2 Architecture décisionnelle

Transcription

1 Intégrer des planificateurs dans le logiciel de vol d un satellite autonome Embedding planning systems in the flight software of an autonomous satellite Solange Lemai 1 Marie-Claire Charmeau 1 Xavier Olive 2 1 CNES 18 av. Edouard Belin, Toulouse cedex 4 solange.lemaichenevier@boursier.cnes.fr marie-claire.charmeau@cnes.fr 2 Alcatel Alenia Space France 100 bd du midi - BP 99, Cannes la Bocca Cedex Xavier.Olive@alcatelaleniaspace.com Résumé Plusieurs bénéfices peuvent être attendus d une augmentation du niveau d autonomie des missions spatiales : une réduction des opérations au sol, une limitation du nombre d interruptions du service ou encore une amélioration de la réactivité du système. Selon les besoins d une mission, de nouvelles fonctions doivent être embarquées telles que la planification de la mission ou le diagnostic de fautes et la reconfiguration automatique. Nos travaux ont porté plus spécialement sur l intégration de systèmes de planification et de moyens de reprogrammation dynamique dans le logiciel de vol d un satellite autonome. En particulier, nous abordons le problème du contrôle de plusieurs planificateurs spécialisés (chacun étant dédié à un type d activité), qui ont des comportements variés (planification anytime, planification par lots, etc.), et qui doivent être coordonnés. Mots Clef Planification, architecture décisionnelle, contrôle d exécution. Abstract Space missions may benefit from a more advanced autonomy level in different ways : reduction of ground operations, reduction of the occurrence of service interruptions or improvement of the reactivity of the system. Depending on the mission requirements, new functions need to be supplied on-board the spacecraft, such as mission planning or failure diagnosis and automatic reconfiguration. Our work focused on the integration of planning systems and of dy- Les travaux présentés dans ce papier ont été cofinancés par le CNES et Alcatel Alenia Space. namic replanning capabilities into the flight software of an autonomous satellite. Especially, we address the problem of controlling several dedicated planners which have various behaviors (anytime planning, batch planning, etc.) and need to be coordinated. Keywords Planning, decisional architecture, execution control. 1 Introduction Les besoins en autonomie d un système spatial varient en fonction du scénario de la mission et des bénéfices attendus. Un satellite en orbite basse peut être équipé d un contrôle d orbite autonome pour réduire les opérations au sol. Une sonde lointaine, à cause des longs délais de communication avec le sol, a besoin d un système de FDIR 1 avancé avec du diagnostic et des capacités de reconfiguration automatique. Ou bien encore, la réactivité d un satellite peut être renforcée par l utilisation à bord de systèmes de planification et de moyens de replanification, par exemple pour prendre en compte rapidement de nouvelles requêtes induites par le traitement à bord des données de la charge utile. Les auteurs de [3] distinguent plusieurs concepts qui peuvent être combinés pour atteindre un niveau d autonomie élevé. Ces concepts sont liés aux problématiques de commande-contrôle d un satellite (par exemple la programmation basée sur des événements, ou la planification à bord), ou bien aux problématiques de maintien à poste et de surveillance du système (par exemple le contrôle d orbite autonome, la télémétrie de surveillance synthétique ou le diagnostic à bord). 1 Failure Detection, Isolation and Recovery.

