MEMOIRE DE FIN D’ETUDE en vue de l’obtention du DIPLOME D ...

N° d’ordre : 07/TCO/GTR Année Universitaire : 2005 / 2006

UNIVERSITE D’ANTANANARIVO

---------------------

ECOLE SUPERIEURE POLYTECHNIQUE

----------------------

DEPARTEMENT TELECOMMUNICATION

MEMOIRE DE FIN D’ETUDE

en vue de l’obtention

du DIPLOME D’INGENIEUR

Spécialité : Télécommunications

Option : Génie de télécommunications et Réseaux

par : RAZAFINDRAKOTOHASINA Andriniaina Jonah

ETUDE DE LA PERFORMANCE DU RESEAU FDDI PAR LA METHODOLOGIE D'ANALYSE TEMPORELLE

Soutenu le 31 janvier 2007 devant la Commission d’Examen composée de :

Président :

M. RAZAKARIVONY Jules

Examinateurs :

M.ANDRIAMIASY Zidora

M.BOTO ANDRIANANDRASANA Jean Espérant

M.RANDRIARIJAONA Lucien Elino

Directeur de mémoire :

RATSIHOARANA Constant

Date de soutenance : 31 Janvier 2007

REMERCIEMENTS

Je rends grâce à Dieu pour sa bonté, de m’avoir donné la force et la santé durant la réalisation

de ce mémoire.

Je tiens également à adresser mes vifs remerciements aux personnes suivantes sans qui ce

travail de mémoire n’aurait pas pu être réalisé :

Monsieur RAMANANTSIZEHENA Pascal, Professeur, Directeur de l’Ecole Supérieure

Polytechnique d’Antananarivo (ESPA), pour mes cinq années d’études.

Monsieur RANDRIAMITANTSOA Paul Auguste, Professeur, Chef du Département

Télécommunication à l’ESPA;

J’adresse mes sincères remerciements à Monsieur RAZAKARIVONY Jules, Maître de

conférence, Enseignant-Chercheur au sein du Département Télécommunication pour l’honneur qu’il

me fait de présider mon jury.

Monsieur RATSIHOARANA Constant, Assistant, Enseignant-Chercheur au sein du

Département Télécommunication à l’ESPA, Directeur de ce mémoire qui malgré ses lourdes

responsabilités m’a toujours prodigué ses conseils. Je tiens à lui adresser toute ma gratitude ;

Monsieur ANDRIAMIASY Zidora, Maître de conférence, Enseignant-Chercheur au sein du

Département Télécommunication à l’ESPA, membre du Jury ;

Monsieur BOTO ANDRIANANDRASANA Jean Espérant, Assistant, Enseignant-Chercheur

au sein du Département Télécommunication à l’ESPA, membre du Jury ;

Monsieur, RANDRIARIJAONA Lucien Elino, Assistant, Enseignant-Chercheur au sein du

Département Télécommunication à l’ESPA, membre du Jury ;

Mes vifs remerciements s’adressent également à tous les enseignants et personnels de l’Ecole

Supérieure Polytechnique d’Antananarivo en général et ceux du Département Télécommunication en

particulier, sans leurs efforts notre formation n’aurait pas pu atteindre ce stade.

Je n’oublierai pas ma famille pour leurs soutiens et leurs encouragements, pour ce mémoire,

comme en toutes circonstances.

Plus particulièrement, à mes parents pour leurs sacrifices durant ces longues années afin que je

puisse arriver à ce niveau et pour tout ceux qui ont contribué de près ou de loin à l’élaboration de ce

mémoire.

AVANT PROPOS

L'informatique d'entreprise, autrefois dominée par les systèmes centraux (mini-ordinateurs et

grands systèmes), a été bouleversée par le développement de la micro-informatique. Celle-ci a apporté

à ses utilisateurs et aux informaticiens des outils efficaces, plus souples, plus confortables et surtout

moins onéreux.

L’augmentation sans cesse des trafics et l’utilisation d’applications multimédias incluant

images, sons et parfois vidéos nécessitent des débits largement supérieurs aux possibilités de la

majorité des réseaux installés. Ces nouveaux besoins en hauts débits sont à l’origine de l’émergence de

nouvelles solutions techniques telles qu’ATM, FDDI, Gigabit Ethernet, etc.

Grâce à ce mémoire, on va essayer d’étudier, puis d’analyser la performance du réseau FDDI.

TABLES DES MATIERES

TABLES DES MATIERES ……………………………………………………………………………….… .......

NOMENCLATURES ……………….……………………………………………………………………..… ......

INTRODUCTION …………………………………………………………………………………………… .......

CHAPITRE 1. : GENERALITES SUR LES RESEAUX ………………………………………………...… ..... 1.1. Principe d’un modèle en couches ...................................................................................................................................

1.1.1. Définition ..................................................................................................................................................................... 1.1.2. Modularité .................................................................................................................................................................. 1.1.3. Communications verticales ....................................................................................................................................... 1.1.4. Communications horizontales ................................................................................................................................... 1.1.5. Schéma global .............................................................................................................................................................

1.2. Le modèle O.S.I. .............................................................................................................................................................. 1.3. Le modèle I.E.E.E. du comité 802 ..................................................................................................................................

1.3.1. Présentation du modèle ............................................................................................................................................. 1.3.2. Normalisation de l’I.E.E.E. .......................................................................................................................................

1.4. Services et protocoles ....................................................................................................................................................... 1.4.1. Définitions ...................................................................................................................................................................

1.4.1.1. Service ............................................................................................................................................................................... 1.4.1.2. Protocole ...........................................................................................................................................................................

1.4.2. Fonctionnement .......................................................................................................................................................... 1.4.2.1. Fonctionnement global ..................................................................................................................................................... 1.4.2.2. Dénomination des primitives de service ............................................................................................................................

1.5. Topologie et architecture ................................................................................................................................................. 1.5.1. Différents types de topologie .....................................................................................................................................

1.5.1.1. Bus ..................................................................................................................................................................................... 1.5.1.2. Anneau .............................................................................................................................................................................. 1.5.1.3. Etoile ................................................................................................................................................................................. 1.5.1.4. Architectures mixtes ..........................................................................................................................................................

1.5.2. Architecture physique et logique .............................................................................................................................. 1.6. Caractéristiques des réseaux ........................................................................................................................................... 1.7. Un médium, des Média ....................................................................................................................................................

1.7.1. Les câbles coaxiaux .................................................................................................................................................... 1.7.2. Les paires torsadées ................................................................................................................................................... 1.7.3. Les fibres optiques .....................................................................................................................................................

CHAPITRE 2. : LE RESEAU FEDERATEUR FDDI …………………………………………………….. ...... 2.1. Introduction ...................................................................................................................................................................... 2.2. La norme ISO9314 : F.D.D.I. .........................................................................................................................................

2.2.1. Principe ....................................................................................................................................................................... 2.2.2. Caractéristiques .........................................................................................................................................................

2.3. Types de nœud FDDI ...................................................................................................................................................... 2.4. Architecture d’une station FDDI ..................................................................................................................................... 2.5. La couche physique .......................................................................................................................................................... 2.6. La couche liaison ..............................................................................................................................................................

2.6.1. Media Access Control (MAC) ................................................................................................................................... 2.6.1.1. La classe de service synchrone .......................................................................................................................................... 2.6.1.2. La classe de service asynchrone ........................................................................................................................................

2.6.2. Logical Link Control (LLC) ...................................................................................................................................... 2.6.3. Station ManagemenT (SMT) ....................................................................................................................................

2.7. Les trames FDDI .............................................................................................................................................................. 2.7.1. La trame du jeton ....................................................................................................................................................... 2.7.2. Les trames des données ..............................................................................................................................................

4

2.7.2.1. La trame LLC .................................................................................................................................................................... 2.7.2.2. La trame SMT ...................................................................................................................................................................

2.7.2.2.1. SMT Hdr .................................................................................................................................................................... 2.7.2.2.2. SMT info ....................................................................................................................................................................

2.7.2.3. La trame MAC .................................................................................................................................................................. 2.8. Le fonctionnement du protocole FDDI ...........................................................................................................................

2.8.1. Circulation du jeton ................................................................................................................................................... 2.8.2. Les temporisateurs .....................................................................................................................................................

2.8.2.1. TTRT (Target Token Rotation Time). ............................................................................................................................... 2.8.2.2. TRT (Token Rotation Timer) ............................................................................................................................................ 2.8.2.3. LATE_CT (Late Counter) ................................................................................................................................................. 2.8.2.4. THT (Token Holding Timer) ............................................................................................................................................ 2.8.2.5. TVX (Timer Valid Transmission) .....................................................................................................................................

2.8.3. Le partage de la bande passante ............................................................................................................................... 2.9. Les modes de fonctionnement et gestion SMT ................................................................................................................

2.9.1. Le processus Claim .................................................................................................................................................... 2.9.2. Le processus beacon ................................................................................................................................................... 2.9.3. L’administration FDDI ..............................................................................................................................................

CHAPITRE 3. : ETUDE DE LA PERFORMANCE DU RESEAU PAR LA METHODOLOGIE D’ANALYSE TEMPORELLE……………………………………………………………………………… .......

3.1. Introduction au système temps réel ................................................................................................................................. 3.2. Contextes temps réel] ........................................................................................................................................................ 3.3. Tâches temps réel .............................................................................................................................................................

3.3.1. Tâches périodiques ..................................................................................................................................................... 3.3.1.1. Paramètres temporels des tâches temps réel ..................................................................................................................... 3.3.1.2. Caractérisations de l’exécution d’un système de tâches ...................................................................................................

3.3.2. Tâches non périodiques ............................................................................................................................................. 3.3.2.1. Tâches sporadiques ........................................................................................................................................................... 3.3.2.2. Tâches apériodiques ..........................................................................................................................................................

3.3.3. Contextes d’ordonnancement ................................................................................................................................... 3.4. Ordonnancement des tâches ............................................................................................................................................

3.4.1. Les tâches périodiques indépendantes ..................................................................................................................... 3.4.1.1. Les algorithmes d’ordonnancement à priorité fixe ........................................................................................................... 3.4.1.2. Les algorithmes d’ordonnancement à priorité variable ....................................................................................................

3.4.2. Les tâches apériodiques indépendantes ................................................................................................................... 3.4.2.1. Le serveur à scrutation ...................................................................................................................................................... 3.4.2.2. Le serveur ajournable .......................................................................................................................................................

3.4.3. Les tâches dépendantes .............................................................................................................................................. 3.4.3.1. Prise en compte des relations de précédence .................................................................................................................... 3.4.3.2. Prise en compte du partage de ressources ........................................................................................................................

3.4.3.2.1. Le protocole à priorité héritée (PPH) ........................................................................................................................ 3.4.3.2.2. Le protocole à priorité plafond (PPP) ....................................................................................................................... 3.4.3.2.3. Le protocole d’allocation de la pile (PAP) ................................................................................................................

3.5. Les réseaux de communication temps réel ...................................................................................................................... 3.5.1. Architecture ................................................................................................................................................................ 3.5.2. Les messages temps réel ............................................................................................................................................ 3.5.3. Ordonnancement des messages temps réel .............................................................................................................. 3.5.4. Protocoles basés sur la compétition ..........................................................................................................................

3.5.4.1. Le protocole CAN .............................................................................................................................................................. 3.5.4.2. Le protocole CSMA/DCR ..................................................................................................................................................

3.5.5. Protocoles à contrôle centralisé: exemple de World FIP ........................................................................................ 3.5.6. Protocoles à contrôle distribué ..................................................................................................................................

3.5.6.1. Le protocole FDDI ............................................................................................................................................................ 3.5.6.2. Le protocole TDMA ..........................................................................................................................................................

3.6. Méthodes et Outils d’analyse temporelle d’applications temps réel distribuées ............................................................ 3.6.1. . Méthodologie de validation .....................................................................................................................................

3.6.1.1. Le modèle général ............................................................................................................................................................. 3.6.1.1.1. Modèle structurel ....................................................................................................................................................... 3.6.1.1.2. Le modèle temporel de tâches .................................................................................................................................... 3.6.1.1.3. Le modèle temporel de messages ...............................................................................................................................

5

3.6.2. Modélisation de l’application .................................................................................................................................... 3.6.2.1. Calcul du temps de propagation d’un message : Cm ........................................................................................................

3.6.2.1.1. Réseau World FIP ...................................................................................................................................................... 3.6.2.1.2. Réseau CAN ............................................................................................................................................................... 3.6.2.1.3. Autres Réseaux ..........................................................................................................................................................

3.6.2.2. Cas pour le réseau FDDI .................................................................................................................................................. 3.6.2.3. Calcul des dates d’insertion des messages ........................................................................................................................

3.7. Prise en compte de la précédence .................................................................................................................................... 3.7.1. Mise à jour des dates de réveil des tâches réceptrices ............................................................................................ 3.7.2. Mise à jour des dates de réveil des tâches successeurs ...........................................................................................

CHAPITRE 4. : SIMULATION SOUS MATLAB 6p5 …………………………………………………… ....... 4.1. Présentation de MATLAB ................................................................................................................................................ 4.2. Fonction de MATLAB pour les graphiques ................................................................................................................... 4.3. Présentation du logiciel ....................................................................................................................................................

4.3.1. La première étape : La modélisation ........................................................................................................................ 4.3.2. La deuxième étape : La prise en compte de la précédence ..................................................................................... 4.3.3. La troisième étape : ....................................................................................................................................................

CONCLUSION………………………………………………………………………………………………… ....

ANNEXES …………………………………………………………………………………………………….. .....

ANNEXE 1 : Liaison par fibre optique……………………………………………………………………… ......

ANNEXE 2 : Le code 4B/5B…………………………………………………………….…………………… .......

ANNEXE 3 : FDDI II, FFOL et TPDDI………………………………………………….………………… ......

BIBLIOGRAPHIE…………………………………………………………………………………………… .......

6

NOMENCLATURES

c : la durée d’exécution, égale à la borne supérieure du temps processeur

nécessaire à l’exécution de la tâche

dB : décibel

km : Kilomètre

kbps : kilobits par seconde

( , , , )m m m mm r C D P= : Modélisation temporelle d’un message m

nm : nanomètre

rm : Date d’insertion de message

rr * : Date de réveil de tâche réceptrice

rs * : Date de mise à jour de la tâche successeur

( , , , )A A A AA r C D P= : la modélisation temporelle d’une tâche A

D : Délai critique, intervalle de temps à partir de la date de réveil, durant

lequel la tâche doit s’exécuter

Dm : Délai de transmission d’un message

Cm : Temps de propagation d’un message

Gbps : Gigabits par seconde

Mbps : Mégabits par seconde

P : Période, intervalle de temps fixe qui sépare les arrivées successive

d’une tâche

Pm : Période de la tâche émettrice du message

µm : micromètre

ANSI : American National Standards Institute

ATM : Asynchronous Transfert Mode

CAN : Controller Area Network

CEM : Configuration Element Management

CSMA/CA : Carrier Sense Multiple Access with Collision Avoidance

7

CSMA/DCR : Carrier Sense Multiple Access/ Deterministic Collision Resolution

DAC : Dual Attachment Concentrator

DAS : Dual Attachment Station

DBDQ : Distributed Bus Data Queue

DM : Deadline Monotonic

DSAP : Destination Service Access Point

DTE : Data Terminal Equipment

ECF : Echo Frame

ECM : Entity Coordination Management

ED1 : End Delimiter (trame)

ED2 : Earliest Deadline (Algorithme d’ordonnancement à priorité variable)

ESF : Extended Service Frame

FC : Frame Control

FCS : Frame Control Check

FDDI : Fiber Distributed Data Interface

FIP : Factory Instrumentation Protocol

FS : Frame Status

FTP : Files Transfert Protocol

IEEE : Institute of Electrical and Electronic Engineers

ISO : International Standardization Organization

LAN : Local Area Network

LATE_CT : LATE_Counter

LED ou DEL : Diode électroluminescente

LLC : Logical Link Control

MAC : Medium Access Control

MAN : Metropolitan Area Network

8

MAP : Manufacturing Automation Protocol

MAU : Medium Attachment Unit

NIF : Neighbor Information Frame

NRZ : Non Retour à Zéro

NRZI : Non Retour à Zéro inversé

OSI : Open System Interconnection

PA : Préambule

PAP : Protocole d’Allocation de la Pile

PCM : Physical Connection Management

PDU : Protocol Data Unit

PDH : Plesiochronous Digital Hierarchy

PPH : Protocole à Priorité Hérité

PL : Physical Layer

PPP : Protocole à Priorité Plafond

PMD : Physical Medium Dependent

PMF : Parameter Management Frame

PS : Physical Signal

RAF : Ressource Allocation Frame

RDF : Request Denied Frame

RM : Rate Monotonic

SAC : Simple Attachment Concentrator

SAP : Service Access Point

SAS : Simple Attachment Station

SD : Starting Delimiter

SDH : Synchronous Digital Hierarchy

SDU : Service Data Unit

SIF : Status Information Frame

SMT : Station ManagemenT

9

SRF : Status Report Frame

SSAP : Source Service Access Point

TDMA : Time Division Multiple Access

THT : Token Holding Timer

TRT : Token Rotation Timer

TTRT : Target Token Rotation Timer

TVX : Timer Valid Transmission

UTP : Unshied Twisted Pair

10

INTRODUCTION

Les réseaux télécommunication et les réseaux informatiques ont connus des bouleversements sans

précédents durant les vingt dernières années. Cela se rapporte sur la demande sans cesse d’améliorer le

débit de communication.

Le problème se pose : sur quel moyen de communication, peut on accéder à ce stade ? Le choix d’utiliser

la fibre optique, avec ses technologies très avancées pourrait être une solution. On constate une

