CONCEPTION DES APPLICATIONS DE CONTROLE-COMMANDE POUR LA PLATE-FORME MBED VIA UNE MODELISATION GRAFCET

(1)

*******

ÉCOLE POLYTECHNIQUE D’ABOMEY-CALAVI

*******

DÉPARTEMENT DE GÉNIE INFORMATIQUE ET TÉLÉCOMMUNICATION

*******

OPTION : RÉSEAUX DE TÉLÉCOMMUNICATION

*******

Mémoire de fin de formation pour l’obtention du Diplôme d’Ingénieur de Conception en Génie Informatique et

Télécommunication

Présenté par Clément Abiodoun HOUNKPEVI

Mémoire soutenu à l’EPAC, Le 1^er Février 2018, devant le Jury composé de :

Président : Dr François-Xavier FIFATIN Membres : 1. Dr Maurice COMLAN

2. Mr Emery ASSOGBA

3. Dr Médésu SOGBOHOSSOU, Maitre de mémoire

Année universitaire 2016-2017 10^ème promotion

Thème : CONCEPTION DES APPLICATIONS DE CONTROLE-COMMANDE POUR LA PLATE-FORME

MBED VIA UNE MODELISATION GRAFCET

(2)

II Rédigé par : HOUNKPEVI Abiodoun Clément

Dédicaces

À Dieu le miséricordieux,

À mes parents,

À tous ceux qui m’aiment,

À tous ceux que j’aime.

(3)

III Rédigé par : HOUNKPEVI Abiodoun Clément

Remerciements

Je ne saurais présenter ce mémoire sans remercier l’ensemble des personnes qui ont permis l’aboutissement de ces travaux.

Je remercie le Directeur de l’EPAC, Prof. Mohamed M. SOUMANOU et le Directeur Adjoint de l’EPAC, Dr. Clément AHOUANNOU.

Je remercie chaleureusement le professeur David DELFIEU et Dr.

Médésu SOGBOHOSSOU, pour m’avoir encadré, beaucoup conseillé et aidé et pour avoir œuvré pour la réussite de ce travail. Je leur exprime toute ma gratitude.

À tous les professeurs du département de Génie Informatique et Télécommunication de l’EPAC à qui nous devons notre formation en particulier le Professeur Marc K. ASSOGBA, Directeur du Laboratoire d’Electrotechnique de Télécommunication et d’Informatique Appliquée (LETIA) de l’EPAC, pour m’avoir accepté dans leur laboratoire afin que je puisse y faire mes stages académiques sans oublier Messieurs Léopold DJOGBE, Michel DOSSOU, Basile DEGBO, Marc K. ASSOGBA, Théophile HOUNGAN, Léonard MONTEIRO, Fréjus SANYA, Patrick SOTINDJO et Tahirou DJARA.

Je ne saurais terminer ces remerciements sans penser aux membres de ma famille. À chaque fois que j’ai pu les retrouver, cela m’a procuré des instants de repos salutaires. Merci pour leur soutien moral et leur accompagnement pendant toutes ces années d’études, en particulier à ceux qui m'ont donné un goût certain pour les études et m'ont permis d'arriver jusque-là. Merci pour ce devoir accompli.

(4)

IV Rédigé par : HOUNKPEVI Abiodoun Clément

Résumé

Pour la réalisation de toute application embarquée, la phase de spécification du système que constitue la modélisation permet de valider ce système. Le GRAFCET constitue un des outils de modélisation de ces types de système. Ce mémoire propose une traduction de diagrammes grafcet en code pour la plate-forme Mbed dans le but de réaliser des applications de contrôle- commande sur cette dernière. Les diagrammes grafcet sont réalisés sous l’éditeur de graphes « Jgrafchart » qui renvoie un fichier XML qui est exploité pour traduire à travers un programme java, les informations utiles sous forme de code dans le langage C++ pour les microcontrôleurs de type Mbed. Les éléments notables du langage GRAFCET dont nous avons tenue compte sont entre autres les étapes et les actions qui leurs sont liées, les transitions et leurs réceptivités, les variables et notamment les éléments qui prennent en compte l’aspect hiérarchique dans le GRAFCET dont les étapes macro et les étapes encapsulantes.

Mots clés :

GRAFCET, Mbed, Jgrafchart, applications de contrôle- commande.

Abstract

For the realization of any eMbedded application, the phase of specification of the system that constitutes the modeling makes it possible to validate this system. The GRAFCET is one of the modeling tools for these types of systems. This master thesis introduces the translation of grafcet chart to a code for Mbed platform in order to realize control applications. Grafcet charts are realized under “Jgrafchart”, the GRAFCHART editor, which return a XML file that is used to translate via à java program, useful information of the chart into code in C++ language for Mbed microcontrollers. The notable elements of GRAFCET that we consider in our work are steps and actions that are associated to them, transitions and their receptivity, variables and especially elements that take account the hierarchical aspect in GRAFCET including macro steps and enclosing steps.

Key words:

Grafcet, Mbed, Jgrafchart, control applications.

(5)

V Rédigé par : HOUNKPEVI Abiodoun Clément

Table des matières

Remerciements ... III Résumé ... IV Abstract ... IV Table des matières ... V Liste des sigles et abréviations ... VIII Liste des figures ... IX Liste des Algorithmes ... XII

Introduction générale ... 1

Chapitre 1 : Etat de l’art ... 4

1.1. Génération de code de Jgrafchart vers ATMEL AVR [4] ... 4

1.2. Embarquer des réseaux de Petri temporel [6] ... 4

1.3. GRAFCHART et GRAFCET : comparaison entre deux langages graphiques de control séquentiel [7] ... 5

1.4. Traduction automatique du modèle GRAFCET d’un système automatisé en un modèle Réseau de Petri temporel [3] ... 6

1.5. Modélisation du grafcet temporisé et vérification de propriétés temporelles [8] ... 6

1.6. Synthèse structurelle d’un contrôleur basée sur le grafcet [9] ... 6

Chapitre 2 : Outils de modélisation et plate-forme de mise en œuvre ... 8

2.1. Le Grafcet ... 8

2.1.1. Les éléments du grafcet décrits dans la norme IEC 60848 [14] ... 8

2.1.2. Règle de syntaxe décrite selon la norme IEC 60848 [14] ... 10

2.1.3. Les éléments d’interprétation du Grafcet [3] ... 11

2.1.4. Règle d’évolution du langage Grafcet selon la norme IEC 60848 [7] ... 13

2.1.5. Interprétations du GRAFCET [15] ... 14

2.1.6. Différences entre GRAFCET et SFC ... 15

2.2. La plate-forme Mbed ... 16

2.2.1. Généralité sur Mbed ... 16

2.2.2. Mbed RTOS ... 17

2.3. Le Jgrafchart ... 17

2.3.1. Généralité sur le JGrafchart ... 18

2.3.2. Le GRAFCET et le JGrafchart ... 18

2.3.3. Modélisation des éléments du langage Grafcet non pris en compte par Jgrafchart ... 26

Chapitre 3 : Traduction des éléments du GRAFCET pour la plate-forme Mbed ... 29

