Réseaux Locaux Industriels

Réf.
: S7574 V1
Réseaux locaux industriels -

Date de publication :
10 juin 2004
Concepts, typologie,
caractéristiques
Cet article est issu de : Automatique - Robotique | Automatique et ingénierie système
par Jean-Pierre THOMESSE
Résumé Cet article présente les concepts des différents Réseaux locaux industriels RLI,
et surtout leurs utilisations. Pour commencer, le modèle OSI, référence réglementaire,
est abordé, puisque ses concepts s'appliquent à tout type de réseau. Puis les
architectures des différents réseaux, leurs domaines d'application et les profils
d'utilisation correspondants sont détaillés.
Pour toute question :

Service Relation clientèle
Techniques de l’Ingénieur
Immeuble Pleyad 1 Document téléchargé le : 16/01/2024
39, boulevard Ornano
93288 Saint-Denis Cedex Pour le compte : 7200092269 - cerist // 193.194.76.5
Par mail :
infos.clients@teching.com
Par téléphone :
00 33 (0)1 53 35 20 20 © Techniques de l'Ingénieur | Tous droits réservés
Ce document a ete delivre pour le compte de 7200092269 - cerist // 193.194.76.5
Réseaux locaux industriels

Concepts, typologie, caractéristiques
par Jean-Pierre THOMESSE
Professeur à l’École nationale supérieure d’électricité et de mécanique (ENSEM)
1. Réseaux et modèle OSI........................................................................... S 7 574 – 2

1.1 Réseau, réseau local, réseau local industriel ............................................ — 2
1.2 Modèle de référence OSI de l’ISO .............................................................. — 3
1.3 Conclusion.................................................................................................... — 7
2. Systèmes automatisés............................................................................ — 7
2.1 Architectures de systèmes et réseaux locaux industriels ........................ — 8
2.2 Domaines d’application .............................................................................. — 9
2.3 Architectures des applications.................................................................... — 10
3. Réseaux locaux industriels.................................................................... — 14
3.1 Types de coopération .................................................................................. — 14
3.2 Qualité de service ........................................................................................ — 17
3.3 Architectures des réseaux locaux industriels............................................ — 17
4. Conclusion ................................................................................................. — 20
Bibliographie ...................................................................................................... — 20
es réseaux locaux industriels ! « La littérature est prolifique sur le sujet. Les

L
Parution : juin 2004 - Ce document a ete delivre pour le compte de 7200092269 - cerist // 193.194.76.5
journaux professionnels l’abordent régulièrement pour annoncer de nou-

veaux produits, publier des études comparatives selon des critères variés et plus
ou moins précis, faire le point sur la normalisation. Les sigles de plus en plus
nombreux ne rendent pas plus claire la situation et de nombreuses questions se
posent sur l’intérêt de tel ou tel réseau, sur ses capacités, son adéquation à un
problème donné d’un utilisateur final. On y rencontre des expressions comme
réseau local d’entreprise, réseau local industriel, réseau temps réel, réseau de
terrain, réseau de cellule, réseau de salle de commande, réseau d’usine, réseau
Ethernet, réseau MMS, réseau MAP, TOP, FIP, PROFIBUS, MODBUS, SERCOS,
Mini-MAP, MAP-EPA, etc. En fait de quoi s’agit-il ? »
Telle était l’introduction de la précédente édition de cet article. Depuis, quel-
ques sigles de réseaux ont disparu, mais on pourrait y ajouter de nombreuses
« normes », qui ne correspondent souvent qu’à des produits très propriétaires,
voire à des tentatives de normalisation qui ont échoué. CEI 61158, EN 50170,
EN 50254, CEI 61375, ISO 15745, EN 50325, EN 50295, CEI 62026, ARINC, Safe-
bus, TTP/A et TTP/C, FlexRay, TCN, WTB, MVB sont entre autres de nouveaux
sigles, de nouveaux noms qui enrichissent les articles [S 7 574], [S 7 575] et
[S 7 576]. L’interrogation « de quoi s’agit-il ? » est toujours, sinon plus, d’actua-
lité. En effet, l’Internet et le Web ont explosé, l’accent économique a essentielle-
ment porté sur le multimédia, le téléphone, la musique, la vidéo, tous ces
médias sur les réseaux numériques. Et ces technologies, aujourd’hui, viennent
encore enrichir les choix possibles dans les réseaux industriels. Mais aussi les
besoins de réseaux n’ont cessé de croître et certaines solutions industrielles ont
investi d’autres domaines comme les systèmes embarqués, la domotique avec
de plus en plus d’équipements dits intelligents, avec les applications de télémé-
decine à domicile, toutes applications qui relèvent des réseaux locaux indus-
triels et qui seront étudiées ici.
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur S 7 574 − 1
tiwekacontentpdf_s7574 v1 Ce document a ete delivre pour le compte de 7200092269 - cerist // 193.194.76.5

RÉSEAUX LOCAUX INDUSTRIELS __________________________________________________________________________________________________________
Notre ambition est de clarifier la situation de tous les réseaux locaux indus-
triels (RLI) ou embarqués, en introduisant les concepts et les critères adéquats
pour permettre au lecteur de situer les différents réseaux les uns par rapport aux
autres mais surtout par rapport aux besoins. C’est pourquoi nous préciserons
d’abord la notion de réseau et de réseau local en nous appuyant sur le modèle
de référence OSI, dont les concepts peuvent s’appliquer à tout réseau, qu’il soit
public, local, industriel, domotique ou embarqué, puis la différence entre réseau
local d’entreprise et réseau local industriel, même si dans les deux cas, certains
protocoles peuvent être identiques.
Pour comprendre la variété des réseaux (mais aussi leurs similitudes), nous
étudierons les architectures des applications dans les différents domaines
considérés comme « industriels » et nous terminerons par l’étude des caractéris-
tiques des réseaux industriels.
1. Réseaux et modèle OSI 1.1.2 Réseau local
Un réseau local couvre une zone géographique limitée sur un

1.1 Réseau, réseau local, réseau local domaine privé, par opposition aux réseaux publics ou longue
distance, ce qui a permis dans les années 1980 de choisir des
industriel protocoles indépendamment des organisations des PTT de
l’époque.
Plusieurs articles ont déjà été consacrés aux réseaux et réseaux
locaux [H 1 418], [S 8 140], [S 8 160] ; nous ne reprendrons pas ici ce
qui peut donc y être trouvé, mais nous introduirons simplement les Parmi les réseaux locaux, on distingue souvent les réseaux locaux
compléments nécessaires, avant de traiter les RLI à proprement parler. d’entreprise [2] (§ 1.1.4) et les réseaux locaux industriels (§ 1.1.3). Ils
diffèrent essentiellement par les contraintes d’environnement
Le terme « réseau » a de nombreuses utilisations et significations. (temps et sûreté de fonctionnement) et par certains services et pro-
En plus des expressions déjà citées dans l’introduction, il désigne tocoles mis en œuvre pour tenir compte des différences de besoins
aussi bien : des applications qui les utilisent.
— un support de transmission (un réseau en fibre optique, un
réseau radio ou plus généralement un réseau sans fil, wireless

network en anglais) ; 1.1.3 Réseau local industriel
— un type de transmission de niveau physique (un réseau en
bande de base) ;
— un protocole de gestion des accès au support (un réseau Ether- Un réseau local industriel est en première approximation un
net ou un réseau à jeton) ; réseau local utilisé dans une usine ou tout système de produc-
— un ensemble de protocoles de niveau transport/réseau (un tion pour connecter diverses machines afin d’assurer la com-
réseau TCP/IP) ; mande, la surveillance, la supervision, la conduite, la
— des profils, c’est-à-dire une pile d’un ensemble de services et maintenance, le suivi de produit, la gestion, en un mot, l’exploi-
protocoles (un réseau MAP, un réseau WorldFIP, un réseau Profi- tation de l’installation de production.
bus). Notons tout de suite que dans MAP, TOP, WorldFIP, le « P »
signifie protocole alors qu’il devrait signifier profil ; nous revien-
drons sur ce sujet à la fin de ce paragraphe. Mais l’aspect connexion de machines, même s’il est fondamental,
n’est pas le seul à considérer. Ce sont surtout les processus d’appli-
cation répartis sur les machines qui sont mis en relation par les
1.1.1 Réseau réseaux. Et ce sont ces relations qui dicteront le choix d’un réseau
plutôt que d’un autre. Les besoins en communication sont alors très
diversifiés selon les matériels connectés et les applications qu’ils
Un réseau est un ensemble de moyens qui permettent la com- supportent, ce qui explique que les réseaux locaux industriels sont
munication entre des processus d’application (ou tâches) répar- nombreux et variés. Il est évident que le trafic entre des capteurs,
tis sur des matériels informatiques de tout type. Cet ensemble des actionneurs et des automates n’est pas le même qu’entre un
est constitué d’au moins un support de transmission pour système de CFAO et un contrôleur de cellule de fabrication. Les
l’acheminement des signaux et de protocoles de communica- besoins diffèrent selon des critères comme la taille des données à
tion selon une architecture en couches conforme ou non au transmettre, les contraintes de temps associées, les coûts accepta-
modèle OSI (Open System Interconnection) [1] [H 1 418]. On bles de connexion, les technologies qu’il est possible de mettre en
parle parfois de système de communication pour désigner un œuvre. Il sera donc nécessaire d’étudier globalement les architectu-
réseau. res des systèmes automatisés pour analyser en détail les divers
types de communication et classer les réseaux locaux industriels
Nota : on dit souvent qu’un réseau connecte des machines, ce qui est une réalité, mais (§ 2.1). Pour satisfaire tous ces besoins, de très divers protocoles ont
en fait, c’est surtout pour permettre la communication entre les tâches qui s’exécutent sur été définis depuis les années 1980, certains ont été normalisés,
les machines. Et en ce sens, un réseau connecte des processus d’application. Cette nuance
est importante car les caractéristiques des processus conditionnent le choix du réseau qui d’autres sont devenus des standards de fait, d’autres enfin sont
les interconnecte. purement privés.
S 7 574 − 2 © Techniques de l’Ingénieur

_________________________________________________________________________________________________________ RÉSEAUX LOCAUX INDUSTRIELS
Nota : on retrouvera des caractéristiques voisines dans des systèmes autres que ceux les réseaux temps réel plus en détail et de façon comparative, étu-
de production, par exemple dans la domotique, ainsi que dans les systèmes de transport
(trains, automobiles). Nous reviendrons sur ces sujets dans le paragraphe 2.2.
dions d’abord les concepts de base de la communication qui servi-
ront de référence. Ces concepts sont définis dans le modèle OSI
(Open Systems Interconnection – Basic Reference Model, ISO 7498)
1.1.4 Réseau local d’entreprise de l’International Organization for Standardization (ISO).
Alors que les réseaux locaux industriels sont utilisés par les
processus déclenchés selon l’état des machines et par les événe-
1.2 Modèle de référence OSI de l’ISO
ments survenant dans leur environnement, les réseaux locaux
d’entreprise sont utilisés au final par des êtres humains. Les uti-
lisateurs de réseaux locaux d’entreprise, du point de vue techni- 1.2.1 Origine du modèle
que, sont les stations de travail, les terminaux, les micro-
ordinateurs et les serveurs qui leur sont connectés. Mais devant Afin de simplifier la définition des normes de communication, en
ces matériels sont des êtres humains qui décident ou non d’utiles situant les unes par rapport aux autres, l’ISO a lancé en 1977 un
liser leur outil de travail et le réseau en fonction de ce qu’ils ont projet de définition d’un modèle de référence pour l’interconnexion
à faire. de systèmes ouverts appelé simplement « modèle OSI » ou
« modèle de référence OSI » [1]. La version finale du modèle OSI
date de 1984. Il a été défini à partir des expériences dans les réseaux
En considérant dans une entreprise les services de gestion du per- publics, mais a dû ultérieurement être adapté aux réseaux locaux.
sonnel, de gestion des stocks, des approvisionnements, de la comp-
tabilité, tous interconnectés par un réseau, chacune des personnes de Un système est dit ouvert lorsqu’il permet la communication
ces services crée du trafic de façon non concertée et donc aléatoire. entre équipements de types différents, pouvant provenir de cons-
De tels réseaux doivent offrir des services adaptés pour chaque sorte tructeurs différents, pourvu que ces équipements respectent les
d’utilisation : accès à des fichiers ou des bases de données distantes règles de communication dans un environnement OSI. Les règles de
et partagées, accès à tout type d’application informatisée, impression communication sont publiques, accessibles à tous. Et inversement,
d’états, messagerie intraentreprise et interentreprise, et ils doivent un système est dit privé lorsqu’il ne permet la communication
être dimensionnés pour supporter tous les utilisateurs simultanés en qu’entre des équipements d’un même type ou d’un même construc-
leur offrant des temps de réponse acceptables. Mais surtout, on ne teur, en utilisant des protocoles qui sont la propriété de quelqu’un.
peut pas faire d’hypothèses sur les comportements des uns et des Nous considérons aussi comme privés les systèmes multiproprié-
autres pour définir des services et/ou des protocoles particuliers, ce taires dans lesquels on peut accéder à des spécifications privées
qui conduit à établir des mécanismes de communication suffisam- moyennant des accords avec les propriétaires. On qualifie parfois
ment généraux pour satisfaire toutes les sortes de besoins. Les tech- ces systèmes de « propriétaires » (en anglais : proprietary). On dit
nologies de l’Internet et du Web ont investi ce domaine. aussi parfois que ces systèmes sont fermés, mais en fait, ils ne le
sont jamais complètement.
1.1.5 Réseau temps réel

1.2.2 Couches du modèle OSI
Un réseau temps réel est capable de fournir des services Le modèle OSI constitue un cadre de référence pour l’intercon-
contraints par le temps. nexion de systèmes ouverts hétérogènes. Il s’agit d’un modèle pour
élaborer des normes d’interconnexion et de coopération de systè-
Une communication étant un phénomène indéterministe, il est mes répartis. Il est construit selon une structure en sept couches
utopique de penser créer des réseaux temps réel à comportement dont chacune correspond à un type de préoccupation ou à un type
purement déterministe. Au mieux, on pourra seulement garantir de problème à résoudre pour pouvoir communiquer (figure 1).
que les contraintes de temps seront respectées avec une certaine L’idée de base de la structure en couches est, comme dans d’autres
probabilité. Il sera alors important que le réseau puisse signaler à domaines, de pouvoir à chaque interface supérieure ignorer le plus
ses utilisateurs (les processus d’application) si une contrainte a été possible ce qui se passe en dessous. Le modèle est applicable à
respectée, ou ne l’a pas été, ou mieux, qu’elle ne pourra pas l’être. toutes les catégories de réseaux. Nous rappelons brièvement le rôle
Tous les réseaux dits industriels ne sont pas pour autant temps réel. de chaque couche. Tous les détails peuvent être trouvés dans de
nombreux ouvrages, par exemple [5]. Nous reviendrons sur le sujet
Mais nous verrons aussi qu’un réseau temps réel doit assurer des dans [S 7 575] pour analyser les principaux services et protocoles
trafics contraints par le temps et des trafics non contraints selon les typiques des réseaux locaux industriels, d’autant que les aspects
besoins des applications et qu’il vaudra mieux parler de profils temporels n’apparaissent pas dans le modèle.
temps réel ou non que de réseaux temps réel ou non. Nous revien-
drons sur ce sujet ultérieurement. Les sept couches initiales du modèle sont rappelées sur la
Nota : l’expression « temps réel » étant aussi employée pour des systèmes transaction-
figure 1.
nels, on utilise parfois l’expression « temps critique » comme qualificatif pour exprimer un
caractère de criticité, si une certaine contrainte de temps n’est pas respectée. En particulier,
Les couches 1, 2, 3 et 4 se préoccupent du transport d’informa-
une application, une architecture de communication, un service, un protocole, pourront tions et masquent aux couches supérieures les problèmes liés à la
être qualifiés de « temps critique », par une mauvaise traduction de time critical..., en par- communication d’informations entre des équipements distants. Les
ticulier à la suite des travaux du groupe ISO TC184/SC5/WG2-TCCA (Time Critical Commu- couches 5, 6 et 7 fournissent des services d’accès à la communica-
nication Architecture) [3]. L’EMUG (European MAP Users Group) a énoncé [4] des
spécifications qui devraient être incluses ou prises en compte dans la définition d’un tion pour différents types d’applications.
réseau dit temps critique ou d’une architecture temps critique.
La couche physique 1 adapte les signaux numériques au sup-
Ces définitions très informelles ne permettent que d’appréhender port de transmission.
le sujet. Remarquons tout de suite que certains services et protocoles
La couche liaison de données 2 fiabilise les échanges de don-
utilisés pour les réseaux locaux d’entreprise pourront l’être aussi
nées entre deux stations.
pour les réseaux locaux industriels, mais qu’ils ne pourront l’être tels
quels pour des réseaux temps réel. Nous avons déjà utilisé de nom- La couche réseau 3 assure la recherche d’un chemin et l’achemi-
breuses fois certains termes comme services et protocoles, sans les nement des données entre les stations terminales dans un réseau
avoir définis. Pour pouvoir analyser les réseaux locaux industriels et maillé.

