Rapport Stage Isim

Conception d'un outil de configuration multi-automates
Je tiens à remercier tout particulièrement Daniel WEIL et Eric VATIN pour leur
encadrement, leur disponibilité et pour l’ensemble des conseils avisés.
Je tiens également à remercier Phillipe AUDFRAY le PDG de ATHYS de m’avoir donné
l’occasion de découvrir son entreprise et Franck Combet BLANC le chef du projet pour ses
conseils précieux et sa bonne humeur.
Je remercie également les autres membres de l’entreprise pour leur accueil chaleureux et leur
sympathie.
Jalal BENALLAL Juin 2003

2
INTRODUCTION : ................................................................................................................ 4
I. PRESENTATION DE LA SOCIETE DU STAGE :.................................................. 5
I.1 PRESENTATION DE LA SOCIETE :..................................................................................... 5

I.2 MARCHE VISES ET PRODUITS :........................................................................................ 5
I.2.1 MARCHE VISE: ................................................................................................................ 5
I.2.2 LE PRODUIT CELLCONTROL............................................................................................ 6
I.2.3 LE LANGAGE SFC+ : ...................................................................................................... 7
I.3 PRESENTATION DU SUJET DE STAGE : ............................................................................. 8
II. ETAT DE L’ART :........................................................................................................ 9
II.1 INTRODUCTION : ............................................................................................................ 9

II.2 SYSTEMES REACTIFS ET SYSTEMES TEMPS REELS : .................................................... 10
II.2.1 SYSTEMES REACTIFS :.................................................................................................. 10
II.2.2 SYSTEMES TEMPS REEL : ............................................................................................. 10
II.3 LES MODELES SYNCHRONES DE REPRESENTATION DES SYSTEMES DE COMMANDE: . 12
II.3.1 L’APPROCHE SYNCHRONE : ......................................................................................... 12
II.3.2 LE LANGAGE ESTEREL : ........................................................................................... 12
II.3.3 LES LANGAGES STANDARD DE LA NORME IEC 61131-3 :............................................ 16
II.3.4 LE NOUVEAU LANGAGE SFC+ :................................................................................... 17
II.4 LA REPARTITION DES SYSTEMES REACTIFS :............................................................... 18
II.4.1 BUT ET INTERET : ........................................................................................................ 18
II.4.2 L’APPROCHE SYNCHRONE ET LA REPARTITION : .......................................................... 18
II.4.3 PERSPECTIVE DE CETTE ETUDE :.................................................................................. 18
II.5 MISE EN RESEAU DE SYSTEMES REACTIFS :................................................................. 18
II.6 CONCLUSION : .............................................................................................................. 19
III. DEVELOPPEMENT : ................................................................................................ 20
III.1 SPECIFICATIONS : ....................................................................................................... 20

III.2 LOGICIELS ET MATERIELS UTILISES :........................................................................ 21
III.2.1 SYSTEME D’EXPLOITATION : ...................................................................................... 21
III.2.2 MODULE D’E/S DEPORTEES ....................................................................................... 21
III.3 ARCHITECTURE DETAILLEE DU PROJET : .................................................................. 23
III.3.1 PRESENTATION .......................................................................................................... 23
III.3.2 LE COMPOSANT MPCL_PRG_SFC ........................................................................... 24
III.3.3 LE COMPOSANT MPLC_KERNEL ............................................................................ 25
III.3.4 LE COMPOSANT MPLC_MAPPING .......................................................................... 26
III.3.5 LE COMPOSANT COS_THREAD ............................................................................... 27
III.3.6 LE COMPOSANT MBLC.............................................................................................. 28
III.4 EVOLUTIONS ET EXTENSIONS :................................................................................... 30
CONCLUSION : ................................................................................................................... 30
BIBLIOGRAPHIE : ............................................................................................................. 31
3
I. Introduction :
Le marché de la production d’objets est devenu une cible favorite des nouveaux concepteurs
de logiciels de pilotage et d’aide au pilotage des systèmes de production et cela devant le
grand progrès que connaît l’automatisation de ces systèmes.
ATHYS jeune entreprise, filiale du groupe DASSAULT SYSTEM propose une suite
logicielle, nommée CellControl, d’aide à la conception des ateliers de production et de leur
programmation. CellControl est proposé comme complément du logiciel de CAO 3D
robotique IGRIP de DELMIA.
ATHYS développe aussi un deuxième produit, c‘est un nouveau langage, nommé SFC+,
destiné à la spécification du comportement des systèmes automatisés. C’est un langage
proche au Grafcet et basé sur la sémantique du langage synchrone ‘Esterel’.
L'objectif de ce travail est de modéliser de manière plus précise le comportement d' une
cellule automatisée voir d' une ligne de production en décrivant son comportement avec le
langage SFC+ et en modélisant la répartition des programmes sur plusieurs automates
(programmation multi-automates). Il faudra tenir compte de la communication entre les
ressources (échange de messages sur un réseau) et des temps de propagation entre les
ressources de calculs ainsi qu'
entre les devices et les automates.
Dans un premier temps, j’ai fait un état de l’art sur les systèmes réactifs, les langages
synchrones, la norme IEC 61 131-3 utilisée vastement dans l’industrie manufacturier, et les
études déjà réalisées dans le domaine de la répartition des programmes: cette partie
correspond à la partie Recherche.
Puis j’ai développé un prototype qui met en pratique la méthode de répartition pour laquelle
j’ai opté. A la fin de ce rapport j’ai mis le point sur l’avancement global du travail, les
validations de certaines parties et les évolutions futures.

4
II. Présentation de la société du stage :

II.1 Présentation de la société :
Athys est une société créée au mois de juin 2000 après une année d’incubation à l’Institut
National de Recherche en Informatique et en Automatique Rhône-Alpes (INRIA). A ce jour,
la société compte 14 salariés.
ATHYS propose sur le marché une gamme de logiciels d’aide à la conception des ateliers de
production et de leur programmation. En effet elle propose un premier produit ‘CellControl’
qui permet de générer et/ou de simuler le contrôle des applications en s’appuyant sur le
logiciel de conception et simulation d’usine que fournit l’entreprise DELMIA (filiale de
Dassault Systèmes) pour la conception et la simulation 3D de l’atelier. Le deuxième produit
est un nouveau langage SFC+ destiné à la spécification du comportement des systèmes
automatisés c’est un langage proche au Grafcet et basé sur la sémantique d’Esterel.
Le groupe Dassault Systèmes, actionnaire principale de la société (avec 80% des actions)
assure la commercialisation de ces produits.
II.2 Marché visés et Produits :
II.2.1 Marché visé:
Le marché visé de la société est celui de l’automatisation de la production. Les leaders de ces
marchés sont les entreprises produisant les objets de consommation. Ces entreprises achètent
des lignes de fabrication à des intégrateurs, qui réalisent l’assemblage des différents
équipements nécessaires (robots, machines-outils, convoyeurs, sécurité, etc.) et réalisent la
mise en œuvre de l’ensemble, notamment le niveau logiciel. Le marché visé comprend donc
à la fois les prescripteurs et leurs fournisseurs intégrateurs.
Les intégrateurs utilisent quatre principaux types de produits :
• Logiciels de CAO, qui servent à modéliser les pièces. CATIA, le logiciel fourni par
Dassault Systèmes, est leader mondial ; il est utilisé par 40% des fabricants de voitures
mondiaux et notamment par tous les constructeurs européens.
• Logiciels de conception et simulation d’usine («Usine numérique» ou «Digital
Manufacturing»), utilisés pour le positionnement des machines dans l’espace, la gestion des
flux et la mise au point des trajectoires des robots et leur programmation. Les deux acteurs
mondiaux de ce secteur sont TECNOMATIX et DELMIA (filiale de DASSAULT Systèmes).
• Ateliers logiciels, servant à construire les logiciels pilotant les chaînes de fabrication. Ces
logiciels sont commercialisés par les fournisseurs de hardware (Siemens, Schneider,
Rockwell, …).
• Hardware, calculateurs de terrain, (Automates Programmables Industriels, API ou
PLC en anglais), bus de terrain, gestionnaires d’Entrées-Sorties, connectique, etc. Ce
matériel est fabriqué et commercialisé par de grands fournisseurs homologués déjà cités.
Pour des raisons historiques, les fournisseurs de logiciels de conception d’usines ne couvrent
pas la conception des logiciels de pilotage des usines. ATHYS SA propose un atelier logiciel
fondé sur deux grands axes stratégiques :
• Pouvoir générer et simuler le contrôle des applications en s’appuyant sur les logiciels
que fournit DELMIA pour la conception et la simulation 3D de l’atelier.