3.1. Traduction ... 29

(6)

VI Rédigé par : HOUNKPEVI Abiodoun Clément

3.1.1. Les variables ... 29

3.1.2. Les étapes ... 30

3.1.3. Les transitions ... 30

3.1.4. Les réceptivités associées aux transitions ... 31

3.1.5. Les actions continues ... 31

3.1.6. Les actions mémorisée ... 32

3.1.7. Le grafcet partiel ... 33

3.1.8. Le processus principal ... 33

3.1.9. Le grafcet partiel ordinaire ... 34

3.1.10. L’expansion ... 35

3.1.11. L’encapsulation ... 36

3.2. Limites dans l’implémentation ... 38

Chapitre 4 : Etude de cas ... 39

4.1. Exemple applicatif ... 39

4.1.1. Analyse du circuit ... 39

4.1.2. Proposition d’un grafcet pour cette application ... 40

4.2. Code obtenu après traduction ... 51

4.3. Implémentation du programme de traduction sous Java ... 51

4.3.1. La structure du fichier XML de JGrafchart ... 51

4.3.2. Le programme Java ... 53

Conclusion et Perspectives ... 57

Référence bibliographique ... 58

Annexe ... 60

1. Diagramme de classe des des programme C++ pour Mbed ... 60

2. Définition de la classe Etape ... 60

3. Définition de la classe Transition ... 61

4. Code pour tester la stabilité ... 63

5. Définition de la classe Grafcet_partiel ... 64

6. Définition de la classe Encapsulation ... 65

7. Définition de la classe Expansion ... 66

8. Définition de la classe Simple (Grafcet partiel ordinaire) ... 67

9. Fonction pour exécuter un objet de type Encapsulation ... 68

10. Fonction pour exécuter un objet Expansion ... 69

11. Fonction pour exécuter un objet de type Simple ... 69

11. Fonction de mise à jour des réceptivités ... 70

English Part ... 71

I- Introduction ... 71

(7)

VII Rédigé par : HOUNKPEVI Abiodoun Clément

II- Discussion ... 73

III- GRAFCET ... 75

1. The elements of the grafcet described in standard IEC 60848 [14] ... 75

2. GRAFCET language evolution rule according to IEC 60848 [7] ... 76

IV- GRAFCET and GRAFCHART ... 77

1. Similarity ... 77

2. Translation of GRAFCET elements for the Mbed platform ... 78

V- Case study ... 82

VI- Conclusion ... 82

(8)

VIII Rédigé par : HOUNKPEVI Abiodoun Clément

Liste des sigles et abréviations

 ARM : Advanced RISC Machines

 CAN : Convertisseur Analogique Numérique

 GCC : GNU Compiler Collection

 GRAFCET : GRAphe Fonctionnel de Commande des Étapes et Transitions

 HDK : Hardware Development Kit

 I2C : Inter-Integrated Circuit (IIC)

 LDR : Light Dependent Resistor

 PN2A : Petri Net to Arduino

 RISC : Reduced Instruction Set Computing

 RTOS : Real Time Operating System

 SED : Système à Evènement Discret

 SFC : Sequential Function Chart

 SPI : Serial Peripheral Interface

 TPN : Time Petri Net

(9)

IX Rédigé par : HOUNKPEVI Abiodoun Clément

Liste des figures

Figure 2.1 : Une étape

Figure 2.2 : Une transition

Figure 2.3 : Une liaison Figure 2.4 : Une réceptivité Figure 2.5 : Action continue Figure 2.6 : Action continue Figure 2.7 : Action à l’activation Figure 2.8 : Action à la désactivation Figure 2.9 : Action sur évènement Figure 2.10 : Action au franchissement

Figure 2.11 : Représentation des étapes dans le GRAFCET Figure 2.12 : Représentation des étapes dans le GRAFCHART Figure 2.13 : Représentation d’une étape initiale dans le GRAFCET Figure 2.14 : Représentation d’une étape initiale dans le GRAFCHART Figure 2.15 : Représentation d’une étape Macro dans le GRAFCET Figure 2.16 : Représentation d’une étape Macro dans le Grafchart Figure 2.17 : Représentation d’une transition dans le GRAFCET Figure 2.18 : Représentation d’une transition dans le GRAFCHART Figure 2.19 : Représentation d’une variable dans le GRAFCET Figure 2.20 : Représentation d’une variable dans le GRAFCHART Figure 2.21 : Représentation d’une action continue dans le GRAFCET Figure 2.22 : Représentation d’une action continue dans le GRAFCHART Figure 2.23 : Représentation d’une action à l’activation dans le GRAFCET Figure 2.24 : Représentation d’une action à l’activation dans le GRAFCHART Figure 2.25 : Représentation d’une action à la désactivation dans le GRAFCET

(10)

X Rédigé par : HOUNKPEVI Abiodoun Clément

Figure 2.26 : Représentation d’une action à la désactivation dans le GRAFCHART

Figure 2.27 : Représentation d’une action sur évènement dans le GRAFCET Figure 2.28 : Représentation d’une action au franchissement dans le GRAFCET Figure 2.29 : Représentation d’une Réceptivité non temporelle dans le GRAFCET

Figure 2.30 : Représentation d’une Réceptivité non temporelle dans le GRAFCHART

Figure 2.31 : Représentation d’une Réceptivité temporelle dans le GRAFCET Figure 2.32 : Représentation d’une Réceptivité temporelle dans le GRAFCHART Figure 2.33 : Représentation d’une « Procedure »

Figure 2.34 : Représentation d’un « Procedure Step » Figure 2.35 : Représentation d’un « Process Step »

Figure 2.36 : Représentation étape encapsulante avec ses encapsulations Figure 3-1 : Déclaration d’une variable d’entrée/sortie digital

Figure 3-2 : Déclaration de variables simples

Figure 3-3 : Déclaration d’une variable d’entrée/sortie analogique Figure 3-4 : Réceptivité

Figure 3-5 : Action continue Figure 3-6 : Action à l’activation Figure 3-7 : Action à la désactivation Figure 3-8 : Action au franchissement

Figure 4-1 : Représentation du circuit électronique de l’application Figure 4-2 : Représentation de la photorésistance et de la résistance en Figure 4-3 : Grafcet partiel ordinaire (Principal)

Figure 4-4 : Bloc Météorologique

Figure 5-5 : Les 3 encapsulations de l’étape « Meteo »

Figure 4-6 : Encapsulation « Temp » s’occupant de la température

(11)

XI Rédigé par : HOUNKPEVI Abiodoun Clément

Figure 4-7 : Encapsulation « Hum » s’occupant de l’humidité Figure 4-8 : Encapsulation « Lu » s’occupant de la luminosité Figure 4-9 : Bloc de gestion du kit RTC

Figure 4-10 : Encapsulation de l’étape encapsulante « RTC »

Figure 4-11 : Bloc 4 (Gestion des affichages et du compte à rebours)

Figure 4-12 : Encapsulation s’occupant de l’affichage de l’heure et de la date Figure 4-13 : Encapsulation de l’étape « Aff_Meteo »

