Implantation sur cible Arduino : platine de feux d’un passage ......Implantation sur cible, L. Tromp, Saint Louis 2014-2015 Page 4 Le parcours des états du RdP est obtenu en simulant

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.


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


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.


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.


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.


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é.


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


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.


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


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.


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;}


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

}


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.


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


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


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

}


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")


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];



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];




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];


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:


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:


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.


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

Documents

Implantation sur cible Arduino : platine de feux d’un passage ......Implantation sur cible, L. Tromp, Saint Louis 2014-2015 Page 4 Le parcours des états du RdP est obtenu en simulant