augmentation de la capacité des réseaux, avec une exploitation plus rapide.

En réalité, le réseau utilisant la fibre optique comme l’élément physique constitue l’épine dorsale de

communication, non seulement par sa vitesse de propagation qui est la célérité de la lumière dans le vide,

mais également par son débit offert qui peut atteindre le térabit. Ces caractéristiques peuvent être très

utiles à la transmission des données de tailles très importantes avec un délai de propagation moindre. On

peut notamment utiliser ce support à l’Internet pour remédier à l’explosion des nouveaux services accrûs

nécessitant une large bande de transmission de données.

Ainsi, ce mémoire donne un aperçu sur le fonctionnement du réseau, normalisé par l’ISO9314, portant sur

la création du réseau « backbone » FDDI. A cet effet, le plan de ce mémoire sera composé de quatre

chapitres comme suit :

Le chapitre 1 esquisse en général la modélisation en couches des systèmes présents dans le réseau en vu

de savoir ses propres fonctions et ses caractéristiques. Il traitera également à énumérer les éléments des

bases lors de la mise en place d’un réseau.

Le chapitre 2 sera basé sur l’étude de base du réseau fédérateur FDDI, comment se comporte cette épine

dorsale, quels sont ses paramètres caractéristiques, peut on faire confiance à son fonctionnement

dépendant du principe de la circulation du jeton temporisé sur anneau. On parlera également comment

gérer les station FDDI, en vu de connaître ses principaux points forts et ses inconvénients.

Le chapitre 3 étudiera la performance du réseau par la méthodologie d’analyse temporelle, dans le cadre

de dégager les caractéristiques temporelles des tâches soumises par le réseau durant les transmission des

données. On mentionnera non seulement la modélisation temporelle des tâches, mais également, on

traitera de la même manière les messages. A cet effet, différents protocoles et procédures seront vus

durant cette analyse.

La partie simulation sera consacrée au chapitre 4. Ce dernier aura pour fonction majeure la mise en

fonction d’un logiciel conçu par moi-même sous MATLLAB 6p5.

Une conclusion générale sera affichée à la fin de ce mémoire, résumant le travail effectué.

11

CHAPITR1. : GENERALITES SUR LES RESEAUXDurant ces dernières années, une multitude de types de réseaux sont venus enrichir le monde de la

communication informatique. Bien que toutes ces solutions aboutissent au même résultat. Connecter vos

unités informatiques entre elles, le choix du type de réseau reste crucial afin de pouvoir vous garantir une

performance accrue mais également une flexibilité maximale.

1.1. Principe d’un modèle en couches [1]

1.1.1. DéfinitionLa mise en oeuvre de systèmes complexes, comme peuvent l’être les réseaux informatiques, nécessite de

mettre en place des outils pour spécifier, réaliser, comprendre ou dépanner. Le terme de « modèle » est en

général utilisé pour ce qui concerne les réseaux. Le modèle le plus connu (voire l’unique) est le modèle en

couches. Il peut se résumer de la manière suivante :

Modèle en couches : modularité, restriction sur les communications verticales et possibilité de

communications horizontales

1.1.2. ModularitéC’est la décomposition d’un problème complexe en plusieurs sous–problèmes :

• Simplification du problème,

• Répartition des taches,

• Gestion des communications par entrées–sorties identifiées.

Figure 1.1 La modularité

1.1.3. Communications verticalesLa restriction sur les communications verticales induit un aspect hiérarchique : un seul type de

communication vers le bas : une couche utilise les services offerts par la (ou les) couche(s)

immédiatement inférieure(s). Elle effectue des demandes de services.

Un seul type de communication vers le haut : une couche fournit des services à la (ou les) couche(s)

immédiatement supérieure(s).

12

Figure 1.2 Communication verticale

1.1.4. Communications horizontalesIl existe une seule manière de communiquer avec la même couche d’un autre système. Le langage de

communication entre couches de même niveau doit être le même (protocole).

Figure 1.3 Communication horizontale

1.1.5. Schéma globalDans un modèle en couches de réseau, la communication entre deux machines est représentée par une

liaison globale correspondant à autant de liaisons virtuelles que de couches. En fait, seule une couche (le

médium) assure une liaison réelle.

Figure 1.4 Schéma global

1.2. Le modèle O.S.I. [1], [21]Le modèle O.S.I. (Open System Interconnection) de l’I.S.O. (International Standardization

Organization) est une architecture générale applicable à un réseau. C’est un concept hiérarchisé

d’organisation (matériel et logiciel). Il existe des produits respectant ce concept, mais il n’y a pas de

correspondance directe avec des produits commerciaux.

Description de chaque couche.

Couche Application : interface d’accès aux services réseaux pour les applications ou les utilisateurs.

Exemple : transfert de fichiers (FTP).

Couche Présentation : mise en forme, codage, compression, cryptage des données utilisateurs.

Couche Session : gestion d’une session de connexion (ouverture, fermeture, reprise sur incident),

connexion : temps de communication entre 2 observateurs.

13

Couche Transport : contrôle de bout en bout de la transmission : rassemble les paquets, élimine ceux en

trop...

Couche Réseau : interconnexion entre réseaux physiquement hétérogènes, choix du chemin entre deux

utilisateurs (adresses).

Couche Liaison : gestion de l’accès au médium, contrôle des erreurs (travail sur un train d’information).

Couche Physique : définition des interfaces électriques, mécaniques, transmission des bits sur le circuit de

communication (câble, fibres optiques).

Figure 1.5 Le modèle O.S.I.

1.3. Le modèle I.E.E.E. du comité 802 [1], [22]

1.3.1. Présentation du modèleLe modèle du comité 802 de l’I.E.E.E. ne décrit que les couches basses de la communication par réseau.

Il concerne uniquement les couches 1 et 2 du modèle O.S.I. mais il définit deux sous- couches

relativement à la couche « Liaison » de l’ISO.

Sous couche LLC (Contrôle de liaison logique) : elle décrit les procédures d’adressage et de mise en

oeuvre de la liaison.

Sous couche MAC (Contrôle d’accès au médium) : elle réalise la gestion des accès : exclusion, priorité,

erreur, collision.

Couche PS (Signal Physique) : elle est équivalente à la couche Physique O.S.I.

Interface MAU (unité d’accès au médium) : elle vient se rajouter entre le médium et la couche PS pour

définir la connexion.

Figure 1.6 Le modèle I.E.E.E. du Comité 802

1.3.2. Normalisation de l’I.E.E.E.A partir de ce découpage, l’I.E.E.E. a constitué un ensemble de normes. Les principales différences se

situent au niveau MAC où plusieurs normes ont été définies, chacune correspondant à un fabricant ou

groupe de fabricants. De plus, l’utilisation d’une norme au niveau MAC conditionne largement les choix

pour la plupart des autres couches ceci en fonction des offres des constructeurs :

• IEEE 802.3 ou Ethernet. Mise en place par Xérox et beaucoup d’autres, ce sont des réseaux à 10 Mbits/s

(100 Mbits ou même 1 Gbits dans une nouvelle mise en oeuvre). La méthode d’accès est dite à

compétition.