5
• Fournir des outils logiciels beaucoup plus performants, offrant notamment un haut
niveau de spécification et de sûreté : le langage SFC+.
II.2.2 Le produit CellControl
CellControl est un atelier logiciel fondé sur deux grands axes stratégiques :
• Pouvoir générer et simuler le contrôle des applications en s’appuyant sur les logiciels que
fournit DELMIA ‘IGRIP’ pour la conception et la simulation 3D de l’atelier.
• Fournir des outils logiciels beaucoup plus performants, offrant notamment un haut niveau
de spécification et de sûreté : le langage Estérel.
Les fonctionnalités qu’apportent ces produits permettraient de déterminer, dès la conception
de l’atelier, deux informations majeures de l’usine :
o Le comportement temporel de l’atelier (comment les machines communiquent
entre elles ? Quels sont les flux des pièces ?).
o Le temps de cycle de l’atelier (alors que les concepteurs n’ont actuellement que
la connaissance à l’avance des temps de cycle de chaque machine prise
séparément).
Les logiciels mis en place dans CellControl sont :
• Control-Design : c’est un logiciel proposé en option du logiciel 3D de DELMIA, nommé
IGRIP. Il permet de spécifier au moment de la conception de l’atelier en 3D quel sera le
comportement dans le temps de l’atelier ou mode opératoire et le temps de cycle de l’atelier.
• CellControl-PostProcesseur : option du produit précédent qui permet de traduire le code
produit par Control-Design en programme compatible avec des Automates programmables.
• Control-Monitor : c’est un logiciel, également fourni en option au logiciel IGRIP
compatible avec Control-Design. Il permet de valider un programme PLC en connectant via
OPC ses entrées/sorties sur une cellule IGRIP simulant la cellule robotique physique.
L'ensemble de ces logiciels constitue un atelier de développement de logiciels de pilotage de
chaînes automatisées.
Le tableau suivant (tableau 1) montre l’architecture des logiciels. Elle est décomposée en 8
composants :
Nom des
Nom de code Description
composants
Listing des différents outils d’une cellule
i-Control-Base IC_BASE
IGRIP.
Création du comportement d’une cellule et
i-Control-Design IC_DESIGN
simulation en utilisant Esterel.
Création du comportement d’une cellule et
simulation en utilisant des outils logiciels
i-Control-Monitor IC_MONITOR
pour PLC via OPC, ou autre système de
communication.
Simulation du comportement logique et
i-Control-Flow IC_FLOW
temporel d’une cellule IGRIP avec Esterel.
6
Génération automatique de critère de

i-Control-Verif IC_VERIF vérification pour le programme de vérification
formelle d’Esterel.
i-Control- Génération d’un code exécutable pour PLC
IC_POSTPRO
PostProcessor(PP) ou contrôleur de robots.
Visualisation du comportement réel d’une
i-Control-View IC_VIEW
cellule avec IGRIP.
Génération d’un code exécutable pour cible
i-Control-Exec IC_EXEC
temps réel.
Tableau 1 : Composants de CellControl
Les liens entre ces différents composants sont représentés sur la figure suivante (figure 1) :
i-C.Base
i-CFlow i-C.Design i-C.Monitor i-C.View
iC.PP i-C.Verif i-C.Exec
Indus. PC/
RTOS PLC
Figure 1 : Architecture de CellControl

II.2.3 Le langage SFC+ :
Toujours dans le domaine des systèmes automatisés, Athys développe un nouveau langage
de programmation destiné à la spécification du comportement des systèmes automatisés. Le
langage SFC+.
Le langage SFC+ est une extension du langage SFC (langage de la norme IEC 61 131-3), ce
nouveau langage remplit les faiblesses de la norme concernant SFC du point de vue de la
sémantique qui n’est pas toujours bien définie par la norme (ex: interprétation, hiérarchie...).
En effet SFC+ est un nouveau langage graphique. Sa définition reste très proche de celle de
SFC mais se basant sur une sémantique formelle qui est celle du langage Esterel.
Essentiellement , SFC+ permet:
• De garder toutes les caractéristiques du SFC classique (notion d’étape/transition).
• Détecter les ‘deadlocks’ et comportement ambigu à l’étape de compilation.
• De générer un code exécutable qui peut être utilisé pour la simulation et/ou pour
être exécuter par des automates sur site.
7
II.3 Présentation du sujet de stage :

CellControl permet de modéliser le comportement d' une cellule automatisée. La partie
automate de ce modèle est écrite dans une version graphique du langage Esterel. Les bonnes
propriétés du langage synchrone Esterel (sémantique formelle, gestion propre du
parallélisme, ...) permettent de garantir a priori le bon fonctionnement d' une cellule
robotique. Actuellement, CellControl n' est utilisé que dans des buts de simulation en liaison
avec l'outil IGRIP de Delmia (figure 3).
Figure 2: Lien entre CellControl et IGRIP

Le langage SFC+ se basant sur la sémantique d’Esterel est destiné à être intégré dans une
nouvelle génération d’automates industriels.
L'objectif de mon travail est de modéliser de manière plus précise le comportement d' une
cellule robotique voire d' une ligne de production en modélisant la répartition des
programmes sur plusieurs automates (programmation multi-automates). Il faudra tenir
compte de l' asynchronisme des ressources (il n' y a pas de lien direct entre le parallélisme
synchrone d' Esterel et le parallélisme physique des ressources), de la communication entre
les ressources (échange de messages sur un réseau) et des temps de propagation entre les
ressources de calculs ainsi qu'
entre les devices et les automates.
Mettre au point une méthodologie pour passer du modèle synchrone décrit avec le langage
SFC+ à une implantation réelle sur plusieurs ressources de calcul. On n' envisagera pas de
réaliser un outil de répartition automatique. Il s'
agit déjà de voir comment peut-on réutiliser
des modules SFC+ utilisés dans un premier modèle unique sur plusieurs automates. Il faudra
entre autre transformer les communications par signaux Esterel en communications réelles
(socket par exemple), utiliser les timers de l'
OS pour gérer le temps,...
L'objectif est donc de trouver une méthode qui permet de garantir que le code tournant sur
les automates est le plus proche possible du modèle réel.

8
III. Etat de l’art :

