modélisation et analyse de mécanismes de communication de

DEA AUTOMATIQUE, INFORMATIQUE INDUSTRIELLE

Année Universitaire 1991 / 92

Modélisation et analyse de mécanismes decommunication de la norme

ISA-SP50

(réseaux locaux temps critique)

Vasques de Carvalho, Francisco

Groupe : OLC Responsable de Stage : G. JUANOLE

Table de MatièresIntroduction .............................................................................................. 4Chapitre I: Communications dans un contexte temps réel ..................... 5

I.1 -Introduction .................................................................................................. 5I.2 -Les Réseaux de terrain................................................................................... 6

I.2.1 -Le concept réseau de terrain .............................................................. 6I.2.2 -Les besoins de communication dans un réseau de terrain.................... 6I.2.3 -Architectures ..................................................................................... 8

I.3 -Un exemple de réseau de terrain : Le réseau FIP............................................ 9I.3.1 -La couche application........................................................................ 9I.3.2 -La couche liaison de données........................................................... 11

Chapitre II: La proposition de norme SP-50......................................... 12II.1 -Introduction ............................................................................................... 12II.2 -Les Services de la couche de liaison de données ......................................... 12

II.2.1 -Service de gestion d'adresses et de ressources associées ................. 13II.2.2 -Service de liaison de données orienté connexion ............................. 13II.2.3 -Service de liaison de données non orienté connexion ...................... 13II.2.4 -Service d'ordonnancement de liaison de données ............................ 13

II.3 -Les protocoles de la couche liaison de données........................................... 14II.3.1 -Gestion d'un segment ..................................................................... 14II.3.2 -Transfert de données ...................................................................... 15

II.4 -Comparaison FIP / SP-50........................................................................... 17II.4.1 -Généralités ..................................................................................... 17II.4.2 -Les services de transfert de données ............................................... 18

Chapitre III: Les Réseaux de Petri Temporisés Stochastiques ............ 22III.1 -Introduction.............................................................................................. 22III.2 -Réseaux de Petri classiques ....................................................................... 22

III.2.1 -Définition formelle ........................................................................ 22III.2.2 -Règle de fonctionnement............................................................... 22

III.3 -Réseaux de Petri Temporisés .................................................................... 23III.4 -Le modèle Réseau de Petri Temporisé Stochastique (RdPTS) ................... 23

III.4.1 -Définition formelle ........................................................................ 23III.4.2 -Règle de fonctionnement............................................................... 24III.4.3 -Graphe d'états probabilisé ............................................................. 24III.4.4 -Construction du graphe d'états probabilisé..................................... 25III.4.5 -Intérêts du graphe d'états probabilisé............................................. 26

III.5 -Exemples d'application.............................................................................. 26III.5.1 -Modèle RPT ................................................................................. 26III.5.1 -Modèle RPTS............................................................................... 28

Chapitre IV: Modélisation et analyse de mécanismes de..........................communication de la norme ISA-SP50 .................................................. 30

IV.1 -Introduction.............................................................................................. 30IV.2 -Modélisation "niveau segment" ................................................................. 30IV.3 -Modélisation "niveau station".................................................................... 31

IV.3.1 -L'aspect durée............................................................................... 31IV.3.2 -Les aspects durée et priorité.......................................................... 34

IV.4 -Modélisation niveau "protocole de communication" .................................. 39Conclusion............................................................................................... 41Bibliographie........................................................................................... 42

Avant-propos

Les travaux présentés dans ce rapport ont été effectués au Laboratoire d'Automatique etd'Analyse des Systèmes (LAAS) du CNRS au sein du groupe Outils et Logiciels pour laCommunication (OLC).

Je tiens à remercier :

Monsieur M. Courvoisier, professeur à l'Université Paul Sabatier et responsable du DEAAutomatique, Informatique Industrielle et Traitement du Signal, de m'avoir permis de suivre cette formation.

Monsieur M. Diaz, directeur de recherche au CNRS et responsable du groupe OLC, de m'avoir acueilli dans son groupe de recherche.

Je tiens également à exprimer ma profonde gratitude à M. Juanole, professeur àl'Université Paul Sabatier et responsable de mon stage, pour son encadrement, son aideet sa constante disponibilité durant mon travail. Je tiens aussi à le remercier pour avoiraccepté que je fasse une thèse dans son groupe.

Je remercie aussi Y. Atamna, chercheur temporaire, qui au long de ce stage, m'a apportéses connaissances sur RdPTS.

Un petit mot pour tous mes collègues du groupe OLC, ainsi que mes camarades deDEA, avec lesquels j'ai passé de très agréables moments.

Ce travail a été également possible grâce à la dispense de service qui m'a été accordée àla Faculdade de Engenharia, Universidade do Porto et a été partiellement financé par laJunta Nacional de Investigação Ciêntifica. J'adresse également à ces organismes degrands remerciements.

3

Résumé

Le travail présenté dans ce mémoire se situe dans le domaine de la spécificationformelle et l'analyse d'architectures de communication des réseaux locaux pour lacommande de processus industriels (Systèmes temps réel).

Les services et protocoles de communication des réseaux locaux pour lessystèmes temps réel doivent principalement satisfaire deux types de contraintes :

-Des contraintes temporelles (ceci résulte de la nature réactive du processusindustriel, c'est à dire, suite à l'occurrence d'un certain événement, le processus doitréagir dans un temps borné).

-Des contraintes en sûreté de fonctionnement (des fonctionnements anormauxpeuvent avoir des conséquences graves, et il est impératif de les détecter et lescontrôler).

Il est donc essentiel avant de passer au stade de l'implantation, d'analyser lecomportement prévu pour les services et protocoles de communication et de vérifier queles contraintes sont satisfaits (d'où la nécessité d'utiliser des modèles formels).

L'architecture de communication, qui servira de support à l'étude effectué dans lecadre du DEA, consistera en la couche de liaison de données du réseau de terrain("Fieldbus") défini par le proposition de norme SP-50 (CEI65C 92/93 : ce propositionde norme intègre en particulier des mécanismes des normes FIP (Factory InformationProtocol) et Profibus).

Le modèle formel, qui sera utilisé, sera le modèle "Réseaux de Petri TemporisésStochastiques" : Ce modèle permet d'exprimer les mécanismes fondamentaux que l'ontrouve dans les architectures de systèmes distribués temps réel (parallélisme,synchronisation par échange de messages, contraintes temporelles); Ce modèle offre despossibilités d'analyses qualitative (séquence d'événements, relation entre deuxévénements exprimé sous forme de logique temporelle,...) et quantitative (temps deréponse, fiabilité,...).

Deux types de résultats sont attendus :

1- Résultats relatifs à l'étude de la couche liaison de données du réseau de terraindéfini par la proposition de norme SP-50 (CEI65C 92/93) : analyse qualitative etquantitative des mécanismes du jeton délégué.

2-Résultats relatifs à l'étude de comparaison avec la proposition FIP (FactoryInformation Protocol) et plus particulièrement, en ce qui concerne les mécanismes de lacouche liaison de données.

4

Introduction

Le projet de DEA ici présenté s'inscrit sur le cadre d'une problématiqueimportante du monde industriel, qui est l'automatisation des systèmes intervenant dans ledomaine de la production.

L'evolution technologique de ces dernières années permet cette automatisation enintégrant dans une même structure des éléments aussi divers que les capteurs, lesactionneurs (électriques, hydrauliques et pneumatiques), le procédé et la commande duprocédé. Cette structure est une structure informatique distribuée, basée d'une part surdes réseaux locaux temps réel, d'autre part sur des capteurs et actionneurs intelligents etenfin sur des algorithmes de commande sophistiqués.

Il est donc absolument essentiel et capital, à la fois sur les plans industriel etéconomique de spécifier et réaliser des systèmes informatiques distribuées (avec enparticulier les réseaux locaux) qui soient en adéquation avec les caractéristiques desprocessus industriels à mettre en oeuvre. La possibilité de la mise en oeuvre "d'usinescommunicantes" dépend, en particulier, de la réussite de ce type d'étude.

Notons que ce type d'étude s'inscrit dans le cadre de la recherche sur les"Architectures de commande temps réel" menées dans le groupe OLC du LAAS. Cetterecherche fait partie de l'axe prioritaire de recherche actuel (prise en compte et analysedes contraintes temporelles dans les systèmes informatiques distribuées).

Notre mémoire comprend quatre chapitres :

-Le premier chapitre présente les principaux aspects concernant la problématiquedes communications dans un contexte temps réel, sourtout dans le domaine des réseauxde terrain ("fieldbus"). Nous présentons aussi un exemple de réseau de terrain : le réseauFIP, et ses caractéristiques les plus importantes.

Le deuxième chapitre présente les caractéristiques essentielles de la propositionde norme SP-50 (CEI65C 92/93) et effectue une comparaison entre des systèmes SP-50et FIP.

-Le troisième chapitre présente le modèle "Réseau de Petri TemporiséStochastique" qui sera utilisé, ainsi que ses principales propriétés.

-Le quatrième chapitre présente enfin la modélisation et l'analyse de types deservice de communication de la couche liaison de données de la proposition de normeSP-50.

5

Chapitre I

Communications dans un contexte temps réel

I.1 -IntroductionLe projet de systèmes de communication de données fiables et efficaces pour

supporter l'automatisation industrielle est un champ d'application très important dans ledomaine des communications entre ordinateurs. Par contre, c'est peut-être un desdomaines les plus difficiles à aborder, vis à vis de la grande variété des besoins et desenvironnements. Ces systèmes doivent être capables de répondre aux besoins defabrication discrète, d'applications de processus continus, de CFAO et de gestionglobale. Chaqu'un de ces domaines a des besoins différents, en termes de type dedonnées à transmettre, de contraintes temporelles, de fiabilité et de différents moyensphysiques sous lesquels l'information sera transmise.

Une installation industrielle typique peut avoir à interconnecter une grandevariété de dispositifs comme, des Contrôleurs Logiques Programmables (CLPs), desrobots, des machines CNC, des ordinateurs de contrôle à plus haut niveau et desconsoles série pour l'initialisation de programmes de fabrication. L'environnement defonctionnement peut être très varié : températures élevées, interférenceélectromagnétique, etc. Finalement, si on considère le contexte de FAO (FabricationAssisté par Ordinateur), il sera nécessaire d'interconnecter ce système avec le système deCAO (Conception Assistée par Ordinateur) de l'entreprise.

Dans les applications pour le contrôle de processus, on a habituellement besoinde transmettre des données périodiquement et avec un grand degré de fiabilité (selon untemps de cycle très faible). D'un autre côté, dans le contexte de l'intégration totale dessystèmes de production, on doit également considérer la gestion de la production qui aen particulier des contraintes temporelles moins sévères, mais peut nécessiter deséchanges d'information de grande taille (fichiers par exemple). La fiabilité de cestransferts de fichiers est un critère important.

Les réseaux industriels sont habituellement divisés en trois niveaux, en fonctiondes contraintes temporelles qu'ils doivent supporter [ULL 91]. Comme le montre lafigure 1.1, les contraintes temporelles sont inversement proportionnelles au niveau de lahiérarchie du système.

L'évaluation des contraintes temporelles consiste à l'analyse du temps maximumd'attente acceptable (tm) entre l'envoi d'une information et la réception de la réponsecorrespondante.