Figure 4-14 : Encapsulation de l’étape « R_Horloge » pour le réglage du temps Figure 4-15 : Sous-bloc d’annulation

Figure 4-16(a) : Encapsulation de réglage de l’heure Figure 4-16(b) : Encapsulation de réglage de la minute Figure 4-17 : Gestion du compte à rebours

Figure 4-18 : Encapsulation de gestion du compte à rebours Figure 4-19 : Etape macro s’occupant du décompte interne

(12)

XII Rédigé par : HOUNKPEVI Abiodoun Clément

Liste des Algorithmes

Algorithme 1 : Schéma d’exécution des Grafcet

Algorithme 2 : Evolution de la fonction principale Algorithme 3 : Evolution du grafcet partiel ordinaire Algorithme 4 : Evolution d’une expansion

Algorithme 5 : Evolution d’une encapsulation

Algorithme 6 : Evolution de la fonction de mise à jour des réceptivités

(13)

1 Rédigé par : HOUNKPEVI Abiodoun Clément

Introduction générale

Le progrès de la technique permet d’envisager des systèmes de contrôle et de commande de plus en plus complexes. Or une bonne conception d’un système informatique complexe, fiable et évolutif, passe par l’usage d’un modèle de cycle de développement tel que le modèle en V [1]. Ainsi, une phase de spécification doit précéder les phases de conception détaillée et de réalisation.

La phase de spécification permet d’exprimer les propriétés du système à concevoir, ou de le décrire par des abstractions formelles autorisant la vérification des propriétés attendues (via des simulations, des preuves mathématiques, le model-checking, ...) : ceci offre une certaine garantie de bon fonctionnement avant le passage à la mise en œuvre de l’application [2].

Dans le domaine des applications de contrôle-commande, le GRAFCET est un outil de modélisation synchrone de spécification semi-formelle pour la description fonctionnelle du comportement de la partie séquentielle d’un système (norme CEI 60848). Il a été proposé pour la première fois en 1977 en France par l’AFCET, « Association Française pour la Cybernétique Economique et Technique », comme méthode de spécification formelle pour les systèmes de contrôle logique (AFCET 1977). En 1988, le GRAFCET, avec un léger changement, fut adopté par la Commission Internationale d’Electrotechnique (CEI) comme un standard international nommé CEI 60848. Il ne constitue pas un langage de mise en œuvre d’une spécification, contrairement au langage SFC (Sequential Function Chart) décrit par la norme CEI 61131-3 et destiné aux automates programmables. La norme GRAFCET permet en particulier de modéliser une application de manière hiérarchique, ce qui peut être utile dans les applications complexe de contrôle-commande.

Plusieurs logiciels d’édition des grafcets existent. Cependant, selon la littérature [3], aucun ne produit un fichier modifiable dans un autre environnement. Par contre le GRAFCHART qui est un langage graphique de

(14)

modélisation d’applications de contrôle séquentiel offre cette possibilité qui manque aux éditeurs du GRAFCET bien qu’il ne soit pas un éditeur du langage GRAFCET. C’est un langage graphique de réalisations d’applications de contrôle séquentiel. Il est basé sur les syntaxes graphiques des GRAFCET et a été développé à l’institut universitaire de Londres et par le département de contrôle automatique en 1991 (Karl-Erik Årzén). La deuxième et dernière version de ce logiciel date de 1997.

Par ailleurs, parmi les plateformes modernes de développement des systèmes embarqués, Mbed est l’une des plus répandues. La programmation des microcontrôleurs Mbed ne nécessite aucune installation de logiciel. Il s’agit ici de disposer d’un PC, d’un navigateur installé et d’un port USB et l’on peut déjà se connecter à son compte privé personnel sur un serveur mise en place à cet effet. C’est à travers ce compte que l’on pourra écrire son programme et le compilé afin de récupérer un fichier BIN que l’on copiera sur la mémoire de notre kit Mbed. Mbed dispose d’un système d’exploitation (OS) temps réel dénommé Mbed OS. L’avantage d’un OS est de faciliter, via des abstractions (API), l’utilisation des ressources d’un ordinateur pour une application, évitant ainsi l’écueil de devoir maîtriser la complexité de l’architecture matérielle.

L’automatisation étant un facteur essentiel de croissance, de la productivité et un élément important de l’amélioration de la qualité de vie, et éprouvant alors de plus en plus la nécessité de disposer de méthodes et d’outils de conception, de réalisation et/ou de commande qui soient particulièrement efficaces, des améliorations successives au niveau du Grafcet et des plateformes Mbed ont fait de ces outils, des outils plus performants pour conduire à l’étude d’un automatisme séquentiel et suivre son évolution. Cependant, il n’existe à nos jours aucune traduction des grafcets en de modèles de code pour la plate- forme Mbed.

C’est alors fort de cela que ce mémoire propose une méthode de conception d’une application de contrôle-commande sous Mbed à partir d’un

(15)

diagramme GRAFCET décrivant le fonctionnement de cette application.

L’objectif principal visé est d’arriver à obtenir un code C++ pour Mbed à partir d’un diagramme grafcet représenté sous l’éditeur Jgrafchart du langage GRAFCHART à cet effet.

Pour atteindre ce but, nous nous sommes fixés des objectifs particuliers.

Dans un premier temps, il s’agira d’explorer la norme CEI 60848, en particuliers les aspects hiérarchiques (macro, encapsulation, forçage) et d’en clarifier les choix sémantiques à opérer compte tenu des ambiguïtés contenues dans la norme. Ensuite, nous ferons une étude du logiciel d’édition de Grafchart Jgrafchart et d’en maîtriser l’usage et définir les limites pour la prise en compte complète des éléments de la norme CEI 60848. L’étape qui suivra sera l’étude de Mbed OS et la maîtrise de l’utilisation du kit LPC1768-SK. Nous proposerons par la suite une démarche de traduction des éléments constitutifs d’un grafcet en entités logicielles pour Mbed OS. L’implémentation de la proposition de traduction suivra. En fin, nous ferons une étude de cas, c’est-à- dire utiliser le logiciel développé pour mettre en œuvre une application de contrôle-commande sur le kit Mbed (montage électronique).

Le présent mémoire est organisé en quatre chapitres. Dans le premier chapitre, nous présentons l’état de l’art. Un rappel sur les définitions, les règles et les propriétés de GRAFCET, de GRAFCHART et de Mbed est fait dans le chapitre 2. On fera également ici une comparaison entre les éléments de grafcet et ceux de Jgrafchart. Le troisième chapitre, propose une traduction des éléments d’un diagramme grafcet en un modèle de code pour Mbed. Cette traduction est implémentée sous l’environnement java. Enfin, le chapitre 4, propose une application que nous nommons Meteo_Horloge pour une mise en œuvre de nos travaux.

(16)

Chapitre 1 : Etat de l’art

Plusieurs travaux ont été réalisés dont le but était de traduire un diagramme grafcet en un modèle de code pour une plateforme de développement d’applications de contrôle-commande synchronisées.

1.1. Génération de code de Jgrafchart vers ATMEL AVR [4]

