Skip to main content

Full text of "NASA Technical Reports Server (NTRS) 19950017327: A format for the interchange of scheduling models"

See other formats

N95- 23747 

A Format for the Interchange of Scheduling Models 

John P. Jaap & Elizabeth K. Davis 

National Aeronautics and Space Administration (NASA) 
Marshall Space Flight Center, AL 35812 
Phone (205) 544-2226 Fax (205) 544-5873 


Activity modeling, activity scheduling, 
model interchange, space station. 


In recent years a variety of space-activity 
schedulers have been developed within the aero- 
space community. Space-activity schedulers are 
characterized by their need to handle large num- 
bers of activities which are time-window con- 
strained and make high demands on many 
scarce resources, but are minimally constrained 
by predecessor/successor requirements or criti- 
cal paths. 

Two needs to exchange data between these 
schedulers have materialized. First, there is sig- 
nificant interest in comparing and evaluating the 
different scheduling engines to ensure that the 
best technology is applied to each scheduling 
endeavor. Second, there is a developing re- 
quirement to divide a single scheduling task 
among different sites, each using a different 
scheduler. In fact, the scheduling task for Inter- 
national Space Station Alpha (ISSA) will be dis- 
tributed between NASA centers and among the 
international partners. The format used to in- 
terchange scheduling data for ISSA will likely 
use a growth version of the format discussed in 
this paper. 

The model interchange format (or MIF, 
pronounced as one syllable) discussed in this 
paper is a robust solution to the need to inter- 
change scheduling requirements for space ac- 
tivities. It is highly extensible, human-readable, 
and can be generated or edited with common 
text editors. It also serves well the need to sup- 
port a "benchmark" data case which can be de- 
livered on any computer platform. 


The data which is interchanged via the 
model interchange format is contained in a data 
set or file. When the data is stored in a file on a 
platform which supports a file extension as part 
of the file name, the extension ".MIF" should 
be used. 

A MIF file is arranged in lines or records. 
Each record contains a single keyword and may 
contain data values. Keywords are surrounded 
by vertical bars. They are case sensitive and 
should not contain characters, such as spaces or 
commas, which might be used as input delimit- 
ers in common user interfaces. 

The information is organized as a hierarchy 
in parent, child, sibling relationships. No key- 
word can be the same as an ancestor or the sib- 
ling of an ancestor. Therefore, on any record, a 
keyword which is a child, sibling, ancestor, or 
sibling of an ancestor of the keyword of the 
previous record may be listed without ambigu- 
ity. But, while descending the hierarchy, ances- 
tral keywords can not be skipped. To obtain the 
full meaning of the data on a record, the key- 
word on the record and all keywords (records) 
in its ancestry must be considered. The order of 
the records in a file is usually significant; arbi- 
trary reordering of the information is not al- 

The file format limits the use of vertical 
bars to keywords and disallows the use of the 
backslash (\) character throughout. Identifiers 
or names cannot contain a comma, parenthesis, 
or space. The file format also specifies formats 
for the following data types: single integer, 
multiple integers including range-of-integers, 
real numbers, time expressions, date expres- 
sions, and character strings. 



At the time of this writing, over 200 key- 
words have been defined in three independent 
hierarchy structures: a data set description hier- 
archy, a mission model hierarchy, and an activ- 
ity model hierarchy. Figure 1 shows the logical 


1 — Data Set Description 

| — Mission Model 

ata Se 

^ — Steps . . . 

1 — Sub-steps . 

Activitv Model AAA 

Steps ... 

1 — Sub-steps 

Activitv Model UK 

Steps . . . 

1 — Sub-steps 

Figure 1. MIF File Organization. 

organization of the file, with hierarchies shown 
for the data set description, mission model, and 
several activity models. 

Data Set Description 

The data set description tells what is on the 
file, its source, and related data. 

Mission Model 

The mission model describes the availabili- 
ties of the resources for a particular scheduling 
task. The following items are included in the 
mission model: 

• Identifiers and descriptive data. 

• Resource availability profiles (including re- 
source envelope definitions). 

• Equipment reconfiguration data and crew re- 
location times. 

• Pre-scheduled crew timeline and duty cycle 

Activity Models 

Activity models are used to describe the 
payloads or experiments to be scheduled. Each 
payload or experiment requires one or more ac- 
tivity models; for complex payloads, an activity 
model is usually included for each functional 

An activity model is the collection of con- 
straint definitions describing a payload or ex- 
periment. Some of the constraints apply to the 
model as a whole, while others only apply to the 
model partitions, known as steps and sub-steps. 

The smallest required, fully functioning, 
clearly delineated partition of an activity model 
is called a step. The steps of an activity model 
describe most of the resource constraints of the 
model. Each activity model in a MIF file must 
have at least one step. 

The optional partition of an activity model 
which supports the execution of one or more 
steps is called a sub-step. Two classes of sub- 
steps are currently defined: crew monitoring 
sub-steps and resource carry-through sub-steps. 

An execution of an activity model is called a 
performance. The performance of an activity 
model is generally considered to consist of the 
execution of the model’s steps and sub-steps. A 
model may be performed multiple times to col- 
lect data. Each performance may contain a dif- 
ferent set of steps and sub-steps, or they may be 
arranged differently when compared to other 
performances of the same model. Step-based 
schedulers usually require that each perform- 
ance contain at least one step. 

