Request Generation II (ReGe II) is a PC-based prototype knowledge based system intented to assist USAF personnel in planning and scheduling satellite operations for their Mission Control Complexes (MCC). It aids MCC personnel in producing weekly Program Action Plans (PAPs) for each of the satellite vehicles an MCC is responsible for monitoring and maintaining. The PAPs are input to the Resource Control Complex (RCC) which schedules all satellite support requests for usage of the network

Greenhut, Darlene D.

English

NASA Technical Reports Server

N91-20676
Request Generation II
Mission Planning and Scheduling
Darlene D. Greenhut
IBM-FSD
685 Citadel Drive East
Suite 400
Colorado Springs, Colorado
80919
Request Generation II (ReGe II) is
a PC-based prototype knowledge
based system intended to assist
USAF personnel in planning and
scheduling satellite operations
for their Mission Control Complexes
(MCC). It aids MCC personnel in
producing weekly Program Action
Plans (PAPs) for each of the
satellite vehicles an MCC is
responsible for monitoring and
maintaining. The PAPs are input to
the Resource Control Complex (RCC)
which schedules all satellite
support requests for usage of the
network.
ReGe II is an IR&D project that
combines the concepts of two
previous projects, Request
Generation (ReGe I) and MCC
Scheduling Automation (MSA). The
aim of ReGe II is to assist USAF
personnel by evolving the task of
vehicle planning and scheduling
away from manual and repetitive
data sorting with the use of
automation with the intent of
freeing the PA up to place emphasis
on the more important aspect of the
task: understanding the changing
needs of the US owned satellites.
This is particularly important in
the current environment where
satellites are increasing in number
and complexity and staff is
frequently turning over due to job
rotation.
The future intent is to imbed this
planning and scheduling capability
within the future CCS-2000
architecture. This will provide an
automated function for populating
the network with maintenance
requests and will provide the
connectivity between the MCC
operators and the existing
configuration controlled mainframe
databases.
Satellite Support Planning Process
Monitoring the health and
performing maintenance on the US
owned satellites is a
responsibility divided among a
number of Mission Control Centers
(MCC). Within each MCC, a staff of
Planner Analysts (PAs) are
responsible for understanding the
needs of the vehicles which the MCC
controls. On a weekly basis
Program Action Plans (PAP) are
produced which detail support
requests for the network resources
needed to monitor, command and
control with each vehicle. The PA's
are guided by three objectives when
planning for vehicles:
o Requests for support
need to satisfy
vehicle requirements
documented by Tests
Operation Instructions
(TOIs), Test Operation
Orders (TOOs) and
Memograms.
o Requests for resources
should be combined where
possible to reduce the
burden on network
resources.
o Requests should be as
flexible as possible,
allowing
the largest time window
within which a support
needs to
be scheduled.
Currently the planning process
begins with the PA sitting down
with paper listings describing
vehicle events such as acquisition
of the vehicle, vehicle sun
eclipses or sun-vehicle-earth
angles.
Next, the PA reviews documents
describing the vehicle requirements
(TOIs, TOOs and memograms).
285
https://ntrs.nasa.gov/search.jsp?R=19910011363 2020-03-19T19:05:55+00:00Z
Particular attention must be paid
to requirements which may have
changedsince the last time the
PAdid planning for that specific
vehicle [Figure I].
]Vehicle I
Vehicle
Support o
o RequiremPonts
0 0
0 0
Previous Jog o _ ° ° ° IThisweek'sl
Figure 1:
PlannerAnalystTasks
The plan which the PAs develop to
satisfy the vehicle requirements is
recorded on paper and carried to a
computer terminal, the data is
entered into the system, and
transferred to the Resource Control
Center (RCC).
The RCC is responsible for
scheduling the range resources
based on the requests made by all
MCCs. Conflicts are resolved via
[MCC N - -7
MI-M-663 II MCC 2 --
MCC 7 I Ran,,
'GeneratdlSchedulel I | ResouPce
SupportllMCC I ll Scheduling
IReJl"c0.,,,ct.
Figure 2:
Current PlanningProces
phone calls to individual MCCs.
Once the range schedule is conflict
free, the schedule is published.
The MCC plans will be readjusted to
the new schedule and the next phase
of vehicle planning can begin
[Figure 2]. Until recently, PA
tasks were performed by civilians
with extended experience. These
tasks are now being transitioned to
DoD military personnel. Development
of tools which will assist in
training, performing the job and in
turnover due to rotation become
very important in this environment.
Much of the work that has been done
in this arena has focused on the
scheduling task within the RCC.
IBM's work began with research on
scheduling tools for the RCC led by
Dr. Mansur Arbabi. During that
research period, IBM won the
contract which developed the RCC
scheduling software and is
currently on contract to maintain
it.
Research done on scheduling within
the RCC branched into MCC
scheduling. A series of projects
followed, each building on the
lessons learned from the previous
IHCC N
IMCC 3
-- I PAPs R,.o,
Support _"_ S
..°,,n.
l Ir//////l _
MCCSchedulingAutomation
286
project. The three projects were:
MCC Scheduling Automation (MSA),
Request Generation (ReGe) and ReGe
II.
The MCC Scheduling Automation (MSA)
research resulted in a prototype
which simultaneously schedules all
requests for an MCC for its
resources for a specified week
[Figure 3]. MCC resources
considered by the algorithm include
personnel and equipment such as
control points, command and
telemetery CSEGS, processor loading
and mission unique equipment. This
also includes range conflict
checks. An interactive capability
allows the operator to make request
changes and re-generate the
schedule.
The MSA project was done on the
host using APL with the
anticipation of interfacing with
the configuration controlled
databases. ReGe I took the next
step in the research toward
developing MCC scheduling tools for
distributing the data and the
processing to intelligent
workstations [Figure 4].
vehicle per run [Figure 5]. With
the lessons learned on scheduling
algorithms and user interfaces
behind this research, ReGe I
focuses on another aspect of the
problem, "can the rules for
scheduling different support or
maintenance requirements be
represented in a knowledge base?"
Our early prototyping in ReGe I
indicates that the answer was
yes
KnowZeogeT] TtM
uase 0 0 E
o! IM
Vehicle 0
Support
LRequirements
_nferen(eEngine
Requests
Figure 5:
PaGeStructure
ReGe II research redefines and
[ MCC N I builds on the objectives of MSA and
[_CC 3 I ReGe II [Figure 6].
MCC 2
_Ccl I PAPs ,..,.
}C-#.E_A-_J[Schedule / _II Rs,ou,c, I MCC N
_m'X]l MCC | Scheduling I MCC3 I I
lIT_III Resources | MCC 2 --
J ." LResolve Conflict, i_ Scheduling
RequestGeneration l
•.\',,. /Schedule
Request Generation (ReGe I) is the Figure 6:
next generation MCC scheduling ReGe [[ Planning Process
tool. It is a PC based prototype
with a modular design which
generates requests for a single
287
Objectives for ReGe II included
providing a tool to generate
vehicle support requests which
would:
o provide an interface to the
planner analyst to
(a) define data to be used in the
scheduling algorithm,
(b) initiate the algorithm and
(c) modify the results of the
algorithm.
o consider constraints such as
vehicle events and MCC resources
when applying the scheduling
algorithm.
o utilize vehicle definition and
requirement definition when
applying the scheduling
algorithm.
The most challenging design issues
of this work are the structure of
the knowledge base and distribution
of the interaction between the
knowledge base and conventional
code.
Processing schedules involving
dates and numbers was found to be
best performed by conventional
code. Access to the data to be
processed and the organization of
that data was better represented at
a higher level, using expert
systems. The kind of data needed in
the processing, thus what types of
matching would be needed drove the
design of the knowledge structure
for vehicle definition, vehicle
event definition, support
requirement definition and support
requests.
The greatest challenge in
structuring the knowledge base for
ReGe II was representing the
vehicle requirements. Each
requirement definition includes:
o what event(S) drive the need
for the requirement.
o an indicator of the complexity
of scheduling a requirement.
o rules for combining
requirements together.
o which vehicles were defined as
needing the requirement.
Driving events for a requirement
would be one or a combination of
the following: date specific, time
specific, previous support(s),
vehicle event(s). Again, vehicle
events that a requirement might be
dependent on might be acquisition
or sun-vehicle-earth angles or
eclipse information.
The complexity indicator of a
support requirement must be
reflective of the types of
constraints which are on the
requirement. The more constraints,
the more difficult it is to
schedule, the higher the complexity
indicator should be. The complexity
indicator is used in determining
the order in which requests are
generated.
Rules for combining requests for
support are essential in meeting
one of the primary goals of a
planner analyst. That goal is to
reduce the load on the satellite
network resources by combining
requirements and use of resources
where possible into one request.
The algorithm employed by ReGe II
begins by processing each
requirement in priority order, for
each vehicle defined as needing
that requirement. A search or match
is then done to find all of the
events defined as triggering the
need for the requirement. Once a
requirement is determined to be
needed for the current week, a
search is then done for other
support requests that this
requirement can be combined with.
The request is then either added to
another request or generated as a
new request. Lastly, resources are
checked and if a conflict is
identified, the request is marked
as in conflict.
The user interface concepts of MSA
for graphical representation of the
vehicle events and the support
requests and an interactivity were
incorporated into ReGe II.
288
Beyond ReGe II, The next step is to
develop a prototype of the tool for
user feedback on: the HCI, the
knowledge representation and the
processing of the expert system and
conventional code. The planner
analyst needs to keep control of
essential tasks and be freed from
mundane, repetitive, data sorting
task.
Summary
The research performed by IBM in
the scheduling arena has resulted
in insight and refinements to
information representation,
information processing and operator
interaction.
IBM's research in MSA, ReGe I and
II is aimed at assisting the planner
analyst within the MCC by evolving
the task away from manual and
repetitive data sorting through
automation in order to free them up
for a more important emphasis:
understanding the changing needs of
the vehicle. In an environment
where the staff is turning over
frequently due to job rotation and
where vehicles are increasing in
number and complexity, tools which
reshape the current planner analyst
task are essential.
This research supports an approach
which distributes data between
existing configuration controlled
mainframe databases to intelligent
workstations in the MCCs which
process data conventionally for
computational operations, but
represents and accesses it through
the higher level representation
using expert systems.
Arbabi, Mansur PHI)., Garate, John
A., Kocher,Donald F., "Interactive
Realtime Scheduling and Control,"
PROCEEDINGS OF THE 1985 SIMULATION
CONFERENCE, Chicago. Ill., Jul,
1985.
IBM-FSD, "Data System Modernization
: System Scheduling," (AT-13),
document no. C27-0020-13-01, Apr.,
1980.
IBM-FSD, "Data System Modernization
: Generic Range Scheduling
Functional Analysis," (AT-13),
contact no. F04690-81-C-003, Oct.,
1982. 1980.
IBM-FSD, "Range Scheduling
AAutomation," Report no.
2G59-IRAD, 1982.
289


Request Generation 2 mission planning and scheduling

Abstract

Similar works

Full text

Available Versions

NASA Technical Reports Server