La couche application a aussi été structurée avec l’expérience.

Utilisateur A Utilisateur B Des développements parallèles de protocoles ont montré que des
services communs pouvaient et même devaient (pour faciliter
l’ouverture) être définis d’une seule façon, ce qui a conduit à la
Protocole norme ISO 9545.
7 Application Application
d'application Le modèle OSI n’est pas seulement une architecture en couches, il
introduit aussi des concepts qui peuvent être appliqués à la plupart
des couches.
Protocole
6 Présentation Présentation
de présentation
1.2.4 Concepts du modèle OSI
Protocole
5 Session Session
de session Le modèle OSI définit non seulement les sept couches bien con-
nues, mais aussi et surtout des concepts, des principes, des
Protocole mécanismes qui peuvent s’appliquer ou être mis en œuvre a priori
4 Transport Transport dans toutes les couches. Les sujets que nous traitons ci-après sont :
de transport
— les notions de service et de protocole (§ 1.2.4.1) ;
Protocole
— les transmissions en point à point, en multipoint ou en diffu-
3 Réseau Réseau sion (§ 1.2.4.2) ;
de réseau
— les communications avec connexion ou non (§ 1.2.4.3) ;
— les protocoles avec ou sans acquittement (§ 1.2.4.4) ;
Liaison de Protocole Liaison de — le contrôle de flux (§ 1.2.4.5).
2 données données
de liaison D’autres principes ou règles comme l’adressage ne seront pas
étudiés ici, car ils intéressent plus les concepteurs de protocoles que
Protocole les utilisateurs. Il suffit de supposer qu’un processus d’application
1 Physique Physique
physique sache désigner son ou ses correspondants sans regarder comment
la désignation et l’adressage sont réalisés. Nous verrons (§ 3) pour-
quoi certains choix sont faits selon les protocoles des réseaux
Médium Médium locaux industriels.
1.2.4.1 Services, protocoles et profils

Figure 1 – Modèle OSI
■ Un service de niveau N (noté service (N ) ou en anglais N-Service)
est une fonction offerte par la couche (N ) à la couche (N + 1), acces-
La couche transport 4 assure le contrôle de bout en bout entre sible par une ou des primitives de service.
les stations terminales. Les unités de données associées à une demande de service de la
La couche session 5 synchronise et gère les échanges pour le couche (N + 1) et reçues par une couche (N ), sont appelées des
compte de la couche présentation. « unités de données de service (N ) » (N SDU ou N Service Data

La couche présentation 6 permet d’accepter des syntaxes diffé- Unit).
rentes pour les données échangées entre les couches application. Un service est dit confirmé quand la demande de service doit être
La couche application 7 donne aux processus d’application le suivie d’une confirmation d’exécution qui peut avoir diverses origi-
moyen d’accéder à l’environnement OSI. Elle n’a pas de limite supé- nes, en particulier la couche homologue distante (figure 2).
Nota : seule la sémantique des primitives de service est en général normalisée. Si la
rieure, c’est-à-dire que l’on peut toujours ajouter des services syntaxe elle-même l’est, on parle de norme d’interface. Il n’en existe quasiment pas.
supplémentaires construits sur des services existant déjà.
La gestion de réseau est un ensemble de fonctions de paramé- ■ Un protocole de niveau N (noté protocole (N ) ou en anglais N-
trage, de configuration, d’exploitation et de surveillance pour per- Protocol) est un ensemble de règles de codage, de coopération et
mettre le bon fonctionnement du réseau. d’échanges entre deux (ou plus) entités de niveau N pour fournir les
services (N ). Ces règles définissent d’une part le format des infor-
mations échangées, d’autre part l’enchaînement de ces échanges.
1.2.3 Extensions du modèle OSI On appelle PDU (N ) (unité de données de protocole ou Protocol
Data Unit) tout bloc d’informations échangé entre deux entités (ou
L’émergence des réseaux locaux et plus généralement les études plus) de même niveau N. Certaines de ces PDU contiennent de
de nouveaux protocoles, en particulier de la couche application, ont l’information « utile », c’est-à-dire provenant de processus d’appli-
conduit à découper ou à structurer ces sept couches. cation, d’autres non, mais sont nécessaires à l’accomplissement du
protocole, ou autrement dit au respect des règles définies.
Une couche de gestion d’accès au support de transmission (en
anglais, Medium Access Control ou MAC) est apparue entre la cou- Une PDU (N ) est composée soit uniquement d’informations de
che physique et la couche liaison de données. Elle permet de gérer contrôle du protocole (N ), dites N-PCI (Protocol Control Informa-
le droit d’émission des stations connectées à un support partagé par tion), soit de données venant du niveau (N + 1) et de PCI (N ).
plusieurs. Une SDU (N ) est donc combinée avec des informations de con-
Dans ce cas, la couche liaison a été renommée par l’expression de trôle du niveau N, pour former une unité de données du protocole
contrôle logique de liaison (en anglais, Logical Link Control ou LLC). (N) qui sera passée au niveau (N − 1) sous forme de SDU (N − 1) et
Cette extension de l’architecture initiale est connue sous le nom de ainsi de suite jusqu’au niveau le plus bas (le niveau physique).
IEEE 802 du nom du groupe de travail qui l’a créée. ■ Liens entre modèle OSI, services et protocoles : pour
La couche réseau a elle-même été structurée en trois sous- récapituler les notions vues ci-avant, il faut se rappeler que le
couches pour faciliter les interconnexions de réseaux locaux et les modèle OSI n’est qu’un ensemble organisé de concepts et qu’il
connexions de réseaux locaux avec les réseaux publics (voir la n’implique aucun service ni aucun protocole particulier. Il ne définit
norme ISO 8648). qu’un cadre fonctionnel et de conception qui précise les problèmes

Utilisateur Fournisseur Utilisateur Utilisateur Fournisseur Utilisateur

de services de services de services de services de services de services
Demande Demande
Indication Indication
Réponse
Confirmation Confirmation
a requête avec réponse b requête sans réponse

(service confirmé par le correspondant) (service confirmé par le fournisseur)
Utilisateur Fournisseur Utilisateur Fournisseur Utilisateur

de services de services de services de services de services
Demande Demande
Indication
Confirmation
c requête sans réponse d requête/indication

(service confirmé localement) (service non confirmé)
Fournisseur Utilisateur Utilisateur Fournisseur

de services de services de services de services
Indication Requête
e indication locale f requête sans suite Figure 2 – Services confirmés

et non confirmés
à résoudre (les couches) et les concepts utilisables pour construire vices (N − 1) insuffisants, il est parfois nécessaire de compléter les
des solutions. Les notions de service et de protocole sont définies spécifications ou de créer une « couche » intermédiaire pour adap-
indépendamment de la couche concernée. Un service pour une cou- ter les besoins exprimés au niveau (N ) aux services disponibles au
che donnée (N ) est normalement d’abord défini en fonction des niveau (N − 1). Enfin, on notera que la qualité de service est le
besoins et en second lieu le protocole (N ) l’est. Il faut noter que moyen de quantifier la façon dont les services sont rendus. Nous
pour une même couche, on peut concevoir plusieurs services diffé- reviendrons sur ce sujet dans le paragraphe 2.
rents. Et un service donné peut être réalisé de diverses façons, c’est-
à-dire par différents protocoles. Il est toutefois clair que les entités ■ Définition des profils : un profil est un ensemble choisi de servi-
communicantes dans un réseau doivent non seulement offrir les ces et de protocoles organisé en couches selon le modèle OSI (ou un
mêmes services, mais aussi respecter le même protocole, sans quoi autre) de telle sorte que des besoins particuliers de communication
il n’y a plus de dialogue possible. soient satisfaits. La définition d’un profil procède de deux
approches :
Un protocole (N ) peut être conçu indépendamment des services
(N − 1), c’est un des principes d’abstraction du modèle OSI. Mais — l’une ascendante qui consiste à considérer d’abord les besoins
quand il doit être effectivement construit en s’appuyant sur des ser- et les contraintes au niveau des supports de transmission, des

débits nécessaires, des distances, des perturbations dues à l’envi-

ronnement, puis d’en déduire la couche physique adaptée, le MAC, Entité N Entité N
le LLC, en fonction de la qualité requise, etc. ;
— l’autre consiste à prendre le problème par la couche applica-
tion, et donc définir quels sont les besoins fonctionnels pour les pro-
cessus de l’application considérée ; on en déduit les services
nécessaires des couches inférieures. La convergence se situe au
niveau de la couche transport. On traite des exemples réels de pro-
fils de réseaux locaux industriels dans l’article [S 7 576].
La notion de profil est importante car, pour que des équipements
puissent communiquer, il faut que toutes les couches de leur profil Figure 3 – Connexion bipoint de niveau N
offrent les mêmes services et protocoles avec des options identi-
ques ou compatibles quand elles existent. C’est la première condi-
tion pour qu’ils soient qualifiés d’interopérables. L’interopérabilité
diffusion ou en multipoint au niveau de la couche application alors
ou l’interfonctionnement est une propriété qui exprime le fait que
que les seules communications possibles au niveau physique sont
des équipements sont capables de coopérer. La première condition
en point à point. Il faudrait alors émettre autant de fois que néces-
est bien qu’ils puissent communiquer, donc qu’ils possèdent le
saire le même message.
même profil de communication.
Une question est de savoir si un émetteur a connaissance ou non
Exemple : on peut comparer l’empilement des services et proto- des récepteurs dans le cas de communication en multipoint. Ce
coles à un jeu de Lego dans lequel toutes les briques ne respecteraient n’est pas nécessaire, ni même possible, dans le cas de la diffusion
pas la même norme pour être encastrées les unes dans les autres. générale, et ce point doit être traité en relation avec le fait qu’une
Elles peuvent alors posséder des plots différents. Une brique du jeu connexion existe ou non.
dispose de plots mâles à son interface supérieure et de plots femelles
à son interface inférieure. Pour pouvoir empiler deux plots, il est
nécessaire que des plots mâles soient complètement compatibles 1.2.4.3 Connexion et communication avec ou sans
connexion
avec des plots femelles. Considérons la construction d’un mur en
N plots. Si N = 7, le mur est une image du modèle OSI. Les plots mâles Dans le langage courant, parler de deux entités connectées signi-
d’une brique (I) représentent alors les services fournis par la couche (I). fie qu’elles sont reliées par un support de communication ou
La brique symbolise le protocole (I) qui permet de fournir les services qu’elles sont branchées sur un même support. On retrouve cette
offerts par l’interface supérieure en s’appuyant sur ceux de l’interface définition quand on parle du niveau physique du modèle OSI. Par
inférieure. Si on ne dispose pas de briques (I) qui offrent des plots extension, on va définir le concept de connexion de niveau N entre
femelles compatibles avec les plots mâles d’une brique (I − 1), il faut deux couches de niveau N. C’est ainsi qu’on peut définir une con-
construire une brique interface, comme on le fait actuellement quand nexion de niveau 2, de niveau 3, 4, etc. On peut assimiler une con-
on a des prises de courant non compatibles. nexion à un canal logique de niveau N par lequel passeront les PDU
(N ) (figure 3).
1.2.4.2 Point à point, multipoint, diffusion L’établissement d’une connexion (N ) est demandé par la couche
■ Une communication de niveau N est dite point à point ou bipoint (N + 1), négocié entre deux entités de couche (N) en passant par la
quand deux entités de couche (N ) seulement sont considérées (pri- couche (N − 1). La notion de connexion de niveau N est indépen-
maire/secondaire ; émetteur/récepteur ; puits/source ; demandeur/ dante de la nature des niveaux N + 1 et N − 1.
répondeur ; client/serveur ; producteur/consommateur ou À quoi sert une connexion ? Une connexion sert d’abord à per-
publisher/subscriber ; agent/manager). mettre à deux ou plusieurs entités communicantes de savoir
Le primaire désigne l’entité qui prend l’initiative de la communi- qu’elles sont présentes et en relation avant d’échanger des informa-
cation, le secondaire l’autre. Un message donné est produit par un tions. Ensuite, elle sert à négocier certains paramètres qui leur per-
producteur, émis par un émetteur ou la source, reçu par le récepteur mettront d’adapter leur comportement (taille maximale des blocs
ou le puits, utilisé par un consommateur. Un demandeur ou client échangés, par exemple) et de réserver ou d’allouer localement des
(ou encore agent) est celui qui requiert un service, le répondeur ou ressources (tampons, files d’attente pour stocker les messages en
serveur (ou encore manager) celui qui fournit le service. attente d’émission ou de réception) pour assurer le bon fonctionne-
ment des échanges. Ensuite, la connexion permet éventuellement
■ Une communication est dite multipoint quand plus de deux enti- d’assurer un contrôle de flux en fonction des ressources allouées.
tés de niveau N sont concernées (un émetteur/K récepteurs). Dans le cas des réseaux généraux, comme on ne connaît pas a priori
le comportement des abonnés, cette phase est très utile pour ne pas
■ Une communication est dite en diffusion quand toutes les entités dire indispensable, car on ne sait pas à l’avance qui veut communi-
connectées de niveau N sont concernées par l’information (un quer avec qui. C’est comme dans le cas du téléphone par opposition
émetteur/tous les autres récepteurs). On appelle parfois diffusion au fax. Le téléphone nécessite que les deux abonnés soient présents
restreinte une communication multipoint. en même temps, le fax non. En ce sens, le téléphone est avec con-
Certains supports de communication conjugués avec des topolo- nexion des utilisateurs, le fax sans connexion des utilisateurs, mais
gies de bus, d’anneau, permettent la diffusion naturelle au niveau de des terminaux.
la couche physique. Mais on connaît la difficulté d’usage de cette dif- Si deux entités doivent communiquer par une connexion, il fau-
fusion naturelle au niveau des couches supérieures, le nombre de dra d’abord l’ouvrir, c’est-à-dire créer ce canal. Un premier échange
publications sur la diffusion fiable en attestant l’intérêt [6] [7] (com- consiste alors à transmettre une PDU d’ouverture et à attendre la
ment être sûr que tous les récepteurs ont bien reçu la même infor- réponse de l’entité à qui l’on a demandé la connexion. Durant la
mation). phase d’établissement de connexion, les deux entités désirant com-
Il est important de noter que ces concepts, naturellement évidents muniquer négocient les paramètres de gestion de la connexion. Si
au niveau de la couche physique, s’appliquent à toutes les couches l’une des deux entités ne peut pas communiquer (elle est hors ser-
du modèle, un support de transmission qui permet la diffusion phy- vice, elle ne peut pas prendre en compte les paramètres de gestion
sique supposée sans erreur : toute trame est reçue par toutes les de connexion demandés par son correspondant...), la demande de
couches physiques, puis par toutes les couches MAC, puis si l’adres- connexion échoue. Une fois la connexion établie, le dialogue peut
sage le permet, par toutes les couches LLC, ou par un sous-ensem- avoir lieu jusqu’à ce que l’une des entités demande l’arrêt, c’est-à-
ble, etc. À l’inverse, on pourrait définir un service et un protocole en dire la fermeture de la connexion.

