L'évaluation de l'algorithme proposé et sa comparaison avec d'autres approches est problé-matique parce que les algorithmes existants (voir par exemple (Lemaître et al. 2002, Cordeau et Laporte 2005, Bianchessi et al. 2007, Beaumet et al. 2011)) ont été developpés pour des systèmes physiques de nature diérente.
Néanmoins, la mission qui se rapproche le plus de celle étudiée est Pléiades-HR, qui sera d'ailleurs opérationnelle très prochainement. Le CNES obtient un plan journalier d'activités en 40 minutes (incluant contrôles a posteriori, traduction en message de programmation pour les satellites, production des interfaces et des bilans de programmation). Pour information, le planicateur utilisé fait appel à un glouton hiérarchique dont le fonctionnement général est le suivant : on tente d'insérer successivement les observations candidates (par ordre de priorité décroissante et selon un certain critère entre observations de même priorité) à leur date de survol, avec vérication exacte de la cinématique des rendez-vous en attitude ; en cas d'échec, on calcule un réarrangement local de la séquence des observations voisines ; en cas de nouvel échec, l'observation candidate est dénitivement abandonnée. Une fois le plan de prises de vue obtenu, la construction du plan de vidage est engagée. Les vérications liées à la mémoire, l'énergie et les températures notamment, sont eectuées après coup. En cas de problème, on désature les vidages et les observations de façon itérative.
En se plaçant dans le contexte précis de la mission Pléiades-HR, il semble toujours dicile de comparer notre algorithme à celui déjà en place pour la simple raison qu'il est dicile de s'assurer que les hypothèses liées aux satellites sont bien les mêmes. Le résultat en serait
biaisé. Nous aurions pu cependant encoder nous-même l'algorithme actuellement utilisé et le comparer avec celui que l'on propose, sur une base commune. Là encore, pour comparer de façon juste, il faut s'assurer que toutes les subtilités de l'algorithme actuel ont été intégrées.
Cela n'a pas été réalisé dans ces travaux.
En revanche, nous réalisons toutes sortes d'expérimentations dans cette section pour at-tester de l'ecacité de l'algorithme de planication.
7.1.1 Résultats expérimentaux sur une instance réaliste de taille réelle Un scénario réaliste de taille réelle est fourni par le CNES. Ses caractéristiques sont les suivantes :
. un horizon de planication de 24 heures ; . 8 stations sol de réception ;
. 3 niveaux de priorité ;
. 1166 requêtes d'observations, toutes associées à une bande et toutes de même poids (1) ; parmi ces requêtes, 377 de priorité 3 (la plus forte), 419 de priorité 2, et 370 de priorité 1 (la plus faible) ;
. des prévisions météorologiques construites à partir de données climatologiques.
Sur cette instance, le temps nécessaire à la production du plan journalier est de l'ordre de 5 minutes sur un processeur Intel 3 GHz, sous Linux, en s'autorisant jusqu'à 2.5 Go de mémoire vive. Ce temps de calcul est acceptable puisque l'objectif est de descendre au-dessous de 10 minutes. Dans ce plan, notons que 907 (78%) observations se voient réalisées et vidées, 15 (1%) se voient réalisées mais non vidées, et 244 (21%) se voient non réalisées. Plus précisément, 274 (73%) observations de priorité 3 sont réalisées, contre 355 (85%) de priorité 2 et 293 (79%) de priorité 1. Les taux de réalisation des observations de priorité 2 et 1 supérieurs à celui des observations de priorité 3 peuvent s'expliquer par la présence de conits géographiques plus nombreux entre observations de priorité 3. Une autre raison est que l'algorithme évite, étant donnée l'heuristique utilisée au niveau 1 de décision, de sélectionner les observations pour lesquelles les prévisions météorologiques sont mauvaises.
La gure 7.1 rapporte la vue principale de l'outil PLANET une fois la planication achevée.
Les observations réalisées apparaissent en bleu sur le planisphère, tandis que les autres appa-raissent en rouge. En bas à droite se trouve représentée l'évolution de la valeur du plan courant au cours du processus de planication (voir le zoom fourni par Figure 7.2). On y décèle trois phases distinctes, chacune associée à un niveau de priorité : la première considère exclusive-ment les requêtes de priorité 3 (en rouge) ; la deuxième considère les requêtes de priorité 3 mais aussi celles de priorité 2 (en bleu) ; enn, la troisième considère, en plus de celles de pri-orité 2 et 3, les requêtes de pripri-orité 1 (en vert). Il est intéressant de constater que l'étanchéité des priorités est préservée. Dans le cas contraire, nous aurions une baisse signicative de la qualité des observations de prioritépdans les plans de priorité inférieure àp. À noter qu'aucun backtrack chronologique n'apparaît ici. Le cas échéant, une alternance d'augmentations et de chutes brutales dans le critère serait constatée.
Les gures 6.6, 6.7, 6.8 et 6.9 détaillent le plan obtenu pour ce scénario qualié de "réel".
7.1. Évaluation des performances en planication 135
Figure 7.1 Vue principale de l'outil PLANET une fois la planication achevée.
priority 3 priority 2 priority 1 0 0 : 0 0 0 0 : 0 1 0 0 : 0 2 0 0 : 0 3 0 0 : 0 4
t i m e ( m i n u t e s ) 0
1 0 2 0 3 0 4 0 5 0 6 0 7 0 8 0 9 0 1 0 0 1 1 0 1 2 0
quality
Figure 7.2 Évolution de la valeur du plan courant au cours du processus de planication.
Tout fonctionne correctement, avec un niveau d'énergie globalement élevé tout au long de la journée et la mémoire protégée de toute saturation. Signalons que le système étant bien dimensionné, il y a très peu de chances de saturer la mémoire ou d'atteindre un niveau critique d'énergie. En pratique, les contraintes qui s'expriment sont avant tout l'agilité dans les zones (très) denses, puis la thermique, et seulement après, et rarement, l'énergétique et la mémoire (panne de batteries, perte de stations de réception, . . . ).
La gure 7.3 met l'accent sur certains chronogrammes représentant l'évolution de l'état de l'un des satellites, sur un horizon de 14 minutes (zoom sur une tranche temporelle). En haut à gauche, un premier chronogramme fournit l'activité principale à bord (OBN pour ob-servation de nuit, OBD pour obob-servation de jour, HP pour pointage héliocentrique, GP pour pointage géocentrique, OM pour man÷uvre orbitale, et RDV pour rendez-vous en attitude).
On y retrouve l'alternance des activités qui contraignent l'attitude du satellite. Au-dessous, un deuxième chronogramme indique l'indice de la bande observée, le cas échéant. Encore plus bas, un chronogramme rapporte les cycles d'activation du plan focal IR, lequel reste on pour les cinq premières observations, puis pour les quatre suivantes, et enn pour la dernière. Dans la seconde colonne, un premier chronogramme indique l'indice de l'observation dont est is-sue l'image télédéchargée le cas échéant. Au-dessous, un chronogramme rapporte les cycles d'activation de l'antenne haut-débit, laquelle est maintenue on pendant tous les télédécharge-ments. Encore plus bas, un autre chronogramme montre la station sol (toujoursSt3 dans cet exemple) vers laquelle s'exécute le télédéchargement courant le cas échéant. Enn, les deux chronogrammes du bas représentent respectivement l'évolution de l'énergie et l'évolution de la mémoire. La mémoire disponible à bord décroît suite aux observations au début de la fenêtre, et croît suite aux vidages à la n.
7.1.2 Pertinence des heuristiques adoptées
Dans cette section, nous confrontons les heuristiques retenues à d'autres possibles. Nous pointons toute une série d'éléments, même si seuls la qualité du plan et le temps de calcul jugent de leurs performances. Les heuristiques testées sont décrites dans la table 7.1, et les 10 instances aléatoires sur lesquelles sont faites ces comparaisons sont précisées dans la table 7.2.
Pour chaque quantité intéressante, nous relevons sa moyenne et son écart-type, lequel gure entre parenthèses.
Niveau 1
La table 7.3 récapitule les résultats obtenus. Notons d'emblée que l'heuristique retenue ore en moyenne le meilleur vecteur qualité (avec de faibles écarts-types) suivie par EOED (Earliest Observation Earliest Date), et enn EOBU (Earliest Observation Best Utility).
Si l'on regarde de plus près les résultats consignés, EOED réalise plus d'observations que les autres, mais avec une couverture nuageuse moyenne et un angle d'acquisition moyen plus élevés. Elle s'avère intéressante sur les orbites "chargées" puisque la densité des zones oblige, quoiqu'il en soit, les satellites à acquérir certaines images à fort tangage avant ou arrière.
En revanche, elle ne tient pas compte des conditions météorologiques et est médiocre sur les orbites peu chargées, où certaines observations peuvent s'eectuer à leur date de survol.
EOBU réalise moins d'observations que les autres car elle a tendance à les eectuer aux dates de survol, mais avec une couverture nuageuse moyenne et un angle d'acquisition meilleurs (plus faibles). Elle permet d'obtenir des angles d'acquisition faibles, mais est myope dans son choix de date (gain immédiat intéressant mais choix limitant pour la suite) et repousse, voire empêche, les observations ultérieures.
7.1. Évaluation des performances en planication 137
Figure 7.3 Mise en évidence de certains chronogrammes représentant l'évolution de l'état de l'un des satellites sur un horizon de 14 minutes.
L'heuristique rule1 est un bon compromis puisque, nalement, elle ache la meilleure qualité moyenne pour les plans produits. Le temps de calcul engendré par rule1 est supérieur aux autres mais reste très faible.
Identiant Stratégie
EOED Choix de l'observation la plus proche dans le temps + date au plus tôt
EOBU Choix de l'observation la plus proche dans le temps + date de meilleure utilité rule1 Heuristique retenue au niveau 1 (décrite en 4.6.1)
GP Insertion de pointages géocentriques exclusivement
HPGP Insertion de pointages héliocentriques en priorité puis géocentriques rule2 Heuristique retenue au niveau 2 (décrite en 4.6.2)
CO Vidages par ordre chronologique de création BU Vidages par utilité décroissante
rule3 Heuristique retenue au niveau 3 (décrite en 4.6.3) MA Activations minimalistes des instruments
CR Activations regroupées si distantes de moins d'une minute rule4 Heuristique retenue au niveau 4 (décrite en 4.6.4)
Table 7.1 Heuristiques testées
Paramètres Valeurs
nombre de satellites 2
centres de réception {Kiruna,Creil,Bruxelles,Madrid,Rome,Gelsdorf, Tanagra,Mas Palomas}
centres de contrôle (inutiles ici) {Kiruna,Aussaguel,Kerguelen}
observations (nombre, position, priorité) 1000 zones choisies aléatoirement dans des régions d'intérêt militaire (probabilité de 0.15 d'accepter une autre zone sur le continent, éloignée des pôles)
horizon de planication 24 h
angles d'observations autorisés 30avant et arrière, 40de façon globale couverture nuageuse données climatologiques moyennes man÷uvres orbitales (nombre, type) 0
Table 7.2 Caractéristiques des 10 instances utiles à la comparaison des heuristiques Niveau 2
La table 7.4 récapitule les résultats obtenus. Notons d'emblée que les qualités moyennes et les temps de calcul sont similaires. En eet, les choix de niveau 2 (insertion de pointages hélio et géocentriques) n'ont pas d'impact direct sur le critère d'évaluation en situation nominale.
En revanche, ces choix peuvent s'avérer importants dans le cas d'une panne de batterie ou d'une perte de station de réception. On aura donc tendance à préférer, entre deux plans de même qualité, celui qui assure le plus fort taux de charge et les meilleures communications bord-sol.
Si l'on regarde de plus près les résultats consignés, GP fournit les meilleurs ratios moyens
temps de vidage possible
visibilités stations réception car elle assure aux satellites une communication avec le sol dès lors
7.1. Évaluation des performances en planication 139
EOED EOBU rule1
nombre d'observations réalisées 752.3 (10.3) 685.0 (11.9) 720.4 (10.9)
. . . de jour 410.8 (13.3) 367.6 (15.1) 392.4 (11.7)
. . . de nuit 341.5 (11.3) 317.4 (12.4) 328.0 (13.3)
. . . de priorité 3 (sur 333.6 (15.9)) 232.5 (21.1) 205.3 (13.4) 222.7 (15.9) . . . de priorité 2 (sur 328.3 (17.1)) 271.8 (19.2) 242.4 (12.9) 253.7 (13.8) . . . de priorité 1 (sur 338.1 (15.5)) 248.0 (16.6) 237.3 (13.4) 244.0 (12.7) . . . avec une couverture nuageuse < 50% 349.1 (11.8) 342.3 (11.7) 346.6 (12.1) . . . avec une couverture nuageuse≥50% 403.2 (16.4) 342.7 (15.8) 373.8 (15.9) couverture nuageuse moyenne 0.508 (0.010) 0.484 (0.012) 0.494 (0.014)
angle moyen d'acquisition 29.8(0.4) 25.6(0.5) 25.7(0.4)
temps de calcul 102 s (6) 112 s (3) 173 s (6)
qualité du plan
74.61(6.31) 74.44(7.27) 63.79(7.93)
69.85(4.73) 75.04(6.23) 71.81(6.36)
76.12 (6.61) 77.18 (6.72) 71.40 (6.13)
Table 7.3 Évaluation de l'heuristique retenue au niveau 1
GP HPGP rule2
satellite 1 taux de charge moyen 48.5 % (1.2) 97.2 % (0.1) 96.4 % (0.6)
temps de vidage possible
visi. stations récep. 81.4 % (2.2) 64.3 % (1.7) 80.3 % (2.1) satellite 2 taux de charge moyen 50.9 % (1.1) 97.2 % (0.1) 96.4 % (0.3)
temps de vidage possible
visi. stations récep. 81.2 % (3.3) 57.9 % (3.1) 80.0 % (3.4)
temps de calcul 172 s (5) 176 s (6) 173 s (6)
qualité du plan
76.11(6.61) 77.18(6.72) 71.44(6.01)
76.06 (6.58) 76.77 (6.97) 68.99 (5.87)
76.12 (6.61) 77.18 (6.72) 71.40 (6.13)
Table 7.4 Évaluation de l'heuristique retenue au niveau 2
qu'ils se trouvent en visibilité station, mais les pires taux de charge moyen. A contrario, HPGP fournit les meilleurs taux de charge moyen, mais les pires temps de vidage possible.
L'heuristique rule2 est un bon compromis puisque, nalement, elle ache des taux de charge très proches de ceux de HPGP, et des temps de vidage possible très proches de ceux de GP.
Niveau 3
La table 7.5 récapitule les résultats obtenus. L'heuristique retenue, qui est un compromis entre gain immédiat apporté au critère et durée de vidage, ne se distingue pas des deux autres, pourtant plus naïves. En eet, le dimensionnement du système est tel que, sans perte de station sol, le télédéchargement n'est jamais un goulet d'étranglement, et la totalité des images peut être vidée sur un passage. En revanche, l'heuristique joue sur l'ordre de vidage, et donc sur l'âge de l'information fournie aux opérateurs. En réalité, il n'y a ici presqu'aucune diérence entre rule3 et BU car les images générées de jour sont toutes de durée identique, de même
CO BU rule3 nombre d'images générées 1112.8 (18.2) 1112.8 (18.2) 1112.8 (18.2) nombre d'images télédéchargées 1076.3 (43.0) 1076.3 (43.0) 1076.3 (43.0)
. . . de priorité 3 328.0 (29.5) 328.0 (29.5) 328.0 (29.5)
. . . de priorité 2 377.0 (28.4) 377.0 (28.4) 377.0 (28.4)
. . . de priorité 1 371.3 (21.2) 371.3 (21.2) 371.3 (21.2)
âge moyen de l'information télédéchargée 3045 s (324) 3046 s (324) 3046 s (324)
temps de calcul 173 s (5) 174 s (6) 173 s (6)
qualité du plan
76.12(6.60) 77.17(6.71) 71.39(6.13)
76.12 (6.61) 77.18 (6.72) 71.40 (6.13)
76.12(6.61) 77.18(6.72) 71.40(6.13)
Table 7.5 Évaluation de l'heuristique retenue au niveau 3 pour les images générées de nuit (durée environ trois fois plus élevée).
Niveau 4
La table 7.6 récapitule les résultats obtenus. Notons d'emblée que l'heuristique retenue ore en moyenne le meilleur vecteur qualité et le meilleur temps de calcul (avec de faibles écarts-types) suivie par CR (Current Rule, actuellement utilisée chez Pléiades), et enn MA (Minimal Activation).
Pour chacune des règles et pour chaque instrument, nous relevons d'une part le pourcentage de cycles on/o restants et d'autre part le pourcentage de temps on restant. L'objectif est qu'ils ne soient pas trop diérents pour ne pas consommer trop tôt l'une des deux quantités.
Si l'on regarde de plus près les résultats consignés, la règle MA est très mauvaise : au bout des 10 minutes autorisées, elle fournit un plan ne contenant que les observations de priorité 3, et consomme beaucoup plus vite son nombre de on/o restants que son temps on restant.
La règle CR, qui regroupe les activations distantes de moins d'une minute, fournit un plan complet en 6 minutes. Seulement, là encore, nous observons d'importants écarts entre les deux quantités étudiées. Nous constatons notamment que le nombre de on/o restant pour la TMI est consommé tandis qu'il reste 70% du temps on, si bien qu'une grande partie des images en mémoire ne sont pas télédéchargées, et implique donc une mauvaise qualité moyenne du plan.
7.1.3 Sensibilité au nombre de demandes d'observation
Nous étudions ici l'inuence du nombre d'observations demandées sur le processus de planication. Les instances aléatoires utilisées sont décrites dans la table 7.7. Il s'agit de 10 instances de 100 observations aléatoires, 10 instances de 200 observations aléatoires, et ainsi de suite par pas de 100 jusqu'à 2300 observations (230 instances).
Les temps de calcul moyens relevés sont achés sur la gure 7.4, et les qualités moyennes par priorité gurent sur la gure 7.5.
Quoiqu'il arrive, si le processus de planication n'est pas achevé au bout de 10 minutes (du fait de backtracks chronologiques), celui-ci est stoppé. Si le dernier plan en construction était
7.1. Évaluation des performances en planication 141
MA CR rule4
satellite 1 plan focal IR % on/o restants 11.8 7.7 22.6
% temps on restant 90.7 36.8 18.5
plan focal visible % on/o restants 9.2 4.8 13.7
% temps on restant 90.1 25.8 10.8
TMI % on/o restants 0.0 0.0 1.3
% temps on restant 97.1 70.8 24.3
satellite 2 plan focal IR % on/o restants 21.3 8.6 25.6
% temps on restant 92.4 43.6 23.2
plan focal visible % on/o restants 5.3 2.3 12.5
% temps on restant 89.0 27.5 13.3
TMI % on/o restants 0.0 0.0 22.0
% temps on restant 92.9 69.2 29.0
temps de calcul 600 s (0) 249 s (137) 173 s (6)
qualité du plan
58.25(6.53) 0(0) 0(0)
65.18(5.90) 65.81(6.21) 54.12(20.0)
76.12(6.61) 77.18(6.72) 71.40(6.13)
Table 7.6 Évaluation de l'heuristique retenue au niveau 4
Paramètres Valeurs
nombre de satellites 2
centres de réception {Kiruna,Creil,Bruxelles,Madrid,Rome, Gelsdorf,Tanagra,Mas Palomas}
centres de contrôle (inutiles ici) {Kiruna,Aussaguel,Kerguelen}
observations (nombre, position, priorité) 100..2300 zones choisies aléatoirement (par pas de 100) dans des régions d'intérêt militaire (probabilité de 0.15 d'accepter une autre zone sur le continent, éloignée des pôles)
horizon de planication 24 h
angles d'observations autorisés 30avant et arrière, 40de façon globale couverture nuageuse données climatologiques moyennes man÷uvres orbitales (nombre, type) 0
Table 7.7 Caractéristiques des 23×10 instances évaluant l'inuence du nombre d'observations demandées
de priorité p, alors on retourne le plan de priorité p+ 1 (réalisable sur l'horizon entier). En pratique, nous disposons toujours d'un plan à retourner car le premier plan est toujours créé rapidement : aucun backtrack chronologique n'est susceptible d'être déclenché. Cette limitation en temps de calcul est tout à fait visible sur la gure 7.4 puisque les plans, à partir de 1500 observations environ, sont produits en 10 minutes. Notons que, jusqu'à 1000 observations les temps sont faibles (inférieurs à 200 secondes) avec de très faibles écarts-types.
La gure 7.5 est très intéressante car elle montre les bénéces de notre planication par niveau de priorité. La valeur du critère associée aux requêtes de priorité3 (requêtes les plus prioritaires) augmente linéairement avec le nombre d'observations, évidemment jusqu'à une certaine limite qui n'apparaît pas sur la gure. À noter que la qualité des requêtes de plus faible
0 5 0 0 1 000 1 500 2 000 nombre d'observations demandées 0
5 0 1 0 0 1 5 0 2 0 0 2 5 0 3 0 0 3 5 0 4 0 0 4 5 0 5 0 0 5 5 0 6 0 0
Temps de calcul (s)
Figure 7.4 Évolution du temps de calcul en fonction du nombre d'observations demandées.
priorité commence à être sacriée à partir de 1000 observations, suivie ensuite par la qualité des requêtes de priorité intermédiaire. Cette gure souligne l'optimisation lexicographique qui est eectuée.
7.1.4 Distance à l'optimum sur une petite instance à l'ordonnancement fortement contraint
Il est toujours bon d'avoir une estimation de l'écart entre une solution approchée et la so-lution optimale. Pour ce faire, nous exécutons l'algorithme PLANET sur une instance petite néanmoins très contrainte, après relaxation du problème. Cette instance implique 13 observa-tions de régions géographiquement très proches les unes des autres. Toutes les requêtes consid-érées ont la même priorité (3) et le même poids (1), et se limitent à l'observation d'une bande.
Les prévisions météorologiques prises en compte sont également identiques (très bonnes) entre requêtes.
Sur cette instance, nous comparons l'algorithme PLANET avec un algorithme optimal A∗, qui utilise un pas de discrétisation d'une seconde (avec durées de rendez-vous arrondies à la seconde supérieure). L'algorithme PLANET est en mesure de planier 12 observations, obtenant une valeur de critère de 9.48, tandis que l'algorithme A∗ est capable de toutes les planier avec une valeur de critère de10.58 (les valeurs de critère tiennent seulement compte des angles d'acquisition). Figure 7.6 et Figure 7.7 fournissent les plans produits par les deux algorithmes. La trace au sol du satellite survolant la France du sud vers le nord est achée en vert. Pour chaque zone au sol, sa petite fenêtre d'observation et la projection de l'attitude
7.1. Évaluation des performances en planication 143
prio 3 prio 2 prio 1
0 5 0 0 1 000 1 500 2 000
nombre d'observations demandées 0
2 5 5 0 7 5 1 0 0 1 2 5 1 5 0 1 7 5
Qualité
Figure 7.5 Évolution du vecteur qualité en fonction du nombre d'observations demandées.
du satellite au moment de la prise de vue sont achées en bleu ou rouge, selon l'algorithme.
Soulignons que PLANET produit le résultat qui est le sien en seulement 2 secondes alors que notre algorithme A∗ prend ici5241 secondes pour statuer. De plus, notre algorithme A∗ est incapable de résoudre des instances de plus de 13 observations par manque de RAM.
Cependant, la comparaison est ici faite pour avoir une idée (visuelle) de la diérence entre une solution produite par PLANET et la solution optimale.
7.1.5 Performance de l'heuristique de choix des observations sur le prob-lème très simplié du Challenge ROADEF'2003
Par ailleurs, nous avons souhaité confronter notre algorithme à des techniques sophistiquées (recherche taboue, recuit simulé, algorithmes génétiques, programmation linéaire . . . ) sur un problème proche, celui du challenge ROADEF'2003 (Verfaillie et al. 2003). Alors organisée par l'ONERA et le CNES, cette compétition ore l'énorme avantage de disposer d'une base commune bien dénie, des mêmes outils d'évaluation et des résultats propres à chaque par-ticipant. En réalité, ce problème très relaxé par rapport à celui qui fait l'objet de la thèse nous oblige à mettre entre parenthèses une grande partie de l'algorithme : seule l'heuristique de choix d'observation est ici évaluée, mais le résultat demeure tout de même une indication importante.
Figure 7.6 Plan produit par l'algorithme PLANET.
Figure 7.7 Plan optimal produit par un algorithme A∗.
Description du challenge
Le challenge ROADEF est une compétition organisée tous les deux ans par la Société Française de Recherche Opérationnelle et d'Aide à la décision. Le but de ce challenge est double. D'une part, il permet aux industriels d'avoir une meilleure perception des développe-ments récents dans le domaine de la Recherche Opérationnelle et de l'Aide à la Décision, et il confronte les jeunes universitaires à une problématique décisionnelle, souvent complexe, rencontrée dans le milieu industriel. En ce sens, le challenge leur permet de vivre une
expéri-7.1. Évaluation des performances en planication 145 ence des exigences et dicultés rencontrées dans l'industrie. D'autre part, ce challenge initie un partenariat permanent entre des industriels et des jeunes universitaires sur des projets d'ampleur industrielle nécessitant la conjonction de compétences scientiques élevées avec une culture et une réalité de l'entreprise actuelle. Aussi, depuis que la catégorie Senior existe, ce challenge permet aux chercheurs conrmés d'une part de montrer et de confronter leurs savoirs et savoir-faires sur un sujet pratique, et d'autre part d'établir des partenariats avec les industriels.
Le sujet de 2003 était proposé par l'ONERA et le CNES. Il s'agissait d'un problème simplié de gestion des prises de vue réalisées par un satellite agile d'observation de la Terre.
Le problème se résume ainsi : sélectionner un ensemble de prises de vue parmi l'ensemble des prises de vue réalisables sur l'horizon considéré et les ordonner dans le temps. Le résultat attendu est donc une séquence de prises de vue qui soit réalisable.
Les contraintes à respecter sont les suivantes. Chaque observation doit être réalisée dans sa fenêtre de visibilité. Entre deux observationsoeto0, un temps minimal de transition dépendant de o et o0 est à respecter. Enn, pour toute paire de bandes jumelles issues d'une demande stéréoscopique, soit aucune n'est acquise, soit les deux (voir en 7.1.5).
Le critère à optimiser (à maximiser) est un critère de gain, déni comme la somme sur l'ensemble des demandes du gain associé à l'acquisition complète ou partielle de chaque de-mande. Le gain associé à l'acquisition complète d'une demande est déni comme le produit de la surface associée à cette demande par le gain par unité de surface. Il est multiplié par 2 en cas de demande de type stéréo, de façon à ne pas défavoriser ces demandes qui sont plus consommatrices en termes de ressource satellite. Le gain associé à l'acquisition partielle d'une demande est déni comme le produit du gain associé à son acquisition complète par une fonction de la fraction acquise (fonction linéaire par morceaux passant par les points<0,0>,
<0.4,0.1>,<0.7,0.4>et <1,1>). La fraction acquise d'une demande est dénie comme la somme des fractions associées aux bandes acquises, divisée par 2 dans le cas d'une demande stéréo, pour tenir compte du fait que toute bande d'une demande stéréo est acquise deux fois.
g=
Nr
X
i=1
gr[i]
gr[i] =gc[i].P(fr[i]) gc[i] =G[i].S[i].(St[i] + 1) fr[i] = St[i]+11 .S[i]1 . X
j∈Str[i]
ss[j].Su[j]
ss[j] =sa[2j−1] +sa[2j]
où : Nr désigne le nombre de requêtes d'observation
G[i]désigne le gain par kilomètre carré associé à la réalisation complète de la requêtei S[i]désigne la surface en kilomètres carrés du polygone associé à la requêtei
St[i]précise si la requête est mono (= 0) ou stéréoscopique (= 1) Str[i]désigne l'ensemble des bandes associées à la requêtei Su[j]désigne la surface utile de la bandej
sa[j]précise si la bandej est retenue (= 1) ou non (= 0)
La phase de qualication consiste à évaluer les programmes des candidats sur huit instances.
L'évaluation dière légèrement selon la nature déterministe ou non des programmes.
Pour une méthode déterministe, l'évaluation consiste à faire tourner le programme du candidat une fois sur chaque instance. Pour chaque instance i, on obtient la valeur de la solution pour chaque instance : ValSoli.
Pour une méthode non déterministe, l'évaluation consiste à faire tourner le programme du candidat 10 fois sur chaque instance. Pour chaque exécution jdu programme sur une instance i, on obtient la valeur de la solution pour chaque instance : ValSolij.
Avec chaque instance est fournie une solution de référence. La note d'un candidat est la moyenne des écarts relatifs par rapport aux solutions de référence exprimée en pourcentage :
Note = 100×18
8
X
i=1
ValSoli−ValRefi
ValRefi (si déterministe) Note = 100×801
8
X
i=1 10
X
j=1
ValSolij −ValRefi
ValRefi (si non déterministe)
Disposant d'un processeur à 3 GHz sous Linux, nous nous autorisons un temps de calcul de 115 secondes.
Adaptation au contexte du challenge
Ce problème concentre de nombreuses simplications vis-à-vis de celui qui fait l'objet de cette thèse. Tout d'abord, les contraintes de limitation de la mémoire et de l'énergie à bord ne sont pas prises en compte, tout comme la planication des vidages de données, des pointages spéciques, et de l'activation des instruments. Un seul satellite est considéré et l'horizon de planication équivaut à une seule révolution de ce satellite autour de la Terre, ce qui élimine la possibilité d'avoir plusieurs fenêtres de visibilité pour une même bande. Les requêtes d'observation sont toutes identiques, d'où la suppression de l'aspect lexicographique de l'optimisation. Le temps de transition minimal entre deux observations o1 et o2 dépend seulement de la séquence, et non plus de la date de n deo1. De plus, les contraintes portant sur la trajectoire en attitude (non éblouissement de l'instrument optique, production énergétique des panneaux solaires, fenêtres eectives de vidage) sont oubliées. Enn, notons que le critère d'optimisation ne tient pas compte de la qualité image (angle d'acquisition, et conditions météo).
An de comparer les solutions produites par notre planicateur à celles des autres par-ticipants, nous sommes donc amenés à mettre entre parenthèses une grande partie de notre