Au niveau usine, un réseau à utiliser pourrait être MAP ("ManufacturingAutomation Protocol"), ou un autre équivalent. Ici le temps "tm" doit être de l'ordre decentaines de ms jusqu'à 1s.

Au niveau atelier un réseau à utiliser pourrait être MiniMAP, ou un autreéquivalent. Ici le temps tm doit être de l'ordre de dizaines de ms jusqu'à 100ms.

Finalement, au niveau machine, le réseau à utiliser, doit être un réseau de terrainou bus de terrain ("fieldbus"), par exemple FIP ou Profibus. Ici le temps tm doit être del'ordre de quelques ms jusqu'à 10ms. Ces contraintes temps réel strictes [PLE 90]caractérisent la différence de ce niveau par rapport aux niveaux supérieurs.

Dans ce travail, nous nous sommes surtout intéressés aux problèmes concernantles transmissions de données dans le niveau inférieur, c'est à dire au niveau machine.

6

Ordinateur de Contrôle Central CFAO Gestion

CLP Console de Contrôle Pont

Machine de Controle Numérique CLP Contrôleur de

Processus

Capteurs (Processus) CLP Actionneurs

(Processus)Contrôleur de

Processus

MAP

MiniMAP

Réseau de

terrain

Aug

men

tati

on d

es

cont

rain

tes

tem

pore

lles

Niveau usine

Niveau atelier

Niveau machine

fig1.1

I.2 -Les Réseaux de terrain

I.2.1 -Le concept réseau de terrain

Les Réseaux de terrain sont une réponse directe à l'augmentation de lacomplexité du câblage dans le niveau inférieur du processus de production. L'idée debase consiste à changer les liaisons point à point par un réseau où toutes les informationssont multiplexées temporellement sur le même support (bus). Ce support fournit un liendirect entre les capteurs, les actionneurs et les équipements de contrôle.

Les avantages importants du réseau de terrain sont :-Faible coût de câblage avec aussi une influence directe sur la simplification de

l'installation et sur la réduction de la complexité de manutention.-Modularité : L'expansion du système est plus facile et rapide. L'addition d'un

nouveau capteur ou groupe de capteurs se fait simplement avec une connexion sur leréseau, et non sur un nouveau "layout", avec de nouvelles interfaces dans le contrôleurcentral.

-Possibilité de diffusion ("broadcasting" et "multicasting") : Si la mêmeinformation physique d'un processus est nécessaire en divers endroits du système(contrôles, opérateurs, alarmes,...), avec un réseau, on peut la rendre accessible, d'unefaçon virtuelle, à toutes les autres utilisateurs. Un réseau de terrain avec capacité de"broadcasting" permet l'aquisition simultanée de tous les capteurs mis en relation (maissitués en des endroits différents). La diffusion d'information pour tous lesconsommateurs sur le réseau peut aussi se faire d'une façon simultanée. Cette doublecapacité est appelée synchronisation.

I.2.2 -Les besoins de communication dans un réseau de terrain

Les capteurs et les actionneurs d'un système automatisé sont contrôlés par lesCLPs qui ont habituellement un travail cyclique consistant à faire l'aquisition de l'état descapteurs, l'évaluation du nouvel état du système et l'actualisation des actionneurs. D'une

7

façon générale, le cycle d'aquisition, de traitement et d'actualisation des actionneurs aune durée fixe.

Quand un système de communication est inséré entre des éléments contrôleurs etcontrôlés, un choix doit être fait entre deux types de communication :

-Communication d'états, c'est à dire le transfert cyclique d'information entreentités communicantes. Si l'information est perdue ou si des erreurs se produisent, unecorrection des données est effectuée au prochain cycle.

-Communication d'événements : l'état d'une variable est seulement reporté auxentités consommatrices de cette variable, lorsque une altération de sa valeur a eu lieu. Cegenre de communication génère un trafic d'intensité extrêmement variable : Parfois leréseau est sans trafic parce que les variables ne changent pas; parfois le réseau est saturéparce que toutes les variables ont changé au même instant. La conséquence non désiréede ce type de communication, est qu'elle ne garantit pas un temps de cycle déterminé,quand des erreurs surviennent.

Les considérations sur le fonctionnement du réseau doivent être posées de lafaçon suivante :a) Types de trafic

-Trafic périodique (synchrone) permettant l'échange de données pour algorithmesd'application (par exemple de régulation), basé sur la communication d'états. Cette partiepeut être divisée en sous groupes de plus petite période ou de plus grande période.

Pourtant, on n'est pas capable de traiter tout le trafic de façon périodique, commepar exemple le traitement d'alarmes ou le déclenchement de procédures d'exception. Cesmessages sont typiquement apériodiques et ne peuvent pas être vérifiés par procédurescycliques. Ce type de trafic est appelé "Trafic apériodique" ou asynchrone.

Trafic cyclique Trafic non cyclique

Cycle élémentaire

Macro cycle

fig 1.2b) Echanges sur le bus

La séquence des échanges sur le bus est imposé par le trafic périodique. Leséchanges de plus grande période imposent ce qu'on appel un Macro-cycle, les échangesde plus petite période étant appelés les Cycles élémentaires. Dans chaque cycleélémentaire doit être réservée une partie pour le trafic apériodique, comme le montre lafigure 1.2. La longueur de la phase apériodique est déterminée par la longueur total ducycle et de sa partie périodique.

8

Dans les prochaines sections, on verra quelques exemples qui montrent desréseaux de terrain avec la plupart de ces propriétés.

Tout d'abord, nous allons faire une analyse simplifiée de quelques solutionsconventionnelles et nous verrons pourquoi elles ne sont pas adaptées a ce concept de"réseau de terrain".

I.2.3 -ArchitecturesLes applications distribuées utilisatrices d'un réseau de terrain ont des besoins

simples en termes de communication : échange de données (valeurs de variables utiliséespar des algorithmes de contrôle) et échange de messages (changement d'états, gestion deressources). En outre, sur un réseau de terrain, les interfaces des capteurs, actionneurs etcontrôleurs sont en général compatibles.

En termes d'architecture, nous n'avons donc pas besoin des sept couches dumodèle OSI de référence de l'ISO, en particulier la couche présentation (parce que lesinterfaces sont généralement compatibles).

Nous pouvons aussi supprimer les couches session et transport , parce qu'ellesn'ont pas de mécanismes supportant le "broadcasting", le "multicasting", lescommunications en cycles périodiques, et surtout parce que les mécanismes propres à lacouche session ont des temps d'accès incompatibles avec les besoins des réseaux deterrain.

Finalement, la couche réseau ne nous intéresse pas pour transmettre l'état descapteurs et des actionneurs à travers des réseaux de plus haute niveau, à cause des tempsd'accès incompatibles avec les réseaux de terrain. De même, la couche réseau n'est pasutilisée dans les réseaux de terrain.

Donc, l'architecture d'un bus de terrain comporte seulement trois couches :application, liaison de données et physique (fig 1.3).

Application

Liaison de donnés

Physique

fig 1.3-La couche applicationTrois types d'éléments de service doivent être habituellement fournis par la

couche application d'un réseau de terrain : un service pour les applications cycliquesavec des primitives de synchronisation; un service de messagerie pour l'actualisation et lalecture des paramètres; un service de gestion du réseau pour la configuration et lecontrôle des ressources de communication.

Dans le cas où le réseau de terrain doit être intégré avec un réseau MiniMAP ouMAP, il serait intéressant que les couches application soient compatibles. Pour cela, onpeut utiliser une implementation réduite de la norme MMS (Manufacturing MessagingService).

-La couche de liaison de données

9

La couche liaison de données doit supporter la communication en temps critique[PLE, 90] entre les entités du réseau. Le terme temps critique est utilisé pour représenterl'existence d'une fenêtre temporelle, dans laquelle une ou plusieurs actions doivent êtreaccomplies, avec un certain degré de fiabilité. L'incapacité d'accomplir les actionsspécifiées pendant la fenêtre temporelle, implique le refus de la requête, refus effectuépar la couche d'application.

Pour la couche liaison de données, habituellement, deux méthodes d'accès sontconsidérés :

a) Le méthode d'accès maître / esclave (centralisé), avec la notion des esclavesproducteurs et / ou consommateurs; Dans cette méthode, la station maître scrutecycliquement toutes les stations. Cette méthode est intéressante lorsque le traitement desdonnées peut être fait seulement dans une station, c'est à dire la station maître. Dans lecas contraire, les stations secondaires n'ont jamais la possibilité de contrôler le réseau;elles peuvent seulement, dans certaines conditions, informer le maître de ce qu'elles ontbesoin de transmettre sur le réseau.

b)Le méthode d'accès avec passage de jeton (décentralisé), et avec multiplesmaîtres sur le réseau.

Les services classiques au niveau de cette couche doivent supporter descommunications orientées connexion et non orientées connexion, des mécanismes dedemande de services de la part des entités communicant vers l'arbitre du réseau, desmécanismes pour le fonctionnement cyclique des séquences de transferts, etc.

-La couche physiqueLa plupart des standards spécifient les caractéristiques suivantes pour la couche

physique : topologie "bus", avec au moins 16 stations interconnectées et par segment;utilisation de paires torsadées blindées or câble coaxial pour le support physique; etutilisation de l'interface électrique RS-485. Le critère suivi est toujours le choix dumeilleur compromis entre le prix et la qualité pour une bonne immunité au bruit.

I.3 -Un exemple de réseau de terrain : Le réseau FIPI.3.1 -La couche applicationI.3.1.1 -Généralités

Les services offerts par la couche application permettent d'accéder aux variablesgrâce à des primitives de service et aussi d'assurer la cohérence des données transmisesgrâce à des statues de validité.

On distingue deux types de service :-Les services MPS, ou services périodiques / apériodiques. Ils sont

spécifiquement adaptés aux besoins temps réel d'une application répartie. Lesinformations échangées sont des variables représentant des données physiques.

-Les services MMS, ou services de messagerie. Les informations échangées sontdes messages principalement utilisés pour répondre aux besoins de gestion deconfiguration et de mode de marche. Ils permettent d'envoyer des messages d'une stationvers une autre.

Nous présentons ici uniquement les services MPS.

I.3.1.2 -Les services MPSLes variables de l'environnement MPS constituent une base de données répartie

entre les divers équipements connectés sur le réseau : On entend par là, que cette coucheoffre un ensemble de services qui permettent l'accès réparti à des données physiques. Les

10

entités application MPS disposent d'une image locale de chaque variable : Chacune deces variables repérée par un nom.

Une seule entité est productrice de la valeur d'une variable, alors qu'une ouplusieurs entités application peuvent en être consommatrices.

L'échange de la valeur d'une variable spécifiée entre un producteur et un ouplusieurs consommateurs peut s'effectuer de façon périodique ou apériodique. Unservice de mise à jour permet de réaliser ces échanges.

Une mise à jour périodique est à l'initiative du réseau (station appelée arbitre dubus) et est définie lors de la configuration. La période de mise à jour de chaque variableest déterminée par les contraintes fixées par l'utilisateur pour les besoins de l'applicationrépartie ou par les contraintes du réseau.

Une mise à jour apériodique de la valeur d'une variable, doit être soumise àl'arbitre de bus par l'équipement souhaitant consommer ou faire consommer cettevariable.