Cela nous amène à distinguer trois phases dans le cycle de vie 1.2.4.5 Contrôle de flux
d’une connexion logique : établissement de la connexion, transfert
de données et déconnexion (ou terminaison de la connexion). Le contrôle de flux est une fonction, elle aussi indépendante de la
Le modèle OSI a été prévu pour accueillir des services et protoco- couche considérée, qui permet à un récepteur d’asservir la vitesse
les avec ou sans connexion. Selon que l’on utilise ou non la notion ou le débit de l’entité émettrice correspondante. Ce mécanisme per-
de connexion, on parle de modèle connecté (ou modèle avec con- met d’informer l’émetteur sur la quantité d’informations que le
nexion) et de modèle non connecté (ou modèle sans connexion). récepteur l’autorise à émettre. En l’absence d’un contrôle du flux
Toutefois, les premiers services normalisés ISO utilisaient essentiel- relatif aux unités de données émises par une source, les tampons
lement le principe de la connexion puis, devant l’apparition de nou- réservés par le destinataire peuvent se remplir (à moins de faire
veaux besoins et de nouvelles technologies (réseaux locaux en l’hypothèse d’une mémoire de réception infinie) et certaines unités
particulier), des services et protocoles sans connexion ont été intro- de données risquent alors d’être rejetées à la réception. Pour éviter
duits. à une source de continuer à émettre des données qui seront rejetées
par le récepteur, un mécanisme de contrôle de flux doit être mis en
Le choix d’un modèle connecté ou non dépend des besoins de place.
l’utilisateur. Dans une couche donnée, on peut combiner les deux
mécanismes offrant ainsi à la couche supérieure les deux types de Globalement, contrôler le flux revient à :
services selon les besoins. Le modèle sans connexion est le plus
simple et le plus facile à implanter, mais offre une moindre qualité — limiter la quantité d’information émise vers le système de
de service. communication ;
— organiser et sélectionner les chemins quand cela est possible
1.2.4.4 Contrôle d’erreurs et acquittements pour ne pas saturer le réseau ;
Étant donné l’imperfection des voies de transmission, les unités — prévoir assez de ressources chez les destinataires.
de données de niveau N émises par une source n’arrivent pas
Nota : ces solutions sont bien connues des spécialistes de la régulation du trafic auto-
nécessairement toutes à destination sans erreur. Il peut y avoir alté- mobile.
ration d’une ou de plusieurs unités de données que le récepteur doit
détecter grâce à des codes détecteurs et rejeter, en informant ou
non l’émetteur selon que le protocole choisi utilise ou non des
acquittements.
1.3 Conclusion
Un acquittement est une information de contrôle du protocole,
émise par un récepteur qui permet d’informer l’émetteur que les
informations ont été correctement reçues ou non. Il est qualifié de
positif quand il indique que le message est correctement reçu, néga- Le modèle OSI est la référence pour étudier et comparer différents
tif dans le cas contraire. Un protocole avec acquittement positif uni- réseaux. Nous en avons présenté les principaux concepts. Les choix
quement n’indique pas les messages erronés. C’est l’absence de services possibles dans une couche sont multiples. Et les choix
d’acquittement dans un délai déterminé qui est alors interprétée par de protocoles encore plus nombreux. La notion de profil est primor-
l’émetteur comme un acquittement négatif. D’autres protocoles sont diale pour assurer l’interopérabilité des équipements. C’est elle qui
complètement sans acquittement. nous permettra de présenter de façon homogène les différents
réseaux locaux industriels.
Ce mécanisme permet à une source de données de recevoir les

acquittements (positifs ou négatifs) et de savoir quelles unités de
données il faut retransmettre en cas d’erreur de transmission. Diffé-
rentes techniques de contrôle d’erreurs peuvent être utilisées :
l’acquittement à chaque PDU, ou l’acquittement par séquences de
plusieurs PDU, qui permet à l’émetteur d’envoyer un nombre prédé-
2. Systèmes automatisés
fini et négocié de PDU sans avoir à attendre un acquittement. Cette
dernière technique a été introduite au niveau de la couche liaison
avec les réseaux à longue distance pour améliorer le débit réel Dans les architectures de systèmes automatisés, on distingue
(nombre de PDU transmises par unité de temps). habituellement les réseaux suivants : réseau de terrain, réseau de
cellule, réseau d’usine. Mais que se cache-t-il derrière ces
La technique d’acquittement est indépendante du niveau consi- dénominations ? D’abord, une sorte de classification hiérarchique
déré. On pourrait définir des protocoles avec ou sans acquittement des appareils et équipements et une évolution historique. Un réseau
à chaque niveau. Toutefois, ce sont les protocoles des niveaux de terrain connecte les capteurs et actionneurs aux automates,
liaison et transport qui possèdent habituellement ces possibilités. contrôleurs et régulateurs, puis le réseau de cellule connecte les
Les mécanismes d’acquittement permettent d’assurer une sorte de automates à un coordinateur, les coordinateurs étant eux-mêmes
contrôle de flux. connectés par un réseau d’usine aux services comme les bureaux
d’études, de méthodes, la gestion, les approvisionnements. Mais on
On confond parfois service confirmé et acquittement ; on dit verra que du point de vue des services, des protocoles et des carac-
qu’un service (N − 1) est confirmé quand la couche (N ) attend téristiques du modèle OSI, cette classification n’est pas suffisante
une information (notée confirmation) signalant si sa demande car un réseau d’un profil donné peut être utilisé à différents endroits
de service a été traitée ou prise en compte. La confirmation peut dans l’architecture.
être positive ou négative, voire retourner un résultat autre que Après avoir rappelé les principaux concepts OSI (§ 1), analysons
booléen. les réseaux locaux industriels du point de vue de leur place et de
Une confirmation est un service de la couche (N − 1) à la leur rôle dans les systèmes automatisés. La dernière décennie du
couche (N ) d’une entité de communication. Un acquittement de XXe siècle a connu des développements importants, tant de pro-
quelque niveau que ce soit (N ) est une PDU d’une entité (N ) duits que de normes. Un bref historique (voir encadré) aidera à com-
vers une autre entité (N ). Il arrive souvent que la réception prendre pourquoi il y a une telle floraison de produits aujourd’hui.
d’une PDU d’acquittement soit interprétée pour générer la Après avoir analysé les applications et identifié les services que les
confirmation d’une requête antérieure. réseaux locaux industriels doivent fournir, nous étudierons com-
Un service est dit non confirmé quand aucune réponse à une ment les caractéristiques des réseaux s’appliquent aux différents
requête n’est prévue. réseaux locaux industriels.

2.1 Architectures de systèmes et réseaux Historique

locaux industriels
Les réseaux locaux industriels ont été introduits petit à petit dans les
systèmes automatisés, à des stades divers selon les domaines d’applica-
2.1.1 Types de réseaux locaux industriels tion. Ils sont nés avec le développement de l’électronique et des maté-
riels numériques programmables. L’apparition des régulateurs
numériques et des automates programmables a conduit les offreurs à
Les réseaux de terrain connectent les capteurs, les actionneurs et mettre sur le marché des réseaux pour les interconnecter et rapatrier à
les dispositifs comme les automates, les régulateurs et plus généra- moindre coût de câblage les informations nécessaires à la conduite par
les opérateurs dans les salles de commande. C’est ainsi qu’est né le
lement tout matériel supportant des processus d’application ayant réseau WDPF de Westinghouse (commercialisé par Jeumont Schneider
besoin d’avoir accès aux équipements de terrain. Ils doivent offrir au en France) dans les années 1970. Ce réseau était essentiellement utilisé
minimum les mêmes services que les systèmes d’entrées-sorties dans les processus continus, les premiers à être automatisés et à innover
industriels, mais d’autres très importants, de synchronisation par dans les nouvelles technologies de l’automatique et de l’informatique
industrielle. Puis est né le réseau MODBUS (MODicon BUS) de Gould
exemple, seront aussi définis pour faciliter la distribution des appli- Modicon, pour coordonner les activités sises sur plusieurs automates.
cations. Dans les processus continus, des calculateurs dits d’optimisation étaient
utilisés de longue date pour envoyer des consignes sous forme d’aides
Les réseaux de cellule , parfois appelés réseaux intermédiaires, aux opérateurs. Il est apparu utile de les connecter d’une part aux sta-
connectent dans une cellule ou un atelier les dispositifs de com- tions de travail des opérateurs et d’autre part aux équipements qui pilo-
mande de robots, de machines-outils, de contrôle de la qualité tent les machines de production. Le grand développement des réseaux
(lasers, machines à mesurer). Ces réseaux se rencontrent essentiel- locaux industriels date du début des années 1980. Le projet MAP naît aux
États-Unis [S 7 576], la notion de réseau de terrain émerge sous le nom
lement dans les industries manufacturières. de réseau ou bus d’instrumentation en 1982 avec la naissance du projet
WorldFIP en France [8] [9].
Les réseaux de salle de commande , dans les processus continus, Parallèlement à ces projets de réseaux ouverts, donc ayant vocation à
ramènent aux opérateurs les informations qui leur sont nécessaires devenir des normes internationales, en l’absence de normes, et devant
pour conduire le processus et qui leur permette de fixer les points l’intérêt croissant des réseaux, de nombreux réseaux locaux industriels
de consigne, ou divers paramètres pour les régulateurs et automa- voyaient le jour chez tous les constructeurs et chez des offreurs indépen-
tes. Ils connectent des automates, des systèmes numériques de dants. En France, la société Gixi sortait Gixinet, issu d’un brevet français
sur l’accès à un bus par une technique à jeton. La société Apsis proposait
contrôle-commande, des systèmes de supervision, etc. les premières versions du réseau FACTOR. La société Compex construi-
sait le réseau LAC. Les constructeurs d’automates programmables pro-
Les réseaux d’usine irriguent l’ensemble de l’usine, interconnec- posaient (la liste est loin d’être exhaustive) Sinec (Siemens), Data
tant des ateliers, des cellules avec les bureaux d’études ou des Highway (Allen Bradley), Tiway (Texas Instrument), Unitelway (Télémé-
méthodes, avec les services administratifs, commerciaux et finan- canique), Jbus (April), Sycoway (ex-CGEE-Alsthom). Les premières ver-
ciers de l’entreprise. sions de ces réseaux fournissaient essentiellement les services suivants :
— le rapatriement d’informations vers des postes de commande
Comment tous ces réseaux sont-ils utilisés ou organisés dans un centralisée ;
système automatisé de production ? Le paragraphe suivant l’expli- — la lecture et l’écriture de variables ;
— le démarrage ou plus généralement la gestion de programmes ;
que à partir de la notion d’architecture opérationnelle. — leur téléchargement ;
— quelques fonctions de service que l’on placerait maintenant dans la
gestion de réseau.
2.1.2 Architecture opérationnelle Certains de ces réseaux peuvent être considérés comme les ancêtres
des réseaux de terrain. Chaque constructeur choisissait son profil à partir
de normes existantes dans les couches basses et définissait des services

et protocoles que l’on peut qualifier d’application, adaptés à ses clients et
L’architecture opérationnelle est l’organisation d’un système à ses marchés.
automatisé, résultat des étapes de spécification et de concep- Ces réseaux utilisaient certains des protocoles développés pour les
télécommunications avec quelques adaptations aux contextes de réseau
tion, quelle que soit la méthode utilisée pour ce faire. local et du milieu industriel. Par exemple, le protocole HDLC a inspiré bon
nombre de protocoles de liaison de données, certes avec des
simplifications ; les concepts de station maître et de station esclave
Il est courant de représenter l’architecture des applications indus- étaient directement repris des réseaux de transmission de données des
trielles par des schémas (figure 4) qui figurent des machines et des années 1960. La principale innovation de ces réseaux fut d’introduire la
notion de « données globales ». Ces informations répertoriées issues de
réseaux. chacune des stations étaient transmises périodiquement à toutes les
Ce genre de schéma a peut-être le mérite de montrer quelle autres de façon à maintenir un état global approché du système. Notons
que cette innovation était due, et particulièrement favorisée par lui, au
machine est connectée à quel réseau, mais au-delà ? Un tel schéma fonctionnement des équipements raccordés qui étaient essentiellement
n’apporte rien quant à la connaissance des fonctions qui participent des automates programmables à système exécutif monotâche périodi-
à la commande du système ni sur les relations ou liens qui existent que (on dit aussi parfois synchrone). Le réseau tentait de reproduire le
entre les fonctions, ni sur les profils des réseaux locaux industriels système d’entrées-sorties de ces équipements, système de rafraî-
chissement périodique des entrées et des sorties.
utilisés. Tout juste peut-on imaginer que des machines connectées Le développement de ces réseaux a accompagné celui des architectu-
sur un même réseau doivent échanger quelques informations. Mais res des systèmes. Il est difficile de distinguer celui des deux phénomènes
lesquelles ? Sous quelles formes ? Quels services sont requis ? qui a précédé l’autre ; ils se sont mutuellement favorisés.
Il faut toutefois distinguer dans cette profusion de produits en général
En fait, une architecture opérationnelle n’est pas qu’un tel incompatibles les réseaux privés des constructeurs d’automates de ceux
schéma, mais aussi la description de la répartition des fonctions de sociétés non constructrices d’équipements, mais plutôt sociétés de
d’exploitation du système de production sur les stations et celle des service, qui devaient pour leurs clients connecter des équipements
hétérogènes grâce à leur réseau. C’est ainsi que sont nés les
relations entre fonctions sur les réseaux choisis. Les fonctions sont « communicateurs » qui étaient des appareils de raccordement des auto-
distribuées, implantées sur des machines connectées par les mates ou des calculateurs au réseau. Ils implémentaient quelques cou-
réseaux locaux industriels et elles donnent naissance à des proces- ches du profil du réseau. Les équipements y étaient raccordés par des
sus qui communiquent en faisant appel aux services de communi- lignes séries synchrones ou asynchrones ou par des liaisons parallèles
comme le standard GPIB. Ultérieurement, ces fonctions de communica-
cation par l’intermédiaire de la couche application. tion ont été implantées sur des cartes compatibles aux bus internes des
Il faut avoir une connaissance sur les processus répartis sur les machines et enfichables directement dans les racks.
À l’origine, ces réseaux étaient conçus à partir des connaissances
divers sites pour pouvoir répondre aux questions précédentes. issues des télécommunications en reprenant des protocoles existants. Ce
Réciproquement, en phase de conception d’une application n’est que dans une deuxième étape que l’analyse des architectures des
particulière, ce sont certaines caractéristiques des fonctions à systèmes automatisés a conduit à identifier des besoins spécifiques et
répartir qui guideront le choix d’un réseau local industriel ou d’un donc à définir des services et des protocoles spécifiques aux différents
domaines industriels.
autre.

Dans le premier cas, les stations sont les capteurs, les actionneurs,
les commandes d’axes, les régulateurs et des automates. Le trafic
Calculateur entre les processus de ces stations est essentiellement périodique et
Calculateur
GPAO relève des réseaux de terrain, voire des sensorbus ou devicebus.
Dans le second cas, les échanges sont des ordres de fabrication, des
coordinations ou des messages de synchronisation entre machines.
Réseau d'usine
Ils peuvent aussi être des fichiers éventuellement importants, lors
Contrôleur Passerelle de téléchargements des programmes nécessaires aux fabrications.
de cellule
Ce trafic est plus aléatoire, et aussi moins contraint par le temps.
Réseau de cellule C’est le domaine des réseaux dits de cellule, voire d’usine.
Automate Automate
2.2.2 Industries des processus continus
E/S Capteur Les processus continus sont caractérisés par le fait que les pro-
duits sont élaborés par diverses opérations en continu sans que le
Capteur Régulateur produit ne présente d’état stable entre deux opérations successives
de la fabrication. Dans cette catégorie, on inclut beaucoup de pro-
Capteur E/S
cessus chimiques, biologiques, agroalimentaires, les processus
sidérurgiques (fonderie, aciérie, laminage), les machines à fabriquer
Vanne
le papier, la production d’énergie, etc. On voit déjà que dans cette
catégorie très générale, on pourra distinguer diverses applications
sur d’autres critères comme les constantes de temps des variables
Réseau de terrain physiques considérées (par exemple, les températures dans un
haut-fourneau et la vitesse de défilement de la tôle dans un laminoir
à froid). Une température sera régulée à une période de l’ordre de la
Figure 4 – Architecture opérationnelle minute, une vitesse de rotation des rouleaux de laminoir à une
période de quelques dizaines de millisecondes. Par ailleurs, une
régulation des vitesses de plusieurs cages de laminoir en série
nécessitera une coordination, une synchronisation très précise des
Les réseaux servent évidemment à acheminer diverses informa-
vitesses respectives des moteurs.
tions entre les stations, mais il est préférable de considérer que ces
échanges ont lieu entre les processus d’application qui résident sur En termes de communication, on retrouvera les besoins caracté-
ces stations, plutôt qu’entre les stations elles-mêmes. Il est donc évi- ristiques des réseaux de terrain assurant en priorité le trafic temps
dent que les échanges vont dépendre de la répartition des proces- réel entre les capteurs, les contrôleurs et les actionneurs et aussi
sus, et réciproquement la répartition des processus va dépendre des permettant une véritable distribution des applications. La qualité de
capacités et des possibilités des réseaux utilisés. service exigée des réseaux dépendra de la criticité de l’application
considérée, qu’elle soit exprimée en termes de qualité des produits
ou de sécurité des personnes, des machines et de l’environnement.

