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. 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. 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
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. 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. 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. 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. 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. 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. 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. à 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
37. Figure A.1 Modèle du procédé de position globale
37
38. Figure A.2 Modèle des contraintes de processus de déplacement
38
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