-Les services de basePour permettre tous les échanges nécessaires, l'interface MPS offre à son

utilisateur un ensemble de services de base qui lui permettent d'accéder aux variables dela couche application.

On distingue les services de lecture ou écriture locaux et distants, les services demise à jour et les services d'indication d'émission ou de réception.

-les services locaux sont réservés aux variables configurées en périodique; leurmise à jour est automatique.

-Les services distants sont réservés aux variables configurées en apériodique; leurmise à jour doit être demandée.

-Le service de mise à jour permet de demander à l'arbitre du bus, ledéclenchement de la mise à jour de la valeur d'une variable : elle peut être demandée parune entité productrice ou consommatrice.

-Le service d'indication d'émission signale à un utilisateur consommateur qu'unevariable à été mise à sa disposition sur le réseau.

-Concept de validité de productionLe rafraîchissement est une information relative à la validité d'une variable : il

renseigne les utilisateurs consommateurs d'une variable sur le respect de production decelle-ci pendant une période temporelle de production. Ce statues est transmis avec lavaleur de la variable lors de sa mise à jour. Celui-ci est élaboré au niveau de la coucheapplication du producteur et mis à disposition du réseau; il est destiné aux entitésapplication consommatrices de la variable identifiée.

On distingue plusieurs catégories d'informations de validité de production :-Le rafraîchissement asynchrone indique chez l'entité productrice de la variable

qu'elle a été mise à disposition du réseau depuis un temps inférieur à la période deproduction.

-Le rafraîchissement synchrone indique chez l'entité productrice que l'ordre desynchronisation a été reçu et qu'ensuite, la valeur de la variable associée à cettesynchronisation a été mise à disposition du réseau depuis un temps inférieur à la périodede production.

-Concept de validité de transmissionLa promptitude est une information relative à la validité de transmission d'une

variable : Elle renseigne les utilisateurs consommateurs sur la réception de la variable

11

pendant une période temporelle de consommation. Ce statues est élaboré au niveau de lacouche application du consommateur.

On distingue plusieurs catégories d'informations de validité de transmission :-La promptitude asynchrone indique à tout moment chez l'entité consommatrice

que la valeur d'une variable a été mise à jour par le réseau depuis un temps inférieur à lapériode de consommation.

-La promptitude asynchrone indique à tout moment chez l'entité consommatriceque l'ordre de synchronisation a été reçu et que la variable associée à cette ordre a étémise à jour par le réseau depuis un temps inférieur à la période de consommation.

I.3.2 -La couche liaison de donnéesLa couche liaison de données est organisée autour de l'arbitre de bus qui gère les

échanges (variables, messages) entre les différents entités qui peuvent être desproducteurs et/ou consommateurs. Nous considérons ici uniquement les échanges devariables (aspect essentiel dans un contexte d'application temps réel).

Les services d'échange de variables existent sous deux formes :-échanges cycliques : Ils sont déclenchés de façon périodique par le système de

communication.-échanges non cycliques : L'utilisateur peut faire la demande d'une mise à jour de

la valeur d'une variable.Les variables sont repérées par des identifieurs uniques pour chaque variable. Les

échanges s'effectuent par diffusion : L'identifieur est mis à disposition sur le bus pourtout élément du système. Chaque entité a alors la possibilité de se reconnaître commeétant productrice ou consommatrice de l'identifieur.

C'est l'arbitre qui doit mettre en oeuvre les échanges de variables périodiques etnon périodiques, ainsi que les transactions de messages sur le bus.

On appelle macro-cycle, la scrutation périodique par l'arbitre de bus de l'ensembledes identifieurs de variables cycliques. Une macro-cycle est composée de cyclesélémentaires qui se caractérisent d'une part, par une scrutation cyclique et d'autre part,par une scrutation non cyclique.

Une transaction d'échanges cycliques de variables se décompose en deux phases :1) Emission par l'arbitre sur le bus d'une trame identifieur d'une variable (id_dat). Toutesles entités reçoivent cette trame : L'entité productrice (de la variable) se reconnaît, ainsique les entités consommatrices concernées.2) Emission d'une trame réponse (rp_dat), par la station productrice (qui contient lavaleur de la variable). Les stations consommatrices concernées prélèvent alors cettevaleur ainsi que l'arbitre du bus, afin de s'assurer que la transaction s'est bien effectuée.

Une demande d'échanges non cycliques de variables aura lieu de la façon suivante :Après la phase 1) de l'échange cyclique (c'est à dire : après le id_dat), l'entité

productrice peut faire une demande explicite pour émettre sur le réseau une autrevariable (identifieur différent), en ajoutant à rp_dat rp_rq pour indiquer au arbitre quelssont les variables qu'elle veut produire.

L'arbitre envoyera les id_dat demandés pendant la phase acyclique et selon sespriorités.

12

Chapitre II -La proposition de norme SP-50

II.1 -IntroductionNous présentons ici les principales idées figurant dans le document fourni par le

"Instrument Society of America" dont le but est proposer une norme pour les bus deterrain et l'interconnexion de bus de terrain (un bus est encore appelé un segment).

Ce document spécifie les services et protocoles de la couche liaison de donnéesdont la technique d'accès au bus est la technique du jeton.

La structure d'un réseau composé de plusieurs segments est représenté sur lafigure 2.1.

LM LM

BLMPont

B

LM LMB

LM

LM LM

B

fig 2.1

On peut distinguer quatre grands types de stations :

-Les stations "Link Master" (LM) qui sont des stations qui à un moment donnépossèdent le jeton et exercent donc le rôle de maître du bus (C'est à dire elles peuventinitialiser un dialogue et les stations qui répondent jouent le rôle d'esclave.

-Les stations de Base (B) qui sont des stations ne possédant jamais le jeton etdonc ne pouvant que répondre à des sollicitations des stations LM (rôle d'esclave).

-Parmi les stations LM, il faut encore définir une station particulières quis'occupe de la gestion du jeton (cette station est appelé LAS -"Link Active Scheduller").Les stations LM élisent celle d'entre elles qui joue le rôle LAS.

-Notons enfin qu'une station Pont permet l'interconnexion de deux segments etpossède l'attribut LM.

II.2 -Les Services de la couche de liaison de données

Quatre types de services sont définis :

13

II.2.1 -Service de gestion d'adresses et de ressources associéesUne entité de la couche liaison de données possède plusieurs points d'accès au

service (DLSAP) auxquels il faut donc associer des adresses. Le fait d'avoir plusieursDLSAPs dans une entité permet d'avoir des services différents associés à ces DLSAPs etdonc de prévoir l'ordonnancement de ces services. A chaque DLSAP peuvent êtreassociées des ressources (buffer / FIFO) pour effectuer avec un système de priorités lacommunication avec les entités distantes.

II.2.2 -Service de liaison de données orienté connexionOn définit des connexions point à point ou multipoint. Notons que, dans le cadre

des services orientés connexion, on peut associer à chaque DLSAP des suffixes, ce quipermet d'avoir plusieurs connexions avec un ou plusieurs DLSAPs dans des entitéséloignées (ces suffixes sont appelés des CEP : "Connection End Points". On note alorsDLCEP au lieu de DLSAP).

Des paramètres sont négotiés à l'établissement d'une connexion, en particulier desparamètres relatifs aux données que l'on veut échanger (taille, priorité, qualité de service(duplication acceptable ou non, perte acceptable ou non), temps maximum pour obtenirune confirmation du transfert).

Un service orienté connexion, permet de réaliser de manière fiable des échangesd'une séquence de blocs de données.

II.2.3 -Service de liaison de données non orienté connexion

Ce service permet de gérer des échanges de messages courts et sans relation lesuns avec les autres.

Un aspect important concernant ce type de services est celui de l'effort requispour le fournir. On distingue deux niveaux :

a) Avec minimisation des pertes : Le service est fourni avec acquittement et, encas d'erreur (pas d'acquittement), on aura une autre tentative immédiate. Ceci marchebien si on fait la communication dans le même segment; par contre, si on sort dusegment l'acquittement sera donné par l'entité pont concernant et on aura seulement lagarantie que les données sont sorties du segment.

b) Avec minimisation des coûts : Le service est fourni avec un acquittementlocal. Cela ne garantit pas l'arrivée des données à leur destination.

II.2.4 -Service d'ordonnancement de liaison de données

Ce service est une caractéristique très intéressante de la proposition de norme.Ce type de service permet en particulier de définir au niveau d'une entité un

ordonnancement sur les différents adresses locales (DLSAPs et DLCEPs) destransactions avec les entités éloignées. Cet ordonnancement est ensuite géré par le LAS(qui donc doit avoir la connaissance, mais la norme ne dit pas comment).

Les transactions à exécuter seront regroupées sous la forme de séquences avecpriorité définie, et seront exécutées d'une façon acyclique (sous condition à définir) oucyclique dans chaque station.

En utilisant les services d'ordonnancement, on peut avoir plusieurs programmessur un segment, déclenchables d'une façon ordonnée. Tous ces aspects sont gérés par leLAS, en donnant la parole (passage du jeton) d'une façon ordonnée à toutes les entitésdu segment.

14

Evidemment, pour avoir une bonne utilisation de toutes ces fonctions, l'utilisateurdoit prendre en compte les principaux aspects divers des communications en tempscritique, par exemple les aspects cycliques ou non cycliques des différentes variables àtransmettre, et bien choisir les différentes fenêtres temporelles. De cette façon, onfacilitera le travail du LAS, ce qui entraînera à des meilleures performances du systèmeglobal.

II.3 -Les protocoles de la couche liaison de donnéesOn peut distinguer trois grandes types de protocoles :a) protocoles pour la gestion d'un segment;b) protocoles pour la gestion d'une connexion;c) protocoles pour le transfert de données ( dans le cas d'un protocole orienté

connexion ou non orienté connexion);

II.3.1 -Gestion d'un segmentLa gestion d'un segment concerne principalement tous les mécanismes

nécessaires pour que des stations puissent devenir maîtres du segment pendant unecertaine période (ce droit consiste en la possession d'un jeton pendant un certain temps;l'obtention du jeton peut résulter d'une condition pré-établie à la configuration dusystème ou d'une demande).

Dans la proposition de norme SP-50 sont définies deux types de jetons à gérerpar le LAS : le jeton circulé ("Circulated Token -CIT") et le jeton délégué ("DelegatedToken -DET").

Le jeton circulé est un jeton avec une certaine durée maximum, qui est envoyé àune entité LM et qui ensuite le passe successivement à au plus sept entités LM dusegment dans l'ordre croissant des adresses, permettant à chacune d'avoir le contrôle dusegment et d'effectuer les actions désirées jusqu'à l'écoulement du temps défini. Aprèsceci, le jeton est renvoyé par la dernière station LM (quand le temps est écoulé) au LAS, sachant qu'au maximum 8 entités ont reçu le jeton dans le segment. Aucun mécanismede priorité n'est associé à ce jeton.

Ce mécanisme, pour être bien utilisé, exige que :a) Les entités dans le segment possèdent des adresses adjacentes;b) les besoins de communication des entités contiguës soient plus ou moins

équivalents. Si ceci n'est pas respecté, le jeton circulé sera envoyé à des entités qui n'enont pas besoin.

Pour faciliter l'utilisation du jeton circulé, le LAS peut faire une scrutationcyclique à huit entités pour voir si une entité à besoin du jeton, en utilisant le "CIP -Circulated Pool".

