MEMOIRE DE FIN D’ETUDE en vue de l’obtention du DIPLOME D ...
Transcript of 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
Taille du message m2 = 8980 Octets
Taille du message m3 = 13470 Octets
Taille du message m4 = 8980 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
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.