• IEEE 802.4 ou Token Bus (jeton sur bus). C’est un réseau industriel créé par GM (réseau MAP. Les

14

débits sont de 1 Mbits/s, 5 Mbits/s, 10 Mbit/s. Le support est souvent du coaxial type TV.

• IEEE 802.5 ou ISO 8802.5 ou Token Ring (jeton sur anneau). Défini à l’instigation d’IBM, il permet

des débits de 1 Mbits/s, 4 Mbits/s, 16 Mbit/s.

1.4. Services et protocoles [1]

1.4.1. Définitions

1.4.1.1. ServiceUn service correspond à un dialogue vertical. Lors de ce dialogue, on dit que :

• Une couche N fournit un service à la couche N+1,

• Une couche N utilise un service de la couche N-1.

Exemple : transmission de message, ouverture d’une connexion

15

Remarque :

Celui qui utilise le service ne sait pas comment il est réalisé (principe de transparence). Une entité peut

fournir un service à plusieurs utilisateurs (SAP : Service Access Point). L’unité d’échange s’appelle une

SDU.

SDU : Service Data Unit, message de service entre deux couches.

1.4.1.2. ProtocoleUn protocole correspond à un dialogue horizontal entre deux couches de même type pour deux machines

différentes. C’est une règle de dialogue entre deux entités appartenant à une couche de même type.

L’unité d’échange est une PDU. PDU : Protocol Data Unit : message de protocole (à l’intérieur d’une

couche).

Remarque :

On peut changer de protocole sans changer de service.

1.4.2. Fonctionnement

1.4.2.1. Fonctionnement globalOn peut le décrire en 3 étapes de base :

1. Une entité de niveau N reçoit une SDU de la part de la couche N+1,

2. Elle doit transmettre une PDU à l’entité distante de même niveau,

3. Pour cela elle émet une SDU pour utiliser un service de la couche N-1.

Ensuite, le même mécanisme est recommencé, jusqu’à arriver à la couche la plus basse : le médium, qui

réalise effectivement l’échange de données :

(N)SDU (N) PDU (N-1) SDU ..... médium

Un mécanisme inverse est mis en jeu lors de la réception d’une (N) PDU, la couche concernée transmet à

la couche supérieure un service sous la forme d’un bloc de données :

(N-1)PDU (N-1) SDU (N) PDU...

16

Figure 1.7 Fonctionnement global

1.4.2.2. Dénomination des primitives de serviceIl est nécessaire de définir des notations pour comprendre le fonctionnement des échanges. Le formalisme

est commun quelles que soient les couches, il est réalisé à l’aide de primitives.

Notation : (name) _ (service) _ (command) :

nom de la couche concernée type de service type de commande

• demande de service : ******_******_REQUEST

• transmission d’une demande : ******_******_INDICATION

• réponse à une transmission : ******_******_RESPOND

• réponse à une demande : ******_******_CONFIRM

RESPOND et CONFIRM ne sont pas obligatoires. Ils dépendent du type de service demandé (avec ou

sans accusé).

1.5. Topologie et architecture [1]

1.5.1. Différents types de topologieLa topologie d’un réseau local ou son architecture d’interconnexion est la manière dont les différents

postes d’un réseau sont reliés.

1.5.1.1. BusToutes les machines sont reliées au même câble. Les données sont disponibles à chaque instant pour tous

les postes.

17

Figure 1.8 La topologie en bus

1.5.1.2. AnneauLes données circulent de machine en machine. Une machine ne voit que la précédente et la suivante via

des liaisons point à point. Les données sont disponibles de manière séquentielle sur les postes.

Figure 1.9 La topologie en anneau

1.5.1.3. EtoileC’est l’archétype d’une structure centralisée. Un poste concentre les données, il fait office d’aiguillage.

Une panne du noeud central bloque toutes les communications. Le nœud central doit avoir une puissance

importante.

Figure 1.10 La topologie en étoile

1.5.1.4. Architectures mixtesToutes les combinaisons des précédentes peuvent être faite pour constituer une topologie plus complexe.

Figure 1.11 La topologie mixte

1.5.2. Architecture physique et logiqueEn fait, il existe une distinction importante entre les connexions électriques (architecture physique) et le

type de fonctionnement, d’échange de données (architecture logique). L’un et l’autre ont une importance

suivant le niveau d’intérêt dans les couches du modèle.

Figure 1.12 Bus physique - Anneau logiqueLes échange de données se font dans l’ordre suivant 1→2→3→4→5→1.... (anneau)

Les données sont systématiquement propagées dans toutes les branches de l’arbre.

Figure 1.13 Arbre physique - Bus logique

1.6. Caractéristiques des réseaux [1]Suivant le type d’architectures physique et logique, les réseaux n’auront pas les mêmes caractéristiques

topologiques ni les mêmes propriétés de fonctionnement.

Certaines caractéristiques sont directement liées au choix de l’architecture :

18

• Type de liaison : point à point, multipoints, régulière, irrégulière.

• Hiérarchie des machines : identiques ou maître–esclave.

Plusieurs propriétés en découlent :

• Connectivité : facilité d’accès aux autres stations.

• Diffusion : capacité à émettre vers toutes les stations.

• Reconfiguration : facilité pour ajouter ou enlever une machine.

• Sûreté de fonctionnement : sensibilité aux défaillances d’un élément.

• Facilité de câblage.

• Fiabilité du câblage : rupture totale de la communication, parasitage, espionnage.

• Prix.

Ces propriétés seront à prendre en compte lors du choix de réalisation d’un réseau. Nous verrons au fur et

à mesure du cours les propriétés de chaque type de réseaux, et dans ce chapitre tout ce qui concerne la

réalisation avec des éléments physiques.

1.7. Un médium, des Média [1]

1.7.1. Les câbles coaxiauxLes câbles coaxiaux ont une bonne immunité aux perturbations électromagnétiques. Ils permettent de

réaliser des réseaux ayant des bandes passantes utiles de 10 à 100 Mhz. Leur montage est relativement

facile. Ils sont surtout adaptés pour des topologies physiques de type bus. Leur coût est relativement

faible.

Figure 1.14 : Le câble coaxial « jaune », ou gros Ethernet : RG11 (câble jaune)

1.7.2. Les paires torsadéesUne paire torsadée est constituée de deux fils souples enroulés l’un autour de l’autre avec un pas réduit (6

torsades par mètre). Les paires sont en général regroupées dans des câbles. Ceux-ci peuvent avoir un

grand nombre de paires. Ces câbles ont été initialement utilisés dans les liaisons téléphoniques (paire

téléphonique).

19

Figure 1.15 Paire non blindée (UTP Unshielded Twisted Pair)

1.7.3. Les fibres optiquesLa transmission de l’information dans des fibres optiques est réalisée par modulation de l’amplitude de la

lumière d’un émetteur (diode, laser) placé à un bout de la fibre, un récepteur étant placé à l’autre

extrémité. Il existe deux types de fibres : les fibres en verre et en plastique. La première possède de

meilleures performances en terme d’affaiblissement, mais est légèrement plus coûteuse et surtout plus

difficile d’usage (fragilité) : elle est utilisée dans les liaisons rapides à longues distances. La deuxième ne

peut être utilisée que sur de courtes distances avec des débits plus réduits.

Figure 1.16 La fibre optique

Les fibres optiques sont insensibles aux perturbations électromagnétiques, l’isolement électrique est total.

Elles ont une atténuation du signal très faible. Elles sont légères mais relativement fragiles. Leur

connexion est difficile rendant assez cher un câblage de ce type. Elles assurent une très bonne

confidentialité des données. Elles sont utilisées pour des liaisons point à point à grande distance ou dans

des environnements très perturbés. Le domaine des grands débits leur est en général aussi réservé

(>100Mbits/sec).

Elles sont utilisées dans les câblages principaux des réseaux (backbone ou anneau principal) :

- Ethernet sur fibre optique, 100 base FX [F≡Fibre optique],

- tokenRing type 5 pour l’anneau principal,

- FDDI (Fiber Distributed Data Interface), réseau à 100Mbits/sec pouvant relier sur

200 km 1000 stations sur deux boucles en fibre optique.

Dans ce chapitre, on a essayé de voir la notion générale sur le réseau. On a pu modéliser ce dernier en une

succession des couches (modèle OSI), qui se communiquent entre elles par l’intermédiaire des services et

des protocoles mis en jeu. On a entamé aussi sur la normalisation IEEE afin de déterminer le

fonctionnement global de deux premières couches du modèle OSI.

20

CHAPITR2.: LE RESEAU FEDERATEUR FDDI

2.1. IntroductionAvec le progrès technologique effectué depuis les années 1980 sur les supports de transmissions utilisant

la fibre optique nous avons vu depuis 1987 l'émergence de nouveau mode de transmission utilisant ce

support.

Jusqu'à lors des protocoles comme IEEE 802.3, 802.4, 802.5 avaient été conçus pour fonctionner avec des

supports dit "électrique" (câbles de type paires torsadées ou coaxiaux) dont les vitesses de transmissions

étaient de l'ordre de 10 Mbps. Depuis peu les vitesses atteintes sont de 10 Gbps mais sur des distances très

courtes (inférieur à 1 Km). La solution fibre optique permet de passer à des supports hautes performances

dont les vitesses sont d'une centaine de Mégabit/s sur des distances supérieures à 100 km. Cette solution

connue sous le nom de FDDI (Fiber Data Distributed Interface) provient du milieu informatique, et plus

particulièrement du secteur des réseaux locaux dont elle constitue une sorte d'extension

2.2. La norme ISO9314 : F.D.D.I. [1], [2], [17]

2.2.1. PrincipeFDDI (Fiber Distributed Data Interface) est un réseau à haut débit (100 Mbps) et grande distance (200

km). C’est en général un réseau fédérateur (interconnexion de réseaux locaux). On peut le classer dans la

catégorie des MAN.

Figure 2.1 Le réseau d’Interconnection FDDI

Il possède une topologie en double anneau à fibre optique, ce qui permet d’allier sécurité et rapidité. Une

coupure sur le réseau n’interrompt pas le fonctionnement total, mais conduit à une reconfiguration du

câblage.

2.2.2. Caractéristiques L'architecture FDDI permet de gérer des débits pouvant atteindre 200 Mbit/s avec un mécanisme de

reconfiguration automatique, à 100 Mbps, en cas de rupture d'un anneau. FDDI est un ordre plus vite que

Ethernet et six fois plus vite que le Token Ring d'IBM. Le module de gestion intégré au réseau, Station

Management (SMT), place FDDI comme le réseau local standardisé le plus performant.

Les caractéristiques de FDDI le font entrer à la fois dans la catégorie des réseaux LAN et des réseaux

MAN. Son utilisation principale est la fédération de réseaux locaux à moyen débit. Dans ce cas

d'utilisation, il est appelé réseau backbone car il constitue l'épine dorsale du système de communication.

21

La capacité de transmission de FDDI rend transparent à l'utilisateur le passage par ce réseau fédérateur.

Topologie Anneau doublé contre rotatifTechnique d'accès jeton temporisé sur boucleDistance de raccordement 200 km (100 Km quand le réseau est à plat)Diamètre de l'anneau 31 km (uniquement sous forme de boucle)Nombre de noeud sur l'anneau 500 (DTE) en classe A

1000 (DTE) en classe B Distance maximale entre deux stations 2 kmDébit nominal 100 MbpsAnneau pouvant aller jusqu'à 100 kmGestion Système d'administration intégré (SMT)Fiabilité Tolérance aux pannes par reconfigurationTaille des trames Trame maximale de 4490 octetsCodage NRZI 4 bits/5 bitsAdressage 16 ou 48 bitsPrincipal protocole TCP/IPSupport Fibre optique normalisée 62,5/125

Tableau 2.1 Les caractéristiques du réseau FDDI

Chaque station est reliée à la précédente par deux fibres optiques en mode point à point. L'anneau

primaire est utilisé pour la transmission normale des données dans un sens. L'anneau secondaire sert de

secours inactif dans l'autre sens. Cet anneau n'est utilisé qu'en cas de coupure de l'anneau primaire suite à

une reconfiguration automatique de l'anneau par rebouclage. Si plusieurs défaillances se produisent le

réseau se scindera en plusieurs sous anneaux indépendants.

Figure 2.2 Panne sur FDDI

2.3. Types de nœud FDDI [2]La topologie permet deux types d'attachements : accès aux deux anneaux ou à un seul. La norme ANSI

définit trois classes de stations :

classe A : désigne les stations à attachement double (DAS: Dual Attachment Station). Les stations

22

de classe A sont reliées directement aux deux anneaux simultanément.

classe B : désigne les stations à attachement simple (SAS : Simple Attachment Station). Les

stations sont reliées à un seul anneau. Une station de classe B n'a pas la possibilité de se raccorder

directement à l'anneau, elle ne peut s'y relier que par l'intermédiaire d'un concentrateur.

classe C : désigne les concentrateurs FDDI. Un concentrateur de niveau 1 (DAC : Dual

Attachment Concentrator), est rattaché directement au double anneau, tandis qu'un concentrateur de

niveau 2 (SAC : Simple Attachment Concentrator) est relié soit à un concentrateur de niveau 1, soit à un

autre concentrateur de niveau 2. Les deux types de concentrateurs possèdent des ports supplémentaires

permettant de raccorder des stations de travail. Ces stations ne sont pas physiquement reliées à l'anneau

mais elles en font logiquement partie.

Figure 2.3 Port FDDI DAS

Figure 2.4 Combinaison de noeuds FDDI

2.4. Architecture d’une station FDDI [2]A la différence de ATM et DBDQ, FDDI définit son propre support physique. FDDI n’est pas conçu pour

utiliser les supports types liaisons spécialisées, hiérarchie PDH, ou SDH des opérateurs.

Figure 2.5 Modèle FDDI

2.5. La couche physique [2], [16]Le niveau physique PL (Physical Layer) est constitué de deux sous-couches :

La sous-couche PMD (Physical Medium Dependent) offre tous les services nécessaires aux

communications numériques point à point entre les stations dans un réseau FDDI, c'est-à-dire à la

transmission de flots de bits codés, d'une station à l'autre. La PMD définit et caractérise les émetteurs et

23

récepteurs optiques, les contraintes de codage imposées par le support, les câbles, les connecteurs, les

bilans énergétiques, les relais optiques et autres caractéristiques physiques.

La sous-couche PMD fait l'objet d'une norme : ISO 9314.3. Dans cette norme ont été définis :

Le support est constitué de deux fibres afin d'assurer la fiabilité du réseau. Le support en fibre

optique multimode de 62,5/125 µm de diamètre, de bilan optique 11 dB et liaisons limitées à 2

kilomètres. Le support fibre optique monomode, permettant l'établissement de liaisons d'une soixantaine

de kilomètres entre les stations.

la longueur d'onde : 1 300 nm;

l'émetteur : LED;

le connecteur : double connecteur ST.

Figure 2.6 Connecteur FDDI

Figure 2.7 Fibre FDDI

Figure 2.8 Schéma de principe de la couche PMDLa sous-couche PHY (PHYsical layer protocole) fait l'objet du standard ISO 9314.1. Elle définit

l'interface entre les couches PMD et DLL. Le niveau PHY est responsable de la synchronisation et des

codages de décodages. Deux niveaux de codage sont utilisés :

Le PHY convertit les symboles provenant de MAC en bits codés en NRZ ; le code utilisé est un code de

groupe de type 4B/5B, c'est-à-dire un groupe de 4 bits de données est codé en un groupe de 5 bits codés

en NRZ qui, à leur tour, sont codés en une séquence de 5 bits codés en NRZI. L'horloge locale utilisée

dans l'interface physique est de 125 MHz qui, en raison du codage 4B/5B, rapporte un débit de 100 Mbps.

24

Figure 2.9 : Codage des informationsLe codage NRZI consiste à provoquer une transition sur un niveau logique '1' dans un moment

élémentaire et de laisser un état stable pou un niveau logique '0'.

2.6. La couche liaison [2]

2.6.1. Media Access Control (MAC)Cette couche est normalisée par MAC ISO 9314.2. Cette couche définit comment le média est accédé ,

incluant le format des trames, le protocole Timed-Token (Jeton Temporisé), l'adressage, les algorithmes

pour calculer les cyclique redondant, vérifier les valeurs transmises, et les mécanismes de récupérations

d'erreurs.

L'accès au support est contrôlé via un jeton, une station ayant capté le jeton le retransmet immédiatement

sur le support un fois sa transmission terminée. Deux classes de services ont été identifiées sur un réseau

FDDI :

service synchrone;

service asynchrone.

2.6.1.1. La classe de service synchrone Correspond aux applications qui nécessitent une bande passante garantie et/ou un délai d'acheminement

déterministe et des contraintes sur la variation de ces délais.

Afin d'offrir un service satisfaisant au trafic synchrone, le temps de rotation du jeton est contrôlé, c'est-à-

dire que le temps total, mis par celui-ci pour parcourir tout le réseau, doit rester en dessous d'un seuil fixé

par les applications utilisant le réseau. Une valeur cible du temps de rotation du jeton, TTRT (Target

Token Rotation Timer), est établi à l'initialisation du réseau. La valeur TTRT est utilisée pour charger un

temporisateur, désigné TRT (Token Rotation Timer), dont le but est de contrôler le délai de retour du

jeton.

De façon optionnelle, plusieurs niveaux de priorité peuvent être distingués au sein du trafic asynchrone

d'une station, ce qui permet de contrôler la bande passante offerte à ces différentes sources asynchrones.

Plus la priorité d'une station est élevée, plus la bande passante disponible pour les sources asynchrones de

cette priorité est grande.

25

2.6.1.2. La classe de service asynchrone Cette classe de service satisfait les contraintes de trafic en créant une certaine quantité de bande passante

partagée par toutes les stations qui utilisent cette classe de service.

Remarque :

Une trame synchrone pourra être transmise indépendamment de la valeur du TRT. Par contre, une trame

asynchrone ne pourra être émise que si le temporisateur TRT n'a pas expiré.

2.6.2. Logical Link Control (LLC) Elle définit les moyens pour échanger des données entre plusieurs utilisateurs LLC. Elle reprend la norme

IEEE 802.3.

2.6.3. Station ManagemenT (SMT) Elle définit la gestion dans toutes les stations. Elle intervient à tous les niveaux de FDDI, reconstitution.

Elle spécifie le contrôle des sous-couches PMD, PHY et MAC, l’initialisation de l'anneau, gestion des

pannes (détection, isolation et reprise sur erreur, actions à entreprendre en cas d’incidents), la

temporisation, l’établissement des statistiques, le responsable de la configuration, reconfiguration de

l’anneau. Elle contrôle l'anneau avec l'insertion ou le retrait d'une station.

26

2.7. Les trames FDDI [1], [2]Il existe deux formes de trame

Les trames de données ;

Les jetons.

2.7.1. La trame du jetonChamps PA SD FC EDNombre de symboles 2 2 2 2

Tableau 2.2 Format des trames de jeton FDDI

PA : Préambule : 16 symboles I.

SD : Start Delimiter (délimiteur de début) : deux symboles J et K.

FC : Frame Control (type de la trame) (jeton, commandes MAC, données LLC, trame asynchrone).

ED : End Delimiter (délimiteur de fin) : deux symboles T et E (E est mis à "1" si une erreur est détectée).

2.7.2. Les trames des données

Figure 2.10 Format d’une trame, format d’un jetonPA : (Préambule), il est constitué d’au moins 8 octets [16 symboles I (Idle)] par le créateur de la trame et

ils permettent la synchronisation de l’horloge du récepteur

SD : (Starting delimiter). Ce séparateur de début codé sur 1 octet, il sert à délimiter le début d’une trame

ou d’un jeton. Cet octet est composé des valeurs J et K (Ces symboles J et K sont 2 symboles du code

4B/5B).

FC : (Frame Control), codé sur 1 octet il décrit le type de la trame et ses particularités. L’octet est décrit

par la forme suivante :

C L F F Z Z Z Z

C Bit de classe de trameL Bit de longueur d’adresse de trameF Bits de format

27

Z BitsTableau 2.3 Dénomination des bits

Le bit (C) de classe de trame indique la classe du service.

Trame asynchrone (0)

Trame synchrone (1)

Le bit (L) de longueur d'adresse de trame indique la longueur des deux adresses MACs (SA et DA).

Adresse 16 bits (0)

Adresse 48 bits (1)

Les bits (F) de format de trame, avec les bits de CL et ZZZZ indiquent le type de trame.

C L F F Z Z Z Z HEXA Type de trame0 1 0 0 0 0 0 0 40 Trame vide1 0 0 0 0 0 0 0 80 Jeton non restreint1 1 0 0 0 0 0 0 C0 Jeton restreint

De

à

0

0

L

L

0

0

0

0

0

1

0

1

0

1

1

1

41 à

4F

Trame SMT

De

à

1

1

1

1

0

0

0

1

0

r

0

0

0

0

1

0

C1 à

CF

Trame MAC

1 1 0 0 0 0 1 0 C2 Trame de balise1 1 0 0 0 0 1 1 C3 Trame de réclamation

De

à

0

0

1

1

0

0

1

1

0

0

0

1

0

1

0

1

50 à

57

Trame LLC Asynchrone

De

à

1

1

1

1

0

0

1

1

0

0

0

1

0

1

0

1

D0 à

D7

Trame LLC Synchrone

De

à

0

0

1

1

1

1

0

0

0

1

1

1

1

1

1

1

67 à

6F

Trame d’implantation

AsynchroneDe

à

1

1

L

L

1

1

0

0

r

1

0

1

0

1

0

1

E0 à

E7

Trame d’implantation

SynchroneC L 1 1 Z Z Z Z Réservée pour l’évolution de norme

Tableau 2.4 Type de trame suivant les valeurs prises par le bit F

DA SA: sont exactement les mêmes que pour les autres réseaux locaux de type IEEE 802.3 802.5 etc.

Elles sont composées de 6 octets. Chaque station a une adresse unique qui l'identifie. Lorsqu'une station

reçoit une trame, elle compare le champ DA de la trame avec le sien. Si les deux sont égaux, la station

copie le contenu de la trame dans son tampon.

Une trame peut aussi être destinée pour plusieurs stations. Le premier bit dans le DA indique si c'est une

adresse individuelle (0) ou une adresse de groupe (1).

Une adresse peut-être administrée localement ou universellement. Si elle est administrée universellement,

les premiers 3 premiers octets de l'adresse est le n° du manufacturier. Les trois derniers octets

28

différentient les stations.

Localement, l'administrateur du réseau assigne une adresse pour chaque station. Le deuxième bit indique

si l'adresse est universelle (0) ou locale (1).

Adresse à 16 bits :

I/G1 bit

N° d’anneau7 bits

Sous adresse de station8 bits

Adresse à 48 bits

I/G1 bit

U/L1 bit

N° d’anneau14 bits

Sous adresse de station32 bits

Tableau 2.5 : Format des adresses

Le premier tableau désigne une adresse sur 16 bits et le second, une adresse sur 48 bits.

Si I/G = 0, Adresse individuelle

Si I/G = 1, Adresse de groupe

Si U/L = 0, Adresse administrée globalement

Si U/L = 1, Adresse administrée localement

FCS : Codé sur 32 bits selon le polynôme suivant :

x31+x30+x26+x25+x24+x18+x15+x14+x12+x11+x10+x8+x6+x5+x4+x3+x+1

ED : Codé sur 8 bits il est constitué d’un symbole T. Ce symbole T indique que la trame est complète.

Toute séquence de données qui ne se termine pas avec le symbole T n'est pas considérée comme une

trame.

FS : Codé sur 8 bits : permet de connaître l’état de la trame :

Ces indicateurs peuvent être Set ou Reset (positionnés à 1 ou 0).

Toutes les trames sont transmises originalement avec les indicateurs à 0. Les indicateurs peuvent être

changés par les stations intermédiaires lorsqu'elles retransmettront la trame.

Les trois indicateurs sont :

Error (bit E)

Lorsque la station détermine qu'il y a une erreur dans la trame. Si une trame est reçue et que l'indicateur E

est positionné à 1, alors la trame est rejetée

Address recognized (ou Acknowledge) (bit A)

Lorsque la station qui reçoit la trame détermine que la trame est destinée à celui-ci.

Copy. (bit C)

Lorsque la station reçoit une trame et est capable de copier le contenu dans le tampon.

A C r r A C r r

29

Tableau 2.6 Détail octet FS

INFO : Ce champ peut être vide ou contenir un nombre pair de symboles. Sa taille est limitée à 9000

symboles (4490 octets).

Le genre d'information contenu dans la partie information peut être connu en notant le FC :

2.7.2.1. La trame LLCDSAP SSAP Control LLC info

Tableau 2.7 Trame LLC

DSAP est un SAP de l'ordinateur destinataire.

SSAP est un SAP de l'ordinateur source.

Control Il y a trois types définis pour le contrôle. Deux de ceux-ci peuvent transmettre l'information de

l'utilisateur dans le champ LLC Info.

2.7.2.2. La trame SMT

SMT Hdr SMT Info

Tableau 2.8 Trame SMT

2.7.2.2.1. SMT HdrClasse de trame Type de trame Version ID Transaction ID Station ID Pad Longueur

Tableau 2.9 SMT hdr

Classe de trame : 1 octet

Les trames SMT sont identifiées par leur classe et type. La classe identifie la fonction de la trame. Voici

les valeurs possibles

HEXA Description01 Neighbor Information Frame (NIF)02 Status Information Frame Configuration (SIF-Cfg) 03 Status Information Frame Operation (SIF-Opr)04 Echo Frame (ECF)05 Ressource Allocation Frame (RAF)06 Request Denied Frame (RDF)07 Status Report Frame (SRF)08 Parameter Management Frame-Get (PMF-Get)09 Parameter Management Frame-Set (PMF-Set)FF Extended Service Frame (ESF)

Tableau 2.10 La classe des trames

Type de trame : 1 octet

30

Le type de trame est un indicateur que la trame est soit une annonce, une requête ou une réponse.

Hexa Description

1 Annonce

2 Requête

3 Réponse

Version ID : 2 octets

La Version ID indique la structure du SMT Info. Il y a deux valeurs acceptables (jusqu'à présent).

Hexa

0001 Pour les stations qui utilisent une version de SMT sous 7.x.

Les trames NIF, SIF et ECF vont avoir cette valeur pour assurer la comptabilité vers l'arrière.

0002 Pour les stations qui utilisent version 7.x de SMT.

Transaction ID : 8 octets

La Station ID est un identificateur unique de la station qui transmet la trame SMT. Les six octets moins

significatifs sont des adresses universelles administrées dans la représentation MSB. Les deux octets plus

significatifs sont applicateur défini.

Pad : 2 octets

Le Pad existe pour que la longueur du SMT Header soit 32 octets.

Longueur : 2 octets

La longueur du champ SMT Info est reportée dans ce champ. La valeur n'inclus pas la longueur du SMT

Header ou ce champ. La valeur peut être de zéro à 4458 octets.

2.7.2.2.2. SMT info SMT Info consiste en une liste de paramètre qui est de la forme :

Type de paramètre OctetsLongueur du paramètre 2

Indexe de ressource 4Valeur du paramètre n

Tableau II.11 SMT Info

S'il y a plus d'un paramètre présent dans la trame, ils seront lus l’un après l'autre. Le type de paramètre est

la valeur qui identifie le paramètre.

Il y a cinq classes de paramètres.

Hexa Description00zz Paramètres généraux10zz Spécifiquement pour les entités SMT dans une station20zz Paramètre qui résolvent les MACs32zz Résout les PATHs dans une station

31

40zz Résout les PORTs dans une stationTableau 2.12 La classe de paramètre

La longueur de paramètre est la longueur totale de l’index de ressource et de la valeur de paramètre. Elle

est utilisée pour dire où un paramètre se termine et où le prochain commence.

L'index de ressource est l'index qui spécifie quel objet le paramètre décrit (soit un MAC particulier, un

PORT ou un PATH). Ce champ est omis des paramètres de SMT et pour tous paramètres qui ont un type

de forme 00zz.

La valeur du paramètre est l'information actuelle. Elle est divisée d'après le type.

2.7.2.3. La trame MACIl y a deux types de trames MAC :

Claim

Beacon.

Une trame Claim a un FC de C3 et le MAC Info est le T_Bid de la station.

Une trame Beacon a un FC de C2 et un MAC Info comme suit :

Nombre d’octets1 Type de Beacon

00 : Beacon régulier

01: Beacon directionnel

02: Beacon bloquant3 00 00 00

Adresse du voisin (optionnel)Tableau 2.13 Trame beacon

2.8. Le fonctionnement du protocole FDDI [2]

2.8.1. Circulation du jetonComme dans le 802.5 (Token Ring de base) une station qui veut émettre doit d'abord capturer le jeton en

le retirant de l'anneau. Par contre elle diffère du 802.3 dans le sens où le jeton n'est relâché que lorsque

toutes les données émises par la station émettrice lui sont revenues.

Dans FDDI, il peut y avoir simultanément dans les données une succession de plusieurs trames provenant

de stations différentes mais dans tous les cas ces données sont toujours suivies d’un jeton. Lorsqu’un

paquet de données arrive sur une station qui a besoin d’émettre, cette station attend que le jeton passe

pour insérer sa trame dans le paquet et redépose le jeton à la suite.

Chaque station régénère, répète et transmet les informations à la suivante. La station destinataire recopie

32

la trame dans une mémoire tampon et la retransmet après avoir modifié les bits "adresse reconnue" et

"trame copiée" du champ d’état. C'est la station émettrice qui retire de l'anneau les trames qu'elle y a

placées.

Lorsqu’une station est en possession d’un jeton elle ne peut le garder indéfiniment. Il est gardé que pour

une durée limitée, pendant laquelle les données sont émises (données synchrones et données asynchrones

respectivement).Ce temps d’autorisation de détention du jeton peut être ou ne pas être écoulé au terme de

la transmission des données. La norme FDDI spécifie un certain nombre de temporisateurs et de

compteurs.

La norme FDDI fixe un temps de propagation de signal sur l’anneau à 1,667 ms. Les 200 km de câble

contribuent pour 1,077ms et les 1000 stations pour 0.6 ms soit un temps de traverser de chaque station de

600 ns.

Le jeton libre arrive en B.B transmet une information vers E

La trame et le jeton arrive en C, C n’a rien à transmettre, il renvoie la trame T1 et le jeton. D veut transmettre des données vers G.

La trame T1 et le jeton arrivent en D. D renvoie T1, capture le jeton, émet sa trame T2, et réémet un jeton.…E recopie la trame T1, renvoie l’ensemble des données.

La trame T1 arrive en G, et est renvoyée. La trame T2 est recopiée et renvoyée, le jeton est renvoyé.…La trame passe de nœud en nœud jusqu’en B sans autre changement.

La trame T2 est libérée en arrivant sur le nœud E. Le jeton est renvoyé.

33

La trame T1 est libérée en arrivant sur le nœud B. La trame T2 et le jeton sont renvoyés.

Tableau 2.14 Circulation du jeton

2.8.2. Les temporisateursChaque station doit maintenir 3 temporisateurs pour réguler les opérations sur l’anneau. Les valeurs de

ces temporisateurs sont administrées localement. Ces valeurs peuvent varier d’une station à l’autre à

condition que les limites applicables à l’anneau ne soient pas violées.

2.8.2.1. TTRT (Target Token Rotation Time).Il indique le temps moyen permis au jeton pour faire le tour complet de l’anneau. Cette valeur est

négociée entre toutes les stations pendant la phase d’initialisation du réseau. Ce temps est négocié grâce

au processus claim. La valeur la plus faible parmi toutes les propositions est retenue. Cette valeur

négociée doit être comprise entre 4 ms et 167 ms.

T_MAX Valeur maximal pour TTRT

T_MIN Valeur minimal pour TTRT

2.8.2.2. TRT (Token Rotation Timer)Ce compteur permet de mesurer le temps de rotation réel. Il reflète le temps à attendre avant de voir

arriver le jeton. Ce compteur est réarmé à chaque fois qu’une station redépose le jeton. Si ce compteur

expire avant le retour du jeton LATE_CT est incrémenté.

2.8.2.3. LATE_CT (Late Counter)Ce compteur enregistre le nombre d’expiration de TRT depuis la dernière réception du jeton.

2.8.2.4. THT (Token Holding Timer) Elle est positionnée à la valeur TTRT-TRT lorsque le jeton arrive en avance. Le THT permettra

d’envoyer des trames asynchrones si nécessaire jusqu’à expiration de ce compteur.

2.8.2.5. TVX (Timer Valid Transmission) Ce temporisateur est initialisé à chaque réception de jeton. Il permet de vérifier si l’anneau est toujours

opérationnel. L’expiration de TVX déclenche un processus claim. La valeur de TVX doit être d’au moins

62500 symboles (2,50 ms).

2.8.3. Le partage de la bande passanteChaque station dispose d’une fraction de la bande passante exprimée en pourcentage. Afin de garantir un

minimum équité sur le partage de la bande entre toutes les stations, une classe de trames synchrones est

34

utilisée pour le trafic régulier et une classe de trame asynchrone pour les transferts moins réguliers ou

aléatoires peut être utilisée.

Figure 2.10 Partage de la bande passanteLe temps de circulation du jeton sur l’anneau à été déterminé pendant la phase d’initialisation et : TTRT=100ms, LATE_CT = 0, TRT=TTRT. A : Le jeton arrive sur une station N qui n’a rien à transmettre. TRT=TTRT,

Le jeton est renvoyé, et TRT commence à décrémenter tant que le token n’a pas fait le tour de

l’anneau.

B : Le token revient avant le fin des 100 ms (ou que TRT =0)

THT=TTRT-TRT (ici 40 ms)

TRT=TTRT

C : Transmission des données synchrones pendant 20 ms et déclenchement du THT pour la

transmission des données asynchrones.

D : Au terme de THT (THT=0) arrêt de la transmission asynchrone et envoi du jeton.

E : A la fin de TRT le jeton n’est pas revenu LATE_CT = 1, TRT=TTRT, et déclenchement de THR

(comptage du retard)

F : Le jeton arrive, (THR < 2*TTRT) envoie des données synchrones et comme LATE_CT ≠ 0 pas

de transmission de données asynchrones. TRT=TTRT.

G : Le token revient avant la fin des 100 ms (ou que TRT =0)

THT=TTRT-TRT; TRT=TTRT; LATE_CT=0

H : Émission des données synchrones et asynchrones puis le jeton

I : Le jeton revient avant expiration de TRT etc.

Figure 2.11 Partage de la bande passante

2.9. Les modes de fonctionnement et gestion SMT [1]Toute la difficulté du protocole FDDI réside dans la gestion de l'anneau. Il faut qu'en cas de problème, la

continuité de l'anneau soit préservée, que l'allocation des ressources reste équitable, que la prise du jeton

35

soit renégociée, les erreurs détectées et corrigées, etc.

Le protocole Token Ring utilise une station particulière appelée moniteur, ayant en charge la totalité de la

gestion du réseau. Cependant, à la suite d'un incident, l'anneau FDDI peut être partitionné en plusieurs

sous anneaux. L'approche moniteur centralisé n'est donc pas valable car elle nécessiterait un gestionnaire

par sous anneau. De plus, une station à double attachement peut, le cas échéant, constituer un anneau à

elle seule et elle doit par conséquent être en mesure de s'autogérer.

C'est pourquoi, il a été décidé qu'une entité de gestion : SMT, serait présente dans chacun des noeuds

FDDI (station ou concentrateur). Chaque station surveille l'anneau en permanence afin de détecter des

conditions d'anomalie qui nécessiterait une réinitialisation de l'anneau. Dans un tel cas, mais aussi lors de

l'insertion d'une station, une procédure d'initialisation est démarrée : le processus Claim.

2.9.1. Le processus ClaimDans un anneau de type FDDI contrairement à un protocole IEEE 802.5 aucune station n’est monitrice du

réseau et chacune d’entre elles doit surveiller en permanence le réseau pour qu’en cas d’anomalie une

réinitialisation du réseau ait lieu. Cette phase est appelée Claim processus.

Cette phase permet de négocier la valeur du TTRT et de déterminer la station qui engendrera le premier

jeton. Pour cela, chaque station émet continuellement des trames dites de négociation (Frame Claim),

contenant la valeur du TTRT qu'elle aimerait voir appliquer. Chaque station qui reçoit une telle trame en

compare le contenu avec sa propre valeur de TTRT à proposer : si la valeur lue est inférieure, elle

propage la trame reçue, sinon elle émet une trame Claim contenant son propre TTRT souhaité. En

l'absence de défaut sur l'anneau, l'une des stations voit finalement revenir sa propre trame Claim, qui a

fourni au passage sa valeur de TTRT à toutes les autres stations. C'est ensuite elle qui fait circuler le

premier jeton sur l'anneau.

Plus une station a besoin d’émettre des données urgentes plus elle aura tendance à demander un TTRT

faible.

Principe

Toutes les stations émettent le t_req avec une valeur de TTRT requise,

Une station recevant une trame analyse le TTRT

s’il est supérieur à celui de la station la trame est rejetée

s’il est inférieur à celui de la station, cette station se retire de la négociation et répète la

trame reçue

La première station recevant sa trame d’origine devient celle dont la valeur de TTRT est

retenue et qui générera le premier jeton.

36

Un premier jeton est généré pour prévenir les autres de la valeur du TTRT. Pendant ce

premier tour aucune station n’a le droit d’émettre de données.

Après ce premier tour les stations à la capture du jeton peuvent transmettre des données.

2.9.2. Le processus beaconQuand une station détecte que le processus de négociation initial a échoué ou alors sur simple requête de

la couche SMT, elle met en place un processus Beacon. C'est le cas lors d'une coupure physique de

l'anneau. Le processus Beacon a pour objet de localiser la panne afin d'entamer les actions de

recouvrement qui s'imposent par l'intermédiaire de la couche SMT. Durant ce processus, chaque station

émet en continu des trames de type Beacon; Lorsqu'elle reçoit de telles trames de sa voisine amont, elle

cesse d'émettre ses propres trames et répète celles qu'elle reçoit. Ainsi, la station suivant immédiatement

la liaison défectueuse va remplir l'anneau avec ses propres trames, identifiées par l'adresse source. Cela

permet donc la localisation du défaut et la mise en oeuvre d'une reconfiguration par utilisation de l'anneau

secondaire.

Principe :

Chaque station émet des trames beacon en continu.

Si une station reçoit d’autres trames beacon elle arrête d’émettre les siennes et recopie

celles qui arrivent.

Une station située immédiatement après la liaison défectueuse inondera le réseau de ses

trames.

Après une coupure une station ne recevra jamais ses trames beacon.

Une fois la panne localisée les procédures de recouvrement d’erreur sont entamées.

Figure 2.12 Restructuration du réseau par les couches SMT

2.9.3. L’administration FDDILe but de FDDI est d’assurer la continuité des transferts de données même en cas de panne. Si une

défaillance se produisait, il faut très vite détecter le problème et entamer la phase de reconfiguration. Pour

ce faire, chaque station ou concentrateur possède son entité de gestion propre pour éviter comme dans le

Token Ring que ce soit la station monitrice qui détecte la panne pour remédier au problème (station

monitrice isolée).

Cette unité de gestion SMT à pour rôle la gestion de la configuration du réseau :

Gestion des connexions

37

Initialisation

Détection d’erreur

Reconfiguration

Détection d’adresse dupliquée.

SMT est décomposé en plusieurs entités auxquelles sont associés des automates décrivant leur

fonctionnement.

Établissement et initialisation des connexions physiques :

Lancement du test de chemin

Contrôle du commutateur optique de dérivation (by-pass)

Test de continuité de la connexion

Refus des connexions illégales ou indésirables,

Signaux sur la topologie physique

Boucle locale de configuration avec le MAC voisin

Le contrôle de la configuration de la station

Lancement des entités MAC

La détection des fautes au niveau physique

Surveillance de la continuité des liens

Reconfiguration sur faute de niveau physique

Le support des fonctions de traçage des fautes

Le test de fiabilité des liens

Le contrôle de la qualité des liens

Le support des états de maintenance en ligne

L’indication de disponibilité de connexion.

SMT est composé de 3 entités

ECM (Entity Coordination Management)

PCM (Physical Connection Management)

CEM (Configuration Element Management)

Un aperçu sur la norme ISO9314, portant sur la création du réseau FDDI, a été décrit. On a mentionné les

38

caractéristiques de ce dernier. On a visualisé de façon détaillée les différentes couches de l’architecture,

ainsi que les formats des trames FDDI. On a pu savoir expliquer facilement le fonctionnement global du

réseau par l’intermédiaire des processus Claim et beacon.

39

CHAPITR3.: ETUDE DE LA PERFORMANCE DU RESEAU PAR LA METHODOLOGIE D’ANALYSE TEMPORELLE

3.1. Introduction au système temps réelLes systèmes temps réel sont, en général, constitués de deux parties: le système contrôlé, processus

physique qui évolue avec le temps, appelé aussi procédé, et le système contrôlant appelé aussi partie

commande qui est un système informatique qui interagit avec le premier. Le système contrôlant prend

régulièrement connaissance de l’état du procédé par le biais de capteurs, calcule la prochaine action à

réaliser sur la base des dernières mesures puis applique une consigne au processus commandé par le biais

d’actionneurs.

Les différentes activités d’un système informatique doivent nécessairement s’exécuter dans des temps

limités appelé échéances.

Un tel système est qualifié de temps réel lorsque sa correction ou sa validité ne dépend pas uniquement de

la justesse des résultats obtenus mais aussi des instants de production de ces résultats. De plus, il est dit à

contraintes strictes si le non respect d'une échéance ne peut être toléré (exemple: la commande du moteur

d’un avion) car cela peut engendrer une catastrophe.

L'architecture matérielle d’un système temps réel peut être:

− Monoprocesseur: tous les programmes s'exécutent sur un seul processeur,

− Multiprocesseur: les programmes sont répartis sur plusieurs processeurs partageant une mémoire

commune,

− Répartie: les programmes sont répartis sur plusieurs processeurs, appelés sites, dépourvus de mémoire

commune mais reliés par un médium de communication par lequel ils peuvent communiquer par échange

de messages.

Les systèmes temps réel répartis basés sur les réseaux locaux font partie de cette dernière catégorie.

La partie logicielle comprend :

− d’une part, un système d’exploitation appelé exécutif temps réel chargé de fournir un ensemble de

services que les programmes de l’application peuvent utiliser durant leur exécution. Il doit en particulier :

- intégrer un ordonnanceur qui définit une stratégie pour le partage du processeur entre activités en attente

d’exécution,

- gérer l’accès aux ressources partagées,

- et offrir des mécanismes de synchronisation et de communication entre les activités du système de

contrôle.

− d’autre part, afin de garantir un fonctionnement correct du procédé, des programmes sont implantés par

40

l’utilisateur et traduisent les fonctions que doit réaliser la partie commande pour la prise en compte de

l’état du procédé et sa commande. Ces programmes se présentent sous la forme d’un ensemble d’unités

d’exécution appelées tâches.

D’un point de vue temporel, les paramètres suivants peuvent caractériser une tâche:

− la date de réveil (notée r) correspond à l’instant à partir duquel la tâche peut commencer son exécution,

− La durée d’exécution (notée C) égale à la borne supérieure du temps processeur nécessaire à l’exécution

de la tâche,

− Le délai critique (noté D) est l’intervalle de temps, à partir de la date de réveil, durant lequel la tâche

doit s’exécuter. En dehors de cet intervalle, son exécution devient inutile.

− La période (notée P) est l’intervalle de temps fixe qui sépare les arrivées successives d’une tâche. Ce

paramètre concerne les tâches activées périodiquement, d’où le nom de tâches périodiques.

Les tâches dont la date de réveil n’est pas connue avant la mise en exploitation du système sont dites

tâches apériodiques.

En général, les tâches périodiques assurent le déroulement normal des fonctions de commande du procédé

alors que les tâches apériodiques traitent les alarmes et les états d’exception.

Les tâches peuvent être indépendantes ou peuvent interagir entre elles.

Nous distinguons alors trois types d'interaction:

− La synchronisation locale qui correspond à une simple synchronisation (postage et/ou attente d’un

événement) ou communication de données (par le mécanisme de boîte aux lettres ou par rendez-vous si

l’attente est bloquante) entre tâches d'un même site.

− La synchronisation globale qui correspond à l’échange de messages entre tâches de sites distincts. La

tâche qui émet un message est dite tâche émettrice, celle qui le reçoit est dite tâche réceptrice. La

synchronisation locale ou globale peut se traduire, d’un point de vue comportemental, par des relations de

précédence entre tâches définissant ainsi un ordre dans leur exécution.

− Le partage de ressources qui traduit l'utilisation de ressources critiques par deux ou plusieurs tâches du

même site.

Figure 3.1 Les caractéristiques temporelles d’une tâche périodique

3.2. Contextes temps réel [18]La grande diversité des domaines d’application du qualificatif temps réel impose une terminologie stricte

définissant les contraintes temporelles, plus ou moins fortes, imposées aux systèmes temps réel.

Systèmes temps réel à contraintes strictes (TRCS) : systèmes composés de tâches soumises à des

41

contraintes temporelles strictes. Chaque occurrence de tâche se voit associer une échéance qu’il serait

inadmissible de ne pas respecter. Une faute temporelle pourrait être coûteuse humainement et/ou

financièrement. Les tâches composant de tels systèmes sont dites TRCS.

Systèmes temps réel à contraintes relatives (TRCR) : systèmes composés de tâches contraintes

temporellement par une échéance comme dans le cas des systèmes TRCS.

Cependant, dans ce contexte, la violation d’une contrainte temporelle est tolérable bien qu’elle entraîne

un coût que l’on cherche à minimiser. Les tâches composant de tels systèmes sont dites TRCR.

Systèmes temps réel à contraintes mixtes (TRCM) : qualificatif regroupant la plupart des systèmes

temps réel puisque les systèmes TRCM sont composés de tâches TRCS et de tâches TRCR. La

problématique dans ce contexte est d’éliminer toute possibilité de faute temporelle pour les tâches TRCS

tout en minimisant les fautes temporelles de tâches TRCM.

3.3. Tâches temps réel [18]Les tâches temps réel peuvent être périodiques, sporadiques ou apériodiques. D’autres tâches, appelées

cycliques, sont étudiées en ordonnancement non temps réel. Les systèmes de tâches cycliques forment

une classe de problèmes à part entière, que nous n’étudierons pas en détails dans cette thèse. Le lecteur

intéressé par l’ordonnancement de tâches cycliques peut se référer à pour un survol. La modélisation par

réseaux de Pétri y est souvent utilisée.

3.3.1. Tâches périodiquesUne tâche Ai est dite périodique si elle est activée à intervalles réguliers. Le modèle classiquement utilisé

pour représenter les tâches périodiques, attribué à Liu et Layland, est présenté sur la figure ci dessous. Ce

modèle, bien que ne représentant qu’un sous-ensemble très restreint des systèmes de tâches pouvant être

implémentés dans un noyau temps réel, est très largement utilisé.

Figure 3.2 Modèle initial d'une tâche temps réelChaque tâche Ai y est simplement modélisée par quatre paramètres temporels :

Sa première date d’activation (appelée aussi date de réveil ou offset) ri. Lorsque toutes les tâches sont

initialement réveillées au même instant 1 2 ... nr r r= = = , on dit que les tâches sont simultanées (on peut

42

aussi trouver le terme synchrone dans la littérature) et sans perte de généralité. On pose

1 2 ... 0nr r r= = = = . Dans le cas contraire, on prend

i

i

min{r }A S∈ comme origine des temps, et toutes les dates

de réveil sont décalées afin de conserver le même écart relatif entre chacune d’entre elles. Les tâches Ai

telles que ri>0 sont dites différées.

Une charge processeur Ci, qui est le temps processeur maximal requis par chaque exécution de Ai. Il est

important de noter que ce temps est une borne supérieure du temps d’exécution requis par une tâche.

Cette borne est loin d’être triviale à obtenir.

Une période d’activation Pi : Ai est activée toutes les Pi unités de temps à partir de la date ri. Il est donc

aisé de calculer chaque date d’activation de Ai à travers le temps puisqu’elle est activée aux dates

, ( 1)i k i ir r k P k= + − ∀ ∈ N étant l’ensemble des entiers positifs : on dit que le réveil de la kème occurrence

Αi,k (nommée aussi requête ou instance) de Αi a lieu à la date ri,k.

Un délai critique Di, temps alloué à la tâche pour se terminer après chacune de ses activations.

L’échéance di,k de la kème occurrence de Αi se calcule à l’aide du délai critique. En effet à chaque date

, ,i k i k id r D k= + ∀ ∈ N Ai,k voit son échéance choir et doit être terminée. Si ce n’est pas le cas, il se produit

une faute temporelle.

Une tâche est dénotée ( , , , )i Ai Ai Ai AiA r C D P= , et un système de tâches :

1 1 1 1{( , , , ),..., ( , , , )}n n n nS r C D P r C D P=

Puisque i iC / P est la fraction d’un processeur dont Ai a besoin pour s’exécuter, la fraction processeur

nécessitée par le système de tâches S est donné par

1

is

i

n CUPi

= =∑

, n étant le nombre de tâches de S. US est la charge (ou taux d’utilisation) du système de

tâches S. Si US est plus grand qu'un entier p, alors le système ne peut se contenter de p processeurs. Par

contre, si le nombre de processeurs est p et que US < p, alors les processeurs ne seront pas occupés

pleinement par le système, on dit qu’ils seront périodiquement oisifs.

3.3.1.1. Paramètres temporels des tâches temps réel- La date de réveil ri

- La durée maximale d’exécution sur le processeur du site ou charge maximale Ci

43

- Le délai maximal à na pas dépasser Di

- La période d’activation Pi

Et les paramètres suivants sont déduits des quatre précédents :

- La kème activation , ( 1)i k i ir r k P= + − , correspond au réveil de la kème occurrence Ai,k de Ai

- La kème échéance , ,i k i k id r D= +

- La charge processeur d’une tâche i

ii

CUP

=(3.1)

- La charge d’un système s i

Ai SU U

∈

= ∑(3.2)

La figure ci-dessous reprend les notations de la définition précédente.

Figure 3.3 Chronogramme des activations et échéances d’une tâche périodique

Généralement, le délai critique est choisi plus petit que la période afin d’interdire toute réentrance d’une

tâche. Cela est dû au fait que, bien que théoriquement l’occurrence d’une tâche soit déclenchée par

l’horloge temps réel (HTR), les tâches sont rendues périodiques dans les langages de programmation

temps réel par l’emploi d’une boucle contenant une instruction de mise en sommeil jusqu’à une date

donnée. A chaque itération de cette boucle, la tâche s’endort, puis est réveillée par l’HTR C’est donc

toujours le même code qui est exécuté, pour chaque occurrence d’une tâche. Permettre la réentrance d’une

tâche reviendrait à autoriser plusieurs pointeurs d’instructions sur le même code, ce qui est envisageable,

mais surtout le partage de variables locales à une tâche, ce qui impliquerait la recopie complète des

données internes d’une tâche dans chacune de ses occurrences.

De par la contrainte de non réentrance des tâches périodiques, le respect de la période entraîne un délai

critique maximum qui est la période de la tâche elle-même (on parle alors de tâches à échéance sur

requête).

Les paramètres temporels définissent de façon statique les contraintes temporelles d’un système de

tâches. Lorsque celui-ci est exécuté, des caractérisations dynamiques servent à rendre compte de la

qualité temporelle de l’application mise en oeuvre. Ceux-ci dépendent de la technique d’ordonnancement

mise en oeuvre.

44

3.3.1.2. Caractérisations de l’exécution d’un système de tâches

- Le début Ai,k, noté débuti,k, est la date à laquelle ,i kA dispose pour la première fois du

processeur.

- La terminaison de ,i kA , notée terminaisoni,k, est la date à laquelle , , ,mini k i k i kA ter aison r= − .

Par définition, une faute temporelle a lieu, si et seulement si, le temps de réponse ne dépasse

pas son délai critique.

- La latence ou temps de retard admissible de ,i kA est donnée par

, , ,mini k i k i klatence d ter aison= − .

- La laxité de ,i kA est donnée à l’instant t par sa marge de manœuvre, c'est-à-dire

, ( ) , , ( )i k t i k i k tlaxité d t C= − − est le nombre d’unité de temps de ,i kA restant à traiter au temps t

pour la terminer.

- Le taux de réaction de Ai,k est donnée par ,

,i k

i ki

TRTxRD

=

Figure III.4 Notations caractérisant l’exécution d’une tâche

Certaines tâches peuvent être soumises à des contraintes de régularité, notamment les tâches

d’acquisition. Cela est dû au théorème de Shannon.

Il faut retenir le fait que bien que les tâches soient périodiquement contraintes, elles ne sont pas

forcément régulières, il est donc utile de caractériser la régularité des tâches.

Remarque :

Soit Ai une tâche temps réel, sa gigue temporelle (on parle aussi de jitter) est donnée par :

, 1 ,max{| ( ) |}i k i ki

i

TR TRgigueD

k

+ −=∈ N (3.3)

On parle de gigue nulle lorsque tous les temps de réponse de Ai sont identiques.

45

Figure 3.5 Exemple de gigue temporelle d’une tâche

La figure ci dessus montre trois occurrences successives d’une tâche Ai avec une gigue maximale

i i

i

D CD−

. Si dans un ordonnancement, une gigue nulle est assurée, la période d’une tâche

d’échantillonnage sera 1/ 2N avec N fréquence du signal à échantillonner. Dans le cas contraire, la

période de la tâche d’acquisition devra être réduite afin de prendre en compte la gigue pouvant être

imposée à la tâche : on parle alors de sur échantillonnage.

Les paramètres temporels des tâches sont obtenus à partir du cahier des charges du système.

Généralement ils ne sont pas immuables, et certaines études ont montré qu’il pouvait être intéressant de

faire varier certains d’entre eux afin, par exemple, de diminuer la gigue temporelle de certaines tâches.

Il est à noter que les paramètres temporels des tâches permettent de valider le comportement temporel du

système et non pas son comportement fonctionnel. En effet, chaque instruction est abstraite à sa durée.

Afin de prendre en compte les interactions entre les tâches telles qu’elles peuvent être créées à l’aide des

primitives temps réel. On va définir les contraintes de précédence et d’exclusion entre les tâches.

Lorsque les tâches ne sont définies que par leurs paramètres temporels, on dit qu’elles sont indépendantes.

Lorsque les tâches communiquent, des contraintes de précédence sont induites par les interactions entre

tâches. En effet, il est primordial de prendre en compte le fait qu’une tâche réceptrice soit en attente tant

que la tâche émettrice associée n’a pas produit un message. C’est d’ailleurs la prise en compte de

contraintes de précédence qui justifie souvent l’existence de dates de réveil. Les contraintes de

précédence étant prises en compte par notre modèle, leur existence peut se justifier dans l’exemple

suivant : supposons qu’une tâche doive lire périodiquement des données sur un disque dur, dont chaque

temps d’accès est borné par 12 ms, puis envoyer le résultat à une tâche de traitement de même période. Il

est intéressant de retarder la tâche de traitement de 12 ms par rapport à la tâche de lecture, même si la

contrainte de précédence entre les tâches n’est pas éliminée par cet offset.

De plus, la plupart des applications temps réel nécessitent la prise en compte de ressources critiques.

46

3.3.2. Tâches non périodiques

3.3.2.1. Tâches sporadiquesLes tâches sporadiques sont très utilisées dans les approches asynchrones du temps réel. Ce sont des

tâches dont on ne connaît pas a priori la période, mais dont on connaît l’intervalle minimal séparant deux

requêtes successives. Une tâche sporadique Aspor peut être caractérisée par trois paramètres temporels :

- Cspor le temps processeur nécessaire au traitement de chaque occurrence de Aspor,

- Dspor le délai critique,

- Pspor l’intervalle minimal séparant deux occurrences de Aspor.

La figure ci-dessus montre que la kème occurrence d’une tâche sporadique Αi, est caractérisée

temporellement par sa date d’occurrence ,i kr et son échéance , ,i k i k id r D= + .

La difficulté de validation de systèmes de tâches sporadiques réside dans le fait que les dates r i,k des

requêtes sont inconnues a priori.

Figure 3.6 Chronogramme d’une tâche sporadiqueLes tâches sporadiques à contraintes strictes ne peuvent être garanties sans concession. En effet, puisque

les requêtes sporadiques ne sont pas connues a priori, le seul moyen de garantir que toute occurrence

d’une sporadique sera traitée à temps est de le faire dans le pire des cas.

C’est à dire que le cas validé est celui dans lequel la tâche sporadique est déclenchée le plus souvent

possible. Il ne s’agit pas de demander au concepteur ce qu’est le plus souvent possible, mais de garantir

que quelle que soit la date à laquelle une occurrence de tâche sporadique apparaît, une place dans

l’ordonnancement est prévue pour elle.

Cela peut être fait en représentant la tâche sporadique Aspor de délai critique Dspor par une tâche serveur

périodique de sporadique Αserv choisie telle que :

Son temps de traitement soit assez grand pour pouvoir y placer As, c'est-à-dire : serv sporC C≥ .

Quelle que soit la date d’occurrence de Aspor, elle puisse être traitée dans le temps imparti à Αserv,

c'est-à-dire : serv serv sporP D D+ ≤ . Par exemple, sur la figure ci dessous, une requête de tâche sporadique a

lieu 0α ≥ unités de temps trop tard pour être traitée par la kème occurrence de Αserv, elle n’est donc

47

traitée que par l’instance suivante du serveur.

Figure 3.7 Traitement d’une requête de tâche sporadique dans le serveur périodique associé

Afin de répondre à ces deux contraintes tout en minimisant l’augmentation de la charge du système et en

maintenant l’ordonnançabilité du système, les valeurs limites sont choisies, c’est à dire serv sporC C= , et le

couple (Dserv,Pserv) est choisi tel que serv serv sporP D D+ = . La figure ci après montre les choix possibles pour

le couple (Dserv,Pserv) tout en respectant la condition nécessaire d’ordonnançabilité serv servC D≤ .

Figure 3.8 Valeurs limites des paramètres temporels d’un serveur périodique de tâche sporadique

Dans la littérature, le couple (Dserv, Pserv) choisi est souvent ( / 2, / 2)spor sporD D . Bien que ce choix

maximise la charge processeur par rapport aux autres choix possibles, c’est lui qui est le moins

contraignant dans les conditions suffisantes d’ordonnançabilité que nous donnerons par la suite.

Cependant, dans le cadre de l’ordonnancement exhaustif, d’autres valeurs de couples peuvent être

choisies sans nuire à l’ordonnançabilité du système.

3.3.2.2. Tâches apériodiquesLes tâches apériodiques sont des tâches pour lesquelles le délai minimal entre deux occurrences est

inconnu. On ne peut donc valider a priori un système composé d’apériodiques à contraintes strictes. Les

apériodiques sont de ce fait considérées à contraintes relatives et sont prises en compte dans le cadre de

systèmes TRCM. Elles sont soit prises en compte dans le travail de fond, c’est à dire dans les temps

laissés libres par les tâches à contraintes strictes, soit prises en compte dans des serveurs d’apériodiques.

3.3.3. Contextes d’ordonnancementAfin de définir au mieux les problèmes d’ordonnancement et les solutions proposées dans certains cas

48

particuliers, les contextes d’étude d’ordonnançabilité sont définis de la manière suivante :

=|architecture |réveil, charge, délai critique, période, préemption, précédences, ressources|χ

Un contexte est une suite d’éléments que nous nommons termes. Chacun des termes du contexte et ses

valeurs possibles sont décrits dans le tableau ci dessous.

Terme Valeurs possibles SémantiqueArchitectures p=1 : m=1

p : m=1

p=1 : m

p : m

Un système monoprocesseur centraliséUn système multiprocesseur centralisém systèmes monoprocesseurs répartism systèmes multiprocesseurs répartis

Réveil ri=0ri

Tâches simultanéesCertaines tâches sont différentes

Charge Ci=1Ci

Tâches de durée unitaireTâches de durée quelconque

Délai critique Di = PiDi

Tâches à échéance sur requêteTâches à délais critique quelconque

Période Pi∅

Tâches périodiquesTâches non périodiques

Préemption Prmpt (ou ∅ )Noprmptprmptnoprmpt

Tâches préemptiblesTâches non préemptibles Des tâches ont des portions de code non préemptibles

Précédences ∅précformenormalepréc

Pas de précédencesPrécédences en forme normalePrécédences quelconques

Ressources ∅resresRW

Pas de ressources critiquesRessources en exclusion mutuelleRessources en lecture écriture

Tableau 3.1 Termes d’un contexte d’étude d’ordonnançabilitéAvec cette notation, | 1, 1| 0, , , |i i i i ip m r C D P Pχ = = = = = dénote l’étude des systèmes de tâches

indépendantes préemptibles périodiques simultanées, de charge quelconque, à échéance sur requête, en

environnement monoprocesseur. La valeur de p dénote le nombre de processeurs par site, alors que m

dénote le nombre de sites. Dans le contexte monoprocesseur centralisé (c’est à dire p=1 et m=1), on écrit

de façon plus brève|1| 0, , , )i i i i ir C D P P= = .Les contextes les plus larges que nous pouvons envisager de