Le jeton délégué, par contre, est envoyé à une seule entité LM pendant un tempsdéfini, lui permettant d'avoir le contrôle du segment pour effectuer le déclenchement desactions souhaitées. L'entité qui a reçu le jeton doit le rendre au LAS, après avoir finitoutes ses activités ou bien au plus tard, après l'écoulement du temps. Un mécanisme depriorité est associé au jeton délégué et permet la restriction des actions à effectuer à unou plusieurs types de demande.

Un mécanisme de scrutation (le "DEP Delegated Pool") permet également defaire des demandes individuelles vers des entités choisies, pour savoir si elles ont besoindu jeton et si oui avec quelle priorité.

15

II.3.2 -Transfert de données

En ce qui concerne les mécanismes de transfert de données, on peut les présenterde plusieurs façons, par exemple en fonction de la qualité de service associée, la causedu déclenchement de la transmission ou les caractéristiques périodiques ou apériodiquesdes données elles mêmes.

-Qualité de service associée

En considérant la qualité de service associée, on peut diviser les mécanismes detransfert de données en deux groupes :

a) avec acquittement local;b) avec acquittement distant.

consommateur consommateurproducteur

LAS LM

LAS LM

DU (i_r)

DU

fig 2.2 fig 2.3

L'acquittement local, offre seulement la garantie que le PDU a été envoyé. Parcontre, avec l'acquittement distant, on a la garantie que le PDU est arrivé de l'autre cotéde la liaison. Le choix du mode de transfert de données, dans le cas d'une liaison point àpoint, est directement lié à la qualité de service qui a été demandée par l'utilisateur dansl'ouverture de connexion (transfert avec ouverture de connexion), ou dans la requête deservice pour envoyer les données (transfert sans ouverture de connexion). Dans le cas decommunication en diffusion ("multicast" ou "broadcast") le transfert de données esttoujours avec acquittement local. On peut voir un exemple sur les figures 2.2 et 2.3.

-Cause du Déclenchement de transmission

En considérant la cause du déclenchement de la transmission, on peut diviser lesmécanismes de transfert de données en deux groupes :

a) Ceux qui ont un déclenchement local oub) Ceux qui ont un déclenchement distant.Le déclenchement local de la transmission peut être effectué quand l'entité qui a

le jeton (et qui par conséquence est le maître du segment) veut transmettre des donnéessur le réseau. Les données à transmettre peuvent être périodiques ou apériodiques.

16

Par contre, le déclenchement distant d'une transmission de données estl'équivalent d'un fonctionnement type maître / esclave sur le segment, dans lequel l'entitéqui a le jeton donne la permission à une deuxième station d'envoyer une unité deprotocole à une ou plusieurs entités. Après que la deuxième station ait effectué satransmission, le contrôle du segment retourne à l'entité qui à le jeton (voir exemple àdeux phases dans la figure 2.4).


LAS LM

LAS LM

DU (i_r)

DU

fig 2.4

Le LM qui a le jeton doit, pour donner la parole à la deuxième station, envoyerune unité de protocole DU avec la permission de réponse immédiate (DU (i_r)"immediate reply"), et la deuxième entité doit envoyer une unité de protocole DU sur lesegment. Cette transmission n'est pas obligatoirement adressée au station LM.

-Caractéristiques périodiques ou apériodiquesEn considérant les caractéristiques intrinsèques des données à transmettre, on

peut diviser les mécanismes de transfert de données en deux groupes :a) transferts périodiques oub) apériodiques.Le déclenchement de la transmission de données périodiques est toujours fait

par l'entité qui a le jeton (LM), qu'il s'agisse d'un déclenchement local ou distant. Celasignifie que l'on a toujours une (ou plusieurs) séquence pré définies, qui serontdéclenchées d'une façon périodique, dans lesquelles la transmission de données decaractéristiques périodiques est définie (Notons que comme c'est le LAS qui a laconnaissance de toutes les séquences prévues pour le segment, c'est lui qui assurera ledéclenchement correct des données périodiques).

Par contre, quand quelqu'un veut émettre des données apériodiques, on peutprévoir deux types des scénarios :

a) Pour une séquence locale préalablement définie, déclenchable d'une façonapériodique (fonction de l'existence d'activité dans un certain adresse), on peut prévoir lefonctionnement suivant : Le LAS a connaissance de toutes les séquences prévues dans lesegment. Quand les conditions de déclenchement se produisent, le LAS a immédiatementconnaissance de la nécessité de servir cette séquence. C'est le même cas que pour unscénario périodique.

17

b) Quand une entité veut transmettre des données apériodiques et nonpréalablement définies, ou bien elle a le jeton et peut utiliser le temps accordé pour faireles actions les plus importantes, ou bien elle doit informer le LAS de son besoin deservice.

Pour qu'une entité informe le LAS, elle doit attendre de recevoir une unité deprotocole qui exige une réponse immédiate et inclure dans la réponse une demande deservice ("delegation request") dans le champ approprié (champ "dd"), et avec la prioritédésirée. L'unité de protocole sera diffusée dans le segment, consommé par le(s)consommateur(s) respectifs et le LAS aura connaissance de cette demande de service(voir scénario fig 2.5 avec utilisation du champ "dd" de l'unité de protocole DU).

Le LAS permettra ensuite la transmission de données apériodiques seulement aumoment approprié.


LAS LM

LAS LM

DU (i_r)

DU (dd)

LAS informé de demande de service

fig 2.5

II.4 -Comparaison FIP / SP-50

II.4.1 -Généralités

Les méthodes d'accès au médiumD'une façon globale, nous pouvons considérer la proposition de norme SP-50,

comme un système mixte, en ce qui concerne les aspects d'accès au médium.En effets, dans cette proposition de norme, nous trouvons des aspects

caractéristiques des systèmes d'accès au médium par passage de jeton (la station qui a lejeton sera le maître du segment pendant une durée accordée), où les aspects concernantsà la gestion du segment sont effectués par une station élue parmi les stations LM : leLAS (c'est l'influence de Profibus [PRO, 91]).

Pourtant, nous trouvons aussi des aspects caractéristiques des systèmes d'accèstype maître / esclave, avec des mécanismes qui permettent aux stations qui n'ont pas lecontrôle du segment (esclaves) de demander un service à la station maître.

Par analyse des divers types de stations existants dans un système SP-50, noustrouvons des stations ("Basic") auxquelles seulement est permis le fonctionnementcomme esclave dans le méthode d'accès maître / esclave. Par contre, pour toutes lesautres stations ("LM" et "Bridge") sont permis les deux types de stratégies d'accès.

18

La norme FIP définit un système d'accès au médium type maître / esclave, danslequel la station maître (l'arbitre du bus) a le contrôle de tout le bus. Nous trouvons aussidans cette norme, des mécanismes qui permettent aux stations qui n'ont pas le contrôledu segment (esclaves) de demander un service à l'arbitre du bus.

Gestion d'adresses, connexions et ressources associéesDans la norme FIP nous avons une adressage statique avec deux types

d'"adresses", selon que l'on envoie des données ou des messages :-Pour chaque variable à transmettre sur le bus, nous avons un identifieur (16 bits)

unique associé. Le transfert des variables, géré par l'arbitre du bus, est toujours fait enfonction de ces identifieurs.

-Nous avons aussi un service de messagerie point à point, qui utilise un systèmed'adressage à 24 bits permettant de coder le numéro du segment réseau de l'entitécommunicante et sa sous adresse dans le segment.

Par contre, dans la proposition de norme SP-50, est fourni un systèmed'adressage qui permet la gestion des ressources de chaque entité d'une façon dynamique(en fonction des DLSAP adresses et des DLCEPs existant localement). Ceci permet enfonction des besoins une allocation / libération de ressources à chaque instant.

La proposition de norme ne considère aucune différence entre l'envoi de variablesou de messages : Tous sont considérés comme des données à transmettre. La taille,priorité et caractéristiques des données sont des paramètres à établir cas par cas.

Ordonnancement de la liaison de donnéesTous les services d'ordonnancement de la liaison de données sont seulement

fournis dans la proposition de norme SP-50 et pas dans la norme FIP.Il est désirable depouvoir influencer la gestion du jeton, et de cette façon de pouvoir "contrôler"l'exécution ordonnée de toutes les séquences périodiques définies localement.

Dans la norme FIP, qui définit un système maître / esclave, nous avons seulementune séquence périodique à accomplir : celle de l'arbitre du bus. Donc, nous n'avons pasbesoin d'influencer l'ordonnancement de plusieurs séquences distribuées, comme dans unsystème SP-50.

II.4.2 -Les services de transfert de donnéesLe transfert de données dans un système SP-50 peut être effectué avec une très

grand flexibilité, par exemple : avec ou sans ouverture de connexion; avec ou sansacquittement; point à point ou multipoint; avec différentes qualités de service.

Par contre, dans un système FIP, nous n'avons qu'un type de service pour letransfert des variables et deux pour le transfert des messages.