III.1 Introduction :
L’étude des systèmes réactifs [Harel et Pnueli 85] se focalise sur les problèmes liés au
contrôle des interactions avec l’environnement du système. Dans les logiciels critiques, ces
interactions sont en général nombreuses et complexes; elles sont par ailleurs la plupart de
temps soumises à des contraintes de temps de réponse (les systèmes dits « temps-réel » en
sont un bon exemple). De plus, une hypothèse raisonnable consiste à considérer qu’un
système réactif est censé fonctionner en permanence (la notion de terminaison n’est pas
pertinente). Un système réactif est ainsi généralement conçu comme un ensemble de tâches
infinies parallèles qui coopèrent à la réalisation d’un comportement complexe.
Les exigences de qualité des logiciels critiques et les considérations précédentes amènent,
d’une part à concevoir des langages de programmation spécifiques. Dans ce domaine, les
langages synchrones connaissent un succès important, dû essentiellement à la simplicité de
leur sémantique basée sur le principe de l’hypothèse de synchronisme, qui stipule que le
système réagit instantanément aux stimulations de son environnement. Ce principe permet
d’obtenir des programmes compilés très performants.
Néanmoins, la simplicité et la forte sémantique de ces langages synchrones n’est pas
suffisante devant des domaines d’application nécessitant une grosse puissance de calcul où
un contrôle réparti, A. Girault [GIR 94] a cité trois de ces domaines d’application pour
lesquels on est confronté à ce problème :
Les systèmes de traitement de signal complexes : Ces systèmes nécessitent de grosses
puissances de calcul. C’est essentiellement le problème auquel s’est attaqué l’équipe SYNDEX
de l’INRIA en se proposant de répartir des programmes écrits dans le langage synchrone
SIGNAL sur des réseaux de transputers.
Les systèmes de contrôle-commande répartis : Ces systèmes sont très souvent répartis
géographiquement pour des raisons de localisation de capteurs ou d’actionneurs, de
compatibilité de gammes, et de sûreté de fonctionnement. La solution utilisée est alors de
programmer séparément chaque calculateur. Pour être maîtrisable, cette solution exige que
l’on étudie soigneusement la décomposition de l’application. Cependant, on peut estimer
préférable de représenter l’application sous la forme d’un programme synchrone unique, de
la mettre au point et de la vérifier sous cette forme, puis de chercher à produire le programme
objet de chaque calculateur en garantissant un comportement d’ensemble similaire .
Remarquons que, contrairement au cas précédent, le découplage de l’application en
calculateurs n’a pas à être automatique, mais doit obéir à des directives du programmeur.
Les tâches de longue durée : il se peut qu’une même application contienne des
composants ayant des dynamiques très diverses, de sorte qu’une machine ‘infiniment rapide’
pour certains composants ne puisse pas être considérée comme telle pour d’autres. Ce cas,
oblige à programmer séparément les divers composants, ce qui n’est pas très grave s’ils sont
indépendants, mais est plus gênant si ces composants communiquent, car cela rend difficile
une vérification d’ensemble. Les solutions que l’on peut proposer sont les mêmes que dans le
cas précédent, à ceci près que les divers composants pourront aussi bien résider sur le même
calculateur, et que l’on parlera donc de répartition en processus plutôt qu’en calculateurs.
Dans cet état de l’art nous allons présenter en premier lieu les systèmes réactifs et les
systèmes temps réels, dans la deuxième partie on mettra plus en avant le principale langage

9
synchrone ‘ESTEREL’ et les langages définit dans la norme IEC 61131-3 utilisé dans
l’industrie manufacturier pour la description du comportement discret des automates
industriels. Puis par la suite, nous verrons différents méthodes et outils de gérer la répartition
et les communications entre systèmes réactifs, pour exposer à la fin notre propre besoin et la
méthode pour laquelle on a opté pour la mise en pratique.
III.2 Systèmes réactifs et systèmes temps réels :
III.2.1 systèmes réactifs :
Dans un sens large, le terme de système réactif peut être utilisé pour décrire tout système de
traitement de l’information ou système informatisé répondant continuellement à des stimulis
externes. Au contraire d’un système transformationnel (figure 1.1,a) qui accepte des données
en entrée et fournit des résultats en sortie, un système réactif (figure 1.1,b) réagit
continuellement et instantanément à des événements ou stimulis, qu’ils soient internes ou
externes [Har 88].
Figure 3: système transformationnel et système réactif
En d’autres termes, un système réactif est conduit par les événements, son comportement
dépend de ces derniers et de l’ordre avec lequel ces événements surviennent.
L’introduction de contraintes de temps inhérentes à l’application, c.à.d. aux processus à
contrôler, en spécifiant des délais avec lesquels seront fournies les réponses aux stimulis,
permet d’introduire la notion de système temps réel.
III.2.2 Systèmes temps réel :
Un système est dit temps réel s’il est capable de respecter de contraintes temporelles, en
d’autres termes, s’il est capable d’effectuer un traitement, d’élaborer une information qui ait
encore un sens relativement aux processus que le système est sensé contrôler. Cette définition
n’est pas complète ni d’ailleurs unique ; [Bro 84] donne une définition plus rigoureuse : une
application temps réel constitue un système de traitement de l’information ayant pour but de
commander un environnement imposé, en respectant les contraintes de temps et de débit

10
(temps de réponse à un stimulus, taux de perte d’information toléré par entrée) qui sont
imposées à ses interfaces avec cet environnement.
On considère usuellement deux grandes catégories d’applications temps réel :
• Applications temps réel à contraintes strictes (temps réel dur) : lorsque le non respect des
spécifications temporelles est assimilable à une panne temporelle pouvant entraîner des
dommages au système ;
• Applications temps réel à contraintes relatives, dans le cas contraire.
Les dommages au système, provoqué par le non respect des contraintes temps réel, peut
comporter des risques majeurs d’accidents. C’est notamment le cas, dans plusieurs domaines
d’applications comme :
Réacteurs chimiques ou nucléaires
Systèmes de transport
Domaine médical
Robotique et machine outils à commande numérique
Gestion, production et distribution d’énergie
Systèmes de télécommunications
Etc…
D’ailleurs tous ces applications ont en commun les caractéristiques suivantes [Gaf96]:
Contrainte temporelles fortes : les systèmes temps réel possèdent souvent des temps
d’exécution ou de réaction impératifs, il est même fréquent que les dépassements temporels
soient purement interdits dans certaines de ces applications.
Prévisibilité et sûreté : en fonctionnement normale, toutes les évolutions (ou leurs
conséquences) doivent être prévisibles. De tel systèmes sont qualifiés de déterministe.
Fiabilité : le risque de panne doit être le plus faible possible.
Robustesse : lorsque l’environnement n’est plus celui prévu ou que l’un des organes
tombe en panne, le système global doit être capable de prendre un mode de
fonctionnement dégradé sécurisé.
Parallélisme et répartition : le processus à commander est souvent constitué de
plusieurs tâches concurrentes. Ceci impose la mise en place de mécanismes de
synchronisation et d’ordonnancement spécifiques aux contraintes temps réel.
Hiérarchie : par soucis de simplification, il est courant de définir un système de
contrôle comme chef d’orchestre de sous-systèmes dont chacun ne gère qu’une partie
de l’application. A leur tour, ces sous-systèmes peuvent se décomposer en des systèmes
plus élémentaires (en particulier dans les systèmes flexibles).
La programmation des systèmes réactifs conciliant un parallélisme logique nécessite une
approche synchrone de programmation (facilitant une description modulaire) avec une
exécution déterministe. Principalement développée en France, cette approche connaît un
succès certain dans l’industrie (avionique, transports, énergie, CAO de circuits). Située à la
frontière de l’informatique et de l’automatique, elle satisfait bien les besoins critiques de ces