décrire à l’aide de cette syntaxe sont donc les systèmes de tâches quelconques partageant des ressources

en lecture et écriture, pouvant avoir des parties non préemptibles, des contraintes de précédence

quelconques, sur une architecture matérielle composée de multiprocesseurs répartis |p,m|

49

ri,Ci,Di,Pi,prmptnoprmpt,prec,resRW|.

Cette notation s’inspire du formalisme | | | |α β γ pour définir les problèmes d’ordonnancement classique, et

utilisé dans un contexte de placement temps réel. α symbolise la configuration matérielle, β la

configuration fonctionnelle, et γ décrit les contraintes et les objectifs à atteindre. Dans un contexte

d’ordonnancement temps réel, γ contient au moins le respect des contraintes temporelles des tâches, on

ne représente donc pas cette contrainte.

Soit la relation d’ordre est moins général que, notée ⊂ , définie sur α par un treillis représenté sur la

figure ci-dessous, et sur les termes de β dans le tableau suivant :

Figure 3.9 Relation d’ordre définie sur la configuration matérielle du contexteRelation d’ordre Explicationri=0 ⊂ ri Les tâches simultanées sont un cas particulier des tâches différéesCi=1 ⊂ Ci Les tâches de charge unitaire sont un cas particulier de durée

quelconqueDi=P ⊂ Di Les tâches à échéance sur requête sont un cas particulier des tâches