Il s’agit ici d’un mémoire de Master dans lequel l’auteur présente une méthode de génération de code pour les microcontrôleurs de type AVR mega8 à partir d’un diagramme réalisé sous Jgrafchart. Le code du langage C généré décrit le même comportement que le diagramme qui a servi à la génération de code et est compilable par le processeur de ces microcontrôleurs.

D’autre travaux abondent dans ce même sens en proposant une traduction d’un langage séquentiel de contrôle en code C. Citons à cette occasion le travail

« Un projet fédérateur d’Informatique Industrielle en IUT GEII : Programmation d’un GRAFCET en langage C sur PIC 18F452 » [5]. Ici également, les auteurs présentent une proposition de traduction d’un grafcet en code C.

Mais il faut noter que parmi les plateformes modernes de développement des systèmes embarqués, ceux reposant sur l’architecture ARM sont les plus répandus. Etant donné donc que Mbed se repose entièrement sur l’architecture ARM et que, même si de nos jours, les plates-formes Arduino fournissent les services ARM, ils n’étaient conçus à la base que pour des applications basiques, nous avons préféré la plate-forme Mbed à Arduino.

1.2. Embarquer des réseaux de Petri temporel [6]

Ce travail entre dans le cadre de la présentation d’un outil (PN2A : Petri Net To Arduino) de traduction des réseaux de pétri en des modèles de code compilable sous Arduino. L’outil PN2A récupère un Réseau de Petri Temporel et génère un code Arduino qui peut être compilé et chargé sur un

(17)

microcontrôleur de type Arduino. Ici, l’auteur a préféré les Réseaux de Petri Temporel au GRAFCHART en justifiant son intérêt pour les Réseaux de Petri affirmant donc « les Réseaux de Petri sont un langage de modélisation couvrant un grand nombre de domaines : les systèmes de contrôle, les protocoles de communication, les systèmes distribué ».

Cependant, dans notre travail, nous avons préféré le GRAFCET aux Réseaux de Petri car, moins un langage est formel, plus il est solliciter et le Grafcet demeure à ns jour un langage de modélisation semi-formel (avec encore quelques ambiguïtés) qu’il faille formaliser.

1.3. GRAFCHART et GRAFCET : comparaison entre deux langages graphiques de control séquentiel [7]

Dans cet article, les auteurs ont procédé à une comparaison du langage GRAFCET à celui du GRAFCHART. Selon eux, les deux langages sont des langages graphiques connus et utilisés pour des applications de contrôle séquentielles. En effet, GRAFCET est un langage de spécification de structures de contrôle alors que GRAFCHART est basé sur le GRAFCET, les Réseaux de Petri et des idées provenant de la programmation orienté-objet. Ce dernier peut être utilisé dans n’importe quelles applications de contrôle séquentielles.

En plus de tout cela, il faut noter que le GRAFCHART dispose d’un éditeur (Jgrafchart) très approprié qui permet de modéliser et de simuler des applications de contrôle-commande. Par ailleurs, cet éditeur peut générer un fichier d’extension XML qui peut être encore exploité pour récupérer les éléments d’une spécification Grafchart [3, p. 68]. Par contre, parmi tous les éditeurs de GRAFCET, aucun ne fournit un fichier exploitable si ce n’est un fichier binaire directement exécutable sur des machines. C’est fort de cela que nous avons considéré, dans notre travail, l’éditeur Jgrafchart pour éditer les grafcets même si tous les éléments du GRAFCET ne sont pas pris en compte dans le GRAFCHART.

(18)

1.4. Traduction automatique du modèle GRAFCET d’un système automatisé en un modèle Réseau de Petri temporel [3]

Ce mémoire décrit une méthode d’analyse et de vérification d’un diagramme grafcet à partir d’une traduction en Réseaux de Petri Temporel.

Ladite méthode repose sur la conversion, à partir d’un code écrit en Java, d’un diagramme grafcet en un modèle de Réseaux de Petri. Ce code permettra aussi de vérifier les propriétés portant sur le temps, les situations, et les actions d’un diagramme grafcet. Ce mémoire traite d’une partie de la nôtre qui consiste à la récupération des éléments d’un grafcet à partir d’un programme Java.

Cependant, il ne traite pas le même problème que nous.

1.5. Modélisation du grafcet temporisé et vérification de propriétés temporelles [8]

Dans cette thèse, l’auteur s’est intéressé au grafcet temporisé et à la vérification temporelle. L’objectif est d’étudier la possibilité de prendre en compte le temps dans la modélisation du grafcet en automate temporisé ainsi que la forme que prennent les vérifications sur ces modèles en tenant compte de l’environnement, de la technique de vérification. Mais cette modélisation peut conduire à une explosion combinatoire du nombre d’états, et il n’arrivait à traiter que des diagrammes grafcet avec des délais de temporisation ne dépassant pas trois unités de temps.

1.6. Synthèse structurelle d’un contrôleur basée sur le grafcet [9]

Les travaux effectués dans cette thèse présentent deux contributions au problème de la synthèse de contrôleur pour les SED modélisés par des grafcets :

 Une méthode systématique de passage de l'automate superviseur vers le grafcet superviseur de manière structurelle.

(19)

 Une approche de synthèse structurelle, dans laquelle la taille de grafcet obtenu est réduite et implantable sur les automates programmables.

Cette thèse décrit comment on pourra structurer un grafcet en vue d’une vérification des propriétés avec la logique temporelle.

(20)

Chapitre 2 : Outils de modélisation et plate-forme de mise en œuvre

Parmi tous les outils de modélisation d’application de contrôle-commande, nous avons retenu le GRAFCET, langage semi-formel auquel il faudra apporter des formalismes. Dans ce chapitre, ce sera le lieu de présenter ce langage et de présenter son algorithme d’interprétation. Ici également, nous présenterons la plate-forme Mbed pour laquelle nous portons un intérêt majeur car étant le seul qui se repose entièrement sur l’architecture ARM, la plus répandu au monde.

2.1. Le Grafcet

Le GRAFCET permet de spécifier le comportement attendu d’un système de contrôle-commande relié à un système physique. Pour cela, plusieurs extensions ont été proposées afin d’accroître ses possibilités de modélisation.

Le GRAFCET a été développé à partir de résultats issus de la communauté scientifique sur les Réseaux de Pétri (RdP) [10] et plus particulièrement sur des travaux relatifs aux réseaux de Pétri Temporels et synchronisés [11]. Une présentation détaillée des concepts et formalismes liant ces deux modèles a été proposée par David et Alla dans [12] et dans [13].Une syntaxe et une sémantique spécifique ont été définies pour le grafcet, afin de prendre en compte les besoins spécifiques des systèmes. Les points clés concernant la syntaxe et la sémantique du grafcet sont rappelés dans la section 2-1-1.

2.1.1. Les éléments du grafcet décrits dans la norme IEC 60848 [14]

L’IEC est une organisation mondiale de normalisation composée de l'ensemble des comités électrotechniques nationaux (Comités nationaux de cette organisation). Elle a pour objet de favoriser la coopération internationale pour toutes les questions de normalisation dans les domaines de l'électricité et de l'électronique. Elle collabore étroitement avec l'Organisation Internationale de

