!;

I
I

I

I MARCH 1987 MDC W5108

!

= Spacestation

I

| Mission Planning System (MPS)

DevelopmentStudy

I

Final Report

I Volume II- Techmcal Report

I

I

,

I W_._ l(ll_s _'E _. M. Chewnin O

Project Manager Manager, Space Station

i Projects

I

I

I

I

PREPAREDFOR THE NATIONAL AERONAUTICSAND SPACEADMINISTRATION. GEORGEC. MARSHALL SPACE FLIGHT

CENTER. UNDER CONTRACTNO. NAS8-37275. EFFECTIVE DATE: 23 MAY 1986

MCDONNELL DOUGLASASTRONAUTICS COMPANY

HUNTSVILLE DIVISION

P.O. BOX 1181

HUNTSVILLE. AL 35807'

I
I

I

I

I

I

I

I

!

I

I

I

I

I

I

I

I

I

I

Section 1

Section 2

Section 3

Section 4

Section 5

Section 6

CONTENTS

LIST OF FIGURES

LIST OF TABLES

INTRODUCTION

1.1 Purpose

1.2 Scope

STUDY OBJECTIVES AND APPROACH

2.1 Objectives

2.2 Technical Approach

PROGRAMMATIC SUMMARY OF STUDY ACTIVITIES

AND ACCOMPLISHMENTS

TASK I - ORIENTATION

TASK 2 - REVIEW SPACELAB MISSION PLANNING PROCESS

AND SOFTWARE

5.1

5.2

5.2.1

5.2.2

5.2.3

Activities and Accomplishments

Spacelab Mission P1annlng Process

Spacelab Functional Flow

Detailed Flow Diagrams

SL MIPS Data Base

TASK 3 - DEVELOP SPACE STATION MISSION PLANNING

CONCEPT AND SOFTWARE REQUIREMENTS

6.1

6.2

6.2.1

6.2.2

6.2.2.1

6.2.2.2

6.2.2.3

6.2.2.4

6.2.3

6.2.3.1

6.2.3.2

6.2.3.3

6.2.3.4

6.2.3.5

Activities and Accomplishments

Space Station Mission Planning Concept

Introduction

Definitions, Groundrules and Assumptions

Space Station Physical Configuration

Space Station Flight Operations Scenario

Scope of Payload Mission Planning

Approach to Payload Mission Planning

SS Payload Mission Planning Process Functional

Description

Subfunction l - SS Projected Orbit Ephemeris

Subfunction 2 - Standard Orbit Opportunities

Generation

Subfunction 3 - Special Observation

Opportunities Generation

Subfunction 4 - User Requirements Definition

And Data Base (URDB) Interface

Subfunction 5 - Generate Planning Center

Integrated Requirements

Paqe

iv

iv

1-1

1-1

1-1

2-1

2-1

2-1

3-I

4-I

5-I

5-I

5-2

5-2

5-9

5-9

6-I

6-I

6-2

6-I

6-2

6-2

6-3

6-3

6-4

6-I0

6-I0

6-10

6-18

6-18

6-18

I
Section

7

6.2.3.6

6.2.3.7

6.2.3.8

6.2.3.9

6.2.3.10

6.2.3.11

6.2.3.12

6.2.3.13

6.2.3.14

6.3

TASK4-

7.1

7.2

7.3

7.3.1

7.3.1.1

7.3.1.2

7.3.1.3

7.3.1.4

7.3.1.5

7.3.2

7.3.3

7.4

7.4.1

7.4.2

7.4.3

7.4.4

7.5

7.5.1

7.5.2

7.5.3

7.5.4

7.5.5

7.5.6

7.6

7.6.1

7.6.2

7.6.3

7.6.4

7.6.5

CONTENTS (Cont'd)

Subfunction6- Integrated Assessment of

Planning Center Summary Requirements

Subfunction7- Assign User Resource

Allocation Envelopes

Subfunction8- Generate Planning Center

Gross Timeline

Subfunction9- Integrated Assessment of

Planning Center TOP's

Subfunction lO- Generate User Activity Plans

Subfunction II- Integrate User Activity Plans

Subfunction 12- Integrated Assessment of

Planning Center Activity Plans

Subfunction 13- Generate User Command Plan

Subfunction 14- Generate Integrated Payload

Data Flow Plan

SS MPS Software Requirements Summary

INVESTIGATE ARTIFICIAL INTELLIGENCE APPLICATIONS

Activities and Accomplishments

Definition Of Artificial Intelligence

Survey of AI Technology

Expert Systems

Training and Instruction

Trending and Prediction

Design and Configuration

Information and Data Interpretation

Planning and Scheduling

Natural Language Interfaces

Automatic Programming

Assumptions Prior to Candidate Evaluation

ADA Software

Specialized AI Hardware

Conventional Hardware

Candidate Evaluation Criteria

Desired Attributes of MPS Tasks

Task Domain

Task Expertise

Task Interfaces and Methods

Organizational Issues

Management Issues

Proposed Users of Task

Artificial Intelligence Techniques

Representation of Knowledge

Manipulation of Knowledge

Control Strategies

Uncertainty Management

Automatic Programming

ii

Paqe

6-18

6-18

6-34

6-34

6-34

6-34

6-43

6-34

6-45

6-48

7-I

7-I

7-I

7-I

7-I

7-3

7-3

7-3

7-4

7-4

7-4

7-4

7-5

7-5

7-5

7-5

7-5

7-5

7-7

7-8

7-8

7-9

7-10

7-10

7-12

7-13

7-14

7-15

7-15

IIIIIIIIIIIIIIIIII
I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

t

b

Section 8

Section 9

Appendix A

y--

CONTENTS (Cont'd)

7.6.6 Explanation Capability

7.6.7 Meta Knowledge

7.6.8 Natural Language Interfaces

7.6.9 Design Capture

7.7 Methodology for Candidate Implementation

7.7.1 VAX Vs. Symbollcs Architecture

7.7.2 ADA Language

7.7.3 LISP Language

7.7.3.1 Rapid Prototyplng Environment

7.7.3.2 LISP Language Advantages

7.7.3.3 Tools Available

7.7.4 PROLOG Language

7.8 Results of Evaluation

7.8.1 Benefits/Concerns

7.8.2 Methodology Summary

7.9 Conclusions and Recommendations

7.9.1 AI Technology

7.9.2 Hardware/Software Architecture

7.9.3 Software Tools

TASK 5 - SOFTWARE DEVELOPMENT PLAN

CONCLUSIONS AND RECOMMENDATIONS

SPACELAB MIPS DATA BASE

iii

Paqe

7-16

7-16

7-17

7-17

7-17

7-17

7-19

7-20

7-20

7-21

7-21

7-21

7-22

7-22

7-25

7-25

7-25

7-25

7-25

8-I

9-I

A-l

I
Number

2.2-]

3-1

5.2.1-1

5.2.2-1

6.2.2-1

6.2.2-2

6.2.2-3

6.2.3-I

6.3-Ia

6.3.1b

7.1-I

7.5-I

7.6-I

7.7-I

Number

5.2.1-1

5.1.1-2

6.3-I

6.3-2

FIGURES

SS MPS Development Study Task Flow

SS MPS Development Study Schedule

Spacelab Funcional Flow

Spacelab Flow Diagram Conventions

Discipline Centers Integration

Element Centers Prime Integration/Discipline

Centers Indirect

Dlscipline Centers Plus Element Centers

Integration

Space Station (SS) Payload Mission Planning

System (MPS) Top Level Funct|onal Flow

SS MPS SW Hierarchy

SS MPS SW Hierarchy

Task 4 Flow Chart

Attributes of MPS Tasks

AI Techniques for MPS Tasks

AI Methodology for MPS Tasks

TABLES

Spacelab Functional Flow Activity Groupings

Acronyms and Abbrevations

SS MPS Software Sets

SS MPS Software Requirements Summary

iv

Page

2-2

3-2

5-3

5-11

6-7

6-8

6-9

6-11

6-49

6-50

7-2

7-6

7-11

7-18

5-4

5-7

6-51

6-52

I

I

I

i

I

I

I

I

1

I

I

I

I

i

I

I

I

I
I

I

I

t

i

1

I

I

i

i

!

I

I

I

I

i

I

I

Sectlon 1

INTRODUCTION

l.l PURPOSE

The purpose of this volume is to provide a detailed description

of the results of the Space Station (SS) Mission Plann|ng System (MPS)

Development Study.

1.2 SCOPE

Thls volume includes a description of the overall Study

objectives and approach In Section 2, a programmatic summary of Study

activities and accompllshments in Section 3, a detailed presentation of

Indlvldual task activities, methods and accomplishments in Sections 4 through

8, and a presentation of Study conclusions and recommendatlons in Section 9.

Major products of the Study are contained In this volume and In Volume III, SS

MPS Software Development Plan.

l-l

I
THIS PAGE INTENTIONALLY

LEFT BLANK

I-2

I

i

I

I

i

I

I

I

I

I

I

I

I

I

I

i

i

I

I
I

I

I

i

i

I

I

I

I

I

I

I

I

I

I

I

I

I

Section 2

STUDY OBJECTIVES AND APPROACH

2.] OBJECTIVES

The basic objective of the SS MPS Development Study was to

define a base|Ine Space Station mission planning concept and the associated

hardware and software requirements for the system. Specific objectives in

support of the basic objective were the following:

a. Develop a mlssion plannlng concept which is consistent with

the overall Space Statlon operations phllosophy.

b. Define and assess the capab111ty of the Spacelab mission

planning system software for use in Space Station mission plannlng consistent

with the concept developed under objectlve a.

c. Determine and recommend where Artificial Intelllgence (AI)

concepts and techniques can be effectively ut111zed for Space Station mission

planning. AI areas to be investigated for application to the speclflc

requirements of mlsslon planning include natural language interfaces, expert

systems, and automatlc programming.

d. Construct a software development plan for a phased

development of a Space Station mission plannlng system. The plan shall

consider the modlflcatlons identified In Objective b, and the implementation

of any AI concepts recommended in Objectlve c. The plan shall Include a

schedule and a manpower estimate.

2.2 TECHNICAL APPROACH

The SS MPS Development Study included the following tasks to

accomplish the study objectives"

Task I

Task 2

Task 3

Task 4

Task 5

Orientatlon

Revlew Spacelab Mlssion Planning

Process and Software

Space Station Mission Planning

Software Requirements

Investigate Artificial Intelligence

Applicatlons to Mission Planning

Mission P1annlng Software Development Plan

The flow of these tasks is reflected in Figure 2.2-I.

Task l was intended for the study team to obtain an initial

familiarization with the process and existing software used for Spacelab

payload mission planning at MSFC and to travel to other NASA centers to obtain

a general familiarization with the processes and software in use for mission

planning at those centers.

2-]

I
e4

ZoZw0

III

2-2
I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

The objective of Task 2 was to establlsh a complete baseline

definltlon of the Spacelab payload mission planning process, along with a

deflnltion of existing software capabilities for potentlal extrapolatlon to

the Space Station era. Areas to be included were orbital mechanics analysis

and planning, mission tlmellne generation, data flow analysis and planning,

onboard computer timellnes generation and implementation, experiments command

planning and implementation, and planning for Payload Operations Control

Center (POCC) support. Pre-flight planning and real-time planning and

replanning activities were also to be defined. The process definition was

required to be defined using detailed functional flow diagrams, and

indlvldual software module functions were to be defined.

Task 3 was to use the Informatlon developed in Task 2 for the

Spacelab payload mission planning process and software as the basis for

defining system requirements to support Space Station mission plannlng. The

system was required to Include the capabllity to permlt the mission planning

function to be centrallzed or distributed, and to be performed by non-expert

mission planners as well as experts. The role of mission planning onboard the

Space Statlon and the Interfaces with the ground were required to be assessed.

Inltlally, flve Space Station mission planning concepts were identified for

assessment; these ranged from all misslon planning done on the ground to all

mission plannlng done on-board the Space Station. Subsequent MSFC guidance

narrowed the possible concepts to one in whlch mission planning was to be

done on the ground with minor real-time replanning capability to be provided

on-board. Comparable to the Spacelab process, detailed flow diagrams of the

Space Station mission planning concept were to be developed, including the

flow of plannlng data. Also, software functions were to be identifled, and

modifications/additlons to the Spacelab payload mission planning system

software to support the Space Station mlssion plannlng concept were to be

defined.

In Task 4, the Space Station mission plannlng concept (developed

in Task 3) was to be reviewed for the purpose of identifying areas where

Artificial Intelligence (AI) concepts might offer substantially improved

capability. Three specific AI concepts were to be investigated for

appllcability: natural language interfaces, expert systems, and automatic

programming. The advantages and disadvantages of interfacing an AI language

with existing FORTRAN programs or of convertlng totally to a new programming

language were to be identified.

2-3

I
Task 5 was intended to integrate the outputs of Task 3 and 4 to

produce the primary product of the Study, a Space Station mission planning

system software development plan. The plan was required to include"

• A detailed description of modifications and additions to

the Spacelab mission planning system which are required in order to make this

system suitable for use in Space Station mission planning.

• Recommendations on the use of AI as means of improving

the overall mission planning process, including identification of specific

areas where AI may be beneficial.

• A development schedule compatible with the overall Space

Station schedules, and the manpower required.

The development plan was also required to include a description

of the Space Station mission planning concept, a review of the functions to be

performed, and a description of the modules required for each function.

Module development standards, such as language used for coding, were also

required to be defined.

I

I

I

I

I

I

I

2-4
I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

Section 3

PROGRAMMATIC SUMMARY OF STUDY ACTIVITIES AND ACCOMPLISHMENTS

The SS MPS Development Study, as depicted in Figure 3-I, was

orlglnaIIy Intended to be an eight-month Study: however, six (6) months into

the Study, the overall schedule was extended two (2) months to accommodate the

longer (than orlglnally anticipated) time to complete Task 2. Also, the

extension provided the opportunity to support MSFC inputs to the NASA Space

Station Operations Task Force and to incorporate appropriate Task Force

concepts and concluslons Into the Study.

An interim review of Study activities and accomplishments,

o_IglnaI1y planned for approximately four (4) months Into the Study, was

waived by MSFC |n favor of weekly progress meetings. However, a formal

presentation of the Spacelab payload mission planning process functlonal flow

diagrams was made on 20 October 1986. Monthly progress reports were prepared

and submitted as required and a final review of the Study was presented as

required on 4 March 1987.

Study activities concluded with the submlttal of a flnal report

(of whlch this volume is a part) and a SS MPS Software Development Plan on

20 March 1987.

3-I

I
-.J

r-_

rl_Z

Ill

1J

r_

r_

_0!

r_

3-2
I

I

I

I

I

I

I

I

I

I

I

I

I

l

I

I

I

I

Section 4

TASK 1 - ORIENTATION

Task I activities first included orientation meetings with MSFC

from 30 May 1986 through early June 1988. These orientation meetings

primarily consisted of MSFC briefings and demonstrations of the Spacelab

payload mission planning process and software and a tour of the MSFC Payload

Operations Control Center (POCC). The knowledge gained from these meetings,

plus handout materials and reference documents, equipped the Study team to

commence its activities on Task 2. Of no less significance, these meetings

permitted the establishment of working relationships with MSFC mission

planning personnel whose inputs to all subsequent Study tasks were invaluable.

Task 1 actlvities also included MSFC briefings on 9 July 1986.

These brleflngs provided the study team MSFC concepts and considerations as

inputs to development of the Space Statlon mission plannlng concept in Task 3.

Final Task 1 actlvitles consisted of travel to other NASA

centers to Investlgate mlsslon planning methods and tools (including AI

appllcatlons) in use or under development at those centers, especially

methods/tools orlented toward Space Station. On 13-15 August 1986, a trip to

Johnson Space Center was accomplished. Subsequently, on 30 September through

2 October 1986, a trip to Ames Research Center and the Jet Propulsion

Laboratory was accomplished. Appropriate reference documents and key contacts

on the Space Station Program were obtained at JSC as subsequent reference

sources for Task 3. Both trips provided information and contacts on

potentially applicable AI concepts and technologies for Task 4.

4-I

I
THIS PAGE INTENTIONALLY

LEFT BLANK

4-2

IIIIIIIIIIIIIIIIIII
I

I

I

I

I

I

I.

I

I

I

I

I

I

I

I

I

I

I

Section S

TASK 2 - REVIEW SPACELAB MISSION PLANNING PROCESS AND SOFTWARE

5.1 ACTIVITIES AND ACCOMPLISHMENTS

As previously stated, the purpose of Task 2 was to review the

current Spacelab (SL) payload mission planning process and software and to

develop a complete definition and understandlng of the process and Mission

Integration Planning (software) System (MIPS). The approach taken to this

task was first to develop an upper level Spacelab functional flow diagram,

then to group the major activities from the overall diagram Into major

functional areas of activity (which tended to correspond to MSFC mission

planning organizational elements), and, finally, for each functional area, to

develop detailed flows to a level sufficient to acquire a thorough

understanding of the mission planning activities and to be able to correlate

the capability of a SL MIPS software module to the objective of a specific

activity. Based on knowledge gained, a data base of mission planning

activities, activity descriptions, and resource data was also developed.

The major inputs to the task were MSFC brieflngs, demonstrations

and handout materlals, Spacelab mission plannlng process and software

documentation, and personal interviews wlth Spacelab mission planning

personnel. By far the most valuable of these inputs were the

interviews/working sessions with misslon plannlng personnel for development of

the upper level functional flow and detailed flows. Mlssion planning

personnel also made certain Inputs to the data base which could only be

provided by people who were experienced In the SL mission planning process.

The support of these NASA personnel was essentlal in accomplishing this task.

The major products of this task were the Spacelab mission

planning process functional flow diagrams and data base. These products, and

the knowledge gained from their development, served as a significant input to

Task 3, because they identified not only the SL Payload MIPS software modules

of potential applicability to Space Station, but also a detailed

understanding of the scope, nature, and sequence of activit|es and

inputs/outputs that are required for the planning of payload on-orbit

operations in general.

Finally, this task revealed certain characteristics and lessons

learned from Spacelab payload mission planning that served as important

considerations in the establishment of the fundamental objectives and

approach toward Space Station mission planning in Task 3. These

characteristics and lessons learned are presented below:

• Spacelab mission planning activities are centralized.

Payload activities are scheduled down to the minute to

make maximum utilization of resources during a

short-duration mission.

The collection of principal investigator experiment

operations requirements is a very sizable manual effort

which continues through all planning cycles.

5-I

I
Spacelab mission plannlng employs a system of 58

actively used computer programs which have evolved over

a ten-year period without the benefit of a rigidly

controlled, structured process of development.

(Upgrading of capabilities is still underway.)

Though employing computer software, the Spacelab mission

planning process involves considerable manual effort of

hlghly skilled personnel.

User-frlendly interactive and automated software is

considered of key importance to reduclng mission

planning manpower requirements.

5.2 SPACELAB MISSION PLANNING PROCESS

This subsection contains and provides introductory explanations

of the Spacelab mission planning process functional flow diagrams and data

base produced by Task 2 of the SS MPS Development Study. Together, the flow

diagrams and data base constitute a complete and thorough definition of the

sequence and nature of Spacelab mission planning process activlties, and the

associated Spacelab MIPS software capabilities and resource requirements.

