Документ взят из кэша поисковой машины. Адрес оригинального документа : http://www.stsci.edu/itm/1998-02/ITM_1998_02.pdf
Дата изменения: Sat Oct 3 08:46:23 1998
Дата индексирования: Sat Mar 1 07:58:12 2014
Кодировка:
Поисковые слова: trees

Internal Technical Memorandum ITM-1998-02

Snapshot Scheduling
Merle Reinhart, Anuradha Koratkar, and Jim Younger October 1, 1998 Concurrence:

ABSTRACT
This report describes the procedures used to select Snapshot exposures for execution. When Snapshot visits are ready to be placed on a flight calendar, they are added to the snapshot Pool automatically. The method for selecting a visit in the Pool is an "ordered" random sample of candidates within six categories ordered by Cycle number (higher to lower) and percentage of visits that have been scheduled or completed. A proposal that has less than 50% of its visits scheduled or completed is given preference within a cycle.

1. Introduction
Prior to July, 1998, a Snapshot (SNAP) visit was added manually to the SNAP Pool when a Program Coordinator (PC) told Science Planning and Scheduling that it was "ready for scheduling." Once a visit was placed in the SNAP pool, its scheduling priority was determined by the end of its assigned scheduling window (earlier end times had higher priority) and the Proposal/visit-id number (lower numbers had higher priority). Due to the large number of visits in the SNAP Pool, and the biases inherent in the old selection method, some proposals achieved a high percentage of completion and others languished at a low percentage. As of July, 1998, SNAPs are placed in the pool automatically, and a revised set of rules for selecting SNAPs for scheduling has been implemented. These changes should result in a more random sampling of the SNAP Pool.

2. Procedure
Once a SNAP visit status is set to "scheduling" in the planning and scheduling database by a PC, the visit is automatically a candidate in the SNAP Pool.

2.1 Assembling a SNAP Candidate List
When a flight calendar is ready for the addition of SNAPs, the calendar supervisor queries the database for a list of SNAP candidates (usually 200) from the pool of visits that have schedulability windows overlapping the flight calendar and are available for scheduling. This candidate list is constructed in three steps. First, the query assembles a list of proposals still active (i.e., that do not have a status of failed, completed, or withdrawn) in the three most recent cycles. Then, the visits are divided into two groups for each proposal: one having a visit status of ready for scheduling and the other having a status of complete or scheduled on an existing calendar. Based on these group-

1

Internal Technical Memorandum ITM-1998-02 ings, a scheduling completion percentage of a proposal is computed. Finally, six categories are constructed (two for each Cycle) based upon cycle number and completion percentage. The first category within a Cycle has a completion percentage less than a 50%; the second has a completion percentage equal to or greater than 50%. The candidates in each of these six categories are then independently randomized. The visit candidates for a flight calendar are selected from the six categories in the following order until the requested number of SNAP visits (usually 200) have been selected: 1. Cycle N proposals with a completion percentage <50%. 2. Cycle N proposals with a completion percentage 50%. 3. Cycle N1 proposals with a completion percentage <50%. 4. Cycle N1 proposals with a completion percentage 50%. 5. Cycle N2 proposals with a completion percentage <50%. 6. Cycle N2 proposals with a completion percentage 50%. Here N is the current cycle number. The situation where SNAP visits are selected from a total of three different Cycles will probably occur in the 2 to 3 month overlap of a current Cycle and the nominal start of the next Cycle when the next Cycle's proposals are being prepared for flight readiness. When the next cycle nominal start time is reached, the N2 cycle's SNAP visits will be set to "withdrawn." Consequently, the Cycle N2 categories (categories 5 and 6) are usually empty. This three-Cycle situation is necessary because there is no way to determine with a database query the location of the nominal cycle boundaries.

2.2 Adding SNAP Candidates to a Flight Calendar
The list of 200 candidates is reassembled in order of decreasing alignment time (largest to smallest), and the available gaps in a calendar are assembled in order of increasing gap size (smallest to largest). The first candidate (with the longest alignment time) is checked against the list of gaps, starting with the smallest gap, and is placed into the first gap that fits, if one is found. Then the second candidate in the list is similarly checked against the gaps and placed on the calendar if possible.This procedure is continued down through the entire list of candidates. On average, 10 visits find a place on a typical flight calendar.

3. Flight Preparation Requirements
PCs who prepare SNAPs for scheduling should select a start window corresponding to the nominal start time of the cycle they belong to and an end window corresponding to the nominal end time of the next cycle (i.e., they should get prepped for a two year period). This should minimize the amount of rework of SNAP proposals as well as the effect of the aforementioned three-cycle situation.

2