En ce qui concerne la cause du déclenchement du transfert des données, pour letransfert de données périodiques, le système FIP dû à sa topologie maître / esclave,permet seulement le déclenchement distant de la transmission (provoqué par l'arbitre dubus). En plus, dans ce système, nous ne pouvons pas avoir de séquences d'exécutionapériodique préalablement définies, en utilisant seulement les services de la couche deliaison de données.

Comme dans le cas d'un système FIP la diversité de modes de transfert estnettement inférieure, nous essayerons de faire une comparaison des scénarios detransmission, entre quelques services existants dans cette norme et ceux qui sont"équivalents" dans la proposition de norme SP-50.

19

Le déclenchement de transmission considéré dans SP-50 sera le déclenchementdistant, parce que dans un système FIP (centralisé) le déclenchement d'actions locales(dans les divers stations) doit être toujours effectué par l'arbitre du bus.

La présentation suivante ne se veut pas exhaustive (voir [LEV, 91]). Le but estde comparer d'une façon simplifiée quelques aspects relevant de la norme FIP et lesaspects équivalents dans SP-50.

Pour le transfert de variables en FIP, nous ferons une comparaison avec letransfert de données multipoint ("group DLSAP-addr"), sans ouverture de connexion("connectionless") et avec acquittement local ("least cost") du système SP-50. La qualitéde service associée doit définir une priorité d'ordonnancement "normal" ou "timeavailable" (avec une limitation à 128 octets de données dans ce deuxième cas), unegamme d'adressage "medium" et une diversité de chemin "fixed path". Seulement aveccette définition, nous pouvons dire que les services offerts par les deux systèmes sont"équivalents".

Transfert périodique de variablesLe scénario SP-50 (fig 2.6) montre comment effectuer le déclenchement distant

périodique d'une transmission de données entre un "producteur" et plusieurs"consommateurs".

LM

DL-BEGIN-SEQ-DEFINITION DL-SCHEDULE-INTERVAL DL-SAP addr : <addr 1.1> Action class : delegate-to-responder DL-END-SEQ-DEFINITION DL-SCHEDULE-SEQUENCE Schedule type : cyclic Cycle period : 10ms Starting time : immediate

PUBLISHER SUBSCRIBER 1 SUBSCRIBER 2

DL-UNITDATA req data : "Asterix"

DL-ATTACH addr : <addr 1.1> DL-CREATE Fifo



DU <addr 1.1> ; i_r

DL-UNITDATA ind

DU <addr 2.1> ; "Asterix"

DL-UNITDATA ind data : "Asterix"(après 10ms)

DU <addr 1.1> ; i_r

DU <addr 2.1> ; "Obelix"

(etc)

DL-UNITDATA req data : "Obelix"

DL-UNITDATA ind

DL-UNITDATA ind data : "Asterix"

DL-UNITDATA ind data : "Obelix"

DL-UNITDATA ind data : "Obelix"DL-UNITDATA req

data : "J. Cesar"

fig 2.6

20

Dans cet exemple, nous avons une séquence définie dans une station, et cetteséquence déclenchera cycliquement toutes les 10ms l'action suivante : permettre à l'entitéd'adresse 1.1 d'envoyer un (et seulement un) message (un PDU) à travers le bus.

Le scénario équivalent en FIP est représenté dans la figure 2.7 (seulement leséchanges d'unités de protocole). Nous aurons une équivalence si l'arbitre du bus produitla variable identifiée par id_x tous les 10ms.

Arbitre du bus

id_dat


Arbitre du bus


rp_dat

fig 2.7

Transfert apériodique de variables

-Scénario SP-50

Supposons que le scénario de trafic périodique se maintient, et que, dans le bus,la station "publisher" veut émettre des données concernant une autre adresse, avec unecertaine priorité.

Dans ce cas, quand cette station reçoive la permission d'émettre un message (unPDU), elle lui ajoute une demande de permission d'émission sur le bus (champ "dd")avec une certaine priorité (dans ce cas priorité 01 -"urgent"). Le LAS, après avoir lu cemessage, demande à la station au moment approprié, quel type de service elle veutexécuter. Après avoir lu la réponse, le LAS effectue le service à l'instant approprié(exemple figure 2.8).

Ceci peut être exécuté d'une autre façon, en utilisant les capacités de passage dejeton, et en donnant la main à la station qui demande le service. Le problème seratoujours ne pas connaître la durée approprié à donner au jeton avant de l'envoyer.

Dans le scénario FIP équivalent (fig 2.9), la station qui demande le service, insèreautomatiquement dans la demande tous les identifieurs des variables qu'elle veutproduire sur le réseau. Nous pouvons constater que dans ce cas, la procédureéquivalente en FIP est moins lourde.

21

LAS PUBLISHER SUBSCRIBER 1 SUBSCRIBER 2

DU <addr 1.1> ; i_r

DL-UNITDATA conf

DU <addr 2.1> ; dd=01 ; "Asterix"


(etc)

DeT (pp=01) ; addr 1.1


DL-BEGIN-SEQ-DEFINITION DL-SCHEDULE-INTERVAL DL-SAP addr : <addr1.2> Action class : delegate-to-responder DL-SCHEDULE-INTERVAL DL-SAP addr : <addr1.3> Action class : delegate-to-responder DL-END-SEQ-DEFINITION

DL-SCHEDULE-SEQUENCE Schedule type : after DL-SAP activity DL-SAP addr : <addr 1.1> Priority : Urgent(tous les 10ms)

après temps disponible

DU <addr 2.2> ; data

DeR (pp=01) ; addr 1.2 ; addr 1.3

DU <addr 1.2> ; i_r

DU <addr 2.3> ; data

DU <addr 1.3> ; i_r

fig 2.8

id_dat (id_1)

rp_dat (id_1) rp_rq (id_2; id_3)

(etc)

(tous les 10ms)

après temps disponible

Arbitre du bus Producteur variable id_1

Consommateur variable id_1

Consommateur variable id_1

rp_dat (id_2) rp_rq (id_3)

rp_dat (id_3)

id_dat (id_2)

id_dat (id_3)

fig 2.9

22

Chapitre III

Les Réseaux de Petri Temporisés Stochastiques

III.1 -Introduction

Le développement des applications distribuées temps réel a besoin de réseaux decommunication basés sur des architectures multicouches de protocoles et de services.

Ces architectures font appel à de nombreux mécanismes complexes : Il est alorsabsolument nécessaire de vérifier leurs comportements avant l'implantation afin d'éviterde mauvais fonctionnements dus à des erreurs de conception. Pour cela, il est essentield'utiliser des techniques de description formelle pour détecter et corriger d'éventuelleserreurs de spécification.

La représentation formelle d'architectures de communication demande desmodèles ayant les attributs suivants :

-Expression du parallélisme et de la synchronisation par échange de messages,-Prise en compte des contraintes temporelles ( le temps peut être un élément de

synchronisation)-Possibilité d'une analyse qualitative (logique des mécanismes),-Possibilité d'une analyse quantitative (performances).

III.2 -Réseaux de Petri classiques

Les Réseaux de Petri classiques permettent une modélisation formelle demécanismes tels que parallélisme et synchronisation par échange de messages. Ilspermettent aussi une analyse qualitative. Des propriétés générales peuvent être observéestelles que "atteignabilité" d'un état, possibilité d'une séquence d'événements, absence demarquage, nombre fini d'états... [BRA 83].

III.2.1 -Définition formelle

-Un Réseau de Petri est un quadruplet R= <P, T, PRE, POST>P est un ensemble fini de placesT est un ensemble fini de transitions

PRE : P*T∅ N est l'application d'incidence avant,

POST : P*T∅ N est l'application d'incidence arrière,

-Un Réseau de Petri marqué est le couple N= [R, M] formé d'un réseau R et

d'une application M : P∅ N, appelée marquage. M(p) est le marquage de la place P, ondit aussi le nombre de marques contenues dans P.

III.2.2 -Règle de fonctionnement

La règle de fonctionnement des réseaux marqués leur donne une dynamique enprécisant comment les transitions permettent de modifier les nombres de marquescontenues dans les places.

23

-Une transition t est franchissable pour un marquage M ssi∀ p E P; M(p)� PRE(p, t ); c'est la précondition de t.

-Si t est franchissable pour M, le franchissement de t permet d'obtenir le nouveaumarquage M' tel que :

∀ p E P; M'(p)= M(p)- PRE(p,t)+ POST(p,t) c'est la post condition pourqu'un marquage M' puisse résulter du franchissement de la transition t.

On peut vérifier deux types de propriétés qualitatives :

-Propriétés générales (indépendantes du graphe de marquage particulier), tellesque vivacité (capacité du système évoluer) et "bornabilité" (capacité d'implémentationd'un système borné). Notons que dans le cas des systèmes de communication, l'absencede vivacité peut induire la perte ou corruption de messages.

-Propriétés spécifiques ( en fonction de l'étude du graphe de marquage). Deuxpropriétés importantes des systèmes de communication peuvent être analysées :l'obtention d'une séquence d'événements attendue (par exemple, en utilisant la capacitéd'effectuer des projections sur les primitives de service, on peut vérifier si le protocolefourni le service attendu); l'obtention des relations logiques parmi deux événements oudeux conditions.

Cependant, ces modèles ne permettent pas de représenter convenablement lescaractéristiques dites de temps réel, essentielles lors de la modélisation de protocoles :des extensions temporelles ont donc été définies.

III.3 -Réseaux de Petri Temporisés

Les Réseaux de Petri Temporisés (RPT) ont été introduits pour analyserl'influence des contraintes temporelles dans la spécification des modèles. Ceux-cipermettent de modéliser les mécanismes de temps de transport, date limite de passage,...

Le modèle est basé sur celui des réseaux de Petri classiques auquel on a ajoutéune application intervalle de temps associé aux transitions : cette application permetd'exprimer un intervalle de temps où chaque transition peut être tirée [ROU, 89].

Le modèle RPT ne permet cependant pas une analyse quantitative desperformances. Pour cela, il a été introduit un autre modèle complémentaire : le modèleRdPTS (Réseaux de Petri Temporisés Stochastiques) que va être présenté par la suite[JUA, 90].

III.4 -Le modèle Réseau de Petri Temporisé Stochastique (RdPTS)

Le modèle Réseau de Petri Temporisé Stochastique est issu des Réseaux de PetriTemporisés et des Réseaux de Petri Stochastiques. Il permet de représenter lespropriétés qualitatives des systèmes telles que synchronisation temporelles (prise encompte de l'influence des contraintes temporelles sur la logique des mécanismes),concurrence, compétition et des propriétés quantitatives propres aux performances dessystèmes.

III.4.1 -Définition formelle

Un Réseaux de Petri Temporisé Stochastique est un triplet : <PN, I0, F0>.

24

-PN est le réseau de Petri sous-jacent,-I0 est une fonction intervalle de tir : à chaque transition ti est associé un

intervalle de tir Ii= [ai, bi] avec 0 �a i �b i ��; a i et bi étant respectivement la borneinférieure (date de tir au plus tôt) et la borne supérieure de l'intervalle de tir (date de tirau plus tard), dans laquelle la transition ti est tirable.

-F0 est une fonction densité de probabilité de tir : à chaque transition ti estassocié une densité de probabilité fi(x) telle que :

⌡⌠ai

bifi(x)dx=1

On considère plusieurs types de formes pour fi(x) :-Cas d'un intervalle [ai, bi] avec bi borné supérieurement :

*fi(x) peut être une densité de probabilité :1. uniquement uniforme : fic(x)= Ci2. uniquement discrète : fid(x)= � nKin�(x- Θn)

3. mixte.-Cas d'un intervalle [ai, bi] avec ai=0 et bi non borné

*fi(x) peut être une densité de probabilité exponentielle.Les densités de probabilité définies au niveau de la fonction F0 sont encore

appelées densités de probabilité intrinsèques.

III.4.2 -Règle de fonctionnementLa règle de fonctionnement du RdPTS, c'est à dire son comportement

dynamique, est basée sur le franchissement des transitions.Une transition ti est franchissable depuis un marquage donné ssi :1. ti vérifie la règle de fonctionnement du réseau de Petri Temporisée sous-

jacent, relative au franchissement d'une transition [Roux, 85],2. elle possède un intervalle de temps sensibilisé,3. La probabilité de tirer ti sur l'intervalle de temps considéré est non nulle.

III.4.3 -Graphe d'états probabiliséLe graphe d'états probabilisé visualise le comportement dynamique du modèle

RdPTS (compte tenu de toutes ses caractéristiques). Il est basé sur deux concepts : leconcept d'état et le concept de transition entre états.

III.4.3.1 -Etats du modèleUn état est un triplet <M, D, F> où :-M est le marquage du réseau de Petri sous-jacent,-D est le domaine de tir, c'est à dire l'ensemble des intervalles de tir des

transitions sensibilisées par le marquage de cet état,-F est le processus stochastique de tir, c'est à dire l'ensemble des densités de

probabilité associés à l'ensemble des intervalles du domaine de tir.Notons que le doublet <M, D> représente une classe d'états dans le modèle RPT

[Roux, 85].

III.4.3.2 -Transition entre états

25

La transition entre deux états est un triplet <ti, Θi, Pi > où :-ti est la transition du réseau de Petri sous-jacent dont le tir provoque le

changement d'état,-Θi est l'instant moyen de tir : Θi est compris entre la date de tir au plus tôt de la

transition ti et la plus petit des dates de tir au plus tard de toutes les transitionssensibilisés dans l'état de départ de la transition -DIT (Dernier Instant de Tir),

-Pi est la probabilité de branchement associée au tir de la transition ti(branchement entre l'état de départ et l'état d'arrivé); plus précisément Pi est laprobabilité de tirer la transition ti entre sa date de tir au plus tôt et la date DIT, sachantque les autres transitions sensibilisés dans cette état seront tirées après.

III.4.4 -Construction du graphe d'états probabiliséTrois points essentiels caractérisent cette construction :1 -La détermination à partir d'un état Ei d'une transition ti tirable,

2 -Le calcul de la probabilité de branchement Pi et du temps moyen Θi .3 -Le calcul d'un nouvel état Ei+1 (nouveau marquage M', nouveau domaine de

tir D' et nouvelle fonction densité de probabilité de tir F').Dans le point 2, on doit considérer deux types de transitions :a) Transition exclusive : le calcul de Pi et de Θi ne dépend strictement que du

domaine de tir Ii et de la fonction densité de probabilité intrinsèque fi (x).

Pi= ⌡⌠Θmi

ΘMi fi(x)dx=1

Θi= ⌡⌠Θmi

ΘMi x.fi(x)dx

b) Transition compétitive ou parallèle : Le calcul de Pi et Θi dépend maintenantd'une part, du domaine de tir Ii et de la fonction de densité de probabilité fi (x), maiségalement, d'autre part, des domaines de tir Ij, Ik ... des autres transitions tj, t ...sensibilisées et de leurs fonctions densité de probabilité intrinsèque fj(x), fk(x) ...

C'est pourquoi, dans ce cas à était défini relativement à la transition ti unefonction densité de probabilité extrinsèque fie(x) (intégrant les influences des autrestransitions sensibilisés) [JUA, 89].

Pi= ⌡⌠Θmi

DΙΤ fie(x)dx=1

Θi= 1Pi

⌡⌠Θmi

DΙΤ x.fie(x)dx

Le point 3 dépend de l'attribut "mémoire temporelle" de l'état Ei+1 atteint aprèsle tir d'une transition ti .

26

a)Ei+1 n'a pas de mémoire temporelle :D-cas où ti est une transition exclusive et fi (x) est quelconque,-cas où ti est une transition compétitive et les densités de probabilité fi

(x), fj (x), fk (x), sont quelconques,-cas où ti est une transition parallèle et les densités de probabilité fj(x),

fk(x) sont uniquement du type exponentiel.Dans ce cas, les intervalles temporels et les fonctions densité de probabilité du

nouvel état Ei+1 sont les intervalles temporels et les fonctions densité de probabilitéspécifiés initialement des transitions nouvellement sensibilisées.

b)Ei+1 a de la mémoire temporelle :Ceci se produit dans le cas où ti est une transition parallèle et les autres

transitions tj, tk, simultanément sensibilisés ont des distributions non toutesexponentielles. Dans ce cas les caractéristiques des transitions non exponentiellesintégrant leur age (intervalle de temps diminué de Θi , fonctions de densité de probabilité

intrinsèque tenant compte de l'age Θi ). Par contre, les transitions nouvellementsensibilisés reçoivent leurs attributs de la spécification initiale (intervalles de temps -densités de probabilités intrinsèques).

III.4.5 -Intérêts du graphe d'états probabiliséCe graphe comporte trois informations relatives au comportement du système

modélisé.-le nom de la transition ti du réseau de Petri sous-jacent dont le franchissement a

provoqué le changement d'état,-le temps moyen Θi de franchissement de la transition ti ,-la probabilité Pi de franchissement de la transition ti .L'étude du graphe peut être faite de deux façons complémentaires :

1. Tout d'abord, en ne considérant pas les informations Θi et Pi associés aux arcs : si onne prend en compte que les séquences de tirs, ce graphe permet une analyse qualitativedes propriétés générales du système, compte tenu des contraintes de parallélisme,d'échange de messages, de synchronisation, mais également des contraintes temporelles(en effet, la structure du graphe dépend, par définition, des contraintes temporelles).

2. Ensuite, en considérant les valeurs Θi et Pi , on peut évaluer toutes les performancesdu type probabilité d'un chemin (ce qui permet en particulier, d'évaluer la probabilitéd'une séquence de primitives de services et/ou de messages de protocoles). De plus, despropriétés du type suivant, très importantes dans un contexte temps réel, sont aussianalysables : après l'occurrence d'un événement "x", il y a une probabilité de X% quel'événement "y" se produisse dans Y unités de temps.

III.5 -Exemples d'applicationIII.5.1 -Modèle RPT

On veut montrer la capacité du modèle RPT de représenter les contraintestemporelles et de faire une évaluation des mécanismes de communication basés sur lasynchronisation, avec l'exemple suivant :

1 -Réseau de Petri sous-jacent :

27

Le modèle du réseau de Petri est celui de la figure 3.1. La place Prod représentel'entité Productrice, laquelle est prête à produire une message. La transition t1 représentela production d'un message et la reposition du Producteur en mode "Prêt à produire". Latransition t2 représente le Moyen de Transmission et la place P2 l'arrivé du message ausite Consommateur. Dans ce site on a place Cons, qui représente l'entité Consommatriceprête à consommer un message. On représente aussi un Buffer, dans lequel le messagearrivé sera mémorisé. Ce Buffer est représenté par 2 places : Buf_V (représent le Buffervide) et Buf_P (Buffer plein). L'action de consommer un message et de retourner à l'état"Prêt à consommer" est représenté par la transition t5.

La transition t3 représente l'action de réception normale du message (i.e. lemessage qui arrive est mémorisé et le buffer vide redevient plein). On a aussi représentéune situation de mauvais fonctionnement du coté Consommateur (la transition t4représent l'arrivé d'une message quand le buffer est plein : le message mémorisé seraécrasé). Ce type de représentation est intéressant, parce que on est en présence d'unprotocole sans contrôle de flux.

Le modèle est non borné (la transition t1 peut être tirée repétitivement), mais ilest vivant (toutes les transitions peuvent être tirées). On doit avoir une attention spécialevis-à vis de la transition t4 (dans le fonctionnement normal du système, t4 ne doit êtrejamais tirée).

t1t2

t3

t4

t5

Prod

P1

P2

Buf_V

Buf_P

Cons

fig 3.1

2 -Spécification des contraintes temporellesa) Spécification 1 : On associe les intervalles de temps suivants aux transitions

du réseau de Petri :

t1 t2 t3 t4 t5[4,6] [2,3] [0,0] [0,0] [0,2]

Le graphe de classe d'états résultant est celui de la fig 3.2 (dans le graphe, lesarcs entre les classes d'état sont étiquetés avec la même référence que la transition duréseau de Petri qui a provoqué la transition d'état, et avec les bornes temporelles).

Le graphe résultant est un graphe borné et on peut voir que le système neprésente aucun interblocage. La "bornabilité" du système est le résultat immédiat descontraintes temporelles (ceci montre l'importance de la synchronisation temporelle,comme mécanisme fondamental du protocole).

28

En analysant le protocole, la transition t4 n'est jamais tirée parce que les temps deconsommation et de production ont une relation que implique que, quand un nouveaumessage arrive, le buffer est vide (fonctionnement correct).

b) Spécification 2 : On considère les intervalles de temps identiques à ceux de laspécification a) excepté pour la transition t5; maintenant on considère t5= [0,4]. Enconséquence, le consommateur est plus lent que dans la première spécification.

