310 likes | 398 Views
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 http://pst.istc.cnr.it.
E N D
Deploying RAXEM2Planning 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 http://pst.istc.cnr.it 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 RAXEM MEXAR
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
Master Time Line (MTL) Telecommands (TCs) AASFO1A3 AASFO1AX AASFO1A3 AASFO1A4 AASFO1A3 AASFO1A5 AASFO1B3 AASFO1B3 AASFO1J3 … Mars Uplink Windows OWLT -- One-Way Light Time The Mex-Up problem Spacon Instruction Form (SIF) RAXEM2 MDAF files Earth
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 The Raxem2 solution AI Module Interaction Module Plan life cycle services Domain Modeling Uplink DataBase User Management Problem Solving User Interaction Spacon Instruction Form (SIF) Generator RAXEM2
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
MTL operation Size(MDAF) Channel operation durUpLink stUpLink Modeling with Timelines 1) MTL Cumulative resource Last(MDAF) First(MDAF) 2) Channel Binary resource
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 foreachmdaftouplinkdo whilenotallocateMDAF(mdaf,currentTime) do if can relax then relax(mdaf) else break end while ifallocated(mdaf) then currentTime primaryUplinkEnd(mdaf) end for functionallocateMDAF(mdaf, currentTime) start firstAvailableInstant(currentTime) whilenotallocated(mdaf) do try ifnotmultiMDAFAllocation(mdaf,start) then singleMDAFAllocation(mdaf,start) onRetryLaterErrordo 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.db Uplink DataBase SQLite
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 “Solve” button • Input for the AI solver • Confirmation scheme • Uplink scheme SIF view
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
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