temps réelPi ⊂ ∅ Les tâches périodiques peuvent être ramenées à des tâches non

périodiques à un dépliage (découpage des tâches périodiques en

non périodiques sur une durée de simulation) près. Cependant, le

dépliage n’est pas polynomial.prmpt ⊂ noprmpt ⊂ prmptnoprmpt Les tâches préemptibles sont un cas particuliers des tâches

totalement non préemptibles qui sont elles-mêmes un cas

particulier des tâches mixtes.précformenormale ∅ ⊂ préc Les tâches sans contraintes de précédence sont un cas particulier

des tâches dont les contraintes de précédence peuvent être mises

sous forme normale, qui sont un cas particulier des contraintes de

précédence quelconque.∅ ⊂ res ⊂ resRW Les tâches sans ressources sont un cas particulier des tâches

soumises à des contraintes des ressources en exclusion mutuelle,

qui sont un cas particulier des ressources pouvant être accédées en

50

lecture ou en écriture.Tableau 32 Relation d’ordre sur les termes d’un contexte temps réel

La relation d’ordre ⊂ est généralisée à un contexte temps réel sous la forme d’un treillis, avec

1 1 1, 1 1, 2 2 2 2, 1 2, 2| | , ,... | | | | , ,...χ α β β χ α β β= ⊂ = si et seulement si :