Le graphe de classe d'états est représenté dans la fig 3.3. Dans ce cas, latransition t4 peut être tirée (écrasage de buffer) : situation d'erreur.

C0

C1

C2

C3

C4C5 C6

C0

C1

C2

C3

C4C5 C7

C6

t1[4,6]

t2[2,3]

t1[0,4]t3[0,0]

t1[1,2] t5[0,2]

t5[0,1]

t1[4,6]

t2[2,3]

t3[0,0]t1[0,4]

t5[0,4]t1[1,4]

t2[2,3]

t2[1,3]

t5[0,3]

t5[0,0]

t2[0,3]

t4[0,0]

fig 3.2 fig3.3

Cette analyse, montre l'influence des contraintes temporelles, mais pour avoir unevue plus claire (valeurs quantitatives), on doit ajouter de l'information aux intervalles detir (fonctions de densité de probabilité).

III.5.1 -Modèle RPTSPour ajouter d'information au modèle RPT, on peut utiliser le modèle RDPTS,

qui permet l'analyse quantitative et qualitative de notre système. On analysera le modèlede la spécification 2, en considérant les fonctions de densité de probabilité associés auxdiverses transitions en utilisant le concept de graphe à 1-x% [JUA, 90]. Les résultatsobtenus sont représentés sur la figure 3.4 (dans le cas de x=0.1%).

t1 t2 t3 t4 t5Intervalle de tir [4,6] [2,3] [0,0] [0,0] [0,2]Distribution sur

l'intervalle0.75 δ(x-4)+

+0.125 1 δ(x) δ(x) 0.25

Dans ce graphe, les arcs entre les états probabilisés sont étiquetés avec la mêmeréférence que transition du réseau de Petri qui a provoqué la transition d'état, laprobabilité de tir de la transition et son temps moyen.

29

On peut obtenir beaucoup d'information quantitative, en exploitant les matricesde probabilité de transitions et de temps moyen de tir.

t1 t2 t3

t5

t2

t5

t1t4

t5

t1

t51;4.2 1;2.5 1;0

.44;.9

.56;1.6

.97;1.1

.03;2.1

1;0

.53;1.1

.47,2

1;1

t11;.8

t2t2

1;1.5

1;1.3

S0 S1 S2 S3

S4

S11

S5

S6 S7

S8

S9 S10

fig 3.4

Par exemple, on peut voir qu'en fonctionnement stationnaire la probabilitérespectivement d'un cycle normal (sans tirer t4) et d'un cycle anormal (tirant t4) sera :

-Pn=0.44+0.56*0.97=0.985-Pa=0.56*0.03=0.015

Nous rappelons qu'un cycle normal consiste à ce que le buffer soit lu avantqu'une nouvelle donnée n'arrive, tandis que un cycle anormal se produit lorsque ladonnée stockée dans le buffer est écrasée par la donnée suivante.

30

Chapitre IV

Modélisation et analyse de mécanismes decommunication de la norme ISA-SP50

IV.1 -Introduction

Dans cette section, nous nous proposons de modéliser au moyen du modèleRdPTS une activité de communication essentielle pour assurer le service périodique dusystème SP50. Cette activité concerne les mécanismes de passage du jeton délégué pourle LAS, à une station LM dans le segment (appelés mécanismes "niveau segment").Après cela, nous ferons la modélisation du fonctionnement de la station qui a le jetondélégué en plusieurs phases, avec différentes complexités de mécanismes (appelésmécanismes "niveau station"). Finalement, nous modéliserons aussi quelques aspectsrelatifs aux protocoles de communications avec les autres stations dans le segment(appelé mécanismes "niveau protocole").

L'analyse effectuée concerne principalement l'influence des contraintestemporelles (différentes temporisations, fluctuations des valeurs de ces temporisations,...) sur les performances de l'activité modélisée.

La modélisation est faite de la manière suivante :-Modélisation des différents éléments de l'architecture du système considéré au

moyen des Réseaux de Petri.-Définition des contraintes temporelles et des distributions de densité de

probabilité associées aux intervalles de temps (modèle Réseau de Petri TemporiséStochastique).

