Internal Technical Memorandum ITM-1998-05
The Short Term Scheduling Process in 1997
A. Patterson, M. England, D. Taylor, and G. Miller
December 2, 1998
ABSTRACT
We discuss the state of the Short Term Scheduling (STS) process in mid-1997. We identify process
steps that are time consuming or repetitive and which lead to a long or variable overall process
time. We then show where the next efforts for streamlining the STS process should be. The
improvements already made to the process since the middle of 1997 are included in the discussion.
1. Introduction
The Short-Term Scheduling (STS) process takes a list of available observations (scheduling units
[SUs] or visits), places them on a flight calendar, and then converts them into command loads
(CL). The work begins three weeks before the command loads are needed, and is routinely done in
units of a seven-day calendar beginning at 0 UT on a Monday.
We studied the STS process by accumulating data from the shift reports for the work done on 26
consecutive calendars in the middle of 1997. We identified 50 different activities which are part of
the STS process and then recorded on which of the two daily work shifts these actions occurred.
The list of the 50 activities is given in “Appendix A” on page 6. The ordering of the activities in the
list follows the sequence in which they are first executed. We identified on which shifts the specified activities occurred, not the time needed for their execution. A single execution of any activity
may be much shorter than a shift or many shifts in length, depending upon the activity.
The nature of the work planned for each of the three weeks of the process is very different. Most of
the work is complete at the end of the first week. Only minor TDRS (Tracking and Data Relay Satellite) activities occur during the second week. The significant work of the final week is to satisfy
the data communication requirements of the calendar with the TDRS contacts granted by NCC
(Network Communication Center) and with requests for extra ones as needed.
When the STS team finds problems at any step of the process, their correction frequently requires
returning to an earlier step, leading to the repetition of some or all of subsequent steps. This is
expected during the first week, but, with one exception, it is not expected in later weeks. Any of
the first week’s work that has to be repeated after the completion of the first week's activities is
classified as rework. Also, any of the second and third weeks’ activities that had to be repeated
were classified as rework. We identified sets of rework activities that occurred in the second and
third weeks, recording what rework activities were done, the reasons for the rework and on which
shifts they occurred.
1
Internal Technical Memorandum ITM-1998-05
The current process does require one set of repeated work activities when a second MS (Mission
Schedule) & CL generation is made during the third week. The Final MS and CLs produced by this
run incorporate the approved TDRS contacts which only become available at the beginning of the
third week.
2. Analysis Procedure
The data were analyzed in two ways, both for the individual activities and for particular groups of
activities. We graphed the distribution of the shift on which each activity first occurred in the work
for each flight calendar, and also the distribution of the number of shifts on which each activity
occurred. The graphs show the histogram of these two parameters produced from the 26 weeks of
the data. The graphs are not presented in this report but can be obtained as hardcopy from Alan
Patterson. Table 1 presents a summary of the data available from some of the graphs. We also produced graphs for groups of related activities. The groups chosen were Preparation, Main
Scheduling, Calendar Completion, SMS (Science Mission Specification) and MS and CL generation, Parallel processing and Final Steps. Appendix A lists the activities and shows to which group
each activity was assigned. The related set of activities concerning Parallels form a clear subgroup
within the larger Calendar Completion group. One activity, Scheduling Requirements, is not
included in any group because it covers actions falling within all of the Preparation, Main Scheduling and Calendar Completion groups. In the graphs and Table 1 the number of shifts for a
particular activity or group indicates the number of shifts on which those actions occurred.
Table 1. Number of shifts required for STS activity groups.
Group
Range (1997)
Average
(1997)
Goal
Delta
Prep
1-4
2
0
-2
Prime scheduling
3-9
6
3
-3
Calendar completion
3-8
5
3
-2
Parallels
2-6
4
1
-3
SMS/MS/CL
3-5
4
2
-2
Final
1
1
1
0
22
10
-12
Totalsa
a. The Totals of the shifts overestimate the combined shift numbers because a
shift may count work on more than one activity group
The work shifts were numbered beginning with those on the Friday preceding the official start of
calendar building. This recognizes the fact that calendar building frequently starts on the Friday
swing shift before the nominal start time on the following Monday. There are two shifts each day.
The odd numbers correspond to day shifts and the even numbers to swing shifts. The Monday day
shifts are numbers 3, 13 and 23 for weeks 1, 2 and 3 respectively. On the graphs showing the start
shifts a dashed line marks the boundaries between the weeks.
2
Internal Technical Memorandum ITM-1998-05
2.1 Preparation Group
The Preparation group shows a surprising spread in the number of shifts on which the activities
happened; from one to four shifts were needed, peaking at two shifts. The individual steps within
the Preparation group are each most likely to appear on only one shift, so none of them appear as
an intrinsically time-consuming step. That the preparation activities have been accomplished in
one shift suggests that streamlining could make this routine, and that with further automation a
total elapsed time much less than one shift should be reachable.
One step not included as a separate activity, but clearly part of the Preparation group, is the generation of the output files from the CALOPT command. They list when all the SUs will schedule
during the week. They are used to create a summary graphical output that shows all the scheduling
places, and this is a practical reference during the building process. The task of creating the
CALOPT output files is handled by multiple batch jobs run on different cpus. In 1997, the longest
running job typically took over 24 hours. Therefore, as a routine, they were initiated on the Friday
before the nominal calendar building start time so that they had the full weekend to execute to
completion by the next work shift.
The speeding up of the calendar add and CALOPT in SPSS 41.5 has reduced the execution time
of most of these batch jobs to under 1 hour. The improvements in calendar add and calendar
AUTO have allowed Main scheduling to be completed more rapidly.
2.2 Main Scheduling Group
There are three steps that are included in the Main Scheduling group: Prime Scheduling, Calendar
Auto and Supersnaps. The activities of these three steps cover from three to nine shifts. The Supersnaps activity always occurs on only one shift. The other two steps consume most of this group's
time. Calendar auto is most likely to occur on four shifts and has appeared on a maximum of six.
The number of shifts required for the Prime scheduling ranges from three to nine shifts matching
that of the group overall. Clearly, it is this group that offers the best opportunity for improving the
calendar building time. The wide spread in the number of shifts needed suggests that once solutions to the difficulties of main scheduling are found, this group should take no more than three or
four shifts.
2.3 Calendar Completion and Parallel Groups
The Calendar completion group took from three to eight shifts, most often five shifts. The wide
spread shows that the causes of the long group time do not occur every week and suggests that a
duration of three shifts should be a achievable once the difficulties that cause the long group time
have been resolved. The Parallel group took from two to six shifts, most often two shifts. The parallel activities that appear on most shifts are the addition of the parallels to the calendar and the
analysis of their scheduling.
2.4 Group for SMS, MS and CL generation.
The group for SMS, MS and CL generation shows activities appearing on three to five shifts, a
shorter range and tighter distribution than seen in previous groups. The SMS generation and
checklisting steps appear on the most shifts. Problems encountered during SMS checklisting usually need to be fixed by modifying the calendar, so the steps here overlap in time with those of the
3
Internal Technical Memorandum ITM-1998-05
preceding group. As with the calendar checklisting, the number of shifts needed for the work
depends upon the problems encountered.
2.5 Final steps.
The final steps of the processing done during the first week, sending the SARS (Schedule Add
Requests for TDRS contacts), generating the MEGG (Missions Events Graphic Generator) and
distributing the initial products, take only a few hours unless there are problems with the network
link to GSFC (Goddard Space Flight Center) or other computer hardware or software problems.
There are no indications that any of the later steps require any significant time, as these actions
rarely occur on more than a single shift.
Table 2. Reasons for Rework Activities
Reason
Number
SUs delivered late or redelivered
41
Instructions delivered late; instruction or PDB problems
16
Scheduling - removal of SUs with problems
2
Scheduling - roll and other reasons
11
Additional TDRS contacts, COMCONs etc.
WFII tapeuse overlaps
19
14
a
Software bugs
5
EPS merge SMS problems
3
EOLOAD instruction delivery
6
Procedural errors
5
MSCL - DMS merges
8
Guide Star
2
Contingency
1
Total number of rework activity sets
143
a. Changes in software have almost entirely eliminated this
problem
2.6 Rework actions.
All flight calendars in this analysis required rework activity.There was always at least one set of
rework activities not related to the need to run MS and CL generation to pick up the granted TDRS
contacts. The maximum found was nine sets of rework. There was a broad distribution in the number of shifts on which rework activities occurred. Rework appeared on anywhere from four to
twelve shifts each week, with a most probable value of ten shifts. Each rework set needed from one
to six shifts with a peak at two shifts. The amount of effort spent on the rework actions is very high
considering that only one set is expected in the third week as part of the Final MS and CL generation. Table 2 shows the causes for the rework actions that occurred and the number of instances
that each cause contributed to a rework activity.
3. Discussion.
The causes of noticeable delays for the Preparation group include late delivery of SUs and the resolution of problems found during SUSORT analysis and unscheduled SU analysis. The effect of
4
Internal Technical Memorandum ITM-1998-05
late delivery of SUs requires the repetition of some or all of the processing steps already completed. The warnings found during SUSORT analysis may require interaction with the PCT
(Program Coordinator Team) and LRPG (Long Range Plan Group) teams for their resolution. The
true schedulability of SUs initially identified as unschedulable should be easy to determine. In
principle no SUs with scheduling problems should appear in the lists of available SUs.
In the Main Scheduling group of activities the manual scheduling of the main SUs and the running
of calendar auto occupied the majority of the time in the first calendar building week. Some individual calendar auto runs can take more than four hours and the manual build process is inherently
iterative, with the number of attempts being highly dependent on the characteristics of the SUs
available. The calendar auto process also fails to handle the scheduling of linked SUs as related
events, so problems created by it have to be corrected manually. Prior to the release of SPSS build
41.5 the step of placing a single SU on the calendar could take a long time when that SU used three
instruments. This contributed to long calendar auto run times and slowed down the manual build
actions.
The manual calendar building process needs to be enhanced with methods that indicate the best
ways to schedule linked SUs. This will reduce the time spent manually juggling the SUs on the
calendar. The need for manual adjustment will also be reduced if the calendar auto can avoid the
partial scheduling of sets of linked SUs. The manual method of calendar construction can be significantly aided as well by the development of specialized tools. One tool could suggest
arrangements of SUs that maximize the number of MUST- and SHOULD-go SUs by using the
data from the CALOPT runs. The execution time for these iterative processes can be improved
with the hardware solution of faster cpus.
The effectof the late delivery of SUs invalidates many calendar auto runs and much of the manual
calendar building effort up to that point. Provided that late delivery of SUs can be prevented,
scheduling of the Mains could be completed in two or three shifts.
There have been significant changes in the process for Parallels since the time that the data for this
investigation were collected. The Parallel Analysis and Matching Parallel steps are no longer in
use. This has eliminated the need to redo any of the parallel activities. Currently the step of Asking
for Parallels has been reduced to about half a shift though this depends on the mix of parallel proposals available at run time. The time needed for the rest of the parallel activities ensure that the
total time needed is definitely more than one shift. The step of Asking for Parallels is still the most
time consuming, followed by the loading of the crafted parallels into the database. Speeding up
these steps should produce a Parallel group time of one shift or less.
For the Calendar Completion group, the activities most likely to appear on many shifts are the
addition of the calendar to the baseline, running the UPDCHK program, adding parallels, analyzing parallel scheduling, running guide star selection, checklisting the calendar and scheduling the
snapshot SUs. The step of placing the calendar on the baseline is not time consuming itself. Neither is that of running the guide star selection. Their ran, on
5
Internal Technical Memorandum ITM-1998-05
initial run can be speedily fixed before the second and therefore final run. Of the steps within the
calendar checklist, running the UPDCHK program can be very time consuming when it finds a
problem.
SMS generation typically takes one hour and the MS and CL take about three hours. These activities appear on multiple shifts because problems are identified during SMS checklisting and the
review of the PASS products. The solution of these problems means returning to a previous stage
in the process with the repetition of many of the subsequent steps. We need to remove the causes
of the errors that are found during the two checking stages. Most often it is problems found by the
SRT (SMS review tool) checker that indicate the need for reprocessing. One of the listed activities,
EPS (Solar Array Pointing) merge SMS generation, is no longer a separate step but is now incorporated into the standard SMS generation step.
4. Conclusion.
This investigation finds that the time and effort needed by the STS calendar building process can
be significantly reduced. The list below shows the areas in which major improvements in the overall STS process are clearly achievable. The items in the list are approximately in priority order.
1. Avoiding late delivery of SUs or need to redeliver them.
2. Enhancing the manual scheduling process with new tools.
3. Scheduling of linked SUs as a related group (especially by calendar auto).
4. Speeding prime scheduling (including calendar auto).
5. Reducing incidence of problems found during checklisting.
6. Avoiding late delivery of instructions or PDB changes.
7. Ensuring all SUs available will cause no problems for calendar SMS or MS.
8. Avoiding WFII tapeuse overlaps (essentially almost eliminated now).
5. Appendix A
Table 3. List of work activities used in the analysis and their group assignment.
Activity
Group
Visit Gathering
Prep
SUSORT Analysis
Prep
Scheduling requirements
Orbit file creation
Prep
CClist creation
Prep
Unscheduled SU analysis
Prep
STIS management SUs
Prep
Calendar auto
Main
Prime Scheduling
Main
Supersnaps
Main
Baseline add
Calendar
Check unscheduled
Calendar
UPDCHK
Calendar
6
Internal Technical Memorandum ITM-1998-05
Activity
Group
Attached Parallels
Calendar + Parallel
parallelsa
Calendar + Parallel
Matched
Ask For Pars (crafted parallels)
Calendar + Parallel
Load Parallels (crafted parallels)
Calendar + Parallel
Update Crafted Parallels
Calendar + Parallel
Add Crafted Parallels
Calendar + Parallel
Analysis of Crafted Parallelsa
Calendar + Parallel
Schedule Earth Calibrations
Calendar
Schedule SNAPs
Calendar
Schedule internals
Calendar
Complete calendar
Calendar
SNAP & attached parallel cleanup
Calendar
Guide Star selection
Calendar
Calendar checklist
Calendar
SMS generation
SMS, MS &CL
SMS checklist
SMS, MS &CL
SRT checker
SMS, MS &CL
Generate EPS SMS
SMS, MS &CL
SMS to PASS
SMS, MS &CL
XFER products
SMS, MS &CL
Generate POTR
SMS, MS &CL
CONFIG file creation
SMS, MS &CL
MS generation
SMS, MS &CL
CL generation
SMS, MS &CL
Review PASS products
SMS, MS &CL
SARS to UPS
Final
SARS to NCC
Final
Generate MEGG
Final
Distribute Products
Final
TDRS Shortfall resolution
Fetch 10 week ephemeris
Last week
Generate OEV files
Last week
Get GSFC files
Last week
Request more TDRS contacts
Last week
Generate OPCATs
Last week
Generate Observation Records
Last week
Generate OTR
Last week
a. Already eliminated
7