11
systèmes. Dans la partie suivante, on détaillera plus cette approche et nous mettrons en
lumière les principaux modèles synchrones de représentation des systèmes de commande.
III.3 Les modèles synchrones de représentation des systèmes de
commande:
III.3.1 L’approche synchrone :
Spécialement destinée à la programmation des systèmes réactifs temps-réel [BB 91].
L’approche synchrone facilite la tâche du programmeur en lui donnant des primitives idéales
de concurrence et de communication : la réaction à un événement d’entrée est supposée
instantanée, ce qui rend les sorties strictement synchrones avec les entrées.
Figure 4 :Exécution d'un système de type réactif.
En pratique, le synchronisme est l’hypothèse que l’application réagit assez rapidement pour
appréhender ses entrées dans un ordre correct et produire toutes ses sorties avant la réaction
suivante.
D’après N. Richard [RIC 2000], le développement d’une application temps-réel réactive doit
être un processus rigoureux, nécessitant des outils adaptés, en particulier des langages pour la
spécification et des outils fiables pour la vérification automatique ; et selon H. Boufaïed
[BOU 98], les solutions traditionnelles n’apportant pas de solution satisfaisante à la
programmation de systèmes réactifs temps-réel, il a été proposé de développer des langages
dédiés plutôt que d’adapter des langages existants. Cela devait permettre de prendre
directement en compte les spécificités de ces systèmes à un haut niveau d’abstraction, en
particulier le déterminisme et le contrôle fin des processus réactifs, malgré la complexité des
comportements décrits. Le modèle synchrone a alors été introduit et de nombreux langages
sont maintenant basés sur cette approche.
Une certaine révolution est apparue avec l’arrivée des langages synchrones comme
ESTEREL, LUSTRE ou SIGNAL. Ils ont en effet permis de définir des sémantiques de
comportements rigoureuses et assurent au niveau implantation que le code généré sur la
machine cible aura rigoureusement le même comportement que le modèle de départ [BGP
93]. Pourtant malgré leurs progrès, les langages synchrones ne font pas encore partie de la
culture industrielle.
S’intéressant plus particulièrement aux systèmes réactifs dans le domaine manufacturier,
nous avons choisi d’exposer le principal langage synchrones ‘ESTEREL’ et les principaux
langages de la norme IEC 61131-3 largement utilisée pour la description des comportements
discrets dans l’industrie manufacturier.
III.3.2 Le langage ESTEREL :

ESTEREL est un langage réactif synchrone de nature impérative, basé d’une part sur des
structures de contrôle comme l’itération, la séquence et la composition parallèle déterministe,
et d’autre part sur un ensemble d’instructions dites réactives faisant référence aux
12
événements auxquels le système décrit doit réagir. La communication et la synchronisation

entre les différentes composantes d’un programme ESTEREL se fait par diffusion
instantanée de signaux correspondant à ces événements [RIC 99]. Une présentation complète
du langage est disponible dans [BER 99]; ouvrage du créateur de ce langage G.Berry
chercheur à l’INRIA Sophia-Antipolis et au CMA-Ecole des Mines de Paris. On exposera ici
les principales caractéristiques de ce langage d’après [RICH 2000].
III.3.2.1 Principes de base du langage :
Chaque signal est caractérisé par son statut, c’est-à-dire par sa présence ou son absence au
cours d’un instant. Il peut être émis par l’environnement si c’est un signal en entrée, ou par le
programme ESTEREL avec l’instruction emit si c’est un signal en sortie. Les signaux sont
diffusés instantanément et sont visibles dans toutes les composantes parallèles du
programme: un signal émis par une composante est reçu par toutes les autres composantes
dans le même instant.
La figure suivante (figure 5) illustre un exemple d’attente concurrente et émission de
signaux.
Figure 5 : Attente concurrente et émission de signaux

III.3.2.2 Modules :
Un programme ESTEREL se présente sous la forme d’un module, qui peut être
récursivement composé de sous-modules. La communication entre un module et son
environnement est réalisée par des signaux. Un module est constitué d’une interface et d’un
corps. L’interface décrit notamment les signaux d’entrée et de sortie du module, c’est-à-dire
respectivement les signaux auxquels il doit réagir et les signaux qu’il peut émettre en
réponse. Le corps définit le comportement du module, sous la forme d’une composition
d’instructions réactives ou impératives.
La figure 6 représente un module ESTEREL M sous la forme d’une boîte noire possédant
une interface constituée d’entrées et de sorties pour la réception et l’émission de signaux.
Figure 6 : Représentation de l'interface d'un module ESTEREL

III.3.2.3 Caractéristiques du langage ESTEREL :
Signaux : Un signal pur est un simple indicateur d’événement, tandis qu’un signal
valué transmet de plus une information typée.

13
Expression de signaux : Il est possible d’utiliser les opérateurs booléens not, and et
or dans une expression testant la présence de signaux. L’exemple suivant émet le signal O1 si
les signaux I1 et I2 sont présents simultanément ou si le signal I3 est absent.
present [I1 and I2] or [not I3] then

emit O1
end present
Manipulations des données : Un module ESTEREL peut manipuler des valeurs de

type quelconque, à condition que ce type soit prédéfini ou qu’il soit déclaré dans la partie
interface du module. Les valeurs manipulées correspondent à des variables, à des constantes
ou à l’information transmise par un signal valué.
Préemption : Un mécanisme de préemption permet d’interrompre un traitement en
présence d’événements particuliers, en l’avortant ou en le suspendant. Les instructions de
préemption d’ESTEREL permettent d’exprimer de façon concise des comportements
sophistiqués ; les opérations disponibles sont la suspension, la préemption fort et la
préemption faible. Ces constructions, en particulier la préemption , sont souvent utilisées
pour représenter des compositions qui doivent s’exécuter dans un délai précis, écoulé lorsque
le signal de préemption est reçu. Une activité suspendue peut reprendre au point où elle a été
préemptée dès que les conditions de suspension ont disparu. L’instruction suspend est
retardée, le bloc encapsulé sera donc exécuté au moins une fois, la figure 7 illustre un
exemple simple de suspension de programme:
Figure 7 : Suspension sur réception de signal
Trappes : Le mécanisme de trappes d’ESTEREL permet de s’échapper d’un bloc

d’instructions en précisant le motif de sortie ; une trappe déclenchée dans un bloc peut être
rattrapée si un traitement spécifique est nécessaire. L’instruction trap définit une trappe qui
peut être utilisée dans son corps : si ce corps se termine, naturellement ou en déclenchant la
trappe (instruction exit), l’ensemble se termine instantanément. Dans l’exemple suivant
(figure 8), le corps du bloc trap déclenche la trappe T lorsque le signal I est présent, et émet
le signal O sinon. Le bloc trap se termine ici seulement si la trappe est déclenchée ; le signal
E est alors émis instantanément.
Figure 8 : Utilisation d'une trappe.

14
Composition de modules : Un module ESTEREL peut instancier d’autres modules

en utilisant l’instruction run et en spécifiant au besoin les correspondances (ou substitutions)
entre les signaux. L’exemple de la figure suivante (figure 9) montre comment créer, dans un
module P, deux instances M1 et M2 d’un module M, et comment faire correspondre les
signaux I1 et I2 de P aux signaux I de M1 et M2. Il est inutile de préciser la substitution de
deux signaux portant le même nom ; le signal O de P correspondra donc au signal O de M1 et
de M2.
Figure 9 : Exemple de composition de modules avec substitution de signaux.
Hiérarchie entre les modules : Nous pouvons alors considérer une hiérarchie entre
les modules : un module qui en instancie un autre peut être appelé module-père et un module
instancié est un module-fils. L’instanciation d’un module correspond à la recopie exacte du
corps de ce module, et à l’ajout des déclarations de son interface à celles de l’interface du
module-père. La substitution ne se limite pas à la correspondance entre signaux : elle
s’applique à tout ce qui peut être déclaré dans une interface de module, c’est-à-dire aux
types, aux constantes, aux fonctions et aux procédures. Cela permet en particulier de définir
des modules génériques, paramétrés lors de l’instanciation.
III.3.2.4 Compilation d’un programme ESTEREL :
Le compilateur ESTEREL produit entre autres un fichier C, représentant un automate à états
finis ou un circuit booléen. Ce fichier contient en particulier une fonction d’activation et une
fonction de positionnement pour chaque signal d’entrée. L’utilisateur doit fournir une
fonction de positionnement pour chaque signal de sortie, dans un fichier C séparé.
L’exécution d’une réaction est obtenue en appelant d’abord la fonction de positionnement de
chaque signal d’entrée présent, puis la fonction d’activation. L’émission d’un signal en sortie
provoque l’appel de la fonction correspondante, définie par l’utilisateur. L’exemple de la
figure 10, inspiré d’un exemple de [HAI 2000], montre la correspondance entre un module
ESTEREL (fichier M.strl) et les interfaces des fonctions C utilisées, présentes dans les
fichiers M.c (généré par le compilateur) et M_outputs.c (fourni par l’utilisateur).

