Quelques approches orientées modèles

Dans cette section nous présentons le langage RMPL (Reactive Model-based Pro-

gramming Language) utilisé dans le système KIRK et l’architecture IDEA (Intelli- gent Distributed Execution Architecture) qui sont deux approches orientées modèles

particulièrement intéressantes dont nous nous inspirons dans cette thèse. La pre- mière permet de concevoir des exécutifs réactifs capables de prendre en compte des contraintes temporelles quantitatives. La seconde quand à elle se base sur une or- ganisation multi-agent orientée modèle dans laquelle un grand nombre de systèmes

y compris des systèmes de planification complexes peuvent être structurés sous la forme d’une collection d’agents en interaction.

2.1.6.a RMPL : un langage orienté modèle pour des exécutifs réactifs et temporels

L’ensemble des exécutifs procéduraux décrits dans la section2.1.5.ane permettent pas de prendre en compte des contraintes temporelles quantitatives durant l’exé- cution. Pour palier à cela,Kim et al.(2001) proposent un langage original nommé RMPL (Reactive Model-based Programming Language). L’approche proposée vise à écrire et exécuter des programmes de contrôle de robot basés sur une program- mation orientée modèle. L’idée ici est d’écrire des programmes de contrôle qui encodent de manière compacte les capacités des robots, les objectifs d’une mission et l’environnement.

Pour ce faire, RMPL propose une représentation unifiée du système en utilisant un seul et même formalisme pour l’exécution, le diagnostic et la planification. Le langage est défini dans l’optique de prendre en compte :

(i) les raisonnements relatifs aux contingences et à l’ordonnancement des ac- tions (Kim et al.,2001)

(ii) l’inférence de variables d’état cachée et le contrôle des variables d’états du système (Williams et al.,2001a).

Dans le système de planification KIRK par exemple, le planificateur prend en entrée des programmes exprimés en RMPL. Contrairement à CLEaR qui utilise un exécutif basé sur le langage ESL, KIRK ne dispose pas d’exécutif programmé dans un langage intermédiaire.

Concepts de base : Considérons c, a, A et B où c est un littéral définissant une condition, a une action commençant à la date courante et A, B des procé- dures RMPL. Les instructions RMPL suivantes définissent les concepts de base du langage RMLP :

– c : tester si la condition est vrai à la date courante, – a : démarrer l’action à la date courante,

– A, B : Exécution parallèle des procédures RMPM A et B. – A; B : Exécution séquentielle des procédures RMPM A et B.

– A[l, u]: Contraindre la durée d’exécution de la procédure A de manière à ce qu’elle soit comprise entre l et u.

– if c thennext A : lancer l’exécution de la procédure A si la condition c =

vrai,

– do A maintaining c : exécuter la procédure A, et assurer que la condition

c=vrai tout au long de son exécution,

– choose {A, B} : exécuter l’une de procédure A ou B.

Ces éléments de base de RMPL permettent de spécifier des branchements condi- tionnels et des synchronisations, des exécutions concurrentes ou consécutives.

Couplage entre RMLP et TPN : Les programmes RMPL sont compilés par le système de planification KIRK sous la forme d’une représentation graphique du plan appelé TPN (Temporal Plan Network Williams et al. (2001b)). Un TPN correspond à un réseau de contraintes temporelles, exprimé en utilisant une général- isation du formalisme des STN. Cette généralisation autorise la prise en compte de contraintes symboliques et des branches conditionnelles. Les auteurs affirment que ces éléments additionnels permettent de traduire l’ensemble des concepts de base en TPL.

2.1. Planification de tâches et contrôle d’exécution 61

Comme dans les STN, les nœuds d’un TPL sont des instants associés à des événements. Les arcs (i, j) du réseau temporel sont étiquetés avec les contraintes des distances entres les instants i et j auxquelles s’ajoutent les deux contraintes symboliques qui sont Tell(c)et Ask(c). La contrainte symbolique Tell(c)permet de tester si la condition c=vrai durant l’intervalle de temps entre i et j. La contrainte

symbolique Ask(c)permet de spécifier que la condition c=vrai, est requise durant

l’intervalle de temps entre i et j. La Figure 2.9 présente une traduction en TPN des différents concepts de base de RMPL.

Astart Aend [l,u] A[l, u] : exécution de A entre l et u [l,u] Tell(c) c[l, u]: imposer la condition c à vrai entre l et u Astart Aend [l,u] [0,0] Ask(c) if c thennext A[l, u] : exécution de A[l, u]si c [l,u] Ask(c) do A[l, u] maintaining c : exécu- tion de A[l, u] en assurant c Astart Aend Bstart Bend [l1,u1] [l2,u2] [0,0] [0,0] [0,0] [0,0] A[l1, u1], B[l2, u2]: exécution parallèle de A[l1, u1]et B[l2, u2]

Astart Aend Bstart Bend

[l1,u1] [l2,u2] [0,0] A[l1, u1]; B[l2, u2]: exécution séquentielle de A[l1, u1]et B[l2, u2] Astart Aend Bstart Bend [l1,u1] [l2,u2] [0,0] [0,0] [0,0] [0,0] choose{ A[l1, u1], B[l2, u2]} : exécution de A[l1, u1]ou B[l2, u2]

