Rapport Stage Isim

Conception d'un outil de configuration multi-automates

Jalal BENALLAL Juin 2003 2

��

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.



��

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



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.



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.



• 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 composants Nom de code Description

i-Control-Base IC_BASE Listing des différents outils d’une cellule IGRIP.

i-Control-Design IC_DESIGN Création du comportement d’une cellule et simulation en utilisant Esterel.

i-Control-Monitor IC_MONITOR

Création du comportement d’une cellule et simulation en utilisant des outils logiciels pour PLC via OPC, ou autre système de communication.

i-Control-Flow IC_FLOW Simulation du comportement logique et temporel d’une cellule IGRIP avec Esterel.



i-Control-Verif IC_VERIF Génération automatique de critère de vérification pour le programme de vérification formelle d’Esterel.

i-Control-PostProcessor(PP) IC_POSTPRO Génération d’un code exécutable pour PLC

ou contrôleur de robots.

i-Control-View IC_VIEW Visualisation du comportement réel d’une cellule avec IGRIP.

i-Control-Exec IC_EXEC Génération d’un code exécutable pour cible 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.Design

i-C.Base

i-CFlow i-C.Monitor

i-C.Verif i-C.Exec

i-C.View

iC.PP

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.



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).

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.

Figure 2: Lien entre CellControl et IGRIP



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



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].

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

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



(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



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

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.

�

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



é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.



�� 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.

�� 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.

present [I1 and I2] or [not I3] then emit O1 end present



�� 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).



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).

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.

x

a b

c

Figure 11 : Exemple d'un programme en LD



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).

x

a

b

c

>= 1

&

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.



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



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.



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).

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.

PLC I PLC II PLC I

Module I/O Déportées

Module I/O Déportées

Réseau de terrain

Figure 15: Structure de la commande Multi-automates.



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.



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.



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.



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.

MPLC_Prg_Sfc

MPLC_Kernel

MPLC_Mappin

COS_THREAD MBCL

Automate 1

MPLC_Prg_Sfc

MPLC_Kernel

MPLC_Mappin

COS_THREAD MBCL

Automate 2

MIOD1 MIOD2

Figure 21 : Architecture générale du projet



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

Prg_Sfc.c PtrFctSfc.cpp

PtrFctInp.c PtrFctOut.c

MplcPrgSfc.dll

Programme SFC

compilation

Figure 22 : le composant MPLC_PRG_SFC.



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.

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.

Read inputs & signals of com

Step Execution

Write outputs

Figure 23 :Boucle d ‘exécution de MPLC_KERNEL

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; MIOD2 IP:192.168.94.120 Port:505; 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; }

Figure 24 : exemple d'un fichier de mapping



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.



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.



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



�� 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).



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.



��

Rapport Stage Isim

Documents

Transcript of Rapport Stage Isim