Évaluation des délais de réactivité des architectures de commande distribuées sur réseau Ethernet

22/09/2017
Publication e-STA e-STA 2007-4
OAI : oai:www.see.asso.fr:545:2007-4:19885
DOI :

Résumé

Évaluation des délais de réactivité des architectures de commande distribuées sur réseau Ethernet

Métriques

24
6
531.84 Ko
 application/pdf
bitcache://958f31c61d1b1ab6cfaed5f9e8d6368e887ddb91

Licence

Creative Commons Aucune (Tous droits réservés)
<resource  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                xmlns="http://datacite.org/schema/kernel-4"
                xsi:schemaLocation="http://datacite.org/schema/kernel-4 http://schema.datacite.org/meta/kernel-4/metadata.xsd">
        <identifier identifierType="DOI">10.23723/545:2007-4/19885</identifier><creators><creator><creatorName>Gaëlle Marsal</creatorName></creator><creator><creatorName>Bruno Denis</creatorName></creator><creator><creatorName>Jean-Marc Faure</creatorName></creator></creators><titles>
            <title>Évaluation des délais de réactivité des architectures de commande distribuées sur réseau Ethernet</title></titles>
        <publisher>SEE</publisher>
        <publicationYear>2017</publicationYear>
        <resourceType resourceTypeGeneral="Text">Text</resourceType><dates>
	    <date dateType="Created">Fri 22 Sep 2017</date>
	    <date dateType="Updated">Fri 22 Sep 2017</date>
            <date dateType="Submitted">Fri 20 Jul 2018</date>
	</dates>
        <alternateIdentifiers>
	    <alternateIdentifier alternateIdentifierType="bitstream">958f31c61d1b1ab6cfaed5f9e8d6368e887ddb91</alternateIdentifier>
	</alternateIdentifiers>
        <formats>
	    <format>application/pdf</format>
	</formats>
	<version>33796</version>
        <descriptions>
            <description descriptionType="Abstract"></description>
        </descriptions>
    </resource>
.

