Deploying RAXEM2 Planning Improvements in Daily Work Practice Giulio Bernardi, Amedeo Cesta & Gabriella Cortellessa ISTC-CNR [PST] Institute for Cognitive Science and Technology National Research Council of Italy Planning and Scheduling Team Work supported by ESA - the European Space Agency

Introduction Raxem is a software system developed to plan the upload of commands to the Mars Express spacecraft (orbiting around Mars since 2004) Raxem project started after the success of Mexar2, which is used to plan data dumping activities from the spacecraft since 2005

Introduction MEXAR RAXEM

Commands from Earth The Mars Express probe receives instructions from Earth Instructions are time-tagged telecommands (TCs) On board, TCs are stored in a memory buffer, the Master Timeline (MTL) TCs are discarded after execution Deciding how to send data is not trivial…

How to send commands? Related TCs are grouped in MTL Detailed Agenda Files (MDAFs) Analogous to programs: they must be uplinked in an unique pass Many constraints: –Communication is only possible during certain uplink windows –Sending data to Mars takes time –The Master Timeline has a finite capacity –A contingency plan is needed in case of failure

The Mex-Up problem An uplink plan must satisfy these goals – specifying when to uplink each MDAF – which modality of transmission should be employed, and –identifying a secondary uplink window to use in case of failures All requested MDAFs must be uplinked as early as possible, so that they are on board in time, given the finite capacity of the MTL and the limited bandwidth of the transmission channel, while trying to keep the MTL as full as possible

The Mex-Up problem MDAF files Earth Master Time Line (MTL) AASFO1A3 AASFO1AX AASFO1A3 AASFO1A4 AASFO1A3 AASFO1A5 AASFO1B3 AASFO1J3 … Telecommands (TCs) Mars RAXEM2 Spacon Instruction Form (SIF) Uplink Windows OWLT -- One-Way Light Time

Before Raxem The complexity of the Mex-Up problem was initially underestimated Planning was carried on manually with paper and pencil Disadvantages of manual planning: –Very time-consuming –Prone to errors –Poor optimization –Emergency re-planning was extremely difficult

The Raxem Solution A first version of Raxem was developed to assist users in solving the Mex-Up problem Notable features: –Interactive plan generation –Graphical output of the solution (charts) –Inspection of spacecraft status Raxem has been operational since summer 2007 [see Cesta et al ECAI-08] The success of Raxem encouraged users to ask for a more complete tool…

Need for better integration A semi-manual procedure was employed to parse Raxem’s output and produce SIF forms (the official instructions delivered to uplink operators) History of performed uplinks was held by external means There was the opportunity to transform Raxem in a tool able to embrace the whole uplink work cycle

More than a planning tool New goals for Raxem2: –Ability of maintaining the whole history of uplink operations (uplink database) –Acknowledgement of arbitrary changes on the planned solution by the users This is necessary to accurately record actual uplink operations –SIF generation and management –User management and graphical improvements

Raxem2 includes a new module that ensures complete and continuous management of the uplink problem Existing functionalities have been comprehensively enhanced Uplink DataBase Uplink DataBase Domain Modeling Problem Solving AI Module User Interaction Spacon Instruction Form (SIF) Generator Plan life cycle services R AXEM 2 Interaction Module User Management The Raxem2 solution

Modeling with Timelines Two relevant components of the model are the MTL and the Communication Channel They are timelines: –They can report their status over time –Data can be allocated/deallocated on them over time The MTL is a cumulative resource –Has a finite capacity The Channel is a binary resource –Is either busy or free in a particular instant

Modeling with Timelines The act of data uplink is an Activity An activity is modeled by two operations: –Channel operation Represents the transmission of data during an uplink window Requires the whole bandwidth of the channel for the entire duration –MTL operation The act of storing data in the MTL It “instantaneously” increases the amount of data in the MTL

Modeling with Timelines 1) MTL Cumulative resource 2) Channel Binary resource Last(MDAF) stUpLink First(MDAF) durUpLink Channel operation MTL operation Size(MDAF)