D’autres besoins de communication moins contraints sont exprimés
2.2 Domaines d’application par les opérateurs d’exploitation et de maintenance. Ces besoins
sont couverts par les réseaux de salle de commande. Des supports
et des câblages particuliers peuvent être nécessaires selon l’envi-
Les domaines d’application sont aussi un critère de segmentation ronnement (parasites électromagnétiques, présence d’eau ou de
ou de classification des réseaux industriels. Nous en étudions ci- produits, températures). Des redondances sont parfois nécessaires
après quelques-uns qui nous permettront de mettre en évidence pour assurer une bonne disponibilité.
certains aspects ou critères plus généraux analysés en conclusion
de ce paragraphe.
2.2.3 Gestion de bâtiments et domotique
On distingue souvent les secteurs suivants : celui des industries
manufacturières (§ 2.2.1), des processus continus (§ 2.2.2), de la
production d’énergie, de la gestion de bâtiments ou de la Ce type d’application couvre la surveillance des bâtiments, le
domotique (§ 2.2.3), des systèmes embarqués (§ 2.2.4), du transport contrôle d’accès, la climatisation, la gestion des appareils électro-
d’énergie et de fluides (§ 2.2.5), et enfin les systèmes de ménagers, la gestion de fluides. Cela relève plus du suivi, de l’obser-
communication (§ 2.2.6). vation que de la commande stricto sensu, ce qui ne signifie pas qu’il
n’y ait pas de contraintes temps réel. Une tentative d’effraction ou
d’intrusion doit être détectée et transmise rapidement.
2.2.1 Industries manufacturières Beaucoup de capteurs sont des contacts tout ou rien (ouverture/
fermeture de porte, de fenêtre, allumage ou extinction de lampes...).
Ces applications sont caractérisées par le fait qu’entre certaines D’autres servent à la mesure des grandeurs physiques concernées
opérations, le produit en cours de fabrication est dans un état stable, (températures, débits), mais on trouve aussi des capteurs comme
c’est-à-dire qu’il ne se dégrade pas s’il est stocké. C’est ce critère qui des caméras ou des microphones pour la télésurveillance. Plusieurs
permet de découpler l’application de commande en autant de sous- types de réseaux cohabitent alors.
applications relativement indépendantes, chacune associée à une Dans ce type d’application, le câblage représente une part impor-
opération. La synchronisation des sous-applications relève de la tante du coût, d’où l’idée d’utiliser la technologie des courants por-
gestion de production mais pas de la commande temps réel propre- teurs sur le réseau électrique, voire les réseaux sans fil. Il doit donc
ment dite ; le respect de contraintes temporelles de synchronisation souvent être étudié spécialement. Le coût des équipements est très
(enchaînement des opérations) est plus important pour des raisons bas. Les protocoles ne doivent pas être trop consommateurs de res-
d’optimisation de la productivité que pour la qualité des produits. sources pour ne pas grever le coût des équipements. Les conditions
C’est ce qui explique que l’on distingue plusieurs types de environnementales ne sont en général pas trop sévères, mais diffé-
communications : à l’intérieur d’une machine et entre les machines. rentes topologies doivent souvent être possibles pour tenir compte,

à moindre coût, des dispositions des bâtiments. Fonctionnellement, événements pour permettre à des opérateurs d’intervenir au niveau
les services requis sont les mêmes que ceux des réseaux de terrain. de l’exploitation et de la maintenance.
Toutefois, dans le cas de grands bâtiments (hôtels, hôpitaux,
lycées...), il est nécessaire d’étudier l’architecture générale du sys-
tème au même titre que dans le cas des applications industrielles. Et 2.2.6 Systèmes de communication et de transport
naturellement, on retrouvera des architectures similaires avec des
réseaux de terrain et un ou des réseaux fédérateurs comme le sont
les réseaux de cellule ou d’usine. On appelle système de communication toute infrastructure per-
mettant le transport de personnes et de fret par des véhicules. On
inclut donc dans ces applications la téléconduite du trafic urbain, la
2.2.4 Systèmes embarqués gestion d’un réseau de chemin de fer, la surveillance d’une auto-
route. La topologie de ces réseaux dépend évidemment de la
géographie du système considéré. Les trafics de données sont des
Ces applications ont comme objectif d’assister le conducteur dans informations d’état sur le système, des événements et des
le pilotage ou la conduite du véhicule (automobile, train, avion...), télécommandes. Les contraintes de sûreté dépendent des applica-
mais aussi d’automatiser complètement certaines fonctions : ges- tions. On se rapproche ainsi des trafics des réseaux de terrain mais
tion et optimisation de la consommation d’énergie, changement sur de longues distances. On pourrait inclure dans ces applications
automatique des vitesses, contrôle de la direction, etc. D’autres la gestion des réseaux de télécommunications, des stations fixes
fonctions, comme la gestion des essuie-glaces, des phares, de pour les réseaux de téléphones mobiles, des satellites, dont beau-
l’accès, des ouvertures de porte, ainsi que des services d’aide à la coup de caractéristiques relèvent des systèmes embarqués avec en
maintenance sont maintenant souvent proposées dans les automo- plus des contraintes de maintien du service, même pendant la main-
biles. tenance ou les mises à jour des versions successives [10].
Ces applications présentent des contraintes de temps et de sûreté
de fonctionnement assez sévères. Elles sont par nature réparties car
chaque équipement est muni de fonctions informatisées. Et ces 2.2.7 Conclusion sur les domaines d’application
équipements doivent donc être reliés par des réseaux. Les réseaux
utilisés doivent donc être adaptés. On y trouve naturellement des
réseaux de terrain, et éventuellement un réseau fédérateur dans un Ces exemples de domaines d’application mettent en lumière les
système de grande taille qui nécessiterait plusieurs réseaux de ter- similitudes et les différences des réseaux locaux industriels. Les
rain, comme dans les TGV. Une autre caractéristique importante similitudes sont essentiellement d’ordre fonctionnel et les différen-
comme dans les processus continus est la prise en compte dans ces d’ordre quantitatif selon les domaines.
l’application de divers modes de marche incluant l’état des réseaux,
pour assurer la sûreté de fonctionnement. On remarquera que les ■ Similitudes :
applications aéronautiques sont assez différentes des autres car les — les notions d’architecture des applications. Dans les applica-
conditions d’arrêt ne sont évidemment pas les mêmes. tions complexes ou de grande taille, plusieurs réseaux sont en
général nécessaires. On trouve toujours un niveau de réseau de ter-
rain et un niveau de réseau fédérateur. Certaines contraintes de
L’expression « systèmes embarqués » dépasse maintenant répartition peuvent imposer l’existence de services ;
les véhicules. On parle de systèmes embarqués chaque fois
— les types de trafics. Les trafics peuvent être classés en trafics

qu’un équipement est muni de fonctions informatiques et de
temps réel d’états, de commandes et d’événements, et en trafics
communication. Par exemple, les appareils électroménagers
non temps réel de gestion, de maintenance.
« intelligents » sont aussi considérés comme des systèmes
embarqués (une machine à café, un réfrigérateur, une machine ■ Différences :
à laver). On parle aussi d’intelligence ambiante (ou informa-
tique pervasive), avec à l’horizon la plupart des objets courants — la sûreté de fonctionnement. Certaines applications ne tolèrent
intelligents et communicants, reconnaissant leur environne- pas d’arrêts intempestifs. Les contraintes de temps et leur criticité
ment, leurs utilisateurs mobiles, etc. La nouvelle problématique sont variables. Il est donc évident que la qualité de service des
de ces systèmes est liée à la mobilité et donc à la communica- réseaux sera un critère essentiel pour les applications les plus
tion sans fil, et à la sécurité. Confidentialité, intégrité, innocuité sévères ;
sont des propriétés fondamentales de ces réseaux. — la notion de modes de marche de l’application. Selon l’état du
processus physique considéré, mais aussi des réseaux, des stations,
divers algorithmes devront être utilisés, des arrêts pourront être
2.2.5 Transport d’énergie ou de fluides commandés, d’autres interdits (par exemple, pour un avion en vol),
des redondances de réseaux et d’équipements sont parfois
nécessaires ;
Ces applications consistent à piloter les réseaux de distribution
d’électricité, de gaz, d’eau, de vapeur, etc. Ce sont des réseaux à — les conditions environnementales. Ces conditions regroupent
grande échelle. Ils servent à surveiller et à télécommander des sta- les distances, les types de perturbations subies, qui sont en fait des
tions éloignées comme des postes de transformation haute tension contraintes sur les supports à choisir, les débits, les topologies.
– moyenne tension, des stations de pompage, des stations d’épura- Nous reviendrons sur ces points après avoir étudié les architectu-
tion. À l’intérieur de certaines de ces stations, il est d’usage d’avoir res des applications.
des automatismes sans opérateur. On y retrouvera des réseaux de
terrain respectant les contraintes environnementales et temporelles
des installations. Des équipements (capteurs et actionneurs) peu-
vent aussi être raccordés tout au long de ces réseaux. 2.3 Architectures des applications
Les caractéristiques de ces réseaux de télécontrôle sont d’abord
les distances souvent importantes, les supports qui sont parfois les
câbles électriques pour le télérelevé des compteurs domestiques, la Dans ce paragraphe, nous allons étudier les fonctions que l’on
radio pour des stations très lointaines (pour des raisons de coût de rencontre dans quasiment toutes les applications, quel que soit le
câblage), etc. Les trafics ressemblent à ceux des réseaux de salle de domaine, et comment organiser ces fonctions, selon quels modèles,
commande, il s’agit de rapatrier les valeurs d’état des stations, les pour maîtriser la complexité des grands systèmes.

2.3.1 Fonctions des systèmes automatisés Le modèle d’architecture fonctionnelle que nous proposons a
pour objectif essentiel de spécifier les échanges entre les fonctions,
Ce paragraphe donne une classification rapide des fonctions que cela afin de pouvoir vérifier que ces échanges fonctionnels pourront
l’on trouve dans quasiment toute application temps réel, que ce soit être supportés par les réseaux pour une distribution spécifiée.
dans les processus industriels, la domotique ou les systèmes
embarqués. On distingue les fonctions de commande automatique Nous ne détaillerons pas ici les modèles formels basés sur les
et celles de surveillance et de gestion par les opérateurs. processus aléatoires et stochastiques, mais de nombreux travaux
dans notre équipe de recherche ont conduit à valider formellement
■ Les fonctions de commande automatique recouvrent les opéra- certaines architectures opérationnelles.
tions suivantes :
— acquisition de données ; Précisons maintenant l’architecture fonctionnelle. Nous introdui-
— validation des données ; sons d’abord le concept d’architecture en couches, ou par niveaux
d’abstraction, qui nous permettra non seulement de structurer
— commande des actionneurs et des machines ;
l’application mais aussi de comprendre le modèle OSI.
— régulation ;
— commande séquentielle ;
— algorithmes de suivi de produit ;
— algorithmes de détection de défauts, de contrôle qualité ; 2.3.3 Objectifs et principes de la structuration
— gestion de production. en couches
■ Les fonctions de surveillance et commande par les opérateurs
recouvrent globalement toutes les actions et interactions entre le
La structuration en couches n’est pas nouvelle ni spécifique aux
système de commande, le système commandé et les différents opé-
systèmes de communication. On la rencontre dans les organisa-
rateurs selon le degré d’automatisation et évidemment aussi selon
tions humaines et dans les systèmes informatiques généraux. Pre-
les domaines d’application. Les interfaces avec le ou les opérateurs
peuvent être locales ou distantes. On trouve ainsi les fonctions nons quelques exemples pour illustrer les principes.
suivantes :
Exemple 1 : ordinateur et système d’exploitation
— contrôle des accès et authentification des personnes ;
— gestion des modes de marche ; Considérons un noyau qui est le matériel de l’ordinateur, au-dessus
— commande de certains actionneurs ; se trouve le système d’exploitation, il inclut le sous-système de gestion
des entrées-sorties et au-dessus le système de gestion de fichiers
— fixation de certains paramètres ;
(figure 5).
— gestion des alarmes ;
— analyse de données ; Une couche offre une abstraction de ses fonctions. Elle fournit des
— gestion du journal de bord de l’installation. services à la couche immédiatement supérieure. Elle est accessible
par le biais d’un langage, le langage d’appel des services. En retour,
■ La gestion du système regroupe toutes les opérations et fonc- une couche fournit des résultats à l’appelant des services. On peut
tions qui ne relèvent pas directement de l’application mais qui sont considérer qu’une couche est un interpréteur de ce langage. L’interpré-
nécessaires pour le bon fonctionnement de l’application. On les tation est faite en utilisant les services de la couche sous-jacente. On
appelle parfois « fonctions de service ». Ces fonctions n’ont pas distingue alors plusieurs niveaux de langage et d’interprétation.
d’impact direct sur le processus physique. Par exemple, on y trouve Dans l’exemple de la figure 5, le langage reconnu et interprété par le
la gestion de réseau, la synchronisation des horloges, la sur- matériel est le langage machine, le langage du système d’E/S est celui
veillance du bon fonctionnement des stations : des procédures définies et celui du système de gestion de fichier est
— identification des nœuds présents dans le réseau ; défini selon les méthodes d’accès, etc.
— gestion des modes de marche des nœuds ; Idéalement, la structuration en couches permet de définir les fonc-
— surveillance du réseau ; tions ou les services en offrant une interface visible de la couche sans
— gestion des programmes (téléchargement, etc.) ; avoir à se préoccuper de la façon dont les services sont réalisés. On en
— gestion des données de configuration ; fait abstraction. Cette structuration permet de diviser un problème glo-
— positionnement et fixation des paramètres ; bal en un ensemble de sous-problèmes hiérarchisés. Cette structura-
— modes de test. tion simplifie donc la conception d’un système, permet de réutiliser
des éléments existants, etc. Elle a de bonnes propriétés au regard du
génie logiciel.
2.3.2 Architecture fonctionnelle et opérationnelle
Exemple 2 : commande de robot
Dans les systèmes complexes, il est nécessaire de décomposer Considérons un robot, muni de trois commandes d’axes, chacune
les grandes fonctions listées ci-avant et d’organiser les coopéra- avec ses capteurs et ses actionneurs. Le système de commande
tions et interactions des composants élémentaires. Ce paragraphe peut être décomposé en deux couches. La première est celle des
expose une méthode de représentation des applications temps commandes d’axes, la seconde celle de commande globale du
réel qui met en évidence les échanges et donc les trafics que robot (figure 6). Celle-ci reçoit des ordres, par exemple « aller au
devront supporter les réseaux choisis comme support de la point P » ; il s’agit d’une demande de service. Cette demande va
solution. déclencher un processus. Ce processus est considéré comme un
La démarche de conception consiste d’abord à définir l’architec- interpréteur de la demande de service. Il va lui-même demander des
ture fonctionnelle selon trois critères : un critère de hiérarchie ou services aux commandes d’axes en leur envoyant des consignes
d’abstraction, un critère fonctionnel et la vue du processus physique (par exemple de position). Les commandes d’axes sont alors consi-
au travers de ses capteurs et actionneurs. Cette architecture fait dérées comme des interpréteurs du langage constitué des valeurs
abstraction des choix d’implantation. La conception de la solution de consigne. Ces commandes pourront inclure des régulateurs de
consiste alors à définir ensuite l’architecture support composée des position, de vitesse qui s’exécuteront périodiquement, pour calculer
matériels et des réseaux, et à projeter l’architecture fonctionnelle les commandes à appliquer aux actionneurs à partir des consignes
sur l’architecture support. Le résultat de cette projection est appelé et des mesures des capteurs. De plus, ces commandes devront
architecture opérationnelle. être synchronisées.