1 2α α⊆ , et 1, 1 2, 1 1, 2 2, 2,β β β β⊆ ⊆ ,… Cette relation d’ordre exprime le fait qu’un résultat présenté pour

un contexte donné s’applique à tout contexte 'χ tel que 'χ χ⊆ Il faut cependant garder en mémoire que

si ce résultat concerne la complexité algorithmique, le passage d’un système de tâches périodiques à +son

dépliage en tâches non périodiques n’est pas polynomial.

3.4. Ordonnancement des tâches [3], [19], [20]L’Ordonnanceur doit régler les conflits des tâches concurrentes pour l’accès au processeur en utilisant

une politique d’allocation qui favorise l’accès aux tâches les plus urgentes. Les études menées sur ce sujet

reposent sur la définition d’algorithmes d’ordonnancement qui construisent une séquence de l’ensemble

des tâches à exécuter en veillant à respecter leurs contraintes temporelles et de synchronisation.

3.4.1. Les tâches périodiques indépendantesLes tâches qui ne présentent aucun type d’interaction parmi ceux décrits précédemment sont dites tâches

indépendantes. Elles sont ordonnancées à l’aide d’algorithmes dirigés par la priorité, présentés ici.

3.4.1.1. Les algorithmes d’ordonnancement à priorité fixePour de tels algorithmes, on affecte une priorité à chaque tâche du système que celle-ci gardera pendant

toute la vie de l’application. Les algorithmes à priorité fixe les plus répandus sont les suivants:

− L’algorithme Rate Monotonic (RM): la plus grande priorité est associée à la tâche de plus petite

période.

− L’algorithme Deadline Monotonic (DM): associe la plus forte priorité à la tâche de plus petit délai

critique.

3.4.1.2. Les algorithmes d’ordonnancement à priorité variableDans ce type d’algorithmes, chaque tâche verra évoluer sa priorité au cours de la vie de l’application.

L’algorithme Earliest Deadline (ED) qui ordonne les tâches selon les échéances croissantes fait partie de

cette catégorie.

3.4.2. Les tâches apériodiques indépendantesLa prise en compte d’un événement aléatoire se fait grâce à une tâche apériodique. Une manière

d’ordonnancer ce type de tâches est de les servir à l’aide d’une tâche périodique spéciale appelée serveur.

51

Au niveau de l’analyse de l’ordonnançabilité, ce serveur est considéré comme une tâche périodique.

Il existe principalement deux types de serveurs qui diffèrent dans la manière de prendre en compte les

tâches apériodiques.

3.4.2.1. Le serveur à scrutationSi aucune requête non périodique n’a été mémorisée avant la date d’activation du serveur, celui-ci aura un

temps d’exécution nul pendant la période courante. Si, par contre, une requête a été mémorisée, le serveur

utilisera son temps d’exécution à sa prochaine activation pour exécuter le traitement associé. Si le

traitement n’est pas terminé sur une période, il sera poursuivi pendant la (les) période(s) suivante(s). Le

temps de réponse (temps écoulé entre la date de réveil et la date de fin d’exécution) des tâches

apériodiques peut être important surtout si elles surviennent juste après la fin d’exécution du serveur.

3.4.2.2. Le serveur ajournablePour remédier à l’incompatibilité des rythmes d’arrivée, ce serveur maintient son temps d’exécution

même si aucune requête non périodique n’est survenue. Dans le cas où une requête survient, le serveur

exécute le traitement associé dans la mesure où son temps n’est pas épuisé ; il n’attend pas la prochaine

activation pour la servir.

3.4.3. Les tâches dépendantes

3.4.3.1. Prise en compte des relations de précédenceL’objectif des algorithmes de prise en compte des relations de précédence est de transformer la

configuration de tâches avec relations de précédence en une configuration de tâches indépendantes, qui

peut alors être ordonnancée à l’aide des algorithmes décrits précédemment. Si la tâche A précède la tâche

B avec les caractéristiques temporelles suivantes: ( , , , )A A A AA r C D P= et ( , , , )B B B BB r C D P= alors les

transformations générales à effectuer sur les paramètres temporels afin de rendre A et B indépendantes

sont les suivantes:

Règles de précédence

A précède B =>A Br r≤

Si A est périodique, B l’est obligatoirement et A BP P=

( ) ( )priorité A priorité B=

3.4.3.2. Prise en compte du partage de ressourcesLe partage de ressources par des tâches locales peut engendrer le problème de l’inversion de priorité.

52

L’inversion de priorités apparaît lorsqu’une tâche prioritaire A est retardée par une tâche moins prioritaire

B parce que A demande une ressource déjà détenue par une tâche C moins prioritaire (que A et B). Les

solutions au problème de l’inversion de priorités existent sous forme de protocoles d’allocation de

ressources intégrés aux algorithmes d’ordonnancement. Ces protocoles adoptent des stratégies pour

réduire le temps de blocage d’une tâche en attente d’une ressource détenue par une tâche moins

prioritaire.

3.4.3.2.1. Le protocole à priorité héritée (PPH)Ce protocole permet à la tâche en section critique d’hériter de la plus haute priorité parmi les tâches

bloquées. L’inconvénient de ce protocole est qu’il n’évite pas l’inter blocage.

3.4.3.2.2. Le protocole à priorité plafond (PPP)Ce protocole a été proposé pour limiter la durée maximale de blocage à la durée d’une section critique et

pour prévenir l’inter blocage. Pour éviter les blocages, une nouvelle notion est définie: la priorité plafond

d'une ressource, qui est le maximum des priorités des tâches pouvant accéder à la ressource. Ainsi, une

tâche ne peut entrer en section critique que si sa priorité est strictement supérieure à la priorité plafond

des ressources alors utilisées.

3.4.3.2.3. Le protocole d’allocation de la pile (PAP)Ce protocole a été proposé par Baker. Il améliore le protocole à priorité plafond en permettant d’avoir

plusieurs exemplaires de la même ressource, d’utiliser un ordonnancement dynamique tel que ED et de

réduire le nombre maximal de changements de contexte. Ici, la priorité plafond d’une ressource est

calculée par rapport au niveau de préemption des tâches qui utilisent cette ressource. Le niveau de

préemption d’une tâche correspond à une seconde priorité choisie de manière quelconque mais qui doit

être obligatoirement fixe. Ainsi, une tâche Tj ne peut préempter une tâche Ti que si le niveau de

préemption de Tj est strictement supérieur à celui de Ti.

3.5. Les réseaux de communication temps réel [3]On qualifie de communication temps réel toute communication soumise à des contraintes de temps. Les

réseaux qui supportent ce type de communication sont appelés réseaux temps réel. Ils sont dits à accès

multiple (World FIP, CAN, CSMA/DCR, FDDI, etc.) car les sites accèdent en concurrence au médium de

communication et c’est la technique implantée sur chacun d’eux souvent appelée protocole de d’accès (ou

protocole de communication) qui règle les conflit d’accès.

53

3.5.1. ArchitectureDans les réseaux locaux temps réel, l’analyse de l’architecture de communication est souvent limitée à

trois couches (voir figure 2). La couche physique gère les connexions physiques pour la transmission de

bits à travers le médium de communication. La sous-couche LLC fournit les fonctions de liaison de

données, de gestion des erreurs et de contrôle de flux.

Figure 3.10 Architecture d’un réseau de communication temps réel

La sous-couche MAC gère l’accès au médium à l’aide d’un protocole de communication. La couche

application fournit les services nécessaires à la gestion des tâches et du contrôle.

3.5.2. Les messages temps réelLes messages venant des applications et transmis au service MAC peuvent être de deux types:

− Les messages synchrones (ou périodiques) caractérisés par un intervalle d’arrivée constant appelé

période. Ils sont souvent utilisés pour l’acquisition de données délivrées par un capteur ou bien pour la

communication entre tâches périodiques,

− Les messages asynchrones (ou apériodiques) souvent utilisés pour véhiculer une information de type

alarme ou une communication entre tâches apériodiques. Contrairement aux messages synchrones, les

messages asynchrones arrivent à des instants non fixés.

3.5.3. Ordonnancement des messages temps réelLes protocoles du niveau MAC ont pour objectif de résoudre les conflits d’accès au médium entre les

sites. Beaucoup de recherches sont faites en vue de l’adaptation de la couche MAC pour la prise en

compte des contraintes de temps des messages. L’accès au médium peut être réalisé de différentes

manières, chacune correspondant à une classe de protocoles de communication. L’accès non contrôlé est

une technique basée sur un principe de compétition puisqu’il s’agit, pour chaque site, d’émettre lorsqu’il

le souhaite pourvu que le bus soit libre. L’accès à contrôle centralisé suppose l’existence d’un site de

contrôle qui distribue un droit de parole aux sites. C’est le cas par exemple de World FIP où un site de

contrôle envoie à chaque site un message l’autorisant à utiliser le médium.

La technique d’accès à contrôle distribué suppose la coopération des sites en vue de déterminer celui qui a

le droit d’utiliser le médium. La technique du jeton circulant est un exemple de mécanisme de coopération

explicite des sites (cas de FDDI) et la technique du partage du temps global en intervalles de temps

alloués aux différents sites est un exemple de coopération implicite (cas de TDMA).

Chacune de ces techniques est illustrée par un exemple de protocole de communication décrit en détails

ci-après.

54

Figure 3.12 Les techniques d’accès

3.5.4. Protocoles basés sur la compétition

3.5.4.1. Le protocole CANCAN est un bus à diffusion. Les sites ne possèdent pas d’adresses et accèdent au bus en utilisant la

technique CSMA/CA (Carrier Sense Multiple Access /Collision Avoidance). Chaque site comporte un

contrôleur CAN (type Intel 82527 ou Philips 82C200) qui assure l'interface avec le bus. Une trame

contient au plus 8 octets d'information utile et des champs de contrôle dont notamment un identificateur

de 11 bits. L'identificateur est utilisé d'une part pour filtrer les trames à la réception et d'autre part pour

contrôler l'accès au bus en assignant une priorité à toute trame. En effet, si un site parmi un ensemble de

sites émetteurs émet un bit 0 alors tous les sites verront 0 (dit bit dominant) sur le bus. Inversement, les

sites verront 1 uniquement lorsque tous les sites émetteurs transmettront un bit 1 (dit bit récessif).

Le bus se comportant comme un ET logique, seule la trame de plus grande priorité (ayant le plus petit

identificateur) sera envoyée car les sites qui émettent des bits récessifs se retirent de la compétition

lorsqu'ils détectent un bit dominant sur le bus.

3.5.4.2. Le protocole CSMA/DCRLe protocole CSMA/DCR (Carrier Sense Multiple Access/ Deterministic Collision Resolution) reprend le

principe de base de la méthode CSMA/CD normalisée et s’utilise sur un réseau composé de sites

connectés sur un bus.

Lorsqu’un site émet une trame, il écoute le support en même temps qu’il émet. S’il ne détecte pas de

collision durant la transmission, il conclut que la trame est émise avec succès, sinon il attend un temps

55

aléatoire avant de tenter une autre émission. Ce protocole est dit déterministe car il résout le problème de

collisions en autorisant tous les sites à émettre dans un ordre défini grâce à un découpage dichotomique

basé sur les adresses des sites. Ainsi pendant toute la phase de résolution de conflit, appelée époque, tous

les sites vont pouvoir émettre dans un ordre fixé et avec un délai maximum connu suivant la position de

chacun.

Si les n sites du réseau sont émetteurs, l’époque est égale à ( 1)p cnC n T+ − avec Cp étant la durée de

transmission d'un paquet et Tc la tranche canal. Si seuls x sites (x<n) sont émetteurs alors l’époque se

réduit à l’expression suivante selon : min{ 1, [ ( )]}np cxxC n x xLog T+ − +

3.5.5. Protocoles à contrôle centralisé: exemple de World FIPWorld FIP (Factory Instrumentation Protocol) est un réseau de terrain qui assure le transfert

d’informations entre les équipements (capteurs, actionneurs, régulateurs, unités de commande, etc.) reliés

à un bus. Il existe deux types de service de transmission: la transmission de variables (service MPS:

services périodiques/apériodiques industriels) et la transmission de messages (service MMS: service de

messagerie). Les variables de nature périodique ou apériodique représentent les données échangées pour

le contrôle d’un procédé. Les messages permettent de gérer la configuration du système de contrôle et

sont de nature plutôt apériodique.

L’ordonnancement des échanges de variables et de messages est défini et mis en oeuvre dans un

contrôleur central appelé arbitre de bus. Il consiste à construire, hors ligne, une table de scrutation qui

sera mise à jour, en ligne, par l’arbitre de bus pour gérer le trafic périodique et apériodique.

3.5.6. Protocoles à contrôle distribué

3.5.6.1. Le protocole FDDIFDDI (Fiber Distributed Data Interface) est un réseau à contrôle d'accès par jeton proche de la norme «

anneau à jeton 802.5 ». Il est basé sur la considération de deux types de trafic: le trafic synchrone soumis

à des contraintes temporelles et le trafic asynchrone qui désigne un trafic non contraint temporellement.

Le principe du protocole est d’allouer à chaque site une durée prédéfinie qui représente le temps maximal

pendant lequel il peut transmettre du trafic synchrone chaque fois qu’il reçoit le jeton.

Le temps maximal que peut mettre le jeton pour faire un tour de l'anneau est un paramètre du réseau

appelé TTRT (Target Token Rotation Time) fixé au démarrage du réseau. A chaque fois qu'un site reçoit

le jeton, il peut émettre pendant un temps i iH TTRTα= (0< αι <100%) des trames synchrones. Les

trames asynchrones ne peuvent être envoyées que lorsque le site reçoit le jeton en avance. Le protocole,

56

tel qu’il est décrit, maintient un temps entre deux visites consécutives d'un site par le jeton inférieur à

2*TTRT si le trafic asynchrone est prévu et est inférieur à TTRT si le mode est uniquement synchrone.

3.5.6.2. Le protocole TDMALe réseau TDMA (Time Division Multiple Access) est un réseau en structure d’anneau qui possède un

générateur de trames. Les trames sont allouées aux différents sites de manière cyclique. Un site ne peut

émettre que dans la trame qui lui est allouée. Lorsque la trame a fait un tour, elle est purgée par le

générateur. Il existe trois politiques différentes d’allocation:

− une trame par site et par cycle,

− plusieurs trames contiguës par site et par cycle,

− plusieurs trames non contiguës par site et par cycle.

Une implémentation de ce protocole est le protocole TTP défini dans le cadre du système d’exploitation

temps réel MARS et qui utilise la deuxième politique d’allocation.

3.6. Méthodes et Outils d’analyse temporelle d’applications temps réel distribuées [3]

3.6.1. . Méthodologie de validationLa méthodologie présentée est principalement constituée :

− Modélisation de l’application à l’aide d’attributs temporels tâches et les messages. Un modèle temporel,

pour les messages, des tâches est présenté. Le délai de transfert étant l’un message, il sera calculé pour

chaque protocole de communication.

− Prise en compte de la précédence : il s’agit de dériver précédence par modification des attributs

temporels des en vue d’obtenir des entités (messages et tâches) indépendantes.

− Ordonnancement des tâches et des messages : les tâches caractéristiques temporelles sont obtenues à

l’étape respectivement sur chaque site et sur le réseau. Un diagramme pour chaque site et pour le réseau et

montre la séquence obtenue dans la situation dite du pire cas. Il reste alors chaque tâche et chaque

message respectent bien ses échéances validité de l’application et d’analyser ses performances mesurées.

Une fois que les hypothèses générales de travail seront citées ci-dessus seront détaillées.

3.6.1.1. Le modèle général

3.6.1.1.1. Modèle structurelNous émettons d'abord quelques hypothèses générales qui supposent:

− l'existence d'une horloge globale, dans le système, qui sert à définir les paramètres temporels des tâches

et des messages par rapport à un même référentiel temporel,

57

− l’existence d'un réseau fiable c'est-à-dire que les messages sont transmis, sans erreurs, au bout d’un

temps fini,

− que seuls les protocoles de communication à délai d’accès borné sont utilisés car ils fournissent un délai

de transmission connu et borné pour les messages,

− que les tâches sont placées sur les différents sites de manière statique et aucune migration de tâche n’est

envisagée,

− que chaque site dispose d’un exécutif temps réel, en plus des tâches application, en particulier d’un

ordonnanceur local de tâches et intègre les fonctions de gestion du réseau,

− que le nombre de sites est connu.

3.6.1.1.2. Le modèle temporel de tâchesNous rappelons que le modèle de tâches que nous adoptons est un modèle classique qui suppose que toute

tâche Ti est caractérisé par quatre attributs temporels :

− ri: la date de première activation,

− Ci: la durée maximale d'exécution sur le processeur du site,

− Di: un délai maximal à ne pas dépasser et

− Pi: la période qui est l'intervalle de temps maximal séparant deux arrivées successives de Ti.

Nos hypothèses concernant les tâches sont les suivantes:

− seules les tâches périodiques sont considérées. Ceci n'est pas restrictif car les tâches apériodiques

peuvent être vues comme des serveurs périodiques traitant des événements apériodiques,