IV.2 -Modélisation "niveau segment"

-Architecture

L'architecture du système considéré (LAS - LM - Stations tiers) est représentésur la figure 4.1.

LAS LM

fig 4.1

Le fonctionnement considéré du système est le suivant :-Le LAS, en connaissant les services dont une station a besoin sur le segment,

envoie un jeton délégué avec une certaine durée vers une station LM pour qu'elle puisseeffectuer les actions nécessaires. Ceci représente une demande de service périodique ou

31

apériodique, et la station LM qui reçoit le jeton fonctionne comme maître du segmentpendant la durée spécifiée.

L'aspect "politique de gestion du jeton délégué" par la partie du LAS, ne sera pasabordée dans ce travail.

-Contraintes temporellesLe LAS envoie le jeton délégué périodiquement à une station LM pour une durée

limitée.

-ModélisationLe modèle RdPTS représentant le niveau segment, est dessiné sur la figure 4.2.

La transition t31 représente la passage de jeton de l'entité LAS à l'entité LM. Latransition t7 indique le renvoie du jeton par la entité LM à l'entité LAS quand la durée aexpiré ou quand il n'y a plus d'action à exécuter sur la station LM.

Le but de ce modèle est de supporter la modélisation du niveau inférieur, celui dela station.

LAS

LM

P1

P30 t7

t31

fig 4.2

IV.3 -Modélisation "niveau station"

Dans la modélisation des mécanismes associés au jeton délégué, au niveaustation, on trouve plusieurs aspects intéressants sur son fonctionnement, tels que ladurée et les priorités associées. On a choisi de faire la modélisation par étapes, pour voird'une façon séquentielle et simplifiée les aspects concernants chacune de ces étapes.

IV.3.1 -L'aspect durée

On a essayé d'abord de modéliser les aspects associés à la durée du jeton délégué,quand il arrive sur une station.

-Architecture

L'architecture de ce niveau de modélisation est représentée sur les figures 4.3.sous la forme de "state chart" [HAR, 88].

La représentation du système sous la forme d'une "state chart", permet de donnerune vue simplifié du système et de ses mécanismes de parallélisme (je rappelle que, dansune "state chart", une ligne en pointillé divisant deux modules signifie que ces deux

32

modules évoluent en parallèle; un arc x interconnectant deux modules signifie qu'unévénement x permet de passer d'un module vers l'autre).

Par analyse de la "state chart", on voit d'abord l'action de prise du jeton (a) etl'action de restitution du jeton au LAS (b). Ensuite on voit que la production de donnéess'effectue indépendamment du fait que l'entité LM (toute la region ombrée) aie ou non lejeton, jusqu'à que se produise l'événement (c) : Buffer plein. Les donnés seronttransmises quand l'entité a le jeton (C) et avant que l'événement (b) ne se produise.

La temporisation locale démarre lorsque le jeton arrive à l'entité LM etl'événement (b) est produit quand il n'y a plus de données ou quand la temporisation setermine.

Production de donnés

(LM)transmis

siontempori-

sationLAS

Buffer plein (LM)

a

b

cd

CA B

SYSTEME

fig 4.3

-Contraintes temporelles

-On doit dans notre modèle considérer les aspects suivants :a) Taux d'arrivée de données (module production de données);b) Temps associé à la transmission de chaque donnée (ce temps ne sera pas

constant, parce que les données n'ont pas toujours la même taille).c) Temporisation associée à la duré du jeton délégué. Cette temporisation sera

initialisée avec le paramètre "durée" qui provient du jeton délégué.

-Modélisation

Le modèle de l'arrivée du jeton délégué à une station LM est représenté sur lafigure 4.4, où les transitions t1 et t2 représentent respectivement l'arrivée du jeton àl'entité LM et son départ respectivement. Expliquons le modèle :

-Quand le LAS envoie un jeton délégué, la transition t1 est franchie et latemporisation t4 démarre. Cette temporisation a une valeur équivalente à la durée dujeton, donc quand la durée se termine, t4 est tirée. En parallèle on a une file de données(P4) avec un buffer de mémorisation (P5). La transition t3 modélise l'arrivée de donnéeset t5 le départ. Le buffer à une capacité maximum de n données. Quand le jeton arrive àla station (P9), elle peut commencer à transmettre les données (t5) qui se trouvent dansle buffer. Le jeton sera renvoyé au LAS (tir de t2) quand le buffer est vide (tir de t7) ouquand la temporisation expire (tir de t6).

33

P4

P7

P5

t3

t7

nt5

t1

t6

t4

t8 t9

t2

P18

P15P14

P13

P10

P9

fig4.4

Ceci permet montrer les aspects essentiels du fonctionnement d'une station quireçoive le jeton délégué.

-AnalyseLa longueur moyenne des messages considérés dans notre analyse étant de 60

octets et le taux de transmission de données étant de 1 Mbit/s, la durée des messages estde 480µs. Le timer Trd (durée du jeton délégué) a une valeur de 2.75 ms et le buffer detransmission une capacité de 2 messages (n=2). Dans le tableau suivant, on représenteles fonctions de densité de probabilité associées aux transitions du réseau de Petri.

transition

t1 t2 t3 t4 t5 t6 t7 t8 t9

f.d.p. δ(x) 0.05 --- δ(x--2.75)

δ(x-1) δ(x) δ(x) δ(x) δ(x)

intervalle [0,0] [5,25] --- [2.75,2.75]

[0.5,0.5]

[0,0] [0,0] [0,0] [0,0]

On présente aussi plusieurs exemples de modélisation correspondant à desdistributions temporelles différents pour ce qui concerne les taux d'arrivé des données(fonction de densité de probabilité associé à t3).

L'analyse effectué par les Réseaux de Petri Temporisés Stochastiques permet devérifier les aspects qualitatifs et quantitatifs du fonctionnement des mécanismesmodélisés.

Exemple A B C Dt3 : f.d.p. e-λt 1 2 δ(x)

t3 :intervalle

[1,�] [0.5,1.5] [0.75,1.25] [1,1]

34

Par rapport aux aspects qualitatifs, on peut vérifier à travers l'analyse des graphesd'états probabilisés, que le système a deux comportements différents :

a) dans une première phase, comme le buffer est vide, le jeton est renvoyé auLAS, et

b) dans une deuxième phase, avec le buffer plein, la transmission de données esteffectuée pendant la durée du jeton (Trd) ou jusqu'à ce que le buffer soit vide.

Par rapport aux aspects quantitatifs, il est intéressant de connaître les divers tauxd'arrivée des données, les probabilités de renvoyer le jeton au LAS après avoir envoyétous les messages ou après l'expiration de la durée associée au jeton. Dans ce derniercas, il est aussi intéressant de connaître quel est le nombre moyen de messages qui sontrestés dans le buffer (P5).

-Résultats

On a obtenu les résultats suivants pour les 4 exemples définis dans le paragrapheprécédent et dans dans les deux phases :

-Phase 1A B C D

P(tir t4) 0 0 0 0P(tir t7) 1 1 1 1

E[m(P5)]ℑ(tirt4)

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

-Phase 2A B C D

P(tir t4) 0.8 0.75 0.5 0.5P(tir t7) 0. 0.25 0.5 0.5

E[m(P5)]ℑ(tirt4)

1.19 1 1 1.096

IV.3.2 -Les aspects durée et priorité

-ArchitectureEn parallèle avec l'aspect durée, on peut aussi considérer l'aspect priorité associé

au jeton délégué.Dans chaque station LM les données à transmettre peuvent se voir associées une

des trois priorités : A -"urgent", B -"normal" ou C -"time available". Quand le LASenvoie le jeton à une station LM, il peut limiter son utilisation par la station LM à unepriorité supérieure à une valeur désirée, c'est à dire, si le jeton à une priorité normale, onne peut transmettre que des données urgentes et normales.

Dans la "state chart" (fig 4.5) on peut voir les mécanismes de production dedonnées subdivisés en trois (chacune d'une priorité différente : A, B et C). Dans lesmécanismes de transmission de données on peut voir que l'on démarre toujours par latransmission de données de priorité la plus élevée (A) et que des mécanismes depréemption (e, f, g, h et i) permettent de revenir pour effectuer la transmission de

35

données de priorité plus élevée avant le fin de la temporisation, en cas de besoin (donnéede priorité X produit pendant la tranmission d'une donnée de priorité inférieur).

temporisation

LAS

a

b

C

Aa B

pA pB pC

bpA bpB bpC

tA tB

tC

Ab AcSYSTEME

cAdA

cBdB cC

dC

ef

g

h

i

fig 4.5-Contraintes temporelles

On doit considérer dans ce modèle (en plus de ce que l'on a considéré dans lemodèle précédent) que les temps associés à la transmission des données de chaquepriorité sont différents, parce que la taille des données permises est aussi différente.

Le taux d'arrivée des données sera aussi différent pour chaque priorité .

-Modélisation

Le modèle concernant tous ces aspects est représenté dans la figure 4.6, où lestransitions t7 et t31 représentent respectivement l'arrivée du jeton à l'entité LM et sondépart. Expliquons le modèle :

-Quand le LAS envoie un jeton délégué, la transition t7 est tirée et latemporisation t9 démarre. Cette temporisation a une valeur équivalente à la durée dujeton, donc quand la durée se termine, t9 est tirée.

En parallèle on a trois files de donnés (P6, P7 et P8) avec les buffers respectifs demémorisation (P12, P13 et P14). Chaque file représente le mécanisme des données d'unepriorité déterminée : P6 priorité "urgent", P7 priorité "normal" et P8 priorité "timeavailable". Les transitions t1, t2 et t3 modélisent l'arrivée des données et les transitionst4, t5 et t6 leur départ. Les buffers associés à chaque priorité ont une capacité limitée àdeux données (mesure fictive pour faciliter la simulation).

Lorsque le jeton délégué arrive à la station, cette dernière peut effectuer destransactions jusqu'à une certaine priorité. Cette valeur est chargée dans la variable x(poids d'un arc), qui permet de voir sur un compteur (P24) quelles sont les files que l'ondoit servir. X a une valeur donnée par le tableau suivant :

Priorité xUrgent 1Normal 2

"Time available" 3

36

P6P9

P12

P26P3

P4

P7

P8

P10

P11

P13

P14

P27

P28

P5

x

P23 P24

P26 P27 P28

P14P13 P12

P4

P3 P24

P5

P3 P24

2

P5 P12

P4 P24

t7

t1

t2

t3

t4

t5

t6

t8

t9

t10t11

t12

t13

t14

t15t16

t17t18

t19

t20t21

t22

t23t24 t25 t26

t27t28 t29 t30

t31

P2

P16

P12P13 P14

P17

P15

P18P19 P20 P21

P22

t32

t33

t34

FILE "TIME AVAILABLE"

(11)

FILE "NORMAL"

(10)

FILE "URGENT"

(01)

fig 4.6

37

A partir de ce moment, la station peut commencer à transmettre des données deplus haute priorité (P3 et t32) qui se trouvent dans le buffer respectif. Quand le bufferest vide et si la priorité associée au jeton le permet, la station commence à transmettredes données de priorité normale (P4 et t33) et de même pour les donnés de priorité "timeavailable".

Les mécanismes qui permettent d'effectuer la préemption sont les transitions t20,t21 et t22, et les mécanismes qui permettent de déterminer quelles sont les files à serviren fonction de la priorité associée au jeton délégué sont les transitions t16 et t18.

Le jeton sera prêt à être renvoyé au LAS (P15) quand les buffers à servir serontvides (tir de t15, t17 ou t19) ou quand la temporisation expirera (P16). Si latemporisation expire, on devra revenir à l'état précédent le début de la dernièretransmission (tir de t10, t11 ou t12) et on remettra le conteur à zéro (tir de t13 et t14),avant de continuer.

Finalement, on peut déterminer si on a besoin de demander au LAS un autretemps de service et avec quelle priorité, selon le tableau suivant :

Séquence desortie

t26 /P21 /t30 t25 /P20 /t29 t24 /P19 /t28 t23 /P18 /t27

Priorité deservice désiré

Aucune(00)

"Urgent"(01)

"Normal"(10)

"Time available"(11)

-Analyse

L'analyse de ce niveau de modélisation sera faite en deux parties :a) Analyse avec une durée du jeton délégué constante et des taux d'arrivé de

données variables;b) Analyse avec une durée du jeton délégué variable et des taux d'arrivé de

données constantes;Pour les deux types d'analyse, nous avons choisi les paramètres suivants :-Longueur moyenne des messages de 20 octets (160µs) pour un message

"urgent", de 60 octets (480µs) pour un "normal" et de 120 octets pour un "timeavailable".

-Taux de transmission des données de 1Mbit/s et buffer de transmission avec unecapacité de 2 messages (n=2).

-Timer Trd (durée du jeton délégué) avec un valeur de 6 ms dans la premièreanalyse et variable dans la deuxième.

-Analyse 1 (durée du jeton délégué constante)

Dans le tableau suivant, on représente les fonctions de densité de probabilitéassociées aux transitions du réseau de Petri.

transition t1 t2 t3 t4 t5 t6 t9 (durée) Autres

f.d.p. --- --- --- δ(x-16) δ(x-48) δ(x-96) δ(x-600) δ(x)

intervalle --- --- --- [16,16] [48,48] [96,96] [600,600] [0,0]

38

On présente aussi deux exemples de modélisation correspondant à desdistributions temporelles différents pour ce qui concerne les taux d'arrivé des données(fonctions de densité de probabilité associés à t1, t2 et t3).

Exemple A t1 t2 t3

f.d.p. 0.25 0.4 0.5

intervalle [0,4] [0,2.5] [0,2]

Exemple B t1 t2 t3

f.d.p. δ(x-4) δ(x-2.5) δ(x-2)

intervalle [4,4] [2.5,2.5] [2,2]

L'analyse effectué par les Réseaux de Petri Temporisés Stochastiques permet devérifier les aspects qualitatifs et quantitatifs du fonctionnement des mécanismesmodélisés.

Par rapport aux aspects qualitatifs, on peut vérifier à travers l'analyse des graphesd'états probabilisés dans les deux cas, que le système a deux comportements différents :


b) dans une deuxième phase, avec le buffer plein, la transmission de données esteffectuée jusqu'à ce que le buffer soit de nouveau vide. Comme nous avons choisi unedurée pour le jeton suffisamment grande (par rapport aux taux d'arrivée des données),toutes les transactions seront effectuées avant de l'expiration de cette durée.