Évaluation des délais de réactivité des architectures de commande distribuées sur réseau Ethernet Gaëlle Marsal1 , Bruno Denis1 , Jean-Marc Faure1,2 1 LURPA - ENS de Cachan - Université Paris Sud 61, avenue du Président Wilson, 94235 CACHAN CEDEX, FRANCE 2 SUPMECA 3, rue Fernand Hainaut, 93407 ST OUEN CEDEX, FRANCE Prenom.Nom@lurpa.ens-cachan.fr http://www.lurpa.ens-cachan.fr ‚ésuméL'idée d'avoir un média universel comme bus deterrain est séduisante. Ainsi, le développement de compo-santsd'automatisationcommunicantsurunréseauEthernetcommuté utilisant des protocoles de communication stan-dards et ouverts est d'actualité. Cependant, ce type de ré-seau introduit des mécanismes de partage de ressources etd'asynchronisme entre processus parallèles. Pour les archi-tectures devant assurer la commande de systèmes à événe-ments discrets, la conjonction de ces mécanismes rend dif-cile l'évaluation du délai de réactivité, retard entre l'oc-currence d'un événement et celle de sa conséquence sur leprocessus.Nousproposonsdanscetarticleuneméthodeba-sée sur la simulation d'un modèle dynamique en réseau dePetrihiérarchiquecolorétemporiséquiprendencomptelesmécanismes d'asynchronisme et de partage de ressources.Deux cas tests permettent de mettre en évidence l'intérêtde la modélisation proposée. wotsE™lés Réseau de terrain, systèmes à événements dis-crets, systèmes réactifs, réseau de Petri, simulation. I. Introduction ves —v—nt—ges du médi— ithernet en t—nt que rése—u de terr—in sont nom˜reuxF gitons p—r exemple l9uniformis—E tion des médi— de ™ommuni™—tion d—ns l9entreprise et l— reE ™on(gur—tion f—™ilitée p—r l— ™ommuni™—tion possi˜le entre tous les ™ompos—ntsF €our pro(ter de ™es —v—nt—ges en g—rE d—nt une ex™ellente r闙tivité de l— ™omm—ndeD de nomE ˜reux ™onstru™teurs et ™her™heurs ont tr—v—illé sur des proE to™oles spé™i(ques ™omme €ro(net ‘I“ ou h€Eithernet ‘P“F gepend—ntD ™es proto™oles sont dépend—nts d9un ™onstru™E teur p—rti™ulier et ne permettent p—s l9utilis—tion de ™omE pos—nts rése—ux st—nd—rds ‘Q“F h—ns ™ette étudeD —u ™ontr—ireD nous nous intéressons —ux rése—ux ithernet ™ommutés utilis—nt des proto™oles st—nE d—rds et ouvertsD plus p—rti™ulièrement wod˜usG„g€D de type ™lientGserveurF gepend—ntD l9utilis—tion de ™es réE se—ux introduit des dél—is di0™iles à déterminerF v— preE mière ™—use de dél—i est l9—jout de ™ompos—nts @™ommuE t—teursA qui induisent des ret—rds v—ri—˜lesF in e'etD ™es ™ompos—nts sont des ressour™es p—rt—géesD et suiv—nt leur ™h—rgeD ils vont ret—rder plus ou moins les tr—mesF he nomE ˜reux tr—v—ux se fo™—lisent sur ™e pointD ‘R“D ‘S“D ‘T“F …ne deuxième ™—use de dél—i est le p—rt—ge des modules d9enE tréesGsorties @iGƒAF ge™i est dû —u f—it que les proto™oles ™lientGserveur ne permettent p—s de ™ontrôle glo˜—l d9—™E ™ès —u médi—D ™ontr—irement —ux proto™oles m—îtreGes™l—ve ou produ™teurGdistri˜uteurG™onsomm—teurF in(nD l— derE nière ™—use de dél—i est l9—syn™hronisme entre l9exé™ution du progr—mme de ™omm—nde et l— s™rut—tion des entrées sortiesF ƒur ™e dernier —spe™tD une —ppro™he intéress—nte est présentée d—ns ‘U“F ille se ˜—se sur une —ppro™he forE melle de modelE™he™king sur des —utom—tes ™ommuni™—nts —(n de déterminer des ret—rds minimum et m—ximumF v— form—lis—tion du pro˜lème sous forme d9une équ—tion dioE ph—ntienne permet de v—lider les résult—ts o˜tenusF gh—que —ppro™he présentée se ™on™entre sur un pro˜lème isolé du resteF „outefoisD d—ns le ™—s de l— ™omm—nde d9un système à événements dis™rets @ƒihA à l—quelle se limite ™et —rti™leD l— perform—n™e —ttendue —u (n—l est le dél—i de r闙tivitéF ge dél—i est dé(ni p—r le ret—rd entre un événeE ment ™—use généré p—r le pro™essus ™omm—ndé et l9évéE nement ™onséquen™e fourni en réponse —u pro™essus @dri sur l— (gure IAF ve ™hronogr—mme sur l— droite de ™ette (E gure illustre l— v—ri—˜ilité du dél—iD ™e qui implique que les perform—n™es de r闙tivité doivent être ™—r—™térisées p—r l— distri˜ution du dél—i de r闙tivité ou de ™ert—ines des ™—E r—™téristiques de ™ette distri˜ution @minimum et m—ximum p—r exempleAF €our év—luer ™e dél—i de r闙tivitéD il est utile d—ns un Processus Cause Conséquence temps0 0 1 1 dr1 dr2 dr3 Commande Contrôleur Commutateur Ethernet Module d'E/S Cable Ethernet 100BaseT temps Fils pour signaux logiques Cause Conséqence Fig. 1. Délai de réactivité premier temps de le dé™omposer en dél—is élément—iresD qui ™orrespondent —ux dél—is induits p—r les di'érents ™ompoE s—nts de l9—r™hite™tureF …ne méthode ™l—ssique pour év—E luer le dél—i de r闙tivité ™onsiste —lors à sommer ™es déE l—is élément—ires ™—l™ulés indépend—mment de l— ™h—rge des ™ompos—nts et de leur dépend—n™eF €our éviter ™es —pproxim—tionsD ™9estEàEdire prendre en ™ompte l— ™h—rge et leur dépend—n™eD nous proposons une méthode de déE termin—tion du dél—i de r闙tivité ˜—sée sur l— simul—tion d9un modèle rése—u de €etri hiér—r™hique ™oloré temporisé @‚d€rg„A de l9—r™hite™ture de ™omm—ndeF ves ™omporteE ments de ™h—que ™ompos—nt sont modélisés isolément p—r un ‚d€rg„D en pren—nt en ™ompte les ressour™es p—rt—E gées @™ommut—teurs et modules d9iGƒA et en dé(niss—nt les ™ommuni™—tions possi˜les entre les ™ompos—ntsF h—ns un premier tempsD nous nous —ppliquerons à montrer l9in)uen™e des dél—is sur les perform—n™es de l— ™omm—nde des ƒihF €uisD l— méthode ™l—ssique de détermin—tion du dél—i de r闙tivité ˜—sée sur l— somm—tion de dél—is éléE ment—ires ser— présentéeF insuiteD le modèle ‚d€rg„ de l9—r™hite™ture ser— dét—illéF in(nD deux —r™hite™tures tests permettront de ™omp—rer ™es deux méthodes et de ™on™lure sur l— v—lidité des hypothèses f—ites pour ™h—™uneF II. Réactivité des architectures de commande A. Architectures de commande distribuées sur Ethernet ƒeules les topologies de rése—u de type ithernet ™omE mutéD ™9estEàEdire ™ompren—nt uniquement des ™ommut—E teurs ™omme ™ompos—nts rése—ux —™tifsD sont étudiéesF he plusD l9étude présentée se limite —ux systèmes de ™omm—nde ™omposés de ™ontrôleurs industriels à moniteur périodique et de modules d9iGƒ déportéesF ves ™ontrôleurs é™h—ngent leurs données @v—leurs d9iGƒA —ve™ les modules d9iGƒ vi— le rése—u ithernet ™ommutéF ges é™h—nges se font selon un proto™ole ™lientGserveurD d—ns notre ™—s wod˜us „g€Gs€F ve ™oupleur ithernet du ™ontrôleur est le ™lient t—ndis que les modules sont les serveursF get —rti™le tr—ite plus p—rti™ulièrement des ™ontrôleurs moE dul—ires @un module g€… et un module ithernetAD des moE dules d9iGƒ déportées serveur ithernet et des ™ommut—E teurs ithernet s—ns qu—lité de servi™eF ve ™ontrôleur — deux —ppli™—tionsD une p—r moduleD le moniteur d9exé™ution péE riodique qui exé™ute le progr—mme de ™omm—nde d—ns le module g€… et le ™lient ithernet d—ns le module ithernet qui envoie ™y™liquement des requêtes —ux modules d9iGƒ déportés pour —™quérir l9ét—t des entrées et r—fr—î™hir l9ét—t des sortiesF ges deux —ppli™—tions s9exé™utent de m—nière —syn™hroneD en p—r—llèleD et ™ommuniquent p—r mémoire p—rt—géeF €our ™e qui est des ™ommuni™—tionsD nous nous fo™—lisons sur l— ™ou™he —ppli™—tion et en p—rti™ulier sur l— s™rut—tion ™y™lique des entrées et sortiesF B. Délai de réactivité ƒeul le dél—i de r闙tivité illustré p—r l— (gure I est étuE diéD ™9estEàEdire le ret—rd entre un événement ™—use généré p—r le pro™essus ™omm—ndé et l9événement ™onséquen™e fourni en réponse —u pro™essusF h—ns le ™—dre de l— ™omE m—nde des ƒihD deux ™—s de (gure peuvent être distingués pour l— v—lid—tion d9une —r™hite™ture p—r r—pport —ux spéE ™i(™—tions X ! le dél—i de r闙tivité ™on™erne une ™omm—nde ™y™liqueD —lors l— distri˜ution du ret—rd doit être év—luéeD ! ou il ™on™erne l— r闙tion à une —l—rmeD —lors l— ˜orne m—xim—le du dél—i su0t pour ™on™lureF ge dél—i de r闙tivité résulte à l— fois du ™omportement du ™ontrôleur et des proto™oles de ™ommuni™—tionF sl peut être exprimé de diverses m—nièresF xous —vons ™hoisi de l9étudier p—r une —ppro™he ˜—sée sur les ™ompos—ntsF einsi l— (gure P illustre l— dé™omposition du dél—i de r闙tivité en dél—is d—ns les ™ompos—nts de l9—r™hite™tureF v9o™™up—tion des difE férentes ressour™es d—ns le temps est représentée sous forme de ™hronogr—mmesD et les )è™hes verti™—les représentent les é™h—nges d9inform—tionD que ™e soit des tr—mes ithernet ou des sign—ux logiquesF in h—ut de ™ette représent—tion se trouve le pro™essusD Moniteur d'exécution périodique Scrutation cyclique des E/S Réseau Ethernet commuté Module d'E/S Processus Cause I1 Conséquence O1 Ecriture sorties contrôleur Lecture entrées Délai de réactivité : dri 3 5 6 7 8 d1 d2 d3 temps d4 d5 d6 d7 Traitement O1:=I1 2 1 4 d8 0 temps temps temps temps Fig. 2. Décomposition du délai de réactivité où se produit un événement ™—useD i™i sur l9entrée sIF v— )è™he I représente l— prop—g—tion de l9inform—tion du proE ™essus —u module d9iGƒD dont nous supposons l— durée néE glige—˜leF v9o™™up—tion pend—nt un temps d1 représente le dél—i dû —u (ltr—geF gette v—leur de l9entrée est envoyée d—ns l— pro™h—ine réponse @)è™he PA à une requête ven—nt du ™ontrôleurD —près un temps de tr—itement dP pour déE ™oder l— requête puis générer l— réponseF insuite l— tr—me p—sse un temps d3 d—ns le rése—u pour —rriver —u ™oupleur ithernet du ™ontrôleurF eprès extr—™tion des données de l— tr—me pend—nt une durée d4D les v—leurs d9entrées seE ront prises en ™omptes à l— pro™h—ine ph—se de le™ture des entrées du moniteur d9exé™ution du ™ontrôleurF eprès tr—iE tement puis mise à jour des sorties en mémoireD une tr—me ™onten—nt l9événement ™onséquen™e @l— v—leur de l— sortie yIA est envoyée dès le pro™h—in ™y™le de s™rut—tion @)è™he TAF v— tr—versée du rése—u durer— un temps d6D potentielE lement di'érent de d3D suiv—nt le tr—(™ inst—nt—né d—ns le rése—uF in(n —près tr—itement d—ns le moduleD l— sortie ser— mise à jourF sl est possi˜le de dé™omposer le dél—i de tr—E versée de ™h—que ™ompos—nt en trois p—rtiesD @ voir pigF Q pour le ™—s d9un module d9iGƒA X ! les dél—is intrinsèquesD d—ns le ™—s du module d9iGƒD d1 pour le (ltr—ge du sign—l logique et d2 pour le tr—iE tement de l— tr—me ithernetD ! le dél—i introduit p—r l9—syn™hronisme entre pro™essus p—r—llèlesD dasynch ! et le dél—i introduit p—r l9—ttente de disponi˜ilité de l— ressour™eD dchF d1 d2 0 2 1 dasynch dchModule d'E/S temps d1 MES Fig. 3. Causes de délai (exemple d'un module d'E/S) in not—nt d1 MES le dél—i p—ssé d—ns un module d9iGƒ entre l9o™™urren™e de sI @IA et l9envoi de l— tr—me @PAD on peut é™rire d1 MES = d1 + d2 + d1 asynch + d1 chF ve dél—i d1 asynch est l9—ttente d9une requêteD —u m—ximum un ™y™le de s™rut—E tion du ™lient noté DSCRD et d1 ch est l9—ttente de l— resE sour™e pro™esseur du serveur qui peut être en tr—in de tr—iter d9—utres requêtesF gon™ern—nt le ™lientD le temps entre l9—rrivée d9une réponse sur le ™oupleur et s— prise en ™ompte p—r le progr—mme de ™omm—nde peut être dé™omE posé ™omme d1 SCR = d4 + d1 asynch + d1 chF ve dél—i d1 asynchD qui est le temps entre d4 et l— )è™he RD représente l9—tE tente de l— pro™h—ine ph—se de le™ture des entrées p—r le progr—mme de ™omm—ndeF ge temps ser— don™ ™ompris entre zéro et une période d9exé™ution du progr—mme noE tée DCT RF ve dél—i d1 chD durée entre l— )è™he Q et d4D est l9—ttente de l— li˜ér—tion du pro™esseurD potentiellement o™E ™upé à tr—iter d9—utres tr—mesF v— dé™omposition du temps entre l9é™riture des sorties p—r le progr—mme @)è™he SA et l9envoi p—r le ™oupleur @)è™he TA peut être dé™rit p—r l9équ—E tion d2 SCR = d5 + d2 asynch + d2 chF s™iD d2 asynch représente l9—ttente du pro™h—in envoi de requête vers le module lié à l— sortie yIF ge temps ser— don™ ™ompris entre zéro et un ™y™le de s™rut—tion DSCRF ƒur l— (gure PD l— somme d2 asynch + d2 ch ™orrespond —u temps entre l— )è™he S et d5F €our ™e qui est du dél—i dû —u ™ontrôleur dCT RD il su0t de prendre en ™ompte l— période d9exé™ution du progr—mmeD d9où dCT R = DCT RF sl est possi˜le de f—ire de même pour ™h—que ™ommut—teur du rése—u ithernetF €our des r—isons de lisi˜ilitéD l— (gure P présente dire™tement le dél—i résulE t—nt de l— tr—versée de l9ensem˜le du rése—uD p—r exemple entre P et Q dRES = d3F ƒi tous ™es dél—is sont déterminésD —lors le dél—i de r闙tivité en est l— sommeD ™9estEàEdire dr = d1 MES +d1 RES +d1 SCR +DCT R +d2 SCR +d2 RES +d2 MES —ve™ les termes de type d1 XY Z @respe™tivement d2 XY ZA qui représentent les dél—is induit p—r le ™ompos—nt ˆ‰ lors de l— ™ommuni™—tion du pro™essus vers le ™ontrôleur @resE pe™tivement du ™ontrôleur vers le pro™essusAF III. Modèle classique : sommation des délais élémentaires v— se™tion pré™édente présente le dél—i de r闙tivité ™omme une somme de dél—is induits p—r ™h—™un des ™omE pos—ntsF ges dél—is sont eux même dé™ompos—˜les en déE l—is intrinsèquesD ™—r—™téristiques des ™ompos—ntsD et exE trinsèquesD dus à des —syn™hronismes et des p—rt—ges de resE sour™esF v— méthode ™l—ssique présentée prend en ™ompte les ™—r—™téristiques des ™ompos—nts et les —syn™hronismesF ille introduit deux hypothèsesD l— première est l— ™h—rge nulle des ™ompos—nts et l— deuxième est l9indépend—n™e des sour™es de dél—iF gette dernière hypothèse se tr—duit p—r un dél—i de r闙tivité minimum qui est l— somme des déE l—is élément—ires minimumD ™9estEàEdire en ™onsidér—nt une syn™hronis—tion p—rf—iteD dasynch = 0F he mêmeD le dél—i de r闙tivité m—ximum est ™—l™ulé ™omme l— somme des déE l—is élément—ires m—ximumD ™9estEàEdire en ™onsidér—nt un —syn™hronisme m—xim—lF gepend—nt ™ette méthode ne tient p—s ™ompte du p—rt—ge de ressour™esD don™ d—ns le ™—l™ul du dél—i de r闙tivité l— ™ompos—nte dch est toujours nulleD quel que soit le ™ompos—nt impliquéF ves équ—tions suiE v—ntes r陗pitulent les dél—is élément—ires minimumD —ve™ dasynch = 0 et dch = 0 X d1 MESmin = d1 + d2 ; d2 MESmin = d7 + d8 d1 RESmin = d2 RESmin = d3 d1 SCRmin = d4 ; d2 SCRmin = d5 dCT Rmin = DCT R €uis suivent les dél—is élément—ires m—ximumD —ve™ dasynch —u m—ximum et dch = 0 X d1 MESmax = d1 + d2 + DSCR ; d2 MESmax = d7 + d8 d1 RESmax = d2 RESmax = d3 d1 SCRmax = d4 + DCT R ; d2 SCRmax = d5 + DSCR dCT Rmax = DCT R in e'etD l9—syn™hronisme m—xim—l sur le module d9iGƒ est donné p—r dasynch = DSCRD puis pour les s™rut—tions d9entrées et sortiesD p—r dasynch = DCT R pour l9—ttente de l— le™ture des entréesD et dasynch = DSCR pour l9—ttente de l9envoi d9une requêteF eu (n—lD les v—leurs m—xim—le et minim—le du dél—i s9expriment —insi X drmin = d1 + d2 + 2 ∗ d3 + d4 + DCT R + d5 + d7 + d8 drmax = drmin + DCT R + 2 ∗ DSCR gette méthode permet don™ de ™—l™uler les v—leurs exE trêmes du dél—i de r闙tivité en ™onn—iss—nt uniquement les données intrinsèques —ux ™ompos—nts @dél—i de (ltr—ge et de tr—itement des tr—mes d—ns les modules d9iGƒD dél—i de tr—versée d9un ™ommut—teur à videD dél—i de tr—itement des tr—mes d—ns les ™oupleursD ™y™le de s™rut—tion et péE riode du progr—mme du ™ontrôleurA déterminées à p—rtir de do™ument—tions ™onstru™teur ou d9expériment—tionsF IV. Modèle Dynamique : Réseau de Petri Hiérarchique Coloré Temporisé €our prendre en ™ompte l— ™h—rge de l9—r™hite™ture et les phénomènes de syn™hronis—tion qui s9y produisentD nous proposons un modèle dyn—mique simul—˜leF ve form—lisme retenu est ™elui des rése—ux de €etri hiér—r™hiques ™olorés temporisés @‚d€rg„A dé(ni p—r tensen @‘V“A et supporté p—r le logi™iel de simul—tion g€x„oolsF A. Structure du modèle global h—ns un ‚d€ hiér—r™hiqueD une tr—nsition est une —˜sE tr—™tion du ™omportement du nive—u inférieurF yn utilise ™e pouvoir de modélis—tion pour —sso™ier une tr—nsition à ™h—que ™l—sse de ™ompos—nt m—tériel de l9—r™hite™tureF einsi —u plus h—ut nive—u de représent—tion du modèle @(gF RA on retrouve une tr—nsition pour dé™rire le ™omporE tement des pro™esseurs des ™ontrôleurs g€…D des ™oupleurs de ™ommuni™—tion ithernet des ™ontrôleurs ith•˜o—rdD des modules d9iGƒ sy•moduleD des ™ommut—teurs ƒwit™hD et une émul—tion du pro™essus €ro™ess pour générer un s™éE n—rio de solli™it—tion de l9—r™hite™ture de ™omm—ndeF intre ™es tr—nsitionsD les pl—™es €ro™ess•eventD fus•ex™h—nge Fig. 4. Vue globale du modèle et ithernet•fr—me modélisent les é™h—nges de données p—r des é™h—nges de jetonsF ves jetons de type i† @d—ns les pl—™es fus•ex™h—nge et €ro™ess•eventA représentent des événementsD soit générés p—r le pro™essus à destin—tion d9un ™ontrôleurD soit générés p—r un ™ontrôleur à destin—tion du pro™essusF ves jetons de type i„rp‚ewi @d—ns l— pl—™e ithernet•fr—meA modélisent les requêtes wod˜us en™—psuE lées d—ns des tr—mes ithernet ™ir™ul—nt d—ns le rése—u ™omE mutéF €our des r—isons pr—tiques il n9est p—s possi˜le de dét—iller l9ensem˜le du modèle d—ns ™e p—pierF xous —vons don™ ™hoisi de nous limiter à une ™l—sse de ™ompos—nts repréE sent—tifs de ™e type d9—r™hite™tures X les ™oupleurs itherE net des ™ontrôleurs @tr—nsition ith•˜o—rdA —ve™ leur ™lient wod˜usF sl est à noter que le modèle glo˜—l — été v—lidé expérimenE t—lement ‘W“F B. Modélisation du comportement des coupleurs Ethernet €our f—™iliter les expli™—tions du ™omportement des ™ouE pleursD un exemple support est retenuF sl est ™omposé de deux ™ontrôleurs qui s™rutent respe™tivement trois et deux modules d9iGƒ @(gF SAF gh—que ™ompos—nt est identi(é p—r un entier unique d—ns l9—r™hite™tureF €—r exempleD le ™ouE pleur de ™ommuni™—tion @ith•˜o—rdA du ™ontrôleur en h—ut et à g—u™he de l— (gure S est identi(é p—r le numéro IF Switch 5 IO_module 6 Eth_board 1 IO_module 7 IO_module 82 Eth_board CPU 3 CPU 3 CPU 3 CPU 3 4 CPU Données intrinsèques aux 2 coupleurs (Eth_board) - durée de génération d'une requête Modbus : 300 µs - durée de traitement d'une réponse Modbus : 300 µs Coupleur (Eth_board) Liste des modules scrutés (IO_module) Durée mini du cycle de scrutation 1 2 6, 7, 8 7, 8 5 ms 10 ms Données de configuration de l'architecture Fig. 5. Exemple support fFI ƒtru™ture du modèle du ™oupleur ithernet h—ns le modèle glo˜—l @(gF RA les interf—™es de l— tr—nsition hiér—r™hique ith•˜o—rd sont les deux pl—™es fus•ex™h—nge et ithernet•fr—meF yn retrouve ™es deux pl—™es d—ns le modèle dét—illé de l— tr—nsition ith•˜o—rd présenté (gure TF ge modèle in™lus ég—lement une tr—nE sition hiér—r™hique ith˜•„g€•s€•l—yers qui modélise le ™omportement de l— pile „g€Gs€ et le médi— ithernet des ™oupleurs de ™ommuni™—tionsF v— pl—™e i„rf•g€… représente l— disponi˜ilité de l— resE sour™e g€… de ™h—que ™oupleurF ille —™™ueille don™ des jetons de type i„rf @des entiers qui identi(ent les ™ouE pleursA et son m—rqu—ge initi—lD ™omposé des deux jetons I et P en un exempl—ire ™h—™un @I–ICCI–PAD indique que les g€… des ™oupleurs ithernet I et P sont disponi˜lesF v— su™™ession des pl—™es et tr—nsitions „ID €ID „P et €P déE ™rit le regroupement et l9en™—psul—tion d—ns des requêtes wod˜us des événements que le ™ontrôleur émet vers le proE ™essusF he m—nière symétrique l— su™™ession des pl—™es et tr—nsitions €QD „QD €R et „R dé™rit que les événements émis p—r le pro™essus sont extr—its des réponses wod˜us puisD mis à l— disposition du moniteur d9exé™ution du ™ontrôleur vi— le ˜us d9é™h—ngeF ves pl—™es et tr—nsitions €VD „TD €UD €SD „S et €T @en gris d—ns le modèleA —ssurent le séquen™ement temporel des reE quêtes wod˜us qui s™rutent les modules d9iGƒF fFP wodélis—tion de l9—syn™hronisme —ve™ le moniteur d9exé™ution sndépend—mment du ™y™le de s™rut—tion des modules d9iGƒD l— tr—nsition „I regroupe —u fur et à mesure de leur —rrivée les événements ev d—ns des listes dédiées à ™h—que p—ire émetteur @un ™oupleur ithernet eth˜A desE tin—t—ire @un module d9iGƒ iomAF ve type de jeton d—ns €I est i„rfxsywxi†vD et représente le produit ™—rtéE sien des ensem˜les i„rf @type qui identi(e les ™oupleursAD syw @type qui identi(e les modulesA et i†v @liste ordonE née de jetons evAF eu fr—n™hissement de „I un événement ev est —sso™ié —u triplet @eth˜DiomDevlA ™orrespond—nt grâ™e à l— g—rde de tr—nsition non expli™itée gu—rd„IF ve poids @eth˜DiomDev X XevlA de l9—r™ „IEb€I indique que le jeton @eth˜DiomDevlA extr—it de €I y est repl—™é en —jout—nt à l— liste evl l9événement ev issu de l— pl—™e fus•e™h—nge grâ™e à l9opér—teur  XX @p—r exemple evQXX‘evPDevI“ devient l— liste ‘evQDevPDevI“AF ve m—rqu—ge initi—l de €I ™omprend S jetons ™orrespond—nt à ™h—que p—ire utile ™oupleurEmodule —ve™ une liste vide d9événements @‘ “AF he f—çon symétrique „R extr—it de €R un jeton @eth˜DiomDevXXevlA pour envoyer vers le moniteur d9exé™ution l9événement ev et repl—™er d—ns €R un jeton @eth˜DiomDevlA pour lequel l— liste d9événement est diminuée d9un événementF fFQ wodélis—tion du tr—itement des requêtes wod˜us vorsque le moment est venu @™e moment est déterminé p—r l— pl—™e €T qui ser— dé™rite ultérieurementAD l— tr—nsiE tion „P prélève d—ns €I l— liste des événements evl à tr—nsE mettre du ™oupleur eth˜ vers le module iom et ™onstruit une requête wod˜us modélisée p—r le triplet @eth˜DiomDevlAD ™9estEàEdire @™lientD serveurD liste d9événementsAF gette reE quête est empilée d—ns une liste pspy pl—™ée d—ns €P qui ™ontient des jetons de type ™ouple X @ ™oupleurD liste de requêtesAF h—ns l— tr—nsition hiér—r™hique qui gère l— pile „g€Gs€D l9opér—teur  X X est utilisé pour dépiler p—r l— g—u™he de l— liste les requêtes wod˜usF sl f—ut don™ empiler p—r l— droite les requêtes —u nive—u de „P pour o˜tenir l— str—tégie pspy désiréeF gel— est o˜tenu p—r l9opér—teur de ™on™—tén—tion de listes ¢¢F einsi l9expresE sion m˜)¢¢‘@eth˜DiomDevlA“ ™on™—tène à droite de l— liste Fig. 6. Modèle du module de communication Eth_board des requêtes m˜)D une liste ™omposée d9une seule requêteF yn rem—rquer— que l— ™onstru™tion d9une requête wodE ˜us @modélisée p—r „PA né™essite l— ressour™e g€… @pl—™e i„rf•g€…A et dure 300µs soit QHH unités de temps du moE dèle @dCQHHAF he f—çon symétriqueD des réponses wod˜us @eth˜DiomDevlA sont org—nisées en listes d—ns €QF „Q extr—it l— liste les événements evl qu9elle empile d—ns €RF fFR wodélis—tion du ™y™le de s™rut—tion e ™h—que dé˜ut de ™y™le de s™rut—tion d9un ™oupleur ™lient @„ir de „SAD les requêtes wod˜us à destin—tion de ™h—que module serveur sont toutes envoyées à l— suite les unes des —utresF ves réponses reviennent —u fur et à meE sure et d—ns un ordre dépend—nt des disponi˜ilités des resE sour™esF vorsqu9elles sont toutes revenues @„ir de „TAD un nouve—u ™y™le de s™rut—tion redém—rre si l— v—leur de temps de ™y™le ™on(gurée est —tteinte ou dép—sséeF v— pl—™e €S ™ontient les ™ouples de ™oupleurs ithernet et de listes de module d9iGƒ à s™ruterF ve m—rqu—ge initi—l dé™rit que le ™oupleur I s™rute les modules TD U et V @un jeton @ID‘TDUDV“AAD et que le ™oupleur P s™rute les modules U et V @un jeton @PD‘UDV“AAF v— pl—™e €U ™ontient les ™oupleurs dont le ™y™le ™our—nt est terminéF ve fr—n™hissement de „S ™h—nge l— d—te —sso™iée —u jeton de €S impliqué d—ns le tir —u moyen de l9expression pl—™ée sur l9—r™ „SEb€SF sl s9—git d9une exE pression ™onditionnelle qui dépend du ™oupleurF einsi pour le ™oupleur ID le jeton —ur— ™omme nouvelle d—te l— d—te de fr—n™hissement de „S —ugmentée de SHHH unités de temps soit 5msD t—ndis que pour le ™oupleur PD l— nouvelle d—te du jeton ser— l— d—te de fr—n™hissement de „S —ugmentée de IHHHH unités de temps soit 10msF v— pl—™e €V —ssure le ™ompt—ge du nom˜re de réponses i pour ™h—que ™oupleur eth˜F vorsque le nom˜re de réponses i est ég—l à l— t—ille de l— liste des modules s™rutés @p—r exemple ialenght@‘UDVDW“A pour le ™oupleur IAD l— g—rde de l— tr—nsition €T permet le fr—n™hissement de ™ette dernière et modélise —insi l— (n du ™y™le en ™oursF V. Application €our ™omp—rer les deux —ppro™hes @somm—tion de dél—is élément—ires et simul—tion d9un modèle dyn—miqueAD deux ™on(gur—tions d9une même —r™hite™ture @pigF UA sont étuE diéesF ves périodes des di'érents ™ompos—nts ont été (xées —ve™ une résolution d9une mi™rose™onde @période du ™ontrôE leur I d—ns l— ™on(gur—tion I X ITFHHQ msA —(n d9éviter des syn™hronis—tions non justi(ées dur—nt l— simul—tionF ges deux ™on(gur—tions @t—˜le sA sont ™—r—™téristiques des —r™hite™tures étudiéesF h—ns l— ™on(gur—tion ID le ™ontrôE leur I joue le rôle de superviseur en s™rut—nt toutes les entrées et sorties déportées à une l—rge période @environ IPH msAF h—ns l— deuxième ™on(gur—tionD les trois ™ontrôE leurs s™rutent ™h—™un neuf modules d9iGƒ —ve™ des périodes pro™hesD ils ont ™ette fois tous un rôle de ™ontrôleurF Fig. 7. Architecture test ves résult—ts de l— simul—tion de l— ™on(gur—tion ID pour VHHH dél—is simulésD sont présentés pigF VF Fig. 8. Résultat de simulation h—ns l— t—˜le ss sont présentés les dél—is de r闙tivité minimum et m—ximum o˜tenus p—r ™h—que modèle pour les deux ™on(gur—tions testsF conf. 1 conf. 2 période contrôleur 1 (C1) 16.003 7.001 période contrôleur 2 (C2) 18.000 7.000 période contrôleur 3 (C3) 20.005 9.000 durée mini de scrutation de C1 120.007 13.000 durée mini de scrutation de C2 45.000 5.500 durée mini de scrutation de C3 45.003 17.001 délai commutateur 0.1 délai modules d'E/S 0.72 modules d'E/S scrutés par C1 1 à 24 1 à 9 modules d'E/S scrutés par C2 1 à 14 8 à 17 modules d'E/S scrutés par C3 11 à 24 16 à 24 TABLE I Configuration temporelle en millisecondes conf. 1 conf. 2 min max min max modèle classique (1) 19.84 127.84 8.84 26.84 modèle RdPHCT (2) 44.77 92.06 11.85 34.97 erreur relative (%) par 55.68 38.86 25.42 23.25 rapport au modèle (2) TABLE II Comparaison des délais minimum et maximum évalués par les deux méthodes (en millisecondes) ‚—ppelons que d—ns le ™—dre de l— ™omm—nde des ƒihD deux ™—s nous intéressentD l— réponse à une ™omm—nde ™yE ™lique ou à une —l—rmeF h—ns le ™—s d9une ™omm—nde ™yE ™liqueD le ™on™epteur s9intéresse à l— rép—rtition des v—leurs et à des ™—r—™téristiques st—tistiques de ™ette rép—rtitionF „—ndis que d—ns le ™—s d9une —l—rmeD le ™on™epteur s9intéE resse —lors à s— v—leur m—xim—leF €our une ™omm—nde ™y™liqueD le modèle ™l—ssique permet uniquement l9év—lu—tion du minimumD du m—ximum et de l— moyenne —ve™ l9hypothèse d9une rép—rtition uniforme des dél—isD —lors que l— simul—tion permet d9o˜tenir l— distri˜uE tion ™omplèteF ves éléments ™omp—r—˜les sont les v—leurs minim—lesD m—xim—les et l9étendue des v—leursF €our les deux ™on(gur—tions les 陗rts sont signi(™—tifs entre les deux modèlesD jusqu9à plus de SS7 pour le dél—i minimum de l— ™on(gur—tion IF in ™e qui ™on™erne l9étendue des v—E leursD pour l— ™on(gur—tion ID elle est ™—r—™térisée p—r un f—™teur T entre les extremum en utilis—nt l— méthode ™l—sE sique —lors que ™e f—™teur est de P si l9on utilise notre méE thodeF einsiD en utilis—nt le modèle ™l—ssiqueD une ™on(guE r—tion ™onven—˜le pourr—it être rejetéeF €our une —l—rmeD les deux modèles permettent le ™—l™ul d9une ˜orne m—xim—leF gepend—ntD d9une p—rtD les résulE t—ts pour l— ™on(gur—tion I donnent une di'éren™e de QW7 entre les deux m—xim—F gel— pourr—it ™onduire à refuser une —r™hite™ture qui ™onvientF h9—utre p—rtD l— ™on(gur—tion P donne une di'éren™e de PQ 7 environ entre les m—xim—D m—is ™ette foisD le dél—i m—ximum ™—l™ulé p—r somm—tion ne m—jore p—s ™elui déterminé p—r simul—tionF in e'etD ™omme il —v—it été mentionné d—ns l— se™tion sssD ™e modèle ne perE met p—s d9—voir une ˜orne m—ximum du dél—i de r闙tivité ™—r il ne tient p—s ™ompte du p—rt—ge de ressour™esF h—ns ™e ™—sD le modèle ™l—ssique pourr—it ™onduire à —™™epter une —r™hite™ture —lors qu9il ne répond p—s —ux spé™i(™—tionsF ves hypothèses du modèle ™l—ssiqueD indépend—n™e des déE l—is et nonEp—rt—ge des ressour™esD sont trop fortes et ne permettent p—s de représenter le ™omportement du sysE tèmeF v— simul—tion du modèle ‚d€rg„ donne des résulE t—ts plus ™omplets ™—r ™e modèle prend en ™ompte les deux m陗nismes négligés p—r les hypothèses du modèle ™l—sE siqueF ue le dél—i de r闙tivité ™on™erne une ™omm—nde ™y™lique ou une réponse à une —l—rmeD il ™onvient don™ de privilégier l— modélis—tion et l9—n—lyse p—r ‚d€rg„F VI. Conclusion xous nous sommes intéressés i™i à l— r闙tivité des —r™hiE te™tures de ™omm—nde distri˜uées sur des rése—ux ithernet à proto™oles ouverts de type ™lientGserveurF ille est ™—r—™téE risée p—r le dél—i entre l9o™™urren™e d9un événement ™—use ven—nt du pro™essus et l9o™™urren™e de l9événement ™onséE quen™e ™orrespond—nt —u nive—u du pro™essusD —ppelé dél—i de r闙tivitéF xous —vons proposé d9év—luer ™e dél—i p—r simul—tion de modèles en ‚d€rg„D ™e qui permet de prendre en ™ompte les m陗nismes de p—rt—ge des ressour™es et de p—r—llélisme de pro™essusF v— ™omp—r—ison des résult—ts o˜tenus p—r siE mul—tion —ve™ un ™—l™ul ™l—ssique de somm—tion des dél—is — montré l9import—n™e de ™es deux m陗nismesD l— né™essité de les prendre en ™ompteD et p—r ™onséquent l9intérêt de l— modélis—tion du ™omportement dyn—mique p—r ‚d€rg„F heux perspe™tives se dessinentF h9un point de vue s™ienE ti(queD nous tr—v—illons —™tuellement —u ™oupl—ge de l— siE mul—tion —ve™ une méthode formelleD ™e qui permettr—it d9o˜tenir des ˜ornes m—ximum et minimum stri™tesD en se ˜—s—nt sur ‘IH“F h9un point de vue ingénierieD les modèles en ‚d€rg„ sont déli™—ts à m—nipuler et doivent être réE servés à des expertsF €our ™el—D un outil d9—ssist—n™e pour ™on™epteur d9—r™hite™tureD ˜—sé sur ™ette modélis—tion est en ™ours de développementF Références [1] Paolo Ferrari, Alessandra Flammini, Daniele Marioli, et Andrea Taroni. Experimental evaluation of PROFINET performances. ‡pgƒHR, Vienna, Austria, September 2004. [2] Stefano Vitturi. DP-Ethernet : the Probus DP protocol im- plemented on Ethernet. gomputer gommuni™—tions, 26 :1095 1104, 2003. [3] Jurgen Jasperneite et Peter Neumann. How to guarantee real- time behavior using Ethernet. sxgywHR, Salvador, Brasil, April 2004. [4] Nicolas Krommenacker, Jean-Philippe Georges, Eric Rondeau, et Thierry Divoux. Designing, modelling and evaluating swit- ched Ethernet networks in factory communication systems. Ist ‡orkshop on ‚„vse, Vienna, Austria, June 2002. [5] Kyung Chang Lee et Suk Lee. Performance evaluation of swit- ched Ethernet for real-time industrial communications. gompuE ter ƒt—nd—rds 8 snterf—™es, 24(5) :411423, November 2002. [6] Yeqiong Song. Time constrained communication over switched Ethernet. pe„9PHHI, Nancy, France, November 2001. IFAC, El- sevier Scientic. [7] Belgacem Ben Hédia, Fabrice Jumel, et Jean-Philippe Babau. Qualité de service des pilotes d'équipements pour les systèmes d'acquisition de données. wƒ‚HS, pages 4762, Grenoble, France, October 2005. [8] K. Jensen. goloured €etri xetsF f—si™ gon™eptsD en—lysis weE thods —nd €r—™ti™—l …se, volume 1, Basic Concepts. Springer- Verlag, monographs in theoretical computer science edition, 2nd corrected printing 1997. [9] Gaëlle Poulard, Bruno Denis, et Jean-Marc Faure. Modélisation par réseau de Petri coloré des architectures de commande dis- tribuées sur réseau de terrain Ethernet et TCP/IP. wyƒswHR, pages 405412, Septembre 2004. [10] Daniel Witsch, Birgit Vogel-Heuser, Jean-Marc Faure, et Gaëlle Marsal. Performance analysis of industrial Ethernet networks by means of timed model-checking. sxgyw¡PHHT, May 2006.