Jul 24, 2002 - 2.3.2 Generation Algorithm . ... 10 Problem Generation Algorithm . ..... In the Mars Express domain the goal can be synthesized with this.
Research Project “Efficient Planning Algorithms for an Interplanetary Mission”
Automating the Generation of Downlink Spacecraft Operation in Mars Express: Analysis, Algorithms and an Interactive Solution Aid
Amedeo Cesta, Angelo Oddi, Gabriella Cortellessa and Nicola Policella
ISTC-CNR [Pst] Planning and Scheduling Team Institute for Cognitive Science and Technology Italian National Research Council Viale Marx 15, I-00137 Rome, Italy {cesta,oddi,corte,policella}@ip.rm.cnr.it
MEXAR-TR-02-10 July 24, 2002
This work is realized in the framework of a research study conducted for the European Space Agency (ESA-ESOC) under contract No.14709/00/D/IM.
Abstract This document describes the main achievements of a study carried out for ESA-ESOC. It concerns the analysis of mission planning problems within the Mars Express mission. Final synthesis of the study is a software system called Mexar (for Mars EXpress scheduling ARchitecture) that supports human mission planners to solve the Mars Express Memory Dumping Problem (Mex-Mdp). Background of this study are several Artificial Intelligence (AI) techniques. In particular Mexar integrates research from three different AI subfields: planning and scheduling, constraint satisfaction, and intelligent interfaces. The study has involved three separate issues: (a) analyzing the features of Mex-Mdp and generating instances of the problem with a certain level of accuracy; (b) automated problem solving of MexMdp; (c) defining of a user interaction environment to flexibly support human mission planners in interacting with the automated algorithms. The three issues reflect the structure of this report that is subdivided in three main chapters plus introduction and conclusions. Mex-Mdp is a scheduling problem with preemption with additional restrictions introduced by the on-board memory capacity. After a formalization of the Mex-Mdp problem, the report presents an analysis of its sources of difficulty considering on the average payload usage of Mars-Express. A random problem generator is also introduced that can take into account different configurations of the spacecraft modules. The report then describes a set of solution methods that work on top of a constraint-based representation of the problem. Both a greedy solver and a local search optimization procedure are shown to solve instances of Mex-Mdp that capture the nominal workload of the spacecraft. In particular, the optimization procedure is experimentally shown to improve the solutions produced by the greedy solver on a set of difficult problems. The Mexar software system allows human mission planners to use the algorithms, to inspect different features of both the problem and the solution. Furtherly, advanced interaction functionalities allow the users to incrementally generate new problems refining an initial one and to generate different solutions to the same problem by combining the basic algorithms. All these features create an example of mixed-initiative problem solving environment in which human experts and the automated planner share responsibilities in the synthesis of effective spacecraft operations.
ii
Contents 1 Intelligent Support to Mission Planning 1.1 The MEXAR Study . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Ingredients for an Intelligent Solution Aid . . . . . . . . . . . 1.3 Plan of the Report . . . . . . . . . . . . . . . . . . . . . . . .
1 1 3 4
2 The Problem: Synthesizing Downlink Spacecraft Operations 2.1 The MEX-MDP Domain . . . . . . . . . . . . . . . . . . . . . 2.1.1 Domain Resources . . . . . . . . . . . . . . . . . . . . 2.1.2 Domain Activities . . . . . . . . . . . . . . . . . . . . . 2.1.3 Problem Definition . . . . . . . . . . . . . . . . . . . . 2.2 Problem Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 2.2.1 A Lower Bound . . . . . . . . . . . . . . . . . . . . . . 2.2.2 Coefficients for Classifying Problems . . . . . . . . . . 2.3 A Problem Generator for MEX-MDP . . . . . . . . . . . . . . 2.3.1 The Domain Description File . . . . . . . . . . . . . . 2.3.2 Generation Algorithm . . . . . . . . . . . . . . . . . .
4 7 7 9 10 12 12 16 18 21 24
3 A CSP Approach to Packet Sequencing 3.1 Constraint Satisfaction Problem Solving (CSP) . . 3.2 CSP Problem Representation . . . . . . . . . . . . 3.2.1 Rules for pruning inconsistencies . . . . . . 3.3 The Greedy Heuristic Solver . . . . . . . . . . . . . 3.3.1 Interleaving planning and scheduling steps . 3.4 An Optimization Procedure Based on Local Search 3.4.1 Taboo search . . . . . . . . . . . . . . . . . 3.4.2 A Move for MEX-MDP . . . . . . . . . . . . 3.5 Experimental Evaluation . . . . . . . . . . . . . . . 3.5.1 Defining Benchmark Problems . . . . . . . . 3.5.2 Experimental Results . . . . . . . . . . . . .
. . . . . . . . . . .
25 27 28 31 32 32 36 37 38 42 42 43
Sequencing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45 50 52 55 56
4 MEXAR: An Interactive Support to Downlink 4.1 From MEX-MDP to a software architecture . . 4.2 Mixed-initiative problem solving . . . . . . . . . 4.2.1 Interactive functionalities . . . . . . . . 4.3 The Problem Analyzer . . . . . . . . . . . . . .
iii
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
4.3.1
4.4
The “glass box” approach to loading, inspecting and solving a problem . . . . . . . . . . . . . . . . . . . . 4.3.2 Exploring the problem space . . . . . . . . . . . . . . The Solution Explorer . . . . . . . . . . . . . . . . . . . . . 4.4.1 Guided sampling of the solution space . . . . . . . .
. . . .
57 60 65 66
5 Conclusions 67 5.1 Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 5.2 Recommendations for future work . . . . . . . . . . . . . . . . 71
iv
List of Figures 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 34 33 35 36
On-board telemetry flow . . . . . . . . . . . . An example of SRPT schedule . . . . . . . . Problem classification . . . . . . . . . . . . . The different software modules . . . . . . . . The data flow of problem generation . . . . . Header Parameters . . . . . . . . . . . . . . . Payload description . . . . . . . . . . . . . . Data Profiles . . . . . . . . . . . . . . . . . . Resource Description . . . . . . . . . . . . . . Problem Generation Algorithm . . . . . . . . Basic CSP search procedure . . . . . . . . . . Packet stores and channel Vs. time windows . The greedy solver . . . . . . . . . . . . . . . . SsmmDumpPlan algorithm . . . . . . . . . . . Propagation algorithm . . . . . . . . . . . . . SsmmDumpSched algorithm . . . . . . . . . . pmove(i,j,k) . . . . . . . . . . . . . . . . . . . The taboo search algorithm . . . . . . . . . . Benchmarks classification. . . . . . . . . . . . Performance on benchmark B1 . . . . . . . . Performance on benchmark B2 . . . . . . . . Performance on benchmark B3 . . . . . . . . Performance on benchmark B4 . . . . . . . . Basic modeling step in Mexar . . . . . . . . Sketch of the Mexar Software Architecture . Mixed-Initiative Problem Solving . . . . . . . Mexar Functionalities . . . . . . . . . . . . Mexar Interactive Environments . . . . . . The Problem Analyzer Layout . . . . . . . . The PA’s menu bar . . . . . . . . . . . . . . The blow up of PA’s buttons . . . . . . . . . Inspecting the “glass box” . . . . . . . . . . . Macro tools for analyzing the solution . . . . Using the Solve-Inspect-Revise Cycle . . . . . Exploring different problem formulations . . . An example of solution failure for overwriting v
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6 15 18 19 20 22 23 24 25 26 27 29 32 33 34 35 39 41 44 46 47 48 49 51 53 54 54 55 56 57 58 59 61 62 63 64
37 38 39 40
The general idea behind the exploration of the Entering the Solution Explorer . . . . . . . . The Solution Explorer Layout . . . . . . . . . Two different exploration statuses . . . . . .
vi
solution space 65 . . . . . . . . . 66 . . . . . . . . . 66 . . . . . . . . . 68
1
Intelligent Support to Mission Planning
Space exploration missions require coordination of a significant amount of activities. State of the art intelligent planning and scheduling (P&S) technology could be of potential great help in supporting such a coordination. The study that motivates this document aims at showing an example of this technology in a support system for a specific mission scheduling problem related to the Mars-Express program of the European Space Agency (ESA) [14]. Mars-Express is a space probe that will be launched during 2003 and after six months will be orbiting around Mars for the next two years and more. It will contain eight different scientific payloads to gather different data on both surface and atmosphere of the Red Planet. During the operational phase around Mars a team of people, the Mission Planners, will be responsible for the on board operations of Mars-Express. They receive input from different teams of scientists, one from each payload, and cooperate with different specialists for more specific tasks (e.g., Flight Dynamics (FD) experts). Any single operation of a payload, named POR from Payload Operation Request, is decided well in advance through a negotiation phase among the different actors involved in the process (e.g., scientists, mission planners, FD experts). The result of this negotiation is (a) acceptance or rejection of a single POR, (b) a start time assignment of the accepted PORs. At the operational level the mission planners will be responsible for data return to scientists for any single POR. Their goal will be to guarantee an acceptable turnover time from the end of the execution of the POR to the availability on Earth of science data generated by that POR.
1.1
The MEXAR Study
The study “Efficient Planning Algorithms for an Interplanetary Mission” is aimed at investigating Artificial Intelligence (AI) techniques to solve planning and scheduling problems involved in the mission. Before entering the technical content a few observations about the premises of this study are worth doing. For AI P&S scientists space missions represent an application domain extremely rich because of the different aspects in the development of the mission plans where P&S techniques could potentially help (e.g., the schedule of PORs, the synthesis of on-board procedures for executing PORs, the synthesis of downlink sequences for dumping data to 1
Earth, etc.). P&S research addresses in general the problem of how to automate decisions on what action to do and when in order to achieve a goal (see [1] as a starting point of a quite vast literature). In space missions such decisions are usually taken by humans well in advance to ensure that no faulty behavior happens at execution time. Almost no space is left for automated methods that are only used to automate routinary tasks. Examples of effective use of automated planning techniques in space have been appearing continuously in the last 3-4 years (e.g., [17, 24]), but most of the missions follow the traditional approach including the MarsExpress. Since the beginning of the study this authors have been faced with a choice between: (a) developing an example of application of their techniques that was just re-doing automatically something that in real mission will be done manually (so working in parallel to the current mission developments); (b) looking for some aspect of the domain that was actually in need of an automated solution but was not under consideration for such an improvement. We actually preferred the second alternative and with the help of Mars-Express mission planning people found out a specific aspect that was worth automating. Such task is the synthesis of spacecraft operation requests (SOR) for dumping the on-board memory in downlink packet sequences. This job is expected to be manually generated by a person working half of his time on this during the two years of operational activity of the space probe. The task is somehow repetitive and not necessarily implies continuous critical situations, although it is very important not to loose science data for effect of overwriting of on-board memory. The problem is not simple and forces a practice of relatively low use of the payload capabilities to minimize the risk of overwriting the on-board memory (a sort of a priori solution of the criticality). An automated solution could eventually foster a practice in which more intense use of the payload is tried because optimizations are looked for automatically (a sort of algorithmic solution of the criticality). The automation of the problem solving in this case was worth pursuing because of the perspectives it may open. Indeed stepping from manual operations to complete automation was considered a bit to sharp of a change so the authors pursued the goal of building an interactive support system the components of Mexar (for Mars EXpress scheduling ARchitecture).
2
1.2
Ingredients for an Intelligent Solution Aid
Our study have followed an incremental approach having produced two intermediate demos (July and November 2001) before obtaining the final version of May 2002 that is currently in use at ESA-ESOC. The first phase of the study consisted in getting acquainted with the domain, the task of mission planning, and the specific problem that has been named Mars-Express Memory Dumping Problem (from now on Mex-Mdp) [10]. In a second phase the demonstration software named Mexar Tool has been produced and first described in [11]. The third phase of the project has focused on three topics needed for producing a reliable version of the software by the end of the study: (a) The generation of benchmark problems for Mex-Mdp. (b) The synthesis of efficient algorithms for solving Mex-Mdp and their evaluation. (c) The design and implementation of a interactive software environment for supporting a users to address Mex-Mdp. Indeed the current release of Mexar, as shown in the May 2002 demo and described in [7, 9, 8], is composed of two main modules, the Problem Solver and the User Interaction Environment plus a third module, the Problem Generator, that represents a basic service needed to test the functionalities of the other two modules. The Problem Generator produces sets of different Mex-Mdp problems used to validate both the solutions produced by the solving algorithms and the functionalities of the interactive software environment. The general idea followed in designing the Problem Generator is of being able to generate either simple or difficult problems for testing a particular feature of the Problem Solver or the User Interaction Environment. The hardness of the problems should be potentially tuned by manipulating a set of parameters. The benchmark problems are also been used to test under different conditions the various visualization capabilities of the graphical modules, to test the ability of representing problem of increasing size, and to analyze possible ways to make the interaction with the problem more effective. The Problem Solver has the goal to search for a solution which delivers the data to Earth as soon as possible, reflecting data priorities, and, more 3
importantly, without data overwriting (a problem due to the physical limitations of the on-board mass memory). A high quality solution for Mex-Mdp is such that not only delivers all the data but also avoids to create critical configurations of the packet stores (such as overloaded packet stores where the percentage of stored data is over a given threshold). Finally, the User Interaction Environment aims at allowing an interactive approach to Mex-Mdp solution. In particular we point out the principle of mixed-initiative problem solving that we have taken as standard reference for our work. According to this principle the human user and the automated problem solver integrate their abilities in the attempt of achieving the best possible solution to a given problem. The interaction environment integrates both a set of basic functionalities to allow the user to maintain control on the different aspects of the problem and the related solution, and two examples of advanced functionalities that show directions on how such a family of tools could evolve in the future.
1.3
Plan of the Report
The remainder of the document is organized as follows. In Section 2, we first introduce the problem addressed by defining its different features (2.1), then trying broad characterization of the problem instances (2.2), and introducing the problem generator (2.3), one of the main efforts in our work. We next describe, in turn, the two building blocks for the solution of Mex-Mdps: the algorithms (described in Section 3) and the Mexar integrated system (Section 4). A general discussion of the various results closes the paper.
2
The Problem: Synthesizing Downlink Spacecraft Operations
After the first period of general acquaintance with Mars-Express features, the study has been aimed at producing an algorithmic support for the synthesis of data return commands from the spacecraft to the ground segment station. Such data dumping procedure should possibly avoid the lost of data. This problem has been defined as the Mars-Express Memory Dumping Problem or Mex-Mdp. We give here some very general information for the reader not strictly familiar with space mission terminology. The spacecraft produces mainly 4
two types of information to be returned to Earth: • Science information from the payloads. The data produced by single operations performed by the eight mission payloads. Such data represent the main reason for a space mission. • Housekeeping information from the different sensors and instruments on board. The data collected on a regular basis to control if the actual behavior of various on-board sub-systems is evolving according to nominal behavior or not. All this data are generically referred to as telemetry (or tm) and are transmitted to Earth during downlink connections (see the general schema in Figure 1). Because Mars-Express has a single pointing system, a direct connection to Earth is available only during certain time intervals (when the spacecraft is not pointing to Mars). As a consequence telemetry is first stored on the on-board Solid State Mass Memory (SSMM) then downlinked to the ground after packetization. According to the documentation, SSMM is endowed with a low level software infrastructure that allows to define a logical level on top of the hardware (equivalent more or less to a file system) in which it is possible to identify logical units for data storage called packed stores. Packed stores are used to subdivide stored telemetry according to the different sources of information and their priority. For example, a different packed store can be associated to different payloads and to housekeeping information having different priorities. Both science and housekeeping data are stored on the assigned packed store according to a further subdivision in data packets smaller units of information whose maximal dimension is usually around 4 kilobytes or also smaller according to the dimension of the information to represent. Each data packet has a header that univocally re-associate it to the original data source once the data packet is downlinked. The SSMM software infrastructure allows to easily manage each packed store as a queue in which data are managed according to a FIFO strategy and cyclically overwritten. The peculiar aspect of the queue is that data overwriting is not forbidden at software level, but should be algorithmically avoided by the policy of data dumping. Data are dumped to Earth executing a sequence of telecommands (Spacecraft Operations) that packetize the 5
SSMM Packet Stores
DUMP
STORE
Priority Scheme
SSMM
TM
DMS VC 1
Real−Time TFG
TM TM Router TM
VC 0
Figure 1: On-board telemetry flow
current data on-board through dumping commands that transfer the information to the downlink (also called communication channel in what follows). Once on ground, the data are decoded and recomposed according to original format. Before entering the detail of our formalization of the problem an important distinction is worth doing. The memory dumping problem has two aspects: • Off-line problem. It is the problem of receiving a description of the telemetry on board for a certain period of time (2 days in the final situation) and deciding the sequence of data packet to be downlinked to Earth during visibility between Mars-Express and Earth ground station. • On-line problem. It is the problem of monitoring the transmission in the downlink and eventually managing the re-dumping of certain data packets. This should be done dynamically during the execution of the downlink. Goal of this study has been to propose solutions for the off-line version of the problem. The idea is to understand how to support Mars-Express expert in producing data packet sequences according to different criteria. 6
2.1
The MEX-MDP Domain
The basic objects that compose the Mex-Mdp domain can be classified either as resources or activities. Resources represent domain subsystem able to give services, and activities are entities that ask for services (they model tasks to be executed using resources over time). Mars Express contains three types of resources: • Solid State Mass Memory. The SSMM is able to store both science and housekeeping (HK) information. SSMM is subdivided in a set of packet stores that are the main memorization units. • On-Board Payloads. The different on-board instruments that generate data for the memory. We model only the process of data generation that is relevant for Mex-Mdp. • Communication Channels. The downlink connections that transmit data to Earth. Three different types of activities are needed to complete the model: • Payload Operation. This activity requires a payload in a given operational mode and generates a set of data packets which will be stored in the SSMM (in one or more packet stores). • Memory Dump. An activity that transmits a set of data packets from a packet store to the ground station. It models a telecommand executed by the spacecraft. • Continuous Data Stream. This kind of activity model on-board processes which work in “background” with respect to the scientific activities (namely the housekeeping produced on a regular basis). It generates a constant amount of data to be stored in the SSMM. The rest of this section provides a more formal definition of the domain features, and describes many of the constraints contained in the problem. 2.1.1
Domain Resources
In Mex-Mdp three types of resources are used: a set of packet stores P K = {pks1 , pks2 , . . . , pksm }, a set of on-board payloads OBP = {obp1 , obp2 , . . . , obps } and a set of communication channels CH = {ch1 , ch2 , . . . , cht }. 7
Packet stores. The on-board SSMM is modeled as a set of packet stores {pks1 , pks2 , . . . , pksm }, each one with a capacity ci (Kbits) and a priority pi for dumping data. The priority is a natural number such that the lower the number, the higher the priority of the packet store (generally it is a number between 1 and 5). Each packet store can be seen as a file of a given maximal size that is managed cyclically (previous information is overwritten if the amount of data overflow the packet store capacity). The number of packet stores is known a priori and they cannot exchange data among them. Data are stored in the assigned packet store according to a further subdivision in data packets {pki }. A data packet is a set of sequential data with an header containing information like: size, application ID, sequence source counter, time, flags, etc. In our model a data packet pkj is a 3-tuple hsscj , qj , pksj i: (a) ssci is the sequence source counter, a natural number that univocally identify the data packet, (b) qj is its size (Kbits), and (c) pksj is the destination packet store. Among the set of packets contained in a packet store a total order is defined, which coincides with the order defined among the ssci values. On-Board Payloads. From the point of view of data generation, an onboard instrument (or payload) is a finite state machine such that, each state has a different behavior in generating observation data. In particular, an on-board instrument is a 4-tuple obpi = hSi , Ti , sratei , ubi i such that: (a) Si is a set of operative states {sj }; (b) Ti = {(sj , sk ) : si , sj ∈ Si } is the set of possible transitions among the states, with (sj , sk ) ∈ Ti if the transition from the state si to the state sj is feasible, the other ones are not feasible; (c) sratei (sk ) represents the available generation data rate during the state sk ; (d) ubi (sk ) is an upper bound constraint on the duration of an activity which requires the instrument obpi in the state (or modality) sk . Communication Channels. These resources are characterized by a set of separated communication windows CW = {cw1 , cw2 , . . . , cwo } identifying interval of time for downlink. Each element cwi is a 3-tuple hri , si , ei i, where ri is the available data rate during the time window cwi and si and ei are respectively the start and the end time of such window. We assume that within an available downlink window only one data packet can be dumped in each instant of time t.
8
2.1.2
Domain Activities
Pointing attention to how resources can be used we describe three types of activities ai : (1) payload operations pori , (2) memory dumps mdi and (3) continuos data streams cdsi . Each activity ai has an associated execution interval, which is identified by its start time s(ai ) and end time e(ai ). The particular case of the continuos data stream operations cdsi is such that s(cdsi ) = 0 and e(cdsi ) = +∞ (where +∞ is internally represented as a finite temporal horizon). Each activity is characterized by a set of resource requirements and constraints. Payload Operations. A payload operation pori corresponds to a scientific observation and is described as a 4-tupla hidi , obpi , sik , di i where: (a) idi is an identification number, (b) obpi is the required payload, (c) sik is the operational state required to obpi , and (d) di the duration of the observation. Each observation generates a set of data which are distributed over the set of available packet stores. According to the Mars Express operational modalities, we use a decomposition model for the set of pori represented with a function Dec(pori ) which decomposes the produced data in a set of different store operations: Dec(pori ) = {sti1 , sti2 , . . . , stis }. A store operation stij transfer a set of data to the SSMM. Each stij is a 3-tuple hqij , dij , pksij i, where qij is a data quantity, dsij is the activity durations (we assume dsij = di ) and pksij is the destination packet store. The amount of data generated depends on the payload obpi and its operative state sik . In particular, the total amount of data generated by pori is qoi = (sratei (sik ))·(dP i ), and for each store operation stij , we have qij = (dpaij ) · (qoi ), such that sj=1 dpaij = 1 for each obpi . The matrix of values dpaij is called data decomposition array. Data are stored in packet stores as a set of data packets. We suppose a simple packetization model : when an amount of data qi is stored starting from the instant s(sti ), an amount of memory is reserved equal to qi , plus an additional quantity for the packets headers. The number of data packets generated is the nearest upper integer of the value qi /Ddp , where all the packets have the same dimension Ddp . In the case a data set does not fit completely the set of packets, we suppose the last one is completed with dummy data. Memory Dumps. A memory dump operation mdi transfers a set of data packets {pkj } from a packet store to a transfer device (Transfer Frame Gener9
ator - TFG). This activity is defined as a 6-tuple hchi , pksi , cwi , di , ssc1 , ssc2 i: (a) chi is a communication channel; (b) pksi is the source packet store; (c) cwi is a communication window (with the associated data rate); (d) di is the activity duration; (e) ssc1 and ssc2 are respectively the start and the end counters of the packets dumped during the operation (with ssc1 ≤ ssc2 ). Continuous Data Streams. This activity represents a continuos generation of data with a fixed average data rate. A cdsi activity is a pair hpksi , f ri i, where f ri is the flat rate (Kbits/second) of the data stream which loads the packets store pksi . 2.1.3
Problem Definition
The definition of the Mex-Mdp problem (and its solution) relies on two main hypothesis. 1. A packet store can be dumped in one or more steps. A single step corresponds to dump a sequence of data packets. The algorithm that plans the different dumps can stop and resume the dumping process of data packets in favor of a different packet store (in the scheduling literature this working behavior is known as preemption). The transmission of a single data packet cannot be interrupted. 2. The solution produced by the solving algorithm can be seen as a stream of packets which enters the Transfer Frame Generator (TFG). Given a set of n scientific observations P OR = {por1 , por2 , . . . , porn } and a domain description that specify all the previous constraints, a solution S is a set of dumping operations S = {md1 , md2 , . . . , mds } such that: • Each dump operation starts after the generation of the corresponding data. For each packet store, the dumping operations are generated according to increasing values of the ssci . • Each memory dump mdi has an assigned time window wj = hrj , sj , ej i, such that the dumping rate is rj and the constraint sj ≤ s(mdi ) ≤ e(mdi ) ≤ ej holds. Dump operations cannot reciprocally overlap.
10
• For each packet store pksi and for each instant t within the considered temporal horizon, the amount of stored data is below or equal to the capacity ci . A solution should satisfy all the imposed constraints, however our main goal is to find high quality solutions with respect to a set of evaluation parameters. In the Mars Express domain the goal can be synthesized with this statement: A high quality plan delivers all the stored data as soon as possible and according to data priority. Consequently we consider the following information as relevant for building up an objective function: 1. the turnover time of a payload operation pori : tt(pori ) = del(pori ) − e(pori ), where del(pori ) is the delivery time of the data generated by pori and e(pori ) is its end time; 2. the priority values of the data generated by the pori . We introduce as an objective function the Mean α-weighted Turnover Time M T Tα of a solution S: n
M T Tα (S) =
1X αi tt(pori ) n i=1
(1)
In the Mex-Mdp domain we can consider several kinds of weights α and consequently different objective functions. • Mean Turnover Time (M T T ) - The most simple one with αi = 1, i = 1..n. • Mean Data Weighted Turnover Time (M T TD ) - In this case αi = 1/qoi (i = 1..n), where qoi is the amount of data produced by the payload operation pori (see Section 2.1.2). This measure represents the average turnover time per unit of data.
11
• Mean Priority Weighted Turnover Time (M T TP ) - This objective function is related to the data priority, we have to consider that in this domain, data priority is associated to packet stores. We propose the following weight αi based on the decomposition model introduce in Section 2.1.2: X X 1 qij dpaij αi = = i = 1..n (2) qoi j=1..s, q 6=0 p(pksij ) j=1..s, dap 6=0 p(pksij ) ij
ij
Where p(pksij ) is the priority of the data stored in the packed store pksij and dpaij is the data decomposition array. Given an instance of a Mex-Mdp, an optimal solution with respect to a weight α is a solution S which minimize the objective function M T Tα (S).
2.2
Problem Analysis
We now present some results identifying general properties of Mex-Mdp aimed at both classifying its instances and understanding the dominant factors to generate hard problem instances. This analysis considers the Mean Turnover Time (M T T ) as the main evaluation parameter for the generated solutions. The Mexar software system also computes the other parameters and show them to the user. For the purpose of this document and the scope of the study we have chosen to privilege the M T T with respect to the other parameters (see also the experimental results later in this documents). Additional work would be needed for realize analogous classifications with respects to other evaluation functions. 2.2.1
A Lower Bound
For problems that are computationally difficult is not possible (or at least extremely difficult) to compute the optimal solution because this implies enumeration of all the solutions. On those problem using heuristic techniques for computing solution is a forced choice. A technique very often used to evaluate the effectiveness of an heuristic incomplete algorithm is the computation of a lower bound of the optimal value. In general, this technique consists of two separate steps: first, a relaxation of the problem is defined (some of the original problem constraints are 12
removed). The relaxation is chosen so a to obtain a polynomial problem; second, the optimal value of its objective function is calculated. Since the number of solutions of the new problem in greater or equal to the number of solution of the original problem, the optimum of the relaxed problem is lower or equal to the real optimum. Of course the interesting lower bounds should be as close as possible to the real situation, and should have a good trade-off in the computational complexity (e.g., low polynomial) with respect to the complexity of the original optimization problem. A lower bound can be used in three different ways: 1. When during an optimization procedure the current best value is equal to a known lower bound, the current solution is an optimum. 2. When a partial solution has a lower bound greater than the current best solution, the search can be stopped and another search path can be tried. 3. A lower bound is a reference value for giving an evaluation of a current best solution (a solution without a proof of optimality). We consider that the Mex-Mdp problem has two main component constraints: the packet store capacities and the constraints imposed by the communication channels. In order to define a lower bound the relaxed version of the problem considers only the constraints over the communication channel. Under this hypothesis, the problem can be reduced to a classical optimization scheduling problem of minimizing the mean weighted flow time (in our case called M T Tα ) on a single capacitated machine (i.e., the communication channel) where preemption is allowed. This problem is known in literature as Weighted Flow Time Problem (WFTP), and even if the WFTP can be seen as a particular cases of Mex-Mdp problem, where the capacity constraints of the set of packet store are not considered, it remains an nphard optimization problem [18]. Hence, in general Mex-Mdp is a difficult optimization problem, where we have the additional complexity induced by the limited capacity of the set of packet stores. In order to give a lower bound, we consider the following hypotheses: • all the communication links have the same data rate r;
13
• we remove the constraints on the packet store capacities, in other words we consider the hypothesis cj = +∞ for each packet store pksj ; • we consider the unweighted version of the problem (only the MTT values). Under the previous hypotheses for this problem a polynomial strategy is known (that is, the amount of computational resources required by the algorithm for the solution of a problem instances is a polynomial function of the problem dimension - in this case the number of PORs) which gives the optimal and minimal MTT value. The name of the algorithmic strategy is SRPT (Shortest Remaining Processing Time). There is only one difference, in the original formulation of the WFTP problem, the machine (in this case the communication channel) is always available over the given temporal horizon, instead, in our case we have some no-communication windows. In order to proof that the algorithm SRPT is always able to find an optimal solution, we propose a proof in the following three steps. Problem Reduction. Under the mentioned hypothesis, the Mex-Mdp problem can be reduced to a scheduling problem with a set of activities A = {a1 , a2 , . . . , an } such that each activity ai is related to a single pori . All the activities must be executed on a single machine (the channel), and the machine can execute only one activity a time. Preemption is allowed, hence the execution of a given activity can be suspended and the execution of a new one can start. All the activity has a start time such that s(ai ) = e(pori ) and a duration di = qoi /r, that is equal to the time needed to dump the volume of data generated by the pori over the communication link at the constant data rate r. The flow time f t(ai ) of the activity ai is defined as f t(ai ) = e(ai ) − s(ai ), the mean flow time mf t is the average value over the set of activities A and we observe it coincides with the definition of mean turnover time (MTT). The problem is to find a schedule, that is a sequence of activity executions over time (remember that an activity can be interrupted several time), such that all the activities are executed and the value mf t is minimal. SRPT algorithm. When the machine is fully available, a simple algorithm strategy, called Shortest Remaining Processing Time (SRPT) can be used to find the an optimal schedule with minimal mf t. The rule is the following: 14
Figure 2: An example of SRPT schedule
at each instant of time t one activity with the minimal remaining time to the end of the activity must be executed. This simple algorithm guarantees the optimality of the schedule when the machine is fully available [18] (in our case, the whole horizon is available for communication), however, we have to extend that property holds also in the case of partial availability of the machine over time. Extending the SRPT algorithm. In Figure 2 a simple running example of SRPT is shown for the case in which the machine (channel) is not available in two different periods of time (the black boxes). There are three different activities (A1, A2 and A3) that are scheduled according to the SRPT rule. We can relay on the hypothesis that without no-communication windows the SRPT algorithm produces an optimal schedule. When there are nocommunication windows, we can think these windows as new dummy activities which have to be scheduled together with the other ones. Let us suppose that the original problem contains n activities, for each no-communication windows, we can add a set of contiguous activities, all with unary duration, such that f ill the whole window. Let us also suppose that we add a total of 0 n unary activities, under this hypothesis the new mean flow time is:
15
n X 1 mf t = ( f t(ai ) n + n0 i=1 0
0
+n)
(3)
We observe that we adopt a discrete model of time, hence: the flow time of each dummy activity is always 1, the dummy activities has always the highest priority in the SRPT algorithm, and the total flow time for the set 0 of dummy activities is n . Equation (3) can be rewritten as: 0
n n mf t = 0 mf t + n+n n + n0 0
(4)
Pn 0 Where mf t = n1 i=1 f t(ai ). We observe that the contribution n to the 0 mean flow time is independent from the scheduling strategy and mf t is minimal by SRPT. Hence, if by ab absurd we suppose that a new schedule 00 exists such the mean flow time of the set of original activities mf t is less 00 than mf t (that is mf t < mf t), by (4) this fact contradict the hypothesis 0 the the value mf t is minimal by SRPT. This lower bound is used in the following to check its distance from a solution. If the distance is high it is worth pursuing further optimizations. If the difference is quite low, this means that either the problem is rather easy or the solver is particularly effective. 2.2.2
Coefficients for Classifying Problems
A different attempt to classify the problem instances involves a different perspective done by introducing three parameters: the Communication Coefficient (CC), the Load Coefficient (LC) and the Data Return (DR). Given an instance of a Mex-Mdp problem, the Communication Coefficient is the ratio between the total volume of data generated by the set of all PORs and the housekeeping activities, and the total data volume downloadable in the time windows [minpori ∈P OR {s(pori )}, maxpori ∈P OR {e(pori )}]. The second parameter compares the data volume generated to the packet store capacities cj . Let us consider the total amount of data generated for P each packet store pksj , Qj = i qij . We define two load coefficient: LCmax = max{cj /Qj }
16
(5)
n
LCavg
1X = cj /Qj n j=1
(6)
The last parameter,the Data Return, is defined as the ratio between the data volume dumped till the end of the dump window following the last POR and, the volume of data generated by all PORs. Classification. The CC and LCmax parameters can be used to perform a rough classification of the instances of Mex-Mdp. Let us consider the schema in Figure 3. We can define four different classes of problems: 1. CC < 1 and LCmax < 1 — these are the easiest instances because there is surely time to dump all the data (CC < 1) and also it is not possible to overwrite data in the packet stores (because LCmax < 1). In addition, with LCmax < 1 we have an equivalent situation to the case of all the packet store with not limited capacity, hence it possible to apply the SRPT rule and obtain an optimal MTT in polynomial time. 2. CC < 1 and LCmax ≥ 1 — In this case SRPT rule does not apply and the highest is the value LCmax , the highest is the distance from the SRPT case, which can be used as a reference value to evaluate the complexity of the problem. 3. CC ≥ 1 and LCmax < 1 — This problem show another kind of criticality, there is no risk of overwriting, however the more is the value CC, the more is the probability that a subset of packet stores remains with some residual data. 4. CC ≥ 1 and LCmax ≥ 1 — This class of instances show both the criticality (vs. the on-board memory and vs. the communication channel) and we expect that the most difficult instances are in this subset (see Figure 3) The classification above proposed, together with the problem generator will turn out very useful in the experimental section to identify balanced benchmark sets that contain both easy and hard problems. In addition the classification is useful to avoid testing the system with very hard problems that are unlikely to be created in Mars-Express for the reasons explained in the introductory section. 17
LC
"difficult problems"
1
"easy problems"
CC
1
Figure 3: Problem classification
2.3
A Problem Generator for MEX-MDP
A key feature for tuning algorithm and system performance is to use realist instances of the addressed problem. This may be considered a secondary issue but being Mars-Express a mission in way of development no realistic instances of the actual payloads were available but few instances coming from the the Stat system [19] distribution. Starting from these initial data we have created a random problem generator that allow us to simulate different operational conditions. Figure 4 gives a high level picture of the three software modules that compose Mexar and their interrelationships. During its use the generator produces one or several problem files that are stored in an output directory. When activated, the User Interaction Environment loads one of the files (a single problem), and shows it to the user, that can ask the Problem Solver to provide a solution, the solution will be shown by the User Interaction Environment in its different features. As explained in previous reports (e.g. [6]) a scenario specification involves two different aspects, namely a specification of domain resources (e.g., the
18
Problem Generator
User Interaction Environment
Problem Solver
Figure 4: The different software modules
available SSMM packet stores, their capacity, the payloads, their internal status, etc.) and the specification of activities (e.g., the single operations the payload are supposed to execute, their duration, the data rate for the housekeeping data, etc.). The input of the Problem Generator contains seeds for both these aspects. Both features can be tuned in different ways by the user. The output of the Problem Generator is a data file that contains the two aspects in a format suitable for an efficient exchange of data between the User Interaction Environment and the Problem Solver. Figure 5 shows how different sources of information are manipulated to specify the so called Mex-Mdp problem. During the information exchange between MPS experts and PST members, a basic decision concerned the use of the Stat input files as a source of information for Mexar. In order to generate realistic data, we use the payload operation files (or requests files) distributed in the Stat system (first input file for the generator). As shown in the figure, an additional use of Stat consists in its output file for determining the set of possible downlink windows. So, the second input file for the generator is extracted from Stat in correspondence with the request file. The third input for the generator consists in a file that models the different features of the domain according to current capability of the system. Section 2 of this report describes in detail what kind of domain complexity is currently taken into account, as a consequence, the following issues are taken into account in the current generator: • Unpredictability of science data. Due to several reasons it is not possible to know the dimension of the output data in advance. For example, this may be a consequence of the efficiency of the compression algorithm on the set of generated data. The generator simulates this unpredictability with a random generation of science data. The dimension of each data production for the SSMM can be represented as a random variable 19
STAT Payload Requests
User Interaction Environment Problem Generator
MEX-MDP Problem
STAT Downlink Windows
Domain Description
Figure 5: The data flow of problem generation
ranging over an interval of possible values with a random Gaussian distribution. • Housekeeping model. Spacecraft housekeeping (HK) information were initially modeled as a set of store activities randomly generated and distributed over the observation period. At present, HK is considered as highly predictable and modeled as a flow of packetized data with a constant flat rate (between 4 and 10 Kbits). • Distribution of data to packet stores. A more sophisticated model is used to represent the amount of science data generated by each observation. Input from MPS experts has produced a more detailed generation model. According to this each instrument has a set of modes, for each mode a set of data are generated such that: – different subsets of data are generated and sent to different packet stores (e.g., HK and science data with different priorities); – for each operational modality of the payloads a data production rate is known. 20
• Priorities. Each packet store has associated a priority value related to the dumping process. The priority is one of the factors used for heuristic evaluation by the problem solver. As said in a previous section some of the input data is taken from the Stat tool distribution suit. In particular we consider as input of the generation algorithm the following Stat data: • The set of Payload Operation Requests (POR). • The set of Possible Downlink Windows connected to the POR. This allows to have a consistent model of the spacecraft attitudes (synchronized with the POR content). • The Distance Events database that contains the apocentre and pericentre times for each mission orbit. Such data are used to convert all the POR temporal specification given in term of orbit numbers to absolute time [seconds] from the beginning of operations. There is one more file used as input by the generator that is called Domain Description. It contains all the information for the Mars-Express scenario configuration. This file has been introduced to allow the user to directly control the problem generation phase deciding several aspects from the size of the various packet stores to the policy for decomposing the data taken among different packet stores. The idea pursued in the generator is that Stat files are considered as an invariant and different problems are generated tuning the parameters in the Domain Description. 2.3.1
The Domain Description File
The Domain Description file allows to change parameters that specify the following aspects: • Payload description: for each payload and its operative states the output data rate is given. To take into account the uncertainty described by the MPS expert [13], we suppose that the amount of data produced for each payload operation is qo = (1 + α) · di · srate(pori , sik ), where α is a Gaussian variable with expected values 0. The set of σ values for the Gaussian associated to each payload can be modified by the users. 21
• Data decomposition model : it represents how data generated by each payload operation is partitioned in the set of available packet stores, in other words it represents the data profile array δij defined in Section 3.2. • Packet stores for science: for each of them the capacity and the priority is given. • Packet stores for spacecraft data: for each one the capacity, the priority and the production data rate is given. In the following we describe the Domain Description file introducing the different sections it contains. At present the file is to be defined using a text editor and paying attention to the position of data information. It is important to remind that in the file examples the lines that do not start with numbers are always comments (and are ignored by the software). ------------------------------------------------------------------Nrenewable Npks-hk-sc Npks-hk-science Npks-data-science Nlinks 1 1 1 11 1 -------------------------------------------------------------------
Figure 6: Header Parameters The file starts with the header shown in Figure 6. It contains basic configuration information for the resources: the columns Nrenewable contains the number of renewable resources, an internal parameter that should be always equal to the number of communication channels. Column Npks-hk-sc contains the number of packets store to memorize housekeeping spacecraft data, Npks-hk-science is the number of packet stores to memorize science housekeeping data, Npks-data-science is the number of packet store for science, and Nlinks is the number of communication links (channels). Figure 7 shows the file section that describes the on-board payloads data generation capabilities. It contains two sections: • The first part is the representation of a bidimensional array “instruments vs. modalities” which gives the output data rates [kbits/sec] for each payload in a given operational modality. The value -1 represents that an entry is not defined. 22
• The second part describes the uncertainty of data that are generated by the payloads. The basic hypothesis is that amount of data produced by each observation is a Gaussian random variable. For each payload the corresponding σ is represented. This value comes from the practical hypothesis that we consider a data uncertainty of ±50% at the values ±3σ with respect to the expected value (3σ = 0.5). ------------------------------------------------------------------ARRAY payloads vs. modalities: data rates [kbits/sec]: ASPE HRSC MARE MaRS OMEG PFSX SSRA SPIC OFFX 0 0 0 0 0 0 0 0 STBY 0.6 2 0.16 -1 2 2.6 2 1 PREO -1 2 -1 -1 2 -1 0.1 -1 MINI 0.6 1250 8 -1 500 32 22.4 -1 LOWI 2 2500 32 -1 500 32 27.1 36 MEDI 6 6250 64 0 500 32 35.5 36 MAXI 18 12500 128 0 500 43 74.6 10 POST -1 2 -1 -1 2 -1 0.1 -1 ------------------------------------------------------------------Data generation uncertainty: sigma value per instrument (Gaussian distribution): ASPE HRSC MARE MaRS OMEG PFSX SSRA SPIC 0.0834 0.0834 0.0834 0.0834 0.0834 0.0834 0.0834 0.0834 -------------------------------------------------------------------
Figure 7: Payload description Figure 8 shows a representation of the Data Profiles Array δij defined in Section 3.2. It gives the schema for decomposing telemetry data into different on board packet stores. Each column of the array represents how data produced by a certain payload are distributed along different packed stores dedicated to science. This decomposition is used for all the payload operations. This is in line with the specification given in [13]. The last section of the file (see Figure 9) describes the set of available resources. First, we have the capacity of each Renewable resource, set to 1 in each file (this is used to model the downlink channels). Second, a description of the set of spacecraft housekeeping packet stores is given. For each one we have a 3-tuple hci , pri , f ri i, that is, capacity [Kbits], priority 23
------------------------------------------------------------------ARRAY payloads vs. science packet stores: data profiles [\%]: ASPE HRSC MARE MaRS OMEG PFSX SSRA SPIC #101 5 1 5 5 5 0 5 0 #201 95 0 0 0 0 0 0 0 #301 0 70 0 0 0 0 0 0 #302 0 29 0 0 0 0 0 0 #303 0 0 30 0 0 0 0 0 #304 0 0 35 0 0 0 0 0 #305 0 0 30 0 0 0 0 0 #401 0 0 0 95 0 0 0 0 #501 0 0 0 0 95 0 0 0 #601 0 0 0 0 0 100 0 0 #701 0 0 0 0 0 0 95 0 #801 0 0 0 0 0 0 0 100 -------------------------------------------------------------------
Figure 8: Data Profiles
and charging flat-rate [Kbits/s]. The third part describes the payload science packet stores, for each one we have a pair hci , pri i, that is, capacity [Kbits] and priority (increasing priorities are designated as increasing positive integers). The last part gives for each communication channels, the number of different communication states, that is, the number of different dumping data rates, included the value O (no communication). The last capability is defined for completeness but not used in depth in the current version of the system. In the table of Figure 9 the science housekeeping packet stores appear before the science data packet stores. 2.3.2
Generation Algorithm
The basic work done by the problem generation algorithm follows from the description of the data files that has been done. Role of the algorithm is to put together heterogeneous data and create a unique output file that represents a Mex-Mdp instance. Figure 10 gives an high level description of the generation method. After loading the input data (Steps 1-4), a problem is generated that, according to definition in Section 3, contains both activities and resources. 24
------------------------------------------------------------------Renewable resources capacities: 1 ------------------------------------------------------------------Spacecraft packet stores: set of 3-tuple : 1000000 1 4 ------------------------------------------------------------------Instrument packet stores: set of pairs : 200000 1 500000 2 8500000 2 3500000 2 40000 2 50000 3 40000 2 10000 2 3000000 3 950000 5 500000 3 300000 3 ------------------------------------------------------------------Number of states for each communication link: 3 -------------------------------------------------------------------
Figure 9: Resource Description
The activities are adapted from the Stat payload operation requests, and the store operations over the packets stores are created according to the parameters in the Domain Description and the random generation of uncertainty. The resources available in the problem are created on the basis of the specified packet stores (capacities, priorities, and charging data rates), the specification of the communication channels (dumping window and related transmission data rates) and so on. The implemented problem generator allows to create different set of problems starting from the basic request sets specified in the Stat suit. The idea is the one of having a limited number of realistic problems given by the Mars-Express MPS and on their basis develop different operative scenarios by changing the domain parameters (mainly the amount of uncertainty in generated data, the distribution policy of the data on packet stores, the packet store priorities, the capacity of the different packet stores).
3
A CSP Approach to Packet Sequencing
This section describes the complete solving abilities that have been produced during the project. This version of the algorithm has been developed in the 25
Problem Generator: Input: Output: 1. 2. 3. 4. 5.
P OR: Payload Operations Set, DW : Downlink Windows, DF : Domain Definition Data, DE: Distance Events Set Mex-Mdp instance
Load (DF ) Load (DW ) Load (DE) Load (P ORs) Create an empty Mex-Mdp instance
/* Define Activities */ 6. Foreach pori ∈ P ORs 7. Compute the start time s(pori ) and the duration di and include them in the Mex-Mdp instance 8. Foreach pori ∈ P ORs 9. Compute the total data produced qo = (1 + α) · di · srate(obsi ) 10. Compute the decomposition Dec(pori ) = {sti1 , sti2 , . . . , stis } 11. Include the corresponding store operations in the Mex-Mdp instance /* Define Resources */ 12. Include the set of resource definitions (packet stores, and communication channels) in the MEX-MDP instance
Figure 10: Problem Generation Algorithm last part of the work after an initial investigation on simpler dispatching techniques. The starting point for these algorithm is the formalization based on Constraint Satisfaction Problems (CSP) [20] a quite powerful representation schemata that offer useful separation among the different modules that turned out to be incrementally empowered of additional functionalities without redesign of the previous parts. This section and the next one shows how powerful such a basic representation schema may be.
26
3.1
Constraint Satisfaction Problem Solving (CSP)
Scheduling problems such as Mex-Mdp can be seen as a special types of CSP. An instance of a CSP involves a set of variables X = {X1 , X2 , . . . , Xn }, a domain Di for each variable and a set of constraints C = {C1 , C2 , . . . , Cq } such that Ci ⊆ D1 × D2 × · · · × Dn , which define feasible combinations of domain values. A solution is an assignment of domain values to all variables which is consistent with all imposed constraints. A general algorithmic template for solving a CSP is shown in Figure 11. It can be seen as an iterative search procedure where the current (partial) solution is extended on each cycle by assigning a value to a new variable. CSPsolver(Problem) 1. CreateCSPForProblem 2. while not(solved or infeasible) do 3. RemoveInconsistentValues 4. SelectDecisionVariable 5. SelectValueForVariable 6. end Figure 11: Basic CSP search procedure As each new decision is made during this search, a set of “propagation rules” removes elements from domains Di which cannot be contained in any feasible extension of the current partial solution (Step 3 of the algorithm). In general though, it is not possible to remove all inconsistent values through propagation alone. Choices must be made between possible values for some variables, giving rise to the need for variable and value ordering (or selection) heuristics (Steps 4 and 5 in the figure). The algorithm describes a greedy (and partial) CSP procedure which can be seen as a starting point for the solving algorithms proposed here for Mex-Mdp. In our study, we have built a CSP representation of the problem and two solution strategies (a greedy satisfacing solver and an optimization procedure based on local search) that work on-top of it. Both such solvers contains two layers of reasoning that see the problems according to different abstractions. We call these two layers planning level and scheduling level. The planning level considers a simplified version of the problem, where only 27
data quantities are considered, and problems about packetization of science and housekeeping data are abstracted away. The scheduling level reasons on the last aspect, namely data packetization on the downlink, in the attempt to further improve the evaluation function MTT. This subdivision over two levels is motivated by the complexity of the optimization problem. Using abstraction we focalize on the dominant aspects of a problem that consists in reasoning on data quantities, packets store capacities and dump capability over the communication links. This is seen as the key aspect to plan for in the solution of Mex-Mdps.
3.2
CSP Problem Representation
The CSP formalization of the Mex-Mdp problem is based on a partition of the temporal horizon H = [0, H] in a set of contiguous windows W = {w1 = [t0 , t1 ] | t0 = 0} ∪ {wj = (tj−1 , tj ] | j = 2 . . . m, ti ∈ H}, such that ∪m i=1 wi = H. We consider a discrete model of time such that H is an interval of positive number. The partition is performed according to the following rules: • Significant events happen at the edges of the windows. Such events includes the origin (reference point), the horizon point, the set of instants where a memory reservation is performed on a packet store, and the set of instants where a change on the transmission channel data rate is operated. • A window wj has a maximal dimension Wmax . Hence a large communication windows is split in more than one windows wj accordingly. • The previous two partition rules are non applied during a period in which the downlink is not available. Figure 12 sketches a representation of the domain, where the temporal behaviors of the communication channel and the set of packet stores is partitioned over time in time windows. The decision variables of the CSP representation are defined according to this set of windows. For each packet store pksi (i = 1..n) and for each time window wj (j = 1..m) we introduce the following terminology. • dij - amount of data stored in the packet store pksi at tj . 28
1
2
m
1 2 Packet Stores
n
Channel w1 t0
w2 t1
wm tm−1
t2
tm
Time
Figure 12: Packet stores and channel Vs. time windows
• Dij - total amount of data generated in the interval [t0 , tj ], Dij = Di(j−1) + dij with Di0 = Li + di0 , where Li is the initial level in the packet store pksi , and di0 is the the amount of data stored at t0 . • lij - maximal level (amount of data stored) allowed at tj for the packet store pksi , lij ∈ [0, ci ], where ci is the maximal capacity of pksi and j = 0, 1..m. • δij - amount of data dumped within wj . This set represents the decision variables of the memory dumping problem at planning level. • lbδij - lower bound of the value δij . • ubδij - upper bound of the value δij . • ∆ij - amount of data dumped in the interval [t0 , tj ], ∆ij = ∆i(j−1) + δij with ∆i0 = 0. 29
• T Xij - minimum amount of data that must be dumped by tj in order to avoid overwriting in the packet store pksi (and in general to avoid the violation of the level constraint lij ), T Xij = max{0, Dij − lij }. Given the communication channel 1 and the set of time windows wj with j = 1..m, we introduce this additional terminology. • bj - maximal dumping capacity available in the window wj j = 1..m. • Bj - total amount of dumping capacity in the interval [t0 , tj ], Bj = Bj−1 + bj with B0 = 0 j = 1..m. Reasoning on the previous definitions we introduce three classes of constraints. The fundamental constraint capture the fact that for each window wj the difference between the amount of generated data Dij and the amount of dumped data cannot exceed lij the maximal imposed level in the window (overwriting). Additionally, the dumped data cannot exceed generated data (overdumping). We define the following inequalities (7) as conservative constraints. 0 ≤ Dij − ∆ij ≤ lij
i = 1..n, j = 0..m
(7)
The second class of constraints considers the dumping capacity imposed by the communication channel. The following inequalities, called downlink constraints, state that for each window wj is not possible to dump more data than the available capacity bj . 0≤
n X
δij ≤ bj
j = 1..m
(8)
i=1
A further set of constraints (9) is directly imposed on the set of decision variables δij and represents upper and lower bound on such variables (see (10) and (11)). That is: lbδij ≤ δij ≤ ubδij
i = 1..n, j = 1..m
1
(9)
In the Mars Express domain a reasonable hypothesis is that the set of communication links are “mutual exclusive”, hence a single link representation with variable data rate is enough to represent the real situation.
30
where lbδij = max{0, T Xij − min{Bj−1 , Di(j−1) − di(j−1) }} i = 1..n, j = 1..m
(10)
ubδij = min{bj , max{0, Dij − T Xi(j−1) }} i = 1..n, j = 1..m
(11)
and
3.2.1
Rules for pruning inconsistencies
From constraints (7), (8) and (9) a set of propagation rules can be defined able to reduce the set of possible values for the decision variables δij ∈ [lbδij , lbδij ]. Application of rules (12) and (13) possibly deduce adjustments of the values ubδik and lbδik based on the conservative constraints, whereas rule (14) is based on the downlink constrains. p X
ubδik = min{ubδik , Dip −
lbδij }
j=1,j6=k
i = 1..n, p = 1..m, k = 1..p
lbδik = max{lbδik , Dip − lip −
p X
(12)
ubδij }
j=1,j6=k
i = 1..n, p = 1..m, k = 1..p n X
ubδik = min{ubδik , bj −
lbδij } j = 1..m
(13)
(14)
i=1,i6=k
lbδij ≤ ubδij
i = 1..n, j = 1..m
(15)
Rule (15) is a consistency condition. In fact, when the application of the previous set of rules (12), (13) and (14) violates the condition (15) for at least one window, the partial solution is not consistent. 31
SsmmDump: Input: mexmdp instance: horizon H, set of windows w1 , w2 , . . . , wm , set of store activities, packet stores and communication links description Output: sequence S of memory dumps over the communication links 1. 2. 3. 4.
{ SsmmDumpPlan(mexmdp) SsmmDumpSched(mexmdp) } Figure 13: The greedy solver
3.3
The Greedy Heuristic Solver
We propose now a one-pass heuristic algorithm for Mex-Mdp that uses preemption. This means that a dump operation from a packet store can be interrupted during its execution (started according to a set of priority rules) in order to start executing a new one. 3.3.1
Interleaving planning and scheduling steps
The broad view of the greedy algorithm is shown in Figure 13, it is based on the idea that a plan is incrementally created within a fixed temporal horizon starting from the time origin. It takes as input a given temporal horizon H, a set of store activities, a description of the communication links, and the set of packet stores. We remember that we suppose that each packet store has a fixed capacity ci and the number of packet stores is also fixed. The output of the algorithm sequence S of memory dumps over the communication links should be consistent with all the domain constraints. All the proposed algorithms work over two levels of abstraction: (1) the planning level, where the horizon is partitioned in a set of windows w1 , w2 , . . . , wm , such that for each window wj the set of decision variables are instantiated that represent the amount of data to be dumped in the window; (2) the scheduling level, where a sequence of memory dump operations is generated over the communication links respecting the constraints imposed over all the windows wj . According to this subdivision in two levels of abstraction, the algorithm shown in Figure 13 uses two procedures: SsmmDumpPlan() and
32
SsmmDumpPlan: Input: mexmdp instance Output: a consistent assignmento of the set of decision variables δij 1. { 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. }
S←∅ j←1 Propagation(mexmdp) while (j ≤ m and Feasible(mexmdp)) { available ← bj while (available > 0 and Feasible(mexmdp)) { i ← SelectNextPacketStorePlan(j) dump ← DataDumpPlan(i, j, available) available ← available − dump lbδij ← lbδij + dump Propagation(mexmdp) } j ←j+1 }
Figure 14: SsmmDumpPlan algorithm SsmmDumpSched() that work respectively at planning and scheduling level. Figure 14 shows the planning algorithm. It resembles the CSP algorithmic template of Figure 11. As first step (Step 4) a propagation procedure is called, this procedure implements the propagation features described above and basically sets the set of domain [lbδij , ubδij ] of possible values for all the decision variables δij . In addition, each time the algorithm performs a solving decision, the Propagation() procedure (sketched in Figure 15) is called again in order to further reduce the domains [lbδij , ubδij ]. In the case the condition lbδij > ubδij holds for at least one variable δij , the problem is inconsistent and the algorithm SsmmDumpPlan() terminates without producing a solution. The function Feasible() just reports the state of feasibility of the current partial solution under construction. Within the main cycle (Step 5-15) the algorithm considers the set of windows w1 , w2 , . . . , wm in increasing order
33
Propagation: Input:
mexmdp instance
Output:
a consistent narrowing of the interval domains [lbδij , ubδij ] or a failure state when at least one domain becames empty (lbδij > ubδij )
1. 2. 3. 4. 5.
while (∃ [lbδij , ubδij ]: is updated and 6 ∃ [lbδij , ubδij ] : lbδij > ubδij ) do { Apply rules (12) Apply rules (13) Apply rules (14) } Figure 15: Propagation algorithm
of time, for each window wj it considers the amount of data bj that can be dumped within the window and iteratively executes the following steps: selects a packet store, with the function SelectNextPacketStorePlan() at Step 8; computes an amount of data to be dumped from the selected packets store (Step 9) by the function DataDumpPlan(); updates the lower bound of the involved decision variable (Step 11); calls the Propagation() function in order to propagate in the current partial solution the effects of the new decision. For each window wj the inner cycle between Steps 7-13 is executed until is available a dump capacity or a failure state occurs. We observe that it is possible to implement different solving priority rules. At present there are two priority rules at planning level. • CFF (Closest to Fill First) that selects the packet store with the highest percentage of data volume. • HPF (Highest Priority First) that selects the packet store with the highest priority. In case that a subset of packet stores has the same priority, the packet store with the smallest store as outcome data is chosen. The execution of the procedure SsmmDump() is completed by the function SsmmDumpSched() shown in Figure 16, this algorithm works at scheduling level and generates the final solution S, that is the sequence of memory 34
SsmmDumpSched: Input: mexmdp instance with a consistent assignment of the set of decision variables δij Output: sequence S of memory dumps over the communication links 1. { 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. }
j←1 while (j ≤ m and Feasible(mexmdp)) { for(i = 1 . . . n) dumpi ← δij while (∃ dumpi > 0) { i ← SelectNextPacketStoreSched(j) dumpi ← dumpi −DataDumpSched(δij , dumpi ) S ← S ∪ GenerateDataPackets(S, δij , dumpi ) } j ←j+1 } Return(S)
Figure 16: SsmmDumpSched algorithm dump operations. It works in analogous way to SsmmDumpPlan() with the difference that no propagation function is called. In fact, when all the variables δij are consistently assigned, it is possible to generate the sequence of data dumping operations without the risk of finding inconsistent states. Within the main cycle (Steps 3-11) the algorithm considers the set of windows w1 , w2 , . . . , wm in increasing order of time, for each window wj , considers the set of assigned decision variables δij (with i = 1 . . . n) representing the assigned dumping capacity to the packet store i and generates a correspondent sequence of memory dumping operations. In particular, this task is executed by the inner cycle between Steps 5-9, three steps are iteratively performed: a packet store is selected at Step 6 by SelectNextPacketStoreSched(); an amount of data given by the value of the function DataDumpSched() is chosen to be converted in data packets; a set of memory dump operations is generated and added to the current final solution S (Step 8). Similarly to the planning level, it is possible to implement different pri35
ority rules working at scheduling level by the definition of the functions SelectNextPacketStoreSched() and DataDumpSched(). Actually there are two different priority rules at scheduling level. • SDF (Smallest to Dump First): selects the packet with the smallest value of the decision variable δij . • HPF (Highest Priority First): selects the packet store with the highest priority We conclude this section with some observation about the problem that we are solving and the proposed algorithm. In the previous section the definition of solution does not consider the possibility that some packets can be lost (or overwritten). This might happen for two reasons: (1) the problem does not have a solution; (2) the algorithm is incomplete in finding a solution. According to the Mars Express documentation, the first hypothesis is quite unlikely to happen, even if, in principle it may happen. In such a case the only possibility is to change the problem definition. The second hypothesis is related to the hardness of the problem. Again on the basis of the ESA documentation, it seems simple to find a solution, on the contrary, it is hard to find an optimal (or near-optimal) solution according to criteria stated in Section 2.1.3. In order to find an optimal solution we could use a complete and systematic schema (such as Branch&Bound ) by considering in principle all the possible solution of the problem. However, for large combinatorial problems as Mex-Mdp, this approach is generally too expensive and we might pay a too high computational time. For this reason we choose to realize an heuristic optimization strategy based on local search which is able to improve an initial solution given as an input. In this way we can choose the desired balance between solution quality and computational costs.
3.4
An Optimization Procedure Based on Local Search
The greedy algorithm described before can be used to sample different solutions by applying it from scratch with different tuning parameters. In order to search more deeply the solution space to improve the solution we have used an optimization schema based on local search. This means that the 36
optimization procedure start from a feasible solution and perform a myopic search of better solutions moving to possible solution close (local) to it. In particular we have used a particular local search called taboo search [15, 16]. 3.4.1
Taboo search
Taboo search is a local search approach applied with success to a large set of combinatorial optimization problems. The tabu meta-heuristic is based of the notion of move. A move is a function which transforms one solution into another. For any solution S, a subset of moves applied to S is computed that is called the neighborhood of S. A tabu search algorithm starts from an initial solution S0 , and at each step i the neighborhood of the current solution is search for to find a new solution Si that has the best value of a given objective function. At this point Si becomes the current solution and the search process is iterated to find a new best neighbor Si+1 . In order to prevent cycling, it is not allowed to turn back to solutions visited in the previous M axSt steps. Where M axSt is the max length of the so-called tabu list, a list of forbidden moves managed with a first-in-first-out rule. Whenever a move from a current solution to its neighbor is made, the inverted move is inserted in the tail of the tabu list whose length is kept less or equal to M axSt by removing its head. During the search process, in order to find a near-optimal solution for the problem, at each step a “global” best solution S ∗ is updated. A tabu move might happen to be interesting with respect to the current solution. In order to perform this move, an aspiration function is defined which, under certain conditions, accepts a forbidden move. Generally, the definition of aspiration function is such that a forbidden move is accepted when it generates a neighbor which improve the solution S ∗ . The search process is performed until at least one of the following conditions becomes true: (1) the objective function of the solution is close to a known lower or upper bound; (2) the algorithm performs M axIter steps without improving S ∗ ; (3) a time limit is reached. Applying taboo search to a particular problem requires the definition of structural elements, such as move, neighborhood, tabu list, aspiration function, etc., is needed.
37
3.4.2
A Move for MEX-MDP
Figure 17 shows a simplified representation of a move. The general idea behind a move definition is this local modification has to bring forward some data in a given packet store, and at the same time, to delay other data in another packet store. The pursued idea is that by bringing forward some data (for example data contained in observations with the smallest volume of data) and delaying other ones, should improve in many cases the objective function. In any case before and after the execution of a move all the domain constraints must hold (we are moving in the solution space). We propose the idea of pmove, that is a move which swaps data contained in time windows (see Figure 17) at planning level, where only the decision variable δij are considered. In this way after the execution of the tabu search procedure a new sequence of data packets have to be generated by the procedure SsmmDumpSched(). The pmove(i,j,k) is defined as it follows: given two packet stores pksi and pksk with i 6= k, and two time windows wj and wj+p with p > 0 and 1 < j + p ≤ m . pmove(i,j,k) moves backward in time a data amount ² from the window wj+p to wj for the packet store pksi , and at the same time moves forward in time an equivalent amount of data ² from the window wj to wj+p for a different packet store pksk (see Figure 17). A fundamental point is the constraints checking: all the domain constraints must hold after the move execution. In particular, on the basis of the above definition, it simple to verify that the dump constraints (8) are always satisfied. Whereas the conservative constraints (7) have to be checked respect to the ² values. We observe that after a move the amount of data stored at tj+p remain unchanged, whereas the levels in tj+r , with r = 0..(p − 1) have to be checked, in particular we have to check for overdumping (the amount of data dumped is greater than the amount of data produced) in the packed store pksi , that is, the following inequalities must hold: Di(j+r) − (∆i(j+r) + ²) ≥ 0 r = 0..(p − 1)
(16)
and for overwriting in the packed store pksk , that is: Dk(j+r) − (∆k(j+r) − ²) ≤ lk(j+r)
r = 0..(p − 1)
(17)
A third and last constraint is δij ≥ 0 for each decision variable, hence after the execution of a move, the following inequalities must hold: δi(j+p) − ² ≥ 0, 38
δkj − ² ≥ 0
(18)
j
...
j+1
j+p
²
i
...
δij + ²
δi(j+p) − ²
.. .
k δkj − ²
δk(j+p) + ²
² tj−1
tj
tj+1
...
tj+p−1
tj+p
Figure 17: pmove(i,j,k)
In order to satisfy the set of inequalities (16), (17) and (18) the value ² must be chosen such that: 0 ≤ ² ≤ ²M (19) where ²M = min{δi(j+p) , δkj , Di(j+r) − ∆i(j+r) , ∆k(j+r) − Dk(j+r) + lkj | r = 0..p − 1}
(20)
According to this definition of move we define the neighborhood of a solution S. Neighborhood Definition. Given a solution S the neighborhood of S is the set of solutions obtained through the application of the pmove(i,j,k) such 39
that: • i, k = 1 . . . n and i 6= k; • ²M > 0 and ² = ²M ; • in the windows wj and wj+p it is possible to dump data, that is bj > 0 and bj+p > 0; As it easy to verify the dimension of a neighborhood is O(n2 m). The Tabu Search Algorithm. Figure 18 shows the tabu search algorithm for the optimization of a Mex-Mdp solution. The algorithm has four main inputs: the initial solution S0 , the parameters M axIter and M axSt, and the objective function fobj . It is worth noting that the tabu search procedure works at planning level and considers for modification only the set of decision variables δij . The main goal is to improve the mean weighted turnover time of a solution. The core of the algorithm consists of two main primitives GetNeigthMoves and MakeMove, which respectively implement the definitions of neighborhood and move. The algorithm uses two variables S ∗ and Smin , which respectively represent the current optimal solution and the best solution found in the exploration of a neighborhood. When the algorithm explores a sequence of M axIter neighborhoods without an improvement of the solution S ∗ , it stops (Step 6). A neighborhood is searched between Steps 9 and 21, where the solution Smin is found. The idea of aspiration function is implemented at Step 13 where a tabu move is accepted in the case it improves S ∗ and the current Smin . Finally, when a solution Smin is found, the move movemax is added to the tabu-list (Step 24) and the variable S ∗ is updated. The optimization algorithm maximize an objective function such that the greater is the value the smaller is the mean weighted turnover time (or weighted flow time) of the payload operations. In order to define such objective function we introduce the following additional definitions. Let deli (tj ) the number of scientific observations delivered by tj for the packet store pksi . It is a real number, that is we considers a kind of fuzzy delivery of the set of stores assigned to pksi (e.g., by ti = 2008 a number of 56.78 observations are delivered). Hence, in order to evaluate the improvements induced by the application of a sequence of pmoves, we consider as reference solution the 40
TabuMexMdp: Input:
S0 , max number of iterations M axIter without improvement, length of the tabu-list M axSt, objective function fobj
Output: a solution S ∗ 1. 2. 3. 4. 5.
{
6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. }
S ∗ ← S0 Scurr ← S0 N iter ← 0 tabulist ← ∅ while(N iter ≤ M axIter)) { neighborhood ← GetNeigthMoves(Scurr ) Smax ← S−∞ while(neighborhood 6= ∅) { move ← SelectMove(Scurr , neighborhood) Smove ← MakeMove(Scurr ,move) if TabuMove(move, tabulist) if (fobj (Smove ) > fobj (Smin ) and fobj (Smove ) > fobj (S ∗ )) { Smax ← Smove movemax ← move } else if (fobj (Smove ) > fobj (Smax )) { Smax ← Smove movemax ← move } } N iter ← N iter + 1 } UpdateTabuList(movemax , tabulist, M axSt) if (fobj (Smax ) > fobj (S ∗ )) { N iter ← 0 S ∗ ← Smax } Return(S ∗ )
Figure 18: The taboo search algorithm 41
initial solution S0 , this solution has a conventional and zero value for the objective function, that is fobj (S0 ) = 0. We observe that when we consider a different solution S, with respect to the initial solution S0 , we can just consider the variation of the values deli (tj ) over all the time windows and the set of packet stores. In particular, (0) let deli (tj ) the number of packets delivered by tj for the packets store pksi in S0 . The value of the objective function for a generic solution S calculated respect to the initial solution S0 is: fobj (S) =
m X n X
(0)
αi (deli (tj ) − deli (tj ))
(21)
j=1 i=1
Where αi is a generic weight related to data priority or data amounts.
3.5
Experimental Evaluation
This section ends up presenting an experimental evaluation of the CSP algorithms we have defined. The basic problem to address has been the definition of a set of benchmarks whose difficulty cover the realistic case of the MarsExpress domain. This has been done tweaking the problem generator we have implemented. 3.5.1
Defining Benchmark Problems
Before presenting experimental results we shortly describe work done to obtain meaningful benchmarks sets. This has been an additional problem in our study because real data are not available and we have build a problem generator (described in [7]) that generated instances from a fixed set of test data given to us by ESA mission planning experts. The generator uses this starting data to generate random problems on different configurations of the spacecraft domain. We generated 27 Mex-Mdp problem instances with the following domain parameters. • 1 spacecraft housekeeping packet store • 1 science housekeeping packet store • 11 science packet stores • 8 payloads 42
• data rate 228Kbps From this set of 27 problems we selected a subset of 6 Mex-Mdp problems. The other ones are not considered because the number of PORs is small or there is a weak interaction among the packet stores. From this core benchmark set of 6 problems, we generated two new benchmark sets, called B1 and B2, by removing/adding PORs in the original 6 problem set. Each benchmark contains 17 instances, and respect to the classification introduced, are positioned in the three subareas around the hard area (that is CC ≥ 1 and LCmax ≥ 1). Hence, they are not the hardest problems (see Figure 19(a) and 19(b)). In order to define a more challenging set of instances, we propose two new benchmark sets, called B3 and B4, moved toward the critical zone (CC ≥ 1 and LCmax ≥ 1) both by reducing the packet store capacities and reducing the transmission data rate. In Figure 19(a) and 19(b)) is possible to see the different allocation of the benchmarks B3 and B4 both the values LCmax and LCavg . 3.5.2
Experimental Results
As previously introduced in this section we evaluate the set of proposed solving techniques only respect to the MTT parameter. In particular, for each benchmark set (B1, B2, B3 and B4), we basically compare three different type of results: • The lower bound of the MTT values. • The MTT values generated by the greedy (one-pass) strategies over the four possible combinations among the planning and scheduling priority rules. For each benchmark set (B1, B2, B3 and B4) we give two graphics: one for the CFF planning rule and another one for the HPF. The name of a solving strategy generated by the combination of two rules is represented with the notation hplanning rulei + hscheduling rulei. For example, CFF+HPF represents the application of CFF planning rule and HPF scheduling rule. • The values obtained with the application of the taboo search optimization strategy. In this case the whole applied algorithm consists of three steps: 1) the application of a greedy planning strategy (e.g., 43
Communication Coefficient (CC) Vs. Load Coefficient (LCmax) 8 B1 B2 B3 B4
7
6
LCmax
5
4
3
2
1
0 0
1
2
3
CC
(a) CC Vs. LCmax
Communication Coefficient (CC) Vs. Load Coefficient (LCavg) 2 B1 B2 B3 B4
1.8 1.6 1.4
LCavg
1.2 1 0.8 0.6 0.4 0.2 0 0
1
2 CC
(b) CC Vs. LCavg
Figure 19: Benchmarks classification. 44
3
CFF); 2) the tabu search; 3) the application of a scheduling strategy for data packetization (e.g., SDF). Again the combination of different solving rules is represented with the notation hplanning rulei + T S + hscheduling rulei. For example, CF F + T S + HP F represents the application of the CFF planning rule, the tabu search (T S) and the HPF scheduling rule. For tabu search we use always the same parameters setting: max number of iterations without improvement M axIter = 1000; length of the tabu-list M axSt = 7. Figure 20 shows the results on benchmark B1. First of all we observe there is a clear partition between the first seven instances and the remaining ones. These last instances can be classified as easy to solve and it is no possible to do better. In addition all the strategies give more or less the same performances. On the other hand, in the first seven instances there is room to find better solutions respect to the greedy performances. This is the case of Figure20(a), where the tabu search strategy improves over the greedy one. For this benchmark the best results are obtained just with the greedy planning strategy HP F (see Figure20(b)). However, the benchmark B1 is the easiest benchmark, which shows in average the lowest load on the set of packet stores. In fact, on benchmark B2, within a pattern of results similar to the one shown in Figure 20, tabu search is able to find the best results with an improvement up to more than 30% over the greedy solutions (see Figure 21). This trend is confirmed also on the benchmarks B3 and B4 of Figure 22 and 23. This experimentation confirms the effectiveness and the flexibility of the solving approach proposed. In particular, the decomposition in three different solving layers (propagation, greedy solution and local search optimization) and the use of a lower bound algorithm, allows the tuning of the right solving process which suits the contingencies of the current Mex-Mdp problem.
4
MEXAR: An Interactive Support to Downlink Sequencing
Commitment of this study has been not only an analysis of the mission planning problem for Mars-Express but also the development of a demonstration system that show planning functionalities at work. This request was 45
Mean Turnover Time (MTT) 228Kps 160000 CFF+HPF CFF+TS+HPF CFF+SDF CFF+TS+HPF LB
140000
MTT [seconds]
120000
100000
80000
60000
40000
20000 1
2
3
4
5
6
7
8
9 10 Problem
11
12
13
14
15
16
17
16
17
(a) CF F
Mean Turnover Time (MTT) 228Kps 160000 HPF+HPF HPF+TS+HPF HPF+SDF HPF+TS+SDF LB
140000
MTT [seconds]
120000
100000
80000
60000
40000
20000 1
2
3
4
5
6
7
8
9
10
11
12
13
14
Problem
(b) HP F
Figure 20: Performance on benchmark B1 46
15
Mean Turnover Time (MTT) 228Kps 160000 CFF+HPF CFF+TS+HPF CFF+SDF CFF+TS+HPF LB
140000
MTT [seconds]
120000
100000
80000
60000
40000
20000 1
2
3
4
5
6
7
8
9 10 Problem
11
12
13
14
15
16
17
16
17
(a) CF F
Mean Turnover Time (MTT) 228Kps 160000 HPF+HPF HPF+TS+HPF HPF+SDF HPF+TS+SDF LB
140000
MTT [seconds]
120000
100000
80000
60000
40000
20000 1
2
3
4
5
6
7
8
9
10
11
12
13
14
Problem
(b) HP F
Figure 21: Performance on benchmark B2 47
15
Mean Turnover Time (MTT) 228Kps 160000 CFF+HPF CFF+TS+HPF CFF+SDF CFF+TS+HPF LB
140000
MTT [seconds]
120000
100000
80000
60000
40000
20000
0 1
2
3
4
5
6
7
8
9 10 Problem
11
12
13
14
15
16
17
16
17
(a) CF F
Mean Turnover Time (MTT) 228Kps 160000 HPF+HPF HPF+TS+HPF HPF+SDF HPF+TS+SDF LB
140000
MTT [seconds]
120000
100000
80000
60000
40000
20000
0 1
2
3
4
5
6
7
8
9
10
11
12
13
14
Problem
(b) HP F
Figure 22: Performance on benchmark B3 48
15
Mean Turnover Time (MTT) 200Kps 160000 CFF+HPF CFF+TS+HPF CFF+SDF CFF+TS+HPF LB
140000
MTT [seconds]
120000
100000
80000
60000
40000
20000
0 1
2
3
4
5
6
7
8
9 10 Problem
11
12
13
14
15
16
17
16
17
(a) CF F
Mean Turnover Time (MTT) 200Kps 160000 HPF+HPF HPF+TS+HPF HPF+SDF HPF+TS+SDF LB
140000
MTT [seconds]
120000
100000
80000
60000
40000
20000
0 1
2
3
4
5
6
7
8
9
10
11
12
13
14
Problem
(b) HP F
Figure 23: Performance on benchmark B4 49
15
grounded on the experience that this authors have in developing planning supports systems (see [2, 12]). Indeed the first two demo version of Mexar (July and November 2001) have been fast prototyped using O-OSCAR our open framework for scheduling applications (see [3]). The software we are currently delivering with this document is an optimized independent application that has been entirely coded in Java with the aim of giving ESA-ESOC a software structure that they can actually use and update according to changes needed during its use. This section shows the basic of the software architecture of Mexar then focuses of the Interaction functionalities of the module.
4.1
From MEX-MDP to a software architecture
Artificial Intelligence techniques work on a symbolic model of the domain of application. This is what the CSP techniques described in Section 3 actually realize in the modeling phase. To better understand the potentialities of the techniques at hand, we insert Figure 24.
50
Payloads
Science C
Spacecraft
Science B
Science A
Housekeeping
Packet Stores
TM (Science + Housekeeping)
SSMM
TFG
TM Router
Memory Dump
(a) The basic problem
Domain Model
Payload Operation Requirements
Housekeeping Activity
Data Packet Sequence for Downlink
(b) The relevant features
Figure 24: Basic modeling step in Mexar In 24(a) we show the part of the spacecraft physical system that is relevant to the Mex-Mdp. Notice that the on board system send to the ground the produced data after executing dump commands. The techniques integrated in Mexar work on a symbolic representation of the spacecraft that, as shown in 24(b), includes a representation of (1) the POR commands, (2) the background housekeeping activity, and (3) the physical on-board system (called the Domain Model in the Figure). It is worth noting that these three aspects are the ones that is possible to manipulate in the Problem Generator (see Section 2.3) to produce different internal representations for the Mex-Mdp. So, in Mexar it is the data file produced by the generator that contains all the information to build up a representation of the on-board system in the CSP framework for generating the dump telecommands for the specific problem. An additional comment concerns the fact that the solution framework is parametric with respect to different descriptions of the domain without 51
requiring any change to solving software. This is why this report emphasize the work done for generating a problem generator for the considered problem. It is also to be said that making the generator more sophisticated one can investigate increasingly complex scenarios working on a model of the real spacecraft. Let us now turn the attention to software modules that compose Mexar, that are two (see Figure 25): 1. The problem solver — It is responsible for implementing the CSP representation and the solution algorithms described in Section 3. It is sketched in the upper part of the figure. Its bipartition constraint data-base and solution algorithms reflects a typical partition in the CSP software code. 2. The interaction environment — It is the module that directly interact with the user, to allow him to use the software and to take part in the advanced problem solving functionalities that keep him in the loop of the solution process. It is shown in the lower part of the figure and will be described in detail in the rest of this document. The figure shows how the interaction module is also in charge of loading the representation of the domain and the current problem that was previously described. Such representation is sent to the solver for its task. A further comment concern the shape of the main interaction module. It has been designed to allow to user to inspect the different aspects of the modeled spacecraft. In fact, the main content of the interface are the timelines (temporal evolutions) of the payloads, the packet stores, and the communication link. In this way the user will have visual perception of both resources and activities in the Mex-Mdp under solution. This total inspection assumption will be called “glass box” principle later in the document.
4.2
Mixed-initiative problem solving
We now start analyzing the interaction services that have been built to create an empowering environment for the Mexar users. The long term aim of these type of tools is the so-called “Mixed-Initiative Problem Solving”, that is, the aim at creating a common environment for the user and the automated system that together solve the problem. The idea is that a human 52
Solving Algorithm
Contraints Data-Base
Problem
Payload Operation Requirements
Housekeeping Activity
Payload Timelines
Payload Descr.
Packed Store Status Profiles
Interaction Support Software
Domain Model
Interaction Commands
Solution
Data Packet Sequence for Downlink
Downlink Schedule Interaction Commands
Figure 25: Sketch of the Mexar Software Architecture
and an artificial agent put together their strengths trying to cooperatively bound their weaknesses (see the simplified view of Figure 26). We can say that this very appealing goal is quite a long term achievement but a lot of intermediate interpretation of the term mixed-initiative pave the way for such an achievement. We believe that also Mexar perform steps in the right direction even if at present it pursue a more restrictive view, namely the one of creating software applications with a high level of interactivity between the user and the system. We have been studying aspects of mixed-initiative problem solving in our previous work (see [4, 22]) and in this study we have chosen to design a system that chooses this perspective in the Mars-Express domain. The result is a system that integrates some of the previous ideas with quite a number of innovative services. The idea of allowing mixed-initiative interaction on Mexar is grounded on the construction of a number of specialized functionalities that all together guarantee the user a degree of intervention on the resolution process.
53
Solver A Solver B Solver C
Current Problem
Figure 26: Mixed-Initiative Problem Solving Another aspect is very relevant in mixed-initiative system, namely the idea of capturing the different skills that a user and an automated system can apply to the resolution process. Broadly speaking an algorithm can perform better on conducting repetitive search steps that are not possible for a human user, while the user usually has more specific knowledge on a domain that is difficult to formalize in general terms to be used by an algorithm. With respect to this second view the steps in Mexar are more preliminary but we believe that some of the ideas show possible ways for further work.
Figure 27: Mexar Functionalities
54
4.2.1
Interactive functionalities
The functionalities Mexar offers to the users are summarized in Figure 27. It clearly shows that the problem solving activity is central in the system. This functionality is guaranteed by different automated services centered on constraint-satisfaction methodology (CSP) described in Section 3 (and first introduced in [9]). The figure also show the flow of control among the different functionalities during their actual use. It is possible to identify an activity that aims generically at defining a single problem. At present, it is quite basic and consists of loading a problem description from a file. An open possibility is to replace it in favor of a more complex incremental functionality that could be well coupled with the CSP modeling used. The definition of a problem is followed by its solution according to the different algorithms produced in our work. A different functionality allows to refine the current problem. This activity consists, right now, in deleting some of the Payload Operation Requests (PORs) from the associated timelines. This can be useful to experiment different load on the resources in specific intervals of the solution. This functionality introduce a cyclic path among these activities that could bring the user to incrementally refine new Mex-Mdp problems. As shown in Figure 28 we group these functionalities in the basic interaction layout called Problem Analyzer.
Figure 28: Mexar Interactive Environments Once defined a problem we can try to solve it with different solution methods. The availability of a portfolio of problem solving procedures (like the greedy solver, local search, with different combination due to possible tuning parameters) has suggested us the idea of involving more deeply the user in the solution process creating an environment in which it is possible to save 55
different solutions. The idea is to allow the user to guide search on how to improve the solutions applying different algorithm to them. We call this process mixed-initiative solution space exploration. This aspect is strictly connected to the availability of evaluation metrics on the solutions as discussed in [9]. To this second cycle between Mexar services is associated a second interaction layout (called Solution Explorer (SE)) that will be described in Section 4.4 and represents a further contribution of this study to Mars-Express mission planning support systems.
Figure 29: The Problem Analyzer Layout
4.3
The Problem Analyzer
The Problem Analyzer (PA) contains two groups of functionalities one for problem editing and refining, another for problem solving. Its current layout is the one sketched in Figure 25. It is an evolution of the one developed for the preliminary versions of Mexar. The layout is based on the idea of inspectability of all the different components of the representation of the Mex-Mdp problem. This inspectability follows what we call “glass box principle” that allows the user to visually control the temporal behavior of the relevant domain variable. 56
Figure 29 show the basic layout of the analyzer. We recognize different aspects of the problem: the PORs list in textual form (#1), their distribution on the payloads timelines (#2), the used capacity of the packet-stores (#3), the communication downlink (#4). It is to be noted that windows #2-4 represent temporalized information that is shown synchronized as much as possible during manipulation. On the side of the screen there is a bar that allows access to different pop-up menus (see Figure 30). The bar can be moved around according to user needs. The first three menu buttons from the left are devoted to the basic tasks of the interaction environment the remaining three give access to additional service functionalities fully described in the Mexar user manual.
Figure 30: The PA’s menu bar Two buttons allow to enter the main functionalities of the analyzer. They are shown open in Figure 31. The services are subdivided between (a) choice, editing and refinement of a problem (commands shown in Figure 31(a)) and (b) problem solution and evaluation (see Figure 31(b)). The rest of the section describes the different interaction paths we have designed for Mexar users. From now on we use the compact expression Edit.Load-Problem to indicate the selection of the command “Load Problem” from the pop-up menu “Edit” (see 31(a)). 4.3.1
The “glass box” approach to loading, inspecting and solving a problem
The example in Figure 32 shows the basic idea used for visualizing a MexMdp problem and its solution. The activity is started by selecting the command Edit.Load-Problem. A specific dialogue allows to choose one of the problem files (see description in [7]). The CSP representation for the problem (described in [9]) is instantiated and used for showing information of the interaction panel. Figure 32(a) shows one of such dumping problems. In the packet-store timeline window, the current capacity requirements to store PORs data are shown. The current representation is normalized in 57
(a) Problem editing
(b) Problem solving
Figure 31: The blow up of PA’s buttons percentage of occupation to allow the representation of the same graph of functions with different size. This choice is because the critical information on the packet stores is the available capacity not the specific values contained now. We see that given a problem some packet store has enough capacity to fully contain the generated data, some others will necessarily require to be dumped to avoid overwriting. The empty downlink window contains as grey thick lines the interval of non-visibility to the ground. A solver is called with Solve.Greedy-Solver. After the solver work the situation is shown to the user as in Figure 32(b). In the table on the side is shown the time of availability on ground of the complete POR data (in case some data is still on board or has been overwritten a line in the corresponding line appears). Showing the same packet store timelines we can see that now the maximum capacity constraint is never violated due to the effect of different dumpings. To use a different greedy algorithm (different settings) on the same problem, it is possible to re-execute the same command. To call the local search on the current initial solution we just execute Solve.Taboo-Search. It is worth saying that the command Edit.Problem-Generator allows to create completely new problems according to the details described in the section on problem generation (and in report [7]). Analyzing the Solution. Mars-Express is endowed with a number of interactive functionalities to inspect single aspects of the current problem and solution with different visual queries. Such services have been build to 58
(a) before solving the problem
(b) after a solution
Figure 32: Inspecting the “glass box” 59
help understanding better an amount of information that is compacted to guarantee intuitiveness of the representation. We are talking about ability of zooming, temporal synchronization, etc. A detailed description of them is is not in the scope of this report and can be found in the Mexar manual. While this local commands are accessible in the specific window they work on, two general commands that are worth some description are attached to the “Solve” menu: Solve.Solution-Table and Solve.Eval-Solution. The solution table is a data structure that reconstructs all the details concerning the solution of the current problem. An example is shown in Figure 34(a). Using the table is possible to check for example (a) how the data from a single POR are segmented in different dump operations, (b) how the data return time has been generated, etc. In general it could be also possible to directly generate the dump commands from the lines of the table. In fact the whole table can be saved as a separate file and manipulated by different programs. We have additionally used the table to validate the results produced by the problem solver using an orthogonal algorithm. It is also possible to go further in the integration of this window with the visual features of the PA layout. The graphic evaluation has been added to have an immediate level of evaluation on the current solution. When calling the command from the menu a dialogue window allows to choose one or more evaluation functions (e.g. Turnover Time, Data Weighted Turnover Time, etc). Figure 34(b) shows an example. The x axis represent the PORs according to their increasing ID number. 4.3.2
Exploring the problem space
The current release of Mexar integrates functionalities of problem refinement. We have described the general idea in some of our initial reports of the project (e.g., [5]). The idea behind is to suggest a modality of work in which the tools is inserted in a continuous loop with the user that uses it to test different alternatives. Figure 33 sketches an hypothetical “Solve-InspectRevise” cycle in which the Mexar tool and the user are integrated. After a given solution the user reasons on the current results and can modify the problem behind, save the changes and start a new solution cycle.
60
(a) showing tabular data on the solution
(b) showing evaluation parameters
Figure 34: Macro tools for analyzing the solution 61
Figure 33: Using the Solve-Inspect-Revise Cycle Before showing examples of use of this service, it is worth noting that we have currently implemented such a functionality starting from a basic problem and working on it by deleting activities. This functionality can be easily extended allowing incremental modifications in any direction (e.g., allowing also addition of activities) because this is fully supported by the background CSP representation. Exploring alternative problem formulations. A first example of problem refinement is shown in Figure 35. The service we have added consists in the possibility of modifying the initial problem by deleting some of the PORs from the timelines. The general schema is exactly the one of having the user strictly in the loop with any decision that may have an impact on the negotiated context with the payload managers. A quite simple example is depicted in Figure 35. The human observes the available scenario in 35(a) for a given problem. He goes through the POR table and, according to his expertise, follows a criteria to remove some of the activities from the problem by deselecting them. Then he can push the “Update” button on the bottom left corner of the layout that transfer these choices on the graphical representation of the problem. At this stage the user can see if the changes have been effective on the packet stores, and can also directly ask for a solution of the same problem. Two different modalities for saving such a new problem are provided: the button Save Problem Changed on the bottom left of the layout save the problem including the deleted activities, so that later on they can be reinserted; the command Edit.Save-as-new define a completely new problem composed only by the selected activities. The idea is the one of allowing a trial-and-error refinement of a problem that can be useful when deciding what POR activities actually plan for execution. 62
(a) before
(b) after
Figure 35: Exploring different problem formulations 63
It is also clear that in such cases the choice of the user in very important but the tool is acting as an intelligent blackboard that shows updated information. This schema can be furtherly enriched and represent a potential line for future developments.
Figure 36: An example of solution failure for overwriting A more specific example: reasoning on failures. In Figure 36 an example is shown in which the problem solving algorithm fails to look for a solution because it ends up warning for overwriting (see small red message on the right bottom corner of the screen). In case of overwriting, the CSP representation informs of unfeasibility of the current configuration and does not produce a solution (see in the figure that the table on the right does not contain values in the column ”Availability”. In such cases again the cycle of iterated exploration shown in Figure 33 could be of great help for driving the user in the right exploration, making deletion more reasoned and so on. Again this is an example in which we have inserted simplified functionalities that show potentialities for future enhancements. 64
4.4
The Solution Explorer
The Mixed Initiative Solution Explorer (MISE) is a completely new environment inserted for the final version of Mexar. We first introduce the general idea behind its design then give some detail on its current implementation.
(a) solution sampling
(b) solution exploration
Figure 37: The general idea behind the exploration of the solution space We have designed two algorithms for Mex-Mdp, namely the greedy and the local search. At a high level of abstraction we can say that the greedy search allows to sample the solution space according to different parameters and to a heuristic function. In Figure 37(a) we show a white board that represent a solution space (not necessarily all consistent) and single separate points that represent single solutions sampled by the greedy algorithm. The local search starting from an initial solution generates a path in the solution space to possibly arrive to a better solution with respect to the initial one. The idea behind the solution explorer is the one that the user can generate an initial solution, save it, try to improve it by local search, save the results, try to improve it by local search with different tuning parameters and so on. It generate in this way a path in the search space. The he can restore one of the previous solution and attack its improvements with a local search with different parameters, etc. In this way he generate a tree of solutions. This procedure can be repeated for different initial start time generating a set of trees (see Figure 37(b)). Using at the same time the evaluation capability on a single solution (shown in Figure 34(b)) and its own experience he can generate different solution series, all of them saved, and, at the end, choose 65
Figure 38: Entering the Solution Explorer the best candidate for execution. The rest of this section describes how this concept of MISE is realized in Mexar. 4.4.1
Guided sampling of the solution space
The MISE environment is entered through the third button in the command bar (Figure 38). One command with the same name enters the MISE environment, the second, Save allows to save the current solution creating a point in the exploratory path. The MISE command allows to enter the environment that essentially is build on top of a repository of solutions. In this data base there is an indexed entry for the solutions that refers to the same problem.
Figure 39: The Solution Explorer Layout The empty layout of this environment is shown in Figure 39. It contains 66
three panes: (#1) is a table containing a distinct saved solution on each line and the information on how it has been generated (with greedy or with taboo) and the average evaluation parameters for that solution; (#2) a simple representation of the set of solution trees that are generated for that problem. This is to keep the user under control of the names of the generated solutions and their starting points; (#3) a graphic window where is possible to compare solutions among them according to different parameters. Figure 40 contains two examples of MISE developed on the single problem at different stages of exploration. Studying the examples it is possible to see that our idea has been again the one of facilitating the analysis of the current problem by the user. He have different tools to evaluate the solutions and can either generate new ones or choose the best according to different temporary criteria. Let us notice that the level of capabilities that the user put in the interaction with the automated tool can be pushed further with additional work.
5
Conclusions
This report describes the main achievement of a study that applies AI techniques to a mission planning problem of Mars-Express. The study has delivered to Mission Planners at ESA-ESOC a tool named Mexar that is able to support them in synthesizing spacecraft downlink operations. The results of our study can be summarized at three levels: 1. Problem Study: The task has been studied and formalized as the Mars Express Memory Dump Problem (Mex-Mdp) whose properties have been analyzed. They include both a lower bound for the more frequent evaluation measure (the MTT) and a definition of macro evaluation parameters for characterizing the difficulty of a problem. Furtherly, a random problem generator, grounded on the MPS experience, has been synthesized that allows the definition of a reasoned set of benchmarks. 2. Problem Solution: A representation of Mex-Mdp has been defined, based on constraint-satisfaction techniques. On top of such a representation the basic solving techniques have been designed: (a) some basic deduction rules that are grounded on the specific problem addressed allow to prune inconsistent search space; (b) an effective greedy procedure allows the fast generation of Mex-Mdp solutions; (c) an optimization 67
(a)
(b)
Figure 40: Two different exploration statuses
68
procedure based on taboo search allows for synthesizing better quality solutions on more difficult problem instances. 3. Tool Development: The CSP solving techniques are integrated in a software environment called Mexar to create an original support system for Mex-Mdps. Such environment is endowed with a quite sophisticated interaction module that pursues the idea of supporting the users by preserving their complete control on the critical decisions. We have seen how such module allows the user to both inspect different aspects of the internal representation (e.g., the timelines) and to actively guide two relevant processes such as the problem refinement and the solution exploration. Mexar has been successfully delivered to the MPS experts that are actually responsible for solving Mex-Mdps during Mars-Express orbiting around Mars. Such users have had a key role in validating the work at different steps of the study. They have been also very relevant to clarify aspects of the problem first, and to suggest ways for improving aspects of interaction module. In fact, the current release of Mexar derives from two preliminary versions that integrated simplified version of both the solver and the interaction modules.
5.1
Comments
The study shows an application of Artificial Intelligence techniques to a ground segment mission planning problem. It is to be noted that the effort in Mexar has been to develop an end-to-end application that allows the user to control the whole cycle from the problem generation to the solution analysis. One comment that is worth doing concerns the variety of different problems that are to be addressed to achieve this result. From the generation of test instances, to their solution, to the development of a sophisticated man-machine interface that offer different services to the user. Necessarily such effort in a limited amount of time needs further refinement in some parts as specified in the next section. Nevertheless it show also important positive aspects that are worth reminding: • The task we have automated usually requires one unit of personnel that is dedicated for half of his working time during the whole mission 69
to manually decide the spacecraft downlink commands. The task of this person is extremely repetitive and involves the control of different details at the same time, mostly represented as numerical values. Mexar shows a way to support the human operator with a software environment that both decreases the time spent in the task and also requires human cognitive abilities at a higher level of abstraction and decision. In this way, a possibility is open for creating a generation of tools that increase the satisfaction of personnel dedicated to continuous tasks that are critical for space missions success. • Tools like Mexar capture an amount of knowledge of the application domain. In particular the CSP internal representation and the algorithms that work on that representation model features of the Mars-Express spacecraft, while the interaction module copes with (and models) aspects of the human work at ground segment. The technology also allows modular extension of such modeling as soon as new features are available or needed. This feature opens the possibility for allowing turnover of the people in charge of the specific task. This aspect may have an impact of the satisfaction of the human operator that may alternate tasks during long time of operational missions. • Mexar is a decision aid that preserves the responsibility of the human mission planner. The tool shows how the human user can be supported by a generation of tools able to both offer different representation of the problem (e.g., to use reasoning on a graphical representation instead of a numeric ones) and to perform combinatorial exploration of alternative solutions (task difficult for human capabilities). Such features are never aimed at substituting human operators but to support them guaranteeing better quality of work. It is worth reminding that a common fake belief on Artificial Intelligence technology concerns their supposed aim at replacing humans in their work. Mexar is an example of tool that actually empower humans of additional capabilities through the creation of a cooperative work environment with software tools. • A different comment concerns the use of the Mexar tool. It is right now tailored to support the mission planner in deciding memory dumps in a daily activity. It is worth noting that the tool can also be used in a preliminary phase of a mission to test, for example, alternative 70
configurations of the on-board memory, payloads and communication channels. In fact Mexar uses a model of the spacecraft domain that is now integrated by the problem generator to create a Mex-Mdp problem specification. It is useful to underscore that the problem solver software is completely parametric with respect to such domain description so as that it is possible to change such description to simulate different operative scenarios. This feature is suitable to be used in a preliminary phase of a mission (e.g., before launch) for experimenting different policies of the mission features. • A further remark concerns an orthogonal dimension: the requirements in terms of both software and hardware. It is worth underlining that the Mexar software tool has been implemented as a Java application that is able to run on different hardware platforms in all cases requiring low computational power and relatively limited hardware costs. The system has been developed under Windows 98 but a successful porting under Linux has required no more than two hours of work for tuning specific features of the visual interface. Again this is worth a comment on the future direction that space software should pursue to achieve a significant reduction of costs maintaining high performance of the automated services. • A final comment concerns the ideas contained in Mexar about the development of interactive systems for supporting space exploration operations. It is to be noted that Mexar opens a possibility for further investigation of a topic (mixed-initiative problem solving) that can be of impact in multiple mission programs. Indeed the idea of studying the interaction of one or more human experts with a mission planner is currently pursued in various projects (for example, NASA Ames is studying a negotiation environment that includes an automated planner for deciding rover tasks in the Mars03 mission ([21, 23]). The problem connected in such interaction are quite complex but Mexar contribute to this scientific debate with the ideas on problem refinement and solution exploration that could be deepened in future studies.
5.2
Recommendations for future work
The effort we have described goes beyond the usual effort of a problem study. In fact our work was supposed to last nine months and lasted eighteen. This 71
is partly due to the time initially spent to look for the right problem to focus, and some other specific inconvenient internal to the project. But it is mainly due to the goal of the authors to obtain a complete end-to-end system that included all the aspects involved in the design and implementation of such systems and, in addition, was able to show the potentials of an AI approach in interactive support systems for ground segments. The result is a system that is far beyond the “prove of concept”. Mexar is a tool that could be actually used after some further effort aimed at considering specific operational constraints. It can indeed be inserted in the loop for a regular use as a support to operators. Among the issues, that were out of the scope of this current study, and would be positive to address we remember: • the input format of the PORs is the one of Stat and not exactly the one studied for Mars-Express. According to MPS experts the relevant information for solving the problem is there yet. Nevertheless the direct access to the real format could allow the system to be experimented with the real POR input that are going to be produced as soon as the mission phase become closer to the launch; • also worth studying would be the problem of experimenting with real users. Perform a real usability test may ensure a positive integration human-system. In particular the advanced features of the interaction module are worth an experimental study with users to understand directions of improvements that are more in line with the need of the users themselves; • further work is worth doing for enhancing the continuity in time of the Mexar use. In the operational phase there is a “continuum” in the use of such a tool and some further functionality is worth designing for making easy the transition between contiguous intervals of time, instead of relying on the load of different problem specification; • further work could be done to better interface the problem generator (as shown this is now done essentially writing a file of information). Here some further work would allow to perform experiments that for example consider alternative scenarios. For example it could be possible to test situations in which some of the on-board components is out of order. This is a possibility available also now but requires knowing 72
the detail of the domain specification file quite well because was not a primary issue in this study; • an additional issue concern the alternative ways for evaluating a solving algorithm. The current study has concerned the average delivery time, some additional work would be needed to understand the amount of security margins leaved in each packet store to face unforeseen events at execution time. These are just examples of what emerges from the work done. But really the domain of application is so rich that quite a number of additional studies could be done on it. The fact remain that these new studies are all enabled by having an open tool like Mexar available. The just mentioned issues concern improvements of the Mexar tool with respect to its current use in support of Mars-Express mission planning. A different dimension would be more related to re-use of the technology in different missions. We really think that the results here described are of more general impact in space missions and not only concerns Mars-Express. In this respect a study worth doing concerns the comparison with the same problem in different missions. The goal would be a push on re-using of components and algorithms both at problem solving at the user interaction module. Having available real data from other missions would allow a generalization of the effort and could create the base for producing a methodology, carefully abstracted away from the current specific system. A final comment concerns the possibility of using the AI techniques introduced in this study to produce a generation of support tools for actually using planning and scheduling components more widely in a mission development process. This study has shown that the possibility is grounded on real capability of the current AI technology. But a key role for achieving certain goals has been played by the real problem at hand. Having the possibility of working on real problems may allow both to understand and situate perfectly the technology, and to make an agenda for creating services for wide use in the future.
Acknowledgments Mexar has been supported by European Space Agency (ESA-ESOC) under contract No.14709/00/D/IM. We would like to thank the project officer 73
Fabienne Delhaise for the time spent in waiting for our results and for the continuous support in creating a bridge between our world and the mission planner’s. Without her role we couldn’t arrive to an open dialogue with people of experience so far away from ours, and as a consequence all the realistic results of our work would have been very difficult to be achieved. We also would like to thank Mars-Express mission planners Michel Denis, Pattam Jayaraman, Alan Moorhouse and Erhard Rabenau for introducing us Mars-Express world and for a number of prompt clarifications during the difficult steps of the study. We are particularly grateful to Michel Denis for pointing our attention to the Memory Dumping Problem in a May 2001 meeting that has been a cornerstone for our study. Finally, we would like to thank Mario Merri for several suggestions he gave us during the project.
References [1] J. Allen, J. Hendler, and A. Tate. Readings in Planning. Morgan Kaufmann, 1990. [2] A. Cesta, P. Bazzica, and G. Casonato. An Object-Oriented Scheduling Architecture for Managing the DRS Satellite Requests. In Proceedings of the International Workshop on Planning and Scheduling for Space Exloration and Science, Oxnard, CA, October, 1997. [3] A. Cesta, G. Cortellessa, A. Oddi, N. Policella, F. Severoni, and A. Susi. A Reconfigurable Constraint-Base Architecture as a Support for Automating Mission Planning. In Proceedings of the ESA Workshop on On-Board Autonomy, ESA-ESTEC, Nordwijk, The Netherland, October, 2001. [4] A. Cesta and D. D’Aloisi. Mixed-Initiative Issues in an Agent-Based Meeting Scheduler. User-Modeling and User-Adapted Interaction, 9:45– 78, 1999. [5] A. Cesta and A. Oddi. Towards a Mission Planning Support System for Mars Express. Technical Report MEXAR-TR-01-02, IP-CNR [PST], Italian National Research Council, April 2001. [6] A. Cesta, A. Oddi, G. Cortellessa, and N. Policella. Describing Knowledge to a Mission Planning Support System – First Steps for Creating a 74
Constraint-Based Tool. Technical Report MEXAR-TR-01-03, IP-CNR [PST], Italian National Research Council, April 2001. [7] A. Cesta, A. Oddi, G. Cortellessa, and N. Policella. MEX SSMM Dumps in Mission Planning: Generating Test Problems. Technical Report MEXAR-TR-01-07, IP-CNR [PST], Italian National Research Council, November 2001. [8] A. Cesta, A. Oddi, G. Cortellessa, and N. Policella. A Mixed-Initiative System for Mars Express. Technical Report MEXAR-TR-02-09, ISTC-CNR [PST], Italian National Research Council, May 2002. [9] A. Cesta, A. Oddi, G. Cortellessa, and N. Policella. Using AI Techniques to Solve Mex-Mdp. Technical Report MEXAR-TR-02-08, ISTC-CNR [PST], Italian National Research Council, May 2002. [10] A. Cesta, A. Oddi, G. Cortellessa, N. Policella, and F. Severoni. MEX SSMM Dumps in Mission Planning: Problem Definition, a Solving Algorithm and a Preliminary Graphic User Interface . Technical Report MEXAR-TR-01-05, IP-CNR [PST], Italian National Research Council, June 2001. [11] A. Cesta, A. Oddi, G. Cortellessa, N. Policella, and F. Severoni. MEX SSMM Dumps in Mission Planning. A Prototypical System for Downlink Packet Sequencing . Technical Report MEXAR-TR-01-06, IP-CNR [PST], Italian National Research Council, July 2001. [12] A. Cesta, A. Oddi, and A. Susi. O-OSCAR: A Flexible Object-Oriented Architecture for Schedule Management in Space Applications. In Proceedings of the Fifth International Symposium on Artificial Intelligence, Robotics and Automation in Space (i-SAIRAS-99), 1999. [13] Michel Denis. Personal communication from Mars-Express MPS. October 9,, 2001. European Space Agency, Mars Express Web Site. [14] ESA. http://sci.esa.int/marsexpress/, 2002. [15] F. Glover. Tabu Search – Part I. ORSA Journal of Computing, 1:190– 206, 1989. 75
[16] F. Glover. Tabu Search – Part II. ORSA Journal of Computing, 2:4–32, 1990. [17] A.K. Jonsson, P.H. Morris, N. Muscettola, K. Rajan, and B. Smith. Planning in Interplanetary Space: Theory and Practice. In Proceedings of the Fifth Int. Conf. on Artificial Intelligence Planning and Scheduling (AIPS-00), 2000. [18] J.K. Lenstra, A. H. G. Rinnooy Kan, and P. Brucker. Complexity of Machine Scheduling Problems. Annals of Discrete Mathematics, 1:343– 362, 1977. [19] Mars Express MOC. Science Timeline Analysis Tool ( Stat) - User Manual. ESA-ESOC, May 2000. [20] U. Montanari. Networks of Constraints: Fundamental Properties and Applications to Picture Processing. Information Sciences, 7:95–132, 1974. [21] NASA/JPL. Mars03 Mars Exploration Rovers. Described in http://mars.jpl.nasa.gov/missions/future/2003.html. [22] A. Oddi and A. Cesta. Toward Interactive Scheduling Systems for Managing Medical Resources. Artificial Intelligence in Medicine, 20:113–138, 2000. [23] Kanna Rajan. NASA Ames, MAPGEN (Mixed-Initiative Activity Plan GENerator). Personal Communication, Toulouse, France, April 2002. [24] B. D. Smith, B.E. Engelhardt, and D. H. Mutz. The RadarSAT-MAMM Automated Mission Planner. In Proceedings of the Thirteenth Innovative Applications for Artificial Intelligence Conference, 2001.
76
