rapport_ecrit_final

15 vues

Publié le

0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
15
Sur SlideShare
0
Issues des intégrations
0
Intégrations
6
Actions
Partages
0
Téléchargements
1
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

rapport_ecrit_final

  1. 1. Travail encadré de recherche : Pilotage de véhicules autonomes Jean Ibarz - ibarz.jean@gmail.com Hédi Najar - hedinajar@hotmail.fr Pierre Fagedet - pierre.fagedet@gmail.com Professeurs encadrant le projet : Euriell Le Corronc - Pauline Ribot 18 mai 2016 Département EEA M1 ISTR 1
  2. 2. Remerciements Nous tenons à remercier dans un premier temps toute l'équipe pédagogique de notre formation ISTR. Nous remercions tout particulièrement Madame Euriell Le Corronc et Madame Pauline Ribot pour leur aide, leur disponibilité et le temps qu'elles nous ont consacré tout au long de ce projet. Nous remercions également Mr Sylvain Durola pour les conseils avisés qu'il a su nous donner concernant certains détails de la modélisation de notre procédé et sur le formalisme des réseaux de Petri en général. Enn, nous remercions Mr Bernard Berthomieu et les collègues de son équipe Mr François Ver- nadat et Mr Silvano Dal Zilio, qui nous ont tous chaleureusement accueillis et nous ont renseignés sur l'utilisation de leur logiciel TINA ainsi que sur le format .tpn. 2
  3. 3. Résumé Ce projet de première année de Master Ingénierie des Systèmes Temps-Réel (ISTR) traite du pilotage de véhicules autonomes. Ce projet de recherche a été eectué sur une période de 6 mois et encadré par 2 enseignantes-chercheuses : Mme Euriell Le Corronc et Mme Pauline Ribot. L'ob- jectif du projet est le pilotage de véhicules autonomes avec un point de vue axé sur les systèmes à évènements discrets et en utilisant le formalisme des réseaux de Petri. Nous devons mettre en place un système permettant de garantir une évolution sûre du procédé, composé de plusieurs AGV (Autonomous Guided Vehicule, ou Véhicule Autonome Guidé en français), c'est à dire sans risque de collision entre les AGV. Le pilotage désiré doit également être optimal et prévenir tout inter-blocage possible entre les AGV (i.e. une situation ou plusieurs AGV ne peuvent plus se déplacer). Nous avons fait le choix d'un réseau composé de 3 AGV que nous avons ensuite modélisé sous forme de réseau de Petri sous TINA [4], modèle auquel nous avons ajouté les contraintes maté- rielles et les spécications de non-collision et de non-blocage que nous nous sommes xés. Nous avons mis en oeuvre un algorithme an de pouvoir planier une trajectoire pour les AGV devant remplir une mission prédénie et optimale par rapport à une fonction de coût. 3
  4. 4. Table des matières 1 Le procédé et son modèle 8 1.1 Le procédé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.1.1 Le réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 1.1.2 Les AGV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.2 Modèle du procédé avec ses contraintes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2 Spécication - pilotage sûr 15 2.1 Spécication de non-collision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.2 Spécication de non-blocage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.3 Modèle supervisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3 Planication de trajectoires - pilotage optimal 22 3.1 Planication de trajectoires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.2 Mission et coûts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.3 Algorithme de recherche d'un plan optimal . . . . . . . . . . . . . . . . . . . . . . . . . 25 4 Mise en oeuvre de la solution globale 28 4.1 Lecture/écriture de chiers .ndr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.2 Transformation du modèle RdP - GMA . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.3 Analyse des performances et optimisations . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.4 Résultats obtenus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Bibliographie 35 A Modèles RdP 36 B Modèles RdP simpliés 41 4
  5. 5. Problématique et Contexte Dans le cadre de ce travail encadré de recherche, nous nous intéressons au pilotage de véhicules autonomes représentés par des systèmes à évènements discrets. L'essor des véhicules autonomes pose de nombreuses questions quant aux méthodes utilisées pour les piloter de manière sûre et optimale sans l'intervention d'êtres humains pendant leurs activités. La réalisation de cette étude passe par diérentes étapes : la modélisation des véhicules en tant que systèmes à événements discrets grâce au formalisme des réseaux de Petri, la rédaction du cahier des charges, comportant les contraintes matérielles et de sécurité à ap- pliquer, la planication de trajectoires optimales pour les véhicules grâce à un système de récompense et de non franchissement de zones ennemies. Notre système physique sera entièrement simulé an que nous soyons plus libre dans notre projet et que nos avancées ne soient pas dépendantes de la disponibilité d'une maquette. Pour cela, nous nous sommes inspiré de l'article pilotage sûr et optimal d'une otte de véhicules autoguidés [1] . Figure 1 Réseau d'AGV [1] Ce réseau d'AGV, décrit dans [1], présente 3 gares W0, W1, et W2 ainsi que 3 AGV V1, V2 et V3. Ces 3 AGV se déplacent dans un seul sens (ils ne peuvent pas faire demi-tour ni reculer). Ce réseau est composé de 3 intersections à 3 voies (1 intersection au niveau de chaque gare W1etW2 ainsi qu'une intersection au centre de ces 2 mêmes gares) et d'une intersection à 4 voies en bas, au niveau de la gare W0. Nous avons imaginé un procédé assez proche de celui-ci et représentant les mêmes types d'intersec- tions. 5
  6. 6. Figure 2 Architecture de la solution envisagée Nous avons établi un modèle RdP de notre procédé an de représenter au mieux notre système physique (procédé). A ce modèle de procédé, nous avons ajouté des spécications construire notre modèle supervisé. Sur ce modèle supervisé, nous eectuons une planication de trajectoires suivant une mission et une fonction de coût. Une fois la planication de trajectoires faite, cette séquence de transitions à franchir est envoyée à notre système physique. Dans le premier chapitre du rapport nous exposerons les détails du système physique et de son modèle. Ensuite, dans le deuxième chapitre, nous présenterons les diérentes contraintes imposées par notre système et les spécications du cahier des charges que nous nous sommes xées qui sont un fonctionnement sans collision et sans blocage. Dans le troisième chapitre, nous évoquerons la mise en place d'un planicateur permettant de sélectionner les trajectoires optimales que devront suivre les AGV. Enn, dans le quatrième chapitre, nous montrerons plus en détail la mise en oeuvre de la solution globale. 6
  7. 7. Vocabulaire et Abréviations Vocabulaire : Supervision de contrôle : la supervision de contrôle est le processus qui consiste à limiter les actions d'un système, normalement décrit par un SED, à un ensemble de comportements sûrs/tolérables/désirés (dénition traduite de [13], page ), Superviseur (de contrôle) : le superviseur (de contrôle) est le processus qui applique la supervision de contrôle, Modèle supervisé : le modèle supervisé est le modèle unié résultant de la fusion du modèle RdP du procédé et du modèle RdP du superviseur (résultant des contraintes matérielles et des spécications du cahier des charges) par fusion de transitions [11], Planicateur : le planicateur est un processus qui dénit un plan suivant une mission et une fonction de coût, Graphe : un graphe est un ensemble de n÷uds (représentants un état) reliés par des arcs orientés. Ces arcs sont associés à une transition et représentent, lors du tir de cette transition, l'évolution d'un état à un autre. Trajectoire : dans notre contexte, une trajectoire est, selon le contexte, un chemin entre 2 noeuds d'un graphe, soit un chemin Séquence : une séquence est une liste ordonnée d'éléments, Plan : un plan est une séquence de transitions contrôlables à tirer dans cet ordre (et unique- ment). Un modèle RdP appliquant un plan peut toutefois tirer des transitions qui ne sont pas présentes dans le plan sans restrictions autres que celles du modèle, Mission : une mission est un ensemble de séquences d'objectifs à remplir. Les séquences d'objectifs sont indépendantes entre elles et peuvent donc évoluer en parallèle, Coût : un coût est une valeur associée à une transition, Place marquée : une place p est dite marquée si son marquage est supérieur ou égal à 1, i.e. si M(p) 1, Objectif : un objectif est un but à atteindre. Dans notre cas, un objectif sera associé à une place. On dira qu'un objectif est atteint ou rempli si la place qui lui est associée est marquée, Planicateur : le planicateur est un processus générant un plan c'est à dire une séquence de transitions contrôlables à tirer tout en respectant un coût et une mission à partir d'un état initial. Abréviations : AGV : Autonomous Guided Vehicule ( Véhicule Autonome Guidé en français), SED : Système à Évènements Discrets, RdP : Réseau de Petri. 7
  8. 8. Chapitre 1 Le procédé et son modèle 1.1 Le procédé 1.1.1 Le réseau Pour réaliser un système physique proche de la réalité, nous avons crée une maquette via le logiciel SCARM (Simple Computer Aided Railway Modeller [15]), qui permet de réaliser des plans de mo- délisme précis et à dimensions réelles (les dimensions sont basées sur des vraies pièces de modélisme disponibles sur le commerce). Cette maquette est représentée Figure 1.1. Ensuite nous avons déni un sens par défaut , représenté par les èches vertes sur les tronçons, pour dénir le sens de déplacement selon l'état des sorties des aiguillages ou des tronçons. Figure 1.1 Modèle physique choisi Remarque : dans ce procédé, chaque voie de déplacement peut-être empruntée dans les 2 sens mais 2 AGV ne peuvent se croiser sur une même voie. Les 3 AGV ont une vitesse binaire (marche avant ou arrêt). Leur sens de déplacement est dicté par l'alimentation des tronçons sur lesquels ils se trouvent. 8
  9. 9. Figure 1.2 Gare W1 Nous allons décrire le fonctionnement du système physique et les sorties liées aux tronçons, gares, aiguillages et intersections. Les tronçons Les tronçons sont des portions du réseau correspondant à des virages ou des lignes droites. Les tronçons nécessitent 1 sortie pour chaque sens de déplacement possible. Si le tronçon peut être traversé dans les 2 sens, il nécessite donc 2 sorties. La table de vérité ci-dessous indique le dépla- cement d'un AGV situé sur celui-ci en fonction de l'état des 2 sorties : Sortie 1 Sortie 2 Type de déplacement 0 0 Pas de déplacement 1 0 Déplacement sens par défaut 0 1 Déplacement opposé au sens par défaut Dans le cas particulier ou un tronçon ne peut être parcouru que dans 1 seul sens, il n'est alimenté que par 1 sortie : pas de déplacement si la sortie est à 0, sens de déplacement par défaut si la sortie est active. Les gares Nous avons décidé que les gares seraient toujours parcourues dans un unique sens : le tronçon de la gare (trW1 pour la gare W1, représentée Figure 1.2) et de sa boucle (trAW pour la même gare) nécessitent donc seulement 1 sortie. Il y a au total 3 gares donc 6 tronçons ne pouvant être parcourus que dans 1 seul sens. Les aiguillages Un aiguillage est un tronçon particulier, puisqu'il possède en plus la possibilité de changer la trajectoire d'un AGV. Notre procédé comporte des aiguillages à 2 directions et des ai- guillages à 3 directions. Les aiguillages à 2 directions nécessitent 1 sortie pour choisir la direction d'un AGV qui le parcourt : Etat de la sortie Trajectoire 0 Gauche (ou rectiligne) 1 Rectiligne (ou droite) Un aiguillage à 3 directions nécessite lui 2 sorties exclusives : Etat de la sortie 1 Etat de la sortie 2 Trajectoire 0 0 Rectiligne 1 0 Gauche 0 1 Droite 9
  10. 10. Dans notre procédé, tout les aiguillages peuvent être parcourus dans les 2 sens : ils nécessitent donc 2 sorties supplémentaires pour le déplacement d'un AGV, similairement à un tronçon à 2 sens de parcours. Les intersections Dans notre réseau on compte 2 types d'intersections : 3 intersections à 3 voies : A, B et C. 1 intersection à 4 voies : D. Un seul AGV peut être présent simultanément dans une intersection de type 3 voies (A, B ou C). L'intersection A est illustrée Figure 1.3. : nous avons fait le choix d'alimenter les 3 tronçons de l'in- tersection communément pour diminuer le nombre de sorties du procédé. Ces intersections nécessitent 2 sorties puisqu'elles peuvent être considérées comme un seul tronçon à alimenter. Les aiguillages, quant à eux, ne sont pas reconsidérés pour les intersections car ils possèdent déjà leurs propres sorties. Figure 1.3 Intersection A L'intersection D est un cas particulier car cette intersection possède 4 voies et permet, de par la structure du réseau, 3 cas possibles où 2 AGV la traversent simultanément. Ces 3 cas sont exposés ci-après, avec les trajectoires des AGV représentées en rouge : Cas 1 Cas 2 Cas 3 Remarque : sur le procédé, les 2 tronçons au centre de l'intersection se croisent mais ne s'inter- sectent pas : l'un des tronçons passe au-dessus de l'autre par l'intermédiaire d'un pont. Nous avons regroupé les tronçons en 2 groupes et fait le choix d'alimenter chaque groupe com- munément, comme illustré sur la Figure 1.4, ce qui permet de respecter les 3 cas vu précédemment. L'intersection de type D possède donc 4 sorties (2 par groupe), dont la table de vérité pour chaque groupe est similaire à celle vu pour les intersections de type 3 voies. Bilan des entrées : 16 (= capteurs de position). 10
  11. 11. Figure 1.4 Alimentation des tronçons selon 2 groupes (bleu et rouge) Figure 1.5 Bilan des entrées/sorties du système physique Bilan des sorties : 6 × 1 = 6 (= alimentation des tronçons à 1 sens de parcours), 13 × 2 = 26 (= alimentation des tronçons à 2 sens de parcours), 16 × (1 + 2) = 48 (= 16 aiguillages à 2 directions, nécessitants chacun 1 sortie pour le choix de la direction + 2 sorties pour les 2 sens de parcours), 2 × (2 + 2) = 8 (= 2 aiguillages à 3 directions, nécessitants chacun 2 sorties pour le choix de la direction + 2 sorties pour les 2 sens de parcours). On compte au total 16 entrées et 88 sorties. 1.1.2 Les AGV Nous considérons que nos AGV se déplacent sur des rails et qu'ils possèdent une vitesse binaire marche/arrêt (avec frein de sécurité) dans un seul sens de déplacement. De plus nous précisons que la dynamique des AGV et leur longueur sont tel que lors d'un arrêt sur un capteur il n'est pas dépassé. 1.2 Modèle du procédé avec ses contraintes Il n'est pas possible de réaliser en l'état le modèle de notre procédé. En eet, ce modèle doit, pour représenter de façon correcte le procédé, être tel que : si une transition est tirable, l'évènement qu'elle représente sur le procédé doit pouvoir avoir lieu, 11
  12. 12. à contrario, si une transition n'est pas tirable, alors l'évènement qu'elle représente sur le pro- cédé ne doit pas pouvoir avoir lieu. Si ces conditions ne sont pas respectées sur le modèle, alors il n'est pas possible de prévoir les évolutions possibles (ou impossibles) du procédé à partir de ce modèle. Illustrons le problème par un exemple. Sur la Figure 1.6, pour que la transition t4 soit franchissable, il faut que l'AGV se trouve sur le tronçon A1 (donc sur trA1) et que la sortie TRA1 (alim trA1) soit active. En réalité la zone grisée est non observable puisque nous n'avons pas de capteur nous per- mettant de savoir sur quel tronçon se trouve l'AGV lorsqu'il a quitté le capteur CW1 : nous savons seulement que l'AGV se trouve entre les deux capteurs CW1 et CA1. Par conséquent nous ne pouvons pas déterminer si la transition t4 est franchissable ou non franchissable. Pour résoudre ce problème, nous avons ajouté des contraintes de déplacement qui contraignent toutes les sorties nécessaires à l'évolution de l'AGV d'un capteur à un autre à être actives pendant tout le déplacement de l'AGV entre ces 2 capteurs. Figure 1.6 Problème de modélisation du procédé Pour le système physique que nous avons considéré, nous ne pouvons pas connaître la position exacte de l'AGV en tout instant : par exemple, sur le RdP représenté Figure 1.6, lorsque l'AGV quitte le capteur CW1 pour aller vers le capteur CA1, on ne peut pas savoir sur quel tronçon il se trouve (il peut se trouver encore sur trW1, sur trAW, sur aigW1, ou encore sur trA1) jusqu'à ce qu'il arrive au capteur CA1. Par conséquent, on ne peut pas savoir quelle sortie activer pour que l'AGV avance et puisse franchir la transition t4 : le procédé n'est pas commandable à partir de ce modèle. Contraintes de fonctionnement : Nombre d'AGV en circulation xé à 3, 2 vitesses : marche avant / arrêt, mise à l'arrêt de l'AGV systématique à chaque arrivée sur un capteur dynamique du système telle qu'un AGV puisse toujours s'arrêter sur un capteur sans le dépasser, un AGV ne peut se déplacer que de capteur en capteur. Un déplacement est symbolisé par une instance d'un processus de déplacement et il ne peut y avoir qu'une seule instance d'un tel 12
  13. 13. Figure 1.7 Processus de déplacement de W1 vers A1 et A1 vers W1 Figure 1.8 Transitions permettant d'exécuter un processus de déplacement ajoutées au modèle du procédé de position processus à la fois pour un même AGV, il ne doit pas y avoir de blocage possible. Blocage : un blocage est une incapacité totale d'un ou plusieurs AGV à réaliser un déplacement. Pour avoir un modèle correct du procédé permettant de le commander, on dénit des contraintes de déplacement. Contraintes de déplacement : Pour eectuer un déplacement, un AGV devra exécuter un processus de déplacement . Un pro- cessus de déplacement déni l'activation des sorties du départ d'un capteur à l'arrivée sur un autre capteur. Il existe un processus de déplacement pour chaque déplacement possible entre 2 capteurs. De cette façon, sur l'exemple précédent (Figure 1.6), on s'assure (en ayant choisi correctement l'état des sorties nécessaires à un déplacement de CW1 vers CA1) que la transition t4, sensibilisée lorsque la place entre CW1 et CA1 est marquée, représente bien le fait que sur le système réel l'AGV pourra évoluer vers le capteur CA1. Sur le modèle de procédé, nous avons ajouté des transitions permettant d'exécuter un déplacement depuis un capteur (voir Figure 1.8). Sur la Figure 1.7 sont représentés les 2 processus correspondants à un déplacement de W1 vers A1 (représenté par la place p_mv_W1A1) et à un déplacement de A1 vers W1 (représenté par la place p_mv_A1W1). Prenons l'exemple où l'AGV se trouve à l'arrêt sur le capteur CA1. Si cet AGV reçoit l'ordre de se deplacer vers CW1 (symbolisé par le tir de la transition t_mv_A1W1 associée à cette contrainte de déplacement). La ressource partagée p_arret est consommée, les sorties nécessaires à ce déplacement sont activées et l'AGV se met en déplacement. Lorsque l'AGV arrive sur CW1 alors la transition 13
  14. 14. t_out_A1W1 est franchie, rendant la ressource partagée et l'AGV se met éventuellement à l'arrêt (où il se remet immédiatement en déplacement si une autre contrainte de déplacement est lancée, puisque le temps de franchissement d'une transition tirée du modèle est supposé de durée innitésimale dans le formalisme que nous utilisons). 14
  15. 15. Chapitre 2 Spécication - pilotage sûr Figure 2.1 Architecture de la solution envisagée Le modèle superviseur qui a pour rôle d'eectuer de la supervision de contrôle du modèle du procédé, est un modèle RdP tel que : l'ensemble des transitions est un sous-ensemble des transitions du modèle du procédé, l'ensemble des places est un ensemble disjoint de l'ensemble des places du procédé. Rappel : le superviseur (de contrôle) est le processus qui applique la supervision de contrôle. Le modèle supervisé obtenu par fusion de transitions du modèle du procédé et du modèle superviseur est donc un modèle RdP dont l'ensemble des transitions est égal à l'ensemble des transi- tions du modèle du procédé : le modèle supervisé n'a donc pas de comportements ajoutés par rapport au modèle du procédé. Au contraire, certains comportements sont limités puisque des arcs entrants sont ajoutés à certaines transitions du modèle du procédé après la fusion des 2 modèles. Nous avons déni 2 spécications principales que doit assurer le modèle superviseur : 1. Spécication de non-collision : il ne doit pas y avoir de collision possible entre les diérents AGV. Cette spécication permet de garantir un fonctionnement sûr. 2. Spécication de non-blocage : les AGV doivent toujours pouvoir se déplacer, c'est à dire qu'il ne doit pas y avoir de situation d'inter-blocage entre 2 AGV. Cette spécication fait partie, entre autres, des caractéristiques du fonctionnement désiré. 15
  16. 16. 2.1 Spécication de non-collision La position d'un AGV n'est connue que lorsque celui-ci se trouve sur un capteur. La structure du réseau du procédé est telle qu'il ne peut pas y avoir de collision si un AGV se déplace d'un capteur c1 qu'il occupe à un autre capteur c2 inoccupé et qu'aucun autre AGV ne réalise simultanément un déplacement qui concerne ces 2 capteurs. La spécication de non-collision est donc garantie en associant une place de ressource unique à chaque place de position sur capteur. Cette place (ressource) est démarquée (allouée) lorsqu'un AGV eectue un déplacement vers le capteur associé. Elle est ensuite marquée (rendue) dès que ce même AGV atteint un autre capteur. Figure 2.2 Ressource associée à la position sur terminal W1 La position d'un AGV sur un terminal, est représenté par les places p_Wi pour le terminal Wi correspondant, correspond au cas le plus simple. Il n'est possible d'atteindre/quitter p_Wi qu'à partir d'un capteur. La gure 2.2 représente la ressource associée au terminal W1. Le positionnement des capteurs et la structure du réseau du procédé nous montre que cette place n'est accessible que par un déplacement de A1 vers W1 : la ressource est donc allouée lors du tir de la transition t_mv_A1W1. Le seul déplacement autorisé pour quitter W1 est un déplacement de W1 vers A1 : on rend donc la ressource lorsque l'AGV atteint le capteur A1 par un déplacement depuis W1, ce qui correspond au franchissement de la transition t_out_W1A1. Figure 2.3 Ressource associée au capteur A1 Les positions sur capteur des intersections A, B et C sont des positions admettants chacunes 3 capteurs adjacents potentiels de départ/destination. Les positions sur capteur de l'intersection D ad- mettent chacune 4 capteurs adjacents potentiels de départ/destination. En appliquant un raisonnement similaire au cas des positions sur terminal précédent, on obtient les gures 2.3 et 2.4. 2.2 Spécication de non-blocage Pour empêcher une situation de blocage d'AGV, il faut s'assurer que le modèle du procédé est vivant. Pour forcer la vivacité d'un modèle RdP avec une supervision de contrôle, lorsque cela est pos- sible, il existe des méthodes de synthèses automatiques basées sur les invariants linéaires de places[13] et/ou sur les pièges/siphons[14]. Dans notre cas, le modèle du procédé contraint par la spécication de non-collision est relativement simple : nous avons donc synthétiser manuellement le modèle permettant 16
  17. 17. Figure 2.4 Ressource associée au capteur D1 d'assurer sa vivacité en analysant les situations conduisants à une impasse et en les prévenants par l'ajout de ressources. En eet, suite à la mise en place de la spécication de non-collision, il est apparu la possibilité d'inter-blocage entre 2 AGV (ou plus) sur diérentes parties du réseau : le modèle contraint par la spé- cication de non-collision est devenu non-vivant. Nous allons analyser les situations d'inter-blocage pour 2 AGV puis pour 3 AGV et proposer dans chaque cas une solution, basée sur la mise en place de ressources, pour prévenir ces blocages. Inter-blocage entre 2 AGV : Un inter-blocage entre 2 AGV peut avoir lieu en toute partie du réseau sauf sur les intersections. En eet, si 2 AGV se dirigent vers une intersection, l'un des 2 pourra toujours emprunter la troisième voie non utilisée pour continuer son déplacement. En revanche, si un AGV est présent dans la boucle d'une gare (par exemple) et qu'un autre AGV se dirige vers cette gare (à partir d'un déplacement depuis le capteur CA2 ou CA3 par exemple si on considère la gare W1), alors il y aura inévitablement blocage puisque les 2 AGV ne peuvent qu'avancer et qu'ils ne peuvent s'éviter. Ainsi, un seul AGV ne peut être présent simultanément dans les lieux du réseau déni sur la Figure 2.5. Par exemple, pour éviter le blocage de 2 AGV sur le tronçon entre les capteurs de positions CA2 et CB1, on met en place une ressource partagée (ici appellée p_nbloc_A2B1). 17
  18. 18. Figure 2.5 Ressources partagées dans le réseau pour le non-blocage de 2 AGV Figure 2.6 Ressource associée à la portion du réseau de la gare W1 pouvant entraîner un blocage entre 2 AGV Cette ressource sera consommée : si un AGV veut se déplacer de CA1 vers CA2 si un AGV veut se déplacer de CA3 vers CA2 si un AGV veut se déplacer de CB3 vers CB1 si un AGV veut se déplacer de CB2 vers CB1 Cette ressource sera relachée lorsque l'AGV arrivera sur le capteur CA1, CA3, CB3, ou CB2. Inter-blocage entre 3 AGV : Nous avons ensuite analysé les lieux où un inter-blocage avec 3 AGV peut se produire et nous avons associé une ressource partagée autorisant 2 AGV en ces lieux (voir Figure 2.7) pour empêcher de tels blocages. Par exemple, un jeton de la ressource partagée appelée p_nbloc_B, en charge du non-blocage au niveau du lieu de l'intersection B, sera consommé : si un AGV veut se déplacer de CA1 vers CA2 si un AGV veut se déplacer de CA3 vers CA2 si un AGV veut se déplacer de CC2 vers CC1 si un AGV veut se déplacer de CC3 vers CC1 si un AGV veut se déplacer de CD1 vers CD2 si un AGV veut se déplacer de CD4 vers CD2 si un AGV veut se déplacer de CD3 vers CD2 18
  19. 19. Figure 2.7 Lieux du réseau où peuvent apparaître une situation d'inter-blocage entre 3 AGV Figure 2.8 Ressources associées aux lieux présentés Figure 2.7 pour prévenir les situations d'inter- blocage entre 3 AGV Un jeton de cette ressource sera relaché lorsque un AGV arrivera sur le capteur CA1, CA3, CC3, CC2, CD3, CD1 ou CD4. 2.3 Modèle supervisé Nous avons dans un premier temps réalisé un modèle supervisé que nous appelons modèle super- visé global . Dans ce modèle supervisé, les AGV ne sont pas diérenciés : il est possible de connaître la position des AGV (représentés par des jetons) mais il n'est pas possible de savoir de quel AGV en particulier il s'agit (puisque les jetons sont indiérenciés). Ce modèle supervisé global (Figure A.6) est obtenu en faisant la fusion des modèles suivant : modèle du procédé de position des 3 AGV (Figure A.1), modèle de contrainte de processus de déplacement (Figure A.2), modèle de spécication de non-collision (Figure A.3), modèle de spécication de non-blocage pour 2 AGV (Figure A.4), 19
  20. 20. modèle de spécication de non-blocage pour 3 AGV (Figure A.5). Pour réaliser cette fusion il sut sous TINA de charger un des modèles à fusionner, puis de cliquer sur File/include/as is et de choisir le modèle à fusionner : les transitions portant le même nom sont alors fusionnées ensemble (remarque : il faut s'assurer que les places portent un nom diérent dans les 2 modèles, sinon elles sont aussi fusionnées entre elles). Une analyse structurelle par TINA nous indique que le modèle obtenu est borné, vivant et ré- initialisable. Ce modèle obtenu pose plusieurs problèmes : 1. il n'est pas possible de diérencier les AGV, qui sont représentés par des jetons, car nous n'utilisons pas le formalisme des RdP colorés et donc les jetons sont indiérenciables. Autrement dit, il est possible de connaître la position des AGV mais on ne peut savoir (sauf cas particulier où les 3 AGV se trouvent au même endroit) où se trouve l'AGV n°1, l'AGV n°2 et/ou l'AGV n°3. 2. comme il ne peut y avoir qu'une seule instance d'un processus de déplacement pour les 3 AGV, le modèle n'autorise que le déplacement d'un AGV à la fois. Or nous souhaitons permettre le déplacement simultané de plusieurs AGV ! Pour résoudre ce problème, nous devons donc diérencier les AGV par un modèle RdP de position diérenciée pour chaque AGV, qui représentera la position de l'AGV concerné ainsi qu'un processus de déplacement associé. Un modèle RdP de position globale (car les spécications de non-blocage et de non-collision font appel à cette information) supervisé représentera toujours la position globale des AGV (indiérenciés) en assurant les spécications pré-citées. 3 modèles supplémentaires de position diérenciée , basés sur le modèle de procédé de position, représenterons chacun la position d'un AGV et seront synchronisés avec le modèle de procédé de position globale supervisé. Nous utiliserons un script .tpn via Tina pour eectuer les opérations suivantes sur ces modèles : merge : l'opération merge permettra d'assembler les 3 modèles de position diérenciée sync : l'opération sync (ou synchronize ) permettra de synchroniser les évolutions des 3 modèles de position diérenciée (préalablement assemblés) avec le modèle de position globale . Pour eectuer ces opérations, il a été nécessaire de labeller ( étiqueter ) les transitions des modèles .ndr réalisés (les transitions de diérents modèles ayant un même label sont synchronisées entre elles). Nous allons illustrer cette étape pour un exemple simple, avec le script .tpn suivant : load pos_1 . ndr load pos_2 . ndr load pos_3 . ndr merge 3 load pos_global . ndr sync 2 On charge ici 3 modèles de positions diérenciées (nommés pos_1.ndr, pos_2.ndr et pos_3.ndr), puis on les assemble avec l'opération merge 3 qui aura pour eet d'assembler les 3 derniers modèles chargés en mémoire. On charge ensuite le modèle de position globale (nommé pos_global.ndr), puis la commande sync 2 va synchroniser les 2 derniers modèles chargés en mémoire, c'est à dire le modèle de position globale et le modèle assemblé obtenu précédemment. Les chiers pos_X.ndr avec X ∈ {1, 2, 3}représentent les modèles de positions diérenciées pour l'AGV X. Le modèle pos_global.ndr représente la position globale des 3 AGV. 20
  21. 21. Figure 2.9 Modèle nal de l'exemple obtenu après exécution du script .tpn et repositionnement manuel des éléments du réseau Modèle pos_1.ndr Modèle pos_2.ndr Modèle pos_3.ndr Modèle pos_global.ndr Remarques : les noms des places et transitions sont sans importance car la synchronisation s'eectue grâce aux labels uniquement, il faut s'assurer que les marquages initiaux des modèles de positions diérenciées soient cohérents avec le marquage initial du modèle de position globale ! On charge alors le script .tpn sous TINA (en l'ouvrant directement avec TINA ou en utilisant File / import / net from tpn depuis l'application si elle est déjà lancée) : le script est exécuté et un nouveau modèle résultant de ces opérations est généré au format texte (chier .net). On transforme ce modèle textuel en modèle graphique avec edit / draw . Puis un repositionnement manuel des éléments du modèle obtenu nous donne le modèle graphique représenté sur la Figure 2.9. Nous avons appliqué cette solution à nos modèles réels et une analyse structurelle sous Tina nous permet de vérier que le modèle est borné, vivant et réinitialisable. Cette fois, puisque les AGV peuvent se déplacer simultanément, il existe 594306 marquages possibles. 21
  22. 22. Chapitre 3 Planication de trajectoires - pilotage optimal 3.1 Planication de trajectoires Rappel : le planicateur est un processus générant un plan c'est à dire une séquence de tran- sitions contrôlables à tirer tout en respectant un coût et une mission à partir d'un état initial. Figure 3.1 Entrées/Sortie du bloc Planicateur Notre planicateur prend en entrée : un modèle RdP au format .ndr un chier .txt décrivant une mission pour chaque AGV un chier .txt décrivant les coût associés à chacune des transitions du modèle RdP supervisé Notre planicateur génère un plan en sortie, dans notre cas ce plan est un chier .scn à charger dans le Stepper Simulator de TINA. Pour calculer le plan, nous devons implémenter un algorithme permettant d'explorer les états pos- sibles du modèle du procédé supervisé simplié (dénie dans le chapitre précédent 2.4) pour trouver une trajectoire optimale. Pour cela, nous devons récupérer les informations nécessaires du chier .ndr permettant de générer notre graphe des marquages accessibles. La recherche d'un plan par l'exploration du graphe des marquages accessibles peut avoir un coût important en calculs et en mémoire. Pour réduire ce coût en mémoire nous avons simplié notre modèle RdP supervisé. La Figure 3.2 montre le modèle de position seul (sans processus de déplacement ni spécication quelconque) et la Figure 3.3 montre le modèle de position seul simplié. Les transitions non contrôlables sont sans intérêt pour le planicateur : en eet, le planicateur n'a et ne doit avoir aucune action sur ces transitions. 22
  23. 23. Figure 3.2 Modèle de position seul Figure 3.3 Partie Modèle de position après simplication De même, la transition t_mv_A1W1 est sans intérêt pour le planicateur car nous admettons que l'objectif des AGV est de desservir des terminaux : on fait donc l'hypothèse que la mission qui leur sera demandé sera de passer et de s'arrêter sur un ou plusieurs terminaux. Il est donc inutile pour le planicateur d'exiger un arrêt sur un capteur autre qu'un capteur sur un terminal (remarque : cet arrêt sera toutefois possible pendant l'application d'un plan). En revanche, les transitions t_mv_A1A3 et t_mv_A1A2 sont contrôlables, en conit struc- turel et eectif, ce qui fait qu'elles représentent un choix d'évolution à eectuer par le planicateur. Ces transitions seront donc nécessaires au planicateur pour calculer le plan. De plus, lorsqu'un processus de déplacement est lancé, l'AGV va se mettre en déplacement jusqu'à arriver à sa destination. Au niveau du planicateur, on peut donc faire abstraction de toutes les étapes intermédiaires pendant le déplacement. Cette fois, le modèle de contrainte de processus de déplacement n'est donc plus nécessaire. Une partie du réseau de position simplié autour de la gare W1 est représentée Figure 3.3. Nous avons dû recréer les modèles de spécications de non-collision et de non-blocage (pour correspondre aux nouvelles transitions), puis fusionner ces modèles avec le modèle de procédé de po- sition simplié an d'obtenir un modèle de position globale supervisé simplié (Figure B.2). Un script .tpn identique au précédent permet alors d'obtenir le modèle de procédé supervisé sim- plié, qui sera le modèle RdP envoyé au planicateur. Une vérication structurelle de ce modèle sous TINA nous assure qu'il est borné, vivant et réinitialisable. Ce nouveau modèle de procédé super- visé simplié comporte 2544 états possibles (rappel : le modèle de procédé supervisé en comporte 594306). 23
  24. 24. 3.2 Mission et coûts La mission à remplir est un aller-retour de chaque AGV entre un terminal de départ et un termi- nal de destination prédéterminé arbitrairement. Les terminaux de départ et de destination associés à chaque AGV sont dénis ainsi : AGV Terminal de départ Terminal de destination 1 W1 W2 2 W2 W1 3 W3 W1 La mission est donc constituée de 3 séquences d'objectifs à remplir. Chaque séquence d'objectifs est associée à 1 AGV, et elle est composée de 2 objectifs (places) à atteindre (marquer) : Wx et Wy, qui correspondent respectivement au terminal de destination et au terminal de départ de l'AGV concerné. Séquence d'objectif Objectif n°1 Objectif n°2 agv n°1 W2 W1 agv n°2 W1 W2 agv n°3 W1 W3 Une illustration de cette mission est représentée Figure 3.4. Figure 3.4 Illustration de la mission à eectuer L'objectif du planicateur est de trouver un plan p permettant de remplir une mission m en mini- misant le coût total J, obtenu par le tir de l'ensemble des transitions de la séquence du plan. Si le coût J associé au plan p est minimal parmi tout les plans permettant de satisfaire la mission considérée, alors on dit alors que le plan p est optimal. Sur la Figure 3.5, nous avons représenté un exemple simple de modèle avec un coût par défaut pour le tir d'une transition de 1, excepté pour les transitions t9 et t5 dont les coûts associés sont respec- tivement 10 et 4. Ces coûts représentent une estimation de la distance à parcourir : plus la distance parcourue est grande, plus le coût est important. La mission consiste à marquer la place p2 puis la place p0. 2 plans sont calculés pour cette mission : Le plan en orange, qui est obtenu sans prise en compte des coûts et qui minimise la taille de la séquence du plan, i.e. le nombre minimal de transitions. La séquence obtenue composé de 3 transitions : t1, t2, t9. Ce plan présente un coût total de 1 + 1 + 10 = 12, 24
  25. 25. Figure 3.5 Comparaison d'un plan optimal (en vert) et d'un plan non-optimal (en orange) Le plan en vert, lui, est obtenu en tenant compte des coûts associés aux transitions tirées. Il comporte une séquence de plus grande taille et composé de 5 transitions : t1, t2, t16, t10, t0. Ce plan présente un coût total de 1 + 1 + 1 + 1 + 1 = 5. Si l'on souhaite minimiser la distance parcourue pour remplir la mission, il sut de minimiser le coût (puisqu'il correspond à la distance parcourue). On constate eectivement visuellement que le plan en vert est optimal en ce critère, puisqu'il minimise le coût total : il représente donc la trajectoire la plus courte remplissant la mission demandée. 3.3 Algorithme de recherche d'un plan optimal La recherche d'un plan optimal s'eectue en 2 étapes : dans un premier temps, on explore tout le GMA et on met à jour les meilleurs coûts obtenus (en tenant compte de l'état de la mission). A chaque fois que le meilleur coût d'un état est mis à jour, on devra le réexplorer. Nous allons décrire le fonctionnement de l'algorithme 3.1 par un exemple concret, illustré Figure 3.6. Ici, la mission à remplir est constituée d'une seule séquence de 2 objectifs : le marquage des états 2 et 5. L'exploration commence par l'état initial 0. A partir de cet état il existe 2 évènements permettant d'atteindre les états 1 et 3. Comme le coût de ces évènements n'est pas spécié, il vaut 1 par défaut. Les nouveaux états 1 et 3 auront donc un coût de (coût courant + coût de l'évènement) soit 0 + 1 = 1. Dans les 2 cas, aucun objectif de la mission n'est rempli puisqu'ici il n'y a qu'une seule séquence d'objectifs et que le prochain objectif à remplir est le marquage de l'état 2. Comme il n'existait aucun coût pour ces états et ce statut de mission, il 25
  26. 26. Algorithm 3.1 algorithme de recherche d'un plan optimal ajouter(liste : liste_etats_a_explorer, etat : etat_initial, cout : 0) while liste_etats_a_explorer non vide do [etat_courant, cout_courant] ← choisir_etat(liste_etats_a_explorer) for all evenement de etat_courant do [nouvel_etat, nouveau_cout] ← etat_suivant(etat : etat_courant, cout : cout_courant, eve- nement : evenement) nouvel_etat_mission ← calculer_mission(etat : nouvel_etat) if nouvel_etat_mission = accomplie then etat_final ← nouvel_etat end if if cout_minimal(etat : nouvel_etat) nouveau_cout ou non deni) then nouveau_cout_minimal(etat : nouvel_etat, cout : nouveau_cout) remplacer_etat_precedent(etat : nouvel_etat, etat_precedent : etat_courant) if nouveletat_mission = accomplie then ajouter(liste : liste_etats_a_explorer, etat : nouvel_etat, cout : nouveau_cout) end if end if end for end while Figure 3.6 Graphe représentant une exploration terminée des états d'un GMA faudra les explorer. Nous devons ensuite choisir un nouvel état à explorer. Considérons l'état 3 parmi la liste des états à explorer {1, 3}. L'application de l'algorithme nous donne cette fois les nouveaux états suivants : nouvel état : 2, nouveau coût : 1+1=2, nouveau statut mission : [5] (car l'état 2 est cette fois marquée), états à explorer : {1, 2} nouvel état : 4, nouveau coût : 1+1=2, nouveau statut mission : [2,5], états à explorer : {1, 2, 4} nouvel état : 5, nouveau coût : 1+1=2, nouveau statut mission : [2,5] (car l'objectif du mar- quage de l'état 5 n'est pas encore vérié : ce n'est pas le prochain objectif à atteindre), états à explorer : {1, 2, 4, 5} Si on considère à présent l'exploration de l'état 2 parmi la liste {1, 2, 4, 5} : nouvel état : 4, nouveau coût : 2+1=3, nouveau statut mission : [5], états à explorer : {1, 4, 5} L'exploration de l'état 4 parmi la liste {1, 4, 5} donnerait : nouvel état : 5, nouveau coût : 3+1=4, nouveau statut mission : [.] (mission accomplie !), états à explorer : {1, 5} 26
  27. 27. Après l'exploration des états 1 (qui ne donnerait aucune mise à jour des meilleurs coûts) et 5 (qui n'a aucun évènement), l'algorithme a terminé son exploration. Il faut à présent retrouver le meilleur chemin. Pour cela, nous avons ajouté une étape : à chaque fois qu'un nouvel état est atteint avec un coût minimal, nous enregistrons l'état qui conduit à cet état (i.e. l'état précédent). Ainsi, connaissant l'état nal ou la mission est accomplie, et les états précédents qui ont conduits à ce meilleur coût , on peut remonte le chemin en sens inverse : ici, l'état précédent l'état 5 est l'état 4, l'état précédent l'état 4 est l'état 2, etc. d'où la séquence 5,4,2,3,0. En inversant la séquence, on retrouve la séquence du plan optimal qui permet d'accomplir la mission avec un coût minimal. Remarque : en réalité, les objectifs ne sont pas directement validés par l'état du GMA mais par le marquage correspondant à l'état du GMA. Il faut donc, lors de la mise en oeuvre, faire cette relation pour calculer le nouvel état de la mission à chaque état du GMA exploré. 27
  28. 28. Chapitre 4 Mise en oeuvre de la solution globale Les modèles RdP sont déjà réalisés sous Tina. Pour mettre en oeuvre la solution globale, nous avons besoin d'eectuer les opérations suivantes : 1. lecture du chier .ndr du modèle du procédé supervisé simplié, du chier décrivant la mission à remplir et, éventuellement, d'un chier décrivant les coûts des transitions (par défaut, les transitions dont le coût n'est pas spécié ont un coût de 1 : s'il n'y a pas de chier, toutes les transitions ont donc un coût de 1). 2. sauvegarder les données en mémoire (RdP, mission, coûts associés aux transitions), 3. générer à partir du RdP le GMA correspondant, 4. appliquer l'algorithme de planication sur le GMA, 5. générer une séquence de transitions franchies (séquence de noms de transitions pour exécuter le plan sur le modèle supervisé simplié, ou séquence des labels de transitions pour exécuter le plan sur le modèle de position globale simplié). En chargeant le chier séquence .scn obtenu dans le simulateur pas à pas de TINA, nous pouvons alors visualiser l'exécution du plan obtenu. 4.1 Lecture/écriture de chiers .ndr Le format des chiers des modèles RdP que nous avons généré sous TINA est le format .ndr. Un extrait de la spécication de ce format est représenté Figure 4.1. 28
  29. 29. Figure 4.1 Spécication du format .ndr Pour segmenter les informations contenues dans chaque ligne, nous utiliserons des masques d'expres- sions régulières avec la librairie standard Java. Nous avons utilisé l'utilitaire Regex Match Tracer pour nous aider à mettre au point ces expressions, qui nous a permis de tester et valider les masques mis au point à l'aide de lignes tests (cf. ), mais également de générer automatiquement le code Java cor- respondant à ces masques. Les masques d'expressions régulières font appel à des groupes nommés , ce qui permet d'accéder facilement aux données. Par exemple, dans le cas de la gure 4.2 : le groupe node1 contient le nom du premier noeud, le groupe ang1 contient l'angle de l'arc du premier noeud etc. Il sut alors de tester chaque masque pour chaque ligne et de vérier si celle-ci correspond lui cor- respond. On peut alors savoir de quel type de ligne il s'agit et générer l'objet correspondant (place, transition, arc) avec les informations extraites. 29
  30. 30. Figure 4.2 Mise au point et test des masques d'expression régulières, ici un des 2 masques pour parser une ligne de type edgedesc Nous avons mis en place un parseur de chier .ndr (chier TINA). Suite à celà nous avons mis en oeuvre un algorithme permettant de planier une trajectoire optimale. 4.2 Transformation du modèle RdP - GMA Fact 4.1. le modèle RdP dont nous souhaitons générer le GMA est borné Pour transformer le modèle RdP en GMA, nous appliquons l'algorithme suivant : Algorithm 4.1 génération du GMA d'un modèle RdP ajouter marquage_initial dans la liste marquages_a_explorer while marquages_a_explorer non vide do marquage_courant ← choisir_et_supprimer_un_marquage(marquages_a_explorer) liste_transitions ← transitions_sensibilisees(marquage_courant) for all transition dans liste_transitions do nouveau_marquage ← tir_transition(transition,marquage_courant) if nouveau_marquage n'existe pas dans le GMA then ajouter nouveau_marquage dans le GMA ajouter nouveau_marquage dans la liste marquages_a_explorer end if end for end while 4.3 Analyse des performances et optimisations La solution que nous avions mis en oeuvre mettait environ 30 secondes pour trouver un plan sur le modèle du RdP supervisé simplié. Ce temps nous paraîssait anormalement long, nous avons donc décidé d'utiliser le proler de l'IDE Netbeans, un outil permettant de réaliser une analyse des performances d'un programme ( benchmarking en anglais). Une analyse des performances liées au CPU pour la recherche d'un plan sur le modèle RdP simplié est illustré sur la Figure 4.3. Sur cette analyse, nous pouvons constater un point chaud ( hotspot ), c'est à dire une méthode qui utilise la majeure partie des ressources CPU : il s'agit de la méthode de test d'égalité entre 2 objets MissionMarking : MissionMarking.equals(Object). Cet objet stocke les informations sur le statut de la mission et un marquage RdP. Il est nécessaire pour vérier, lors d'une exploration sur les états du GMA, si les places sont marquées (pour calculer le nouvel état de la mission), et pour savoir si le nouveau coût obtenu pour le nouveau marquage et le nouveau statut de mission est meilleur que ceux précédemment obtenus. 30
  31. 31. Figure 4.3 Benchmarking de notre solution sur la recherche d'un plan sur le modèle RdP simplié avant optimisation Figure 4.4 Benchmarking de notre solution sur la recherche d'un plan sur le modèle RdP simplié après correction de bugs et les diverses optimisations Nous avons alors mis en place des UnitTests (tests d'intégration) sur le test d'égalité de cet objets, qui fait lui-même appel à des tests d'égalité sur les objets Mission, SubMission, et Marking. Après diverses modications du code, nous avons résolu le problème. Nous avons également réalisé par la suite diverses optimisations, comme la mise en cache du calcul des valeurs de hashage pour les objets dont cette méthode est le plus souvent invoquée, ce qui nous a permis d'obtenir les nouvelles performances Figure 4.4. Cette fois, le nombre d'invocations de la méthode MissionMarking.equals(Object) passe de 150M à 1M, ce qui montre que le problème à été corrigé. Les temps de calculs sont passés (lors d'une analyse de performances), de 50.6 à 2.7 secondes, ce qui est bien plus raisonnable. Cette analyse nous permet aussi de constater qu'il serait complètement inutile d'essayer d'optimiser le code des méthodes MarkingGraph.State.equals(Object) (0.5% d'utilisation CPU), Marking- Graph.Mission.isDone() (1.2%) etc. A contrario, on voit immédiatement que la méthode MarkingGraph.Mission.checkObjectives (tinaparser.PN.PNMarking) utilise un temps considérable (58,4%). Il serait donc judicieux d'optimiser cette méthode ou les méthodes auxquelles elle fait appel! Nous avons aussi aché quelques statistiques pour analyser cette fois les performances de l'algo- rithme : FSM with 2544 states generated in 235.158729 ms. Mission : agv1= *{p_W2.1.1}* − {p_W1. 1 . 1 } ; agv2= *{p_W1.2.1}* − {p_W2. 2 . 1 } ; agv3= *{p_W1.3.1}* − {p_W3. 3 . 1 } ; States : 50083 Iterations : 222534 31
  32. 32. Retries : 66292 Ici, on constate que pour la mission considérée, il existe 50083 états diérents possibles à explorer. L'algorithme a calculé inutilement environ 222000 − 50000 = 172000 états. Cela est dû au fait que parfois, l'algorithme explore un autre chemin et obtient un état déjà exploré avec un meilleur coût, ce qui l'oblige à explorer de nouveau cet état et généralement les états accessibles à partir de cet état. Il est donc potentiellement possible d'augmenter les performances de la recherche du plan optimal en diminuant les explorations inecaces, ce qui peut être fait en utilisant des algorithmes plus sophistiqués, faisant appel à la notion d' heuristique . 4.4 Résultats obtenus A la sortie de notre planicateur, nous obtenons un chier .scn donnant la liste des transitions controlables à franchir qui respecte à la fois la mission et les coûts attribués à notre modèle RdP supervisé simplié, grâce à la solution d'exploration du GMA mis en oeuvre au dessus. Le chier récuperé en sortie, que nous avons appelé global.scn , contient la séquence de transitions suivantes : t_mv_W3D4 t_mv_W2C2 t_mv_C2C3 t_mv_D4D1 t_mv_W1A1 t_mv_A1A2 t_mv_B1B2 t_mv_A3A1 t_mv_W1A1 t_mv_A1A3 t_mv_D1D4 t_mv_D3D1 t_mv_A3A1 t_mv_W1A1 t_mv_A1A2 t_mv_C1C2 t_mv_W2C2 t_mv_C2C3 t_mv_D3D1 t_mv_A3A1 t_mv_B1B2 t_mv_C1C2 Voici un tableau récapitulatif et une illlustration Figure 4.5 an de mieux comprendre les trajec- toires suivis par nos AGV avec cette planication : AGV Transition t_mv N° du déplacement Postion de départ Position d'arrivée Rouge t_mv_W3D4 1 W3 D4 Bleu t_mv_W2C2 2 W2 C2 Bleu t_mv_C2C3 3 C2 D3 Rouge t_mv_D4D1 4 D4 A3 Vert t_mv_W1A1 5 W1 A1 Vert t_mv_A1A2 6.1 A1 B1 Vert t_mv_B1B2 6.2 B1 C1 Rouge t_mv_A3A1 7 A3 W1 Rouge t_mv_W1A1 8.1 W1 A1 Rouge t_mv_A1A3 8.2 A1 D1 Rouge t_mv_D1D4 8.3 D1 W3 Bleu t_mv_D3D1 9.1 D3 A3 Bleu t_mv_A3A1 9.2 A3 W1 Bleu t_mv_W1A1 10.1 W1 A1 Bleu t_mv_A1A2 10.2 A1 B1 Vert t_mv_C1C2 11 C1 W2 Vert t_mv_W2C2 12.1 W2 C2 Vert t_mv_C2C3 12.2 C2 D3 Vert t_mv_D3D1 12.3 D3 A3 Vert t_mv_A3A1 12.4 A3 W1 Bleu t_mv_B1B2 13.1 B1 C1 Bleu t_mv_C1C2 13.2 C1 W2 On remarque que certaines transitions contrôlables, comme par exemple t_mv_A3A1 que l'on peut traduire par transition de déplacement de A3 vers A1 , ont une position d'arrivée diérente de A1 dans le modèle de position global simplié. Cela est dû au fait que l'AGV va continuer tout droit tant qu'il ne passera pas sur un terminal ou une position pour laquelle il doit choisir une direction parmi plusieurs. En eet, lors de la simplication du modèle, comme cela est mentionné dans la partie 2.4, nous faisons abstraction de certaines transitions sans utilité pour le planicateur. 32
  33. 33. Figure 4.5 Illustration des déplacements des diérents AGV avec la planication obtenue Nous avons également mis une vidéo permettant de mieux visualiser l'évolution du modèle du procédé de position global simplié l'url suivante : https://youtu.be/EWUxkvHT8CA 33
  34. 34. Conclusion Ce projet a été très enrichissant car il nous a permis d'approfondir nos connaissances en Systèmes à Évènements Discrets (plus précisement en Réseau de Petri), mais également en programmation en langage Java et en planication algorithmique. De plus il nous a permis d'explorer plusieurs idées an de mettre en oeuvre notre solution et de mettre à prot les qualités de chaque membre du groupe. Ce que nous avons particulièrement apprécié dans notre projet, c'est que bien que nous ayons été encadrés par deux enseignantes chercheuses, nous avions un degré de liberté assez important dans le choix de nos solutions pour mener à bien notre projet (par exemple nous avons pu décider du langage de programmation pour mettre en oeuvre notre planication, de l'algorithme utilisé : la liste n'est pas exhaustive !). Au cours de ce projet, nous avons eu également la chance de rencontrer à deux reprises l'équipe VERTICS du LAAS, qui sont les développeurs du logiciel TINA. Il nous ont renseignés sur le fonc- tionnement du format .tpn qui nous a permis d'obtenir un modèle RdP permettant de diérencier la position de chaque AGV sans se tourner vers le formalisme des RdP colorés. Ce projet pourrait être continué en mettant en place d'autres types d'algorithmes an de comparer les performances obtenues pour chacun d'eux. On pourrait également envisager de réaliser un Step- per Simulator , permettant de visualiser directement la solution obtenue sur une interface graphique indiquant précisément la position de chaque AGV et leur direction (par exemple), ou tout autre type d'information qui pourrait être utile. On pourrait également envisager une application permettant de gérer un projet composé plu- sieurs RdP et générant automatiquement un script .tpn. Cette application pourrait également gérer la concordance des marquages initiaux des diérents modèles RdP pour envisager des diérentes pos- sibilités de marquage initial, permettant de tester les solutions obtenues sur diérents cas de façon éventuellement automatique! Dans l'ensemble, ce projet a été pour notre groupe un dé passionnant et captivant, dont nous avons rempli la totalité des objectifs que nous nous étions xés. 34
  35. 35. Bibliographie [1] Yoann Arnaud, Jose Cury, J.J. Loiseau, and Claude Martinez. Pilotage sûr et optimal d'une otte de vehicules autoguidés. mar 2009. [2] Maen Atli. Contributions à la synthèse de commande des systèmes à évènements discrets : nouvelle modélisation des états interdits et application à un atelier exible. PhD thesis, sep 2012. France. [3] Francesco Basile, Roberto Cordone, and Luigi Piroddi. A branch and bound approach for the design of decentralized supervisors in petri net models. jan 2015. Milan, Italie. [4] Bernard Berthomieu. Tina. http://projects.laas.fr/tina/, 2016 (accédé le 26 Mai, 2016). [5] Elodie Chanthery. Planication de mission pour un véhicule aérien autonome. PhD thesis, sep 2007. Toulouse, France. [6] Elodie Chanthery and Yannick Pencolé. Modélisation et intégration du diagnostic actif dans une architecture embarquée. 2009. Toulouse, France. [7] YuFeng Chen, ZhiWu Li, and Abdulrahman Al-Ahmari. Nonpure petri net supervisors for optimal deadlock control of exible manufacturing systems. mar 2013. [8] José-Manuel Colom. Transformation of petri nets. may 2012. Barcelone, Espagne. [9] Sidi Mohamed Douiri, Souad Elbernoussi, and Halima Lakhbab. Cours des méthodes de résolution exactes heuristiques et métaheuristiques. Technical report, Universite Mohammed V, Faculte des Sciences de Rabat. [10] Jean-Louis Ferrier. Commande par supervision : outils et synthèse. France. [11] Jan Friso Groote and Marc Voorhoeve. Operational semantics for petri net components. Theore- tical Computer Science, 379 :19, jun 2007. [12] Bo Huang, MengChu Zhou, and GongXuan Zhang. Synthesis of petri net supervisors for exible manufacturing system via redundant constraint elimination. aug 2015. Chine. [13] John O. Moody. Petri Net supervisors for discrete event systems. PhD thesis, Université de Notre Dame, apr 1998. [14] Faten Nabli, François Fages, Thierry Martinez, and Sylvain Soliman. A boolean model for enu- merating minimal siphons and traps in petri nets. In CP, 2012. [15] Milen Peev. Simple computer aided railway modeller. http://www.scarm.info/index.php, 2016 (accédé le 26 Mai, 2016). [16] Mustafa S.Durmus, Ugur Yildirim, and Mehmet T. Soylemez. Automatic generation of petri net supervisors for railway interlocking design. nov 2012. Sydney, Australie. [17] Fernando Tricas, José Manuel Colom, and Juan Julian Merelo. Using the incidence matrix in an evolutionary algorithm for computing minimal siphons in petri net models. oct 2014. Roumanie. [18] Rongming Zhu. A deadlock prevention approach for exible manufacturing systems with uncon- trollable transitions in their petri netmodels. feb 2011. Chine. 35
  36. 36. Annexe A Modèles RdP 36
  37. 37. Figure A.1 Modèle du procédé de position globale 37
  38. 38. Figure A.2 Modèle des contraintes de processus de déplacement 38
  39. 39. Figure A.3 Modèle de la spécication de non-collision Figure A.4 Modèle de la spécication de non-blocage pour 2 AGV Figure A.5 Modèle de la spécication de non-blocage pour 3 AGV 39
  40. 40. Figure A.6 Modèle de procédé supervisé 40
  41. 41. Annexe B Modèles RdP simpliés 41
  42. 42. Figure B.1 Modèle de procédé de position simplié Figure B.2 Modèle de procédé de position globale supervisé simplié 42

×