15
Figure 10 : Exemple de correspondance Esterel/C.
III.3.2.5 Conclusion :
ESTEREL est un langage synchrone de nature impérative, adapté à la description de
systèmes temps-réel critiques ; il est par exemple utilisé chez DASSAULT-AVIATION pour
concevoir des systèmes avioniques. Ce langage permet de définir un système réactif sous la
forme d’un module, constitué de composantes parallèles communiquant par diffusion
instantanée de signaux. La description du comportement d’un module est réalisée à l’aide
d’instructions réactives explicites, comme la pause ou l’attente retardée d’un signal.
ESTEREL offre une remarquable puissance d’expression, tout en garantissant le
déterminisme du système décrit. En pratique, ce langage nécessite la mise en œuvre d’une
machine d’exécution, réalisant l’interface entre le système synchrone et son environnement
asynchrone. Des outils de vérification formelle sont disponibles, permettant de concevoir et
de valider des comportements complexes s’exécutant en parallèle. L’architecture d’un
système réactif décrit en ESTEREL est statique, ce qui permet de garantir la validité du
système pendant toute la durée de son exécution.
III.3.3 Les langages standard de la norme IEC 61131-3 :

III.3.3.1 LD: le langage ‘Ladder Diagram’ :
Le langage LD décrit le système d’un point de vue “Electro-mecanique” du système. Le
comportement est décrit par une série d’interrupteurs et de relais, connectés par des fils
(figure 11).
a b
x
c
Figure 11 : Exemple d'un programme en LD

L’avantage du langage LD est qu’il a une sémantique très simple et non ambigu. Par contre,
la description du comportement en LD n’est pas facile à maintenir ou à réécrire.

16
III.3.3.2 Le langage FBD: Function Block Diagram :

Le langage FBD est défini par une série de bloc de fonctions interconnectés par des signaux
internes (figure 12).
a
>= 1
&
c x
Figure 12 : Exemple en FBD.
III.3.3.3 Le langage SFC: Sequential Function Chart :

Le SFC est un graphe constitué de séquence d’étapes et de transitions reliées par des liaisons
orientées (figure 13).
Figure 13 : Programme en SFC

Ce langage, largement utilisé pour les automatismes logiques, permet très clairement
d’exécuter des séquences en parallèle. De plus ce modèle est synchrone; plusieurs transitions
peuvent être franchies simultanément. Des extensions du modèle permettent des descriptions
hiérarchisées (SFC partiels) et si on utilise la notion de forçage on peut prendre en compte
certaines formes de préemption.
Le SFC est largement diffusé dans le monde industriel. Il est d’ailleurs implanté sur de
nombreux automates programmables et constitue un outil aisé de spécification de la
commande. Il est utilisé comme modèle de base par de nombreux simulateur.
III.3.4 Le nouveau langage SFC+ :
L’idée de ce nouveau langage en cours de développement par l’équipe de ATHYS est de
proposer dans le marché de l’industrie manufacturière un langage à la fois proche de SFC et
complété par de nouvelles fonctionnalités comme par exemple la hiérarchie, l’avortement
faible ou fort, ou encore les restrictions dans les divergence en ET.
Le langage SFC+ tient sa forte sémantique du langage synchrone ESTEREL.

17
III.4 La répartition des systèmes réactifs :

III.4.1 But et intérêt :
Dans la réalité industrielle, les systèmes réactifs doivent être distribués sur plusieurs unités de
calcul pour diverses raisons , dont :
La répartition des tâches, afin de rendre le programme plus modulaire, ce qui
permettra facilement le changement en cas d’évolution ou d’extension par exemple de
composants qui constituent la chaîne complète ;
Le gain de performance, l’utilisation de plusieurs unités de calcul pouvant amener
une plus grande fréquence de réponse des applications ;
La délocalisation géographique des éléments du systèmes ;
La tolérance aux fautes, en dupliquant les partie sensibles de la chaîne.
III.4.2 L’approche synchrone et la répartition :
Dédiée à la programmation des systèmes réactifs temps-réel, l’approche synchrone se doit de
fournir aux programmeurs des mises en œuvres distribuées des spécifications réalisées à
l’aide des langages synchrones d’une part et de permettre la communication entre des
programmes réalisés séparément en respectant les contraintes de l’aspect temps réel d’un
autre part.
Plusieurs études ont été menés ou sont toujours en cours sur ce vaste sujet traitant d’un côté
la mise en communication entre plusieurs systèmes synchrones, et d’un autre côté la
répartition automatique des automates synchrones entre plusieurs ressources.
III.4.3 Perspective de cette étude :
Dans la perspective de la première approche (la mise en communication entre plusieurs
systèmes synchrones), et dans le but de trouver les nouvelles fonctionnalités du langage
SFC+, nous avons décidé d’utiliser les performances de ce langage pour modéliser d’une part
les systèmes réactifs, et d’un autre part de répartir les automates sur plusieurs ressources de
calculs de façon indépendante et de chercher le moyen de les communiquer.
III.5 Mise en réseau de systèmes réactifs :
Un système réactif devient séquentiel en lui ajoutant une mémoire et des ports de
communication. Il peut [BOU 96] recevoir des messages sur ses ports d’entrée et envoyer des
messages par l’intermédiaire de ses ports de sortie. Un réseau de processus séquentiels est
formé en connectant les ports des processus par des canaux. Un canal est une file FIFO de
taille infinie. Un processus communique de façon asynchrone avec les autres processus tout
au long de son exécution, en déposant des messages sur les canaux connectés à ses ports de
sortie et en récupérant les messages dans les canaux connectés à ses entrées. Cette
récupération est bloquante : un processus qui tente de prendre un message dans un canal vide
est bloqué jusqu’à ce qu’un message soit déposé sur le canal, auquel cas il peut reprendre son
exécution. L’envoi et la réception de messages sont les seuls mécanismes de synchronisation
disponibles ; il n’y a en particulier aucun partage de variables globales.
Un canal a au plus un processus producteur, capable de déposer des messages, et un
processus consommateur, capable de récupérer ces messages. Les canaux sans producteurs
constituent les entrées du réseau de processus et les canaux sans consommateurs
correspondent aux sorties du réseau ; ces entrées et ces sorties permettent l’interfaçage avec
18
l’environnement. La structure d’un réseau peut être modifiée dynamiquement, au cours de