The Solver The software component that generates a plan It employs a relatively simple constructive algorithm which provides a good trade-off between speed and optimality of the solution It can relax constraints for some MDAFs if needed: –Confirmation Scheme (full or reduced?) –Uplink Scheme (secondary window or not?) The user can change them too by providing hints to the solver

The main algorithm foreach mdaf to uplink do while not allocateMDAF(mdaf,currentTime) do if can relax then relax(mdaf) else break end while if allocated(mdaf) then currentTime  primaryUplinkEnd(mdaf) end for function allocateMDAF(mdaf, currentTime) start  firstAvailableInstant(currentTime) while not allocated(mdaf) do try if not multiMDAFAllocation(mdaf,start) then singleMDAFAllocation(mdaf,start) on RetryLaterError do start  instantToRetry end try end while end function foreach mdaf to uplink do while not allocateMDAF(mdaf,currentTime) do if can relax then relax(mdaf) else break end while if allocated(mdaf) then currentTime  primaryUplinkEnd(mdaf) end for function allocateMDAF(mdaf, currentTime) start  firstAvailableInstant(currentTime) while not allocated(mdaf) do try if not multiMDAFAllocation(mdaf,start) then singleMDAFAllocation(mdaf,start) on RetryLaterError do start  instantToRetry end try end while end function

The Persistence Module Raxem’s data is held in the uplink database –It contains both the historical data and the working set Persistence is handled using DAO objects implementing CRUD methods The database backend is provided by SQLite library –All data is contained in a single file –No need for an external system –Backups and software deployment are easy Uplink DataBase Uplink DataBase SQLite uplink.db

Interactive planning Raxem2 encourages user’s involvement in planning Planning parameters can be altered for individual MDAFs: –Use reduced confirmation (shorter uplink) –Don’t allocate a secondary window –Exclude some MDAFs from the plan Possibility of tuning the solution Allows to perform what-if analysis

The Raxem2 interaction MDAF view Input for the AI solver –Confirmation scheme –Uplink scheme SIF view “Solve” button

Great Flexibility Users can override any decision made by the solver Raxem2 accepts any change, and issues warnings if needed Users can also inform the system about uplinks that actually happened In both cases, the internal model of the problem is updated accordingly

The SIF form view Uplink intervals (can be overridden) Comment areas

Solution view: before Raxem Olligram: hand-made gantt-like chart

Initial solutions in Raxem v1 MTL Usage level Uplink Graph OnBoard Execution Graph

The integrated view in Raxem2 MTL Usage level Uplink Graph OnBoard Execution Graph

Experimental Results Accuracy and performance tests –Accuracy: degree of adherence of the solution to user’s expectations (percentage) –Performance: time needed to produce a plan (seconds) Two sets of data, about 60 MDAFs each Tests show program behavior with different planning parameters Raxem2 always outperforms Raxem by a great extent

Experimental Results (2) Accuracy full wfull w/0reduced w/reduced w/o Set %95.76%92.73%100.00% Set %100.00%92.98%100.00% Performance (seconds) full wfull w/0reduced w/reduced w/o Set1 Raxem Raxem n/a0.948 Improvement33.51%126.87%n/a200.00% Set2 Raxem Raxem n/a1.138 Improvement51.84%233.33%n/a223.30%

User Assessment Raxem2 is operational at ESA since March 2009 Engineer work load was reduced from 5 hours to below 1 hour The software was up to expectations with regards to –plan generation –handling of emergency situations –flexibility SIF management has proven to be a very valuable feature

Conclusions Raxem2 is a successful example of integration of different technologies Planning & Scheduling capabilities alone are not enough: users need a complete system to effectively perform their work Seamless integration with the established work practice is necessary for acceptance in a rather conservative environment

Conclusions Key factors for success –Continuous user involvement in planning Small adjustments, what-if analysis –Centrality of user in the decisional process Not a “black box” system Operators can override any choice –Integration of different technologies Needed to provide the most effective and complete user services

Questions ?