-Résultats (analyse 1)Par analyse des résultats, nous pouvons vérifier tous les aspects liées aux

mécanismes de service des différents files (pour les différents priorités) et auxmécanismes de préemption qui permettent d'intercaler des transactions de plus hautepriorité parmi les transactions en cours.

-Analyse 2 (durée du jeton délégué variable)Dans le tableau suivant, on représente les fonctions de densité de probabilité

associées aux transitions du réseau de Petri.

transition t1 t2 t3 t4 t5 t6 t9

(durée)

Autres

f.d.p. δ(x-4) δ(x-2.5) δ(x-2) δ(x-16) δ(x-48) δ(x-96) --- δ(x)

intervalle [4,4] [2.5,2.5] [2,2] [16,16] [48,48] [96,96] --- [0,0]

On présente aussi deux exemples de modélisation correspondant à desdistributions temporelles différentes pour ce qui concerne la durée du jeton délégué(fonction de densité de probabilité associé à t9).

L'analyse effectuée par les Réseaux de Petri Temporisés Stochastiques permet devérifier les aspects qualitatifs et quantitatifs du fonctionnement des mécanismesmodélisés.

39

Exemple A B C

t9 : f.d.p. δ(x-6)0.25δ(x-2)+0.25δ(x-3)+

+0.25δ(x-3.5)+0.25δ(x-6) 0.5

t9 : intervalle [6,6] [2,6] [2,4]

Par rapport aux aspects qualitatifs, on peut vérifier (comme dans les casprécédents) à travers l'analyse des graphes d'états probabilisés, que le système a deuxcomportements différents :


b) dans une deuxième phase, avec le buffer plein, la transmission de données esteffectuée pendant la durée du jeton (Trd) ou jusqu'à ce que les trois buffers soient denouveau vides.

-Résultats (analyse 2)

Par analyse des résultats, nous pouvons vérifier l'influence de la durée du jetonsur le fonctionnement de tous les mécanismes de la station, comme par exemple si on ale temps suffisant ou non pour vider tous les buffers ou dans le cas contraire quelle est laprobabilité de laisser desdonnées non transmises pour chaque priorité.

Nous pouvons aussi constater qu'en utilisant plusieurs impulsions de Dirac, avecla valeur désirée, dans la fonction de densité de probabilité d'une transition (exemple B),nous pouvons voir le résultat d'utilisation d'un jeton pour différents temporisations.

IV.4 -Modélisation niveau "protocole de communication"

Dans la modélisation niveau "station" nous nous sommes intéressés auxmécanismes internes de fonctionnement d'une station, quand elle reçoit un jeton délégué.Cependant, nous devons encore représenter les transactions à un autre niveau : celui duprotocole de communication, c'est à dire les échanges entre la station qui a le jeton etcelle qui reçoit le message.

Ce niveau de modélisation représente les actions concernant la transmission dedonnées dans le modèle du niveau "station", que d'une façon abrégée on a représenté parun ensemble place / transition pour chaque priorité de données.

Dans la proposition de norme SP-50, nous pouvons transmettre les données deplusieurs façons : avec acquittement local ou distant (mécanisme de réponse immédiatedu consommateur ("immediate reply")), avec ou sans ouverture de connexion, avecdifférents qualités de service, etc...

Dans ce travail, nous avons modélisé uniquement une transmission de donnéessans ouverture de connexion ("connectionless") et avec acquittement local ("least cost").

-Architecture

L'architecture du système considéré (LM - station consommatrice) est représentésur la figure 4.7.

40

LM

Station consommatricePDU

fig 4.7-Contraintes temporelles

Le temps associé à l'envoi d'un message dépend de sa priorité. Dans le modèleréseau de Petri, que nous montrerons de suite, nous représentons les différentes prioritésde données (avec différents longueurs moyennes de données) à transmettre par unetransition avec différents temporisations associées pour chaque cas.

-Modélisation

Le modèle RdPTS représentant le niveau "protocole de communication", pourune communication comme défini précédemment, est dessiné sur la figure 4.8.

Les transitions t1 et t3 représentent respectivement le début et la fin detransmission. Pour faire une intégration de ce modèle avec le modèle du niveau "station",nous devons faire la substitution de la place intermédiaire entre les transitions début etfin de transmission, pour tout ce modèle (par exemple, pour la file "urgent" nous devonssubstituer la place P26 pour le modèle approprié du niveau "protocole decommunication").

P2

P3 P4

P5

t1

t2t4

t3 t5

P1

fig 4.8

Quand nous avons le début d'une transmission, la transition t2 sera sensibilisée.Cette transition représente le temps de traitement de la station. Quand la transition serafranchie, on envoie un PDU à l'autre station (P2, t4 et P4) et on signale "fin detransmission" au niveau "station".

Ceci représente un modèle très simple d'un cas d'envoi de données, mais il faudraencore modéliser plusieurs types de communications, et ensuite faire une analyseconjointe avec le niveau "station", pour avoir des résultats plus intéressants. Cetteanalyse sera effectuée par la suite.

41

Conclusion

Cette étude nous a permis de nous familiariser avec:

-Les réseaux locaux industriels et en particulier les bus de terrain qui permettentla mise en oeuvre d'applications distribuées à fortes contraintes temporelles.

-Les protocoles de communication pour les bus de terrain : nous avons analysé leprojet de norme SP-50 qui combine les aspects de la norme Profibus et de la norme FIP.

-Le modèle Réseau de Petri Temporisé Stochastique qui est un modèle bienadapté à l'étude des systèmes informatiques distribués temps réel.

En ce qui concerne l'analyse effectué sur la norme SP-50, nous avons considéréuniquement le mécanisme inhérent à la technique du jeton délégué, que nous avonsanalysé de manière structurée (niveau segment, niveau station, niveau protocole decommunication). En particulier, nous avons étudié le phénomène de la production dedonnées, en tenant compte de la durée du jeton délégué, des différents files dans lastation avec des priorités et des taux d'arrivées différents.

Ce travail de DEA est le début d'un travail qui devra nous permettre de faired'une part, une analyse complète de la norme SP-50 et d'autre part, une analysecomparative des différents architectures des réseaux locaux temps critique (élémentsessentiels.dans le contexte du développement de la Production Automatisée. A partir dela, nous pensons pouvoir définir une approche méthodologique pour la spécificationd'architectures de communication temps réel, ce qui devrait constituer notre travail dethèse.

42

Bibliographie

[ISA 359H] -ISA /SP50 Data link service definition

[ISA 360H] -ISA /SP50 Data link protocol specification

[LEV, 91] -359/ 360 Fieldbus data link tutorials collection, Leviti, 65C-WG6

[FIP, 90] -FIP, la couche liaison de donnés, norme AFNOR, 91

[PRO, 91] -Profibus standard, translation of German standard, DIN 19245, 91

[PLE, 88] -Time critical communication networks : Field buses, Pleinevaux etal, IEEE Networks, 5/88

[STE, 88] -Computer communications for industrial automation: the MAPprotocols, Stewart, Comp. Communications, 10/88

[BEU, 88] -Les réseaux locaux industriels, Beuchot et Josserand, Hermes

[ATM, 90] -Modélisation et analyse au moyen de réseaux de Petri TemporisésStochastiques de protocoles de communication temps réel du système FIP,Atamna, Rapport de DEA 89/90, LAAS

[JUA, 91] -Modèles pour l'analyse qualitative et/ou quantitative d'architecturesde communication temps réel, Juanole, RGE 2/91

[ULL, 91] -Fieldbus application layer and real time distributed systems, Ulloa,IECON'91

[BER, 91] -Modélisation et analyse des contraintes temporelles dans les réseauxlocaux, Bergé, Rapport de DEA 90/91, LAAS

[LEP, 91] -Les réseaux locaux industriels, Lepage et al, Hermes

[JUA, 92] -Petri Nets based models and communication protocols, Juanole etAtamna, ETFA'92, IEEE Workshop on emerging technology for factoryautomation, Australie

[ATM, 92] -Le modèle réseaux de Petri temporisés stochastiques -Applicationau système de communication FIP, Atamna et Juanole, Rapport LAAS 92

modélisation et analyse de mécanismes de communication de

Documents