Application de la théorie de la supervision : un exemple de conception de programmes d’API

01/10/2017
Publication e-STA e-STA 2003-1
OAI : oai:www.see.asso.fr:545:2003-1:20070
DOI :

Résumé

Application de la théorie de la supervision : un exemple de conception de programmes d’API

Métriques

27
8
404.87 Ko
 application/pdf
bitcache://80056dec2ceccd03062a0fc7716f687226e831f0

Licence

Creative Commons Aucune (Tous droits réservés)
<resource  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                xmlns="http://datacite.org/schema/kernel-4"
                xsi:schemaLocation="http://datacite.org/schema/kernel-4 http://schema.datacite.org/meta/kernel-4/metadata.xsd">
        <identifier identifierType="DOI">10.23723/545:2003-1/20070</identifier><creators><creator><creatorName>Laurent Pietrac</creatorName></creator><creator><creatorName>Samir Chafik</creatorName></creator><creator><creatorName>Luc Regimbal</creatorName></creator></creators><titles>
            <title>Application de la théorie de la supervision : un exemple de conception de programmes d’API</title></titles>
        <publisher>SEE</publisher>
        <publicationYear>2017</publicationYear>
        <resourceType resourceTypeGeneral="Text">Text</resourceType><dates>
	    <date dateType="Created">Sun 1 Oct 2017</date>
	    <date dateType="Updated">Sun 1 Oct 2017</date>
            <date dateType="Submitted">Sun 9 Dec 2018</date>
	</dates>
        <alternateIdentifiers>
	    <alternateIdentifier alternateIdentifierType="bitstream">80056dec2ceccd03062a0fc7716f687226e831f0</alternateIdentifier>
	</alternateIdentifiers>
        <formats>
	    <format>application/pdf</format>
	</formats>
	<version>34087</version>
        <descriptions>
            <description descriptionType="Abstract"></description>
        </descriptions>
    </resource>
.