Lire un enregistrement ‹‹ fabriquer 100 pièces ››

‹‹ compte-rendu ››
SGF SGF : système de gestion de fichiers
Commande
Lire un secteur de cellule
IOCS IOCS : input/output control system ‹‹ percer trous (coordonnées) ››
‹‹ trou terminé ››
SIO (start input/output) ‹‹ prendre pièce machine 1 ››
‹‹ OK ››
Hardware
‹‹ usiner (paramètres) ››
‹‹ fin usinage ››
Figure 5 – Fonctions d’accès à un fichier Commande Commande Commande

de machine 1 de robot de machine 2
Figure 7 – Commande de cellule

Aller au point P(x,y,z)
Commande de robot
consigne de déplacement de Axe3
consigne de déplacement de Axe2 Hiérarchie Maintenance
consigne de déplacement de Axe1
Contrôle qualité
Axe1 Axe2 Axe3
Contrôle-commande
N +1
Capteurs Actionneurs
Figure 6 – Commande de robot N1 N2
Exemple 3 : système automatisé de production (N -1)1 (N -1)2 (N -1)3 (N -1)4

Considérons un ensemble de deux machines desservies par un
Fonctions
robot de chargement et déchargement de pièces. Processus
physique
« Fabriquer 100 pièces » est une requête ou une demande de ser-
vice. Le « compte-rendu » est une information qui est renvoyée au
demandeur de service, par exemple à la fin, quand tout s’est bien
Figure 8 – Modèle 3-axes

passé, ou en cours de traitement si une anomalie se produit.
La « commande de cellule » doit coordonner les trois appareils pour
exécuter la requête (figure 7). Elle interprète la requête. Pour cela, elle
s’appuie sur les services fournis par les systèmes de commande des grandes fonctions ne sont pas hiérarchisées les unes par rapport
machines et du robot. Elle va donc demander successivement ou en aux autres, c’est pourquoi nous introduisons le modèle suivant.
parallèle des services à ces trois commandes du niveau inférieur En nous appuyant sur la structuration en couches et en introdui-
(« usiner (paramètres) », « prendre pièce machine 1 », « percer trou »). sant les différentes fonctions d’un système automatisé dans des
Ces trois commandes vont interpréter ces requêtes à nouveau en plans parallèles, nous allons identifier d’autres flux ou échanges.
s’appuyant sur les services d’un éventuel niveau inférieur comme les
commandes d’axes évoquées dans l’exemple 2. Les exécutions ou 2.3.3.1 Modèle 3-axes
interprétations donneront ensuite lieu à des comptes-rendus notés
« fin usinage », « OK », « trou terminé ». L’axe horizontal modélise le processus physique par son interfa-
On pourrait aussi distinguer le niveau de service des capteurs et çage avec le système de commande (les capteurs et les action-
actionneurs, celui des commandes d’axes. On retrouve à chaque neurs). Le processus physique peut être décomposé par
niveau différents langages et interpréteurs. équipement ou par machine comme c’est souvent le cas dans les
Cette façon de procéder conduit à identifier les entités fonctionnel- industries manufacturières.
les de chaque niveau et les échanges entre elles. Ces échanges peu- L’axe vertical représente les niveaux hiérarchiques selon une
vent être spécifiés très précisément : taille des demandes de service, structuration en couches. À un niveau donné, une entité offre des
des réponses, périodicité requise, contraintes de temps à respecter. services à l’entité de niveau supérieur en utilisant les services des
Si on choisit une architecture support et une distribution des entités, entités de niveaux inférieurs. Mais une entité offre aussi des servi-
on connaît alors les performances et plus généralement les capacités ces à celles du niveau inférieur.
du réseau choisi, il n’y a plus qu’à s’assurer que les propriétés des spé- Le troisième axe représente les fonctions qu’on peut trouver pour
cifications peuvent être vérifiées. une application donnée. La figure 8 ne représente que trois plans
Les exemples 2 et 3, représentés par les figures 6 et 7, illustrent (trois fonctions) : la commande automatique, la maintenance et le
la structuration en couches qui permet de décomposer les fonctions contrôle qualité ; on pourrait y ajouter le suivi de produit si besoin
de commande automatique (§ 2.3.1) en différentes sous-fonctions et était, la supervision par les opérateurs.
de spécifier les échanges entre elles. Ce modèle est basé, entre autres, sur le fait que certaines grandes
fonctions ne sont pas hiérarchisées mais indépendantes en termes
Si on cherche à structurer les autres fonctions de surveillance, de de service, même si elles échangent des informations. Il permet
commande par les opérateurs, de diagnostic, de maintenance, on maintenant de spécifier les échanges et donc les communications
peut leur appliquer les mêmes principes. Toutefois, toutes ces selon deux classes. Dans chaque plan vertical, les échanges sont liés

d’un service qui initialise l’échange au moment où il le faut. En

retour, c’est le fournisseur du service qui prend l’initiative de la
réponse quand celle-ci est prête.
i +1 i +1 Nota : les termes requête, indication, réponse, confirmation sont issus du modèle OSI
étudié au paragraphe 1.2. Cette analogie a été choisie pour bien montrer les similitudes de
certaines coopérations entre fonctions et entre les couches du modèle OSI.
Requête Confirmation Réponse Indication
■ Flux horizontaux : ils représentent les échanges d’informations

i i
entre entités de plans différents. Le modèle impose de ne considérer
ici que des échanges de données, mais pas de demande explicite de
service, cela afin d’assurer une indépendance maximale des fonc-
tions (l’émetteur d’une information n’attend pas de réponse). Ces
Figure 9 – Échanges verticaux données peuvent être des variables très simples (valeur d’une pres-
sion) ou plus complexes (ordre de fabrication). Ces échanges
n’imposent pas de réponse des récepteurs. Cela ne signifie pas qu’il
aux demandes de service et à leurs comptes-rendus : on l’appellera
n’y a pas d’acquittements, qui sont toujours possibles mais qui sont
flux vertical ; entre entités de différents plans horizontaux, on identi-
attachés à un autre niveau de protocole. Les flux horizontaux irri-
fie aussi des échanges d’informations.
guent l’ensemble de l’application afin que toutes les fonctions ou les
Ce modèle n’explique pas la méthode de spécification, c’est-à- entités aient une vue cohérente de l’installation. On voit ainsi qu’une
dire comment on obtient cette architecture. Il n’a comme objectif même information peut intéresser plusieurs entités destinataires. Si
que de préciser les flux pour faciliter le choix de réseaux et la elles sont ultérieurement réparties sur plusieurs sites, le réseau uti-
définition de l’architecture opérationnelle. Les réseaux choisis lisé devra donc offrir des services de communication autres que les
devront assurer les échanges associés aux différents flux en termes services bipoints usuels.
de services disponibles adaptés aux caractéristiques des échanges,
en termes de débit par rapport à la charge induite, en termes de res- Du point de vue des contraintes temporelles, les flux horizontaux
pect des contraintes de temps associées aux échanges. sont soumis à des contraintes différentes. Il ne s’agit plus ici de
temps de réponse mais de durée de vie des données à transmettre.
2.3.3.2 Types de flux La durée de vie d’une information est, comme pour les temps de
réponse, de plus en plus courte quand on s’approche du niveau des
Dans ce paragraphe, nous précisons les échanges entre entités de capteurs et plus généralement de l’instrumentation sur le processus
façon à déterminer quels services (et leurs qualités de service) sont physique. La durée de vie d’une information est d’abord représenta-
requis pour assurer la communication. À ce niveau de description,
tive du comportement de son producteur. Si une information est
nous nous intéressons uniquement aux aspects fonctionnels des
produite de façon périodique, du point de vue de son producteur, sa
échanges du modèle « 3-axes » sans préjuger de la façon dont ils
durée de vie sera au maximum égale à la période de production.
seront réalisés avec un réseau particulier.
Pour les consommateurs, cette durée de vie dépendra de leur
Nous avons d’abord séparé les échanges internes à une fonction comportement. Par exemple, un consommateur n’est pas obligé de
des échanges externes entre fonctions. Les premiers sont des consommer à la fréquence de production et peut n’être intéressé
échanges verticaux, les seconds des échanges horizontaux pour que par une valeur sur deux, sur trois, etc.
reprendre la géométrie du modèle.
Si une information est produite de façon aléatoire, il est plus déli-
■ Échanges verticaux (figure 9) : la méthode de décomposition
cat de définir sa durée de vie. Elle est au plus égale à l’intervalle
d’une fonction en niveaux hiérarchisés conduit à définir des échan-
entre deux productions, mais peut être beaucoup plus courte. Si l’on
ges entre entités de niveaux adjacents d’un même plan, donc d’une
intègre la propriété de cohérence (même vue du système par les dif-
même fonction. Ces échanges sont soit des demandes de service,
férentes entités) et si l’on désire que les moments d’incohérence
soit des comptes-rendus du fournisseur de service vers son utilisa-
teur. soient les plus courts possible, il est évident qu’au moindre change-
ment d’état, il faudra informer les entités concernées.
Les demandes de service émanent soit de l’entité de niveau supé-
rieur – on les appelle des requêtes –, soit de l’entité de niveau infé- L’initialisation d’un échange de type horizontal est considérée à ce
rieur – on les appelle des indications. Les comptes-rendus émanent niveau de spécification comme étant à la charge du producteur de la
respectivement soit de l’entité de niveau inférieur – on les appelle donnée à échanger.
des confirmations –, soit de l’entité de niveau supérieur – on les
appelle des réponses.
Les demandes de service (requêtes ou indications) sont émises 2.3.3.3 Synthèse sur les flux
cycliquement ou non. Plus le niveau i est proche de celui des cap-
teurs, plus elles seront cycliques et de courtes périodes, mais il n’est Dans ce modèle, une même information peut être transmise selon
pas impossible d’en trouver également dans les plus hauts niveaux le premier type d’échange vertical mais aussi selon le deuxième
de la hiérarchie. type d’échange horizontal. Il peut donc être intéressant de les
En général, la contrainte de temps associée est exprimée en ter- fusionner lors du choix du réseau dans la définition de l’architecture
mes de temps de réponse, c’est-à-dire que du point de vue de l’utili- opérationnelle.
sateur, l’intervalle de temps entre l’émission d’une requête (resp.
l’indication) et la réception de la confirmation (resp. la réponse) est Par exemple, si un régulateur a besoin de lire une vitesse, il peut
majoré supérieurement par un ∆t max. Cette contrainte est en géné- le faire par une demande « lire vitesse » et attendre la réponse. Mais
ral de plus en plus sévère au fur et à mesure que l’on se rapproche le capteur de vitesse peut lui-même être conçu pour émettre la
du processus physique. Pour des raisons de sécurité (des person- vitesse sans qu’on la lui demande. Si c’est le cas, le régulateur n’a
nes, des machines), le délai maximum doit être absolument res- qu’à s’abonner à la valeur de l’objet « vitesse » et n’aura plus à la
pecté quand on est dans les couches basses. Dans les couches les demander. Nous verrons dans le paragraphe suivant que cette ana-
plus hautes, le non-respect est souvent moins catastrophique. On lyse des flux a conduit à distinguer deux grandes familles de modes
peut seulement perdre en productivité mais ne pas mettre en cause de coopération, le modèle client-serveur et le modèle producteur-
la sécurité globale de l’installation. En général, c’est le requérant consommateurs.

3. Réseaux locaux industriels

i +1 i +1
Requête Confirmation Réponse Indication

3.1 Types de coopération
i i
Cas A Cas B
Le type ou le mode de coopération désigne la façon dont les
processus d’application coopèrent. C’est une des premières
caractéristiques des réseaux locaux industriels. Figure 11 – Coopération entre entités adjacentes : schéma
fonctionnel
On distingue plusieurs modèles de coopération : client-serveur,

client-multiserveur, producteur-consommateurs et producteurs-
distributeur-consommateurs. i +1 i
Réseau
3.1.1 Modèle client-serveur
Nous considérons à nouveau la cellule automatisée composée Figure 12 – Distribution des entités adjacentes : schéma
d’un robot et de deux machines-outils (figure 7, exemple 3) étudiée opérationnel
au paragraphe 2.3.2. On a mis en évidence la coopération entre enti-
tés de niveaux adjacents (figure 9). Cette coopération est typique-
ment du type client-serveur.
Client Système de Serveur
(i +1) communication (i )
3.1.1.1 Définition
Requête
Indication
Le modèle de coopération client-serveur est un modèle
bipoint. Deux processus sont en relation : le client et le serveur.
Le client émet une demande de service vers le serveur. Le ser- Réponse
veur, selon ses possibilités et ses ressources, traite la requête et
Confirmation
renvoie la réponse au client.
Ce modèle est très général. Une grande diversité de services peut Cas A
fonctionner selon ce modèle. La plupart des services/protocoles de

couche application respectent ce modèle (MMS – Manufacturing
Message Specification – en est le prototype). La durée totale de Système de
Client Serveur
l’opération est imprévisible, sauf à faire des hypothèses sur la dis- (i ) communication (i +1)
ponibilité du serveur et du réseau chargé d’acheminer la demande
et la réponse. Requête
‹‹indication››
La figure 10 montre les enchaînements de primitives du modèle Indication
client-serveur. Le système de communication transporte la requête
du client vers le serveur. Cette requête arrive sous forme d’indica- Réponse
tion au serveur. C’est l’indication qui déclenche l’exécution du ser- Confirmation
vice requis. Le serveur répond sous la forme d’une confirmation. ‹‹réponse››
Selon les services et donc selon les protocoles, les réponses sont
transmises à divers moments de l’exécution du service chez le ser-
veur. Par exemple, la réponse peut être envoyée avec le résultat du Cas B
service, mais elle peut aussi être envoyée en début d’exécution.
Figure 13 – Coopération entre entités adjacentes : schéma
opérationnel
Client Système de Serveur

Analysons maintenant comment le modèle client-serveur permet
communication de transporter les requêtes identifiées dans le schéma fonctionnel.
Nous reprenons sur la figure 11, dans le cas A, l’enchaînement
Requête
requête-confirmation entre deux entités (i + 1) et (i) et, dans le cas B,
Indication l’enchaînement indication-réponse entre deux entités (i) et (i + 1).
Supposons que les entités (i) et (i + 1) soient implantées sur deux
Réponse stations reliées par un réseau qui fonctionne selon le modèle, client-
serveur (figure 12).
Confirmation
Les échanges correspondant aux cas A et B sont représentés sur
la figure 13. Dans le cas A, la coopération de type client-serveur
modélise le fait que la requête fonctionnelle est transportée de
Figure 10 – Modèle client-serveur (i + 1) vers (i), qu’elle arrive sous forme d’indication en (i), que la

