Réseaux inform. répartie (1993) Thomesse

Cet article est en cours de mise en ligne

Cette page est destinée à héberger un article, écrit par Jean-Pierre Thomesse et publié dans la revue Réseaux et informatique répartie en 1993.

Introduction

Encore un article sur FIP, (Factory Instrumentation Protocol ou en français Flux d’informations en provenance du ou vers le Processus) ! Oui, mais aussi sur le concept de réseau de terrain. Au moment où la normalisation internationale avance de façon significative, où des projets européens comme DIAS (Distributed Intelligent Actuators and Sensors (FAN 92] sont arrivés à des résultats reconnus importants, il nous a semblé utile de faire le point sur l'histoire de FIP et sur ce que FIP apporte en tant que services ou fonctionnalités nouvelles. L’histoire est toujours instructive et celle de FIP est très différente de celles de ses rivaux.

En un mot, FIP est né de la volonté de quelques personnes représentant dès le début plutôt les utilisateurs ; les constructeurs ont ensuite été associés et depuis lors, tous ont coopéré de façon exemplaire avec les laboratoires qui l'ont voulu et ne l'oublions pas, avec l’aide des pouvoirs publics.

Cet investissement initial de grandes entreprises, utilisatrices de réseaux, d'automatique et d'informatique industrielle, a conduit à des spécifications originales et surtout indépendantes de l'offre courante, traduisant les besoins en informatique temps réel répartie des futures installations ; originalité et vision futuriste qui évidemment furent des freins à la normalisation tant que l’analyse des promoteurs n'était pas comprise de tous les acteurs. Après les rappels historiques qui s’imposaient, cet article présente les particularités des réseaux de terrain, par rapport aux réseaux généraux pour lesquels les modèles et les principales nonnes de services et de protocoles ont été faits.

Cette analyse est menée en plusieurs temps, d'abord les services tels que les utilisateurs veulent les voir, puis sous l’angle de la communication en termes d'architecture au sens du modèle OSI, avec une étude des caractéristiques et des mécanismes utiles pour les protocoles de réseaux de terrain. C’est ainsi qu'on reprendra les concepts usuels tels que les acquittements, le contrôle de flux, etc. pour analyser les choix possibles dans le cas qui nous intéresse. Enfin dans une dernière partie, les particularités de FIP seront détaillées ; à savoir quelle architecture pour FIP, quels services, quels protocoles ?

Un avertissement s’impose. Nous avons voulu éviter les formalismes pour mettre l’accent sur les motivations qui d'ailleurs n'étaient pas toujours, il y a plusieurs années, aussi explicites qu'elles peuvent l'être aujourd'hui. C'est pourquoi à plusieurs endroits, certains choix seront discutés sans démonstration formelle. Nous n’avons pas voulu, non plus comparer FIP à d'autres propositions. C'est certainement à faire, ce fut déjà fait au moins en partie [INT 89], [AGU 89], mais il fallait déjà, une présentation de FIP avant d'étudier d'autres réseaux et leurs comparaisons. Enfin, d’un point de vue pratique, nous nous sommes limités aux couches OSI de liaison de données et d'application, qui sont les plus significatives de FIP. Les autres couches mériteraient d'autres présentations, ainsi que la gestion de réseau, la sûreté de fonctionnement, les normes d'accompagnement et beaucoup d'autres sujets à traiter et à présenter.

L'histoire de FIP

Le contexte en 1982

L'idée d’un réseau de terrain allait naître (le terme n’existait pas encore et on ne parlait pas encore de réseau d'instrumentation), même si certaines idées étaient déjà plus ou moins dans l'air. On parlera plutôt de réseau de terrain que de bus pour ne pas supposer une topologie particulière. Même si la plupart de ces réseaux ont une topologie de bus, d’autres sont possibles, celle d'anneau par exemple SERCOS1 [MUT 89].

