UNIVERSITÉ D’ABOMEY-CALAVI
****
ÉCOLE POLYTECHNIQUE D’ABOMEY-CALAVI
*****
DÉPARTEMENT DE GÉNIE INFORMATIQUE ET TÉLÉCOMMUNICATIONS
Option : Réseaux Informatiques et Internet (RII)
MÉMOIRE DE FIN DE FORMATION
POUR L’OBTENTION DU
DIPLÔME D’INGÉNIEUR DE CONCEPTION Thème :
Editer et Projeter des Grafcets sur une Architecture Arduino
Réalisé par :
Narcisse Dimon ASSOGBA
Mémoire soutenu le1er Février 2018devant le jury composé de : Président : Dr. François-Xavier FIFATIN Enseignant à l’EPAC
Membres : Dr. Médésu SOGBOHOSSOU Enseignant à l’EPAC Dr. Emery ASSOGBA Enseignant à l’IFRI
Dr. Maurice COMLAN Enseignant à l’EPAC, Maître de mémoire
Année académique :2016 - 2017
10
èmePromotion
Dédicace
À
mes parentsFrançoise et Honoré
ASSOGBA
, mon frèreRoméo,mes sœursNadègeetDiane.J’ai le grand plaisir de vous dédier ce travail en témoignage d’affectation et de re- connaissance et je vous remercie pour votre encouragement, votre soutien, votre confiance et votre amour inconditionnel.
Narcisse Dimon ASSOGBA
Remerciements
En préambule de ce mémoire, je tiens à remercier le Seigneur tout puissant qui nous a accordé la santé, la force, et la persévérance nécessaires pour la réalisation de ce projet de fin d’études.
Je remercie aussi tous ceux qui de près ou de loin ont participé à la réalisation de ce travail. Je pense particulièrement :
— auPr. Mohamed SOUMANOU, Directeur de l’École Polytechnique d’Abomey Calavi (EPAC) et à son adjoint, lePr. Clément AHOUANNOU, ainsi qu’à tout le personnel administratif ;
— au Dr. Léopold DJOGBE, Chef du département Génie Informatique et Télécommunications (GIT) et à tous les enseignants dudit département ;
— auPr. David DELFIEU, enseignant-chercheur à École Polytechnique de l’Uni- versité de Nantes, pour avoir proposé ce sujet et accepté superviser le travail ;
— au Dr. Maurice COMLAN, notre maître de mémoire, pour avoir accepté encadrer ce travail ainsi que pour ses précieux apports, sa disponibilité et ses conseils judicieux ;
— àM. Victor OYETOLA, Chef Service Promotion des TICs du Rectorat de l’UAC et à ses collèguesCésaire YADOULETON,Isaak TOVIESSIetSolange ZANNOU de la division Réseaux et Systèmes, pour l’accueil exceptionnel qu’ils nous ont réservé dans leur service ;
— à toute ma famille, pour son soutien indéfectible ;
— à tous mes camarades de la 10ème promotion du Secteur Industriel de l’EPAC, pour tous les bons moments passés ensemble ;
— à mes amis qui ont, de quelque manière que ce soit contribué à la concrétisation de ce travail.
ii
Résumé
Le présent mémoire porte sur la conception et la réalisation d’un éditeur et simulateur de Grafcet, permettant à partir du Grafcet de générer un programme directement exécutable sur une carte Arduino. Ce travail se veut être une solution pour aider à la réalisation des travaux pratiques d’automatisme ; et plus globa- lement d’offrir un environnement de développement d’automates permettant, à partir du formalisme Grafcet, de réaliser des automates bas coûts à base de modules Arduino. Les cartes Arduino sont l’une des cartes à microcontrôleur les plus accessibles et faciles à utiliser. Aussi le Grafcet est un modèle bien connu et incontournable dans le monde des systèmes automatisés. Autant de raisons qui ont motivé le choix de ces technologies. Enfin, pour atteindre les objectifs fixés, nous sommes partis d’un éditeur libre de Grafcet JGrafchart, développé en Java et que nous avons adapté en lui ajoutant notamment le générateur de code pour Arduino.
Mots-clés : Grafcet, Arduino, automate programmable industriel (API), génération de code, éditeur/simulateur de Grafcet, automatisme.
Abstract
This thesis deals with the design and implementation of a Grafcet editor and simulator, allowing to generate a directly executable program on an Arduino board from a Grafcet. This work is intended to be a solution to help carrying out automation laboratory exercises ; and, more generally, to offer a programmable logic controller (PLC) development environment allowing to obtain low-cost PLCs based on Arduino modules, from the Grafcet formalism. Arduino boards are one of the most accessible and easy-to-use microcontroller boards and Grafcet is a well-known and essential model in the world of automated systems. All these reasons motivated the choice of these technologies. Finally, to achieve the set objectives, we started from a free Grafcet editor JGrafchart, developed in Java and that we adapted by including,among other things, the code generator for Arduino.
Keywords : Grafcet, Arduino, programmable logic controller (PLC), Grafcet editor/
simulator, process control.
iv
Sigles et abréviations
API Automate Programmable Industriel.
CEI Commission Electrotechnique Internationale.
CPU Central Processing Unit.
DPWS Device Profile for Web Service.
E/S Entrée et Sortie.
EDI Environnement de Développement Intégré.
FBD Function Block Diagram.
Grafcet GRAphe Fonctionnel de Commande Etape Transition.
IEC International Electrotechnical Commission.
IL Instruction List.
JVM Java Virtual Machine.
LD Ladder Diagram.
MLI Modulation par Largeur d’Impulsion.
MVC Modèle Vue Contrôleur.
PID Proportionnel, Intégral et Dérivé.
PLC Programmable Logic Controller.
POO Programmation Orientée Objet.
RdP Réseaux de Petri.
SED Systèmes à Evénements Discrets.
SFC Sequential Function Charts.
ST Structured Text.
TTL Transistor-Transistor Logic.
XML eXtensible Markup Language.
Liste des figures
1.1 Éléments de base d’un Grafcet . . . 6
1.2 Eléments de base d’un SFC [OMR15] . . . 7
1.3 AUTOMGEN en mode «Expert» . . . 9
1.4 Interface de Unity Pro XL . . . 10
1.5 Implémentation d’un exemple sur JGrafchart . . . 11
1.6 Automate programmable industriel . . . 12
1.7 Structure d’un API . . . 13
1.8 Schéma d’une carte Arduino. . . 15
2.1 Diagramme de la classe Action . . . 21
2.2 Diagramme des classes Thread et ThreadController . . . 21
2.3 Diagramme de la classe ActionThread . . . 22
2.4 Diagramme de la classe Step . . . 23
2.5 Diagramme de la classe Transition . . . 23
2.6 Diagramme de classe global . . . 24
3.1 Organisation des fichiers . . . 29
3.2 Ports d’entrée et de sortie d’une étape . . . 32
4.1 Interface principale de l’éditeur . . . 40
4.2 Fenêtre de connexion de la carte Arduino . . . 40
4.3 Fenêtre de gestion des variables du Grafcet . . . 41
4.4 Fenêtres d’édition des étapes et transitions . . . 41
4.5 Variables utilisées dans le Grafcet du cas d’application . . . 42
4.6 Grafcet du cas d’application . . . 43
4.7 Schémas du montage réalisé avec Fritzing . . . 44
1 Basic elements of a Grafcet . . . 73
2 Diagram of an Arduino card. . . 74
3 Editor main interface . . . 77
4 Grafcet of the application case . . . 79
5 Montage diagrams with Fritzing . . . 79
vi
Liste des tableaux
3.1 Spécifications techniques de la carte Arduino UNO . . . 37
4.1 Liste des composants . . . 43
Liste des codes
2.1 Algorithme d’interprétation utilisé . . . 203.1 Gestion de cohérence des éléments graphiques . . . 31
3.2 Commandes AVR pour la compilation . . . 33
3.3 Commande AVR pour l’empaquetage . . . 34
3.4 Commande AVR pour l’édition de liens . . . 34
3.5 Commande AVR pour charger le format du fichier binaire . . . 34
3.6 Commandes AVRDUDE pour charger le programme sur la carte . . . . 34
A.1 Code du Makefile . . . 51
B.1 Code XML du Grafcet du cas d’application . . . 54
C.1 Code Arduino généré pour le cas d’application . . . 60
1 Interpretation algorithm . . . 77
Table des matières
Dédicace i
Remerciements ii
Résumé iii
Abstract iv
Sigles et abréviations v
Liste des figures vi
Liste des tableaux vii
Liste des codes vii
Table des matières viii
Introduction Générale 1
1 Contexte et justification . . . 1
2 Problématique . . . 2
3 Objectifs . . . 2
4 Plan du document . . . 3
1 Synthèse Bibliographique 4 1.1 Grafcet et SFC . . . 5
1.1.1 Le Grafcet . . . 5
1.1.2 Le SFC . . . 6
1.1.3 Différences entre Grafcet et SFC . . . 7
1.2 Les éditeurs de Grafcet . . . 8
1.2.1 Exemples d’éditeurs de Grafcet . . . 8
1.3 L’Automate Programmable Industriel . . . 12
1.3.1 Architecture d’un API . . . 12
1.3.2 Programmation d’un API . . . 13
1.4 Les kits de la famille Arduino . . . 14
1.4.1 Principe de fonctionnement . . . 14
1.4.2 La programmation des composants . . . 14
viii
TABLE DES MATIÈRES
2 Conception du traducteur de Grafcet en code source pour Arduino 16
2.1 Choix de mise en œuvre . . . 17
2.1.1 Les éléments de Grafcet non implémentés . . . 17
2.2 Algorithmes d’Interprétation . . . 18
2.2.1 Interprétation du Grafcet . . . 18
2.2.2 Interprétation du SFC . . . 19
2.2.3 Algorithme d’interprétation utilisé . . . 19
2.3 Définition des classes . . . 20
2.3.1 La classeAction . . . 20
2.3.2 Les classesThreadetThreadController . . . 21
2.3.3 La classeActionThread . . . 22
2.3.4 La classeStep . . . 23
2.3.5 La classeTransition . . . 23
3 Implémentation de l’Éditeur 25 3.1 Cahier des charges de l’application . . . 26
3.1.1 La barre des menus . . . 26
3.1.2 La barre d’actions rapides . . . 27
3.1.3 Palette latérale . . . 28
3.1.4 La zone d’édition . . . 28
3.1.5 La zone d’affichage des erreurs et logs . . . 28
3.2 Présentation de l’éditeur . . . 28
3.2.1 Prise en main de JGrafchart . . . 28
3.2.2 Mise à jour des fonctionnalités . . . 29
3.2.3 Compilation du Grafcet . . . 31
3.2.4 Module de génération du code Arduino . . . 32
3.2.5 Exécution du code sur Arduino . . . 32
3.3 Environnement de développement et matériels utilisés . . . 35
3.3.1 Environnement logiciel pour la conception de l’éditeur . . . 35
3.3.2 Environnement pour l’exécution du Grafcet sur Arduino . . . . 36
4 Résultats, Analyses et Discussions 38 4.1 Résultats . . . 39
4.1.1 Bilan . . . 39
4.1.2 Interfaces de l’application . . . 39
4.2 Cas d’application : Système de détection d’incendie . . . 42
4.2.1 Grafcet du Système . . . 42
4.2.2 Schémas du montage . . . 43
4.3 Analyses et Discussions . . . 45
Conclusion Générale et Perspectives 46
Références bibliographiques 46
ANNEXES 51
A Makefile pour la compilation du code source Arduino et son transfert sur
une carte 51
TABLE DES MATIÈRES
B Fichier XML du Grafcet du cas d’application 54 C Code Arduino généré pour le cas d’application 60
English Version 71
Réalisé par Narcisse Dimon ASSOGBA x
I NTRODUCTION G ÉNÉRALE
1 Contexte et justification
La représentation graphique permet de décrire le fonctionnement séquentiel d’un système automatisé sans ambiguïté et d’une façon compréhensible par toutes les catégories de personnel. En effet, l’œil humain est capable de saisir, d’un regard, une évolution séquentielle représentée graphiquement [EMHL+06]. Parmi les méthodes possibles, on trouve l’organigramme, les machines à états, le Grafcet, les Réseaux de Petri (RdP).
Le modèle des réseaux de Petri a été créé en 1962 par Carl Adam Petri, pour modéliser les processus communicants. L’intérêt majeur des RdP, pour la modélisation des systèmes de contrôle, provient de ce qu’ils permettent de représenter de manière simple, claire et graphique les concepts de parallélisme, de synchronisation (rendez-vous, précédence...), de partage de ressources, de communication, de causalité [CG06]. En fonction de leurs caractéristiques, les RdP peuvent être simples, autonomes ou non, à prédicats, colorés, continus, synchronisés, temporisés, hybrides ....
Le Grafcet dérive des RdP ordinaires. Néanmoins, la sémantique des deux (2) modèles diffère [SV15]. Le Grafcet, normalisé en 1988, permet de décrire le comportement de la partie séquentielle du système de commande des procédés industriels [CEI02], grâce à un Automate Programmable Industriel (API), une machine électronique programmable destinée à piloter en ambiance industrielle et en temps réel des systèmes automatisés.
Le comportement d’un API peut également être obtenu avec un ordinateur ou une carte dotée d’un microcontrôleur comme les modules mbed1,*8 le Raspberry PI2, les LaunchPad3 ou encore les cartes Arduino4. Ces cartes sont beaucoup plus accessibles et présentent des performances acceptables pour des applications
1. https ://os.mbed.com/
2. https ://www.raspberrypi.org/
3. http ://www.ti.com/tools-software/launchpads/overview.html 4. https ://www.arduino.cc/
INTRODUCTION GÉNÉRALE
automatisées de moyenne taille. La carte Arduino UNO (carte d’entrée de gamme) offre par exemple un processeur de 20Mhz, 32Ko de mémoire vive et 14 Entrées et Sorties (E/S) [Ard17b].
Le challenge est d’aboutir à des équipements faciles à acquérir et de performances comparables à celles des API actuels et capables d’interpréter des formalismes standardisés de l’automatisme comme le Grafcet.
2 Problématique
Ce sujet relève des domaines de l’automatisme, de l’informatique industrielle et de la programmation (C, Java) ainsi que de quelques principes théoriques sur les Systèmes à Evénements Discrets (SED), qui contrairement aux systèmes de variable continue, sont des systèmes qui satisfont les deux propriétés : l’espace d’état est discret et la transition d’état est déclenchée par l’événement [CL06].
Le développement d’automates se fait principalement à partir de description en Grafcet, en langage Ladder, avec des logigramme ou en liste d’instructions. Mis à part leur coût, relativement élevé, les automates sont difficiles à acquérir. Cette situation constitue un frein à la réalisation des travaux dirigés d’automatisme industriel. Par contre, les cartes à microcontrôleur présentent un meilleur compromis entre prix, accessibilité et performances pour obtenir les mêmes résultats.
Les cartes de la famille Arduino figurent parmi les cartes à microcontrôleur les plus répandues, disposant d’une forte communauté d’internautes et d’une riche documentation. Parallèlement le formalisme Grafcet et son dérivé le SFC est une référence en matière de développement d’API, à côté du Ladder, qui n’a été introduit qu’avec la norme CEI-61131. Ces raisons justifient notre choix sur ces technologies.
3 Objectifs
Le principal objectif visé par ce travail est la conception et la réalisation d’un environnement de développement d’automates permettant à partir du formalisme Grafcet, de réaliser des automates à faibles coûts à base de modules Arduino.
Plus spécifiquement, il s’agira pour nous :
— de concevoir, à partir des éléments existants5, un logiciel plus global permettant d’implémenter un éditeur et simulateur de Grafcet ;
— d’intégrer à l’éditeur un générateur de code, qui produira à partir du Grafcet, un code source qui pourra être embarqué sur des cartes Arduino ;
— enfin, d’utiliser le logiciel développé pour mettre en œuvre une application de contrôle / commande sur un kit Arduino (montage électronique).
5. Nous partirons de l’éditeur libre JGrafchart
Réalisé par Narcisse Dimon ASSOGBA 2
INTRODUCTION GÉNÉRALE
4 Plan du document
Le présent mémoire fait le point des travaux et comprend trois (3) chapitres :
— le premier, permettra d’introduire quelques concepts autour desquels s’articu- lera le travail et de présenter des travaux qui se rapprochent de notre contexte ;
— dans le second chapitre nous présenterons le travail effectué, à commencer par les étapes de la conception de l’éditeur en passant par les algorithmes de compilation, d’interprétation et de traduction du Grafcet, pour finir par le matériel et technologies utilisés ;
— le troisième chapitre est consacré au cas d’application et à la discussion sur les résultats du travail.
Enfin, nous conclurons par un point des travaux et la proposition de perspectives.
C HAPITRE 1
S YNTHÈSE B IBLIOGRAPHIQUE
«Plusieurs modèles existent et chaque modèle possède ses caractéristiques propres. En conséquence, le choix du modèle dépendra du système conçu et des propriétés à analyser. »
Michel Diaz
4
Chapitre 1. Synthèse Bibliographique
1.1 Grafcet et SFC
1.1.1 Le Grafcet
Le GRAphe Fonctionnel de Commande Etape Transition (GRAFCET) est utile pour concevoir des graphes donnant une représentation graphique et synthétique du comportement des systèmes. Il est utilisé en industrie pour décrire le comportement séquentiel des procédés. Inspiré des RdP et normalisé par la Commission Electrotechnique Internationale (CEI) sous le standard CEI 60848, il obéit à des règles de syntaxe et de sémantique bien défini.
1.1.1.1 Éléments de base
Un Grafcet se compose de façon élémentaire d’un ensemble :
— d’étapes, qui décrivent un état du système. Une étape est soit active soit inactive. Une ou plusieurs actions lui sont associées, pour indiquer le comportement d’une variable de sortie ;
— de transitions, qui indiquent la possibilité d’évolution d’activités entre deux ou plusieurs étapes. Une expression booléenne, appelée réceptivité est associée à chaque transition ;
— de liaisons orientées, qui indiquent les sens d’évolution en reliant les étapes aux transitions et les transitions aux étapes.
La règle de syntaxe exige que l’alternance étape-transition ou transition-étape soit toujours respectée quelle que soit la séquence parcourue [CEI02]. La Figure 1.1 présente la présentation graphique des éléments de base d’un Grafcet et les possibilités d’agencement.
A ces éléments de base s’ajoutent des composants plus complexes comme les macro-étapes, les étapes encapsulantes, les éléments de parallélisme et de synchronisation (divergence/convergence).
1.1.1.2 Règles d’évolutions
La norme CEI-60848 définit cinq (5) règles d’évolutions. Ces règles décrivent le principe d’évolution séquentielle entre les situations (ensemble des étapes actives à un instant donné et formant l’état du système) du Grafcet.
1. Situation initiale : choisie par le concepteur, elle est décrite par l’ensemble des étapes actives à l’instant initial. Les étapes initiales sont activées inconditionnellement en début de cycle.
2. Franchissement d’une transition : une transition est dite validée lorsque toutes les étapes immédiatement précédentes reliées à cette transition sont actives. Le franchissement d’une transition se produit lorsque la transition est VALIDÉE, ET QUE la réceptivité associée à cette transition est VRAIE.
3. Évolution des étapes actives : le franchissement d’une transition entraîne simultanément l’activation de toutes les étapes immédiatement suivantes et la désactivation de toutes les étapes immédiatement précédentes.
Chapitre 1. Synthèse Bibliographique
FIGURE1.1 – Éléments de base d’un Grafcet [CEI02].
4. Évolutions simultanées : plusieurs transitions simultanément franchissables sont simultanément franchies.
5. Activation et désactivation simultanées d’une étape : si, au cours du fonctionnement, une étape active est simultanément activée et désactivée, alors elle reste active.
1.1.2 Le SFC
Le langage Sequential Function Chart (SFC), dérivé du Grafcet, est l’un des cinq (5) langages introduits par la norme CEI-61131-3. C’est un langage graphique beaucoup plus appliqué à la programmation des API.
1.1.2.1 Éléments de base
Tout comme en Grafcet, un procédé, en SFC, est représenté comme une suite connue d’étapes, reliées entre elles par des transitions. Une condition booléenne est attachée à chaque transition. Un ensemble d’actions est attaché à chaque étape. La Figure 1.2, présente la structure de base d’un programme SFC.
Réalisé par Narcisse Dimon ASSOGBA 6
Chapitre 1. Synthèse Bibliographique
FIGURE1.2 – Eléments de base d’un SFC [OMR15]
(a) Etape : elle représente un processus élémentaire au sein du processus global.
Lorsqu’une étape devient active, les blocs d’action affectés à cette étape sont exécutés. La première étape d’un programme est appelée "étape initiale".
(b) Bloc d’action : il contient les traitements (actions) pour une étape donnée.
(c) Action Qualifier (mot-clé) : il définit le moment de l’exécution et le comporte- ment de chaque action. La norme CEI-61131-3 en donne une liste exhaustive.
(d) Nom de l’action : il spécifie pour chaque action, le nom d’une variable (booléenne) ou d’une fonction exécutant les instructions liées à l’action.
(e) Transition : elle représente la condition qui transfère le statut actif de l’étape précédant la transition à l’étape suivant la transition.
1.1.3 Différences entre Grafcet et SFC
Se basant sur les normes CEI-60848 et CEI-61131-3, relatives respectivement au Grafcet et au SFC, un Grafcet est utilisé pour spécifier le comportement de la partie séquentielle des systèmes de commande (vue externe d’un système de contrôle/commande), alors qu’un SFC décrit la structure, ou une partie de la structure, du logiciel exécuté dans un automate programmable industriel réalisant ce comportement (vue interne du système de contrôle/commande) [Deg12].
Dans un Grafcet, chaque changement d’état d’une variable d’entrée provoque le franchissement des transitions qui mènent à une situation stable avant un autre changement d’état. Alors que dans un SFC, les évolutions sont régies par le cycle de lecture des entrées de l’automate exécutant le modèle. Par conséquent, un seul ensemble de transition simultanément franchissables peut être franchi à chaque cycle d’exécution [SV15]. La notion de situation stable n’a donc pas la même définition dans les deux langages.
Chapitre 1. Synthèse Bibliographique
En cas de sélection de séquence (divergence en OU), l’activation exclusive d’une séquence n’est pas garantie dans un Grafcet. Le concepteur doit s’assurer que les conditions des transitions sont mutuellement exclusives. Au contraire en SFC, toute sélection de séquence est exclusive. Il ne peut pas y avoir des transitions franchies simultanées dans une sélection de séquence ; pour ce faire, le concepteur peut définir des priorités entre les différentes séquences [PRF11].
1.2 Les éditeurs de Grafcet
Un éditeur de Grafcet est un logiciel qui permet de réaliser des Grafcet, il intègre le plus souvent un environnement de dessin permettant de réaliser le modèle graphique et utilisant la technologie du glisser-déposer ; un analyseur syntaxique pour assurer la cohérence des éléments tels que définis à la Section 1.1.1.1 ; et aussi un environnement pour la simulation / exécution du modèle qui se base sur les règles d’évolutions énumérées plus haut.
1.2.1 Exemples d’éditeurs de Grafcet
Il existe une panoplie d’éditeurs de Grafcet, les uns aussi performants et complexes que les autres. Nous avons dans le cadre de notre travail étudié les caractéristiques de trois (3) éditeurs.
AUTOMGEN8
Automgen est un atelier logiciel d’automatisme possédant de nombreuses fonctionnalités : programmation avec des langages d’automatisme normalisés, génération de code pour automates programmables et autres cibles, simulation, création d’IHM et de supervision sur Internet. Produit commercial de la société française indépendante IRAI, qui développe des logiciels pour automaticiens depuis 1988, AUTOMGEN fonctionne exclusivement sur l’environnement Windows et propose au lancement le choix d’un mode [IRA08]. Les modes « Débutants » permettent de commencer à utiliser AUTOMGEN dans une configuration « dépouillée » avec peu d’options dans les menus et des palettes simplifiées. Ce mode convient particulièrement aux personnes utilisant AUTOMGEN pour la première fois. Le mode expert, dont une capture de l’interface principale est présentée à la Figure 1.3, propose l’ensemble des fonctionnalités.
AUTOMGEN intègre un certain nombre de fonctionnalités dont entre autres :
— un environnement de développement entièrement paramétrable ;
— un simulateur de parties opératives 2D et 3D avec moteur physique TOKAMAK ou BULLET ;
— un simulateur électrique, pneumatique, hydraulique, électronique digitale (module AUTOMSIM) ;
— une compatibilité avec une large gamme d’API (SCHNEIDER, SIEMENS, GE- FANUC, KLOCKNER-MOELLER, ...) ;
— intégration des langages de la Norme CEI-1131 : Grafcet, Ladder, Blocs-fonctionnels, Littéral ST, Organigrammes, Logigrammes, GEMMA.
Réalisé par Narcisse Dimon ASSOGBA 8
Chapitre 1. Synthèse Bibliographique
FIGURE1.3 – Fenêtre principal d’AUTOMGEN en mode « Expert » [IRA08].
Unity Pro
Unity Pro est un logiciel commun de programmation, mise au point et exploitation des gammes d’automates Modicon M340, M580, Premium et Quantum (Figure 1.4). C’est un logiciel propriétaire, tout en un, développé par la société Schneider Electric [Sch17].
Le logiciel est disponible en cinq (5) variantes en fonction des fonctionnalités embarquées : "Unity Pro S", "Unity Pro M", "Unity Pro L", "Unity Pro XL" et "Unity Pro XLS". Mais de façon globale, il intègre les fonctionnalités suivantes :
— développement d’application sous Windows (XP-VISTA-7) ;
— disponible en 6 langues (Français, anglais, allemand, espagnol, italien et chinois) ;
— cinq (5) langages de programmation ;
— création de blocs fonctions utilisateur (DFB) ;
— diagnostic étendu de l’application ;
— création d’écrans d’exploitation ;
— création de structures de données ;
— conversion d’applications PL7/ Concept existantes ;
— test de l’application via un simulateur.
Chapitre 1. Synthèse Bibliographique
FIGURE1.4 – Interface de Unity Pro XL [JEI17].
JGrafchart
JGrafchart est une implémentation en Java de Grafchart, un langage de supervision, de contrôle de séquence et de traitement des procédures développée depuis 1991 au département d’Automatisme du Lund University en Suède. Le langage est basé sur le Grafcet/SFC, les RdP, les machines à états et la Programmation Orientée Objet (POO) [Lun17].
JGrafchart est un éditeur libre, multiplateformes et disposant des fonctionnalités suivantes :
— séquence étapes-transitions avec divergence en OU/ET ;
— espaces de travail structurés ;
— utilisation des procédures pour la réutilisation de code ;
— les Process Steps pour l’exécution asynchrone des procédures ;
— prise en compte des E/S physiques, par XML, ou via le réseau (DPWS6) ;
— interaction avec les éléments graphiques ;
— sauvegarde des fichiers sous le format XML.
La Figure 1.5 montre un exemple de Grafcet éditer sous JGrafchart.
6. Protocole utilisé pour l’envoi de messages sécurisés avec un Web service, très utilisé au niveau des équipements avec des ressources limitées.
Réalisé par Narcisse Dimon ASSOGBA 10
Chapitre 1. Synthèse Bibliographique
FIGURE1.5 – Implémentation d’un exemple sur JGrafchart [Lun17].
Chapitre 1. Synthèse Bibliographique
1.3 L’Automate Programmable Industriel
Un API est une forme particulière de contrôleur à microprocesseur qui utilise une mémoire programmable pour stocker les instructions et qui implémente différentes fonctions, qu’elles soient logiques, de séquencement, de temporisation, de comptage ou arithmétiques, pour commander les machines et les processus.
C’est un ordinateur simplifié, qui est relié physiquement par une interface d’entrée à des capteurs et par une interface de sortie à des actionneurs (Figure 1.6). Cet appareil de contrôle/commande largement répandu dans l’industrie, est apparu aux États-Unis vers 1969. Il est conçu pour être exploité par des ingénieurs, dont les connaissances en informatique et langages de programmation peuvent être limitées [BS15].
FIGURE1.6 – Automate programmable industriel [BM06].
1.3.1 Architecture d’un API
De manière générale, un API est structuré autour de plusieurs éléments de base que sont l’unité de traitement, la mémoire, l’unité d’alimentation, les interfaces d’entrées-sorties, l’interface de communication et le périphérique de programmation (Figure 1.7) :
L’unité d’entrées-sorties (E/S) d’un API apporte le circuit d’interface entre le système et le monde extérieur. Au travers de canaux d’entrées-sorties, elle permet d’établir des connexions avec des dispositifs d’entrée, comme des capteurs, et des dispositifs de sortie, comme des moteurs et des solénoïdes. C’est également par l’intermédiaire de cette unité que se fait la saisie des programmes depuis un terminal. Chaque point d’entrée-sortie dispose d’une adresse unique, que le CPU peut utiliser.
Réalisé par Narcisse Dimon ASSOGBA 12
Chapitre 1. Synthèse Bibliographique
FIGURE1.7 – Structure d’un API [BS15].
1.3.2 Programmation d’un API
La programmation des APIs s’effectue à l’aide de langages spécifiés qui appartiennent en général à trois grandes familles :
— langage machine : c’est un langage en binaire, interprété par le microprocesseur d’un ordinateur.
— Grafcet : il s’agit d’un langage graphique inspiré des réseaux de Petri, bien adapté aux systèmes à évolution séquentielle, présenté à la Section 1.1.1.
— Ladder: c’est une représentation graphique d’équations booléennes sous une forme analogue à celle des schémas électriques. Le Ladder est basé sur le principe d’une alimentation en tension représentée par deux traits verticaux (barres d’alimentation) reliés horizontalement par des échelons [BM06] qui contiennent :
• des contacts qui permettent de lire la valeur d’une variable booléenne ;
• des bobines qui permettent d’écrire la valeur d’une variable booléenne ;
• des blocs fonctionnels qui permettent de réaliser des opérations plus complexes que la lecture ou l’écriture de variables.
Les constructeurs des API proposent pour leurs programmations un ou plusieurs langages qui appartiennent aux familles décrites précédemment.
Cependant, bien que les langages d’une même famille se ressemblent, ils ne sont pas nécessairement compatibles, ce qui rend très délicat le transfert du programme de contrôle d’un API à un autre. La norme IEC 61131-3, résultant de la volonté des constructeurs et des utilisateurs de normaliser ces langages dans le but de faciliter la réutilisation logicielle, définit cinq (5) langages pour la programmation des APIs [IEC03] :
• le langage SFC (Sequential Function Chart) appartient à la famille des langages Grafcet. Les actions dans les étapes sont décrites avec les langages ST, IL, LD ou FBD ;
Chapitre 1. Synthèse Bibliographique
• le langage LD (Ladder Diagram) appartient à la famille des langages Ladder ;
• le langage ST (Structured Text) est un langage textuel de haut niveau (type Pascal) dédié à la description de procédures complexes, difficilement mo- délisables avec les langages graphiques. C’est le langage par défaut pour la programmation des actions et des réceptivités du langage SFC ;
• le langage IL (Instruction List) appartient à la famille des langages machine ;
• le langage FBD (Function Block Diagram) est un langage graphique qui permet de réaliser des équations complexes à partir de fonctions élémentaires représentées par des blocs fonctionnels. Les variables d’entrées et de sorties sont connectées aux blocs par des arcs de liaison.
Une sortie d’un bloc peut être connectée sur une entrée d’un autre bloc.
1.4 Les kits de la famille Arduino
Arduino, est un nom générique de marque de la société italienne Smart Projects, donné à un ensemble de cartes électroniques. Les schémas de ces cartes sont publiés en licence libre. Vingt-quatre (24) versions des cartes de type Arduino ont été produites et vendues dans le commerce jusqu’en 2017 (Uno, Méga, Nano, Léonardo, Due ...) [Ard17a].
Un module Arduino est généralement construit autour d’un microcontrôleur Atmel AVR (ATmega328, ATmega32u4 ou ATmega2560 pour les versions récentes, ATmega168, ATmega1280 ou ATmega8 pour les plus anciennes), et de composants complémentaires qui facilitent la programmation et l’interfaçage avec d’autres circuits. Chaque module possède au moins un régulateur linéaire 5 V, un oscillateur à quartz 16 MHz (ou un résonateur céramique dans certains modèles) et utilise la plupart des entrées/sorties du microcontrôleur pour l’interfaçage avec les autres circuits.
1.4.1 Principe de fonctionnement
Les différentes versions des cartes Arduino fonctionnent sous le même principe général. La Figure 1.8 présente les principaux éléments qui composent une carte Arduino UNO.
Le microcontrôleur est préprogrammé avec un bootloader de façon à ce qu’un programmateur dédié ne soit pas nécessaire. Les modules sont programmés avec une connexion série TTL, mais les connexions permettant cette programmation diffèrent selon les modèles.
1.4.2 La programmation des composants
Le logiciel de programmation des modules Arduino est une application Java, libre ; multiplateforme et du même nom que les cartes, servant d’éditeur de code et de compilateur, et qui peut transférer le firmware et le programme au travers de la
Réalisé par Narcisse Dimon ASSOGBA 14
Chapitre 1. Synthèse Bibliographique
FIGURE1.8 – Schéma d’une carte Arduino [Mai17].
liaison série (RS-232, Bluetooth ou USB selon le module). Le langage de programmation utilisé est le C++, compilé avec avr-g++.
Il est également possible de se passer de l’interface Arduino, et de compiler puis de téléverser les programmes via l’interface en ligne de commande, en utilisant respectivement AVR-GCC pour la compilation et le programmateur AVRDUDE pour charger le programme sur la carte. Nous revenons sur ce mécanisme à la Section 3.2.5 du document.
C HAPITRE 2
C ONCEPTION DU TRADUCTEUR DE G RAFCET EN
CODE SOURCE POUR A RDUINO
« Le fossé séparant théorie et pratique est moins large en théorie qu’il ne l’est en pratique.»
Auteur Inconnu
16
Chapitre 2. Conception du traducteur de Grafcet en code source pour Arduino
2.1 Choix de mise en œuvre
Notre conception de l’éditeur de Grafcet se base sur les spécifications :
— du Grafcet pour l’aspect syntaxique (représentation graphique des éléments) et les règles d’évolutions ;
— et du SFC pour la définition des actions et leurs interprétations.
En effet, Le Grafcet est un langage de spécification et se caractérise principalement par ses éléments graphiques. Il offre une représentation synthétique du comportement reposant sur une description indirecte de la situation du système. La représentation distingue :
— la structure, qui permet de décrire les évolutions possibles entre les situations,
— et l’ interprétation, qui fait la relation entre les variables d’entrée, la structure, et les variables de sortie.
La norme propose une démarche d’interprétation, mais pas une méthode d’implémentation logicielle.
Le SFC dérivée du Grafcet, est un langage d’implémentation. Elle définit une méthode d’implémentation des principaux éléments du Grafcet (étape, transition, action). Nous nous intéressons, pour la conception, à définition des actions, qui remplaceront dans notre cas les actions Grafcet.
L’action indique le comportement d’une variable de sortie, il constitue avec la réceptivité les éléments d’interprétation d’un Grafcet.
L’implémentation logicielle d’une réceptivité est aisée car elle consiste généralement à l’évaluation d’une expression booléenne. Par contre, l’implémentation d’une action est plus délicate et nécessite une méthodologie très explicite, raison pour laquelle nous avons opté pour les actions SFC, qui sont très clairement définies.
Aussi, lors d’une sélection de séquence, c’est la logique du Grafcet qui est appliquée. Le concepteur devra s’assurer de l’exclusion mutuelle au niveau des conditions de transition.
2.1.1 Les éléments de Grafcet non implémentés
Pour cette première version, certaines fonctionnalités des Grafcets n’ont pas été prises en compte. Il s’agit :
— du grafcet partiel : il résulte d’une partition, selon des critères méthodologiques, du grafcet global d’un système. Un grafcet partiel est constitué d’un ou plusieurs grafcets simples ;
— du forçage de situation d’un grafcet partiel : c’est un moyen de structuration qui utilise les ordres de forçage, permettant d’imposer une situation spécifique à un grafcet partiel donné, à partir de la situation d’un autre grafcet partiel ;
— de l’encapsulation : utiliser pour structurer de manière hiérarchique un grafcet.
Aussi au niveau des actions (définition de la norme CEI-61131-3), voici la liste des
"actions qualifiers" qui ont été implémentés :
— N : action non mémorisée ;
Chapitre 2. Conception du traducteur de Grafcet en code source pour Arduino
— S : action mémorisée ;
— R : réinitialisation d’une action mémorisée ;
— D : action retardée ;
— L : action limitée dans le temps ;
— DS : action retardée et mémorisée.
2.2 Algorithmes d’Interprétation
2.2.1 Interprétation du Grafcet
Le comportement d’un Grafcet est décrit par cinq règles d’évolutions (Section 1.1.1.2). L’implémentation de ces règles est possible via un algorithme d’interprétation. Nous présentons ici l’Algorithme 2.1 proposé dans [DA92].
ALGORITHME2.1- Interprétation du Grafcet [DA92]
Pas 1. Initialisation : activation des étapes initiales et exécution des actions impulsionnelles qui y sont associées. Aller aupas 5.
Pas 2. Quand un nouvel événement externe se produit, déterminer l’ensembleT1des transitions franchissables sur occurrence de cet événement. SiT1n’est pas vide, aller aupas 3. Sinon, modifier éventuellement l’état des actions conditionnelles associées aux étapes actives. Attendre un nouvel événement externe aupas 2.
Pas 3. Franchir toutes les transitions franchissables. Si la situation est inchangée après ce franchissement simultané, aller aupas 6.
Pas 4. Exécuter toutes les actions impulsionnelles associées aux étapes devenues ac- tives aupas 3.
Pas 5. Déterminer l’ensemble T2 des transitions franchissables sur occurrence de l’événemente(toujours occurrent). SiT2n’est pas vide aller aupas 3.
Pas 6. Une situation stable est atteinte.
Pas 6.1. Déterminer l’ensemble A0 des actions à niveau qui doivent être désactivées (actions associées aux étapes qui étaient actives au pas 2 et qui sont inactives maintenant, et actions conditionnelles associées aux étapes restées actives pour lesquelles les conditions ne sont plus vérifiées).
Pas 6.2. Déterminer l’ensemble A1 des actions à niveau qui doivent être activées (actions associées aux étapes qui étaient inactives au pas 2 et qui sont actives maintenant éventuellement sous réserve de conditions, et actions conditionnelles associées aux étapes restées actives pour lesquelles les conditions sont vérifiées alors qu’elles ne l’étaient pas aupas 2).
Pas 6.3. Mettre à0toutes les actions qui appartiennent àA0et qui n’appartiennent pas àA1. Mettre à1toutes les actions qui appartiennent àA1.
Aller aupas 2.
Réalisé par Narcisse Dimon ASSOGBA 18
Chapitre 2. Conception du traducteur de Grafcet en code source pour Arduino
Analyses :
L’algorithme permet d’obtenir les deux modes d’évolution du grafcet (évolution fugace et non fugace) [CEI02] :
— une évolution fugace, correspondant à la bouclepas 5→pas 3→pas 4→pas 5, tant que la liste des transitions franchissables est non vide ;
— et dans le cas contraire une évolution non fugace, correspondant plutôt à la séquence pas 5 → pas 6 → pas 2, qui indique le passage par une situation stable.
Une action mémorisée est exécutée même si la situation n’est pas stable. Une action continue n’est pas modifiée entre deux situations stables [Deg12].
2.2.2 Interprétation du SFC
L’Algorithme 2.2 présente une démarche d’interprétation du SFC proposé dans [PV08].
ALGORITHME2.2- Interprétation du SFC [PV08]
Pas 1. Déterminer l’ensemble des étapes actives.
Pas 2. Évaluer toutes les transitions associées aux étapes actives.
Pas 3. Exécuter les actions avec le mot-clé P0 (impulsion sur front descendant) en dernier.
Pas 4. Exécuter les actions actives.
Pas 5. Franchir toutes les transitions franchissables : déactiver les étapes qui les pré- cèdent et activer les étapes suivant les transitions franchises.
Pas 6. Mise à jour du statut des actions.
Pas 7. Aller aupas 1.
Analyses :
L’Algorithme 2.2 suit un modèle d’évolution à passage différé7 [PV08]. Dans ce modèle, seules les actions directement rattachées aux étapes actives sont évaluées.
Ensuite, celles qui sont franchissables seront franchises les unes après les autres.
L’algorithme suit aussi une évolution cyclique sans recherche de situation stable. Au cours de chaque cycle, une scrutation est faite pour obtenir les changements d’état des variables d’entrée.
2.2.3 Algorithme d’interprétation utilisé
De l’Algorithme 2.1, nous avons conservé le principe d’initialisation et de sondage des transitions franchissables. Par contre, nous avons opté pour une évolution sans recherche de situation stable telle que proposée dans l’Algorithme 2.2.
7. En anglais : deferred transit evolution model (DTEVM)
Chapitre 2. Conception du traducteur de Grafcet en code source pour Arduino
Ainsi, nous ne distinguons plus les actions conditionnelles ou impulsionnelles (le mot-clé permettra de distinguer sa nature lors de l’exécution).
Le Pseudo-code 2.1, présente l’algorithme d’interprétation proposé.
CODE2.1 – Algorithme d’interprétation utilisé
1 Définir la liste des étapes ; /* Chaque étape comportant la liste de ses actions */
2 Définir la liste des transitions ; /* Chaque transition comportant sa condition de transition, la liste de ses étapes précédentes et la liste de ses étapes suivantes */
3 Créer une liste vide des transitions franchissables ; 4 Activer les étapes initiales ;
5 Exécuter les actions qui y sont associées ; 6
7 TantQue (Vrai) Faire
8 Vider la liste des transitions franchissables ; 9 Pour chaque transition Faire
10 Si transition validée ET conditions de transition satisfaite Alors 11 Ajouter la transition à la liste des transitions franchissables ; 12 FinSi
13 FinPour
14 Si la liste des transitions franchissables est non vide Alors
15 Pour chaque transition franchissable Faire /* En théorie simultané */
16 Franchir la transition ;
17 Déactiver les étapes précédentes à la transition ; 18 Activer les étapes suivantes à la transition ;
19 Exécuter les actions associées aux étapes activées ; 20 FinPour
21 FinTantQue
2.3 Définition des classes
Pour la mise en œuvre du Pseudo-code 2.1 (traduction en langage C++ pour Arduino), nous avons créé et utilisé des modèles d’objet, qui sont décrits dans cette section.
2.3.1 La classeAction
Un objetactionpermet de représenter une action associée à une étape et possède les attributs :
— qualifier (mot-clé associé à l’action et permettant de définir son comportement : mémorisé ou non, impulsionnel, avec retard ou limite de temps [IEC03]) ;
— time, le temps en second, de retard ou limite si il y a lieu ;
— variable, l’adresse de la variable booléenne (variable standard 3.2.2) dont l’ac- tion modifie l’état si tel est le cas ;
Réalisé par Narcisse Dimon ASSOGBA 20
Chapitre 2. Conception du traducteur de Grafcet en code source pour Arduino
FIGURE2.1 – Diagramme de la classe Action
— etthread, objet de la classeActionThreadreprésentant l’adresse du thread de- vant exécuter la suite d’instructions dans le cas d’une fonction bloc.
La classe possède deux (2) constructeurs qui dépendent de la nature de l’action (action formée d’une variable standard ou d’une fonction bloc). Les méthodes execute() et deactivate() permettent respectivement d’exécuter les instructions de l’action dès que celle-ci est activée et d’arrêter son exécution aussitôt que les conditions d’arrêt sont respectées.
2.3.2 Les classesThreadetThreadController
Ces deux (2) classes sont issues de la librairie ArduinoTread (présentée à la Section 3.3.2) et permettent d’implémenter le multi-taches (thread) sous Arduino.
FIGURE2.2 – Diagramme des classes Thread et ThreadController
Thread est la classe de base, qui contient les méthodes pour définir et exécuter lescallbacks, vérifier si le thread doit être exécuté, et créer également unThreadID unique à l’instanciation de la classe. La classe possède les attributs :
— interval: intervalle de temps voulu entre deux exécutions en millisecondes ;
— last_run: l’heure en milliseconde (timestamp) de la dernière exécution ;
— _cached_next_run: l’heure calculée de la prochaine exécution (timestamp) ;
— enabled: definit si le thread est activé ou non ;
— ThreadID: le numéro d’identification du thread ;
— ThreadName: le nom du thread, utilisé pour le débogage.
Et les méthodes suivantes :
Chapitre 2. Conception du traducteur de Grafcet en code source pour Arduino
— setInterval(): qui permet de définit l’intervalle de temps voulu entre deux exé- cutions ;
— shouldRun(): détermine si le thread peut être exécuté à nouveau ;
— onRun(): permet de définir la fonction (callbacks) qui sera appelée si le thread est exécuté ;
— run(): lance l’exécution du thread.
La classe dispose également d’un constructeur permetant d’instancier un nouveau thread, avec le nom ducallbackque devra exécuter le thread et l’intervalle de temps voulu entre deux exécutions.
La classe ThreadController, qui hérite deThread, peut contenir plusieurs autres threads et permet d’ordonnancer leur exécution. Elle possède un nouvel attribut threads, qui est un tableau de Thread; redéfinie la méthode run() de la classe Threadet ajoute les nouvelles méthodes :
— add(): pour ajouter unThread à la liste ;
— remove(): pour retirer unThreadde la liste ;
— clear(): retire tous lesThread
— get(): pour obtenir unThreadde la liste, connaissant son indice.
2.3.3 La classeActionThread
FIGURE2.3 – Diagramme de la classe ActionThread
La classeActionThreadest utilisée pour définir un thread représentant une action dans le cas des fonctions blocs (Section 3.2.2). Elle hérite de la classeThreadet ajoute les nouveaux attributs :
— thread_delay : le temps (en millisecondes) après lequel le thread devra être exécuté, si il s’agit d’une action retardée ;
— thread_limit : la limite de temps après laquelle le thread ne pourra plus être exécuté, si l’action possède un limite de temps ;
— depart_time: référence à l’heure (timestamp) à laquelle le thread a été lancé ;
— once: définit si il s’agit une action périodique ou non.
En plus des ces nouveaux attributs, le constructeur de la classe a été redéfini de façon à ne prendre que le numéro d’identification du thread, qui correspond au numéro d’ordre de l’action associée ; la méthode shouldRun() a été redéfinie pour prendre en compte les contraintes de délais liées aux actions. Et une nouvelle méthode init() permettant d’initialiser les nouveaux paramètres de temps a été ajoutée.
Réalisé par Narcisse Dimon ASSOGBA 22
Chapitre 2. Conception du traducteur de Grafcet en code source pour Arduino
2.3.4 La classeStep
Un objet de la classeStepest la représentation en mémoire d’une étape du Graf- cet. Il possède les attributs :
— id, qui est un identifiant unique associé à l’étape ;
— name, le nom donné à l’étape dans le Grafcet, cela est utile pour les opérations de débogage ;
— state, qui donne l’état de l’étape (active ou non)
— et enfin un tableauactions, contenant les références des actions liées à l’étape et dont le nombre est sauvegardé dans l’attributN_ACTION.
FIGURE2.4 – Diagramme de la classe Step
Le constructeur de la classe permet de créer un nouvel objet step, avec son identifiant, son nom et le nombre d’actions qui lui sont associées. Les méthodes activate() et deactivate() permettent d’activer ou de désactiver l’étape puis d’enclencher les opérations qui sont liées à chaque état.
2.3.5 La classeTransition
FIGURE2.5 – Diagramme de la classe Transition
La classeTransitionquant à elle représente une transition. Elle possède unidet deux tableaux succeedingSteps et preceedingSteps, qui stockent respectivement la liste des identifiants des étapes précédentes et suivantes à la transition. Le nombre des éléments de chaque liste est respectivement enregistré dans les attributs N_SSTEPetN_PSTEP.
Chapitre 2. Conception du traducteur de Grafcet en code source pour Arduino
A la construction d’un objet transition, son identifiant, le nombre d’étapes précédentes et suivantes sont fournis. La méthode isValidate(), vérifie si la transition est validée c’est-à-dire que toutes les étapes qui lui sont immédiatement antérieures sont actives. La méthodeevaluate()par contre vérifie si la condition de transition est vraie ou pas. En fin la méthodefire(), franchit la transition si les deux précédentes renvoient des résultats positifs, ce qui entraîne la désactivation des étapes immédiatement antérieures à la transition et l’activation de celles immédiatement postérieures à la transition.
La Figure 2.6 montre le diagramme de classe présentant les relations entres les classes définies.
FIGURE2.6 – Diagramme de classe global
La définition de ces classes, combinée à l’utilisation de certaines bibliothèques crées pour Arduino (listées à la Section 3.3.2) nous a facilité la traduction du Pseudo- code 2.1 en langage C++ (Section 3.2.4).
Réalisé par Narcisse Dimon ASSOGBA 24
C HAPITRE 3
I MPLÉMENTATION DE L ’É DITEUR
« Il y existe deux manières de concevoir un logiciel. La première, c’est de le faire si simple qu’il est évident qu’il ne présente aucun problème. La seconde, c’est de le faire si compliqué qu’il ne présente aucun problème évident. »
Tony Hoare
Chapitre 3. Implémentation de l’Éditeur
3.1 Cahier des charges de l’application
Dans cette section, nous proposons une description des interfaces de l’application. Nous nous sommes inspirés pour cette proposition, de l’interface de Jgrafchart, de Automgen 8 et de Unity Pro XL.
L’interface principale sera composée des éléments suivants :
— une barre des menus ;
— une barre d’actions rapides, en dessous de la barre des menus ;
— une palette latérale pour les composants du Grafcet ;
— une zone d’édition ;
— puis une zone pour l’affichage des erreurs et des logs.
3.1.1 La barre des menus
Elle sera composée de six (6) menus définis comme suit :
Le menu “Fichier” Il permet, via ses sous-menus :
— de créer un nouveau document (Ctrl+N) ;
— d’ouvrir un fichier existant (Ctrl+O) ;
— d’enregistrer le document en cours (Ctrl+S) ;
— d’enregistrer sous un autre nom le document en cours ;
— d’imprimer le document en cours (Ctrl+P) ;
— de voir les cinq (5) derniers documents édités ;
— enfin de quitter l’application (Alt+F4).
Le menu “Edition” Il gère l’interaction avec le document en cours d’édition. Il se compose des sous-menus suivants :
— Annuler (Ctrl+Z), pour annuler la dernière action ;
— Rétablir (Ctrl+Y), pour rétablir la dernière action annulée ;
— Copier (Ctrl+C), pour copier l’élément ou la zone du graphe sélectionné ;
— Couper (Ctrl+X) ;
— Coller (Ctrl+V) ;
— Sélectionner tout (Ctrl+A) ;
— Assistant, ouvre une nouvelle fenêtre qui permet de générer facilement un Grafcet en précisant le nombre d’étapes et si par exemple le graphe doit être en ligne ou comporter une divergence ;
— Préférences, pour définir des comportements par défaut de l’éditeur et d’autres paramètres. Ce sous-menu ouvrira une nouvelle fenêtre.
Réalisé par Narcisse Dimon ASSOGBA 26
Chapitre 3. Implémentation de l’Éditeur
Le menu “Affichage” On peut y retrouver les sous-menus suivants :
— Zoom + (Ctrl++), pour faire un zoom sur le document en cours d’édition ;
— Zoom - (Ctrl+-), pour diminuer le zoom ;
— Zoom adj., adapte le zoom de façon à ce que tous les éléments sur la feuille soient visibles ;
— Afficher grille (à cocher), pour afficher ou non une grille dans le document ;
— Afficher palette (à cocher), pour afficher ou non la palette des composants ;
— Afficher logs (à cocher), pour afficher ou non la zone d’affichage des erreurs.
Le menu “Exécution” Il gère la compilation, l’exécution et le débogage, les sous-menus présents sont :
— Compiler : enregistre, vérifie les erreurs et compile le document en cours d’édition ;
— Exécuter : lance l’exécution/simulation avec la dernière version compilée, per- met de voir l’évolution sur le Grafcet ;
— Arrêter : arrête l’exécution/simulation ;
— Pas à pas : pause/continuer.
Le menu “Automate” Ce menu contient les actions qui ont directement rapport à l’automate. On retrouve les sous-menus :
— Mode standard : permet de mettre l’éditeur dans un mode où le projet peut être projeté sur un automate (Arduino) ;
— Mode simulation : permet d’entrer en mode simulation ;
— Connexion/Déconnexion : permet en mode standard de connecter l’automate, une nouvelle fenêtre s’ouvrira pour les configurations nécessaires ;
— Variable : ouvre une nouvelle fenêtre pour l’édition des variables.
Le menu “Aide” Ce menu propose de l’aide et facilite la prise en main, avec les sous- menus :
— Aide : qui ouvre le glossaire d’aide ;
— A propos : qui donne des informations sur le logiciel, sa version, ....
3.1.2 La barre d’actions rapides
Elle regroupe juste au-dessous des menus une série d’actions les plus importantes lors de l’édition. On y trouvera les actions :
Chapitre 3. Implémentation de l’Éditeur
Nouveau du menu fichier, Exécuter,
Ouvrir, Arrêter,
Enregistrer, Pas à pas, pause/continuer, Copier du menu édition, Mode standard/simulation, Couper, Connexion/Déconnexion,
Coller, Zoom +,
Annuler, Zoom –,
Rétablir, Zoom adj.,
Compiler, Aide.
3.1.3 Palette latérale
Située à gauche de l’interface principale, elle offre les composants de Grafcet (étape, transition, divergences, commentaires . . . ) qui peuvent être sélectionnés et déposés dans la zone d’édition.
3.1.4 La zone d’édition
C’est dans cette zone que le Grafcet est dessiné. Elle reçoit les éléments disponibles dans la palette latérale.
A ce niveau, un double clic sur un composant ouvre une nouvelle fenêtre qui permet d’éditer les propriétés du composant. Un clic droit par contre ouvre un menu contextuel contenant entre autres les actions copier, couper, coller, supprimer, propriétés et d’autres actions qui dépendront du type de composant.
Si le clic droit se fait dans une zone ne comportant aucun élément, alors on obtient des actions permettant d’ajouter rapidement certains éléments de la palette (étape, transition, commentaire . . . ) et d’autres actions comme coller, assistant, variables, préférences.
3.1.5 La zone d’affichage des erreurs et logs
Cette zone complètement en bas de l’interface principale, permettra d’afficher les erreurs et messages résultants de l’exécution d’une action. Elle servira de première base pour le débogage et permettra à l’utilisateur d’avoir un retour des actions qu’il effectue.
3.2 Présentation de l’éditeur
3.2.1 Prise en main de JGrafchart
Pour atteindre notre objectif, nous sommes partis du logiciel JGrafchart, présenté à la Section 1.2.1. JGrafchart est une application développée en Java avec la bibliothèque Swing8, ce qui lui permet de pouvoir être déployé sur tous les systèmes d’exploitation ; une caractéristique qui était décisive lors de notre choix.
8. Bibliothèque graphique offrant un ensemble de composants "légers" qui présente pratiquement le même rendu sur toutes les platesformes. https ://docs.oracle.com/javase/8/docs/api/javax/swing/package-summary.html
Réalisé par Narcisse Dimon ASSOGBA 28
Chapitre 3. Implémentation de l’Éditeur
Après quelques semaines d’analyses des fichiers sources, nous avons compris que l’application a été développée en adoptant une architecture orientée événements et en suivant le paradigme de programmation Modèle Vue Contrôleur (MVC). Chaque interface (graphique) possède une liste prédéfinie d’événements (clique sur bouton, appui sur une touche du clavier), auxquels sont rattachés des actions à exécuter. Ainsi avant l’exécution d’une action, le contrôleur vérifie si toutes les conditions sont remplies. Par exemple on ne pourra pas avoir accès à l’éditeur de variables si un document n’est pas ouvert.
FIGURE3.1 – Organisation des fichiers
Il est aussi à noter que les fichiers sources sont classés dans des packages de façon thématique comme l’illustre la Figure 3.1. Cette organisation permet de se retrouver facilement et de maintenir l’application.
3.2.2 Mise à jour des fonctionnalités
Pour adapter l’application à nos besoins, nous avons dû apporter quelques modifications en désactivant certaines fonctionnalités pour l’alléger et puis en développant de nouvelles conformément au cahier des charges.
Ainsi :
— le menu "Misc." (Autres) a été désactivé. Ce menu gérait l’interconnexion de l’application à un réseau d’ordinateurs via un serveur sur lequel les fichiers sont partagés en utilisant le protocole DPWS.
— le module de contrôle par PID (Proportionnel, Intégral et Dérivé), une méthode de régulation souvent employée pour les asservissements [RDC10], a été désactivé. Ce module ne rentrait pas dans le cadre de notre travail.
Chapitre 3. Implémentation de l’Éditeur
— la palette latérale a été allégée, en retirant les composants liés aux modules désactivés.
— le menu "Automate", qui gère les interactions avec l’automate (carte Arduino) connecté a été créé. Via ce menu, il est possible :
• d’éditer les variables du Grafcet ;
• de définir le type de carte et le port COM sur lequel il est connecté ;
• d’exporter le code source pour Arduino généré à partir du Grafcet ;
• de téléverser directement le code sur une carte pré-configurée.
— le module de gestion des variables a également été recréé, pour faciliter la prise en main de l’application aux professionnelles, familiers avec les environnements comme Unity Pro ou PL7. A partir du nouveau module, il est possible de créer et de gérer trois (3) types de variables :
• les variables standards, ce sont les variables bâties autour des types primitifs (ENTIER, REEL, STRING, BOOLEEN . . . ). Ils ont un nom formé en suivant la norme du langage C ; un type issu de la liste exhaustive des types primitifs ; une valeur, faisant office de valeur initiale ; ils peuvent aussi être associées à une E/S via le champ «Adresse». Enfin le concepteur peut décider d’associer un commentaire à la variable. Dans un contexte de programmation, ces variables seront considérées comme des variables globales, accessibles depuis toutes les méthodes du programme.
• les fonctions blocs, disponibles uniquement au niveau des actions, elles permettent de définir des actions complexes nécessitant une suite d’instructions. Ces instructions peuvent être écrites en Instructions List, en Structured Text ou en langage C (seul le langage C sera implémenté pour cette première version). Les fonctions blocs ont aussi un nom formé sur les mêmes principes que les noms des variables standards.
• les sessions de transition, utilisées pour définir la condition de franchissement d’une transition, elles représentent une expression dont la valeur peut être évaluée à VRAI ou FAUX en fonction des règles d’évaluation du langage utilisé.
— des modifications ont aussi été apportées à la zone d’édition, notamment au niveau du menu d’édition des étapes et des transitions, de façon à ce que :
• une ou plusieurs actions puissent être associées à une étape, comme spécifier dans la norme CEI 61131-3 sur langages de programmation des API, et à chaque action est affectée un mot-clé (qualifier) qui définit le comportement de l’action lorsque l’étape est active. La norme CEI 61131-3 donne aussi la liste exhaustive de ces mots-clés.
Une action en soi, est formée par une variable du type booléen (ce qui inclut les E/S digitales) dont la valeur est mise à 0 ou 1 en fonction du mot-clé qui lui est affectée, ou d’une fonction bloc spécifiant une liste d’instructions complexes.
Dans notre implémentation de l’éditeur, les actions d’une étape sont défi- nies suivant ces règles.
Réalisé par Narcisse Dimon ASSOGBA 30