réponse de (i) est transportée vers (i + 1) qui arrive sous forme de 3.1.2 Modèle producteur-consommateurs
confirmation en (i + 1). L’entité (i + 1) est client, l’entité (i) est serveur.
Dans le cas B, l’indication fonctionnelle est en fait une requête Le modèle producteur-consommateurs est un modèle multi-
émise par le client (i) vers le serveur (i + 1) qui arrive effectivement point dans lequel le producteur d’une donnée peut l’émettre
sous forme d’une indication. Et la confirmation du modèle client- vers tous ceux qui en sont consommateurs. Cette émission peut
serveur correspond à la réponse du modèle fonctionnel. être, selon le protocole utilisé, en diffusion générale ou en mul-
tipoint. Dans ce cas, deux principales techniques peuvent être
mises en œuvre :
Dans l’architecture fonctionnelle des systèmes automatisés,
on distingue des niveaux d’abstraction N, N − 1, N + 1, à ne pas — chaque consommateur se reconnaît comme abonné sans
confondre avec les niveaux OSI. Cette architecture fonctionnelle que le producteur ait à le nommer ;
[11] [12] [13] est complètement indépendante des architectures — tous les récepteurs sont explicitement spécifiés par l’émet-
opérationnelles. Pour obtenir cette dernière, en phase de con- teur.
ception de l’application, on décidera du placement des fonc-
tions sur les stations. Connaissant les relations entre les
Si l’on sait garantir que chacun recevra la même valeur, on a
fonctions, on identifiera immédiatement les échanges que le
résolu le problème d’obtention du même résultat par des clients dif-
réseau doit assurer. Ces échanges seront donc spécifiés non
férents (consommateurs). L’initiative de l’émission est laissée au
seulement en termes qualitatifs mais aussi en termes quantita-
producteur, mais celle de la production peut être confiée à un
tifs.
« client » qui déclenche l’opération et qui est choisi parmi les con-
sommateurs.
Nota : notons que les producteurs et les consommateurs sont respectivement les ser-
3.1.1.2 Limites veurs et les clients du modèle client-serveur.
■ Dans ce modèle, le temps n’est pas pris en compte, c’est-à-dire Ce modèle peut être décliné sur n’importe quel protocole de
qu’il est impossible d’une part de spécifier un délai maximum pour Medium Access Control. Par exemple, avec un protocole comme
que le client obtienne la réponse, d’autre part d’avoir un moyen de Ethernet (CSMA/CD), chaque producteur attend que le canal soit
vérifier que ce délai est respecté. libre pour tenter une émission. Avec un protocole de type passage
de jeton ou de droit de parole, chaque producteur attendra que le
C’est pourquoi une extension de ce modèle, que l’on pourrait droit d’émission lui soit attribué pour émettre le résultat de la pro-
appeler client-serveur temporel, a été étudiée dans divers travaux duction. Un cas particulier est obtenu avec un protocole centralisé
de recherche : il s’agit d’associer une contrainte de délai au traite- comme expliqué au paragraphe suivant.
ment de la demande et d’offrir dans le protocole fonctionnant sur ce
modèle les mécanismes adéquats pour indiquer au client si tout
s’est bien passé ou non et pourquoi. Indiquons tout de suite que ce 3.1.3 Modèle producteurs-distributeur-
modèle n’est intégré sous une forme générale dans aucune norme consommateurs
de service ou de protocole.
3.1.3.1 Motivations
■ Si deux clients demandent un même service à un serveur, ce der-

nier les traitera en séquence et pourra fournir des réponses différen-
tes à chacun d’eux. Par exemple, deux fonctions ont besoin de lire la Ce modèle est une extension du précédent pour permettre de
mesure d’un capteur de vitesse ; elles sont clientes du capteur qui maîtriser le temps, en particulier dans la gestion de plusieurs
dans ce cas est le serveur. La vitesse peut évoluer entre les deux serveurs producteurs de données. Dans ce modèle, l’initiative
réponses et cette différence de vue du processus par les deux clients des émissions et certaines synchronisations sont confiées au
peut nuire au bon fonctionnement du système. C’est pourquoi si, distributeur, ce qui permet d’ordonner les échanges de façon à
dans un système automatisé, deux fonctions (ou plus) ont besoin garantir au mieux le respect de certaines contraintes temporel-
d’avoir accès aux mêmes objets, le modèle client-serveur n’est pas les.
particulièrement adapté.
■ Si un client veut demander simultanément des services à plu- Le producteur d’une donnée est un processus d’application res-
sieurs serveurs, il ne peut le faire que séquentiellement, ce qui ponsable de la production de la donnée.
revient à considérer comme simultanés tous les événements inter- Le distributeur des données est un processus d’application qui est
venant dans l’intervalle de temps nécessaire aux exécutions responsable du transfert de chacune des données du producteur à
séquentielles des demandes de service. Un modèle client- tous ses utilisateurs.
multiserveur a été défini pour certains services [14]. Il faudrait
l’étendre avec la possibilité de gestion de contraintes temporelles. Les utilisateurs des données (les consommateurs) sont des pro-
cessus d’application qui ont besoin des données pour être exécutés.
Les modèles producteur-consommateurs et producteurs-distribu- Plusieurs idées directrices ont présidé à l’élaboration de ce
teur-consommateurs ont été introduits pour pallier ces deux der- modèle.
niers problèmes.
La première est de fournir les services d’échange de valeurs de
On notera que si le modèle client-serveur est très général, les variables ; les seuls services accessibles selon ce modèle sont
autres aujourd’hui ne sont pas définis pour tout type de services l’émission et la réception d’objets. Donc les modèles ne mettront en
mais seulement pour les accès aux données, c’est-à-dire que les œuvre que les concepts d’émetteur et récepteur ou producteur et
seuls services disponibles sont les opérations de lecture et d’écri- consommateur. De plus, il s’agit de rendre les objets produits direc-
ture. C’est pourquoi ils seront essentiellement présents dans les tement accessibles par les services de lecture/écriture (réception/
réseaux de terrain et les réseaux domotiques qui s’en rapprochent. émission) sans avoir à activer un processus d’application. Il sera
alors possible de séquencer les échanges sur le réseau sans avoir à
Il est important de noter que l’indisponibilité de ces modèles dans tenir compte des comportements des processus d’application con-
un profil de communication peut introduire des contraintes sur la cernés, sous réserve qu’ils indiquent leur état aux récepteurs des
répartition des processus d’application coopérants. données.

La deuxième est que la plupart des informations doivent être pré-

sentes à des instants prédéfinis chez éventuellement plusieurs con- Producteur Consommateur Consommateur
sommateurs (aspect multipoint des échanges). Ce n’est donc pas à Original de x
chacun d’eux de demander l’émission par le producteur. Cette fonc-
tion sera celle de la distribution. Cette fonction est encore renforcée Distributeur x x x
par le fait que les activités de plusieurs producteurs doivent pouvoir x
être synchronisées. Si on appelle transaction de communication
l’ensemble des transferts associés à une demande de lecture d’une
liste de variables, demande qui peut concerner plusieurs émetteurs,
il faut pouvoir ordonner les demandes de transferts élémentaires, Copies de x
d’où la notion de distributeur du réseau WorldFIP. Distribution
La troisième est que dans le modèle client-serveur, en cas
Figure 14 – Modèle producteurs-distributeur-consommateurs
d’absence ou de retard de la réponse, le client est sans information
sur le serveur. Il s’agit de corriger cela.
particulier, si l’on désire démarrer/arrêter un processus à distance,
La quatrième idée est que les objets ont une durée de vie limitée ce processus devra être consommateur d’un objet dont la valeur
et qu’il n’est pas utile de considérer les suites de valeurs comme des indiquera l’action à mener. Si ce n’est pas ce processus qui est le
éléments de file d’attente. Nous aurons donc des mécanismes avec consommateur, ce sera un ordonnanceur local.
écrasement d’anciennes valeurs par des nouvelles.
Le producteur de cet objet n’est pas spécifié dans le modèle. Mais
Ce modèle suppose que les valeurs des objets soient accessibles
l’intérêt est que, si plusieurs processus doivent être démarrés/arrê-
chez les producteurs par le système de communication et que l’on
tés en même temps, comme l’objet en question est transmis selon
puisse donc ignorer le délai d’élaboration de la réponse à une
le modèle producteurs-distributeur-consommateurs lui-même, on
requête par un serveur. C’est d’ailleurs l’hypothèse sous-jacente du
peut être sûr qu’en cas de bonne transmission, aux délais de propa-
service RDR (Request Data and Reply) du LLC3 [S 7 575].
gation près, les opérations auront lieu en même temps si les ordon-
nanceurs locaux n’introduisent pas de délais supplémentaires. On
3.1.3.2 Principes peut considérer ce cas comme réaliste en particulier dans les
Trois types de processus cohabitent, les producteurs, le ou les dis- réseaux de terrain, compte tenu du type de processus implanté sur
tributeurs et les consommateurs. Un producteur produit localement des capteurs et des actionneurs.
la valeur d’un objet ; le distributeur déclenche le transfert et la Le modèle producteurs-distributeur-consommateurs peut rempla-
réception, l’opération de recopie chez les consommateurs de la cer le modèle client-serveur quand le distributeur connaît les besoins
valeur originale prise chez le producteur ; les consommateurs utili- de tout client potentiel. Le modèle producteurs-distributeur-
sent la copie locale de l’objet. consommateurs est avantageux par rapport au modèle client-serveur
Ces processus sont plus ou moins dépendants les uns des autres. quand un serveur a plusieurs clients simultanés. Si plusieurs entités
Ils peuvent être complètement indépendants ou coordonnés de normalement clientes d’un même serveur doivent profiter du service
façon étroite, par exemple, produire de façon périodique, transmet- au même moment pour des raisons de cohérence, le modèle produc-
tre à la même fréquence et consommer de manière identique, mais teurs-distributeur-consommateurs permet de les satisfaire en une
toute autre situation peut être définie. Les comportements tempo- seule transaction.
rels des divers processus sont définis selon les besoins de l’applica-
tion. 3.1.3.3 Application aux réseaux de terrain
Dans le cas de WorldFIP, des mécanismes de validation temporelle
des valeurs d’objets ont été introduits pour permettre aux consom- Les principaux objets échangés sur un réseau de terrain sont les
mateurs de savoir si les délais impartis au producteur et au distribu- grandeurs numériques ou booléennes en provenance des capteurs,
teur sont respectés ou non. vers les actionneurs et de variables d’états entre les organes de
commande.
C’est cette notion d’original et de copies qualifiées temporelle-
ment de la valeur d’un objet qui fait parfois dire que WorldFIP est un Exemple : si nous considérons un régulateur et un capteur, par
système réparti de gestion de base de données de terrain application du modèle d’architecture fonctionnelle, le régulateur devrait
(figure 14). émettre une requête vers le capteur pour obtenir la valeur mesurée
Nota : pour réaliser un comportement du type client-serveur, il faut définir le serveur
comme confirmation. Si nous ajoutons un système de supervision ou un
comme consommateur et producteur. Il est consommateur d’un objet porteur de la système d’aide à la maintenance, le régulateur envoie usuellement la
requête, tel qu’à sa réception, le serveur soit activé ; il dépose ensuite le résultat dans valeur mesurée vers ces deux autres organes. Si nous utilisons le
l’objet dont il est producteur. Un serveur est donc d’abord consommateur de l’objet modèle producteurs-distributeur-consommateurs, nous voyons qu’en
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. Il faut toutefois remarquer que le producteur de la une transaction, la valeur mesurée du capteur pourra être transmise au
requête n’est pas forcément le même que le consommateur du résultat. En outre, plusieurs régulateur, au système d’aide à la maintenance et à celui de supervision.
clients peuvent profiter du résultat. On obtient un comportement du type multiclients-
serveur.
Plus généralement, on peut, avec ce modèle, implémenter divers Nous venons d’étudier les différents modèles qui président au
services comme « activer une tâche », « arrêter une tâche ». fonctionnement des réseaux locaux industriels. Ils ne sont pas
Le modèle producteurs-distributeur-consommateurs impose de exclusifs les uns des autres ; plusieurs modèles peuvent cohabi-
traduire toute demande de service en un objet particulier ou en la ter dans un même réseau, ce qui se traduit par plusieurs profils
valeur d’un objet. Si l’on assimile les consommateurs à des clients dans l’architecture de communication. On rencontrera souvent
vis-à-vis des objets consommés ou utilisés, le modèle producteurs- des réseaux locaux industriels (surtout les réseaux temps réel) à
distributeur-consommateurs définit la façon dont ces clients seront deux profils, l’un dit non temps critique pour des besoins
alimentés par les producteurs de ces objets sans préjuger des com- d’échanges classiques comme dans tout réseau et l’autre adapté
portements des producteurs et des consommateurs. Si l’on désire à la communication présentant des aspects de criticité tempo-
influencer ou contrôler le comportement d’un producteur ou d’un relle. Mais dans ce cas et avec un seul support de transmission,
consommateur, équivalent d’une demande de service, nous devons il ne faut pas oublier que les deux profils se rejoignent au moins
définir un ou plusieurs objets qui seront consommés par les proces- au niveau du Medium Access Control qui devra alors tenir
sus concernés. Le comportement des processus sera alors le résul- compte des contraintes de temps ou des priorités des trames
tat de l’interprétation locale de la valeur de l’objet reçu. En issues des différents processus d’application.

Dans une application autour d’un réseau de terrain, les clients doi- Récapitulons les principales caractéristiques des échanges :
vent recevoir certaines grandeurs à des instants précis. Ces gran- — taille des messages : certains sont courts, d’autres longs, par-
deurs sont répertoriées. Le distributeur peut gérer et séquencer ces fois trop longs pour être transmis en une fois et ils doivent subir une
transactions pour satisfaire les contraintes de temps. segmentation à l’émission et un réassemblage à la réception ;
— sécurité requise : les acquittements sont-ils nécessaires ou
non, ainsi qu’un contrôle de flux ? Quels sont les taux d’erreurs
acceptables ? ;
3.2 Qualité de service — transmission point à point ou autre : dans le cas de transmis-
sions point à point, les acquittements sont possibles. Sinon, se pose
le problème de la cohérence spatiale, c’est-à-dire de l’identité des
La notion de qualité de service cherche à exprimer la façon dont copies chez tous les destinataires ;
un service est rendu, et ce, autant que possible, sous forme quanti- — périodicité : un échange est-il périodique ou non ? Une gigue
fiée. Cela implique au minimum que le demandeur puisse requérir est-elle acceptable ? Sous quelles conditions ? Dans quelles
la qualité de service désirée et qu’en retour, il puisse se rendre limites ? ;
compte de la qualité réellement atteinte ou obtenue. Le fournisseur — contraintes de temps : est-on capable de garantir un délai
du service, quant à lui, doit pouvoir réagir aux demandes en indi- d’émission, un délai de réception de plusieurs messages, un temps
quant a minima s’il peut ou non fournir la qualité requise et dans les de réponse ? ;
systèmes plus sophistiqués, il peut négocier la qualité du service — règle d’émission : l’émission d’un message est-elle spontanée
avec le demandeur (par exemple, en contrepartie d’un tarif plus ou par son producteur ou est-elle seulement sur requête ? ;
moins élevé). Ensuite, il doit mettre en œuvre tous les moyens à sa — cohérence temporelle des opérations distribuées : des opéra-
disposition pour satisfaire ses engagements. tions, par exemple des échantillonnages de mesures sur des cap-
teurs, doivent parfois se dérouler en même temps. Quels
Dans les applications temps réel, la qualité de service concerne
mécanismes pour garantir ce principe ?
surtout, d’une part, la sécurité des transmissions et, d’autre part, le
respect des contraintes de temps. Selon les trafics, on mettra Nous allons maintenant analyser ces différences d’un point de
l’accent sur l’un ou l’autre des aspects, voire sur les deux. vue technique ; en quoi les réseaux locaux industriels sont-ils effec-
tivement différents en termes d’architecture OSI et en termes de
Exemple 4 mécanismes OSI ?
Dans le cas de la commande de cellule (exemple 3), le processus de Nota : en ce qui concerne les contraintes temporelles, il ne faut pas confondre vitesse
ou débit et respect des contraintes. Un réseau à 10 Mbits/s n’est pas plus « temps réel »
fabrication sur le contrôleur nécessite le téléchargement d’un qu’un réseau à 1 Mbit/s. Bien sûr, un débit minimal est nécessaire pour répondre aux
programme ; ce programme doit être transmis sans erreur le plus rapi- besoins d’une application, mais ce n’est pas en surdimensionnant qu’on résout le pro-
dement possible sans toutefois qu’un léger retard soit trop préjudicia- blème. Si la stratégie choisie pour ordonner les tâches contraintes n’est pas adaptée au sys-
ble si le processus physique est dans un état stable pendant ce temps. tème, et en particulier les échanges sur le réseau, les contraintes peuvent ne pas être
respectées, même à haute vitesse (cf. la fable du lièvre et de la tortue dans [15]).
L’opération n’est pas critique du point de vue temporel, mais elle doit
être effectuée sans erreur.
Exemple 5
3.3 Architectures des réseaux locaux
Le processus de commande d’axe (exemple 2) doit recevoir la valeur
industriels
d’une mesure, par exemple, toutes les 10 ms. Cette valeur peut être
erronée une fois de temps en temps, mais pas de manière consécutive
et la période doit être respectée. Les sécurités de transmission porte-
ront non seulement sur la protection contre les erreurs éventuelles, Depuis la normalisation du modèle OSI, tout système de commu-
mais aussi sur les instants où les mesures sont produites, transmises, nication y fait référence, c’est-à-dire que chaque constructeur de
consommées. réseau, quel qu’il soit, aime à dire que son produit est conforme au
modèle. Mais que signifie être conforme au modèle OSI ? En théo-
rie, cela signifie que le réseau en question offre une architecture en
Dans ces deux exemples, les mécanismes de traitement des
sept couches qui sont celles définies par l’ISO. Mais cela ne veut pas
erreurs ne seront pas les mêmes. Dans l’exemple 4, on choisira des
dire que dans chacune des couches, les services offerts et les proto-
acquittements et un contrôle de flux ; dans l’exemple 5 et en géné-
coles utilisés sont d’un type donné, voire normalisés. Les réseaux
ral pour les trafics périodiques, on fera le choix de communication
de terrain en particulier – mais ce ne sont pas les seuls – ne dérogent
sans acquittement, avec un contrôle de la reprise en cas d’erreur par
pas à la règle et selon une expression consacrée maintenant, il est
les processus d’application.
dit que ces réseaux doivent offrir une architecture en trois couches
Exemple 6 selon le modèle OSI « réduit ».
Un processus de supervision doit être averti des dysfonctionne- Ce modèle a été introduit au milieu des années 1980 à propos du
ments du processus physique dans des délais raisonnables qui dépen- projet MAP (Manufacturing Automation Protocol). Afin de satisfaire
dent des constantes de temps des variables physiques. Il faudra soit disant des exigences de temps réel, les auteurs de MAP, qui lui
pouvoir garantir que des contraintes de temps seront respectées. est conforme au modèle à sept couches, ont estimé que pour
« accélérer » la communication, certaines couches n’étaient pas fon-
Exemple 7 damentalement nécessaires dans certains cas de figure. C’est ainsi
Dans un processus continu comme un laminoir, les états d’une que les couches réseau, transport, session et présentation ont dis-
machine amont devront être transmis à la machine aval (et réciproque- paru du modèle général, donnant naissance au modèle réduit
ment) dans des délais compatibles avec la vitesse de transfert du pro- composé uniquement des couches physique, liaison de données et
duit et les temps de réaction des machines. Les contraintes de temps application.
sont ici encore fonction du processus physique et il faudra pouvoir Il faut bien être conscient qu’en supprimant des couches, on dimi-
adapter les protocoles du profil à chaque cas particulier. nue d’autant le « temps de traversée » de l’empilement des services
mais qu’en contrepartie, on n’en bénéficie plus. De plus, le pro-
Ces quelques exemples montrent bien que les contraintes à res- blème du temps réel n’est pas seulement un problème de temps de
pecter sont diverses et que les réseaux locaux industriels doivent communication mais aussi et surtout dans de nombreux cas, un
fournir la qualité de service requise par l’application. C’est cette problème de temps de réponse du ou des processus d’application
variété des qualités de service qui a conduit à la prolifération de ces sollicités. Ce temps est évidemment indépendant du nombre de
réseaux. couches traversées. Comme nous l’avons déjà souligné au