Figure 2.9 – Traduction TPN des concepts de base de RMPLKim et al.(2001)

2.1.6.b IDEA : une architecture distribuée pour la planification réac- tive orientée modèle

L’architecture IDEA (Intelligent Distributed Execution Architecture Muscettola

et al.(2002); Dias(2003)) se base sur une approche multi-agent orientée modèles

dans laquelle un agent définit un module fonctionnel, un système de planification, un système de diagnostic, etc. Chaque agent dispose d’un modèle de contraintes et gère un ensemble de variables dont l’état est fonction du temps. L’idée principale de IDEA est qu’un grand nombre de système de contrôle peut être structuré sous la forme d’une collection d’agents en interaction.

Controlling

System ... ControllingSystem

Execution Feedback Goal Goal Register Execution Feedback Goal Plan Service Layer Reactive Planner Search

Engine ControlSearch

Plan Runner Model Plan Database Controlled System Controlled System ...

Figure 2.10 – Structure d’un agent IDEA selonDias(2003)

les systèmes externes (contrôlés2 ou contrôlant3) via un ensemble de goal registers. Ces goal registers maintiennent le contexte d’exécution de l’agent en envoyant ou en recevant des messages correspondant aux buts envoyés aux systèmes contrôlés ou aux buts reçus des systèmes contrôlant.

La structure d’un agent IDEA est constituée de quatre principaux éléments qui sont : un plan service layer PSL , un plan database PD, un plan runner PR, et un

reactive planner RP.

plan service layer PSL : il gère les interfaces pour la communication entre les actions, les buts et les échanges de données entre les systèmes externes.

plan database PD : il contient un ensemble ordonné d’instants décrivant la dy- namique temporelle des variables d’états du système. Les variables d’état définis- sent des processus parallèles décrivant :

(i) les changements ou les persistances de la valeur d’un attribut dans le temps (ii) la séquence des actions exécutées et celles prévues pour une exécution dans

le futur.

Les actions et les attributs sont constitués d’une structure particulière appelée

token. Un token est un intervalle temporel durant lequel une procédure doit être

exécuté. Les résultats de l’exécution sont soit envoyés aux systèmes externes, soit exploités afin de guider l’exécution des actions.

plan runner PR : il gère une boucle d’exécution simple de type SPA (sense/- plan/act cf. section 2.1.4.a). Le PR est activé à temps discret et synchronisé avec l’horloge interne de l’agent. Son principe de fonctionnement est :

– se réveiller suite à un message reçu d’un système externe, ou à la date de réveil prévue par l’horloge interne,

– mettre à jour les valeurs des goal registers en fonction des messages reçus, – activer le RP et planifier sur la base du contexte courant et des observations,

2. Le système externe est considéré comme contrôlé si c’est l’agent IDEA qui initialise l’ensem- ble des valeurs du goal register

3. Le système externe est considéré comme contrôlant si l’ensemble des valeurs du goal register, l’agent IDEA est initialisé par le système externe

2.1. Planification de tâches et contrôle d’exécution 63

– mettre à jour le contexte d’exécution et envoyer des messages appropriés aux systèmes externes,

– invoquer le RP afin de déterminer la prochaine date d’expiration de l’exécu- tion,

– s’endormir jusqu’à la prochaine date d’expiration de l’exécution.

reactive planner RP : chaque fois qu’une nouvelle information est perçue ou encore, lorsque la fenêtre de réalisation d’une action expire, le plan runner PR active RP. Ce dernier est chargé de prendre des décisions sur un horizon court portant sur la prochaine étape. Il détermine les procédures qui répondent aux buts et vérifie la consistance temporelle de tous les tokens suivants. Pour ce faire, RP consulte un Model décrivant les règles d’enchaînement des procédures et les mécanismes de synchronisation du démarrage et de la fin des procédures. Il met à jour le plan database PD en y représentant aussi bien les intervalles temporels durant lesquels les procédures ont été (exécutions passées) ou doivent être exécutées (exécutions futures). Reactive Planner Long-Term Planner Path Planner Goal loader ... Plan Database

Model Reactive planner is

activated within a plan runner cycle

Goal register Control planner activation in the same way as for external

controllers

Figure 2.11 – Structure d’un agent IDEA selonFinzi et al.(2004)

Toutefois, des planificateurs spécifiques plus complexes fonctionnant sur des horizons différents peuvent être introduits dans la structure d’un agent IDEA (cf. Figure 2.11). Pour cela, il suffit d’inclure dans le Model les mécanismes permet- tant d’activer et de faire coopérer les différents planificateurs qui modifient le plan

database PD. A l’instar des systèmes externes, cela se traduit par la spécifica-

tion, pour chaque planificateur, d’un ensemble de tokens dont l’exécution active le planificateur. Ainsi, l’activation des planificateurs spécifiques peut être planifiée de manière appropriée en fonction de l’évolution des états interne et externe modélisés par l’agent.