The satellite domain was developed following discussions with David E. Smith and Jeremy Franks at NASA Ames Research Center. It is intended to be a first model of the satellite observation scheduling problem. The full problem involves using one or more satellites to make observations, collecting data and downlinking the data to a ground station. The satellites are equipped with different (possibly overlapping) collections of instruments, each with different characteristics in terms of appropriate calibration targets, data productions, energy consumption and requirements for warming up and cooling down. The satellites can be pointed at different targets by slewing them between different attitudes. There can be constraints on which targets are accessible to different satellites due to occlusion and slewing capabilities. Instruments generate data that must be stored on the satellite and subsequently downlinked when a window of communication opportunity opens with a ground station. Communication windows are fixed. Data takes time to downlink and it could be impossible to downlink an entire satellite store in a given time frame, so downlinks must be scheduled around the storage capacity, the production of data by observations and the opportunities to downlink data as they arise. In the real problem there are additional difficulties such as the management of energy and the use of solar power and the maintenance of operational temperatures during periods in shadow. In order to make the problem accessible to the planners in the competition (given the time scales for encoding the domain, writing a problem generator and testing competing planners) several important features of the real problem are simplified. Perhaps most important of these is that in the real problem targets are only visible during particular time-windows, although the elimination of the problem of downlinking data is also a significant simplification. Representing the windows of opportunity is possible in PDDL2.1, but not entirely straight-forward and this remains an area in which there is need for development. Management of power and temperature were also simplified away.
The STRIPS version of the problem involves deciding on the most efficient covering of the observations given the satellite capabilities. This is an interesting combinatorial problem if the satellites are assumed to be free to operate concurrently (in a Graphplan-style parallel activity), but otherwise the problem offers few interesting choice points. The STRIPS version was based on an earlier Satellite domain contributed by Patrik Haslum.
The metric version of the problem introduces data capacities into the satellites and fuel use in slewing between targets. The plans are expected to minimize fuel use in obtaining the data. This problem combines a constrained bin-packing problem (getting the data into the limited stores of the satellites, subject to the constraints that only certain satellites are equipped to obtain certain data) with a kind of route planning problem (finding fuel-efficient paths between targets while also considering the combined costs of the fuel consumption by all of the satellites).
The temporal versions introduce duration and make concurrency important. The full temporal problem includes different slew times between different pairs of targets. These problems both involve minimising make-span times for the data acquisition. A complex version of the domain combines the temporal and metric features so that planners are required to manage the problem of storing different sized data blocks in limited capacity satellite data stores.
A further variant of the Satellite domain, called the HARDNUMERIC version, represents an important departure from traditional planning problems: the logical goals describing the intended final state are trivial (either empty or a few simple final positions for the satellites), but the metric by which the plans are declared to be evaluated is the quantity of data collected. The problem is interesting because a null (or nearly null) plan will solve all the instances, but the quality of these plans will be zero. To produce a good plan it is necessary to ensure that the satellites are used to collect data and this, in turn, requires that the planner constructs reasonable data collection goals. This is a hard problem for most current planners -- particularly the fully-automated planning systems. Nevertheless, it is a realistic demand for many problems that a planner might be required to face: it is not uncommon for the specific final state to be less important than the effects of the actions carried out in reaching it.