# Presentation: 280357

## Request-Oriented Scheduling Engine (ROSE)

- John Jaap
- Marshall Space Flight Center
- Flight Projects Directorate
-  Ground Systems Department
- 256-544-2226
- John.Jaap@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

- What It IsA Candidate Usage Concept

## 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.

## 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.

## 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. 

**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.

**ROSE Is ...**

## 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.  **

- This approach mirrors the real world.  In a laboratory, experiments use equipment that use power, etc.

**ROSE Is ...**

## 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.**

## ROSE Is ...

**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).
**J****AVA**** 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.

**ROSE Is ...**

**Configuration**

## Candidate Operations Concept 

**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.**

**Candidate Operations Concept **

- 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.

## Candidate Operations Concept 

**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 of****the scheduling engine.**** **

**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.**

**Candidate Operations Concept **

- 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.*

## 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.**

## 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. **

## Candidate Operations Concept 

## Candidate Operations Concept 

**Candidate Operations Concept **

- Equipment models require only occasional updates.

## Equipment models require only occasional updates.

## 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**

- Timeline Validation  Model Validation.  It is not necessary to validate the scheduling engine for each iteration.

**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?**

## Candidate Operations Concept 

**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.

**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. **

**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 PD’s 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.

## 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.**

## Status

**ROSE Prototype Status ...**
**Web Architecture Prototyped and Verified.**
**Academia (SFF) Recommendations on Modeling To Be Incorporated Soon.**
**J****AVA**** 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.**