(21)

Normalisation (ISO), selon des conditions fixées par accord entre les deux organisations [14].

La Norme internationale CEI 60848 a été établie par le sous-comité (3B : documentation), du comité d'études 3 de la CEI (documentation et symboles graphiques). Cette norme décrit le langage Grafcet qui constitue un langage de base pour d’autres langages comme le SFC de la norme CEI 61131-3.

Les éléments du langage Grafcet décrit dans [14] sont entre autres les étapes, les transitions, les liaisons …

- Etape

C’est l’élément du langage GRAFCET utilisé pour définir la situation de la partie séquentielle d’un système. La figure 2.1 donne une illustration d’une étape.

Figure 2.1 : Une étape

- Transition

C’est l’élément du langage GRAFCET qui indique la possibilité d'évolution d'activité entre deux ou plusieurs étapes. Sa représentation est faite à la figure 2.2.

Figure 2.2 : Une transition

- Liaisons

Eléments du langage GRAFCET, les liaisons orientées indiquent les voies d'évolution en reliant les étapes aux transitions et les transitions aux étapes. Elles sont orientées comme le montre la figure 2.3.

(22)

Figure 2.3 : Une liaison

2.1.2. Règle de syntaxe décrite selon la norme IEC 60848 [14]

Une spécification grafcet permet de décrire le comportement souhaité d’un contrôleur logique. Une étape ne peut être liée qu’à des transitions, et une transition qu’à des étapes.

Une étape définit un état partiel du système ; une étape peut être active ou inactive. De plus, une variable booléenne appelée « variable d’activité » de l’étape peut être définie pour chaque étape. Des actions peuvent être associées à une étape ; une action associée à une étape est réalisée uniquement lorsque cette étape est active. Une action agit sur les variables de sortie.

Quant aux transitions, une condition peut être associée à chacune d’elles.

Cette condition est une expression booléenne appelé réceptivité et qui est définit à partir des variables d’entrée et de sortie. Les transitions peuvent se trouver dans trois états. Le premier correspond à l’inactivation d’au moins une étape parmi ceux se trouvant en amont de la transition concernée. L’état « valide », le deuxième état, correspond à l’activation de toutes les étapes qui se trouvent en amont de la transition concernée. En fin, l’état « franchissable » est l’état acquis par la transition lorsqu’en plus du fait qu’elle est valide, sa réceptivité est vraie.

La représentation d’une spécification grafcet peut être structurée et hiérarchisée à l’aide de grafcet partiels, du forçage, de macro-étapes ou d’étapes encapsulantes.

1

Liaison

1

Liaison

(23)

2.1.3. Les éléments d’interprétation du Grafcet [3]

2.1.3.1. Réceptivité

Une réceptivité associée à une transition est une condition logique et/ou un évènement. Une condition logique est une fonction booléenne de variables externes et de variables internes. Une variable interne est liée aux activations des étapes. Une variable externe est l’information venant d’un capteur, d’un bouton poussoir ou d’un système extérieur. La figure 2.4 donne la représentation d’une réceptivité.

Figure 2.4 : Une réceptivité

2.1.3.2. Action

Les actions associées à une étape sont inscrites dans un rectangle d’action de façon à mettre en évidence ce qui s’exécute lorsque cette étape est active.

Souvent, il s’agit de commande d’actionneurs (vérins, moteurs). Cela peut être aussi des commandes de fonctions auxiliaires d’automates (compteur, temporisation, …). Elles peuvent aussi décrire des liens avec d’autres systèmes logiques ou analogiques (changement de vitesse de moteur par exemple). Nous distinguons plusieurs types d’actions telles que les actions continues, les actions conditionnelles, les actions temporisées :

 Action continue : Représentée à la figure 2.5, elle est exécutée si l’étape à laquelle elle est associée est active.

Figure 2.5 : Action continue

 Action conditionnelle : Une proposition logique, appelée condition d'assignation, qui peut être vraie ou fausse, peut conditionner une action

Réceptivité

(24)

continue. La figure 2.6 est une représentation d’une action continue conditionnelle.

Figure 2.6 : Action continue

 Action mémorisée : Elle permet d’affecter une valeur déterminée à une variable de sortie. Cette action est effectuée à l’activation ou à la désactivation d’une étape, au franchissement d’une transition ou sur apparition d’évènement.

Figure 2.7 : Action à l’activation

Figure 2.8 : Action à la désactivation

Figure 2.9 : Action sur évènement

Figure 2.10 : Action au franchissement Actions

Actions

Condition

Actions Conditon

Actions Actions

(25)

2.1.4. Règle d’évolution du langage Grafcet selon la norme IEC 60848 [7]

La définition complète du comportement de toute spécification Grafcet peut être obtenue par l’application des cinq règles d’évolution suivantes :

Règle 1 :

La situation initiale, choisie par le concepteur, est la situation à l’instant initial. À l’initialisation, toutes les étapes initiales (les étapes de la situation initiale, indiquées par un carré double) sont actives ; toutes les autres étapes sont inactives.

Règle 2 :

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. Une transition validée et dont la réceptivité associée est vraie est immédiatement franchie.

Règle 3 :

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.

Règle 4 :

Plusieurs transitions simultanément franchissables sont simultanément franchies.

Règle 5 :

Si, au cours du fonctionnement, une étape active est simultanément désactivée et activée, alors elle reste active.

Cette description textuelle des règles d’évolution du Grafcet telles que définies dans la norme IEC 60848 est suffisante pour la compréhension du comportement décrit et permet l’implantation d’algorithme d’interprétation.

Ces règles d’évolution montrent que l’état global d’une spécification grafcet, appelé situation et caractérisé par l’ensemble des étapes actives d’un grafcet à un instant donné, est défini par l’ensemble de toutes les étapes

(26)

simultanément actives ; la situation initiale d’un grafcet est définie par l’ensemble des étapes initiales de ce dernier.

2.1.5. Interprétations du GRAFCET [15]

L'algorithme 1 ci-dessous décrit le séquencement des phases d'exécution d'un grafcet en tant que modèle réactif synchrone : dans un cycle indéfini, chaque occurrence d'un événement externe est suivie d'un calcul de réaction (avec actualisation des états de sortie). La première ligne correspond à la situation initiale avant entrer dans la boucle infinie (lignes 2-15). Une évolution de l'exécution s'étend des lignes 2 à 7: alors qu'un ensemble de transitions sont franchies d’un seul coup, les actions sont effectuées consécutivement jusqu'à ce que le grafcet atteigne une situation stable (ligne 8).

Dans une situation stable (lignes 9-13), les actions continue liées à la situation actuelle sont exécutées, tout comme les actions conditionnelles avec des conditions réelles (lignes 9 et 10); seulement un changement sur une entrée ou une occurrence de timeout sur un variable temporisée (lignes 11-13) pourrait faire quitter cette stabilité, à condition qu'une nouvelle phase de tir soit activée (ligne 5) par ce changement. Il est à noter cependant que le temps passe vraiment (ligne 11) seulement dans une situation stable: pendant une évolution, il est supposé suspendu. De plus, l'état de les sorties soumises à des actions continues ne peuvent changer que une situation stable.

