Date: November 14, 2001

1
Request-Oriented Scheduling Engine (ROSE)
What It IsA Candidate Usage Concept

• John Jaap
• Marshall Space Flight Center
• Flight Projects Directorate
• Ground Systems Department
• 256-544-2226
• John.Jaap_at_msfc.nasa.gov
• http//payloads.msfc.nasa.gov/ROSE/

Elizabeth Davis Is Co-researcher on ROSE Kim
Muery Is Co-creator of Candidate Usage Concept
2
ROSE Is

• Key Features
• Incremental Scheduler ROSE processes a single
  request (adding a task to a timeline) and then
  waits for another request. Other scheduling
  engines are batch and user-assisting.
• Web Application The user navigates via a web
  browser to the ROSE web site, logs on, and
  proceedsto formulate scheduling requests and
  submit them for scheduling.
• Transaction-Quality Implementation The system
  is sufficiently robust so that nothing is ever
  lost hardware or software failures cannot cause
  the loss of what is already in the timeline.
• Graphics User Interface The request
  formulation process (modeling) employs graphical
  methods to describe activities and sequences.
  The user is presented with a canvas to which
  items are added and arranged in a hierarchy (for
  activities) or in a
  network (for sequences).
  Details of the requirements
  are entered via dialog
  boxes.

ROSE is the subject of an on-going research
project into advanced planning and scheduling
systems by the Ground Systems Department of the
Flight Projects Directorate.
Graphical modeling is similar to the Interim
Users Requirements Collection (iURC) system.
3
ROSE Is

• Implications
• Geographically Dispersed Users ROSE supports
  remote users even the on-board crew can use
  ROSE.
• Multiple Simultaneous Users ROSE supports
  simultaneous users working on a single timeline.
  ROSE funnels incoming scheduling requests from
  the users into a single stream and applies the
  requests one at a time to the timeline.
• On-The-Fly Timeline Integration ROSE applies
  all scheduling requests to a single timeline
  further integration is not needed.
• Immediate Feedback ROSE provides immediate
  feedback when a request is submitted.
• Minimized Change Requests ROSE users see where,
  on the timeline, a model was scheduled. They can
  immediately re-submit if the request did not
  yield the desired results.
• Anyone Can Be an Expert Being an expert in the
  behavior of the scheduling engine means knowing
  how the engine will react to a given model, and
  how to build a model to achieve the desired
  results. ROSE will make the users virtual
  experts in using the scheduling engine by making
  them experts in modeling.

After only a few submittals, the users will know
what to expect from the engine i.e., they will
become virtual experts on the scheduling engine.
4
ROSE Is

• Modeling
• Maximally-Expressive Modeling ROSE uses a
  request format that is a natural representation
  of the requirements without adding artificial
  constraints or constructs. This modeling
  methodology might be called high-fidelity or
  hi-fi modeling the model looks like the
  real-world payload and the engine interprets the
  model as expected. Modeling is based on
  activities, which define the resource
  requirements (with alternatives) and other
  quantitative constraints of tasks to be
  performed, and sequences, which define the
  relationships between tasks. Sequences may also
  define relationships with other sequences, with
  activities and sequences of other payloads or
  station systems.

5
ROSE Is
Modeling In the ROSE modeling approach, nearly
all resources are defined in the equipment models.

• Payload Developers provide descriptions of their
  equipment and how they intend to use it. They
  also provide descriptions of how they intend to
  use station-provided equipment.
• Personnel at the Control Center (not the payload
  developers) build equipment models. These models
  define how much of each station resource is used
  when the equipment is operated. Most equipment
  will have multiple operation modes with differing
  resource requirements each of these modes is
  modeled.
• Equipment models include both information
  received from the payload developers and
  requirements derived from how the equipment is
  connected (integrated) with the station.

Crew is treated as a unique resource, not as
equipment. Additionally, an equipment model
never specifies any crew usage.
This approach mirrors the real world. In a
laboratory, experiments use equipment that use
power, etc.
6
ROSE Is

• Modeling Innovations
• Activities can include non-homogeneous optional
  groupings. For example, an activity may require
  crewman 1 and the 35mm camera or crewman 2 and
  the digital camera.
• Sequences may include sub-sequences.
• Sequences may include "percent-coverage"
  relationships (downlink must be available for 80
  of the time).
• Sequences may specify alternate scenarios (if
  available, use real-time video otherwise, record
  and downlink later).
• Sequences may include optional tasks.
• Sequences may include resource lock-in (if
  crewman 1 is selected for the first activity,
  then he must be selected for subsequent
  activities).
• Sequences may include resource carry-through
  tasks (if the start of this task is delayed, then
  specified resources are consumed during the
  delay).
• Sequences may include preemptable or
  interruptible activities and specify the
  resources consumed by and during the interruption.

7
ROSE Is
Configuration

• Scheduling Engine An incremental scheduler
  schedules each request within the available
  resources while meeting all the temporal
  constraints.  An initial profile of resource
  availabilities will be input from à priori
  sources.  All incoming requests will be handled
  by a standalone application (configured as a
  windows service) running on a server running
  Microsoft Windows (currently Win2000 Server).
• Database All models, à priori resource
  availabilities, and the timeline are stored in a
  relational database (such as Oracle or SQL
  Server).
• Web Server The interface between the client and
  the scheduling engine / database is handled by a
  web server (currently IIS 5.0).
• JAVA Applet and Web Browser The user
  interacts with a web browser and a JAVA applet.
• Timeline Inspection The current
  (dynamic)timeline can be examined.
• Delete or Replace Scheduling entities can be
  deleted or replaced.

