Exécution de plan en planification

L’idée maitresse des travaux portant sur la décision dans les systèmes complexes autonome se base sur l’hypothèse que l’autonomie d’un système dépend de sa capacité à manipuler et adapter des plans dans un contexte différent de celui pour lequel le plan a été initialement conçu.

Dans la littérature, trois grandes stratégies ont été développées pour appréhen- der le couplage planification et exécution : planification réactive, planification suc-

cessive et planification continue.

La première approche (planification réactive) est centrée autour du composant d’exécution. La planification est dans ce cas vue comme une ressource pour l’exé- cution. La seconde approche (planification par lot) intègre les deux composants (planification et exécution) sous la forme de processus distincts. Le plan produite par le planificateur porte sur tout l’horizon de la planification c’est-à-dire de l’état initial à l’état but. Ce plan complet est ensuite passé au système d’exécution. En cas d’échec le planificateur génère un nouveau plan partant de l’état courant. No- tons toutefois, qu’il existe des systèmes de planification successive tel que Remote

Agent (Muscettola et al.,1998) dans lesquels le temps est subdivisé en horizon de planification (cf. Figure2.7-a). Le plan est donc construit sur l’horizon courant et

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

exécuté. Ensuite la planification est réalisée successivement sur les horizons suiv- antes. Enfin, la troisième approche (planification continue) consiste à entrelacer continuellement les phases de planification et d’exécution. Dans ce cas, la planifi- cation reste active afin d’adapter le plan en cas de conflit ou lorsque de nouveaux buts sont ajoutés. Les actions exécutables sont lancées même si le plan n’est pas complet. Comme l’indique la Figure2.7-b, la construction du plan est réalisée de manière incrémentale. L’horizon sur lequel on travaille est décalé au fur et à mesure de l’exécution de façon à ce que le nouvel horizon recouvre partiellement l’horizon précédent. Planier pour l'hori- zon suivant Planier pour l'hori- zon suivant

(a) Planication successive (b) Planication continue

Figure 2.7 – Planification successive vs planification continue

Dans le cas des applications qui nous intéressent, l’horizon d’une simulation peut couvrir plusieurs années. Considérant, l’incertitude intrinsèque des systèmes de production agricole, il nous parait simplement aberrant d’aborder les différents problèmes de décision sous la forme de planification portant sur tout l’horizon de la simulation. A ceci s’ajoute le fait que les planifications stratégique, tactiques et opérationnelles portent sur des horizons très différents allant de plusieurs années à quelques jours. Dans ces conditions, la stratégie adoptée pour les phases de planifi- cation et d’exécution doit pouvoir permettre de prendre en compte cette variabilité de l’horizon de planification. Pour ces différentes raisons, les approches de planifica- tion successives ne nous semblent pas pertinentes. Nous proposons dans la suite de développer quelques systèmes de planification réactive et de planification continue.

2.1.5.a Stratégie de planification réactive

Les approches de planification réactives exploitent généralement un langage inter- médiaire permettant de spécifier la façon d’exécuter un plan. Dans ces systèmes les plans sont pré-spécifiés. Tant que le plan reste valide, l’exécutif s’occupe de son interprétation. En cas d’échec, il sollicite le planificateur pour l’obtention d’un nouveau plan valide dans le contexte d’exécution courant. La planification est dans ce cas utilisée comme une ressource pour l’exécution. Dans cette classe d’exécutifs on retrouve d’une part, celles qui sont purement réactives (ESLGat (1997), TDL

Simmons et Apfelbaum (1998)). Généralement elle ne fonctionnent pas lorsque