l’exécution des processus : le nombre de processus et de canaux peut évoluer, et les
interconnexions peuvent être modifiées. Le déterminisme d’un réseau de processus
séquentiels est garanti si les hypothèses suivantes sont respectées :
– un processus ne peut pas tester si un canal est vide, afin que le comportement du réseau ne
dépende pas des différentes vitesses d’exécution des processus (ce qui le rendrait
indéterministe) ;
– un processus ne peut pas tenter de récupérer un message sur plusieurs canaux à la fois.
Le réseau de processus réactifs décompose les applications en zones réactives, dont les objets
partagent la même notion d’instant. Ces zones utilisent des mécanismes synchrones pour la
communication interne et des mécanismes asynchrones pour communiquer entre elles,
comme l’illustre l’exemple de la figure 14.
Figure 14 : Communication entre objets réactifs.
Les signaux d’entrée et de sortie sont l’interface du programme synchrone. Tout signal
d’entrée possède une méthode de connexion prenant comme argument un signal de sortie ;
cette méthode permet de déclarer explicitement des connexions point-à-point
unidirectionnelles entre objets synchrones. Des mécanismes de vérification assurent qu’un
signal d’entrée est bien connecté à un signal de sortie du même type.
La communication entre les objets synchrones et les autres objets du langage se fait au
travers d’une interface permettant de traduire les signaux synchrones en événements
asynchrones et vice-versa.
III.6 Conclusion :
Le réseau d’éléments synchrones fournit une solution plus dynamique de description de
systèmes réactifs. Des objets encapsulant des modules synchrones sont interconnectés pour
former des réseaux d’objets synchrones. Plusieurs objets synchrones peuvent être connectés à
une même entrée d’un autre objet synchrone. Les objets et les connexions peuvent être
ajoutés et retirés du réseau à tout moment de l’exécution du système, et les connexions
peuvent être modifiées. La communication asynchrone est possible avec les objets non
synchrones du système, constituant l’environnement du réseau d’objets synchrones. Les
réseaux de processus réactifs constituent également une solution dynamique et déterministe,
connectant par des canaux FIFO des processus s’exécutant en parallèle.

19
IV. Développement :
IV.1 Spécifications :
Le but du projet est de modéliser de manière plus précise le comportement d’une cellule, et
cela en modélisant la répartition des automates sur plusieurs ressources de calcul.
La principale tâche consiste à faire communiquer plusieurs programmes SFC+. La
communication se fera avec le modèle TCP/IP.
Le travail sera validé par la réalisation de la commande réparties d’un ou de plusieurs
modules d’entrées/sorties déportées.
On peut modéliser la structure de la commande dans la figure suivante (figure 15).
PLC I PLC II PLC I
Réseau de terrain Module I/O Module I/O

Déportées Déportées
Figure 15: Structure de la commande Multi-automates.
En effet, la commande de la cellule robotisée est répartie sur plusieurs automates, ces
derniers peuvent communiquer des signaux entre eux, envoyer des commandes aux
actionneurs (ici se sont les sorties des modules d’IO déportés) et recevoir les informations
des capteurs (les entrées des modules IO déportés).
Le travail consiste donc à réaliser une maquette d' un noyau d' exécution générique pour
permettre l'
exécution d’un programme SFC sur chaque automate, gérer les communications
au sein du réseau, et réaliser le mapping entre les signaux des différents automates. L’entité
automate sera mise plus en détail dans la section suivante. Ce travail s'
inscrit dans le cadre du
projet de R&D d’ATHYS.
20
IV.2 Logiciels et matériels utilisés :

IV.2.1 Système d’exploitation :
Pour la réalisation de notre maquette, nous avons pour commencer développer dans
l’environnement Windows 2000, sa capacité de gérer les threads et les timers étaient
suffisantes dans un premier lieu pour tester un première version du produit.
Dans une deuxième phase, nous utiliserons QNX pour exploiter son déterminisme et ces
caractéristiques d’un OS Temps Réel.
IV.2.2 Module d’E/S déportées
Afin de tester la communication avec l’environnement extérieur, nous avons utilisé un
module d’E/S déportées de marque WAGO. Ce module est composé d’un coupleur de bus de
terrain Ethernet TCP/IP et de 8 E/S digitales (figure 16).
Figure 16 : Module d'I/O déportées -Wago-

L’échange des données de processus est effectué à l’aide du protocole Modbus/TCP du
constructeur Schneider Electric. Le protocole Modbus sur TCP/IP utilise la messagerie
Modbus pour la couche application et TCP/IP pour la communication sur Ethernet. On peut
représenter l'
ensemble des couches réalisées pour Modbus sur TCP selon le modèle OSI
présenté dans la figure 17.

21
Figure 17 : Modèle OSI

Ce module est composé d' un coupleur de bus de terrain Ethernet TCP/IP supportant une série
de protocoles de réseau pour transmettre des données de processus via Ethernet TCP/IP, la
figure 18 illustre Ce coupleur de bus, la notice détaillée est mise en Annexe.
Figure 18 : Coupleur de bus de terrain; 10 Mbits/s
Les bornes d’entrées digitales de ce module (figure 19) permettent de raccorder au réseau des
capteurs et des contacts secs, la séparation galvanique bus de terrain/bornes est assurée par
des optocoupleurs, est aussi composé de 8 entrées et de 8 sorties numériques.

22
Figure 19 :Bornes d'entrées digitales à 4 canaux.

La transmission des signaux de commande aux actionneurs connectés se fait par
l’intermédiaire des bornes de sorties digitales (figure 20), toutes ces sorties sont protégées
des courts-circuits, et la protection galvanique bus de terrain/bus est assurée par des
optocoupleurs.
Figure 20 :Bornes de sorties digitales du module
IV.3 Architecture détaillée du projet :

IV.3.1 Présentation
Le projet est composé de plusieurs composants, chaque composant réalise une tâche précise,
le schéma suivant illustre la manière dont est organisée l’architecture globale.

23
Automate 2 Automate 1
MPLC_Prg_Sfc MPLC_Prg_Sfc
MPLC_Kernel MPLC_Kernel
MPLC_Mappin MPLC_Mappin
COS_THREAD MBCL COS_THREAD MBCL
MIOD1 MIOD2
Figure 21 : Architecture générale du projet
L’entité Automate est caractérisé par une adresse IP et un numéro de port de communication,
l’adresse IP peut ne pas être unique (pour avoir la possibilité de faire tourner deux
programmes automates sur la même machine), mais le numéro de port est unique pour
chaque automate. Chaque composant automate est constituée de 5 sous-composants :
• MPLC_Prg_Sfc : ce composant reçoit le fichier sfc qui contient le corps du
programme à exécuter par l’automate et communique les informations nécessaires au noyau
(MPLC_Kernel).
• MPLC_Kernel : ce composant constitue le noyau de l’application, c’est lui qui teste
les entrées reçues par le module MPLC_mapping et génère les sorties correspondantes.
• MPLC_Mapping : ce module gère tout ce qui est résolution d’adresse
d’acheminement et mapping des entrées/sorties du programme.
• COS_THREAD : ce module donne les fonctions nécessaires qui permettent de
communiquer avec les autres entités Automates, c’est à dire la réception et l’envoie de
signaux de communications.
• MBLC : le composant MBCL représente le pilote (driver) du module d’Entrées/Sorties
Déportées (IOD). Il permet la connexion, et la communication avec les modules
d’Entrées/Sorties.
Nous allons détailler à la suite les fonctions de chaque composant et son rôle dans la chaîne.
IV.3.2 Le composant MPCL_PRG_SFC
Chaque entité Automate contient un seul fichier SFC+ qui gère le comportement interne de
l’automate, ce fichier est compilé en langage C par le compilateur Camstrl.

