Evaluation de l`influence d`un réseau de communication sans fil sur

Evaluation de l'influence d’un réseau de
communication sans fil sur la commande d’un SED
Gilbert Habib(1), Pascale Marangé(2), Jean François Pétin(1), Thierry Divoux(1)
(1) Centre de Recherche en Automatique de Nancy (CRAN)
Nancy-Université, CNRS, Campus Scientifique, BP 239, 54506 Vandoeuvre-lès-Nancy
{Gilbert.Habib, Jean-Francois.Pétin, Thierry.Divoux}@cran.uhp-nancy.fr
(2) Centre de recherche en STIC (CReSTIC), URCA, IUT de Troyes - 9 rue du Quebec, 10026 Troyes
{[email protected]}
- CRAN -
1
Plan
•Introduction: Système Discret Contrôlé en Réseau
•Problématique
•État de l’art
•Cas d’étude
•Approche analytique
•Modélisation Matlab Simulink
•Modélisation Opnet
•Conclusion
- CRAN -
2
Système Discret Contrôlé en Réseau (SDCR)
•
SDCR : ensemble des lois de commande discrètes pilotant une partie opérative
•
à travers un réseau de communication.
L’implantation de ces lois est supportée par un ensemble d’Automates
Programmables Industriels (API) et/ou de boîtiers d’entrées/sorties déportés
échangeant de l’information
•L’API lit les variables d’entrées, les traite et met à jour les variables de sorties selon
un cycle caractérisé par une période PAPI.
•Tous les équipements en réseau sont munis d’un coupleur de communication
caractérisé par un cycle de scrutation nommé Pcarte.
- CRAN -
3
Problématique
•
Adéquation Qualité de service Réseau et Commande SED
•
•
•
Impact de la QoS réseau sur les propriétés de la commande (déterminisme, sûreté) en
particulier pour les réseaux non déterministes (Ethernet, réseaux sans fil, …)
Impact des paramètres réseau (priorités, taille des paquets, nb de retransmission) et des
paramètres de commande (structure de la commande, temps de cycle automate, …) sur
la QoS de l’application globale (SDCR)
Modèles et outils de représentation dédiés
•
Modèles
•
•
•
De nature déterministe pour la commande des SED
De nature stochastique pour la modélisation du réseau de communication
Outils
•
•
Matlab Simulink (TrueTime) orienté « commande » avec modélisation grossière du réseau
Opnet orienté « réseau », a priori non adapté pour la modélisation de la commande (réutilisation
du formalisme EFSM pour la modélisation de la commande ?)
Objectif : proposer une approche de conception et de validation conjointe
commande discrète / réseau pour des SDCR distribués sur un réseau sans fil
802.11e (WIFI)
- CRAN -
4
Etat de l ’art
•
Approches orientées « réseau »
•
•
•
•
•
Modèles stochastiques ou basés sur le calcul réseau (dans le pire des cas)
Applications aux systèmes continus contrôlés en réseau
[Georges et al., 2005], [Tipsuwan et al., 2009], …
Problème: pas ou peu de prise en compte de la commande
Approches orientées « commande »
• Modèles SED de la partie commande (automates, RdP, …)
• [Marsal et al., 2005], [Addad et al., 2008], …
• Problème : modélisation très grossière du réseau, souvent sous la forme de
retards matérialisés par un état ou une place
•
Approches conjointes
• Modèles SED + modèles stochastiques du réseau
• [Greifeneder et al.2008], [Bordbar et al. 2005],…
• Problèmes : Outils propriétaires, paramètres réseaux négligés
- CRAN -
5
Cas d’étude
•
Comportement étudié:
ƒ
Propriétés de type « sécurité » : par exemple évitement de collisions entre les 2 vérins
ƒ
Propriétés de type « Performances temporelles » : en particulier, temps TS qui représente le
temps entre le départ de S1 et l’arrêt du vérin espéré sur S2 (émission de l’ordre de sortie B=1,
émission du signal capteur S2, émission de l’ordre d’arrêt B=0 )
Ts=t+T+Tinertie
o
o
o
t: le temps où le vérin arrive au capteur S2
T: délai de bout en bout (entre l'occurrence de l’événement généré par le capteur S2 et la réception par
un actionneur (vérin) du signal de commande émis(ordre d’arrêt))
Tinertie: temps nécessaire pour que le vérin s’arrête après recevoir l’ordre d’arrêt
- CRAN -
6
Cas d’étude
•
Modélisation
ƒ
(1) Calcul analytique dans le pire des cas
ƒ
(2) Modélisation sur Matlab Simulink
ƒ
(3) Modélisation sur Opnet
- CRAN -
7
(1) Calcul de délai de bout en bout
T
T est un délai entre l'occurrence de l’événement généré par un capteur et la
réception par un actionneur du signal de commande émis
T=??
- CRAN -
8
(1) Calcul de délai de bout en bout
T
T=a+
•a représente le temps pour que le coupleur de communication prenne en compte cet événement (=m1*Pcarte)
- CRAN -
9
(1) Calcul de délai de bout en bout
T
T=a+d1+
•a représente le temps pour que le coupleur de communication prenne en compte cet événement (=m1*Pcarte)
•d1 est le temps de transmission sur le réseau de communication
- CRAN -
10
(1) Calcul de délai de bout en bout
• Calcul de d1 [Habib et al. 2009]
• Réseau Wifi en mode infrastructure EDCA
• Couche MAC selon CSMA / CA avec tirage aléatoire d’un temps d’attente
(backoff time) pour accéder au médium en cas d’indisponibilité
Donnée
Donnée+Ack
Station 1
AIFS
Donnée
Station 2
5 4 3
2 1
AIFS
Donnée+Ack
AIFS
Donnée
Station 3
3 2 1
• Délai maximal
Donnée+Ack
AIFS
• Max(k)=∑{(AIFS+Backoff)j+F(x(j),r(j))+SIFS+ACK)}+(AIFS+Backoff)k + F(x’(k),r’(k))
avec j = Stations qui veulent envoyer des paquets.
F(x,r) = temps nécessaire pour envoyer un paquet de taille x avec un débit r
- CRAN -
11
(1) Calcul de délai de bout en bout
T
T=a+d1+b+
•a représente le temps pour que le coupleur de communication prenne en compte cet événement(=m1*Pcarte)
•d1 est le temps de transmission sur le réseau de communication [Habib et al. 2009]
•un autre retard b est dû au temps de cycle de l’API (=m2*PAPI) ( délai d’attente pour la prise en compte par l’API)
- CRAN -
12
(1) Calcul de délai de bout en bout
T
T=a+d1+b+k*PAPI+
•a représente le temps pour que le coupleur de communication prenne en compte cet événement(=m1*Pcarte)
•d1 est le temps de transmission sur le réseau de communication [Habib et al. 2009]
•un autre retard b est dû au temps de cycle de l’API (=m2*PAPI)
•message est ensuite traité par l’API, l’exécution des lois de commande pouvant nécessiter plusieurs cycles (k)
- CRAN -
13
(1) Calcul de délai de bout en bout
T
T=a+d1+b+k*PAPI+c+
•a représente le temps pour que le coupleur de communication prenne en compte cet événement(=m1*Pcarte)
•d1 est le temps de transmission sur le réseau de communication [Habib et al. 2009]
•un autre retard b est dû au temps de cycle de l’API (=m2*PAPI)
•message est ensuite traité par l’API, l’exécution des lois de commande pouvant nécessiter plusieurs cycles (k)
•un retard c dépendant de la période de scrutation du coupleur de communication (=m3*Pcarte)
- CRAN -
14
(1) Calcul de délai de bout en bout
T
T=a+d1+b+k*PAPI+c+d2
•a représente le temps pour que le coupleur de communication prenne en compte cet événement(=m1*Pcarte)
•d1 est le temps de transmission sur le réseau de communication [Habib et al. 2009]
•un autre retard b est dû au temps de cycle de l’API (=m2*PAPI)
•message est ensuite traité par l’API, l’exécution des lois de commande pouvant nécessiter plusieurs cycles (k)
•un retard c dépendant de la période de scrutation du coupleur de communication (=m3*Pcarte)
•d2 est le temps de transmission sur le réseau de communication [Habib et al. 2009]
0≤m1, m2, m3 ≤1
- CRAN -
15
(1) Calcul de Tmin et Tmax
T=a+d1+b+k*PAPI+c+d2
•a représente le temps pour que le coupleur de communication prenne en compte cet événement(=m1*Pcarte)
•d1 est le temps de transmission sur le réseau de communication [Habib et al. 2009]
•un autre retard b est dû au temps de cycle de l’API (=m2*PAPI)
•message est ensuite traité par l’API, l’exécution des lois de commande pouvant nécessiter plusieurs cycles (k)
•un retard c dépendant de la période de scrutation du coupleur de communication (=m3*Pcarte)
•d2 est le temps de transmission sur le réseau de communication [Habib et al. 2009]
0≤m1, m2, m3 ≤1
Cas 1: T=Tmin
Cas 2: T=Tmax
m1=m2=m3=0
d1=d1min
d2=d2min
m1=m2=m3=1
K=kmax
d1=d1max
d2=d2max
K1=K+1
T ≤ Pcarte +d1max+PAPI+k1*PAPI+Pcarte +d2max
T ≥ d1min +PAPI+d2min
- CRAN -
16
(2) Modélisation sur Matlab / TrueTime
•
Matlab/Simulink
• Modèles SED: basé sur les StateCharts
• Modèles Réseau : basé sur la bibliothèque TrueTime
• Modèles stochastiques pour les couches MAC et PHY pour le WIFI
• Limites : cf. problématique (modélisation très grossière du réseau)
• Adaptation de la bibliothèque TrueTime pour une modélisation
plus fine du réseau
• Notion d’acquittement (non définie dans la bibliothèque actuelle)
• Introduction des entêtes MAC, PHY sur les paquets (non traité dans la
bibliothèque actuelle)
• Définition standardisée de la fonction qui définit le temps de transmission
physique d’un paquet sur le réseau (couche physique) (modélisé par une
fonction simple « taille des paquets/débit » dans la bibliothèque actuelle)
• Gestion des priorités (non définie dans la bibliothèque actuelle)
• …
- CRAN -
17
(2) Modélisation sur Matlab / TrueTime
a) API
b) Réseau
c) Partie Opérative
d) Modèle de l’environnement
- CRAN -
18
(2) Modélisation sur Matlab / TrueTime
a) API
Ce modèle décrit le fonctionnement de l’API. Il est représenté par trois modèles:
¾Lecture: il sert à lire les entrées depuis la carte d’E/S
¾Commande: il traite les informations, évolution de la commande
¾Ecriture: il mets à jour les sorties de l’API
- CRAN -
19
(2) Modélisation sur Matlab / TrueTime
b) Réseau
Le modèle du réseau est simulé en utilisant
la librairie TrueTime modifiée dans Matlab.
c) Partie Opérative
Elle est présentée en deux modèles:
Sens et Position
Voir plus [Thèse de P.Marangé, 2008]
- CRAN -
20
(2) Modélisation sur Matlab / TrueTime
d) Modèle d’environnement
Il gère l’ordre d’exécution des modèles de commande, de PO et de l’API
- CRAN -
21
Résultats de simulation sur TrueTime
¾ Conditions de simulation
¾ Recherche d’un nombre d’itération selon la variabilité des résultats (dans l’exemple,
une centaine d’itérations)
¾ Temps d’arrêt (Ts) du vérin en fonction de la taille des paquets et
de Pcarte
¾ 0.05<Pcarte<=0.11, le délai introduit par le réseau est important, d ’où un écart
important sur Ts en fonction de la taille des paquets.
¾ Pcarte>0.11, le réseau a peu d’influence sur le comportement global du système.
- CRAN -
22
Résultats de simulation sur TrueTime
•
Comparaison entre Tsmin, Tsmax analytiques et Ts simulé en
fonction de Pcarte
- CRAN -
23
(3) Modélisation sur OPNET
• OPNET
• Modèles réseaux : modèles stochastiques et/ou déterministes (EFSM :
Extended Finite State Machine))
• Equivalences entre EFSM et des modèles plus classiques en SED ‘ex
Statechart) ?
Modèle Statechart
Modèles OPNET
ƒEtat vert
: état dont la sortie ne nécessite
pas d’événement mais uniquement une condition
logique(boucle default si la condition n’est pas
validée)
ƒEtat rouge
: état dont la sortie nécessite
l’occurrence d’un événement
- CRAN -
24
(3) Modélisation sur OPNET
• Modélisation de la commande SED sous OPNET
• Modèles Réseau :
• Couches PHY, MAC
• Couche APPLICATION divisée en deux zones:
• Période de scrutation (zone 2)
• Primitives d’application décrites en EFSM (zone 1)
• Modèles Commande
Zone1
Zone 2
Couche MAC
• Modélisés en EFSM dans comme une application de type zone 1
Couche Physique
Commande SED
3 couches OSI
- CRAN -
25
(3) Modélisation sur OPNET
- CRAN -
26
(3) Résultats sur OPNET
Simulation en faisant varier la taille des paquets, la période de scrutation des coupleurs (paramètres du réseau),
la taille des capteurs et leur espacement (partie opérative). Dans les exemples Cas1 et Cas2 ci-dessous, le
nombre de retransmission autorisées, le débit le temps de cycle API ont été maintenus à une valeur constante.
- CRAN -
27
Conclusion
• Comparaison des résultats
• Résultats similaires entre OPNET et TrueTime pour tous les scénarii simulés
• Résultats conformes aux résultats analytiques
• TrueTime présente toujours des limitations
• Impossibilité de définir des paramètres et attributs spécifiques (taille des paquets,
nb de retransmissions autorisées,…) à chaque flux, …
• … malgré les modifications apportées
• Les développements futurs se feront sur OPNET
• Bilan : travail réalisé essentiellement sur les paramètres du réseau
• Perspectives portent sur:
• La prise en compte des paramètres de commande (structure, période API,…)
• L’étude des propriétés de sécurité (évitement de collisions, …)
• Gestion des priorités : gestion par la partie commande de la priorité des flux
dans le réseau pour que ce dernier s’adapte au mieux aux besoins de la PC.
- CRAN -
28