8
Candidate Operations Concept

• Deploy a web-based request-oriented scheduling
  engine so that payload developers schedule their
  own payloads.
• The concept is based on an instance of ROSE
  installed at a major support facility, such as a
  payload control center, and serving all of the
  payload developers (PDs) supported by that
  facility. The payload developers would remotely
  connect to the ROSE system and simultaneously
  schedule their payloads. The results would be
  the timeline provided by that installation (or
  partner) to the Payload Operations Integration
  Function.

The operations concept proposed in this
presentation is one of several ROSE-based
operations concepts that are being discussed in
conjunction with the ROSE research project.
The ROSE system and ROSE-based operations
concepts can be used for scheduling applications
other than the space station.
9
Candidate Operations Concept
The Critical Element If payload developers, who
already have expertise in the payloads, are to
formulate scheduling requests and submit them to
a scheduling engine, they must have expertise in
the scheduling engine.

• Being an expert in the behavior of the scheduling
  engine means knowing how the engine will react to
  a given model, and how to build a model to
  achieve the desired results.
• ROSE will make the payload developers virtual
  experts in using the scheduling engine by making
  them experts in modeling. ROSE uses a request
  format that is a natural representation of the
  requirements without adding artificial
  constraints or constructs the model looks like
  the real-world payload and the engine interprets
  the model as expected.
• ROSE provides immediate feedback (when a request
  is submitted, the resulting timeline is available
  immediately), thereby exposing users to the
  workings ofthe scheduling engine.

After only a few submittals, the payload
developers will know what to expect from the
engine when a request is submitted i.e., they
will be virtual experts.
10
Candidate Operations Concept
Current Concept for Comparison Modeling in the
current concept is always a cooperative affair
between the payload developer (PD) who knows his
hardware and requirements and the scheduling
cadre who knows how the scheduler works. There
is no capability for the PD to acquire expertise
in the scheduling engine because he has no direct
feedback from the engine about the modeling
process.
11
Candidate Operations Concept
Candidate Concept Based on the increment plan
produced during the preparation phase, and other
information, the cadre generates daily
allocations per payload for the planning period
to be scheduled. The allocations are not
profiles but are total usage limits of each
resource during the period. Once the system is
initialized with all the resource constraints,
the payload developers use the ROSE system to
produce a timeline. As always, producing a good
timeline requires attempting to schedule a model,
rejecting unacceptable results, tweaking the
models, and trying again.
12
Candidate Operations Concept
13
Candidate Operations Concept
Equipment models require only occasional updates.
14
Equipment models require only occasional updates.
15
Candidate Operations Concept

• Timeline Validation
• Timeline validation is done after the PDs have
  produced the timeline.
• Timeline validation only needs to validate the
  models.
• Model validation is easy because all resources
  (except crew) are associated with equipment
  usage.
• Model validation is done by comparing the
  scheduled models to a reference set of models.
  (Reference models are built during the
  preparation stage.) It is only necessary to check

• Is all the equipment needed by this payload
  listed on the model?
• Are the equipment modes correct?
• Are the equipment modes in the correct sequence?
• Are the durations within the allowed range?

Timeline Validation ? Model Validation. It is
not necessary to validate the scheduling engine
for each iteration.
16
Candidate Operations Concept
Benefits (tangible and intangible) This concept
allows the payload developers, the customers, to
produce the timeline they want. Giving the
customers what they want is the epitome of a
better timeline.

• Better Schedule The quality of the timeline
  should be better because the timeline is produced
  by those with the most knowledge about the
  payload and how it should be scheduled.
  Additionally the timeline will be produced with
  up-to-date models the PDs have total control of
  the models and are free to make updates at any
  time.

• Fewer Change Requests Because the PDs produce
  the timeline, they should need to generate far
  fewer change requests to be implemented by the
  execution team. Fewer change requests reduces
  the workload (and size) of the execution team.

• Less Cadre Time and Burn-Out The candidate
  concept eliminates scheduling as a cadre task.
  Even though some new tasks are introduced, the
  number of cadre members can be reduced.

• Available to the Crew The crew using their
  Internet access could act as part of a PDs team
  and schedule payload activities as though they
  were on the ground.

• Reduced Hardware Cost ROSE operates on low-cost
  computers running the Windows operating system.

17
Candidate Operations Concept
Conclusion The ROSE-based operations concept
presented here is an alternative concept that is
operationally viable, is low cost, provides more
autonomy to payload developers and is presented
for future consideration in defining the
long-term operations concept for ISS payload
operations.

• The ROSE system is based on a proven modeling
  methodology that adequately and eloquently
  represents payload requirements.
• The architecture of the ROSE system has been
  developed and demonstrated. Research and
  development on the scheduling engine shows that
  it is feasible to develop a scheduling engine
  that matches the modeling methodology.
• The proposed process can easily be substituted
  for the current process, with reductions in
  required personnel.

Most significantly, the ROSE-based concept allows
the payload-developer community to produce the
timeline. The ROSE system will provide them with
a convenient and robust tool to produce the
timeline they want. At the same time, the
ROSE-based concept provides adequate controls to
ensure that the timeline meets programmatic
constraints.
18
Status

• ROSE Prototype Status
• Web Architecture Prototyped and Verified.
• Academia (SFF) Recommendations on Modeling To Be
  Incorporated Soon.
• JAVA Applet 90 Complete.
• Equipment Mode Editor 80 Complete.
• Scheduling Engine Just Starting.

Authorization/funding for prototyping the
scheduling engine was recently obtained from
Center Directory Discretionary Funds. This is
projected to be 1.5 FTEs annually for 2 years.