5.2.l Spacelab Functional Flow

The Spacelab Functional Flow dlagram, presented in Figure

5.2.1-I, was developed in order to identify all major activities of the

Spacelab payload mission planning process. The diagram shows interfaces

required by the planning center (MSFC) with the principal Investigators (PI's)

and with the STS center (JSC). The PI interfaces are indicated at the top of

the diagram and STS center interfaces are shown at the bottom of the diagram.

The Spacelab Functional Flow diagram includes activities ranging

from payload data collection, through the required analyses, to preparation of

payload mission execution documentation. The activities for three (3)

planning cycles (preliminary, basic, update) are encompassed by the flow

except where noted by the diagram legend. Real-time replanning activities are

also encompassed by the flow. All activities may not be performed, or may be

significantly reduced in a planning cycle based on the changes/updates

required from a previous cycle. The Flow accommodates a multidiscipline

payload complement but includes a unique path for a payload complement of

co-aligned IPS-mounted stellar observation experiments.

The SL mission planning process activities shown in the Spacelab

Functional Flow diagram are grouped into nine (9) major Functions. These

functions and the subfunctions which comprise each are identified in Table

5.2.1-I.

Table 5.2.1-2 is a listing of acronyms and abbreviations used in

the Spacelab Functional Flow diagram, and subsequently in the detailed flow

diagrams and data base.

5-2

I

I

I

I

I

I

I

I

I

I

I

I

!

I

I

I

I

I
• . !_LI

I

(J

4...........] ......................._.................',,i,:...........................',-

S31VOdn

,,,..

.,.,,.

..,,.

... ,.i

..,,.

.. ,,..

_-d d _

• _)u .)

m

01-

0

m
,!l

I!

,IIiI

II

!,

i,iIi!I

Iii

I

I!!

II!I

I i"

....

)I

I

IIIi!IIIIIIi

I
I

I

I

!

I

I

I

i

I

I

I

I

I

I

I

I

I

i

TABLE 5.2.1-I

SPACELAB FUNCTIONAL FLOW ACTIVITY GROUPINGS

FUNCTION

Payload Data Collection

Orbit Analysis

Mission Timeline Analysis

SUBFUNCTIONS

N/A

Orbit Requirements Evaluation and

Selection

Launch Window/Launch Time

Selection

State Vector Generation/Ephemeris

Data Development

Experiment Opportunities

Generation

Mission Profile Generation

Dedicated Stellar Observation

Generation

Attitude/Maneuver Tlmeline

Generation (Mu|tldisclpline)

Attitude/Maneuver TImellne

Generation (Dedicated Stellar)

Orbiter Pointing Data Generation

TDRS Acquisition/Loss Generation

POCC MMU Data Set Generation

Objective Loads Generation

Joint Operations Target File

Generation (Dedicated Stellar)

Create Mission Timeline Models

Generate Crew Handover Cycle

Create ESS Target File

Mission Timeline Generation

Payload Crew Activity Plan

Development

5-4

i
TABLE 5.2.1-I

SPACELAB FUNCTIONAL FLOW ACTIVITY GROUPINGS (CONT'D)

FUNCTION

Flight Definition

Document Development

Flight Planning Annex

Input Development

Crew Procedures

Development

Data Flow Analysis

MMU Load Input

Development

SUBFUNCTIONS

N/A

N/A

* Develop Stowage Book

* Develop TV, Photo Procedures

* Develop Experiment Crew procedures

* Develop Payload Systems Handbook

* Develop CDMS Dictionary

* Build PFDF Documents

Create Data Flow Models

Generate Mission Data

Requirements Profile

Schedule Onboard Data Management

and Downlink

Schedule POCC Data

Capture/Management/Distribution

Verification of Data Flow Schedules

Data Flow and System

Configuration Document Development

Update or Enhance Existing Schedules

* Create ECOS Subordinate Timelines

* Create ECOS Master Timeline

* Build ECOS Timeline Tape

* MMU Optimization

These subfunctions do not appear in the upper level functional flow but are

defined in the detailed flow diagrams

5-5

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I
I

I

I

I

!

I

I

i

I

i

I

I

I

I

I

I

I

I

I

TABLE 5.2.1-1

SPACELAB FUNCTIONAL FLOW ACTIVITY GROUPINGS (CONT'D)

FUNCTION

Experiment Command

Planning Development

SUBFUNCTIONS

* Generate Command L|st

* Check Command Syntax

* Produce Command T1metags

* Generate Command T1mellne

* Create POCC Checkllst

* Check Activity Syntax

* Produce Activlty Tlmetags

* Generate POCC Checklist

and Command T1mellne

These subfunctions do not appear in the upper level functional flow but are

defined in the detailed flow diagrams

5-6
ACT/DEACT

ASCII

AT PHY

CAP

CDMS

CEL

CMNDS

COO

DDU

DEFN

DEP

DFA

DS

EBCDC

ECAS

ECOS

ERD

EDT

ESS

FDD

FO's

FPA

H/O

HDRR

HEX

HRM

IPRD

IPS

IWG

JSC

LDF

MDP'S

MGMT,MANGMT

MMU

MMUM

MPE

MSFC

MSN

MSNIND

MTL

MVR

NDF

O&IA

0/0

OCCULT

OPS

PAO

PCAP

TABLE5.2.1-2

ACRONYMS AND ABBREVATIONS

- Actlvatlon/Deacti vation (Spacelab) - American Standard Code For Information Interchange - Atmospheric Physics - Crew Activity Plan - Command and Data Management Subsystem (Spacelab) - Celestlal - Commands - Coobservation (File) - Data Display Unlt (Spacelab) - Definition - Dedicated Experiment Processor - Data Flow Analyst - Dedicated Stellar (Mission) - Extended Binary Coded Decimal - Experiment Computer Appllcations Software (Spacelab) - Experiment Computer Operating System (Spacelab) - Experiment Requirements Document - VAX Editor - Experiment Schedullng System - Flight Definition Document - Functional Objectives (Experiments) - Flight Planning Annex - Handover (Crew Handover Cycle) - High Data Rate Recorder (Spacelab) - Hexidecimal - High Rate Multiplexer (Spacelab) - Integrated Payload Requirements Document - Instrument Pointing Subsystem (Spacelab) - Investigators Working Group - Johnson Space Center - List Directed File - Mission Dependent Parameters - Management - Mass Memory Unit - Mass Memory Unit Manager - Mission Peculiar Equipment - Marshall Space Flight Center - Mi ssion - Mission Independent - Master Timellne - Maneuver - Name Directed File - Operations and Integration Agreements - On/Off (File) - Occultation (Orbiter) - Operations - Public Affairs Office - Payload Crew Activity Plan

5-7

IIIIII!iIiIiIIIIIII
I

I

I

I

I

I

I

I

I

PFDF

PI

PL PHY

PL, PIL

POCC

POH

PTS

SAA

SCAS

SCOS

SL

SOPG

SPAH

STL

STO

STS

T/L, TL

TDRS

VAX

m

E

w

m

m

i

a

m

TABLE 5.1.1-2

ACRONYMS AND ABBREVATIONS

Payload Flight Data File

Principal Invest|gator

Plasma Physics

Payload

Payload Operations Control Center

Payload Operations Handbook

Payload Timellne Summary

South Atlantlc Anomaly

Subsystem Computer Appl|cat|ons Software (Spacelab)

Subsystem Computer Operat|ng System (Spacelab)

Spacelab

Science Operations P1ann|ng Group

Spacelab Payload Accommodatlons Handbook

Subordinate Timeline

Storage (File)

Space Transportat|on System

Timeline

Tracking and Data Relay Satellite

D|gital Equipment Corporat|on Computer

I

I

I

I

I

I

I

I

I 5-8

I
5.2.2 Detailed Flow Diagrams

The SL mission planning process detailed flows provide, as

necessary, a breakdown of functions and/or subfunctions to a task/subtask

level necessary to understand the mission planning activities, or to a level

to correlate a particular software module to an activity. For example,

"Payload Data Collection", which is a manual activity, is detailed at the

function level, whereas the Orbital Analysis subfunction "Experiment

Opportunities Generation" is broken down to tasks and subtasks - e.g.,

"Generate Solar Targets" (task) and "Generate Sun Rise/Set" (subtask).

Activities may be manual, automated, or a combination of manual

and automated. Manual activities normally include the collection of

information (verbal Inputs, Informal or formal documentation), the evaluation

and assessment of this information, and the publlcatlon of the results

(informal or formal documentation). However, some manual activities produce a

computerized input for a subsequent activity - e.g., use of the VAX editor to

create a computerized file for use by a software module in a subsequent

automated activity.

Automated activities include a software module, based on some

fixed algorithm, which reads a computerized input file(s) (fixed format),

performs specific operations on the input data, and then outputs the results

as either a computerized output File(s) or as a printout. Some automated

activities require, or permit, manual inputs to the software module via a

keyboard.

A legend for the detailed flows is presented in Figure 5.2.2-I

which shows the conventions utilized in their development. The set of flows

which represent the breakdown of the upper level Spacelab Functional Flow

diagram to lower level detailed flows (subfunctlons, tasks, subtasks) is

presented on page 5-12 through page 5-59.

5.2.3 SL MIPS Data Base

The SL MIPS data base was developed in order to provide activity

summary data, software description and requirements data, and activity time

and skill requirements data. The level of detail of the data base is

consistent with the level of detail in the Spacelab mission planning process

detailed flow diagrams; that is, entries exist in the data base corresponding

to each lowest hierarchical level activity (function, subfunction, task or

subtask) identified for every function in the flow diagrams. When assessed in

conjunction with the detailed flows, the data base provides a comprehensive

definition of the Spacelab payload mission planning process.

5-9

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I
I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

The data base consists of eight (8) interrelated tables of data:

0

0

0

0

0

0

0

0

Activity Summary Data

Activity Time and Skill Requirements

Software Used by Activity

Software Description

SoFtware Peripherals Required

Activity Input/Outputs

Computer Input/Output Summary

Manual Input/Output Summary

The complete data base, including an introductory explanation of

each table, is contained in Appendix A of this volume.

5-10
_ PAYLOAD DATA /

COLLECTION

MANUAL TASKS

AUTOMATED TASKS

I

I

I

I

I

|CONSTRA,NTSj

PRINTOUTS OF I

HSN IND DATA I

,_ READ BY

',,PCAP PROGRkl"

FIGURE 5.2.2-I.

EXECUTABLE SOFT'HARE HODULE (NAME) USED BY TASK

COMPUTERIZED INPUTS/OUTPUTS (FILE NAME)

FILE TYPE _ E.G., 0,"0

MANUAL INPUTS BY USERS

PAPER INPUTS/OUTPUTS - FORMAL OR INFORHAL DOCUMENTATION

COMPUTER PRINTOUTS, ETC.

DECISION GATE

CHOICE GATE

ADDITIONAL EXPLANATIONil NFORMATION

SPACELAB FLOW DIAGRAM CONVENTIONS

5-11

I

1

I

I

i

I

I

I

I

I

I

I

I

I
I

I

I

T ,,,,J Z

I

• dl '. _ _1 Z: Z

0

,' T _ " /-i

¢_)

REQMT UPDATES _ .,_ >

! I_1 _ -_ I °

I ,"I_lF_:;----- . ooL_ " °__""°' _ i ,_, , ..,.., , " "

¢ | --I _ I IIJJ

_c : I _1 i I I---_i 7'-, : '

l I- _ ._i : l u) \ i I ! :

........................-\ _

-U _"%_*a _"

Z

I 5-12
Z0i

I--

L,J

ILl

--I

I.I=I

g') Z

.<Z

(Dm

I--

.<

.=I

.<

>.

I.I.I

(/)

l-- Z

I=I=I

S"

(/)ILl m

m

-_,,,

Z_

-<_

--1 "--

--0

f'_ 0°

O0

m

--Z

_.lu.

5-13I
I

I

I_Z_l i:_l

I_.<zl

I I.jT__ I I_!

I_\

I _o= I_=_._

I __=o _

>__

I _)

I _ _ _

I -_ °_ _ _ " _° _

Ii S _8 __ oB_l ==

U. tJ) o.

il ' '

I 5-14
Z

I11 0

UJ

>.

UJ

t--

</> m

ELI E

_J

2:

Q,

I11 Z0D

ELI Z

LU

L_

m

..JU

Z>

..j_-

i.,_ I..-