2 Selon les besoins de la mission, le logiciel de vol d un satellite doit être doté des fonctions suivantes : Traitement des données - traitement à bord des données scientifiques, par exemple pour détecter de nouveaux objectifs pour la mission, Orbitographie - calcul des données orbitales et de datation appliqué au guidage et au contrôle d orbite, Programmation sur événements - activation de commandes associée à des événements qui peuvent être déclenchés par la surveillance (alarme FDIR...) ou qui sont calculés à bord (événements orbitaux tels que le début et la fin du survol d une zone,...), FDIR évoluée - allant jusqu au diagnostic de panne et à une reconfiguration et reprise de mission autonomes, Planification - élaboration des plans d activités des charges utiles et/ou de la plate-forme à partir d objectifs fournis par le sol, Reprogrammation dynamique - adaptation du plan d activités en fonction du contexte détecté à bord (nouveaux objectifs, modification des ressources, etc. ). Nous présentons dans la section suivante un concept d architecture qui intègre ces nouvelles applications décisionnelles dans le logiciel de vol d un satellite. La troisième section détaille un exemple de niveau décisionnel conçu pour une application de surveillance de la Terre. Nous évoquons en particulier le problème posé par la coordination de plusieurs planificateurs spécialisés et la solution adoptée. La dernière section décrit la maquette mise en place pour tester les performances temps-réel des algorithmes de planification sur un banc de test développé par Alcatel Alenia Space. 2 Architecture décisionnelle Le développement d un système autonome complexe repose sur l organisation des composants logiciels en une architecture en boucle fermée. La plupart des architectures existantes qui intègrent des capacités décisionnelles sont basées sur des niveaux hiérarchiques. Dans le domaine de la robotique par exemple, l architecture 3T [2] comprend trois niveaux qui correspondent à trois composants : un système de contrôle bas niveau réactif, un système d exécution de plan réactif et un système délibératif qui a un temps de réponse plus lent. L architecture LAAS [1] se décompose aussi en trois niveaux : un niveau fonctionnel qui encapsule dans des modules les fonctionnalités de base du système, un niveau décisionnel qui est chargé de l élaboration du plan et de son exécution, et un niveau intermédiaire qui a un rôle de protection de fautes et qui filtre les commandes envoyées par le niveau décisionnel au niveau fonctionnel. Dans le domaine spatial, l architecture conçue pour l expérimentation du Remote Agent [10] intègre trois composants hiérarchiques : un système de planification responsable de la planification de la mission, un exécutif utilisé pour détailler les activités du plan, et un système de diagnostic et de reconfiguration. De même, nous proposons d organiser les applications logicielles selon trois niveaux hiérarchiques (cf. Figure 1). Ces niveaux sont caractérisés par des temps de réaction différents, ils manipulent des données plus ou moins abstraites et ont une connaissance différente de l état du système (globale ou locale). Ils interagissent par envoi de commandes au niveau inférieur et envoi de bilans au niveau supérieur. Niveau décisionnel plan Suivi état Niveau opérationnel Interface bord/sol Niveau fonctionnel Planificateurs Exécutif décisionnel Exécutif opérationnel requêtes FDIR opérationnelle COM THERM ENERGIE SCAO Charge Utile FDIR FDIR FDIR FDIR FDIR FIG. 1 Architecture décisionnelle Le niveau décisionnel est chargé de la programmation des activités de la plate-forme et/ou de la charge utile, et du contrôle de l exécution du plan d activités. Deux modes de fonctionnement peuvent être considérés à ce niveau. Dans un mode simplifié, il n y a pas de système de planification disponible et le niveau est seulement responsable de l exécution d un plan d activités envoyé par le sol. Dans un mode plus complet, les plans sont élaborés à bord à partir d objectifs envoyés par le sol et de l état courant du système (niveaux des ressources, etc.). Le niveau opérationnel est chargé de l exécution des opérations (décomposition et routage des commandes, surveillance de l état global du système), qui proviennent soit des activités planifiées au niveau supérieur, soit des commandes envoyées par le segment sol. Le niveau fonctionnel regroupe les traitements et boucles de contrôle des sous-systèmes classiques : COM - communication avec les stations sol (émission de télémétrie, réception de télécommandes, contrôle des antennes). THERM - gestion du contrôle thermique. ENERGIE - gestion de l alimentation (surveillance et contrôle des batteries et des panneaux solaires). SCAO (Système de Contrôle d Attitude et d Orbite) - ce sous-système rassemble des fonctions : d estimation d attitude, de navigation (estimation du modèle d orbite courant et de la position sur l orbite), de propagation d orbite (prédiction d événements orbitaux tels que les prochaines fenêtres de visibilité avec une station sol),