− deux tâches liées par une relation de précédence locale ou globale ont la même période,

− chaque tâche émet des messages à la fin de son exécution et n'en reçoit qu'en début d'exécution. Ce type

de tâches peut être obtenu facilement à partir de tâches ordinaires par un simple découpage,

− Les tâches émettrice et réceptrice de messages doivent inclure dans leurs durées d'exécution

respectivement le temps de fragmentation et le temps de réassemblage des paquets au niveau de la couche

application, si l'on ne veut pas créer de sous tâches chargées de ces traitements.

Les algorithmes d’ordonnancement utilisés au niveau des sites sont du type RM, DM ou ED et leur sont

associés des protocoles de ressources de type PPH, PCP ou PAP afin de réduire le temps de blocage sur

les ressources.

Dans toute la suite, nous parlerons de messages pour désigner les entités d’information échangées par les

tâches application. Ces messages seront décomposés en un ensemble d’entités plus petites appelées

trames ou paquets correspondant aux unités d’information manipulées par la couche MAC.

58

3.6.1.1.3. Le modèle temporel de messagesPuisque toutes les tâches de l’application sont de nature périodique, les messages échangés sont supposés

de nature synchrone. Un message synchrone m est caractérisé par (voir figure 3.13) :

Figure 3.13 Le délai de transmission d'un message

− rm: la date d'insertion de m dans la file de transmission,

− Cm: le temps de propagation sur le réseau, qui est proportionnel à la taille du message et qui correspond

au nombre d'unités de temps nécessaires à la transmission du message à travers le médium de

communication,

− Dm: le délai de transmission qui sépare le moment où le message est prêt à être émis de l'instant de sa

réception par le site destinataire. Il correspond au temps de propagation additionné au temps d'attente

dans la file de transmission c'est-à-dire au délai de communication entre la tâche émettrice qui insère un

message dans la file de transmission et la tâche réceptrice capable de consommer le message.

− La période Pm puisque m est généré périodiquement par la tâche émettrice.

Le nombre de messages émis par une tâche ainsi que les destinations des messages sont supposées

connus. Chaque message possède une taille fixe et un délai critique confondu avec sa période. On associe

à chaque message un tampon à une case pour son émission et un autre pour sa réception.

3.6.2. Modélisation de l’application

Considérons une tâche émettrice E sur un site N caractérisée par ( , , , )e e e er C D P

A chaque cycle d'exécution, E peut envoyer un message m à une tâche R d'un site M.

De manière similaire, R est caractérisée par ( , , , )r r r rr C D P . E et R étant liées par une relation de

précédence globale, Pr est égale à Pe par hypothèse.

Le message m est caractérisé par ( , , , )m m m mr C D P avec Pm la période égale à Pe car m est émis

périodiquement par E. Nous devons avoir nécessairement les relations suivantes : 0 m m mC D P≤ ≤ ≤ .

Le but est de calculer les caractéristiques temporelles des messages en supposant que celles des tâches

sont connues au départ c’est-à-dire définies par l’utilisateur ou déterminées automatiquement à l’aide

d’un outil d’évaluation des paramètres.

Comme la période Pm est connue puisqu’elle est égale à celle de la tâche émettrice, il reste à déterminer

les paramètres Cm, Dm et rm. Cm et Dm sont deux paramètres qui dépendent étroitement du réseau utilisé

59

et de la taille du message.

Comme la période Pm est connue puisqu’elle est égale à celle de la tâche émettrice, il reste à déterminer

les paramètres Cm, Dm et rm. Cm et Dm sont deux paramètres qui dépendent étroitement du réseau utilisé

et de la taille du message.

3.6.2.1. Calcul du temps de propagation d’un message : Cm

3.6.2.1.1. Réseau World FIPDans le cas de World FIP, vu le type d’applications distribuées auxquelles nous nous intéressons, seul le

trafic périodique est considéré. La transmission de toute variable périodique (selon la terminologie de

World FIP) se fait en 2 étapes: la diffusion d’une requête par l’arbitre de bus ; le producteur de la variable

spécifiée dans la requête répondra en diffusant la variable proprement dite. Le temps de transmission Cm

de m est égal au temps d’émission de la requête ajouté au temps d’émission de la variable, plus deux fois

le temps de retournement tr. Le temps de retournement est le temps qui sépare la fin de réception d’une

trame du début de l’émission de la trame suivante. Si De est le débit du réseau:

( )8 106= 2m rnC tDe+ +

Où (n ≤ 128) (3.4)

3.6.2.1.2. Réseau CANUn message CAN ne peut pas transporter plus que 8 octets de données. Il contient 47 bits de contrôle, 8

octets d’information utile et

34 85

n+ bits de bourrage.

60

Par conséquent si De est le débit du réseau, le temps de propagation est égal à :

8 348 475

me

nnC

D

+ + + = Où (n≤8) (3.5)

3.6.2.1.3. Autres RéseauxPour les réseaux FDDI, CSMA/DCR et TDMA de débit De, un message émis par une tâche de

l’application peut avoir une taille qui excède le nombre maximal d’octets pouvant être transporté par une

trame.

Un découpage en paquets est alors inévitable, il sera fait au niveau de la couche application avec insertion

des paquets dans la file de transmission dans l’ordre FIFO. Si un message m est constitué de p paquets, la

taille d’un paquet variant d’un réseau à un autre, la transmission de m nécessite p fois Cpi où Cpi

correspond à la durée de transmission d’un paquet i:

1p pi

pC C

i=

= ∑(3.6)

Si le réseau est CSMA/DCR : 8 144

pie

nCD+=

Où (n≤1518) (3.7)

Si le réseau est FDDI: 8 168

pie

nCD+=

Où (n≤4490) (3.8)

Si le réseau est TDMA: 8 28

pie

nCD+=

Où (n≤8) (3.9)

3.6.2.2 Calcul du délai de transmission d’un message : Dm

Comme cela est expliqué dans, Dm doit être au moins égal au temps d'attente dans la file de transmission

rajouté au temps de propagation du message via le médium de communication. Calculer le délai de

transmission Dm d’un message m revient à évaluer le temps d’attente de m dans la file de transmission,

dans la situation la plus défavorable, car le temps de propagation Cm est facile à déterminer connaissant

la taille de m. Il s’agit donc de construire la file de transmission du site émetteur afin de déduire le

nombre s de paquets qui peuvent précéder le message m et par conséquent retarder son envoi. Le principe

est de considérer tous les messages émis par le site émetteur du message m car ils sont tous susceptibles

de précéder m dans la file de transmission. Le nombre de fois qu’un message m’ peut précéder le message

61

m est donné à l’aide du rapport de leurs périodes c’est-à-dire '

m

m

PP

. La file est obtenue à partir des

messages en remplaçant chacun d’eux par les paquets qui le constituent.

3.6.2.2. Cas pour le réseau FDDILe délai de transmission varie selon que les (s+p) paquets de la file de transmission soient émis dans la

bande synchrone du site émetteur au premier passage du jeton ou non.

En effet, si

1pi

s pC TTRT

iα

+≤

=∑

(αTTRT est la bande passante synchrone qui désigne la portion de TTRT dont dispose un site pour émettre

des messages synchrones) alors le délai maximal de transmission est :

max max(1 ). . ( 1). ( 1)m p pD TTRT TTRT n C TTRT n Cα α= − + + − = + − (3.10),

Avec Cpmax le temps maximal de transmission d'un paquet et n le nombre total de sites. Cette formule

exprime le fait que le délai de transmission correspond au temps d'attente du jeton, plus le temps de

transmission durant la bande passante allouée ainsi que le temps nécessaire pour atteindre la destination la

plus éloignée. Cette destination est celle qui nécessite le parcours de (n-1) sites à partir de la source.

Par ailleurs, si .piC TTRTα> , le délai de transmission est :

max. ( 1)m pD k TTRT n C= + − , (3.11)

Avec : 1

.

s p

pii

Ck

TTRTα

+

==∑

(312)

3.6.2.3. Calcul des dates d’insertion des messagesSelon les hypothèses relatives aux tâches, les messages sont générés en fin d’exécution des tâches

émettrices. Le problème est de trouver cet instant puisqu’il correspond à rm. La fin d’exécution de la

tâche émettrice E est e e e mr C B r+ + = , eB est un facteur qui comptabilise tous les retards dus à

l'interaction de E avec son contexte local. Il inclut deux types de retard:

− eH dû à la préemption de E par des tâches plus prioritaires,

− eR dû à l’attente de ressources critiques locales détenues par d'autres tâches moins prioritaires. eR est

un temps de blocage généré par le phénomène d’inversion de priorités et minimisé par les protocoles

62

d’allocation de ressources.

m e e e e e e er r C B r C H R= + + = + + + . (3.13)

Le facteur de blocage dépend du type d’algorithme d’ordonnancement utilisé car la priorité d’une tâche

varie avec le type d’algorithme. De plus, en s’exprimant en fonction du temps eR , il dépend du protocole

d’allocation de ressources utilisé puisque le calcul de eR varie selon le type de protocole utilisé. Le

facteur de blocage dans le cas d’un ordonnancement local à priorité fixe.

Nous désirons calculer eB dans le cas d’un ordonnanceur local à priorité fixe tel que

RM ou DM. Comme e e eB H R= + , nous commençons par le calcul du terme eH .

Calcul de eH

Dans RM, les tâches les plus prioritaires que E sont celles de périodes plus petites c’est-à-dire toutes les

tâches xT tel que x eP P< et toutes les tâches yT de même période que E mais de plus grande priorité

affectée.

Pour tout xT : x eP P< et pour tout yT : y eP P= et ( ) ( )ypriorité T priorité E> :

[ ].ee x yx

x y

DH C CP= +∑ ∑ (3.14)

Dans DM, les tâches plus prioritaires que E sont celles de délais critiques plus petits:

[ ].ee xx

x

DH CP= ∑ ∀ :x x eT D D< (3.15)

Calcul de eR

Comme expliqué, dans la partie descriptive des protocoles d’allocation de ressources, eR se calcule

différemment et est minimal dans les protocoles PPP et PAP. La procédure de calcul de eR selon le

protocole d’allocation de ressources utilisé est décrite ci-dessous.

Procédure de calcul de eR dans le cas de PHP

Soit une tâche T:

1. Considérer les tâches moins prioritaires que T

2. Sélectionner celles qui possèdent des ressources communes avec T, soit l ce nombre

3. Considérer toutes les ressources dont a besoin T, soit s ce nombre

4. eR est donnée par la relation suivante :

eR = Max(l,s)*max(durée des sections critiques ) i=1,s (3.16)

63

Procédure de calcul de eR dans le cas de PPP ou PAP

Soit une tâche T:

1. Considérer les tâches moins prioritaires que T

2. Sélectionner celles qui possèdent des ressources communes avec T

3. Considérer uniquement les ressources dont la priorité plafond est ≥ priorité (T), soit s ce nombre

4. eR est donnée par relation suivante :

eR = max(durée des sections critiques ) i=1,s (3.17)

3.7. Prise en compte de la précédence [3], [19]Suite à la constatation suivante : « les tâches réceptrices possèdent des dates d’arrivée qui ne

correspondent pas nécessairement à l’instant de réception des messages attendus », la prise en compte de

la précédence globale c’est-à-dire de la communication consiste à modifier les dates d’arrivée en vue de

réveiller les tâches correspondantes à des instants où l’on est sûr qu’un nouveau message est arrivé à

destination et est prêt à être consommé.

3.7.1. Mise à jour des dates de réveil des tâches réceptricesDans toute application distribuée composée de tâches périodiques, nous avons toujours le triplet suivant:

tâche émettrice message émis tâche réceptrice

( , , , )e e e er C D P ( , , , )m m m mr C D P ( , , , )r r r rr C D P

Si la tâche R attend des messages m et m’ respectivement des tâches E et E’, R doit être réveillée à un

moment où m et m’ sont arrivés à destination. Par conséquent, la nouvelle date d’arrivée de R est égale à :

' '* max{ , , }r r m m m mr r r D r D= + + car chaque message m atteint sa destination dans un délai maximal égal à

Dm. Dans le cas général, * max{ , }r r m mr r r D= + avec *rr la nouvelle valeur de rr .

3.7.2. Mise à jour des dates de réveil des tâches successeursLes tâches réceptrices peuvent précéder d’autres tâches sur le même site, appelés tâches successeurs.

Nous venons de voir que la prise en compte des messages nécessite de retarder les tâches réceptrices en

modifiant leurs dates d’arrivée. Si de plus, elles précèdent d’autres tâches locales, il y a lieu de modifier

les dates d’arrivée de ces tâches pour maintenir les relations de précédence. Le tableau ci-dessous

récapitule les transformations à effectuer sur les paramètres temporels des tâches en vue de prendre en

compte la précédence locale.

64

Algorithme Condition 1 Condition 2 Condition 3RM

* {( , *)}s s rr Max r r=

Affectation statique des

Priorités avec respect des

précédences

s rP P=

DM * {( , *)}s s rr Max r r= ( , *)i sMin D D s rP P=ED * {( , * )}s s r rr Max r r C= + * {( , * )}r r s sd Min d d C= − s rP P=Tableau 3.3 Règles de prise en compte des relations de précédence locale entre toute tâche

, , ,( )r r r r rT r C D P= précédant une tâche , , ,( )s s s s sT r C D P=

On a présenté une méthodologie de modélisation et de validation d’applications temps réel réparties. Ces

applications composées de tâches réparties sur différents sites communiquent par échange de messages à

travers un réseau de communication à délai d’accès borné. La méthodologie a pour objectif de vérifier le

respect des contraintes temporelles des tâches et des messages et d’utiliser les séquences d’exécution pour

faire une analyse de performance. Cette méthodologie comprend trois étapes : la modélisation de

l’application, la prise en compte de la communication et l’ordonnancement des tâches sur les sites et des

messages sur le médium de communication

65

CHAPITR4. : SIMULATION SOUS MATLAB 6p5Cette partie a pour but de simuler la performance du réseau FDDI sous le logiciel scientifique MATLAB

version 6p5.

4.1. Présentation de MATLAB [14]MATrix LABoratory est un puissant outil de calcul mathématique. Il est doté à la fois d’un langage de

programmation haut niveau et d’outils dédiés aux calculs numériques et à la visualisation numérique.

MATLAB intègre dans sa version originale les outils mathématiques classiques : calculs matriciels,

manipulation de fonction, graphisme, traitement du signal, traitement de l’image, CDMA, réseau de

neurones, logique floue, …

Actuellement, toute personne travaillant avec les mathématiques : que ce soient les ingénieurs, les

chercheurs,… utilisent MATLAB comme outil.

Le système MATLAB se divise en deux parties : le noyau MATLAB, et une collection de toolboxes.

Le noyau MATLAB comprend :

- Un environnement de travail offrant plusieurs facilités pour la manipulation des données. Son

interpréteur permet de tester rapidement ses programmes MATLAB.

- Un système graphique MATLAB (interface homme-machine, graphiques, images, animation) ;

- Un langage de programmation MATLAB ;

- Une librairie de fonctions mathématiques MATLAB ;

- Un système d’interfaçage facilitant l’exécution de programmes C ou Fortran ou JAVA sous

MATLAB.

La collection des toolboxes (boîtes à outils) regroupe un ensemble de fonctions à un thème.

4.2. Fonction de MATLAB pour les graphiques [14]axis : permettant de choisir les dimensions des axes

figure : spécification du nom d’une fenêtre graphique

gca : récupération d’un pointeur sur un objet graphique déjà présent

get : obtention des propriétés d’un objet

grid : ajout d’une grille pour une courbe tracée

hold on : pour tracer plusieurs courbes, avec, chacune ses propriétés propres, on l’insère entre les

deux commandes ‘plot’ pour maintenir le premier écran afin que la courbe suivante

n’écrase pas la précédente

linewidth : spécification de la largeur du trait d’un tracé

66

msgbox : crée une boîte de message

plot : pour tracer des courbes

set : pour spécifier les propriétés d’un objet

subplot : commande qui permet de subvenir en une matrice de sous fenêtres une fenêtre graphique

title : titre de la figure

xlabel : dénomination de l’axe des abscisses

ylabel : dénomination de l’axe des ordonnées

4.3. Présentation du logicielComme l’on a précisé auparavant, le logiciel élaboré aura pour objet de calculer les différents critères et

d’analyser le comportement du réseau FDDI lors d’insertion et des transferts et des messages.

Figure 4.1 Fenêtre d’accueilPour continuer, on clique sur le bouton, une nouvelle interface graphique apparaît.

67

Cette fenêtre aura pour fonction de calculer tous les critères mis en jeu lors de la modélisation temporelle des tâches et des messages. A cet effet, on a divisé notre analyse en trois grandes étapes :

Dans la première étape, on a modélisé les tâches issues de chaque site Ni en Ai (Ri, Ci, Di, Pi), représentées dans la fenêtre ci-dessous. Cette fenêtre est composée de : La caractéristique des tâches pour le site choisi (Site N1, ou Site N2, ou Site N3) Le choix du site et de tâche à analyser, L’étape de l’analyse est composé de : données réseaux et résultas de calcul. La première étape consiste donc à calculer : Le temps de propagation sur le réseau Cmi, i varie de 1 à 4 Le délai de transmission Dm La période PmComme le message mi est modélisé par mi (Rmi, Cmi, Dmi, Pmi), la deuxième étape consiste à déterminer la date d’insertion des messages Rm, la date de réveil des tâches réceptrices Rr et la date de réveil des tâches successeurs Rs et les des retards.Ces deux premières étapes sont gérées par la fenêtre ci-dessous.

Figure 4.2 Fenêtre gérant les calculs

68

Si par hasard, une zone d’édition de texte est vide, par exemple le débit, un message d’erreur apparaît :