En 1982, les réseaux locaux industriels (réseaux privés des constructeurs de système de contrôle/commande et réseaux d'automates essentiellement, GIXINET en France), commençaient à être installés. Aux Etats-Unis, le projet MAP^ en était à ses débuts.�

Le réseau de lerrain FIP 289 Le rapport du Professeur Soutif [SOU 82] recommandait alors de favoriser le développement de l'instrumentation et la notion de "smart sensor" (traduit par "capteur intelligent") faisait son apparition en France. Des moyens de communication numériques sont alors nécessaires. Des utilisateurs, par leur expérience et l’analyse de leurs applications avaient aussi identifié des besoins en communication pour satisfaire aussi bien la commande des procédés que leur maintenance, leur gestion, en particulier à EDF^ et au sein de ITïXERA [GAL 82].

Par ailleurs, des besoins de communication spécifiques au temps réel avaient été identifiés. Pour y répondre, des mécanismes sont étudiés et proposés à la fois comme des services temps réel, de communication au sens OSI et comme des primitives de langage, voire comme des concepts structurants [MEN 76], [THO 80], [LAD 82].

En particulier le concept de données dites transmissibles explicitant différents flux de données et le comportement des consommateurs, vis à vis du flux d'exemplaires, est en partie à la base du mécanisme de mise à jour de FIP [COC 78], [COC 81, [NON 78a], [NON 78b], [THO 78]. Ces différents principes de communication ont été ensuite approfondis dans [PER 85]. A la demande de quelques industriels, les pouvoirs publics décidaient en juin 1982 d'organiser une réflexion sur la possibilité de définir de nouvelles nonnes de communication et Monsieur Robert Berthoumieux de la Mission Scientifique et Technique du Ministère de la Recherche et de la Technologie, me demandait d'animer un groupe de travail sur les réseaux locaux industriels, afin d'étudier ce qu'il était envisageable de faire dans ce domaine - quelles actions devraient être menées

Je me rappelle la communication téléphonique de Monsieur Berthoumieux, en juin 1982, alors que j'étais dans une salle de travaux pratiques avec des élèves. Il me dit : "Il faudrait définir quelque chose qui serait le CP/M de l'instrumentation".Je rappellerai à ceux qui n'ont pas connu la micro-informatique de cette époque, que CP/M était un des "standards" de système d'exploitation des ordinateurs personnels. Souhaitons à FTP une autre carrière que celle de ce "standard" ! Dans l’esprit de Robert Berthoumieux, il s'agissait déjà de définir un standard ou une norme. On n'imaginait pas, à l'époque, à quel point l'aspect "système d'exploitation", au sens originel du terme, allait lui aussi s'appliquer à FIP. Les objectifs du groupe de travail étaient, en reprenant les termes de la demande, de proposer : - un système d'échanges d'information entre les éléments d'une chaîne de régulation ou d'automatismes qui pourrait faire l'objet d'une norme, - les composants de couplage entre le support de ce système et les éléments de la chaîne, - le logiciel d'exploitation de microordinateurs adapté à ce système, aux besoins de la régulation et des automatismes et aux langages de programmation de haut niveau.� 290 Réseaux et informatique répartie. Vol. 3 - n° 3/1993 2.2. La naissance des concepts FIP Le 30 septembre 1982, le groupe de travail se réunissait pour la première fois au 5 rue Descartes à Paris. Il est important de noter que ce groupe était constitué d'utilisateurs, d’ingéniéristes et de chercheurs. Les représentants de l’offre ne sont apparus que plus tard une fois les principales spécifications énoncées. Un certain nombre d'actions étaient engagées : - préciser les besoins des utilisateurs, - faire le point des études économiques existantes [LAN 82] sur le sujet, - préciser comment on pourrait évaluer les systèmes de contrôle/commande, - recenser les normes ou les projets de nonnes, - recenser les projets de recherche en cours sur le sujet Le premier rapport intermédiaire en janvier 1983 établissait quelques recommandations : 1. Isoler les réseaux de capteurs/actionneurs des autres types de réseaux, pour les raisons suivantes : - le besoin est assez bien identifié et recensé ; - les solutions actuelles (en 1982) ne sont pas transposables ; - les coûts de connexion doivent être faibles ; - il n’existe pas de norme (ni de projet de norme) sur ce plan. 2. Les recommandations concrètes étaient (déjà ! ) : - sortir des spécifications pour fondre les protocoles dans le silicium et bien sûr - trouver les partenaires ; ■ établir une proposition de norme internationale dans des délais les plus brefs possibles (nous étions en janvier 1983) ; - informer les utilisateurs potentiels de façon à ce qu'ils puissent intégrer le produit dans leurs produits propres. 3. Pour des réseaux autres que les réseaux de terrain, certains travaux à mener étaient identifiés, en particulier, - proposer des projets de norme pour les couches du modèle OSI non encore normalisées et pour satisfaire des besoins non encore couverts, 4� Le réseau de terrain FIP 291 Du point de vue économique, les économies sur le câblage (études, réalisation..,) étaient déjà bien appréhendées et le besoin de faire une norme internationale était parfaitement ancré dans l'esprit des participants au groupe de travail. Un dernier point stipulait la nécessité de figer les protocoles dans le silicium. Le sous-groupe de travail prenait alors la décision de spécifier plus précisément FIP ; ce fut fait lors d'un séminaire les 19-20 et 21 avril 1983 qui s'est tenu à l’hôtel Mercure à Orsay. Les principes techniques de base de FIP y furent édictés. Certaine contribution de J.M. Cour [COU 83a] allait même jusqu’à proposer une première note d’application d'un circuit FIP OOO.Les fonctionnalités d’émission / réception et des diagrammes de temps étaient proposés. Ceci montrait à quel point on désirait tous voir se concrétiser les travaux. Mais il fallut un an encore pour éditer le premier document public sur FIP [GAL 84] connu sous le nom de "Livre blanc". Il était diffusé par le Ministère de l’Industrie et de la Recherche le 24 mai 1984, à environ deux cents exemplaires auprès des responsables de grandes sociétés pouvant être intéressés. Ce document présentait les motivations économiques et techniques pour étudier un réseau de terrain et les premières spécifications fonctionnelles préliminaires. Nous avions pris le parti de ne pas breveter les propositions mais de les diffuser le plus largement possible afin de convaincre un maximum de sociétés du bien fondé du système d’abord, et ensuite afin d’en faire une norme non seulement française mais aussi et surtout internationale. Qu’était FIP à ceue époque ? Essentiellement un sigle, une analyse de la problématique de la communication industrielle et de la situation internationale sur ce sujet, des recommandations et quelques principes de base. Sans reprendre l’ensemble du "livre blanc", FIP devait améliorer les caractéristiques des systèmes décentralisés, dont • la modularité, - la banalisation de l’information de terrain, - la cohérence de ces informations, - la hiérarchisation des communications, - la souplesse d’évolution. L’idée essentielle est alors de mettre à disposition de tout équipement, toute donnée disponible dans le système, à des instants garantis, avec sécurité et disponibilité, et des capacités d’adaptation aux cas industriels d’automatismes, c’est à dire des facilités de configuration pour tenir compte des particularités de chaque cas. Par ailleurs, des études avaient été approfondies au sein du groupe de travail sur des sujets comme : - l'élude de la complexité d'un premier circuit et les techniques de réalisation des circuits intégrés [DAN 84], - l’étude de la sûreté de fonctionnement de FIP [POW 83], - l’étude de la redondance du gestionnaire de nomenclature [ROL 84], et J.M.COUR [COU 83b] plaidait, avec raison, pour la spécification et la construction� 292 Réseaux et informatique répartie. Vol. 3 - n° 3/1993 d’un outil de développement permettant à tout utilisateur potentiel de s'initier et de prendre connaissance des possibilités de FIP. Il aura fallu attendre la fin 1990 pour disposer d'un tel outil avec le circuit Fullfip et le FIP starter kit [CEG 90] d'une part et les outils FEP ToolBox du centre de compétence de FIP [LET 90a], mais ceci est un autre épisode de l'histoire. On peut ainsi constater qu'en mai 1984, en plus du "Livre Blanc"[GAL 84], nous avions un ensemble de résultats d'études qui incluaient des spécifications techniques détaillées.De plus, alors que nous n’étions pas encore fixés sur le nombre de couches de services et protocoles (et lesquelles), G.Le Lann avait animé un sous groupe chargé d'étudier ce que pourrait être une couche "transport temps réel" [LeL 83a], [AYA 83]. Des mots clés bien connus : temps de réponse, priorités, débit de transport, robustesse, connexion ou pas, point à point, diffusion, adressage, étaient au centre des débats. Certaines de ces idées et de ces contributions ont été utilisées ultérieurement dans la définition des normes françaises ( voir en particulier [UTE 92a]). L’idée de base de données industrielles répartie et temps réel faisait son apparition (voir entres autres [MAM 85]). 2.3. Le premier composant et la naissance du club A la suite de la diffusion du livre blanc, un consortium d’industriels (CGEE Alslhom actuellement CEGELEC, OSEE et TELEMECANIQUE) développait, dans le cadre d'un contrat du Ministère de l'Industrie, le premier composant ”FIP001" [THO 86a]. Il est à noter que le groupe restreint avait continué à travailler et avait rédigé une première spécification technique d’un circuit intégré fin 1984 [FIP 84]. C'est grâce à ce circuit que EdF avec CGEE Alsthom installait industriellement le premier réseau FIP dans sa centrale hydraulique de Revin (Ardennes) en 1987-1988 [LOB 88]. Le développement de cette application mettait en évidence un certain nombre de points : - validité des concepts de base de FIP, - sécurité de la couche liaison de données, mais aussi, comme c'était prévisible, - besoin de spécifier des services de niveau supérieur aux fonctions de FIP001. En parallèle un groupe FIP capteurs était créé, animé par M. Taillebois, qui spécifiait les fonctionnalités qui devaient être offertes pour les capteurs. [DAN 86J. On voyait apparaître ici quelques-uns des services de la couche application, de la gestion de réseau et des normes d'accompagnement qui sont encore à l'étude, en particulier dans des projets français (INF ou européens comme INCA^ , DIAS, PRIAM& entre autres. ^ INF Interface Normalisée Fonctionnelle ^ INCA Interface Normalisée Capteur Actionneur ^ PRIAM Prenrmative Requiremenls for Intelligent Actuation and Measurements� Le réseau de lenain FIP 293 Ces analyses et résultats d'expérience concluaient au besoin de spécifier plus précisément un certain nombre de services (en s'inspirant du modèle OSI) qui, même s’il ne nous semblait pas particulièrement approprié au cas des réseaux de terrain, faisait foi en la matière. C'était un point de passage obligé pour la normalisation internationale. La tâche était d'une autre nature que celle du groupe de travail initial et relevait donc d'une autre démarche que de l'activité de quelques bénévoles, surtout que FIP venait de faire son apparition sur la scène internationale avec une première présentation à une réunion du sous-comité 65C/WG6 de l'IEC [GAU 85]. Le 21 mars 1986, à la FIEE, une réunion était organisée par le Ministère du redéploiement industriel et du commerce extérieur à laquelle participaient non seulement ceux qui étaient impliqués depuis le début dans ce projet mais aussi plus de trente sociétés qui s'étaient montré intéressées par l’idée. C'est à cette réunion qu'était décidée la création de l'association "Club FIP". Une assemblée générale le 13 juin 1986 lançait les travaux du club, organisait les premiers groupes de travail et élisait un bureau présidé par Marc Desjardins, directeur technique de l'EXERA, et donc représentant des utilisateurs. Le club était officiellement créé le 6 mars 1987 ; il allait avoir son siège social à l'ENSEM à Nancy, avant, compte tenu de son développement, d'avoir ses propres locaux en 1990. 2,4. Les objectifs et les travaux du club FIP Le club FIP a comme principal objectif de diffuser et promouvoir le concept FIP. Pour cela, le club, qui regroupe aujourd'hui environ 120 membres, désire être largement ouvert et est prêt à accueillir de nouveaux membres tant français qu'étrangers. Pour atteindre son objectif, le club mène ou coordonne un ensemble de travaux: - études marketing et économiques, - définition de propositions de nonnes, - liaison avec les organismes de normalisation et diverses organisations nationales et internationales, - validation de protocoles, - études des procédures de test de conformité avec l'ACERLI^, - vérification et validation des spécifications techniques des circuits intégrés qui réalisent les protocoles de communication FIP, - développement d'outils et assistance technique - formation au sein d’un centre de compétences FIP, > définition d'un plan industriel, - recherche/développement avec des laboratoires. - préparation de nombreuses expositions et promotion de FIP. Après ces rappels historiques sur les origines de FIP, entrons dans des considérations plus scientifiques et plus techniques. ^ ACERU Association française des Centres d'essai des Réseaux Locaux Industriels� 294 Réseaux et informatique répartie. Vol. 3 - n° 3/1993 3. Le concept de réseau de terrain Définir un réseau et en particulier un réseau de terrain, c'est : - définir des services et des qualités de service, qui ici, s’expriment surtout en termes de respect de contraintes de temps, - choisir une architecture, - définir des protocoles pour assurer les services avec la qualité requise. On pourrait considérer les réseaux de terrain comme des réseaux tout à fait généraux et choisir des services et protocoles dans le grand catalogue de l'ISO. C'est ce qui était plus ou moins attendu des premiers normalisateurs dans ce domaine, peut être par analogie avec ce qui s'était passé dans MAP. En fait une étude tant soit peu approfondie montre que l’on peut obtenir certaines qualités de service en tenant compte des particularités propres aux réseaux de terrain. Les services d'un réseau de terrain sont d'abord issus de ceux des systèmes d’entrées * sorties industrielles (c’est la moindre des choses que de fournir au moins les mêmes services que les systèmes traditionnels). Mais ils sont aussi et surtout issus des besoins de répartir les traitements qui se partagent des données. Ceci conduit en première approximation à considérer qu'un réseau de terrain fournit globalement les services nécessaires aux divers types d'échanges des diverses données entre les entités fonctionnelles qui composent une application industrielle temps réel répartie. 3.1. Les caractéristiques des réseaux de terrain Les caractéristiques des réseaux de terrain sont d'abord relatives aux trafics supportés qui sont relativement bien connus dès que l'on sait dans quelle application sera installé le réseau de terrain. Cette connaissance s'enrichit de celle des contraintes de temps associées à l'application considérée. A cela s'ajoute des besoins directement issus de la répartition des applications sur des sites distants : les problèmes de cohérences. 3.1.1. Objets échangés Un réseau de terrain remplace le câblage traditionnel entre les appareils tels que capteurs, actionneurs (appelés souvent équipements de terrain) et les organes de contrôle ou de commande tels que les automates, les régulateurs appelés équipements de commande. Les échanges entre ces équipements correspondent à des lectures et écritures de valeurs d'objets : valeur de mesures de capteurs vers les organes de commande, valeurs de positionnement d'actionneurs, mais aussi des valeurs de paramètres d'algorithmes implantés aussi bien dans des capteurs que dans des automates ou des actionneurs. Avec le développement des instruments dits intelligents, les échanges concerneront aussi des demandes de service et des envois de comptes rendus comme dans n'importe quel réseau ou système réparti (par ex : activation d'une tâche). Un des points importants est que les objets susceptibles d'être échangés sont connus et définis à partir du moment où on connaît l’application concernée dans� Le réseau de terrain RP 295 laquelle le réseau de terrain est installé. Par exemple, un capteur de pression délivre une pression qui est répertoriée dans l'application. Nous verrons que FIP et maintenant la norme internationale utilisent fort à propos cette connaissance. De plus, comme dans tout réseau, des services usuels de messagerie sont utiles pour communiquer certains messages dont la sémantique n'est connue que des processus d’application qui se les échangent. 3.1.2. Aspects temporels Certains des échanges sont contraints par le temps selon divers types de contraintes. Tout d’abord, les échanges sont, soit périodiques, soit aléatoires. Si on considère les échanges périodiques, ils sont liés à l'usage de la théorie des systèmes échantillonnés pour définir les algorithmes de commande. La demande de rutilisateur est que les échanges soient assurés périodiquement, sans retard, sans déphasage d'un cycle au suivant. Les périodes ne sont certainement pas toutes les mêmes, compte tenu des constantes de temps des variables des procédés. En ce qui concerne les échanges aléatoires, il en est qui sont contraints par une échéance. Les demandes de service elles mêmes peuvent être contraintes ou non par une échéance pour obtenir la réponse à une requête. Il est donc évident que certains services fournis par le réseau de terrain seront contraints par le temps et que d'autres ne le seront pas. Notion de fenêtre temporelle Si on considère les algorithmes de commande, ils nécessitent généralement plusieurs données d'entrées pour évaluer des commandes. Ces entrées doivent être mesurées à des instants pas trop éloignés les uns des autres, ou autrement dit, dans un intervalle de temps spécifié. On dira alors que les entrées (ou plus généralement les données) sont dans une même fenêtre temporelle. La répartition des applications conduit à considérer des horloges réparties ; le réseau de terrain doit fournir un minimum de services pour permettre de garantir le respect de ce type de contraintes, liées à l'existence du concept de fenêtre temporelle. Ceci se traduit par la nécessité de définir un service du type READ LIST au sens de MMS^ mais avec des implantations différentes pour les éléments de la liste en mettant aussi en évidence ici le besoin de synchroniser au moins les productions des objets composant la liste et d'organiser leurs transferts. 3.2. Cohérence des données Les cohérences de données sont capitales pour autoriser la moindre distribution des traitements sur des sites différents. Nous considérerons d'abord les aspects de cohérences temporelles puis la cohérence spatiale. Prenons un exemple pour illustrer les cohérences des données vues par les processus d'application. Soient 2 capteurs de pression et 2 capteurs de débits notés PI, P2, Dl, D2. MMS ManufacturingMessage Spécification� 296 Réseaux et informatique répartie. Vol. 3 - n° 3/1993 Soient un régulateur, un automate et un poste opérateur qui utilisent les valeurs produites par ces capteurs.

3.2.1. Cohérence temporelle On suppose que le régulateur a besoin à certains instants périodiques des valeurs de PI, Dl, P2, D2. La cohérence temporelle de production de PI, Dl, P2, D2 est une propriété qui indique si ces quatre valeurs ont été produites dans une même fenêtre temporelle. Il faut en effet être sûr que toutes les valeurs datent à peu près du même instant d’échantillonnage pour la cohérence de l’algorithme. La cohérence temporelle de transmission de PI, Dl, P2, D2 est une propriété qui indique si ces quatre valeurs sont arrivées chez Tutilisateur dans une fenêtre temporelle donnée et sont donc disponibles au moment où l'algorithme de régulation doit être exécuté. 3.2.2. Cohérence spatiale En général plusieurs stations sont des récepteurs potentiels d'une même information car on voudrait favoriser la répartition des traitements ce qui pose le problème de la cohérence spatiale connu aussi sous le nom de la diffusion fiable. Si les processus d'application répartis sont conduits à prendre des décisions à partir de listes de variables, il est nécessaire que les valeurs des variables de ces listes soient égales, pour que les décisions soient cohérentes. La cohérence spatiale concerne des listes identiques de variables utilisées par des processus sur des stations différentes. La cohérence spatiale d'une liste est une propriété qui indique à tous les utilisateurs de la liste que les copies des valeurs de variables sont les mêmes chez tous les utilisateurs. C'est pour ces raisons que d'autres modèles de coopération que le modèle client serveur entre les processus d'application doivent être étudiés. En effet, le modèle client serveur permet aux utilisateurs d'avoir accès séquentiellement à la liste de valeurs. Deux accès successifs au serveur par deux clients peuvent donner des résultats différents, ce qui conduit à des copies différentes chez les deux clients.� Le réseau de terrain FIP 297 3.3. Interconnexion avec d'autres réseaux Dans les architectures des systèmes automatisés, le réseau de terrain n'est pas toujours le seul réseau et une communication avec d'autres doit être possible. 11 est souhaitable de disposer d'une interface commune afin d'éviter des passerelles compliquées ; ce besoin renforce l'idée de la nécessité de plusieurs profils dans le réseau de terrain [GRA 92], 3.4. Conclusion Il est clair que tous les réseaux se disant réseaux de terrain n’intégrent pas tous les concepts ci -dessus évoqués, pourtant, il est nécessaire aujourd'hui de fournir des services facilitant la distribution des applications ; des services et protocoles comme CCR11, TP1^ le font mais sans prendre le temps en considération. Comme nous le verrons plus loin, la présence de données munies d’une durée de vie souvent très limitée oblige à considérer d'autres solutions. 4. L'architecture d'un réseau de terrain 4.1. Considérations générales Depuis la normalisation du modèle OSI. [ZIM 80] tout système de communication doit y faire référence c’est à dire que chaque constructeur de réseau, quel qu'il soit, aime à dire que son produit est conforme au modèle même quand cela est tout à fait abusif. Mais que signifie être conforme au modèle OSI ? Normalement cela signifie que le réseau en question offre une architecture en sept couches qui sont celles définies par l'ISO. Mais cela ne veut pas dire que dans chacune des couches, les services offerts et les protocoles utilisés sont d'un type donné voire normalisés. Les réseaux de terrain et FIP en particulier ne dérogent pas à la règle et selon une expression consacrée maintenant, il est dit que les réseaux de terrain doivent offrir une architecture en 3 couches selon le modèle OSI "réduit”. Ce modèle a été introduit au milieu des années 80 à propos du projet MAP. Afin de satisfaire des exigences de temps réel, les auteurs de MAP^, qui lui est conforme au modèle à 7 couches, ont estimé que pour accélérer la communication, certaines couches n'étaient pas fondamentalement nécessaires dans certains cas de figure. C'est ainsi que les couches réseau, transport, session et présentation ont disparu du modèle général donnant naissance au modèle réduit composé uniquement de la couche physique, de la couche liaison de données et de la couche application. D faut bien être conscient qu'en supprimant des couches on diminue d'autant le "temps de traversée" de l'empilement des services mais qu'en contre-partie on n'en bénéficie plus. De plus, le problème du temps réel n’est pas seulement un problème de temps de communication mais aussi et surtout dans de nombreux cas, le H CCR Concurrtncy Committment Recovery 12 jp Transaction Processing� 298 Réseaux et informatique répartie. Vol. 3 - n° 3/1993 problème du temps de réponse du ou des processus d'application sollicité(s). Ce temps est évidemment indépendant du nombre de couches traversées. Ce n'est pas parce que on met moins de temps à transmettre ou à recevoir que l’on respecte mieux les contraintes de temps [LeL 89], [ELL 90], [LeL 91]. Pourquoi trois couches et lesquelles ? et quels services ? Quelles sont les raisons pour concevoir un réseau de terrain selon l’architecture à trois couches ? et quels types de service doit-on y trouver pour offrir un aspect temps réel ou temps critique ? Bananms On utilise l'expression "temps critique" comme qualificatif pour exprimer un caractère de criticité du substantif ainsi qualifié si certaine contrainte de temps n'est pas respectée. En particulier une application, une architecture de communication, un service, un protocole pourront être qualifiés de "temps critique", par une mauvaise traduction de "time critical", en particulier avec les travaux du groupe ISO TC184/SC5/WG2-TCCA (Time critical Communication Architecture) [GRA 92}. LEMUG (European MAP Users Group) a énoncé [EMU 89] un certain nombre de spécifications qui devraient être incluses ou prises en compte dans la définition d’un réseau dit temps critique ou d'une architecture temps critique. Ces éléments montrent bien qu’il ne s’agit plus d’édulcorer le modèle OSI pour satisfaire des aspects temporels mais qu’il s’agit aussi d’intégrer des mécanismes et le temps dans le modèle d’un réseau temps critique. N’oublions pas que le modèle OSI est né de l’expérience acquise dans les grands réseaux essentiellement à commutation de paquets et que le temps n'a jamais été pris en compte dans ce modèle. Il serait donc assez paradoxal de vouloir traiter du temps et en particulier respecter des contraintes temporelles en s'appuyant sur un modèle qui n’y fait jamais référence. 4.2. Quelles couches ? Il est clair que la couche physique est nécessaire. On ne peut s'en passer quel que soit le support de transmission utilisé (sauf peut-être à utiliser la transmission de pensée ! et encore ! ! ). La couche de liaison de données est, elle-aussi, nécessaire pour assurer au moins la détection d'erreurs de transmission, et fournir éventuellement une communication fiable entre deux ou plusieurs stations. Elle inclut, comme dans le modèle IEEE 802, la sous couche Medium Access Controi puisqu'on suppose qu’un support est partagé entre les stations connectées. Cette couche, dans les travaux de FIP et des réseaux de terrain en général, n’a pas été spécifiée indépendamment de la couche LLC. La couche réseau et la couche transport ont été introduites dans le modèle OSI pour intégrer le fait que la communication entre deux abonnés passait par des stations intermédiaires ou des noeuds intermédiaires, les commutateurs assurant le routage. Il fallait donc fournir le service de routage des paquets (couche réseau) et assurer un contrôle de bout en bout entre les deux abonnés (couche transport). Ce contrôle de bout en bout est dans l’esprit, du même type que celui qui est offert dans la couche liaison de données. La différence est que ces services s'appliquent à des objets différents : -me trame dans le cas de la couche liaison de� Le réseau de terrain FIP 299 données, un message composé éventuellement de plusieurs paquets (et donc trames) dans le cas de la couche transport. Dans les deux cas, il s'agit d’offrir un service fiable de transmission d’une certaine quantité d'information. Si la couche réseau n'est pas nécessaire, à supposer que le réseau de terrain ne soit pas constitué de sous réseaux, le contrôle de bout en bout de la couche transport peut être toujours nécessaire. En effet, le problème des messages multipaquets (fragmentation et réassemblage) subsiste, qui ne serait pas résolu sans couche transport. Si on fait l'hypothèse de messages courts et que l'on adapte les trames de la couche liaison de données aux plus longs messages possibles, le rôle de la couche transport disparaît totalement. Notons que ne pas considérer de sous réseaux, n'empêche pas d'accepter que le réseau de terrain puisse être formé de plusieurs segments reliés par des ponts [KAC92]et [CRE 91] voire de plusieurs tronçons physiques reliés par des répéteurs. En ce qui concerne la couche session, elle n'apparaît pas nécessaire dans le cas des réseaux de terrain car son rôle dans le modèle OSI trouve son origine dans des échanges de grande quantité d'informations ce qui n'est pas le cas ici. Un minimum de la couche présentation est nécessaire mais peut être implémenté statiquement plutôt que dynamiquement. Ceci signifie simplement qu'on ne décrira pas l'ensemble de la trame à chaque transfert. Par contre on définira chez les abonnés, la syntaxe des objets produits et consommés. La couche application est évidemment nécessaire mais devra être différente des existantes aujourd'hui pour fournir les services requis par la répartition des informations, tâches et contrôle et pour satisfaire des aspects temporels. Au dessus viendront s'ajouter des normes d'accompagnement pour normaliser soit des constituants, soit des fonctions communes à plusieurs constituants. Plus précisément il s'agirait de normaliser la fonction de communication de ces constituants ou le comportement des fonctions vu de la communication. Ceci afin d'améliorer l’interopérabilité des dispositifs, voire assurer ultérieurement l'interchangeabilité d'appareils analogues. On est donc amené à considérer une architecture de communication à deux piles ou deux profils, une architecture de communication non temps critique pour des besoins d'échanges classiques comme dans tout réseau, et une architecture adaptée à la communication présentant des aspects de criticité temporelle. 4.3. Le modèle Producteur-Distributeur-Consommateurs 4.3J. Pourquoi un autre modèle que celui de client-serveur La question était de savoir selon quel modèle les processus d'application allaient coopérer. Le modèle client-serveur bien connu devait-il être repris tel quel ? Plusieurs raisons [THO 89b] nous ont conduits à définir un autre modèle pour répondre aux besoins spécifiques tels qu'énoncés au paragraphe précédent C'est le modèle appelé Producteur- Distributeur- Consommateurs (PDC). Le producteur d’une donnée est un processus d'application responsable de la production de la donnée. Le distributeur des données est un processus d'application qui est responsable du transfert des données du producteur de chacune d'entre elles à tous ses utilisateurs.� 300 Réseaux et informatique répartie. Vol. 3 - n° 3/1993 Les utilisateurs des données sont des processus d'application qui ont besoin des données pour être exécutés. Plusieurs idées directrices ont présidé à l'élaboration de ce modèle. La première est que le principal besoin est l'échange de valeurs de variables ; les seuls services accessibles selon ce modèle sont l'émission et la réception d'objets. Donc les modèles ne mettront en oeuvre que les concepts d'émetteur et récepteur ou producteur et consommateur. De plus il s'agit de rendre les objets produits directement accessibles par les services de lecture/écriture (réception/émission) sans avoir à activer un processus d'application. Il sera alors possible de séquencer les échanges sur le réseau sans avoir à tenir compte des comportements des processus d'applications concernés sous réserve d'indiquer sous certaine forme leur état aux récepteurs des données La seconde est que la plupart des informations doivent être présentes à des instants prédéfinis chez éventuellement plusieurs consommateurs (aspect multipoint des échanges). Ce n'est donc pas à chacun d'eux de demander l'émission par le producteur. Cette fonction sera celle de la distribution. Cette fonction est encore renfoncée par le fait que les activités de plusieurs producteurs doivent pouvoir être synchronisées. Si on appelle transaction de communication l'ensemble des transferts associé à une demande de lecture d'une liste de variables, demande qui peut concerner plusieurs émeueurs, il faut pouvoir ordonner les demandes de transferts élémentaires d'où la notion de distributeur du réseau FIP. La troisième est que dans le modèle client serveur, en l’absence ou retard de la réponse, le client est sans information sur le serveur. La quatrième idée est que les objets ont une durée de vie limitée et qu'il n'est pas utile de considérer les suites de valeurs comme des éléments de file d'attente. Nous aurons donc des mécanismes avec écrasement d'anciennes valeurs par des nouvelles. Ce modèle suppose que les valeurs des objets sont accessibles chez les producteurs par le système de communication et que l'on peut donc ignorer le délai d'élaboration de la réponse à une requête par un serveur. C’est d’ailleurs l'hypothèse sous-jacente du service RDR (Request Data and Reply) du LLC3. 4.3.2. Principes du modèle PDC Trois types de processus cohabitent, les producteurs, le ou les distributeurs et les consommateurs. Un producteur produit localement la valeur d'un objet ; le distributeur déclenche le transfert et la recopie chez les consommateurs, de la valeur originale prise chez le producteur ; les consommateurs utilisent la copie locale de l'objet. Ces processus sont plus ou moins dépendants les uns des autres. Ils peuvent être complètement indépendants, ou être coordonnés de façon étroite, par exemple, produire de façon périodique, transmettre à la même fréquence, et consommer de manière identique, mais toute autre situation peut être définie. Les comportements temporels des divers processus sont définis selon les besoins de l’application. Dans le cas de FIP, des mécanismes de validation temporelle des valeurs d'objets ont été introduits pour permettre aux consommateurs de savoir si les délais impartis au producteur et au distributeur sont ou non respectés.� Le réseau de terrain FIP 301 C'est cette notion d'original et de copies de la valeur d’un objet qui fait parfois dire que FIP est un système réparti de gestion de base de données de terrain (fig 2). Remarques Pour réaliser un comportement du type client serveur, il faut définir un objet porteur de la requête, tel qu'à sa réception, le serveur soit activé, il dépose ensuite le résultat dans l'objet dont il est producteur. Un serveur est donc d'abord consommateur de l'objet requête et producteur du résultat du service. Un client est de son côté, producteur de la requête, et consommateur du résultat. 11 faut toutefois remarquer que le producteur de la requête n’est pas forcément le même que le consommateur du résultat. Plus généralement, on peut implémenter divers services comme "activer une tâche", "arrêter une tâche", avec ce modèle. Le modèle PDC impose de traduire toute demande de service en un objet particulier ou en la valeur d'un objet. Si l’on assimile les consommateurs à des clients vis à vis des objets consommés ou utilisés, le modèle PDC définit la façon dont ces clients seront alimentés par les producteurs de ces objets sans préjuger des comportements des producteurs et consommateurs. Si l’on désire influer ou contrôler le comportement d'un producteur ou d'un consommateur, équivalent d'une demande de service, nous devons définir un ou plusieurs objets qui seront consommés par les processus concernés. Le comportement des processus sera alors le résultat de l'interprétation locale de la valeur de l'objet reçu en particulier si l'on désire démarrer/arrêter un processus à distance, ce processus devra être consommateur d'un objet dont la valeur indiquera l'action à mener. Si ce n'est pas ce processus qui est le consommateur, ce sera un ordonnanceur local. Le producteur de cet objet n'est pas spécifié dans le modèle. Mais l'intérêt est que, si plusieurs processus doivent être démarrés/arrêtés en même temps, comme l’objet en question est transmis selon le modèle PDC lui-même, on peut être sûr qu'en cas de bonne transmission, aux délais de propagation près, les opérations auront lieu en même temps, si les ordonnanceurs locaux n’introduisent pas de délais supplémentaires. On peut considérer ce cas comme réaliste, compte tenu du type de processus implanté sur des capteurs et des actionneurs. Le modèle PDC peut remplacer le modèle client/servcur quand le distributeur connaît les besoins de tout client potentiel.� 302 Réseaux et informatique répartie. Vol. 3 * n° 3/1993 Dans une application autour d'un réseau de terrain, les clients doivent recevoir certaines grandeurs à des instants précis. Ces grandeurs sont répertoriées. Un distributeur peut gérer et séquencer ces transactions. On pourrait en première approximation considérer ce modèle comme proche du modèle client/multiserveurs [DAK 90], restreint aux accès aux variables . Le modèle PDC est avantageux par rapport au modèle client/serveur quand un serveur a plusieurs clients simultanés. Si plusieurs entités normalement clientes d’un même serveur doivent profiter du service au même moment pour des raisons de cohérence, le modèle PDC permet de les satisfaire en une seule transaction. 4.3.3. Application du modèle PDC aux réseaux de terrain Les principaux objets échangés sur un réseau de terrain sont les grandeurs numériques ou booléennes en provenance des capteurs, vers les actionneurs et de variables d'états entre les organes de commande. Exemple : Si nous considérons un régulateur et un capteur, par application du modèle d'architecture fonctionnelle, le régulateur devrait émettre une requête vers le capteur pour obtenir la valeur mesurée comme confirmation. Si nous ajoutons un système de supervision ou un système d’aide à la maintenance, le régulateur usuellement envoie la valeur mesurée vers ces deux autres organes. Si nous utilisons le modèle PDC, nous voyons qu’en une transaction, la valeur mesurée du capteur pourra être transmise au régulateur, au système d’aide à la maintenance et à celui de superviseur. 4.4. Quelles caractéristiques pour les services et protocoles ? Le modèle OSI définit non seulement les sept couches bien connues, mais aussi et surtout, des concepts, des principes, des mécanismes qui peuvent s’appliquer ou être mis en œuvre dans toutes les couches, en tant que élément de service ou de qualité de service, ou de protocole. Les réseaux de terrain, on l'a vu dans les paragraphes précédents se distinguent des réseaux généraux. La question que nous traitons ici est relative à l'adéquation de certains choix aux réseaux de terrain. Les sujets que nous traitons ci-dessous sont bien connus : - transmission en point à point, en multipoint ou en diffusion - service et protocole avec ou sans connexion - protocole avec ou sans acquittement - besoin ou non de contrôle de flux Quelles sont les caractéristiques, les choix judicieux pour un réseau de terrain ?� Le réseau de terrain FIP 303 4.4.1. Point à point vs multipoint vs diffusion Les spécifications des réseaux de terrain et plus généralement des réseaux temps critique nécessitent la diffusion, le multipoint et le point à point. On connaît la difficulté de la mise en œuvre de la diffusion naturelle au niveau de la couche physique, le nombre de publications sur la diffusion fiable en attestant l'intérêt [CRI 85]. Les protocoles actuellement normalisés ne s'intéressent qu'aux communications point à point à part les LLC1 et les LLC3, sans avoir traité le problème de la diffusion fiable. On remarquera seulement que les plus récents travaux de normalisation (en particulier à propos des réseaux de terrain au sein de la CEI), ont conduit l'ANSI à engager de nouvelles réflexions sur les services et protocoles multipoint (ANS 91]. Une question est de savoir si un émetteur a connaissance ou non des récepteurs dans le cas de communication en multipoint. Ce n'est pas nécessaire, ni même possible dans le cas de la diffusion générale, et ce point doit être traité en relation avec le fait qu'une connexion existe ou non. 4.4.2. Protocole avec ou sans connexion On utilise souvent des protocoles avec connexion à différents niveaux du modèle OSI. ACSE1^ définit des associations point à point. Les protocoles usuels de niveau 6 et 5 le font également. Dans le profil MAP seules les couches 2 et 3 sont sans connexion. Les réseaux de terrain nécessitent-ils l'usage de ce principe et sous quelle forme ? A quoi sert une connexion ? Une connexion sert d'abord à permettre aux entités concernées et communicantes de savoir qu'elles sont en relation. Ensuite à négocier certains paramètres qui leur permettront d'adapter leurs comportements (taille de trames par exemple) et qui permettront de réserver ou d'allouer localement des ressources pour assurer le bon fonctionnement des échanges. Ensuite la connexion permet d'assurer un contrôle de flux en fonction des ressources allouées. Dans le cas des réseaux d’intérêt général, quand on ne connaît pas a priori le comportement des abonnés, cette phase est très utile pour ne pas dire indispensable. Dans le cas des réseaux de terrain, on peut considérer que l'on est dans un milieu où n'importe quelle entité ne va pas décider brutalement de communiquer avec n'importe quelle autre. On a connaissance des processus d'application et donc des sites qui sont concernés par, soit l'émission de certaines grandeurs, soit leur réception. Alors pourquoi ne pas réserver des ressources a priori pour satisfaire ces échanges sans obliger les processus concernés à ouvrir une connexion, négocier les paramètres, etc. chaque fois qu'ils veulent communiquer. Ces ressources peuvent être par exemple une file d'attente, comme usuellement dans les protocoles ISO, ou de simples tampons compte tenu du fait que les données ont une durée de vie finie et que l'on peut parfois perdre une information au profit de la suivante. ACSE Association Control Service Elément� 304 Réseaux et informatique répartie. Vol. 3 - n° 3/1993 L’opération de réservation de ces ressources qui ensuite pourraient être allouées de façon permanente ressemble à s'y méprendre à une ouverture de connexion. La fermeture serait alors la suppression de ces réservations. En conclusion sur ce point, on voit que la notion de connexion "permanente" parait bien adaptée à notre cas, situation qu'on peut rapprocher d'autres cas connus comme le circuit virtuel permanent dans X2S. 4.4.3. Protocole avec acquittement ou non La plupart des protocoles usuels utilise l'acquittement (positif, négatif, les deux) avec ou sans anticipation à différents niveaux du modèle OSI. On confond parfois service confirmé et acquittement ; à savoir que l'acquittement ou la réponse à une requête, à sa réception est utilisé pour générer la confirmation de la requête. Une des demandes des utilisateurs de réseaux temps critique est de placer la gestion ou mieux, le recouvrement des erreurs sous le contrôle de l'utilisateur c'est à dire sous le contrôle des processus d'application [EMU 89]. Que faire quand dans une architecture on ne dispose que des 3 couches précitées ? - acquitter au niveau 2 ? au niveau 7 ? à l'un et à l'autre ou nulle part ? La solution est d'abord de tenir compte du type d'échange ou d'une certaine sémantique des informations transmises (événements ou états). Il est clair qu'à ce sujet les habitudes prises ont la vie dure. On ne transmet habituellement dans les réseaux généraux que lorsqu'on a quelque chose à émettre, c'est à dire sur un événement, et ce pour des tas de raisons. Dans les réseaux de terrain, les producteurs de données ont l'habitude d'émettre de façon périodique, que la valeur de l’information ait changé ou non. Ceci est vrai aussi bien pour les capteurs que pour les régulateurs ou les automates. Dans le premier cas où on ne transmet que de façon aléatoire quand quelque événement s'est produit, il est important de s'assurer que la transmission a correctement eu lieu, donc d'attendre du récepteur qu'il dise si tout s'est bien passé ou non. D'où les mécanismes connus d'acquittement, d'attente de réponse pendant un délai donné,etc. Mais combien de temps ces échanges prendront-ils ? Le problème de la sécurité des transmissions se pose autrement quand le récepteur attend quelque chose. Il peut se rendre compte à certains instants que ce qu'il attendait est arrivé ou non. Auquel cas, il prendra les dispositions nécessaires à la situation. Donc, dans les réseaux de terrain, au moins en ce qui concerne le trafic périodique, on peut penser que les acquittements ne sont pas nécessaires. On notera seulement que si une donnée est diffusée toutes les 20 ms, à quoi cela sert-il de demander une réémission sur une erreur de transmission. Bien sûr, si 3, 4 ou 10 fois de suite, l'information est erronée, on devra certainement agir, mais cette action ne peut en aucun cas être confiée au système de communication qui n'en a pas les moyens ; c'est le processus utilisateur qui seul pourra le faire. A cela s'ajoute le fait que gérer des acquittements en mode diffusion (restreinte ou généralisée) peut être très coûteux en charge induite, voire impossible. On verra au paragraphe 5 que FIP n’a pas retenu d'acquittements de niveau liaison de données pour le trafic périodique ou apériodique d'objets identifiés mais uniquement pour la messagerie classique. Toutefois, le mécanisme de cohérence� Le réseau de terrain FIP 305 spatiale est plus performant et fournit à moindre coût en terme de charge, une meilleure qualité de service car indiquant que les informations correctement reçues sont aussi valides temporellement parlant [SIM 90c] et [SON 91a]. 4.4,4. Contrôle de flux Dans les réseaux généraux, le contrôle de flux a été rendu nécessaire par le caractère aléatoire des échanges. Eviter les congestions des stations intermédiaires ou terminales a été une des préoccupations majeures et compréhensible des concepteurs. A partir du moment où les trafics sont mieux connus, où on sait que certaines informations perdent de leur sens au bout d’un temps connu, il faut repenser le problème. C'est pourquoi dans les réseaux de terrain, on peut dimensionner a priori le réseau, compte tenu des contraintes de l'application, de façon à éviter certains types de congestion. Globalement, contrôler le flux revient à : 1 limiter la quantité d’information émise vers le système de communication, 2 organiser et sélectionner les chemins pour ne pas le saturer, 3 prévoir assez de ressources chez les destinataires. Ces solutions sont bien connues des spécialistes de la régulation du trafic automobile. Dans le cas des réseaux de terrain, le point 2 n'a pas de raison d’être si on suppose qu'il n'y a pas deux chemins pour aller d'un point à un autre. Les points 1 et 3 tombent eux aussi quand on considère le trafic de valeurs d'objets entre des tampons à une place et non plus des messages stockés dans des files d'attente. Par ailleurs, le caractère périodique de nombreux échanges contribue à réguler de lui-même le flux. On sait qu'a priori on ne pourra pas dépasser le débit maximum. 5. FIP : architecture, services et protocoles Cette partie est spécialement consacrée à la description de la solution FIP aux problèmes de communication en temps critique dans les réseaux de ten-ain tels qu'ils ont été présentés dans les paragraphes précédents. Il est habituel de présenter un profil de communication par d'abord son architecture puis par les services et protocoles couche par couche. Ici nous présenterons effectivement l'architecture de FIP en nous appuyant sur les normes existantes ou en projet. Dans un deuxième temps, parce qu'il est difficile de classer certains mécanismes dans les couches OSI, nous présenterons les principes de base de FIP, qui sont relativement indépendants des couches de liaison de données et d'application : communication en muitipoint, adressage, tous mécanismes et solutions choisies pour implanter le modèle producteur,distributeur,consommateur. Nous nous limiterons aux services et régies répondant aux besoins de communication avec contraintes de temps, aussi bien au niveau des couches de liaison de données et d'application. Les services innovants de la couche application feront l’objet de la troisième partie de ce paragraphe. Nous ne traiterons pas de la gestion de réseau, ni de la couche physique, ni des travaux en cours sur les nonnes d'accompagnement� 306 Réseaux et informatique répartie. Vol. 3 - n° 3/1993 5.1. L'architecture de FIP L'architecture de FIP est décrite par la figure 3 Figure 3 : Architecture de FIP La norme UTE Pr C46.601 décrit cette architecture [UTE 90a]. La couche physique fait l'objet des normes C46.604, [UTE 90d] et C46.607, [UTE 92b} pour respectivement, le câblage par paires torsadées blindées et pour le câblage en Fibre optique. La norme C46.603 [UTE 90c] définit la couche liaison de données et les nonnes C46.602, [UTE 90b] et C46.606, [UTE 92a] la couche application. La gestion de réseau fait l'objet de la norme C46.605, [UTE 89]. Cette architecture met bien en évidence l’existence de deux profils relativement différents pour les couches application et liaison de données. Dans cette dernière, on trouve d'une part les services associés au trafic d'objets identifiés et d'autre part les services usuels de messagerie ; dans la couche application, on distingue les services MPS qui utilisent les services de transfert d'objets identifiés de la couche deux, des services de type MMS, qui utilisent eux, la messagerie de niveau deux. Cette architecture est en fait constituée d'un profil offrant une certaine qualité de service temporelle (on pourrait dire une architecture temps critique), et d'un profil, plus classique ne présentant pas cette propriété. Les nonnes FIP ne font pas référence à une couche de gestion d’accès au support (Medium Access Control). Toutefois, la fonction est bien présente, et est même spécifiée et en partie modélisée [KAC 92]. Elle est utilisée sans distinction par les deux types de service de la couche LLC. 5.2. Principes de base Les services et protocoles de FIP ont été définis pour satisfaire les besoins spécifiques des processus d'application répartis autour d'un réseau de terrain. La distinction entre services de niveau application et liaison de données pourra parfois paraître artificielle. C'est pourquoi nous regroupons ici des principes communs. La première caractéristique est la communication en multipoint, principe de base imposé par le modèle producteur, distributeur, consommateurs.Le réseau de terrain FIP 307 La seconde caractéristique réside dans l'adressage.On a vu au paragraphe 3.1. que la plupart du trafic était connu, les objets échangés étaient connus ; ce sont les entrées et les sorties des processus d'application. Nous allons utiliser cette propriété J pour définir un adressage peu usité. Chaque objet possède un nom unique et global dans l’application. A titre d'exemple, les variables de pression, de débit, de vitesse, etc. ont toutes un nom différent pour l'application. Chacune de ces variables ou plus généralement, chacun de ces objets a un producteur unique. On utilise le nom de .) l'objet pour distribuer le droit de parole aux stations. C'est ce qu'on appelle l'adressage source. Tout transfert de valeur est réalisé par un échange de deux PDU, une première (notée "ID-DAT, nom de la variable”) pour diffuser le nom de l'objet, une seconde diffusant la valeur (notée "RP-DAT, valeur de la variable") (fig.4). Le distributeur diffuse le nom de l'objet, le producteur qui s’est reconnu, la valeur. Ce sont ces objets qu’on appelle objets identifiés, constituant le trafic identifié. La notion de destinataire ici, n’apparaît pas. Les consommateurs doivent se reconnaître, par le nom de l’objet en diffusion et recopier la valeur au passage.

La PDU de nom représente donc une adresse source qui désigne l’information à émettre et implicitement la station émettrice. Ce principe est aussi bien valable pour la couche application que pour la couche liaison, seuls les objets concernés différent Les objets de la couche application sont les variables des processus d’application. Plusieurs objets de la couche application peuvent être regroupés en un seul objet de la couche liaison pour des raisons d’efficacité. On remarquera que le système FIP utilise la diffusion au niveau physique, au niveau liaison et aussi au niveau application. Ces principes de base s'appliquent que les échanges soient périodiques ou pas. Se pose alors le problème de la sécurité des échanges. Les acquittements conventionnels étant prohibés compte tenu des spécificités (cf §3), il n’y a pas d'acquittement au niveau liaison pour le trafic identifié. Seul le trafic dit de messagerie autorise les acquittements. Pour l'accès au support, la solution est bien évidemment la même. La différence tient au fait que la trame de valeur contient� 308 Réseaux et informatique répartie. Vol. 3 * n° 3/1993 l'adresse du destinataire, et qu'un champ de contrôle précise s’il s’agit d'un échange avec ou sans acquittement. Notons toutefois que le service dit de cohérence spatiale est un acquittement de groupe et de niveau application [SON 91a]. Etudions la fonction de distribution et l'arbitrage de bus. Dans le modèle producteur- distributeur-consommateurs, la fonction de distribution a la responsabilité de déclencher les échanges entre producteur et consommateurs. Certains de ces échanges doivent avoir lieu dans un ordre établi, éventuellement périodiquement et sans déphasage, d'autres sur demande. Comment gérer ces deux types de trafic ? La solution retenue aujourd'hui dans FIP repose sur un distributeur centralisé. D'autres solutions pourraient être envisagées, citons par exemple les protocoles ARINC [ARI92] dans un autre domaine. Le distributeur est aussi souvent appelé arbitre de bus. Pourtant, on peut distinguer les deux fonctions. L'arbitrage de bus est une spécificité de niveau deux. Medium Access Control, la fonction de distribution représente plutôt les services de niveau application. La notion de distribution est liée en fait aux services de lecture de liste de variables et de cohérences temporelles et spatiale. On pourrait envisager d'autres implantations du même modèle avec d'autres protocoles de niveau MAC. Trafics périodique et apériodique Les algorithmes de contrôle, de conduite, de surveillance étant définis et construits de façon à être exécutés de façon essentiellement cyclique, on connait statiquement quels sont les objets dont ils ont besoin en entrée, quels objets sont produits et ont besoin d'être échangés. Il est à noter que cette nomenclature se répétera cycliquement, conférant au réseau FIP la fonction principale de scrutation périodique d'états. Si le trafic périodique laisse du temps libre, ces intervalles pourront être utilisés pour le trafic aléatoire. D'autres besoins conduisent à définir des mécanismes permettant de construire d'autres trafics, et notamment le trafic aléatoire d'objets identifiés ou de messagerie.

Figure 5 : Demande de droit de parole � Le réseau de terrain FIP 309 Il peut s'agir d’objets appartenant déjà au trafic périodique ou d’objets identifiés non soumis au trafic périodique. Aujourd'hui la gestion de ce trafic est réalisée par l’arbitrage de bus. Une demande de trafic aléatoire émane forcément d'un producteur de données, qui, quand on lui donne la parole, en profitera pour éventuellement demander d'autres droits (le service de niveau LLC est L-UPDATE (nom de variable) et se traduit par indication notée RQ dans le champ contrôle de la trame RP-DAT, cf fig 5). Ces demandes sont prises en compte par l'arbitre de bus, qui distribue les droits supplémentaires en fonction du temps laissé libre par le trafic périodique considéré prioritaire. Il est clair que le choix de classer certains échanges dans le trafic périodique ou dans l’apériodique, dépend fondamentalement de l'application et de la conception de la solution. Ceci n'est pas défini dans les normes. Des modèles toutefois, permettent d'évaluer a priori les performances temporelles d'une application [SON 91b], [SIM 90a,b], 5.3. La couche application Les services de MPS On l'a vu dans l'architecture (§ 4.1), la couche application contient deux éléments de service : MPS pour Messagerie Périodique et apériodique, et un sous ensemble de MMS . Nous ne traiterons pas ici de la partie relevant de MMS. Notons seulement que la norme UTE C46.606 a prévu une sous couche dite MCS pour résoudre le problème de l'absence des couches intermédiaires comme dans FAIS ou mini MAP. Le principe de base de FIP consiste à garantir que tous les processus d'application où qu'ils soient, sur quelque site que ce soit, doivent avoir la même vue de l'état du système. C’est pour cela que le modèle productcur-distributeur- consommateurs a été introduit (cf §4). Le modèle producteur-distributeur-consommateurs dissocie la production des données de leur transfert et de leurs utilisations par les consommateurs. Ce principe consiste, rappelons le, à déclencher, par une fonction de distribution, un échange entre un producteur et des consommateurs ; d'une part, sous réserve de bon fonctionnement, tous les processus reçoivent les mises à jour en même temps(au délai de propagation près) ; d'autre part le distributeur scande les échanges permettant ainsi de garantir certaines propriétés temporelles. Nous allons détailler ici d'abord les services associés à la gestion d'objets simples, puis nous étudierons celle des listes d'objets. 5.3.7. Services associés à des variables simples Les services de la couche application sont ceux de lecture et d’écriture de valeurs de variables. Ces variables peuvent être de type simple : entier, flottant, booléen, chaîne de caractères, ou de type structuré : tableau, liste. Ces services sont soit strictement locaux, soit des opérations distantes.

Le réseau de terrain FIP 313 5.3.1.4. Validation temporelle des valeurs En reprenant le modèle producteur-distributeur-consommateur, trois opérations, production, transfert, et consommation se déroulent normalement dans cet ordre. Toutefois, pour de multiples raisons connues ou inconnues, plusieurs productions successives peuvent se succéder sans transfert, le même exemplaire d'un objet peut être transféré plusieurs fois, et un consommateur peut consommer plusieurs fois le même exemplaire, ou ne pas avoir le temps de consommer tous les exemplaires reçus. Entre ces trois opérations, deux intervalles de temps sont caractéristiques : entre production et transfert, entre transfert et consommation. Les contraintes de temps s'expriment partiellement sur ces intervalles. Il faut donc qualifier temporellement les valeurs pour permettre de vérifier leur "fraîcheur" et savoir si les délais entre production et consommation ne sont pas hors limites. Des informations booléennes associées aux variables échangées renseignent l'utilisateur sur la validité des données produites et consommées. Ces informations sont les promptitudes et les rafraîchissements. Rafraîchissement Les statuts de rafraîchissement sont élaborés par la couche application de l'entité productrice. Un statut de rafraîchissement, lorsqu’il possède la valeur VRAI, indique à un utilisateur consommateur que le producteur de l'information a respecté un délai de production appelé période de production. L'entité de communication manipule alors une information atomique de la forme <statut, valeur variable>. V _F Rafraîchissement

tj début de chaque période Pi instants de production. Figure 10 : Exemple de rafraîchissement� 314 Réseaux et informatique répartie. Vol. 3 - n° 3/1993 Promptitude

Les statuts de promptitude sont élaborés par les entités de communication utilisatrices. Un statut de promptitude, lorsqu'il possède la valeur VRAI, indique à un utilisateur consommateur que la variable considérée a été rafraîchie par le réseau en respectant la contrainte de temps, par exemple la période de transmission (ou de distribution). tj instants prévus de réception R instants réels de réception. Figurel 1 : Exemple de promptitude Ces attributs de rafraîchissement et de promptitude sont attachés au respect d'un délai ; plusieurs cas de figure ont été envisagés pour déterminer le début de ces délais. On dispose ainsi de statuts dits synchrones quand le début d'un délai coincide avec la réception d’un objet particulier dit "variable de synchronisation". Les statuts sont dits asynchrones quand le début du délai est défini par la fin de l'opération précédente. Les automates de ces mécanismes sont décrits dans [UTE 90b]. 5.3.1.5. Services de synchronisation Un processus asynchrone est un processus dont l'exécution est indépendante du comportement du réseau. Mais on peut attacher certains processus à des événements de communication, c'est ainsi que la réception ou l'émission d'une variable sont des événements typiques permettant la synchronisation de processus. Un processus est dit synchronisé quand son exécution est liée à une indication de réception ou d'émission en provenance du réseau. Les processus qui composent une application peuvent être synchronisés ou asynchrones. Certains processus d’application ne supportent que le mode de fonctionnement asynchrone en particulier certains capteurs ou actionneurs. Un� Le réseau de terrain FIP 315 mécanisme de resynchronisation leur permet de participer à une application répartie synchronisée.

Le mécanisme de resynchronisation associe un deuxième tampon à une variable au niveau de la couche d'application. Le tampon privé sera exclusivement accessible par le processus d'application. Il y accédera à l'aide de lectures ou d’écritures locales asynchrones. Le tampon public ne sera accessible que par le réseau. Accès Synchrone Figure 12 : Mécanisme de resynchronisation Le mécanisme de resynchronisation consiste à transférer le contenu d'un tampon dans l'autre, en fonction d'ordres de synchronisation provenant du réseau. Ces ordres de synchronisation sont les Top de Positionnement pour les variables consommées resynchronisées et les Top de Photo pour les variables produites resynchronisées. 5.3.2. Services associés aux listes de variables La couche application offre un service de lecture de listes de variables simples. L’utilisateur a alors la possibilité de lire un ensemble d'informations composé des valeurs des variables de la liste. La couche application offre des informations similaires sur les listes, offrant ainsi aux processus application utilisateurs de la liste, des informations de cohérence de production, de cohérence de transmission et de cohérence spatiale de données. 5.3.2.1. Cohérence temporelle de production Le statut de cohérence de production est une information booléenne élaborée par la couche application, et renseignant le processus application utilisateur du respect d’une période de production par les producteurs des variables de la liste. Les producteurs doivent tous élaborer un statut de rafraîchissement, et leurs périodes de� 316 Réseaux et informatique répartie. Vol. 3 - n° 3/1993 production doivent être identiques. La cohérence de production est une cohérence temporelle. Le processus application utilisateur, lorsqu’il manipulera les valeurs des variables de la liste, saura si globalement tous les producteurs ont respecté la période de production qui leur est affectée. Le statut de cohérence aura la valeur VRAI lorsque tous les statuts de rafraîchissement des variables composant la liste seront vrais. Ce statut correspond à un ET logique entre les différents statuts de rafraîchissement. 5.3.2.2. Cohérence temporelle de transmission Le statut de cohérence de transmission est une information booléenne élaborée par la couche application, et renseignant le processus application utilisateur du respect par le réseau d'une mise à disposition de l'ensemble des variables de la liste dans un temps inférieur à leurs périodes de distribution respectives. La cohérence de transmission est une cohérence temporelle. Le processus application utilisateur de la liste saura, à l'aide du statut de cohérence de transmission si le réseau a respecté les périodes de distribution de chacune des composantes de la liste. Le statut de cohérence de transmission est obtenu en effectuant un ET logique entre tous les statuts de promptitudes. 5.3.3. Cohérence spatiale Optionnellement, un statut de cohérence spatiale d'une liste peut être élaboré au niveau d'une couche application. Ce statut indique lorsqu'il possède la valeur VRAI, que toutes les instances d'une même liste consommées par plusieurs utilisateurs sont identiques. Ce mécanisme d'élaboration s'appuie sur la diffusion par chaque entité consommatrice d’une variable de cohérence associée à une liste de variables.. En reprenant l'exemple du § les entités Automate, Opérateur et Régulateur sont utilisatrices de la liste < Débitl, Pressionl, Débit2, Pression2 >. Le statut de cohérence spatiale indiquera chez chaque utilisateur de la liste si les différentes copies de cette liste consommée sont identiques. La loi de composition permettant l’évaluation du statut de cohérence spatiale et un ET logique sur toutes les valeurs des différentes instances de variables de cohérence individuelles. La collecte des statuts de cohérence permet aux consommateurs d'indiquer si la liste est correcte, et complète, mais aussi de réclamer la réémission de tout ou partie de la liste. C’est en ce sens que ce mécanisme est aussi un moyen performant d'acquittement groupé des échanges élémentaires entre les différents producteurs et chaque consommateur [SON 91a].� Le réseau de terrain FIP 317 6. Conclusion Dans cet article nous avons essayé de présenter FIP de la façon la moins formelle possible, en montrant que les réseaux de terrain ne peuvent pas être construits à partir des mêmes considérations que les réseaux généraux. L'histoire a permis de montrer l'importance de la prise en compte des besoins des utilisateurs dans la définition des services. Les points les plus importants sont certainement tous ceux qui contribuent à qualifier temporellement les comportements des processus. Us peuvent être repris dans d'autres contextes pour satisfaire des besoins analogues. Ces points sont essentiellement les mécanismes de cohérence autour du concept de distribution, la technique d'acquittement global, qui introduit une nouvelle approche de la sécurité des transmissions. Mais surtout, en dehors de toute considération de techniques protocolaires, FIP est une des bases essentielles des futures générations d’architectures des systèmes automatisés. Les projets déjà cités, DIAS en particulier, montrent bien l'intérêt des capteurs et actionneurs intelligents et ouvrent la voie à de nombreux développements et innovations. La multiplication des annonces de produits "fipés" ces derniers mois montrent bien que la voie est maintenant largement ouverte. Cette disponibilité de nouveaux produits va permettre de nouvelles expérimentations non seulement industrielles mais aussi dans les laboratoires où certains travaux de recherche sont en cours. Nous ne citerons que quelques sujets actuellement abordés au sein de notre équipe, la synchronisation d'horloges [HE 90] [HE 93], l'impact sur les systèmes de production de programmes et sur les architectures futures des applications [LAI 91] [SIM 92], architectures validées, voire certifiées, interopérables, aux constituants interchangeables, etc, mais cela relève d'une autre histoire. Remerciements L’auteur tient à remercier tous ceux qui ont contribué à quelque titre que ce soit à cette épopée exemplaire dans l'histoire des relations industrielles et universitaires, en premier lieu, tous les participants de la première heure, dont beaucoup ont été cités ci-dessus, et en particulier ses collègues du sous groupe qui a défini FIP : Messieurs COUR (GIXI), DANG (IMAG/CNET), DUBY (COMSIP), GALARA (EDF), LE GAULAIS (CONTROLE BAILEY), MICHEL (CNET), PEINTURIER (CGEE), POWELL (LAAS), TAILLEBOIS (MCB), avec Messieurs BERTHOUMIEUX et DESJARDINS qui ont su créer le milieu et les conditions de la réussite. Merci aussi, à Françoise HUMBERT-BONNE qui a assuré tout le secrétariat de FIP de 1982 à 1991, à Ahmed TANTAWY pour son aide aux débuts de cette aventure, puis à Jean Pierre BARDINET qui en 1988, découvrait FIP en organisant le premier stand FIP pour l'exposition Mesucora, à Philippe LETERRŒR et toute l'équipe du centre de compétence FIP. Merci aussi aux collègues de 1ENSEM et en particulier à Françoise SIMONOT pour leur aide et coopération tout au long de cette démarche et de cette décennie. Merci enfin à tous ceux qui dans les divers groupes de travail ont défini dans le détail les services et protocoles de FIP et écrit les versions successives des normés, avec une mention toute spéciale pour Jean Pierre LOBERT dont la compétence, le dévouement et le charisme ont grandement contribué au succès de cette entreprise.� 318 Réseaux et informatique répartie. Vol. 3 - n° 3/1993 Enfin, l'auteur remercie vivement les lecteurs anonymes dont les remarques ont permis d'améliorer la première version de cet article. Bibliographie [AGU 89] M.W.C. De AGUILAR. Analise comparativa de desempenho da camada enlace de dados do PROFIBUS e do FIP. Université de Santa Calanna, Florianopolis, Brésil, 1989. [ARI92] ARINC 659, Draft of project paper 659 Backplane Data Bus, may 1 1992, Aeronautical radio inc, 2551 Riva Road, Annapolis, Maryland 21401. [AYA 83] J.M. AYACHE. Protocoles de transport en temps réel. Note interne Groupe FIP RLI 1983. [CEG 90] CEGELEC. FIP STARTER KIT Note d'utilisation CEGELEC Clam art. 1990. fCOC78] A.COCHET MUCHY. La production de programmes dans le projet Sygare. Thèse de Docteur-Ingénieur, INPL, NANCY, 19/8. (COC81) A. COCHET MUCHY, J.P. THOMESSE. Compiling distributed applications. Microprocessing and Mictoprogramming vol.7 - 1981 - pp 13-19. [COU 83a] J..M. COUR. Note préliminaire. FIP 000, Emetteur récepteur pour bus FIP Note d'orientation Groupe FIP RU. 04/05/83. [COU 83b] J.M. COUR. FIP Le concept de système de développement. Note d'orientation Groupe FIP RU. 27/08/83. [CRE 91) D. CREUSOT, J.P. ELLOY, S. KACHKACIII, J.P.THOMESSE. Interconnexion de réseaux : FIP-FIP et FIP-MAP, Actes du Colloque A2RP, MRT, PARIS 15-16 Jan 1991. [CRI 85] F. CRISTÏAN, H. AGHIU, R. STRONG, D. DOLEV. Alomic broadeast : from simple message définition lo byzantine agreemenl, Proc FTCS 15, Ann Arbor, Michigan, 1985, pp 200-206. [DAK 90] Y. DAKROURY. Spécification et validation d'un protocole de messagerie multi-serveurs pour l'environnement MMS. Thèse de Doctoral. Université de NANTES. 1990. (DAN 84] M. DANG. Elude de la complexité du circuit FIP 001 et des possibilités CAO de circuits intégrés. Note interne Groupe FIP RLI. 15/02/84. [DAN 86] M. DANG, G.MICHEL. Spécifications fonctionnelles du composant FIP capteurs. Note CNET15/04/86. [ELL90] J.P.ELLOY. Les contraintes du temps réel dans les systèmes industriels répartis. Journée SEE Grenoble, 6 juin 90. [EMU 89] Européen Map Users Group. User reauirements for communications in rime critical applications. Feb89, réf ISO/TC 184/SC5/WG2-N18Ô. [FAN 92] D. FANTONI. G. TEDESCO, S. CANCIAN, R. FERTINO. L'application de FIP sur le site pilote industriel de la Centrale ENEL de Piombino. Actes de la Conférence Automation, CETIM Ed., Paris, 1992. (FIP 84] FIP Spécifications préliminaires du composant FIP-001 Note interne FIP RU 1984. [GAL 82} D. GALARA. Besoins fonctionnels en communication dans les systèmes de contrôle/commande. Note interne Groupe FIP RLI 1982. (GAL 84) D. GALARA, J.P. THOMESSE. Groupe de réflexion FIP. Proposition d'un système de transmission série mulliplexée pour les échanges d’informations entre des capteurs, des actionneun et des automates réflexes. Ministère de l'Industrie et de la Recherche, mai 1984, 56 pages. Réédité par Editions KIRKI991. [GAU 85) M. GAULT, J..P. LOBERT. Contribution for the fieldbus standard, Présentation IEC/TC65/SC65C/WG2 1985. .� Le réseau de terrain FIP 319 [GRA 92] K. GRANT Users Requirements on Time Critical Communications Architectures. Technical Report ISO TCI 84/SC5/WG2/TCCA . April 1992. [HE 90] J. HE, Z. MAMMERI, J.P. THOMESSE. Clock synchronization in real-time distributed Systems based on FIP fieldbus. 2nd IEEE Woikshop on Future Trends of Distributed Computing Systems. Cairo, 1990, pp. [HE 93] J. HE. Modélisation des algoritmes de synchronisation d'horloges physiques, Thèse de 1TNPL, Nancy, Juillet 1993. [INT 90] Workshop on Fieldbus. FIP and PROFIBUS. Colloque SYSTEC90, München, Allemagne, 1990. [KAC 92] S. KACHKACHI. Interconnexion de réseaux FIP, simulation d'un pont. Diplôme supérieur de formation des ingénieurs par la recherche et la technologie. INPL, NANCY, 1992. [LAD 82) P LADET. Contribution à l'étude des systèmes informatiques répartis pour la commande des procédés industriels. Thèse d'état INPG, Grenoble 1982. [LAI 91) T. LAINE. Modélisation d'applications réparties pour la configuration automatique d'un bus de terrain. Thèse de doctorat de 1TNPL, NANCY, 1991. [LAN 82] M. LANCIAUX, J.M. COUR, P. ROLLIN. Estimation du marché des réseaux locaux industriels en 1982. Note interne Groupe FIP RLI 30/11/82. [LEJ 82) M. LEJON Le bus de transmission. Note interne Groupe FIP RLI 22/10/82. [LeL 83a] G. LE LANN. Compte rendu de la réunion du groupe RU TIR Note interne Groupe FIP RU .25/02/83. [LeL 89] G. LE LANN. Critical issues in distributed real time computing. Workshop on Communication networks and distributed operating sysrtcms, Oct 24-26, 1989. [LeL 91] G.LE LANN. Designing real lime dependable distributed Systems, Rapport INRIA n°1425. Avril 1991. [LET 90] P. LETERRIER, T. VALENTIN. FIP TOOLBOX Note d'utilisation Centre de compétences FIP. NANCY 1990. [LET 90] P. LETERRIER, J.P. THOMESSE. Fff-Concepts, services et protocoles. Revue Générale d'Electricité, Juillet 1990, pp 17-25. [LOB 88] J.P. LOBERT. FIP à Revin, film 16 mm, durée : 9 mn 45 Première expérimentation de FIP sur un site industriel, réalisé par J.P. Lobert EDF-DER Clamait, 1988. [MAM 85] Z. MAMMERI. Conception des applications réparties en commande de procédés industriels, une approche par la structuration des données. Thèse de doctorat de l'INPL Nancy, Juin 1985. (MEN 76] H.G. MENDELBAUM. Structuration dans la conception et la réalisation des systèmes en temps léel.Thèse de Doctorat d’état, PARIS 6.1976. [MPM 91] MultiPeer/MultiCast Workshop, Organised by U.S.Army and the Institute for simulation and training of University of Florida, Orlando Aug 6-8 1991. (MUT 89] P. MUTSCHLER. Open system for communication in machine tools. EPE Conf, Aachen, Germany, 1989. [NON 78a] P NONN. Le système d'exploitation dans le projet Sygare. Thèse de Docteur-Ingénieur, INPL, NANCY, 1978. [NON 78b] P. NONN, J.P. THOMESSE. Le système d'exploitation dans le projet Sygare. Congrès AFCET, PARIS, Nov 1978. [PER 851 G.R. PERRIN. La communication : un outil pour la spécification, la construction et la vérification de systèmes parallèles. Thèse de Docteur d'état, NANCY, 1985.� 320 Réseaux et informatique répartie. Vol. 3 - n° 3/1993 (POW 83] D R. POWELL. Quelques réflexions sur la sûreté de fonctionnement du réseau local industriel FIP. Note LAAS 83024 .06/05/83. [ROL 84] P. ROLJN. Redondance du gestionnaire de nomenclature Note interne Groupe FIP RU 01/06/84. (SIM 90a] F.SIMONOT, Y.Q.SONG, J.P.THOMESSE. Approximate method for performance évaluation of message exchange in fïeldbus FIP. 4th International Conférence on Data Communication Systems and their Performances, Barcelona, June 1990, pp 358-374. fSIM 90b] F. SIMONOT, Y.Q. SONG, J.P. THOMESSE. Queuing Analysis of Message Exchange in Fieldbus FIP, IMACS-IFAC International Symposium on Mathematical and Intelligent Models in System Simulation, Brusells, 3-7 sept. 1990, pp VI-B1.1/VI-B1.7. (SIM 90c) F. SIMONOT, Y.Q. SONG, J.P. THOMESSE. Reliabilily of Time Criiical Multicast Communication. IECON'90, 16lh Annual Conférence of IEEE Industrial Electronics Society, Asilomar, Californie, 27-30 nov. 90, pp 517-521. (SIM 92] Fse SIMONOT, C. VERUNDE. Importance d'un cadre de référencedans la mise en place d’une démarche de déveioppementd'un système automatisé de production. Actes de la conférence canadienne sur l'automatisation industrielle, Montréal, Canada, Juin 1992. (SON 91a] Y.Q. SONG, P. LORENZ, F. SIMONOT, J.P. THOMESSE. Multipeer/multicast Proiocols for Time-Crilical Communication. Multipeer/multicast workshop, Orlando (USA), 6-8 August 1991. [SON91b| Y.Q. SONG. Etude de performances de FIP, aide au dimensionnement d'applications. Thèse de Doctorat INPL, NANCY, 1991. (SOU 82] M. SOUTTF. Rapport sur l'Industrie des Instruments de Mesure, Ministère de la recherche, PARIS, 1982. [THO 78a] J.P. THOMESSE, A. COCHET-MUCHY, P. NONN. Data Flow Analysis for the Description and Management of Synchronisation in Real Time Applications. IFAC/IFIP Workshop Real Time Programming, June 1978, Mariehamn/Aland - Finlande. [THO 80] JP. THOMESSE. SYGARE : une structuration pour la conception d'applications en temps réel et réparties. Thèse de Doctorat d'état INPL NANCY. 1980. [THO 86a] J.P. THOMESSE, M. RODRIGUEZ. FIP, A Bus for Instrumentation. Advanced seminar on Real Time Local Area Networks. Colloque INRIA Bandol 1986. [THO 89b] J.P. THOMESSE, P. NOURY. Communication models. Client-server vs Producer- Distributor-Consumers. Contribution ISO TC 184/SC5/WG2-TCCA,oct 89. [THO 90a) JP. THOMESSE. Les réseaux locaux à temps critique. Colloque Le Temps Réel, Nantes, oct 1990. pp29-40. [THO 90b] J.P. THOMESSE. Time Critical Applications and Time Critical Communications, Contribution ISO/TC184/SC5/WG2 - TCCA, mars 90. [UTE 89a] UTE NF C46-605 Norme expérimentale déposée en décembre 1989 • Bus FIP pour échange d'informations entre transmetteurs, actionneurs et automates • Gestion de réseau. Nouvelle version normalement prévue en juin 1993. (UTE 90a] UTE Projet de norme C46-601. Architectures du réseau de terrain FIP. [UTE 90b] UTE NF C46-602 - Norme homologuée en avril 1990 - Bus FIP pour échange d'informations entre transmetteurs, actionneurs et automates - Couches application - Service périodique et apériodique. [UTE 90c] UTE NF C46-603 - Norme homologuée en juin 1990 - Bus FIP pour échange d'informations entre transmetteurs, actionneurs et automates - Couche liaison de données. [UTE 90d] UTE NF C46-604 - Norme homologuée en mai 1990 - Bus FIP pour échange d'informations entre transmetteurs, actionneurs et automates • Couche physique en bande de base sur paire torsadée blindée.� Le réseau de terrain FTP 321 [UTE 92a] UTE NF C46-606 Norme expérimentale déposée en février 1992. Bus FEP pour échange d'informations entre transmetteurs, actionneurs et automates - Couche application • Services de Messagerie. [UTE 911 UTE NF C46-6CT7 Norme homologuée en mai 1991 - Bus FIP pour échange d'informations entre transmetteurs, actionneurs et automates - Couche physique en bande de base sur fibre optique. [ZIM 80J H. ZIMMERMANN, OSI référencé model. The ISO model of architecture for open System interconnection, IEEE Trans. COM-28 n°4, April 80, pp 425-432.