Application de la théorie de la supervision : un exemple de conception de programmes d’API LAURENT PIÉTRAC, SAMIR CHAFIK, LUC REGIMBAL Laboratoire d’Automatique Industrielle, INSA de Lyon Bâtiment St Exupéry, 25 Avenue Jean Capelle, 69621, Villeurbanne CEDEX, France {laurent.pietrac, samir.chafik}@lai.insa-lyon.fr Résumé — Pour assurer le bon fonctionnement d’un système, il est nécessaire de démontrer que les programmes de commande respectent les propriétés de sécurité spécifiées dans le cahier des charges. Cette démonstration peut se faire soit par la validation (ou vérification) soit par la synthèse de trajectoires de commande. L’approche de vérification et de validation a l’inconvénient de nécessiter l’écriture préalable du programme puis de vérifier les propriétés attendues, alors que l’avantage de l’approche de synthèse repose sur la prise en compte des propriétés dès le début de la conception. Dans cet article, nous nous sommes basés sur l’approche de synthèse pour proposer une application du principe de la théorie de supervision à la programmation de la commande des systèmes automatisés de production (SAP). Notre contribution consiste dans un premier lieu à obtenir des modèles corrects (vérifiant les propriétés attendues) et surtout simples à construire et à lire. Dans une seconde étape, nous proposons une méthode de passage de modèles formels vers un programme API. Mots clés — théorie du contrôle par supervision, synthèse, programmes API, conception, traduction. I. INTRODUCTION Les technologies de la communication sont de plus en plus présentes au sein de l’entreprise et permettent en particulier d’intégrer le système de commande de l’atelier aux différents systèmes d’informations de l’entreprise [1]. Parallèlement à cette évolution quantitative des services rendus par la commande des systèmes automatisés de production, les exigences qualitatives des utilisateurs ont également augmenté. Un système de production doit aujourd’hui absolument être sûr, dans le sens où il faut trouver le meilleur compromis entre les contraintes de sécurité et de productivité imposées par l’environnement de l’entreprise. La commande opérationnelle des SAP est pour une part prépondérante constituée d’automates programmables. Les langages de programmation de ces automates ont également beaucoup changé ces dernières années. Hormis l’entrée de gamme, la plupart des automates peuvent se programmer par différents langages basés sur la norme IEC 61131-3 [2]. Ces langages utilisent de nombreux types de variables, de structures ou d’objets permettant d’inclure dans les programmes des fonctions de surveillance, d’évaluation de performances, de traçabilité, etc. Par contre les méthodes d’utilisation de ces langages n’ont pas évolué : le concepteur ne dispose d’aucune aide à la conception des programmes. Seules sa compétence et son expérience lui permettent d’écrire des programmes dont il garantit qu’ils permettront d’obtenir un système sûr de fonctionnement. Pour prouver le fonctionnement sûr, il est indispensable de démontrer que les programmes respectent un certain nombre de propriétés de sécurité. Deux approches sont possibles : la démonstration a posteriori (on parle alors de validation ou de vérification) et la démonstration a priori (il s’agit de synthèse de trajectoires de commande). Les méthodes de vérification permettent de prouver des propriétés intrinsèques du programme – réinitiabilité, blocage, etc. – tandis que les méthodes de validation ont pour objectif de prouver l’adéquation entre le programme et les propriétés spécifiées dans le cahier des charges [3]. En pratique, la vérification et la validation formelles mettent en œuvre la démonstration automatique ou le model-checking [4], avec des concepts très proches du génie informatique [5]. Nous considérons que ces méthodes ont l’inconvénient majeur de nécessiter une écriture préalable du programme. En effet lors d’une première conception, le programmeur peut ne pas arriver à valider complètement son programme. Lors d’une reconception, avec modifications des propriétés attendues, le problème est encore plus crucial. Contrairement aux approches précédentes, l’approche par synthèse consiste à construire d’abord les modèles du système et des propriétés attendues pour obtenir ensuite un modèle de commande qui, par essence même, respecte toutes les propriétés spécifiées. Les propriétés sont donc prises en compte dès le début de la conception, ce qui permet de réagir à des blocages ou à des modifications plus rapidement. De plus, les blocages sont levés plus facilement car il est plus aisé d’identifier les propriétés qui sont en cause. Notre proposition consiste donc à appliquer ce principe de synthèse à la programmation de la commande des SAP en utilisant la théorie du contrôle par supervision et ses fondements qui sont les automates à états et la théorie des langages. Cette proposition entraîne deux questions : 1. comment gérer la taille des modèles ? 2. comment passer du modèle formel au programme ? Pour répondre à ces questions nous avons appliqué notre approche sur un système réel [6]. Dans la suite de cet article nous allons d’abord présenter l’exemple de SAP qui nous a servi de support. Nous aborderons ensuite la mise en œuvre de la théorie du contrôle par supervision avant de présenter l’interprétation des trajectoires retenues pour aboutir à un programme implantable sur API. Nous conclurons ensuite sur la pertinence de notre approche. II. LE SYSTEME ETUDIE Le système considéré est une chaîne de production de type « transfert libre » implantée dans l’Atelier Inter établissements de Productique (AIP) Rhône-Alpes Ouest. Ce système est structuré autour d’un convoyeur central qui permet la circulation de palettes entre six postes de travail. Chaque palette porte une pièce sur laquelle les opérations doivent être effectuées et une étiquette permettant d’identifier la pièce et de stocker les informations relatives à la gamme de fabrication de cette pièce. Chaque poste est constitué de trois zones (figure 1). La zone d’entrée permet l’aiguillage de la palette vers la zone de travail si la pièce doit y subir une opération ou vers la zone de sortie dans le cas contraire. La zone de travail est la zone où sont effectivement réalisées les opérations. La zone de sortie permet d’éviter les collisions entre les palettes provenant de la zone de travail et la zone d’entrée. figure 1 : schéma d’un poste de travail La commande de chaque poste de travail est constituée d’un automate Schneider Premium. Ces automates communiquent chacun, par l’intermédiaire de bus Uni- Telway, avec deux stations XGS de lecture/écriture sur des étiquettes magnétiques et avec un terminal de dialogue d’exploitation XBT Magélis. Les automates comportent en outre chacun un serveur Web et peuvent échanger des informations par un réseau Ethernet. Ces automates sont programmés par l’intermédiaire du logiciel PL7-pro qui permet d’écrire des programmes en utilisant les langages basés sur la norme IEC 61131-3. Parmi ces langages, ceux mis en œuvre sont le Sequential Function Chart (SFC) pour la structure séquentielle du programme, le langage à contacts (LD) pour les réceptivités et les traitements et le langage littéral structuré (ST) pour les sous-routines. III. THEORIE DU CONTROLE PAR SUPERVISION A. Approche centralisée 1) Théorie La théorie de contrôle par supervision a été initiée par Ramadge et Wonham (RW) en 1987 [7]. Cette théorie a été conçue dans le cadre des systèmes à événements discrets (SED). Son principe de base est la séparation claire entre le modèle du système considéré et le modèle des spécifications que doit respecter ce système. Dans l’approche classique, dite approche centralisée, le modèle du système est appelé générateur et le modèle des spécifications est appelé superviseur (figure 2). Les événements générés sont spontanés car aucun mécanisme ne vient contraindre l’occurrence des événements. Ils sont instantanés c’est-à-dire considérés comme ayant une durée nulle. Enfin aucune horloge ne séquence l’occurrence des événements, ils sont donc asynchrones. Le comportement décrit par le générateur correspond à l’ensemble des trajectoires possibles (hors contraintes) du système. Superviseur Générateur événements événements observés événements interdits figure 2 : modèles de la théorie de la supervision L’ensemble des événements générés est appelé alphabet du système et noté Σ. Cet alphabet est partitionné en deux ensembles disjoints : les événements contrôlables Σc et les événements incontrôlables Σuc. Le superviseur ne génère aucun événement. Il observe tout ou partie des événements générés et interdit l’occurrence de certains événements. Limite du poste Limite du poste Zone de travail Zone de sortie Zone d’entrée L’association du générateur et du superviseur correspond à l’ensemble des trajectoires possibles respectant les spécifications. Ces comportements, appelés « comportements optimaux », représentent les trajectoires de commande du contrôleur. Elles peuvent ensuite être implantées sous forme d’instructions dans la partie contrôle-commande du système. L’opération mathématique permettant d’obtenir les trajectoires de commande du contrôleur est appelée synthèse du contrôleur. 2) Application sur l’exemple L’étude d’un système nécessite d’abord de scinder le système étudié en sous-systèmes distincts. Chaque sous- système est modélisé sous la forme d’un automate à états. Le modèle du système, le générateur G, est obtenu en faisant le produit de tous les automates des sous- systèmes. De la même façon, chaque spécification est modélisée par un automate à états. Le superviseur S est le résultat de la composition parallèle de ces automates. Pour mettre en œuvre ces opérations, ainsi que la synthèse du contrôleur, nous utilisons le logiciel TCT1 . En appliquant cette approche sur le poste de travail de la figure 1, on obtient un générateur qui contient 108 000 états et 1 165 500 transitions. La synthèse de contrôleur n’a pas aboutie, car les calculs nécessaires dépassent les capacités du logiciel de synthèse TCT. Les modèles obtenus sont donc difficilement lisibles et exploitables par le concepteur, alors que le système étudié semble simple à étudier par d’autres approches : RdP, grafcet… 1 TCT est un logiciel développé à l’université de Toronto au Canada. Cet outil permet l’exploitation du concept de la théorie de RW et permet la synthèse du contrôleur. En conclusion, le contrôle par supervision selon RW reste un concept simple, général et pouvant être appliqué à une large étendue de systèmes réels. Cependant, cette théorie peut introduire une complexité de calcul importante pour de grands systèmes rendant parfois impossible la synthèse d’un contrôleur. En effet, la description de l’ensemble des trajectoires nécessaires à la détermination du comportement optimal est potentiellement la cause d’une explosion combinatoire. Cette explosion est le frein qui est classiquement évoqué à l’utilisation de cette théorie. Pour lever cette complexité, la décomposition reste donc une approche privilégiée de résolution. Celle-ci se trouve être formalisée par les trois approches suivantes : l’approche modulaire, l’approche décentralisée et l’approche hiérarchique. Le lecteur trouvera dans [8] une étude comparative sur un exemple de ces différentes approches. Seule l’approche décentralisée sera présentée dans cet article. B. Approche décentralisée 1) Théorie Le contrôle par supervision décentralisée permet de réduire la taille des contrôleurs synthétisés. Cette réduction est obtenue en adoptant une décomposition du système G2 en sous-systèmes élémentaires ou procédés Gi (figure 3). Cette structure est motivée par le fait que l’accomplissement d’une sous-tâche de contrôle ne nécessite que la gestion d’un certain sous-ensemble de l’alphabet global Σ, d’où l’intérêt de cette structure où chaque sous-système Gi est observé et contrôlé uniquement sur le sous-alphabet Σi par un superviseur individuel dit local Si,loc. figure 3 : contrôle par supervision décentralisée Pour cela il convient d’introduire la notion de projection naturelle Pi qui consiste tout simplement à éliminer les événements qui n’appartiennent pas à Σi [9]. Dans ce cas un superviseur local Si,loc contrôle uniquement les événements dans Σi tel que L(Gi) = Pi(L(G)). En boucle fermée avec Gi ce superviseur synthétise Ki,loc = L(Si,loc, Gi) = SupC(L(Gi) ∩ Ei,loc) qui est le langage suprême contrôlable d'une spécification locale Ei,loc par rapport au générateur local i. L’effet global d’un superviseur local Si,loc, donc Si ~ , sur le générateur global G synthétise le langage K Il est i téressant de déterminer les conditions pour lesquelles . ) ( * , Σ ⊆ ∩ = − loc i 1 i i K P G L ~ n i S ~ peut synthétiser le même fonctionnement optimal que celui du superviseur centralisé Si. Autrement dit, déterminer les conditions pour que (i.e. quand i i K K ~ = i K ~ i K L( n i= ∧ est globalement optimal). D’après [10] on dit que si et seulement si K i K ~ = /G) S ~ i 1 i est normal3 . Dans la réalité plusieurs superviseurs locaux sont couplés au système et agissent d'une façon concurrente. Cependant cette action concurrente de tous les superviseurs locaux sur le système permet-elle d'obtenir un fonctionnement aussi optimal que celui du superviseur centralisé ? i.e. ? = SupC(L(G) ∩ E). Sous la supposition de la normalité (Ki = ), cette égalité est bien vérifiée. Ainsi le contrôle décentralisé obtenu est optimal dans le sens où le fonctionnement de l'ensemble des superviseurs locaux liés à G est équivalent à celui du superviseur centralisé. i K ~ 2) Application sur l’exemple Reprenons le poste décrit par la figure 1. Ce poste qui constitue le système global à contrôler, peut être décomposé en trois modules ou zones : la zone d’entrée, la zone de travail et la zone de sortie (figure 4) séparées par des zones d’interaction représentées par des stocks. Pour des raisons d’espace limité pour la conférence, nous ne considérerons que la zone de travail et le stock 3. C’est autour de ces deux modules que nous appliquerons la programmation de la commande de SAP. Zone d’entrée Zone de sortie Stock aval Stock 1 Stock amont Zone de travail Stock 3 Stock 2 Projection P1 G1 Projection P2 G G2 S2,loc S1,loc K1,loc K ~ 2 figure 4 : structure d’un poste de travail La zone de travail est composée de trois sous-systèmes qui sont la butée Bt et le capteur de présence palette Cp, l’indexeur Id et enfin le lecteur magnétique Lct (voir figure 5). Les modèles de chacun de ces sous-systèmes sont présentés sur les figures 6, 7 et 8 (les doubles flèches représentent les états initiaux et marqués, les flèches barrées représentent les événements contrôlables). Par manque de place la forme de ces modèles ne sera pas justifiée ici. L’automate décrivant l’ensemble des comportements possibles de la zone de travail est le produit de ces trois automates, il comprend 60 états et 232 transitions. Lecteur magnétique Lct Indexeur Id Capteur présence palette Cp Butée Bt G figure 5 : zone de travail 2 Le système G peut être modélisé par un automate G = (X, ∑, δ, x0, Xm) avec : X = ensemble des états de G, ∑ son alphabet, δ=fonction de transition, x0=état initial et Xm ensemble des états marqués de G. al si K = L(G) ∩ P-1 P(K) dsbt = demande de sortie de la butée fsbt = fin de sortie de la butée drbt = demande de rentrée de la butée frbt = fin de rentrée de la butée ap t arri ée d’ ne palette dans 3 Un langage clos K L(G) est dit norm ⊆ 1 apz 0 4 3 2 dpz frbt fsb dsb drb dpzt figure 6 : modèle de la butée Bt et du capteur Cp figure 7 : modèle de l’indexeur Id figure 8 : modèle du lecteur magnétique Lct La spécification de contrôle de la zone de travail est la suivante : lorsqu’une palette est détectée par le capteur de présence palette, la butée sort afin de la bloquer et une demande de lecture indique si la palette doit être indexée ou non. En fin de traitement la butée rentre, autorisant ainsi le départ de la palette. Le modèle de cette spécification est donné par l’automate de la figure 9 avec ΣZT l’ensemble des événements constituant la zone de travail (ΣZT correspond aux 15 événements énumérés sur les figures 6, 7 et 8). figure 9 : modèle de spécification de la zone de travail La synthèse a donné le contrôleur local de la figure 10. Grâce au TCT nous avons vérifié que les langages de contrôle des trois zones du poste de travail sont normaux et non conflictuels. En plus le fonctionnement global décentralisé est optimal dans le sens où il correspond au même fonctionnement que celui du contrôle centralisé. Par conséquent, les contrôleurs locaux obtenus sont plus simples, facilement mis à jour et transplantables. En effet, en utilisant cette approche, le plus grand contrôleur local obtenu contient 12 états et 14 transitions, alors que pour l’approche centralisée, le contrôleur obtenu dépasse de loin les 108 000 états et 1 165 500 transitions. figure 10 : contrôleur local de la zone de travail La spécification d’interaction du stock 3 est représentée par un automate à états avec des événements appartenant aux deux zones de travail et de sortie (figure 12). Son but est de surveiller l’évolution du système en comptant le nombre de pièces dans le stock 3 et d’agir sur le procédé supervisé lorsque le nombre de pièces atteint 5. La figure 11 représente le principe de ce contrôle supervisé. G S1,loc S2,loc S3,loc Sn,loc S1,stock S2,stock Sk,stock apzt dsbt fsbt dlect 0 1 2 3 4 pzt 5 frbt drbt flind dlind 1 1 9 8 7 find 6 pnzt dind dpzt dind find dlind flind 1 2 3 0 dind = demande d’indexage find = fin d’indexage dlind = demande libération d’indexage fli d fi d libé i d’i d dlect 2 0 1 decrt dlect = demande lecture de l’étiquette pzt = pièce à exploiter dans la zone pnzt = pièce sans action à exploiter decrt = demande d’écriture sur étiquette fecrt = fin d’écriture sur étiquette fecrt pzt, pnzt figure 11 : structure de contrôle supervisé La particularité de cette spécification d’interaction est de ne pas modifier les trajectoires de contrôle déjà élaborées. Son unique rôle est d’interdire l’événement drbt dans la trajectoire de contrôle de la zone de travail lorsque le stock est plein (dans Σ5). Cet événement sera le seul à être conditionné lors du passage en langage API (section suivante). Cette spécification contrôlable est non conflictuelle non seulement avec la zone de travail mais aussi avec la zone de sortie. ∑3 ∑0 = ∑ZT – {fsbt,dind,dlect,decrt} ∑1 = ∑ZT – {pzt,pnzt,drbt,dind,decrt} ∑2 = ∑ZT – {find,drbt,dlect,decrt} pzt ∑2 3 2 ∑1 dpzt ∑0 flin pnzt fsbt 1 0 Les événements portant l’indice 3 correspondent à des événements relatifs à la butée B3 et au capteur C3 présents dans la zone de sortie. L’événement dpc3 correspond ainsi au départ de la pièce de la zone de sortie, et donc à la diminution du nombre de pièces présentes dans le stock 3. ∑5 ∑2 dpc3 dpzt ∑0 dpzt ∑1 dpc3 dpc3 dpzt dpzt dpc3 dpzt 1 0 2 3 4 5 dpc3 ∑3 ∑4 ∑Stock={apzt,dpzt,dsbt,fsbt,drbt,frbt,dind,flind,dlind,flind, dlect,pzt,pnzt, decrt,fecrt,apc3,dpc3,dsb3,fsb3,drb3} ∑0 = ∑ Stock – {dpzt} ∑1 = ∑2 = ∑3 =∑4 =∑Stock - {dpzt, dpc3} ∑5 =∑Stock - {dpc3, drbt} figure 12 : spécification du stock 3 Cette dernière étape permet en cas d’interaction entre sous systèmes d’obtenir des contrôles simples sans modifier l’objectif de la supervision. IV. PROGRAMMATION DES API A. Changement de cadre théorique L’utilisation de la théorie du contrôle par supervision a permis de démontrer qu’il existe un ensemble de trajectoires de commande permettant de respecter les propriétés de sécurité et de vivacité spécifiées. Avant de faire un choix de trajectoire, il est nécessaire de clarifier les changements de cadre théorique qui rendent nécessaire l’interprétation des trajectoires de commande pour la programmation des API. La théorie du contrôle par supervision considère un générateur spontané d’événements et un superviseur qui observe ces événements et en interdit certains. Un SAP peut, de manière simplifiée, être modélisé sous la forme d’une partie commande envoyant des ordres à une partie opérative qui lui renvoie des compte-rendus. Cependant la partie opérative n’est pas un générateur spontané d’événements, et ne peut donc pas être assimilée au générateur, comme la partie commande ne peut pas être assimilée au superviseur. Nous considérons pourtant que le contrôleur synthétisé correspond bien au modèle de comportement de l’ensemble partie opérative - partie commande. Pour interpréter ce comportement et déduire un programme de la partie commande il est nécessaire de faire un choix de trajectoires en tenant compte de deux propriétés de cette partie commande : le déterminisme et la réactivité. B. Choix de trajectoires 1) Principe La partie commande d’un SAP doit avoir un comportement déterministe vis-à-vis de ses entrées, c’est-à-dire que dans une situation donnée, elle ne doit jamais avoir le choix des sorties à générer. Or les événements contrôlables sont interprétés sous la forme de sorties et les événements incontrôlables sous forme d’entrées de la partie commande. Concrètement cela signifie donc que lorsque, dans un état donné, plusieurs trajectoires démarrant par un événement contrôlable sont possibles, il est nécessaire de ne garder qu’une seule de ces trajectoires. La figure 13 montre ainsi un exemple de suppression de la transition portant l’événement contrôlable a à partir de l’état 7, ne laissant ainsi qu’une trajectoire possible à partir de cet état. figure 13 : application de la propriété de déterminisme L’utilisateur attend aussi de la partie commande qu’elle ait un comportement réactif, c’est-à-dire qu’elle réagisse le plus rapidement possible à une variation de ses entrées. En terme d’événements, cela signifie que si dans un état donné il peut arriver l’occurrence d’un événement contrôlable et celle d’un événement incontrôlable, nous choisissons la trajectoire commençant par un événement contrôlable. 1 2 3 g r g figure 14 : application de la propriété de réactivité Ces deux étapes de choix de trajectoires amènent une troisième étape qui est la recherche d’un automate dans lequel tous les états sont accessibles et co-accessibles (automate émondé). Sur la figure 13 les états 8 à 12 sont supprimés car devenus inaccessibles après l’élimination de la transition entre les états 7 et 8. Les trois étapes précédentes n’étaient mises en œuvre que pour les transitions modifiant l’état du système. Une quatrième étape est la suppression de toutes les transitions ne modifiant pas l’état du système puisque ces transitions ne seront pas traduites sous forme d’une réaction de la partie commande. La figure 14 présente ainsi un exemple de transition portant l’événement g ne modifiant pas l’état du système (état 3) : cette boucle peut être supprimée. L’ensemble de ces choix n’aboutit pas à l’obtention d’une seule trajectoire possible. Certaines divergences de trajectoires, correspondant à plusieurs événements incontrôlables possibles à partir d’un état donné, n’ont pas été éliminées. Ces divergences correspondent à des réactions distinctes suite à des événements différents. Elles représentent bien le comportement attendu de la partie commande et seront implantées dans le programme. 2) Application sur l’exemple Le problème du choix de trajectoire ne concerne que les automates représentant les contrôleurs locaux. Pour la zone de travail (voir figure 10) la seule transition supprimée est celle portant l’événement dpzt entre les états 1 et 0. L’automate final comprend donc deux trajectoires qui correspondent à l’occurrence de deux événements incontrôlables à partir de l’état 4. Les suppressions de trajectoires sont du même type sur les automates représentant les contrôleurs locaux des autres zones. Le problème du choix de trajectoire ne s’applique pas sur les spécifications d’interactions entre zones car celles-ci seront directement traduites sous la forme de conditions complémentaires à l’évolution des commandes de zones. 7 8 13 a c 11 14 10 15 9 12 C. Traduction Nous avons cherché à obtenir des programmes ayant une structure proche de ce que nous aurions pu écrire directement. C’est pourquoi nous avons utilisé le SFC pour décrire la structure séquentielle du programme et le LD pour les réceptivités et les traitements. Le SFC et les réceptivités font partie du traitement MAST, tandis que les traitements sont regroupés dans le traitement POST. Le langage ST est utilisé pour programmer les sous-routines et les boites fonctionnelles. La traduction des contrôleurs locaux nécessite tout d’abord la traduction des événements. Les événements incontrôlables sont traduits sous la forme d’expressions combinatoires d’entrées de la partie commande ou de variables internes. Les événements contrôlables correspondent à des actions simultanées sur des sorties ou sur des variables internes. Ces traductions correspondent à des préoccupations logiques ou technologiques. Par exemple des temporisations sont introduites pour que les mouvements des palettes se terminent correctement ou que les lecture et écriture se fassent. La traduction nécessite aussi des règles de traduction des structures des automates sous forme de structures de SFC. Ainsi, l’alternance événement incontrôlable – événement contrôlable se traduit assez naturellement sous forme d’une alternance (transition, réceptivité) – (étape, action). De même le choix de deux trajectoires commençant par un événement incontrôlable s’interprète sous la forme d’un choix de séquence. Par contre nous avons traduit la succession de deux événements incontrôlables par une succession transition - étape – transition afin de bien distinguer les deux occurrences d’événements correspondants. Les contraintes de stocks ont été traduites sous forme d’instances d’une boite fonctionnelle DFB dans laquelle une variable représente la taille du stock considéré. L’incrémentation et la décrémentation de cette variable se fait par l’intermédiaire d’événements qui sont traduits grâce aux règles précédentes. Les lectures et écritures sur les étiquettes magnétiques se font par l’intermédiaire de sous-routines dont seules l’activation et le résultat apparaissent dans les réceptivités et les traitements du POST. D. Le programme obtenu La figure 15 représente le SFC correspondant au contrôleur de la zone de travail. Les réceptivités ont été incluses ici dans un soucis de lisibilité : elles sont en réalité programmées sous forme de réseaux LD. Les parenthèses associées aux étapes sont des commentaires. Cette figure montre bien que le graphe obtenu est facilement exploitable. figure 15 : SFC de la zone de travail La figure suivante représente les entrées et sorties de la DFB gérant le stock 3. Les fronts descendant des entrées %I3.1 et %I3.3 correspondent respectivement aux événements dpzt et dpc3 (figure 12). La variable %M53 indique que le stock 3 est plein. figure 16 : DFB de gestion du stock 3 A part les variables internes représentant les fins de temporisation, le POST ne comprend que des actions maintenues. Ceci est dû aux choix technologiques sur les vérins et les distributeurs. La vérification de l’état du stock, par l’intermédiaire de %M53, est directement rajoutée dans les conditions autorisant la libération d’une palette dans la zone de travail. Ceci correspond à l’interdiction de l’événement drbt dans la spécification du stock 3. %I3. 1 N %I3. 3 N DFB valid entrée_p sortie_p nb_p_ma nb_p_s %MW53 %MW57 %MW57 %MW53 %M5 0 %M5 3 Stock_pl dfb Stock3 %X1 4 %Q4.5 %Q4.4 %Q4. 3 R %X15 %M5 3 TM.P:10 %X1 2 %SR2 %M1 %TM5 TM.P:10 %X11 %Q4.3 %M4 2 %TM4 S C R S (*Attendre une palette*) (*Sortir la butée de travail*) (*Demander la lecture et démarrer la temporisation*) (*Libérer la palette*) (*Demander l’aiguillage*) (*Libérer l’aiguillage*) %M25.%M1 10 15 11 12 %M25.%M1 %I3.1 M0 %I3.10.%I3.9 %I3.8 %I3.2.%M42 14 %M21.%M5 %I3.1 16 figure 17 : traitements POST de la zone de travail V. CONCLUSION Au début de cet article, nous avions posé deux questions. La première question était « comment gérer la taille des modèles ? ». L’exemple présenté nous a permis de montrer qu’il est possible d’utiliser la théorie du contrôle par supervision sans être confronté à ce problème d’explosion combinatoire. Bien sûr ceci nécessite d’utiliser une méthode permettant de décomposer le système tout en conservant les propriétés vérifiables dans l’approche centralisée. Cet aspect méthodologique est un axe majeur de nos travaux, et nous semble un apport théorique et pratique important. La seconde question était « comment passer du modèle formel au programme ? ». Cette traduction nécessite un algorithme de choix de trajectoires de commande puis l’utilisation de règles de traduction des événements, des structures des automates décrivant les contrôleurs et des contraintes de stocks. Ceux que nous avons mis en place sur cet exemple nous ont permis d’obtenir un résultat cohérent. VI. REFERENCES [1] P. Baptiste, V. Botta-Genoulaz, E. Niel, C. Subaï,« Duparadigme Suivi/ ordonnancement/ GPAO au paradigme ERP/APS/MES : révolution ou évolution ? », CPI’2001, Fès, Maroc, 24-26 oct. 2001, actes sur CD-ROM, 102.pdf [2] Commission Électrotechnique Internationale, « Automates programmables – partie 3 : langages de programmation », norme internationale IEC 61131-3, novembre 1993. [3] J. Zaytoon, V. Carré-Ménétrier, « Grafcet et graphe d’états : comportement, raffinement, vérification et validation », APII-JESA, vol. 33, n°7, p. 751-782, 1999 [4] S. Lamperière-Couffin, O. Rossi, J.-J. Lesage, J. M. Roussel, « Formal validation of PLC programs: a survey », ECC’99, Karlsruhe, Allemagne, 31 aôut-3 sept. 1999. [5] Ouvrage collectif coordonné par P. Schnoebelen, « Vérification de logiciels – techniques et outils du model-checking », Vuibert, Paris, 1999. [6] L. Regimbal, « Application de la théorie de contrôle par supervision : proposition d’une approche d’implantation décentralisée », mémoire d’ingénieur CNAM, soutenance prévue en janvier 2002. [7] P. J. Ramadge, W. M. Wonham, « Supervisory control of a class of discrete event processes », SIAM journal on Control and Optimization, vol. 25, n°1, p. 206-230, 1987. [8] S. Chafik, « Proposition d’une structure de contrôle par supervision hiérarchique et distribuée : Application à la coordination », Mémoire de thèse de l’INSA de Lyon, soutenue le 22 décembre 2000. [9] F.Lin, W.M.Wonham, "Decentralized Supervisory Control of Discrete-Event Systems", Inform.Sci., vol. 44, n°3. p. 199-244, 1988. [10] F.Lin, W.M.Wonham, "Decentralized Control and Coordination of Discrete-Event Systems with Partial Observation",. IEEE Transactions on Automatic Control, vol. 35, n°12, p. 1330-1337, 1990.