,.-(_

_Z

O0

--Z

UIJ.

Z_

IIIII

_@,!

5-15I
IIIIIIIi!I

=

I

£

I_

I_<,,,

Z_-

I--X

ml.IJ

i nn .. i -_

UuZa3

I

!

Ib

w

!

a

L$,

!! L

li

_1

_ii: ."I

e! '"' ,L._I _ I [e_J _ i i I

i

°°1

5-16
5-17

:> ::3 ,< LIJI ,,,,,,,,

I

I,.,I,.(,_ I.-"

5-19
i u_ ¢,,_ I-. I 5-20
5-21 1
i 5-22
5-23 I
I I--:_ U_L_V ,. I U. _) _-- I 5-24
5-25 I
I

_ | :_

I

_-...........J

I

5-26
Z0

I==

-,C

Lla Z

IJJ Z0m

IJJ

(/) 0K

..J

OOuj

OOP-

>.(/)

KuJ

Z_-

KK

_Z

O0 0

U

--Z

Uu_

Z_

I

0 '

5-27
II 5-28
.<

-,.I

,..I

ILl

I--

I,--

.<m

LLI Z0m

I-,

.<

e,,t,,,

ILl Z

LLI

l.IJ Zmi

I.I.I

,j..- m

I,,--

I.I.I

>.

I.I.I

o')z

m

<,,o ,,<

_,,j-

...I "_. Z e--,

I,-

,,--,I --

.<_..

i,_. i.-.-

_.<

_Z

O0

m

O_

-.Z

LJ I.L.

7_

LJ. ¢0_

.+.-_+

I

+II

5-29
IIIII'!I z,,' .<uJ!--

--0

I ,,,z O0 I oU-.Z

Z_ | ==u. td) I 5-30
Z0m

I-'-

_cZ

ELI

(.0

t,O t,_ -.(_

_C)

>-.-I

_oZ

U

.<.<

.< e.,,

I.-C_

--I--

_'Z

O0

u

0U

--Z

Z,._

u_cO

III!I

"_I

=o I

5-31

III
I

I

I

I

I

I

R

I _ I_ I

I_ I

I _ _oo

O

1

1 o_--Z

(.; 1.1.

1 z©

I

5-32
5-33

t

IIII
Ii

5-34
(n

lJJ 0

ILl

mi

(._ ..J

>- UJ

._:E

<,--

Z_--

_Z

_jQ

m

Z_

..j(n w

E

E

-- Lid

P- pZ_

Q-J

(v_ ,,

--Z• i ilmm

ZFQU

--ZU u.

Z_

IIIIIIIII

+.-+ +_ i _

II

_ _+_[-

-

dk +,g

I

Z

0 (.lit,,I

,,.._I

,__ _) _. z_

X_I ='_-_

_1: (/)0f

0._-0I

(1) (/) ,_/

" II

5-35
IIIII

--)- I _

.<_

IO1 _ L_

w_

II

I _±_O II

Z_ I d

3 IIII 5-36

y]
t.t) TM

=..I m

¢J)IJ.

>..

..ji--

._,,, Z

_

.<

l.IJ l=-

Z</) ibm

.-I_)

IJJ l.iJ

s"uj

lime

I-- I""

Zw

Or-,, ii

iaiam i

--Z

mVl

Z n,'_i

°I

5-37
°,

IIII

I iF

5-38
X " u"r_ "_0

m _

Z

L,J /.-- ,^ i.U zb., _zl

,.- =- 1 ;_ _:

I,l.I l

'< '_' Z ,-_._ _ .v, I _ _ _(5 ,"_._ _-._ , <v /_i J _+_ _ ....+---"

-_ ,_, _ _, ,x_ •

_'= __ _++1 I_1 _ °" i

_.l _ £ z_ so_ _ I_ I I_ _,_

--= +L_ <._L I

I,l,l I-" _ '-" _ __ _ -, .... .__.__! _ o_

,__ _-_ (n_.,z

o^ %'=" LLI "--"b ._.'_ m

_z

,,. t.J_ 0_-.

.1-o)

(.) _..

.<

_ °°ZZ

,.,. +

w<""" I

_1 II_+__I

,++-.+, ..+.++

I "_ o "¢ i_ I

1:3 _ ty I ,r,. _ I--

I m ("__('_ l _ 0ZZ t,,J

! O_ -c_ I _)

5-39 I
i 5-40
III >= " I _ "° I < !

___° I

_S_I

__I

'

__ I

_._,__

_ III

5-41 I
IIII 5-42
i==ZO

.=J

>.

L_J

C)

I-- Z

Id.i

s- o

C) ZOm

l.- mZi

Id..

Idd

-'ri

...J iJ=

C) m

I.=UZ

Cw' 0

IIII

..J -- ¢=_ "_o

I

,---! III

Z ,.=,,

__,, | __I Z

_I " _

_I

___iI

----45---"I

"'"--I

_,,. -_ ::'i

•.cz_I

,-,__--]

i

__I

_r__zj

III

5-43

I
IIII| _-

_

l_ 12_t

Ii __ i i i __ i <, iI s _) I

LL !

_l:

_!

18S

IiiI 5-44
5-45

I
.,J

:>.-

z::

r,,.

c, wo

c,,,.

it,,.

!,,,-. 0Z

III 5-46
5-47 I
I

I

!

I il

I_-I

z I_ /

! 5

0

I

I

I _

i ,.<_ Z_u

O_

..j W.l

_, Z

! "'

.<z

| ,',o

--Z

UI,

Z_

...............................

I_ (s) I

z__l

•-r o') ,,v I

I 5-48
5-49 I
I 5-50
--- I.I.

..jZ

.<0

I

I

5-51
I

I

> _

_j,

U

0

|. =

Z

6

! ._< .Oooo. i

I _ _ _

| <z _O

m

| ou--Z

| z=

LI. _,0

p-a.

.cx

¢.j u.i

I 5-52
..J

"rU0Z

mmm

H- mX

LQU

ooZ

Z

.(uJ

Z_

KO

0.< .-1

i.i ¢"_

e_

-<Z

_0O

U

--Z

U_.I.

Z_

L._ (,0

III!

@,

T'II!!

I

III

_-_
&m

F,-

=

=

Z

i

m

w_
¢,¢

ILl Zm

,-,,I

.,j... m

I,-.

ILl

I-- i....

z..<

,s...Zi

C_.. ,""'

Oev

-aO

tH_

e_

O0

_-0

_U

Zuj

-,_ ,,, •-1 U _ ,,

r.z

0

Z_

0U

--Z

Uu.

Z_

IIII

I° 'I • !II!I!

.....i

i

I'!

5-55 I
I

'

!

I

_ ___

G'-:

#

e_

_N

wllg

Zw

L_ __

E_

I ss ..........

! _..

I _= ]

I

5-56
I-,,

W

za.

w<

0.

0_

._Z

w";

>w

w£: C:--.

)... F--

a.o

zu

mi,aJ

Ot'_

<..Jm

0_

Z:Za i iim

Zu

OZ mZ

_

5-57

III,

-!I!

"I I

o=> ia_ i! h- _" u.- o__ _.,.e.,... i

|

&

III
i T II > I _-
F--

Z

L_J

0

I.U

>

i!1

Z

il

Z

Z

.<

O.

Z

2::

2::

I--

Z

I.u

2::

C2.

X

e •

Z

0

I-.

U

Z
I

I

I

I

I

I

I

I

I

I

I

i

I

I

I

I

I

I

Section 6

TASK 3 - DEVELOP SPACE STATION MISSION PLANNING

CONCEPT AND SOFTWARE REQUIREMENTS

6.1 ACTIVITIES AND ACCOMPLISHMENTS

As indicated previously, the objective of this task was to

develop a payload mission planning concept consistent with the overall Space

Station operations philosophy and to define a system of software requirements

maximizing use of SL MIPS software modules (modified as necessary) to

implement the concept.

The approach taken to thls task consisted of four subtasks.

First, basic definitions, groundrules, and assumptions were established; these

pertained to the current Space Station design and operations concepts and

philosophies, the scope of mission planning for Space Station,

objectives/requirements to be achieved/satisfied by the approach to mission

planning, the structure of organizations/personnel involved in mission

planning, the number, purpose, and nature of planning cycles for Space

Station, and the degree of allocation of mission planning functions between

ground-based organizations and the on-board crew. The second subtask involved

the construction of a set of functional flow diagrams defining the Space

Station payload mission planning concept to a level of detail equivalent to

the Spacelab functional flow diagrams. The third subtask then involved the

identification of modified SL MIPS software modules or new computer programs

to automate individual mission planning activities identified in the flow

diagrams. The fourth an_ final subtask involved the summarization and

systemization into a hierarchical structure of the new or modified SL MIPS

software programs as the basis for preparation of a software development plan

in Task 5.

Inputs to this study task were derived from a variety of sources"

- Space Station Program reference documents

Space Station plans, study reports, white papers,

briefings, meeting minutes, etc., published by NASA

organizations, contractors, and working groups, including

the NASA Space Station Operations Task Force and its panels

Task 2 products and knowledge pertaining to the Spacelab

mission planning process

The products of this task consist of the Space Station payload

mission planning concept functional flow diagrams, a summary table describing

the new and modified SL MIPS software modules required to implement the SS MPS

concept, and the hierarchical structure of software for the SS MPS. The SS

mission planning concept functional flow diagrams, including an explanation of

the fundamental definitions, groundrules, and assumptions supporting the

mission planning approach, as well as an explanation of the flow diagrams

themselves, are contained in Subsection 6.2. The summary table of required

new and modified SL MIPS software modules and the hierarchical structure of

required software modules are presented in Subsection 6.3.

6-I

I
6.2 SPACE STATION MISSION PLANNING CONCEPT

6.2.1 Introduction

This section presents and explains the functional flow diagrams

representative of the Space Station (SS) payload misslon planning concept

developed under Task 3 of the SS Mission Planning System (MPS) Development

Study.

Prior to presenting the functional flow diagrams in Section

6.2.3 below, the following section provides the fundamental definitions,

groundrules, and assumptions which support the approach to SS mission planning

reflected in the flow diagrams.

6.2.2 Definitions, Groundrules and Assumptions

6.2.2.] Space Station Physical Configuration

The Initla] Operations Capability (IOC) configuration of the

International Space Station was used as the baseline for this Study. It will

be built up over a four year period by about 30 assembly missions and is

designed for future growth and enhancements. It consists of the following

elements:

o U.S. Laboratory Module

o ESA Laboratory Module

o JEM Laboratory and Exposed Facility

o" Habit Module

o Mobile Servicing Center (MSC)

o MSC Maintenance Depot

o Mobile Transporter

o Servicing Facility

o Attached Payloads Platforms

and Accommodation Equipment

o Pressurized Logistics Carrier

o Unpressurized Logistics Carrier

o 3EM Experiment Logistics Module

o Airlock

o Hyperbaric Airlock

o Te]erobotic Servicer

o Solar Power Module

o Truss Assembly

o Propulsion Assembly

o Resource Node l

o Resource Node 2

o Resource Node 3

o Resource Node 4

In addition to the manned base described above, the current

definition for the Space Station system includes co-orbiting and polar

platforms.

Primary physical accommodations to payloads on the manned base

will be provided by the laboratories and the attached payload platforms and

accommodation equipment.

Additional detailed definition of the Space Station physical

configuration may be found in JSC 30000, the Space Station Program Definition

and Requirements Document (PDRD).

6-2

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

!
I

I

I

I

I

I

I

I

I

I

I

!

I

I

I

I

I

I

I

6.2.2.2 Space Station Flight Operations Scenario

The Space Station orbit will be nominally circular with a normal

operative altltude of 463 km and an inclination of 28.5 ° (JSC 30000). Orbit

characteristics wi11 not be adjusted to accommodate particular payload

requirements.

The Space Transportation System (STS) Space Shuttle will be the

primary support vehlcle to the Space Station. As the Space Station orbit

decays, the STS wi11 be planned to rendezvous with the Space Station for the

purpose of accomplishing logistics resupply, payload equipment and crew

changeout. Space Station reboost will be nominally performed after each STS

visit.

6.2.2.3 Scope of Payload Mission Planning

For the purpose of thls Study, the scope of payload mission

plannlng was assumed to encompass the operations of multl-dlscipline payloads

contained within or attached to the Space Station manned base elements.

Excluded, therefore, were the operations of payloads on co-orbiting or polar

platforms; it was assumed that the influences of these platforms on manned

base payload operations will be input to the plannlng process in the Form of

Space Station operations constraints.

The various payload disciplines considered, particularly those

whose operational requirements would include specific orbital environmental

conditions, fields of view, or targets, were the same as those currently

accommodated by the Spacelab mission planning process - namely,

- Astrophysics

- Solar physics

- Plasma physics

- Earth sciences

- Life sciences

- Material Science

The scope of mission planning was further assumed to apply to a

"misslon increment", the period (up to 90 days) of Space Station orbital

operations bounded by STS visits (i.e., fixed payload complement).

The payload mission planning process was assumed to commence

with definition of the payload complement and the corresponding accommodating

Space Station elements for the mission increment.

The payload mission planning process activities were assumed to

range from the collection of payload operations requirements data through the

preparation of mission execution plans and procedures. It was further assumed

that the process must accommodate real-time replanning, as well as pre-flight

planning. (This is similar in scope to the Spacelab process, the definition of

which provided an excellent Foundation for identifying required Space Station

planning activities.)

6-3
6.2.2.4 Approach to Payload Mission Planning

A. Objectives

The following objectives were established for the Space Station

mission planning process, many of which were based on an assessment of the

characteristics of, or lessons learned from the Spacelab mission planning

process:

decentralize planning; specifically maximize

direct Space Station user involvement via

user-frlendly interfaces

to ensure the use and production of common data, and

to facilitate the integration of planning data,

provide common capabllltles at common planning levels

(from the users up to an assumed payload operations

integration center)

- automate to the maximum extent possible

elimlnate paper; emphasize readlly accessible data

bases between geographically dispersed locations of

planning activity

provide SS user flexibility within allocated resource

constraints

minimize the intensity (labor and computer) of

plannlng activities

The final two objectives were especially encouraged by lessons

learned from the Spacelab payload mission planning process, in which the

relatively short duration mission (7-I0 days) forced the planning of payload

activities down to the minute to maximize the utilization of resources. To

achieve these two objectives, an approach of using "resource allocation

envelopes" was assumed, where such an envelope is a prescribed period of time

with an associated vector of average resource utilization levels. In addition

to achieving the aforementioned two objectives, this approach was justified by

the longer duration mission for Space Station (compared to Spacelab). Also,

the obvious disadvantage of this approach - the inefficient management and use

of resources - can be overcome, if necessary, since the scheduling software

can deal with scheduling data to a finer granularity.

B. Planning Organizations

Based primarily on concepts and definitions in use by the NASA

Space Station Operations Task Force, the following mission planning

organizations were defined"

o Users - Principal Investigators (Pl's)

6-4

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I
i

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

o Planning Center - An organization which Integrates the

requirements, planning, and operations of a particular

sclence/englneering discipline or of a particular Space

Station physical element (e.g., US Lab)

o Payload Operations Integration Center (POIC) - The

organization responsible For integrating payload

operations plans From all the planning centers and for

providing the primary interface between the user community

and the Space Station Systems Operations organization.

o Space Station Systems Operations - the organization

responsible for overall management and integration of

Space Station operations

o Investigator Horklng Group (ING) - An organization of

users headed by a mission scientist to encourage

cooperative science operations and to resolve confllcts

among users.

The ING is an organization successfully employed in the Spacelab

process. IWG's have therefore been recommended to be established for Space

Station at each planning center and at the POIC plannlng levels.

Whether planning centers will be organized around

science/englneering disciplines (discipllne centers) or around Space Station

physical elements (element centers), is a matter to be decided by NASA and its

international partners. The matter has been discussed at length by the NASA

Space Station Operations Task Force. The two approaches are depicted

graphically in Figures 6.2.2-I and 6.2.2-2. A third hybrid approach which

employs both discipline centers and element centers in-line In the planning

process is depicted in Figure 6.2.2-3, but has been discarded because of the

complex network of planning interfaces.

The overall advantage to the discipline center approach is the

enhancement of cooperative science, while the advantage to the element center

approach is that it directly supports the analytical integration process for

SS elements and allows resource allocation/utilization planning to be

controlled/verified for compatibility with element design/operational

capabilities as planning is integrated. Under the discipline center approach,

control/verlfication of resource allocatlon/utilization planning versus SS

element capabilities must be centralized at the POIC.

For this Study, the mission planning concept has been derived to

accommodate either discipline centers or element centers.

C. On-Board Crew Mission Planning

Based on MSFC guidance for this Study, the provision of planning

capabilities to the on-board crew has been limited to a minor real-time

replanning capability. Space Station Phase B studies have shown the crew to

be the most critical Space Station resource. Also, astronaut corps inputs to

6-5

I
the NASA Space Station Operations Task Force have indicated a preference for

no mission planning responsibility. Therefore, crew utilization should be

restricted to activities which must be performed on-board in order to maximize

crew availability for experlmentation. Furthermore, on-board planning will

place a significant demand on on-board resources (e.g., mass storage). For

these reasons, providing the on-board crew any mission planning capability is

subject to reconsideration, in favor of increasing the automation of mission

planning activities on the ground to minimize manpower requirements.

6-6

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I
III,'III

ff_

ll-=m IL..J i

m.._ ..-jpj

II

_1_ _- I m | m

(,.)1

w_n_ Oz

6-7

I--I

_-I

zO

I--

ILl

I-,- z

I-- z

L_

(_Wz

,..,.I

Lf)I

cl.I

i,
I I I I

6-8
gIi 6-9

z

(:D

I,,..,-

IJ,J

I,-,-- z

1'--4

_n

,._

i-- z

LIJ

(.J

I--- Z

.--I

U')

...J

¢3.

(.,,')

r,,

I--- Z

LtJ Z

_.J

Q.

(.J

(.n

I--I

!

(.,j w
6.2.3 SS Payload Mission P1annin_ Process Functional Description

Four distinct high level payload mission planning cycles have

been identified as depicted in the Space Station (SS) Payload Mission Planning

System (MPS) Top Level Functional Flow, Figure 6.2.3-I.

Cycle A, Define Resource Allocation Envelopes, is necessary for

preliminary definition of user resource requirements and integration/approval

of these requirements to arrive at agreed upon resource allocations for each

experiment entity (single experiment or group of experiments) as well as

resource a11ocatlons for each planning center.

Cycle B, Generate Tactical Operations Plan (TOP), results in a

resource a11ocation plan for the mission increment that assigns time blocks

(resource allocation envelopes) available for each experiment entity within

which to schedule detailed operations.

Cycle C, Generate Execution Plans, includes the user activity

Involved in generating detailed activity and command plans for resource

allocatlon envelopes, plus the activities to integrated those plans. This

cycle also results in an integrated payload data flow plan.

Cycle D, Perform Mission Increment Replanning, encompasses

simi1|ar activities to Functions B and C. Resources are reallocated; users

change detailed activlty/command plans; the crew replans activities over which

they have control; and all changes are integrated. The data flow plan is

finalized and the detailed payload crew activity plans are generated.

A flow of subfunctions for each planning cycle is presented in

the flow diagrams designated A, B, C and D. Each of the unique subfunctions

appearing on these charts is identified by the number in the upper right hand

corner of the flow diagram block. A corresponding flow diagram at the

subfunction level is included with the detailed description of each

subfunction presented in the following sections.

6.2.3.l Subfunction I - SS Projected Orbit Ephemeris

This subfunction will likely be performed by the Space Station

Systems Operations organization. It is included here because the software

required to perform this function could be easily derived from the SL MIPS.

The basic activity is to generate detailed ephemeris data, such as ascending

node data, ground track data and earth shadow on/off times to serve as a basis

for subsequent mission planning activities.

6.2.3.2 Subfunction 2 - Standard Orbit Opportunities Generation

This activity may also be performed by the SS Systems Operations

organization, but is included here because again SL MIPS software could be

utilized with modifications to perform the activity. The basic activity is

the generation of standard orbit observation opportunities. An observation

opportunity (obs opp) is a particular object or condition that is available as

a function of time (on or off). The designation "standard" is made because

the obs opps generated during this activity are those that are used by a wide

variety of mission planning organizations and scientific disciplines.

Grouping these into one subfunction performed by the same organization insures

use of common data across all Space Station users and planning centers.

6-10

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I
IIIIIIIIIIIIIIIIIII 6-11
CO

LIJ

Q.

0

_1

I.U

>.

Z

i11

Z

Q

m

I--

U

0

-.I

._1

ULI

U

_Y

c_

l,J

z

m

I.I.

I

S_!3S1"1

I

9/_, I/;_.1.3 9N-Id

6-12

I /310d NOIJ_VJ-S 33Vd
IIIiII!I!IIIIi!IIII

_Jz

_JI

S_13S1"1 NOIIVIS 33VJS 9_ I 1_13 9N-Icl

9_ I SS

/310d

6-13
CO

z

_J

Q. ,-.,

ZZ

Q,,,

UU

XZ

wZ

_-__q

z_

I

U

i.i.i

I- Z

.(Iv<l:

tv 1.14--I

w t.O Q.

z :::I i-.

,., (j

c3

'li_E

S_!3S1"1

D,. <1: <1:1. c=c

9/_1/_!/3 9N-Id

9.,_, I SS

loci

6-14

NOI/V/S 33VdS

I
!III1

,, -j

_u 4E (4_

O( _. Q) IIItIIIIt

'__L_ '

I

, _>_ It

9/AI

1_113 9Nld

9MI SS NOIIV.LS

13lOd 33VdS 0lAd Igg-NO it

', ]_103 (]g -NO

I

6-15
Z

C)i

.,(

_C

l.l.l 7

l,.l.l

CO

,,y r

l.l.l

-Il.l.l

l--" B

C_

LU

l,,-

C_

r_

CO

COI1 i l 7

C)mUZ

LL

co

6-16
IIIIII!II!IIIIII!II

6-17
6.2.3.3 Subfunction 3 - Special Observation Opportunities Generation

This activity involves generation of the observation

opportunities that are discipline dependent. It is expanded into task level

flow diagrams corresponding to the identified disciplines. Each of these

tasks includes the detailed activities required to generate the specific obs

opps for each discipline. In practice, this activity will be performed by

both SS users and the planning centers. The users will perform analyses to

determine when they want to operate and which obs opps they want to utilize.

Planning center personnel will access all users obs opps requirements entered

in the User Requirements Data Base (URDB) and generate an integrated planning

center set of obs opps to serve as input for subsequent mission planning tasks.

6.2.3.4 Subfunction 4 - User Requirements Definition and Data Base

(URDB) Interface

This activity includes user interactive input/editing of a data

base that contains resources, obs opps, sequencing/concurrency and number of

performances/duration requirements as well as operational constraints for each

individual experiment entity. An entity can be a single experiment or a group

of experiments. Depending on experiment resource profiles, a particular

experiment will have from one to many resource envelopes. User friendliness

and scheduling complexity as well as resource utilization efficiency will be

significant factors in determining the characteristics of the resource

profiles.

6.2.3.5 Subfunction 5 - Generate Planning Center Integrated Requirements

User requirements are summarized in a gross scheduling activity

based on the URDB entries and the observation opportunities file. No resource

checking is performed during scheduling. The output schedule(s) are used to

determine the overall planning center resource requirements.

6.2.3.6 Subfunction 6 - Integrated Assessment Of Planning Center Summary

Requirements

Planning center resource requirements, SSP management

guidelines, resource allocation rules, user group guidance and element design

constraints are utilized as inputs to assign each planning center a specific

set of resource allocations.

6.2.3.7 Subfunction 7 - Assign User Resource Allocation Envelopes

This activity is basically a formal approval process of each

users URDB entries. There may be cases where user resource requirements are

incompatible with those available to the planning center when considering

other manifested users. These cases must be treated separately and will

require reduction of user resource requests (redesign, reduced objectives,

etc.) or an appeal through channels for increased planning center resource

allocations. A thorough compatibility analysis of preliminary user

requirements in the strategic level planning/manifesting process should reduce

the potential for conflicts at this point.

6-18

I

I

I

I

I

I

I

I

I

!

I

I

I

!

!

I

I

I

I
I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

°_...i ,_

•.I _ _-_-.l

lieu. ,vii. 4 .................................................

_-° _

, .

•C ¢,._

_':: °"- " ............."# ..................................................... I

0

o oj. ll4= L :

_<_ I<,>"'\ _> _.<,>I'_"- _ ..................... _ ii 8 /_ \ _ I_'I I-,-_: \ i

II=- 'll ='- _ I

-'-_._"" / I <c_i"_ _ _ ,

m_ \,,,,, _ / I ,',, _ml % _'-' # I

oo \o I I _I \-_ J I _ = ,,, ,,/ , ..'= , v i

_,. . ............... -=:-.j. .................................._iL

-_. "" . I_ >

I _ _ ' I,,,,1_ I

= \_,_/ I_,e ,.,.

:= e<_ _ .-I /

............... .-I......................./

_ _<_ _ A<,", t,_i _°}'--"/

--- _/ _Oe.. "_ _ I_,1_. __1 I

v \ -- _ I _'_-_"I

I_°°'

I ($-19
n_,w

W

0

Z

ot

z * ....._ ..........I

/__ _- _1 A_ i

i../ T f.O O e_.%...._---ll I_1 om i.-I _" ._ I:1. _'LI o

./" ¢_

............... -_-1- .................................... - f.____o'_

w "-'J ¢d'_ 0

--.- \N¢_ /

o

i •

6-20 I
i!IIII

,,!!!!!!!III

=

C_i o Z

C_i

_.. uZ

LL

=:

z

I.UZ

I.U

L_I

r_i | v<

F--

I

6-21
0

1

JJ

Z

lJ

_0

iii

Z

0

Q

Z

O

i

I--"

LIJ

O_

0

,.J

1

111

(,0

i i

Z

O

1

I1

Z

(,0

1

I1

1

Z

0

0

Z

0

1

Il

LIJ

0

0

GO

l.U

I.-

Z

1

i

i i

v

I--

T ,

_I_

_8 : I

o i

1

i

q-, _0 o

\;_ ...................

iiiiiiiii1

1

6-22 1
IIIiI

_

I_

I __._ ! =Q -r" < < ! -

_.1 ILl | *'<

zZ | "' i

um. _ °.

!

wz

__.oc0

.,p__

¢.90.

W

F-- W

W

6-23
6-24
i 6-25

I
ZOm

k-Z

LQ

L0

00

Q.J niZo -- O Z Z _- O

-"O

-< _.

>"O

u_Z

o0O

KiU LU

UJ 09

C_

I ELI

iI

Z_

i.-i

U_

Z'h_

U.v

09

II

i _"_ _3_..

_°°

O--_.

_°°

6-?-6
IIIIIIIIIIIIIIIIIII

_.JI

%,- i ¢ 70m

F..- U7

LJ..

6-27

,,°_

_o_

P--_

_-<z

°_

o

_Wz
l-- Z

L,J

iii

C_

,,y

,,,-,

LLI

I'--'

,<

I.I.I Z

iiil

LLI

I"Z

LLI Z

iui ZZ<

,_I

0..

l.,l.I

I-,. <

,,.y

l.I.,I Z

111

_OI, i Zm

I..- Z

11

rY",

@

6-28
IiIIIIIIIIIIIIIIII

z_

O.

_°

'0 I,I Z0

rams i ZD <

0

.............................. __

L

Iz_o\

I

6-29
!II

(Z)

7"

LU

m,, i0

m,'

LU

F=

,<

,Y

LLt_

F-!

Z_a i

L,]

M= Z

L,]

(=) ZmZZ

,,(

..J

111

M-

,<

m,,

i,i Z

LUIi

i

Z0

{=) Z

L_

mm

V)

g

6-30
III

I--

II!IIIIIIiIIIl

X

I,J.J

I.i.J m

CJ

I.iJ

I.J.I

I--

I--, Zu

1.1.1

I-- 7

1.1.1 UZiZ

_J

C_

I,.i.I Z

I.iJI

L_0 i Z0i

I-- UZ

I--

I_J

LId m

CJ U0

I-- ZUZZZ<

I--

LUZ

LLI Ii i v<

k-,

I-

.,CZ

I_w ill,, _ _°

"" ¢JT

"_'uJ

¢JX

_1_

If_cJ

!

6-31
CO

F=

C)

r,,,

m,,

,<

CO

m,,

l,i Z

L,]-

L,J ZmZZ

.<

,.J

W,. 0

F-- Z

LU

CO

CO

i,J

CO

CO

.<

r_

Ld

.<

m,, Zm Ii i Z0n

F-- UZ

LL

CO

Q

6-32

Z_

b

F-

_oQ '"_ D C,-,-_
IIIIIII

6-33
6.2.3.8 Subfunction 8 - Generate Planning Center Gross Timeline

This activity is basically a scheduling function which develops

blocks of times within which each experiment may plan operations. This time

block allocation approach allows the user flexibility in scheduling his

Indivldual operations while minimizing the number of iterations required to

obtain a workable timeline. The tolerances included when allocating these

time blocks will be a significant factor, essentially trading off user

flexibility for schedule efficiency. The subfunction includes edlting obs

opps subjects; generating/editing mission tlmeline models; and generating the

gross tlmellne with the appropriate output products to be included in the

Tactical Operations Plan (TOP) Data Base.

6.2.3.9 Subfunction 9 - Integrated Assessment of Planning Center TOP's

Thls subfunction includes the following interrelated tasks:

verify that each plannlng center TOP does not violate the planning center

resource a11ocatlons; consolidate the plannlng center TOP's; identify any

operational confllcts between users of separate planning centers or between SS

systems and users; schedule centrallzed resources that are not completely

handled by resource a11ocation (crew, data flow etc.); determine what changes

are required to eliminate conflicts and satisfy user resource demands; and

generate the Integrated Payload TOP.

6.2.3.10 Subfunction 10 - Generate User Activity Plans

This is a detailed activity where each user defines desired

experiment operating times within the TOP-allocated time blocks and assigns

specific start/stop times to each operating step (mode).

6.2.3.11 Subfunction 11 - Integrate User Activity Plans

This subfunction includes the integration of the activity

plans of a11 users of a particular planning center; verifies compatibility

with TOP a11ocations; consolidates users activity plans; verifies

compatibility with other planning center users; re-schedules user operations

to eliminate identified resource or operational conflicts; generates the

planning center activity plan data base; and, in the daily planning cycle,

generates the planning center detailed Payload Crew Activity Plan (PCAP).

6.2.3.12 Subfunction 12 - Integrated Assessment of Planning Center

Activity Plans

This activity is nearly identical to subfunction If. The

difference is that the integration is now at the overall SS payloads level

(POIC) instead of the planning center level. The inputs are planning centers'

activi'ty plans and the outputs are the payload activity plans data base and

payload summary PCAP.

6.2.3.13 Subfunction 13 - Generate User Command Plan

This subfunction includes the user activities of generating a

command sequence to transition between steps (modes) of experiment operations

and generating time windows during which these commands must occur based on

the finalized user activity plans.

6-34

I

I

I

I

I

I

I

I

I

I

i

I

I

i

I

I

I

I

I
IIIIIIIIIIIIIIIIII @

m,.,i

=1

wm=)

&&

I

6-35
F0

,° III

Z

© u

U "--i

_. v

_,¢ P0

o_,_ f--L)

-_Coz

--; L,. --

--,.,_

I--

v,,,

Q3'"

o°

F0

6-36
I

I

i

I

I •

1°I

b

I .......... _--

I ,,-I, - ':

I _

I _ _ I

_-

I _ _

I _- _ ,

' lil

, olil

I 6-37
I.l.l

i

,..I £n

I--

¢00

uJ

I-- 77m77

ILl

ill

i IZ0m

I-- 7

L,J

i

,,.I n

I--

¢/)

¢0

Ld

I--

I.I.I 7I| * v

I--

6-38
I

'I

III

,I

IIIIIIIIIIII

F-- ZmIi . Z0

hi,

F.- Z

_=

r-_

I

6-39
<

._I

>- mm

e,,

W.J

¢0

_J

i-- Z

W.J I mZ0mZ

l,

¢0

6-40
6-41
Z

.<

..J

=,. -<

-=, 0. u

_.= L,]

(=_ ,=J u •< .<

m,, _=

L,J

Z

-- .< m" 7 0 _

0

Z ,.=

,.

_.v

mm 0"_

p i ,d

_n

_,_n

8 d_1 I - II

--=_ I

6-42
I 6-43
Ii

t,/')

7"

,-I 7

,r" o

,,,v

I.I.I

I'.,,-

I..I.I 7

111I m | 0 z0

I,,.-. 7

LL

f_b_.

K22_ m

8,,

.c.c_

'vlg_

w_

8

,.c ¢._

...J Iwe.@

__o

6-44

111I11!
I

!

I

I

I

I

I

I

I

II

I

I

!

I

I

I

i

I

6.2.3.14 Subfunction 14 - Generate Integrated Payload Data Flow Plan

This activity involves scheduling overall payload data flow

activities such as on-board data management of downlink/uplink and ground data

capture, management and distribution as well as generating the integrated data

flow plan.

6.2.3.15 Subfunction 15 - Onboard Reschedullng

This subfunction allows for minor re-scheduling on-board by the

SS crew. Accompanying activities of updating the PCAP and coordinating the

changes wlth the ground are also required. Nhether or not the overall SS

operations concepts a11ow for on-orbit re-scheduling is as yet unresolved.

The magnitude of the data requirements and the use of on-orbit crew time may

force e11mination of this subfunction.

6-45

!
.<

.<

.<

.=I

.,(

r_

L.U

F=

.<

LU

F-- 7m

l,t

B=.

.,(Z

i,iI J | i

C_ m

_=.

(..) Z

,,m

co

IIIII!

6-46
II!!!IIIIiII!IIIII

C_

ILl

"!- 0

(/)I Z

C_I

Lr') m | 0 Z

C_ i

I-- 0Z

u.

v I

6-47
6.3 SS MPS SOFTWARE REQUIREMENTS SUMMARY

Figure 6.3-Ia presents a hierarchical structure of the software

modules envisioned to be required to implement the SS payload mission planning

concept presented in the previous subsection; this structure is oriented

toward the SS planning organizations (users, planning centers, POIC) and

includes the definition of executive programs to interface with the using

organizations and to control the execution of lower level software modules.

Figure 6.3-Ia also identifies (per the figure legend) the modified SL MIPS,

new, and AI-application candidate software programs. (Section 7 presents the

ratlonale for the AI-applicatlon candidates.)

Figure 6.3-Ib Identifles additional software modules required to implement the

SS payload mission planning concept. The modules Identified are those

envisioned to be required to be provided to the on-board crew and the Space

Station Systems organization for mission planning and wlll have to be

integrated Into the software systems to be developed for the crew and systems

organlzatlon.

For the purposes of assessing the applicability of AI techniques to the SS MPS

in Task 4 of the study, and for generating the Software Development Plan in

Task 5, the computer programs identified in Figure 6.3-I were grouped into

software sets - i.e., groups of programs of a slmlllar nature at the same

hlerarchlcal level. The software sets are presented in Table 6.3-I. Note

that Sets E and F identify Phase I and II versions of the three "System

Executives" The distinctions between these versions are explained in the

Table 6.3-3 introduced in the following paragraph.

Flnally, pages 6-52 through 6-65 of this section present a table (Table 6.3-2)

which describes the indlvidual software module requirements to implement the

SS MPS concept. The table identifies each required software module by name

and whether the module is new or a modified SL MIPS software module. Also

provided Is a functional description of each module. Finally, each software

module is correlated to subfunctions/tasks in the SS mission planning concept

functional flow diagrams presented previously.

6-48

I

I

I

i

I

I

i

I

I

I

I

I

I

I

I

I

I

I
l

I o_o __

I _

I _ ....

l _ U___

1 ._

I _l.'_" __!i

I _ _

I '-: -- I_l_-_ i1 _ i l,O}l

_W -- '_

1 _!_

1

1

1

.(::

U

S.-

_S

S-

(2)

.el.

(_

r.z)

c_.

_E

(_

(/)

rx3

I

or)

_D

i,i

c:E

i,

l 6-49
I,LI U

_0

U.n"

a:_

wO_

r--m_

_o_

I--Q

Q.

_zQ_z cn

oz___

_n(_O

_w.,-

0_1,-

a.

mz

IIIIIIIIIIII

_D

ILl

n_

I u_ I

6-50
I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

TABLE 6.3-].

NEH SOFTWARE

SET A - SPECIAL OBS OPPS EXECUTIVES

TOP LEVEL

ATMOS PHYS

SOLAR

EARTH SITE

PLASMA PHYSICS

CELESTIAL

SET B - URDB I/F

SET C - EDITOR EXECUTIVES

MODEL EDITOR EXEC

OBS OPPS EDITOR EXEC

SCHEDULER EXEC

SET D - RE-SCHEDULER

SET E - SYSTEM EXECUTIVES (PHASE I)

USER MPS EXEC

PLANNING CENTER MPS EXEC

POIC MPS EXEC

SET F - SYSTEM EXECUTIVES (PHASE II)

USER MPS EXEC

PLANNING CENTER MPS EXEC

POIC MPS EXEC

SET G - COMMAND PLANNER

SET H - NEW TIMELINE ANALYSIS MODULES

MDL EXTRACT

MDL COMPARE

TL COMPARE

TL MERGE

PCAP DELTAS

SUMMARY PCAP

SET L - OUTPUT PROCESSOR EXEC

SS MPS SOFTWARE SETS

MODIFIED SL MIPS SOFTWARE

SET I - TIMELINE ANALYSIS

ESP

PCAP

PTS

TAE

VME

SET J - ORBIT ANALYSIS

ASEP

ATMOS

BORB

CAVA

ESAL

ESDATA

LTO

RADI2

STAR

TANRAY

TARGEN

SET K - DATA FLOW ANALYSIS

PROFILE

MISSION WINDOWS

ONBOARD RECORDER SCHEDULAR

POSSIBLE FORMATS

FORMAT SCHEDULAR

POSSIBLE POCC CONFIGURATIONS

POCC CONFIGURATION SCHEDULAR

PLAYBACK SCHEDULAR

INTERACTIVE DATA UPDATE SYSTEM

VERIFICATION

COMPARE TDRS

COMPARE MODELS

DATA MANAGEMENT CHECKLIST

DATA SCHEDULE FILE

ANTENNA DISPLAY

IDMS LIBRARY

6-51

I
I

i,,--

I--

'++ "+' + I

+z+.+ + i

iii

6-52
E_<

0

,.,-_ _, :_ I 6-53 I
6-54
I m,++, ___ ,+, _+_. a z++ +

I 6-55

I
i_

_1

6-56I
I
6-58
IIII

6-59

I
6-60

I
I 6-61 I
i

6-62

IIII
IIII

6-63
_5

6-64

mmmmu
I __ !I

6-65
THIS PAGE INTENTIONALLY

LEFT BLANK

6-66

IIIIiIIIII!IIiIiIII
I

I

I

I

I

!

I

I

!

I

i

!

I

I

!

I

i

I

Section 7

TASK 4 - INVESTIGATE ARTIFICIAL INTELLIGENCE APPLICATIONS

7.1 ACTIVITIES AND ACCOMPLISHMENTS

The objectives of this task were to:

(I)

(2)

(3)

Define AI techniques that could be applled to SS MPS tasks.

Identify and evaluate all tasks that could use the AI

techniques.

Recommend a methodology for Implementatlon of the

identlfied AI tasks.

These objectives were accomplished as i11ustrated in Figure

7.1-I. Two areas of effort contributed to accomplishment of the objectives

speclfled above. The flrst effort was to conduct a survey of the current AI

technology. The second effort was to compile a 11st of desired criteria for

an AI software development program. Both efforts increased the quality and

scope of the recommended hardware and software methodology.

7.2 DEFINITION OF ARTIFICIAL INTELLIGENCE

Artificial Intelligence Is the emulatlon of human inte111gence

and thought processes by computational models. It is the branch of Computer

Science concerned with designing intelligent computer systems that exhibit the

characteristics associated with inte111gence In human behavior - reasoning,

understanding language, solvlng problems, etc.

Expert systems are AI programs that are designed to execute a

highly speciallzed and dlfflcult task with the proficiency of a human expert.

They employ domain-specific problem-solving strategies as opposed to broad,

general-purpose strategies.

7.3 SURVEY OF AI TECHNOLOGY

A limited survey was conducted of the efforts of various

companies and Government agencies to summarize the type of problems that were

being solved with AI techniques and the degree of success In their

performance. Three areas of the technology were addressed: expert systems,

natural language interfaces, and automatic programming. Expert systems were

categorized into training and instruction, trending and prediction, design and

configuration, information and data interpretation, and planning and

scheduling.

7.3.1 Expert Systems

7.3.1 .I Training and Instruction

The Army Missile Command Research and Development Center

successfully deployed an expert system to train operators in the use of an air

defense system. It was prototyped with a commerically available expert system

tool on an IBM PC and then ported to a larger mainframe. The system performs

off-line simulations to improve operator proficiency and provide advisory

functions during actual real-time situations.

7-I

I
I

r_

U

,,¢

l

7-2
I

I

I

I

I

I

I

I

!

I

i

I

I

I

I

I

I

i

7.3.1.2 Trending and Prediction

The KNOMES system deslgned by MDAC-Huntington Beach is a

hierarchlcal object-oriented program that performs fault Isolatlon, correction

and prediction. It is implemented In ADA on the VAX and has been tested on

the SS Data Management System test bed at NASA JSC.

The Systems Autonomy Demonstration Program funded by NASA Ames

Research Center has designed several subsystems using autonomous control

modules.

Autonomous control is the goal of the NASA Goddard Research

Center in designing controllers for the Space Statlon power dlstrlbutlon

system.

The Navigation Subsystem Technlcal Assistant, designed by Boeing

Seattle for the USAF, monitors GNC data and provides recommended actions to

the human operator. It was implemented in prototype on an IBM PC using the

Personal Consultant shell from Texas Instruments.

The STALEX system designed by NASA JSC performs launch wlndow

selectlon given the many time-dependent factors of orbltal mechahlcs and

ground tracklng slte avallablllties.

7.3.1.3 Design and Conflguratlon

The most renowned configuration expert system in the industry is

Dlgltal Equipment Corporation's XCON, formerly called RI. It Is implemented

in OPS5 on the VAX. XCON specifies a detalled computer hardware

conflguration, Includlng integratlon and test Instructions, from an input of

customer requlrements.

The KATE system from NASA KSC is currently being prototyped to

capture the design knowledge of the existing LES expert system. LES a11ows

the generator to access all electrical schematics of the LOX fueling system of

the Shuttle. The KATE system will allow a higher level of user interface to

this data base and promote faster electrical redesign. KATE is being

implemented on IBM PC/AT's.

The HICLASS system from Hughes Aircraft is tailored to CAD/CAM

applications. It was originally coded in FORTRAN and SPL, later converted to

PASCAL running on the HP 3000. It has lately been re-coded into C on the

Apollo workstations under the Unix operating system.

7.3.1.4 Information and Data Interpretation

The EAGLE system, developed at INCO (a MDAC subsidiary),

processes large quantitities of numerlcal and qualitative data to provide

advisory information to Air Force operators in the NORAD system. The initial

prototype was implemented in LISP using KEE on the Symbolics machine.

The XSEL system in use at DEC is the front end processor for the

XCON system mentioned above. It interprets multiformat input data from the

customer and outputs standardized configuration requirements.

7-3

i
7.3.1.5 Planning and Scheduling

The KNOMES system from MDAC-HB includes several expert system

routines devoted to planning and scheduling for the Space Station.

The MARS system, formerly PLANNET, from MDAC-Kennedy Space

Center Division, has been implemented in several prototypes to schedule

Shuttle payload integration operations for the entire O&C building. It is

implemented in LISP on a Symbollcs machine.

The PLAN-IT system from NASA 3PL was derived from Voyager

mission experiment scheduling. Modules applicable to Spacelab mission

planning to are currently being sought. PLAN-IT is implemented In LISP on a

Symbolics machine.

The MAESTRO system for Martin Marietta Corporation addresses the

problem of experiment scheduling for the Space Station. It is implemented In

LISP on a Symbollcs machine.

The Space Station Expert System from Lockheed in Houston is a

scheduling system prototype to provide on-board advice'to operators for

reconflguring resources to meet a hazardous or unexpected event.

7.3.2 Natural Lanquage Interfaces

Intellect, from Artificial Intelligence Corporation, was one of

the first NLI's available for information retrieval from existing data bases

In finance, businesses and marketing. Lifer is a follow up to the Intellect

tool. It facilitates queries to conventional data bases.

Language Craft Is a tool available from Tecknowledge. It is

implemented on the Symbolics machine.

Chat-B0 is a NLI developed at Stanford and marketed by SRI. It

is implemented in Prolog on the Symbolics machine.

Savvy is a tool from a MDAC subsidiary that is implemented on an

IBM PC/XT.

7.3.3 Automatic Programming

The ABE system, being developed by Technowledge for DARPA, is a

comprehensive attempt to gather an assortment of existing AI tools, languages

and techniques, and to develop a system that will allow an operator to

assemble expert systems at a high level. The languages contained thus far

are: Common LISP, MRS, Knowledge Craft and Sl. The logic frameworks

include: Blackboards, Data Flow Paths, Intermodule Transaction, and Data

Importer. The total system is still in a prototype phase.

7.4 ASSUMPTIONS PRIOR TO CANDIDATE EVALUATION

Experience gained from the early phases of the project allowed

several assumptions to be made prior to evaluation of the SS MPS candidates.

7-4

I

i

I

I

I

I

I

I

!

I

I

I

!

I

I

I

I

I
I

I

I

I

I

I

I

I

I

I

I

I

I

I

l

I

l

i

7.4.1 ADA Software

It is assumed that all new non-Al mission planning software

tasks will be coded In ADA for compatibility with Space Station program

requirements.

All AI techniques can be implemented in LISP, PROLOG or ADA.

LISP and PROLOG have only a few advantages over ADA, as explained In

subsection 7.7 below.

7.4.2 Specialized AI Hardware

If specialized AI hardware Is required, assume a Symbollcs

architecture. LISP and PROLOG are not viable languages unless executed on

specialized AI processors. Symbollcs Is the best processor currently on the

market.

The execution of LISP on coprocessor boards installed In

conventional computers is not considered; however, their emergence on the

market Is imminent.

7.4.3 Conventional Hardware

Assume a DEC VAX architecture for all ADA software

implementations.

7.4.4 Candidate Evaluation Criteria

The criteria for candidate evaluation are not discrete. They

are frequently interrelated.

The criteria are qualitative rather than quantitative. Also,

not all criteria are of equal importance.

The evaluation of each software set against the criteria is

subjective. The evaluation is highly dependent on definitive information

about AI techniques and Space Station operations concepts.

7.5 DESIRED ATTRIBUTES OF MPS TASKS

This llst of desired attrlbutes is based upon industry accepted

standards for a software development project. Several attributes have been

added or modified to tailor them to software projects employing AI techniques.

The desired attributes for candidate MPS tasks are shown in

Figure 7.5-I. Each software set received a "+" if the set contained the

desired attribute and a "-" if the attribute was missing and could cause

potential problems In the implementation of the task.

7.5.l Task Domain

Domain Knowledge Base is Bounded and Stable

The knowledge base required to accomplish the task must be

bounded to have some defined limits; otherwise, the software data base is

7-5

I
FIGURE 7.5-1

ATTRIBUTES OF MPS TASKS

TASK GROUP

A B C D E F G H I J K L

Domain isbounded and stable

Domain isspecializedand detailed

TASK EXPERTISE

Expertise to be lost

Expertise is scarce

Singlepoint expert

Expert is dedicated

TASK INTERFACES AND METHODS

System can monitor real world

I/0 and methods can be defined

Debu_£in_ the software

ORGANIZATIONAL ISSUES

Required Documentation

Confi£uration control

System acceptance testin8

MANAGEMENT ISSUES

Realisticschedules and milestones

Resource comittment

Low initialcost

Lone term manhour savin£s

PROPOSED USERS OF TASK

User acceptance

+ - + + + + + + - _

+ + + + + - _ + + + + +

+ + + + + + - + + + + +

+ + - + + + - + + + + +

+ - + + + + + + +

!+ + + + -.- + + + + + +

+ - + + + + + + +

_ ._ + - + -.- + + + + +

+ + + + + + + + + +

+ !+ + + + + + + + + + +

+ + + + + + + + + + + +

+ - + + - ._ + + + + + +

+ + + + -. - + + + + + +

+ + + + + + + + + + + +

+ - + + + + + + 4

+ + - + + + - + + + + 4

+ - + + -, - + + + + + 4

I

I

I

SOFTWARE SETS

A - SPECIAL OBS OPPS EXECUTIVES G - COMMAND PLANNER

B - USER REQUIREMENTS DATA BASE INTERFACE H - NEW TIMELINE SOFTWARE

C - EDITOR EXECUTIVES I-MODIFIED TIMELINE SOFTWARE

D - RESCHEDULER J - MODIFIED ORBITAL MECHANICS SOFTWARE

E - SYSTEM EXECUTIVES PHASE I K- MODIFIED DATA FLOW SOFIWARE

r - SYSTEM EXECUTIVES PHASE 1I L - OUTPUT PROCES_30R EXECUTIVE

7-6

I

I

I

I

I
I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

never complete and a goal state for project completion is Impossible to

define. Object oriented programming styles can alleviate this problem somewhat

by providing a workable system by declaring objects or modules to deal with

input that is outside the current domain. These objects would contain generic

methods and generic rules that cover all posstble cases. This will allow the

system to "soft fat1" when confronted with an inquiry outside the task's

domain. However, this type of program is likely to be in a state of constant

revision.

The knowledge base must also be stable; otherwise, when the

system is released, it ts already out of date. Frequent mandatory updates to

the knowledge base detract from the manpower savings realtzed from Initially

automating the task.

Domaln Knowledqe Base is Speclallzed and Oetatled

Assuming that the task domain is bounded, the Ideal domain

should consist of specialized knowledge instead of a broad expanse of general

knowledge. Speclallzed knowledge usually lends itself to representation using

one or two programming techniques, thus reducing the modellng task complexity.

Detailed knowledge implies that the task contains some expertise

(is not a trtvial problem), and ts therefore worth the effort to code the task.

7.5.2 Task Expertise

Expertise to be Lost

If the expert now performing the task wlll soon be retiring,

advancing, etc., and it w111 be difflcult and expensive to train another

expert, then automation may be justified.

Expertise is Scarce

If the expert could be useful in many different locations at the

same time, then automation and duplication may be justified.

Single Point Expert

A few people, or preferably one person, must be designated as

the domain expert. Multiple experts cause problems such as conflict of

information, and organization of segments of knowledge from different experts.

Expert is Dedicated

The expert must be able to suspend his normal duties when needed

to assist on the project. This may be difficult since true experts usually

have a high demand for their time. Of course, the expert must possess the

communications skills to have his knowledge encoded correctly and possess the

patience to verify that the system performs correctly. The expert must be

interested in the success of the project.

7-7
7.5.3 Task Interfaces and Methods

System Can Monitor State of the Real World

A11 slgniflcant communlcations from the user must be capable of

capture by the system. For example, current systems are not capable of

capturing facial expressions and voice inflections of a human. The system

will contain a model of the real world (withln its domain limitations) that it

can use to formulate responses. Thls model must be easlly updated by the

user (keyboard, voice recognltion, etc.). Manual data entry Is not a task

that humans perform efflciently; preferable interfaces are with automatic

stimuli (data stream from other computers, sensors, etc.).

Input, Output and Methods Can be Deflned

The expert or pool of experts must be able to deflne

"acceptable" Input and output. An expert(s) must be able to define the scope

of the task and the methods used to perform the task. The AI capabillty of

rapid prototyping can be cost effective in the early phases of requlrements

definitlon to define the methods.

Debugging the Software

During the design phase, unexpected responses by the software

are still dlfficult to detect and isolate. In conventlonal code, paths of

procedural flow may occur that the designer never intended nor had perceived.

This is becoming less of a problem for conventlonal software wlth improved

editors and debuggers. In LISP and especially PROLOG, slmllar bugs may exist

as loops In the knowledge base which cause Incorrect assumptions. LISP and

PROLOG edltors and debuggers are also very powerful and Improving. This

problem seems to be based on the complexity of the task rather than the choice

of software language for implementatlon.

7.5.4 Organizational Issues

Required Documentation

Automation reduces the amount of documentation required by the

user to complete the task, but it necessitates creation of a new set of

documentation for maintenance of the new hardware and software. This

documentation must describe in detall the implementation of the task on the

machine.

Documentation also includes comment lines within the source

code. Contrary to rumors about the readability of LISP and PROLOG, these AI

languages must contain complete comments to code just as in conventional

languages.

Note in Figure 7.5-I that is an applicable desired attibute for

all MPS tasks; therefore, it does not, in effect, serve to identify automated

over manual or AI over non-AI tasks.

7-8

I

I

I

i

i

I

I

I

I

I

I

I

I

I

I

I

I

I
I

I

I

I

I

i

I

I

I

I

I

I

I

I

I

I

i

I

i

Configuration Control

Machlne hardware and software and the documentation must all be

kept In a known state to a11 users and development and maintenance personnel.

Revisions to the hardware and software must be controlled and tracked. A

configuration management system Is established after early prototyping but

prior to Preliminary Design Review. That system continues throughout the llfe

of the project.

Thls desired attibute is also applicable for all MPS tasks and

therefore does not serve to identify automated over manual or AI over non-AI

tasks.

System Acceptance Testinq

Inltlal release of the system must be accompanied by testing

adequate to provide confidence that the system performs as expected. The test

cases used are typlcally "worst case" or "average" scenarlos. If the range of

real world problems that the system will encounter Is difficult to

approximate, then the amount of acceptance testlng wlll be very large in order

to obtaln a satisfactory level of confidence in the system's performance.

7.5.5 Management Issues

Realistic Schedules and Milestones

A reallstic schedule for project completion should contain

adequate time for a11 phases of software development and requirements

definition and deslgn. (For example, adequate tlme may not exist to clearly

deflne the methods to be automated to accomplish MPS tasks previously

performed manually.) S1gnlficant milestones should be established at the

beginning of the project. The level of system performance at these

milestones should be well defined to avoid ambiguity about the progress of

the system.

The final acceptance milestone should include the explicit

deflnition of "project success".

All milestones serve to verify that the system is developing

toward the desired target and to rekindle controlling management's interest

and awareness in the project.

Resource Commitment

The necessary resources must be committed, by management, to the

project. Budget must be allocated for hardware and software purchases,

adequate facilities must be designated, and necessary manpower skills must be

committed. (It is assumed that is an applicable desired attribute for all MPS

tasks and therefore does not serve to identify automated over manual or AI

over non-AI tasks.)

Low Initial Cost

Automation frequently requires a large "up front" investment of

capita] equipment and man hours. It may take several years of savings from

7-9
automation to recover the initial cost. Obviously a low initial cost is

preferred to a high one.

Long Term Manhour Savings

The goal of automation is to alleviate humans of the mechanics

of performing a task, that they may spend their time in a more cost efficient

task. The tlme required by the user to operate and maintain the system must

not exceed the time required to do the task manually for automation to be

considered successful.

7.5.6 Proposed Users Of Task

User Acceptance

Unless the system Is accepted by the end users It will be

ignored and abandoned.

The Ideal delivered system should flt into the user's daily

routlne, impose few new requirements, and demand little or no training in its

use or interpretation.

There must be an efficient feedback method from the users to the

system designers and maintainers. Ideally the users should maintain the

system.

The users must trust the system output. This can be facilitated

by heavily involving the users in the design process. The Explanation

Capability of AI systems is a good technique to enhance credibility in the

eyes of the users.

7.6 ARTIFICIAL INTELLIGENCE TECHNIQUES

An attempt was made to comb through the many books describing AI

techniques and pull out the techniques that demonstrate advantages over

conventional programming techniques.

The definition of an AI technique versus a conventional

technique Is subjective and a source of disagreement within the programming

community. The boundary between the two is constantly shifting. Many AI

techniques were first implemented in LISP or PROLOG and then found their way

to conventional implementations in FORTRAN, PASCAL or C. For our definition,

AI techniques are most easily imp]emented in ADA, LISP or PROLOG, while

implementations in FORTRAN, etc., are considered to be strictly conventional.

Note that ADA holds the middle ground, being a derivative of PASCAL and

FORTRAN, but designed to easily implement complex AI techniques.

The following paragraphs describe the AI techniques identified

as advantageous over conventional programming techniques. These techniques are

listed on Figure 7._-1. The functions of each software set were evaluated

against the list and given a "+" if any of the task functions could be

implemented using an AI technique.

7-10

I

I

I

I

I

I

I

I

I

I

!

I

I

I

I

I

1

I
I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

FIGURE 7.6-1

AI TECHNIQUES FOR MPS TASKS

TASK GROUP

A 8 C D E F G H r J K L

l"_r'4".l"_r-_._r-l_l 1 _ 1 IUDi t.Jr J_l_ll,.,_ YY 1.,r'-IJ_rr'-

Production Rules

State space representations

Frames, 0bjectorientedprogrammin 8 + + + + + + +

+ + :+ + + + +

+ +

Scripts

Semantic nets

MANIPULATION OF KNOWLEDGE

Abstraction

Inheritance

Pattern matching

Augmented transitionnetworks

Chainin_

CONTROL STRATEGIES

Demons/Methods

Blackboards

UNCERTAINTY MANAGEMENT

Fuzzy lo_ic

Dempster shaeffer theory

Baysian inference

AUTOMATIC PROGRAMMING

Module selectionand sequencin_

Learnin_ capability

EXPLANATION CAPABILITY

META KNOWLEDGE

NATURAL LANGUAGE INTERFACES

DESIGN CAPTURE

+ + + + + + +

+

+ + +

+ +

+ + + + + + +

+ + + + + +

+ + + + + + +

+

+ + + + +

+ + + + + + + + + + + +

+ + + + + +

+ + + + + +

+ + +

+

+ + +

+

+ + + + + + + + + +, + +

+ + + + + +

+

+ + +

SOFTWARE SETS

A - SPECIAL 0BS 0PPS EXECUTIVES O - COMMAND PLANNER

B - USER REQUIREMENTS DATA BASE INTERFACE H - NEV TIMELINE SOFTVARE

C - EDITOR EXECUTIVES I-MODIFIED TIMELINE SOFTVARE

D - RESCHEDULER J - MODIFIED 0RBITAL MECHAN ICS SOFTWARE

E - SYSTEM EXECUTIVES PHASE I K- MODIFIED DATA FL0V SOFTVARE

F - SYSTEM EXECUTIVES PHASE II L - OUTPUT PROCESSOR EXECUTIVE

7-11
7.6.1 Representation of Knowledqe

Production Rules

Rules are useful for representation of dectsion trees, i.e.,

"ifthen" statements to be accessed only when the precedent matches the real

world model. This technique exists in all the large mainframe A1 tools and it

is the principal technique used in many PC-based tools.

Applications In the SS MPS include rules for experiment model

building, software module selection and sequencing, scheduling, output

formatting, loglc manipulations and generic rules for processing data outside

the current domain.

State Space Representations

Space state representations are useful to represent domains with

a large number of input criteria and a large number of acceptable outputs.

This technique Is implemented in several expert systems used for route

finding, chess playing, etc.

Applications tn the SS MPS lnclude reschedullng strategies,and

mapping of logic solution paths in experiment Integration.

Frames/Object Oriented Programming

Object oriented programming is an organization technique that

divides a large "master" program into subprograms, similar to FORTRAN

subroutines, called modules or objects. The data used by the module is also

stored in the module. Hhen dialog is needed between objects they send

standardized messages to each other. (See Demons below under Control

Strategies.) Objects can be organized in a traditional hierarchical structure

but the emphasis is for module autonomy, i.e., controlling functions and

decisions are made at the lowest possible level in the hierarchy. This

programming technique has proven especially powerful for modeling real world

objects and their interaction with other objects. Implementations have been in

graphics, animation, and factory floor simulations.

Object oriented programming also facilitates frequent updates to

the domain knowledge base since code is 1ocallzed. This makes modeling

feasible for a task that is constantly changing in definition.

Object oriented programming emphasizes the use of calls to

common library routines. This results in a substantial reduction of the

number of lines of source code required.

This technique has been implemented in languages like

SMALLTALK-80, MODULA2, SIMULA-67, CLU, and LISP tools like ART and KEE. Object

oriented programming is one of the primary goals of ADA. It can be implemented

by data hiding, function hiding, common module libraries, operator overloading

and other techniques.

7-12

I

I

I

I

i

I

I

I

I

I

I

I

I

I

I

I

I

I
I

I

!

!

I

I

I

I

I

!

I

I

I

I

I

i

!

I

Scripts

Scripts is a set of data patterned after real world scenarios

which can be used to provide default values and predict typlcal responses in a

real world situation. Scripts are typically stored in frames (objects) and

selected using the pattern matching technique.

Applications in the SS MPS include supplying default values to

incomplete user input data, supporting intelligent dialog In a natural

language interface, and providing canned planning strategies for default

planning by the user.

Semantic Nets

Semantic nets represent objects, actions, or events as nodes and

their relatlonshlps as interconnecting links. The technique is useful for

mapping multldlmenslonal inheritance trees and viewing It from any

perspective. The technique is used extenslvely In Natural Language Interfaces

to map text Into paraphrases and primitives to be processed by separate

routines.

7.6.2 Manlpulatlon of Knowledqe

Abstraction

AI languages facilitate the implementatlon of abstraction by

their ab111ty to encode heurlstlcs and logic functions. Abstraction techniques

are used to efficiently search through a large set of detalled, possibly

incomplete, data to produce sets of possible solutlons. Abstraction is a

technique whlch a11ows the software to create previously undefined

configurations from a domain of apparently unrelated facts. In conventional

programs all processing paths are predetermined by the programmer which Is

likely to result in an inefficient search through the possible solution space.

Applications in the SS MPS include: generalization of specific

details to a higher level of requirements definition; inference of

non-specific English language to specific meaning; and restricting

reschedu1|ng in the effort to locate a "best" solution.

Inheritance

Links between objects in object oriented programming allow them

to obtain information from their "parent" objects (objects established as

"above" them in a hierarchy structure). This significantly reduces the amount

of code required at the lower element levels, and assures continuity

throughout a branch of related objects.

Applications to the SS MPS include: tailoring dialog in a NLI to

a particular person; passing constraints of an experiment down to the step

level; filling in meaningful data where scripts don't apply or fall short; and

a11owing vocabulary modules to inherit meanings from a particular dlscipline.

7-13

!
Pattern Matching

AI languages have the capability to search through the knowledge

base and plck a partlcular object based upon its content without having to

know the object identifier or data type. This eliminates the need for

arbitrary naming and data typing necessary in conventional languages.

Applications to SS MPS include activation of rule sets,

selectlon of scripts, and analysis of decisions at state space nodes.

Augmented Transition Networks

Nhen coupled wlth Semantic Nets this Is the most popular

technique used in Natural Language interfaces.

Chainint

Forward chaining (data driven search) and backward chaining

(goal directed search) are the two establlshed methods for searching through a

state space. Forward chaining is typically used For design and conflguration

problems. Backward chalnlng Is typically used for dlagnostlc problems.

Appllcations to the SS MPS include concept formulatlon, and

generatlon of queries from the knowledge base to the user.

7.6.3 Control Strateqles

Demons/Methods

Demons, or methods, are used with object oriented programming to

pass messages between objects (causing the receiver to perform an action upon

itself). They are programs that wait for a particular condition to occur.

Applications to the SS MPS include consistency checking input

data from the real world against previous input data or known conditions, and

activation of rule sets to handle queries outside of the current domain.

Blackboards

Blackboards is a technique used widely in "Sensor Fusion",

a11owlng separate routines to post their proposed solutions in a global or

restricted data area to be accessed by other routines for constraint

monitoring. This technique serves as a "checks and balances" technique to

verify that no routine exceeds its authority in making decisions or

assumptions. This strategy of executing routines based upon the contents of

the blackboard differs From the hierarchical control strategy of conventional

programs in which each program has a predefined and limited set of possible

activators.

Applications to the SS MPS include constraint checking between

large modules of varying conditions, i.e., intermodule, interdepartment,

interdiscipline, and interexperiment.

7-14

I

I

I

I

I

I

I

I

I

I

!

I

I

I

I

I

I

I
I

I

!

I

I

i

I

I

i

I

!

I

I

i

i

I

7.6.4 Uncertainty Management

Fuzzy Logic

Values needed by the system can be inferred From values provided

by the user or otherwise presently known by the system. This could be useful

in supplementing an incomplete data entry by the user. The technique of Fuzzy

Logic can be used to perform reliable assumptions. Fuzzy Logic grades or

qualifies statements rather than evaluating them to be strictly true or

false. The results of Fuzzy reasoning are not as definite as those derived by

strict logic, but they cover a wider range of possibilities.

Appllcatlons to the SS MPS include tracking of assumptions, andencoding qualltatlve rather than quantltative Informatlon about an object.

Dempster Shafer

Humans sometimes have the uncanny ability to know the "goodness"

of a particular solution. The Dempster Shafer technique allows the system to

arrive at an overall numeric value, representing total confidence In the final

solution, by summing the confidence factors at each decision node of a State

Space, Decision Tree, etc. Thls can not be easily implemented In conventional

languages because of the difficulty In tracing the decision path.

AI programs supplement this further by their explanation capability that

allows the human to view the logic path that produced the decision.

Applications to the SS MPS include the generation of confidence Factors for a

particular solution.

Bayesian Inference

This is a sophisticated technique that deals in probablllty

computations. In Bayesian Inference, the overall probability that a

particular assumption is true is based on a computation of the individual

probabilities and the conditional probabilities of each assumption

prerequisite. This technique provides more accurate confidence factors than

the Dempster Sharer technique, but requires an exponentlally greater number of

computations.

7.6.5 Automatic Proqrammin_

Module Selection and Sequencinq

The most widely demonstrated technique of Automatic Programming

is module selection and sequencing. This technique selects predefined

software modules for problem solution and sequences their execution. Module

selection and sequencing is typically aided by heuristic rules of operation.

Learnin_ Capability

The capability of expert systems to learn how to solve problems

outside of the current domain is based on the ability of programs to create

and execute their own code. This process is similar to conventional programs

generating strings of text.

7-15

!
The process is somewhat more straightforward in LISP since, in

that language, text and data are treated identically, i.e., newly created code

appears identlcal to all other LISP code. With the use of the EVAL statement

In LISP the new code can be forced to execute. Since LISP machines have

runtlme linking and dynamic memory management, the code can execute

immediately after its creation. Conventional systems would have to go through

the compile/llnk cycles.

In theory these processes could be used for systems that "learn"

and for "automatic programming". In practice, only a few successful and

limited applications have been implemented (VLSI design, image processing,

animation). More definition Is required in the area of programming

conventions. Most early attempts have been met with some rather bizarre

computational results when attempting to generate code in real time.

Appllcatlons to the SS MPS Include the ablllty to successfully

encode changing human logic patterns used in the bulldlng of a MPS schedule.

7.6.6 Explanation Capability

The ability of AI languages to Form links between

elements(nodes) facilitates the display of the solution path. Thls is

difficult to Implement in conventional languages without a dedicated trace

routine. Explanatlon of which branches were taken and why help reinforce the

user's confidence in the system.

In a LISP machine the explanation path is easily traced back

through the memory links performed at runtime during the solution of the

problem. ADA systems implement explanation via stack pointers.

Appllcatlons to the SS MPS include the ability to explain any

computation/assumptlon to the user to build his confidence in the system

output.

7.6.7 Meta Knowledge

Problem solving systems contain the complete set of knowledge

for their domain. However, they cannot handle problems outside of their

domain and are unaware of this inability. When the program is queried by the

user, it searches its data base for a solution. Since the domain fails to

produce an affirmative answer, the answer returned is "no" instead of the

correct answer of "I don't know". Programming in knowledge of "what a system

does not know" significantly increases the size of the software. Definition

of meta-knowledge is still a research area of AI. Techniques used include

"Metadata" and Data Dictionaries.

Applications to the SS MPS include the capability of any module

to recognize its own limitations and request assistance from the next higher

module in the hierarchy or from the human expert.

7-16

I

I

I

I

I

I

I

I

I

I

I

I

I

I

1

I
I

i

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

7.6.8 Natural Language Interfaces

Natural language interfaces are one of the most successful and

actlve areas of AI technology. Several commerically available software

packages have shown adequate vocabularies in bounded domains.

Applications in the SS MPS include interfacing to the individual

users to allow them access to the MPS software system.

7.6.9 Design Capture

Much emphasis is given in AI technology to programming problem

solutlons on a higher level. Conventional programs classically encode the

numeric solution to a problem, logically supported by comments to the code. If

the design of the coded module must change to meet new requirements It must be

done manually, based on the comments and other supporting documentation. The

capability of AI languages to directly encode the logic of the problem

solution allows programs to encode the requirements more directly and to be

more adaptive to requirements changes.

Applications to the SS MPS lhclude appending logic reasoning to

objects representing users, experts and experiment/Space Station hardware.

7.7 METHODOLOGY FOR CANDIDATE IMPLEMENTATION

The methodology for hardware and software host selection is

illustrated in Figure 7.7-I. The software sets were evaluated against the

attributes described below and given a "+" if they exhibited a need for that

attribute. They were given a "-" If they had no need for that attribute.

7.7.1 VAX Vs. Symbollcs Architecture

Commerical Support of Hardware

Compared to conventional computer manufacturers, very few

companies are involved in the sales and service of LISP machines. For overall

reliability, maintainability, proven performance, and acceptance by industry,

the VAX is the best alternative. In the the SS MPS, if a task is time

critical, i.e., if machine downtime must be kept to a minimum, then the VAX is

the preferred processor.

However, Symbolics machines are constantly improving and the

market share does not appear to be diminishing. The LISP computers will not

soon become a dinosaur. But, DEC will likely market a co-processor board for

its VAX computers in an effort to gain their share of the LISP computer market.

Real Time Environment

VAX processors are fast enough to support real time

environments. Some LISP machines are burdened with the problem of garbage

collection which is very detrimental in a real time environment.

7-17

I
FIGURE 7.7-1

AI METHODOLOGY FOR MPS TASKS

VAX _o. SYMBOLICS

Commercial support

Real time environment

Many users

ADA LANGUAGE

Standardization

Sizeofsource code

I

!

TASK GROUP I

A B C D E F G H I J K L

+ - + + + + + + + + + +

+ - + + + + + + + + + +

+ + - + + + + + + + + +

+ + + + + + + + + + + +

+ + + + + + + + + + + +

CapabilitytoimplementAI techniques + + + + + + + + + + + +

LISP LANGUAGE

Rapid prototype environment

LISP languaSe advantages

Tools available

PROLOG LANGUAGE

Predicate calculus

Parallelprocessing

- + - + + +

- + - + - +

- + -,_ + +

- 4- - + + + ......

+ + + ......

RECOMMENDED METHODOLOGY

Deliver on VAX in ADA (no A I)

Deliver on VAX in ADA (use AI) + + +

Prototype on SYMBOLICS in LISP +

Deliver on SYMBOLICS linked to VAX

Implement in Spacelab MIPS + +

+ + +

+ + +

+

4-

+ + + 4- +

SOFTWARE SETS

A - SPECIAL 0BS OPPS EXECUTIVES 6 - COMMAND PLANNER

B - USER REQUIREMENTS DATA BASE INTERFACE H - NE%"TIMELINE SOFTVARE

C - ED ITOR EXECUTIVES I-MODIE IED TIMELINE SOFT%'ARE

D - RESCHEDULER J - MODIFIED 0RBITAL MECHAN ICS S01:'TVARE

E - SYSTEM EXECUTIVES PHASE I E- MODIFIED DATA FL0%" SOFTWARE

F - SYSTEM EXECUTIVES PHASE II L - OUTPUT PROCESSOR EXECUTIVE

7-18

I

I

I

I
I

I

I

I

I

I

I

I

i

i

I

I

I

I

I

I

I

I

!

Also, LISP and PROLOG do not execute efficiently on VAX

hardware. Neither does ADA execute efflclent]y on a LISP machine. Therefore

the only two reasonable alternatives for software in a delivery environment is

LISP on a LISP machine or ADA on a VAX.

Norkstatlons or Tlmeshared Terminals

LISP machines are usually dedlcated workstations with a higher

unit cost than the multl-user environments of VAX hardware. VAX computers are

the best alternatlve for support of more than a few users.

7.7.2 ADA Language

Standardlzatlon of Software

ADA (ANSI approved MIL-STD 1815A) has been adopted as the

language to be used In all Space Station on-board system appllcations. Some

LISP programmers feel that this requirement will be waived for LISP subroutine

calls from an ADA supervisor. The official position Is not yet known.

ADA also interfaces more easlly with conventlonal code modules

11ke FORTRAN. Hhenever Interfaclng Is requlred between LISP code and

conventional code It Is usually performed by a hardware interface between two

dedlcated processors.

LISP is a powerful language well suited to solving some

problems; however, there are some arguments against LISP. Since LISP is a

relatively young language several dlalects exist. There is as yet no industry

wide standard, but DARPA has selected Common LISP. Common LISP contains a

small subset of the functlons available In Zetallsp (used on the Symbolics

mainframes). This reduced set of functlons 11mits the power of the language

and increases the amount of code the programmer must generate. Since the

language is extensible, programmers could build their own library functions.

But then the variations within subroutines written by different programmers

is a problem during integration of the larger program. This problem seems to

be solved by adoption of a standard, such as Common LISP, but the

extensibility feature is then lost.

PROLOG is also a powerful language well suited to solving

problems in logic. Japan has selected it as the basis for their Fifth

Generation Project, a new breed of computers they hope will replace current

processors. However, PROLOG is not widely used or accepted in this country.

Size Of Source Code

LISP code is roughly equivalent to the level of detail found in

assembly language for ADA. This translates to more lines for a LISP

programmer to generate for an equivalent function in ADA. LISP code also

requires a larger dictionary of functions. Commercial tools exist for LISP

which raise the level significantly, but processing speed is decreased

slightly due to the increased software overhead. Language flexibility is

also decreased slightly by the rigid structure of the tool.

7-19
7.7.3 LISP Lanquaqe

7.7.3.] Rapid Prototyping Environment

Less Time In EditlCompilelLlnk/Debuq Cycle

In conventional hardware file manipulation must be performed

between each cycle. On a LISP machine these utillties are all available under

the same monltor, so transfer from one cycle to the next Is Instantaneous.

User Frlendly Edltor

Many features, are easy to Implement on LISP machine edltors.

These include wlndows, graphlcs and syntax check and correctlon.

Dynamic L1nklnq

LISP elements may be manlpulated independent of the values of

those elements. Declaration of their value Is only required Just prior to

output of the flnal solution. In conventional programs all varlables must

have a declared value. No such 11mltatlon exists for a LISP machine which

performs dynamlc llnklng at runtime.

Interpreters and Compilers

Incremental compilers (interpreters) are efficlent, by industry

opinion, on LISP machines. Interpreters are also avallable for conventional

hardware, but are very slow and inefficient. LISP interpreters facilitate

debugging durlng compile.

LISP machines also support tradltlonal compilatlon of source

code files. Benchmark tests indicate that comp111ng increases execution speed

by 4 to 30 times and reduces source code size up to I/3 to I/lO of original.

Incremental Execution

This utility allows programmers to debug with the edltor as

errors are encountered during execution and then continue execution.

Incomplete Input Data

LISP listener environments a11ow programmers to execute programs

and have partial solutions returned which contain the undefined data.

Conventional programs will not execute without complete input data.

Dynamic Memory Management

Since memory a11ocations are performed at run tlme in LISP

machines the programmer does not have to declare these as in conventional

languages.

7-20

I

I

I

I

1

I

I

I

I

i

I

I

I

I

I

I

I

I
I

i

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

Supports Bottom-Up or Top-Down Design

LISP subroutines can be executed and wi11 return a value.

Conventional subroutines require overhead software to call the subroutlne.

Thls means software modules can be developed and tested at any time, even if

the modules above it in the hierarchy are not yet implemented.

LISP wlll also support top down design in the same manner as

conventlonal languages.

7.7.3.2 LISP Language Advantages

Function Library

12,000 functlons currently exist In Zetallsp, enough for nearly

every appllcatlon by today's standards. In addltlon, LISP Is extenslble by

the programmer. Extensibillty a11ows the user to add new functions to the

ex1stlng 11brary without having to change the compiler.

Encode Heurlstlcs

LISP 11sts and elements easlly encompass numbers and variables

used by conventional programs such as FORTRAN. Therefore, LISP can represent

a wlder variety of data types. The abillty to encode heuristics is possible in

ADA but Is slightly more straightforward in LISP.

Abillty To Implement Recursive Solutions

LISP functions can call themselves without limit. Thls is

difficult to implement in ADA or any conventlonal languages. This technique

has been Implemented to represent inflnlte series mathematical equations,

language syntax, and multidlmenslonal organ|zational trees.

7.7.3.3 Tools Available

LISP tools such as ART, KEE and Knowledge Craft a11ow the user

to code a large task with a limited knowledge of LISP. User interfaces are

extremely friendly and interactive. Tools do tend to be a large overhead which

uses up memory and slows processing time. But, a11 three vendors offer

production model shells with a reduced amount of code overhead. Some projects

like PLAN-IT were forced to code their own inference engine to get the needed

execution speed.

7.7.4 PROLOG Language

Predicate Calculus

Predicate calculus is the most widely accepted mathematical

language for modeling of logic based problems and theorems. Many of the

problems In the field of AI are heavily logic based, so predicate calculus is

the natural choice. LISP and ADA can implement predicate calculus equations

but implementation is more straightforward in PROLOG.

7-21

I
Parallel Processing

Parallel Processing has been proposed as one posslble solution

to speed up large complex software programs. However, the serial method of

solut|on in conventional software does not lend itself easily to division into

paralle1 tasks. PROLOG is exceptionally well suited to this dlvlsion by

a11ocation of each decision node to a processor. The processor could be

dedicated, for a massive computer by today's standards, or a11ocated from a

common pool of available processors. The precedent matching technique of rule

firings in a production system could also be divided into parallel tasks.

To date, no practical large scale systems have yet been

Implemented due to hardware 11mltat|ons. Current efforts of Japan's Fifth

Generation Computer project are focused in the fleld of building such

processors. Techniques for programming in PROLOG also need to be refined to

reduce the combinatorlal explosion problem in the solution search space.

7.8 RESULTS OF EVALUATION

The evaluation of each SS MPS task against the Desired

Attributes criteria produced a 11st of benefits and concerns for the

Implementatlon of each software set. These benefits and concerns are

summarized in subsection 7.8.1.

The summation and weighing of all evaluations performed

previously, resulted In the task methodology recommended for implementation.

This recommendation is shown on the bottom half of Figure 7.7-I and summarized

in subsection 7.8.2.

7.8.1 Benefits/Concerns

Each software set Is 11sted below accompanied by its:

Benefits - Those characteristics which will result in the

biggest payoff after the task is automated.

Concerns - Those possible pitfalls that must be avoided during

project development and implementation.

Set A - Special Obs Opps Executives

Benefits- Since expertise is scarce and it is expensive to train

an expert, automation and replication of this task will result in a big

payoff. Most functions are easily implemented which will result in a low

initial cost and high user acceptance of output data.

Concerns- There may be a minor difficulty in defining a method

for modeling a new user defined target currently outside of the knowledge base.

Set B - User Requirements Data Base Interface

Benefits- Since expertise is scarce and it is expensive to train

an expert, automation and replication of this task will result in a big

payoff.

7-22
I

i

I

I

I

I

I

I

I

I

I

I

!

I

I

I

I

I

Concerns- Problems may be encountered in correctly modellng the

experiment as descrlbed by the user. Definition of the Information extraction

technique may be dlfflcult. The user may become easily frustrated if the

system falls to dlalog Inte111gently wlth him. The cost of software

requlrements definltlon will be high due to the prototyplng phase and the cost

of a LISP tool. There Is no "generic" or "worst case" acceptance test

available so acceptance tests w111 have to be numerous.

Set C - Editor Executives

Beneflts - Automation would signlflcantly speed up this process

In a11 cycles of plannlng and save slgnlflcant manpower.

Concerns- None.

Set D - Rescheduler

Beneflts - Since expertise is scarce and it Is expensive to

train an expert, automatlon of thls task w111 result In a blg payoff.

Repllcatlon of thls task wi11 also result in a blg payoff since it is needed

at seven points in the MPS phases of plannlng. Interfaces are readlly deflned

since they are a11 in electronlc format. If the software is used only on the

ground (plannlng centers and the Payload Operatlons Integration Center), and

since the task boundary Is well deflned, it could be executed on a specialized

LISP processor and interfaced to the VAX.

Concerns - Several methods currently exlst for rescheduling.

Deciding on one strategy or set of strategies could be dlfflcult. Experience

has shown on several systems that the LISP inference engine must be coded from

scratch to obtain acceptable operating speed. This increases the level of

effort in prototyplng. However, several organizations have already developed

working prototypes to address thls problem.

Set E - System Executives Phase I

Benefits - Since expertise is scarce and it is expensive to

train an expert, automation and replication of this task wi11 result in a big

payoff. A Natural Language Interface (NLI) would be a powerful interface

tool. Several off-the-shelf commercial tools already exist.

Concerns - Defining and debugging the specialized vocabulary for

the NLI will require a large manhour effort. The experts allocated to the

task may not be motivated to debug the user interface down to the level of

refinement necessary for the user to accept and use the NLI. Since there is

no "generic" or "worst case" test for the NLI, acceptance will have to consist

of an extensive battery of tests. Several successful NLI's have been

developed, but they should st111 be considered a moderate schedule risk.

Set F - System Executives Phase II

Benefits - Implementation of the Apprentice/Advisor would result

in a tremendous manpower savings over the life of the Space Station. It would

be the primary step needed for future transfer of the bulk of mission planning

to on-board the station.

7-23

I
Concerns - The highly unstable and broad domain may be difficult

to model completely and accurately. The expert may be difficult to isolate

and motivate to invest the time needed to train the Apprentice. System

acceptance tests will have to be extenslve and confldence factors tested for

Planning Center and Payload Integration Center management to accept the

Advlsor output.

Set G - Command Planner

Benefits - Information in the SS MPS such as canned typical

command tlmelines may be very useful to the novice user. They impose no

restriction on the experlenced PI.

Concerns - Since expertise is a plentlful resource for each

dedicated PI and the time required to create a command timellne is relatively

short, the cost of encodlng Intelligent software to assist the user may not be

cost effective.

Set H - New T1mellne Software

Benefits - Tasks to be Implemented are straightforward

and do not require a large use of AI techniques.

Concerns- none.

Set I - Modified Timeline Software

Benefits - Tasks to be implemented are straightforward and

do not require a large use of AI techniques.

Concerns - none.

Set J - Modified Orbital Mechanics Software

Benefits - Tasks to be implemented are straightforward and

do not require a large use of AI techniques.

Concerns - none.

Set K - Modified Data Flow Software

Benefits - This task could be more flexible to a changing

Space Station configuration environment by using Object Oriented Programming

to model the individual hardware elements and the constraints and interactions

between the elements and the station.

Concerns - The major portion of the task is already

coded (SSDFAST in FORTRAN), therefore recoding into ADA would not be cost

effective.

7-24

I

i

I

I

I

I

I

I

l

I

I

I

!

I

I

I

I

I
I

I

I

I

I

I

I

I

I

i

I

I

I

I

I

I

I

I

Set L - Output Processor Executive

Benefits - This task could be more flexible to a changing

Space Station configuration environment by using Object Oriented Programming

and Design Capture to model the requirements for printing/display formats and

the constraints on each module of information.

Concerns - The major portion of the task is already coded

(PCAP and PTS in FORTRAN), therefore recoding Into ADA would not be cost

effective.

7.8.2 Methodoloqy Summary

Fourteen tasks were selected as candidates for using AI

techniques. Thirteen tasks are recommended to be dellvered in ADA on the VAX.

One task is recommended to be delivered on the Symbolics in LISP

wlth a hardware interface to the VAX. At a future date It should be ported to

the VAX prior to installation on-board the Space Station.

Machine.

MIPS.

Four tasks are recommended for prototyping on the Symbolics

Three tasks are recommended for implementation in the Spacelab

7.9 CONCLUSIONS AND RECOMMENDATIONS

7.9.1 AI Technoloqy

AI technology is still very young. The experience base of

expert systems performance is small compared to conventional programs.

However, the systems In existence do strongly support the many advantages of

incorporating this technology into the workplace. AI has proven effective in

solving many of the problems where conventional programs fail.

7.9.2 Hardware/Software Architecture

The conclusion to largely use ADA on a VAX is also supported by

a study conducted by MDAC-HB for the JSC Space Station Phase B contract.

The largest value of LISP and PROLOG is in the rapid prototyping

environment.

7.9.3 Software Tools

Use is recommended during prototyping of an expert system

development tool and a natural language development tool.

An in-depth technology survey, with the targeted MPS candidates

in mind, should be performed immediately prior to purchase of any

off-the-shelf AI tools.

7-25

I
THIS PAGE INTENTIONALLY

LEFT BLANK

7-26
I

I

I

I

I

I

I

i

I

I

I

I

I

I

I

I

I

I

Section 8

TASK 5 - SOFTWARE DEVELOPMENT PLAN

The objective of this task was to generate a Software (SW)

Development Plan for the definition, design and implementatlon of the SS MPS.

The approach taken to this task consisted of four subtasks.

First, assumptions Inherent In the generation of the SW Development Plan were

Identlfled; these pertalned to SW development fac111tles, computer operating

systems, coding languages and standards, required formal reviews, required

documentatlon, etc. The second subtask involved developlng a technical

descrlptlon of the project - SW requirements, SW hlerarchy, etc., and a

detalled descriptlon of the actlvlties required to successfully complete the

development project. Based on the assumptions of subtask I and the

descrlptlons of subtask 2, subtask 3 was performed to generate cost estimates

for Indlvldual or sets of required SS MPS computer programs in terms of

manpower and schedule using the Constructive Cost Model (COCOMO), and

Integrating these into project level manpower requirements and schedule

recommendations. The fourth and final subtask was to document and publlsh the

SW Development Plan.

Inputs to this study task were derived from:

- Task 3 products (SS MPS Functional Flows and SW

Requirements Summary)

- Task 4 products (AI recommendations and

implementation requirements)

- COCOMO Mode]

- Existing SW development plans (boilerplates)

The product of this task is the SS MPS SW Development Plan,

which constitutes Volume III of the Study final report. In summary, the SW

Development Plan documents requirements for a 4841 manmonth effort over a 64

month period to successfully complete the SS MPS software development project.

8-I

I
THIS PAGE INTENTIONALLY

LEFT BLANK

8-2

IIIIIIIiIIIIIIIIIII
I

I

I

I

I

i

I

I

I

I

I

I

I

I

I

I

I

I

I

Section 9

CONCLUSIONS AND RECOMMENDATIONS

Based on the results of the SS MPS Development Study presented

in the previous section, the following conclusions have been drawn:

I) A detailed definition of the Spacelab payload mission

plannlng process and SL MIPS software has been derived; this definition

(functlonal flow dlagrams and data base) will be of great value for training

Spacelab mlsslon planning personnel and for assessing and Improving the

process.

2) A basellne concept for performing SS manned base payload

mlsslon plannlng has been developed; this concept Is consistent with current

Space Station design/operations concepts and philosophles; however, those

concepts and philosophies are the results of Phase B studles and will

therefore gain further deflnltion and changes as the Space Station Program

progresses.

3) SS MPS software requirements have been defined. These

software requlrements make maximum use of SL MIPS software with modificatlons,

but do Include requirements for new software to accommodate the complexlty of

the SS mlssion planning concept and to maximize automation of the concept.

Also, requirements for new software include candidate programs for the

appllcatlon of AI techniques to capture and make more effective use of mission

planning expertise and to involve SS users directly in the mission planning

process.

4) ASS MPS Software Development Plan has been developed which

phases efforts for the development of software to implement the SS mission

plannlng concept. The efforts are phased for the immediate start of

development of long-lead-time software programs, but for delayed development

of programs with a high dependence on SS design/operations concepts. The

development schedule, relative to the current overall Space Station Program

schedule, indlcates the development effort should begin as soon as possible.

5) The estimated manpower requirements to develop the SS MPS

are signlflcant; however, the scope of the SS mission planning problem is

significant and the process of development is recommended to be highly

structured and rigidly controlled. Nonetheless, the software system concept

is intended to provide uniform methods of planning payload operations across

al__Zlequivalent planning levels in order to facilitate the integration of

planning, and is intended to maximize the automation of mission planning to

minimize long-term mission planning costs.

Based on the conclusions above, the following recommendations

are offered"

I) Use the definition (functional flows and data base) of the

Spacelab payload mission planning process and software to train mission

planning personnel and to evaluate and improve the process. As improvements

are made, update the flow diagrams and data base.

9-I
2) Proceed wlth implementation of the SS MPS Software

Development Plan, includlng the structured and controlled process for software

development.

3) Maintain the SS mission planning concept, software system

concept, and Software Development Plan consistent with SS design/operations

concepts and program schedules.

4) Use Spacelab mission planning as a test bed for testing

prototypes of AI applications.

9-2

I

I

I

I

I

I

I

I

I

I

I

I

i

I

I

I

I

I

I
I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

!

I

!

APPENDIX A

SPACELAB MIPS DATA BASE

The SL MIPS data base was developed in order to provide activity

summary data, software description and requirements data, and activity time

and skill requirements data. The level of detail of the data base is

consistent wlth the level of detail in the Spacelab mission planning process

detailed flow diagrams; that is, entries exist in the data base corresponding

to each lowest hierarchical level activity (function, subfunctlon, task or

subtask) identified for every function in the flow diagrams. When assessed in

conjunction with the detailed flows, the data base provides a comprehensive

definltlon of the Spacelab payload mission planning process.

The data base consists of eight (8) interrelated tables of data:

o

o

o

o

o

o

o

o

Activity Summary Data

Activity Time and Skl11 Requirements

Software Used by Actlvlty

Software Description

Software Peripherals Required

Activity Input/Outputs

Computer Input/Output Summary

Manual Input/Output Summary

Table ] provides the activity summary data which identifies an

activity and Its position in the hierarchy of activlties (function,

subfunctlon, task, subtask), the activity objective, method of accomplishment

(manual or automatic), and the need for the activity.

Table 2 provides the activity time and skill requirements data

which includes, for each activity, skill type and skill level, manpower

requirements and throughput calendar time for each cycle the activity is

performed. Time here refers to the total amount of time required to

accomplish the activity (data collection and assessment, analysis, computer

setup time required, and evaluation of results). The mission planning cycles

are, in sequence, preliminary (P), basic (B), update (U), and replanning (R).

Table 3 provides the software identification for activities that

are automated, and the required computer setup time for each cycle the

activity is performed. Time here is inclusive of time required for file

updates/edits, runstream development, and software interaction.

Table 4 provides a description and the resource requirements for

each software module. This table is linked to other tables in the data base

by software name. Data included are: software function definition, mode of

operation, skill requirements, language, lines of code, memory requirements,

and estimated CPU time. In this table, where a software name is followed by a

number (NAME-I), the number links the software to a particular activity in

other tables. A software module may be used to accomplish several different

activities; the difference in this table is the required CPU time.

Table 5 identifies the interface peripheral required by a user

to exercise a particular software module.

A-I

!
Table 6 provides an Input/output summary for all the activities

performed during the mission planning process. For each activity the

followlng data is provided: Input/output name, I/O form (computer or manual),

software module association, the I/O type (input or output), source or

destination of I/O, and an indication of which planning cycles utillze the I/O.

Table 7 provides summary data for a11 computer input/outputs. Data

included are: input/output name, file slze (maximum, minimum) and a brief

description of the data contained in the Input/output file. For some

Input/outputs only one entry is made for file size (minimum). These values

are provided as an average (typical) file size.

Table 8 provides summary data for all manual input/outputs. Data

included are: input/output name, type (form) of Input/output (verbal,

written, formal or informal document), name of document (if applicable) In

which the Input/output is published, and a brief description of the data

contained in the Input/output.

A-2

I

I

I

I

I

i

I

I

I

I

I

I

i

i

I

I

i

I

I
I

I

,I

I

I

i

I

I

I

I

I

I

I

I

I

i

I

I

i

TABLE l

ACTIVITY SUMMARYDATA
I

I

I

I =_"

,i

I =

i!_i ° _i=i_i

5

i Z

I

I

I

z

M

v _ .4

=

-.£ _8

,.,I

u

_8 =

I

I

I

I
o

z

0

t,

z
I

I

I
U _ U U

°° ! J i

i_ _ _ _ -_ -

_ z

i_ l.i "iili°ii _ i_

1

I

I

I
N

I

2I

II

I

II
_ U U U U U U U

1i.. o.;.o , ,o
I

I

i

i I

I

I

N

Z

@

I

I
U t.t

U

III

oI

z
IIII

__

I i _ - = ,,=, - s- | e | I,i- I.-

0

iu_v I IIII
i i N

z

,.,,.. - _- _.. ..

Z

_ ®_ -_ -
N_

8_ 8_ o_

Ii
v

u

__U__v

NZ

_v

_N

Z

IIIIi!Ii
mm

Z

_v

-_-_ _z8__

iI

z

I

_i_ '_

__ __o_

m
=lC0

IiiI
I

I

g

v

I

l

l

U

z

I

I
,0

b_z

¢nz

III!iIIi
I
!

I

I

i U U U i U '

o _ E = _ _

_ _ I

' ! _ _

_ _ _ _°_ _ _ > _ I

I

I

I

I
I

i

I

I _ U U ! U

i ° 'ii i!oo:: i

I _ _i -

E_e

I

I

I

_E

I

I
,(

I--

o

(// (// _ °

C=)

=_

,.=,-_ ..=.__

__ _._-

o_oo

I
II
f,...

CO0L

,IC

>-

o_ZN

,9C

__ _<_ __

li. Nz

,.=m

(/# i i °° i i IIIIiIIII! • IIIIIIIII
!!l IlIIlI!IlIllllII

TABLE2

ACTIVITY TIME AND SKILL REQUIREMENTS
!I
¢0

COo

,or o

N

MJ

,1¢

Q.

a¢ 0¢ Z "J" vX

I.M

_.o

¢I.

31[

v- v

NNNNNNNNNNNNNNNP_PP_P_NNNNNNNNNNN

t//

I.M

Q¢

UJ

_d

(//

-jN

I,-- N

,K

IM

Q. N

,,.,, UN

_U

__NNNN

_0000_

__-

NN_NNN_NN_

ww

I--

IIIIIIIIIIIItIIIIII
IIIIIII

_.

-g

I-

I°

9

I'

I°

I :::i

8_8_8

00

X_XX_

__-

N8

L)0

_8=

8._8

II
p,,.

¢0OO

• 1¢ a¢ z zv

..I

X

I,MO

a¢

a., NZ

NN NNNNNNNN NNNNNNNN

NNN

0.

bd

(/)

IMZ

h-- N

0 9¢
!I!I!i

°

II

N

U,

I

I*-- I_ I_ I-- i-- )*-

Q. '_ "Jm Q. Q_

II
I"-,.

cO

,.,lr

,ec

tts

.,ILU

UJ

I[N

(#) Z

LIJ

"Jr

t--

zZ

9¢X

Q.w

..J Q_

Q. Z

mm

o_

o_

z_

_,

_°

w

z_

_N

S _88

O

',4'

jiN

a.

I.LI a

U.

M f,_

G_

2,-.

)l,,- (I) "J.

I,--

,.,s_

},- ,_

J.-

_.88

O

..4"

)-

N

IIIIIIIlIItJ|IIIII
IIInIIIIIIIIIIIIII

r.-

_o

coo

t-_ Q. Z

uJZ

U_

_gN

rtZ

U3

",Jr

>-

12. z_

X

u3

LU0z

,

az

0Z

u

I-.

ILl d

>-

C.3

I.- U

,C

0m

00

uU

N

I
z

_

-'I,w ,,,

N_ ,r

rJ) I-* z w

:

N

IIIIIII
IIIII

p,..

00

¢0

I°

III

(/)

.J

Q¢

I _, N

f/JZ

tlJ

IXI--

>-

1--

IIIII

M,I

ZZXW

.J.

¢MO

,..J _¢

eL.

N

_o>*

¢M

Q.

>..

t_

>.-

_S

¢J

>.. U

>- N

NNNNNNNNNN_NNN_N_NNNNN,N_NNNNNNNNN

NNNN_ PP_PPPP_N

N

IJJ uJ LU

UJ ttJ UJ C__ ,-5

I
p,.

¢0

¢0o

¢_

,.... z

uJZ

uJN

,K

uJ

3[:

[,-

>-

I--

O

Q.*

ZZX

_.o

O., z

MJ

Q.

>-

I,--

U)

9[ >.- U

[,--

uJUU

NNNNNNNNNNNNNNN____NNNNNNNNN O O O O O O O

OOOOOOOO

N

IIIIIIIIIIIIIIIIII
!III g I

aa_ | I

Illii

III
N

cO

C3 gz

ul

-I. N0Z

_JXW

.Ji

_N

i

Q.

.-I.

_v

l,l

r,

__NNNNNNNNN_NNNNNNNNN

d_d_d_ Z Z Z z z z

IIIIIIIIIiIIIIIIII
IIIII

I

IIIiIIIIIIIII

TABLE3

SOFTWARE USED BY ACTIVITY
IIIII i =_

oooo

(,J | _ _ e ,.-7. _ , z I _

•,_ --

!-

-Jr5

0

o8

f_

(#')

1-

f,n

f,n

Ill

II
"_

Z

a Q-_

¢.2

_ ).- Q. _

Ni

cn0U

[m

uz

NN__

Z_z

0

_ O_

_ _0_

zz

¢_ u.I _ z

Q. I_0

000

z

I=-

,,>,_

,_=I.-- ¢f_ ¢/)_*-_

=_ =___

iN, ,_o

= ..=._.=

(_ I-.- ILl

__ ,.>,,,=, _._ =" _._

z

z

"O

-J_

IIIIIIIIIIiIIIIIII
IIIII

=_oooo ,,, ,-o | _ _ | _ o . i 1 , i 0 o i °- I " II
0

I,-,

m

I

II

il

I

I

oooooo o

° I

I

G

"- " I
II
I

!

I

I

I

_ __ "" ° ° ° ° ° ° ° ° ° + I

° I

° I

° i

; _ o _ o o o o o o o o o o o o

° i!

+' + --, _ _ +" _ _ I

..,-:- _ _ _ _ i I =_, • | ,', _. _ > _ _ _

+ -++- i I

+ + t I

_ _, _ _mm __ ,.- _-,. -

r_. '.+- < _ - ,,= _ _ _ _ ,m m _ ,+-'+r-. -- ..,+. m '-: _,

o++++ or+++,

+..+._ = ,,=, ,.., r+ ,,=, e--

" --, '_ m m < m ,,,.,

:+< - ++,.., +> +_ +> +,_ ..><. I
I

I

I

I

I

I _ i

_ i -_ •

!

z

r,

I

I

I

LI.I N

-- ac

_. =_

I..= ¢=_

(.3 )== _ _=3

w _ "'

Ik,l I=- Z

U

II

I
I

I

I

I

I

I

!

I

I

I

I

I

i

I

i

!

I

I

i

TABLE 4

SOFTWARE DESCRIPTION
III| _ I

°

II

i11 Zz

i

II
ILl

'I" t_d'
!!iI!

I.I.I

ut

I

0

I
0Mw

z

I!I
1I
laJ Z

•-,_o ,-,o o__o
IIIIII

no

N_

,'_ o.

ill

I" "_ N Zv

>._

uJ ,_

3[v

_p

uJZ

=.i

00

f- e-

__ooo

IIIII

o _,°° _>-, .___ _o_-__

¢._

II
¢O

c0

1.5 OO QIII z I " I

I_4 ill

Z2

GO

N I.--

,-_ ..._ ==___•

NN IJi4 {=3ZZ____ r=J_ZN i&/

l&/ z

r/)

X
1111

It

IAl

111

..J i Z

11
WI N

e_

iII
N

UJ _'PWw(/)

I°

IIIII

z

-I

_E _EZ

0

zz

2 II
N

CO

_rj

0

_ 9C

rlh 4"I

W

X

9C

Z

_E

_f3

c_
II Z II
uJ

z
II

z

-I I.I

II
uJ

3E

...e

u)

G_

Q_

0.

!III
II
P_

P_ONO

CO

IM

==v

,.=._ Z

qr_ Z

WN |

=I[

(3NzXz3

(I)

oOOO

f44 N

fJNm

,.=,

N

_=_ _oo

IIIIIIIIIIiIIIIIIi
I

I

I O_

q'- uJ

Z ,'*-

r_ _ z

i _0 _

0

uJ uJ

3E

0

N

w _

I

I

I

¢,J

2

I ,..

Z

I

_Z_

LU

I
N

hCOO

,,_ CL

C2

III

"' _EI

_zI

"I

IJJ lI4

z2

Ni! W

_

0

Z

uJz uJ

.J

UN

iii,

IIII
IIiIiI

('%1 uJ

C=,

_ >-_

.Jr >,.

uJ

3£: ,,.,*

(n

t.UZ

.J

v,- _0

OOOO°COO

w,-p

.4" .4'

t,rt O (:.

Im

N

N2

-,,,

¢#1v

III

ILl Z a¢

__-

uJ_

__

I

N

I
UJ

(jNN

w_ ""

z0

I-- Uz@

N

Z

X _J LU_ tv I-- O_S_ _lZ UJZ LLI

8

w
II

z

z

II
cO

P_

o

qc _

o o.

Z

Z

iv U
IIIIII

N

CO0

t-_ a.

NZ

"=_v

u,l COWZ

,=.,

.=.I

t._0 wi,_ m..

'_00 m0

N0 I_0

|! i_

'° ii i i

IJl.I

..J

z

Nz

IJ. I_

=_

=_

i.,-0

!i

t,_Z

w -z c_

tu

I,,-

_Cz

Oq

_CX

_C

z

z

Zw

IIIII

t// zN

_C

I,N

AO_ _-_. _e

_

!I
I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

I

i

I

TABLE 5

SOFTWARE PERIPHERALS REQUIRED
I

I

I

I

!

i

ii

I

II

I

I

11

I

I

i

!

I

l

!

I
N

3

0

Q.

N

0 "*

,v

_)

.-J

Q. Z

_ e

_ZZZ_

Z Z ZZ_ZX_ZXZZ_ZE_ZX_

Z
IIIIIII

i

IIIIIIII

IfII

TABLE6

ACTIVITY INPUT/OUTPUTS
III i i i i I _ _i

il_ i °

I

i !i i°"

IIIIIi

Z

Z

z

_z

3N _N 3N _N =3_

I--

N

L_ _ Co

II
f..

cO

c_

(/I

a.

zM ,,,,,I

I,=-N

U

._5_

_:=

OO

tu_ uJ

zzz

,r_

=_=

2Sz

z2N S= S= _=

go$ oo= oo=

_3g _Bg _3_

_>_ _>__

- _o_ <_ _ <0 0 - _

O_

2

35 35 35 $5 35

=_ =_ =_ =_ =_ <_ U U _ U

I!lIiIIIIIIIIIIIII
IIIIII

O,

t.5

r._ a.

zz*

_.zzzz

_*Zzzz

_:====

IiZ

Q,.

iiz

IIII

z

NOOOO

_" sXZ

LU _--

(J7 _. (/) Q.

Z

,_ ,v

_Q _O _O

(J7

XN

O.

_)

L_ I-.

)--Z

(_) Q. O

ZZZ

*.j

L_J

Q.

(_Q

t=-.

Z

wQ

fig w

O

N_

_N

0_

0

I
i°

0_

G_ S

_.=ZM

_J

_r ZSS

U

==

r_

,,=o

e,, N

_J

_A

e_

,,=.,.o

r,,

Q_

O_

U.I

IIIIIIIIIII
IIIiIIIIIiIIIIIIII

ao

o, Q

(/)S

Z_*

Q.

_X

UJ

3_

z_

0N (,j Zz _N

_

>-

>- _

Z

Z

Q. WN

_

_N

>- z

_

_.

z

>-

>-

>-

Q_ n0

uJ_

>-

>-

>- ZX

¢_O

_v

N

>-

LU

Z

_z

I.U

r.n

0

Q.

UJ Z

U.I

_2

z

>-

>- zO

Q. 2z

t_

uJN

(._ I,&l

>-

Q_ O

Q. z

u,IN

I
aO

r-Q

0.

a. ZN

0.

Zz,

NZ

UJ

.J

>-

_zN

][ZZ

4(

0000

MJ U (.1 (.t

U

r_

UZ

0000

z2

--i

uJ

IIIIII

I

III
IIII

_ _i ' i

I"

zz

u.l

III

=_

uJ t-_

_==_

I

>-

uJ

_=

1.1.1 z

ILl 0

Q.

UJ

G_=

=_

cJ

uJ

_J

)-

_J

.._ ,!-

=_

¢.}

.0=

=_

uJ

)-Z

L)

0

_N

0

111

)-

z

N_

u

I,--

uJ ¢'_ z _

z

Nz

z

0zw

LI

Z_

0

¢v

¢_1 z

I
cO

r_

CO

O,

GO S

Q. 5

Q. Z

ZZ_ 08N

N

I,--Z

.1

I,,,-O"

ul

Z

a.

,ag Z_

Z

_,-_ZZ

_a

Z_ a_

UZX

ZZZZ _-

Q. Q. _. Q. Q. i i i i i i i i

2_

IIIIiIIiIIII1IIIII
III

_,,=, _= LU

IIIII

,'_ uJ

Q. zN

.C

f_ i-.

,,pON

OO

O

O

i.u ,_

IIIII

G_ (/I _JN

{n

G_

_J

G_

_=_

_-_0O

I

z G_z

u

_=

,,=,

:2::

I.U

--JZQ

Z

r,=)

=_

l.uzO

_=

_=

>=

).-

>-

z_ _z _ _8

¢.=)

_=

_u

_=_

z

¢/) I-- O ¢n N _J

ZOZ C)

X

Nz

O

OO

i_i i--

Q.

u

>..

O

..I

Q.

..i

O

.J

¢.JzO

C) cc_

(-I

N.-

z I.- OZ zz zO

</)

C)

_=O

I
cO

O_

S

a.

o.

z

)-

N

G

0
IiI

II

li
Q

C2S

a. z

IiI
IIIIIIIIIIIIIIIIIl

cO

G_

a. NN

Nz

l_J

a_

Q. zZ0

=_

N-

=_

F-- N

F--

UJ N

=_0z

uJ

,,=,

_=_ z

z

>-oU

=_

==Zu

_z

_0_

_8

>- z

_NoN_

_8

_UZ

_zZ_

___-

0o

-=I

(.)

z

,,=,

c=)

F--

F.--

C_

U

_QW

_2Z_

WO_

_U_Q

Z

,vZ

i..=

C_

0--

_0

OZ

F--

I
CO0S

Q.

',,I"

z0Nz

wl

>-

_z

_NZ0z

Q,.

o. z

UZ_ 0

ul

z0

_z_

..I

..Jw .e_

H: _-- 0

t.u t.u (/1

(/)

uJ

)-

c_

0

8

z_

o_ _o_

_Jz

Q.

-_ i.J N M

o

s-zzO

LU

31:

Q.O

3EN

_J

N

U_

UJ

lIIII!IIII!II!I!!
• ,v Q_ Z

Q. Z I N I

-_N

(,')_

_Z

0_

_-- I

..Izz

z

(_z0

_.J0 uJ

)..

..J_ _/)

Xz

(..)

(J)v

z (_zN

I.- I_I z

8=

_. ,_J (/)

uJO uJ

zN

c.)

i-.8

_v

_C

u)

_C

b0zO

c.) w

_C

LUZ

_CO

)-

a_Z

Ud

I.-- _:K Z

L_I W L_J I
oOQ

4C qC

o.

)..

I--MG

III
IIIIIII

S

l--

N

N

s- OS

_E

III

i-N

00_0

_JX

II
cO

_2

Q.

=_N

>-

l--

III

°I

l,J lu

ud

Q.

I.-Zz3N

>-

)--

O_ "_

==

2__ U.I

_O _O

w

__=_ °__ -_-

_

IIIIIIIIII
III

N, )-

O,

N5 _- o

Q.

U

>,- :b- >-_ _. :p.

III

wN

I

w

-=

I
cOQ

c_ el

el5

ZNa

IJJ

e_

UJ

_z

r_ZN

I-.

Z

W

00_NN

iiiiiiii

r.J (.J 1.1 (.J l,.J (.J (.I (.J i-= I.-- X

_

IIII
IIIIII N

I',,, 0

_: u

z

I,tJ U

Q_

I

uJ

I--

0

X0N III 1

Q. z

II

N

I

fj) (,-) z

L_I I M I

Q_

Q..

UJ

,IQ_

t..U

.r _.--

I

01TwTN0zZ

n,I Z

ZTZ

z

>-

>- zz

18 r,

,>, .,

:zN

_,_

I
z_

N

)-

Q. I11

<S

Z

uJSS

Q. ZN

uJ

z

==o

o_

IIIIIII
IIIIIIIIIIIiIIIIII

_J

iN.,

cO

¢..

r._ Q= S

Q. S

Q= Z

_* 0

w_

o

d

0'_ I-.z

_S

a.

OZ

N_

z -,1 N _ _ z

z_

z

LQd_

w

2 '_

s" ..j

UJ•

$2

>- _ .J

_

ul I-. ¢,_ Od

0=N

_

Z ...I

z

z

8_5

I,=.-

,,-I,

20O ,v

_Z

98

zO

O_

Z_

O

_N

w_

,-iw

_J_

8_

X

u. _," z O

z

_v

t_w

_

,,=,80 0

2

>-

>- Oq

u= .'_

(,.5

"_0

0

_,.,,

_,J

I
Q

G_

ft. ZM

_=b

uJ

3

X0z

_E

___

_Z _Z _Z

O_ O_ O_

=G

_9

ILl U

Z

(Z)0

N_

U_

Iv

__iI

8

II
| iii

i ii

ZSS

I

N

55555 _,

ZZ Z_

_0 _0 _0 _0 _0 _0 _0 _0 _0

z

uJ

{/)

_t_0

I!
00oo

w

_0

zz,

_U, NU

NO

°

o

NOO

ZZZNN

w2

2__ R_ RR R_

O

IIIIIIIIIIIIIIIIII
§ | _

_

,i

III

lJr,

00000

eL Q. Q. Q. Q. Z "J* Z "_ :Z

0

_m

I

ddddd

w_

=,,.. U _t 0 5

I
f%i

cO

O,

e=. 0

,._ Q.

Q.

zz

)_:

_g:

.1

tfJzo

iiiiiiii

Z

Q. §zN

r, N

Z

0

IIIIIIIIiIIlIIIIlI
III d

i- | - _

_-_ -_-

"g

"' _=_= _,

g

I

=8

II
cO

O,

v.*

¢_

(_N

)-

_°N

Nz

0

_kJ Q=a

(,.)

_=

LLI I_=

QI:

UJN

I,IJ I--

UJ

0

0000

_S

Z0

Q. Q. Q.

¢.) ¢_U

Q. Z

>-

)--

UU°

_

U_u

z_

_0 _0 _0

_8..3ooo

_o _o _8 _o _8 _o _o

IIIIIIIIIIIIIIIIII
I

I

I

i =_=_ •

I _ _i

' i i i

0 0

Z

_., .v

0. a.

IS

z

I

3 3 3 3 3 3 _

= -- = = = _- = =_

X X

_0 _o _0 _o _0 _o w_ w_

Z

s-,

r.J

_J

0

-._

_.-

sO

ILl

_O

ss--

_J

0

W

I

I
Iii

_i

onSN

o.. zN

III
IIIII z

(n

,¢_ .e{

.._0

_ ,.,N - 1 u

q3

8

0u

_3

z

A

¢n0

I.--

I

z

v

0

¢nS

r_

n,,

t,l

--_0

_,- ¢J

2_

I
ZSz

5

(J

_JON

v

5_

5

U_MN

v

__ _0 _0

o30

_= usz

'"N

,,=,3 ,,=,3 0 _.9 0

o30

v

,v

_J
I

I

I

i _ o_

i °

i

I

I

i

I
CO

O,0

g.j S

Q.

I-- 5

uJ

¢C

Q.

I!I

 oo. o, i i i i i ,

ul

Q.

_m

Z0NS

Q.

00

U3

..J

>-

r_

r_ ,.,

U_

z8

IIiIIIII
m

a. uJ

m_

IN

Z I °z I ) I!

u

_J _J

88888"===

00_00

_8

u)Zz

,,.d, 8

,,"s,

I
f_

cON

Nz ¢J) u

LLI

Q.

,J0

Nz

a.

Mz

_.o

t_l

In

(/)

0

__0000

lu UJ LU _1

r, _. O. Q. 0 U

(/)

u.I

(/)

I--

U1z _n

_n

IIIIIII!IIIIIIIIii
I!I

CO

O_

I

LU

(-5

Q*

ZZ8

8_

I"

NZ

_°

I,-- 2

III!

uJ uJ

)-z

U r,_ w _

w

z

I
III

_.iI

§_I

_= ,- ,-=

!

Z0z

Z_

N

N

N

ZX

u. I--

IIIIIII
IIIiII

O,

_:

_,_ U

li

tu

wIIII

S

Q. U.I N -- 0N

I,J

wJ

III I !I!

z

GO

{..J z0

_=_ z Z

_=

z

u.i0

i--.

==X

i--- zN

_=_ N M Z _"

_=

_=

,Y

LIJ

==XzQ

_=_ z Z

_= _-

zN

_=_

=_X0z

X

zT i--

uJ

=_X

I_JT

_=_ z Z N

zZ

=_

I:

.=_ zN

Q. x

N

2X

0S

_=

,vZz

_=_

=

¢.} 0x

IJJ

uJ

_.=

_J

_=_

Go

5"

.J ._ z XiI zz0

r_Oz

Tim

Z

f_ u.

C_ w

z I
0 0 0 _ 0 0
III

Q_

§-_i li ii; i i i °

LIJ

¢_ -.-

0

II!II

zz

Z

G.

_C

(.I

Q.

I-N

u./ N u.l

z

Q. a. _. Q. Q. Q. i_. _. Q.

G. Q. i_. ,_ i_. Q. Q. Q. i_.

I

LU

I..- ¢n

UJ U./

¢=2 Q¢

_C

_=

c_

(J1

_C

uJ2

c_ _.-

uJ

uJz

(._ Q.

(.J

¢,.)

,Y

!
,no o

t.lJ

i.-

.qE

,-i M (I)

3E: zN

E,

i!I
II!II

It

itI

it!

zzNNzz

s-z0

z

s-- u,. z

_.z _-

z

I,=- N0zZ

>-

.=,J zN

N

---x_

I
Ul

O. uJ

>-

j..

N

N

ul ==

ul

@

<=

5

i iiiiiiiiiii

- . <<._ __ <<._ _ _ _ <<-_

ILl O_

_'_ _J

I

I

I
IIII

II_ i °

,.n

' i i i,, ¢. S

, -°i.°

zzX

Z

a.z

Z

0

oS

-_Z

Z

u. r._

C_

t.U0

I-.Ez

o.S

IIi

X_ X_

J:

>-

IIz0Z

wZz

'!"

n,

_-0

z_

>- 0n0ZzX

v

_8

>-

>-

>- z0

_n

(nN

LU

r_

Z

Z

"Jr" CL

(nT

8_

O. 2:

S£

UJ

>-

>- 0Z

=:

(11

u)

,_ >. o rv

>-

>-

>-

z

>- .-I

_8

uJz

=: X

(n0

it. f_l 0

uJ0

8_

o,£

#S

I
N

_C

IIIII

11tI
!

!

!

i ! .... o

! iii5

!

!

!

!

w ,v

0

e,

e..

e,

5

u.

0

!
z

N

d

N

! i ; i

-_ i _!-

S

o. uJ

S

- o ::

N

'I"

0

N

0 0 0 0 0 0

z

z_O Z_O z_O Z_O Z_O _0

!

l

!
II

II

II

IiI

II

f_I!

p,,.

00

a=

zz

,._ ,v

a,. Q,. gN ! ,

tz

I,- M

tl

i

_,_=o

o___

0

Z

e_

,0

o_

11

0

I.M

0

o_

,,'7

z0 !
zN

MG

0

_Q

!I
!!!!!!

cO

O_0

,._ Q.

zz

5_: U w

I°

a.

s11| Z

e_

!!!

),- ).._ )- )- ). )., 5

o___

_°N

N_0

0N

_ _° 0

SS==SSS

_5

u.I

E_

w

j,.,. Z

_C

r,_z

_N.,-

!
5

o.zN

w

00

wzN

0

0

t_ h5_0 ,.":

g_

O

II

I)I
III!!!
p,,.,.

00

,e,,,-

o r,

N

z

N

LU

(,..t

CO

(/1

ii ° _

= _ i- ®

_., _ _ _

U _ U
!!IIII!!|I!

GO

I.--

O. l&l Z N GO Z0Z

.-I

O. Z

I-.

!|
I.-.

X0NZZ

o. zN

o,5

uZ

N

_5

L_N

_,,x

2

2

_-x

"-i _u

,55 z

LU

III
m

!

,a

Im

Z

|

!

!

N

!

!
!

ii

I,,- N
!!

N

_. >- >- >- z0

tJJ

Q. _-- *loCi I--

0_0__000 --0 i i i i i i ! i _

ZS

Q.

Q. Z

|

I-- zN

Q.

"_ddd

dd_ _=doo8

u_w

I

sZ _--

o_

I--_ uZ

(.; u.

o_,

.-_0

_-- ¢C --

s* 3[ I-- 0 0 l-- --

I
O,

e.- 05G

,I[

N

,0

a.

N

3lX0z

I.-S

o_o

Z IJ _J

0

I_ _I. ;-. I.Q
!!!

Q. UJ

1°

)l- zZu

_

8_

I!

*

_MN

_J

!

Z

ul ul

IJ_

z

°..i __ _ x

'.Jr

ZZ

XXX_

NN N__ N_

!
i

"

MG

..o oSNG

M

_ou_

IIIIIIlI1lI
III

zz_

I ' NZ w tu

Ix

I_

-11

_*zz

-_

I_

IIt

,(

d

II

L&J (n

.,.iZ

u.I LJ :lC
!!!!!!!IIIIIIIIIIII

TABLE7

COMPUTER INPUT/OUTPUT SUMMARY
!I!!II!!

I U,I |z ! -

¢._

!I

11I1

z

I-

< +<_<

m<

__

+

11
^_

z

v

U

NX

I

o

I

N a_

!

0

UU_UUU

U

UU

IIIIIl
!B!!! z

II-

I-- I-- !!
iz
IIIIiI

z

I

i

!I
N

XZ

000

i°

(/) f._XXXX 3E

IIIII
II

II

II

III

II

t! i

^_

u.XZ

II

el Z

I-

I1

Uz

!
i2_

v

X

,_ZZ

000

00o

000

0

0

IIIII
!!!I uJ I

t_J z0

0,, N

N

uJ a.

!!
zN

!IIIIIIII
IIIIII

Z ILlh_

I"-_g

I

_

_ _, m

u=x

I

_=

O.

1z

=X

1!
z

ZZ
!I!!I!IIIII

z

L/J

F--

.--O

(.n

O..-

!!
u.

XZ

00

0 _rN

U _"
iIIIai,

!

'!

t

zU

!

^| _

N

_Z

_.| _ XZ

III

L_I Z

O.

a. Z

!!
i

IIm

II

liImI

II
II

I

I

z

§

z

I

!

III!II

(n

I_ | _

_

N

eL.XZ

!!!

z§N

!!
I!IIII

_-____ i_-

i!-

- !i1

___I
II

I11

Z

m_

00

II

IIIIIIIIIiIIIIIIIII

TABLE8

MANUAL INPUT/OUTPUT SUMMARY
II
zN

=_

=_

>

." _._ _-=> _-_

.v .v

(/)

,.=,
I

I

I

" i

_ _ N N

__-o _ !"

l - i _ ) °_

(_ (#)

m - -'

m _ I :-i -'-

!

I _. E E ° ._ °

I

I

i z

_m _mm

I

I
I'..-

cO

cO

,'. O.

III

zzX

=_

_=N
I

I

I

" I" = i =

I = -i + ! :. '._==+_ _ =+ I + = i _'--_ ° i '-,_ _ o'-= < _ ._,- <_-

| i .. <=="'- +_! <

| I- =' _. "...

I " =i,+ + -+ =i +°_<==__

i

! =

!

I - _ _ < < _ <

i ,.+. r_ B _ _- =" i+ i

! .

£

I

| I ! = _

= _ _. = _ •

I

I
.=_ z

z§z

N

_zzz
III

!

g|I "°_'"

_ _i_

II
oO

CO

0

a o.

3r.

@

O.

z

N

z

T

z
II

+

i!

I-

II

<

•,-_ ":

-+.++ +_

++ ,.,e.

m+mm

° ++++
i I

I I I I
II

+
z

°i o !

!

m

e _