Vers une vision int´ egr´ ee

Dans les travaux pr´ec´edents, les caract´eristiques du r´eseau sont simplement int´egr´ees comme donn´ees d’entr´ee pour l’analyse de la commandabilit´e et de la stabilit´e de l’application ; il n’existe pas de mod´elisation du r´eseau en vue de le caract´eriser. (Juanole et Blum, 1999) notent pourtant que le d´eveloppement d’ap-plications sur les syst`emes distribu´es n´ecessite des ´etudes `a caract`ere pluridisciplinaire : on ne peut plus se contenter d’´evaluer le comportement du syst`eme distribu´e par rapport `a des objectifs de Qualit´e de Service de la communication ; il faut imp´erativement relier cette Qualit´e de Service aux indices de performances sp´ecifiques des applications.

(Juanole et Blum, 1999) proposent une m´ethodologie d’´evaluation de l’asservissement du syst`eme distribu´e pr´esent´e sur la figure 1.5. L’´evaluation de l’asservissement du syst`eme est bas´ee sur la stabilit´e. Le syst`eme distribu´e concern´e par l’application est mod´elis´e par un r´eseau de Petri temporis´e stochastique repr´esent´e sur la figure 1.8.

L’int´erˆet majeur du r´eseau de Petri est l’int´egration sur le mˆeme mod`ele de la partie applicative avec la partie communication du SCR. Les transitions probabilistes permettent de faire ´evoluer le mod`ele suivant les particularit´es du r´eseau (pertes, protocole) et les transitions temporis´es de mod´eliser les phases d’attentes. L’´etude du comportement dynamique de ce mod`ele est ensuite utilis´ee afin de d´eterminer deux param`etres de la Qualit´e de Service du r´eseau : τdle d´elai et T , la p´eriode moyenne entre deux ´echantillons. Ces deux param`etres sont ensuite r´eutilis´es dans la boucle de r´egulation et dans l’expression de la marge de phase de l’asservissement qui permet de d´efinir la stabilit´e de l’asservissement.

Dans le cadre de nos travaux, nous avons ainsi initi´e cette approche `a partir d’une simple mod´elisation d’un ´echange maˆıtre / esclave. Le r´eseau de Petri temporis´e de la figure 1.9 fait ainsi ´emerger trois probl`emes majeurs. Les deux premiers sont de niveau application et consistent `a ´etudier les p´eriodes de rafraˆıchissement des effecteurs ainsi que leur promptitude par rapport aux tˆaches qui s’ex´ecutent cycliquement sur l’automate. La troisi`eme est relatif au retard subi sur le r´eseau.

Le mod`ele de la figure 1.9 prend en compte deux entit´es (un automate et un capteur). L’automate ex´ecute cycliquement un ensemble de tˆaches, la dur´ee du cycle est d´efinie par la transition t1et est born´ee par [a, b]. Le rˆole du capteur est de mesurer une variable (cycle de production d´efini par t11) et de la communiquer `a l’automate `a chaque fois qu’il la lui demande. Le sc´enario de communication consid´er´e est de type maˆıtre / esclave. L’automate (le maˆıtre) d´efini un cycle de polling (transition t7) de requˆetes auxquelles le capteur r´epond instantan´ement (place P 15). La mod´elisation du r´eseau n’est pas d´etaill´ee. Elle est simplement repr´esent´ee par les transitions t20et t21, qui permettent d’introduire le d´elai engendr´e par sa travers´ee. Il est `a noter que ce d´elai est suppos´e born´e.

1.1 Syst`emes contrˆol´es en r´eseau (SCR) 11 Site producteur (site i)

g´en´erateur p´eriodique d’´echantillons skn(t) p1 p12 t1 t11 entit´e producteur p2 t2 entit´e liaison site i p3 p4 t3 t4 p5 t5 p6 entit´e consommateur p9 p11 entit´e liaison site j p7 t7 t8 p8 p10 t9 couche physique t6 t14

Site consommateur (site j)

