Méthodologie de modélisation dans le cadre de la synthèse formelle des SED

30/09/2017
Publication e-STA e-STA 2005-2
OAI : oai:www.see.asso.fr:545:2005-2:20016
DOI :

Résumé

Méthodologie de modélisation dans le cadre de la synthèse formelle des SED

Métriques

13
5
320.92 Ko
 application/pdf
bitcache://6ea95e68f842a294d4faa29ba5588d21043396b4

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:2005-2/20016</identifier><creators><creator><creatorName>Abdelouahed Tajer</creatorName></creator><creator><creatorName>François Gellot</creatorName></creator><creator><creatorName>Véronique Carre-Menetrier</creatorName></creator><creator><creatorName>Alexandre Philippot</creatorName></creator></creators><titles>
            <title>Méthodologie de modélisation dans le cadre de la synthèse formelle des SED</title></titles>
        <publisher>SEE</publisher>
        <publicationYear>2017</publicationYear>
        <resourceType resourceTypeGeneral="Text">Text</resourceType><dates>
	    <date dateType="Created">Sat 30 Sep 2017</date>
	    <date dateType="Updated">Sat 30 Sep 2017</date>
            <date dateType="Submitted">Fri 25 May 2018</date>
	</dates>
        <alternateIdentifiers>
	    <alternateIdentifier alternateIdentifierType="bitstream">6ea95e68f842a294d4faa29ba5588d21043396b4</alternateIdentifier>
	</alternateIdentifiers>
        <formats>
	    <format>application/pdf</format>
	</formats>
	<version>34038</version>
        <descriptions>
            <description descriptionType="Abstract"></description>
        </descriptions>
    </resource>
.