paragraphe 3.2, ce n’est pas parce que l’on met moins de temps à Un minimum de la couche présentation est nécessaire, même si
transmettre ou à recevoir que l’on respecte mieux les contraintes de le modèle réduit ne la mentionne pas. Les problèmes de syntaxes
temps [15] [16] [17]. différentes existent toujours si les systèmes sont hétérogènes. Si on
ne transfère pas la syntaxe de chaque message à chaque fois, il faut
Les réseaux locaux industriels présentent donc différentes archi-
toutefois qu’elle soit connue de l’émetteur et des récepteurs. Cela
tectures à sept couches ou moins selon le modèle OSI intégral ou
peut être défini lors d’une phase de configuration, justifiant ainsi le
selon des modèles réduits. Nous analysons ci-après les raisons pour
fait que cette couche n’apparaît plus dans l’architecture.
lesquelles certaines couches peuvent être oubliées. Pourquoi trois
couches et lesquelles ? Et avec quels services ? Quelles sont les rai- La couche application est évidemment nécessaire. Elle offrira des
sons pour concevoir un réseau selon l’architecture à trois couches ? services selon le modèle client-serveur, producteur-consommateurs
Et quels types de service doit-on y trouver pour offrir un aspect ou producteurs-distributeur-consommateurs. Au-dessus viendront
temps réel ou temps critique ? 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 communi-
Pour satisfaire des aspects temporels, il ne s’agit pas seule- cation de ces constituants ou le comportement des fonctions vu de
ment d’édulcorer le modèle OSI mais aussi d’intégrer des méca- la communication, cela afin d’améliorer l’interopérabilité des dispo-
nismes de gestion du temps. N’oublions pas que le modèle OSI sitifs, voire d’assurer ultérieurement l’interchangeabilité d’appareils
est né de l’expérience acquise dans les grands réseaux essen- analogues.
tiellement à commutation de paquets et que le temps n’a jamais En conclusion, les modèles réduits sont à trois ou quatre cou-
été pris en compte dans ce modèle. Il serait donc assez para- ches. Notons que dans le cas où des services d’application peuvent
doxal de vouloir traiter du temps et en particulier respecter des être utilisés dans différentes architectures de communication, ils
contraintes temporelles en s’appuyant sur un modèle qui n’y peuvent devoir être implantés sur une couche LLC ; il est alors
fait jamais référence. nécessaire de prévoir une adaptation entre application et LLC. Cette
couche, dans le cas de Profibus, est appelée LLI (Lower Layer Inter-
face). Dans le cas du réseau WorldFIP, pour pouvoir utiliser les servi-
3.3.1 Quelles couches ? ces MMS sur la couche liaison de données, une couche dite MCS
(Messaging Common Services) assure des fonctionnalités relevant
de la couche transport et de ACSE (Association Control Service
Il est clair que la couche physique est nécessaire. On ne peut s’en Element).
passer quel que soit le support de transmission utilisé.
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 3.3.2 Caractéristiques des services/protocoles
éventuellement une communication fiable entre deux ou plusieurs des réseaux industriels
stations. Elle inclut, comme dans le modèle IEEE 802, la sous-
couche MAC puisque l’on suppose qu’un support est partagé entre
les stations connectées. Cette couche n’est pas toujours spécifiée Nous avons présenté les concepts généraux des services et proto-
indépendamment de la couche LLC et l’est parfois en conjonction coles indépendamment de l’usage qui peut en être fait. Nous repre-
avec la ou les couches physiques possibles dans un réseau donné. nons ici ces concepts à la lumière des besoins des réseaux locaux
La couche réseau et la couche transport ont été introduites dans industriels répertoriés ci-avant.
le modèle OSI pour intégrer le fait que la communication entre deux
abonnés passait par des stations ou des nœuds intermédiaires, les 3.3.2.1 Point à point, multipoint, diffusion
commutateurs, qui assurent le routage. Il fallait donc fournir le ser-
vice de routage des paquets (couche réseau) et assurer un contrôle Les spécifications des réseaux de terrain et plus généralement
de bout en bout entre les deux abonnés (couche transport). des réseaux temps réel nécessitent la diffusion, le multipoint et le
point à point. Les protocoles actuellement normalisés ne s’intéres-
Ce contrôle de bout en bout est, dans l’esprit, du même type que
sent qu’aux communications point à point, à part les LLC type 1 et
celui qui est offert dans la couche liaison de données. La différence
les LLC type 3, sans avoir traité le problème de la diffusion fiable. On
est que ces services s’appliquent à des objets différents : une trame
remarquera seulement que les travaux de normalisation (en particu-
dans le cas de la couche liaison de données, un message composé
lier à propos des réseaux de terrain au sein de la CEI, Commission
éventuellement de plusieurs paquets (et donc trames) dans le cas de
électrotechnique internationale) ont conduit l’ANSI (American Natio-
la couche transport. Dans les deux cas, il s’agit d’offrir un service fia-
nal Standard Institute) à engager de nouvelles réflexions sur les ser-
ble de transmission d’une certaine quantité d’information. La cou-
vices et protocoles multipoints en 1991 [18], sachant que la
che réseau est donc nécessaire si des sous-réseaux sont utilisés.
principale norme qui accepte la diffusion est la norme CEI 61158 [19],
Si la couche réseau n’est pas nécessaire, à supposer que le réseau composée de huit spécifications de réseaux différents [20], qui
de terrain ne soit pas constitué de sous-réseaux, le contrôle de bout seront étudiées dans les articles suivants [S 7 575] [S 7 576].
en bout de la couche transport peut être toujours nécessaire. En Une question est de savoir si un émetteur a connaissance ou non
effet, le problème des messages multipaquets (fragmentation et des récepteurs dans le cas de communication en multipoint. Ce
réassemblage) subsiste, qui ne serait pas résolu sans couche trans- n’est pas nécessaire, ni même possible dans le cas de la diffusion
port. Si on fait l’hypothèse de messages courts et si l’on adapte les générale, et cela doit être traité en relation avec le fait qu’une con-
trames de la couche liaison de données aux plus longs messages nexion existe ou non.
possibles, le rôle de la couche transport disparaît totalement.
Il est important de se rappeler que si le niveau application utilise
Notons que ne pas considérer de sous-réseaux n’empêche pas le modèle client-serveur, toutes les communications à tous les
d’accepter que le réseau puisse être formé de plusieurs segments niveaux OSI seront point à point. Les liaisons multipoints ne sont
reliés par des ponts, voire de plusieurs tronçons physiques reliés utiles que pour les autres modèles de coopération.
par des répéteurs.
En ce qui concerne la couche session dont le rôle dans le modèle 3.3.2.2 Protocole avec ou sans connexion
OSI trouve son origine dans des échanges de grandes quantités
d’informations, elle n’apparaît pas nécessaire dans de nombreux L’habitude des protocoles avec connexion est née avec les
cas. réseaux publics, ne serait-ce que pour pouvoir affecter dynamique-

ment les ressources nécessaires et les comptabiliser. Dans les le contrôle de l’utilisateur, c’est-à-dire sous le contrôle des proces-
réseaux locaux industriels, le problème se pose autrement. Tout sus d’application [4].
dépend de la dynamique que l’on veut accepter dans la gestion des
communications entre les processus, et bien sûr dans celle des res- Que faire quand dans une architecture, on ne dispose que de trois
sources nécessaires. couches : acquitter au niveau 2 ? Au niveau 7 ? Par les processus
eux-mêmes ? À l’un et à l’autre ou nulle part ?
Exemple 8
Une station ne possède qu’un processus cyclique. Il est en commu- La solution est d’abord de tenir compte du type d’échange ou
nication selon le modèle producteurs-distributeur-consommateurs d’une certaine sémantique des informations transmises selon qu’il
avec d’autres qu’il ne connaît pas. Il doit donc localement disposer de s’agit d’événements ou d’états.
tampons en réception et d’autres en émission. Tout est connu à la con-
figuration du système, il n’a pas besoin d’ouvrir de nouvelles con- Dans le premier cas, on ne transmet que de façon aléatoire quand
nexions intempestivement pour établir des relations dynamiquement quelque événement s’est produit ; il est important de s’assurer que
avec d’autres processus. 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 con-
Exemple 9 nus d’acquittement, d’attente de réponse pendant un délai donné,
Un ordinateur de pilotage de cellule, à certains moments et compte etc. Mais combien de temps ces échanges prendront-ils ?
tenu de l’état des machines de la cellule, peut devoir demander le télé-
chargement d’un nouveau programme à partir de plusieurs machines Dans le second cas où l’on transmet des états périodiques, le pro-
possibles. C’est un cas où l’usage de protocoles avec connexion blème de la sécurité des transmissions se pose autrement car le
s’impose. Si ce n’était pas possible, il faudrait avoir établi toutes les récepteur attend quelque chose. Il peut se rendre compte à certains
relations possibles et donc avoir réservé des ressources de façon per- instants que ce qu’il attendait n’est pas arrivé et prendre les disposi-
manente pour un usage épisodique. La connexion est par ailleurs utile tions nécessaires à la situation.
pour des raisons de sécurité.
On ne transmet habituellement dans les réseaux généraux que
On utilise souvent des protocoles avec connexion à différents lorsque l’on a quelque chose à émettre, c’est-à-dire sur un événe-
niveaux du modèle OSI. Le modèle client-serveur utilise des asso- ment, et ce pour de multiples raisons, y compris la minimisation du
ciations (connexions de la couche application) point à point entre nombre des échanges. Dans les réseaux de terrain, les producteurs
processus. Les protocoles usuels de niveau 6, 5 et 4 le font éga- de données ont l’habitude d’émettre de façon périodique, que la
lement. Dans le profil MAP, seules les couches 2 et 3 sont sans con- valeur de l’information ait changé ou non. Cela est vrai aussi bien
nexion. pour les capteurs que pour les régulateurs ou les automates.
Dans le cas des réseaux de terrain, on peut considérer que l’on est Donc, dans les réseaux de terrain, au moins en ce qui concerne les
dans un milieu où n’importe quelle entité ne va pas décider brutale- échanges périodiques, on peut penser que les acquittements ne
ment de communiquer avec n’importe quelle autre. On a connais- sont pas nécessaires. On notera aussi que si une donnée est diffu-
sance des processus d’application et donc des sites qui sont sée toutes les 20 ms, à quoi cela sert-il de demander une réémission
concernés par soit l’émission de certaines grandeurs, soit leur sur une erreur de transmission ?
réception. Alors pourquoi ne pas réserver a priori des ressources
Bien sûr, si trois, quatre ou dix fois de suite, l’information est erro-
pour satisfaire ces échanges sans obliger les processus concernés à
née, on devra certainement agir, mais cette action ne peut en aucun

ouvrir une connexion, négocier les paramètres, etc., chaque fois
cas être confiée au système de communication qui n’en a pas les
qu’ils veulent communiquer. Ces ressources peuvent être par exem-
moyens ; c’est le processus utilisateur qui seul pourra le faire.
ple une file d’attente, comme usuellement dans les protocoles ISO,
ou de simples tampons compte tenu du fait que les données ont une À cela s’ajoute le fait que gérer des acquittements en mode diffu-
durée de vie finie et que l’on peut parfois perdre une information au sion (restreinte ou généralisée) peut être très coûteux en charge
profit de la suivante. induite, voire impossible.
Notons que l’on retrouve les mêmes problèmes avec des solu-
On verra dans [S 7 576] que le réseau de terrain WorldFIP n’a pas
tions voisines dans le protocole RSVP du monde Internet qui permet
retenu d’acquittements de niveau liaison de données pour le trafic
au niveau de la couche réseau de réserver les ressources
périodique ou apériodique d’objets identifiés mais uniquement
nécessaires, en particulier pour la transmission d’informations mul-
pour la messagerie classique.
timédias.
L’opération de réservation de ces ressources qui ensuite pour-
raient être allouées de façon permanente ressemble à s’y 3.3.2.4 Contrôle de flux
méprendre à une ouverture de connexion. La fermeture serait alors
la suppression de ces réservations. En conclusion sur ce point, on Dans les réseaux généraux, le contrôle de flux dynamique, en
voit que la notion de connexion « permanente » paraît bien adaptée ligne, a été rendu nécessaire par le caractère aléatoire des échanges.
à ce cas, situation que l’on peut rapprocher d’autres cas connus Éviter les congestions des stations intermédiaires ou terminales a
comme le circuit virtuel permanent dans le protocole X25 de com- été une des préoccupations majeures et compréhensibles des con-
mutation de paquets. cepteurs.
Comme à propos des connexions, le contrôle de flux s’impose

3.3.2.3 Protocole avec acquittement ou non dès que la densité des échanges varie de façon impromptue. À partir
du moment où les trafics sont mieux connus et maîtrisés, il faut
La plupart des protocoles usuels de niveau 2 et 4 des télé- repenser le problème. Si les trafics sont maîtrisés, cela veut dire
communications utilisent les acquittements avec ou sans anticipa- qu’un certain contrôle de flux a été mis en place, par exemple à la
tion. On a vu que dans le cas des réseaux locaux industriels et temps configuration, en limitant naturellement les demandes d’émission.
réel, il ne suffit pas qu’un message soit reçu sans erreur pour qu’il C’est le cas dans la mise en œuvre des trafics périodiques ; on peut
soit correct, encore faut-il que du point de vue temporel, le message alors dimensionner a priori le réseau, compte tenu des contraintes
soit valide. Cet aspect temporel est important à prendre en compte de l’application, de façon à éviter certains types de congestion. Le
pour savoir si des acquittements sont judicieux ou non. C’est pour caractère périodique de nombreux échanges contribue à réguler de
cela qu’une des demandes des utilisateurs de réseaux temps réel lui-même le flux. On sait qu’a priori, on ne pourra pas dépasser le
est de placer la gestion ou, mieux, le recouvrement des erreurs sous débit maximum.