Figure 4.3 Message d’erreur

En complétant donc toutes les zones d’édition de texte et en choisissant la valeur du TTRT, on obtient le

résultat en cliquant simplement sur le bouton.

4.3.1. La première étape : La modélisationComme on a mentionné au début, le rôle de la première étape est de calculer les temps de propagation

Cmi des messages mi sur le réseau, le délai de transmission Dm et la période Pm. Pour tester son

efficacité, on va faire un exemple de calcul en remplissant les zones d’édition de texte :

Débit = 100 Mbps

Taille du message m1 = 4490 Octets




Et on va choisir la valeur du TTRT égal à 5 ms, et la valeur de s égal à 3.

Figure 4.4 Modélisation : Exemple de calcul Analyse de ces résultats obtenus

Le délai de transmission Dm est largement inférieur au délai maximal D de la Tâche A1 :

Dm = 693.324 µs et D = 10000 µs. On peut dire que la transmission du message m1 par la tâche A1 s’est

déroulée dans la bonne condition.

4.3.2. La deuxième étape : La prise en compte de la précédencePour arriver à cette étape, il suffit de cliquer sur le bouton. On va prendre toutes les données ci-dessus

pour les calculs des retards et de la date d’insertion des messages Rm et les dates de réveil des tâches

réceptrices et successeurs. On a utilisé le protocole PHP et l’algorithme RM dans le calcul de ces

paramètres.

Figure 4.5 Prise en compte de la précédence : Exemple de calculAnalyse de ces résultats obtenus

Les retards égaux à 1100 µs sont : He qui est dû à la préemption de la tâche émettrice A1 par des tâches

plus prioritaires, et Re qui est dû à l’attente des ressources critiques locales détenues par les tâches moins

69

prioritaires que A1. Malgré ces retards, la transmission des messages peut encore aboutir à la

destination sans écrasement des paquets dans la file de transmission : après l’obtention de cette valeur, on

met à jour automatiquement les dates qui suivent : la date d’insertion de message Rm, les dates de réveil

des tâches réceptrices et successeurs.

Dans le cas où une tâche choisie n’a pas de tâche successeur (les tâches successeurs sont des tâches qui

ont été précédées d’autres tâches sur le même site), un message apparaît et affiche qu’il est impossible

d’évaluer la valeur de la mise à jour de la tâche successeur.

Figure 4.6 MessageSi on ne veut plus continuer l’analyse, on clique sur le bouton, une boîte de question dialogue apparaît.

Figure 4.7 Quitter la simulationDans ces deux premières étapes, il y a des notations ou de nomenclature à éclaircir, il suffit donc de

cliquer sur le bouton. Une fenêtre apparaît et donne des aides supplémentaires sur les éventuelles

notations incompréhensibles.

Figure 4.8 La liste des notationsEn cliquant sur le bouton, on obtient toutes les caractéristiques temporelles des tâches dans les sites.

Figure 4.9 Les sites et ses caractéristiques

En cliquant sur le bouton, on peut voir le schéma du site :

Figure 4.10 Le site

4.3.3. La troisième étape : Cette troisième étape consiste à visualiser graphiquement les courbes donnant l’allure du temps de

réponse des messages (c’est le temps qui sépare l’instant de son insertion dans la file de transmission de

la fin de sa transmission sur le réseau).

Figure 4.11 Temps de réponse

On peut aussi visualiser les courbes donnant l’allure de débit en fonction du niveau de priorité juste en

cliquant sur le bouton.

70

Figure 4.12 Courbe donnant l’allure du débit pour un niveau de priorité 4

Figure 4.13 Débit pour les différentes valeurs de niveau de priorités

En cliquant toujours sur ce bouton, on peut déduire l’allure de l’efficacité du réseau FDDI en fonction de

la valeur du TTRT.

Figure 4.14 L’efficacité du réseau FDDI

On remarque qu’à travers ces courbes, le débit de transmission évolue en fonction du niveau de priorité :

plus le niveau de priorité augmente, plus la largeur de bande occupée par soumis s’élargit. Du point de vu

efficacité du réseau, même si l’anneau a une dimension de 50 km de diamètre, l’efficacité est toujours

supérieure à 85%. D’où son la performance du réseau FDDI est démontrée non seulement sur le point de

calcul mais également sur les courbes.

En résumé, cette simulation s’est divisée en deux parties. Premièrement, on a établi un logiciel permettant

d’effectuer les calculs nécessaires dans l’évaluation de la performance du réseau FDDI par la

méthodologie d’analyse temporelle. On peut dire qu’avec les résultats ainsi obtenus, on pourra envisager

une utilisation optimale du réseau. Deuxièmement, on a visualisé les différentes courbes exprimant cette

performance.

71

CONCLUSION

Grâce à ce mémoire, on a pu faire une nouvelle approche sur l’utilisation de la fibre optique dans le

réseau « backbone » FDDI, après avoir donné un aperçu indispensable sur le réseau en général. On a

étudié de façon détaillée le fonctionnement du réseau normalisé par l’ISO9314. On a déduit que le

concept FDDI définit un réseau local ou métropolitain performant, pouvant transporter des informations à

haut débit (100Mbps) avec une administration réseau intégré. On constate également que FDDI serait

aujourd’hui une solution bien adaptée à la demande croissante d’interconnexion de réseaux locaux dans

un contexte de réseau fédérateur. Les constructeurs offrent déjà des solutions d’interconnexion de type

Ethernet et Token Ring au travers FDDI. En somme, FDDI est une technologie de réseau local pouvant

supporter la notion de réseau intégrateur de type réseau métropolitain, grâce à ses caractéristiques

techniques et son architecture (à double anneau), fédératrice de réseaux par l’utilisation de routeurs et des

ponts et sa méthode d’accès de type jeton temporisé sur boucle.

L’architecture FDDI permet de gérer des débits pouvant atteindre 200 Mbps avec un mécanisme de

reconfiguration automatique, à 100 Mbps, en cas de rupture de l’anneau. Le module de reconfiguration

intégré au réseau, STM, fait de FDDI le réseau local standardisé le plus performant.

On a aussi présenté une méthodologie de modélisation et de validation d’applications temps réel réparties.

Ces applications composées de tâches réparties sur différents sites communiquent par échange de

messages à travers un réseau de communication à délai d’accès borné. On a pu démontrer que la

méthodologie a pour objectif de vérifier le respect des contraintes temporelles des tâches et des messages

et d’utiliser les séquences d’exécution pour faire une analyse de performance. Durant la partie simulation

vue au chapitre IV, on a pu constater que dans le réseau FDDI, le temps de réponse d’un message ne

dépasse pas la période, ce qui justifie sa performance. Autrement dit, le nombre d’écrasement de paquets

est presque nul.

72

ANNEXES

ANNEXE 1 : Liaison par fibre optique

Une liaison par fibre optique point à point comprend :

Les fibres optiques elles mêmes, contenues dans un câble qui protège et qui peut comporter un

grand nombre de fibres. Il en existe une grande variété, correspondant à autant de besoins et

d’applications différents. Le raccordement des câbles entres eux et aux interfaces est l’un des principaux

problèmes pratiques de mise en œuvre des liaisons.

L’interface optique d’émission constituée du composant optoélectronique d’émission (diode laser

ou diode électroluminescente) qui effectue la conversion électrique / optique, ainsi que les circuits

permettant son fonctionnement correct et l’adaptation du signal,

L’interface optique de réception constituée d’une photodiode qui effectue la conversion inverse,

de ses circuits de polarisation et d’un préamplificateur compensant l’atténuation de la fibre optique.

Lorsque la longueur de la liaison le nécessite, on y insère un ou plusieurs répéteurs, utilisés pour amplifier

le signal.

73

ANNEXE 2 : Le code 4B/5B

Symbole de Code4B

Code 5B Signification

Données Contrôle

0 0000 11110 Donnée 01 0001 01001 Donnée 12 0010 10100 Donnée 2

3 0011 10101 Donnée 34 0100 01010 Donnée 45 0101 01011 Donnée 56 0110 01110 Donnée 67 0111 01111 Donnée 78 1000 10010 Donnée 89 1001 10011 Donnée 9A 1010 10110 Donnée AB 1011 10111 Donnée BC 1100 11010 Donnée CD 1101 11011 Donnée DE 1110 11100 Donnée EF 1111 11101 Donnée F

H 00100 HaltI 11111 Idle

J 11000 Délimiteur de trameK 10001 Délimiteur de trameL 00101 Délimiteur de trameQ 00000 QuietR 00111 Reset (0 booléen)S 11001 Set (1 booléen)T 01101 Délimiteur de trame

74

ANNEXE 3 : FDDI II, FFOL et TPDDI

Très rapidement après la conception de FDDI s'est fait sentir le besoin d'un réseau local capable de

supporter simultanément voix, son, images numériques et données. Le réseau FDDI s'est avéré ne pas

convenir à ce type d'application, principalement pour un réseau comportant un grand nombre de noeuds.

En effet, la parole transmise de façon numérique a des contraintes de délais et de synchronisation assez

sévère. Même si la classe de service synchrone permet de garantir un débit minimum, elle ne permet pas

de traiter et de restituer un flux de données uniforme et sans variation. Une technique de type jeton peut

assurer une régularité dans l'accès mais le temps de traitement dans chaque noeud du réseau représente un

retard pouvant devenir trop important lorsqu'un très grand nombre de stations est en jeu.

Une nouvelle version de FDDI a donc été proposée, principalement à l'initiative de spécialistes en

télécommunications comme British Telecom et AT&T, elle aussi basée sur une boucle en fibre optique.

FDDI-II est une extension de FDDI qui lui reste compatible en lui ajoutant la possibilité d'acheminer du

trafic isochrone (véhiculé traditionnellement grâce à une technique de commutation de circuits) en plus

des trafics asynchrones et synchrones (généralement véhiculé par commutation de paquets).

La technique utilisée dans FDDI-II pour rendre un service en mode circuit consiste à imposer une

structure de trame toutes les 125 μs. Une connexion en mode circuit repose alors sur un intervalle de

temps donné dans la trame récurrente. Les canaux sont établis par SMT. Un réseau FDDI-II peut

fonctionner selon deux modes :

- en mode de base : seul le service en mode paquet est disponible et on retrouve alors un fonctionnement

strictement identique à celui de FDDI.

- en mode hybride : les services en mode paquet et en mode circuit sont simultanément offerts.

Quand des stations FDDI et FDDI-II coexistent sur un même réseau, seul le mode de base peut être

utilisé.

Normalisation : l'ANSI (comité X3T9.5)

Cette norme FDDI-II a d'ailleurs aussi été proposé à l'IEEE 802.6 comme recommandation possible mais

en y ajoutant des canaux synchrones et un débit total qui atteindrait 155 Mbits. Mais l'IEEE a finalement

préféré le protocole DQDB.

Pour un réseau local de capacité à 100 Mbit/s sur une longueur de plus de 50 km. C'est une double boucle,

avec un contrôle d'accès par jeton.

FDDI-2 est une extension de la norme FDDI en y incluant une trame synchrone. La bande passante est

constituée de la trame asynchrone et de 16 canaux synchrones qui contiennent 96 groupes cycliques, les

«Cyclic Group», de 16 octets chacun.

75

Le débit synchrone est donc de : 16.96.8/125 s = 98 304 Mbit/s.

FFOL (FDDI Follow On Lan)

FDDI et FDDI-II fonctionnent tous deux à 100Mbits/s et il faudrait un réseau fédérateur offrant un débit

encore plus élevé pour interconnecter plusieurs de ces réseaux. C'est pourquoi l'ANSI travaille depuis

1990 sur un projet qui serait à FDDI ce que FDDI est aux réseaux locaux tels que Token Ring et Ethernet

: le projet FFOL. Il devra être capable :

d'interconnecter les réseaux FDDI.

de supporter des canaux FDDI-II et autres canaux large bande.

de servir de réseau local d'attachement de stations, ce pour répondre aux besoins d'interconnexion

de stations de travail à très hautes performances.

Ce réseau hybride devrait être caractérisé par des débits de 150 à 2500 Mbits/s.

TPDDI (Twisted Pair Distributed Data Interface)

Le support physique de base qui avait été définit, il y a maintenant plus de 10 ans, était exclusivement de

la fibre optique. Elle peut être aujourd'hui remplacée par des paires de fils torsadées avec le nom TPDDI.

Les distances sont évidemment plus courtes, d'une trentaine de mètres à une centaine de mètres suivant la

qualité des paires métalliques. On peut décomposer TPDDI en deux sous-classes :

CDDI : (Copper Distributed Data Interface) pour les paires de fils torsadées non blindées (câble

téléphonique)

SDDI : (Shielded Distributed Data Interface) pour les paires blindées. Dans ce cas, les équipements

optiques seraient remplacés par des connecteurs beaucoup moins chers.

76

BIBLIOGRAPHIE

[1] G. Jacquet, Christophe Léger, Réseaux, 2002–2003

[2] E. Brassart, Réseaux Hauts Débits : Fiber Distributed Data Interface, MCF IUT Informatique

d’Amiens

[3] http:// www.cedric.cnam.fr/~bouzefra/articles/saad99.pdf

[4] C. L. Liu, J. W. Layland « Scheduling Algorithms for Multiprogramming in a Hard

Real-Time Environment » Journal of the ACM, Vol. 20, n°1, 1973.

[5] B. Sprunt, L. Sha, J. Lehoczky, « Aperiodic Task Scheduling for Hard Real Time

Systems », Real Time Systems, Vol. 1, 1989

[6] J. P. Babau, « Etude du comportement temporel des applications temps réel à contraintes strictes

basée sur une analyse d’ordonnançabilité », thèse de Doctorat, ENSMA, 1996.

[7] Z. Mammeri, « Réseaux et Temps Réel - Ordonnancement de Messages », Actes de l’Ecole d’Eté

Temps réel, 26 sept. 1997, Poitiers (France).

[8] International Standard Organization, « Road Vehicles - Low Speed Serial Data

Communication- Part2:Low-Speed Controller Area Network (CAN) », ISO 11519-2,1994

[9] Carrier Sense Multiple Access with Collision Detection (CSMA/CD), IEEE std

802.3, 1985

[10] Token Ring Access Method and Physical Layer Specification, IEEE Std 802.5,

1985

[11] H. Kopetz, G. Grünsteidel, « TTP Protocol for Fault-Tolerant Real-Time Systems »,

IEEE Computer, janvier 1994.

77

[12] K. Tindell, A. Burns, J. Wellings, « Analysis of real-time « communications »,. of Real Time

Systems 9, 1995.

[13] N. Homayoun, P. Ramaritham, « Dynamic Priority Scheduling of Periodic and

Aperiodic Tasks in Hard Real-Time Systems », The Journ. of Real Time Systems, 1994.

[14] K. Tindell, H. Hansson, « Real-Time Systems and Fixed Priority Scheduling »,

Report of Uppsala Univ., oct. 1995.

[15] M. Eric, Informatique : Initiation au MATLAB

[16] C. Viho et B.Cousin- Technique de transmission, IFSIC -Université Rennes I, Janvier 1998

[17] B. Cousin- FDDI, IFSIC -Université Rennes I, Mars 1999

[18] E. Grolleau, Ordonnancement temps réel hors-ligne optimal à l’aide de réseaux de Petri en

environnement monoprocesseur et multiprocesseur, Novembre 1999.

[19] http : // formation.in2p3.fr / formation / infoG / WEB-ECOLE-edition-2 / SYSTEME-TR /

ordonnancement_TR.pdf

[20] http://www.lisi.ensma.fr/ftp/pub/documents/reports/2000/2000-CIFAO-David.pdf

[21] D. Présent, Architecture des réseaux Département S.R.C.- U.I.T de Marne de Valée

[22] O. El kharki, Réseaux Informatiques, Université Ibn Zohr, Février 2004

78

http://www.lisi.ensma.fr/ftp/pub/documents/reports/2000/2000-CIFAO-David.pdf

Nom : RAZAFINDRAKOTOHASINA

Prénom : Andriniaina Jonah

Adresse de l’auteur : Lot IPT 255 Antanety Bemasoandro ITAOSY

102 Antananarivo

Madagascar

Tél : (00261) 32.04.793.83

E-mail : [email protected]

Titre de mémoire : ANALYSE DE LE PERFORMANCE DU RESEAU FDDI PAR LA

METHODOLOGIE D’ANALYSE TEMPORELLE

Nombre de pages : 76

Nombre de tableaux : 16

Nombre de figures : 61

Mots clés : FDDI,

TTRT,

NRZI,

Jeton temporisé sur boucle,

Système temps réel

Directeur de mémoire : RATSIHOARANA Constant

Résumé

Ce travail présente l’étude du réseau FDDI et une méthodologie de modélisation et de validation

d’applications temps réel réparties. Ces applications composées de tâches réparties sur différents sites

communiquent par échange de messages à travers un réseau de communication à délai d’accès borné. La

méthodologie a pour objectif de vérifier le respect des contraintes temporelles des tâches et des messages

et d’utiliser les séquences d’exécution pour faire une analyse de performance. Cette méthodologie

comprend deux étapes : la modélisation de l’application, la prise en compte de la communication.

Abstract :

This work presents a study of the network FDDI and validating distributed hard real-time applications.

Composed of tasks distributed on different sites, this kind of application communicates by exchanging

messages via a communication network. The aim is to verify the deadline meeting of tasks and messages

and to use the scheduling sequences to do a performance analysis. This methodology consists of modeling

the application taking into

account the communication aspect and scheduling tasks on their sites and messages on the

communication medium.

MEMOIRE DE FIN D’ETUDE en vue de l’obtention du DIPLOME D ...

Documents

Transcript of MEMOIRE DE FIN D’ETUDE en vue de l’obtention du DIPLOME D ...