Algorithme 1 : Schéma d’exécution des Grafcet

1 Faire les actions à l’activation sur les étapes initiales 2 TantQue Vraie Faire

3 Evaluer les réceptivités des transitions

4 Calculer la table des transitions franchissables

5 Si la table des transitions franchissables n’est pas videAlors

6 Franchir les transitions de la table d’un seul coup 7 Faire les actions à la désactivation

8 Sinon

(27)

9 Evaluer les conditions des actions continues ;

10 Mettre à jour les sorties autorisées par les actions continues (et remettre à jour les autres) ;

11 Démarrer/ Redémarre le temps pour les variables temporel ; 12 Attendre l’occurrence d’un évènement externe ;

13 Suspendre tous les compteurs de temps ;

14 FinSi

15 FinTantQue

2.1.6. Différences entre GRAFCET et SFC

La comparaison suivante est basée sur les deux normes relatives au GRAFCET et au SFC, respectivement la norme IEC 60848 [14] et la norme IEC 61131-3[16].

Selon [3], le GRAFCET est un langage de spécification pour la description fonctionnelle du comportement de la partie séquentielle des systèmes de commande. Mais, le SFC est utilisé pour structurer une unité d’organisation de programmes ; ses éléments sont définis en utilisant un ou plusieurs des quatre langages de programmation décrits dans la norme.

Un Grafcet est donc utilisé pour spécifier un comportement (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).

Les différences entre ces deux langages normalisés résident aussi bien dans leur syntaxe que dans leur sémantique [17]. De plus, ces deux normes ne sont également pas destinées au même usage ; la norme IEC 60848 décrit un langage de spécification, tandis que la norme IEC 61131-3 décrit un langage d’implantation. Par exemple dans un SFC, toute sélection de séquence est

(28)

exclusive, il ne peut pas y avoir de franchissement simultané de plusieurs transitions d’une même sélection de séquence. Afin de s’assurer de cela, l’utilisateur peut définir des priorités entre les différentes séquences.

De même un grafcet peut contenir une ou plusieurs étapes initiales (au moins une étape initiale par cycle de séquence), alors qu’un SFC ne peut et ne doit comporter qu’une seule étape initiale par diagramme SFC. Un SFC ne comporte pas d’action conditionnelle. En revanche, les actions peuvent également être déclenchées à l’activation ou à la désactivation de l’étape à laquelle elles sont associées.

La principale différence sémantique réside dans la définition des règles d’évolution. Dans une spécification grafcet, les évolutions entre situations stables sont dues à un changement des variables d’entrées ; alors que dans un SFC, les évolutions sont régies par le cycle de lecture des entrées du contrôleur exécutant le modèle. Par conséquent, un seul ensemble de transitions simultanément franchissables peut être franchi à chaque cycle d’exécution.

Ainsi, les notions de situations stables et instables n’ont pas de sens dans un Modèle SFC.

2.2. La plate-forme Mbed

Comme toutes les autres plates-formes de programmation, Mbed est, non seulement une plate-forme, mais aussi un système d’exploitation pour les appareils connectés à internet et utilisant des microcontrôleurs de type ARM Cortex-M 32 bit.

2.2.1. Généralité sur Mbed

Les microcontrôleurs Mbed sont une série de modules de prototypage Mbed officiels basés sur le HDK Mbed. Ils offrent des solutions de prototypage rapide, flexible et à faible risque. L’interface de programmation fonctionne avec Windows, Mac OS X et Linux. Le code binaire peut être obtenu à l’aide du

(29)

compilateur en ligne de Mbed ou en utilisant l’un des outils de compilation hors ligne (standard) tels que Keil uVision, Red Code, Code Sourcery, GCC ou IAR.

Les langages de programmation des microcontrôleurs Mbed sont le C et le C++

[18].

Il existe plusieurs cartes de démonstration matérielles pour la plateforme Mbed, la première étant la carte microcontrôleur Mbed commercialisée sous le nom de "Mbed NXP LPC1768". C’est une carte démo basée sur un microcontrôleur NXP, qui a un cœur ARM Cortex M3, fonctionnant à 96 MHz, avec 512 KB de mémoire flash et 64 KB de mémoire RAM ainsi que plusieurs interfaces que sont Ethernet, USB périphérique, CAN, SPI, I2C et d'autres entrées/sorties.

Différentes versions de la carte ont été proposées, avec des microcontrôleurs dont NXP LPC2368 (ARM7TDMI-S), NXP LPC1768 (Cortex-M3), NXP LPC11U24 (Cortex-M0). Pour nos différents projets d’étude de cas, le kit LPC1768 sera le microcontrôleur que nous utiliserons.

2.2.2. Mbed RTOS

RTOS est un acronyme qui signifie Real Time Operating System.

Mbed RTOS est la partie de Mbed qui s’occupe de l’aspect temps réel de cette dernière. A cet effet, il a été doté d’un système d’exploitation dénommé Mbed OS[19]. L’avantage d’un OS, c’est de faciliter via des abstractions API l’utilisation des ressources d’un ordinateur pour des applications évitant ainsi l’écueil de devoir maitriser la complexité de l’architecture matérielle.

2.3. Le Jgrafchart

D’après [7] GRAFCHART est un langage de programmation graphique des applications séquentielles, procédurales et des applications orientées étape- transition. Il est basé sur des idées provenant :

- des GRAFCET/SFC

(30)

- des Statecharts

- du langage ordinaire de programmation textuelle - des Réseaux de Petri

GRAFCHART peut être utilisé pour tout type d’applications à évènement discret comme par exemple le contrôle logique, la gestion des procédures d’exploitation, le contrôle par lots basé sur une recette et la modélisation de flux de travail. L’éditeur d’objets graphiques pour le GRAFCHART est le JGrafchart.

2.3.1. Généralité sur le JGrafchart

Avec l’éditeur JGrafchart, l’utilisateur programme, configure et exécute les programmes. Les programmes peuvent également être enregistrés sous le format XML. JGrafchart est basé sur l’interprétation et sur la compilation.

L’interprétation est effectuée en temps réel en relation avec l’environnement externe. JGrafchart est implémenté sous Java 2 et Swing.

2.3.2. Le GRAFCET et le JGrafchart

Le GRAFCET et le GRAFCHART sont des langages de modélisation des applications séquentielles de contrôle-commande. Nous présentons dans cette section les similitudes ces deux langages afin de pouvoir bien situer les éléments du GRAFCET qu’on pourra représenter dans l’éditeur de GRAFCHART (Jgrafchart).

-

Etape avec son bloc d’actions

Selon [20], « Les étapes modélisent l'état du système. L'ensemble des étapes actives à un instant donné constitue la situation du GRAFCET et les actions associées sont exécutées ». Les figures 2.11 et 2.12 représentent respectivement les étapes dans le GRAFCET et le JGRAFCHART.

(31)

Figure 2.11 : Représentation des étapes dans le GRAFCET

Figure 2.12 : Représentation des étapes dans le GRAFCHART

- Etape initiale