3 de guidage (calcul des consignes d attitude), de contrôle d orbite autonome (calcul des manoeuvres de correction d orbite), de contrôle et surveillance des actionneurs. CHARGE UTILE - gestion des instruments dédiés à la mission (éventuellement avec une analyse des données à bord). La stratégie FDIR est répartie entre les niveaux : détection et reconfiguration locale dans les sous-systèmes, diagnostic et reconfiguration globale au niveau opérationnel, prévention au niveau décisionnel (par exemple, détecter en avance qu un plan n est plus consistant avec l utilisation effective des ressources et peut conduire à des échecs). Comme évoqué précédemment, notre travail s est concentré sur l intégration de systèmes de planification dans l architecture, c est-à-dire sur le niveau décisionnel. On appelle ici système de planification tout processus de décision qui sélectionne et ordonne les activités à réaliser pour accomplir des objectifs définis par le sol. Cette décision doit tenir compte de contraintes de ressource (énergie, mémoire, etc.), de contraintes temporelles (périodes d éclairement, etc.), et de contraintes de compatibilités entre activités. Ce processus fournit un plan d activités. L exécution du plan est gérée par un exécutif décisionnel. C est également l exécutif décisionnel qui décide, en fonction des bilans et des alarmes, du besoin de modifier le plan courant (abandon pour un nouveau plan, réparation du plan, extension de l horizon, etc.). Dans notre approche, l exécutif décisionnel a un rôle central dans le niveau décisionnel : en interface avec le niveau inférieur, il surveille l exécution du plan, et coordonne les différents systèmes de planification. Dans la section suivante, nous présentons un exemple de niveau décisionnel et nous proposons, pour l exécutif décisionnel, un schéma de contrôle générique basé sur des automates. 3 Exemple de niveau décisionnel 3.1 Contexte Le CNES a cofinancé, avec l ONERA, une thèse sur la planification à bord de la mission d un satellite autonome. Ces travaux sont basés sur une mission de référence d observation de la Terre : une constellation de satellites en orbite basse chargés de surveiller les feux de forêt et les volcans. Chaque satellite est équipé d un instrument d observation et d un instrument de détection qui pointe en avant du satellite. Ce dernier instrument permet la détection de nouveaux feux ou d éruptions volcaniques. En cas de détection d un nouveau point chaud, une alarme est envoyée à un centre de mission au sol via un satellite géostationnaire, et le satellite doit réaliser une observation de la zone le plus tôt possible (l instrument d observation survole une zone une minute après l instrument de détection). Un centre de contrôle au sol collecte toutes les requêtes d observation et les répartit entre les satellites de la constellation (en leur associant des niveaux de priorité qui dépendent du statut d activité de la zone). Chaque satellite va ensuite sélectionner et ordonner les observations qu il peut réaliser en fonction de ses ressources (énergie, mémoire) et des prochaines fenêtres de visibilité permettant le télédéchargement des données. La planification à bord du satellite permet une reprogrammation rapide lorsqu un nouveau point chaud est détecté (ce point chaud correspond à une requête d observation avec un haut niveau de priorité). Sylvain Damiani a développé des stratégies d allocation des requêtes au sol (voir [5]) et des algorithmes de planification à bord pour les activités d observation et de télédéchargement (voir [6]). 3.2 Niveau décisionnel Nous considérons un satellite de la constellation qui reçoit des requêtes du centre de contrôle et peut détecter de nouvelles requêtes à bord. Le niveau décisionnel d un tel satellite comprend : plusieurs planificateurs spécialisés un planificateur d observations anytime - Cet algorithme choisit la prochaine observation à réaliser parmi les requêtes candidates sur un horizon de raisonnement. Cette décision prend en compte la faisabilité d une requête (consommations de mémoire et d énergie, compatibilités entre deux observations successives) et optimise le nombre de requêtes de forte priorité pouvant être accomplies. L algorithme a un comportement anytime : il parvient rapidement à une première solution puis l optimise en étendant progressivement son horizon de raisonnement. Ce planificateur est relancé à chaque fois que le contexte de planification est modifié (par exemple à l arrivée d une nouvelle requête). un planificateur de télédéchargement - Ce planificateur est activé à l approche d une fenêtre de visibilité avec un centre de mission au sol. Il sélectionne, parmi les observations en mémoire, celles qui doivent être télédéchargées, en fonction de leur taille et de leur priorité. un estimateur de télédéchargement - Cet algorithme est activé à chaque fois que le planificateur d observations est relancé. Il est utilisé pour estimer l énergie consommée et la mémoire libérée pendant la prochaine fenêtre de visibilité. Cette estimation est ensuite utilisée par le planificateur d observations pour prédire l évolution des niveaux de mémoire et d énergie sur l horizon de raisonnement 2. une règle de décision simple - Cet algorithme peut être utilisé à la place du planificateur d observations anytime. Il décide simplement si la prochaine observation parmi l ensemble des requêtes est réalisable, c est-àdire si les ressources nécessaires sont disponibles et si 2 Cependant, si le planificateur de télédéchargement a produit un plan détaillé de télédéchargements pour la prochaine fenêtre de visibilité, ce plan est utilisé à la place de l estimation.