4. Conclusion — des réseaux

périodiques ;
dans lesquels les échanges sont plutôt
— des réseaux devant assurer des échanges contraints par le

On a vu qu’une analyse des architectures selon les types de maté- temps.
riels conduisait à distinguer parmi les réseaux locaux industriels soit
En fait, n’importe quel réseau local industriel peut présenter cha-
des réseaux de terrain, soit des réseaux de cellule, d’usine. Mais
cune de ces caractéristiques et son opposé. Aucun réseau n’a à
l’analyse des besoins en communication des processus d’applica-
assurer que du trafic périodique, comme aucun réseau n’assure que
tion répartis conduit à distinguer :
des échanges contraints.
— des réseaux fonctionnant selon le modèle client-serveur ou
selon celui des producteurs-consommateurs ; On en conclut donc qu’un réseau local industriel devrait présenter
— des réseaux avec une architecture en trois, quatre ou sept différents profils [21] [22] pour satisfaire ces différents besoins ou au
couches ; moins un profil temps réel et un autre. Cela est rarement le cas.
— des réseaux dans lesquels est privilégiée la transmission Dans la réalité, un réseau présente un profil et il faut s’en contenter,
d’états périodiques ou celle d’événements ; c’est-à-dire en tenir compte pour décider de la répartition des fonc-
— des réseaux dans lesquels certains comportements sont tions et traduire l’expression des échanges quelle que soit leur
définis statiquement ; diversité en fonction des services fournis par le profil.
Bibliographie
Références [10] APVRILLE (L.). – Contribution à la reconfigu- [19] CEI. – Digital data communications for
ration dynamique de logiciels temps réel measurement and control – Fieldbus for use
embarqués : application à un environnement in industrial control systems. CEI 61158
[1] ZIMMERMANN (H.). – OSI reference model.
de télécommunication par satellite. Thèse de (2003).
The ISO model of architecture for open sys-
doctorat, Institut national polytechnique de
tem interconnection. IEEE Trans. on Commu- [20] LEVITI (P.). – IEC 61158 : an offence to techni-
Toulouse (2002).
nications COM-28 no 4, pp. 425-432 (avr. cians. IFAC Int. Conf. on Fieldbus Systems
1980). [11] BROWN (P.F.) et Mc LEAN (C.R.). – The archi-
tecture of the NBS factory automation and their Applications, FET’2001, Nancy,
[2] PUJOLLE (G.). – Les réseaux. Eyrolles (2000). France, Pergamon, pp. 9-16 (2001).
research testbed. Congrès IFAC, Munich, RFA
[3] GRANT (K.). – Users requirements on time (1987).
critical communications architectures. Tech- [21] THOMESSE (J.-P.). – A Review of the Fieldbu-
[12] THOMESSE (J.-P.). – Les réseaux locaux à ses. Annual Reviews in control, 22, pp. 35-45
nical Report ISO TC184/SC5/WG2/TCCA (avr. temps critique. Colloque AFCET, Le Temps
1992). (1998).
Réel, Nantes, pp. 29-40 (oct. 1990).
[4] European Map Users Group. – User require- [13] SIMONOT (F.) et VERLINDE (C.). – Importance [22] THOMESSE (J.-P.). – Fieldbuses and interope-
ments for communications in time critical d’un cadre de référence dans la mise en rability. Control Engineering Practice, 7,
applications. Réf. ISO/TC184/SC5/WG2-N180 place d’une démarche de développement pp. 81-94 (1999).
(fév. 1989).
d’un système automatisé de production.

[5] Interconnexion de systèmes ouverts (OSI). Actes de la conférence canadienne sur
Tome 1 : Modèle de référence de base. l’automatisation industrielle, Montréal,
AFNOR. Canada (juin 1992). Dans les Techniques de l’Ingénieur
[6] CRISTIAN (F.), AGHILI (H), STRONG (R.) et [14] DAKROURY (Y.). – Spécification et validation
DOLEV (D.). – Atomic broadcast : from sim- d’un protocole de messagerie multi-serveurs
ple message definition to byzantine agree- pour l’environnement MMS. Thèse de docto- RUBINO (G.) et TOUTAIN (L.). – Réseaux locaux.
ment. Proc. FTCS 15, Ann Arbor, Michigan, rat, université de Nantes (1990). [H 1 418], traité Technologies logicielles – Archi-
pp. 200-206 (1985). tectures des réseaux (1998).
[15] LE LANN (G.). – Designing real time depen-
[7] BRES (G.). – Panorama sur les généraux dable distributed systems. Rapport INRIA THOMESSE (J.-P.). – Les réseaux locaux industriels.
byzantins. TSI, 10, no 5, pp. 341-353 (1991). no 1425 (avr. 1991). Normes. [S 7 575], traité Informatique indus-
[8] GALARA (D.) et THOMESSE (J.-P.). – Groupe [16] LE LANN (G.). – Critical issues in distributed trielle (titre provisoire, à paraître).
de réflexion FIP. Proposition d’un système de real time computing. Workshop on Commu-
transmission série multiplexée pour les nication networks and distributed operating THOMESSE (J.-P.). – Les réseaux locaux industriels.
échanges d’informations entre des capteurs, systems (24-26 oct. 1989). Principaux profils. [S 7 576], traité Informatique
des actionneurs et des automates réflexes. industrielle (titre provisoire, à paraître).
[17] ELLOY (J.-P.). – Les contraintes du temps réel
Ministère de l’Industrie et de la Recherche dans les systèmes industriels répartis. Jour- RACHID (A.) et COLLET (F.). – Bus CAN. [S 8 140],
(1984). Réédité par Éditions KIRK (1991). née SEE, Grenoble (6 juin 1990). Paru dans traité Informatique industrielle (2000).
[9] THOMESSE (J.-P.). – Le réseau de terrain FIP. RGE no 2/91, p. 26 (fév. 1991).
Revue Réseaux et Informatique Répartie, [18] ANSI. – Multipeer/multicast workshop. BAJIC (E.) et BOUARD (B.). – Réseau Profibus.
no 3, Hermès, pp. 287, 321 (oct. 1993). Orlando, États-Unis (6-8 août 1991). [S 8 160], traité Informatique industrielle (2001).

Gagnez du temps et sécurisez vos projets
en utilisant une source actualisée et fiable
   
RÉDIGÉE ET VALIDÉE MISE À JOUR 100 % COMPATIBLE SERVICES INCLUS
PAR DES EXPERTS PERMANENTE SUR TOUS SUPPORTS DANS CHAQUE OFFRE
NUMÉRIQUES
 + de 340 000 utilisateurs chaque mois

12 000 articles de référence et fiches pratiques
 + de 10
 Des Quiz interactifs pour valider la compréhension
SERVICES ET OUTILS PRATIQUES
  
Questions aux experts* Articles Découverte Dictionnaire technique multilingue Archives Info parution
Les meilleurs experts techniques La possibilité de consulter 45 000 termes en français, anglais, Technologies anciennes et versions Recevez par email toutes les nouveautés
et scientifiques vous répondent des articles en dehors de votre offre espagnol et allemand antérieures des articles de vos ressources documentaires
*Questions aux experts est un service réservé aux entreprises, non proposé dans les offres écoles, universités ou pour tout autre organisme de formation.
Les offres Techniques de l’Ingénieur

INNOVATION ENVIRONNEMENT – SÉCURITÉ ÉLECTRONIQUE – PHOTONIQUE PROCÉDÉS CHIMIE – BIO – AGRO
• Éco-conception et innovation responsable • Sécurité et gestion des risques • Électronique • Formulation
• Nanosciences et nanotechnologies • Environnement • Technologies radars et applications • Bioprocédés et bioproductions
• Innovations technologiques • Génie écologique • Optique – Photonique • Chimie verte
• Management et ingénierie de l’innovation • Technologies de l’eau • Opérations unitaires. Génie de la réaction
• Smart city  Ville intelligente • Bruit et vibrations TECHNOLOGIES DE L’INFORMATION chimique
• Métier : Responsable risque chimique • Sécurité des systèmes d’information • Agroalimentaire
MATÉRIAUX • Métier : Responsable environnement • Réseaux Télécommunications
• Bois et papiers • Le traitement du signal et ses applications SCIENCES FONDAMENTALES
• Verres et céramiques ÉNERGIES • Technologies logicielles – Architectures des • Mathématiques
• Textiles • Hydrogène systèmes • Physique Chimie
• Corrosion – Vieillissement • Ressources énergétiques et stockage • Sécurité des systèmes d’information • Constantes physico-chimiques
• Études et propriétés des métaux • Froid industriel • Caractérisation et propriétés de la matière
• Mise en forme des métaux et fonderie • Physique énergétique AUTOMATIQUE – ROBOTIQUE
• Matériaux fonctionnels. Matériaux biosourcés • Thermique industrielle • Automatique et ingénierie système BIOMÉDICAL – PHARMA
• Traitements des métaux • Génie nucléaire • Robotique • Technologies biomédicales
• Élaboration et recyclage des métaux • Conversion de l’énergie électrique • Médicaments et produits pharmaceutiques
• Plastiques et composites • Réseaux électriques et applications INGÉNIERIE DES TRANSPORTS
• Véhicule et mobilité du futur CONSTRUCTION ET TRAVAUX PUBLICS
MÉCANIQUE GÉNIE INDUSTRIEL • Systèmes aéronautiques et spatiaux • Droit et organisation générale de la construction
• Frottement, usure et lubrification • Industrie du futur • Systèmes ferroviaires • La construction responsable
• Fonctions et composants mécaniques • Management industriel • Transport fluvial et maritime • Les superstructures du bâtiment
• Travail des matériaux – Assemblage • Conception et production • Le second œuvre et l’équipement du bâtiment
• Machines hydrauliques, aérodynamiques et • Logistique MESURES – ANALYSES • Vieillissement, pathologies et réhabilitation du
thermiques • Métier : Responsable qualité • Instrumentation et méthodes de mesure bâtiment
• Fabrication additive – Impression 3D • Emballages • Mesures et tests électroniques • Travaux publics et infrastructures
• Maintenance • Mesures mécaniques et dimensionnelles • Mécanique des sols et géotechnique
• Traçabilité • Qualité et sécurité au laboratoire • Préparer la construction
• Métier : Responsable bureau d’étude / conception • Mesures physiques • L’enveloppe du bâtiment
• Techniques d’analyse • Le second œuvre et les lots techniques
• Contrôle non destructif
www.techniques-ingenieur.fr
 CONTACT : Tél. : + 33 (0)1 53 35 20 20 - Fax : +33 (0)1 53 26 79 18 - E-mail : infos.clients@teching.com

Réseaux Locaux Industriels - Concepts, Typologie, Caractéristiques

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Réseaux Locaux Industriels - Concepts, Typologie, Caractéristiques

Transféré par

Droits d'auteur :

Formats disponibles

Réf.

Réseaux locaux industriels -

Cet article est issu de : Automatique - Robotique | Automatique et ingénierie système

par Jean-Pierre THOMESSE

Pour toute question :

1. Réseaux et modèle OSI........................................................................... S 7 574 – 2

es réseaux locaux industriels ! « La littérature est prolifique sur le sujet. Les

journaux professionnels l’abordent régulièrement pour annoncer de nou-

tiwekacontentpdf_s7574 v1 Ce document a ete delivre pour le compte de 7200092269 - cerist // 193.194.76.5

RÉSEAUX LOCAUX INDUSTRIELS __________________________________________________________________________________________________________

1. Réseaux et modèle OSI 1.1.2 Réseau local

Un réseau local couvre une zone géographique limitée sur un

réseau radio ou plus généralement un réseau sans fil, wireless

tiwekacontentpdf_s7574 v1 Ce document a ete delivre pour le compte de 7200092269 - cerist // 193.194.76.5

_________________________________________________________________________________________________________ RÉSEAUX LOCAUX INDUSTRIELS

1.1.5 Réseau temps réel

tiwekacontentpdf_s7574 v1 Ce document a ete delivre pour le compte de 7200092269 - cerist // 193.194.76.5

RÉSEAUX LOCAUX INDUSTRIELS __________________________________________________________________________________________________________

La couche application a aussi été structurée avec l’expérience.

1.2.4.1 Services, protocoles et profils

compte de la couche présentation. « unités de données de service (N ) » (N SDU ou N Service Data

tiwekacontentpdf_s7574 v1 Ce document a ete delivre pour le compte de 7200092269 - cerist // 193.194.76.5

_________________________________________________________________________________________________________ RÉSEAUX LOCAUX INDUSTRIELS

Utilisateur Fournisseur Utilisateur Utilisateur Fournisseur Utilisateur

a requête avec réponse b requête sans réponse

Utilisateur Fournisseur Utilisateur Fournisseur Utilisateur

c requête sans réponse d requête/indication

Fournisseur Utilisateur Utilisateur Fournisseur

e indication locale f requête sans suite Figure 2 – Services confirmés

tiwekacontentpdf_s7574 v1 Ce document a ete delivre pour le compte de 7200092269 - cerist // 193.194.76.5

RÉSEAUX LOCAUX INDUSTRIELS __________________________________________________________________________________________________________

débits nécessaires, des distances, des perturbations dues à l’envi-

tiwekacontentpdf_s7574 v1 Ce document a ete delivre pour le compte de 7200092269 - cerist // 193.194.76.5

_________________________________________________________________________________________________________ RÉSEAUX LOCAUX INDUSTRIELS

Ce mécanisme permet à une source de données de recevoir les

tiwekacontentpdf_s7574 v1 Ce document a ete delivre pour le compte de 7200092269 - cerist // 193.194.76.5

RÉSEAUX LOCAUX INDUSTRIELS __________________________________________________________________________________________________________

2.1 Architectures de systèmes et réseaux Historique

de normes existantes dans les couches basses et définissait des services

tiwekacontentpdf_s7574 v1 Ce document a ete delivre pour le compte de 7200092269 - cerist // 193.194.76.5

_________________________________________________________________________________________________________ RÉSEAUX LOCAUX INDUSTRIELS

ou de sécurité des personnes, des machines et de l’environnement.

tiwekacontentpdf_s7574 v1 Ce document a ete delivre pour le compte de 7200092269 - cerist // 193.194.76.5

RÉSEAUX LOCAUX INDUSTRIELS __________________________________________________________________________________________________________

— les types de trafics. Les trafics peuvent être classés en trafics

tiwekacontentpdf_s7574 v1 Ce document a ete delivre pour le compte de 7200092269 - cerist // 193.194.76.5

_________________________________________________________________________________________________________ RÉSEAUX LOCAUX INDUSTRIELS

tiwekacontentpdf_s7574 v1 Ce document a ete delivre pour le compte de 7200092269 - cerist // 193.194.76.5

RÉSEAUX LOCAUX INDUSTRIELS __________________________________________________________________________________________________________

Lire un enregistrement ‹‹ fabriquer 100 pièces ››

Figure 5 – Fonctions d’accès à un fichier Commande Commande Commande

Figure 7 – Commande de cellule

Figure 6 – Commande de robot N1 N2

Exemple 3 : système automatisé de production (N -1)1 (N -1)2 (N -1)3 (N -1)4

Figure 8 – Modèle 3-axes

tiwekacontentpdf_s7574 v1 Ce document a ete delivre pour le compte de 7200092269 - cerist // 193.194.76.5

_________________________________________________________________________________________________________ RÉSEAUX LOCAUX INDUSTRIELS

d’un service qui initialise l’échange au moment où il le faut. En

■ Flux horizontaux : ils représentent les échanges d’informations

tiwekacontentpdf_s7574 v1 Ce document a ete delivre pour le compte de 7200092269 - cerist // 193.194.76.5

RÉSEAUX LOCAUX INDUSTRIELS __________________________________________________________________________________________________________

3. Réseaux locaux industriels