Dynamic Allocation of Resources to Improve Scientific Return with Onboard Automated Planning

1
Dynamic Allocation of Resources to Improve
Scientific Return with Onboard Automated Planning
Fabrício de Novaes Kucinskis fabricio_at_dea.inpe.br
Aerospace Electronics Division - DEA Onboard
Data Handling Group - SUBORD
2
Contents

• Introduction
• Onboard Planning Scheduling
• The RASSO Service
• The System Model
• The State Verifier
• Implementing Onboard Planning Safely
• Current Status
• Related Work
• Conclusion

3
Introduction

• The satellites of the Brazilian Program for
  Scientific Satellites and Experiments carry a
  collection of scientific and technological
  experiments
• These experiments run through a repetitive
  pattern, with pre-defined quotas of resources
• But there are scientific events of which
  occurrence is randomic and of short duration
• The opportunity to better analyse these events
  has to be taken!

4
Onboard Planning Scheduling (1)

• Its not possible to the ground team to
  reconfigure the satellite on time to analyze the
  event
• Classical programming techniques are not enough
  to deal with a huge number of states in which the
  system can be at the moment of the detection of
  the event
• AI Planning Scheduling is presented as a
  potential solution to be exploited!
• RASSO, a Resources Allocation Service for
  Scientific Opportunities, makes use of Planning
  Scheduling to increase the satellites autonomy.

5
Onboard Planning Scheduling (2)

• Planning is the selection and sequencing of
  activities such that they achieve one or more
  goals and satisfy a set of domain constraints
• Scheduling is the assignment of resources and
  times for each activity, so that the assignments
  obey the temporal restriction so activities and
  the capacity limitations of a set of shared
  resources
• In RASSO, scheduling is dealt as a stage inside
  planning, merging the domain restrictions to the
  ones of resources and time.

6
The RASSO Service

• A service provided by COMAV, the new Brazilian
  satellites computer
• Attend on requests for more resources triggered
  by the scientific experiments when they detect
  events that will not be adequatelly observed with
  the current available resources
• Composed by
• a Negotiator Module
• a Planner Module, with a State Verifier and a
  compiled System Model

7
The System and Service Architecture
8
The Negotiator Module

• Verifies if there is free resources to attend on
  the experiments request if so, it allocates
  directly
• If not, it verifies if its possible to
  reallocate resources from other experiments using
  a Negotiation Rules Table
• If its possible to reallocate, the Planner
  Module will be called to replan the satellite
  activities

9
The Planner Module

• Goals
• Reallocate resources from other experiments and
  processes to attend on the request
• Keep these resources allocated during the events
  duration
• Return the resources to the experiments and
  processes that had yielded them
• Do this (1, 2 and 3) affecting the least possible
  the other experiments and the proper satellite
• Uses a model of the system compiled with the
  service

10
The System Model

• Described in C language, uses a pseudo-script
  created with macros
• structures -gt types of objects of the system
• enumerations -gt domains of objects attributes
• functions -gt actions available to the planner
• Conditions verify if an action in applicable
• Each action is called in two different moments
  when planning and when sending the plan to
  execution through the Time-Tagged Commands (TTC)
  Queue

11
The System Models Pseudo-Script
include "language.h" RASSO_domain
OperatingModes normal, privileged,
yielding RASSO_domain ExperimentID ex_1, ex_2,
ex_3, ex_4, ex_5, ex_none RASSO_type
Experiment ExperimentID id
OperatingModes mode Experiment exp1, exp2,
exp3, exp4, exp5 RASSO_action
(AllocateMemory) when_planning
condition(exp1.mode normal) //
effects of the action in the current state have
to be described here when_running
// time-tagged command(s) related to
the action here action_success
12
The State Verifier

• The initial state of the planning process is a
  future state of the onboard system
• In RASSO, each satellite command that affects the
  model has a corresponding RASSO_Action
• To discover the future state the Planner calls a
  State Verifier Module, which read the TTC Queue,
  discovers what commands will affect the model and
  applies the corresponding actions to the current
  state

13
Implementing Onboard Planning Safely (1)

• Theres a great and justified resistance related
  to the increase of the satellites autonomy
• This resistance is even bigger when something
  related to AI is mentioned!
• Theres the need to use a gradual and
  confidence-based way to implement onboard
  planning
• RASSO does this by using three operating modes
  disabled, advice and act

14
Implementing Onboard Planning Safely (2)

• In the Disabled mode, the service is not
  available
• In the Advice mode, when receiving a request from
  an experiment, the service will work in a plan as
  it would send it to execution, but it will not.
  The resulting plan will be sent to the ground
  operations team to be analyzed and compared to
  the current (normal) plan, that was really
  executed
• In the Act mode, the RASSO service is completely
  operational

15
Current Status

• RASSO is in development phase, at the same time
  as COMAV
• At this moment, were working in the improvement
  of the System Model and the State Verifier
• We intend to have a first complete and working
  version until the end of the year

16
Related Work

• NASA / Ames Reseach Center RAX-PS
• aboard the Deep Space One probe
• controlled the probes thrust control and rote
  correction for two times in May 1999
• NASA / Jet Propulsion Laboratory
• flight in the Earth Observing One LEO satellite
• replan activities, including downlink, based on
  the observations of previous orbital cycles
• became fully operational in April 2005
• NASA / Ames Reseach Center IDEA
• a framework that merges planning and execution

17
Conclusions

• Given the level of development reached by onboard
  satellite systems, the next step to take is the
  increase of its autonomy
• Providing technology for the use of onboard
  planners meets that, but it is something to be
  treated carefully due to the criticality of the
  application
• Through modest goals and a realistic approach,
  RASSO consists of a first step toward the use of
  onboard planning to increase the autonomy of our
  satellites in a near future

18
Are you awake yet?
So, thank you!
fabricio_at_dea.inpe.br