Fig.1.8: R´eseau de Petri d’un syst`eme distribu´e temps-r´eel (Juanole et Blum, 1999)

La particularit´e de ce RdPT est de prendre en compte l’asynchronisme au niveau de l’automate entre le cycle d’ex´ecution des tˆaches (t1) et le cycle de collecte des informations distantes (t7). Les requˆetes via le r´eseau ne sont pas directement forc´ees dans le cycle applicatif. Si la dur´ee du cycle est ainsi garantie, cette technique n´ecessite l’utilisation d’une m´emoire partag´ee dans laquelle l’automate viendra directement piocher les valeurs mesur´ees `a distance (P 2 r´epr´esente l’op´eration de lecture locale par cycle et P 3 l’´etat de la m´emoire d´edi´ee `a cette valeur). Le but du cycle P 5, P 6 est donc de mettre `a jour ces valeurs en ´emettant les requ`etes n´ecessaires. Le mˆeme principe est n´ecessaire sur le capteur o`u la fr´equence de polling ´etablie par l’automate peut ˆetre diff´erente du cycle de production de la valeur mesur´ee stock´ee dans P 13.

L’int´erˆet de ce RdPT est l’´etude des op´erations de lecture / ´ecriture sur cette m´emoire partag´ee qui est une zone fronti`ere entre deux processeurs compl`etement autonomes. Les possibilit´es d’analyse offertes par ce mod`ele concernent notamment la v´erification de la compatibilit´e de la dur´ee des cycles de production et de scrutation en fonction des d´elais introduits par le r´eseau. Prenons par exemple le cas de la place P 13 qui repr´esente l’´etat de la m´emoire tampon de la valeur mesur´ee par le capteur. La pr´esence d’un jeton y indique que cette variable a ´et´e mise `a jour depuis la derni`ere requˆete de l’automate re¸cue en P 13. Ainsi, si la transition t16 est franchie, cela signifie que la valeur qui sera transmise `a l’automate sera la mˆeme que la pr´ec´edente. A l’inverse, le franchissement de la transition t13correspond `a une configuration o`u le capteur met `a jour la valeur plus souvent qu’elle n’est scrut´ee par l’automate, ce qui peut se traduire par un manque de r´eactivit´e de l’automate.

automate programmable capteur P 0 t1 [a, b] P 1 t2 P 2 P 5 t7 [c, d] P 6 t8 P 7 t20 [g, h] P 14 P 10 [e, f ] t11 P 11 t12 P 12 t13 t14 P 13 t15 t16 P 15 t21 [i, j] P 4 t5 t6 P 3 t3 t4

Fig.1.9: R´eseau de Petri d’un ´echange maˆıtre / esclave

Cette ´etude (qui pourrait ˆetre ´etendue au niveau de l’automate) est int´eressante car elle illustre bien l’int´erˆet de ce type d’analyse pour la v´erification et l’´evaluation de performances d’architectures de commande comme les syst`emes contrˆol´es en r´eseau. L’exemple de la figure 1.9 reste toutefois simple et `a d´etailler afin d’obtenir un mod`ele complet de l’architecture (de la mod´elisation de la tache applicative `a l’´equipement d’interconnexion r´eseau) et v´erifier ainsi les ´eventuels blocages ou probl`eme d’incoh´erence d’une information distribu´ee sur deux automates `a un instant donn´ee.

Dans (Poulard et al., 2004), les r´eseaux de Petri color´es sont utilis´es pour mod´eliser le comportement dynamique d’une architecture de commande bas´ee sur Ethernet. Le mod`ele est d´etaill´e pour chacun des composants de l’architecture (r´eseau, automate, commutateur et process).Ces travaux ont la particu-larit´e de pr´esenter un mod`ele complet d’une architecture de commande, c’est-`a-dire la description des tˆaches, l’interface de communication r´eseau mais aussi la mod´elisation du protocole de communication utilis´es incluant les ´equipements r´eseaux. Si dans (Juanole et Blum, 1999), la mod´elisation par r´eseau de Petri permet d’´evaluer les modifications de la commande d’un syst`eme `a asservissement, (Poulard et al., 2004)(Marsal et al., 2005) montrent que l’´evaluation d’une commande d’un syst`eme `a ´evennements discrets distribu´e sur un r´eseau ouvert comme Ethernet est li´ee au d´eterminisme des ´etats de la com-mande. En effet, la distribution des communications sur un r´eseau implique que les p´eriodes de scrutations soient correctement d´efinies conform´ement aux sp´ecificit´es des tˆaches applicatives. Comme nous l’avons initi´e sur la figure 1.9, cette analyse permet d’ajuster la r´eactivit´e de la commande. De plus, la variance des d´elais engendr´es sur le r´eseau peut amener dans le cas d’une scrutation cyclique des situations o`u un nouveau cycle de scrutation d´emarre alors que les r´eponses n’ont pas encore ´et´e re¸cues. La distribution des d´elais issue du comportement du protocole de communication et des ´equipements utilis´es doit ˆetre prise en compte dans le comportement du syst`eme.

Tout ceci montre que les sp´ecificit´es du r´eseau influent aussi bien sur les syst`emes `a ´ev´enements discrets que sur les syst`emes `a espace d’´etat continu et que les influences sur la commande doivent ˆetre ´etudi´ees dans les deux cas, sachant que les outils d’´evaluation des syst`emes `a ´ev´enements discrets font apparaˆıtre

1.1 Syst`emes contrˆol´es en r´eseau (SCR) 13 d’autres points cruciaux.

Outre l’´etude de l’acc`es au r´eseau, l’acc`es concurrent de plusieurs tˆaches `a un mˆeme processeur doit ´egalement ˆetre pris en compte. Les travaux pr´esent´es dans (Kr´akora et Hanzalek, 2004)(Kr´akora et al., 2004) visent l’´etude des propri´et´es temporelles (temps de r´eponse, ordonnan¸cabilit´e des processus p´eriodiques) et des propri´et´es logiques (deadlock, exclusion mutuelle, acc`es `a base de priorit´e) des ap-plications comprenant deux types de ressources partag´ees : le processeur et le bus. La mod´elisation du protocole de communication (ici, le r´eseau de terrain CAN) est r´ealis´ee au moyen d’automates tempo-ris´es. L’int´erˆet est une mod´elisation compl`ete de l’application et l’objectif est une aide `a la v´erification compl`ete de ses propri´et´es. D’autres travaux similaires se portent ´egalement sur le r´eseau Ethernet (Dolejˇs et al., 2004).

1.1.6 Simulations

L’un des points cl´es des syst`emes contrˆol´es en r´eseau est la v´erification des performances du contrˆole pour divers niveaux de performance du r´eseau. L’approche classique consiste alors `a utiliser des outils de simulation.

Deux mod´elisations du r´eseau ont ´et´e r´ecemment propos´ees pour l’environnement MATLAB/Simulink (d´edi´e `a la simulation de la partie contrˆole) : NCsimulator (Lian, 2001) et TrueTime (Cervin et al., 2003)2. Elles permettent alors d’inclure dans la simulation du contrˆole des effets caract´eristiques du r´eseau.

(Branicky et al., 2003) introduisent un nouvel ensemble de travaux dont l’id´ee originale est la co-simulation. Dans cette approche, l’outil de simulation r´eseau ns-2 est ´etendu pour prendre en compte les nœuds des SCR (contrˆoleurs, capteurs, actionneurs . . . ) qui interagissent sur un r´eseau Ethernet. Cette extension (Agent/Plant pour ns-2) est utilis´ee afin de raffiner la conception du r´eseau et du syst`eme de contrˆole. Cette id´ee de co-simulation est reprise par (Hartman, 2004) qui r´eutilise les r´esultats de

la simulation sous ns-2 dans une simulation sous MATLAB/Simulink du syst`eme de contrˆole global.

L’avantage est une mod´elisation plus fine de la Qualit´e de Service du r´eseau.