The model/step/sub-step structure for repre- 
senting requirements was chosen because it was 
judged to be more robust than other representa- 
tions. This representation observes well the ax- 
iom that models should exhibit high fidelity and 
flexibility; high fidelity means that an observer 
can correlate the model to the actual activity; 
high flexibility means that the model can repre- 
sent the scheduling flexibility of the actual ac- 
tivity. The chosen representation also supports 
interchanges with schedulers which use models 
with requirement profiles attached directly to 
the model; in the model interchange format, a 
one- step model with requirement profiles on 
that step is used. 



Currently the Mission Planning Division at 
the Marshall Space Flight Center is the keeper 
of this format. As stated earlier, a growth ver- 
sion of this format is expected to be used for in- 
terchanging scheduling data for International 
Space Station Alpha (ISSA). The current defi- 
nition may be superseded by the ISSA defini- 
tion, and the ISSA configuration control func- 
tion may become the keeper of this format. 

Those wishing to have the format extended 
should contact the authors of this paper. 


The complete model interchange format is 
available in printed form, or electronically in 
PostScript, Bookreader, and possibly World 
View formats. Documentation can also be ac- 
cessed on the World Wide Web via Mosaic. 

Sample Data Cases 

Sample files containing the subset of the de- 
fined format currently used by Marshall Space 
Flight Center are available for several Spacelab 
missions and some ISSA data cases. 

Software Requirements 

Implemented of software which reads a 
MIF file should allow for extensions of the for- 
mat. Since at some future date new keywords 
may be defined, the software should contain 
code to ignore unrecognizable keywords. They 
must also develop mapping code to convert data 
in the MIF representation to their internal repre- 

Implemented of software which writes a 
MIF file must develop mapping code to trans- 
late their data to the MIF representation. 


Figure 2 shows part of a two-step activity 
model with variable separations and durations. 
This figure also shows a sub-step (its keyword is 
| -step | ). The sub-step could also have been 
positioned before step 1 or after step 2. Repre- 
senting the requirements as two steps and a sub- 

step is considered a high fidelity representation 
because it closely matches the usual description 
of the activity. The model has high flexibility 
because it captures the variable step separation 
and duration, and the choice of crewmembers 
for step 2. As shown, the model does not re- 

| Model | SEPAC-1 

|Comment| Beam firing (low power) 

|Partner| USA 
jstepl 1 

|description| Capacitor charge 
jscience_value| 0 
jduration| 0:15:00 
jnondepletable| POWER 
|profile| 2.750 

|sub-step| trickle 
|— step[ trickle 

|-description| capacitor trickle charge 
|-nondepletable| POWER 
|— profilel 0.128 
|step| 2 

|description| Beam Firing (level 1) 

| separation | 

|min| 0:00:00 
|max| 0:30:00 

|min| 0:10:00 
|max| 0:20:00 
jpreferred| 0:20:00 
|science_value| 4 

|type| FULLTIME 
|pick| 1 

|crewmember| PS1 
jcrewmemberj PS2 
jat_location| MODULE 

|type| FULLTIME 
jpick| 1 

jcrewmember| Commander 
|at_location| MID-DECK 
|intersected_opp| SHADOW 
|intersected_opp| K-band 
|nondepletable| POWER 
|profile| 0.500 

Figure 2. A Model with Variable Durations. 

quire that high power be available immediately 
before shadow. The sub- step would not be 
scheduled whenever the separation between 


steps 1 and 2 is zero. 

Figure 3 presents part of a one-step activity 
model with a power profile (shown in inset). 

Figure 3. A Model with a Power Profile. 

This type of model would be used in schedulers 
which use activity models with requirement pro- 
files attached directly to the model. The current 
format limits profiles to constant values, ramps, 
and step functions. 


The four significant requirements that drove 
the formulation of the model interchange format 
were that it must be universal, extensible, port- 
able, and human-readable. Since this format 
was developed chiefly for the interchange of 
data, rather than for the storage and manipula- 

tion of data within schedulers, these require- 
ments were deemed to be more important than 


A format was needed which could be used 
by all space-activity schedulers. This format 
provides for all known constraints and require- 
ments which affect the scheduling of space ac- 
tivities. The section entitled "File Contents" in 
this paper describes the current contents. 


It was necessary that the format be one 
which can evolve as new capabilities are added 
to existing schedulers and as new schedulers are 
developed. This format may be extended by 
adding to existing hierarchies; i.e., by defining 
new children or siblings at any level. Entirely 
new hierarchies may also be defined; this is 
equivalent to defining siblings of the highest 
level in the current hierarchy. 


Since currently available schedulers are on 
different platforms, a format which could be 
read or written on any platform was needed. To 
this end, the information is stored in a MIF file 
as ASCII characters only and is line- or record- 
oriented. A benefit of this characteristic is that 
the file can be edited with common text editors. 


A person can easily read a MIF file or use a 
text editor to create/edit one by virtue of the fol- 
lowing attributes: 

• The syntax is simple. There are a limited 
number of rules and special characters. 

• A cascading outline hierarchy is used. Each 
entry in the hierarchy resides on a separate 
line with no other keywords. Ancestry key- 
words are not necessarily repeated; the com- 
mon conventions for outline presentation are 

• The format is free. Virtually nothing within 
a line is positional. The user can indent as 
desired to improve readability.