4 l observation n est pas en conflit avec une requête de plus forte priorité. un processus de gestion des requêtes Une requête envoyée par le sol spécifie une zone géographique et une priorité. Une telle requête-sol doit être ensuite décomposée en un ensemble de requêtes d observation possibles en utilisant la prédiction à bord des prochains survols de la zone. Ce processus maintient à jour l ensemble des requêtes et leur statut. un processus de gestion du plan Ce processus maintient à jour un plan en intègrant les activités sélectionnées par les planificateurs. Le séquencement des activités et le suivi de l état reposent sur ce plan. un processus de suivi de l état Ce processus vérifie régulièrement que les niveaux de ressource prévus dans le plan et les niveaux réels sont consistants. Il déclenche une alarme si ce n est pas le cas, pour signaler que le plan doit être révisé. un exécutif décisionnel Il coordonne le niveau décisionnel. Son rôle est détaillé dans le paragraphe suivant. 3.3 Coordination Ce niveau décisionnel intègre plusieurs planificateurs, chacun étant dédié à un certain type d activité (par exemple observation ou télédéchargement). Une autre option aurait pu être l utilisation d un planificateur global unique qui prend en compte tous les types de requêtes et gère les interactions entre tous les types d activités (cf. le planificateur HSTS utilisé dans le cadre de l expérimentation Remote Agent [9] ou CASPER à bord du satellite Earth Observing-1 [4]). Ce choix a été motivé par la possibilité d utiliser des algorithmes dédiés plus performants. En contrepartie, le contrôle de ces planificateurs est plus compliqué. Ils ont des conditions d activation différentes, des durées différentes, des horizons de raisonnement différents, ils peuvent être interruptibles ou non interruptibles, et ils ont besoin d être coordonnés (un planificateur utilise le résultat d un autre planificateur, ou bien, un planificateur est utilisé à la place d un autre en fonction du contexte). Ainsi, dans notre approche, l exécutif décisionnel est chargé du contrôle de l exécution des activités du plan, mais également du contrôle des différents planificateurs. Nous proposons un schéma de contrôle générique (indépendant de l application) pour implémenter l exécutif. Les planificateurs peuvent être considérés comme des activités spécifiques qui doivent être contrôlées au même titre que les activités du plan. Par contrôler une activité, on entend : décider de son activation ou de son arrêt en fonction de certaines conditions et du contexte. L exécutif décisionnel peut être considéré comme un module recevant et émettant des signaux, et le contrôle d une activité peut être géré à l aide d un automate d état. Nous définissons un automate d état générique pour le contrôle d une activité qui permet de représenter des comportements variés (activité interruptible, non interruptible, à durée limitée, etc.). 3.4 Exécutif décisionnel I O Interface VC TrStart, TrStop, fr, exec FIG. 2 Exécutif décisionnel Activité (a4,p4) Activité (a3,p3) Activité (a2,p2) Activité (a1,p1) La Figure 2 illustre l implémentation de l exécutif décisionnel. Il peut recevoir un ensemble I de signaux en entrée et émettre un ensemble O de signaux en sortie. Ces signaux peuvent être valués et correspondent, par exemple, à des événements et à des commandes. Un ensemble V C de variables de contrôle est utilisé pour représenter et maintenir le contexte d exécution. La valeur de ces variables évolue en fonction des signaux émis et reçus. L exécutif contrôle l exécution d un ensemble d activités A = {(a, P )}, une activité étant définie par son nom a et par un ensemble de paramètres P. Les signaux en entrée sont spécifiques à l application. Certains ne sont utilisés que pour mettre à jour les variables de contrôle, d autres sont utilisés pour contrôler les activités. Ces derniers sont traduits en signaux internes : TrStart (déclenche le lancement d une activité), TrStop (déclenche l arrêt d une activité), ou fr (bilan renvoyé à la fin d une activité). Ces signaux internes peuvent également être émis lors de l exécution d une transition de l automate. Une liste fifo de signaux internes est associée à chaque activité. Toutes les activités sont contrôlées selon un même schéma qui spécifie comment gérer le lancement, l exécution et l arrêt d une activité. Ce schéma est défini par deux automates d état. Un premier automate est utilisé pour gérer une instance de l activité en attente de lancement, le second est utilisé pour contrôler une instance de l activité en cours d exécution. L exécutif comporte une paire d automates pour chaque activité de A 3. L automate gérant une instance en attente est détaillé Figure 3. L état initial de l automate est IdleStarting. Il entre dans l état Starting sur réception d un signal interne TrStart. L exécutif vérifie alors que certaines conditions sont satisfaites pour pouvoir lancer l activité. Ces conditions sont exprimées dans Lc et Lca et portent sur le contexte d exécution (constitué par la valeur courante des variables 3 L implémentation courante ne permet pas l exécution en parallèle de deux instances d une même activité.

5 TrStart/startA, set(ltm) IdleStarting IdleExecuting). Elles correspondent par exemple à l envoi d un bilan sur le statut d exécution de l instance d activité. L exécutif déroule les automates selon la boucle décrite Table 1. Ltm/ LtmA (Lc&Lca&activity_is _in_state_idleexecution)/ exec,reset(ltm) Starting Lca Lca/Alc Ltm/ LtmA Enable Starting Condition FIG. 3 Automate pour l instance d activité en attente de lancement de contrôle et l état courant de tous les automates). On considère deux types de conditions : des conditions contingentes (Lc) et des conditions contrôlables (Lca). Si les conditions Lca ne sont pas satisfaites, l exécutif peut activer la procédure Alc pour rendre ces conditions vraies. Finalement, si Lc et Lca sont satisfaites, et si il n y a pas d instance de l activité en cours d exécution, l instance en attente peut être lancée via l émission du signal interne exec 4. Si les conditions ne peuvent pas être satisfaites, le délai Ltm définit la durée maximale autorisée pour essayer de lancer l activité. De façon similaire, le second automate gère l exécution (comprenant la surveillance de conditions et de délais) et l arrêt (en fonction de déclencheurs, conditions, bilans ou délais) de l instance d activité. Un exemple complet d instanciation du schéma de contrôle est donné Table 2. Etm, Ectm et Stm sont des délais représentant les durées maximales autorisées respectivement : pour la durée de l activité, pour essayer de restaurer des conditions d exécution, et pour la procédure d arrêt de l activité. Ec, Eca, Sc et Sca sont des formules exprimant des conditions sur le contexte d exécution. Ec et Eca correspondent aux conditions contingentes et contrôlables qui doivent être vérifiées pendant l exécution de l activité. Sc et Sca correspondent aux conditions qui doivent être satisfaites avant l arrêt d une activité. Finalement, Scmd, Aec, Asc, starta, exa, LtmA et StmA sont des procédures d émission de signaux internes et externes exécutées lorsque certaines transitions des automates sont franchies. Scmd correspond à la commande envoyée pour arrêter l activité. Aec et Asc sont les procédures utilisées pour restaurer des conditions contrôlables. starta, exa, LtmA et StmA sont des procédures associées à l entrée et à la sortie d un état non actif des automates (IdleStarting ou 4 Sur réception de ce signal, le second automate entre dans un état Executing et active la procédure Lcmd qui lance l activité. Boucle - traiter les signaux d entrée reçus : mise à jour des variables de contrôle et émission des signaux internes correspondants - si il existe une liste fifo non vide, ou si le contexte d exécution a changé, ou si le délai d un timer est atteint - pour chaque activité - consommer le premier signal de la fifo - pour chaque automate - mémoriser la première transition franchissable à partir de l état courant selon l ordre de priorité : (1)signal/(2)condition/(3)timer - pour chaque transition sélectionnée - set/reset des timers - exécution de la procédure (émission de signaux internes, émission de signaux externes, mise à jour des variables de contrôle) - mise à jour de l état de l automate TAB. 1 Cycle d exécution Au final, créer un exécutif pour une application spécifique revient à définir : l ensemble des activités, l ensemble des signaux d entrée et l ensemble des signaux de sortie, l ensemble des variables de contrôle, et les fonctions définissant leur évolution en fonction des signaux reçus et émis, et pour chaque activité, les conditions, délais et procédédures, et les correspondances entre les signaux d entrée et les signaux internes. Dans notre exemple d application, l exécutif décisionnel gère 7 activités : 2 qui concernent le plan (observation et télédéchargement), 4 qui concernent les planificateurs (planificateur d observations, règle de décision, planificateur de télédéchargement et estimateur de télédéchargement) et 1 pour le niveau décisionnel 5. Les variables de contrôle indiquent notamment si le satellite est en visibilité avec une station sol ou si un plan de télédéchargement est disponible pour la prochaine fenêtre de visibilité (detaileddownloadp lan = true). Le schéma de contrôle a été instancié pour chaque activité (cf. Table 2). Par exemple, le signal TrStart du planificateur d observations, qui doit être relancé à chaque fois que 5 On peut considérer en effet que les applications du niveau décisionnel sont activées ou arrêtées en fonction de commandes provenant du sol et des alarmes venant du niveau opérationnel.

6 le contexte de planification a changé, correspond à la réception d un événement signalant l arrivée d une nouvelle requête, ou l abandon d une requête, ou l achèvement d une observation, ou une alarme du processus de suivi de l état. Cependant, la commande de lancement n est envoyée que si un plan de télédéchargement ou une estimation des ressources est disponible (Lca). Cette condition peut être satisfaite en lançant l estimateur de télédéchargement (Alc) et en attendant son résultat. Toutefois, il est inutile de lancer le planificateur d observations lorsqu une observation est en cours d exécution (Lc), puisqu il faudra le relancer à la fin de l observation (pour tenir compte des nouveaux niveaux de ressource). TrStart RequestEvt(new) or RequestEvt(abandoned) or ReportEvt or AlarmEvt starta / Lc is_in_state(observation,idleexecution) Lca (updatedroughplan or detaileddownloadplan) and is_in_state(obs_planner,idleexecution) Alc if( is_in_state(obs_planner,idleexecution)) TrStop(observation planner) if ( updatedroughplan and detaileddownloadplan) TrStart(rough download planner) Ltm durée maximale de l estimateur de télédéchargement Lcmd Cmd_StartObsPlanner LtmA / exec / Ec true Eca true Aec / Etm Ectm 0 TrStop / Sc true Sca true Asc / Stm 0 Scmd Cmd_StopObsPlanner StmA if ( obsplanempty) Cmd_ErasePlanTimeline(observation) fr / exa / TAB. 2 Schéma de contrôle pour le planificateur d observations 4 Expérimentation La prochaine phase de ce travail est l adaptation des algorithmes de planification aux contraintes temps-réel et le test de leurs performances et de la boucle de reprogrammation dynamique sur un banc équipé d un processeur SPARC fourni par Alcatel Alenia Space. Une maquette a été conçue pour intégrer le niveau décisionnel décrit précédemment dans l architecture Plug & Play développée par Alcatel Alenia Space (cf. [8]). 4.1 Interface avec l architecture Plug & Play Niveau fonctionnel Niveau opérationnel Niveau décisionnel SCAO Composants applicatifs batterie Services (TM, TC, temps,...) Hardware... Bus logiciel OS et Hardware Dependent Software OBCP Accès direct aux services FIG. 4 Architecture Plug & Play Composants décisionnels L architecture Plug & Play a été conçue pour améliorer la réutilisation des composants logiciels et la modification dynamique du logiciel à bord. Elle se décompose en deux parties distinctes (voir la Figure 4). Une partie gelée contient l OS temps-réel, le logiciel dépendant du matériel et les services (réception de télécommandes, gestion de la télémétrie, gestion du temps, etc.). Et une partie plug & play regroupe les composants applicatifs indépendants. Ces composants peuvent faire des appels directs à la couche des services. Sinon, la communication entre la couche des services et les composants ou entre les composants est réalisée par un bus logiciel dédié à la transmission de télécommandes, de télémétrie et d événements. Ainsi, un niveau décisionnel peut être intégré grâce à l insertion de nouveaux composants applicatifs. Le niveau décisionnel reçoit des télécommandes du centre de contrôle au sol (par exemple de nouveaux objectifs mission), il produit des activités à réaliser par les sous-systèmes et reçoit des bilans sur ces activités, ou éventuellement des alarmes. Les composants décisionnels ont accès à des informations sur l état courant du système (par exemple le niveau de la batterie) via la couche des services et la télémétrie. Les activités planifiées par le niveau décisionnel sont souvent représentées à un niveau abstrait (par exemple faire une observation ) à cause de la complexité des algorithmes et de la nécessité de simplifier le problème de planification. Une telle activité doit ensuite être détaillée en une séquence de commandes pour les sous-systèmes. Ceci peut être réalisé en utilisant des OBCPs (On-Board Control Procedures, voir [7]). Une OBCP est associée à chaque type d activité. Lorsque l exécutif décisionnel décide de lancer ou arrêter une activité du plan, il envoie une télécommande via le bus dont l exécution active ou interrompt l OBCP correspondante. L exécution de l OBCP peut aussi élaborer des évé-

7 nements bilans renvoyés à l exécutif décisionnel. 4.2 Maquette Plus précisément, le niveau décisionnel de la maquette est constitué des composants applicatifs suivants : un composant planning, qui regroupe les quatre planificateurs et le processus de gestion des requêtes, un composant plan database, qui est responsable de la gestion du plan courant (intégration des plans fournis par les différents planificateurs, séquencement des activités du plan, surveillance de la consistance de l utilisation des ressources prédites par le plan et de l utilisation réelle), et un composant executive qui implémente l exécutif décisionnel. Afin de tester la boucle de reprogrammation dynamique, trois composants de simulation ont également été définis : Un composant data analysis est utilisé pour simuler la détection à bord de nouveaux points chauds et donc de nouvelles requêtes qui doivent être prises en compte dans la programmation de la mission. Un composant orbit propagator est utilisé pour simuler le calcul des événements orbitaux tels que la prédiction du prochain survol d une zone ou les fenêtres de visibilité avec les stations sol. Finalement, un composant SatSimu est utilisé pour simuler l exécution (succès ou échec) des activités et l évolution des ressources du satellite (l espace mémoire disponible et le niveau d énergie). La maquette est encore en cours de développement. Cependant, l exécutif décisionnel a été implémenté 6. Pour donner une idée du travail nécessaire pour développer un exécutif décisionnel pour une nouvelle application, le composant executive représente environ 2410 lignes de code, dont 50% sont génériques et réutilisables. La taille du code spécifique à l application augmente avec le nombre d activités (7 dans notre exemple), avec le nombre de signaux entrants et sortants (respectivement 10 et 22 dans l exemple), avec le nombre de variables de contrôle (6 dans l exemple) et avec le nombre de paramètres des signaux et activités. 5 Conclusion Les futurs scénarii d autonomie vont nécessiter l intégration de systèmes de planification dans le logiciel de vol d un satellite. Nous présentons dans cet article un exemple d architecture comprenant plusieurs planificateurs spécialisés et nous proposons un exécutif générique pour les coordonner. Une maquette est en cours de développement pour tester les performances temps-réel de ces algorithmes et la boucle de reprogrammation dynamique. 6 Remerciements Nous souhaitons remercier Sylvain Damiani et Gérard Verfaillie pour de nombreuses et enrichissantes discussions sur la planification et les architectures décisionnelles pour les applications spatiales, ainsi que Gérald Garcia et Christelle Roubion pour leur aide précieuse sur l implémentation de la maquette. Références [1] R. Alami, R. Chatila, S. Fleury, M. Ghallab, and F. Ingrand. An architecture for autonomy. International Journal of Robotics Research, Special Issue on Integrated Architectures for Robot Control and Programming, 17(4), [2] R. P. Bonasso, J. Firby, E. Gat, D. Kortenkamp, D. P. Miller, and M. G. Slack. Experiences with an architecture for intelligent, reactive agents. Journal of Experimental & Theoretical Artificial Intelligence, 9(2/3) : , April [3] M-C. Charmeau and E. Bensana. Agata, a lab bench project for spacecraft autonomy. In International Symposium on Artificial Intelligence Robotics and Automation in Space (isairas), [4] S. Chien, R. Knight, A. Stechert, R. Sherwood, and G. Rabideau. Using iterative repair to improve the responsiveness of planning and scheduling. In Proceedings of the International Conference on AI Planning Systems (AIPS), [5] S. Damiani, G. Verfaillie, and M-C. Charmeau. An earth watching satellite constellation : how to manage a team of watching agents with limited communications. In Proceedings of the International Joint Conference on Autonomous Agents and Multi-Agent Systems (AAMAS), [6] Sylvain Damiani, Gérard Verfaillie, and Marie-Claire Charmeau. An anytime planning approach for the management of an earth watching satellite. In International Workshop on Planning and Scheduling for Space (IWPSS), [7] G. Garcia, C. Roubion, and S. Prunier. Java as a standardized on-board control procedures platform? In Proceedings of DASIA, [8] C. Moreno and G. Garcia. Plug & play architecture for on-board software components. In Proceedings of DASIA, [9] N. Muscettola. Hsts : Integrated planning and scheduling. In Fox, M., and Zweben, M., eds, Intelligent Scheduling, Morgan Kaufman, [10] N. Muscettola, P. P. Nayak, B. Pell, and B. Williams. Remote agent : To boldly go where no ai system has gone before. Artificial Intelligence, 103, langage C, avec des restrictions spécifiques aux applications spatiales telles que l allocation statique de mémoire.