Upload
others
View
2
Download
0
Embed Size (px)
Citation preview
Implantation sur cible, L. Tromp, Saint Louis 2014-2015 Page 1
Implantation sur cible Arduino :
platine de feux d’un passage piétons
DU BESOIN CLIENT A LA COMMANDE
Le point de vue de départ est celui du besoin du client-vendeur ou celui du client utilisateur. Le langage
SysML permet de modéliser graphiquement ce besoin, exprimé ou anticipé, afin de mettre au point le
cahier des charges, support de la conception du ‘produit’. En effet, en tant que client soi-même, on peut
penser que la satisfaction s’exprime davantage comme résultat de la qualité de l’interaction, esthétique,
ergonomique et comportementale (cf le récent concept marketing d’‘expérience client’), que d’intelligence
de réalisation.
Le concepteur s’appuie sur ce que doit faire le produit spécifié en termes de consigne et de résultat attendu
dans les différentes phases de vie (échanges de messages, activités à mener, modes de fonctionnement à
gérer). La conception doit rendre transparente à l’utilisateur du produit le fonctionnement interne du
système, en articulant matière, énergie et information. Or, autant il y a un lien naturel et un cadre de
modélisation homogène entre les tâches opératives spécifiées et les actions opératives réalisées
(mécanique, électrique, thermique, etc.), autant il n’y en a pas avec les décisions séquentielles qui y
mènent. Imposer un résultat n’a jamais indiqué comment l’obtenir, ce sont deux compétences distinctes.
L’automaticien a pour premier objectif de spécifier la coordination des actions opératives et de
communication. Cette spécification est algorithmique et repose sur des modèles adaptés aux
comportements de commande: hiérarchie, séquencement, choix, priorités, parallélisme, synchronisation,
partage de ressource, etc. Il s’agit de coordonner les ordres, non les effets, de contrôler l’état interne de la
partie commande, non celui de la partie opérative.
L’implantation concrète sur un dispositif de pilotage s’appuie sur cette spécification, elle est d’ordre
informatique et électronique et nécessite l’élaboration d’un couple logiciel de modélisation-post-
processeur, ou bien la programmation directe comme présenté dans ce document.
POINTS DE VUE POUR L’ IMPLANTATION SUR CIBLE
Dans le contexte de l’implantation sur cible, on considèrera fixée l’architecture opérative. Il s’agit alors de
piloter les flux d’énergie délivrés aux actionneurs, dans le bon ordre, afin d’obtenir les effets prescrits sur
la matière d’œuvre dans les configurations recensées par le modèle SysML. L’automaticien spécifie
graphiquement, donc modélise, la coordination puis la gestion de l’activité des pré-actionneurs et des
dispositifs de communication.
Celle-ci est organisée en deux niveaux hiérarchiques :
la décision (ou commande) d’action, de nature binaire, considérée ici, puis...
le contrôle de l’intensité de cette action, de nature analogique ou numérique.
Les réseaux de Petri sont ici utilisés comme langage graphique de spécification-modélisation du
comportement de la PC. Dans l’objectif visé, il s’agira dans un second temps de traduire en équations puis
en lignes de code le comportement ainsi spécifié.
Compte tenu des travaux de l’équipe de Démosciences, la cible choisie est Arduino, et le langage est soit le
C utilisé pour le programmer directement, soit Python grâce au module py2duino. Le système utilisé
comme support est la maquette simulant les feux à un passage piétons. La démarche exposée se généralise
à d’autres cibles et d’autres langages, le modèle étant commun.
Implantation sur cible, L. Tromp, Saint Louis 2014-2015 Page 2
DONNEES DE DEPART
Les données de départ de l’automaticien sont les scénarios de fonctionnement, spécifiés au moins au niveau
de la matière d’œuvre et peut-être au niveau des effecteurs (car du côté du client) par le modèle SysML.
La démarche de l’automatique n’est comprise ni dans SysML car prescrire un objectif ne dit pas comment
l’atteindre ni dans les algorithmes standard de l’informatique (IPT notamment) car les concepts qui y sont
abordés ne sont du niveau de complexité ni du fonctionnement attendu (parallélisme d’activités
indépendantes, hiérarchie de processus, communication entre processus de même niveau) ni des réalités du
système piloté (répartition, multi-processeur, réactivité).
Les modèles pertinents ne sont compris ni dans SysML car les machines d’état montrent rapidement leurs
limites pour la modélisation de la commande de systèmes complexes (en premier lieu explosion du nombre
d’états de la PC à considérer, inefficacité dans le cadre de système de commande répartis), ni dans l’IPT
car une spécification efficace est graphique et non pas littérale. Les diagrammes d’activités de SysML ne
conviennent pas non plus pour des raisons scientifiques : depuis les années 1950, il a été établi (Moore et
Mealy dans un contexte informatique) que le cadre naturel de pensée des systèmes dynamiques de décision
décompose le fonctionnement interne en deux blocs : dynamique d’état et combinatoire des sorties1.
Modèles de systèmes à événements discrets dans l’approche moderne, ou d’état
Machine de Moore (1958) Machine de Mealy (1955)
Les sorties, ou ordres sont des fonctions combinatoires de l’état de la PC, donc en amont des actionneurs.
Les activités de SysML spécifient à l’opposé les effets à obtenir sur la PO ou sur la matière d’œuvre suite à
ces ordres, c’est-à-dire en aval des actionneurs. L’automaticien traduit donc une fin en moyens.
1 Il en est de même au automatique continue moderne (voir le document, ‘Les SED par une approche
d’état’ sur le site de l’UPSTI).
Sorties
yn
Etat
xn
Entrées
un
xn
yn
un
Implantation sur cible, L. Tromp, Saint Louis 2014-2015 Page 3
MOYENS A DISPOSITION
Lorsque le système à commander est simple (par exemple un seul actionneur ou bien fonctionnement
cyclique ne disposant que de peu de variantes), le modèle des machines d’état peut être satisfaisant car il
suffit bien souvent de suivre pas à pas le comportement prescrit de l’effecteur. Le nombre d’états de la PC
(défini ci-dessus) est du même ordre de grandeur que celui de la PO (qui est un concept plutôt vague au
demeurant, peut-être homogène à la combinaison instantanée des tâches opératives).
Dans les cas de structures ou de fonctionnement complexes, le modèle de l’ordonnancement des ordres ne
peut s’appuyer sur la recension exhaustive des états de la PO (au sens précédent), celui-ci se dénombrant
approximativement comme produit des nombres d’état de tous les actionneurs, d’où l’explosion
combinatoire. De plus, l’évolution d’un tel modèle guidé par le résultat nécessite de le repenser
complètement, tout étant lié.
La disparition du programme des CPGE du Grafcet en tant que langage normalisé de spécification-
modélisation des automatismes logiques et l’incapacité méthodologique, comme technique, des
diagrammes d’état ou d’activité de SysML à remplir la même fonction, mène à présenter en quelque pages
les réseaux de Petri, dont une des descendances a été le Grafcet.
Les RdP sont un modèle très utilisé pour la modélisation de nombreux types de Systèmes à Evénements
Discrets. Ils sont enseignés en école d’ingénieur et utilisés en recherche et développement (réseau,
logistique, fiabilité, jeux, gestion des ressources, etc.) dans leur version déterministe comme aléatoire.
SYNTAXE ELEMENTAIRE DES RESEAUX DE PETRI ET EXEMPLES
Structure
Un réseau de Petri, RdP, est constitué de places et de transitions, reliées par des arcs orientés, ou flèches.
Une place ne peut être reliée qu’à des transitions et inversement : c’est un graphe biparti. Une place
modélise un contenant ou une condition, le contenu ou la valeur étant représenté par des jetons, ou
marques. Une transition modélise une possibilité d’évolution.
Les jetons se déplacent dans le RdP lors de franchissements, ou de tirs, de transitions.
.
Pour départager ces deux évolutions, le modèle des RdP associe une condition logique à chaque transition.
Celle-ci est une garde si son niveau haut peut perdurer ou un événement si son passage au niveau haut est
fugace. Notons Ci la condition (garde ou événement) associée à la transition Ti.
Place d’entrée de la transition T2 : P0
Places de sortie de T2 : P2 et P3 (parallélisme)
Places d’entrée de T5 : P2 et P4
(synchronisation)
Transition d’entrée de P0 : i.
Transition de sortie de P0 : T1 et T2 (choix)
La répartition des jetons dans un RdP est appelé
marquage et sera noté M.
Le marquage définit l’état du RdP, donc de la
commande
Les conditions initiales de ce système dynamique
sont contenues dans le marquage initial ici M0={ 1,
0, 0, 0, 0}. Dans cet état, les deux transitions T1 et
T2 sont dites sensibilisées car toutes leurs places
d’entrée (en l’occurrence, P0) disposent d’un jeton.
Implantation sur cible, L. Tromp, Saint Louis 2014-2015 Page 4
Le parcours des états du RdP est obtenu en simulant le RdP : à partir du marquage initial, les marquages
suivants sont dits accessibles :
M0 T2 M1 M0 T1 M2 M1 T4 M3 M3 T5 M2
M1={0, 0, 1, 1, 0}
M2={0, 1, 0, 0, 0}
M3={0, 0, 1, 0, 1} M2={0, 1, 0, 0, 0}
Le retour en M0 n’est possible qu’à partir de M2 par le tir de T0.
On peut résumer ces évolutions sur le graphe des marquages accessibles à partir de M0:
Le graphe des marquages accessibles est toujours un graphe d’état : un seul sommet de ce graphe est actif
à chaque instant, ce qui est somme toute normal pour un état. Ce n’était pas le cas du RdP initial.
Remarque importante : la structure du graphe d’état est ici ‘plus simple’ que le RdP de départ, pourquoi
ne pas utiliser directement les machines d’état ? La raison en est que la stratégie de commande consiste
justement à décrire par le parallélisme d’action, le partage de ressources, la synchronisation des
différentes parties du système commandé. La simplicité des graphes d’état est trompeuse et n’est de ce fait
pas un argument pertinent au moment du choix du type de modèle (machine d’état vs Petri ou autre)
adapté à un comportement complexe. Les machines d’état ont été pour cette raison abandonnées dans les
années 1980 au profit de modèles plus évolués dont la syntaxe est adaptée à l’objectif et la sémantique
simple.
Ces langages de modélisation modernes permettent d’analyser, d’expliquer, de faire évoluer une
commande mais aussi de simplifier grandement son inévitable maintenance: en effet, dans un graphe
d’état, tous les comportements, même autonomes, sont mélangés, ce qui complique le diagnostic d’un
dysfonctionnement.
Cette opposition est comparable à celle d’un polynôme considéré dans sa forme développée (graphe
d’état) ou factorisée (RdP ou Grafcet). Il est clair que cette seconde version, donnant accès à ses racines,
est toujours plus utile pour l’analyse et la manipulation. Le passage à la forme développée est irréversible.
Implantation sur cible, L. Tromp, Saint Louis 2014-2015 Page 5
Sémantique des places
Si chaque place peut contenir plus d’un jeton, ces jetons représenteront des quantités, comme l’état
d’un stock ou d’une file d’attente à un péage d’autoroute. Le RdP est un bon modèle pour décrire
les flux, les accumulations, les traitements en lot.
Si chaque place peut contenir au plus un jeton, celui-ci peut représenter un stock borné à 1
(ressource occupée vs libre) mais également et qualitativement l’activité de cette place : une place
active est repérée par la présence d’un jeton.
En pratique, les RdP 1-bornés modélisent tout autant un flux sur des postes de capacité unitaire qu’un
séquencement d’activations. Ce sont ces RdP adaptés à la commande qui ont été présentés plus haut.
Les RdP peuvent aussi être constitués de graphes
disjoints, ou non connexes (voir ci-contre). Cette
architecture de commande modulaire permet
d’éviter toute spécification globale (type graphe
d’état) en séparant les comportements
fonctionnellement distincts.
Dans l’optique de la commande des feux du passage piétons, on peut envisager plusieurs structures de
commande :
trois RdP non connexes : gestion de la ressource ‘zone à bandes’, gestion des ‘feux voiture’ et
gestion des ‘feux piétons’, synchronisation des RdP-feux sur le RdP-ressource ;
deux RdP non connexes : un pour chaque feu, synchronisation directe entre eux ;
un RdP : parallélisme structural permettant à plusieurs séquences d’être exécutées simultanément,
ce n’est alors par une machine d’état. Sa capacité d’évolution est plus faible que les versions non
connexes.
Il reste maintenant à établir une structure de commande permettant de satisfaire le cahier des charges puis à
traduire cette structure en équations d’activation et de désactivation des places en fonction de conditions
logiques à déterminer. En revanche, la commande des sorties est immédiate car les places sont bien sûr
conçues en lien avec l’action qui leur sera associée.
Il n’y a pas de méthodologie universelle pour cette élaboration : en revanche, certains concepts sont
récurrents, l’automaticien doit les utiliser à bon escient.
Implantation sur cible, L. Tromp, Saint Louis 2014-2015 Page 6
Modélisation graphique de la dynamique d’évolution d’état
On considère le RdP précédent, maintenant muni de ses conditions logiques (événements ou gardes):
Remarque : à titre de comparaison, la même spécification structurelle grâce aux graphes d’état donne le
résultats suivant (graphe des marquages accessibles).
Sa structure très ramifiée découle du fait que les deux graphes peuvent srtucturellement évoluer de
manière indépendante. Pour les feux, les RdP étant synchronisés, le nombre d’états accessibles sera en
pratique plus limité.
Implantation sur cible, L. Tromp, Saint Louis 2014-2015 Page 7
Modélisation littérale de la dynamique d’état
Considérons le RdP de droite comme modèle du fonctionnement des ‘feux voiture’. L’activité de chaque
place Pi étant binaire par nature, on lui associe une variable binaire Xi avec la convention : (Pi
active)(Xi=1)
A l’instant initial, le marquage indique ‘Feu vert’.
Si la condition, pour l’instant non précisée, c0 devient vraie, le tir de T0
a lieu ce qui se traduit par l’événement ’Le feu passe à l’orange’ par:
désactivation de P0 et
activation (théoriquement simultanée) de P1.
Il en sera de même lors du tir des transitions T1 (désactivation de la
place d’entrée et activation de la place de sortie).
Il faut alors distinguer l’état courant de la PC de l’état suivant visé par le tir de la transition. On notera
Xi=Xin+1 et xi=Xin, les états suivant et actuel.
Par exemple,
pour le marquage initial tant que c0=0 : (X0=x0=1) , (X1=x1=0) et (X2=x2=0).
à l’instant même où c0=1, alors (x0=1 et X0=0) soit la désactivation de P0, (x1=0 et X1=1) soit
l’activation de P1 et (x2=X2=0), soit aucune évolution de P2.
l’évolution précédente déclenchée par c0 ne doit cependant se produire que si la transition était T0
sensibilisée, c’est-à-dire ssi P0 était active, soit x0=1.
La programmation repose sur l’équation d’état logique associée à l’activité de chaque place, mise sous la
forme d’un système dynamique élémentaire : Xi=f(xi,ci),
La méthodologie générale à suivre est la suivante pour chaque place :
Détermination des conditions de mise à 1, notées xi (pour enclenchement de la variable xi)
Détermination des conditions de mise à 0, notées xi (pour déclenchement de la vraiable xi)
Ecriture de l’équation Xi=f(xi,ci) sous la forme:
Ecriture des équations de sorties.
L’équation est celle de la commande d’une mémoire élémentaire (1 bit) à marche
prioritaire dont le fonctionnement est traduit dans la table de vérité suivante :
Comportement
1 - - 1 Pour toute valeur de , et de , la place est activée ou reste active
0 0 0 0 Mémorisation à 0
0 0 1 1 Mémorisation à 1
0 1 1 0 Mise à 0
0 1 0 0 Maintien à 0
Soit pour chacune des places :
Place P0 Place P1 Place P2
Implantation sur cible, L. Tromp, Saint Louis 2014-2015 Page 8
L’ensemble des équations décrivant la commande des feux de voiture est :
L’événement c0 provient de l’appui sur le bouton poussoir simulant un appel piéton. ;
L’événement c1 provient de la fin du décompte de la temporisation de durée à l’orange :
L’événement c2 provient de la fin du décompte de la temporisation de durée au rouge.
Soit :
IMPLANTATION SUR CIBLE
Cinq registres (ensembles de mémoire) sont a priori nécessaires :
Un pour l’état actuel : x=(x0, x1, x2)
Un pour l’état suivant : X=(X0, X1, X2)
Un pour les entrées E=(bouton)
Un pour les conditions : c=(c0, c1, c2)
Un pour les sorties : S=(Vert, Orange, Rouge) (on peut toutefois s’en passer en programmation
Arduino, les valeurs des sorties étant directemen affectées aux broches).
Hypothèses
Certaines hypothèses doivent être imposées pour passer du modèle à la réalisation pratique :
Les changements des variables d’entrée sont les événements externes
Les changements de marquage sont des événements internes
L’espace temporel interne est sans commune mesure avec l’espace temporel externe : l’ensemble
des évolutions découlant d’un événement externe est achevé avant la survenue de l’événement
externe suivant
Les occurrences d’événements externes non corrélés sont temporellement distinctes
En première approche, on considèrera pour implantation rapide sur Arduino que les hypothèses précédentes
impliquent que la durée de maintien à 1 des variables d’entrée est plus longue que le temps de cycle du
programme : un événement externe sera toujours vu. En d’autres termes, les Systèmes à Evénements
Discrets de commande évoluent en pratique sur garde brève et non sur événement strict.
De toute façon, un dispositif monoprocesseur n’a pas une réactivité infinie.
Implantation sur cible, L. Tromp, Saint Louis 2014-2015 Page 9
Construction des événements : fronts actifs
Les événements peuvent être externes (appui sur bouton) ou internes (fin de temporisation). Un événement
est fugitif par nature : s’il dure moins de temps qu’un cycle du programme, il peut être perdu. Les gardes
représentent les conditions pouvant perdurer : ce sont les niveaux des variables internes ou externes.
Un événement n’existe pas en soi, c’est un point de vue particulier sur l’information, il faut donc le
construire informatiquement
Le front actif d’un signal, qui peut être montant ou descendant, est un événement lié au changement de
valeur (et non d’état, terme réservé usuellement au système dynamique) d’une variable:
front montant d’une condition c :
front descendant d’une condition c :
Ceci se particularise :
aux événements externes :
o appui sur un bouton poussoir:
o relâchement:
aux événements internes sur marquage de place :
o activation d’une place : o désactivation :
Temporisations
Principe
La construction d’une temporisation repose sur la lecture de l’instant courant du processeur. A
l’occurrence d’un événement déclencheur (Evénement1 ci-dessous, ‘début tempo’), un compte à rebours
est lancé. Un événement de fin (Evénement2, ‘fin tempo’) est émis à l’issue du décompte.
Les temporisations étant ici prévues pour déclencher une évolution certaine, le compte à rebours sera
réinitialisé une fois l’événement ‘fin de temporisation’ survenu.
Mais une temporisation peut aussi intervenir dans une garde sous la forme d’une inhibition (‘tant que’ le
décompte n’est pas achevé) ou d’une validation (‘à partir de’ la fin du décompte). Dans ce cas, la
réinitialisation de la temporisation dépendra d’un autre événement (Evénement3, ‘réinit tempo’).
t ti
tc
tf
tc < tf
Temporisation en cours
t ti
tf=tc
(tf == tc) Evénement2
Fin de temporisation
t ti
tc
Evénement3 tf =
Temporisation réinitialisée
tf =
t ti=tc
tf
Evénement1 tf = ti+
Début de temporisation
Implantation sur cible, L. Tromp, Saint Louis 2014-2015 Page 10
Gestion du temps
En fixant tf à une valeur grande, symboliquement l’infini, le test (tf == tc) ne sera jamais vrai. Le test
d’égalité ayant toujours, en toute probabilité, la valeur Faux, on testera en pratique (tf > tc) : Evénement2
surviendra au temps de cycle du programme près. Les instants finaux liés à chaque temporisation sont
mémorisés dans une liste timer[].
On considérera dans le programme suivant qu’Evénement3 est identique à Evénement2, la réinitialisation
de la temporisation est faite dans la même itération de la boucle que la mise à un de la condition.
Dans le langage Arduino, l’instant courant est donné par la commande millis().
Algorithme d’exécution du réseau de Petri de commande
Paramétrage :
o affectation des variables et mnémoniques, état (marquage) initial, sorties initiales
Réglage :
o déclaration des numéros et statuts des broches
Boucle infinie :
o lecture des entrées
o calcul des conditions : événements = construction des fronts, sinon gardes = valeurs
o calcul de l’état suivant
o déclenchement des temporisations sur calcul des événements internes déclenchants (fronts
de variable de place)
o affectation des sorties sur état (et sur entrée le cas échéant si programmation d’une machine
de Mealy) actualisation de l’état
Recherche de stabilité
Dans l’algorithme précédent, chaque itération provoque autant la lecture des entrées que l’affectation des
sorties, même si les conditions d’évolution de l’état sont déjà remplies. La question de la recherche de
stabilité avant affectation des sorties n’est donc pas traitée, toutes les sorties sont impulsionnelles ou à
niveau si elles sont maintenues d’un cycle à l’autre.
La recherche de stabilité peut toutefois être réalisée par une boucle ‘tant que’ à l’aide d’un registre
supplémentaire de mémorisation de l’état précédent pour éviter son écrasement.
Mémorisation et compteurs
Des mémoires internes binaires permettent de réaliser la mémorisation de la commande d’une sortie, qui
n’est ainsi plus directement reliée à l’état courant du RdP. La mise à un et à zéro de ces variables sont
déclenchées a priori sur un événement interne, comme l’activation ou la désactivation d’une place.
Des mémoires internes numériques permettent de réaliser un comptage/décomptage de passage activé sur
événement interne ou externe.
Implantation sur cible, L. Tromp, Saint Louis 2014-2015 Page 11
Programme Arduino 1/2 // Programme issu du réseau de Petri de pilotage du feu tricolore d'un carrefour
//Laurent Tromp, 06/06/2015
//Saint Louis, Paris
// Numéros de broches: registre des entrées / sorties
const int VV = 10; //Vert voiture
const int VO = 9; //Orange voiture
const int VR = 8; //Rouge voiture
const int PV = 7; //Vert piéton
const int PR = 6; //Rouge piéton
const int Bouton = 5; //Appel piéton
const double infini=pow(10,5); //grande durée pour les temporisations
const double tempo[]={1000,1500}; //durées des temporisations
// Variables:
double timer[]={infini,infini}; //Initialisation des compteurs
boolean x[]={1,0,0}; //registre de l’état courant Voiture, initialisé
boolean X[]={1,0,0}; //registre de l’état suivant, initialisé
boolean C[]={0,0,0}; //registre des gardes/événements RdP voiture
boolean E[]={0}; //registre des entrées
boolean S[]={0,0,0}; //registre des sorties (inutile en pratique)
boolean boutonprec=0;
void setup() {
pinMode(VV, OUTPUT); //Déclaration des broches
pinMode(VO, OUTPUT);
pinMode(VR, OUTPUT);
pinMode(PV, OUTPUT);
pinMode(PR, OUTPUT);
pinMode(Bouton, INPUT); }
void loop()
{ E[0]=digitalRead(Bouton); //lecture du bouton poussoir
boolean demande=E[0]&&!boutonprec; //construction d'un front montant
boutonprec=E[0]; //mémorisation de l'entrée
if (demande==1){C[0]=1;} else {C[0]=0;} //définition des conditions
if (millis()-timer[0]>tempo[0]){C[1]=1;timer[0]=infini;} else {C[1]=0;}
if (millis()-timer[1]>tempo[1]){C[2]=1;timer[1]=infini;} else {C[2]=0;}
X[0]= x[2]&&C[2] || x[0]&&!C[0]; //équations d’état RdP Voiture
X[1]= x[0]&&C[0] || x[1]&&!C[1];
X[2]= x[1]&&C[1] || x[2]&&!C[2];
if (X[1]&&!x[1]){timer[0]=millis();} //enclenchement des temporisations
if (X[2]&&!x[2]){timer[1]=millis();} //sur front montant
digitalWrite(VV,x[0]); //affectation des sorties
digitalWrite(VO,x[1]); //sur l’état courant
digitalWrite(VR,x[2]);
for (int i=0;i<=sizeof(x);i++){x[i]=X[i];} //actualisation de l'état RdP Voiture
}
Implantation sur cible, L. Tromp, Saint Louis 2014-2015 Page 12
MODELE PRENANT EN COMPTE DES PIETONS : SYNCHRONISATION DE RDP
La gestion du feu des piétons relève d’une partie opérative différente, elle sera modélisée par un RdP non
connexe (sans transition ni place commune) avec le RdP Voiture. La coordination des évolutions des ordres
émis vers chaque feu nécessitera des échanges de messages synchrones : message, compte-rendu,
acquittement afin d’éviter tout blocage d’un des RdP dans un état intermédiaire et de ce fait limiter le
risque de commande erronée et pas suite d’accident.
Le RdP suivant est un modèle de type système à événements discrets pour la commande du carrefour.
Structurellement, le RdP est codé ainsi :
et
Prise en compte du séquencement imposé : explications
Le premier message synchrone a lieu en P2 : les piétons peuvent passer (il est aussi possible de
prévoir un retard de T0b par rapport à P2 en ajoutant une place intermédiaire).
Une fois les piétons passés et leur feu PR de nouveau rouge, il faut que le feu voiture reste rouge
pour éviter tout accident : c’est la raison de la duplication de la place P2 en P3.
Afin d’éviter tout blocage, les RdP évoluent séquentiellement : les messages synchrones suivants
doivent être échangés dans cet ordre : {2, 2b} c2b {2,3b} c2 {3,3b} c3b {2,0b}
c3 {0,0b} qui est l’état initial. Leur sémantique la plus simple est celle sur les variables
d’activité des places.
Les temporisations se trouvent en c1, en c1b et en c2b.
Implantation sur cible, L. Tromp, Saint Louis 2014-2015 Page 13
On peut visualiser le séquencement des tirs de transition :
Pour le fonctionnement attendu, les événements ou gardes adéquats donnent les systèmes couplés suivants :
et
La distinction entre les xi et les xbi, ainsi qu’entre les ci et les cbi n’est utile que dans le cadre de la
présentation initiale. Une numérotation commune est préférable pour n’avoir qu’un vecteur (registre en
pratique) d’état et un vecteur de conditions. Le terme vecteur est justifié dans la suite.
1
2
3
4
5 6
7 8
Implantation sur cible, L. Tromp, Saint Louis 2014-2015 Page 14
Programme Arduino 2/2
Le programme est modifié en conséquence (on ne reproduit que les parties différentes du programme) :
// Numéros des broches: registre des entrées / sorties
...
const double tempo[]={1000,1500,5000,1000}; //durées des temporisations
// Variables:
double timer[]={infini,infini,infini,infini}; //Initialisation des compteurs
boolean x[]={1,0,0,0}; //registre de l’état courant Voiture, marquage initial
boolean X[]={1,0,0,0}; //registre de l’état suivant initialisé=marquage initial
boolean xb[]={1,0,0,0}; //registre de l’état courant Piéton, marquage initial
boolean Xb[]={1,0,0,0}; //registre de l’état suivant initialisé=marquage initial
boolean C[]={0,0,0,0}; //registre des gardes ou événements RdP Voiture
boolean Cb[]={0,0,0,0}; //registre des gardes ou événements RdP Piéton
boolean E[]={0}; //registre des entrées
boolean S[]={0,0,0}; //registre des sorties RdP Voiture
boolean Sb[]={0,0}; //registre des sorties RdP Piéton
boolean boutonprec=0;
void setup() {
... }
void loop()
{ E[0]=digitalRead(Bouton); //lecture du bouton poussoir
boolean demande=E[0]&&!boutonprec; //détection d'un front montant
boutonprec=E[0]; //mémorisation de l'entrée
if (demande==1){C[0]=1;} else {C[0]=0;} //événement déclencheur du programme
if (millis()-timer[0]>tempo[0]){C[1]=1;timer[0]=infini;} else {C[1]=0;}
C[2]=xb[3]; //garde de synchro du RdP Piéton
C[3]=xb[0]; //garde d'acquittement du RdP Piéton
X[0]= x[3]&&C[3] || x[0]&&!C[0]; //équations d'état RdP Voiture
X[1]= x[0]&&C[0] || x[1]&&!C[1];
X[2]= x[1]&&C[1] || x[2]&&!C[2];
X[3]= x[2]&&C[2] || x[3]&&!C[3];
if (X[1]&&!x[1]){timer[0]=millis();} //enclenchement de la tempo feu rouge
//Idem RdP piéton
if (millis()-timer[2]>tempo[2]){Cb[1]=1;timer[2]=infini;} else {Cb[1]=0;}
if (millis()-timer[3]>tempo[3]){Cb[2]=1;timer[3]=infini;} else {Cb[2]=0;}
Cb[0]=x[2]; //garde de synchro du RdP Voiture
Cb[3]=x[3]; //garde d'acquittement du RdP Voiture
Xb[0]=xb[3]&&Cb[3] || xb[0]&&!Cb[0];
Xb[1]=xb[0]&&Cb[0] || xb[1]&&!Cb[1];
Xb[2]=xb[1]&&Cb[1] || xb[2]&&!Cb[2];
Xb[3]=xb[2]&&Cb[2] || xb[3]&&!Cb[3];
if (Xb[1]&&!xb[1]){timer[2]=millis();} //enclenchement des temporisations
if (Xb[2]&&!xb[2]){timer[3]=millis();}
digitalWrite(VV,x[0]); //Affectations des sorties
digitalWrite(VO,x[1]);
digitalWrite(VR,x[2]||x[3]);
digitalWrite(PV,xb[1]);
digitalWrite(PR,xb[0]||xb[2]||xb[3]);
for (int i=0;i<=sizeof(x);i++){x[i]=X[i];} //Actualisation de l'état RdP Voiture
for (int i=0;i<=sizeof(xb);i++){xb[i]=Xb[i];} //Actualisation de l'état RdP Piéton
}
Implantation sur cible, L. Tromp, Saint Louis 2014-2015 Page 15
PROGRAMMATION A L’AIDE DU MODULE PY2DUINO
Les avantages essentiels de la programmation en Arduino sont la rapidité d’exécution et la robustesse du
programme.
Les inconvénients essentiels résident dans :
la pratique du C, en plus de Python et de Scilab,
la compilation du programme et le téléversement dans le processeur après toute modification,
l’absence de visualisation de l’état interne de la carte, le moniteur série n’étant pas très pratique
d’utilisation.
Le module Py2duino développé par Alain Caignot et présenté à Démosciences en 2014, permet de
s’affranchir de ces limitations. L’utilisation de ce module nécessite au préalable :
l’installation une fois pour toutes du module serial dans la distribution Python (pip install pyserial sous pyzo)
le téléversement initial dans le processeur du programme réalisant la communication avec Python
(toolbox_arduino_v3.ino)
Une traduction directe (non optimisée) en Python du programme écrit initialement en C-Arduino est
fournie ci-dessous. Le parti-pris a été de décrire le fonctionnement logique par True et False. Le
programme fonctionne également avec 1 et 0.
from py2duino import * #importation du module de traduction
import time #module de gestion du temps
ar1=Arduino(4) #déclaration de la carte sur le port COM4
time.sleep(1); #tempo permettant la communication de s'établir
#Numéros des broches:
VV = 10; #Vert voiture
VO = 9; #Orange voiture
VR = 8; #Rouge voiture
PV = 7; #Vert piétons
PR = 6; #Rouge piétons
Bouton = 5; #Appel piétons
#Constantes
infini=pow(10,15); #grande durée pour les temporisations
F=False; #raccourcis
T=True;
tempo=[1.000, 1.500, 5.000, 1.000]; #durées des temporisations
# Variables:
timer=[infini,infini,infini,infini]; #Initialisation des compteurs
x=[T,F,F,F]; #Etat courant RdP Voiture et marquage initial
X=[T,F,F,F]; #Etat suivant initialisé au marquage initial
xb=[T,F,F,F]; #Etat courant RdP Piéton et marquage initial
Xb=[T,F,F,F]; #Etat suivant initialisé au marquage initial
C=[F,F,F,F]; #gardes ou événements RdP voiture
Cb=[F,F,F,F]; #gardes ou événements RdP piétons
E=[F]; #entrée=bouton
S=["LOW","LOW","LOW"]; #Sorties RdP Voiture
Sb=["LOW","LOW"]; #Sorties RdP Piétons
boutonprec=F; #valeur initiale du bouton poussoir
# Déclaration des broches
ar1.pinMode(VV,"OUTPUT")
ar1.pinMode(VO,"OUTPUT")
ar1.pinMode(VR,"OUTPUT")
ar1.pinMode(PV,"OUTPUT")
ar1.pinMode(PR,"OUTPUT")
ar1.pinMode(Bouton,"INPUT")
Implantation sur cible, L. Tromp, Saint Louis 2014-2015 Page 16
while True: #boucle sans fin
E[0]=ar1.digitalRead(Bouton); #lecture du bouton poussoir
demande=E[0] and not(boutonprec); #détection d'un front montant
boutonprec=E[0]; #mémorisation de l'entrée
if demande==T: C[0]=T; #événement déclencheur du programme
else: C[0]=F;
if (time.time()-timer[0]>tempo[0]): #compteurs de tempo et test de fin
C[1]= T; timer[0]=infini;
else:
C[1]= F;
C[2]= xb[3]; #garde de synchro du RdP Piétons
C[3]= xb[0]; #garde d'acquittement du RdP Piétons
X[0]= x[3] and C[3] or x[0] and not C[0]; #Calcul état RdP Voiture
X[1]= x[0] and C[0] or x[1] and not C[1];
X[2]= x[1] and C[1] or x[2] and not C[2];
X[3]= x[2] and C[2] or x[3] and not C[3];
if (X[1] and not x[1]): timer[0]=time.time(); #tempo feu rouge sur front
#Idem RdP Piétons
if (time.time()-timer[2]>tempo[2]):
Cb[1]=1;timer[2]=infini;
else: Cb[1]=F;
if (time.time()-timer[3]>tempo[3]):
Cb[2]=T;timer[3]=infini;
else: Cb[2]=F;
Cb[0]= x[2]; #garde de synchro du RdP Voiture
Cb[3]= x[3]; #garde d'acquittement du RdP Voiture
Xb[0]= xb[3] and Cb[3] or xb[0] and not Cb[0];
Xb[1]= xb[0] and Cb[0] or xb[1] and not Cb[1];
Xb[2]= xb[1] and Cb[1] or xb[2] and not Cb[2];
Xb[3]= xb[2] and Cb[2] or xb[3] and not Cb[3];
if (Xb[1] and not xb[1]): timer[2]=time.time();
if (Xb[2] and not xb[2]): timer[3]=time.time();
if x[0]: S[0]="HIGH"; #Affectation du registre des sorties
else: S[0]="LOW";
if x[1]: S[1]="HIGH";
else: S[1]="LOW";
if x[2] or x[3]: S[2]="HIGH";
else: S[2]="LOW";
if xb[1]: Sb[0]="HIGH";
else: Sb[0]="LOW";
if xb[0] or xb[2] or xb[3]: Sb[1]="HIGH";
else : Sb[1]="LOW";
ar1.digitalWrite(VV,S[0]); #Communication à l’Arduino
ar1.digitalWrite(VO,S[1]);
ar1.digitalWrite(VR,S[2]);
ar1.digitalWrite(PV,Sb[0]);
ar1.digitalWrite(PR,Sb[1]);
for i in range(len(x)): #Actualisation de l'état RdP Voiture
x[i]=X[i];
for i in range(len(xb)): #Actualisation de l'état RdP Piétons
xb[i]=Xb[i];
Implantation sur cible, L. Tromp, Saint Louis 2014-2015 Page 17
MODELISATION ALGEBRIQUE
Formulation d’état
L’expression ‘vecteur d’état’ n’a d’intérêt que dans un contexte algébrique, idéalement linéaire. La
formulation linéaire d’un système dynamique exprimé sous forme d’état est la suivante :
Continu linéaire
ou continu non linéaire
Discret linéaire :
ou discret non linéaire
A condition de changer de lois de composition interne, il est possible de ramener les équations du système
logique à une formalisation identique :
devient :
Dans ce cadre, le 0 devient Vrai, le 1 devient Faux, la multiplication devient ET et l’addition devient OU.
Pour le reste, les règles de l’algèbre linéaire s’appliquent de manière usuelle.
Expression des conditions
Plus spécifiquement, le système est :
car:
On obtient donc le système dynamique complet:
Implantation sur cible, L. Tromp, Saint Louis 2014-2015 Page 18
Prise en compte de la synchronisation (ou couplage)
Lorsque les RdP sont synchronisés sur état, les règles d’évolution font intervenir des ‘produits’ de variables
d’état, ce qui exclut a priori une formulation linéaire.
Toutefois, dans notre cas, les produits sont limités à deux variables d’état. La forme précédente peut
s’étendre en établissant la dépendance linéaire entre les conditions et l’état, ce qui impose trois calculs
successifs :
des conditions d’évolution en fonction des entrées et de l’état courant
de l’état suivant en fonction de l’état courant et des conditions
des sorties.
Ne sont pas prises en compte alors les fonctionnements ‘annexes’ comme le départ des temporisations.
Rappel des équations des systèmes à événements discrets couplés :
et
En version renumérotée avec , , et , on obtient:
Implantation sur cible, L. Tromp, Saint Louis 2014-2015 Page 19
Sous forme algébrique linéaire:
Les structures plus complexes que ces deux cycles synchronisés se conçoivent puis se formalisent de la
même manière.
CONCLUSION
Ces paragraphes avaient plusieurs objectifs, notamment montrer que:
d’un point de vue théorique, la formulation d’état convient non seulement aux systèmes
dynamiques continus mais également aux systèmes dynamiques logiques, ou séquentiels ;
l’on dispose d’un cadre conceptuel fondé permettant d’analyser et de concevoir des Systèmes à
Evénements Discrets pour la commande et que ce ne sont ni des machines d’état ni des diagrammes
d’activité, outils qui ne se situent pas au niveau adéquat d’étude du système car ils confondent la
spécification de l’effet visé avec celle de l’ordre pour l’obtenir ;
d’un point de vue pratique, qu’il serait envisageable d’engendrer automatiquement les commandes
Arduino à partir d’un logiciel de simulation de RdP comme celui utilisé dans ce document,
pipe25_rc5, logiciel gratuit téléchargeable, à condition toutefois d’entrer dans son code puis de
l’adapter. Il s’agirait en quelque sorte de mettre au point un post-processeur.
Le bénéfice réside dans la compréhension avancée des différentes étapes de l’implantation sur cible d’une
stratégie de commande, à bien moindre échelle toutefois et de manière bien plus artisanale que ce
qu’autorisent nativement les logiciels de type Automgen.
Enfin, par leur très grande variété (temporisés, aléatoires, colorés, etc.), les réseaux de Petri permettent
d’aborder la modélisation et l’analyse formelle de toutes sortes de systèmes dynamiques (à événements)
discrets : fabrication, réseaux, fiabilité, gestion de projet, etc. Voir par exemple « Les réseaux de Petri, Un
outil de modélisation », Annie Choquet-Geniet, Dunod, Collection Sciences Sup, 2012.
Implantation sur cible, L. Tromp, Saint Louis 2014-2015 Page 20
Du besoin client à la commande __________________________________________________________ 1
Points de vue pour l’implantation sur cible __________________________________________________ 1
Données de départ _____________________________________________________________________ 2
moyens à disposition ___________________________________________________________________ 3
Syntaxe élémentaire des réseaux de Petri et exemples ________________________________________ 3
Structure __________________________________________________________________________________ 3
Sémantique des places _______________________________________________________________________ 5
Modélisation graphique de la dynamique d’évolution d’état ________________________________________ 6
Modélisation littérale de la dynamique d’état ____________________________________________________ 7
Implantation sur cible __________________________________________________________________ 8
Hypothèses ________________________________________________________________________________ 8
Construction des événements : fronts actifs ______________________________________________________ 9
Temporisations _____________________________________________________________________________ 9 Principe ___________________________________________________________________________________________ 9 Gestion du temps __________________________________________________________________________________ 10
Algorithme d’exécution du réseau de Petri de commande _________________________________________ 10
Recherche de stabilité ______________________________________________________________________ 10
Mémorisation et compteurs _________________________________________________________________ 10
Programme Arduino 1/2 ____________________________________________________________________ 11
Modèle prenant en compte des piétons : synchronisation de RdP ______________________________ 12
Prise en compte du séquencement imposé : explications __________________________________________ 12
Programme Arduino 2/2 ____________________________________________________________________ 14
Programmation à l’aide du module py2duino ______________________________________________ 15
Modélisation algébrique _______________________________________________________________ 17
Formulation d’état _________________________________________________________________________ 17
Expression des conditions ___________________________________________________________________ 17
Prise en compte de la synchronisation (ou couplage) _____________________________________________ 18
Conclusion ___________________________________________________________________________ 19