les systèmes échouent et qu’aucun plan et procédure explicites n’est pré-spécifié. D’autre part on retrouve celles qui intègrent des capacités délibératives dans l’exéc- utive (PROPELLevinson (1995), Propice Despouys et Ingrand(1999).

Les exécutifs Execution Support Language ESL (Gat,1997) et Task Description

Language TDL (Simmons et Apfelbaum, 1998), respectivement utilisés pour la sonde Deep Space one avec l’architecture Remote agent puis dans l’implémentation CLEaR de l’architecture CLARAty peuvent être considérés comme des systèmes d’exécution purement réactifs.

ESL : ESL se base sur un exécutif procédural réactif nommé Reactive Action

Package (RAP (Firby, 1994)) et propose dans le langage intermédiaire, des con- cepts permettant d’encoder les connaissances d’exécution permettant de prendre en compte :

– des événements de synchronisation sur les actions,

– des sélections et des décompositions de méthodes dans un sous ensemble de méthodes prédéfinis,

– des contingences relatives à la détection des échecs et l’appel des procédures de correction,

– des buts sur l’état du système à atteindre et les méthodes pour y arriver, – des requêtes sur un ensemble de propositions logiques.

Dans, ESL, la prise en compte de la contingence est fondée sur la philosophie « cognizant-failure » c’est-à-dire l’idée selon laquelle, en cas de détection d’échec inévitable, le système est capable d’y répondre de manière appropriée. Cela sup- pose que les situations de succès et d’échecs des actions puissent être facilement identifiées.

TDL : TDL dispose de caractéristiques très proches de ESL. Les actions sont exécutées suivant un arbre généré en fonction de l’état du système. Chaque nœud de l’arbre est capable de détecter les situations d’échec. Il existe plusieurs autres systèmes d’exécution réactifs que nous ne présentons pas ici.

PROPEL : Contrairement à ces deux exécutifs purement réactifs, PROPEL (PROcedure Planning and Execution Language Levinson (1995)), intègre une ca- pacité délibérative dans l’exécutif. Dans l’architecture de PROPEL on retrouve un exécutif et un planificateur, le tout associé à un moteur de recherche qui opère dans un espace de procédures prédéfinies. Ce moteur génère des procédures disjonctives représentées sous la forme d’un arbre OU. L’exécutif exploite cet arbre et utilise une technique de recherche prédictive afin d’évaluer les choix et génère le plan adéquat en fonction du contexte d’exécution. Dans PROPEL, l’exécutif n’autorise aucun « backtrack » dans l’arbre de recherche. De la même manière que l’exécutif, le planificateur utilise une technique de recherche prédictive pour l’anticipation et la prise en compte de situations d’échec. L’anticipation dans PROPEL consiste à simuler l’effet des actions et à produire un plan correspondant à un ensemble de règles de sélection associées à des procédures abstraites. Ces règles seront ensuite exploitées afin de guider l’exécution. En cas de d’échec imprévu, le planificateur opère des "backtrack" dans l’arbre de recherche initialement généré par l’exécutif afin de trouver de nouvelles règles exploitable par l’exécution. On retrouve des fonctionnalités similaires également dans PropiceDespouys et Ingrand (1999) qui se base sur un exécutif procédural nommé OpenPRS (Ingrand et al.,1996).

2.1.5.b Planification continue

L’approche de planification continue consiste à entrelacer continuellement les phases de planification et d’exécution. La planification reste active afin d’adapter le plan en cas de conflit ou lorsqu’un nouveau but est ajouté. Dans cette approche, certaines actions sont exécutées même si la planification est en cours.

SIPE : afin d’entrelacer les phases de planification et d’exécution dans SIPE et SIPE-2 (System for Interactive Planning and Execution monitoring Wilkins

(1988)), l’utilisateur définit les buts qui peuvent être reportés. En utilisant une technique de planification non-linéaire hiérarchique, un premier plan est alors con- struit sur la base des buts qui ne peuvent être reportés. L’exécution de ce plan est réalisé en parallèle avec la planification portant sur les buts reportés. En cas d’échec de situation inattendu, soit le plan construit en parallèle est mis en œuvre, soit le système de réparation de plan de SIPE est appelé afin de modifier le plan.

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

CLEaR : Basé sur l’architecture CLARAty le système CLEaR (Closed-Loop Ex-

ecution and Recovery (Fisher et al.,2000;Estlin et al.,2001)) combine le planifica- teur continu nommé CASPER (Continuous Activity Scheduling, Planning, Execu-

tion and Re-planning (Chien et al.,2000)) à un système d’exécution basé sur TDL (Task Description Language (Simmons et Apfelbaum,1998)).

CASPER (Continuous Activity Scheduling, Planning, Execution and Re-

planning Chien et al. (2000); Chien (2006)) se base sur le planificateur ASPEN

(Rabideau et al., 1999) qui utilise une technique de planification par recherche

locale afin de réduire le temps de replanification. En conséquence la réactivité du système se trouvera ainsi augmenté. Pour ce faire, un premier plan est construit sur un horizon donné. Ce plan sera ensuite étendu de manière incrémentale au fur et à mesure de l’exécution. Les auteurs préconisent de combiner cette planification con- tinue avec une approche hiérarchique de planification. Cela consiste à opérer une planification à long terme portant sur un niveau d’abstraction élevé. Ensuite, des planifications sur des horizons de plus en plus courts sont réalisées afin d’obtenir des plans de plus en plus détaillés.

Planication à long terme Planication à moyen terme Planication à court terme

augmentation des détails du plan

Figure 2.8 – Horizon de planification hiérarchiqueChien et al. (2000)

Cette approche est schématisé par le Figure2.8. L’idée de base étant de consid- érer qu’il est inutile de construire un plan détaillé sur du long terme. Pour chacune des couches, le planificateur opère de manière continue. La taille de l’horizon et la fréquence de la planification diffèrent en fonction du niveau de planification. En cas de situation inattendue, le plan est réparé en exploitant les capacités d’ASPEN. Pour assurer que le planificateur ne modifiera pas des actions encours d’exécution, une fenêtre d’engagement est définie. Ainsi, au sein de cette fenêtre, toutes les mod- ifications du planificateur sont interdites. En fonction des applications, l’exécution peut être suspendue ou non durant la replanification.

Pour intégrer la planification et l’exécution dans CLEaR, les auteurs définissent trois classes de processus qui sont :

. Processus de planification : maintient le plan courant et répond au consigne de

replanification des processus d’exécution.

. Processus d’exécution : maintient une copie du plan et se charge de l’engagement

des actions

. Processus d’estimation d’état : maintient l’estimation de l’évolution de l’état du

système et des ressources.