ALEXANDRE PHILIPPOT, ABDELOUAHED TAJER, FRANÇOIS GELLOT, VERONIQUE CARRE-MENETRIER Centre de Recherche en STIC (CReSTIC) UFR Sciences de Reims, Moulin de la Housse, BP 1039, 51687 Reims Cedex 2, France alexandre.philippot, abdelouahed.tajer, francois.gellot, veronique.carre@univ-reims.fr http://cifa2004.ec-lille.fr/ Méthodologie de modélisation dans le cadre de la synthèse formelle des SED Résumé— Les approches formelles de vérification ou de synthèse de la commande des SED nécessitent une modélisation du système et de ses spécifications, tâche relativement difficile du fait de la complexité des systèmes réels. Dans ce papier, nous proposons une méthodologie de modélisation du procédé et des contraintes pour améliorer la praticabilité de ces approches formelles. Cette méthodologie est utilisée dans le cadre d’une approche formelle de synthèse de commande spécifiée par Grafcet. Un exemple de préhenseur pneumatique illustre le papier. Mots clés— Grafcet, automates, synthèse de commande, théorie de supervision, modèles à base de règles I. INTRODUCTION L’objectif de nos travaux est de fournir, pour la commande d’un procédé donné, spécifiée par Grafcet [1], une implantation sur Automate Programmable Industriel (A.P.I.) qui soit réactive, déterministe et sans blocage. Cette implantation doit alors avoir le comportement le plus large possible par rapport à la commande et un ensemble de contraintes de sécurité et de vivacité [2]. La démarche s’articule autour d’une étape de préparation à la génération de la commande, d’une étape de génération de la commande proprement dite et d’une étape d’exécution de la commande. Le schéma de la figure 1 résume ces différentes étapes qui sont explicitées dans la suite du papier. Nous n’aborderons pas ici le formalisme que le lecteur pourra retrouver dans [3]. ASS: Automate des Situations Stables Actions Evénements événements, conditions actions Exécution de la commande Σu Σc SUP: Automate correspondant au langage suprême du procédé supervisé Activation/désactivation de Σc Σc ∪ Σu Contraintes de sécurité et de vivacité Procédé Système en execution Extraction [ROU 94] Grafcet Synthèse [KUM91] SYNC: Automate du comportement commun à ASS et à SUP OPT: Automate correspondant à l’implantation optimale de la commande Extraction des états bloquants Visualisation des corrections en temps réel Visualisation et analyse des séquences bloquantes Visualisation des corrections avant implantation Figure 1 : Démarche de synthèse formelle à partir de spécifications Grafcet Pour la première étape, le concepteur doit modéliser la commande sous forme de Grafcet, le comportement de la partie opérative et des contraintes de sécurité et/ou de vivacité sous forme d'automates conformes à ceux utilisés dans la théorie de supervision [4]. A partir de ces modèles sont élaborés deux automates : l’automate des situations stables ASS [5] représentant l’automate de commande qui est déterministe et réactif, et l’automate du superviseur SUP décrivant le plus large comportement commandable admissible du procédé par rapport aux contraintes spécifiées [6]. Dans la seconde étape, les actions du Grafcet lorsqu'elles ne sont pas admissibles par SUP, sont filtrées grâce à une intersection particulière des automates SUP et ASS. Il s’agit ensuite de retirer les évolutions bloquantes et non atteignables pour générer OPT le graphe d’états correspondant à la commande optimale. Cette démarche de synthèse étant sensible aux erreurs de modélisation, nous avons intégré le concepteur dans la boucle d’élaboration de la commande, en lui proposant de visualiser la ou les séquences bloquantes, lui permettant ainsi d’agir sur les raisons du blocage en modifiant par exemple la commande, en relâchant des contraintes ou en affinant le modèle de la partie opérative. De nouvelles itérations de la synthèse sont alors effectuées à partir des modèles corrigés pour générer en finalité un modèle de commande correcte [7]. Nous proposons également au concepteur de visualiser les corrections apportées par la démarche avant l’implantation de la commande, corrections qui portent sur l'interdiction des actions du Grafcet non autorisées dans l'état courant du graphe de commande connecté au procédé. Dans la dernière étape de la démarche, la commande optimale implantée est exécutée et une animation en ligne du Grafcet originel est proposée au concepteur lui permettant de visualiser les corrections apportées et acceptées par ailleurs. Nous avons montré l’applicabilité de cette démarche sur plusieurs exemples [2], [3], [8]. Cependant, pour être réellement praticable sur des systèmes réels complexes, cette approche se heurte à des problèmes liés à la difficulté de modélisation du comportement du procédé et des contraintes ainsi qu’à l’explosion combinatoire inhérente aux modèles utilisés. Pour comprendre l’intérêt d’une méthodologie de modélisation, nous proposons en section 2 d’illustrer notre démarche de synthèse sur un exemple afin de montrer les difficultés rencontrées lors d’une modélisation intuitive du procédé et des contraintes. En section 3, nous présentons une méthodologie de modélisation de la partie opérative appliquée au même exemple et dans la section 4, nous proposons une adaptation de cette méthodologie pour la modélisation des contraintes de sécurité et de vivacité. Le préhenseur qui illustre le papier est présenté succinctement figure 2.a et 2.b. Il a pour rôle de saisir un pignon dans un tiroir pour ensuite le déposer sur un axe. La préhension s’effectue par aspiration, le déplacement vertical par un vérin double effet piloté par un distributeur mono-stable et le déplacement horizontal par un vérin double effet piloté par un distributeur bi-stable. Les caractéristiques complètes sont disponibles à l’adresse http://www.lurpa.ens-cachan.fr/cosed/, il s’agit d’un benchmark élaboré dans le cadre du groupe de travail COSED (ce groupe s’intitule désormais INCOS depuis octobre 2003) du GDR MACS [8]. ENTREES Evénements non commandables Σu SORTIES Evénements commandables Σc pièce dcy haut bas gauche droite DESCENDRE ASPIRER AVANCER RECULER Poste de prise Poste de dépose Mouvement à effectuer Avec aspiration Sans aspiration RECULER AVANCER DESCENDRE a) Paramètres du préhenseur pneumatique b) Entrées/Sorties du système du point de vue de la commande Figure 2 : Caractéristiques du préhenseur pneumatique II. PROBLEMATIQUE DE LA MODELISATION A TRAVERS L’EXEMPLE A. Préparation à la génération de la commande 1. Notation et préliminaires Pour bénéficier du cadre formel lié à la théorie de supervision [4], la modélisation de la partie opérative ainsi que la spécification des contraintes de sécurité et de vivacité s’effectue sous forme d'automates décrivant les évolutions physiquement possibles du procédé par des événements simples. Pour refléter les interactions entre la commande spécifiée par Grafcet et la partie opérative, nous avons choisi l'interprétation de S. Balemi [9], où les événements commandables Σc représentent les entrées du procédé et les événements non commandables Σu ses sorties. La commande peut dès lors forcer à tout instant l'entrée du procédé et la génération des événements est initiée conjointement par le procédé et/ou la commande. Cette interprétation est spécialisée de manière à concilier la nature continue des actions et des variables d'entrée du Grafcet avec le caractère événementiel du modèle de la théorie. Ainsi, nous avons retenu la correspondance suivante : un événement commandable correspond soit à l'activation ↑z soit à la désactivation ↓z d'un ordre du Grafcet, tandis qu'un événement non commandable est associé soit au front montant ↑e soit au front descendant ↓e d'une variable d'entrée du Grafcet. Les ensembles Σc et Σu s’écrivent alors Σc = ↑Z ∪ ↓Z et Σu = ↑E ∪ ↓E. Les ensembles d'événements ↑Z et ↓Z, correspondent aux activations et désactivations des ordres, tandis que les ensembles d’événements ↑E et ↓E reflètent les fronts montant et descendant des entrées. Nous n’insisterons pas dans cette partie sur la modélisation de la commande où aucune contrainte particulière n'est imposée pour cette activité de nature intuitive, le concepteur devant simplement se conformer à la définition du modèle Grafcet. L’extraction de l’Automate des Situations Stables ASS s’effectue par l’intermédiaire de l’outil AGGLAE [5]. 2. Modélisation de la partie opérative La description précise du comportement de la partie opérative est une opération complexe car les évolutions d'un système physique sont de nature asynchrone et non déterministe. Pour contourner les difficultés d’une modélisation globale, nous avons choisi une démarche modulaire permettant d’exprimer des causalités simples entre les éléments de la P.O. Par conséquent, la modélisation s’effectue à l'aide d'un automate réceptif aux ordres de la commande et qui agit sur l'évolution des valeurs logiques des entrées du Grafcet de manière à exprimer les réactions de la partie opérative. Dans le cadre de l’exemple du préhenseur, le modèle complet est constitué de quatre automates décrivant respectivement le mouvement horizontal illustré figure 3, le mouvement vertical, le mouvement d’aspiration et le bouton poussoir départ cycle. Ces modèles tiennent compte de la technologie des vérins animant le préhenseur pneumatique [8]. En situation initiale, le préhenseur est en position haute, à gauche, l’aspiration est au repos et le bouton poussoir dcy est relâché. Concernant le mouvement horizontal, le préhenseur quittant sa position initiale (état 0 sur la figure 3), peut se déplacer soit à droite (état 1), soit à gauche (état 5). L’activation de l’ordre AVANCER lance le déplacement du préhenseur vers la droite, lui faisant quitter la position gauche (état 2). La continuation du mouvement lui fait atteindre la position droite (état 3). La désactivation de l’ordre AVANCER lui permet de revenir à l’état initial. A partir de l’état 1, si l’ordre AVANCER est désactivé, le préhenseur retourne dans son état initial. Dans l’état 2, la désactivation de AVANCER ne permet plus un retour en situation initiale car la technologie utilisée force le préhenseur à aller vers la droite (état 4 puis état 0). Le comportement du préhenseur pour un mouvement vers la gauche à partir de la situation initiale est similaire à celui de droite. ↑RECULER 2 1 4 3 5 7 8 6 ↑AVANCER ↓AVANCER ↓RECULER ↑gauche ↓gauche ↑droite ↓AVANCER ↑AVANCER ↑droite ↑gauche ↓RECULER ↓droite ↓RECULER ↑RECULER 0 ↑ AVANCER ↑ RECULER Mouvement horizontal ↓AVANCER Figure 3 : Modèle du mouvement horizontal Le modèle global associé au comportement de la partie opérative est alors obtenu par la composition asynchrone des différents automates et se compose pour cet exemple simple de 432 états et 2664 transitions. 3. Modélisation des contraintes Les contraintes à modéliser portent sur l’inhibition des actions et/ou l’agencement et le séquencement d’exécution des commandes envoyées au procédé. Pour modéliser des contraintes complexes, plusieurs automates peuvent être utilisés et ensuite composés pour obtenir le modèle global des contraintes. Pour l’exemple, nous avons imposé quatre contraintes de sécurité ainsi que deux contraintes de vivacité liées à l’aspiration. a) Contrainte N° 1 : Ne pas avancer et reculer en même temps 0 1 2 ↑AVANCER ↓AVANCER ↓RECULER ↑RECULER Σ-{↓AVANCER, ↑RECULER} Σ-{↓RECULER, ↑AVANCER} Σ-{↑RECULER, ↑AVANCER} ↑ASPIRER Σ-{↑gauche, ↑bas, ↑dcy, ↑ASPIRER} Σ-{↑ASPIRER, ↑bas, ↓gauche} 1 2 Σ-{↑ASPIRER, ↓bas, ↓gauche} 0 0 ↓bas ↓gauche {↑gauche, ↑dcy} ↑bas b) Contraintes N° 5 : Commencer l’aspiration en bas et à gauche Σ-{↑ASPIRER, ↓bas, ↑gauche} 3 ↑bas ↓bas ↓gauche ↑gauche Figure 4 : Modèle des contraintes de sécurité et de vivacité La première contrainte est illustrée figure 4.a, elle consiste à interdire l'activation simultanée des ordres AVANCER et RECULER. L'état 0 correspond à l'ensemble des états du procédé où tous les ordres sont autorisés sauf AVANCER et RECULER qui sont des événements permettant de sortir de l’état 0. L’évolution vers l’état 1 s’effectue par l'activation de l'ordre AVANCER (le retour à l’état 0 est conditionné par la désactivation de AVANCER). L’état 1 autorise alors tous les ordres, excepté l’ordre RECULER. Pour interdire l’activation de l’ordre AVANCER, quand l’ordre RECULER a été envoyé vers la partie opérative (état 2), le raisonnement est identique. Les autres contraintes de sûreté consistent à interdire l’occurrence simultanée des ordres DESCENDRE et RECULER, AVANCER et DESCENDRE ainsi qu’à n’autoriser les mouvements horizontaux qu'en position haute. L’automate de la figure 4.b décrit la contrainte de vivacité qui représente la chronologie des événements autour de l’aspiration. Elle impose que l’ordre ASPIRER soit envoyé lorsque le préhenseur se situe en bas à gauche. Le modèle global des contraintes est alors obtenu par composition synchrone des automates. Il se compose de 128 états et 1856 transitions. L'opération de synthèse [6] consiste ensuite, à partir des modèles du procédé et des contraintes, à générer l'automate du superviseur SUP qui pour cet exemple est constitué de 1030 états et 4143 transitions. B. Génération de l’automate de commande Cette étape consiste à déterminer dans un premier temps l'automate SYNC représentant le comportement commun des automates SUP et ASS. Il s'agit d'un automate composé de 95 états et 187 transitions, regroupés à travers 57 régions. L’objectif est ensuite, de générer la commande réactive et déterministe (automate OPT) correspondant au plus grand sous-ensemble de comportements de SYNC, exempt de blocage. L’automate de commande OPT comporte alors 57 états et 111 transitions. Cet automate peut ensuite être implanté dans une architecture programmable [10]. Le tableau 1 résume les tailles des différents automates. ASS Procédé Contraintes SUP SYNC OPT 11 états 23 trans. 432 états 2664 trans. 128 états 1856 trans. 1030 états 4143 trans. 95 états 187 trans. 57 régions 57 états 111 trans. Tableau 1 : Bilan des différents automates C. Discussion Dans une démarche de synthèse, la modélisation de la partie opérative s’avère indispensable car même s'il est identifié sans blocage lors de ses évolutions théoriquement possibles, le modèle de la commande peut engendrer des blocages durant l'exécution réelle s'il entraîne la partie opérative dans une situation logiquement incompatible avec l'expression logique des transitions validées. Cependant, les modèles d’éléments de partie opérative et de contraintes que nous venons de présenter, sont complexes et conduisent à se poser plusieurs questions : Comment vérifier que rien n’a été oublié en termes d’états et de transitions, comment intégrer de nouveaux éléments dans ces modèles sans tout recomposer... La modélisation proposée actuellement fait appel non seulement à une bonne connaissance du système, mais aussi à l’expérience et les compétences en terme de modélisation du concepteur. Lors de l’élaboration des modèles du système et de ses spécifications, le concepteur a tendance à faire l’amalgame entre le modèle de la commande, le modèle de la partie opérative et le modèle des contraintes. Par exemple, au niveau de la commande, le concepteur cherche implicitement à intégrer une image de la partie opérative dans le Grafcet afin d'exprimer la causalité entre l’envoi des ordres et les réactions conséquentes de la partie opérative. Ceci suppose cependant, que toutes les réactions du procédé et leur ordonnancement, sont connus de manière précise pour chaque action et chaque situation de la commande. C’est illusoire car la complexité et la nature parallèle des systèmes de commande et des procédés à commander entraînent des évolutions parallèles et complexes entre l'envoi des ordres et les réactions conséquentes du procédé. De même au niveau de la partie opérative, ce sont les contraintes de sécurité que le concepteur tente d’intégrer implicitement afin d’exprimer au plus tôt, des restrictions sur le comportement du procédé. Dans l’exemple, le modèle du mouvement horizontal (figure 3) intègre la contrainte « Ne pas avancer et reculer en même temps ». La contrainte est dans cet exemple, simple à exprimer car il s’agit d’un modèle élémentaire de partie opérative mais ceci risque d’être beaucoup plus complexe lorsqu’il s’agit de modèles où la granularité du comportement modélisé est différente. D’autre part, quand des éléments du système doivent être ajoutés, retirés ou configurés différemment, le concepteur doit revoir l’ensemble des modèles et ses interactions. Il est donc préférable de s’appuyer sur des modèles explicites et indépendants pour la commande, la partie opérative et les contraintes. Néanmoins, la modélisation explicite de la partie opérative est une tâche complexe qui se heurte non seulement à des problèmes méthodologiques de structuration et de composition de ses éléments mais aussi au choix de la granularité du comportement modélisé. Par conséquent, nous proposons dans la suite du papier une méthode structurée à base de règles, en s’appuyant sur des travaux de V. Chandra [11], pour aider le concepteur dans sa tâche de conception des modèles de partie opérative. Nous montrerons que cette structuration peut être étendue moyennant quelques adaptations à la modélisation des contraintes III. METHODOLOGIE DE MODELISATION DE LA PARTIE OPERATIVE Pour structurer, nous avons retenu une modélisation à base de règles définissant les interactions entre les événements commandables et les événements non commandables et de relations précisant les liens entre les événements non commandables. Il s’agit dans le premier cas de règles dites d’occurrence et dans le second cas, de relations de précédence. Ces règles définies par l’utilisateur sont ensuite traduites en automates compatibles avec les principes énoncés précédemment concernant en autre la notation et la sémantique de cette notation (voir § II.A et II.B). A. Règles d’occurrence et relations de précédence Avant de déterminer les règles d’occurrence des événements commandables, il faut commencer par fixer le contexte c’est à dire les conditions initiales du système. Il s’agit ensuite de recenser tous les événements liés à l’élément de partie opérative que l’on cherche à modéliser puis de définir sous forme de règles, l’influence de l’activation et de la désactivation des événements commandables sur les événements non commandables. Par conséquent, chaque règle va s’exprimer selon le principe simple d’une « cause/conséquence », la cause est liée à l’événement commandables et la conséquence porte sur l’événement non commandable. Pour chaque règle d’occurrence ayant la même cause, il faut ensuite établir sous forme de relations de précédence, la chronologie liant les événements non commandables conséquents. Dans le cadre de l’exemple et pour le mouvement horizontal, il existe deux événements commandables AVANCER et RECULER, et deux événements non commandables gauche et droite. En situation initiale, le vérin se trouve à gauche et aucun ordre n’est envoyé à la partie opérative. Afin de définir les règles d’occurrence, il faut s’intéresser aux conséquences des ordres envoyés. L’activation de l’ordre AVANCER permet au vérin de se déplacer vers la droite et de quitter sa position gauche. De même, l’activation de RECULER fait revenir le vérin de la position droite jusqu’au fin de course gauche. Suite à l’activation d’AVANCER, la chronologie des événements non commandables est la suivante : désactivation de gauche puis activation de droite. Pour la relation de précédence liée à l’activation de l’ordre RECULER, la chronologie se présente ainsi : désactivation de droite avant activation de gauche. Les conditions initiales et les différentes relations concernant le mouvement horizontal sont résumées sur le tableau 2. Conditions Initiales ↓ AVANCER ↓ RECULER ↓ droite ↑gauche ↑AVANCER → ↓ gauche ↑AVANCER → ↑droite ↑RECULER → ↓ droite ↑RECULER → ↑gauche ↓AVANCER → ↑ droite ↓RECULER → ↑gauche Règles d’occurrence Relations de précédence ↓ gauche précède ↑droite ↓ droite précède ↑gauche néant néant Tableau 2 : Paramètres du modèle de mouvement horizontal B. Construction de l’automate de partie opérative La construction de l’automate de la partie opérative s’appuie sur les informations précédemment acquises et s’effectue selon les quatre étapes suivantes : 1. Construire l’automate à 2n états (n étant le nombre d’événements commandables) décrivant toutes les évolutions possibles des événements commandables à partir des conditions initiales données. 2. Compléter l’automate obtenu précédemment, par les événements non commandables résultant des règles d’occurrence, 3. Construire un automate dit de précédence à partir des relations de précédence et de la situation initiale des événements non commandables, 4. Faire le produit croisé synchrone de l’automate issu des règles d’occurrence et de l’automate de précédence. Cette méthode de modélisation s’effectue pour chaque partie de notre système. Le modèle global de partie opérative s’obtient alors par composition asynchrone de tous les modèles. Les étapes 1 et 2 de cette méthode consistent donc à établir pour le mouvement horizontal un automate à 4 états avec des évolutions entre état liées à l’activation ou la désactivation de l’ordre AVANCER et de l’ordre RECULER, puis compléter cet automate par les événements non commandables gauche et droite en respectant les règles d’occurrence définies par l’utilisateur. Ces étapes sont illustrées figures 5.a et 5.b. Aucun ordre n’étant activé dans les conditions initiales, l’état 0 de la figure 5.a permet soit l’activation de l’ordre AVANCER (état 1), soit l’activation de l’ordre RECULER (état 2). A partir de l’état 1, la désactivation de AVANCER est alors possible ce qui permet de retourner à l’état initial. A partir de l’état 1, l’activation de l’ordre RECULER est également possible et permet de se rendre à l’état 3. De même, à partir de l’état 2, il est possible de retourner à l’état 0 par désactivation de RECULER ou de partir vers l’état 3 par activation de AVANCER. A partir de cet automate, il faut ajouter des boucles sur les états prenant en compte les événements non commandables définis dans les règles d’occurrences (Fig. 5.b). Suite à l’activation de l’ordre AVANCER (états 1 et 3 de l’automate précédent), il est possible de désactiver gauche et d’activer droite. L’activation de l’ordre RECULER entraîne quant à lui des boucles dans les états 2 et 3 avec l’activation de gauche et la désactivation de droite comme événements non commandables. L’étape 3 conduit à établir avec les deux relations de précédence liant gauche et droite, l’automate de précédence illustré figure 5.c. A l’initialisation, le vérin est à gauche (état 0), l’activation de droite (état 2) ne peut se faire qu’après une désactivation de gauche en état 1. De même, pour retourner en état 0, la désactivation de droite (état 1) précède l’activation de gauche. Chaque état de cet automate autorise bien sûr tous les événements Σc du système. Pour obtenir l’automate final du mouvement horizontal (Fig. 5.d), il suffit alors d’effectuer un produit croisé synchrone entre l’automate issu de l’étape 2 et l’automate de précédence issu de l’étape 3. Le mouvement est alors décrit de façon complète indépendamment de la commande à travers 12 états et 35 transitions. La comparaison avec le modèle intuitif de la figure 3 montre clairement qu’aucune contrainte n’a été prise en compte dans le modèle de la figure 5.d, car par exemple pour l’état 3 les deux ordres AVANCER et RECULER sont envoyés en même temps à la partie opérative. C’est donc l’opération de synthèse qui supprimera les trajectoires non souhaitées par l’utilisateur. 0 1 ↑ AVANCER ↓ AVANCER ↑ RECULER 2 ↓ RECULER ↑ RECULER 3 ↓ RECULER ↑ AVANCER ↓ AVANCER 2 1 ↑ gauche ↑ droite 0 ↓ gauche ↓ droite Σc Σc Σc a) Automate des événements commandables b) Automate avec la prise en compte des événements non commandables c) Automate de précédence d) Automate final du mouvement horizontal ↓ gauche ↑ droite ↑ gauche ↓ droite 0 1 ↑ AVANCER ↓ AVANCER ↑ RECULER 2 ↓ RECULER ↑ RECULER 3 ↓ RECULER ↑ AVANCER ↓ AVANCER ↓ gauche ↑ droite ↑ gauche ↓ droite ↑ droite ↑droite ↑ gauche ↑ gauche ↓ gauche ↑ droite ↓ droite 0 1 ↑ AVANCER ↓ AVANCER 2 ↓ RECULER ↑ RECULER 3 ↑ AVANCER ↓ AVANCER ↑ RECULER ↓ RECULER 4 6 ↑ AVANCER ↓ AVANCER 5 ↓ RECULER ↑ RECULER 8 ↑ AVANCER ↓ AVANCER ↑ RECULER ↓ RECULER 7 10 ↑ AVANCER ↓ AVANCER 9 ↓ RECULER ↑ RECULER 11 ↑ AVANCER ↓ AVANCER ↑ RECULER ↓ RECULER ↑ droite ↑ gauche ↓ gauche ↓ droite ↑ droite ↑ droite ↑gauche Figure 5. Etapes de la construction de l’automate du mouvement horizontal La construction des automates du mouvement vertical, du mouvement d’aspiration et du bouton poussoir départ cycle, s’effectue de manière identique. L’automate global de la partie opérative est alors obtenu par produit croisé asynchrone de ces modèles ce qui correspond à un automate de 288 états et 2184 transitions. IV. MODELISATION DES CONTRAINTES Notre méthode est basée sur les règles d’occurrence et des relations de précédence dont nous avons donné les définitions dans le paragraphe précédent. La modélisation des contraintes nous impose de modifier quelque peu ces définitions : les règles d’occurrence définissent un lien entre les événements commandables et les événements non commandables qu’ils soient cause ou conséquence et quant aux relations de précédence, elles définissent un lien soit entre événements commandables entre eux, soit entre événements non commandables entre eux. Nous définissons alors les contraintes de sécurité comme étant des contraintes entre événements commandables et les contraintes de vivacité comme des contraintes entre événements commandables et événements non commandables. Par conséquent, la méthode de modélisation des contraintes va dépendre du type de contrainte à modéliser. A. Modélisation des contraintes de sécurité La démarche consiste à établir i) la situation initiale, ii) les relations de précédence entre les événements commandables utilisées dans ce type de contraintes. Aucun événement non commandable n'intervenant dans cette contrainte, il n'y a donc aucune règle d'occurrence entre événements commandables et événements non commandables. La construction de l’automate de contraintes s’effectue alors à partir des conditions initiales et des relations de précédence. Comme pour le modèle de partie opérative, il faut prendre en compte dans l’automate de précédence et au niveau de chaque état, tous les autres événements du système sauf ceux de la contrainte. Pour la contrainte « Ne pas avancer et descendre en même temps », l’application de la démarche fournit les relations suivantes : Conditions initiales : ↓AVANCER, ↓DESCENDRE. 1) 2) Relations de précédence : ↑AVANCER → ↓AVANCER ↓AVANCER → ↑AVANCER ↓AVANCER → ↑DESCENDRE ↑DESCENDRE → ↓DESCENDRE ↓DESCENDRE → ↑DESCENDRE ↓DESCENDRE → ↑AVANCER 3) Prendre en compte l’ensemble des événements sauf AVANCER et DESCENDRE La construction de l’automate est illustrée en figures 6.a et 6.b. a) Automate de précédence 1 0 ↑DESCENDRE 2 ↓DESCENDRE ↑AVANCER ↓AVANCER b) Automate final Σ-{DESCENDRE, AVANCER} 1 0 ↑DESCENDRE 2 ↓DESCENDRE ↑AVANCER ↓AVANCER Σ-{DESCENDRE, AVANCER} Σ-{DESCENDRE, AVANCER} Figure 6 : Construction de l’automate représentant la contrainte « Ne pas avancer et reculer en même temps » B. Modélisation des contraintes de vivacité La démarche consiste à établir i) la situation initiale, ii) les règles d’occurrence entre événements non commandables (cause) et événements commandables (conséquence) utiles à la contrainte, iii) les relations de précédence entre les événements commandables. La construction de l’automate de contraintes s’effectue alors à partir des conditions initiales, des règles d’occurrence et des relations de précédence. Cette construction doit cependant s’effectuer en tenant compte de la structure même de la contrainte. En effet, la contrainte « Commencer l’aspiration en bas ou à gauche » ne conduit pas au même modèle que la contrainte « Commencer l’aspiration en bas et à gauche ». Il faut donc traiter différemment une structure de contrainte exprimée sous forme d’un OU logique entre les événements non commandables et une structure en ET. Pour une structure en OU, la construction se compose de cinq étapes assez similaires à celles de la construction de l’automate de partie opérative : 1. Construire l’automate à 2n états (n représente le nombre d‘événements non commandables) décrivant les évolutions des événements non commandables à partir des conditions initiales données, 2. Compléter cet automate par une boucle sur chaque état autorisant tous les événements exceptés les événements commandables liés aux conséquences des règles, 3. Compléter l’automate précédent en prenant en compte au niveau des boucles, les événements commandables liés à la partie conséquence des règles d’occurrence, 4. Construire l’automate des relations de précédence, s’il existe de telles relations, 5. Calculer le produit croisé synchrone entre les automates résultant des étapes 3 et 4. Pour la contrainte « Commencer l'aspiration en bas OU à gauche », les relations sont les suivantes : a. Conditions initiales : ↓ASPIRER, ↑gauche et ↓bas b. Règles d’occurrence : -↑ bas => ↑ASPIRER -↑ gauche => ↑ASPIRER c. Relations de précédence : - Aucune Pour cette contrainte, la première étape de la construction génère un automate à quatre états liés aux événements bas et gauche. En tenant compte des conditions initiales, ces deux automates sont représentés sur la figure 7.a. Il faut ajouter ensuite les boucles correspondant aux événements admissibles sauf ASPIRER (Fig. 7.b). Les conséquences des règles d’occurrence concernent seulement l’activation de l’ordre ASPIRER qui est autorisé lorsque l’on se trouve en bas ou à gauche (Fig. 7.c). Comme aucune relation de précédence n’est définie, l’automate final pour la contrainte correspond à l’automate de boucles contraint (Fig. 8.d). A partir de l’état initial, tout ordre est autorisé car la condition gauche est vérifiée, seul l’état 2 n’autorise pas l’activation de ASPIRER car gauche et bas sont désactivés dans cet état. a) Automate de cause à 2n états b) Automate de boucles c) Automate de boucles contraint 0 1 ↑bas ↓bas ↓gauche 2 ↑gauche ↓gauche 3 ↑gauche ↑bas ↓bas d) Automate final 0 1 ↑bas ↓bas ↓gauche 2 ↑gauche ↓gauche 3 ↑gauche ↑bas ↓bas Σ-{↑ASPIRER, ↑bas, ↑gauche} Σ-{↑ASPIRER, ↓bas, ↓gauche} Σ-{↑ASPIRER, ↓bas, ↑gauche} Σ-{↑ASPIRER, ↓bas, ↑gauche} 0 1 ↑bas ↓bas ↓gauche 2 ↑gauche ↓gauche 3 ↑gauche ↑bas ↓bas Σ-{↑bas, ↑gauche} Σ-{↓bas, ↓gauche} Σ-{↓bas, ↑gauche} Σ-{↑ASPIRER, ↓bas, ↑gauche} 0 1 ↑bas ↓bas ↓gauche 2 ↑gauche ↓gauche 3 ↑gauche ↑bas ↓bas Σ-{↑bas, ↑gauche} Σ-{↓bas, ↓gauche} Σ-{↓bas, ↑gauche} Σ-{↑ASPIRER, ↓bas, ↑gauche} Figure 7 : Construction de l’automate représentant la contrainte « Commencer l’aspiration en bas ou à gauche» Pour une structure en ET, la construction se compose de six étapes sensiblement différentes de la méthode de construction précédente : 1. Construire un automate pour chaque règle ce qui revient à construire un automate à 2 états pour chaque événement non commandables à partir des conditions initiales données, 2. Compléter cet automate par une boucle sur chaque état autorisant tous les événements exceptés les événements commandables liés aux conséquences des règles, 3. Compléter l’automate précédent en prenant en compte au niveau des boucles, les événements commandables liés à la partie conséquence des règles d’occurrence, 4. Etablir le produit croisé synchrone des différents automates de règles, 5. Construire l’automate des relations de précédence, s’il existe de telles relations, 6. Calculer le produit croisé synchrone entre les automates résultant des étapes 5 et 4. Pour la contrainte « Commencer l'aspiration en bas ET à gauche », les relations sont identiques à la contrainte « Commencer l'aspiration en bas OU à gauche ». Pour cette contrainte, la première étape de la construction génère deux automates. Le premier est lié à l’événement bas et le second à l’événement gauche. En tenant compte des conditions initiales, ces deux automates sont représentés sur la figure 8.a. Il faut ajouter ensuite les boucles correspondant aux événements admissibles sauf ASPIRER (Fig. 8.b). Les conséquences des règles d’occurrence concernent seulement l’activation de l’ordre ASPIRER qui est autorisé lorsque l’on se trouve en bas (Fig. 8.c.1) et à gauche (Fig. 8.c.2). Comme aucune relation de précédence n’est définie ici, l’automate final pour la contrainte s’obtient par composition synchrone des deux automates de règles (Fig. 8.d). A partir de l’état initial, tout ordre est autorisé mis à part l’activation d’ASPIRER car les conditions bas et gauche ne sont vérifiées, seul l’état 1 autorise l’activation de ASPIRER. 0 1 ↑bas ↓bas a) Automates de causes b) Automates de boucles d) Automate final de la contrainte 0 1 ↑gauche ↓gauche 2. Automate pour gauche 1. Automate pour bas 1. Automate pour bas 0 1 ↑bas ↓bas ↓gauche 2 ↑gauche ↓gauche 3 ↑gauche ↑bas ↓bas Σ-{↑ASPIRER, ↑gauche, ↑bas} Σ-{↑ASPIRER, ↓bas, ↑gauche } Σ-{↓gauche, ↓bas} Σ-{↑ASPIRER, ↑bas, ↓gauche} c) Automates de boucles contraints Σ-{↑ASPIRER, ↓bas} 0 1 ↑bas ↓bas Σ-{↑ASPIRER, ↑bas} 2. Automate pour gauche 1. Automate pour bas 0 1 ↑bas ↓bas Σ-{↓bas} Σ-{↑ASPIRER, ↑bas} 0 1 ↑gauche ↓gauche Σ-{↓gauche} Σ-{↑ASPIRER, ↑gauche} 2. Automate pour gauche 0 1 ↑gauche ↓gauche Σ-{↑ASPIRER, ↑gauche} Σ-{↑ASPIRER, ↓gauche} Figure 8. Construction du modèle de la contrainte « Commencer l’aspiration en bas et à gauche » Cette méthode a été utilisée pour chacune des contraintes définies au §II.B.2. Pour obtenir l’automate des contraintes global, il faut effectuer une composition synchrone des différents automates obtenus ce qui engendre un automate possédant 64 états et 1056 transitions. V. CONCLUSION La difficulté de modélisation, qu’elle soit pour la partie opérative ou pour les contraintes de sécurité et de vivacité, nous a conduit à proposer une méthodologie formelle d’aide à la modélisation. Basée sur des règles d’occurrence liant événements commandables et événements non commandables et des relations de précédence entre événements de même type, cette méthode permet au concepteur de décrire facilement son système sans avoir à modéliser directement des automates à états. La comparaison entre les automates obtenus par modélisation intuitive et par modélisation systématique (Tableau 3) montre une diminution du nombre d’états et de transitions. Il reste néanmoins à établir le formalisme de modélisation afin d’automatiser cette méthode. Méthode intuitive Méthode systématique Partie opérative 432 états 2664 transitions 288 états 2184 transitions Contraintes 128 états 1856 transitions 64 états 880 transitions Tableau 3 : Comparaison des méthodes de modélisation Cependant, la méthode est sensible aux erreurs du concepteur dans la définition des règles et/ou des relations pouvant entraîner des blocages dans la procédure de synthèse de commande. Le concepteur étant intégré dans la boucle d’élaboration de la commande, est assisté dans la recherche des causes conduisant à de tel blocage. Cette assistance permet ainsi de vérifier la cohérence des règles et relations ayant servies à l’élaboration des différents automates. VI. REMERCIEMENTS Les auteurs tiennent à remercier J.M. Roussel du LURPA de Cachan pour la mise à disposition de l'outil AGGLAE sous différentes cibles et pour les modifications apportées à cet outil le rendant compatible avec l’outil support de notre démarche. VII. REFERENCES [1] International Electrotechnical Commission, Preparation of function charts for control systems. Publication 848, 2002 revised version. [2] J. Zaytoon, V. Carré-Ménétrier, Synthesis of a correct control implementation for manufacturing systems, International Journal of Production Research, vol. 39, n°2, p. 329-345, 2001. [3] V. Carré-Ménétrier, J. Zaytoon, Grafcet : behavioral issues and control synthesis, European Journal of Control, vol. 8, n° 4, p. 375-401, 2002. [4] W.M. Wonham, P.J. Ramadge. One the supremal controllable sublanguage of has given language. In: SIAM J Control Optimization, Volume 25, n°3, page 637-659, 1987. [5] J.M. Roussel. Analyse de Grafcet par génération logique de l’automate équivalent. In: Thesis of doctorate of the higher teacher training school of Cachan, 1994. [6] KUMAR R., Supervisory Synthesis Techniques for Discrete Event Dynamical Systems, Thesis for Ph. D. Degree, Université du Texas, 1991. [7] A. Tajer, A. Philippot, F. Gellot F.,V. Carré- Ménétrier, Contribution à l’amélioration de la praticabilité des approches formelles de synthèse de commande , JDA’03, Valenciennes, 2003. [8] A. Philippot, A. Tajer, F. Gellot, V. Carré-Ménétrier. Synthèse de la commande spécifiée en Grafcet : application à un préhenseur pneumatique. MSR' 03, Metz, 2003. [9] S. Balemi, G.J. Hoffmann, P. Gyugyi, H. Wong-Toi, G.F. Franklin, Supervisory control of a rapid thermal multiprocessor, IEEE Transactions on Automatic Control, vol. 38, n°7, p. 1040-1059, 1993. [10] International Electrotechnical Commission, PLCs – Part 3 : programming languages. Publication 611131-3, 1993. [11] V. Chandra, R. Kumar. A Discrete Event Systems Modeling Formalism Based one event Occurrences Rules and Precedences. In: IEEE Transactions one Robotics and Automation, Volume 17, n°6, 2001.