Une étape initiale est une étape qui modélise l’état du système au démarrage de ce dernier. A travers les figures 2.13 et 2.14, nous représentons respectivement une étape initiale dans le langage GRAFCET et dans le GRAFCHART.

Figure 2.13 : Représentation d’une étape initiale dans le GRAFCET

Figure 2.14 : Représentation d’une étape initiale dans le GRAFCHART

- Etape Macro

Une étape macro est une représentation unique d’une partie détaillée du grafcet appelée expansion. L'expansion d'une macro-étape M* est une partie de grafcet munie d'une étape d'entrée E* et d'une étape de sortie S*. L'étape d'entrée E* devient active lorsque l'une des transitions amont de la macro-étape est franchie. La ou les transitions aval de la macro-étape ne sont validées que

(32)

lorsque l'étape de sortie S* est active. Les figures 2.15 et 2.16 représentent respectivement les représentations d’une étape macro dans GRAFCET et sous Jgrafchart.

Figure 2.15 : Représentation d’une étape Macro dans le GRAFCET

Figure 2.16 : Représentation d’une étape Macro dans le Grafchart

- Transition

Les transitions contrôlent le passage d'une étape à une autre, par l'intermédiaire des réceptivités qui leur sont associées. Nous présentons à cet effet aux figures 2.17 et 2.18 respectivement les représentations d’une transition dan GRAFCET et sous Jgrafchart.

Figure 2.17 : Représentation d’une transition dans le GRAFCET

Figure 2.18 : Représentation d’une transition dans le GRAFCHART

- Variables

Dans le langage GRAFCET, les variables sont juste matérialisées par leur nom. ‘‘Dc’’ pourrait être par exemple utilisé pour désigner une variable

« Départ cycle » comme à la figure 2.19. Dans ce cas les types des variables

(33)

importent peu. Par contre, dans le langage Grafchart [21], les variables sont représentées dans un rectangle où à l’intérieur, nous mettons le type et la valeur de la variable et à l’extérieur, en dessous du rectangle, nous mettons le nom de la variable comme décrit à la figure 2.20.

Var

Figure 2.19 : Représentation d’une variable dans le GRAFCET

Figure 2.20 : Représentation d’une variable dans le GRAFCHART

- Action continue

Une action continue est nécessairement associée à une étape. Plusieurs actions peuvent être associées à une même étape. Le libellé d'une action continue est la désignation de la variable de sortie assignée à la valeur vraie selon la règle d'assignation comme nous le décrit la figure 2.21. Dans le GRAFCHART, cette variable est précédée de l’identificateur « N » et succédée par un point-virgule (voir figure 2.22).

Figure 2.21 : Représentation d’une action continue dans le GRAFCET

Figure 2.22 : Représentation d’une action continue dans le GRAFCHART Variable

(34)

- Action mémorisée

Une action mémorisée possède un libellé qui décrit comment la variable de sortie est affectée à une valeur déterminée selon la règle d'affectation.

Plusieurs types d’action mémorisée existent. Citons les actions à l’activation (figure 2.23 et 2.24), les actions à la désactivation (figure 2.25 et 2.26), les actions sur évènement (figure 2.27) qui sont toutes liées aux étapes et les actions au franchissement (figure 2.28) qui sont liées aux transitions.

 Action à l’activation

Dans JGrafchart, elle est représentée par une ligne d’instruction précédée d’un identificateur « S ».

Figure 2.23 : Représentation d’une action à l’activation dans le GRAFCET

Figure 2.24 : Représentation d’une action à l’activation dans le GRAFCHART

 Action à la désactivation

Elle est représentée Dans Jgrafchart par une ligne d’instruction précédée d’un identificateur « X ».

(35)

Figure 2.25 : Représentation d’une action à la désactivation dans le GRAFCET

Figure 2.26 : Représentation d’une action à la désactivation dans le GRAFCHART

 Action sur évènement

Le libellé indique, dans une action sur évènement comme le montre la figure 2.27, la mise à la valeur 1 d'une variable Q, lorsqu’un des événements associés à l'action (ici représenté se par ) se produit.

Figure 2.27 : Représentation d’une action sur évènement dans le GRAFCET Les actions sur évènement ne se retrouvant pas dans le langage GRAFCHART, leur édition dans Jgrafchart est impossible.

 Action au franchissement

Une action au franchissement est une action mémorisée associée à l’ensemble des événements internes qui ont chacun pour conséquence le franchissement de la transition à laquelle l’action est reliée. De même qu’une action sur évènement n’a pas une modélisation dans Jgrafchart. La figure 2.28 présente donc la représentation d’une action au franchissement dans le

(36)

GRAFCET. En effet, la représentation traditionnelle de l'action par un rectangle est complétée par un trait oblique reliant l'action à la transition.

Figure 2.28 : Représentation d’une action au franchissement dans le GRAFCET

- Les réceptivités