24
Prg_Sfc.c
PtrFctSfc.cpp
compilation Programme
PtrFctInp.c SFC
MplcPrgSfc.dll
PtrFctOut.c
Figure 22 : le composant MPLC_PRG_SFC.
Le composant MPLC_PRG_SFC (figure 22), reçoit le fichier SFC+, et génère une Dll
(librairie dynamique), cette librairie contient les fonctions nécessaire à MPLC_Kernel pour
exécuter le programme compilé avec Camstrl.
Les différentes fonctions de ce composant sont :
• Generate_Interface_Prog() : cette fonction utilise la librairie dynamique camstrl.dll
pour générer l’interface de notre programme sfc, cette interface contient les informations
concernant les entrées et les sorites du programme, comme leurs types et noms.
• Generate_File_Fct_Reac(): cette fonction génère un fichier C++ qui contient un
pointeur sur la fonction principale du programme. Ce pointeur est utilisé par MPLC_Kernel
pour l’exécution pas à pas.
• Generate_Ptr_Fct_Input(): cette fonction génère un fichier C++ qui contient des
pointeurs sur les fonctions d’entrées qui doivent être lancées si l’entrée associée est activée
• Generate_Fct_Output(): cette fonction génère un fichier C++ contenant entre autres
un pointeur sur fonction qui retourne la liste des sorties et leurs valeurs générées pour
l’instant présent.
• Generate_Library : cette fonction compile le fichiers précédents et génère la librairie
dynamique MplcPrgSfc.dll qui va être utilisée par MPLC_Kernel.
IV.3.3 Le composant MPLC_KERNEL

Le composant MPLC_KERNEL est le noyau d’exécution permettant d’utiliser l’automate
(C) généré par Camstrl. Il utilise la dll générée par le composant MPCL_PRG_SFC, qui
permet d’associer les fonctions de l’automate C avec les Entrées/Sorties.
MPLC_KERNEL effectue une boucle à chaque cycle. Un cycle est composé de 3 états
(figure 23) :
• Read inputs & signals of communication : cette étape bloquante attend les messages
envoyés par les modules COS_THREAD et MBLC (présentés ci-après), ces modules

25
reçoivent des signaux de l’extérieur (signaux de communication des autres Automates ou des
entrées physiques des modules d’entrées/sorties actionnées par des actionneurs).
• Step Execution : Exécution d’un pas de l’automate. Le programme généré par Camstrl
est exécuté. Les sorties sont mises à jours.
• Write Outputs : Envoie des sorties activées et leurs valeurs vers les modules
COS_THREAD et MBLC.
Read inputs & signals of com
Step Execution
Write outputs
Figure 23 :Boucle d ‘exécution de MPLC_KERNEL
IV.3.4 Le composant MPLC_MAPPING

Ce module reçoit un fichier de mapping (figure ff), ce fichier contient toutes les informations
sur les autres automates de la cellules et les emplacements physiques des entrées/sorties du
programme Sfc.
PLC
{
PLC1 IP:192.168.94.118 Port:500;
PLC2 IP:192.168.94.117 Port:500;
PLC3 IP:192.168.94.117 Port:502;
}
MIOD
{
MIOD1 IP:192.168.94.119 Port:505;
Figure 24 : exemple d'un fichier MIOD2 IP:192.168.94.120 Port:505;
de mapping
MIOD3 IP:192.168.94.121 Port:505;
}
INTERFACE
{
input A com PLC1 AA;
input B phy MIOD1 bitValue:128;
output S1 com PLC3;
output S2 phy MIOD3 bitValue:8;
}

26
Dans ce fichier l’utilisateur précise :

PLC : entre les deux accolades l’utilisateur donne les caractéristiques des autres PLCs de la
cellule, c’est à dire un nom unique, leur adresse IP et le port de communication de leurs
serveur multiClients. Ces informations serviront au PLC de connaître les adresses pour
acheminer les signaux de communication.
MIOD : dans cette partie, on déclare les noms et les adresses IP et les ports de
communication des modules d’entrées/sorties déportées.
INTERFACE : dans cette partie, on précise les emplacements physiques des entrées et des
sorties du programme SFC+. En effet dans cette partie on précise :
• Pour les inputs : s’ils sont utilisés pour la communication avec d’autres PLCs (mot
clé com), il faut préciser le nom du PLC et le nom de l’output qui envoie
l’information de l’autre bout. S’ils sont utilisés pour attendre un signal venant de la
cellule c’est à dire des capteurs d’un des modules d’entrées/sorties (mot clé phy),
dans ce cas il faut préciser le nom du module et l’adresse du registre dans ce module
associée a cette entrée.
• Pour les outputs : s’ils sont utilisés pour la communication avec d’autres PLCs (mot
clé com), il faut juste préciser le nom du PLC vers lequel il faut acheminer
l’information. S’ils sont utilisés pour activer un actionneur de la cellule c’est à dire
vers des sorties d’un des modules d’entrées/sorties (mot clé phy), dans ce cas il faut
préciser le nom du module et l’adresse du registre dans ce module associée a cette
sortie.
Ce composant fait aussi deux tâches principales :
− L’interprétation des informations reçues par le serveur (le composant
COS_THREAD) qui reçoit les signaux de communication des autres PLCs et aussi les
signaux reçus des modules d’entrées/sorties (par le composant MBLC), ces signaux reçus
sont traduit par des lancements de fonctions d’entrées dans la première étape de
MPLC_KERNEL.
− L’acheminement des outputs générés par le MPLC-KERNEL, en effet ce module
associe à chaque output une adresse physique, l’output peut être un signal destiné à un autre
automate ou à un module d’entrées/sorties déportées.
IV.3.5 Le composant COS_THREAD
Le composant « COS_THREAD » fournit les fonctions nécessaires pour gérer les
communications entre PLCs, c’est une librairie de fonctions qui permet les services suivants :
lancement de Process
Thread
Sémaphores
TCP/IP Socket
Le protocole de communication utilisé étant le protocole TCP/IP, les communications avec
les autres automates et les modules déportés se font avec des sockets.

27
IV.3.6 Le composant MBLC

Le module d' Entrées/Sorties Déportées utilisé dans ce projet est de marque WAGO. Ce
module est composé d' une tête de station communiquant par réseau Ethernet (référence 750-
342) avec un PC. Ce module est aussi composé de 8 entrées et de 8 sorties numériques.
Coupleur Ethernet
4 entrées numériques 4 sorties numériques

Figure 25: Module d'I/O WAGO
Le principe d’échange des données est expliqué dans la partie ‘Logiciels et matériels
utilisés’.
La librairie MBCL représente le pilote (« driver ») du module d’Entrées/Sorties Déportées
(ESD). Elle est écrite en langage C et a été compilée et testée sous QNX 6.1 et Windows
2000 dans le cadre d’un autre projet. Ce composant a été retouché pour être utilisé dans le
projet actuel.

28
Méthodes implémentées :
4 fonctions sont de types externes, donc utilisables par d’autres programmes :
XCMBCL_Open : permet d’ouvrir une connexion TCP avec le module d’ESD.
XCMBCL_Close : permet de fermer la connexion TCP.
XCMBCL_Communicate : permet de lire et écrire sur les Entrées/Sorties lorsque une
connexion est ouverte. Cette fonction reçoit entre autre, en paramètre le code d’une fonction
à exécuter parmi celle listée ci-dessous et l’adresse de l’entrée ou de la sortie sélectionnée.
Figure 26: Fonctions permettant de lire et écrire sur le module d'ESD.

XCMBCL_Read_Configuration permet de connaître le nombre d’entrées et de sorties
constituant le module. Par exemple, l’adresse 0x1025 contient le nombre d’entrées
numériques connectées au coupleur.
XCMBCL_Decode_TCP_segment est dédiée au test du pilote. Elle permet d’analyser le
contenu d’une réponse et de l’afficher à l’écran.
5 autres fonctions sont propres à la librairie et sont appelées par les fonctions citées
précédemment :
XCMBCL_Send est appelée lorsque on envoie une requête au module d’ESD.
XCMBCL_Rec est utilisée pour recevoir la réponse à cette requête.
XCMBCL_Build_TCP_segment permet de construire la trame Modbus/TCP à envoyer
au module, selon le modèle décrit ci-dessous :
Figure 27 : Trame Modbus/TCP

