Règles ADAGRS

Les figures 7.114a, 7.115, 7.116, 7.117, 7.118 (p. 177, 178, 179, 180, 181) présentent les règles ADAGRS modélisant l’application.

La figure 7.114b (p. 177) présente une vue d’ensemble des états du système et les transitions possibles entre ces états. Un nœud peut se trouver dans l’état (fig. 7.114a, p. 177) :

– normal : lorsqu’il parcours la grille pour aller de point en point.

– visite : lorsqu’il a atteint un waypoint destination de son plan de vol. C’est dans cet état qu’il détectera la présence d’un éventuel incident sur le point de la grille correspondant.

– selection : état transitoire dans lequel il exécute la fonction behaviour_selection pour déterminer s’il doit traiter (ou continuer à traiter) un incident ou passer au waypoint suivant.

– traitement : lorsqu’il traite un incident.

N_i : Nœud i parcourant la grille (“normal”) Vi : Nœud i visitant un waypoint (“visite”) Ti : Nœud i traitant un incident (“traitement”) S_i : Nœud i calculant son prochain état (“selection”)

(a) Légende. Ni Vi Si Ti arrivée sur WP

point visité _{détection incident}

id_incident 6= 0 id_incident = 0 msg fin incident msg/evt/ǫ msg/evt/ǫ msg/evt/ǫ (b) Automate.

Figure 7.114 – CARUS : Légende et liens entre les états.

L’étiquetage ici est de la forme9 :

{<Évt>, <État>, <ID>, <Estimation situation globale>, <Msgs>} et {∅,N, i, FGE

i,t , m}, par exemple, est noté : Ni

FGE i,t , m

. Pour mémoire, seul le prochain message m de la file (celui qui est significatif pour la règle) est représenté dans l’éti-quette. On rappelle également que lorsqu’un des éléments de l’étiquette n’est pas important pour la règle exprimée il est remplacé par un tiret (’-’) ; ce qui donnera, par exemple : Ni

FGE i,t ,

-.

La figure 7.115 regroupe l’ensemble des transitions commandées par l’application (sur détection d’un événement extérieur). Elles correspondent exactement (par groupe de 2) aux transitions noires de la figure 7.114. On rappelle (section 3.4 que p. 57), pour l’ensemble des cas de la figure 7.115 :

– les règles de type Ni ^b Ni indiquent qu’un événement b non directement géré par le modèle s’est produit ;

– les règles de type ^b Ni Vi indiquent une évolution interne au modèle en réponse à la survenue de l’événement b.

Ni v Ni

-, - ,

-(a) Arrivée sur un point (commandée par l’application).

N_i V_i

v

-, - ,

-(b) Passage en mode visite.

V_i ^v V_i

-, - ,

-(c) Fin de visite

(commandée par l’application).

Vi Ni

v

-, - ,

-(d) Passage en mode normal.

Vi di Vi

-, - ,

-(e) Détection d’un incident10. (commandée par l’application).

Vi Si

di

-, - ,

-(f) Selection de comportement pour savoir s’il faut ou non traiter l’incident.

Ti di Ti

FGE

i,t , - FGE

i,t , -(g) Fin d’incident détectée (commandée par l’application).

Ti Ni

di

FGE

i,t , - reassign(FGE

i,t ), -(h) Retour en mode normal.

Figure 7.115 – CARUS : Événements déclenchés par des détections de l’application.

Si FGE i,t , -Ni FGE i,t+ǫ, -F_i,t^GE+ǫ(i).id_incident = 0 Ti FGE i,t+ǫ, -F_i,t^GE+ǫ(i).id_incident 6= 0 FGE i,t+ǫ= behaviour_selection(FGE i,t )

Figure 7.116 – CARUS : Sélection de comportement. Après application de la fonction behaviour_selection() sur FGE

i,t , FGE

i,t+ǫ(i).id_incident indique l’identifiant de l’éventuel point en incident à traiter.