C’est une proposition logique, qui peut être vraie ou fausse et qui est associée à chaque transition. S'il existe une variable logique correspondante, elle est égale à 1 quand la réceptivité est vraie et égale à 0 quand la réceptivité est fausse. La proposition logique formant la réceptivité est constituée d'une ou plusieurs variables booléennes (variable d'entrée, variable d'étape, valeur d'un prédicat, etc.). Il existe plusieurs types de réceptivités associés aux transitions dans le GRAFCET. Mais seulement celle dépendant du temps (figure 2.29 et 2.30) et celle non dépendant du temps (figure 2.31 et 2.32) sont pris en compte dans Jgrafchart. Dans notre traduction, nous nous contenterons de ces deux types de réceptivité. Cependant, nous ne considèrerons pas l’union ou la réunion logique d’une réceptivité dépendant du temps et d’une autre réceptivité.

 Réceptivité non dépendant du temps

Figure 2.29 : Représentation d’une Réceptivité non temporelle dans le GRAFCET

(37)

Figure 2.30 : Représentation d’une Réceptivité non temporelle dans le GRAFCHART

 Réceptivité dépendant du temps

La notation 't1/*/t2' pour une réceptivité indique que la réceptivité n'est vraie qu’après un temps t1 depuis l'occurrence du front montant de la variable temporisée et redevient fausse après un temps t2 depuis l'occurrence du front descendant. L'astérisque doit être remplacé par le nom de l'étape à temporiser. t1 et t2 doivent être remplacés par leur valeur réelle exprimée dans l'unité de temps choisie. La variable temporisée doit rester vraie pendant un temps supérieur ou égal à t1 pour que la réceptivité puisse être vraie.

Quant à la réceptivité de type t/*, pour passer la transition associée, il faut nécessairement attendre t unité(s) de temps après l’activation de l’étape associé (ici représentée par le *). Ainsi, la réceptivité devient fausse dès la désactivation de l’étape temporisée. Il est toutes fois possible qu’il n’y ait pas une liaison directe entre l’étape et la transition.

Figure 2.31 : Représentation d’une Réceptivité temporelle dans le GRAFCET

Figure 2.32 : Représentation d’une Réceptivité temporelle dans le GRAFCHART

(38)

Dans la figure 2.32, la transition n’est franchissable que 2 seconde après l’activation de l’étape de nom « Nom ».

Plusieurs autres éléments du Grafcet sont non pris en compte dans le Grafchart dont les étapes encapsulantes, les forages .... La section suivante apportera des détails sur les éléments du Grafchart considérés afin de proposer une modélisation des étapes encapsulantes par Jgrafchart.

2.3.3. Modélisation des éléments du langage Grafcet non pris en compte par Jgrafchart

Le Grafchart étant un langage dérivé de plusieurs langages dont le Grafcet, le SFC, le réseau de pétri …, il comporte alors des éléments qui ne se trouvent pas dans le Grafcet. Citons pour la circonstance la « Procedure » qui n’est pas une étape mais plutôt un grafcet partiel (figure 2-23) qui peut être appelé de deux façons.

- La première est l’appel via une étape « Procedure Step » (figure 2.34).

Dans ce cas, les transitions qui se trouvent après cette étape ne sont validée que lorsque le grafcet partiel de la « Procedure » se trouve à une situation où l’étape « Exit Step » c’est-à-dire l’étape de sortie de ce grafcet partiel est activée.

- La deuxième façon d’appeler une « Procedure » est l’appel via une

« Process Step » (figure 2.35). Dans ce second cas, les transitions qui se trouvent après cette étape sont validée immédiatement. L’évolution du grafcet principal qui appelle la « Procedure » est indépendante de celle du grafcet partiel contenu dans cette même « Procedure ».

Cette deuxième description correspond bien au fonctionnement d’une étape encapsulante. En effet, une étape encapsulante sera représentée par une

« Process Step » et toutes les encapsulations de cette étape seront représentées par des grafcets partiels contenus dans une étape macro. Toutes ces étapes

(39)

macro seront par la suite représentées sans liaisons et sans transitions dans la

« Procedure » qui sera appelée par notre « Process Step » (figure 2.36).

- Une « Procedure »

Figure 2.33 : Représentation d’une « Procedure » - Un « Procedure Step »

Figure 2.34 : Représentation d’un « Procedure Step » - Un « Process Step »

Figure 2.35 : Représentation d’un « Process Step »

(40)

- Une étape encapsulante

Figure 2.36 : Représentation étape encapsulante avec ses encapsulations Dans ces conditions, le nom de l’étape encapsulante sera celui de l’étape

« Process Step » et les encapsulations représenteront respectivement les étapes macro qui se trouvent dans la « Procedure ».

(41)

Chapitre 3 : Traduction des éléments du GRAFCET pour la plate-forme Mbed

Dans ce chapitre, nous allons décrire les façons de représenter les différents éléments du GRAFCET sous forme de code C++ sous l’éditeur de Mbed. Nous allons également décrire les algorithmes d’interprétation des grafcets partiels à savoir les encapsulations et les expansions ainsi que d’autres algorithmes d’interprétation qui participe au bon déroulement du grafcet global.

3.1. Traduction

3.1.1. Les variables

Le langage GRAFCET comprend deux types de variables. Les variables d’entrée qui influencent le comportement du système et les variables de sortie qui évoluent suivant le comportement du système. Dans notre cas (cas du Mbed), nous définirons deux types de variables dont celles d’entrée/sortie et celles qui sont simples. Les variables d’entrée/sortie s’identifieront de celles simples sous Jgrafchart par le fait qu’elles sont initialisées par les ports du microcontrôleur auxquels elles sont associées. Cette initialisation est effectuée au niveau du nom de la variable concernée. D’une façon générale, nous considérons comme variables d’entrée pour le langage GRAFCET les variables simples et d’entrée du Mbed. Les figures 3-1, 3-2 et 3-3 décrivent les différentes possibilités de déclaration de variables aussi bien dans GRAFCET que dans Jgrafchart.

Figure 3-1 : Déclaration d’une variable d’entrée/sortie digitale DigitalOut Var(p10);

DigitalIn Var(p10);

(42)

Figure 3-2 : Déclaration de variables simples

Figure 3-3 : Déclaration d’une variable d’entrée/sortie analogique

3.1.2. Les étapes

Une étape sera considérée comme un objet ayant certains attributs à savoir : ses types (ordinaire ou non) et (initiale, star, d’entrée ou de sortie), ses états antérieur et courant, la durée en temps réel d’activation de ce dernier afin de gérer éventuellement les temporisations qui lui sont liées et un identifiant. En plus de ces attributs, une étape macro aura un état particulier pour permettre aux transitions qui la suivent de la voir activée après l’activation de l’étape de sortie contenue dans son expansion. Les méthodes Getter et Setter sont utilisées pour manipuler ces différents attributs. Les détails sur cette classe pourront être retrouvés dans l’annexe 1.

3.1.3. Les transitions

Une transition, sera tout comme une étape un objet ayant les attributs suivants : un identifiant, la liste des étapes qui suivent cette transition, le type de réceptivité et éventuellement le temps et l’étape de temporisation, la liste des étapes qui précèdent cette transition, une variable booléenne de sa validité et une variable de franchissabilité. Ici également, des méthodes Getter et Setter ainsi que d’autres méthodes utiles sont utilisées pour manipuler les attributs ci-dessus

bool Var3;

int led1 ; double Var2 ;

AnalogOut Var1(p16) ; AnalogIn Var1(p16) ;

(43)

cités. Les détails sur cette classe pourront également être retrouvés dans l’annexe 1.

3.1.4. Les réceptivités associées aux transitions

Une réceptivité sera représentée par une fonction booléenne qui retourne la valeur « Vraie » si la réceptivité est vraie et « Faux » si la réceptivité est fausse. La fonction sera appelée à chaque fois que l’on aura besoin de tester la réceptivité à laquelle elle est associée. Par ailleurs, Il est à noter que les réceptivités avec temporisation sont prises en compte directement par les transitions auxquelles elles sont associées. En effet, le temps et l’étape de temporisation sont enregistrés comme attribut au niveau de la transition à laquelle la réceptivité est associée (figure 3-4).

Figure 3-4 : Réceptivité

3.1.5. Les actions continues

Une action continue est une fonction qui sera exécutée par le processus principal « main » lorsque le grafcet sera dans sa situation de stabilité globale (aucune transition franchissable). En effet, le programme principal vérifie en permanence la stabilité globale du grafcet et qui dans le cas échéant, exécute les actions continues et conditionnelles.

bool Receptivite_Id_Transition(){

if(Libele) return 1;

return 0;

}

(44)

Figure 3-5 : Action continue

3.1.6. Les actions mémorisée

Une action mémorisée est également une fonction qui sera exécuté par le processus qui prend en charge le grafcet partiel auquel appartient l’étape à laquelle est associée l’action concernée.

Figure 3-6: Action à l’activation

Figure 3-7: Action à la désactivation

Figure 3-8: Action au franchissement bool Nom_Etape_Continue(){

Libele_Action_continue;

}

bool Nom_Etape_Activation(){

Libele_Action_activation;

}

bool Nom_Etape_Desactivation(){

Libele_Action_desactivation;

}

bool Nom_Etape_Franchissement(){

Libele_Action_franchissement;

}