29
XCMBCL_Test_Response permet de tester la validité de la trame reçue (envoyée par le

module).
IV.4 Evolutions et extensions :
La démarche suivie pour tester le programme globale est de valider le bon fonctionnement de
chaque module indépendamment et ensuite assurer la liaison avec les autres modules.
Entrant dans le cadre de R&D de l’entreprise, ce projet a pour but de valider le bon
fonctionnement de systèmes dont le comportement est décrit par le nouveau langage SFC+
est réparti sur plusieurs unités de calculs (programmation multi-autommates).
Dans un premier lieu, on s’est concentré sur la méthode d’interfacer et de faire communiquer
les bouts de programmes entre eux.
Plusieurs extensions et évolutions de ce projet restent à réaliser, les prochaines étapes seront
donc :
Plus de déterminisme : actuellement, l’OS utilisé est Windows 2000, pour assurer le
déterminisme de l’application et assurer encore plus les contraintes temps réel, une migration
vers un système temps réel (comme QNX) se voit nécessaire.
Aspect Communication : la communication entre automates se fait actuellement sous le
protocole TCP/IP, ce protocole de communication malgré sa forte envergure ne représente
pas un moyen de communication fiable et déterministe, pour une plus grande sûreté, on doit
utiliser un bus de terrain dédié pour les applications industrielle déterministe.
Simulation : ce projet peut être utilisé dans des fins de simulation aussi ; le produit
CellControl simule le comportement dans le temps d’une cellule robotisée dans
l’environnement IGRIP, cette simulation ne tient pas compte de la répartition des
programmes sur plusieurs unités de calcul, dans notre cas, nous pouvons utiliser CellControl
comme interface pour simuler le fonctionnement de la cellule tout en modélisant la
répartition des automates.
Conclusion :
Ce stage m’a permis de découvrir l’ambiance de travail d’équipe d’une structure autour d’un
produit innovant et de mener un travail de conception et de réalisation logicielle.
D’un point de vue technique, j’ai pu découvrir un nouveau concept de langages : ‘Les
Langages Synchrones’, pu améliorer mes compétences en langage C++ et me familiariser
avec la gestion des ressources et la communication par sockets. De plus, j’ai développé mes
capacités de travail en groupe et l’exploitation des résultats de mes collègues.
Lors de ce stage, j’ai spécifié et développé une maquette qui permet de modéliser la
répartition des programmes gérant une cellule robotisée sur plusieurs automates
(programmation multi-automates).

30
Bibliographie :
• [BB91] A. BENVENISTE, G. BERRY, The Synchronous Approach to Reactive and

Real-Time Systems, Proceedings of the IEEE 79, 9, Septembre 1991.
• [BER99] G. BERRY The Esterel v5 language primer. Manuel de référence, Centre de
Mathématiques Appliquées (INRIA et École des Mines de Paris), 1999.
• [Bro84] D.R. Brownbridge. Recursive Structures in Computer Systems. PhD thesis,
University of Newcastle upon Tyne, United Kingdom, September 1984.
• [BOU96] F. BOUSSINOT La programmation réactive : application aux systèmes
communicants. Collection technique et scientifique des télécommunications
(CNET/ENST). Masson, 1996.
• [BOU98] H. BOUFAÏED Machines d’exécution pour langages synchrones. Thèse de
doctorat, Université de Nice-Sophia Antipolis, novembre 1998.
• [Gaf96] D. Gaffé Le modèle Grafcet : réflexion et intégration dans une plate-forme
multiformalisme synchrone. PhD thesis, Doctorat de l' Université de Nice-Sophia
Antipolis, Janvier 1996.
• [GIR92] A. GIRAULT, sur la répartition de programmes synchrones, Doctorat de
l’Institut National Polytechnique de Grenoble, Mars 1992.
• [HAI2000] O.HAINQUE Compilation séparée et exécution distribuée d’applications
synchrones modulaires programmées en Esterel. Thèse de doctorat, École Nationale
Supérieure des Télécommunications, juin 2000.
• [Har88] D. Harel. Statechart: a visual formalism for complex systems. Science of
computer Programing, Juin 1987.
• [HP85] D. Harel et A. Puneli. Logics and models of concurrent systems, Springer
Verlag New-York, 1985.
• [RIC2000] N. RICHARD, Systèmes et langages réactifs synchrones, rapport de
recherche, ENST, 2000.

31

32

33

34

35

36

37

38

Rapport Stage Isim

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Rapport Stage Isim

Hochgeladen von

Copyright:

Verfügbare Formate

Conception d'un outil de configuration multi-automates

Jalal BENALLAL Juin 2003

I. PRESENTATION DE LA SOCIETE DU STAGE :.................................................. 5

I.1 PRESENTATION DE LA SOCIETE :..................................................................................... 5

II. ETAT DE L’ART :........................................................................................................ 9

II.1 INTRODUCTION : ............................................................................................................ 9

III. DEVELOPPEMENT : ................................................................................................ 20

III.1 SPECIFICATIONS : ....................................................................................................... 20

Jalal BENALLAL Juin 2003

II. Présentation de la société du stage :

Jalal BENALLAL Juin 2003

Génération automatique de critère de

i-CFlow i-C.Design i-C.Monitor i-C.View

iC.PP i-C.Verif i-C.Exec

Figure 1 : Architecture de CellControl

II.3 Présentation du sujet de stage :

Figure 2: Lien entre CellControl et IGRIP

Jalal BENALLAL Juin 2003

III. Etat de l’art :

Jalal BENALLAL Juin 2003

Figure 3: système transformationnel et système réactif

Jalal BENALLAL Juin 2003

Jalal BENALLAL Juin 2003

Figure 4 :Exécution d'un système de type réactif.

III.3.2 Le langage ESTEREL :

événements auxquels le système décrit doit réagir. La communication et la synchronisation

Figure 5 : Attente concurrente et émission de signaux

Figure 6 : Représentation de l'interface d'un module ESTEREL

Jalal BENALLAL Juin 2003

present [I1 and I2] or [not I3] then

Manipulations des données : Un module ESTEREL peut manipuler des valeurs de

Figure 7 : Suspension sur réception de signal

Trappes : Le mécanisme de trappes d’ESTEREL permet de s’échapper d’un bloc

Figure 8 : Utilisation d'une trappe.

Jalal BENALLAL Juin 2003

Composition de modules : Un module ESTEREL peut instancier d’autres modules

Figure 9 : Exemple de composition de modules avec substitution de signaux.

Jalal BENALLAL Juin 2003

Figure 10 : Exemple de correspondance Esterel/C.

III.3.3 Les langages standard de la norme IEC 61131-3 :

Figure 11 : Exemple d'un programme en LD

Jalal BENALLAL Juin 2003

III.3.3.2 Le langage FBD: Function Block Diagram :

Figure 12 : Exemple en FBD.

III.3.3.3 Le langage SFC: Sequential Function Chart :

Figure 13 : Programme en SFC

Jalal BENALLAL Juin 2003

III.4 La répartition des systèmes réactifs :

l’environnement. La structure d’un réseau peut être modifiée dynamiquement, au cours de

Figure 14 : Communication entre objets réactifs.

Jalal BENALLAL Juin 2003

PLC I PLC II PLC I

Réseau de terrain Module I/O Module I/O

Figure 15: Structure de la commande Multi-automates.

IV.2 Logiciels et matériels utilisés :

Figure 16 : Module d'I/O déportées -Wago-

Jalal BENALLAL Juin 2003

Figure 17 : Modèle OSI

Figure 18 : Coupleur de bus de terrain; 10 Mbits/s

Jalal BENALLAL Juin 2003

Figure 19 :Bornes d'entrées digitales à 4 canaux.

Figure 20 :Bornes de sorties digitales du module

IV.3 Architecture détaillée du projet :

Jalal BENALLAL Juin 2003