La règle de sélection de comportement est donnée figure 7.116. Elle correspond aux flèches vertes de la figure 7.114b (p. 177). La fonction de sélection de comportement behaviour_selection() est exécutée sur l’estimation de la situation globale par i au temps (local) t (FGE

i,t ). Le résultat de cette exécution est la nouvelle estimation de la situation globale par i, au temps t + ǫ (FGE

i,t+ǫ), dans laquelle son champ id_incident indique éventuellement l’identifiant du point qu’il doit traiter :

– si FGE

i,t+ǫ(i).id_incident = 0, le nœud continue de (resp. recommence à) visiter la grille (état N) ;

– si FGE

i,t+ǫ(i).id_incident 6= 0, le nœud traite (resp. continue de traiter) le point en incident (état T ).

∗i cm ∗i

FGE

i,t , ∅ FGE

i,t , ∅

(a) Demande de création d’un nouveau message

(commandée par l’application).

∗i ∗i cm FGE i,t , ∅ FGE i,t , m (b) m contient FGE i,t . ∗i Mn{-,?} M² {-,?} M 1 {-,?} FGE i,t , m ∗i FGE i,t , ? Mn{-,m} M² {-, m} M 1 {-, m } (c) Diffusion de FGE

i,t (contenu dans m).

Figure 7.117 – CARUS : Diffusion par le nœud i de son estimation de la situation globale.

La règle de création d’un message contenant l’estimation locale de la situation globale du nœud est donnée par la figure 7.117b. Le message est ensuite envoyé au voisinage direct du nœud qui l’a créé par l’application de la règle 7.117c. Cette règle est commandée périodiquement par l’application (fig. 7.117a).

À chaque réception de message par un nœud i (fig. 7.118a et 7.118b), l’estimation locale de la situation globale du nœud courant (FGE

i ) est “fusionnée” avec celle de l’émetteur (FGE

j ) grâce à l’opérateur ⊎. Cet opérateur garde les informations les plus récentes portées par les deux estimations11. La fonction de réaffectation est ensuite immédiatement exécutée afin de prendre en compte les modifications pour la suite de la mission. Si le nœud était dans l’état traitement (Ti) au moment de la réception, il passe dans l’état selection pour, le cas échéant, relâcher le point incident. Dans les autres cas (Ti), il reste dans l’état dans lequel il était.

Ti M{m,-} ∗j FGE i,t , -Si ∗j reassign(FGE i,t ⊎ m.FGE j,t−ǫ), -M{?,-}

(a) Réception de message par un nœud en traitement.

m contient FGE

j . Réaffectation des points en fonction des informations reçues. Le nœud passe en mode selectionpour déterminer s’il doit ou non continuer à traiter l’incident en fonction des informations reçues.

Ti M{m,-} ∗j FGE i,t , -Ti ∗j reassign(FGE i,t ⊎ m.FGE j,t−ǫ), -M{?,-}

(b) Réception de message par un nœud pas en traitement (T = {N, V, S}). m contient FGE

j . Il y a seulement réaffectation des points en fonction des informations reçues et le reste de l’étiquette du nœud reste inchangé.

Figure 7.118 – CARUS : Réception de messages et réaffectation de points.

Remarque : la supposition de la disparition d’un nœud de la flotte entraîne nécessairement un décalage dans la répartition des points à visiter. Ce décalage peut mener à ce qu’un nœud en incident cesse (à tort ou à raison) le traitement qu’il effectue. Nous n’avons pas mis en place d’événement applicatif (par exemple associé à un timer, fig. 7.115) commandant le passage de l’état traitement à l’état selection pour prendre en compte ceci. En effet, pour relâcher le point, il est nécessaire qu’il existe un autre nœud en traitement sur ce point. C’est pourquoi, nous avons décidé d’utiliser uniquement la réception d’un message pour passer de l’état traitement à l’état selection. Le message reçu peut apporter des informations empêchant la mauvaise décision qui aurait pu être prise si le passage en selection avait été fait sur simple événement applicatif.