DECEMBER 198Y

MDC H1343A

SPACE STATION DATA SYSTEM

ANALYSIS/ARCHITECTURE STUDY

Task 1

-Functional Requirements Definition, DR-5

|NAS_-CB-177838) SPACE STATICN DATA S_STEM

ANAL¥SIS/ARCHIT_C3ORE 5_UD¥. _ASK 1:

FUNCTIONAL RE_UIBfMEN_S DEFINITION, DR-5

_McDonnell-Douglas Astronautics Co.) 308 p

HE AI_/MJ_ A0I CSCL 22B G3/18

N86-20473
MCDONNELL_-----

DOUGLAS ,_'_'/--J

CORPORATION

SPACE STATION DATA SYSTEM

ANALYSIS/ARCHITECTURE STUDY

Task 1 - Functional Requirements Definition, DR-5

DECEMBER 1985 MDC H1343A

REPLACES MDC H1343

DATED OCTOBER 1984

REVISED MAY 1985

MCDONNELL DOUGLAS ASTRONAUTICS COMPANY-HUNTINGTON BEACH

5301 Bolsa Avenue Huntington Beach, California 92647 (714) 896-3311
PREFACE

The McDonnell Douglas Astronautics Company has been engaged in a Space

Station Data System Analysls/Archltecture Study for the National Aeronautics

and Space Administration, Goddard Space Flight Center. This study, which

emphasized a system engineering design for a complete, end-to-end data system,

was divided into six tasks:

Task I.

Task 2.

Task 3.

Task 4.

Task 5.

Task 6.

Functional Requirements Definition

Options Development

Trade Studies

System Definitions

Program Plan

Study Maintenance

McDonnell Douglas was assisted by the Ford Aerospace and Communications

Corporation, IBM Federal Systems Division and RCA in these Tasks. The Task

inter-relatlonshlp and documentation flow are shown in Figure I.

This report was prepared for the National Aeronautics and Space

Administration Goddard Space Fllght Center under Contract No. NAS5-28082

Questions regarding this report should be directed to:

Glen P. Love

Study Manager

McDonnell Douglas Astronautics Company

Huntington Beach, CA 9264?

(714) 896-2292

PRECEDING PAGE BLANK NOT FILMED

°o,

III
iv
Section l

Secton 2

Section 3

Section 4

Section 5

CONTENTS

EXECUTIVE SUMMARY

l.l

1.2

1.3

1.4

Methodology 2

SSIS/SSDS Concepts 4

SSIS/SSDS Functional and Performance Requirements 7

Conclusions and Recommendations II

TASK l DESCRIPTION 13

2.1 Purpose 13

2.2 Scope 15

STUDY METHODOLOGY

SSIS/SSDS CONCEPTS

4.1

4.2

4.3

17

4.4

21

SSIS Concept Assumptions 21

4.l.1 Controlling Documents 21

4.1.2 Customer Service Assumptions 21

4.1.3 Program Operating Assumptions 22

4.1.4 Program Phase Assumptions 23

Functional Topology of the SSIS 24

4.2.1 SSPE Identification 24

4.2.2 Space Station System Element Connection 26

4.2.3 SSlS/SSDS Functional Boundaries 32

4.2.4 SSDS/TMIS Boundaries 37

4.2.5 SSDS - Subsystem Interface Diagrams 38

Functional Architecture of SSIS 48

4.3.1 Data Flow Diagram Conventions 48

4.3.2 Characterization of the SSlS 52

4.3.3 Operation of the SSIS - How the

System Works 52

4.3.4 End-to-End Command Management and Data

Handling/Delivery 56

Operations Concept for the SSlS 67

4.4.1 SSlS Life Cycle Operations -

Customer Perspective 68

4.4.2 Operator's Perspective of SSIS Operations 90

4.4.3 Space Station Data System Build-Up

Scenario 125

4.4.4 Space Station Growth Scenario 152

4.4.5 Operational Design Drivers 158

SSIS/SSDS FUNCTIONAL REQUIREMENTS 161

5.1

5.2

Requirements Analysis Methodology 161

SSIS Functional Requirements and Design Drivers 165

5.2.1 SSPE Functional Requirements 165

5.2.2 Customer Requirements for Standard

Services from the SSlS 184
Section 6

Section 7

Section 8

5.3

S.4

5.5

SSDS Functional Requirements

S.3.1 Functional Requirements to Manage

Customer/Operator Delivered Data

(Function l.O)

5.3.2 Functional Requirements to Manage

Customer/Operator Supplied Data

(Function 2.0)

5.3.3 Functional Requirements to Schedule

and Execute Operations

(Function 3.0)

5.3.4 Functional Requirements to Operate

Core Systems (Function 4.0)

5.3.5 Functional Requirements to Manage

Facilities and Resources

(Function 5.0)

5.3.6 Functional Requirements to Develop,

Simulate, Integrate, and Train

(Function 6.0)

5.3.7 Functional Requirements to Support

Space Station Program

(Function 7.0)

5.3.8 General Design Requirements

Requirements Drivers

S.4.1 Impacts of Overall Data Rates

5.4.2 Real-Time Operation of Payloads

5.4.3 Automation

5.4.4 Scheduling

5.4.5 Level of Physical Distribution

Requirements Traceability

5.S.l Requirement Sources

5.5.2 Traceability Implementation

5.5.3 Traceability Report Examples

SUBSTANTIATING ANALYSES/TECHNICAL 3USTIFICATION

6.1

6.2

6.3

6.4

Review of Analyses Performed

Structured Systems Analysis - Level l

Data Flow Diagrams

MRWG Functional Requirements Analysis

MRWG Performance Requirements Analysis

TASK MAINTENANCE

CONCLUSIONS AND RECOMMENDATIONS

REFERENCES

DICTIONARY OF ACRONYMS AND TERMS

DEFINITIONS

187

187

190

198

201

213

215

222

223

231

231

233

234

235

236

237

237

237

239

243

243

244

259

264

273

275

279

281

283

vi
6LOSSARY

A

A&R

A/A

A/D

A/L

A/N

AC&S

ACA

ACO

ACS

ACS/COM

ACTS

AD

AD

ADOP

ADP

AFOSR

AFP

AFRPL

AGC

AGE

AI

AIE

AIPS

ALl

ALS

ALS/N

AMIC

ANSI

AOS

AP

APD

APSE

ARC

Automatic

Automatlon and Robotics

Analysls/Archltecture

Advanced Development

Alrlock

Alphanumeric

Attitude Control System

Attitude Control Assembly

Administrative Contracting Officer

Attitude Control and Stabilization

Attitude Control System/Communications

Advanced Communications Technology Satellite

Ancillary Data

Advanced Development

Advanced Distributed Onboard Processor

Advanced Development Plan

Air Force Office of Scientific Research

Advanced Flexible Processor

Air Force Rocket Propulsion Laboratory

Automatlc Galn Control

Attempt to Generalize

Artlflclal Intelligence

Ada Integrated Environment

Advanced Information Processing System

Alr Lock One

Alternate Landing Slte

Ada Language System/Navy

Automated Management Information Center

American National Standards Institute

Acqulsltlon of Signal

Automatic Programming

Avalanche Photo Diode

Ada Programming Support Environment

Ames Research Center

vii
ART

ASCII

ASE

ASTROS

ATAC

ATC

ATP

ATPS

ATS

AVMI

ANSI

B

BARC

BB

BER

BIT

BITE

BIU

BIU

BIU

BMD

BTU

BW

C

C2

C3

C3I

C&DH

C&T

C&T

C&H

C/L

CA

CAD

CAE

CAIS

CAM

Automated Reasoning Tool

American Standard Code for Information Exchange

Airborne Support Equipment

Advanced Star/Target Reference Optical Sensor

Advanced Technology Advisory Committee

Alr Traffic Control

Authority to Proceed

Advanced Telemetry Processing System

Assembly Truss and Structure

Automated Visual Maintenance Information

Adoptive Wafer Scale Integration

Bridge

Block Adaptive Rate Controlled

Breadboard

Blt Error Rate

Built-ln Test

Built-ln Test Equipment

Buffer Interface Unlt

Bus Interface Unlt

Built-ln Unit

Ballistic Missile Defense

British Thermal Unit

Bandwidth

Constrained

Command and Control

Command, Control, and Communication

Command, Control, Communication, and Intelligence

Communications and Data Handling

Communication and Tracking Subsystem

Communications and Tracking

Control and Warning

Checklist

Customer Accommodation

Computer-Aided Design

Computer-Aided Engineering

Common APSE Interface Set

Computer-Aided Manufacturing

viii
CAMAC

CAP

CASB

CASE

CATL

CBD

CBEMA

CCA

CCB

CCB

CCC

CCD

CCITT

CCITT

CCMS

CCR

CCSDS

CCTV

cd/M 2

CDG

CDMA

CDOS

CDR

COS

CE

CEI

CER

CFR

CFS

CG

CIE

CIL

CIU

CLAN

CM

CM

CMDB

Computer Automatic Measurement and Control

Crew Activities Plan

Cost Accounting Standard Board

Common Application Service Elements

Controlled Aceptance Test Library

Commerce Business Daily

Computer and Business Equipment Manufacturing Association

Cluster Coding Algorithm

Contractor Control Board

Configuration Control Board

Change and Configuration Control

Charge-Coupled Device

Consulttve Committee for International Telegraph and Telephone

Coordinating Committee for International Telephony and Telegraphy

Checkout Control and Monitor System

Configuration Change Request

Consultative Committee for Space Data System

Closed-Circuit Television

Candelas per square Meter

Concept Development Group

Code Division Multiple Access

Customer Data Operations System

Critical Design Review

Control Data Subsystem

Conducted Emission

Contract End-Item

Cost Estimating Relationship

Code of Federal Regulations

Cambridge Flle Server

Center of Gravity

Customer Interface Element

Critical Item List

Customer Interface Unit

Core Local Area Network

Configuration Management

Center of Mass

Configuration Management Data Base

Jx
CMG

CMOS

CMS

CMU

CO

COF

COL

COMM

COP

COPCC

COPOCC

COTS

CPCI

CPU

CQL

CR

CR

CR&D

CRC

CRF

CRSS

CRT

CS

CSD

CSDL

CSMA/CD/TS

CSTL

CTA

CTE

CUI

CVSD

CWG

D&B

DADS

DAIS

DAM

Control Moment Gyro

Complementary Metal-Oxlde Semiconductor

Customer Mission Specialist

Carnegle-Mellon University

Contracting Officer

Component Origination Form

Controlled Operations Library

Commercial Missions

Co-orbltal Platform

Coorblt Platform Control Center

COP Operations Control Center

Commercial Off-the-Shelf Software

Computer Program Configuration Item

Central Processing Unit

Channel Queue Limit

Compression Ratio

Change Request

Contract Research and Development

Cyclic Redundancy Checks

Change Request Form

Customer Requirements for Standard Services

Cathode Ray Tube

Conducted Susceptibility

Contract Start Date

Charles Stark Draper Laboratory

Carrler-Sense Multiple with Access/Colllslon Detection and Time

Slots

Controlled System Test Library

Computer Technology Associates

Coefficient of Thermal Expansion

Common Usage Item

Code Variable Slope Delta (Modulation)

Commonality Working Group

Docking and Berthing

Digital Audio Distribution System

Digital Avionics Integration System

Defense Acquisition Regulation

X
DARPA

DB

DBA

DBML

DBMS

DCAS

DCDS

DCR

DDBM

DDC

DDT&E

DEC

DES

DFD

DGE

DHC

DID

DIF

DMA

DMS

DoD

DOMSAT

DOS

DOT

DPCM

DPS

DR

DR

DRAM

DRD

DS&T

DSDB

DSDL

DSDS

DSIT

DSN

DTC

Defense Advanced Research Pro3ects Agency

Data Base

Data Base Administrator

Data Base Manipulation Language

Data Base Management System

Defense Contract Administrative Services

Olstrlbuted Computer Design System

Data Change Request

Distributed Data Base Management

Discipline Data Center

Design, Development, Testing, and Engineering

Digital Equipment Corp.

Data Encryptlon Standard

Data Flow Diagram

Display Generation Equipment

Data Handling Center

Data Item Description

Data Interchange Format

Direct Memory Access

Data Management System

Department of Defense

Domestic Communications Satellite System

Distributed Operating System

Department of Transportation

Differential Pulse Code Modulation

Data Processing System

Discrepancy Report

Data Requirement

Dynamic Random-Access Memory

Design Requirement Document

Development Simulation and Training

Distributed System Data Base

Data Storage Description Language

Data System Dynamic Simulation

Development, Simulation, Integration and Training

Deep-Space Network

Design to Cost

xi
DTC/LCC

DTG

E/R

EADI

ECC

ECLSS

ECMA

ECP

ECS

EOF

EEE

EHF

EHSI

EIA

EL

EM

EMC

EMCFA

ERE

EM!

ERR

EMS

EMU

EHUDS

EO

EOL

EOS

EPA

EPS

ERBE

ERRP

ESR

ESTL

EVA

F/T

FACC

FADS

Design to Cost/Life Cycle Cost

Design To Grow

Entity/Relationship

Electronic Attitude Direction Indicator

Error Correction Codes

Environmental Control and Life-Support System

European Computers Manufacturing Assoc.

Engineering Change Proposals

Envlronmental Control System

Engineering Data Function

Electrical, Electronic, and Electromechanlcal

Extremely Htgh Frequency

Electronic Horizontal Situation Indicator

Electronic Industry Association

Electrolumlnescent

Electromagnetic

Electromagnetic Compatlblltty

Electromagnetic Compatibility Frequency Analysis

Earth Mean Equator

Electromagnetic Interference

Executive Management Review

Engineering Master Schedule

Extravehicular Mobility Untt

Extravehicular Maneuvering Untt Decontamination System

Electro-optic

End of Life

Earth Observing System

Environmental Protection Agency

Electrical Power System

Earth Radlatton Budget Experiment

Equipment Replacement and Refurbishing Plan

Engineering Support Request

Electronic Systems Test Laboratory

Extravehicular Activity

Fault Tolerant

Ford Aerospace and Communications Corporation

Functionally Automated Database System

xii
FAR

FCA

FCOS

FCR

FDDI

FOF

FDMA

FEIO

FETNOS

FF

FFT

FIFO

FIPS

fl

FN

FMEA

FMECA

FO

FO/FS/R

FOC

FODB

FODS

FPR

FQR

FSD

FSE

FSED

FSIM

FSW

FTA

FTMP

FTSC

laAs

GaAsP

laInP

GaP

lAPP

Federal Acquisition Regulation

Functlonal Conflguratlon Audit

Flight Computer Operating System

Flight Control Rooms

Fiber Distributed Data Interface

Flight Oynamlcs Facility

Frequency-Division Multiple Access

Flight Equipment Interface Device

Floating Gate Election Tunneling Metal Oxide Semiconductor

Free Flier

Fast Fourier Transform

First In First Out

Federal Information Processing Standards

foot lambert - Unit of Illumination

Facility Management

Failure Modes and Effects Analysis

Failure Mode Effects and Criticality Analysis

Fiber-Optlcs

Fall-Operatlonal/Fail Safe/Restorable

Fiber-Optlc Cable

Fiber-Optic Data Bus

Fiber Optic Demonstration System

Federal Procurement Regulation

Formal Qualification Review

Full-Scale Development

Flight Support Equipment

Full Scale Engineering Development

Functional Simulator

Flight Software

Fault Tree Analysis

Fault Tolerant Multl-Processor

Fault Tolerant Space Computer

Gallium Arsenlde

Gallium Arsenic Phosphorus

Gallium Indium Phosphorus

Gallium Phosphorous

Geometric Arithmetic Parallel Processor

..°

Xlll
Gbps

GBSS

GEO

GEP

GFC

GFE

GFP

GFY

GIDEP

GMM

GMS

GMT

GMW

GN&C

GPC

GPP

GPS

GRO

GSC

GSE

GSFC

GTOSS

H/W

HAL

HDDR

HDDR.

HEP

HFE

HIPO

HIRIS

HMI

HM

HOL

HOS

HPP

HRIS

I

Gtgabtts Per Second

Ground Based Support System

Geosynchronous Earth Orbit

Gas Election Phosphor

Ground Forward Commands

6overnment-Furntshed Equipment

Government-Furnished Property

6overnment Fiscal Year

6overnment/Industry Data Exchange Program

Geometric Math Model

Geostatlonary Meteorological Satellite

Greenwich Mean Time

Generic Maintenance Work Station

Guidance, Navigation, and Control

General-Purpose Computer

General-Purpose Processor

Global Positioning System

Gamma Ray Observatory

Ground Service Center

ground Support Equipment

(Robert H.) Goddard Space Flight Center

Generalized Tethered Object System Simulation

Hardware

Hlgh-Order Algorithmic Language

Help Desk Discrepancy Report

Hlgh Density Digital Recording

Heterogeneous Element Processor

Human Factors Engineering

Hierarchical Input Process Output

Hlgh Resolution Imaging Spectrometer

Habitation Module One

Habitation Module

Hlgh Order Language

Hlgh Order Systems

Hlgh Performance Processors

Hlgh Resolution Imaging Spectrometer

Interactive

xiv
IIF

II0

IBM

IC

ICAM

ICB

ICD

ICDT

ICS

ID

IO

IOM

IDMS

IEEE

IEMU

IF

IFIPS

ILD

IMU

INS

IOC

10P

IPCF

IPC

IPL

IPR

IPS

IR

IR&D

IRN

ISA

ISA

ISDN

ISO

ITAC-O

ITT

IV&V

Interface

Input/Output

IBM Corporation

Intercomputer

Integrated Computer-Alded Manufacturing

Internal Contractor Board

Interface Control Document

Institute (for new generation) Computer Technology

Interpretive Computer Simulation

Interface Diagram

Identification

Intelligent Database Machine

Information and Data Management System

Institute of Electrical and Electronic Engineers

Integrated Extravehicular Mobility Unlt

Intermediate Frequency

International Federation of Industrial Processes Society

Injector Laser Diode

Inertial Measurement Unlt

Inertial Navigation System

Initial Operating Capability

Input/Output Processor

Interprocess Communications Facility

Interprocesses Communication

Initial Program Load

Internal Problem Report

Instrument Pointing System

Infrared

Independent Research and Development

Interface Revision Notices

Inertial Sensor Assembly

Instruction Set Architecture

Integration Services Digital Network

International Standards Organization

Integration Trades and Analysls-Cycle 0

International Telegraph and Telephone

Independent Validation and Verification

XV
IVA

IgS

_}PL

3SC

KAPSE

KEE

KIPS

KOPS

KSA

KSC

Kbps

Klpc

LAN

LaRC

LCC

LCD

LDEF

LDR

LED

LEO

LeRC

LIDAR

LIFO

LIPS

LISP

Lisp

LLC

LMI

LN2

LNA

LOE

LOE

LOS

LPC

LPS

LRU

LSA

Intravehlcular Activity

Intelligent Work Station

_et Propulsion Laboratory

(Lyndon B.) 3ohnson Space Center

Kernal APSE

Knowledge Engineering Environment

Knowledge Information Processing System

Thousands of Operations Per Second

Ku-band, Single Access

(3ohn F.) Kennedy Space Center

Ktloblts per second

Thousand instructions per cycle

Local-Area Network

Langley Research Center

Life-Cycle Cost

Liquid Crystal Dtsplay

Long-Duratlon Exposure Facility

Large Deployable Reflector

Llght-Emlttlng Diode

Low Earth Orbit

Lewls Research Center

Laser-Instrument Distance and Range

Last In First Out

Logical Inferences Per Second

List Processor

List Processor

Logical Llnk Control

LISP Machine Inc.

Liquid Nitrogen

Low-noise Amplifier

Level of Effort

Low-earth Orbit Environments

Loss of Signal

Linear Predictive Coding

Launch Processing System

Line-Replaceable unit

Logistic Support Analysis

xvi
LSAR

LSE

LSI

LTV

LZPF

M

pP

MA

MA

MAPSE

Mbps

MBPS

MCAIR

MCC

MCC

MCDS

MCM

MCNIU

MDAC-HB

MDAC-STL

MOB

MDC

MDMC

MORL

MFLOP

MHz

MIMO

MIPS

MIT

MITT

MLA

MMI

MMPF

MMS

MMS

MMU

Logistic Support Analysis Report

Language Senslty Editors

Large-scale Integration

LTV Aerospace and Defense Company, Vought Missiles Advanced

Programs Division

Level 0 Processing Facility

Manual

Microprocessor

Multiple Access

Managing Activity

Minimum APSE

Million Blts Per Second

Million Bits Per Second

McDonnell Aircraft Company

Mission Control Center

Microelectronlcs and Computer Technology Corp.

Management Communications and Data System

Military Computer Modules

Multl-compatlble Network Interface Unit

McDonnell Douglas Astronautics Company-Huntlngton Beach

McDonnell Douglas Astronautics Company-St. Louis

Master Data Base

McDonnell Douglas Corporation

McDonnell Douglas Mlcroelectronlcs Center

McDonnell Douglas Research Laboratory

Million Floating Point Operations

Million Hertz

Multlple-Input Multlple_Output

Million (machine) Instructions Per Second

Massachusetts Institute of Technology

Ministry of International Trade and Industry

Multlspectral Linear Array

Man Machine Interface

Mlcrogravlty and Materials Process Facility

Module Management System

Momentum Management System

Mass Memory Unlt

xvii
MMU

MNOS

MOC

MOI

MOL

NOS

NPAC

MPS

MPSR

MRMS

MRNG

MSFC

MSI

NSS

NTA

NTBF

NTTR

MTU

NASA

NASCON

NASPR

NBO

NBS

NCC

NFSD

NGT

NHB

NISDN

NIU

NL

NLPQ

NMI

NMOS

NMR

NOS

NS

NSA

Manned Maneuverlng Unit

Metal-Nltrlde Oxlde Semiconductor

Mission Operations Center

Moment of Inertia

Manned Orbiting Laboratory

Metal Oxlde Semlconductor

Multlpurpose Appllcatlon Console

Materlals, Processing In Space

Multl-purpose Support Rooms

Moblle Remote Manlpulator System

M1sslon Requlrements Working Group

(George C.) Marshall Space Flight Center

Medlum-Scale Integratlon

Multlspectral Scanner

Man-Tended Approach

Mean Time Between Failures

Mean Tlme to Repair

Master T1mlng Unlt

National Aeronautics and Space Admlnlstratlon

NASA Communications Network

NASA Procurement Regulation

NASA Baseline

Natlonal Bureau of Standards

Network Control Center

NASA FAR Supplement Olrectlve

NASA Ground Terminals

NASA Handbook

NASA Integrated System Data Network

Network Interface Unit

National Language

National Language for Queuing Simulation

NASA Management Instruction

N-Channel Metal-Oxlde Semiconductor

N-Modular Redundant

Network Operating System

Nassl-Schneldermann

National Security Administration

°°o

XVlll
NSF

NSTS

NTDS

NTE

NTRL

NTSC

Nd:YAG

OMI

O/B

OASCB

OCN

ODB

ODBMS

OEL

OES

OIO

OLTP

OMCC

OMV

ONR

ORU

OS

OSE

OSI

OSM

OSSA

OSTA

OSTDS

OTV

P&SA

P/L

PA

PAM

PASS

PBX

PC

PCA

National Science Foundation

National Space Transportation System

Navy Tactical Data System

Not To Exceed

NASA Technology Readiness Level

National Television Standards Committee

Neodyntum Yttrium Aluminum Garnet (laser type)

Operations and Maintenance

Onboard

Orbiter Avionics Software ControlBoard

Operations and Control Network, Operational Control Networks

Operational Data Base

Onboard Data Base Management System

Operating Events List

Operating Events Schedule

Operations Instrumentation Data

On Llne Transaction Processing

Operations Management and Control Center

Orbital Maneuvering Vehicle

Office of Naval Research

Orbital Replacement Unlt

Operating System

Orbit Support Equipment

Open Systems Interconnect

Orbital Service Module

Office of Space Science and Applications

Office of Space and Terrestrial Application

Office of Space Tracking and Data Systems

Orbltal Transfer Vehicle

Payload and Servicing Accommodations

Payload

Product Assurance

Payload Assist Module

Primary Avionics Shuttle Software

Private Branch Exchange

Personal Computer

Physical Configuration Audit

xix
PCA

PCM

PCR

PDP

PDR

PDRD

PORSS

PILS

PIN

PLA

PLAN

PLSS

PNAD

PMC

PN

POCC

POP

POPCC

POPOCC

PRISM

PSA

PSA

PSCN

PSL

PTR

QA

R

R&D

R&QA

R/M/A

R/T

RAD

RAM

RAP

RC

RCA

RCS

Program Change Authorization

Pulse Code Modulation

Program Change Request

Plaznka Display Panel

Preliminary Design Review

Program Definition and Requirements Document

Payload Deployment and Retrieval System Simulation

Payload Integration Library System

Personal Identification Number

Programmable Logic Array

Payload Local Area Network

Payload Support Structure

Power Management and Distribution

Permanently Manned Configuration

Pseudonotse

Payload Operations Control Center

Polar Orbiter Platform

Polar Orbit Platform Control Center

POP Operations Control Center

Prototype Inference System

Problem Statement Analyzer

Preliminary Safety Analysis

Program Support Communications Network

Problem Statement Language

Problem Trouble Report

Quality Assurance

Restricted

Research and Development

Reliability and Quality Assurance

Reliablllty/Malntalnabillty/Avallabllity

Real Time

Unit of Radiation

Random Access Memory

Relational Associative Processor

Ring Concentrator

RCA Corporation

Reaction Control System

XX
ROB

RDC

REM

RF

RFC

RFI

RFP

RGB

RID

RIO

RISC

RMS

RMSE

RNET

ROM

ROTV

RPMS

RS

RSA

RTX

S&E

S/C

S/W

SA

SA

SAAX

SAE

SAIL

SAIS

SAR

SAS

SASE

SATS

SBC

SC

SCR

SCR

relational Data Base

Regional Data Center

Roentgen Equivalent (man)

Radio Frequency

Regenerative Fuel Cell

Radio Frequency Interference

Request for Proposal

Red-Green-Blue

Review Item Disposition

Revision Item Description

Reduced Instruction Set Computer

Remote Manipulator System

Root Mean Square Error

Reconflguratton Network

Read Only Memory

Reuseable Orbit Transfer Vehicle

Resource Planning and Management System

Reed-Solomon

Rlvest, Skamtr and Adleman (encryptlon method)

Real Time Execution

Sensor and Effector

Spacecraft

Software

Single Access

Structured Analysis

Science and Technology Mission

Society of Automotive Engineers

Shuttle Avionics Integration Laboratory

Science and Applications Information System

Synthetic Aperture Radar

Software Approval Sheet

Specific Application Service Elements

Station Accommodations Test Set

Single Board Computer

Simulation Center

Software Change Request

Solar Cosmic Ray

xxi
SCS

SDC

SDP

SDR

SDTN

SE&I

SEI

SESAC

SESR

SESS

SEU

SFDU

SI

SIB

SIFT

SIMP

SIRTF

SLOC

SMC

SMT

SNA

SNOS

SNR

SOA

SOPC

SOS

SOW

SPC

SPF

SPF

SPR

SPR

SQA

SQAM

SQL/DS

SRA

SRAM

Standard Customer Services

Systems Development Corporation

Subsystem Data Processor

System Design Review

Space and Data Tracking Network

Systems Engineering and Integration

Software Engineering Institute

Space and Earth Scientific Advisory Committee

Sustaining Engineering System Improvement Request

Software Engineering Standard Subcommittee

Single Event Upset

Standard Format Data Unit

International System of Units

Simulation Interface Buffer

Software Implemented Fault Tolerance

Single Instruction Multi-Processor

Shuttle Infrared Telescope Facility

Source Lines of Code

Standards Management Committee

Station Management

System Network Architecture

Silicon Nltrlde Oxide Semiconductor

Signal to Noise Ratio

State Of Art

Shuttle Operations and Planning Complex

Silicon On Saphlre

Statement of Work

Stored Payload Commands

Software Production Facility

Slngle-Polnt Failure

Spacelab Problem Reports

Software Problem Report

Software Quality Assurance

Software Quality Assessment and Measurement

SEQUEL Data System

Support Requirements Analysis

Static Random Access Memory

xxii
SRB

SRC

SREM

SRI

SRM&OA

SRMS

SRR

SS

SSA

SSA

SSCB

SSCC

SSCR

SSCS

SSCTS

SSDMS

SSDR

SSDS

SSE

SSEF

SSIS

SSME

SSO

SSOCC

SSOCC

SSOL

SSON

SSOS

SSP

SSPE

SSPO

SSSC

SSST

STAR

STARS

STDN

STI

Software Review Board

Specimen Research Centrifuge

Software Requirements Engineering Methodology

Stanford Research Institute

Safety, Reliability, Maintainability, and Quality Assurance

Shuttle Remote Manipulator System

System Requirements Review

Space Station

Structural Systems Analysis

S-band Single Access

Space Station Control Board

Station Station Communication Center

Support Software Change Request

Space Station communication system

Space Station communications and tracking system

Space Station data management system

Support Software Discrepancy Report

Space Station data system

Software Support Environment

Software Support Environment Facility

Space Station Information System

Space Shuttle Main Engine

Source Selection Official

Space Station Operations Control System

Space Station Operations Control Center

Space Station Operation Language

Spacelab Software Operational Notes

Space Station Operating System

Space Station Program

Space Station Program Element

Space Station Program Office

Space Station Standard Computer

Space Station System Trainer

Self Test and Recovery (repair)

Software Technology for Adaptable and Reliable Software

Standard Number

Standard Technical Institute

o°,

XXllm
STO

STS

SUSS

SYSREM

Sl

SubACS

TAI

TBD

TBU

TC

TCP

TCS

TDASS

TOM

TDMA

TDRS

TDRSS

TFEL

THURIS

TI

TM

TM

TMDE

TMIS

TMP

TMR

TMS

TPWG

TR

TRAC

TRIC

TSC

TSIP

TSP

TSS

TT&C

TTC

Solar Terrestrial Observatory

Space Transportation System

Shuttle Upper Stage Systems

System Requirements Engineering Methodology

Silicon

Submarine Advanced Combat System

International Atomic Time

To Be Determined

Telemetry Buffer Untt

Telecommand

Transmissions Control Protocols

Thermal Control System

Tracklng and Data Acquisition Satellite System

Technology Development Mission

Tlme-D1vlslon Multiple Access

Tracking and Data Relay Satellite

Tracking and Data Relay Satelllte System

Thln Fllm Electrolumenescent

The Human Role In Space (study)

Texas Instruments

Technical Manual

Thematic Mapper

Test, Measurement, and Dlagnostlc Equipment

Technical and Management Information System

Triple Multi-Processor

Trlple Modular Redundancy

Thermal Management System

Test Plannlng Working Group

Technlcal Requlrement

Texas Reconflgurable Array Computer

Transltlon Radlatlon and Ionlzatlon Calorimeter

Trade Study Control

Technical Study Implementation Plan

Twisted Shielded Pair

Tethered Satellite System

Telemetry, Tracking, and Communications

Telemetry Traffic Control

xxiv
TTR

T_T

U

UCC

UDRE

UIL

UON

UPS

URN

UTBUN

UTC

V&V

VAFB

VAX

VHSIC

VLSI

VLSIC

VV&T

WAN

WBS

WBSP

WDM

WP

WRO

WS

WSGT

WTR

XOFS

YAPS

ZOE

ZONC

ZnS

Timed Token Ring

Traveling-Wave Tube

Non-restrictive

Untform Commercial Code

User Deslgn Revlew and Exerctse

User Interface Language

Untque Object Names

Uninterrupted Power Source

Untque Record Name

Unique Telemetry Buffer Unit Name

Universal Coordinated Time

Valldatton and Vertftcatlon

Vandenberg Atr Force Base

Virtual Address Exchange

Very High-Speed Integrated Ctrcutt

Very Large-Scale Integration

Very Large-Scale Integrated Ctrcutt

Validation, Verification and Testing

Wide Area Network

Work Breakdown Structure

Wtdeband Signal Processor

Wavelength Dlvlslon Multiplexing

Work Package

Work Release Order

Workstatlon

White Sands Ground Terminal

Western Test Range

XEROX Distributed File System

Yet Another Production System

Zone Of Exclusion

Zone Of Non-Contact

Zinc Sulfide

XXV
Section l

EXECUTIVE SUMMARY

The initial task in the Space Station Data System (SSDS) Analysis/Architecture

Study is the definition of the functional and key performance requirements for

the SSDS. The SSDS is the set of hardware and software, both on the ground

and in space, that provides the basic data management services for Space

Station customers and systems. The primary purpose of the requirements

development activity is to provide a coordinated, documented requirements set

as a basis for the system definition of the SSDS andfor other subsequent

study activities. These requirements should also prove useful to other Space

Station activities in that they provide an indication of the scope of the

information services and systems that wlll be needed in the Space Station

program. Key objectives of the requirements development task are as follows:

l ° Identify a conceptual topology and architecture for the end-to-end

Space Station Information Systems SSlS.

. Develop a complete set of functional requirements and design drivers

for the SSlS.

o Develop functional requirements and key performance requirements for

the Space Station Data System (SSDS).

. Define an operating concept for the Space Station Information Systems

SSIS.

The operating concept was developed both from a Space Station payload customer

and operator perspective in order to allow a requirements practicality

assessment.
I.I METHODOLOGY

The SSDS requirements task methodology emphasized the use of higher level

requirements that were developed in other Space Station activities. The

requirements methodology flow Is shown in Figure l-l. The primary sources of

higher level requirements were; (1) the mission, operations, and system

requirements from the Space Station definition and preliminary design RFP, (2)

the Customer Requirements for Standard Services from the SSlS document

prepared by GSFC, and (3) the Mission Requirements Working Group mission data

base. In addition, other Space Station documents, requirements developed on

other space programs, and industry study reports were used to identify

potential requirements. It should be noted that the RFP and the customer

requirements document were not available until late in the study task. The

requirements imposed by these documents were superimposed on a basic Jet of

requirements that had been developed earlier from the previous NASA studies,

industry studies, and functional analysis.

Cuaomer SSm

Requi_ments Openmlnll

(GSFC) Concqm

I ___m

Figure 1.1. Requirements Development Methodology Flow
To establish a context for defining and testing requirements, a concept for

the SSOS, and for a more encompassing Space Station Information System (SSIS),

was defined. The definition includes a description of the system topology,

its architecture, and an operational concept. The SSIS "topology" is a

description of the SSIS showing its elements and their tnterconnectlons, i.e.,

what the system looks like. The "architecture" describes the form of the

system as viewed by the customer/user, i.e., how the system works. The

operational concept describes scenarios for customer and system operator

interaction with the SSlS. The concepts that have been defined provide a

context for requirements generation and should not be taken as a

representation of the final architecture of the SSDS. However, certain themes

have been established in the concept that have been used to influence the

requirements and will be carried into the system definition task. These

themes include standardization of interfaces, elements, and procedures, an

end-to-end view of the system, a continual emphasis on customer

accommodations, and a cost versus benefit approach to autonomy and automation.

Given the SSIS topology, and the higher level requirements contained in the

RFP, the GSFC Customer Requirements for Standard Services document, and the

mission requirements data base, a detailed set of SSIS and SSDS functions was

identified and the associated requirements defined. A system analysis

technique called Structured System Analysis (SSA) was used to decompose high

level functions into lower level functions and to test the completeness of the

function set. SSA creates data flow diagrams that describe the information

flow and identify processes that affect information as it flows through the

system. The top-level data flow diagrams for the SSDS are included in Section

6.2. The functions llst and the associated requirements are contained in

Section 5 and in Appendix A. The operations concept was used as a cross check

on the practicality, completeness and adequacy of the requirements.

Functional requirements are presented In a hierarchical manner for clarity.

For the lower level functional requirements, requirements data sheets were

completed that defined, for that function, its meaning, criticality,

interfaces, and key performance requirement(s). This data is entered in a

computer data base and is presented in Appendix A.

3
Traceability of the SSDS requirements has been developed to show both

"top-down" and "bottom-up" traceability. The top-down traceability shows, for

each applicable requirement in the higher level documents, what SSDS function

defines and implements the corresponding SSOS requirement. Bottom-up

traceability defines, for each SSDS requirement that we defined, what its

higher level source(s) is.

1.2 SSIS/SSDS CONCEPTS

A model was established for the SSIS in the form of a topology of the

end-to-end information system for Space Station customer and operators,

encompassing both space and ground elements. The space elements in the SSIS

were defined to include the Space Station (base), the platforms, OMV, OTV, and

co-orbitlng free-flyers. Ground elements were identified to operate the

system and support the major end-to-end functions. These elements (or

functions) include Space Station control, platform control, OMV control, OTV

control, data handling, and customer data centers (regional data centers and

customer remote facilities). Added to thls were data distribution elements

and support elements to complete the end-to-end nature of the SSlS. Primary

information interfaces were identified to complete the functional topology.

The SSOS is defined as a subset of the SSIS. A set of criteria was defined to

determine the placement of SSIS elements Ins!de or outside the SSDS. The

intent of the criteria was to refine the study statement of work definition of

SSlS/SSDS boundaries, including consideration of NASA funding and

organizational patterns, and to exclude unique customer applications and core

systems functions from the SSDS. These SSIS/SSOS boundary definitions apply

to both space and ground functions. The primary criteria used were (1) the

perception of the SSlS element or function as a user standard service, and (2)

the perception of the element or function as a core service. In general,

elements or functions that met either of these criteria were placed in the

SSDS. Figure I-2 shows the SSIS/SSOS model resulting from the use of the

boundary criteria. A more detailed discussion of the criteria and the

SSDS/SSIS division is contained in Section 4.

4
Customers

I

Space

Station if--

:perat°rs II I

I

I

I

Unique _ I

Customer II I

Applicati°ns[! II

I

1

Standard

Customer

Services

I

I

1_

i w

I

k_

Customer and

Core Services

• Processing

• Data Transport

• Storage

• Operator Services

Institutional Services

oSTS

• TDRSS

• TMIS, etc

u.,qu.U I I

Payload I

Payload I1_ Sensors I

I I Applicationsll I and I

Iii ' JJ I Effect°rs I

I I

i I

"1i I

A 1' Subsystem Sensors i

q_'_Applicati°nsl _ 1 Effectors and I

I

[ I

J I

I

I

I

I

I

m m n u J

Figure 1-2. SSIS/SSDSModel

A key interface for the SSOS is with the planned Space Station Technical and

Management Information System (TMIS). While the TMIS fits at least partially

within our concept of the SSlS, we have defined the SSDS to be mutually

exclusive of the TMIS. The TMIS is expected ¢o be the primary repository of

Space Station program management and engineering data, and certain types of

operational data. SSDS functions use and access the TMIS data bases and, in

turn, provide data to the TMIS. Onboard crew, mission controller, and

customer access to the TMIS data bases may be provided through the SSIS.

The architecture concept for the SSIS is an explanation of how the SSIS works

in moving, processing, and storing data. The architecture description

provides a top level view of how the system manages commands, manages customer

and operator data, supports system scheduling and control, manages core

systems and resources, supports simulation, integration, and training, and

provides (limited) programmatic support. This top-level "how-it-works m

description gives an integrated overview of the major SSDS functions.
A concept of command management was developed that provides validation,

conflict checking to avoid undesirable payload interaction, and feedback to

ensure system integrity and safety while providing a high degree of autonomy

to the customer. In fact, customers should be unaware of the command

management process unless a real conflict is detected which precludes or

delays the execution of a command.

A more detailed view of the SSIS is provided in the discussion of operational

concepts, which is provided both from customer and operator perspectives. The

operations concept provides a view of the primary customer information system

needs and an operatlonal approach that is responslve to those needs. These

needs encompass system transparency, customer operational autonomy, data

integrity, system friendliness, and flexibility. An SSIS which has these

attributes can contribute greatly to the abtltty of the customer to maximize

return on hts space mission investment. The SSIS must also support the

overall program needs for crew safety, system integrity, and overall system

management, including a capability to resolve competing demands for system

resources. The operations concept described in Sectton 4 addresses these

customer and system needs for information services. A key feature of the

operations concept from the customer's perspective is the plan to allow a

customer to interact wlth the SSIS on his terms to the maximum extent

feasible. In other words, the customer can interact using nonspecialized

hardware and software, with mlntmal specialized training, from a locatlon and

at a time of his choosing, and with mtntmal operatlonal constraints.

The operator's perspective of SSIS operations describes a view of how onboard

crew members, ground controllers, planners, and system developers interact

with the SSIS, and how the SSIS supports their operations.

Autonomy and automation are important top-level themes that Influenced our

operations concept. Autonomy and automation are intended to improve cost

effectiveness, crew productivity, system performance, and reliability. These

techniques wtll be applied to our future architecture definition where they

produce clear advantages.
The SSIS provides resources to support long- and short-term planning and

scheduling. The TMIS provides supporting analyses and data bases in the area

of mission manifests and accommodation analysis. The short-term functions

wlll be shared between the space and ground elements with a capability to do

the daily activity scheduling and reschedultng onboard the station. As the

system matures, a higher percentage of the planntng and schedullng activity

will be performed on board.

The importance of standardization to the operating and architectural concepts

is apparent. The multiplicity and complexity of customer needs could drive

system costs and customer costs out of reasonable bounds if a standards

discipline is not imposed on the system. Selection of appropriate standards

can significantly help control system and customer costs for development,

integration, training, operations, and maintenance. Our theme for selecting

standards will be to use widely accepted commercial and international

standards in areas where they are available and to recommend the use of new or

evolving standards in other areas.

1.3 SSIS/SSDS FUNCTIONAL AND PERFORMANCE REQUIREMENTS

The key functional requirements for the broadly defined SSlS have been defined

and an assumed allocation made to Space Station Program Elements (SSPEs).

Drivers on the SSOS related to these requirements are identified. Functional

requirements for the SSOS were defined at a greater level of detail and key

SSDS performance drivers were identified. A traceability matrix was developed

to show the source of SSDS requirements in higher level documents and to show

the allocation of higher level requirements to SSDS functions.

The functional requirements allocated to _he SSPEs, that are not in the SSDS,

are complementary to the functions assigned to the SSDS. The identification

of these requirements provides an indication of the functional interfaces

between the SSOS and other program elements. The SSOS drivers that have been

identified are primarily related to (1) data rates, and (2) activity

scheduling. Mission aggregate data rates are clearly going to be a major

influence on the SSOS system design, affecting onboard acquisition and

storage, onboard communication processing, TORSS utilization, ground data

distribution, ground data processing, and data archlving provisions.
The complexity and simultaneous nature of mission tasks and the need to

consider several interrelated resource constraints will make activity

scheduling a challenge. SSDS provisions to support the activity scheduling

will be driven by these considerations.

Several customer standard services have been identified and have been

allocated to the SSlS (external to the SSDS). This allocation was made on the

basis that, (1) it was determined that the service will most likely be

implemented as a multlprogram (institutional) NASA service, i.e., not

dedicated to the Space Station program, or (2) it was determined that the

service should be offered as a customer option (extended service) because it

may not be universally needed. These customer services include ground

processing of customer data beyond GSFC-deflned Level 0 (time-ordered raw

data, separated by customer, wlth essential ancillary data), long-term data

archiving, customer-to-customer data exchange, customer facility work

stations, and certain long-term planning and programmatic data that is assumed

to be in the TMIS.

The SSDS functional requirements are organized into a hierarchical set of

functions under seven top-level functions as shown in Figure I-3. This

organization of functions is carried down to the third and fourth levels in

the SSDS functions list and is consistent with our data flow diagrams.

L"

Function l.O, Manage Customer/Operator Delivered Data, contains those

requirements related to payload and core data acquisition, tlme-tagging,

distribution, buffering, temporary storage, and display, including the

processing necessary to support these activities. Data accounting

requirements are included. Requirements for real-tlme and delayable data for

customers are addressed. Level 0 data processing is ayailable as a standard

customer service.

Function 2.0, Manage Customer/Operator Supplied Data, encompasses the

requirements associated wlth commands and other data that originate at the

customer or operator. These include command distribution and validation, and

ancillary data acquisition, formatting, and distribution. Also included are

customer support requirements related to payload pointing, payload control

processing, payload monitoring, and qulck-look data processing. OTV, OMV, and

payload checkout operation support requirements are defined.

8
v

o_

0 v

WZ

._ZZ

v

w ¢o

Z F6-

_8g

v

OOWW

-ZX_

_WO

W

W

_000

v W

LU WI--

Z

• . ._- .,_

U

vvvv

W

U

_W

ZZ_

• . _t_

_ _8 _ _oo _ _

• . . _

-_- ..._ _ ._ --_

"0

0

°_

0

0

0 _

4_

e"

E

I_" ¢"

_ J

o ._

L •

_. |

i

I,-

0

tU.

0

I,I.

g
Function 3.0, Schedule and Execute Operations, contains those functional

requirements related to developing generic and specific schedules, command

conflict checking, and the control of command sequences. Specific scheduling

products have been identified, including a typical day schedule, a short-term

schedule, and an operating event schedule.

Function 4.0, Operate Core Systems, contains the SSDS requirements which have

been collected to support core system operations, to provide crew support in

areas such as health maintenance, recreation, EVA, training, and safety, to

provide special onboard customer services, and to monitor both core and

customer systems. The special customer services include: monitoring of

contamination, venting, and the general payload environment; providing

relative alignment reference; providing current and projected ground track

information; and providing current and projected magnetic field information.

The system monitor and status functional requirements include caution and

warning and mass properties statusJ

Function S.O, Manage Facilities and Resources, contains the SSDS functional

requirements for managing space and ground data processing facilities of the

Space Station Program. The ground facilities include control centers, data

handling facilities, and support facilities. As part of this functional area

the SSDS is required to monitor customer usage of Space Station resources for

potential billing purposes. This function also includes SSDS requirements to

reconfigure facilities In response to operations or maintenance timelines or

system failures.

Function 6.0, Develop, Simulate, Integrate, and Train, contains the SSDS

functional requirements to support development, simulation, integration, and

training. This very broad set of requirements are interrelated In their

extensive use of simulation models. They are also related in that they are

primarily off-llne from the mission operations. These requirements are

intended to meet the majority of core system and customer needs for integrated

system simulations.

Function 7.0, Support Space Station Program, includes SSOS requirements for

support of programmatic activities such as logistic planning, operating manual

I0
maintenance, inventory control, and configuration management. The SSOS will

be closely coupled to the Technical and Management Information System (TMIS)

in this functional area. The exact allocation of functions between the SSDS

and the TMIS wtll need to be refined as the two systems become better defined.

In reviewing the SSDS requirements that have been defined, several areas

appear to contain the most critical drivers to the SSDS design. These areas

are related to (1) overall data rates, (2) real-time payload operation, (3)

automation and autonomy, (4) development, training, and simulation support, 5)

level of physical distribution, and (6) scheduling. In these areas, the

magnitude or complexity suggested by the requirements indicate that particular

attention should be paid to these areas in future study tasks.

1.4 CONCLUSIONS AND RECOMMENDATIONS

An overall concept has been defined for an end-to-end SSlS that includes all

major SSIS elements and functions. The concept, and the accompanying

operational concept for the SSlS, served as a context for validating the

completeness and correctness of the set of functional requirements.

Within the SSIS, the SSDS was defined by developing a set of boundary

criteria. The functional requirements for the SSDS were developed in detail

by identifying requirements in higher level documents, decomposing the

requirements through functional analysis, and allocating the requirements to

SSDS by use of the boundary criteria. Thls set of functional requirements are

soundly derived and are adequate to support the subsequent tasks of the study.

Key performance requirements were derived from the higher level source

requirements. SSDS design drivers have been identified in the requirements

set and can be used to properly focus the trade studies and system definition

activities•

Recommendations resulting from this task are as follows:

l • The operating and architectural concepts developed in this task

should be presented to Space Station operators and potential

customers for comment and feedback.

11
o The Mission Requirements Working Group data base should be refined

and expanded to provide more definitive customer requirements in

areas such as live television, remote real-time operations, ancillary

data type and quality, and data delivery.

1 A special emphasis study should be conducted to define customer

classes and a NASA interface scenario with the classes.

Results from these activities will enable requirements refinement and SSIS

operating concepts completeness.

12
Section 2

TASK l DESCRIPTION

The MDAC Team has completed the Functional Requirements Definition (Task l)

for the Space Station Information System (SSIS) design. The major products of

Task l are:

l .

.

3.

4.

5.

6.

7.

Top level end-to-end SSIS overall concept, including:

a. SSlS operational concept from both customer and operator

perspectives

b. Functional topology

c. Functional architecture

SSlS functional requirements

SSDS interface definition

SSDS functions identification

SSDS functional requirements

SSDS requirements drivers

Computer-based requirements traceability matrix

In addition, a relational data base has been created which includes design

characteristics of the functions, and will be extended during the remainder of

the study to include function assignment to end item and physical location.

This data base is reported in a separate document entitled "SSDS Functional

Requirements and Design Characteristics'. An example of the data contained in

this document is shown in Figure 2.1. The electronic data base contains the

output in four screens. These screens are merged into two pages in the

report. One page presents requirements and the other characteristics.

2.1 PURPOSE

Task 1 has been conducted to develop a top level, end-to-end SSIS overall

concept and to provide a coordinated, documented set of requirements to serve

13
. I:iii: i

.) Itliii II

m Ii oooooolloo

• | __t_aaa,_a;aa

o P.- -: c"_'g._c

%_ _ ,,, ,!I & 0.Iio .

! ! = .... °°-°

!,!.. c:" oE_J.l,_ -II

I C_ i _ II II II II II II II II

o_ 1; 'i u

• "" "ill _..'"

,C3 " aii

'+{II i ti i' ilt +- ,

i 1 t_,_ t tl

1

i i' ""'"'"' I

"I's +"" ' +_ °c)++c)++++°°

- oo.,,,2 >,+ < <i',+- iI <.,,-,-=.-<.+,.- .,-

_: i <'._-_,_.i_.

. i

I J liliililWkiO

_ 00000

0

U.

i2

0

&

14
as a basis for the development of the Space Station Data System (SSDS)

preliminary design. Results are documented in this report, principally in

Sections 4 and 5 and Appendix A.

2.2 SCOPE

This report presents the results of Task l - Functional Requirements

Definition, including:

The SSIS Functional Topology (Section 4.2) - Topology is defined as

the structure and interrelationship of the subsections of the SSIS.

The topology discussion identifies the physical elements comprising

the SSIS and how they interconnect. The role of each element is

defined, and top level functions are identified.

The SSlS Functional Architecture (Section 4.3) - Architecture

describes the functional form of the SSlS as viewed by the customers

and operators. The architecture shows how the SSIS works. The

architecture from Task l is preliminary and was developed to provide

a basis for further system analysis. Details of the architecture are

to be developed in Task 4.

The SSIS Operating Concepts (Section 4.4) - The operating concepts

supplement the architecture by describing how the customers and

operators use the system.

Functional Requirements (Section S) - The SSlS and SSDS functional

requirements define, by SSIS element and SSDS function, what must be

done to meet the Space Station requirements (Reference l), the

customer requirements for standard services (Reference 2), mission

requirements compiled by the Mission Requirements Working Group

(Reference 3), and the requirements implied by the topology,

architecture, and operating concepts.

SSDS Requirements Drivers (Section 5.4) identifies those functional

and performance drivers that are expected to have a major impact on

the SSDS designs.

16
The Requirements Traceability Matrix (Section 5.5) provides sources

for all functional requirements and top-down traceability of all

Space Station and customer requirements to responsive functions.

This allows functions to be related to system requirements,

establishing the scope of the functional requirements.

The complete functions ltst (Appendix A-4) and functional data sheets

(Reference 14) characterize the functions and define key design and

performance characterlstlcs.

The functions ltst (Appendix A-4) contains indications of functions

solely in the Space Station and its associated ground elements,

common to both Space Statlon and platform systems, and replicated

among the Space Station, platforms, and associated ground elements.

16
Section 3

STUDY METHODOLOGY

The Task 1 study methodology is illustrated by the diagram of Figure 3-I.

There are three principal sources of SSlS requirements indicated:

The Space Station Phase B RFP Statement of Work, Attachments C-2,

C-3, and C-4 (Reference l) - The final draft, issued September 15,

1984, was used to indicate the Space Station Program (SSP) scope and

Space Station mission, operation, and system requirements.

• The Customer Requirements for Standard Services from the SSIS

(Reference 2) - Revision }, dated September 19, 1984, was used to

indicate customer requirements for the SSIS.

Mission Data Base (MRWG)

' (pPeh_aCus_reSBtma_p) I

Customer

Requirements

(GSFC)

[ Task 1 Activity

I SSIS/SSDS Functions

I

"F TraMe_Ixllty

"_ Requirements

]

i

I i

!

i Other Documents ]

i GSFC Data Sys Concepts II

JSC SS Avionics ]i -I

JPL SSIS Study i_ --J

Y.llow Books I _-JL-J

GSP Bk 3, 6 T

Structured 1 i

Systems

Analysis i

-( 1 I

_1 SSDS

_] Requirements Functional i

SSIS

Functional

L[

I I

L._

SSlS

operating

concepts

_J

Figure 3-1. Requirements Definition Methodology

17
Space Station Program Mission Requirements (Reference 3) - The

Mission Requirements Working Group (MRWG) compilation of mission

requirements, dated March 15, 1984, was used to indicate typical

mission support requirements and key performance requirements to

meet mission demands.

The explicit and implicit SSIS functional requirements from these documents

have been combined with requirements resulting from the Task l analyses to

form functional requirements (Section 5.2). The development of these

requirements was facilitated by two principal analyses:

The development of a top level, end-to-end SSIS concept, including

topology, architecture, and operation•

Structured system analysis, identifying the logical functions of the

system and their interrelationship (Section 6.2).

The next step was to develop SSDS functional requirements (Section 5.3).

Development of a complete set of performance requirements and an SSDS

specification was deemed to be a part of the Task 3 and 4 effort. However,

much of the groundwork for the SSDS specifications was laid in Task l.

Specifically, the team has

• Developed a complete 11st of SSOS functions which meet the

functional requirements of the SSIS and References l, 2, and 3.

o Performed complete Level 1 and limited Level 2 and 3 structured

systems analyses to define and scope these functions•

o Mapped requirements from references l, 2, and 3 to the functions

llst and developed a complete traceability matrix showing this

mapping•

e Developed functional and key performance requirements for each

function at the appropriate level from References l, 2, and 3,

other NASA documents, and the team data base.

18
o

Identified additional source documents supporting the need for

and requirements on each function.

. Perfomed engineering analyses of mission requirements to derive

key SSDS performance requirements.

The results of these analyses are collected in the data base in Appendix A and

Reference 14. The complete data base Is available in the VAX computer at MDAC

Huntington Beach in the Smartstar data management system. In Smartstar, the

data base can be updated, supplemented by performance and design data from

Tasks 3 and 4, manipulated to generate key parameter reports, and accessed by

NASA and team members.

The above work was greatly aided by prior and concurrent studies conducted or

sponsored by the NASA. Table 3-I shows some of the more frequently used

documents and the portions of the Task l activity to which they were most

applicable. The scope and depth of this prior work helps assure the

completeness and correctness of the Task l products.

Table 3-1. Prinicipal Documents Used in Task 1

Usage

Developing Structured SSDS SSDS

SSlS systems SSIS SSIS/SSDS Traceability functional performance

Document Reference concept analysis requ_ements functions matrix requirements requirements

Space station RFP

Customer requirements

for standard services

Mission requirements

SSDS RFP

Yellow book 3, 6

JSC 18740

GSFC data system concepts

JPL D1737

Space telescope

Global positioning system

TDRSS

EOS status review

5

6

7

8

9

10

11

12

13

,/

,/

,/

,/

,/

,/

,/

,/

,/

,/

,/

,/

,/

,/

,/

,/

,/

,/

,/

,/

,/

,/

,/

,/

,/

,/

19
Section 4

SSlS/SSOS CONCEPTS

A top level, end-to-end SSIS overall concept was developed in Task l. This

concept is described from five perspectives:

I)

2)

3)

4)

s)

Functional topology (what the system looks like)

Functional architecture (how the system works)

Operations from customer perspective

Operations from a system operator perspective.

Operations from buildup and growth perspectives.

Each of these concept descriptions emphasizes the complete, end-to-end data

flow. Identification of all of these data flows and all of the interactions

customers and operators will have with the system ensures adequate breadth for

the requirements. Decomposition of functional requirements can then be

performed with confidence in the completeness of the scope.

4.1 SSIS CONCEPT ASSUMPTIONS

The key assumptions that guided the development of the SSIS concept are

discussed below.

4.1.1 Controlling Documents

References l, 2, and 3 were selected as controlling the scope, function,

performance, and design of the SSlS and SSDS.

4.1.2 Customer Service Assumptions

Customers include all authorized users of Space Station program, engineering

and payload data or products for scientific, commercial, or technological

21

PRECEDING PAGE BLANK NOT FILJ_ED
purpose. Potential Space Station customer operating requirements affecting

customer service functions of the SSlS include:

Customers will want to access SSIS services from onboard the Space

Station or any of several ground locations, including the customer's

own facility and facilities provided by the program and NASA.

Customers will want to operate their payloads interactively in real

time. This operation may include coordination between onboard and

ground operations.

Customers will want to choose from a variety of data return means to

satisfy operational and economic constraints.

Customers will require quick-look payload data to ensure proper

payload functioning.

Customers will desire interactive involvement in system schedule

development, including real-time adjustments to accommodate targets

of opportunity.

Customers will require system support throughout the phases of their

programs from inception through development integration, activation,

operation, and closeout.

Customers will have a variety of technical backgrounds. The system

must be user friendly in order to accommodate all customers. It must

facilitate their use of the system, minimize the need for special

training, and maximize Space Station program productivity.

4.1.3 Program Operating Assumptions

The Space Station Program includes multiple ground and orbital elements

operating together. Key operating assumptions affecting the function of the

SSIS include:

The Space Station navigates using GPS.

navigation.

TDRSS provides backup
Space and ground elements communicate primarily through the Tracking

and Data Relay Satellite System (TDRSS). One, two or three Ku-band

Single Access (KSA) and S-band Single Access (SSA) channels must be

shared at least among Space Station Program Elements (SSPEs). A Task

3 trade study will examine these alternatives.

The Space Station is normally operated onboard, with capability for

at least limited operation from the ground.

The Space Station will provide data relay and navigation and control

services for constellation elements.

The ground system will handle data for all SSPEs.

The system will support SSPE growth, expansion, and upgrade.

4.1.4 Program Phase Assumptions

The Space Station Program requirements on the SSIS will vary during the

program phases. The following assumptions characterize the relationship

during the development, buildup, and growth phases:

Development - The SSIS/SSDS will be developed in parallel with the

modules, subsystems, ground facilities, and space elements. Portions

of the SSIS may be available to support SSPE prelaunch verification,

but the complete SSIS will not be operational until IOC. Simulation

and integration test software and hardware developed for the

integration tasks are assumed to be useable in the ongoing "Develop,

Simulate, Integrate, and Train' function, especially the Software

Support Environment (SSE).

Buildup - The SSIS capability to support remote operation of the

Space Station and platforms must be in place at the beginning of the

buildup phase. The initial Space Station module(s) transported to

orbit is assumed to be unable to support continuous occupancy. The

start of continuous operation will follow an on orbit integrated

system test. IOC and continuous occupation are assumed to be

coincident.

23
Operation - The SSIS will fully support the continuing operation of

the Space Station Program (SSP). The SSOS will support operation of

the Space Station and its ground facilities, and coordinate

multiprogram support services. The SSOS will support customer

payload com_nd and operation and deliver customer payload data. The

SSIS will provide additional Standard Customer Services in support of

customers throughout their involvement with the SSP.

Growth and Evolution - The SSIS will fully support the growth and

evolution of the program and its associated elements. Growth and

evolution includes adding new Space Station modules, adding new

SSPE's, automating functions, relocating functions, expanding

services, and improving system operation. The SSIS will support the

development and verification of hardware and software to achieve

growth and evolution, in addition to supporting operation of the

system.

4.2 FUNCTIONAL TOPOLOGY OF THE SSIS

The functional topology of the SSIS shows the functional elements of the SSIS

and their relationship. The topology was developed by first identifying the

SSPEs, determining their roles, and identifying relationships. This

functional topology represents a baseline to be used to develop SSDS

requirements. Allocation of specific functions to systems, subsystems and

facilities will be developed in Tasks 3 and 4.

4.2.1 SSPE Identification

SSPEs were identified from References l and 2, the assumptions of Section 4.1,

other prior Space Station and Data System Studies, and system analyses of the

SSIS. Table 4-I shows the SSPEs identified and their sources. The SSPEs and

roles thus identified provide a context for the SSlS. These SSPEs are used to

develop the SSIS topology and their roles are used toaid definition of the

SSDS element functions.

24
Table 4-1.

Space station

program element Sources

GPS RFP 1

RFP

Polar platform (POP) RFP

POP control RFP

Coorbiting platforms (COP) RFP

COP control RFP

Free fliers RFP

Free flier control Analogy to RFP

Space station RFP

RFP

RFP

CRSS 2

Space station control RFP

RFP

TDRSS RFP

CRSS

Network control CRSS

Data distribution network CRSS

Data handling center Engineering

Analysis

OMV RFP

OMV control RFP

OTV RFP

OTV control RFP

I "

Space station payloads RFP

Customer, subcontractor RFP

Discipline data centers CRSS

CRSS

Remote customer facilities CRSS

Space station engineering RFP

data center CRSS

NSTS orbiter RFP

RFP

NSTS mission control CRSS

Deep space network RFP

Space Station Program Elements, Sources, and Roles

Parasxaph

number Roles

C-4- 2.2.5.3f

C-4- 2.2.6.2k

C-2- 2.3

C-3- 2.4g

C-2- 2.2

C -3 - 2.4g

B- 2.12d

C -3 - 2.4g

C-2- 2.1

C-4- 1.2

C-3- 2.1c

6.1.22

C-3- 2.4g

C-3- 2.4j

C-4- 2.2.6.2g

0.1

0.1

2.2.3.4,

3.1.2.1

N/A

C-3-1.1 c

C-3-2.4g

C-3-2.1 d

C-3-2.4g

C-2-2.1

C-3-2.4g

3.3.2

3.4

6.1.2

C-4-2.2.5.3e

4.1.1

B-2.12a

_:-3-2.1 f

0.1,7.1.2

C-4-2.2.6.2g

Stable time and frequency reference

Navigation signals

Base for multiple payloads

Routine platform planning and operations

Base for multiple payloads

Routine platform planning and operations

SSPE's

Routine free flier planning and operations

Base for multiple payloads

Laboratory and crew habitation provisions

Service/maintain OMV

Operate customer payloads

Coordinate SSP operations, planning and support

Provide essential ground operations capability to

space station

Space station - ground communications

Platform - ground communications

Coordinate uplink/downlink service requests

Provide transparent data link between customer

and onboard equipment

Required to separate/merge and buffer customer and

core data steams

Orbit maneuvers for satellite/platform servicing

Onboard and ground locations are required to control

OMV o per atio ns

High energy orbit payload transfer

Ground location is prepared to control high energy orbit

injection and return

Perform science and applications, commercial and technology

Development missions

Routine payload planning and operations

Routine customer data processing

Maintain customer data archives

Command customer payload operation and data handling

Archival storage of core system data

Provide stored and processed data to customers

Primary means for launch, access and resupply

Tend initial and growth space station

Long term rendezvous service planning, support

Provide contingency command and telemetry link

Launch integration site RFP C-3-2.3a

Contractor facilities Engineering N A

analysis

Development, simulation RFP C-3-2.3b

and training RFP C-3-2.3d

RFP C-3-2 .5

CRSS 1.1.4

Other communications links RFP C-4-2.2.6.2f

CRSS 1.1.10

Technical management RFP C-6

information system

EVA (MMU, EMU) RFP C-4-2.2.11

Provide launch readiness verification

Provide pre<lelivery verification and integration test

Use flight system to reduce GSE for testing

Insure modifications and upgrades interface and

function correctly

Provide ground and onboard crew training

Provide focal point for customer payload integration

and test

Provide customer payload-ground communication

independent of TDRS/TDAS

Provide program management services

Provide SSP, engineering, operations, administrative

and descriptive information

Bill customer for services rendered

Assembly, maintenance, servicing, repair of SS,

1) Space station definition and preliminary design, RFP, September 15, 1984. platforms, structures, satellites, and vehicles

2) Customer Requirements for Standard Services from the SSIS, revision 1, September 19, 1984

25
4.2.2 Space Station System Element Connection OF POOR QUALII_

The SSPEs and their interconnection are shown in Figure 4-1. The SSPEs are

derived from those of Table 4-1. Their relationships to the SSIS are

discussed below:

Global Positioning System (GPS) - The GPS is a system of satellites

emitting signals which allow accurate determination of position and

velocity. The Space Station, platforms, free-flyers, and the OMV and

OTV are presumed to be able to navigate using GPS. GPS also provides

an accurate time and frequency reference.

Polef

Ptatfoim

Spice

Station

Customer

Payloads

IllIoI Ilalllll, (Customer %

Slnmtem Ccmlml Option)

%

Constellation

Control

Space Station

Control

Data

Handling

EVA

..... Grow_ Caplettity

----- O_lonm Camaetllty

r I

TDAS I

TDRS J

NSTS

Orettllr

Other S|telllta

DOMSAT

J Launch

Integretlon

U

Data Distribution Network

0

I-IF- i

Plat _orm Other Plllt|olrm

Control Satellite Control

Ground

Station

DataReglonlml Canters I

(c.om.\

Option)

Figure 4-1. Space Station Program Element Interconnection

Polar Platform (POP) and Control - The POP is a polar platform in

sun-synchronous orbit which will be used primarily for earth and

atmospheric observation. POP has no direct orbital communication

with the Space Station, but will coordinate some observations and

share some ground data handling facilities. Both will relay data to

the ground through TDRSS KSA channels. Since the Space Station and

26
POPneed not transmit simultaneously, a single ground Data Handling

Center and network sized to handle 300 Mbps could distribute data for

both systems. The POP will be joined by other satellites which may

similarly share the ground Oata Handling Center. POP and these

additional satellites will be controlled from their own ground

control centers.

e Co-orbiting Platform (COP) and Control - The COP is a platform in low

inclination, low earth orbit. Early payloads are primarily

astronomical and solar observatories. Other platforms, providing

bases for multiple payloads, may be added. When in line of sight,

the platform(s) may use the Space Station to relay data to and from

ground stations and customer facilities. The Space Station provides

tracking, traffic control, and support services. It may also provide

remote platform and/or payload operation. Platforms at different

orbital altitudes will not be able to maintain line-of-sight

communications to the Space "Station. These platforms must provide

their own communication links, but may use Space Station ground

facilities in the same manner as the POP.

e Free-Flyers and Control - Free-Flyers are single payload satellites.

When in orbits accessable from the Space Station, Free-Flyers may be

serviced and maintained from the Space Station. The Space Station

will provide communications, tracking, traffic control and support

services to coorbiting free-flyers, including spacecraft and payload

control options.

e Space Station and Control - The Space Station is the permanently

manned vehicle which provides a base for multiple payloads,

habitation for the crew, and operating control for payloads, the

Space Station, and constellation elements. The Space Station

receives data from the payloads and constellation elements, and

relays the data to the ground, together with core systems data,

through TDRSS. Customer payload commands and data, together with

ground operator commands and data are relayed to the Space Station

through TDRSS. The Space Station routes the commands and data to

27

r
payloads, core systems, and constellation elements. The Space

Station must support real-time transmission of operating data and

commands, near real-time transmission of quick-look data, and delayed

transmission of bulk commands and data. Real-time operations of the

payloads require limited two-way data relay, including audio and

video links. Delayed data will be packetized and transferred at

rates consistent with the TDRSS KSA band. In addition, the Space

Station must support onboard operation of the Station, its payloads,

constellation elements, the OMV, and the OTV. The Space Station

operation and control is supported from the Space Station Control

Center.

Space Station's System Control - The Space Station System Control

Center provides overall SSP coordination, including services such as

scheduling and resource planning, coordination among SSPES, ground

facilities management, portions of command management, and customer

information coordination and dissemination. Their service will be

defined during Task 4.

Tracking and Data Relay Satellite System (TDRSS), Network, and

Control - The TDRSS satellites will be the primary means for

communication between the Space Station and the ground. TDRSS

provides Ku and S-band single access channels (KSA and SSA) and

multiple access (MA) S-band channels for communication. The

equivalent of one KSA will be available to the program for bulk data

uplink and downlink. The equivalent of one SSA channel will be

available for command and monitoring. An MA channel will be

available for voice communication. The Tracking and Data Acquisition

Satellite (TDAS), as a growth capability, will provide multiple beam

antennas. This capability will allow direct data relay to multiple

customer and SSDS centers, or even remote customer facilities. The

TDRSS ground station at White Sands, New Mexico is a relay station.

It provides for channel separation and retransmisslon through DOMSAT

and other satellite and ground links. It is assumed that the

aggregate of these links, comprising the Space Station Data

Distribution Network, wlll be able to handle simultaneous KSA and SSA

transmissions at the full TDRSS bandwidth capability. The Network

Control Center regulates and allocates network operation.

28
Data Handling Center - The Data Handling Center receives, buffers,

and retransmits uplink and downlink data. Data From TORSS are

captured and pre-processed (if desired by the customer), separated

according to destination, and retransmitted according to negotiated

schedules. The records are purged when satisfactory receipt at the

destination is confirmed. Uplink data are received, buffered,

merged, and transmitted to TORSS according to a negotiated schedule.

Again, recorded data are purged when satisfactory transmission is

confirmed.

Orbital Maneuvering Vehicle (OMV) and Control - The OMV provides for

the deployment and retrieval of payloads in low inclination, low

earth orbit. The vehicle is reusable and based on the Space

Station. OMV will have manipulators and grapplers which allow it to

retrieve and service satellites on orbit. The Space Station provides

maintenance, resupply, and primary control. The OMV has a video

camera which provides an image of the work to the operator for

interactive control. The operator may be located on the ground for

operations out of direct Space Station-OMV communications. The OMV

will also be used to maneuver traffic through the constellation.

Orbit Transfer Vehicle (OTV) and Control - A reuseable OTV, or ROTV,

is classified as a Space Station growth element. There may be

interim, expendable stage OTVs as well. Both reuseable and

non-reuseable vehicles will be referred to as OTVs in this report.

The OTV is used to launch payloads to geostationary and other high

energy orbits and return or to launch interplanetary missions. It is

also possible that OTVs will be used to place or service payloads in

intermediate inclination orbits, in the absence of suitable National

Space Transportation System (NSTS) flights. Payloads in

geostationary orbit may also be serviced on orbit, using the robotics

of an OMV. The OTV is based on the Space Station for maintenance,

payload mating, and resupply. The OMV may be used to maneuver the

OTV into and out of the constellation. Once at the orbital launch

point, control is handed over to the OTV ground control center for

launch and return. The OTV may use TDRSS, DSN, and Space Station

communications links.

29
Regional Data Centers (RDC) - The regional data centers are

multipurpose facilities or facility complexes providing payload

operation, data processing, and data archiving services for a class

of related payloads. Instrument specialists and principal

investigators may use regional data center facilities to validate,

access, and analyze data. The centers may also provide instrument

monitoring and payload operations control center (POCC) services,

including real-time payload operation and quick-look monitoring of

engineering and scientific data. Alternatively, the POCC function

may be accommodated in separate facilities.

Remote Customer Facilities - Commercial customers, as well as some

others, will have their own facilities for payload operation and

control and data reception, archiving, and analysis. A remote

customer facility may be connected directly to the data distribution

network or to a regional data center. When tied to the RDC, the

customer facility can utilize the support services available at the

RDC.

Engineering Data Center - The Engineering Data Center(s) provides

archival storage of Space Station and platfom engineering data.

This center will support program and customer requests for Space

Station Program historical data.

Optional Payload Control Center - A payload control center may be

provided at the Space Station Control Center to provide short term

support, additional support for payload checkout and special or short

term mission operations, such as some technology development missions.

NSTS Orbiter and Control - The orbiter is the means of Space Station

deployment, construction, and resupply. All ground-to-orbit

transportation is assumed to be handled via Shuttle orbiter. Two way

communication is required to facilitate maneuvering through the

constellation and docking to the Space Station. The NSTS orbiter is

controlled from its existing Mission Control Center, as well as by

the onboard crew.

30
Deep Space Network (DSN) - This network is the primary means for

communication between the OTV control center and the OTV from orbital

launch through geostationary orbit operations and return to

rendezvous with the Space Station. It also provides a contingency

command and telemetry link for Space Station communications. The DSN

will handle only spacecraft data in this backup role. Command and

telemetry data will be transferred directly with the SSCC.

Launch Integration Facilities - These ground facilities provide

verification of launch readiness for payloads and SSPEs. Launch

integration facilities are assumed to be remote from the SSDS ground

element. The relationships may include both software and simulation

support, as well as interface control.

Contractor Facilities - The contractor facilities at which Space

Station modules and upgrades are being manufactured will be supported

in their validation and integration tests. The primary support to

the facility is expected to be in the development and delivery of

simulation models, and in software development and integration.

Development, Simulation, Integration, and Training - Support

functions anticipated include the development and integration of new

and modified software, software uplink, integration of customer

payloads, end-to-end communications checkout, use of flight equipment

in lieu of GSE, crew training, and construction of simulation models

for use at remote sites.

Other Communications Links - Provisions to allow customers to

communicate with their payloads outside of TDRSS/TDAS are to be

supplied by the customers. These include direct space-ground links

and other satellite relays. These links are most likely to be used

by foreign customers desiring little delay in transmitting commands

and receiving data and by customers requiring complete security of

their data.

Technical and Management Information System (TMIS) - The TMIS will be

used to support the management of the SSP and engineering development

and integration of the Space Station elements. This program element

31
will be involved in establishing schedules, monitoring and

controlling resources, managing budgets, maintaining manuals and

procedures, developing NSTS manifests, controlling inventories, and

developing and managing the Space Station configuration. The SSOS

provides the TMIS with station operating data, and the TMIS provides

the SSOS with configuration, planning, and programmatic data.

Frequent data interchange between the SSOS and the TMIS will be

required. Oetails of these interchanges will be developed during the

SSP preliminary design.

EVA (MMU, EMU) - EVA support systems, including the MMU and EMU will

be monitored by the SSOS and may be automatically maintained on the

Space Station using SSOS support services. The SSOS will also

maintain EVA communications, including ground links and operations

and procedure support.

4.2.3 SSIS/SSDS Functional Boundaries

With the many SSPEs and functions performed by these elements, it becomes

necessary to establish criteria for inclusion in or exclusion from the SSIS

and the SSDS. These criteria are discussed below and applied to determining

SSIS and SSDS boundaries.

Criteria For Inclusion in SSIS

An SSP element or function is to be included in the SSIS if

l , The element or function is in the end-to-end data flow. The

end-to-end data flow extends from the customer's facility to his

payload, from the engineering data center to the Space Station

hardware elements, and from the platform or free-flyer control

centers to the platforms or free-flyers.

. The element or function is a Space Station or Platform Core or

Customer Unique Application. Space Station and platform core systems

and customer-unique applications, both onboard and on the ground, are

considered to be part of the SSIS, as they are end points for data.

32
Core systems maintain the environment in which those using Space

Station Program services operate. Customer-unique applications are

performed by customer supplied subsystems implementing functions

Unique to their applications. Customer-unique applications may be

supported as SSIS customer services, but only to the extent

negotiated between the customer and the Space Station Program. This

criterion incorporates requirements of Reference 5.

. The function or element performs services dedicated to the SSIS,

which the SSIS must have to operate. This criterion becomes a

catchall for elements or functions which may be unclear or omitted

under criteria l and 2. No new elements or functions were included

in the SSIS under this criterion, but it does serve to confirm

several elements and functions as being a part of the SSlS.

. The function or element is in the SSDS. The SSOS is defined to be a

wholly contained subset of the SSIS. Therefore, any element or

function found to be in the SSDS must also be in the SSlS.

Criteria for Inclusion in the SSDS

An element or function is included in the SSOS if

.

.

The element or function provides a core service. All data processing

and data management services provided to the Space Station and

platform facility subsNstems are included in the SSDS. These

services may be implemented in space or on the ground. This

criterion incorporates requirements of Reference 5.

The element or function provides a standard customer service. The

standard customer services are understood to include those services

available to any customers, whether in space or on the ground.

Standard services should be defined in response to requests from

multiple customers. Some standard customer services will be included

in the SSIS, but not in the SSOS, per Table 4-2. This criterion

incorporates requirements of References 2 and 5.

33
Table 4-2. Customer Standard Services in SSlS, Not in SSDS

Standard customer services

not in SSDS

Payload data processing beyond

level 0

• Data archiving beyond

that necessary to ensure

satisfactory delivery to

the customer's designated

facility

• Facilitate routine data

analysis services

• Access to Space Station

programmatic, .administrative

and descriptive information

(Note: engineering and some

operations information are

provided by SSDS)

• Data exchange among

customers

• Audio and video recording

and playback between

elements

• Long term mission planning

(not including mission

operations)

• Remote Work Stationsat

customers home institution

Rationale

Extended

service

X

Multi

program

X

X

X 1

TMIS

service

X

Applicable

paragraph

from Ref. 2

3.1.1,

3.1.3,

3.3.1

3.1.6,

3.4.1

3.4.1.1

3.4.1.3

3.3.3

4.2.1

3.1.7

5.4.1

5.2.3,

5.2.6,

5.3.3

7.1.2

6.1.5.2.3

IOnboard record and playback services for both audio and video are in SSDS

• The element or function manages datainboard of sensors and

effectors. This criterion is a clarification of criteria 5 and

that it excludes the .hardware elements (sensors and effectors)

the SSO$.

6, in

from

. The element or function manages data prior to delivery to or after

receipt from customers or operators. This criterion clarifies the

customer and operator ends of the SSlS/SSDS boundary• The end-to-end

data flow includes institutional facilities, such as TDRSS, that

cannot be a part of the SSOS. However, the associated data

management functions provided by the SSP are tested by this criterion

for inclusion•

34
Criteria for Exclusion from the SSDS

gB The element is a unique sensor/effector/special purpose processor

embedded in a system. This criterion compliments criterion 7 by

excluding elements which are more appropriately part of nominally

autonomous systems. These systems may still contribute status data

to the SSDS and receive operating commands such as mode and

configuration changes.

lO. Element or function is a multiprogram facility or service used by but

not dedicated to the SSP. This criterion adds a restriction on the

SSDS scope to exclude institutional facilities and systems.

The elements and functions included in the SSIS and in the SSOS are shown in

Table 4-3. The criteria by which the decision was made are indicated.

Table 4-3_ Development - of SSIS and SSDS Boundaries

SSIS criteria SSDS criteria Exclusions

1 2 3 4 5 6 7 8 9 10

End Mng

to Ded User Mng data Multi

Space station program end RFP SSIS In Core std ' inbd before Embed prog In In In

element/funtion data def serv SSDS, serv serv data trans proc sen_ SSP SSIS SSDS

GPS x/ No No No 2

Polar platform (POP) x/ Yes Yes Yes

POP ground data handling x/ x/ x/ x/ Yes Yes Yes

POP control x/ Yes Yes Yes

Co-orbiting platform (COP) x/ x/ x/ x/ x/ x/ Yes Yes Yes

COP control x/ x/ x/ Yes Yes Yes

Free fliers x/ _/ _ Yes Yes No

Free flier control x/ x/ x/ Yes Yes Yes3

Space station x/ _/ x/ x/ x/ x/ x/ x/ Yes Yes Yes

Space station control x/ x/ x/ x,/ x/ Yes Yes Yes

TDRSS _ x/ x/ x/ Yes Yes No Network control x/ Yes Yes Yes 1

Data distribution network x/ x/ x/ x/ Yes Yes Yes1

Data handling center x/ x/ x/ x/ _/ x/ x/ Yes Yes Yes

OMVservices _/ ,/ ,/ ,/ _/ ,/ 4 Yes Yes Yes

OMV control x/ x/ x/ x/ x/ x/ x/ Yes Yes Yes

OTV services x/ x/ x/ x/ x/ Yes Yes Yes

OTV control x/ x/ x/ x/ x/ x/ x/ Yes Yes Yes

Core systems x/ x/ x/ x/ Yes Yes Yes3

S.S. payloads x/ x/ Yes Yes No

Regional data centers _ x/ x/ x/ x/ Yes Yes Yes 1

Engineering data center x/ x/ _ Yes Yes Yes

Customer facilities x/ Yes Yes No

Customer payload control x/ x/ x/ x/ Yes Yes Yes

NSTS orbiter x/ Yes Yes No

NSTS mission control x/ Yes Yes No

Deep space network x/ x/ Yes Yes No

Launch integration site _ x/ Yes Yes No

Contractor facilities 9 x/ Yes Yes No

Development, simulation x/ x/ x/ x/ x/ x/ x/ Yes Yes Yes

and training facility

Alt. communications links x/ x/ Yes Yes Yes 3

Technical management x/ x/ Yes Yes No 2

information system

1) Portions are institutional and not in the SSDS.

3) Included to define interfaces

2) See text for explanation of exclusions

Disposition

35
Free flyer control, Network control Data Distribution and Alternative

Communications link are included in the SSOS for the purpose of defining

interfaces and potential additional requirements placed on these elements.

These interfaces are discussed in Section 5.2.1.

The GPS broadcasts signals that are received and processed by the SSPEs.

However, GPS neither responds to the Space Station nor has knowledge of its

presence. Hence, GPS meets the requirements for exclusion.

The Technical and Management Information System (TMIS) serves program-wide

technical and management information distribution functions for both the SSP

and for customer services. The customer services provided are more properly

considered to be part of the SSP than of the Space Station Data System in the

context of this study. Therefore, the TMIS is considered to be part of the

SSIS, but not part of the SSOS.

There are, in addition, some customer standard services in the SSIS, but not

in the TMIS or the SSOS. These services are excluded from the SSOS because

the services are considered to be beyond those appropriate for SSOS (extended

services), or meet criterion lO. Table 4-2 shows the customer standard

services in the SSIS, including those within TMIS.

The entries in Table 4-2 require some explanation. "Applicable Paragraph"

shows the specific paragraphs in Reference 2which define the required

standard service. Only those portions of the paragraph implicit in the listed

Standard Customer Service are intended to apply. Some paragraphs will also

contain services which are included in the SSDS.

Payload Data Processing Beyond Level Zero (raw data) includes all

processing producing physical units and parameters (Reference 2,

Appendix B), but excludes unique processing or handling (paragraph

3.1-3) unless specifically negotiated between the customer and Space

Station Program.

Data Archiving ranges from short term ('"1 week) to long term (up to

two years). The short-term archiving (paragraph 3.4.1.2) is included

36
in the SSDS to ensure delivery of acceptable quality data to the

customer. This archiving includes only level 0 data. All longer

term archiving is an SSIS standard customer service.

Facilitate Routine Data Analysis Services provides facilities and

off-the-shelf software routines to support routine customer data

analyses.

e Access to Space Station Programmatic, Administrative, and Descriptive

Data is expected to be supported by the TMIS. The engineering and

operations data also mentioned in paragraph 4.2.1 should be accessed

through the SSDS. These boundaries should be either transparent to

the customer or delineated through user friendly prompts and

interaction, such that customers can easily access all types of

information.

Data Exchanges Among Customers will often involve archival or

planning data. To keep the system uniform, all data exchange among

customers is allocated to SSIS standard customer services.

Audio and Video follows the same rules as data exchange, above.

Long-Term Mission Planninq, in the context of paragraph 7.1.2,

includes SSPE support services (NSTS, OMV, OTV, etc). Customer

payload accommodations is also a part of long-term mission planning.

SSDS will provide all phases of mission operations planning.

Remote Work Stations are an extended service to promote

standardization.

4.2.4 SSOS/TMIS Boundaries

There are potential areas of overlap between the SSDS and the TMIS in

programmatics. The functions involved were examined in light of the stated

TMIS objectives (Reference l, section C-6) and the Customer Requirements for

Standard Services, (Reference 2). The distinguishing features of the TMIS and

SSDS identified are discussed below.

37
The THIS features are:

Deals primarily with management, development, and long range planning

for the Space Station.

Deals primarily with program managers, designers, and contractors.

Deals primarily with engineering development data and programmatic

data.

Development contractors are the primary data sources.

Customer interactions are primarily program information and

coordination of multiprogram services.

The contrasting SSOS features are:

Deals primarily with operation of the Space Station and payloads and

handling of customer data and commands.

Deals primarily with core operator and customer operators.

Deals with both real-time and non-real-time operational data and

commands.

Customer interactions are primarily operational and data processing.

Based on these distinguishing features, the SSDS/TMIS boundaries are drawn in

the areas of potential overlap as defined in Table 4-4.

4.2.5 SSDS - Subsystem Interface Diagrams

The onboard portion of the SSDS includes both core and customer services.

This scope is understood to include all those standard data services

appropriate for implementation in general purpose processors. The charts that

follow are a first step in defining a detailed boundary betwen the SSDS and

the onboard subsystem equipment. This boundary will be further clarified by

the SSDS Functional Interface Specifications that are to follow in Task 4.

Figure 4.4.4.1-I from the Reference System Configuration has been copied and

annotated as Figure 4-2 to show a top level view of the SSDS-subsystem

boundary on the Space Station. The boundary is shown by the bold, dashed

lines. Note that the Information and Data Management Subsystem (IDMS) is

fully contained within the SSDS. The Subsystem Data Processors (SDP) for the

subsystems are also shown a within the SSDS.

38
Table 4-4. SSDS/TMIS Boundary Definition

Function SSDS responsibility TMIS responsibility

Logistics Planning • Customer and core resupply needs • New payloads

• Payload, space station, platform, • New modules

Satellite, OMV and ROTV • Major upgrades

maintenance needs • STS scheduling and manifest requests

• LRU'son orbit

Program. budgeting and • Input requests and status • Integrated development, monitor and

scheduling statusing of budgets and schedules

Customer Billing • Input data services rendered • Prepare billing for all services and

post payments

Manuals and procedures • Payload operations procedures • Equipment specifications

reporting • Payload maintenance manuals • Equipment operating procedures

• Facility operating procedures • Other facility and equipment

• Space station system maintenance maintenance manuals

manuals • Payload interface specifications

• Emergency procedures • System specifications

Configuration management • Real time mass and area properties • Configurational properties

• Core system equipment status • Equipment lists, serial nos.

• Facility configurations • Equipment histories, failure

• LRU status mechanisms

• Real time operational data base • Planning for changes

• Measurement, monitor and test • Instrumentation lists

current configuration • List of possible system tests

Inventory Control • Spares on board • Spares in pipeline

• Spares at facilities • Location of payloads

• Location of payload spares

• Location of repair parts

Planning/scheduling • Operating schedules • Programmatic schedules

• Master Plan

• Accommodation plan

Customer interfaces • Receipt and delivery of payload commands

• Receipt and delivery of payload data

• Acquisition and delivery of

ancillary data

• Development and use of simulation

for payload integration and

customer training

• Customer authentication

• Command dictionary maintenance

• Customer handbook

• Customer accommodation plan

• Customer billing

• Customer priorities

• Prior designation of specific commands

as restricted or constrained by the SSP

• Manifesting customer payloads and

supplies

The numbers 1 through 7 appear, next to the subsystems and indicate the figure

number in which the subsystem interfaces are further defined. The Propulsion

System electronics (RCS electronics) are shown to be included within the GN&C

subsystem (page 416 of the reference configuration). Therefore, no separate

figure is provided for the RCS. Similarly, the electronics support of

payloads is included in the SSOS, and no separate diagram is shown for the

payload and servicing accommodations subsystems. The remaining seven

subsystems are shown in the interface diagrams of Figures 4-3 through 4-9.

The Subsystem Interface Diagrams Show the subsystem "sensors and effectors" on

the left hand side. Typical data flows between the SSDS and the sensors and

effectors are indicated. Subsystem functions performed by the SSDS are

39
ill

1

I

n

1

I•

I

II

II

I

I

1

I

n

I

I

II

n

i•

i

i

i

I

i

i

n

pmmi|mmimimm|mi|imnimmmmmmmm|mmim_ _mi||immnmanmmu|i|mmmmanmmmmmm

-- SSOS -" ,,,

i • =-

ia n I ,

" " I

ii m m

Power m m

Subsys -= SDP _= Payload 1

-in n _ "i - li -_-_ I

ECLSS=:1 SDP_ ": -- I;- _ I

U _ i i

_1 i - _.J ,, I ,, ( ,r,_._,_ ,.. ,. I

. . - I-= _ o_1

"l I_ " - IE ,J_ _, I

-"1 SOP =_L-_/'n_ = L_i I _r_o I Q,-, I

Propulsion-I I_C_ -_ i Payload N I ; i gur I _ I

=-I I -- • | • _ u o I

_' _ : ,,,,,,,,,,,,,= _ /

• I I 0o. /

;! I _ _ I Payload 1

:1 SOP I,tl'l_tD_lb _-(,o_---_ Data

Therm am| I" _.J - v i Gataway l

c ow System iiSDP

Illllllllllllllllllllllll

Storage Data SDP

Time and

Frequency

Facilities

Mgmt and

Control

Portable

Workstations

Cam and Cntrt

Workstation

i SDP

SOP

C

.o o= ]i

OZ

__lllllllllllll

I Payload

Cam•

Gateway

i

I

Jllllllllllllllll

_llllllllllllllllllllllllllllllllllllllll=

:

Hab _i

Workstation =-

I

I i

Lab 1 -=

I

Workstations _,,

1

I

i

I" Lab 2 -=

Workstations _m

i

1

I

F_|_|__|__u_l|______l_

Figure 4-2. Information and Management Subsystem Space Station

4O
0

0C0C0

L_

41
C

_b _ 4s _,cts

0

0

O.

E

0

_ z

.N X

I

--I

._- "O

A _

_-0 e=(U .,--,,0

_i -o'_,_m >"',

EEe_N _'c m_

U)

mDl, ._ w n m

!

0 0

,-r C..)

2_ "5 o

_ m N

e- ,-

0- 0 <,rr

I -

'_' __

• d_ J

c

,.

E £

C

.u 3.

,- .c

E1 E • E

<I < :1:

_ g

c Q_

I _

w

m_m

T_

0

0

_m L_

il°o.*

_.Iz-

=. .

t_

e,

o

_J

_oI o

i

I

-_ > I

I

I

!

I

-- tO 0

0 _"

O ro_ c) ,o

g

I

I

_..E -

0

_E

0

0

I

_P

--I

i11

,f

42
r_

¢/)oo

err

U.Q.

_'_ O0

nn _" U..J

C0 ___

o_ -_

®&

_-®x

0T0

r_0U
oc

44
0

i

C

e0

.m

i

U

Z

,0,

::u
0

tO

C

C

2

i1
1

"10

eCO

0

_'E

<:

,-' E o._o

on',,,

(2,

C

l1

"o

o

I,-

E

E

o

,d,

ii

47
indicated in the center boxes on the diagrams. Data Flows to and from other

SSOS functions are also indicated.

A similar set of diagrams define the platform SSOS - subsystem interfaces.

ECLS and crew systems are not present on the platforms. Structures and

mechanisms and Communications are modified as shown in Figures 4-I0 and 4-11.

4.3 FUNCTIONAL ARCHITECTURE OF SSIS

System architecture is closely related to system design. Only the top level

of architecture can be presented without specifying the design to a

significant degree. This section is, therefore, constrained to a very top

level discussion. Some additional design-independent detail will be provided

in Section 4.4 in the discussion of SSIS operation.

The architecture will be presented in a top level data flow diagram, showing

how the system works from a logical" perspective. A more detailed discussion

will follow on the two major end-to-end data flows, command management, and

customer data handling.

4.3.1 Data Flow Diagram Conventions

Structured Systems Analysis (SSA), Reference 4, has been used extensively in

Task l to develop the logical operation of the system. Data flow diagrams

(DFD) are used to provide a graphic presentation of the results of SSA, and to

show the overall working of the system being analyzed. There are four

conventions used In data flow diagrams, as illustrated in Figure 4-12, etc.

External agencies enter data into. the system and receive data from

the system. They do not otherwise interact with the system.

External agencies are designated by squares with a double line at the

top and left. For simplicity of the diagram, an external agency may

be duplicated on the diagram. A diagonal line across the bottom

right corner indicates a duplication.

48
Qwc

u.CO

DO_

N_N

m

o

°_C

c- O

u_

49
°l

!1 /ill _l °

eo

0

<F1 ll ll I llll

cO

"_o,

@Fo

co

o_

_g

>u

_L

8

_ c
AN EXTERNAL AGENCY

IS IDENTIFIED BY

A SQUARE: ENTERS,

RECEIVES DATA

AGENCY

A PROCESS IS

IOENTIFIEO BY A

RECTANGLE WITH ROUNOED

CORNERS: TRANSFORMS OATA

x.x

PROCESS

DATA

FLOW

DATA FLO#j

f

At" ]ooo, I EPEATE,

i OAT, STO, E

AN EXTERNAL AGENCY OR

A DATA STORE MAY BE

REPEATEO TO SIMPLIFY THE

OATA FLOWS

Figure 4-12. DFD Symbol Conventions

0003

REPEATEO

EXTERNAL

AGENCY /

I [0003

DATA FLOW J REPEATED

1 EXTERNAL

AGENCY /

A DATA STORE

To IS IDENTIFIED BY ATA AN OPEN ENOEO RECTANGLE;

IFLON HOLDS DATA FOR LATER I

RETRIEVAL

0002 DATA STORE

DATA FLOWJ

A REPEATED EXTERNAL AGENCY

IS IDENTIFIED BY A SQUARE

WITH A SLASH IN THE LOWER

RIGHT CORNER

]ATA

FLOW

'/1 004 IREPEATED DATA STORE

A REPEATED DATA STORE

IS IDENTIFIED BY AN

OPEN ENDED RECTANGLE

WITH A TRIANGLE

Processes transform flows of data, usually in some fundamental way

that alters its form and content. A process is designated by a

rounded corner rectangle.

Data Stores contain data to be made available to other processes when

the processes do not necessarily take place in immediate sequence.

Therefore, the data in a data store should have a significant

lifetime. Data stores are designated by extended, open sided

rectangles. Data stores may also be duplicated to simplify the

diagram.

Data Flows identify the data moving among processes, data stores and

external agencies. The data flows are designated by labeled arrows.

Structured systems analysis is used to develop multiple levels of detail to

describe what the system does. The top level (Level 0 DFD) shows the entire

system in its simplest form. The level 0 analysis concentrates on the

51
end-to-end paths connecting external agencies. It becomes an outwardly

focused description, focusing on the questions, "Who will be using the

system?", "What do they want the system to do?", and "What are the major data

input to the system?." The processes depicted are very top level and

generic. Subsequent levels of OFOs will add progressively more detail.

4.3.2 Characterization of the SSlS

The first step in an SSA is to ascertain the answers to the above questions.

These responses, in appropriate detail for an SSlS Level 0 DFD, are:

a. Customers will use the system to develop payloads, develop software

and command sequences, command payloads and receive data.

bo Operators will use the system to command the Space Station and

associated flight and ground SSPEs and receive the data required to

operate these systems.

c. Contractors will use the system to develop software and verify SSPEs.

de Payloads will interface with the system, receiving required commands

and ancillary data and generating data to be returned to the customer

and/or operator.

e. SSPEs, including core systems, facilities, and constellation

elements, will interface with the system, receiving required control

and generating operating and status data.

f . TMIS will interface with the system, providing program management

control and requiring programmatic and technical information.

4.3.3 Operation of the SSIS - How the System Works

The team used SSA to develop the data flow diagram of Figure 4-13. Key

definitions for the data flow diagrams are provided, and the major functions

of the SSIS identified in the analysis are described in the following

paragraphs.

52
4.3.3.1 Level 0 OFD Definitions. The following definitions will aid in the

understanding of the Level 0 Data Flow Diagram:

e Payloads are the customer supplied packages mounted in or on the

Space Station. Some payloads will utilize Space Station data

processing and/or operator services.

- 7.0

SUPPORT 1 SSIS USAEE.

;SPACE ] MAINTE:22;:TZC: NEEDS

:ou_'.°,%Rd

/loo'lcoRs ST*TUS

SYSTEM STATUS DISPOSITIO.. SCHEDULES.

DATA

OPERATE EXECUTABLE

OPERATING CORE CORE CMNDS,

COMMANOS SYSTEM DATA

Igo': ul RECO.FI,URE i _ DISCONNECT

DO YSTEM

S RESOURCE FORCASTS.

OPERATING MODE

0010 I

DATA L.

PROCESSING r--

RESOURCES]

CORE STATUS

_FACILITIES

STATUS

STATUS

RECONFIGURE

Figure4-13. SSDSLevel0 DFD

O01§

-I TNIS

//]001t I CORE STATUS

[ 1"0 _ CORE DATA ) MANAEE PAYLOAO DATA

/ OPERATOR

CORE. PAYLOAD DATA

SCHEDULE

REGUESTS

P/L NODE.

STATUS

SCHEDULE

AND ' PROSRAM

EXECUTE SCHEDULES

OPERATIONS

IO0*flNASTER PL,.

bRESTRICTED CONSTRAINED

P/L CNMOS. VALID

_PERATOR CNNDS/DATA

0PERkTIN6

REBUIREHENTS

SCHEOULE

NEN SOFTNARE

DATA BASE

0013 I

EXECUTABLE RESTRICTED. / PkYALNODA DS

CONSTRAINED P/L CMDS -I_l CONST

ELEMENTS I

F STATUS DATA ._

FaOIBIPAYLOAB STATUS (UNRESTRICTED P/L

J ICNNOS, DATA

/ MANAGE i J /

/ CUSTOMER/ ] /DI CUSTOMER/

/ OPERATORI ........... i I OPERATOR

/ SUPPLIED mu*aru_*.*unj I

/ DATA I -- . _,

t _P/L I; CORE CMNDS. DAT_ /

. SYSTEN CONTROL .J

PROCEDURES. 1/0

,o

LS .ULATED S..ULUS pO'S I

/IHTE6nATIO"I

Constellation Elements include those spacecraft and their payloads

flying in the proximity of the Space Station. Most constellation

elements will use the Space Station as a communications node. The

Space Station will also control the maneuvers of these vehicles.

53
Polar and Coorbiting Platform_ are unmanned, multimission spacecraft.

The Polar platform(s) will operate independent of the Space Station

using their own communication links through TDRSS. The coorbiting

platform may use the Space Station as a communications node, if it

remains in line or sight of the Space Station, or it may operate

independently.

Customers are those utilizing Space Station services, primarily

commanding payloads and receiving data. Customers may be either

onboard or on the ground.

Operators are Space Station Program employees, both onboard and on

the ground.

Contractors are designers and developers of Space Station equipment

and software.

Data Processing Resources include the computers, storagedevices and

networks supporting the SSDS facilities.

Core Systems are the systems that maintain the environment in which

the customers and operators perform their functions.

TMIS is the Technical and Management Information System. The TMIS

supports the SSDS by providing information and coordinating

multiprogram resources..

Core Status is a data store containing the status and monitoring data

for all core systems and SSDS facilities.

Payload Status contains the status and monitoring data for all

payloads.

Master Plan is provided by TMIS and contains program schedules.

Restricted Commands are those payload and core commands which could

endanger the health and safety of the Space Station, or its payloads,

and constellation elements.

54
Constrained Commands are those payloads which require coordination

with other customers and core systems to ensure that customers do not

interfere with each other and to coordinate Space Station Systems

support of customer requests for services.

Unrestricted Commands are those that are neither restricted nor

constrained.

Executable Commands are restricted or constrained, but cleared for

execution on a specific schedule.

4.3.3.2 Level 0 Data Flow Diagram

Manage Customer/Operator Supplied Data (l.O) - This function receives both

real-time and bulk payload and core systems data and transmits these data to

the customer's and operators.

Manage Customer/Operator Supplied Data (2.0) - This function receives payload

and core commands and data from the customers and operators. Operators will

always provide the core commands and data. Both customers and operators may

command payloads and enter data destined for the payloads. The function will

pass unrestricted payload and core commands and all payload data on to the

Space Station, Constellation and platforms and their payloads. Restricted and

constrained commands are sent to the Scheduling function to be checked for

execution. The customer or operator entering the command is notified of its

disposition.

Schedule and Execute Operations (3.0) - This function provides an environment

for customers and operators to develop the Space Station, platform, payload,

and supporting facility operating schedules. The schedules are developed to

maximize the value of payload output within the constraints of SSP resources.

The execute operations portion of the function dispatches commands to execute

operations according to the schedule. Restricted and constrained commands are

checked to determine whether they are executable under the conditions at the

requested execution time. Those which are executable are passed on to the

payloads or core system. Those not executable are arbitrated with the

operator and customers involved and scheduled for execution, if possible.

55
Operate Core Systems (4.0) - Evaluates and processes core system sensor data

and generates system operating commands. Many of these commands are generated

autonomously within this process. Commands which can be generated and

executed by the process are governed by system operating mode.

Manage Core Facilities (S.O) - Performs any necessary reconfiguration of the

facilities. The data processing facilities are notified of scheduled events

affecting their operation. Limitations have been taken into consideration as

SSP constraints in the scheduling process. The function will also notify

Operate Core Systems (4.0) to disconnect operating power from pay]oads showing

evidence of serious malfunction or exceeding prescribed operating power

limits. Standby power will not be disconnected unless the Space Station

crew's health or safety are endangered.

Oevelop, Simulate, Integrate and Train (6.0) - This function serves customers,

operators and SSP contractors by configuring and executing simulations to

Develop new software

Verify and integrate new software

Verify and integrate new hardware

Oeliver simulation models to customers and contractor facilities

Train operators to operate the Space Station, platforms, and selected

payloads

Train customers in the use of the system

Verify end-to-end communications links.

Support Space Station Program (7.0) - This function provides logistic

requirements and SSIS resource usage to the TMIS. It also provides

maintenance of SSOS facility and payload manuals and procedures, facility

spare and repair parts inventory control, and operating configuration

management.

4.3.4 End-to-End Command Management and Oata Handling/Oelivery

These two major, end-to-end functions of the SSDS were selected for further

elaboration due to their importance.

56
4.3.4.1 Command Management. The SSOS command management problem represents a

demanding set of requirements unique to the Space Station program. As

described in the operations concepts and requirements, there is a desire to

meet the following needs:

e The value of the Space Station and platform payload and mission

operations should be maximized within constraints of limited

resources and safety.

It should be possible for customers to command their payloads in real

time or with stored commands, from space or ground, for

non-restricted, and restricted and constrained commands.

Non-restricted commands should receive no further checking beyond the

address of the payload. Ideally, restricted and constrained commands

should be allowed in real time also, as long as the customer is

operating within the resources and constraints that have been

negotiated.

Autonomy and customer operations and commanding should be supported

to the maximum extent possible, with minimum delays and schedule

constraints. This implies less reliance than in the past on the use

of integrated timelines and schedules which must be developed long in

advance for all customer operations.

Customer privacy should be supported, with commands from some

customers being encrypted.

The personnel operations activity and customer specific development

required to perform command management should be minimized.

Space Station health and safety must be protected, and customers must

be inhibited from interfering with each other.

In summary, the steps in implementing the command management data flow to be

described in Section 6 (figures 6-3 and 6-4) are:

57
e The sender is authenticated, and the command and its destination is

validated as being authorized for the issuer (customer or operator)

for the time the command is sent.

e Dataand commands destined for the core system may be subject to

checking depending on the authorization of the operator issuing the

command (e.g., not all operators will be allowed to issue all

commands).

Customer commands are checked for their classification as restricted,

non-restricted, or constrained.

Non-restricted commands and data other than commands are passed

directly to the core or payload with no further checking beyond the

address of the destination.

Restricted and constrained _ommands receive command management, with

conditions for executability of the commands checked by one of

several alternative processes.

Some restricted and constrained commands may be processed for

immediate execution, while others are processed for later execution.

Those commands accepted for later execution may become not executable

before their scheduled time because of unforecasted system or payload

status changes.

Those restricted or constrained commands which can be executed

immediately are routed directly to their destination without further

delay.

Those restricted or constrained commands which are entered by the

customer for execution at a later time are checked for executability

under the conditions scheduled for the time of execution. Commands

executable at their scheduled time are held until the time for their

release and routed to the payload. Changes to the schedule resulting

from equipemnt failure, loss of capability, or preemption by higher

58
priority may cause commands being held for later execution to become

not executable. These commands so affected will be treated as any

other "not executable" command.

Commands which are not executable are referred to the customer and/or

operator for scheduling.

Disposition is reported back to the customer or operator at several

points:

- upon acceptance or denial of the command

- upon scheduling of the command for later execution

- upon delivery of the command to the customer built-in unit (BIU)

port

- perhaps at intermediate points

All disposition is reported to the customer/operator entering the

command.

All processing is consistent with customer real-time payload

operation from space or ground, except for disposition of not

executable commands.

The following discusses some of the options and issues related to meeting the

above requirements. Options are classified by each of the following steps:

Options for the off-line analysis of customer command operations and

classification as to Whether they are non-restricted, constrained, or

restricted.

Options for the on-line process of classifying a command when it is

issued by the customer and received by the SSDS.

• .

Options for checking restricted and constrained commands to determine

whether they are executable.

The final design for command management will be developed in Tasks 2, 3 and

4. Some of the activities for which options will be developed and trade

studies conducted are discussed below, together with one or more of the

possible options.

59
First, the customer command operations must be classified as restricted,

constrained, or non-restricted. This classification must be done no matter

how the command management is implemented.

One option for this classification and command development process involves

building a command dictionary as illustrated in Figure 4-4. The dictionary

would contain command identification information, "command keys" which

initiate execution of the operation, and command restrictions and

constraints. (Note that the end-to-end command flow is shown in the data flow

diagrams in section 6. Figure 4-14 i11ustrates the command classification and

command dictionary development process which is normally performed offline to

support the command management flows.)

The proposed operation is analyzed against I) a preselected list of Space

Station resources which may limit operations (e.g., power), 2) potential

interferences with sensitive Space Station systems and payloads, and 3)

I

I

I

I

I

L

Operation

Operation

Key

Command

Sensitivities

Interferences

i

Resources Required

• Power • -_-

• Data • _--

Comm_nd-_l_tl_na_- --l

Contents

• Crew • _ _-

,f

Key Command !

R,C, or U

Constraint

Conditions

Executable if:

Restriction

Conditions

Data for Other

Payload and

Core

Operations

Executable if: I

1__ Re r, ,on_-_'-"_"_'-_ J

_ Classtsi_itation FoC°Enditl:tl_: n

_{ Reviewof--o_

Figure 4-14. Customer Operation Commands Sequence Development

6O
potential sensitivity to interference from projected payload and Space Station

operations. The command operation is classified according to restricted,

constrained, or non-restricted. If restricted or constrained, the specific

conditions for execution are defined.

Customers may use combinations of operations contained in the command

dictionary to construct operational sequences for real-time or scheduled

control of their payloads. The classification of the set and of the

conditions for execution may be carried to higher and lower levels to allow

customer flexibility in building commands without repeated review. However,

each operational sequence must bear the highest classification of the

constituent command sets.

The second area for options development relates the results of the off-line

analysis of customer command operations to implementation of the on-line

command management functions (see Figure 6-3). There are several options for

implementing this command management function. All will likely utilize some

form of the command header, and thus some background is needed to explain this

concept.

Customer command messages will likely be in the form of "messages" or

"packets" (though this need not imply packet switching). Such command packets

will have a header (and trailer) which wrap around the customer command, with

information to be supplied in a standard format (which is to be determined in

this study). This header information must have the destination address (the

payload) so that it may be routed over the ground and/or on-board transport

networks, but the header may be used for command management as well. For

example, the command headler could specify the command classification

(restricted, constrained, or non-restricted). In fact, the addressing scheme

might itself be used for command classification as noted below.

If this header were customer supplied and not checked, it would imply trusting

the customer to not intentionally or unintentionally mis-identify the command

(e.g., labeling a constrained command as non-restricted). Checking might also

be necessary to prevent customers from sending commands to the wrong payload,

61
or a saboteur from sending commands to a payload. If SSDS supplied, it

implies maintenance of a database for all customer commands so that the SSDS

can perform the classification, which will require significant effort.

When a customer issues a command (real time or stored), the SSDS must first

verify that the command is coming from a valid customer authorized to send

commands to the specified payload. The command must then be managed as

restricted, constrained, or non-restricted. Two options to performing this

management are:

In one option, the results of the analysis of the customer command

operation could be reflected in the command header and the data

transport network and affect how commands are routed. Commands with

addresses which imply that they are not restricted would be routed

directly to the payload -- in effect having their own logical path.

Restricted or constrained commands would be routed to intermediate

destinations for further checking.

This option implies trusting the customer to identify the command correctly,

and also implies an SSOS ability to read and check restricted or constrained

commands. However, the command distribution capability (e.g., the data

network) would automatically route non-restricted commands in real time, and

no separate unrestricted command databases would need to be employed other

than the network routing tables. However, the database for reading and

resolving restricted and constrained commands may be extensive. Customer

payload software could further be required to ignore unresolved, restricted

and constrained commands and this would have to be verified in testing.

Another option would be to require the customer to pre-define

concatenated versions of all restricted or constrained commands for

use in a command dictionary maintained by SSDS. The customer would

issue "command keys u. Command keys would have address headers so

they could be routed to the right payload. The SSDS would use the

command dictionary to check the condition for execution of the

commands and accept commands whose requirements are met at the time

indicated for execution. Resolution of restricted and constrained

62
commands would be simplified at the expense of an extensive SSDS

database maintenance task. Non-restricted commands may be passed

directly through to the payload or may be required to be recognizable

by the SSDS.

Validated command sequences triggered by the key commands could be stored on

the ground or on-board the Space Station, either in the customer's processor

or in an SSDS processor utilized by the customer as a standard service. This

processor would translate all key commands into the pre-stored sequences.

Non-restricted commands would be forwarded directly to the payload, while

restricted or constrained commands would be subject to checking conditions for

execution. The command dictionary would be required to keep a list of at

least all customer restricted and constrained operations and their command

keys, as well as information on constraint and restriction conditions.

In both options, a mechanism must be provided to merge or otherwise issue the

core commands (e.g., connect power).necessary to implement the payload

commands. Knowledge of Space Station and payload status is required at the

location where this command management is performed.

The final area for options development is resolution of the commands which

exceed constraints or violate restrictions. This condition may result from

circumstances such as:

Customers attempting to operate their equipment in a manner not

anticipated in the schedule.

• Station equipment failure or other loss of capability.

• Schedule preemption by a higher priority operation.

• Error conditions.

The SSOS should attempt to resolve these commands. Resolution could be

determined by an operator, automatically by the SSOS software, or

interactively, with or without customer involvement. An interactive procedure

with customer involvement is currently preferred.

63
If the command cannot be scheduled for execution at a time satisfactory to the

customer it must be rejected. The customer must then replan the operation.

In order to replan the operation, the customer must be informed of the reasons

for rejection, and may require assistance in replannin9. The SSDS will be

required to supply the reasons for rejection, and the Space Station Program

should be prepared to assist in replannin9.

One implementation of the command management process is illustrated in Figure

4-15. When a customer or operator enters a command key, the SSDS will perform

the following functions:

SSDS

Disposition

CUSTOMER SERVICES

Auth.nticeUon I I Commend Dictionary I

Valid Cmds Unrestricted

Customer PIL PIL Cmd Cmds Payload

Customer

Unique

GanereUon Command i Short-Term Sched

Disposition Ops

Events

SERVICES

Cmd Dictionary

•• Restrictions Constraints Timeline j

Core Status

Crude

Operator Core I

CORE SERVICES

Figure 4-15. End-to-End Command Management

a. Validate P/L commands

The Customer/Operator is validated as one who is authorized to use

the system.

64
The address for the input is validated as authorized for the customer

or operator.

Data other than commands destined for the core system, payloads and

constellation elements are passed directly to their addressed

destination.

b. Check P/L Command Restrictions/Constraints

Payload commands are checked against the command dictionary and

confirmed as restricted, constrained, or non-restricted.

Non-restricted commands are sent directly to the payload, core

system, or constellation elements.

e Restricted and constrained commands are sent to the scheduling

process for disposition.

C. Develop Ops Events Schedule

• Disposition is reported back to the customer or operator.

Conditions for executability of restricted or constrained commands

are checked. Those commands which can be executed immediately are

passed on to their destination. Other executable commands are time

tagged and loaded into the Operating Events Schedule to be delivered

at their scheduled time.

Commands which are not executable are referred to customer and

operator for scheduling.

All disposition is reported to the customer/operator entering the

command.

All processing is consistent with customer real-time payload

operation, except disposition of not executable commands.

65
4.3.4.2 End-to-End Customer Data Handling/Delivery

This second major end-to-end data flow is illustrated in Figure 4-16. The

customer payload receives real-time ancillary data from the SSDS and merges

the data into the payload data stream. Payload data required by the customer

in real-time are designated by the payload for real-time delivery. These data

are kept separate from bulk data in order to expedite delivery. Bulk data are

accumulated onboard for scheduled, high data rate downlink. Once per orbit

downlink of bulk data will accommodate all requests from Reference 3.

However, optimum link usage and onboard storage may require other schedules.

The data downlink and distribution is governed by priorities developed

interactively among customers and operators.

Oownlink data are captured, and delivered to a handling process for standard

processing. The data are sorted according to customers, processed to level O,

Onboard

o -III...

I Cust It,-

R/T Ancillary

Data

SSDS

.i

Std

PIL

Data

IIF

Voice/'TV

Voice/TV

Voice/TV

Sched

Data

Dist

mm

mo

!

_%ustomer _

(2 yr)

Customer Archive

Options + Cost

Figure4-16. End-to-EndCustomerData Delivery

66
and delivered. Online storage is maintained for 12 hours to support

quick-look monitoring by the customer and to ensure delivery. Offline storage

is maintained for one week after receipt of satisfactory quality data by the

customer. Data accounting is provided to the customers, showing the status of

all payload data.

Archival storage for up to two years, as well as level IA processing, are SSIS

standard customer services. Additional archival storage and customer unique

processing are beyond the scope of the SSlS.

4.4 OPERATIONS CONCEPTS FOR THE SSlS

An operations concept for the SSlS was developed to describe how customers and

system operators would use the SSIS in support of their missions. The purpose

of this operations concept is to describe the ways in which people will use

the SSlS to accomplish all phases and modes of their operation. The operation

concept also serves as a preliminary description for potential customers and

operators of the way the SSlS works so that they may provide inputs to the

system requirements refinement and design.

Two views of SSIS operations are provided; the customer's perspective

(paragraph 4.4.1) and the operator's perspective (paragraph 4.4.2). The

customer's perspective describes how a Space Station or Platform customer uses

the SSlS to plan missions, develop and integrate payloads and support systems,

perform mission operations, and acquire and use the mission data. The key

goals driving this operations concept have been (1) to provide maximum

operational autonomy for the customer, (2) to make the integration of customer

systems with the Space Station and Platforms simple, straightforward, and

relatively inexpensive, and (3) to provide the customer with a reasonably

broad set of options for planning and implementing his Space Station and/or

Platform mission(s).

The operator's perspective describes the SSIS operations concept from the

viewpoint of the Space Station operations manager. Space Station and Platform

resources scheduling, crew scheduling, overall mission integration, core

system maintenance, training, and system upgrades are key concerns.

67
The above perspectives deal with the operation of the Space Station and

platforms after IOC and between growth cycles. A buildup scenario has also

been provided (paragraph 4.4.3) to identify the capabilities required during

buildup and the SSDS functional requirements. Growth cycles are examined in

paragraph 4.4.4.

From the above, the operational design drivers are identified (paragraph

4.4.5) to provide guidance to the remainder of the study.

4.4.1 SSIS Life Cycle Operations - Customer Perspective

This section describes a chronological sequence of operations related to the

customer. For the purpose of this discussion, a customer is defined as an

individual or organization with an objective related to the Space Station

Program and has primary responsibility for a payload and for the use and

interpretation of data provided by that payload. The customer will receive

support from the SSlS to accomplish'the mission objectives. Inherent in this

description is the philosophy that each customer will differ in the degree and

type of services that he will use; customer costs vary accordingly. This

concept implies the need to clearly inform the customer of the methodology for

getting an experiment on the Space Station or the Platform, and of these

optional services and related costs available with each option to support his

activities.

Basic to the customer perspective is that most operations are transparent and,

with few exceptions, all interfaces standard.

Some of the operations described in this section may become part of the TMIS

as its definition becomes firm. Since those portions of the TMIS needed for

customer operations are contained within the SSIS, no distinction is made

between the SSlS and TMIS in discussing operations from the customer's

perspective.

4.4.1.I Familiarity and Agreements. Many prospective customers will know the

Space Station Program well enough to initiate inquiries into becoming a

customer and to promote their own missions. However, it is to NASA's interest

to agressively seek customers by supplying program information on capabilities

68
and services offered. Workshops, seminars and public releases can be used as

information dissemination vehicles. NASA may consider assigning prospective

customer relations to a specific organization as an option.

In the age of personal computers, it is desirable that NASA maintain a menu

driven, publicly accessible data base that describes the Space Station Program

details as selected by the viewer. This will be enhanced to enable an easy

transition from the general public to a Space Station Program (SSP) customer.

It is envisioned that SSP customers will vary from college graduate students

working on theses to highly competitive commercial customers similar to the

STS electrophoresis experiments which may yield production of life saving

pharmaceuticals. Figure 4-17 is an example of a menu provided to the public

simply by dialing an BOO number or some equally inexpensive access. The

content of this information and procedural data base will evolve with the

Space Station Program.

The NASA will maintain a customer handbook available in either printed form or

by electronic transmission. This handbook would be available in different

levels of detail depending on the customers level of interest and

negotiation. The sincere customer will obtain a thorough description of the

services that could be provided as well as the actions expected of a

customer. Example topics covered will include:

Space Station Program general description

Management procedures

Available resources

User interface

Scheduling

Security

Space platforms

Space Station Attached facilities

Space Station Laboratory Facilities

Crew services

Flight preparation

Launch and landing operation

Orbital operations

69
NASA

)ace Station Information Service

Please Select Area of Interest:

What is the Space Station?

How does It get energy?

How do space robots work?

How Is life sustained?

Who can visit?

How do I perform an experiment?j

Figure 4-17. Space Station Information Service

Customer responsibilities

Cost estimating procedures and data base.

Current & Projected Nonproprietary Payloads & Missions

This handbook would be supplemented by meetings with cognizant NASA personnel

as well as workshops.

Historically the programmatics of having an experiment accepted on a NASA

program involves lengthy, time engaging, very formal interface meetings and a

mountain of paper. To a large extent, this process will be codified and

reduced to an interactive dialog through terminals. This trend is exemplified

in Figure 4-18.

One electronic process would be explanation of available, measurable resources

and services versus cost; It would be a NASA policy decision to provide a

schedule of cost. Figure 4-19 shows examples of measurable items.

70
J

Past Experiment Planning

Process

Figure 4-18. Trends in Experiment Planning

Future Experiment Planning

Process

Select Topic for Expanded Detail and Cost

• Space Facilities Usage

• Ground Facilities Usage

• Telecommunication

[_ • Logistics Support

• Crew Time

• Simulation Time

• Training Support

Figure 4-19. Electronic Negotiations

71
Other measureables include:

Integration and training

Storage by duration and media type

Communication links and local bus bandwidth

Priority servicing

Launch and deorbit (by weight and volume)

Power

Operator time

Special facilities.

Security/privacy

Given detailed knowledge of the Space Station Program and costs of service

from either an electronic data base or a written handbook, the potential

customer can then prepare and submit a proposal to NASA. The customer's

proposal could be prepared electronically by providing responses to a standard

set of queries.

Successful review and subsequentnegotiations would necessarily be performed

in face-to-face meetings; each customer would then enter into a contractual

agreement with NASA which specifically describes the services to be provided

and the associated costs. In many cases, these costs would represent fund

transfers between NASA offices or reimbursable funds between other government

agencies and NASA. The extent that these procedures can be made uniform will

aid in the development of a commercial customer base.

4.4.1.2 Long Term Planning. A traditional source of consternation between an

experimenter and the Program Office is the lack of synchronization between

their respective schedules. For example, experimenters must realize that a

high fidelity simulation of a major payload requires precise definition of all

interfaces as much as a year prior to the simulation.

An explicit planning process would synchronize deliverables by all parties.

This process would be accessible from interactive terminals. The planning

system would be sufficiently programmed to prompt for delinquent entries or

inadequate responses. This intelligence would include the ability to suggest

72
adequate work-around during contingencies. Figure 4-20 gives examples of

issues to be addressed by long-termplanning.

The consequence of interactive sessions associated with this long-term

planning process would be the definition of specific dates agreeable to both

parties for milestones associated with the activities typified in Figure

4-20. Naturally this procedure would be interactive and, when required,

supplemented with face-to-face negotiations. However, the long-term planning

process could easily be designed to provide prompting comments to either party

that would indicate, among other things, time to fulfillment of the next

milestone and the status of past milestones fulfillment.

A major function during this phase will be customer familiarization with the

required standards. In addition, contingency management planning would be

initiated in order to establish respective roles in the event of payload

malfunction. This planning would continue to be updated as the project

progresses, perhaps even supported by a customer failure modes and effects

analysis.

Select Area for Milestone Planning Development

• Interface Specification

• Simulation

• Training

• Logistics Support

[_ • Payload Checkout

• Requirements Definition

• Software Delivery

• Review

Figure 4-20. Integrated Planning Process

-..- Cu: In.House

-J' _ Payload Oevelopment

Schedule

73
4.4.1.3 Development and Training. As development progresses, details,

specifically Interface Control Documents (ICDs) must be agreed upon. In

general, standards will exist. Even so, each customer will have certain

options and related design decisions such as:

Encryption/decryption

Higher level protocols

Data capture parameters

Display page definitions

Processing algorithms

Command philosophy

Command specifications

Telemetry measureables

Operational constraints

Standard core services.

The standard core services requested by the customer will include avionics

support (orbit and attitude determination), core resources monitoring (power,

core data and communications services, ECLSS usage (on Space Station), sensor

monitoring, etc.), configuration management, generic resource scheduling, etc.

Payload operations could be simulated on NASA premises or through

telecommunication from NASA to customer premises. NASA supported simulation

would include mechanical, electrical, logical, and format test for

compatibility with the Space Station or Platform data system.

Higher fidelity simulations may be required for payload operations which have

complex interfaces to the Space Station or Platform Systems and/or which

impose risk on the health and safety of the Space Station/Platform. In these

cases, their operation cannot be made autonomous, and coordinated operational

scenarios will be required.

Dependent upon the nature of the payload and the fidelity of the simulation

chosen by the customer or required for Space Station or NSTS crew training,

the customer will have to provide varying amounts of information,

characterizing the payload. Figure 4-21 gives example items.

74
Y

Select Payload Characterization Category:

• Communications System Interface _r

• Telemetry and Command Interface _ i//J

• Display and Control Page Formats

• Payload Control Interfaces __

; O• Payload Flight Software IF I_ &

, • Fault Annunciations _ '_ I._._ _,

/ • Communication Occlusion Spec (Extemal Payloads) HI I I

• EVA Servicing Procedures

Figure 4-21. Payload Definition Requirements

Definition of other payload characteristics may include:

e

e

e

e

e

e

e

e

e

a

e

e

Payload design documentation

Workstation/payload interfacing software (for Space Station operation)

Payload models

Ha]function and anomaly procedures

Environmental contamination -- outputs and sensitivities

Power and thermal requirements

Fluid dynamics

Graphics information; information required for visual modeling

Berthed payload dynamics (includes RMS-type operations)

Payload retention and deployment specifications

Payload tracking (deployed and co-orbiting payloads)

Carrier (OHV and OTV)/pay]oad interface specifications and switchover

procedures for deployment (e.g., hardwire to Space Station vs. RF

link tracking, telemetry, and command interfaces)

75
To ensure that the customer's payload can be integrated into the Space Station

or Platform in a straightforward manner, and in order to ensure data

availability, the customer will have to provide information for simulations.

This information will vary in detail depending on the complexity of payload

operations and required coordination with Space Station or Platform systems.

Oiscussions will probably begin several years before the detailed simulation

is required. Initially, only general instrument parameters will be required.

These will then be refined up to the time that the complete simulations is

available. At this time customer provided models, or an actual payload

simulator developed by the customer will be used for simulations and training

on complex payload operations.

Training would be mostly applicable when a Customer Mission Specialist (CMS)

is required. If the Mission Specialist is trained by NASA, this training

could include all adjustments, installation, tear down and rebuild with any or

all specific parts of the customer's payload. Further, a ground operator

instructor could be co-trained by means of closed circuit television with

appropriate time delay.

Other typical training choices for the customer include:

SSPE training -- OMV and OTV (for co-orbiting platforms), platform

operations, etc. or subsystems which are subject to customer

interaction.

Instrument control -- cameras, thematic mappers; multi-spectral

scanners, telescopes, sensor pointing.

Platform Operations control center capabilities, interfaces, and

operating procedures.

• POCC operations training for customers purchasing POCC services.

Services training -- TMIS (or its equivalent for customers),

scheduling services.

• Voice communication protocol

76
• Archival data retrieval and analysis.

• Space Station and Program capabilities and operations.

It should be noted that no science or payload training will be available on

the Space Station Program. Thus, such training, as is required may be

minimized in customer ground facilities.

4.4.1.4 Launch Support and Payload Integration. The customer will be

actively involved in all integration and in all of the integration and test

phases of his payload. This section discusses the program support provided to

the customer during predelivery testing, launch support, transport to orbit,

and during final integration and test onboard the Space Station or Platform.

Predelivery testing would principally consist of some levels of simulation, as

discussed in Section 4.4.1.3. The level of complexity of this testing will

vary from customer to customer. Tests could be as simple as a mere physical

and functional electrical verification up through a rather complex, high

fidelity simulation. The location of these tests would, in turn, also vary

depending on complexity; they could be performed at the customer's facility or

at a NASA facility.

Launch support would include a variety of customer support operations such as

calibration, flight readiness checkout, environmental control, interface

verification, and other functions that could be performed prior to launch.

These functions that would be )6 tested are dependent on the type of payload.

The final integration and test of the payload would then be performed by the

crew or the CMS possibly in conjunction with the ground based customers. The

Mission Specialists will need to perform instrument checks, operational

checks, and data handling checks. These might include:

Instrument Checks

Damage Inspection

Alignment and clearance checks

Pressure test

77
Power connection checks

Basic start-up test (a go, no-go type assessment)

Thermal checks

Operation Checks

Functional Checks

Communication interface checks

Temperature

Cleanliness

Humidity compatibilities

Safety constraints (hazardous material handling, etc.)

Emergency procedures

Maintenance procedures

Data Handlin9 Checks

Instrument calibration and baseline operational checks

Data capture

Data reduction algorithm verification

End-to-end data transmission and verification test

Software and data hardware verification

Command verification

The customer-developed test and verification procedures will be performed for

assurance that the customer apparatus is performing properly, that no

unexpected interface problems have occurred, that no transit damage has

resulted during the launch and transport to the spacecraft, and that the crew

or CMS has set up the payload to operate as expected. This procedure

execution phase is shown in Figure 4-22.

4.4.1.5 Operations Phase.

4.4.1.5.I Status. Customers could maintain knowledge of the current Space

Station operation by means of remote terminals. Information obtained would

include that shown in Figure 4-23.

78
Select Test Procedure Category for Execution: ._,_,_

• Instruments Checks

• Operations Checks

[_ • Data Handling Checks

I

)orations and Validation ......

Ground Support

Figure 4-22. On-Orbit Test and Validation

Select Operational Status Category:

• Current and Extended Ephemeris

• Current and Projected Ground Contact

[_ • Near-Term Reboost Schedule

• Near-Term Shuttle Visits

• Space Stations Environment

• Current Station or NSTS Crew Activities

I/ • Mission Timeline i

• Projected Downtimes

• Projected Communication Times

- II II_II II

_C nr

.. _ . |m f

F .

Figure 4.23. Space Station Operational Status

;'9
As protected by an access code, the customer would also be able to obtain

specific status information relative to his payload operations such as:

Current operating schedule

Projected operating schedule, especially where required resources may be

impacted

Current health and safety

Logistics status (consumer resupply schedule)

Archival data status (location, amount, accessibility)

Maintenance schedule

Status of payload instrument interfaces.

4.4.1.5.2 Scheduling. In thecontext of this section, scheduling refers

to the prearranged timeline execution of payload commands in context with

operational status. This is in contrast to the planning function which takes

place over a period of time prior to command execution. Scheduling which

takes place closer to the time of execution frequently involves conflict

resolution between requests for limited space Station or Platform resources.

The scheduling function must take into account changing priorities and payload

compliment.

Principal Investigators or Payload Managers clearly prefer that their payload

schedules be autonomous; certain payload operations, unfortunately, result in

potential conflicts between payloads and between any given payload and the

Space Station or Platform operations. Therefore, scheduling must consider the

interrelationships between these elements. Constrained and restricted

commands will be subject to scheduling and timetagging based on numerous

criteria such as the Space Station or Platform attitude, orbital position,

interaction between payloads, etc. Unrestricted commands may bypass the

scheduling function of the customer's discretion, and be delivered directly to

the payload.

8o
There maybe more payloads on board the SpaceStation than can be operated at

their maximumdesired duty cycle becauseof limited resources. Principal

Investigators will need to interact with the scheduling function to help

optimize the output of their payloads within the constraints imposed by the

limiting resources.

Outside events, such as emergencies or even transient observational events may

dictate the desire for short-term schedule modification. The Space Station

Program must support different time levels of schedule change as, for example,

monthly inputs (astrophysics), daily inputs (earth observations), hourly

changes (atmospheric observations). In all cases the SSDS must support short

term schedule revisions down to the last minute to accommodate changes in

observations and targets of opportunity.

4.4.1.5.3 Payload Control. Customer control over payloads will be

exercised primarily through commands; commands may be entered either from the

customer facility, the Payload Operational Control Center, from the Space

Station (includes the co-orbiting platform), or from commands stored or

generated by the payload.

Figure 4-24 illustrates the SSIS top level role in payload operations of which

payload control is one. Not shown here is the aspect that many customer

commands are not subject to scheduling and pass unrestricted directly to the

payload, while others will be checked prior Co transmission to the payload.

During the development stage, the customer will provide NASA with a list of

expected commands and associated results from these commands; this list will

be updated through operations. All commands will be categorized by the Space

Station Program according to whether they are unrestricted, constrained, or

restricted. Unrestricted commands may be-exercised by the customer at any

time without review by the SSP, subject to the limitation that such conditions

as emergencies or safing modes could prevent the delivery of unrestricted

commands. Typical unrestricted commands might include:

Iris adjustments

Filter wheel location

Change in focal length

81
\_ Payload

• Command Initiation

.4....-

• End-Item Command Validation

• Long.Term Science Data

Archive

• Data Processing and Information

Extraction

Customer Facility

Figure 4-24. Payload Operations

mmmmmm'

_A

• Payload Planning/Scheduling

- Interactive

- SSIS Resource Allocation Among

Customers

- Support for Alert and Rapid Replanning

• Payload Control

- Functionally Transparent R/T and SPC

Support

- Protection Against Unauthorized Access

- Command Receipt Validation

• Payload/Ancillary Data Handling

and Distribution

- Catalogue, Archive, Manage, Disseminate

- Transparent Customer Data Delivery

• Quick-Look in R/T

• Level 0 Within Negotiated

Time Period

- R/T and Post Mission Engineering and

Operations Data

Payload Operations // Regional Data

Control Center / Center

,I

SSIS Standard Customer Services

O

Contained gas flow rate

Request for video infon_tion

Shutoff of equipment (no large power surge)

Temperature sensing.

Restricted commands are, by definition, those commands that might involve the

health and safety of the Space Station or Platform or any habitable portion of

the Space Station. Typical restrictive commands might be:

Power on (significant power surge)

Attitude related maneuvers

Toxic material control

Spacecraft data base modifications

Pyrotechnic initiation

Component rotation

EVA navigational control.

82
Constrained commands are, by definition, those commands that may affect other

payloads and/or commands that require certain Space Station or platform

support requiring associated engineering commands. The list of constrained

commands will vary in time due to a changing payload manifest and an evolving

spacecraft configuration.

payloads are:

Typical constrained commands which may affect other

Gas emission

Electromagnetic wave generation

Demand for spacecraft resources

Communications demands

Large thermal changes.

Typical of the payload commands affecting the spacecraft might be:

Observations requiring large scale attitude maneuvers

Power bus reconfiguration

Module atmosphere pressure changes

Stored program commands can fall into any of the above categories. In

general, the customer will have unencumbered control of software embedded in a

payload. However, restricted and constrained commands must be checked for

execution.

One basic requirement of the SSOS is that the customer be granted privacy of

command and data. Privacy of the command channel can be effected by ensuring

adequate authentication of the customer identification code prior to

transmission and permitting encryption. Similarly, the customer's command

data base and the nature, type and results of his commands must be protected

by adequate code words. In addition, the NASA will design to ensure that a

customer command sequence cannot be encroached upon. Security, however, shall

be the responsibility of the customer, as for example, by providing his own

encryption/decryption devices as desired.

In addition to digital commands, the customer may exercise a command process

through either audio and/or video communication with Mission Specialists.
Again, during such operations, these links can be kept private. For certain

operations including the co-orbiting platform and/or the Orbital Maneuvering

Vehicle (OMV), the customer could be permitted, within the limits of safety to

control selected operations by direct interaction. This would require the

customer's presence at the appropriate control center.

The customer may incorporate validation into the payload command, either by

telemetry measurables or by end-item verification. In addition, the customer

may request the SSDS to provide status throughout the command process, e.g.,

RF lockon, command receipt, and command transfer to the payload. The Space

Station Program may also provide full duplex verification of command delivery

to ensure no undetected transmission errors.

4.4.1.5.4

locations:

Customer Data. The customer may receive data at several

Space Station (for customer'Mission Specialists)

Orbiter

POCC

Oiscipline-oriented regional center

Customer premises.

Data may come from several sources: Payload (real time and delayed),

ancillary (real time and delayed), payload archives and engineering/core

archives. The data may be transmitted through TDRSS, or by alternative means

supplied by the customer.

Operational aspects of SSIS support for data flow to the customer are shown in

Figure 4-24.

With the exception of data received at the Space Station or NSTS, real time

data will actually be subject to a variety of delays; these delays will not

necessarily be constant for any given customer or type of data. The

transmission delay is predictable but may vary for any given task. Even

though dedicated TDRSS links may be used, transmission and buffering delays

will still occur. It is, as yet, uncertain whether there will be competition

for TDRSS links among the Space Station, POP(s) and the COP. To the extent

84
that channels are shares, real time data will be restricted. Given the high

data rates now projected for some payloads, further buffering may be necessary

at TDRSS White Sands recieving station in order to match the rate of incoming

data with the available link capacity leaving White Sands. If the data are to

be distributed from a POCC to the customer's premises, then further buffering

is likely, in order to accommodate POCC to customers data link rates. Under

the foregoing conditions, it appears that there are major potential

differences in system impact between data delivery with only transmission

delays and data delivery with relatively short delays resulting from in

transit buffering. Although operations with the SSDS and even the SSIS should

be transparent to the customer, significant data delays are likely to occur

unless a single access (SA) link has been scheduled. A design driver will be

the requirement to minimize these delays and restrictions for the delivery of

payload and engineering/ancillary data for real-tlme operations.

Data received at any site from any source may be processed at a variety of

levels. Data will be provided by the SSDS as raw data or at Level 0 at the

customer option, or at level 1A by the SSlS with processing performed at the

customer's option. At the Space Station and POCC sites the customer can

perform routine analyses on his data using SSlS standard customer services and

can perform quick look and routine analyses using SSIS facilities and his own

software resources.

One example of customer processing above Level 0 is quick-look data

processing. The SSDS will provide the customer any selected Level 0 data from

his payload data stream to allow for quick-look processing in space, at a

POCC, or at the customer's premises. This data will include the necessary

ancillary data to support the processing to the desired level.

Required ancillary data will be selected by the customer during the

development phase. These data will be provided to the customer coincident

with his relevant data. Examples of ancillary data are:

Time

Configuration changes

Attitude

Orbit position

Water dump status.
Pointing/orientation

Power Flux/usage

EMI mapof station

Thruster firings

Internal pressure

Atmospherecomposition

Relative humidity

Radioactivity exposure

Chemical contaminants

Optical environment contaminants

Crew/operations activity

Accelerometer data

OMVberthings/status

EVAactivity

Internal temperature

External temperature

Particulate count

Particulate types.

The SSDSalso provides the customer with the capability to request ancillary

data not on his original list. In this case, the data would be retrieved from

the core data base, whether in space or on the ground. The customer mayalso

retrieve data from the core engineering archived data base during its

retention time of at least two years.

The customer's ability to process data shall be protected by several

mechanisms. To begin with, the customer shall have the option to peruse

quick-look data at the level he selects. Further, upon receipt of customer

data, should anomalies becomeapparent, the customer may request repeat

transmission of data from an SSOSarchive for up to 12 hours. Further, this

samecapability exists for data up to one week of relative age with a slightly

greater time lag for delivery. All of this data will contain a priori

designated ancillary data. Should the customer desire engineering or

ancillary data other than a priori designated ancillary data of one week in

relative age, it may be obtained from short-term archives. Such data would

also be available for a period of up to 2 years from longer term archives.

86
The customer shall be able to either restrict or authorize access to payload

data. A standard level of SSDS data privacy will be available to the

customer. In addition, the customer may elect to implement his own higher

level of security.

4.4.1.5.5 Teleconferencing. Customers may elect video and/or voice

teleconferencing among several sites on earth and the Space Station and NSTS.

This teleconferencing capability may be required when missions involve

different experimenters located at different sites or where experts are

available at different sites.

Video teleconferencing would be possible between NASA facilities and the Space

Station and NSTS using NASA's private telecommunication networks currently

under development (e.g., NASCOM, Program Support Communication Network) and a

link to space through White Sands. Optionally customers may tie into the

video conferencing network by leasing transmission facilities which

interconnect with the NASA facilities. The number of customers a11owed this

type of direct connection will be severely limited. Further, this type of

function is limited to standard physical (transmission) and logical

(compression algorithms) interfaces. Such customers must also provide their

own equipment.

Customers will arrange a video conference in advance by calling a central NASA

point of contact. Since the conference resources are shared among many

customers, and might be shared with Space Station core operations, delay may

vary depending upon the degree "of contention. It is likely that only one

duplex, two party conference may be in progress at any given time. However,

many parties may have amonitor only" capability.

To schedule a conference, each customer must specify the time, date, duration

and the location of the "chaiman" in control of the conference proceedings.

The "chairman location" must be at a NASA facility.

Each conference will be in "near" full motion as NASA's networks employ video

compression down to 1.544 Mbps; the customer will notice some degree of

degradation.

87
The transmission among the NASA facilities (including the Space Station) will

be encrypted (in response to the general requirement placed by Presidential

Directlveon all such transmission). However, encryption to the customer

premises is the responsibility of the customer.

Voice teleconferencing, in contrast to video teleconferencing, may be arranged

on relatively short notice. Customers will see few delays in scheduling.

Urgent requests, particularly in support of an active mission, may be

scheduled on the same day.

Voice teleconferencing may be implemented through existing NASA facilities

with a link to the Space Station through White Sands. However customers can

tie into the conferencing network by leasing transmission facilities which

interconnect with NASA facilities. Customers who do so must provide their own

equipment. Conferees may also be added using "dial-up' connections over the

telephone network, though the customer will likely see severe degradation of

quality in this case. Orbiter teleconferencing capabilities for Polar

Platform missions are described in SG07700. Capabilities can be scheduled

through the Platform Operations Control center.

Privacy for all links may be provided by virtue of having point-to-point

transmission facilities. This privacy will apply to the Space Station by

providing an appropriate receiver.

4.4.1.5.6 Customer Mission Specialist (CMS). Some customers may desire

that their own Mission Specialist perform their payload on-orbit operations,

as was the case with the recent electrophoresis experiment where MOAC supplied

a CMS as part of the NSTS crew. Feedback from these experiences are providing

valuable data as to how the SSlS can better serve customer provided CMS

personnel. The Customer Mission Specialist will operate under the authority

of the Station Director or NSTS commander, as appropriate, and will perform

associated payload operations and housekeeping tasks.

Two aspects of the SSIS functions to support this level of customer

participation are the need for high fidelity simulations, and the need to

provide a flexible and efficient near-term scheduling environment allowing a

88
high degree of autonomy for onboard crew personnel. This aspect is also

addressed in the operator's view of this operating concept. Other items, one

of which is standard service requirements, are: ready access to a ground data

base with pertinent experiment and systems data; point-to-point audio and high

resolution video; and real-time access onboard to Space Station engineering

and payload data.

NASA documentation will be provided that describes the requirements for

selection and qualification of these Mission Specialists. Given selection,

Customer Mission Specialists will receive training on general Space Station

operations for approximately two to three months. Examples of training areas

include:

e

Zero-g orientation

Habitability equipment and procedures

Activity planning

Communications procedures

Emergency and safety procedures

Exercise and health maintenance routines

Housekeeping

Information and data management system.

Naturally, the CMS would prove useful in the event of a contingency involving

the customer's payload by providing fault isolation support, limited repair

and modification and part replacement.

4.4.1.6 Post Mission Operations.

The customer may receive some services after mission completion. This would

include return of the payload, availability of archived data and data based

files, analysis of space affects on the physical payload, and analysis of the

payload data. The analyses, both scientific and engineering, would be based

on NASA's experience and would include correlation of spacecraft operations

and status with the particular payload operations involved. Engineering data

will be archived by the Space Station Program for at least two years.

Customers can negotiate for longer term storage of engineering data as well as

long term storage of payload data. The customer will have knowledge, by means

89
of an interactive terminal, of the contents of all archived data and the means

to retrieve it with the exception of data that is protected for privacy

purposes. In this regard, any customer may designate the level of privacy

associated with the data, and through mutual agreement, allow other persons

access to the data. Again, the level of post-mission support would be

cost-dependent.

4.4.2 Operator's Perspective of SSlS Operations

SSIS operation is described in this section from the perspective of ground and

onboard Space Station Program (SSP) operators. Operator is defined as either

NASA or contractor personnel who manage, coordinate, and effect SSP operations

and assist customers in accomplishing mission objectives. The operator's

perspective is described through a set of operator tasks. These tasks range

from system development to real-time operations. Section 5 provides

additional information.

Figure 4-25 provides an overview of operator's perspective discussed herein.

EVA

OMV Integration/ Customer

MMU Checkout PIL Systems

OTV _ _ / • SS Based

"%__ .j • FreeFlyers

/ ....... _ _.._- Core

COP "__(_;_at;rs_________= Systems

__.A.._ __._ lining

Customer

Integration POCC _ Operator

Test _ D t

Planning and Scheduling

Training

ata Collection

Standard J. _1 and Distribution _ Customers (TDRSS, NASCOM, RDC, etc.)

...._ Software • OTV

Support v _

NSTS Control

(SSE) (MCC)

Figure4-25. Overviewof Operator's Perspective

90
4.4.2.1 Operator Background. Before the individual operator tasks are

presented, the assumptions made for the operators' perspectives and a

description of generic material that applies to all the operators is

presented. These descriptions provide background material that may apply to

one or more of the operator tasks and can influence the operator perspective.

The generic material provides viewpoints or perspectives of what an operator

should know about these subjects. None of the descriptions are specific tasks

but concepts that influence operators' perspectives. This information enables

the operator to understand the overall ground or onboard operational

environment and/or scope of responsibility. At times, these descriptions

touch on customer perspectives to give a clearer picture of the operator

environment• The five areas cover

I •

2.

3.

4.

5.

Automation

Work stations

Redundancy/failure managemeht

Privacy/security

Standardization/commonality.

The fifteen operator tasks are

1. Hardware maintenance

2. Software development and maintenance

3. OMV, OTV, MMU, COP, and free-flyer control

4. Docking/berthing

5. EVA

6. Avionics management

7. Non-avionics core system management

B. Logistics

9. Unmanned operations

lO. Safe-haven/contingency

II. Facilities management

12. Training and simulation

13. Planning/scheduling

14. Onboard mission support

15. Customer coordination

91
4.4.2.2 Assumptions for Operator's Perspective

The following assumptions augment those of Section 4.1 for the

descriptions in 4.4.2.

e

o

Operator data provided by standard communication services

Spacecraft hardware maintenance is primarily replacement.

COP is serviced from the Space Station

POP is serviced from the NSTS

Prime software development languages for the SSP will be a minimum

set of standard High Order Languages (HOL's). Included will be a

- "User Interface Language n for commands, displays,

system test.

Space Station controls all operations within its control zone.

Constellation Operations:

- Station remote manipulator for berthing/docking,

deployment, station servicing.

- OMV can grapple, maneuver OTV, COP, free-flyers

- EVA's for COP, OMV, free-flyer servicing

SSCC provides global interfacility coordination

COP and POP control centers control platform operation

Planning and scheduling integrates core and customer requirements;

all data/plans for flight and flight support operators contained in

flight data file.

4.4.2.3 Generic Concepts. The six generic support considerations and

concepts described in this section apply to all of the specific tasks

performed by the operators.

4.4.2.3.1 Automation. The. first viewpoint of any operator is to ask: what

job or role must I fulfill? One major factor impacting the answer is the

degree of automation of the system that will support the operator. The

spectrum of automation ranges from a labor intensive, step-by-step manual

control to attending to a system only when alerted by the system of a problem

or need for interaction. The operator does not have to monitor a display

unless there is a specific reason. Casual monitoring is possible but not

92
required. Certain safety aspects mayrequire close-at-hand monitoring for

specific operations to reduce the time for manual takeover, but this is a

planned event.

Table 4-5 presents a view of core and customer weekly manpower derived from

data in the Phase B RFP (reference l). The data shows the limited number of

hours available per week for all operation activities, particularly for core

operations. These data clearly show a limitation of onboard operator time

availability. The automation and autonomy trade studies must consider this

limitation for the autonomous, non-automated Space Station option in addition

to other factors such as cost effectiveness and total program cost.

The burden of onboard operator monitoring and management of core and customer

systems can greatly be reduced by tutorial and prompting aids. Figure 4-26

gives a view of an operator managing three displays. The cursor on the

operators Daily Summary is positioned and the "enter u key is depressed to

activate the Payload SAA XXX Plan display. After, "events" l and 2 are

completed ("C" under status), the cursor is positioned to Event-3 and the

Event-3 detailed display is activated. This display shows the operating

status as active ("A") at Step-2 whose duration is 50 minutes. The

Table4-5. On-OrbitManpowerAvailability in Man-HoursPerWeek

Core

Activity Support

Scheduled 48 (Note 1)

Training 6 (Note 3)

Replanning 6 (Note 3)

Unscheduled 6 (Note 3)

Total 66 Hours

Notes:

Customer

Support

264 (Note 2)

18 (Notes 3,4)

18 (Notes 3, 4)

18 (Notes 3, 4)

318 Hours

(1) 2 Space Station Operators x 4 Hrs/Operator x 6 Days = 48

(2) Note (1) + 4 Mission Operators x 9 Hrs/Operator x 6 Days =

264

(3) Space Station Specialist Time for These Activities Divided

Evenly Between Core and Mission OPS

(4) Nominal Mission Specialist Time Spent Only on Missions

93
[.,sS,ON sOAY12,SU..A.,I

IO : O0:O0 129:08:35:11 00:05:10 120:00:10:21

PAYLOAD SAA XXX I PL SAA XXX-EVENT 3 ]

07:00 WAKEUP

07:30 BREAKFAST STATUS EVENTS OPS STATUS STEP OPS

00:00 TRAININO

r--1 00:30 PL SAAXXX -4D C I-WARM UP SW I ON C I-SEQ. 1 START KY.AA

10:30 PL SAAYYY (5 MIN) (5 MINI

12:00 LUNCH C 2-1NIT SW 2 OH r--I A 2-SEQ.1 MIO HY-I,Q

13:00 EVA-PLSAAZZZ (10 SECl 150MINI

18:00 REPLAN/TRAIN I---I A 3oSEQ.i SW 3 QN -4 3--$80.1 Ell KY-BO

\,..°/ ,,.., ,..,., j

20:00 DINNER 4-SEQ. 2 SW 4 OH

21:00 FREETIME S-SHUTDOWN SW I OFF

23:00 SLEEP

Daily Summary Payload

SAAXXX Plan

Payload SAA XXX

EventSequence

Figure4-26. Promptsfor Operator

elapsed-time clock indicates 5 minutes and I0 seconds of activity into the

Step-2 sequence. These types of aids are necessary to maximize efficient

onboard operations and to minimize training time.

In an effort to relieve the Space Station ground and flight operators of as

many duties as possible, the promising potential of artificial intelligence

(AI) will be considered. In addition to the more traditional automation

techniques, full use will be made of the emerging capabilities of AI systems

that perform such functions as: problem diagnosis, planning and scheduling,

computer-aided instruction and training, data base storage and retrieval,

voice recognition, natural language understanding, visual pattern recognition

and robotics. IOC versions of these systems will generally tend to take the

form of operator "assistants" rather than operator "substitutes". As

confidence grows in the reliability of these systems, they will evolve toward

more autonomous operation.

The area of artificial intelligence with the most near-term promise is in the

area of "expert systems". Very significant gains in operator productivity can

be expected early in the program through the utilization of this technology.

Potential SSP applications for expert systems are numerous and varied, and the

production of these systems will yield a great deal of terrestrial benefit, as

well as Space Station benefit. Some of the more obvious applications are:

94
diagnosis of problems in on-board systems, medical diagnosis, activity

planning and scheduling, intelligent computer-aided instruction and training,

and intelligent data storage and retrieval assistance.

Figure 4-27 provides a brief summary of operators perspectives towards

automation.

DRIVERS

• Full.Time Operation

• Limited On-Orbit Resources

• Minimize Ground Army

OPERATOR'S VIEW OF AUTOMATED OPERATION

• Normal Operations Are Automated

• Operator Notification When Action Required

• Prompts Operator

• Level Choosen by Operator

• Supports Training

ARTIFICIAL INTELLIGENCE TECHNOLOGY

• Expert Systems Now Emerging

• Other Technologies for Growth

• Voice Recognition

Figure 4-27. Automation Is the Key to Effective Use of Operators

4.4.2.3.2 Workstation. Workstations are generally viewed as multipurpose

applications consoles (MPAC). These provide ground and onboard operators the

necessary means to control and monitor the status of all SSlS functions. A

portable MPAC is also available for flight operations at locations away from

fixed MPACs.

The basic characteristics performed by the MPAC are:

l ,

2.

3.

4.

Command and control (interactive)

Multifunction (not dedicated to a specific task)

Visibility into all SSIS functions

Annunciation (alarms, caution, and warning).

95
The operations tasks are all accomplished by configuring a MPAC. A second

MPAC can be configured as a backup to the prime MPAC.

Workstations will also take other forms. Onboard windows will be used to

monitor EVAs, exterior station operations (docking/berthing, vehicle relative

motion, mechanism movements, and earth/celestial observations). Television

monitors will be used extensively for IVA and EVA operations. OMV and RMS

end-effectors and docking operations are some examples. Also, joystick

control of the Space Station Mobile Remote Manipulator System (MRMS) is a

special feature not part of the MPAC. Other special mechanisms for specific

operations at various Space Station locations will be used.

4.4.2.3.3 Redundancy/Failure Modes. The Space Station and platforms will

have a wide variety of redundancy management methods employed in the

implementation of the ground and on-board systems. Those ground parts of the

data system which do not provide real-time support are expected to be simplex,

with repair as the failure recovery technique. Any ground data system

components which support real-time operations may, in addition, include

redundancy in the form of on-line (hot backup) equipment ready to take over

immediately, or in the form of off-line (cold backup) equipment that can be

reconfigured in a short time for real-time support. In both cases, the

current configuration will be available as a checkpoint from which to restart,

without the need to manually respecify the entire system configuration.

The onboard subsystems may require a wider variety of redundancy options, due

to more limited repair and replacement capability. Those portions of onboard

data critical to the operation of the spacecraft and to the well-being of the

crew (Space Station) will employ redundant on-line subsystems, executing in a

fail-operational/fail-safe (FOFS) configuration. Those portions of the data

system requiring recovery in a few seconds may utilize an on-line,

reconfigurable spare in a failure mode. Less critical portions that allow a

few minutes of down time, may be implemented as one on-line unit with an

alternate unit connected to the system but with power removed. This cold

backup technique allows recovery by manually or automatically turning off the

faulty unit and turning the replacement unit on. The faulty unit may then be

repaired or replaced from the spares. For subsystems which allow extensive

96
periods of down time, ranging from a few minutes to several hours or days (or

until the next NSTS visit, in the case of the POP(s)), there may be a single

unit connected to the system. In case of failure, this unit would be repaired

or replaced from the spares before being restored to normal operation.

Finally, for the least critical subsystems, where loss is very unlikely and is

not critical to safety or to the mission, there may be no spare or repair

capability on-board.

The operator may be involved in implementing portions of any of these

redundancy methods. The operator will be especially involved in directing

system fault down when system capability must be shed because of failures, in

fault isolation and recovery, and in repair. The exact technique to be used

will depend on the subsystems which are defined as the system design is

developed. Key considerations in arriving at the redundancy levels will be

the criticality of the subsystem, the likelihood of subsystem failure

(including the probability of multiple failures between the NSTS revisit

points), the sparing level (subsystem, units, components, etc., including

online spares on the platforms), the ease of replacement or repair (especially

if EVA is necessary), and the storage space available For spare parts.

4.4.2.3.4 Privacy/Security

Privacy and security (definitions) of data and communications will be

needed within the data system to prevent unauthorized access to customer's

data bases, payloads and operations procedures. Security requirements may

include the resource utilization profiles of some payloads. These needs must

be balanced with the need for safety of the vehicle and crew and for the

control of interaction among the vehicle and several payloads.

The three basic parts of privacy provided by the data system are the ability

to command a payload or core function, the ability to passively listen to

communications, and the ability to read out stored data and procedures.

Commands to the payloads must be checked for authorization of the operator to

command that payload. Further measures must be provided to assure a high

degree of security and privacy of data, such as that contained in on-board or

ground data bases and of data transmissions. The data system will include

normal commercial protection techniques such as password protection for access

97
to data bases. All transmissions of data will be encrypted. In addition, the

individual customers may apply their own data encryption within the data

itself for further security and protection against "tapping" the communication

links. The data required for interactive planning and scheduling must also be

protected from general access to avoid inadvertent compromising of proprietary

processes. The only constraint imposed by the data system on individual data

encryption is that any information needed for routing data within the data

system must be in the clear. For example, the identification of the

destination of the communication, the identification of the sender, and

adequate information to distinguish restricted and constrained commands must

be in the clear•

4•4.2.3.5 Standardization/Commonality. Standardization can lead to

increased human productivity and reduced program life-cycle costs and

therefore will be used extensively on the Space Station Program. The concept

of standardization can have different meanings. Standardization can mean a

common element used widely within a program, but this element may not be

common with any other program. It can mean commercial or military standard

specifications or discipline organization standard specifications for

communications interfaces, network protocols, processor instruction

architectures, etc. Standardization will be incorporated into the Space

Stations program in some or all of the following forms:

I •

2.

3.

4.

Space Station program defined standards

Commercial standards

Military standards

Discipline organization (e.g., IEEE, SAE).

These standardization issues will be the subset of a Task 3 trade study to

determine the level and vigor with which standards will be employed.

Commonality on the Space Station Program (SSP) means use of the same equipment

and software across Space Station Program Elements (SSPEs). That is the use

of standard or common hardware and software systems for Space Station,

Co-orbiting Platform, Polar Orbiting Platform, OMV, OTV, etc. As such,

commonality could be considered a higher level of standardization applied at

the program level.

98
Standardization will be used extensively for application in the SSP and in

SSDS. Standardization will be implemented for:

l ° Data Distribution

- network protocols

- network operating systems

- inter-networking

. Software languages

- user interface language

- applications language

3. Operating Systems

. Data Base Management Systems

- query language

- data organization

5. Packet telemetry and telecommands

. Processors

- embedded microprocessors

- general purpose processors

- network interface units

7. Multi-purpose Application Consoles (MPAC)

8. Software development approaches/tools.

All of these areas are transparent to the operator except the various

languages (user interface, applications, DBM query), the MPAC and the software

development approaches/tools.

The International Standards Organization (ISO) seven layer reference model for

Open Systems Interconnect (OSl) is not a fully accepted standard, but current

and future implementations will greatly influence future standards.

99
The following operator interface scenario describes the standardization level

that will be realized on the SSP. The operator interfaces to the SSOS through

a standard MPAC. The fixed and portable MPAC are functionally the same. The

operator has worked on a standard MPAC during ground training and simulation

and knows the Logon procedures and how to select options from menus. Standard

aids are available which present "help u displays which the operator has seen

before and during training.

Changing or creating software in the space environment is the same process as

the operator uses on the ground. The applications language and user interface

language are the same and the software editor is the same. All the procedures

for changing or creating software are the same. The onboard operator will be

able to address software created off-line and make desired corrections.

Simulation support to validate and integrate new software will be available.

Protection will be provided to inhibit inadvertent or unintentional changes to

flight critical software. The flight-critical software development is a

ground process. The standard user interface language allows any operator to

create and execute test control sequences. However, coordination is required

if test control sequences cross some core subsystem and customer payload

interface boundaries.

The technique for requesting hard copy of displayed data is the same on all

MPACs. Each display panel used for subsystem control presents a unique

layout, but typically items such as the keybdard layout and touch screen

control will be standard.

The operator has a standard data base query language. The query language is

the same as that used on the ground for inventories, manuals, schedules,

maintenance, etc. The physical location of the data is transparent to the

operator.

Growth and technology insertion are both very strongly tied to

standardization. For example, growth in data processing can be achieved by:

(1) adding more processors to a system to provide additional capability, or

(2) replacing the entire subsystem with new technology. In either case, the

interface standards between the new change (processor, software, sensors,

devices) and the existing systems must meet established standards.

IOO
Software improvements can be particularly expensive in an embeddedsystem

unless pre-planned improvements were accounted for in the initial designs.

Again, interface standards must be met.

Operator perspectives for these improvementscould range from no impact to a

direct impact. Direct operator impacts are those that involve: (1) defining

the change, (2) implementing the change, or (3) new training because of the

change.

Figure 4-28 provides a summary of standardization/commonality with respect to

simplification of operations.

• Ground to Onboard

• Training to Operations

• Maintenance

• Throughout Space Station Program

• Core Systems

• Customer Systems

• Standard Customer Services

• Operations Transparency

• Growth

• Technology Insertion

• Changing Mission Set

• Data Handling

Figure 4-28. Standardization/Commonality Will Simplify Operations

4.4.2.4 Operator Task Descriptions. The following sections describe fifteen

operator tasks that encompass the onboard and ground SSIS functions. This

approach allows an across the SSlS functions view to provide a perspective of

the SSIS through the separate operator tasks. The viewpoints generally

represent mature operations. NSTS operations in support of the Space Station

Program are not emphasized.

101
The individual operator tasks may provide views that range beyond the

boundaries of SSIS. As such, the task scenarios were developed for

completeness and general understanding of task activities.

4.4.2.4.1 Hardware Maintenance. This operator task consists of maintaining

hardware associated with the Space Station and co-orbiting platform payload

and core systems. The hardware is the set of data management equipment and

subsystem devices. The hardware is distributed among the ground, the

platform and the Space Station. Therefore, the operators are physically

located in space and on the ground.

The hardware operator task involves the following

• Observation of equipment performance degradation or failure

• Isolation of the problem

• Determination of what action, if any, is necessary

• Scheduling the maintenance

• Performing the maintenance and retesting.

This operator task is accomplished by using the functions of device management

and monitor and status. Device management is a generic function that enables

the operator to manage and control the hardware and devices associated with a

specific function group. For example, device management covers the devices

associated with navigation. These devices could include star trackers, rate

gyros, and alignment sensors. Device management allows the operator direct

control via an MPAC over typical subfunctions for each device such as

- performance monitor

- redundancy management

- configuration management

- power distribution.

The performance monitor subfunction is intended for a detailed health and

status of the device. Monitor and status system is a global view of the

health and status of the subsystems.

102
Generally, monitor and status system provides the operator with the first

indication of a problem in a subsystem. System status provides this global

service. This function would indicate which subsystem is affected and how to

access the subsystem device management display for more detail. "Caution" and

"Warning" may actually provide the first indication of a failure if the

failure warrents an audio and/or visual alarm. Diagnostics support will be

used by onboard and ground operators to provide more detailed support in

determining the exact cause of the failure or isolating the failure to an

Orbital Replaceable Unit (ORU). Schematic presentation, expert systems and

trend analysis support will be available to the operators. Command interface

processing will be a software process that implements the operator MPAC input

commands to control any function group.

In summary, the device management functions in conjunction with the monitor

and status system function allow onboard and ground operator capability to

perform the overall hardware maintenance task for ground and Space Station

equipment.

4.4.2.4.2 Software Development and Maintenance. The perspective of this

task depends on the specific type of software to be developed. Software

development will be performed for

I. Onboard operating system and network operating system

2. Onboard application software

3. SSPE software: OMV, OTV, Core

4. Optional support for customer software development

5. Ground operations support sites: SSCC, COP-CC, POP-CC, DHC, RDC, SSE

6. System test and control - generic

7. User displays.

103
Another aspect of the problem is the specification of the language or

languages a software developer would expect to use.

Figure 4-29 illustrates the software development operator's viewpoint of the

SSE.

E_ CUSTOMER

SOFTWARE

LOAD ON-BOARD

SOFTWA RE

MOOE LS, TOOLS

0_, UTILITIES

(OPTIONAL)

J cUsT°mER I

! I_VELD*'ERI SSE COMMON

• USER SW • MODELS

PROGRAM

MANAGEMENT

DATA

GROUND

SOFTWARE

LOCAL • MODE LS "_ I

PROCEI$1NG • SIM REQ I UNIQUE

I

HQLS GROUND

I • OS . • HOL$

LOCAL J • NOS • OS MODELS, TOOLS,

f_-_..._._ PROCESSING I • UTILITIES • UTILITIES UTILITIES ,_

I_ I .I MODE_.TOOLS/"

o,.

/ .MODELS J GROUND l

• _-_ _ ./ • APPLICATIONS SW - I APPLICATIONI

ON.eOARD J ,l_t _ P •CMI)ATA- '_/_ IDEVELOPERI

LDEVELOPERI ___I'SSE I !'--

 ; ..>IOEVE'OPERS,LOCAL

--_ PROCESSING

Figure 4-29. Centralized Coordination Is Required for DistributedSoftware Development

The Software Support Environment (SSE) presents a perspective that is

essentially the same for all software developers. The Phase B RFP goal is to

use the SSE for all onboard and ground software development and maintenance

for each flight Space Station Program Element (SSPEs) and for their ground

support functions. Another Space Station program objective is to maximize

commonality of hardware, software and systems among the SSPEs. "The SSE is

defined as the common software required for the development of application

software for the flight and ground systems." The exact SSE will be under

study during the Phase B period. The SSE provides capabilities which supports

the development facility discussed in 4.4.2.4.11. The following is a summary

of the SSE scope.

I04
a)

b)

c)

d)

e)

f)

g)

h)

i)

J)

Language processors -- compilers, interpreters, preprocessors,

assemblers and link editors.

Simulators -- for design, development, test, validation and secondary

training.

Data Base Management Systems -- storage and access of large set of

data.

Requirements and Design Tools -- requirements development and program

design languages.

Test and Analysis Tools -- simulation aids and data reduction

Build and Delivery -- integration of software components into

program-end-items.

Operating Systems -- standard network operating system and standard

subsystem processor operating system for onboard SSDS.

User Interface Language -- a standard language for core and payload

operators.

Software Quality Assurance and Configuration Control Standards --

follow NMI 2410.6 for all software development.

Business Support Systems -- all support tools must be consistent with

the TMIS.

The above SSE scope is today's best perspective for Space Station Program

software development. However, all program elements may not be compatible

with these concepts. For ground facilities, we must consider that NASA

institutions currently contain millions of lines of development and

operational software that support various space programs. The potential to

recover much of the existing software base for Space Station Program

utilization will be traded against developing and integrating new software

based on program standards. It is anticipated that the ground systems will

continue to reflect a mixture of commercially available program product

software, NASA and DoD space program developed software and uniquely developed

software for Space Station Program.

A language utilization perspective for the various Space Station Program

software users is presented in Table 4-6 The table is based on several

assumptions, one of which is that a standard "higher order language" (HOL)

105
will be adopted as the primary method for software implementation. This does

not preclude the customer from using non-HOL source language as an embedded

element in the payloads but it will not be supported by the SSE. The payload

software must then only satisfy the required, standard interfaces to the

subject SSPE.

Table 4-6. Software Development Language Development

Software

development

type

Languages

Standard

HOL

User

interface

language

Other

language(s)

Onboard operating system X

(SS, COP, POP)

Network operating system X

Core applications X X

Payload applications X X X

OMV and OTV X X X (Note)

SSCC, DHC, RDC, SDE X X X

System test and control X

User displays X

Note: Allows for the potential use of existing flight-qualified embedded processor hardware and software.

The User Interface Language (UIL) is viewed as the prime operator language to

perform system testing and control. This applies to all SSPEs including the

Space Station Program ground and onboard elements. As indicated in the table,

UIL is viewed as the language that is utilized by all operators to build all

system displays and by any operator to build special displays for viewing

desired data. Also, UIL is used by all operators to build commands to acquire

data and to send commands to Space Station systems, ground and onboard, and

for customer payloads. Again, this does not preclude the payload operator

from embedding pre-stored commands that are envoked by onboard operators or by

standard customer interfaces.

106
The need for other languages is indicated in the table• These cover the

discussions presented above with respect to the payloads, the OMV and OTV, and

special ground operating systems, and existing institutional software programs.

The SSE, the above language view, and NASA controlled software development

procedures provide a perspective of software development. Operator developed

procedures must follow NMI 2410.6 for all software development.

4.4.2.4.3 OMV, OTV, MMU, COP and Free-Flyer Control. A background overview

for the constellation elements operations described in this and the next

section allows the Space Station to be used as an effective base of

operations. In summary, it allows: (1) a variety of environments, (2) extend

the range of man's operation, (3) extends system life, and (4) provides a base

for higher energy missions.

The general operator tasks associated with these five vehicles in association

with the Space Station are:

•

2.

3.

4.

5.

Maintain and service

Deploy

Control within Space Station control zone

Control outside Space Station control zone

Retrieve.

Task 1 is performed by onboard or ground operators. Tasks 2, 3, and 5 are the

responsibility of onboard operators. Task 4 is a ground responsibility and is

not in the SSDS. The preceding applies to the OMV, OTV, and COP. The MMU is

controlled only by onboard operators. All operators can utilize an MPAC to

achieve these tasks. All five tasks are achieved by managing operator input

commands/data and basic operation of the core systems.

Task l Maintenance and Service, is accomplished by using the functions which

support customer system operations, operate Core subsystems and basic crew

support. The OTV, OMV, and MMU maintenance operations are performed jointly

by onboard and ground operators. The service and maintenance of the COP and

free-flyers are both treated as payloads and are achieved by operator

interaction with functions which support customer payload checkout/service.

107
Any vehicle, while attached to the Space Station, can receive standard

services. These are: power, thermal control, structures and mechanical

support, communication, and external interface management. The platform is

serviced by EVA or robotic operations, either on site or retrieved and

attached to the Space Station. EVA may be based on the Space Station or the

Shuttle Orbiter, while robotic operations may be controlled from the ground,

the Shuttle Orbiter, or the Space Station.

Task 2, vehicle deployment from the Space Station, is achieved by onboard

operators. The Space Station MRMS is likely to be used for deployment of most

vehicles from the Space Station. The MMU is deployed by EVA operators. The

MRMS operator would impart sufficient relative velocity to avoid recontact.

The onboard operators could deploy the OMV by directly controlling its

translational capability. This depends on safety and environment

contamination considerations. The same could apply to the OTV. Another

option is, once the OMV is free it could be controlled by the onboard

operators to grapple and then deploy the vehicle (OTV, free-flyers).

Automatic deployment by the MRMS may be a possible operator selected option.

For task 3, control within the Space Station zone, the onboard operators will

generally control the attitude and positioning of all vehicles. This will be

accomplished by transmitting relative position and attitude commands to

constellation members. Those vehicles without guidance, navigation and

control functions (free-flyers) will be placed and repositioned by operators

controlling the OMV. Vehicles in the constellation will be maintained in a

basically coplanar orbit with the Space Station. Position monitoring and

traffic control will be highly automated functions. Approach and departure

corridors will be kept clear to allow access to the control zone.

Vehicles such as the OTV, OMV, and COP may leave the control zone and thus

require ground operator control. These vehicles are returned to the zone by

rendezvous sequences controlled by ground operation centers (Task 4). The

desired return point for entry to the proximity sphere is defined by the Space

Station traffic control function. Control handoff after rendezvous completion

is accomplished automatically by traffic control command to the cooperating

vehicles (OTV, OMV, COP). One transfer option is for traffic control to

10_
command the cooperating vehicle to maneuver to a zone reachable by the Station

MRMS (except COP). Another is to have the ONV maneuver the vehicle to the

MRMS reachable zone. When the NRNS has grappled the vehicle, traffic control

discontinues active control.

Task 4, control of vehicles outside the Space Station control zone are the

ground operator's responsibility. These are not discussed in detail.

Operations include: (l) maneuvering the OTV, OMV, and COP to and from the

Space Station control zone, (2) platform operations, (3) OTV missions, and (4)

free-flyer operations.

Task S, the retrieval of a vehicle in the Space Station control zone, is

achieved by onboard operators. The OMV is maneuvered to the docking/berthing

position along a safe return path. The safe return path is determined by

using traffic control for all approach trajectories. The OTV may be

maneuvered to the Station by onboard operators, or the OMV may be used to

retrieve the OTV. The MMU can be maneuvered by the EVA operator to the

Station MMU attach point. The COP is brought near the Station by the OMV for

EVA servicing.

4.4.2.4.4 Docking/Berthing. Docking/berthing is likely accomplished with

the use of the Station MRMS. It is basically the reverse of deployment.

Video cameras are used to monitor and an MPAC is used to manually control the

operation. The RMS operation could be highly automated; automatic deployment,

storage and way point maneuver sequences, collision avoidance from known

configuration, video on end-effector, automated grappling and rigidizing

sequences. The operator could invoke these automated sequences and supplement

them with manual RMS control to berth the COP, OMV or free-flyer. Final

alignment, retraction, capture latching, and rigidizing may be done by

automated sequences, monitored and controlled by the operator. The MMU is

attached by the EVA operator. The free-flyers are attached to a maintenance

position by the RMS or EVA operator.

The NSTS can dock to an unmanned Space Station or be berthed at a manned Space

Station. If the Space Station is manned then there is audio contact between

the NSTS and Space Station operators. The NSTS crew also has visual contact

Io9
with the docking port during final approach. The Space Station operator

requests the NSTS to be placed in a free drift manual mode before the RMS

grapples the NSTS for berthing. If the Space Station is unmanned, then the

docking is controlled by the NSTS.

4.4.2.4.5 EVA. The operator monitors EVA using video support and audio

communications to MMU or EMU. An MPAC is configured to monitor and control

airlock activity. Automated sequences (with manual override) are used for

environmental conditioning of the airlock and control of airlock access

(opening, closing, latching). Manual overrides are provided for all these

automated functions. Monitoring and control of the MMU is performed

autonomously by the EVA operator and station operators. The RMS can be used

to position the EVA operator for Station and vehicle service operations. The

platform will be serviced by EVAs. The OMV can maneuver the COP platform

within the MMU/EVA range for serving. The platform itself may be maneuvered

within servicing range. POP EVA activities and capabilities are described in

3SC 07700.

4.4.2.4.6 GN&C Management. The avionics systems are highly automated and

are designed to require minimal attention by operators to continue proper

operation. The avionics systems include navigation, guidance, attitude

control, traffic control, tracking and time management. These systems are

self-managing and perform automatic reconfiguration to recover from failures.

Manual override is provided.

The operator interfaces with each of these systems by configuring an MPAC by

selection from system menus. The operator is aided with prompts. Systems

performance and status is displayed at the MPAC. Graphics is used as much as

possible to present data. When failed ORUs are replaced and demonstrated to

be operational by self-test, the operator uses the MPAC to inform the avionics

system of this restoration. The avionics system then automatically

reconfigures the redundancy management level.

The operator has the capability to override or inhibit automated functions

using the MPAC.

110
Manyavionics systems are automatic with minimal operator interaction. The

operator interacts with mission planning to coordinate reboost. Momentum

managementis automated. The nominal SpaceStation attitude is an earth

reference local vertical. The operator can select and effect various attitude

orientations from the nominal. Anyattitude maneuvering is performed

automatically after the attitude reference is established.

The navigation functions of attitude and state vector determination are

performed automatically. This includes filtering, sensor source selection and

source editing. The operator has override capability. The operator interacts

with traffic control to coordinate OMVactivities required to reposition

free-flyers in the constellation. The operator also managescollision

avoidance option selection. Time and frequency managementis automated using

GPSsignals.

4.4.2.4.7 Non-GN&C Core System Management. The operator manages the core

facility subsystems using automated sequences supported by the MPAC. The core

facility subsystems include: power, thermal control, structures and

mechanisms support, ECLSS, communications, and external interface management.

All core facilities operate automatically with minimal operator attention.

The operator monitors and controls the core facilities subsystem in a similar

fashion to the avionics systems. The main operator interactions are to

monitor status and performance and to restore, redundancy following replacement

of failed ORUs.

The operator interacts with the communication subsystem to establish voice and

video contact internal to the Space Station and with external vehicles. The

operator also configures the communications subsystem to establish voice and

video contact with the MMU for EVA.

4.4.2.4.8 Logistics. The primary onboard operator interface with the

logistics system will be to update the status of inventory items not monitored

automatically. These data are input to the integrated logistics function for

resupply and inventory management, using methods similar or the same as

commercial inventory managers and resupply. While some spare parts and

111
supplies will be monitored automatically, most will require the onboard

operator involvement in entering identification of failed parts and spares and

supplied used.

The ground operator may have a much wider involvement, in that some aspects of

inventory control and transportation may be cost effective as manual or

interactive operations.

4.4.2.4.9 Unmanned Operations. The Space Station is intended to be a manned

operation after initial build-up, except in unforeseen circumstances that may

require removal of the crew. In such a case, the vehicle will be made

quiescent, with only safety critical core and/or payloads operating. There

will, of course, be no onboard operator. The ground operators will assume

responsibility for all operations during unmanned phases. Nominally, the

operator should need no special functions beyond his normal monitoring

functions, since the onboard subsystems are automated and operate

autonomously. In the event of a failure or the need to activate or deactivate

a subsystem, the ground operator will use the normal telecommunications to

perform the needed actions to monitor and control the onboard systems.

4.4.2.4.10 Safe Haven/Contingency. This operator task involves those

functions of the data system needed to operate the safe haven in contingency

conditions, such as loss of pressurization or damage to a module. The basic

assumption is that there will be the need for an orderly shutdown of

non-critical core and payload functions, and for a more frequent monitoring of

remaining levels of resources, "such as food, water, and other supplies.

The safe haven/contingency operator tasks include the following:

.

2.

3.

4.

5.

Monitoring supply levels in the safe haven.

Safing or orderly shutdown of non-essential subsystems and payloads.

Correction of the malfunction, if possible.

Resumption of normal operations after correction.

Docking and rescue from the safe haven, if appropriate.

112
These operator tasks make use of several functions. The generic Function oF

device management, necessary for safing and orderly shutdown, is exercised

from the workstations in the safe haven by the onboard operator, or from the

telecommunication link by the ground operator.

At any time, the ground operators can take over onboard operator's systems

management tasks, if necessary, during contingencies.

4.4.2.4.11 Facilities Management. This core operator perspective covers

several viewpoints:

1. A physical location and means to accomplish an operator task.

2. A location to status all high level aspects of a facility.

3. A location to access detailed data from distributed facility sources.

4. A location to command and control distributed facility functions.

. A location for coordination of separate operational requirements into

an integrated operational plan.

These five tasks can be grouped in two basic sets. The first set is task 1 by

itself. The second set is the rest of tasks 2 to 5. Task l is the view that

facility management is the means to do the job. The second set is a view for

the operator whose job is basically to either directly support the operators

under task 1 or manage/control the specific facility so that the operators

under task l are successful. The "facilities" in this report are:

- Space Station Flight Facility

- Space Station Control Center (SSCC)

- Regional Data Center (RDC)

Data Handling Center (DHC)

Development Facilities (includes SSE).

113
The subfunctions under "Manage SSDS Facilities", describe the activities

associated with these five facilities. All of these facilities are used by

both core and customer operators. This section provides a core operator

viewpoint.

Table 4-7 provides a perspective of facilities management for each individual

operator task in 4.4.2.4. This table is a task l viewpoint of what each

facility provides as a means to accomplish each operator job.

Tasks 2 through 5 are partially described in the table. However, these tasks

are much more detailed at each facility level. They cover the day-to-day and

long term management of each facility.

The flight facility is managed by both ground and onboard operators when it is

manned. Onboard, the generic device management and operate core systems

function, are used to achieve detailed reviews of system performance,

individual device performance, and subsystem performance and status. Most of

these tasks will be automated in the mature operations phase. More hands-on

monitoring and control will be needed prior to this time. Global management

of all onboard systems and necessary customer systems management (basic

operations and safety information) will be achieved by interfacing with the

"Monitor and Status System" function set. The SSCC provides basic onboard

operator support and will manage separately, specific onboard elements. The

ground also provides basic "second source" data and commands for element

failures and contingency needs. For extreme contingencies, the ground

operators at the SSCC, may take over most of the Space System system

management. For normal operations prior to the "mature operations phase", the

ground will receive more telemetry to monitor and control the planned

operations. Much less telemetry will be needed for the mature operations

because of increased onboard automation onboard reports if system status and

operation will be prepared and downlinked. In addition, the capability to

increase the detailed view of any onboard system through increased telemetry

will be available and easily invoked by ground operators. The unmanned

operation by SSCC operators may require less telemetry for habitable systems,

but again, for special needs the ability to acquire any system and control

that system will be easily implemented.

114
The SSCC operators must also manage SSCC ground operations and also provide

global interfacility coordination and planning. These detailed operations are

not detailed herein. Tasks l through 5 and the "views" in Table 4-B provide

some insight. In general, the parallels between the flight facility

management and the SSCC management are very strong. Both must manage: (1)

distributed functions in physically separated systems, and (2) personnel

assignments and coordination in widely separated locations.

The Roe and DHC management needs are indicated by their functions and in Table

4-7. The management needs of these facilities again parallel the SSCC general

needs. Table _7. 0peratorFac_ Pe_pective

Facility applicability

Regional Data

Space Station data handling

Operator Space control center center center Development

task Station (SSCC) (RDC) (DHC) facility

H/W

maintenance

s/w

development

and

maintenance

OMV, OTV, COP

free-flyer

control

Docking/

berthing

EVA

Avionics

management

• Hands-on • Performance Same as Same as • H/W sire

• Performance • Inventory SSCC SSCC • System test

• Inventory • Diagnostic for RI)C for RI)C (H/W, S/W)

• Self test • Schematics functions functions • Trouble analysis

• Replace • Expert system • Training

• Short term trend • Long term trend

• Contractors

• Display gen. • Test scripts Same as Same as SDE for all

• Develop some (test lang) SSCC SSCC application

test scripts • S/W dev for RDC for DHC S/W dev

(test lang) • Display gen functions functions

• No source language

S/W dev

• Hands-on • Outside N/A Vehicle data • Simulation

• S.S. control zone • S.S. control zone TLM handling • Secoridary

• OMV control • OTV control training

• OTV control • Coordination

• COP control (COP, OTV, OMV)

• S.S. RMS • SSST training

• Hands-on • Monitor N/A 'Vehicle data • Simulation

• All vehicles • Support TLM handling • Secondary

• Monitor/control • SSST training training

• S.S. RMS

• Cooperative

NSTS docking

• Hands-on • Monitor

• Monitor • Support

• S.S./Vehicle • SSST training

servicing

•N/A TLM handling N/A

• Hands-on • Monitor/Perform.

• Monitor • SSST training

• Control • Control support

• Diagnostics

• Expert system

N/A TLM handling • Simulation

• Secondary

training

• S/W dev

Non-avionics , Same as above Same as above N/A Same as above Same as above

core system

Logistics • Sparing • Inventory N/A N/A N/A

• Logistics module • Center logistics

• S.S. support

115
Table 4-7. Operator Facility Perspective (Continued)

Operator

task

Unmanned

operations

Safe-haven

Training and

simulation

Planning and

scheduling

Onboard

mission

support

Customer

coordination

Facility management

Space

Station

Regional Data

Space Station data handling

conUol center center center

(SSCC) (RDC) (DHC)

N/A • Management of all

core systems

• Reduced SSCC ops

N/A Reduced TLM

• Occupy area

• Reduced ops

• Contingency train.

• Contingency flight

data file

• Contingency support N/A • Normal TLM

• More onboard ops • Special TLM

mgmt needs

• Station specialist • SSST training • RDC training • DHC training

• Mission specialist • SSCC ops • RDC simulation • DHC simulation

• Health and habitat • Global mgmt

• Infrequent events • Contingency

• Contingency

• Near term updates • Near term coord • Plan • Plan

• Long term access • Long term dev. • RDC train • DHC train

coordination • Intercenter and sire and sire

• Flight data file coordination

access • Flight data file

• Contingency mgmt

• Contingency

Development

facility

Continue normal

functions

• Contingency

support

• Continue normal

functions

• Normal ops

• All operators

• Contingency

• Sim support

• Normal ops

• Contingency ops

• Prime support • Normal ops • POCC role • Normal ops • Normal ops

to customers • Customer support • Customer con- • Special • Sire support

• Station specialist • Global regret trol options customer needs • SW dev (optional)

backup • Customer/mission

• Multi-tasked specialist

among customers coordination

N/A • Normal ops • POCC • Normal ops • Normal ops

(ground) • Customer/mission • Customer con- • Customer/ • SW dev

specialist trol options specialist needs coordination

coordination • Customer/mission coordination • Sim support

• Global mgmt specialist

coordination

4.4.2.4.12 Training and Simulation. This section covers the training and

simulation needs of C0P operators in the Space Station and ground operators

for the POP and COP. It does not cover those same need_ at the Data Handling

Center (DHC) and at the Regional Oata Center (ROC). The discussions do cover

the needs of the Space Statto_ Control Center (SSCC), the SSE, the customer

facilities and the flight facilities. Training is defined as all the

information and interactions necessary for an individual to perform a task.

This can include "built-in simulations" that are envoked by the operator

interactions. Other simulations are controlled by operators that are

examining detailed data to determine system element correctness or

performance. These latter simulations are typically performed by software

116
development and system testing personnel and are not considered operator

training herein. Lesser training fidelity is required for the Space Station

than in past progcams because of increased system automation.

Figure 4-30 provides a view that training and simulation maximizes SSP

operational capabilities.

Training of flight operators is achieved by interaction with onboard and

ground facilities. The ground training elements of the SSCC are:

- Space Station Systems Trainer (SSST)

- Proximity and manipulator operations trainer

- One-g trainer

- Flight environment trainer

- Training terminals.

Operator training is achieved through "part-task" training and "full-task'

training. The part-task training is focused on smaller tasks. Full-tasking

training joins part-task elements into a higher-level of fidelity necessary

for integrated training.

' I _ MPAC fMi.,o. "_, _I On.O_, _ _11I;_1 . _ -_

_Specialist _'_ Training r_ __ __7 __

.

I

I I NASA Training

I II I Facilities

Customer f _,aaion___.JTr,,.oliL._f _round_'___.

_,SpeclaliatTI Facilities __r_Oparators F Ground

• SIM Req |

• Models

(SSCC) Flight

,C ,.

. Models • SIM

Data

• S/W • Models

7 • SIM Data

t * S/W

Software "--_

Support

Environment • Sire

Req

k._Station _'_

peclalistJ

1 f Ground

_ i \o,,era,o,J

POCCS _Cuatomerl_

t F-m,sa,on_

_.ci...tj

Figure 4-30. Training and Simulation Maximizes Use of Program Operational Capabilities

117
The SSST provides both part-task and full-time task training. This includes

system management (avionics and non-avionics), system management ground

support, activity planning, logistics, communications usage and

contingencies. It provides a representation of the operating environment of

the manned modules. The SSST will be networked to the other ground training

elements as needed.

The proximity and manipulator operation trainer provides part-task operator

training to develop hand and eye coordination and precise control. The

manipulator is used for berthing/docking, grappling structures, and payload

deployment. This high-fidelity training contains controls, displays, visual

cues and dynamics. The trainer can be interfaced with the SSST and NSTS crew

simulator as necessary. The trainer also contains a high-fidelity OMV

simulator of its maneuver capabilities and it manipulator operation.

The one-g trainer will be kept in the same configuration as the Space Station

and provides training for habitability, maintenance/service and EVA

preparation.

The flight environment trainers provide a neutral buoyancy trainer, hardware

mockups and tools for activities in a weightless environment.

Training terminals will be available (MPACs) that are the same as those in the

SSST that provide tutorial walk through training. These relieve the training

load on the SSST.

Preflight training for Mission Specialists and customers is a ground

reponsibility. These ground operators are tasked with the training of these

two sets of people to operate in the Space Station environment. POCC training

is provided at the POCCs. The customer facilities are used extensively for

onboard (Mission Specialists) and ground operator/customer payload training.

Training on the Space Station will essentially take place on the job.

Experienced crew members will train new crew members. The Space Station,

obviously, contains the highest training fidelity. The operators will have

interfaces to onboard data bases that contain information on schedules,

118
activity plans, maintenance and operations. All these data are available via

an MPAC. Tutorial information on basic and detailed operations for onboard

training and refresher training needs are available.

The above are the prime training viewpoints. The Software Support Environment

(SSE) is considered a secondary training facility and a prime specific

simulation facility. The SSE training aspect may provide more fidelity in

some cases than the ground facilities. These will be used as needed.

The SSE presents to the operator not only a software development facility but

a facility to perform simulations and secondary training. The operator

controls simulations and training sessions from a standard MPAC, the same MPAC

used for software development and for the onboard SSDS interface. The SSE

simulation capability has several major modes: flight simulation mode and

flight computer mode. These modes are selectable by the operator. The flight

computer mode is supported by hardware elements. These hardware elements are

used to support the prototype concept. Customer supplied hardware can also be

integrated into the simulation in the flight computer mode. The SSE always

contains a full-up flight computer mode (network, processors, interface

devices, secondary memory, etc.). The SSE has a network connection to the

NASA Advanced Development DMS test bed for exchange of application software

and models.

The use of the SSE for simulation and training is supported by documentation

in the form of user guides. These user guides are available on the MPAC or in

manuals. Remote ground and onboard workstations (MPACs) are supported. The

user guides contain various MPAC capabilities for selecting options in the

simulation or training session. The operator is aided with "help" displays,

prompts and illustrative examples. The test scripts developed for a session

may be saved and used in subsequent sessions. The operator language for test

script development contains as a subset a user interface language. The user

interface language is used during operations to construct test sequences and

can be used for the same purpose during simulation or training.

The SSE will support real-time training sessions and training in either the

flight simulation or flight computer mode. Simulation runs will normally be

119
submitted by the operator for batch execution. These runs can be submitted

remotely. Interactive simulation can be performed by the operator by

uploading the simulation configuration to their remote workstation. Remote

site training is supported but not in real time. Real-time remote site

training can be accomplished by uploading the simulation configuration to the

remote workstation or by the remote workstation interacting with the SSE.

Simulation hardware models are selectable by the SSE operator. Model

selections are made on panels presented on the MPAC. The operator can control

the insertion of hardware model errors and model failures. The simulation

defaults to idealized models in case the operator does not select an option on

the panel. Customer supplied hardware models are supported.

SSE software versions (developed or operational) are selected in much the same

manner as the selection of hardware models.

SSE simulation results are presented to the operator in the form of plots

reports, etc. The operator developed test script controls the post processing

of results. The results can be delivered to the operator on the MPAC

display. The operator can select formats for hardcopy or display presentation.

The SSE maintains parameter simulation files which contain software names and

labels. Software parameters can be sampled at various locations during

execution. The operator specified these locations and parameters in the test

scripts.

SSE aids are provided to isolate on-line errors (i.e., program exceptions).

Errors are logged and traces are provided to aid the operator. Various

monitoring devices are available to allow monitoring of the onboard Operating

System (OS) and onboard Network Operating System (NOS) execution and

performance during software development and testing.

System tests are performed in the SSE by the operators. The flight computer

mode, highest fidelity mode of hardware, will be used for system test. A high

fidelity simulation occurs at this time and all the major hardware components

are available. Some hardware interfaces are still simulated. The simulation

fidelity level will be specified by the operators.

120
The operator training task at any facility involves those functions of the

data system needed to train the onboard and ground personnel to operate: the

Space Station, the constellation elements, the ground facilities, and

payloads. There are three primary personnel groups:

I .

2.

3.

Onboard operators

Ground facility operators

Customer/operators.

Onboard and ground facility operators will require periodic training of

off-nominal conditions that are not encountered in the day-to-day operation of

the Space Station, and in operation of payloads that will not be directly

controlled and monitored by the payload's owners. These conditions would

typically be emergency procedures that require more rapid response than is

available from textual reference to fault recovery procedures, or infrequent

procedures.

4.4.2.4.13 Planning and Scheduling. These operator tasks are among the most

important and difficult to achieve in order to produce effective coordination

of requirements and resources. Without well understood objectives and timely

plans to achieve them, an inordinate amount of operator time will be wasted in

support of system operation and customer objectives.

Planning and scheduling applies, in some degree to all operator tasks. A

starting point is to begin with customer requirements and basic core system

requirements. A view of the overall process is illustrated in Figure 4-31.

The basic core and customer requirement inputs and established SSP program

objectives and priorities are utilized by the SSP community as a whole to

develop operational plans. For clear objectives, a programmatic plan is

established which becomes the skeleton for specific mission plans. From the

mission plans, long-term plans are developed which are utilized by operators

to develop near term plans which are then used to control the operations of

the various SSPEs. The status of the SSPEs provide feedback in this process

that can cause changes in the various multilevel plans to accommodate the real

environment operations. The entire set of information or plans is called the

Flight Data File.

121
Customer

Requirements

Core

Requirements

Inputs

SSP

Priorities

Disposition

Inputs

Planning

and

Scheduling

Disposition

Status

SSPEs

Space

Station

Constellation

Elements

Ground.

Support

Centers

Comm

Links

POCCs

PILs

Programatic Plan h

Mission Plan

Long-Term h

Plan

Near-Term Plan ]

Figure 4-31. Planning and Scheduling Provides Coordination of Requirements and Resources

The above process generally describes planning and scheduling for onboard and

ground operators performing station core tasks and operators supporting

customer payloads. The view presented herein is that the planning and

scheduling process for onboard and ground operator directly performing core

and customer tasks and those operators supporting these operations will be

merged together into a uniform plan.

Generally, all plans are electronically available to any operator. Special

security needs are accommodated. The process begins with premission (i.e.,

preoperations) activities that must accommodate basic SSP goals and

requirements. Mission manifests are utilized to determine the desired habitat

and customer needs and resources. The premission plan baselines ground and

onboard personnel support levels and skills required. Ground resources are

established to provide basic support from the (1) NSTS, (2) SSCC, (3) DHC, (4)

RDC. Onboard system resource needs are similarly established: (1) avionics

services, (2) subsystems, (3) OMV, OTV, and EVA, and (4) data management

services and storage. Next, an integrated communications and network

utilization baseline is established. Iteration of these early

premission/preoperations requirements evolve into the accepted mission plan.

122
The next step is the development of a long-term plan. This is defined by

ground operators and customers for on-orbit operators to follow. Plans are

blocked out by operator and task for approximately a two week period. This

integrated plan coordinates all known ground and flight systems status (core

and payload)_ This plan is uplinked to the on-orbit operators. It becomes

the skeleton of the near-term crew activity plan (CAP) developed by the

on-orbit operators.

The on-orbit operators use the skeleton long-term CAP, onboard data and

status, and communications with ground operators and customers to create the

near-term CAP. This covers a one-to-two day period. The on-orbit operator

can best develop the detailed plan and schedule based on their station

environment knowledge and crew skills and status.

4.4.2.4.14 On-orbit Mission Support. The on-orbit operator task functions

are:

I. Coordinate operations with ground customer.

2. Operate necessary customer payload/experimentequipment.

. Maintain/service customer equipment (reference 4.4.2.4.1, Hardware

Maintenance, for viewpoint).

4. Perform EVAs as required.

5. Execute training for specific customer related tasks.

Both the Mission Specialists and Station Specialists share their scheduled

work time supporting, as necessary, all the Space Station and COP payloads and

experiments. They are, in general, not experts in all the payloads. The

customers or principal investigators are, in general, on the ground. This

does not preclude a customer or expert operator from becoming an on-orbit crew

member for a long duration need.

123
The preceeding includes autonomous operation of a payload by the customer with

only occasional support by on-orbit operators.

The customer coordination needs may be very extensive. Voice and video are

utilized between the customer and onboard operators. Common data base access

for both is the prime means for recording/updating experiment operations

procedures. These data are contained in the Flight Data File. Customers are

expected to provide their equivalent of a Flight Data File to Space Station

specifications.

4.4.2.4.15 Customer Coordination. This ground operator task directly

supports the customer by providing the following:

l . Point of contact for customer to assist them in general SSP policy

and procedures.

. Specifically includes:

- Front-end negotiation for customer experiment integration into

planned profiles

- Training of customer and a Mission Specialist will address Space

Station environment and procedures, and standard customer

services -- voice, video, data processing, and problem reporting.

- Handling and transportation of payload.

- Arrange/contract data links and processing to acquire data and

move it to customer.

- Training of customer and Mission Specialist(s) to acquire data.

3. Negotiation of NASA provided services beyond the standard services.

These ground customer specialists share their time among several customers.

The time spent is proportional to prenegotiated services. Telemetry service

and data rates will be based on the amount of data captured, stored and

delivered.

124
4.4.3 Space Station Data System Build-Up Scenario

The current NASA plans call for an operational Space Station during the early

1990's. One of the challenging aspects associated with this goal, is that of

"Station build-up", defined as the set of activities that transform the fully

developed Space Station elements into the deployed, operational, IOC system.

This scenario is intended to provide some insight into the Space Station

Program (SSP) build up activities while focusing on its Data System (SSDS)

operations. The objective is not to develop a comprehensive description of

the build-up procedure but to insure that Station requirements imposed on the

SSDS by the Station configuration at each step of the build-up can be

satisfied by the SSDS capabilities provided at the corresponding step. These

requirements must also include those uniquely associated with build-up.

There is a tendency to think of "build-up" only in terms of the space segment

because of the associated unique accQssiblllty/environmental issues; however,

ground segment support is such an integral part of the over-all operation

that, in the general case, the ground elements must also be addressed.

Conceptually, the ground segment will be initially emplaced and activated in

order to provide maximum support for the space segment preparations, and

activation. The actual station hardware must itself be segmented into launch

packages for NSTS transport to the defined low earth orbit and integrated in

an orderly sequence into the defined IOC con£iguration. Specifically, then,

the build-up activities will include:

l) installation/activation of the program ground segments,

2) space segment launch preparations and launch operations

3) launch package on orbit deployment and assembly to existing structure

4) activation and checkout of added Station equipment and capabilities

5) full verification of SSDS operation and performance at final assembly

6) full crew manning of Station

7) installation/deployment and activation (as required) of

experiments/payloads

125
Clearly, the build-up planning effort must generate a comprehensive task

sequence with sufficient definition early in the acquisition phase to

effectively interface with the design/development activities.

A distributed networking approach is anticipated for the Station SSDS since

• the Station itself has physically distributed modules and sub-systems

• processing loads may be too large to be efficiently supported by a

centralized configuration

• network technologies with adedquate data rates to support SSP

applications are currently being defined/developed and will be

available for IOC

• this approach provides the modularity that supports

a) commonality/standardization

b) technology insertion

and, c) orderly growth

Technology/design details of the SSQS have been minimized in an attempt to

maintain generic concepts; however it has been necessary to generate a

ground/space allocation of SSDS functions and to provide a distribution of

sub-system equipment across the Station structure and modules to support those

functions. The intent of these assumptions and allocations is only to provide

a target final configuration to be achieved within the scenario, not to

espouse any particular design features.

With respect to the space segment Build-up, the distributed approach also

supports the derived requirement to maintain a stable, self-powered, ground

controllable configuration at each stage of the operation as subsequently

discussed.

An initial task of the scenario development was an assessment, provided in

Table 4-8, of SSDS functional hequirements at each stage of the build-up sequence. This assessment led to a distribution of SSDS functions across the Station, i.e., launch packages as shown in Figure 4-32 and an insight into the

SSDS equipment requirements within each package. These requirements are

integrated into Table 4-9 which summarizes the over-all scenario in terms of

126
127
HM1

Workstations

| Med and

DMS _ Health Maint

| Subsystem Mgmt

L cs,w

Power

Comm and Tracking

ECLSS -I TCS

Sa ' /ven /

HM2 LL

DMS

• Workstations

Entertain and Train

EVA Support

Core Data Store

Subsystem Mgmt

Facil Mgmt

Seq Ops

Sched Develop.

Cmd Mgmt

Core Data Mgmt

C&W

Power

Comm and Tracking

ECLSS I TCS

Operations Center I Traffi(;Nav and

Safe Haven J

Figure 4.32. Preliminary Space Station Functional Distribution

ACA_

I TC&S DMS* I

Keel Struct Comm* I

I.cB TCSI

LM

I DMS Comm

ECLSS TCS

Safe Haven,

Lab 1

f Workstations

|Cust Data Mgmt

/ OustOps

DMS_ Support

/ Ancillary Data

/ Mgmt

_.C&W

Power

Comm and Tracking

SafeECLSS Haven _..

Lab 2 U

Workstations

JCust Data Mgmt

DMS / Data Buffers

Lc&w

Power

Comm

SafeECLSS Haven

*Temporary Equipment/Functions

I) the sequence of launch packages, 2) derived Station operational

requirements (at each stage), 3) the SSDS functions to satisfy the Station

requirements, and finally, 4) the equipment added to perform the SSDS

functions.

The basic approach to the space segment build-up scenario is the deployment of

each launch package outfitted with its full IOC. A policy established for the

scenario was the activation of these added capabilities as soon as possible in

order to provide early exposure of problems and to maximize crew familiarity

with the Station operating characteristics. When a module is added to the

Station, for example, its equipment will be powered up in a predefined

sequence, excercised through its Built-In-Test (BIT) diagnostics, configured

with its appropriate software and brought on-line to allow NSTS and ground

crews to perform incremental system verification tests. Operational realities

cannot be pre-defined however it is anticipated that much of the Station

autonomy will be initially over-ridden by ground control; responsibilities

will migrate from ground to space as the Station develops and ground crew

confidence increases.

128
POOR QUALITY

N

&

¢g

>,,

E

=1

o

i,,.

¢l

¢¢

¢/)

i

0

3

dN_

_.

o

]i=

,_,-

o o o o

o o o o o o oo o o o _ o o o a o o o o o

ooooo

c_

A

oooooo oo o

! -E . oz

w_

!z=

_g

o o

i i

,- , ,.,; ,..; , I

I

129
A

¢_1

al Q. vEE

¢i) oo_

i.

al

¢ni

III

Io

o

z

oo

_-_ z _

_

,N

_o

,N

w

o

i*i

_ ' ,

r_

_=

..2 c-_

_w
Platform and free flyer deployment/activation are not separately discussed in

this paper since build-up operations for these spacecraft is expected to

closely resemble those of the Space Station build-up operations. There will

be some interaction between these elements (during their build-up phase) and

the Space Station, however, these interactions should not differ from the

servicing and data support activities that are adequately documented

elsewhere. The ground elements for these platforms and free-flyers are part

of the SSDS ground segment and will not be separately addressed.

Also, the man tended Station option has not been specifically addressed since

it is concluded that this option would consist of build-up operations provided

in following scenario, however an interim configuration would be maintained

for the unmanned period, then upgraded to the manned configuration discussed

in the following sections.

The space segment build-up sequence provided in these discussions has been

adapted from the reference 1 NASA Reference Configuration. The scenario

presented here is an expansion of that NASA effort.

4.4.3.1 Data System Ground Segment

The SSOS ground segment will consist of those elements (functions) required to:

• monitor and control the SS, COP, POP, and free-flyers

• distribute uplinked data/commands and downlinked core and mission

telemetry

• capture, process, archive and distribute the core and mission telemetry

data

• develop software and hardware and provide system simulation and training

• manage (scheduling, config, control, etc.) the above.

These ground elements will include but not be limited to SS, COP, POP and free

flyer Control Centers, POCC's, Engineering Data Center, Data Handling Center,

Regional Data Centers, Development, Simulation & Training (DS&T) System, and

Data Distribution Network and Network Control, plus the appropriate interfaces

to the NASA Technical, Management and Information System (TMIS). The TMIS is

expected to support the ongoing configuration management, scheduling, and

readiness status functions required during the build-up.

131
Clearly, the build-up phase represents a period of uncertainty since it may

represent the first 'all systems' integration effort. The ground elements

associated with 'core' operations must, therefore, be in place with sufficient

operational maturity to support monitoring and control of the first space

segment elements. These capabilities must include effective sub-system

monitoring and commanding, plus the ability to simulate system

phenomena/anomalies, diagnose the cause(s), and design and validate solutions

prior to effecting appropriate changes on the flight system. The Data

Handling Center, and other Network and Data Distribution elements must also be

ready to support the initial data format and rate requirements.

In reviewing the operations of ground system emplacement and activation, no

specific technical or operational issues have been identified that necessitate

particular strategies or sequencing except, as indicated earlier, the need to

have an operational system of sufficient capability to support the deployment,

assembly and activation of the space segment. The high IOC data rate

capabilities associated with capture, distribution, archiving etc. need not

actually be operational until late in the Station build up sequence; however,

any options excercised in this area must not impact the over-all build-up

schedule. The ground segment elements will incorporate the

standardization/commonality policies of the over-all program (SSP) such that

individually verified equipment can be 'installed and activated' within each

respective facility with minimal problems. The degree of pre-launch

ground/space segment integration will depend on the particular strategies

selected, however the DS&T System, utilized heavily during DDT&E of the ground

and space elements, will continue to support the build-up and activation

operations in any case. TDRS/distributlon links will be simulated at least

initially and full end-to-end data checks may be deferred until the Space

Segment is in place.

The ground SSDS/TMIS combinatlon will support the planning, scheduling,

configuration management, and mission readiness, including pre-launch

integration and checkout. The NASA/Contractor team will update the associated

status data bases such that comprehensive, real-tlme visibility of build-up

operations will be available via this 'paperless' system to perform effective

program plannlng/scheduling.

132
4.4.3.2 Data System Space Seqment

One of the goals of the on orbit space segment build-up task is to maintain a

stable, self-powered and ground controllable configuration at each step of the

operation. This goal, coupled with the constraints of NSTS payload limits,

has led to the development of the plan presented in the NASA Reference [1] in

which a specific sequence of structural and module packages are boosted into

near earth orbit for incremental assembly into the IOC configuration. The

plan requirements drive the Station configuration and design in order to

develop packages compatible with the NSTS cargo envelope, weight, c.g., etc.,

and allow subsequent deployment and assembly within the projected on-orbit

resources.

Preliminary NASA planning accomplishes the butld-up with 7 such packages,

shown in Figure 4-33; a schedule of 6 - 12 months is anticipated for the

effort, driven primarily by the launch preparations (NSTS refurbishment, launch

package integration, and pre-launch checkout) and other impacting flight

commitments. As indicated earlter, it is the intent of this scenario to

tnsure that this build-up sequence can provide, at the conclusion of each

mission, an appropriate complement of SSDS hardware and software to meet the

projected interim requirements of the Station.

Ground operations between the tntttal butld-up missions wtll focus on

monitoring, controlling, and correcting the developing station, becoming

thoroughly famtltar with the station operations and operating characteristics

at each stage of development. It Is possible that perturbations to this

scenario may result from equipment failures, Incompatibilities or deficiencies

detected during the butld-up however, tn the work case the resultant

activities would merely be re-iterations (launch package removal and

replacement) of the activities and operations presented. Such perturbations

are therefore not specifically addressed.

4.4.3.3 Build-Up Preparations

In the anticipated sequence of build-up preparation, the flight segments of

the SSDS, will first be integrated and verified within their parent elements

of the Station. These elements will then be assembled for Station system

133
Transverse

Boom

Extension

(Flight 5)

Upper

Keel Boom

(Flight 4)

Transverse

Boom

Extension

(Flight 5)

Lower Keel Structure

(Flight 2)

(Flight 1)

Boom

Lab 2

(Fli

LM

(Flight 5)

Lab 1

(Flight 6)

Keel Extension Structure

(Flight 2)

Figure 4-33. Space Station Build Up Packages

HM1/AL1/AL2 (Flight 3)

HM2

Flight 4)

134
integration and verification prior to launch according to the selected

integration strategy. Finally, system elements will be assembled into

assigned launch packages for Orbiter integration, pre-launch checkout, and

launch. Orbiter integration will require special preparation and attachment

of structural members however, the SSDS equipment located within module or

structural housings should not be impacted.

During pre-launch operations some SSDS checkout is anticipated with the

packages in the Orbiter bay. Several options are available to accommodate

this checkout; depending on the required depth. This scenario, however, has

shown a need for an interface between the Orbiter and the SSDS to allow the

orbiter crew to perform on orbit monitor and control functions on the Station

sub-systems. DMS common equipment, (MPAC, BIU, and processors), may therefore

be installed within the Orbiter to support this function; the network

Interface(s) will most likely be provided through the docking port. This

interface could be harnessed to the launch package within the cargo bay to

perform at least confidence level diagnostics. If required, more

comprehensive system level checkout could be performed prior to Orbiter

integration using a combination of specific GSE at the launch site plus remote

system simulation support provided by the Software Support Facility. It is

anticipated, however, that some checkout of the launch package will be

required prior to its removal from the Orbiter bay to establish that no

significant damage has occurred. Power will be provided from an auxillary on

the Orbiter for this operation and the SSDS interface will be utilized

(through the special harnessing above) to perform this checkout.

For the actual launch and orbital boost, it is assumed that there is no

continuous power requirement for any of the station equipment, sensors, or

experiments, and each package will be 'cold started' on orbit.

4.4.3.4 Build-Up Operations

The following discussions provide general descriptions and features of each

launch package, an overview of each mission wlth the identified issues, and a

discussion of the SSDS operations and issues.

135
For all orbital construction tasks, the Orbiter will be rigidly attached to

the developing Station in order to reduce dynamics complexities and minimize

collision risk. The Shuttle Remote Manipulator System (SRMS) grappling

capability will be used to maneuver the Orbiter and/or Station into coupling

position with temporary or permanent docking ports utilizing engagement

mechanisms and some aids for range, range rate and attitude will be utilized.

For the remainder of the discussions, these attachment operations will merely

be referred to as berthing. Impact dynamics during berthing, SRMS/MRMS

Ioadlng/unloading operations, and resultant attitude control requirements are

acknowledged to be significant issues but will be appropriately left to others

for comprehensive analysis and discussion.

Communications will play a major role in developing the Station configuration

and a number of associated issues must be resolved. Of particular concern are

the Statlon/Orbiter communication interfaces. It is not intended to provide

solutions or even options to such issues within this document. Instead,

communications functions will only be generically addressed with the

assumption that appropriate conversions and/or compatible transponders can be

utilized.

4.4.3.4.1 Fliqht #1

4.4.3.4.1.I Package Definition

The initial build-up mission will deply the Station Transverse Boom shown as a

folded launch package in Figure 4-34 and unfolded in Figure 4-33. The

preliminary configuration provided in reference If], locates hardware for the

Electrical Power System (EPS), Thermal Control (TCS), and Guidance, Navigation

and Control (GN&C) sub-systems across the Boom a shown in the figure. The g

foot cube at the center of the structure, identified as the Attitude Control

Assembly (ACA) compartment will house the Inertial Sensor Assemblies (ISA)'s,

CMG's of the GN&C sub-system, and regulators/dlstribution equipment of the

electrical power system (EPS); solar arrays and regenerative fuel cells will

136
Radiator Panels

(Stowed) Antennas (Stowed)

• /

/ / Radiator Heat

I '?_L, i

1

/

/

ACS/COM Section

Deployable Structure

Power System Section

(37.5 kW)

Deployment Arrays (37.5 kW)

Rails Typ (Partial System)

Figure 4-34. Transverse Boom Launch Packagebe located further out on the boom structure as may be the Magnetic Torquers

of the GN&C.

Addition of communications and some SSOS capabilities, will allow the Boom to

be deployed as the initial stable element around which the Space Station can

be assembled.

The SSDS capability will require a set (or sets) of processors, memories, mass

storage devices, etc. but is expected to be temporary in that its functions

will be transferred when the permanent equipment is integrated into the

Station. However the equipment may remain in place as a spares resource and

also for contingency purposes. Other options include use of a 'throw away'

unit or permanently locating some function in the ACA. Networks/busses will

be provided to permanently interface this equipment to the sub-systems NIU's

and to the DMS of the final IOC configuration.

137
The communications equipment must include both a NSTS and TDRS S-Band

capability. One option for the TDRS link would be to provide the full IOC

capability within the boom structure then relocate the antennas, amplifiers,

and recievers etc. to the upper boom when installed. The alternative,

proposed in reference Ill, utilizes low gain S-Band equipment for all

communications on the initial configurations. This latter approach is

basically compatible with the requirements and has therefore been adopted.

GPS receivers will be included in the preliminary configuration to provide

position, velocity and time reference to the GN&C sub-system.

Thermal control equipment, radiator panels, etc., provided on the Boom for

Power Sub-system equipment cooling will also accommodate the added DMS and

Communications equipment.

The initial SSOS will have an autonomous capacity to perform the Station data

and command management functions plus. subsystem supervision and redundancy

management. Consistent with IOC design requirements, the ground crew will

have the ability to over-ride all operations.

4.4.3.4.1.2 Mission Overview

The first mission will remove the Boom structure from the Orbiter cargo bay

using the Orbiter SRMS, and fully 'construct'/deploy the boom with its first

set of solar arrays. Typical of most build-up operations, this activity will

be EVA intensive. Communication between EVA and NSTS crew will be relayed to

ground as usual.

For the start-up/checkout operation, the Orbiter will be attached to the Boom

at its temporary docking port utilizing the Orbiter attitude control system to

sun orient the boom solar panels for the activation of the Electrical Power

Generation System. An alternate possibility, however, Is to allow the Fuel

Cell system to provide the start up power and allow the station to

autonomously orient the solar arrays when the DMS and GN&C subsystems are

operational. The Power Management and Distribution equipment will be

activated and configured followed in sequence by the DMS, Comm, and GN&C

subsystems.

138
The last major operation will be to checkout the Mobile Remote Manipulator

System (MRMS). It will be positioned at its designated servicing station

which will supply power for manipulator operations and recharge its batteries

for mobile operations. The MRMS will be excercised both from its local

control panel and via its S-Band RF link.

4.4.3.4.1.3 SSDS Operations

The SSDS equipment will be powered and software configured via an automatic

ROM bootstrap/memory load technique typical of all the equipment, power up

BIT/diagnostlcs will also be performed. The SSDS will perform its 'manage

delivered data' function by accumulating the sub-system data, formating the

data packets with appropriate header/trailer data and issuing the resulting

data stream to the Comm system. This low rate data will not require any

substantial DMS or Comm buffering and will be compatible with the S-Band links

provided. The Comm system will begin transmitting the Station sub-system

'operation and health' (house keeping) data stream to the ground via the

Orbiter for evaluation. The SSDS g_ound system will perform functions of data

capture, data handling, and processing to support real time displays and trend

analyses for ground crew evaluatlon. The raw data will also be archived

within the Engineering Data Center for available access and additional

processing by ground personnel. As previously indicated, the Orbiter will

have access to the DMS via its onboard workstation (MPAC) interconnected

through the docking port. This access will allow any special sub-system

diagnostics or verification tests to be performed or any operating mode to be

established. The GN&C equipment (ISA's, CMG's, star-trackers, processors and

BIU, etc.) will be powered up and its associated processors (dedicated or

assigned) initialized and brought on line under DMS control. Some time

(perhaps hours) will be required for the GN&C equipment, i.e. CMG's to reach

operational status.

During this period, the GN&C will be placed in an 'attitude hold' mode to

disable all control command outputs, however the sub-system will begin its

initial attitude determination/update utilizing the sub-system star trackers,

then begin to navigate based on incoming GPS data. Ephemeris data will be

provided in secondary storage for DMS/GN&C to propagate orbit parameters and

139
begin control and pointing command generation. GN&C command and data products

will be interrogated/monitored by NSTS (via Orbiter MPAC) and ground crews

with updates/adjustments provided as required. When operation is judged

acceptable, command outputs will be selectively enabled and the GN&C will slew

and maintain the solar arrays to appropriate pointing angles.

At some point in the mission the Station/TDRSS S-Band link capability will be

exercised with the ground crew monitoring the Station and exercising the

repertoire of commands required to control the DMS and other subsystems. The

DMS will receive the upllnked commands and data provided by the Comm system,

perform validation and authentication checks, then issue the commands and data

to the appropriate subsystem.

The final SSDS capabilities will be that of subsystem monitoring and

configuration management. The 'operation and health' data of each subsystem

will be monitored and appropriate action taken depending on the fault

tolerance techniques employed. Typically, each subsystem processor will

reconfigure its own sensors and effectors as required, however, the initial

DMS may have the capability to reconfigure and initialize the sub-system

processors.

When NSTS and ground crews are satisfied with the station operation, the

attitude control operation will be verified by disabling the Orbiter control

system and allowing some low level of control by the Station. With normal

indications, the Orbiter will disengage to a safe distance and ground crews

will fully enable the attltude'control. Autonomous momentum management will

also be provided by the SSDS utilizing the magnetic torquers however this

function may be initially assumed by ground crews.

14o
4.4.3.4.2 Fliqht #2

4.4.3.4.2.1 Package Description

The second flight package will consist of the Keel structure plus lower

assembly support bays shown in Figure 4-33. IOC equipment on the structure

will include Reaction Control System (RCS) and Thermal Control Sub-system

(TCS) hardware.

4.4.3.4.2.2 Mission Overview

For this mission the Orbiter will berth at the port on the Transverse Boom;

the ground crew will command the GN&C into the 'attitude hold' mode as the

Orbiter approaches. When docked, the Orbiter will establish an optimum,

stable attitude to support the assembly operations.

The initial build-up operation willlcheckout and position the MRMS which will

be used in conjunction with the SRMS to remove the upper keel structure from

the Orbiter bay. When the main body of the keel is assembled to the boom, the

MRMS will be 'walked' down the keel to support construction of the lower keel

assemblies. Redundant service lines (DMS networks, TCS & RCS ducts and power

distribution cables) will be connected/attached to their respective

sub-systems. These service lines may be pre-integrated or may be carried

separately; in either case they will require.routlng and securing within the

previously packaged structure.

The RCS equipment (thruster nozzles, drivers, instrumentation, etc.) mounted

on the keel wlll be used for orbit adjustments, collision avoidance and for

back-up momentum management. The TCS equipment (fluid pressure vessels, flow

control devices system processor(s), instrumentation, etc.) will provide and

control heat exchange with the Station main thermal radiator panels to

maintain appropriate temperature sinks for the Station equipment.

141
Both systems will be activated, and checked out. Reserve propellant tanks

attached to the lower keel structure will support the RCS checkout.

Instrumentation packages within the Keel structure will monitor

vibration/flexure modes and structural misalignment. At the conclusion of the

mission the Orbiter will disengage. Ground personnel will establish a

favorable gravity gradient station orientation.

4.4.3.4.2.3 SSDS Operations

No additional SSDS functions are provided by thls mission however the existing

SSDS capabilities will support the routing of commands from the GN&C subsystem

to test fire the RCS jets under ground crew control. The structural

instrumentation will be treated as a set of isolated sensors. The resulting

data will be monitored by the appropriate 'caution & warning' function of the

SSDS and will be included within the downlinked engineering data.

4.4.3.4.3 Fliqht #3

4.4.3.4.3.1 Package Definition

The third mission will include the first habitation module, HMI, with the two

Station Airlocks ALl & AL2 shown in Figure 4-33. AL2 will be subsequently

removed and permanently attached to HM2. As indicated in Figure 4-33, HMI

contains DMS, Comm, ECLSS, TCS equipment plus crew facilities and "Safe Haven"

capability.

4.4.3.4.3.2 Mission Overview

The Orbiter will dock/berth to the temporary docking port at the starboard

keel extension. This port will include the DMS/C&T interface. For this and

subsequent missions, the Station attitude control system will remain

operational and the Orbiter ACS will be inhibited prior to berthing contact

and securing. The MRMS will be relocated to support SRMS removal of the

142
module and its attachment to the lower keel structure. Module utility lines

(electrical power, SSDS/C&T links, and TCS/ECLSS ducting) will then be

attached. Finally, ALl and AL2 will be attached to the module. Following

module attachment, the Orbiter will berth at the HMI docking port.

The module equipment will be activated and checked out as much as possible

prior to Orbiter departure. However, two issues must be addressed in order to

speculate on the immediate utility of the HMI capabilities. First, it is not

clear that the stand-alone module can initiate and maintain its 'shirt sleeve'

environment for effective use as a work/rest station. Secondly, it is not

clear whether the electrical/electronic equipment can be activated and checked

out within the unpressurized module due to thermal considerations.

This scenario will assume that the module ECLSS will not have the stand-alone

capability, therefore, the crew will remain suited for all flight #3 and #4

module activities. This will not only limit the utility of the module but

will delay the detailed module checkout of the man/machine interfaces until

flight #5. On the second issue, it will be assumed that the module electrical

equipment can be operated in the unpressurized environment with the available

Thermal Control equipment and cold plates in each module.

Suited crewmembers will enter the module via the docking port to configure and

perform a limited module checkout. Following module checkout, the crew will

establish a predefined module configuration, and depart with the Orbiter.

4.4.3.4.3.3 SSOS Operations

The HMI checkout effort will complete the normal power up and self test

operations then proceed with a communications verification, including

voice/video to the Orbiter and communication via TDRS to the ground. 'Safe

haven' direct to ground communications will be excercised at appropriate orbit

positions. The HM-I SSDS equipment will be initialized with its appropriate

memory load and brought "on-line n Appropriate operational diagnostics will

be performed with both local operation utilizing the MPAC and by the ground

crew.

143
The SSDS equipment in this module will provide crew support functions, i.e

medical, health maintenance, EVA support together with some general data

storage and buffer capability. The HM-I communications equipment signal

processors will support the K and S-Band communication with TDRS.

4.4.3.4.4 Fliqht #4

4.4.3.4.4.1 Package Definition

The fourth NSTS package, shown in Figure 4-33, will consist of the second

Habitation Module, HM2, plus the upper keel structure with its high

performance (IOC) TDRSS communication equipment.

4.4.3.4.4.2 Mission Overview

The mission will begin with the Orbiter berthing at HMI. The MRMS will remove

the HM2 module from the Orbiter bay in conjunction with the SRMS and position

it for attachment to the keel structure. These attachment operations differ

in that HM2 will also attach to HMI to form one half of the module "race

track". Airlock AL2 will be relocated from HMI to HM2 and the HM2 service

links will be connected. The upper keel and boom structure will be

transported via the MRMS under EVA control and assembled to the keel. The g

foot TDRS antennas, power amplifiers, low noise amplifiers (LNA)'s and

receivers will be located onto the upper keel structure to support the IOC

ground link capability.

Suited crewmembers will then enter HM2 and perform a checkout sequence similar

to that employed on HMl.

144
4.4.3.4.4.3 SSDS Operations

The DMS equipment within HM2 will include fixed and portable work stations

(MPAC's) plus the processors, BIU's and mass storage to provide the functions

of sub-system monitor and control, scheduling, operations sequencing, command

management, traffic control, Facility Management, and Caution & Warning. Once

the equipment is brought on line with an appropriate software load, the

limited functions of the ACA SSDS equipment will be assumed by the HMI and HM2

equipment and the ACA equipment will be taken off line. Appropriate

Command/control diagnostic checks will be performed from the ground.

The added SSDS functions of scheduling, operations sequencing, along with

enhanced Caution & Warning, and Facility Management functions, when

operationally mature will reduce the ground crew requirements during and

between Orbiter missions. The remaining functions within the module will be

checked within the inherent limitations of the suited crewmen; however, the

GN&C, Comm and DMS will be configured, through ground and Orbiter crew

commands, to activate the high gain direct TDRS llnk.

4.4.3.4.5 Fliqht #5

4.4.3.4.5.1 Package Definition

The fifth package as shown in Figure 4-33 will consist of the Logistics Module

(LM), along with port and starboard extensions for the Transverse Boom to

support the second set of solar arrays.

4.4.3.4.5.2 Mission Overview

As usual, the Orbiter will dock at the HMI docking port. The MRMS will remove

the Logistics Module from the cargo bay and position the module for positive

mate to HM2 and attachment to the keel structure. The normal connection of

utilities, power, and thermal control will occur.

A major activity of this mission will be the activation of the LM, HMI and HM2

ECLSS system to provide module habitability and a second base for EVA support.

145
The Transverse boom extensions will be deployed utilizing the MRMS under EVA

control followed by attachment of the set of solar arrays.

4.4.3.4.5.3 SSDS Functions

Suited crewmen will enter HMI through the docking port and cross into the

Logistics Module to configure its ECLSS equipment, pressure sources and

regulators and sinks. HM-2 first and then HMI will be configured to accept

the LM supply pressures of gas, water etc. and their ECLS systems will be set

to normal design conditions.

Once monitoring on ground and within the module indicate an acceptable crew

environment, the crewmen will de-suit and begin the comprehensive checkout of

each habitation module. This checkout will verify the full workstation/DMS

capabilities and voice/video comm capabilities between modules and Orbiter and

ground. The EVA servicing and support functions will also be checked, in

addition to other crew support functions not previously excercised. All

discrepancies and anomalies will be worked with ground crew utilizing full

audio/visual (TV, text, and graphics) communication capabilities. Effective

troubleshooting can be performed to isolate faulty equipment and return it

with the Orbiter.

At this point, the program has the option of leaving a 2-3 man crew at the

Station to support the on-orbit integration operations. The decision would be

based on factors of overall utility and the demonstrated station safety and

reliability.

4.4.3.4.6 Fliqht #6

4.4.3.4.6.1 Flight Package

The Flight No. 6 wlll consist of laboratory module, LAB I. This module, as

shown in Figure 4-33, contains a major portion of the C&T control and processing equipment associated with traffic control, the DMS payload collection and

146
distribution equipment, and the standard communication (voice/video) access,

ECLSS, and "Safe-Haven" equipment.

4.4.3.4.6.2 Mission Overview

For this mission, the Orbiter will dock at HMI and the MRMS will be translated

down the keel for access to the Orbiter and the LAB l attach point. LAB l

will be removed and positioned using the combination of SRMS, MRMS and EVA

support. Following mechanical securing of the module and attachment of its

utility lines, the crew will checkout and configure the module to establish a

habitable environment for subsequent checkout.

This mission provides a second opportunity to leave a 2-3 man crew on-orbit to

support continuing station checkout operations . Experiments housed within

the Lab l module could also be activated at the conclusion of the mission,

depending on their support requirements.

Any defective equipment identified during this or earlier checkout could be

removed by the crew for onboard repair or return to earth, since the orbiter

will have available cargo space to deliver repalred/replacement equipment on

both the 6th and 7th flights.

The LAB 1 module will be configured for either a 'manned' or 'man-tended'

operation depending on whether a partial crew remains within the Station.

It should be noted that the SSDS functional distribution provided in Figure

4-32 dictates a deviation from the Reference Configuration in that LAB l, with

its customer data management, mission support, and ancillary data management

functions, has been deployed first to provide a more operationally continuous

build-up sequence. There has been no consideration for any structural

difficulties that this deviation might cause.

147
4.4.3.4.6.3 SSDS Operations

Once the LAB 1 module has been powered and is habitable, its communication

equipment will be checked out followed by activation of the DMS and Comm &

Tracking equlpment. It is also anticipated that some payloads/experiments

within this module will be activated to satisfy associated 'user' agencies and

also to support some limited system checkout. The added SSDS functions within

this module are those of 'customer data management', customer operations

support' and 'ancillary data management'. The Comm & Tracking equipment

includes signal and data processors for constellation tracking functions and

to support video/data formatting associated with the TDRSS forward and return

links.

System level checks will be initiated from the HMI workstation in conjunction

with ground crews to fully exercise the payload oriented capabilities. These

exercises will include command and monitor sequences by ground and on-board

crews to: l) verify command management functions, 2) verify payload sequencing

operations, 3) verify the distribution of ancillary data for payload access,

and 4) verify the end-to-end, multl-experiment (and core) data flow including

ground archiving and distribution to user.

4.4.3.4.7 Fliqht #7

4.4.3.4.7.1 Package Description

The last station build-up package will consist of the LAB 2 module plus any

replacement/returned equipment.

4.4.3.4.7.2 Mission Overview

This mission will berth to HMI and utilize the MRMS and SRMS with EVA support

to emplace the LAB 2 module.

This module, as shown in Figure 4-32, will house the normal ECLSS, TCS,

communication access, Power, and "safe haven" equipment plus DMS equipment in

148
the form of work stations, data processors, and mass storage equipment, to

support functions of customer data management and customer operations support.

The module activatlon/checkout sequence will follow the previous flow and

finish with system integration of its functions via HMI and HM2 operations.

4.4.3.4.7.3 SSOS Operations

When the module has been powered up, and is habitable, the normal checkout

will proceed with verification of communications (voice/video) and its

workstation. Then, as with the LAB l checkout, some payload/experiments

within the module will be activated and end to end checkout performed. This

module, as indicated in Figure 4-33, will house the large mass storage

equipment utilized during zone of exclusion (ZOE) period and for general (load

relief) data buffering as required.

4.4.3.5 Initial Operational Capability

At the conclusion of the 7 mission sequence, the SSDS will be fully in place,

performing or ready to perform all defined functions. Additional flights will

be required, however, to transport the OMV, additional payloads/experiments/

free flyers, and personnel required to supplement the Station crew and thus

achieve the IOC station configuration illustrated in Figure 4-35. Also, there

will be some transitional, start-up period to bring the Station up to a

routine working status. There will be a heavy reliance on the robustness,

i.e. flexibility and tolerance of the SSOS during this period since its

background tasks must be continued while supporting ground/Station crew real

time tasks and adapting to the growing payload/experlment mission support

requirements. Equipment problems will inevitably occur during this period as

will human errors; the systems must discriminate faulty conditions and command

sequence errors while continually prompting the crews for appropriate

actions. This will not only test the dynamic and static fault tolerance

features of the subsystems but will also be a challenge to the short term

scheduling and operations sequencing capability of the SSDS.

149
I 1

Figure 4-35. IOC Configuration

150
The activities required to emplace and activate payloads and experiments

should not present any particular difficulties after the 7th mission.

Internal (pressurized) payloads/experiments will be carried through from the

Orbiter, through the habitation modules to the Laboratory Modules. Size

limitations must be imposed to insure appropriate clearance through this

path. In the Laboratory modules, the payloads/experiments will be placed on

standardized racks with 'standardized' interfaces for power, SSDS functions,

and thermal control as required. The checkout will be initiated with a power

up, built in testing (BIT) operations. Scheduling of this testing and the

monitoring of its results will be performed locally on the Laboratory work

station. Voice and video communication will be available directly to the

associated user agency for use as required. Once this checkout is complete,

then the SSOS will be configurated to schedule the Payload/Experiments

operations with respect to Space Station resources, and data management.

Externally mounted payloads, particularly the larger volume variety will be

transported from the Orbiter bay, most likely under EVA control, to their

s_ructural mount. The payloads will be mounted at prepared locations with the

standard interfaces to electrical power, thermal control, and the SSDS.

Rotating mounts will be available as required. Portable MPACs will be

utilized by the EVA personnel to support the initial checkout and appropriate

configuration of the payload. Voice communication will be transmitted to the

associated user along with video provided by remote cameras. Provisions must

be made to support this local operation of the MPAC and video camera. Once

the payload has been judged operational, its schedule will be established via

command through the MPAC to the SSOS scheduling function.

The scenario proposed for this initial build up provides a key advantage in

that on-orbit integration and verification is performed incrementally,

allowing early and continuous evaluation of each subsystem as deployed. Thus

adjustments and corrections can be applied in a more timely manner. This

approach is, of course, heavily dependent on, and strengthens the arguments

for a distributed subsystem architecture. The alternative, centralized

approach would necessitate deferment of any significant system verification

151
until the major elements of the Station had been assembled and presents a

somewhat higher risk to the over-all program.

4.4.4 Space Station Growth Scenario

A growth phase for the Space Station is predicated on currently p_ojected

mission manifests and foreign (international) Station involvement plus

addition of the Orbital Transfer Vehicle (OTV) with its mission operation and

servicing requirements. It is also anticipated, however, that the reality of

an operational Space Station will stimulate unscheduled demands for

payload/experiment support in both high and low earth orbits. This support

will translate into additional laboratory modules and payload truss mounts,

additional habitation modules, additional structure, and additional capacities

in all sub-systems as diagrammed in Figure 4-36. While some elements and

options of growth can be formulated to a reasonable degree, the actual growth

path cannot be defined because of the mission demand uncertainties and to a

lesser extent, the unpredictability of technological advances.

With respect to the SSDS, the key growth drivers will be: l) increased volumes

of data to be handled at higher data rates, 2) increased free flyer (and

tethered) traffic, and 3) increased space/space and space/ground

communications requirements. More processing power, more mass memory, and

higher data transfer capacities will clearly be required, coupled with

improved space/ground communication paths, i.e. TDAS and direct broadcast.

Growth activities are expected to occur in discrete and potentially

independent steps. The distributed SSDS topology anticipated for IOC appears,

therefore, to provide an optimum baseline for the growth scenario, but must

incorporate flexibilities for growth that have been planned from the inception

of the program. 'Scarring' (built-in growth accomodation), will be provided

wherever practical within the space elements, to absorb or anchor the

additional capacititles and resources.

The growth activities provide the opportunity not only to increase mission

support capabilities, but also to reduce operational costs through technology

152
w m ,

.- ._ ',

I II0 k"_l

i i

_._=<"

r,

U.
upgrades, and to reduce ground support requirements through implementation of

more Station automation and autonomy. Technology upgrading (or insertion)

will be supported through continued use of standardized hardware such that

higher performance, higher reliability products of reduced size, weight, power

and cost can be 'dropped in' with minimal impact. Greater automation and

autonomy will require more use of artificial intelligence and robotics, both

of which are expected to proliferate in the growth time frame.

The specific drivers and impacts of growth are discussed in the following

paragraphs.

4.4.4.1 Ground Segment

The growth of the ground segment and its drivers cannot be specifically

tracked since significant changes in the configuration of the space/ground

link are expected within the growth period. Thus, although the projected

mission set may generate higher aggregate data rates and volumes, addition of

improved beam switched communicatlon satellites and/or direct broadcast will

relieve much of the ground data handllng/distrlbutlon demands through use of

more distributed approaches.

There will be a continuing effort to reduce operational costs of the SSDS

ground system by reducing ground crew requirements through the use of enhanced

automation and 'expert systems', and through the use of more reliable, more

fault tolerant hardware to reduce down time and maintenance requirements.

software upgrades will be an Implicit part of growth to correct identified

deficiencies and enhance user (customer and ground crew) utility. This is

likely to be a significant program cost driver beyond initial development

costs. Provisions for cost effectively accommodating software upgrades must

be a major consideration in early definition and planning.

No significant technical drivers can be identified in these 'growth'

modifications since the ground elements are not impacted by volume, weight,

power constraints or accessibility limitations. Addition of ground terminals

154
within regional data enters or remote customer facilities to accommodate

direct broadcase will be accomplished with no particular difficulty. In

summary then, the SSP ground segment 'growth' can be characterized as:

I) enhancements to the space/ground communication and data distribution,

supported at least in part by direct broadcast from Station or through

advanced communication satellites

2) enhancements in data handling, resource planning/scheduling, etc.

utilizing 'expert systems'.

and 3) software upgrades to correct identified deficiencies and improve

user utility of the SSDS with a relatively unconfined environment.

The issue to be resolved is that of location and capability of the Data

Handling Center (DHC). Current planning, co-locates the DHC at the White

Sands Ground Terminal. When direct broadcast to the Regional Data Centers

(e.g., TDAS) is implemented the DHC functions that are duplicated with the

Regional Data Centers will disappear. The majority of the remaining functions

will migrate to orbit. The IOC location of the DHC should consider the smooth

transition to the growth phase.

4.4.4.2 Space Segment

The Space segment, in contrast, will be continually constrained by volume,

power, weight, and accessibility. In addition, sub-system capabilities cannot

be significantly impaired during growth rework.

As indicated in the Background. section, the demand for additional

payload/experiment support translates to additional structure, additional

laboratory and habitability modules, and additional sub-system capabilities.

The laboratory modules wlll house the added payloads/experiments along with

additional Comm & Tracking and DMS hardware/software for their support. The

habitability modules will house additional DMS equipment including normal

MPAC's, and will support additional crew personnel, including mission

specialists as required. The additional structure will be required for the

attachment of these modules and any for additional external payload/experiment

support.

155
Sub-system expansion must occur across the board to provide the increased

capacities in the areas of power generation, thermal dissipation, attitude

control etc. The primary impact on the SSDS, however, is from the growth

requirements of data handling, data base management, and communications

although the distributed topologies postulated in the Butld-Up scenario should

adequately support expansions of the data/data base management capacities.

Growth of the SSOS functions will be facilitated by spare capabilities built

in to the IOC configuration. Spare network nodes, for example, and even spare

networking can be provided tn the IOC conflguratlon along with the required

additional sub-system associated cables and ducts. Local area networks

(LAN's) within each added module can therefore be readtly linked to existing

backbone networks or to new backbones which are bridged to those existing.

The data/data base management equipment within those modules will provide the

horizontal growth required.

Clearly, some vertical growth can be implemented through technology insertion,

the replacement of existing ORU's or perhaps single card's to provide more

faster, lower power, or (for the Polar Platform(s)) more radiation tolerant

hardware.

Continued utilization of standards will be mandatory in the growth phase to

insure compatibility of physical and logical interfaces such that replacement

hardware and software will essentially be a 'drop-ln' operation, transparent

to the system operation.

Foreign involvement is anticipated in the Space Statlonand may take the form

of additional modules with potentially differing LAN topologies. Interfacing

these modules to the SSDS can be effected through imposed standards or through

the use of internetwork gateways.

Some growth wlll have more of an impact, particularly if specialized solutions

are implemented for functions previously performed by general purpose

hardware. A primary example of this is the area of artificial intelligence.

A.I. machines and software wlll be further exploited during growth phases of

156
the SSP. Functions such as scheduling, operations sequencing, configuration

and resource management, crew support i.e. physiological, biological, training

are all strong candidates for A.I. expert system solutions. An implementation

option, in such cases would be to house these new solutions in the added

habitation modules. The function would then merely be with minimal disruption

to function operation.

The most significant driver to SSDS growth will be the management of the data

that is collected from the additional experiments/payloads and free-flyers and

delivered to the communication port(s) for transfer to the ground. This

volume of data may require new solutions perhaps beyond the capabilities of

the TDRSS link(s), particularly in a multiple COP and POP scenario. Improved

and multiple communications ports may be required to implement direct

transmission to ground or use of multiple satellites with advanced

technologies.

The space segment growth scenario therefore consists of the following tasks.

• replacement of ORU's and/or component cards to provide an expansion of

capabilities.

• expansion of sub-systems to provide more additional resources and

support capabilities.

• addition of structural elements and associated monitoring

instrumentation.

• addition of the OTV to support high energy orbit transfer and

servicing of payload.

• addition of lab and habltatlon modules

• addition of back-bone networks/bridges/gateways for the additional

modules/nodes

• addition of data management/communication equipment to transfer the

increased volumes and rates of data to the ground/users.

Verification of these addltlonal/modified resources will be performed in the

same fashion as described in the original build-up, i.e. no specific

additional growth implementation issues are identified.

157
4.4.5 Operational Design Drivers

One of the purposes of the operational concept definition was to identify key

SSIS and SSDS design drivers that result from the operational concept. A key

design driver is an operational, functional, or performance requirement that

is expected to have significant impact on the performance, complexity, risk,

or cost of the system. The following key operational design drivers have been

identified:

a. The need for system transparency as viewed by the customer will

impact system complexity by causing special provisions to be

implemented to minimize data transport delays and to minimize system

interactions that might constrain or interfere with customer

independence. Certain delays are inevitable because of communication

path propagation times and link outages. Additional delays, such as

those caused by processing, reformatting, conflicts, or capacity

limitations, need to be minimized in the design In order to provide

good functional transparency.

be The quantity of data archlvlng requested by customers and the need to

provide wide, easy-to-use, access to the archlved data will influence

the capacity and complexity of the system.

C • The amount of customer data processing beyond Level 0 will drive the

capacity of the processing resources In the SSlS.

do The amount, type, and quality (accuracy, precision, etc.) of

ancillary data requested by the customer will influence the SSIS

processing resources significantly.

e. The level and implementation plan for autonomy/automation provisions

will have a profound effect on system processing resource

requirements. The need for autonomy and automation also will

influence the basic system architecture and the design implementation

of subsystems.

158
f. The number and physical distribution of customers will impact the

networking, complexity of interactive scheduling, and the difficulty

of dealing with restricted and constrained commands.

go The degree to which customers are involved in payload operation,

especially real time command and monitor and short term schedule

changes, will drive operations approaches and affect the complexity

of the scheduling, command management and data handling functions.

ho The number of customers competing for limiting system resources will

also impact the complexity of scheduling and system operation.

i • The Space Station is expected to undergo extensive growth

modification and upgrade during its lifetime. New technology must be

accommodated, providing ready means for its integration.

159
Section 5

SSIS/SSOS FUNCTIONAL REQUIREMENTS

This section contains the functional and performance requirements developed in

Task I. The SSIS functional requirements are given in Section 5.2, together

with the performance drivers. The SSDS functional requirements are given in

Section 5.3. Section 5.4 provides a summary of SSDS functional and

performance requirements which will have a major effect on the SSDS design.

The discussion of requirements is divided between the SSIS and the SSDS.

Discussions of the SSIS, because of its broader scope, will be centered on the

SSPEs. The SSPEs and their roles have already been identified in Section

4.2. In Section 5.2, the discussion will cover the functions and key

performance drivers. Discussions of the SSDS will be centered on functions

and their decomposition to lower-level functional requirements.

5.1 REQUIREMENTS ANALYSIS METHODOLOGY

The functional requirements have been developed from previously published

documents, from the team data base, and fromengineering analysis. Functional

requirements from the controlling documents (References l, 2, and 3) were

identified and entered into the traceability matrix. Details of this process

are given in Section 5.5, and the complete traceability matrix is given in

Appendix A.

In addition, two top-down analyses were conducted in parallel to develop SSOS

functions. A function tree was developed from prior analyses and logical

decomposition of functions to successive levels. In parallel, data flow

diagrams were developed to level l for all functions, and to levels 2 and 3

selectively for some of the complex or critical functions. These parallel

analyses provided an extremely valuable cross check of the completeness of the

functions required of the SSDS.

P_ECEDING PAGE IBLM_ gOT FILMED

161
The function tree and data flow diagrams were merged to form an integrated,

hierarchical set of SSDS functions. The function set was checked for

completeness against the SSIS and SSDS requirements. Each of the requirements

was mapped to an appropriate function. Where no appropriate function was

found, a function was added to provide For the SSIS requirement.

The result is a validated, integrated set of SSDS functions, traceable to the

requirements and/or analyses that were used to identify the functions. The

functions are fully responsive to the requirements, and are sufficient to

perform all identified SSDS operations.

The final function list is contained in Appendix A, Section A-4. Figure 5-I

shows the top three levels of the function tree. The number of SSIS

requirements mapping to each function is shown in parentheses after each

entry. Most of the functions are supported at this third level by multiple

requirements. Some of the broader or more generic requirements were mapped

only to the second level. These requirements also support the lower level

functions. There are, therefore, many requirements supporting each function

at the third level, considering the flow down of the requirements from the

higher level.

Space Station Program Elements (SSPEs) were identified and allocated to SSDS

or to the non-SSOS portions of the SSIS in Section 4.2. Requirements

pertaining to non-SSOS elements and their interfaces were collected by SSPE.

These requirements are delineated in Section 5.2. Requirements pertaining to

SSDS elements were collected by SSDS function in the hierarchical structure of

Figure 5-I. These requirements are delineated in Section 5.3.

An SSIS Functional Requirements Data Sheet, Figure 5-2, was prepared for the

functions in the function tree at a level which will support definition of

design requirements. The functional requirements from these data sheets have

been entered into a computer-based requirements data base. Output reports are

found in Reference 14. Key performance requirements identified for those

functions are collected as SSDS performance requirements in Section 5.4. Only

those requirements affecting the overall SSDS performance were considered.

Hence, the performance requirements relate to quantities of data, rates of

throughput, and timeliness of operation. Wherever possible, representative

162
ORIG,_AL _,_-_"

Poor QUALrrY

:z

_. v

._. ==, s-

>=

_22

v

o

:1,

i_ _

_.i ¢ _

_! C>-

v

C

_Z

-2X_

Z Z zz

- _ _

.--_ -_ . . ._

•

• _ _ _ _ _ _ " . .

v

. _._. ,_ . _ - :.,,_ "'_ . :_j

i

- ¢¢

<: =,,

-. v,¢

-= _ _-_-_ _"

_¢: C'.J')

._ -"_ ._ _ _,,__

- _ _ _

m w_

i_ _

vvvv

2

_n

Z_

2

_0

0

¢

0

"0

,,,o

N

L

O

5

r'

0

4J

L

L

L

O

3

O

O

¢,

¢

O_

r"

"5

-,-j

4-;

...<

r.

e

L

De

I--

.2

n

o

I.-

u

163
Pm1_rml I_

Functkm Numt_r. Neme:.

F_ct_ lype:

Dem, t_t Ion:

SSOS FUNCTtONAL REQUIREMENTS DATA SHEET

RetlN¢ by:. No. __

Prosrllm P11ml_: Initial .--

Dote:

Growth

Function SkN_:Wm:

Cdflcelltlr, Re_ml_ Time Im_l_

0role Ptt_mey Code:

Ale rmWAmtt/mcla t kin#l: IqOCI_WI?

_e, lt4m_

Nm

#3 #4 _5

Sow_e

Rate

D_tleml_m

Rmte

Arm

ADOCTiONAL R|QUIR FJII|NTlk

DEaN CNAMACTEMIST1¢I:

DAta $OuMxw:

RIN Tkw: _O Oet_ ASm ntue

_ t._a__ I.a_nmt __ I_m__ km

Dins Qua. W 8N Emw RMel

Sm

System 0qNUemy CUe:

P_ LCmeUm DAI:

0kmm.,um_ VW: ne_mmm _

ioc CAPAIHUTY

DAt_ M_meWq: W,mmmm n,W Cy_e _a_m

wowee_ _. Iqqmm _--- __ oew n,,q_ __

DA_ mmr.le_ Sowmlm kS_eea_neNNl_ ._. k nvl

k,e_,nd kSym NO. o_ me_W

GROWTH CAIIAWUTY

DAt_ g,_ hmnmi_e _ C_ nemMm

Pmw_w uem_. _qmm _--- __ 0e_ nNm __

om S_mee: S,_ ki_ ___ % in__t_s

Figure 5-2. Functional Requirements Data Sheet

data are drawn from the Woods Hole Mission Requirements (workshop).

Engineering estimates are used where no applicable data are found.

Areas of major design impact which will be noted in the following sections are:

• Peak data rates, especially for Space Station and POP payloads, will

drive data throughput, onboard processing, and recording rates.

e The combined data rate of the Space Station, COP and POP(s),

including payload data, are to be transmitted to the ground via

TORSS. A single Ku-band channel is limited to about 300 Mbps. The

combined average data rates of these facilities is approaching 300

Mbps. Hence, these data rates drive the system.

164
0 The requirement for real time, interactive control of payloads From a

remote location will affect primarily the scheduling of data and

command handling resources and communication links.

. The data rates and requirements for on-line and short-term archival

storage combine to drive the design of data storage systems. Onboard

storage is driven by the scheduling of TDRSS downlinks. In-process

storage at the Data Handling Center is driven by the requirement for

12 hours of in-process storage to ensure data delivery. Short-term

archival storage is driven by the requirement for storage for one

week after receiving data of satisfactory quality at the customer's

facility.

, The Network Control capability (NCC) must be expanded to accommodate

the increased TDRSS traffic and to operate the Data Distribution

Network. Implications to he NCC will be developed in Task 3 and 4.

5.2 SSIS FUNCTIONAL REQUIREMENTS AND DESIGN DRIVERS

This section defines functional requirements for the Space Station Information

System (SSIS) and interfacing Space Station Program Elements (SSPEs). Section

5.2.1 provides the functional requirements related to the SSPEs and their

interfaces with SSlS, together with the key requirements driving the SSIS/SSDS

design. Section 5.2.2 defines customer requirements for standard services

from the SSIS for those SSIS functions that were determined to be outside the

SSDS by the criteria in Section 4.2. Customer requirements for the SSDS will

be addressed in Section 5.3.

5.2.1 SSPE Functional Requirements

Each of the Space Station Program Elements (SSPEs) identified in Section 4.2

are either in the SSIS or interface with the SSIS/SSDS. Functional

requirements allocated among the SSPEs, SSlS and SSDS, and key performance

drivers are presented by SSPE in this section. The discussion is restricted

to those elements identified in Table 4-3 as being in the SSIS, but not in the

SSDS.

165
5.2.1.1 Space Station Payload Requirements

A) payload Functional Requirements

The Space Station payload interfaces with the SSDS are illustrated in Figure

5-3. The payloads shall perform the following functions:

• Receive customer/operator data and commands from the SSDS.

a. Decode/de-encrypt data and commands protected by customer

b. Execute prestored sequences of commands

2. Receive time and frequency references

• Receive from SSOS standard core and customer data services, for

example,

• State vector

Ephemerides

Pointing angles, etc.

Payload

1

Payload

2

coo

Payload

N

SciencelEngrg Data

II

Ancillary Data

Commands

SciencelEngrg Data

Ancillary Data

Commands

Sclence/Engrg Data

Ancillary Data

Std

Cmd

and

Data

IIF

SSDS

Commands

• Peak Science/Engineering Data Rats = 300 Mbps

• Average SciencelEngineerlng Data Rats = 6.9 Mbps, 1994

=54.1 Mbps, 1997

• Average Command Data Rate = 2.8 kbps, 1994

=3.4 kbps, 1997

Std

Comm

IIF

Figure 5-3. 55DS/Payload Data Interfaces

166
. Generate and issue scientific/engineering data stream to the SSDS.

The payload shall:

a.

b.

C.

d.

e.

Accept and merge Space Station ancillary data

Provide error protection enhancement coding and security

Encrypt as required

Issue payload data stream in appropriate format

Issue payload health and safety status monitors.

. Utilize subsystem-protected, reconfigurable resources:

• Electrical power

• Thermal control

• Fluids.

. Provide fine pointing, as required by the payload, to supplement

coarse pointing provided by the Space Station articulating payload

mount. The customer shall be responsible for developing the

coarse-pointing reference and delivering pointing requirements to the

SSDS in the commands from the payload.

B) Key Drivers

I. Return Data Rates and Storage.

The IOC Space Station payload complement may provide an aggragate

peak data rate of up to 302 Mbps. An estimated IOC (lg94 reference

date) onboard storage requirement of about lO lO to 10II bits is

based on the scenario of a single downlink data burst of about 5

minutes per orbit with data collected at the 14.9 Mbps (6.4 payload

data plus 8 voice/video and core) average rate indicated in Table 6-9,

during a nominal 90-minute orbit. The average data rate peak is 56

Mbps in lg96. Note that these rates include a 1.8 "scheduling

factor" applied to missions with data rates less than 50 Mbps and

apply to short term averages. See Section 6.4 for further discussion

of average data rates. The corresponding onboard storage

requirement is about 1010 bits for IOC and 3XlO II bits in

lggT. These figures include Space Station core data and voice/video

167
link requirements, and represent a significant impact on the return

portion of the SSDS data management and communication subsystems.

2. Forward Data Rates.

.

The aggregate IOC forward link command rate is estimated at 3-4 kbps

average for IOC and growth payloads. The rate does not include

voice/video or Space Station core requirements. The total potential

forward rate requirements represent an impact on the forward portions

of the SSDS data management and communication subsystems.

Scheduling of Resources.

Mission model analysis yields an average IOC payload power

consumption on the Space Station of 54 kw, neglecting possible

redundancy between Comm 1201 and SAAX0401. The target IOC power

system delivery is 75 kw of which 25 kw is allocated for SS

housekeeping. Thus a power resource allocation/scheduling impact on

the payload complement is indicated.

A crew of two station specialists and four mission specialists is

forecast for the IOC Space Station. The crew resource matches the

estimated payload support requirements on an averaged allocation;

however, some impact is anticipated on day-to-day operations which

will require scheduling flexibility.

5.2.1.2 Core System Requirements

A) Core System Functional Requirements

The Space Station core systems interfaces with the SSDS are illustrated in

Figure S-4. The core systems shall perform the following typical functions:

1. Maintain Space Station environment and communications links.

. Accept and execute SSDS commands for

a. Orbit maintenance

188
Core Systems

Navigation

I

Power

Operations

and

Procedures

Commands

IA Operations

ControIC°ntaminati°n I Levels' Alarms

I

SSDS

r I

Sensor Data

Status w Op. Events Sched.

== eduJe,

/ Command,

_ Commands , Control _ _ Displays .

Status Std C°mmands_ _''_l

l i Cmd

and

Data

i_ Queries I/F Status / Commands

Displays _Sensor

j w Data Alarms

Status __

Figure 5-4. SSDS - Core Systems Data Interface

Std

Cmd

and

Data

I/F Commands Displays !

Operator

b. Collision avoidance

c. Attitude maintenance

d. Attitude changes to accommodate payloads

e. Crew health maintenance, recreation, and training

f. ECLSS reconfiguration

g. Thermal control subsystem reconfiguration

h. Power subsystem reconfiguration

i. Communication subsystem reconfiguration

j. Resource management

k. Redundancy management

I. Maintenance/repair/growth operations.

. Generate engineering and status data

a. Subsystem status

b. Consumables status.

e Generate caution and warning information on equipment operating

limits and hazards to personnel and vehicle safety, and alert

operators to unsafe conditions

169
B) Key Drivers

I. Data Rates and Buffering.

The high payload data rates will have a significant impact on the

SSDS/communications subsystem design to provide

5.2 .I.3

a. adequate data distribution and growth capability,

b. adequate data buffering and growth capability,

c. rapid reconfigurability to accommodate operations schedule

changes

Co-Orbiting Platform Requirements

A) COP Functional Requirements

The co-orbiting platform(s) (COP) interfaces with the Space Station

communications system are shown in Figure 5-5. Alternatively, the COP may

interface directly with TDRSS. The COP shall perform the following functions:

l .

Co-orbiting

Platform

FreeFlyers

Maintain orbit and attitude per performance requirements

I

P/L, Engrg Data J

mF_

P/L Cmds

Traffic Control

--w

P/L, Engrg Dam

L

wr

P/L Commands

..d

Traffic Control

Comm

System

I/F

SSDS

Control

0n-Board Storage

Commands

Std

Cmd _, Commands

and

Data

ill=-

Displays

A P/L Cmds

P/L Data

Peak Science/Engineering Data Rate = 1 Mbl:_

Average Science/Engineering Data Rate = 1 Mbps

Average Command Data Rate = 1 kbps

Figure 5-5. COP, Free-Flyer -- SSIS Data Interfaces

Operator

Customer

170
. Receive commands and data via TDRS or Space Station relay and

a.

b.

C.

d.

Error check data

Validate data and command sources and destinations

Distribute data and commands to individual payloads

Execute orbit, attitude, and resource adjustment commands.

. Provide scientific/engineering data stream to co-orbiting platform

control and customers via TDRSS or Space Station relay, and

a. Collect scientific/engineering data and merge to data stream

b. Encode, modulate, and transmit return link data via TDRS.

NOTE: Platform ancillary data are provided to payloads for their own

merging.

. Receive and execute traffic control and proximity operations commands

from Space Station while in Constellation area.

. Receive and execute COP Control Center orbit and attitude commands

when remote from the Space Station.

B) Key Drivers

I. Return Data Rates and Storage Requirements.

The IOC Co-Orbiting Platform payload data rate varies with mission

assignment from l to 16 Mbps, with growth to about lO0 Mbps in some

mission models. Reference 15 seems to show 1 Mbps peak and average

with no growth. The onboard storage requirement is estimated to be about

5XlO g bits based on the l Mbps average data rate of Reference 15, and of

a single downlink burst during each gO-minute orbit. The onboard storage

requirement may apply either to the Space Station, the platform, or both,

depending on whether the platform transmits directly to TDRS or uses the

Space Station to relay data.

171
5.2.1.4 Co-Orbiting Platform and Free Flyer Control Center Requirement_

A) COP and Free Flyer Control Center Functional Requirements

The COP and Free Flyer control center interfaces with the Space Station

Control Center are illustrated in Figure 5-6. Both control centers shall also

interface with the TDRSS ground station (optional) and the Data Handling

Center. The COP and Free Flyer Control Centers shall perform the following

functions:

l ° Plan and schedule Spacecraft operations

a. Maneuvers

b. Data links.

. Provide mission control data to the SSCC or TDRSS ground station for

relay to the Spacecraft

a. Attitude and orbital adjustments for nonproximity operations

b. Core system data and commands.

3. Receive engineering data from the Data Handling Center.

. Coordinate with the SSCC for rendezvous with the Space Station or OMU

for payload or Spacecraft servicing and maintenance.

B) Key Drivers

• None identified.

I COP Control

FreeFlyerControl

POP

Control

Platform Data

iControlCommands '

_, Operation =

Coordination

,_,, Vehicle Data Std

I C'ontrol Commands Cmd

I.., Coordination _ and L Data

.I - _ I/F

n_ Platform Data

I Control Commands _._

J_, Coordination

SSDS

Scheduling

#ata

Platform

.,= Data [ Data _

Figure 5-6. COP, POP, Free-Flyer Control - SSDS Data Interfaces

C" "_ 172

Std

Cmd

and

Data

I/F

Operations

_, Req'ts

I Customer

t Operator
5.2.1.5 Polar Platform

A) POP Functional Requirements

The Polar Platform (POP) shall have no direct orbital interfaces with the

Space Station. The POP shall perform the following functions:

I. Maintain orbit and attitude to performance and mission requirements.

o Receive commands data from Polar Platform Control via TDRS

distribution network and

a.

b.

C.

d.

Error check data

Validate data and command sources and destinations

Distribute data and commands to individual payloads

Execute orbit, attitude, and resource adjustment commands.

. Provide scientific and engineering data stream to Polar Platform

Control Center and customers via TDRSS and the Data Handling Center.

a. Collect data from the commercial and scientific, and merge to

data stream

b. Encode, modulate, and transmit downlink data to TDRSS.

NOTE: Platform ancillary data are provided to payloads

for merging prior to downlink.

The mission model of Reference.15 indicates three POPs, designated POP-I,

POP-2 and POP-3.

B) Key Drivers

I. Return Data Rates and Data Storage Requirements

The proposed complement of POP payloads has an aggregate peak data

rate of 393 Mbps for POP-I, 300 Mbps for POP-2 and 76 Mbps for POP-3

at IOC for each POP. POP-I data rates grow to 66g in Igg5. An

estimated storage requirement of about 0.5XlO 12 bits for POP-1 and

IO II bits for POP-2 and -3 derives primarily from buttering high

173
rate missions through the exclusion zone. It was assumed that only the

highest rate mission would operate through the exclusion zone on any

single pass. These figures represent a significant potential impact on

the POP data management and communication subsystem design.

5.2.1.6 Polar Platform Control Center

A) POP Control Center Function Requirements

The POP Control Center shall interface with the Space Station Control Center,

the TDRSS ground station, and the Oata Handling Center. Interfaces with the

SSCC were shown in Figure 5-6. The POP Control Center shall perform the

following functions:

1. Provide scheduling, and operations control for Polar Platform.

e Coordinate scheduling requirements for data links with Network

control center.

o Provide scheduling and command management for coordinated payload

operation between the Space Station and POP.

4. Receive POP engineering data from the Data Handling Center.

B) Key Drivers

None identified.

5.2.1.7 Tracking and Oata Relay Satellite (TDRS)

A) TDRS Functional Requirements

The TDRS shall be the primary data link for the Space Station and platforms.

The TDRS shall

• Receive reconfiguration commands from White Sands Ground Terminal

(WSGT) for antenna pointing, frequency, and modulation, etc., to

transmit and receive payload data.

174
2. Receive and forward link signals, from TDRS ground station.

. Retransmit forward link data to the Space Station Communications

Subsystem, COP Communications Systems (optional), Polar Platform

Communications System, and other SSPEs such as OMV and OTV when these

SSPEs are not using other links for communication with the ground

(users are discriminated by frequencies, polarization, PN code, and

communication beam pointing).

. Receive return link signals from Space Station Communications

Subsystem, COP Communications Systems (optional), and Polar Platform

Communications System (users are discriminated by freqencies,

polarization, PN code, and communication beam pointing).

5. Retransmit return link signals to TDRS ground station.

B) Key Drivers

I. Return Data Rates.

The current planning is to effectively dedicate one to three SA

channels to the Space Station program (SSP). This limits the SSP

return link data rate to 300, 600 or 900 Mbps total data rate. These

rates will place some new requirements or limitations on the SSP or

TDRSS. A single channel limits return data operations of SS, COP,

and POP and may translate to schedule constraints for payload

operations. Two or three channels will require new and extensive

equipment at the ground stations. In addition, the TDRSS is designed

to operate at steady data rarest necessitating buttering and

scheduling operation. These impacts will be more severe with the

implementation of the proposed uplink and downlink video, real-time

remote payload operation, and audio communicaions.

175
5.2.1.8 TDRSS Ground Station Requirements

A) TDRSS &round Station Functional Requirements

The TDRSS ground station shall interface with the Space Station Control

Center, platform control center(s) and the Data Distribution Center. The

TDRSS ground station shall:

I , Provide forward link data and commands to TDRS:

a. Receive packetized, framed data from the data distribution

network

b. Error check

c. Provide data accounting

d. Format and transmit data to TDRS per scheduled time, frequency,

channel, and modulation.

. Provide return link data to the Data Distribution Center

a. Receive and capture TDRS data

b. Transmit framed data.

3. Provide second source tracking data for SSPE navigation.

B) Ke_, Drivers

1. Data Rates.

The high payload data rates will significantly impact the current

configuration of TDRSS Ground Station operation. Average data rates,

including Space Station and platform engineering data and audio/video

links, will approach 300 Mbps, while peak rates could exceed 600 Mbps.

176
5.2.1.9 Space Station Data Distribution Network Requirements

A) Data Distribution Network Functional Requirements

The Data Distribution Network interfaces with the TDRSS Ground Station, the

Data Handling Center, customer facilities, RDCs, and SSPE control centers are

illustrated in Figure 5-7. The network shall:

I • Relay forward link commands and data from SSPE and payload control

centers to the TDRSS Ground Station•

. Relay return link data from the TDRSS Ground Station to the Data

Handling Center.

. Distribute return link data to customers, data centers and control

centers.

SSDS

l Engineering I _ Core Data Data Center I Core Archives

j v

I lj Core Data Operators _ Displays

Core Vehicle

Std

Cmd

and Archive Data

Data

I/F

Data

Distribution

doad

Data

Customer

Data

g

Real

Time

On-Line Storage

Off-Line Storage

Average TDRSS Downlink Data Rate = 263 108 Mbps, Mbps, I1999 OC

On-Line Storage 1013 Bits

Off-Line Storage = 2x1014 Bits

Customer Peak

(Downlink)

r

Space

Station

I/F

Data

Dist.

Network

l

Vehicle DatalB !

Payload

Data

! .eo.="J

Pay load

Data

Accounting w

Data I

Requests i

Individual Data Rate = 300 Mbps

Figure 5-7. Data Network - SSDS Data Interfaces

TDRSS

Ground

Station

SSDS Control

Centers

Customer

Facility

No. 1

(RDC)

Customer

Facility

No. N

177
B) Key Drivers

1. Data Rates

The high data rates will require a major increase in the capacities

of the current configuration distribution network. The average data

rate between the TDRSS Ground Station and the Data Handling Center

will approach 300 Mbps, while peak rates may exceed 600 Mbps. The

aggregate rate from the Data Handling Center to customer and program

facilities will also approach 300 Mbps.

5.2.1.I0 National Space Transportation System (NSTS) Requirements

A) NSTS Functional Requirements

The NSTS shall support the Space Station program by providing transportation

services, including

I. Coordinate rendezvous and berthing with the Space Station.

B) Key Drivers

None Identified.

S.2.l.ll NSTS Mission Control Requirements

A) NSTS Mission Control Functional Requirements

The NSTS Mission Control Center shall coordinate operations with the Space

Station, including

l • Participate in and support scheduling for NSTS operations to

transport payloads, SSPEs, crew and logistics supplies between the

ground and the Space Station.

178
.

.

Support customer payload/NSTS integration, launch and space

deployment.

Support SSPE/NSTS integration, launch, and space deployment

operations.

B) Key Drivers

None identified.

5.2.1.12 Contractor Site Integration Facility Requirements

A) Contractor Site Functional Requirements

Contractor facilities shall interface with the software development

environment and the integration facilities to coordinate the development and

verification of applications software and the integration of hardware and

software into the Space Station system, including the following:

I . Link to the SDE to utilize the software development and integration

tools discussed in Section 4.4.2.4.2.

. Link to the Development, Simulation, and Training Facility for system

electrical and communications interface compatibility.

B) Key Drivers

None identified.

5.2.1.13 Network Control Requirements

A) Network Control Functional Requirements

The Network Control Center shall support scheduling of links, including the

following:

179
I. Plan and schedule network operations, maintenance, and growth.

. Provide routing, IO, TDRS channel, frequency, PN modulation

assignments per SSP and other customer requests.

o Provide rapid rescheduling of links in support of customer window of

opportunity or operating requests.

B) Ke_f Drivers

1. Data Scheduling

The high data rates represent a major increase in network performance

requirements which will necessitate additional communications

channels and intensive scheduling for data handling, buffering,

temporary storage and distribution.

2. Operation/Configuration Scheduling

An impact is anticipated in responding to SSDS schedule change

requests to accommodate customer "windows of opportunity". Policies

must be established supported by realistic reconfiguration

capabilities.

3. Customer Real-Time, Remote Operation Complete

Complete, two-way links between the customer and payload must be kept

open continuously during real-time operation. Typical command rates

range up to 1DO Kbps, while data rates for most real-time, remote

operation are under l Mbps.

IBO
5.2.1.14 OTV Requirements

A. OTV Functional Requirements

The Orbital Transfer Vehicle (OTV) shall interface with the Space Station.

shall be controlled from the Space Station during prelaunch deployment and

postrendezvous retrieval. The OTV shall perform the following functions:

It

l , Communicate with the Space Station

a. Vehicle status

b. Payload status

c. Responses in support of deployment and retrieval operations.

2. Respond to Space Station control commands.

. Berth to the Space Station for checkout and servicing.

a. Provide diagnostics on OTV system status.

B) Key Drivers

None identified.

S.2.l.IS Customer Regional Data Centers (RDC) Requirements

A) SSIS Functional Requirements

The RDCs shall interface with the Data Distribution Network, and shall perform

the following functions:

1. Receive, process, and archive payload return data.

. Generate catalogs and indexes for archived data and provide

query/accessibility.

3. Receive requested core ancillary data and process with payload data.

181
4. Provide SSDS entry point for uplink payload data and commands.

. Provide SSDS entry point for schedule, configuration, and core

ancillary data requests.

6. Receive dispositions to customer requests.

7. Provide alternative POCC services to customers.

8. Support customer data processing at all levels.

B) Key Drivers

None Identified. Data rates to be developed in Task 4.

5.2.1.16 Individual Customer Facility

A) SSIS Functions

Customers may use the support facilities provided by the RDCs or the payload

operations center for all of their payload operations and data processing.

Customers may also have their own individual facilities. Those not connected

to an RDC must provide the RDC resources desired themselves. Those utilizing

RDC support shall interface with the RDC andshall

I. Provide SSOS entry point for payload commands and data.

. Provide delivery point for payload data (raw, pre-, or fully

processed).

. Provide SSDS entry point for schedule transactions

a. Existing schedule examination

b. Schedule requests/dispositions.

. Provide SSOS entry point for core data requests

a. Core data and processing level.

182
5. Process amd archive payload return data.

6. Generate catalogs and indexes for archived data.

B) Key Drivers

None identified.

5.2.1.18 Deep Space Network Requirements

A) SSIS Functional Requirements

The Deep Space Network shall

l . Provide communication link to OTV, when outside Space Station and

TDRSS communications zones.

e Provide backup, limited capability communications link for Space

Station.

B) Key Drivers

1. Data Rates

In the event that DSN is used as a backup communications link, the

downlink data sourced.by SS, COP and POP must be configured to meet

the capability ("85 Mbps) of this network, without causing

unacceptable impacts on other DSN-dependent space vehicles.

2. Reduced Coverage

Use of DSN will impose severe constraints on orbital coverage of

space elements, limiting communication traffic to the Space Station

to an average of (TBD).

183
5.2.1.19 Space Station Integration Facilities at Launch Site

A) SSIS Functions

The Launch Site integration facilities shall interface with the SSIS for

requirements and simulations, and shall

I. Support integration activity of payloads and SSPEs.

2. Support prelaunch checkout of payloads and SSPEs.

B) Key Drivers

None identified.

5.2.1.20 Alternative Communications Links

A) SSIS Functions

The customer may provide alternative communication links from his payload to

his ground station, either by non-TDRSS satellite link or by direct broadcast.

The SSDS shall be involved in this transmission only to the extent that

interference with other SSP communication links is precluded. No independent

customer command links are anticipated.

5.2.2 Customer Requirements for Standard Services From the SSIS.

The SSIS shall provide the following customer standard services exclusive of

SSDS:

5.2.2.1 Data Processing Beyond Level O. The SSIS shall provide or provide

for the following standard customer data processing services:

ao Payload data processing to level 1A at a negotiated cost to the

customer.

b. Support of production of level IB data.

184
C • Facilities and software routines to support routine analysis of

payload data for customers.

5.2.2.2 Data Archivin_. The SSlS shall provide, as a standard service, data

archiving beyond that necessary to ensure the satisfactory delivery of payload

data to the customer's designated facility. The SSIS shall provide the

following standard archiving services:

a. Maintain customer data archives including both level 0 and level IA

data as required.

b. Provide a data search and retrieval system for archived level 0 and

IA data.

C • Support long term archiving of level 0 and level IA data for up to

two years at a negotiated cost to the customer.

d. Provide a catalogue of archive data and support interactive customer

access to the catalogue.

e. Provide an inventory of level 0 and level 1A data available from the

archive, the characteristics of the data and sensor system, the level

of processing and quality of data, associated ancillary data, where

the data reside, and how to obtain the data.

f. Maintain a log of customer data transfer requests and their

disposition, cataloging access information for file transfer and

producing management reports on the transfer activity.

5.2.2.3 Provide Access to Space Station Programmatic Data. The SSlS shall

provide a standard customer service to assist customers in obtaining standard

programmatic data sets including

a. Space Station programmatic data, such as the master plan and customer

payload inventory control.

185
b. Space Station administrative data, such as requirements For

SSP-customer interfacing, resource utilization reports and billing

For services rendered.

C. Space Station program descriptive data, such as the customer handbook

and experiment long term planning support.

5.2.2.4 Data Exchange Among Customers. The SSIS shall provide, as a standard

service, support for data exchange among customers. This support shall be

provided at RDC's and other facilities, as appropriate.

5.2.2.5 Audio and Video Recording and Playback Between Elements. The SSIS

shall provide, as a standard service, support for the capability for video

recording and playback between any two elements of the Space Station program

which are capable of exchanging video recording information.

5.2.2.6 Long-Term Mission Planning. The SSlS shall provide standard support

service to customers to assist them in their long-term mission planning.

These services shall include

a. Trajectory and rendezvous planning service relating to the Space

Station.

b. Space Shuttle rendezvous with the SPace Station and projected Space

Shuttle manifests.

c. OMV and OTV planned launches and trajectory and rendezvous planning.

d. Platform trajectory and rendezvous planning services.

e. Trajectory and rendezvous planning services for other free-flyers.

5.2.2.7 Remote Workstations at Customer's Facility. The SSlS shall also

provide, as a standard customer service, a portable remote workstation which

may be located at the customer's home institution.

186
5.3 SSDS FUNCTIONAL REQUIREMENTS

This section presents the SSDS functional requirements, as derived from

References l, 2, and 3 and the systems analyses of Task I. The SSDS must

continue to perform many of these functions in the presence of various

faults. Specifics are given in the criticality entries of Appendix A, Section

9. The requirements are organized according to the logical, end-to-end data

flow structure of SSDS Level 0 data flow diagrams (Figure 4-3) and the

complete functions list of Appendix A, section 4.

5.3.1 Functional Requirements to Manage Customer/Operator Delivered Data

(Function l.O)

The SSDS shall provide end-to-end handling of data originating in customer

payloads and core systems. Specifically, the SSDS shall

ao Accept customer data from attached, platform, and free-flyer payloads

and deliver the data to the customer's designated location. Customer

data includes payload instrument data, engineering data, SSPE

ancillary data delivered to the payload, processor dumps, and any

other data available in or to the payload and required by the

customer.

b,

Co

de

e.

Accept core systems data and delive_ to the Space Station Control

Center, Platform Control Centers and Engineering Data Center.

Manage customer payload data.

Manage Space Station and Platform core systems data.

Provide data privacy (definition).

f.

go

Time tag customer delivered data.

Manage Space Station Program engineering archival data retrieval and

delivery to customers.

187
h. Perform data quality analysis at appropriate points throughout the

system.

5.3.1.I Additional Functional Requirement to Manage Real Time Data Return

(Function l.l). The SSDS shall provide for the capture, prioritizing,

routing, dispatch, and packetizing of real-time and near-real-time data to

customers and station operators, within the constraints of available data link

schedules. Specifically, the SSDS shall support real-time and near-real-time

data return by the following services:

a. Provide real-time, raw payload data to customer.

b. Relay level-O payload and monitor data to customers in near real time

for "quick look" monitoring.

C. Deliver core system monitor data to ground operators in real time or

near real time.

d. Provide real time core data and critical payload data to ground

operators to enable ground control of critical systems.

e. Account for real-time and near-real-time data until delivered.

5.3.1.2 Additional Functional Requirements to Manaqe Delayable Data Return

(Function 1.2). The SSDS shall provide for the capture, prioritizing,

routing, dispatch, and prompt delivery of bulk data from payload and core

systems to customers and ground operators. Specifically, the SSDS shall

a. Accumulate bulk data from all payload sources and core systems.

b. Relay all data to the ground at least once per orbit, consistent with

scheduling of available data links.

C. Account for all accumulated payload data until satisfactorily

received at the customer's designated location.

188
d. Account for all accumulated core data until satisfactorily received

at the program designated facility.

5.3.1.3 Additional Functional Requirement for Data Distribution (Function

1.3). The SSDS shall provide for general preprocessing, capture, routing and

retransmission of real time, near real time, and delayable data to the

designated end points. Specifically, the SSDS shall

a, Provide real-time distribution of real time and near-real-time data,

including level 0 processing, demultiplexing, buffering, routing, and

retransmission.

b° Provide for real-time reallocation of data distribution resources to

support customer target of opportunity operation.

c. Provide prompt distribution of delayable data.

d. Provide temporary storage for data until confirmation of receipt.

5.3.1.4 Additional Functional Requirements to Manage Customer Data (Function

1.4). The SSDS shall manage the delivery of requested data to the customer,

including data interface management, capture, handling, standard processing,

and accounting of payload and ancillary data. Specifically, the SSDS shall

a. Acquire core ancillary data, in addition to the ancillary data merged

into the customer payload data telemetry stream, including:

(1) Space Station engineering and operations data

(2) Space Station programmatic, descriptive, and

administrative data

(3) Related SSPE data

(4) Related payload data.

be Distribute data to local customers, including audio, video, and

digital data.

C. Provide routine customer Level 0 data processing, i.e., data as

output from the payload with reconstructed sensor formats, time

ordering, full resolution, and merged ancillary data.

189
d. Provide temporary customer data archives to ensure satisfactory data

delivery.

e. Provide customer data accounting until confirmation of satisfactory

receipt:

(1)

(2)

(3)

Search, access, and retrieval

Catalog and inventory Level 0 and IA data

Customer data tracking.

5.3.1.5 Additional Functional Requirements to Manage Deliverable Core Data.

The SSDS shall manage the delivery of core data, including interface

management, capture, data processing, and data display. Specifically, the

SSDS shall

a.

b.

c.

do

e.

5.3.2

Support retrieval of archived core data.

Distribute core data to SSP_ elements, including:

(1) Space Station control center

(2) Platform control centers

(3) Free-flyer control center

(4) OTV control center

(5) OMV control center

(6) Engineering data center.

Support delivery of core ancillary data to customers requesting

specific data.

Provide core data archival storage.

Process and display data for Space Station operators according to

standard, operator-selected formats.

Functional Requirements to Manage Customer/Operator Supplied Data

(Function 2.0)

The SSDS shall provide end-to-end handling of commands and data originated by

customers and operators. Specifically, the SSDS shall

19o
a.

b•

Provide command, control, and data handling for all customer payloads

on the Space Station, free-flyers or platforms.

Support remote operation of customer payloads, including real time

entry of non-restricted commands, executable restricted and

constrained commands, as processed in functions 3.2 and 3.3.

C• Support payload operation from the Space Station, ground control

centers, and customer remote facilities.

d. Support transmission, reception, and distribution of customer audio,

video, and digital data.

e.

f•

g.

Support loading of customer provided on-board computers.

Provide the capability for crew or ground to modify, and/or delete

software within the operating system consistent with operational

safeguards to prevent impact to station operations.

Permit, with proper authorization, the ground or the payload

specialists to generate or change, in a real-time mode, payload

stored, automated command sequences for future execution on board

platforms or the Space Station•

h.

i •

j °

k.

Provide distribution of commands and serial data loads to subsystems.

Log all commands and maintain a record of command disposition.

Report command and data disposition to the command source.

Verify that all tran'smitted commands, including those scheduled for

later execution, are delivered to the customer interface and

retransmit as required.

5.3.2.1 Additional Functional Requirements to Validate Payload Commands/Data

(Function 2.1). The SSDS shall provide for authorization of commands and

uplinked data flow to payloads and subsystems. Specifically, the SSOS shall

191
a. Provide a check of operator/customer identification to ensure that

commands and data are being issued by an authorized customer/operator.

b. Perform simple syntax checks on the command data header.

Co Include provisions which prevent unauthorized access to all

communication links.

do Ensure that the operator is authorized to send commands or data to

the address in the header.

e. Provide customer command and data entry accountability.

5.3.2.2 Additional Functional Requirements to Check Payload Command

Restriction/Constraint (Function 2.2). The SSOS shall check each payload

command, real time or deferred execution, to determine whether the command is

restricted or constrained. Non-restricted commands and all data shall be

passed directly to the addressed payload or to the Space Station processor

scheduling operation of that payload. Restricted and constrained commands

shall be checked against the appropriate restriction/constraint parameters, as

outlined in Section 5.3.3. If found to be allowable at their scheduled

execution time, the restricted/constrained commands will be executed as

outlined in Section 5.3.3. If commands are not executable, an unacceptibility

disposition report shall be promptly issued to the command source.

Specifically, the SSDS shall

a. Maintain a list of all customer commands indicating which are

restricted, constrained, and non-restricted.

b. Provide for identification/differentiation of restricted,

non-restricted and constrained commands and transmit or route to

scheduling as appropriate.

c. Provide disposition of commands and data status to the customer.

192
d. Pass non-restricted commands directly to the customer payload with no

further checking beyond that of the address of the payload.

e. Provide command management to protect the system from executing

inadvertent and unauthorized (and restricted) payload commands that

may affect crew safety and/or damage the station.

5.3.2.3 Additional Functional Requirements for Vehicle Core Commands/Data

(Function 2.3). The SSDS shall provide for commands and data entered by the

core system operators. Specifically, the SSDS shall

a. Verify that the operator is authorized to enter commands or data.

be Verify that the operator is authorized to command the system

addressed.

c. Check command or data header syntax.

d. Check commands for restriction or constraints.

e. Deliver non-restricted, real-time commands and data to their

destination.

f. Process restricted or constrained commands as provided in Section

5.3.3.

5.3.2.4 Additional Functional Requirements to Provide Ancillary Data

(Function 2.4). The SSDS shall make available and provide to customers a

standard package of Space Station avionics, housekeeping, and special event

data for inclusion in the payload data stream. The SSDS shall also make Space

Station ancillary data to customers upon request. Specifically, the SSDS shall

am Provide ancillary avionics and housekeeping data (timing, state

vector, RF communication, System Status, Acquisition of Signal/Loss

of Signal, moding, pointing, etc.) to attached payloads and customers.

193
b°

C •

Provide state vector data, attitude, attitude rate, and other special

purpose information to support individual customer payload functions

on the Space Station, Space Platforms, satellites, and free-flyers.

Provide ancillary data, when appropriate, to the customer's own

equipment either on the ground or onboard, and in calibrated

(engineering) units.

d. Routinely provide a time reference to an accuracy of l millisecond.

e,

f,

Provide orbit position data of a selected reference point for each

Space Station system element to an accuracy of TBD meters.

Provide attitude data for each Space Station system element to an

accuracy of TBO degrees.

5.3.2.5 Additional Functional Requirements to Support Customer System

Operation (Function 2.5). The SSDS shall provide standard support functions

to Space Station, platform and free-flyer payloads. These services shall

range from data processing to payload checkout, servicing, and operation, as

described in the ensuing sections. The SSDS shall provide general payload

support in the following areas:

a. Provide moderate accuracy pointing of rotating payload mounts, as

required for attached payloads to meet nominal pointing

requirements. (High accuracy pointing shall be funded and provided

by the customer.)

b° Support cooperative operation with co-orbiting platforms and their

attached instruments, experiments and payloads.

5.3.2.5.1 Additional Functional Requirements for Customer Data Processing

(Function 2.5.1). The end-to-end data support is primarily transparent such

that as a basic service, the delivered data has the same form and content as

that issued from the payload. However, some options will be available.

194
Specifically, the SSDS shall provide customers with options for

a. Payload data storage and processing facilities to support payload

operation. Access to the services shall be provided through standard

network interface nodes and attached work stations.

b. Monitoring payload housekeeping data.

c. A negotiated quick-look capability for level 0 data.

All customer unique software must be provided by the customer and must be

compatible with SSP programming standards. All data processing and handling

within the SSIS must be according to standard service practices.

5.3.2.5.2 Additional Functional Requirements for Customer Payload

Operation (Function 2.5.2). The SSDS shall provide general support functions

for customer payloads. Specifically, the SSDS shall

a. Provide for capability for independent customer operation and

monitoring of payloads, including ground-to-payload command and

monitor, consistent with safety and compatible with SSP operational

constraints.

b. Provide for activation of payload stored command sequences by I) time

comparison with the space element onboard clock (to a resolution of

l.O milliseconds), 2) initiation of a payload real-time command, 3)

another stored command, or 4) event-driven sequences.

C.

d.

e.

Provide health and safety monitoring of payload at customer request.

Provide, as an optional service, customer payload or process control.

Provide customer payload activation/safing services.

195
5.3.2.5.3 Additional Requirements to Support OTV Operations (Function

2.5.3). As part of the Space Station growth capability, the Orbital Transfer

Vehicle (OTV) will be a key element in the transfer of platforms and/or

free-flying payloads between the Space Station and high-energy orbits. The

SSDS functional requirements include support of OTV operations, maintenance

and servicing. Specifically the SSDS shall

a. Support the integration, checkout and launch of payloads and

satellites with OTVs prior to transfer to high energy orbits.

b. Provide for maintenance, servicing, refueling and logistical resupply

for OTVs.

Co Support deployment, launch planning, rendezvous planning, and

retrieval of OTVs.

d. Relay OTV status to OTV control and customer.

e. Support handoff of OTV eperation to OTV control center.

5.3.2.5.4 Additional Functional Requirements to Support OMV Operations

(Function 2.5.4). The Orbital Maneuvering Vehicle will be operated and based

at the Space Station and supported by the Space Station. Specifically, the

SSDS shall

a. Provide support for the OMV to checkout, maintain, and service

payloads, satellites, and platforms in low inclination, low earth

orbits.

b. Provide support for the OMV to transport co-orbiting satellites and

platforms between their orbits and the Space Station for servicing.

c. Provide for storage, maintenance, servicing, and refueling of OMV.

d. Support deployment, targeting, rendezvous, and retrieval of the OMV.

196
e. Support remote ORV operations for onsite maintenance and servicing of

satellites and platforms.

5.3.2.5.5 Additional Functional Requirements for Customer Payload Checkout

and Servicing (Function 2.5.5). The SSDS shall support all phases of customer

payload checkout and servicing. Specifically, the SSDS shall

a. Support checkout of payloads and satellites after receipt from NSTS.

b. Provide a standard servicing interface, servicing equipment and EVA

support equipment.

Co Provide for maintenance (instrument replacement, etc.), servicing

(consumables resupply, battery recharge/replacement and checkout of

remotely located payloads capable of maneuvering themselves to within

the range of OMV or OTV.

do Support the integration, checkout, and launch of payloads and

satellites with transfer stages for deployment to other orbits.

e. Provide the resources to support fault detection and isolation to

customer's payload.

f. Provide optional payload activationhafing services.

5.3.2.6 Additional Functional Requirements for SSPE Checkout and Servicing

(Function 2.6). The SSOS shall support all phases of SSPE checkout, and

servicing. Specifically, the SSOS shall

a. Support/interface with SSPEs and customer elements during assembly,

growth, and servicing.

b. Support maintenance and servicing of OMVs and platform as an initial

capability and OTVs as a growth capability including logistical

resupply.

197
C • Support on site servicing within the capabilities of the OMV and

OTV. Support servicing of the co-orbiting platform at the Space

Station.

d° Support real-time operations, trend analysis, maintenance, and

checkout of all SSPEs.

ee Support automatic servicing and performance checkout of the EMUs,

MMUs and general EVA equipment.

f ,

5.3.3

g.

Retain service data and performance trend data for use in defining

the need for maintenance of all Space Station systems and equipment.

Provide the resources and services to differentiate between payload

and SSIS faults.

Functional Requirements to Schedule and Execute Operations (Function

3.0)

The SSDS shall provide for the short term (estimated to be one to two weeks)

scheduling and executing all operations required by the Space Station

operators and all commands that are either restricted or constrained and

entered by payload operators. The SSDS schedules shall be based on the master

plan maintained by the SSDS with inputs from the Space Station Program and

transmitted through the TMIS. Disposition of all commands entered will be

shown to the operator or customer entering the command.

5.3.3.1 Functional Requirements to Develop Recurring Operations Masters

(Function 3.1). The SSDS shall support customer and operator interactive

development of normal day and major event operations masters. Both shall be

used as baselines for developing the short term operating schedule for the

Space Station program elements.

The SSOS shall support the development of recurring operations masters by

a. Supporting interactive payload planning and scheduling.

198
b.

C .

Integrating customer payload operating requests with Space Station

resource availability.

Supporting customer requests for non-SSlS resources.

d. Providing projected data on Space Station resources

e. Interactively developing payload and Space Station operations

schedules.

5.3.3.2 Functional Requirements to Develop Short Term Schedules (Function

3.2). The SSDS shall support the interactive development of short term Space

Station schedules by Space Station system operators and customers.

Specifically, the SSOS shall

a. Allow near-term planning entries by the onboard crew.

bB Coordinate communications allocations for all SSPEs with the network

control center. Resolve all SSP requirements conflicts. Provide

type of service, data rates, desired times, and allocations to SSPEs.

C • Support interactive planning by payload and core system operators,

including significant orbital parameters, such as time, orbital

position, and object ephemerides, which may influence payload and

Space Station operations scheduling.

d. Provide indications of Space Station and Platform resource

capabilities and availability to support payload output optimization.

e. Optimize utilization of Space Station and Payload resources and

maximization of payload output.

f. Support rapid replanning to allow customers to take advantage of

payload opportunities.

go Support clearing of restricted and constrained payload commands to

assist in real-time payload operation.
h. Support customer requests for non-SSIS resources.

i •

j •

Develop integrated Space Station Program operations schedules.

Provide accounting of the disposition of restricted and constrained

commands.

k• Schedule use of Space Station resources by other SSPE's (e.g.,

platform, Space Station communications, crew time, etc.) and resolve

conflicting requests•

l • Support interactive schedule development with appropriate data

processing, input/output, and displays•

5.3.3.3 Functional Requirements to Develop Operating Event Schedule (Function

3.3). The SSDS shall prepare an operating event schedule containing the time

sequenced operating events in the short term schedule, together with the

commands necessary to initiate these operations. Specifically, the SSOS shall

ao Check restricted commands and constrained commands for execution

within the existing short term schedule.

b• Deliver immediately or incorporate into the operating event schedule,

as appropriate, those restricted and constrained payload and core

commands which are executable.

Co

do

Alert the customer and operator to those restricted and constrained

payload commands which are not executable in the current short terms

schedule. Transfer these commands to Function 3.2 for disposition.

Support real-time reallocation of data distribution resources to help

meet customer priorities. Coordinate communications requirements

with Network Control.

eo Store customer payload commands for execution according to a

schedule, sequence of events, or another stored command.

2O0
f ° Provide accounting of commands incorporated into the operating event

schedule.

5.3.3.4 Additional Functional Requirements to Sequence Operations (Function

3.4). The SSDS shall provide for the execution of the scheduled operations.

Specifically, the SSDS shall

a. Activate stored payload command sequences based on time, sequence of

events, or other stored command prompts.

b. Provide for the execution of core commands according to locally

stored command sequences.

c. Provide accounting of commands issued.

5.3.4 Functional Requirements to Operate Core Systems (Function 4.0)

Core system include both the space and ground elements that are necessary to

operate the Space Station, Platforms and their associated control and data

handling program elements.

5.3.4.1 Functional Requirements to Operate GN&C Systems (Function 4.1). The

SSDS shall provide the capability to operate the Space Station and Platform

GN&C systems. The SSDS shall also support the control of proximity operations

with other vehicles.

."

5.3.4.1.I Functional Requirements for Navigation (Function 4.1.1). The

SSDS shall perform navigation functions including:

a.

b.

Calculation of the Space Station and Platform navigation state vector.

Calculation of navigation state vectors for Space Station program

elements. (Space Station only)

C. Incorporation of navigation state vector information from second

sources.

201
d. Developing approach and departure trajectories for SSPEs. (Space

Station only)

e. Delivery of navigation attitude and attitude rate information to

customers.

f. Delivery of navigation information to payloads, including position to

an accuracy of TBD meters.

g. Delivery of empherides data to assist in pointing of payloads,

pointing mounts, and Space Station and platform appendages (solar

arrays, radiators, antennas, etc.).

h. Determination of Space Station and Platform attitudes.

i • Providing the attitude to customers and payloads to an accuracy of

TBD degrees.

Providing an appropriate time tagging for all navigations state data

to an accuracy of TBD msec.

k. Propagating the Spacecraft navigation state vector to specific states.

I . Propagating constellation navigation state vectors to specific

states. (Space Station only)

mo Maintaining Space Station, Platform and constellation drag and

gravity models.

Be Initiation of scheduling attitude and translation manuevers. (Note:

these may also be operator initiated.)

5.3.4.1.2 Functional Requirements for Guidance (Function 4.1.2). The SSDS

shall provide or support the guidance and orbit control of the Space Station

and constellation elements. Specifically, the SSDS shall

a. Provide guidance for SSPE traffic control.

202
b• Provide guidance for approach and departure for SSPEs.

c. Support SSPEplanned operations.

d. Coordinate reboost maneuversamongpayloads and SSPEs.

e. Manage Space Station and Platform reboost, translation and attitude

maneuvers.

f.

g.

Plan orbital maneuvers to avoid collisions with orbital SSPEs and

debris.

Provide orbital re-entry targeting for disposal of SSPEs.

h•

i •

Provide Space Station and tether control when in tethered operations.

Totally or selectively inhibit RCS operation during periods of EVA

and sensitive payload operations.

j . Command gimbal position and rate for Spacecraft controlled pointing

mounts, radiations, solar arrays and communications antennas.

5.3.4.1.3 Functional Requirements for Attitude Control (Function 4.1.3).

The_SSDS shall support attitude control for the Space Station and selected

SSPEs. Specifically, the SSDS shall

a. Establish and command the maintaining of the Spacecraft attitude.

b•

C •

Establish and maintain SSPE relative attitudes.

Provide planning informaion for SSPE operations•

d. Provide active Spacecraft momentum management.

e. Coordinate attitude maneuvers with SSPEs and payloads.

f . Provide dynamic stabilization between flexible body modes and

attitude control•

2o3
5.3.4.1.4 Functional Requirements for Traffic Control (Function 4.1.4).

The SSDS shall support local traffic control in the vicinity of the Space

Station. Specifically, the Space Station SSDS shall:

a. Establish and maintain SSPE relative state vectors.

b. Accept second source relative state vector information.

c. Propagate constellation relative state vectors.

d. Monitor SSPE approach and departure trajectories.

eo

f .

Warn operators of unsafe traffic conditions.

Support development of collision avoidance commands.

g. Execute collision avoidance maneuvers.

h. Support berthing, docking, and separation operations.

i. Control OMV operations within the constellation.

j. Control OTV operations within the constellation.

k. Schedule rendezvous with satellites and free-flyers.

° Control satellite and free-flyer maneuvers during proximity

operations, via OMV or direct Space Station control of free flyer.

m. Provide powered guidance support to satellites and free-flyers.

5.3.4.1.5 Functional Requirements for Tracking (Function 4.1.5). The SSDS

shall support tracking of objects in the vicinity of the Space Station and

platforms. Specifically, the SSDS shall

a. Provide tracking and acquisition for detached vehicles.

204
b. Track all objects near or approaching the Space Station and platforms.

C . Provide target identification/discrimination and maintain accounting

for all objects in the tracking zone based on propagated state

vectors and tracking data. Use state vectors to account for objects

not resolved because of proximity or obscuration.

5.3.4.1.6 Functional Requirements for Time and Frequency Management

(Function 4.1.6). The SSOS shall support the maintenance of time and

frequency standards for Space Station and payloads. Specifically, the SSDS

shall

a. Provide a time reference to an accuracy of at least l millisecond.

b. Provide a frequency reference to at least TBO.

C • Support the generation of a'more accurate time reference for payloads

which require greater time accuracy.

5.3.4.2 Functional Requirements to Operate Non-GN&C Core Systems (Function

4.2). The SSDS shall support the operation of non-GN&C core systems. The

support shall include system command and control, data handling, resource

distribution and control, and monitoring and fault isolation of orbital

replaceable units.

5.3.4.2.1 Functional Requirements to Operate Power System (Function

4.2.1). The SSDS shall support the operation of the Space Station and

platform power systems. Specifically, the SSDS shall support

a. Automatic reconfiguration of electrical resources, loads and busses

to optimize the collection of energy and to distribute electrical

power to payloads and core systems according to the scheduled demands.

b. Automatic shedding of loads to control power consumption during

periods of lower than planned energy, including various system faults.

c. Notification to operators of abnormal power conditions.

205
d. Reduction or shedding of power to payloads exceeding prescribed

]imits.

e. Evaluation of array and projection of energy available.

f. Array deployment and retraction.

g. Maintain power to critical systems during all system faults and

emergencies. (Note: this requirement may be met autonomously by the

power system.)

5.3.4.2.2 Functional Requirements to Operate Thermal Control System

(Functions 4.2.2). The SSDS shall support operation of the thermal control

system. Specifically, the SSDS shall support

a. Control of temperatures in electronic equipment and habitable units

of the Space Station.

b. Management of customer payload thermal loads.

c. Management of Spacecraft thermal loads.

d. Monitoring and protection of payload thermal interfaces.

5.3.4.2.3 Functional Requi_aments for Structures and Mechanisms Support

(Function 4.2.3). The SSDS shall provide support for structures and mechanism

monitoring on the Space Station. Specifically, the SSOS shall support:

a. Berthing, docking and separation operations for OMV, OTV, NSTS,

platforms, MMU, and Free flyers.

b. OMV berthing.

c. OTV berthing.

d. MRMS operations for construction, berthing and EVA.

2o6
e. Mechanism control.

5.3.4.2.4 Functional Requirements for ECLSS Operation (Function 4.2.4).

The SSDS shall support the operation of the environmental and life support

systems on the Space Station. Specifically, the SSDS shall support

a. The monitoring and regulation of the atmospheric composition in

habitable modules.

b. The control of temperature and humidity in habitable modules.

c. The management of potable and grey water quality.

d. The detection and control of contaminates and toxic fluids.

e° The detection of emergency conditions, such as fire, unsafe

environment, excessive pressure shell leakage, and critical equipment

failures.

5.3.4.2.5 Functional Requirements for Communication (Function 4.2.5). The

SSDS shall support communications between the Space Station and ground

elements, between the Space station and constellation elements, between the

platforms and ground elements and within the Space Station both inside the

vehicle and during EVA. Specifically, the SSDS shall provide or support

a. Near continuous ground to Space Station communication by voice and

video, and data for real-time monitor and control.

b. Cooperative operations with constellation elements and payloads.

Co Intrastation and extrastation person to person audio and video

communication.

d. Support of remote operations by manipulators and OMV.

e. Private crew communications between the Space Station and the ground.

f. Control of OTV and OMV operations.

_7
g. Control of free-flyers and satellites during proximity operations,

via OMV or direct Space Station control of free flyer.

h. Control of space platforms and platform payloads.

i ° Payload data return from platforms, free-flyers, and other satellites

in the constellation.

j. Management of communication links and antennas.

k. Coordination and sequencing of transmissions.

In addition to support of payload data return, the SSDS shall not preclude

independent customer communication for return through satellite links other

than TDRS or direct broadcast to the ground. The Space Station shall

communicate primarily through the TDRSS satellite system. The communications

systems shall also provide a contingency link between the Space Station and

the ground. The SSDS shall provide privacy of all communications to and from

Space Station and SSPEs.

5.3.4.3 Functional Requirements to Support Flight Crew Activities (Function

4.3). The SSDS shall support the normal operations of the Space Station crew,

including such activities as health maintenance, recreation, operation of

Space Station equipment servicing and maintenance of Space Station and payload

equipment, and servicing and maintenance of satellites and SSPEs.

5.3.4.3.1 Functional Requirements for Health Maintenance (Function

4.3.1). The SSDS shall support the operation of the Space Station health

maintenance facilities. Specifically, the SSDS shall support

a. The maintenance of crew medical data base and health records.

b. The downlink of diagnostics for crew health maintenance.

c. The physiological monitoring and analysis of crew physiological data.

d. Support of medical diagnostics for the crew.

208
e. The analysis of crew nutrition requirements.

f . Planning of crew exercise programs to accommodate varying levels of

strenuous crew activities in operating the Space Station and payloads.

5.3.4.3.2 Functional Requirements for Space Station Safety (Function

4.3.2). The SSDS shall support the maintenance of safe conditions on board

the Space Station. Specifically, the SSDS shall

a.

b.

Co

Provide for independent detection and control of emergency conditions.

Notify operators of the failing of critical systems.

Provide for detection and suppression of fires.

de Detect and correct unsafe buildup of toxic or undesirable elements in

the Space Station atmosphere.

e. Provide alarm to warn SPace Station crewmen of the buildup of toxic

elements in the Space Station atmosphere.

f , Monitor all Space Station payloads, systems and coorbiting spacecraft

status data. The SSDS shall analyze the status data and determine

unsafe and out of tolerance conditions. The SSDS shall identify

failed equipment and automatically execute reconfiguration. The

caution and warning system shall provide alarms and warnings to the

Space Station crew and present appropriate diagnostic displays.

5.3.4.3.3 Functional Requirements to Support Habitability (Function

4.3.3). The SSDS shall support the habitability of the Space Station by

providing commercial video and audio-visual entertainment. The SSDS shall

also support private crew/ground audio communications.

5.3.4.3.4 Functional Requirements for EVA Support (Function 4.3.4).

SSDS shall support the safe EVA activities of the Space Station crew by:

a. Inhibiting RCS firings during EVA activities.

The

209
b. Controlling manipulator arm movement during EVA activity to avoid

hazzards to the EVA crew.

c. Providing O&M procedure support to crewmen during EVA.

d. Providing support for automatic and semiautomatic servicing and

checkout of MMU and EMU equipment.

e. Supporting airlock control.

f. Supporting EVA monitoring and control.

5.3.4.3.5 Functional Requirements for Operations and Procedure Support

(Function 4.3.5). The SSDS shall provide operations and procedure support to

the Space Station crew and ground crews in Space Station facilities.

Specifically, the SSDS shall provide:

a.

b.

Onboard training of crewmen in critical and emergency operations.

Onboard training of crewmen in various maintenance and operating

procedures for core and payload systems.

c. Maintenance and troubleshooting procedures support.

d. Critical or contingency procedures support.

e. Documentation of IVA and EVA operations data.

f. Maintenance information recording and retrieval.

5.3.4.4 F_unctional Requirements to Provide Customer Avionics Services

(Function 4.4). The SSDS shall provide avionics data to meet specific

customer needs. The support shall include the recording of anomalous events

taking place aboard the Space Station and platforms which may affect the

operation or the quality of the data collected by Space Station payloads.

These reports shall automatically be available to customers whose payloads or

payload data may be affected.

210
5.3.4.4.1 Functional Requirements for Special GN&C Services (Function

4.4.1). The SSDS shall provide special GN&C support services for customer

payloads, including:

a. Pointing coordinates for articulating mounts and payloads.

b. Relative alignment attitude references to payloads.

c. Ground track determination and forecast to payloads and customers.

d. Magnetic field and field forecasts to payloads and customers.

e. Provide range, range rate and attitude of platforms and free fliers

relative to space station.

5.3.4.4.2 Functional Requirements for Contamination Control (Function

4.4.2). The SSDS shall monitor the contamination environment in and about the

Space Station or platform and provide contamination data to customers who

payloads or payload data may be affected by contamination events.

Specifically, the SSDS shall

a. Monitor internal and external contamination sensors and other induced

environment sensors including electromagnetic vibration, acoustics,

shock, linear acceleration, temperature, reduced atmosphere,

contamination, and radiation.

b. Determine the potential effects of venting, RCS and other burns, and

water dumps on external payloads.

C. Monitor the external environment including return flux, number column

density of IR and other molecules, and discernable particles in the

field of view of optical instruments.

d. Determine the potential effects of venting, burns, and water dumps by

any object in the constellation on all objects in the constellation.

em Determine the effects of performing EVA activities on all objects in

the constellation.

211
5.3.4.4.3 Functional Requirements for Tracking Services (Function 4.4.3).

The SSDS shall provide customers and their payloads basic data on the relative

range and range rate to SSPEs of interest to the customers.

5.3.4.5 Function Requirements to Monitor and Status System (Function 4.5).

The SSDS shall provide general monitoring and status of both core and customer

systems.

5.3.4.5.I Functional Requirements to Monitor Core System Status (Function

4.5.1). The SSDS shall provide general capability to monitor the status of

core systems, including:

a. Monitoring of orbital replaceable units, notifying crew of failed

units and supporting fault isolation and repair. (Space Station only)

b. Monitoring and control of fluids and fluids status.

Co Monitoring of Space Station, platform and ground station system

performance.

5.3.4.5.2 Functional Requirements to Monitor Customer System Status

(Function 4.5.2). The SSDS shall provide general customer system monitoring

support, including

a. Monitoring of fluids status.

b. Monitoring of payload status indicators such as voltage and current.

C • Monitoring of customer and customer support ground systems such as

data links, data processing equipment and data storage equipment.

5.3.4.5.3 Functional Requirements for Mass Properties Configuration

Updates (Function 4.5.4). The SSDS shall provide up-to-date data on mass

properties and related configuration information for the Space Station. Data

to be provided includes:

212 "
a.

b.

C.

d.

e.

Mass

Moments of inertia

Area and area distribution

Location of payloads

Location of other key equipment.

5.3.4.S.4 Functional Requirements for Diagnostic Support (Function

4.5.5_. The SSOS shall provide general diagnostic support for the Space

Station operators. Support categories include

a° Schematic presentations showing key status and performance data of

various Space Station equipment.

be Expert system analysis to support the operation and control of the

Space Station.

C° Trend analysis to indicate _he probable performance of various Space

Station systems and potential for failures or less than satisfactory

performance.

5.3.4.5.5 Functional Requirements for System Test and Evaluation (Function

4.5.6l. The SSOS shall support the test and evaluation of both payload and

Space Station systems. This support shall include both prelaunch and on-orbit

procedures. Payload test data shall be delivered to the customer. System

test data shall be delivered to the Space Station operators and to the

affected contractors. Operators shall be supported by procedures and by

indications of satisfactory system performance.

5.3.5 Functional Requirements to Manage Facilities and Resources (Function

5.0)

The SSOS shall provide for the management of facilities identified as being in

the SSDS. This management shall include the protection of proprietary

information, the management and distribution of data bases, the support of

access to subsystems status, and the management of facility data processing

equipment.

213
5.3.5.I Functional Requirements to Manage Flight System Facilities (Function

5.1). The SSDS shall provide the facilities necessary to manage the flight

system data base,-manage the flight system data processing equipment, and

prepare displays and controls for operator interfacing. Specifically, the

SSDS shall provide for

a. Command and control and data handling from all habitable Space

Station modules.

b. Management and delivery of core data files to appropriate data

processors and to operators.

c. Monitor and control data processing equipment.

d. Management of facilities supporting payload data processing.

e. Rate buffering for customer delivered data.

f. Support of fault detection and isolation for data processing

equipment.

g. Reconfiguration of data processing equipment to meet changing demands

and to recover from equipment failures.

h.

i .

Monitoring and protecting of data system interfaces.

°"

Measurement and control of available data resources•

j • Monitoring of payload consumption of critical Space Station resources

and issuance of reconfiguration or disconnect commands to the core

subsystems.

k. Support for onboard separation of customer stored command sequences.

I. Storage of customer command sequences•

214
5.3.5.2 Functional Requirements to Manage Ground System Facilities (Function

5.2). The SSDS shall provide for the management of the Space Station Program

Ground SYstem facilities, including SSDS data base management, Ground System

schedule managment, management of displays and controls for ground operators,

and global facilities management coordination for all SSDS data processing

facilities. Specifically, the SSDS shall provide for

a. SSDS data base file management and delivery.

b. Status inset end-to-end communications system.

c. Status at ground data processing equipment.

d. Reconfiguration of ground system data processing equipment to meet

changing demands or to recover from equipment failure.

e. Monitoring and protection of ground data system interfaces.

f. Customer systems statusing.

go Real-time reallocation of data distribution resources to meet

real-time changes in customer requirements.

h. Support uplink of developed software for both customer systems and

core systems, including customer stored command sequences. (Note:

Customer command sequences may also originate from the customer's

facility and be transmitted as payload data or may be originated by

an onboard mission specialist.)

5.3.6 Functional Requirements to Develop, Sims!ate, Integrate, and Train

(Function 6.0)

The SSDS shall provide a robust environment for development and integration of

hardware and software and the training of crew, operators, and customers. Not

the least of this environment will be simulations of sufficient fidelity to

215
support verification of l) physical and logical interfaces, 2) software

performance, and 3) end-to-end data transfer. The SSDS shall

a. Provide the capability to ensure that all modifications and upgrades

function properly and are compatible with interfacing hardware and

software components.

b. Provide to the customer those common tools necessary to permit

adequate verification and validation of customer hardware and

software with the standardized SSDS interfaces. All tools necessary

for payload performance verification, over and above interface

verification, will be the responsibility of the customer.

5.3.6.1 Additional Functional Requirements To Interpret Model Requests

(Function 6.1). The SSDS will provide a configurable integration system of

sufficient breadth to support all standard customer, crew, and contractor

requirements. A primary task of the system mechanization will be the

processing of system requests to determine and issue the reconfiguration

requirements to the overall hardware and software elements of the system.

system will operate interactively with the using agency to support these

requests. Specifically, the SSDS shall

The

a. Provide user-friendly remote access using menu-driven prompts to set

up the simulation for use by the customer.

b. Provide a choice of subsystem models ranging from static models to

highly dynamic models subject to customer provided boundary

conditions. Models of SSIS subsystems, ancillary data blocks, and

operational constraints are some of the required models.

C. Accept characteristics of equipment and/or software to be supplied by

the user.

d. Display resource availability.

e. Display current system interconnection.

f. Display system schedules.

216
5.3.6.2 Additional Functional Requirements To Develop Communication Model

Configuration (Function 6.2). The integration system communication links to

the operational system will operate in conjunction with a configurable

communications element simulator. Specifically, the SSOS shall support

integration testing to:

a. Verify customer payload to communication system interfaces.

bo Provide for external interfaces to verify end-to-end customer data

throughput. The data shall be verified from the payload through

delivery as a completed data set. The customer shall provide the

source of the payload data.

C. Select system simulations to be used, including data entry and

reception models.

5.3.6.3 Additional Functional Requirements To Simulate Space Station

Communication Elements (Function 6.3). The communications simulation shall

include communication links to the operational system. Specifically the SSDS

shall

a. Provide for maximum use of flight system capability to reduce the

requirements for ground support equipment and other support during

ground testing.

be Accept payload test data from the Space Station or the customer

payload in the simulator and deliver to the customer for verification

of communication links.

Co Accept payload commands from the customer and deliver to the Space

Station payload in the simulator for verification of command link.

d. Provide the interfaces to allow a verification of (segmented as

necessary) end-to-end customer data throughput.

e. Configure the communications simulation.

217
f. Perform simulations of communications system elements.

g. Interface with other simulations, as required to incorporate

communications interfaces and simulations.

5.3.6.4 Additional Functional Requirements To Develop Hardware Integration

Configuration. (Function 6.4). This funtion derives and issues the hardware

simulation configuration requirements. The SSDS shall

a. Select a standard data interface for payload or contractor hardware

connection.

b. Select simulation models of the SSDS interaction with the hardware to

verify hardware functions.

5.3.6.5 Additional Functional Requirements To Simulate Space Station Elements

(Function 6.5). The SSDS shall prov'ide the resources to support customer and

contractor hardware integration. Specifically, the SSDS shall

a. Provide standard data interfaces for mounting customer payloads and

contractor hardware at the simulator.

b.

Co

do

e.

Provide for remote hardware data interfaces at the customer or

contractor facility.

Provide the facilities and resources to support' Space Station

equipment verification testing to ensure that all elements and

payloads are launch ready.

Accept test data from the customer payload and return to the customer

for verification.

Support verification and compatibility testing of standard ancillary

data formats and information content.

f. Provide simulation functions to enable the validation of operational

procedures and software to the limits of expected flight constraints.

218
g. Support software development for the customer testing and execution

of customer analysis programs.

h. Develop simulation models and deliver to contractor to support Space

Station hardware integration at the contractor's facility.

i . Develop simulating models and deliver to customer to support payload

integration at the customer's facility.

j. Verify that interfacing hardware meets data interface standards.

5.3.6.6 Additional Functional Requirements To Develop Software Inteqration

Configuration (Function 6.6). The SSDS shall provide the facilities and

resources to support customer and contractor software integration.

Specifically, the SSDS shall

a. Provide a remotely accessible, real-time simulation of SSIS software

services to the extent necessary to verify the SSIS to Payload

software interfaces at the customer's facility.

b. Provide user-friendly remote access using menu-driven prompts to set

up software integration simulations for use by the customer.

C . Provide simulation functions to enable the validation of operational

procedures and software to the limits of expected flight constraints.

5.3.6.7 Additional Functional Requirements To Simulate Space Station

Processors (Function 6.7). The SSDS shall provide Space Station software

simulation and processor emulation in support of software development,

integration, and performance simulations. Specifically, the SSDS shall

a. Support the capability for customer payload specialists to develop

and verify payload stored command sequences for future execution

onboard the platforms or the Space Station, especially those

requiring core system interaction.

219
b° Provide a remotely accessible real-time simulation of SSIS software

services to the extent necessary to verify the following

SSIS-to-payload software interfaces at the customer's Facility:

l) Protocols at all software layers

2) Full breadth of customer command capability

3) Standard ancillary data formats and information content

4) SSIS/DBMS interaction with flight and ground customer

application software.

Co

de

Configure system data processing simulations.

l

Simulate command and data management.

e. Simulate system operation.

f. Verify that software packages meet interface standards.

5.3.6.8 Additional Functional Requirements to Conduct Traininq Exercise

(Function 6.8). The SSDS shall interpret training requests and provide the

appropriate training operation configuration_ Specifically, the SSDS shall

aJ Provide capability to receive new or revised training material

transmitted from the ground.

be Provide preflight training on systems management, trajectory and

navigation support, activity planning, logistics, communications,

emergencies, proximity and manipulator operations, and the onboard

training system. Extensive preflight training will be limited to

critical systems functions with an emphasis on part-task training.

Co Configure on-orbit training to support crew special and emergency

operations.

22o
d. Configure ground based training to support all aspects of crew

training.

e. Select procedures, simulations, and interfaces to be used.

f.

g.

ho

Provide on-board accessible training capabilities to maintain

critical crew skills, to maintain crew quick reaction capability for

emergency procedures and contingencies, and to support in-flight

operation and maintenance tasks, both IVA and EVA, for payloads and

core system operation.

Provide preflight training which is limited to critical system

functions with emphasis on part-task training.

Optimize crew interfaces and establish training commonality,

providing common trainingsoftware packages and video tapes for

ground training facilities and on-board training utilizing Station

training capability, using new or revised training lessons

transmitted from the ground.

i. Provide CCTV for crew training.

j .

k.

l ,

mo

Provide mission and payload independent customer training facilities

necessary to adequately train the customers in operation of the SSIS.

Provide high fidelity simulation of payload work stations.

Provide for training in the integrated operation of multiple payloads.

Configure training simulations.

n. Simulate system operation.

221
5.3.6.9 Additional Functional Requirements to Develop Software (Function

6.9. The development function shall include services to assist both

contractors and customers in software development. The software support

environment shall primarily support contractor applications software

development and integration. The SSDS shall also support the development of

software for customer payloads and for use in the simulator. The SSDS shall

a. Provide software programming language support.

b. Maintain a library of standard routines for use by customers,

contractors, and simulation software developers.

C° Provide simulation functions to validate customer and contractor

software.

d. Support onboard or customer facility generation of customer stored

command sequences.

e° Support onboard software development for modification by the Space

Station crew.

5.3.7 Functional Requirements to Support Space Station Program (Function

7.0).

The SSOS shall interface with the SSIS and TMIS to provide SSP programmatic

support.

5.3.7.1 Functional Requirements to Maintain Integrated Logistics Plan

(Function 7.1). The SSDS shall monitor payload and core systems consumables,

repair parts and spare parts. The logistics planning shall develop

requirements for timely resupply. Logistics support requirements shall be

delivered to TMIS for incorporation into the SSP plans.

5.3.7.2 Functional Requirements to Loq Customer Usage of the System (Function

!.2). The SSOS shall be responsible for logging all customer usage of SSIS

services. Reports shall be presented to the customers, and chargeable service

data shall be delivered to the TMIS.

222
5.3.7.3 Functional Requirements to Maintain Technical Documents (Function

7.3). The SSDS shall be responsible for maintaining Space Station, SSOS

facilities, and payload operations and maintenance manuals. Satellite service

procedures shall be supplied by the SSP, with updates based on servicing

experience supplied through the SSDS. Manuals required onboard shall be

available to customer guest operators and crew via CRT display.

5.3.7.4 Functional Requirements to Control Inventories (Function 7.4). The

SSOS shall be responsible to status inventories of materials, repair parts and

spares for SSDS facilities, the Space Station, and payloads. The primary

responsibility for inventory control will rest with the SSP. Inventory status

will be communicated through the TMIS.

5.3.7.5 Functional Requirements for Configuration Management (Function 7.5).

The SSOS shall be responsible for monitoring the mass properties data required

to perform avionics calculations. Basic data are provided through the TMIS.

The SSOS will keep the mass properti'es data base current, including effects of

docked vehicles and tethers.

5.3.8 General Design Requirements

5.3.8.1 SSDS Operational Lifetime. (RFP C-4-2.1.4.1) The SSDS shall have the

ability to remain operational indefinitely through periodic inspection,

maintenance, and replacement of components. Servicing intervals for the

platforms shall be as specified in paragraph 3.4 of attachment C-3.

5.3.8.2 SSDS Modular design commonality growth. (RFP C-4-2.1.5} The SSDS

shall be designed to facilitate system growth through use of modular and

subsystem design. The SSDS shall employ common hardware, software, and

standard interfaces which optimize benefit to the SSP.

The SSIS/SCS shall be designed to be modularly expandable/replaceable. It

shall permit customer and system technology upgrades, capability upgrades, and

function migration between ground and space. (CRSS-I.I.6)

223
5.3.8.3 SSOS Technoloqy accommodations. (RFP C-4-2.1.6) The SSDs shall be

designed to accommodate the incorporation of new technology as appropriate to

optimize benefits to the program.

Technology accommodation. The SSDS shall accommodate new technology without

requiring major redesign or reevaluation or disruption of services of the

system to the extent practical. (RFP C-4-2.5.1.c)

5.3.8.4 SSOS Autonomy/Automation (RFP C-4-2.1.7,2.1.8) A phase degree of

on-orbit autonomy shall be provided consistent with evolving systems and

operations requirements, cost, and applicable evolving technologies. Platform

design shall facilitate autonomous operations between scheduled servicing

period but shall not preclude ground intervention.

A phased progressive automation of both flight and ground elements shall be

accommodated consistent with evolving system requirements, cost, applicable

technologies, and the NASA Automation and Robotics Plan (to be supplied at

CSD, April 1985).

5.3.8.5 SSDS Maintainability.

shall be designed:

(RFP C-4-2.1.9) SSDS hardware and software

To facilitate on-orbit and ground maintenance, inspection, and repair with

maintenance performed on-orbit to the Orbital Replaceable unit (ORU) level.

(RFP C-4-2.1.9.a)

Such that all reasonable failures or damage is restorable or repairable.

(RFP 4-2-I.9.b)

To be capable of undergoing maintenance without the interruption of critical

services and with minimum interference with other SSOS operations.

(RFP C-4-2.1.9.d)

Such that preventive and corrective maintenance activities for the Space

Station system minimize the use of available crew time. (RFP C-4-2.1.9.h)

224
5.3.8.6 SSDS Reliability. (RFP C-4-2.1.10) Reliability programmatic

requirement shall be as specified in SSP J8400001, "Product Assurance

Requirements for the Space Station Program." Reliability design requirements

for the SSP are as follows:

Failure tolerance. (RFP C-4-2.1.10.1) Safety critical and mission critical

subsystems are those whose function, if lost, would produce a condition

endangering on-board personnel or prevent the accomplishment of a critical

mission objective. Safety and mission-critical subsystems shall be designed

to be fail-operational/fail-safe/restorable, as a minimum (except primary

structure and pressure vessels in rupture mode and premature firing of

pyrotechnics). This criteria applies during all operational phases except

initial assembly and maintenance. For applicable subsystems, some degraded

performance following the first failure is not precluded by the

fail-operational/fail-safe requirement. During assembly and maintenance,

critical SSDS subsystems shall be fail-safe as a minimum. Other SSDS

subsystems and ground support hardware shall be designed to be

fail-safe/restorable. Subsystems in pressurized modules shall be able to

return to normal operation after the module has lost pressure on-orbit and

been repressurized.

Redundancy (RFP C-4-2.1.I0.2) Redundancy verification. Redundant functional

paths of subsystems shall be designed to permit verification of their

operational status in flight without removal of ORUs. (RFP C-4-2.1.I0.2.a)

Failure propagation. (RFP C-4-2-I.I0.3) Subsystem design shall be such that

one failure does not cause additional failures.

Separation of redundant paths. (RFP C-4-2.1.I0.4) Alternate or redundant

functional paths shall be separated or protected such that any event which

causes the loss of one functional path will not result in the loss of the

alternate or redundant functional path(s).

5.3.8.7 SSDS Safety. (RFP C-4-2.1.11) The safety programmatic requirements

shall be as specified in "Product Assurance Requirements for the Space Station

Program", J4800001. The SSDS and ground systems shall meet the safety design

requirements specified herein.

_5
The following safety requirements are applicable to all SSPsystems,

subsystems, and operations. Theserequirements apply under worst-case natural

and induced environments.

Override capability. The crew must be able to override any automated safing

or switchover capability of functional paths. All overrides shall be two-step

operations with positive feedback to the initiator that reports the impending

results of the override commandprior to the acceptance of an execute

command. Separable functional paths shall be used to prevent single failures

from causing both an unintended auto switchover and the inability to override

it. (RFP C-4-2.1.11.4.a)

Command/control redundancy. Redundant accommodations for complete command and

control of the Space Station shall be provided in separate pressurized

volumes. Functions to reestablish pressure in a module shall be operable by

pressure-suited crewmembers. (RFP C-4-2.1.11.4.b)

5;3.8.8 SSDS Privacy/Security Information privacy. The SSDS shall provide

data partitioning and protection to assure mission success and accommodate

data privacy, commercial proprietary data, and security measures.

(RFP C-4-2.2.2.5.I.b)

The SSDS design shall provide for crew members to communicate privately with

the ground. This private communication link shall include both audio and

video data. (RFP C-4-2.2.6.2.j)

The SSlS/SCS shall permit the customer to perform private operations covering

commanding, data transmission, and in Site hands-on operations. (CRSS-I.I.7)

5.3.8.9 SSOS Standards Standardized language, protocol, format, and

transmission rates for all SSDS and all SSOS subsystems. (RFP C-4-2.2.5.3.g)

As a first preference, customer interface standards shall be defined in

accordance with the International Standards Organization (ISO) seven layer

model for Open System Interconnect (OSI). (CRSS02.1.1)

226
The SSIS/SCS shall use, for each of the seven layers, existing internationally

accepted standards as first priority followed by new standards development

(within the OSI model framework). (CRSS-2.1.1.1)

The customer interfaces defined within the first three layers of the OSI model

shall conform to standards defined and controlled by sources such as:

NBS, National Bureau of Standards

ANSI, American National Standards Institute

ECMA, European Computer Manufacturing Association

CClUTT, Consultative Committee for International Telegraph and Telephone

EIA, Electronic Industry Association

CCSOS, Consultive Committee for Space Data Systems

IEEE, Institute of Electrical Electronics Engineers

(CRSS-2.1.1)

When practical, appropriate standards from these sources shall be used at

higher layers of the OSl model. (CRSS-2.1.2.1)

The SSIS/SCS shall obtain and/or develop standards for customer interfaces in

candidate areas such as software, critical/limited payload health and safety

monitoring, man-machine interfaces, uniform system control and operational

language for Payload test/checkout and operations, command generation, time

code, attitude and position data, pointing coordinate systems, data base

management systems, graphics displays, data handling/archiving/distribution,

documentation, configuration control, cost accounting, data system

requirements definition, operation audit trail, etc. When new customer

standards are proposed, the SSlS/SCS shall present these standards on behalf

of all customers. (CRSS-2.2.1)

227
5.3.8.10 SSDS Customer/Operations Support The SSDS shall support a

user-friendly language for the man/machine interface. The language shall be

capable of interfacing between man and machine for communications, display

generation, monitoring, checkout and control during all phases of development

and operations. (RFP C-4-2.2.5.2.c)

The SSIS/SCS shall be designed to provide simultaneous premission, mission,

and postmission customer support. (CRSS-I.I.2)

The SSIS/SCS shall be designed to reduce requirements placed upon customers by

minimizing the complexity of interfaces, avoiding duplication of payload

options, and by providing a user friendly environment for the customer during

the payload life cycle. (CRSS-I.I.4)

The SSIS/SCS shall maximize the use of standard interfaces throughout the

system. (CRSS-I.I.5)

The SSlS/SCS system design and operation shall be user friendly.

Examples of "user friendly" features are:

Interactive SSIS user terminals

"Prompts" user through an operation

Informs user of errors made and where they were made

Provides a "help" function to assist user when necessary

Protects against customer deduced system crashes

Continually informs user of what operation is taking place (never

displays a blank screen)

Allows a skilled user to bypass menus, etc. for more rapid operation

(CRSS-I.I.8)

The SSIS/SCS shall enable a customer to control his payload in functionally

the same manner as if the payload were in his laboratory. (CRSS-6.1.3,1.1.3)

The SSIS/SCS shall make payload information available to the flight crew or

payload specialists via computer terminal equipment with keyboard entry/

display and generation of text/graphics display. A hard copy generation

capability shall be provided. (CRSS-6.4.1)

228
This equipment shall be functionally equivalent to commercially available

equipment to the maximum extent reasonable. (CRSS-6.1.4.2)

The SSIS/SCS shall be designed to support customer payload operations 24

hours/day, 7 days/week. (CRSS-l.l.l)

5.3.8.II SSDS Communications TORSS shall be the primary means of Orbital

Maneuvering Vehicle (OMV), platform and Space Station payloads space to ground

communications. All payload (requiring TDRSS services) downlink/uplink

communication rates shall be consistent with the TDRSS limitations, as defined

in the latest users guide, ["TRDSS User's Guide", Revision 5, March 1984,

(J8400026)]. The Space Station and platform(s) shall be capable of

transmitting/receiving customer data to/from the ground through TDRSS

consistent with requirements in Reference 19, Appendix A. All customer

requests for uplink/downlink support will be managed by the SSIS in

coordination with the TDRSS Network Control Center (NCC). (CRSS-O.I)

Communications between the ground and the Space Station and SpacePlatforms

shall be through the Tracking and-Data Relay Satellite System (TDRSS) or its

replacement system. The use of the maximum TDRSS transmitted and received

data rates over both the Ku-band single access link and the S-band single

access link shall be provided for. Data rates in excess of the maximum shall

be transmitted as individual data streams to the ground independent of TDRSS

and TDAS using payload providing systems. Provisions shall be made for a

contingency command and telemetry link to the ground from the Space Station

and Space Platforms. (RFP C-4-Z.2.6.2.g)

The SSIS/SCS shall permit an alternate communication link consistent with

Space Station Program policies, implemented by the customer independent of

TRDSS/TDAS. (CRSS-l.l.lO)

The SSlS/SCS shall support the customer requirements for communication rates

up to those overall design constraints described in Reference 19, Appendix A.

(CRSS-5.1.3)

229
The SSIS/SCS shall permit customer provided direct Space Station

System-to-Ground transmission links subject to Space Station System

constraints and restrictions. (CRSS-5.1.5)

Standard telecommunications interfaces shall be provided enabling customers to

receive and transmit video, voice, data, and commands via customer supplied

equipment. (CRSS-5.1.8)

The SSIS/SCS shall provide sufficient video channel(s) (uplink and downlink)

to the Station for use by all customers on a scheduled basis. (CRSS-5.2.9)

The uplink and downlink shall support transmission of command and data

information between customer's ground and onboard equipment in a transparent

manner. Restricted and constrained commands shall be identified and

transmitted or inhibited by the SSIS. (CRSS-6.1.3.1)

5.3.8.12 SSOS Workstation The SSIS/SCS shall provide these work stations at

three locations as Follows:

A work station in the customer control facility which will be available to

individual customers. (CRSS-6.1.5.2.1)

A flight station which will be used by the onboard Space Station crew or the

onboard payload specialists. This station shall provide For onboard time

shared use of text and graphics type keyboard display terminals for use by

crew or customer's onboard representative in controlling the operations of the

customer's onboard hardware. This terminal shall be functionally identical to

a commercially available text and graphics terminal and shall interface to the

customer's payload via a transparent data link. (CRSS-6.1.5.2.2)

The SSIS/SCS shall provide onboard workstations capable of supporting mission

planning, scheduling, and system resource allocation as stated Paragraphs

7.2.1 and 7.2.2 of reference #2. (CRSS-7.2.3)

Operational interfaces. The onboard operational interface to the DMS shall be

through Multipurpose Applications Consoles (MPAC) and the distributed computer

processing system. (RFP C-4-2.2.5.I.a)

23o
5.4 REQUIREMENTS DRIVERS

The team has reviewed the functional and performance requirements generated in

Task l and identified those functional and performance requirements which are

expected to have a major impact on the design of the SSDS. These requirements

and their expected impacts will be discussed in the subsections of 5.4.

5.4.1 Impacts of Overall Data Rates

Data rates for the primary SSPEs are developed in Section 6.4. Data rates are

shown in Figure 5-8. The aggregate average payload data rate of the Space

Station, COP and POP begins in 1992 at about lO0 Mbps. There is an additional

estimated overhead of about 8.6 Mbps for voice, _ideo, and spacecraft

engineering data. As the number of payloads on orbit increases, the aggregate

data rate increases to a peak of 253 Mbps in 1999. With voice, video, and

engineering data, the average data rate is about 263 Mbps. These data rstes

do not include the additional transmission requirements necessary to achieve

the error rates of lO -6 required by the Space Station program. The bit

current KSA channel capability for TDRSS is 276 Mbps. With current coding,

300

250

50

n

Effective Capacity per KSA Channel

n

POP-3

Capacity With Convolutional Encoding

m m m _

POP-2

m m _ m

POP-1

Space Station Payloads

Core, Audio, Video, COP _ ,

1992 1993 1994 1995 1996 1997 1998 1999 2000 2001

Figure 5-8. TDRSS KSA Channel Requirements Versus Capacity

231
the effective capacity is ISO Mbps. Hence, lower coding overheads, lower data

rates and/or multiple TDRSS channels are required for the combined

transmission, especially after 1999. The level of coding and overhead to be

incorporated will be developed in Task 4.

It is conceivable that the peak payload data transmission for the combined

Space Station, COP and POP could be scheduled so that there is no simultaneous

transmission of information on two KSA channels. There is some evidence

supporting a probable lower average data rate for some of the highest data

rate instruments in the Space Station program, especially those of POP-I.

With these caveats, it seems possible that the combined data rates of the

Space Station program will be consistent with the use of an equivalent single

KSA channel. If this is indeed the direction that the program takes, data

rates will become design drivers in the following areas:

Scheduling of facilities and communication links from the space

vehicles through the TDRSS to the Data Handling Center.

Providing adequate onboard storage for data to buffer the data

collection and transmission according to the combined transmission

schedule to TDRS.

Performing level 0 data processing in real time at 300 Mbps with data

recording and error detection.

Supporting real-time error correction processing on the raw data.

On-line storage of up to lO13 bits of data to support the 12 hour

on-line storage requirement.

Sorting, repackaging, routing, and transmission of individual

customer data packages.

Distribution of data rapidly enough to receive confirmation of

satisfactory transmission within the 12 hours on-line storage

duration.

232
If the program chooses instead to go to simultaneous use of parallel TDRS

channels, the impact on the design will be felt primarily at the TDRS ground

station and in the communication from the ground station to the Data Handling

Center. The TDRS ground stations will have to be upgraded to receive 600 Mbps

transmission rates. The ground station must later buffer these transmission

rates over the entire period of transmission overlap, or it must upgrade its

retransmission facility to route the full 600 Mbps transmission rate. In

either case, it will be necessary to have at least four and perhaps eight

equivalent DOMSAT links connecting the TDRS ground station or the Data

Handling Center to the next communication nodes. Design impacts to the Data

Handling Center would be dependent upon which method for relay of data is

selected. If the TDRSS ground station does not provide data buffering, the

Data Handling Center must. Otherwise, the Data Handling Center impact is

probably not substantially dependent on the transmission scenario selected.

A trade study will be conducted in Task 3 to determine the program impact of

using l, 2, or 3 single access channels.

5.4.2 Real Time Operation of Payloads.

There is a requirement for customers to be able to operate their payloads

interactively in real time from remote operations centers. Real-time

operation implies the real time entry of commands, the real-time processing of

those commands and delivery of the command to the payload, the real-time

return of payload monitor data from the payload to the customer, and some

amount of real-time processing of the payload monitor data to enable the

customer to determine the next operation. Intermingling of the real-time data

throughput with the bulk data discussed in Section 5.4.1 would create very

serious operating problems. However, many of the payloads can be operated in

real time using a dedicated or shared MA channel. Most payloads can be

operated using only the data capabilities of a single SSA TDRS channel.

Depending on the specific payloads, it may be possible to operate several

payloads simultaneously on a single SSA channel, and some may be operated

simultaneously on an MA channel. Since the SSA and MA channels can be kept

separate from the KSA channel, this would facilitate real-time data movement

for a single customer. It appears that the SSDS can provide for the real-time

2_
operation needs of most customers in this manner. The allowable reaction time

or performance delay for various payloads will also bear on this problem.

MDACwill develop representative delays allowable.

A second implication of real-time operation is involved in the designation of

commands as being unrestricted, restricted, or constrained. Real-time

operaLion must be conducted using only allowable commands. The Space Station

and all of its payloads must be in operating modes that will permit all of the

operations that are to be performed in real-time payload operation. This

creates a potential for a severe scheduling problem for real-time payload

operations.

Real-time operation may also be conducted by a Space Station guest

investigator or mission specialist onboard the Space Station. This mode of

operation relieves the data communication problems between the Space Station

and the customers facility. The operation may need to be supported by a

two-way audio or video return and two-way audio link between the Space Station

and the customer's facility. Including video return and frame rates in excess

of those which can be transmitted by a TDRS SSA band would again impose

difficult data separation problems. Real-time operation on board will also

require that all of the constraint and restriction checking for commands be

accomplished on board.

5.4.3 Automation

The degree to which SSDS functi.ons are automated will have a major impact on

the design of the SSDS. Functions which can be automated can be located

either on board or on the ground according to results of relatively simple

trade studies. Functions which are not completely automated impose

requirements on the operators. Since operators are a limited resource on

board the Space Station, the opportunity for onboard manned involvement in the

operation of the Space Station functions is limited. Therefore, functions

which are not automated will tend to be driven to locations on the ground.

There will certainly be effects on the Space Station engineering data rates.

There may also be effects on the operation and performance of Space Station

systems which are not fully automated.

234
5.4.4 Scheduling

In the preceding paragraphs several references to scheduling problems have

been raised. Automation of many of the scheduling functions appears to be

important in reducing program operating costs. However, both operators and

customers will require that they be allowed to interact the scheduling

function. Scheduling appears to be driven toward a responsive, interactive

tool. The concept developed for scheduling functions in Task l appears to be

amenable to this form of schedule development. However, other alternatives

should be considered in selecting the concept to be used in scheduling. Some

of the requirements placing additional burdens on scheduling function include

Customer and operator interactive scheduling.

Flight crew involvement in selecting tasks to be performed on orbit

and the sequence and timing of these tasks.

The customer requirement for rapid rescheduling to meet "windows of

opportunity" for his payload.

The desire of many customers for real-time payload operation, which

involves the real-time processing of commands through the scheduling

function and the rapid arbitration of restricted or constrained

commands not executable in the current schedule.

The major impact on day-to-day schedules caused by the scheduling of

major events such as satellite servicing, vehicle mating and

launching, and major maintenance for buildup activities on the Space

Station or payloads.

These requirements all drive scheduling toward a high degree of automation.

The degree of difficulty embodied in automating scheduling will be very

strongly affected by the degree to which the systems resources are to be

optimized. Scheduling a function to BO% of a limiting or constraining

capacity is far easier than scheduling a function to 90% or I00% of that

capacity. Scheduling automation will be greatly facilitated by working to the

80% capacity level for all but the most critical functions. The three

_5
resources identified as most critical are: Space Station power, Space Station

crew time, and communications data rate. Communications data rates are

buffered by onboard storage of data. Power generation is buffered by onboard

energy storage. Limiting of payloads and their duty cycles, especially during

the early years of Space Station operation, to something significantly less

than the limits of these constraining resources will greatly simplify the

automation of Space Station program scheduling. Hence, there is a trade

between the cost and time required to develop varying degrees of schedule

automation with varying degrees of sophistication and the ability to fully

utilize limiting Space Station resources. However, automated scheduling is

mandatory to meet Space Station customer requirements.

5.4.5 Level of Physical Distribution

The SSDS functions will be physically distributed among many geographic and

space locations. Some locations will be divided into two or more facilities.

Within facilities, functions may be allocated to multiple processors and

storage units.

The level of distribution, including both the numbers of locations and

facilities and the functions assigned to the locations and facilities, and

the types and quantities of data traffic among functions will drive the

selection of network concepts to be used. The problems of distribution and

networking must be worked together to produce the optimum system design.

Distribution, and the associated potential for functional autonomy, can also

benefit SSDS development and maintenance. Functional partitioning with well

selected interfaces allows corrections, extensions, and upgrades to be

incorporated in one function substantially independent of other functions.

This capability will be required in the development and anticipated growth and

evolution of the Space Station. Functional distribution should be planned to

facilitate system developmental and operational autonomy, as it affects this

flexibility.

These benefits must be traded against the inherent design problems of highly

distributed systems, e.g., data base management, resource control, and network

communications.

236
5.5 REQUIREMENTS TRACEABILITY

The credibility of SSIS functions evolved by the Task l activities is

maintained by full traceability to the requirement that each function was

derived to meet. The need to understand the system drivers is the first of

three major benefits that traceability provides. By having traceability

between the top level requirements and the functions, changes in requirements

are made simpler. If the design of a system to implement a function is found

to be too complex or expensive, the driving requirement may be traced and

altered. Any alterations to a requirement may also affect other functions.

With a traceability system the affected functions can be traced and modified

as required.

Requirement/function traceability supports function justification.

traceability system each function can be traced to its key driving

requirement, thus each function is justified.

With a

The visibility of the completeness of the functions list is also provided by

assuring traceability. Mapping all the SSDS related requirements insures that

the functions list accommodates all requirements, thus the functions list is

validated and checked for completeness.

5.5.1 Requirement Sources

The Space Station Definition and Preliminary Design RFP (Reference l), and the

Customer Requirements for Standard Services from the SSIS (Reference 2) are

the primary control documents for use in the traceability matrix.

Additionally, engineering analyses were performed on the data base derived by

the Langley Mission Requirements Working Group (reference 3) to extract

mission requirements that affect the SSDS.

5.5.2 Traceability Implementation

An analysis of the requirements documents was performed to extract the

functional requirements that pertained to the SSDS. After this analysis was

completed, each of the resulting requirements were mapped to specific

237
functions that were derived to meet each requirement. The results from the

mapping process were entered into a computerized traceability matrix that was

developed using the ACCENT R data management system.

The automated traceability matrix provides complete top down/bottom up

traceability. A requirement can be traced to the functions that satisfy the

requirement. In addition, functions can be traced to the requirements that

gave rise to each function; thus, the traceability matrix gives complete

top-down/bottom-up traceability as shown in Figure 5-9.

Additional bottom-up traceability exists within the requirements data base.

Many functions were derived from other requirements documents such as Yellow

Books and CDG briefing material (before References l and 2 were available).

To accommodate this, space was provided on a functional data sheet to give the

document name and paragraph number of the requirement that needed the function.

_8 RFP

Space

Station

System

Requirements

C-4

OPS C-3

Other Sources

• Yellow Books

• SSIS Report (JPL)

• CDG Repom

• Industry Structures

\

Figure 5-9. Traceability

238
5.5.3 Traceability Report Examples

The top-down traceability report maps each requirement to the function derived

to meet the requirement. The requirement is identified by its unique

requirement number, document abbreviation from where the requirement was

extracted, and the paragraph number of the requirement. Each requirement is

also given a brief descriptor to help further identify the requirement.

Requirements extracted from Reference 3 are identified by the major mission

number, then the count of other missions that need the function is given in

parentheses. Next, the list of functions that map to the requirement are

given. The functions are identified by their derived function number and

abbreviated function title. Example output from the top-down report can be

seen in Figure 5-I0. The full report is in Appendix A-5.

The bottom-up traceability report maps each function to the requirements that

gave rise to the function. The function is identified by function number and

abbreviated function title. The requirements are identified by their

paragraph number from the document from which they were extracted. The

document can be identified from the requirement number field. Requirements

numbered from lO00-1ggg come from Reference l, requirements numbered from

2000-2999 come from Reference 2, and requirements numbered from 3000-3999 come

from the analysis of Reference 3. The requirement is further identified by a

brief descriptor. Example output from the report can be seen in Figure 5-11.

The complete bottom-up report is in Appendix A-6.

239
REQUIREMENT # DOCUMENT

ll05 RFP

PARAGRAPH #

C-4-2.2. B

DESCRIPTOR

ATTITUDE CTRL & VELOCITY ADJUSTMENT

DERIVED FUNCTION NUMBER

4.1.2

4.1.3

FUNCTION TITLE

GUIDANCE

ATTITUDE CONTROL

REQUIREMENT # DOCUMENT PARAGRAPH #

2012 CRSS 3.2.2

DESCRIPTOR

PROVIDE CUSTOMER DATA ACCOUNTABILITY

DERIVED FUNCTION NUMBER

l .4.6

2.1

2.2

3.3

FUNCTION TITLE

CUSTOMER DATA ACCOUNTING

VALIDATE P/L CMMDS/DATA

CHECK P/L CMMDS/DATA

DEVELOP OP EVENT SCHEDULE

REQUIREMENT # DOCUMENT

3023 MRWG

PARAGRAPH #

SAI_X0303(8)

DESCRIPTOR

CREW PHYSIOLOGICAL MONITORING

DERIVED FUNCTION NUMBER

4.3.1

FUNCTION TITLE

HEALTH MAINTENANCE

Figure 5-10. Output from Top-Oown TraceabilityReport

24O
FUNCTION NUMBER FUNCTION NAME

2.5.2 COST P/L OPS

PARAGRAPH

NUMBER REQ#

C-2-3.1.3 I005

C-3-3.1.G I034

6.3.1.I 2046

6.3.2 2047

7.I.3 2053

SAAX0305(32) 3040

COMMlll?(37) 3044

DESCRIPTOR

INDEPENDENT CUST. OPERATION & MONITOR OF P/L

INDEPENDENT CUST. OPERATION AND MONITOR

ACTIVATE STORED COMMAND SEQUENCES

STORED P/L CMMD ACTIVATED BY ANOTHER STORED CMMD

PAYLOAD HOUSEKEEPING DATA MONITOR

CUSTOMER PROCESS CONTROL

PAYLOAD ACTIVATION/SAFING

Figure5-11. Output from Bottom-Up TraceabilityReport

241
Section 6

Substantiating Analyses/Technical Justification

This section contains a description of additional analyses which were

performed in the development of the SSDS and SSIS functional requirements.

The section also contains the technical justification for some of the key

performance requirements. This section is not intended to be a complete

discourse on the analyses undertaken. Rather, it is a supplement to the other

sections of this report wherein many of the appropriate analyses are described.

6.1 REVIEW OF ANALYSES PERFORMED

The methodology followed in developing the SSDS and SSIS requirements was

described in Section 3 of this report. Three parallel paths were followed in

developing the SSIS and SSDS requirements. One path involved the review of

then available literature and extraction from the literature functions which

were appropriate for the SSIS and SSDS. A second path used structured systems

analysis to define the logical steps required to process data during

end-to-end movement through the system. The third path used requirements from

the Mission Requirements Working Group, the Space Station Phase B RFP, and the

customer's requirements for standard services from the SSIS, produced by

GSFC. Functional and performance requirements were identified from these

three documents and traced through to the SSIS functional requirements and the

SSDS requirements.

The structured systems analysis was described at a top level in section 4.3.

Section 6.2 will present the Level l data flowdiagrams and the analyses

represented in the indicated flows. Lower level data flow diagrams and the

accompanying data dictionary will be developed as a part of task 4.

The development of the function requirements was covered in Section 5.1. The

analysis of available literature and development of SSIS and SSDS functions is

shown in Appendix A-4.

243

_RECEDING PAGE BLANK NOT FILMED
Section 6.3 shows the development of functional requirements from the mission

requirements working group output. Section 6.4 shows a compilation of

performance requirements as generated by the Mission Requirements Working

Group.

6.2 STRUCTURED SYSTEMS ANALYSIS - LEVEL l DATA FLOW DIAGRAMS

There are two accepted approaches in structured systems analysis to developing

Level l data flow diagrams from a level 0 data flow diagram. In one approach

the level l data flow diagram covers the entire system, but contains

significantly more detail than the level 0 diagram. In the other approach

each function in the level 0 diagram is expanded at Level I. Because of the

complexity of the system and the significant degree of independence of

functions at level O, the latter course has been chosen.

The Level 0 data flow diagram was shown as Figure 4-3. This diagram is

reproduced here as Figure 6-1 for convenience. The diagram contains seven

functions, each of which will be expanded as Level l data flow diagrams.

Figure 6-2 shows the expansion of Function l, Manage Customer/Operator

Delivered Data. This function receives data generated by the payloads and

core systems and delivers the data to its appropriate destination. The

external agency in the upper left hand corner of the diagram, labelled OMV,

OTV, and constellation interfaces represents the communication interfaces on

the Space Station to elements in the constellation. These elements may be

transferring to the Space Station both data to be relayed to a destination in

real time and data which may be held for bulk transfer at a frequency of

approximately once per orbit. Real-time data are delivered to Function l.l,

Manage Real-Time Return. Bulk data are delivered to a data store labeled

"Delayed Payload Data." Similarly core systems, at the top of the figure,

also generate real-time data for monitoring. The bulk core systems data to be

returned has previously been stored by the core system functions in a data

store labeled Core Status. The real time core system data are also delivered

to Function l.l. At the far left, Space Station payload data to be delivered

in real time are routed to Function l.l while delayable payload data are

routed to a data store, and held for the once per orbit bulk data return.

244
ORIGINAL PAQE Itl

r--'_o---_ sszs OSA6E. _£ OF POOR OUAL_E STATUS

SUPPORT I LO6ISTICS NEEDS _ - " . /___luuj_._._

SPACE_ _ TMIS _ .O_a_ _ORE_AtA J

STATION I MAINTENANCE e-----=---=- =_ j_ ...... r-- I PROSRAML_"eEDS iO00_ ! t I CU'S'?O'#_R/ l"---_AYL°A°DATA 100_3

I | _--- OPERATOR

• • OPERATOR r,I- . -_-'--_'.'--- -"' - . DATA PAYLOAD COMMANDS _ _ C_ON...S.T_

/_C_ I I______ZJ /SCHEDULE _ ) J L._____] ,",-r," ,:,','_,_I_ I.E=O--TS J STATUS,.OOE ; r

CORE t OISP.ITIO.1⁄2 .... - ( J

LqTATUS I _.nA_T._T'_e / ' / /_ * l | .... lU /

-- ; I _,_._._.E_.._ SC-DOLE /_ STATUS d ICMMDS. DATA

• ..... ';..._ OP_F_n__TEI EXECUTABLE I H_ F PROIRAN !

_[;_.',_" I .#o_.. I core CNNOS, I EXECUTE L, SCHEDULE • _ n _ I r_

,w ala/CMO OATA OPERATIONS - L "-" " i;"

k RESOURCES. COR l ' co,,o.,-1---J NANAEE .,::: f

TONER/

SYSTEM STATUS,_ OPERATOR I: OPERATOR

_ "r"_ A-_-.---_--_ _"ESTRICTED CONSTRAII_EO I SUPPLIL='D [ OZSPOSITIONJ i_

I .... i " - ---- ' * /

t #°?_NS! IILsIIP T koHEOULEO OPERATIONS t %O.E, SYSTE. CONTROV

, , ISTATUS / ! C PRO_"TSPROCEDURES.

' ' I | [OO90lSHOnTTERM SCHEDULE | I/O, R,EACTZONS ,

IOOSOIFACILITIESSTATUS' | F---"----- _ I(" "00"4 '

='ON_I;URATION. / _CHEDULED OPERATIONS _1 f _ I

_,_ FACILITIES / _ 5, I;I ) II I' [

I" ..... STATUS ) 1 / II I' CUSTOMERS I

l i AND I

L,.---.--_O0_.O " ] STATUS , -] MAliAi;e / - 6 o 3 I I iCONTRACTORSI

t | "TFACILITZES/ NEW/UPDATED -'" -'_ I _ - " " I

DATA L RECONFI6URE AND DATABASE, llPRo=sIN.- / RESOU_CE_ L ._- ._.e__ _T

II RESOURCES t / r 2.,_.._'.._}.. =-' I MODELS, DATA )l

/ I o=_,_,°,== L _; '_"_=_'z=_L PROCEDURES. Z/O )

k I I!0015

% SIMULATED STIMULUS_: HARDWARE }

"_i AND

! SOFTWARE I

Figure 6-1. SSDS Level 0 DFD , ....... RESPONSE i; FOR I

_ZNTEERATIONJ

The onboard customer or operator represents one of the end points of the

data. Both real-time and delayed data are shown as delivered to the onboard

customer/operator. Note that the box representing this external agency has

been duplicated and it appears at the top center and the bottom left of the

figure. The onboard customer or operator use these data to monitor the

performance of payloads and to interact with payloads or core systems in real

time. A two-way voice and video communication link between the onboard

customer or operator and the ground customer or operator is provided by this

function.

Bulk data from both the core and the payloads is delivered to Function 1.2,

Manage Delayed Data Return. Both data return links are governed by previously

established priorities. Both deliver data to a data distribution function,

Function 1.3. The data distribution function will read the data header,

select the appropriate routing of the data, and deliver the data to the

designated end point. The data are shown as divided into two streams. One

245
_0007 1 CUSTOMER __

. i POLAR 1.4 _VOICE. VI_E_o027

i ii AND .£O-ORBITIN@

CORE i PLATFORMS MANAEE I I GROUND

_ SYSTEMS • . L ......... )ELIVERABLEI PAYLOAD ' CUSTOM=RS

" /---I . I0002 ! I CUSTOMER _ATA _

I/_ i _ ....._ i I I DATA _ -'I

, PLATFORM / ...... , OMVoOTV I ± ON_O_RD |PAYCO_' _ I

AND CORE -_ CUSTOMER/' "

/

,INTERFACES AT VIDEO _0028 " ' i INTEI _kTk p L _ I ICUSTO._R _A,A T I : I

_l-'-- _I_1 "-_--_ | _VOZCE. VIDEO CORM I | _ CUSTOMER ]

/ _ST; .... . ,11 OPERATIN6 I _.,,_.__...,r" 1.3 1 I _ RD'C'S ]

/ 14II:AL-/LR¢ / •. * I nat A _ -, " .. I I I; /NON_SSnS

i L DATA _/ I "'" " I t ......... __szs/sc_ll

,_U&/LUN_L L

I _---_ q NANAiE / HEAL TIRE DATA _1 .... ] I:NrT...av .......

ii ..... _EAL-TIMEIRETU.NI- DATARETU.. -i ] -_7---'-_,

i: S_X_)_N i DATA J L PRIORITY -hi | I ;RCHIVE _0030 !

I _ PAYLOADS -I. j _ f_-_'. Y I DATA __ I

I L_____,_._J _ IO021;PRIORITIE S i _ _ "_ENGINEERINEI

_,----_IDELAYABLE I /"---L::.._U_ IOPER_TOR RATA. I f O_TA ,

"-"-_, n,_• IFLIEHT IDATA R=_,m- I IVOICE. VI_O COMN ;I CE TER !

Iooa,]_Ec,YEOOATA I""" I _ a L

---...... , I .1 '- " o,o

MANAEE CORE "T _ i: '

4.3 " ' '] DATA _X_ I I li BROUND I

SUPPORT _OO02 I I ' -- k J i, i

F_I6HT :l L_ORE. R/L DELAYED DATAI -- _ _OPERATOR L--T J

 Re. [ oNOOARO I- ' I voice,video

ACTIVITIES : I CUSTOMER/ , i

LOPE"ATOP/J,, IOOIIiCO_STATUS

Figure 6-2. SSDS Level 1 DFD 1.0 Manege Customer/Operator Delivered Data

stream includes all customer data while the other stream includes all core

data. The recipients are the ground customers at their own facilities,

customers regional data centers, the engineering data center, and ground

operators. The customer payload data will be delivered either to the

customer's own facility or to the customer's regional data facility, depending

upon the customer's selection. Core data are either delivered to ground

operators or to the core data center for archiving.

Most of the customer's ancillary data requirements are expected to be met by

delivering ancillary data in real time to the customer's payload on the Space

Station. Additional ancillary data are provided either from the Space Station

control center or the engineering data center upon customer request.

Figure 6-3 shows the management of customer or operator supplied data. This

function manages the commands and data supplied by the customer or by the core

system operator. Payload commands and data are received from the

246
customer/operator in the upper right hand corner of the figure while core

commands are received from the core operator at the right center of the

figure. Commands and data destined for the payload or for vehicles in the

constellation are sent to function 2.1, Validate Payload Commands/Data. In

this function the customer or operator is first authenticated as being one who

is able to enter commands. The address of the command is then checked against

those that the customer or operator is authorized to command.

The commands and data meeting these tests are termed valid payload data and

valid payload commands. Valid payload data are delivered directly to the

payloads or to the OMV, OTV, or constellation interface with no further

checking. Valid payload commands are checked against the list of constrained

VALID PAYLOAD DATA

--r VALID UNRESTRICTED ' 7

PAYLOAD COMMANDS ( 2 2 -7 ,( 2.1 ]

._ I i VEHICLE iu_.... U nuu n'rv r \ f I VALID P/L CMMDS I |

'CMMUb, _ wm. .... I ' PAYLOAO ,

OAT7 b' I" ._,ND / _ CHECK r VAALy_A,T_EL CMMDS/DATA i!O00i

I _ cuN_., i - i r "_ COMMAND I f 1 A LUAU ,-- I/

I ('- I_ INTERFACE J I { {COMMAND IQESTRICTIONI {PAYLOAD I COMMANDS/ I I;

I_,,_T ' A I I I'CLASSIF_CATIDN ICONST_AINTI IdDMMANOS_[ DA,A DISPOSITION 2 COUSETO#TERX

] SYSTEM OPS DATA :' PAYLOAD ENTERED _ PAY AD _ " " : LO

I _.... I I I ' IDISPOSITION IJ AUTHO_ZED T R]ISPOSI, ION

I I_____ ..... _ I I J I............ _ ICUSTOMERS 10150 iPROCEDURES 'STATUS

_7_em_'IVALIO C_STYOPE_ATOR, E{_7coRE _AUT_ORIZED /700_IOMMA_OLO_

' '_ ' ' ' ' ' ,SYSTEM'

_.: .... 11 I° [ 1 ,, OCEDURESID:SPOSIT:ON I , ,P/L CMMDS _0034 IAUTHENTICAT.ON

I 'Ip 0037 COMMAND DICTIONARY PA

I .IPATLUAU I I I

CMMOS _DATA IC6_OL CMMDS OATA ! COMMANDS iOPEA_ATO__S, [ CORE 1003: _ ]

i I I ' i W ' IENTERED ,,AL]DNESSES J CMMDS/I_ I

I/ 2.5 ]_.lJ _ / I ! r " DATA'i I

....... I ' ' "- I cDRe /

t"--," SUPPORTi"7"'ANCILLAR, I pr_ovioE i i, i il P N OP_R'TO"I

CUSTOMER I IANbII-L I .F,E_.,',_VE,. ¢ a 3 ] I ( 2 3 ] DIS OSITIO _ I

I eYST_ M t IDATA I ANbILLAHT i " i ! t l ' / ';-L-- --I

O;ERA;_ON I=L I DATA IDEVELOP I , _ VALIDATE I

_. I ] OPERATING I ' . I co_E | UNRESTRICTED w

J 7 L I EVENTS / i VALZu I COMMANDS / / CORE CMMDS _ -- -

$ ; _ SCHEDULE I _,M,,_,R_AIUM 2ATA I VALID CORE' DATA /( 4.0

COaE I

,STATUS !DATA 7 _ SYSTEM ,i SYSTEMS

, ANCiLLAAY DATA

too.iPAYLOAD/100,_iCDRE STATUS STATUS _ _00_0 ONV. OTV II

t c_T. I

I I"'E"'A%t

MODE

/IO011iCORE STATUS

SSPE STATUS

•Figure6-3. SSDSLevel1 DFD 2.0 ManageCustomer/0peralorSuppliedData

t i

SSPE

DIAG- F

--( 2"6 ]NOSES " 71p 4"3"5'1 l

I SSPE IMAINTENANCEII

'i AND

CHECKOUT SSPE MAIN. I. _EPAIR I[

AND AND SERV, , PROCEDURES

l'SERVICING Ii_PAOCEDURES __ i I

) L_ 'q

247

ORIGINAL PAGE IS

OF POOR QUALITY
and restricted commands contained in the command dictionary. Those commmands

found to be unrestricted are delivered directly to the constellation interface

or payload. Those found to be restricted or constrained are sent to Function

3.3 to determine whether the command can be executed. A command log is kept

to record the disposition of all commands. Disposition is reported back to

the operator who entered the command.

Commands and data entered by the core system operator follow a similar chain

of processes. The commands are validated in Function 2.3. However, valid

core commands are all checked for restriction in Function 3.3. As with the

payloads, valid core data are sent directly to the appropriate core system.

Ancillary data required by payloads and by constellation elements is provided

through Function 2.4. Function 2.5 provides support for the operation of

customer systems, including the operation of customer payloads, the provision

of data processing resources in support of customer payload operation, the

operation of the OMV and the OTV, and support of customer payload checkout.

Function 2.6, SSPE Checkout/Service, which would normally appear at this

level, is not included because the data flow paths are many and varied. It

was felt that their inclusion would not significantly improve understanding oF

the system operation.

Function 3.0, Schedule and Execute Operations is shown in the Figure 6-4. The

scheduling of Space Station operations begins with a master plan generated by

the TMIS. This input is seen in the center left hand side of the figure. The

master plan contains major events such as the STS visits to the Space Station,

OMV and OTV launches, major maintenance actions and buildup of the Space

Station, addition and removal of payloads, major construction activities, and

major payload maintenance actions. The accommodation portion of the master

plan shows what payloads will be onboard the Space Station at what times and

the characteristics of the payload operations.

Typical day schedules are developed for both a normal day and for days on

which major events occur. Normal days are defined as those days when no major

events take place. These days are expected to comprise approximately 60% to

248
l

l

i

l

L

Figure 6-4. SSDS Level 1 DFD 3.0 Schedule and Execute Operations

80% of the total operating days of the Space Station. A normal day schedule

is used as a baseline for developing a schedule for a major event day.

Payload operation may be discontinued on major event days in accordance with

constraints imposed by the major event taking place and with any limitations

that may be required for critical Space Station resources. Operating

priorities are used to allocate any impacted Space Station resources.

Customers and operators input their desired operations with sufficient

descriptive information to develop timelines, assess impacts on Space Station

resources, and determine interferences between operations of core and payload

systems. Any conflicts in the schedule are examined in the scheduling

function and possible resolution is reported back to the customers and

249
operators. Again, operating priorities are used to arbitrate between

competing requirements for critical resources and interferences or conflicts

between the operation and characteristics of the payloads and core systems.

Shuttle manifests and schedules have previously been established in the master

plan. Additional interaction is allowed to provide space on the Shuttle for

repair parts and resupply of consumables. A file of recurring operations is

kept to show resource requirements timelines and interferences for each of the

recurring core and payload operations. This file is periodically updated by

the information coming into the development of typical day schedules or the

development of short term schedules.

Short term schedules are developed beginning with a baseline of a normal day

or a major event day. The events in the normal operating day are confirmed

with the customers and operators. Any change requests from the customers or

operators are entered into the short term schedule. Resource availability and

utilization, interferences, and possible resolutions of conflicts are relayed

back to the customers and operators. The customers and operators

interactively develop the short term schedule to optimize the output of

payloads during specific days.

Communications needs are arbitrated with network control for each individual

day. Communication allocations are returned from the network control showing

the time slots that can be reserved for the major communication links to be

used.

The flight crew is involved in the development of the short term schedule

through their task selections. Again, conflicts are resolved by operating

priorities.

The output of the short term schedule is held in the data store. The short

term schedule will typically be developed, beginning approximately one week

before the date of operation. The schedule may be updated or revised to

accommodate targets of opportunity by individual customers.

250
The operating event schedule is the actual detailed timeline on which the

Space Station will operate for a particular day. Function 3.3 develops the

operatingevent schedule based on the short term schedule for that day. The

real-time commands for the payloads and for the core system are checked

against the restrictions or constraints for those commands. Those commands

which are found to be provided for within the short term scheduled are time

tagged and loaded into the operating events schedule. Those restricted or

constrained commands which are inconsistent with the short term schedule are

returned to the short term schedule development function for arbitration

between the customers and operators.

Any change to the payload or core which has not been scheduled will

automatically trigger a review of the operating events schedule to ensure that

all of the commands that have been stored in that file are executable.

The operations to be executed are selected from the operating events schedule

in accordance with their time tag by the sequence operations function.

Payload commands are sent on to the payloads on the constellation interfaces.

Core commands are sent to Function 4, Operating Core Systems. The timing for

the execution of the commands in the operating events schedule can be

controlled to approximately 1 msec. The time input comes from Function 4.1.6,

Time and Frequence Management.

The commands stored in the operating events schedule are not envisioned to be

the detailed instructions set that is executed by the payload or core system.

These commands are envisioned to be keys that trigger the execution of a

command sequence which has been prestored in the payload or the core system

processor.

The operation of the Space Station and ground core systems is shown in Figure

6-5. The core systems are split into avionics core systems and non-avionics

core systems, following approximately along the lines of predominantly

software systems and predominantly hardware systems. Operator control inputs

enter into the system via the validated core commands and sequence operations

functions in the upper right hand corner. These commands have been previously

checked for restrictions and constraints and are found to be executable at the

time the commands are issued by these functions.

251
NON-6N E C

loaot ]OPERATIN6r 4.a /

! _ONNANOS |

NON-FIN & C _-" | OPERATE !

][ CORE | SENSOR |NON-EN E C I RECONFIEURE.

',I SYSTEMS / DATA _/ CORE L. DISCONNECT

L __J -] SYSTEMS r'- ---_-h--- - r

t Jf s.' 1

_.-6N _ c S_ATUSEJ / .AN*SE/

f -- / FLrGHT/ (

l _/ SYSTEN I

_ _r GN & C STATUS |FACILITIESI

AVIONICS

SERVICES

REQUESTS

PROVIDE l

CUSTONER

AVIONICS

SERVICES

_0013

_ PAYLOADS.

_ts

U

6N E C ! 4.1 JL

OPERATING l

0202 i CONNANOS OPERATE <

SENSOR fin E C NASS. AREA PROPERTIES

U GN G C DATA SYSTEN I--

SYSTEM - J020__ NASS PROPERTIES CONFIGURATION

Tp NED I CAL

TRAINING

RECORDS

ROPERTY

BOI61PAYLOAD STATUS ]UPDATES r 1o2o41cR81STATUS

t i -

PAYLOAD STATUS 4.5 CREW DATA _

MONITOR

AND

STATUS

_! _ SYSTE.

J

I

I

jt

• 1.1/3.2 ]

DEV. S.T. l

FLIGHT CREW pATA

4.3 CREW TASK I

SELECTIONS )

CORE DATA

FACILITIES STATUS

f T

CUSTOMER ALARMS.

SYSTEM STATUS

Figure 6-5. SSDS Level 1 DFD 4.0 Operate Core Systems / CUSTOMER

/

CORE SYSTEN STATUS. ALARNS

1

CREW DATA

REQUESTS.

TASK SELECTIONS

NESSAGES.

PROCEDURES.

REQUIRED TASKS

i

L _._ _0102

i OPERATOR

The two functions operate non-avionics core systems and operate avionic

systems are still high level functions. There are two additional levels of

subdivision, shown in Appendix A-4, before the detailed operation of these

functions is defined. At the level illustrated, these functions enter

commands and control into the systems and receive back sensor data. The

sensor data are processed to provide the status of the core systems. Each of

the functions must have both ground and onboard sections in order to provide

for the autonomous operation of the Space Station onboard as well as the

operation of the Space Station by ground crews during periods of emergency or

periods when the Space Station is not inhabited.

Function 5.1, Manage Flight System Facilities, monitors the voltage and

current draw of the payloads as well as other potentially critical indicators

of payload status. When a payload is determined to be drawing more power than

252
allocated to that payload or when evidence of serious payload malfunction is

detected the reconfigure or disconnect command is sent to the non-avionics

core systems. The function will then disconnect operating power from the

payload which appears to be malfunctioning.

Function 4.3 in the lower right hand corner, provides support for the flight

crew activities. This function prepares the necessary displays of core data

to the flight crew to enable them to monitor and operate the core systems.

The function also displays procedures to the crew to instruct the crew in

Space Station and payload operations and maintenance procedures. The function

assists in displaying required tasks to the crew and entering their task

selections into the scheduling function.

Function 4.4 provides special avionics services to payloads and to customers.

This function will provide such avionics type information as is not normally

generated by the core avionics systems. This function includes such avionics

services as providing pointing coordinates to payloads, determining and

forecasting ground track and monitoring Space Station contamination

environment.

Function 4.5 provides a general monitor and statusing of both the core and the

payload systems. This function monitors core payload facilities and crew

status and prepares appropriate display data for operators and customers.

This function also prepares the mass properties configuration data necessary

for the avionics systems to determine orbit and attitude and propagate the

navigation state vector.

The management of SSOS facilities is illustrated in Figure 6-6. Each of the

functions manages the data processing equipment in its facility. The

functions include the evaluation of the data processing requirements for the

facility and determination of the utilization of the available data processing

equipment. The functions monitor the status of their respected facilities and

determine facility capability.

Function 5.2, Manage Space Station Control Center Facilities, also includes a

global facilities management function. This function includes the

253
4.2 _) IO01?[.ASTE_PLAN

" /I |_06.A.

OPERATE ] r _SCHE_LE

HON-GN G C/ 14

o_.o /I RECONFI6URE.

='='_"= h DISCONNECT

IPROCESSZN6/ I i ]

I EOUIPNENT / I _

)ST.US "j

+ ] TATuS ]

_AE_UEST

NETWORK. TDRS SCHEDULE

CONTROL

SCHEDULE REIiUESTS

EXECUTIONS

• NEW SOFTWARE

DATABASE

r

SCHEDULED

OPERATIONS

OO89JoPERATIN6 EVENTS SCHED.

063

EVELOPNENT

COMMUNICATION

INTERFACE

O090JSHORT TERM SCHEDULE

5.2

NANA6E

6ROtlNO

SYSTEN

FACILIrIES

RECONFIGURE

| • gROUND I

•I DATA I

I PROCESSZNGI

I ErzUZPNENT I

CONFI6URAT ION.

TATU5

[Ot3OIGROUNO FACILTTZES STATUS

CONF[GURATION,

STATUS

Figure 6-6. SSDS Level 1 DFD 5.0 Manage Facilities and Resources

coordination of the configuration of data processing equipment For all

Facilities in order to provide for the prompt movement of data through the

system. This function also arranges the network and TDRS satellite schedules.

As previously mentioned, monitoring of payload status indicators and core

system indicators in Function 5.1 may lead to a requirement to reconFigure the

non-avionic core systems or to disconnect various payloads. This function

also controls the systematic shedding of load under conditions of loss of

power system capability in order to protect the Space Station and its crew.

The development, simulation, integration, and training function operation is

illustrated in Figure 6-7. This function provides a development and

simulation environment for general purpose use by contractors, customers and

system operators. NASA is considering multiple facilities to support this

function, including a software development environment, core and payload

254
ORIGINAL PAGE IS

OF POOR QUALITY Tn_:';:NG £T&TJ£

• I TglAINENG EXERCISE qEQUZREMENTS

2EV-:O_ _NTERPRET i "_

COMM. COMMUN:C_T_QN MODEL REQUT.REMENTS MOOEL

MODEL SO;TW_RE ']:AGNOSTICS REQUESTS

CO'x=23 _

# =

L__ :MOFI¢L ) _

: ; _- I SOT TWARE E .6 COMMUN'[CATZONS ;REQUIREMENTS I MODEL F t

_]ONEZGUR4TZON ( .REQUIREMENTS [ n_vP_nP

c--L-6 3--q _,0MM. OAT._. IJ0065 W CARABILITIESJ I -[ S'O_FTW'-A-REII

" --- ! SZMULAT:ON MONITOR J I _H4RDW4RE ilNTEGRAT_ON I

' S'[MUL,_,TE IMODEL ' MODEL ' CONF]:G .

S S ' _ CUSTOMEI_, HO TFWARE ,RE[;UIR_'M_'NTS_- " i

i . :.. i UPq_MA/UM I

! sYS.=M i MooE-S2 ICONT"ACT_iR_ i _ J

: COMM. "_----------'_, tOEVELOPEO I A ") ! I " -

.._,., ELEMENTS _ ': ISOPTW_RE '_S/W OIAG'' '_ _' ISOFTWARE ' r _ " I T " " ' " "f J[NTEGRAT]'ON

r E 6 g .......

IsMULCTED| !, ! I iI t

_'OREOAT_._* S OAT_I ,.1 4:JRRENT MODELS-, SOFT..RE] IZNTEOR",_ONI_ I

" ' _ / IT _ , I ' • i [ CONFIG ! - t I

: OoE_l_'63----"lI _O067'SIMULATT-CNMOOELS I I i i i i ]MOOELS

IbEVELOP_ENT' I Y P. ] / _ "" _

SI TE -

S.S. L CORE DATA CORE DATA X I

t ELEMENTS F" , _. F

..... I"lI PIL ErIUIPMENT DATA .__j _ 0511 CORE STATUS' ! I ,)

UU/I= LH/" CMMOS, ANC.LLARY _ DATA-I- J,_ _,. : ; _ _ & ;

10NSITE F -- ' "1 _1_ I ,

, I I i II PROCEDURES, '

IHARDWARE] _ OFF SITE I i '__ C STOMER i I./., s/w, OAT_ I :

I! CUSTOMER. I !I"NTEG_AT_rON _ 0UERATOR: _ 1000_ 1 ........ i

IICONTRACTORI MODE- II CONTRACTORI # I __ , ,

It SYSTEM I ,' L I ......... /I _ I RESPONS_ y :

I _ I _ CUSTOMER/' I

" -- I OPERATOR / EXERCZSE PROMPTS.

I J_ SYSTEM REACT:ONS

Figure 6-7. SSDS LeYel 1 OFD 6.0 Develop, Simul,,te, Integr_,te and Train

integration facilities, and a Space Station simulator and training facility.

This section discusses those SSOS functions performed by the aggregate of all

of these facilities. The data flow diagram has five major branches:

a.

b.

c ,

Communication simulation models which enable the function to

interface with Space Station elements through communication

interfaces.

Hardware integration interfaces which enable the function to validate

the performance of payload and contractor hardware for onsite and

off-site.

Software integration capability which allows the function to verify

the functioning and operation of software packages in the simulated

environment of the Space Station system.

255
d . Customer and operator training capability which conducts training

exercises and simulates the response of the Space Station system to

customer or operator input.

e. Software development environment for both operational software and

software simulations built into the simulation mode]s.

These five areas all allow cross coupling between areas to share capabilities

among the simulations. A single function provides an operator interface to

enter into each of the branches of the system. Function 6.1, Interpret Model

Requests, provides a user friendly environment to assist the facility user in

establishing the model requirements and developing the software simulation

that will best suit the needs of the user.

Each branch is separated into functions which develop the model configuration

and functions which actually perform the simulation. Thus 6.2 develops

communication model configurations while 6.3 simulates the Space Station

communications elements. Function 6.3 interfaces with an external

communications interface that allows any portion of the communication links of

the Space Station system to be accessed in the simulation. Data are provided

directly back to the user. It is anticipated that this branch will be used

primarily in verifying the customer end-to-end data links.

Function 6.4 develops the hardware integration configuration while Function

6.5 simulates the Space Station elements, allowing both payload and Space

Station hardware to be verified. The facilities include external interfaces

for both customer payloads and contractor hardware to be validated on site.

The communication interface can also be used to validate off-site hardware.

The integration simulation model may also be exported to a customer or

contractor off-site location to allow the customer or contractor to perform

his own integration tests at his own facility.

The software integration configuration is developed in Function 6.6. Function

6.7 simulates the operation of the Space Station Program processors with their

software. The customer operator or contractor inserts his software into the

Simulation Models data store from the external agency box in the top center in

25B
the figure. This model then is available to insert into the software

simulation from the duplicatedsimulation data store in the right center of

the figure.

Function 6.10 supports the development of software for both simulation and use

in operational equipment. Validated models may be transported directly to the

Space Station or payloads through the communications interface provided in

this function.

Training exercises are configured in Function 6.8 and performed in Function

6.9. The simulator prompts the operator to execute the training exercise,

accepts the operator responses and displays back the system reaction to the

operator response. Actual or simulated core data are made availabe to the

simulation to support the use of authentic data in the simulations.

The programmatic support is illustrated in Figure 6-8. It is envisioned that

the majority of the programmaticsfor the Space Station program will be

provided through the TMIS. A limited logistics plan covering payload and

station resupply and maintenance needs will be delivered to the TMIS from the

SSDS. Logistics support requirements are coordinated by the TMIS.

A majority of the manuals are also envisioned to be prepared by Space Station

program contractors, and available through TMIS. However, the actual

operating procedures for various core systems are expected to be prepared and

maintained in the SSDS; Payloads procedures for both operations and

maintenance are also expected to be provided by the customer. The procedures

in these manuals are expected to be made available to the customers and

facility operators, primarily via CRT display.

Inventory control is also limited to the inventories of material and equipment

in the various SSDS facilities. The TMIS and SSDS will cooperate in this

inventory control.

Configuration management is predominantly a TMIS function. The only role of

configuration management in the SSDS is to maintain the specific data required

to operate and control the Space Station.

257
ALLONABLE COMMANDS, 10106

RESTRICTIONS. NASA 1 | --

CONSTRAZNTS | CUSTOMER REQUEST FOR I CUSTOMERS -- _PROCEDURES _'_ L. COMMANDS, CHECKS I |

1003'IAUT"E"TZCATZON -- - " _ _SIS 10*091"NUALS

/ .... _ESOURCE t

• "'= USA6E ADOITIONS

[ 7 t L PAYLOAD NANITENANCE NEEDS ) / t _ _,p_A._. '

f [ 0016 JPAYLOAD STATUS _ SSIS USAGE _ C_;A_R _---J f 71:; u "_ °

/ PLAN LRESUPPLYNEEOSJ _ J r l SYSTEN L_gll_ IxIES / ]

/ F / $SIS l ]-- NANTAIN

- ) ORE STATUS RESOURCE MANUALS

,, o.. 1 / /

| / ! [OOZSIFACZLZTZES STATUS / /

/ / I f 7.5 1 _

, • I / INASS AREA

| | STATZON |0102 l | / PROPERTIES /

| | MAINTENANCE I / CONFI6 | _ _ORE

/ _ NEEDS I I |NANASEW_T| & pROCEDURES

L_ _=TES OPERATORS ' 0203 INASS PROP" CONFI'" / I / L J 'STATUS

I i I L_PE_,_CAT_ONSJO'O" --

J _/L, CORE -1 /

Oft' LOEISTICS PLAN I _PERADES I / r'_ '' 1/ i INVENTORIES /OPERATO

t1_ /

I I f

_o_ST_CS S.PPORT / I CORE P/L r, _ _._NTENANCE l _ATERIAL

REOUIRENENTS J I .,TrbT._ | " L ACTIONS J _OCATION

1 TNZS I _[CZV_o ] F _TATUS"

/ I _ CONTROL IUPOATE LOCATION. /

l J IOtO31INVENTORIES

Figure6-8. SSDSLevel1 DFD 7.0 SupportSpaceS_tion Program

Customers are expected to provide their own Command authentication data.

Customers, in addition to using the identification provided through the TMIS,

may also incorporate such passwords as they wish to protect the transmission

of data to and from their payloads. Customers are expected to provide a

complete list of their commands including the restrictions and constraints on

any commands. Those commands to be restricted or constrained are negotiated

with the Space Station Program through the TMIS. The command dictionary will

contain not only the complete list of commands and the commands that are

constrained or restricted, but will also contain the circumstances under which

these constrained or restricted commands are executable.

The above data flow diagrams contain the logical structure required for the

platforms, also. However, there are many non-platform functions, external

agencies, and data flows also presented. Figures 6-9 through 6-11 show the

258
diagrams significantly altered for the platforms, i.e., Functions l.O, 2.0 and

4.0. The logic of each is the same as for the Space Station, with the

exception of the elements removed. The remaining data flow diagrams are

substantially the same and show replicated and common or shared functions.

ooo7 ORIGINAL PAGE iS _.4 ioo27 [

PLATFORM 04: I:K)(H_ QUALITY' M_A-GE I I

DATA 1 -I I

iAEA__TIM E !CORE _ " 0028

_OATA _ _ I_

REAL T_ME DATA _ n_ ANCILLARY '

Ioo ' L

REAL-TIME ' RETURN

! PLATFORM DATA | l OATA _-ER--_-----------I TU 1 ! CORE--------_

uI STATZO. -_-L _ _-- _, • C-_, i OATA ] __ J- PRIORITY _._ j I ARCHIVE 10030

._ 00211PR'IORZTZES ! T_=_A_R nATA !_ -I ENszNEERz"6

!DELAYABLE f "i".... I I_'0i'CE' "V,.,_E6 COMM I I CENTER

!P/L DATA :DA,A RETURN I I ' I

' I 2 _ MANAGE

i I MANAGE I I CORE | __,T_, \ =o-_,,,_OATA_ =E_LEt =U_ t DATA_--_---_ _ROU.O

t I /

i

_5_ORE _TAT'_

Figure 6-9. SSDS Level 1 DFD - Platforms, 1.0 Manage Customer/Operator Delivered Data

6.3 MRWG FUNCTIONAL REQUIREMENTS ANALYSIS

_he Mission Requirements Working Group (MRWG) of the Space Station task force

prepared a mission model for the Space Station comprised of Ill missions.

These requirements and the mission model were subsequently updated by the

Woods Hole Mission Requirements Workshop. Requirements for Space Station

program services for each of the missions were identified in the mission

model. These requirements include power, thermal control, data processing,

259
data rate, data storage, crew activities, mass, and volume. There are well

over lO0 such requirements tabulated in the electronic data base maintained by

Langley Research Center. In addition, there are textual descriptions of each

mission and its operation. This data base was reviewed to determine the

standard customer services being requested from the mission data base.

i zl

IF °'c'M_ 1 v_'°ATEC" 1°°°'

_1 c_A_ • PAYLO__ _S/OATA

_LASS"ICATZOM'-_CiNSTRAZ cDWWANo SmZCTZ _DWWA.S PAY'O*O COWWAN.S/ DATA I OXSPOSZTZONCUSTOME_X

i i/ _,Y_oAol / IE"TE_oF'I I--_.AYLoA° -L__.... _"1 Ioo- _ i/! !_°_"¢_T,O, ' ,_t.) !AOT'_OR,Z. : _O0_,'ne-_--4"-_'_0".

/ I- / / I / ( _"P' ... ICUSTOMERS. Lot5o lPROCEDURES ISTATUS PLATFORM I ) /I t t V "Jr' _ IxOOneSSES i l

/ ;:Y'_O_°_s _-_ /I/l°"'lcow"A"°'LO" I n n T _ ,--

/ t _ J - IRESTRICTEO/I i / /lO0.aiJCOaWANO LOt;

I CONSTRAINED l 5YST H

SYSTEM IOPERATIN6_ i IVALID CUST/OPERATOR _ /sg.".E.... IAU_OOZ._o / t

OPS OAT ICNNOS. DATA I ICONTnOLCNWOS. OATA _ /_:."2_= = iY.8"-:_;_' / cone ,0032 I

• I .... CORE

"_---_ SUPPORT ' " ' '_ OPERATOR

r-USTONER, DATA RY, ANCZU.ARY ' • / ( 2.3 ] DISPOSITION :_l J

O_EYRSATTEINoN L. _"_' | DATA i I I " _,-..--L,--] i

i- I , I DEVELOP I • _ VALIDATE /

; OPERATIN6 V CORE UNRESTRICTED w

]'_ L , .E,,, I •:___o___ I=o,,,--,//conec,,,, .7--._ .

-- - I i ; I SCI#EDLA.EI OI_..RkTORI DATA / VALZD CORE'DATA .....

/]0o.lcone STA_,

lO([,61PAYLO_STATUS

Figure 6-10. SSDS Level 1 DFD - Platforms, 2:0 Manage Customer/Operator Supplied Data

260
ORiGiNAL PAGE IS

OF POOR QUALIFY

In this review, 57 standard customer services for the SSDS were identified.

Thirty of the services involved the providing of data either already available

in the core systems or readily providable by core systems software.

Twenty-seven of these services require functions which are not presently

envisioned to be required to operate the core systems. Customer core and

service functions were developed for each of the missions in the MRWG mission

model (Ill missions). This tabulation has not been updated for the "Woods

Hole" model, as the conclusions regarding SSDS mission support services would

not be materially altered. These are recorded in Tables 6-I thru 6-8. The

missions are divided according to payloads in or on the Space Station,

payloads on platforms, payload integration and launch services, and satellite

NON-GN _ C

10201 I OPERATING _ 4.2

I I COMMANDS _ L_

INON-GN G C _ .... 1 OPERATE

, coREI R_°R /,ON-GN, C" RECONFIGORE.

I SYSTEMS ___ D.... _._ CORE DL_DIS_NNECT Joo13

I I I SYSTEMS _ .... /_ AVIONICS-I

t J ;F '" 11 IIII_III IP,,,o,os

NON-GN&CSTATUSi) '1 =ANAG_I t _--J:=-

( ] FL{GAT ! i r v 4 4 _ I . .

51 SYSTEM I / " /

I GN & C STATUS I FACI-TTT=C

• I f_--------'x I ..... I _, PROVIDE !

_ _ : I 1 i I CUSTOMER

0)_I CORE STATUS ; L ) I/'--_ AVIONICS '

' " " '....... Ii SERVICES I

CORE _ i I

! AVIONICS I L J

GN _ C C __L___ fl DATA J

!0202 b -! ---- _ OPERATE _e_ ....... \

I / SENSORI -=_°_=I LMASS, AREA_ROPERTIES . I GN G C I DATA __ o o _ F" _

SYSTEM r-0203 ,MASS PROPERTIES ' CONFIGURATIO N I I 7

O016iPAYLOAD STATUS

L PAYLOAD STATUS

CORE DATA

FACILITIES STATUS

F

_FACILITIES STATUS

i

q

1PROPERTY

IUPOATES

i

r 4.5

4

I MONITOR AND

_ STATUS

SYSTEM

I

I

I ! 0106 L CUSTOMER SYSTEM STATUS ALARMS.

CUSTOMER

CORE SYSTEM STATUS. ALARMS

Figure 6-11. SSDS Level 1 DFD - Platforms, 4.00_,Drate Core Systems

i I 2._/3.,_ _'1_

EXEC. CORE ,! VALIDATE i

COMMANDS/ i_CORE CMMOSt,

>DATA ,i SEQUENCE I iOPERATIONS I'

261
ORIGINAL PAGE iS

OF POOR QUALITY

servicing missions. Tables 6-1 thru 6-4 show the standard core service

functional requirements of the mission model. Tables 6-5 thru 6-8 show the

payload requirements for customer services which are not normally provided by

the core systems.

Each of the functional requirements which were identified for the Space

Station payloads has been recorded in the requirements traceability matrix.

The requirements are also assigned to functions in the Space Station functions

list and are incorporated into the SSDS functional requirements in section 5.3.

Table6-1. SpaceStation Mission RequirementsforStandard CoreServices

Y - MISSION REQUIRES THIS SERVICE

CODE NO MISSION TITLE

SAAX0001 SPECTRA OF COSMIC RAY NUCLEI

SAAX0OO5 TRANSITION RADIATION AND IONIZATION CAL.

SAAX0O08 HIGH ENERGY ISOTOPE EXPERIMENT

SAAX0Ol0 SOLAR CORONA DIAGNOSTICS MISSION

SAAX0201 LIDAR FACILITY

SAAX0207 SOLAR TERRESTRIAL OBSERVATORY

SAAXO301 HEALTH MAINTENANCE,CLINICAL RES

SAAXO]02 ANIMAL AND PLANT VIVARIUM AND LAB

SAAX0303 HUMAN RESEARCH LABORATORY

SAAX0304 CE LSS EXPE R;MENTAL SYSTEMS

SAAX0305 DEDICATED CELSS MODULE

SAAX0306 CELSS PALLET

SAAX0307 LIFE SCIENCES LAB

SAAX0401 MICROGRAVITY AND MAT PROCESS EAC NO 1

SAAX0403 MICROGRAVtTY AND MAT PROCESS FAC NO 2

SAAX0404 MICROORAVLTY AND MAT PROCESS FAC NO 3

COMM1014 REMOTE SENSING TEST, DEV AND VERIF

COMMl105 COMMUNICATIONS TEST LAB

COMM1201 MPS PROCESSING LAB 1

COMM1202 EOS PRODUCTION UNITS

COMM1203 ECG PRODUCTION UNITS

COMM1204 MPS PROCESSING LAB 2

COMM1205 ECG PRODUCTION UNITS t2

COMM1206 B_OLOGICAL PRODUCTION UNITS

COMM1208 CRYSTAL PRODUCTION UNITS

COMM1213 CONTAINER LESS PROCESS PRO0 UNIT

TOM X2010 MATER;ALS PERFORMANCE TECH

TOM X2020 MA TE RIALS PROCESSING TECHNOLOGY

TOMX2O60 DEPLOYMENT ASSEMBLY AND CONSTRUCTION

TOM X2O7O STRUCTURAL OYNAMICS

TOMX2OBO DESIGN VERIFICATION TECHNOLOGY

TDMX2110 LARGE SOLAR CONCENTRATOR TECHNOLOGY

TDMX2120 LASER POWER TRANSMISSION RECEPT

TDMX2130 WASTE HEAT REJECTION TECHNOLOGY

TDMX2150 POWER SYSTEM TECHNOLOGY EXP

TDMX2210 LARGE SPACE ANTENNA TECHNOLOGY

TOMX2220 TE LEC_ SYSTEMS TECHNOLOGY

TDMX2230 SPACE INTERFEROMETER SYST TECH

TOMX2260 EARTH OBSERVATION LNSTRUMENT TECH

TDMX2310 FLUID MANAGEMENT TECHNOLOGY

TOMX2S20 LOW THRUST PROPULSION

TOMX24t0 ATTITUDE CONTROL TECHNOLOGY

TOMX2420 FIGURE CONTROL TECHNOLOGY

TDMX2430 ADVANCED CONTROL DEVICE TECHNOL

TOM X2460 TELEPRESENCE TECHNOLOGY

TOMX2470 INTERACTIVE HUMAN FACTORS

TDMX2BtO ENVIRONMENTAL EFFECTS TECHNOL

TOM X2520 HABITATION TECHNOLOGY

TOM X2530 MEDICAL TECHNOLOGY

TDMX2570 OTV SERVICING TECHNOLOGY

,,//_o_

_7_7_/_/_,o'/_

; Yi Y!

_Y YY

Y

I I y

II Y

, , Y

Y

,y

,Y

JY Y

YII Y

;IYI Y

11 Y: Y

Y

_Y

IY

Y

Y

Y

Y

vl y

vl !

vl i

vl '

I

YIYIYIYI

I

VlVt IV

YIY_ IY

YJYI IY

I

Vl

Vl

v_ IV

YI fY

Vl IV

YL IY

YI

IYIYi YIYl

262
Table 6-2. Platform Requirements for Standard Core Services

Y - MISSION REQUIRES THIS SERVICE

CODE NO MISSION TITLE

SAAX0004

SAAX00O6

SAAX00O7

SAAX0009

SAAX0011

SAAXO202

SAAXO208

SAAXO209

SAAXO210

SAAXO211

SAAXO212

SAAX0213

SAAXO214

SAAXO215

SAAXO21B

SAAXB217

SAAXO218

SAAX0219

SAAXB220

COORBITtNG PLATFORM

SHUTTLE INFRARED TELESCOPE FACILITY

STARLAB

HIGH THROUGHPUT MISSION

PINHOLE/OCCU LTER FACILITY

ADVANCED SOLAR OBSERVATORY (ASO)

POLAR PLATFORM

EARTH OBSERVING SYSTEM (EOS)

MOD RES IMAGING SPECTROMETER

HIGH RES IMAGING SPECT (HIRIS)

HIGH RES MULTIFREQ MW RADIOMETER

LASER ATMOSPHERIC SOUNDER (LASA)

SYNTHETIC APERTURE RADAR

RADAR ALTIMETER (ALT)

SCATTE ROMETER (SCATT)

TROPOSPHERIC COMPOSITION MONITOR

DIRECT TROPOSHPER IC WIND SENSING

UPPER ATMOSPHERIC COMPOSITION

UPPER ATMOSPHER IC WIND SOUNDING

ENVIRONMENTAL MONITORS

AUTOMATED DATA COLLECT/LOC SYS

COMMIO23 STEREO SAR AND MLA AND CZCS

I

; COMMIBIB MULTI LINEAR ARRAY STEREO

I

illlll!

////////

////////,,

[.

YIY Y Y Y Y Y YiY

_JY Y V Y Y Y Y Y

YIY Y Y Y Y Y Y Y

YI Y Y Y Y Y Y Y Y Y

V[ Y Y Y Y Y Y Y

I

I

i I

• I

/_//_//// /

/

Y Y

Y Y

Y

Y Y

Y Y

I

, , r _ i . /i11

//

_" _" r YIY YIY

¢ YIY

fJ ¢ Y

I

i

Table 6-3. Payload Integration Mission Requirements for Standard Core Services

SAAX0020 LARGE OEPLOYARLE REFLECTOR Y

SAAX0101 MARS GEOSCIEN/CLIMATOL ORBITER Y

SAAX0102 LUNAR GEOSCIENCES ORBITER Y Y Y y

SAAX0103 COMET RENDEZVOUS/ASTEROID FLYBY Y Y Y Y

SAAX0104 VENUS ATMOSPHERE PROBE Y Y V Y

SAAX010E SATURN ORBITER/TITAN PROBE Y Y Y Y

SAAX0106 SATURN FLYBY/SATURN PROBE y y y y

SAAX0107 MAIN BELT ASTERO)D RENDEZVOUS Y y y y

SAAX0109 NEAR EARTH ASTEROID RENDEZVOUS Y y Y Y

SAAXOtI0 MARS SAMPLE RETURN LAUNCH y y Y y y y

SAAX0221 LARGE MICROWAVE ANTENNA y y y y y

COMMl110 CLASS IV COMM SAT DELIVERY Y Y Y Y V Y

COMMl115 CLASS III SAT DELIVERY y V y y y y

COMMl116 CLASSIICOMMSAT DELIVERY y y y y y y

COMMl117 CLASSICOMMSAT DELIVERY y y y y y y

COMMl124 CLASSIVCOIVIMSAT SERVICING Y Y Y Y Y Y

COMM1125 CLASSII) COMMSAT SERVICING y y y y y y

COMM1126 CLASS II COMM SAT SERVICING y y y V y y

COMMt304 OMV_TMS y y y y y y y

COMM1309 SPACE BASED OTV y y V y V y y

COMM1312 SATELLITE SERVICING y y y y y y

COMM1318 MULTIUSE PLATFORM y y y y y y

TOMX2530 SATELLITE SERVICING TECH v y v v y y v

i' '

f

J

I

y Y

!

I

i

Y 1 ¢1

Y Yi ;I

y !

Y i

1

v i

V

Y

Y

Y Y!

" i

g

Y

v

Y Y

Y Y

Y Y

Y Y

Y Y

Y Y

Y Y

Y Y Y

Y Y Y

fl _1 y y y

_1 _1 y y y

fl _J y y y

t I ,I y y y

fl _1 y y y

_1 ,, ,_ , y y v

y V Y

Y Y Y

y

Y Y

V V

Y Y

Y Y

Y Y

Y Y

Y Y

Y Y

y

Y Y i

V Y i

v v i

Y Y

Y Y

v Y

Y V

Y Y v

Y Y Y

g Y V

Y Y

Y Y
Table 6-4. Free Flyer Servicing Mission Requirements for Standard Core Services

Y - MISSION REQUIRES THIS SERVICE

CODE NO MISSION TITLE

SAAX0012 HUBBLE SPACE TELESCOPE

SAAX0013 GAMMA RAY OBSERVATORY

SAAX0014 XRAY T(MING EXPLORER

SAAX001S INTERNAT SOLAR TERRESTRIAL PROGRAM

SAAX0016 SOLAR MAX MISSION

SAAX0017 ADVANCED X RAY ASTROPHYSICS FACILITY

SAAX0018 UV LONG BASELINE INTERFER

SAAX0019 FAR UV SPECTROSCOPY EXPLORER

SAAX0022 SOLAR SEISMOLOGY MISSION

SAAX0203 OCEAN TOPOGRAPHY EXP ITOPEX)

SAAX0204 GEOPOTENTIAL RESEARCH MISSION

SAAX0205 GEOSYNCHRONOUS PLATFORM

SAAX0206 UPPER ATMOSPHERE RESEARCH SAT.

SAAX0222 INFRARED SOUNDING

SAAX0223 LARGE IMAGER

SAAX0402 MICRO G VARIABLE 'G' FREE FLYER

SAAXOS01 EXPERIMENTAL GEO PLATFORM (XGPI

Y

Y

Y

Y

Y

Y

Y

Y

Y

Y

I/I//

/ /////

// /////

_'_

YY YY

YY YY

YY YY

YY YY

YY YY

Y Y

YY YY

YY YY

YI; Y YY Y

YIY Y Y

_i/// ////

/////

/////

/,.

I

YYY Y YY

YYY Y YY

Y Y i Y Y

Y Y YY

Y Y YY

Y Y

Y Y Y

Y Y YY

Y Y Y

Y Y Y

Y Y Y Y

i

6.4 MRWG PERFORMANCE REQUIREMENTS ANALYSIS

The various panels at the Woods Hole Requirements Workshop tabulated

performance requirements for each of the III missions in the mission set.

These requirements include performance requirements applicable to the SSDS,

such as:

q)

Data rate from the payloads

Payload operating hours per cycle

Payload operating cycles per day

Delta delivery time

Command rate to the payloads

Command generation hours per cycle

Command generation cycles per day

Command delivery time

Voice channel time

Video channel time.

In addition, an upper limit for onboard data storage for the Space Station and

platforms can be inferred by assuming a once per orbit data dump to the

264
Table 6-5. Space Station Mission Requirements for Customer Services

Y - MISSION REQUIRES THIS SERVICE

CODE NO MISSION TITLE

SAAX0001 SPECTRA OF COSMIC RAY NUCLEi

SAAX0005 TRANSITION RADIATION AND IONIZATION CAL.

SAAX000S HIGH ENERGY ISOTOPE EXPERIMENT

SAAX001O SOLAR CORONA DIAGNOSTICS MISSION

SAAX02Ol LIDAR FACILITY

SAAX0207 SOLAR TERRESTRIAL OBSERVATORY

SAAX0301 HEALTH MAINTE*NANCE/CLINICAL RES

SAAX0302 ANIMAL AND PLANT VIVARIUM AND LAB

SAAXOSO3 HUMAN RESEARCH LABORATORY

SAAX0304 CELSS EXPERIMENTAL SYSTEMS

SAAX0305 DEOICATEO CELSS MODULE

SAAX03O6 CELSS PALLET

SAAX03O7 LIFE SCIENCES LAB

SAAX04Ol MICROGRAVITY AND MAT PROCESS FAC NO. 1

SAAX0403 MICROGRAVITY AND MAT PROCESS FAC NO 2

SAAX0404 MICROGRAVITY AND MAT PROCESS FAC NO S

COMM1014 REMOTE SENSING TEST. DEV AND VERIE

COMM1165 COMMUNICATIONS TEST LAB

COMM1201 MPS PROCESSING LAB 1

COMM1202 EOS PRODUCTION UNITS

COMM1203 ECG PRODUCTION UNITS

COMM1204 MPS PROCESSING LAB 2

COMM1205 ECT PRODUCTION UNITS t2

COMMt206 BIOLOGICAL PRODUCTION UNITS

COMM120C CRYSTAL PRODUCTION UNITS

COMM1213 CONTAINE R LESS PROCESS PROD UNIT

TDMX2010 MATERIALS PERFORMANCE TECH

TDMX2020 MATERIALS PROCESSING TECHNOLOGY

TDMX20_ DEPLOYMENT ASSEMBLY AND CONSTRUCTION

TDMX2070 STRUCTURAL DYNAMICS

TDMX2080 DESIGN VERIFICATION TECHNOLOGY

TDMX2110 LARGE SOLAR CONCENTRATOR TECHNOLOGY

TDMX2120 LASER/POWER TRANSMISSION/RECEPT

TDMX2130 WASTE HEAT REJECTION TECHNOLOGY

TOMX2150 POWER SYSTEM TECHNOLOGY EXP

TDMX2210 LARGE SPACE ANTENNA TECHNOLOGY

TOMX22ZO TELECOM SYSTEMS TECHNOLOGY

TDMX2230 SPACE INTERFEROMETER SYST TECH

TOMX2260 EARTH OBSERVATION fNSTRUMENT TECH

TDMX2310 FLUID MANAGEMENT TECHNOLOGY

TDMX2320 LOW THRUST PROPULSION

TDMX24t0 ATTITUDE CONTROL TECHNOLOGY

TDMX242B FIGURE CONTROL TECHNOLOGY

TOMX2430 ADVANCED CONTROL DEVICE TECHNOL

TOM X24S0 TELEPRESENCE TECHNOLOGY

TDMX247E INTERACTIVE HUMAN FACTORS

TOMX25t0 ENVIRONMENTAL EFFECTS TECHNOL

TOM X2520 HABITATION TECHNOLOGY

TOM X2530 MEDICAL TECHNOLOGY

TDMXZ57B OTV SERVICING TECHNOLOGY

///

///

,v

Y

Y

Y Y

Y Y

Y

Y Y

Y Y

Y Y

Y Y

Y Y

Y Y

Y Y

Y Y

Y v

Y Y

Y Y

Y Y

Y Y

Y Y

Y Y

Y Y

YI;

Y Y

Y Y

ground. These requirements are summarized for the Space Station and for the

platforms in Tables 6-9 thru 6-13. The peak data rates shown in the tables

represent the sum of the peak data rates of the individual payloads which are

on board the vehicles for each of the years shown. Two average data rates are

shown, one for all missions, and one excluding the very high rate missions

likely to be downlinked by "bent-pipe" relay. The average data rates for the

low rate missions includes a scheduling factor of 1.8 for data rates less than

50 Mbps to accommodate peak data recording rates. The peak and average command

265
Table 6-6. Platform Requirements for Customer Services

Y - MISSION REQUIRES THIS SERVICE

CODE NO MISSION TITLE

SAAXO0O4

SAAXO006

SAA X0007

SAAXO0O9

SAAX0011

SAAX0202

SAAX0208

SAAX0209

SAAXO210

SAAXB211

SAAX0212

SAAX0213

SAAX0214

SAAXO21B

SAAXO216

SAAX0217

SAAXO21B

SAAX0219

SAAX0220

COMM1023

COMM1019

COORBITING PLATFORM

SHUTTLE INFRARED TELESCOPE FACILITY

STARLAB

H_GH THROUGHPUT MISSION

PINHOLE_OCCU LTER FACILITY

ADVANCED SOLAR OBSERVATORY (ASOI

POLAR PLATFORM

EARTH OBSERVING SYSTEM IEOSI

MOO RES IMAGING SPECTROMETER

HIGH RES IMAGING SPECT (HIRIS)

HIGH RES MULTIFREQ MW RADIOMETER

LASER ATMOSPHERIC SOUNDER (LASA)

SYNTHETIC APERTURE RADAR

RADAR ALTIMETER {ALT)

SCATTEROMETER (SCATT)

TROPOSPHERIC COMPOSITION MONITOR

DIRECT TROPOSHPERIC WtNO SENSING

UPPER ATMOSPHERIC COMPOSITION

UPPER AIrMOSPHEBIC WIND SOUNDING

ENVIRONMENTAL MONITORS

AUTOMATED DATA COLLECT ,LOC SYS

STEREO SAR ANO MLA AND CZCS

MULTI LINEAR ARRAY STEREO

-_/ ")2

¢

I

Y

Y

CODE NO

SAAX0020

SAAXOl01

SAAXOlO2

SAAXOlO3

SAAX0104

SAAX0105

SAAXOlO6

SAAX0107

SAAX0109

SAAX0110

SAAX0221

COMM1110

COMMl115

COMMl116

COMM1117

COMM 1124

COMMl125

COMM 1126

COMM1304

COMM1309

COMM1312

COMM1318

rDMX25_O

/_#/_#/,,_

_ o o _._,,_

Y Y y" ¢

y' Vly Y'[

Y Y YIY vIy y y

_' Y YIY YIY Y Y'

;**IY

vl

YI

vl

vl

vl

vl y

vl

 )i%f

1

YIY ¢

¢ Y Y ¢IYI

Y! Y !

Y Y I

I Y Y i

ltlllY Y'!'11i

_ Y Y

I _Y Y

Table 6-7, Payload Integration Mission Requirements for Customer Services

I/ ill _ /,/ i ii/ ii/ II

/ //////////

/

LARGE DEPLOYABLE REFLECTOR Y Y Y Y Y Y Y Y i

MARS GEOSCIEN,CLIMATOL ORBITER Y Y ! Y Y Y y y Y [

LUNARGEOSCIENCESORBITER Y Y y y y y y y J

COMET RENDEZVOUSIASTEROIO FLYBY Y Y I Y Y Y Y Y Y

i

VENUS ATMOSPHERE PROBE Y Y I Y Y Y Y Y Y

SATURN ORBITER/TITAN PROBE Y Y Y Y Y Y Y Y

SATURN FLYBY:SATURN PROBE Y Y Y Y Y Y Y Y

MAIN BELT ASTEROID RENDEZVOUS Y Y Y Y Y Y Y Y

NEAR EARTH ASTEROID RENDEZVOUS V Y ' Y Y Y Y Y Y

MARS SAMPLE RETURN LAUNCH Y Y Y Y Y Y Y Y

I

LARGE MICROWAVE ANTENNA y y y N Y Y Y Y [ Y Y Y Y Y Y Y Y

CLASS IV COMM SAT DELIVERY Y V Y Y Y Y Y V Y Y Y Y Y Y

CLASS III SAT DELIVERY Y Y Y Y Y Y Y Y Y Y Y Y Y Y

CLASSHCOMMSAT DELIVERY Y Y Y Y Y Y Y Y Y Y Y Y Y Y

CLASSICOMMSAT DELIVERY Y ¥ Y Y Y Y Y "_ Y Y Y Y Y Y

CLASS tv COMM SAT SERVICING Y "_ Y i Y Y Y Y _ Y Y Y Y Y Y

i

,_LASS,,,COMMSAT SERV,C,NG Y _ YjYIY Y Y _ Y Y Y Y Y Y

CLASS II COMM SAT SERVICING Y _ Y j Y [Y Y Y _ Y Y Y Y Y Y

OMVT_,.S Y¢ Y Y _ _ Y v YiY Y Y Y Y , , , v Y Y

SPACEBASEDOTV Y V Y _ _ Y V Y IY v Y v y "_ Y v y v ¥ Y v v

SATELLITESERVICING Y _ i v Iv v Y Y _ v v Y v v v v Y

MULTIUSE PLATFORM Y "_ Y Y Y Y Y Y :

I

SATE LLITE SE RVICING TECH I I _ ..... Y Y Y Y I [ i

266
CODE NO

SAAX0012

SAAXOOt3

SAAX0014

SAAX0015

SAAX0016

SAAX0017

SAAX0018

SAAX0019

SAAX0022

SAAX0203

SAAX02B4

SAAX02O5

SAAX02O6

SAAX0222

SAAXO223

SAAX04O2

SAAXOS01

Table 6-8. Free Flyer ServicingMission Requirements for Customer Services

_///////

/// ///

Y - MISSION REQUIRES THfS SERVICE

MISSION TITLE

HUBBLE SPACE TELESCOPE

GAMMA RAY OBSERVATORY

X RAY TIMING EXPLORER

INTERNAT SOLAR TERRESTRIAL PROGRAM

SOLAR MAX MISSION

ADVANCED XRAY ASTROPHYSICS FACILITY

UV LONG BASELINE INTERFER

FAR UV SPECTROSCOPY EXPLORER

SOLAR SEISMOLOGY MISSION

OCEAN TOPOGRAPHY EXP (TOPEXI

GEOPOTENTIAL RESEARCH MISSION

GEOSYNCHRONOUS PLATFORM

UPPER ATMOSPHERE RESEARCH SAT

INFRARED SOUNDING

LARGE IMAGER

MICRO G VARIABLE 'G" FREE FLYER

EXPERIMENTAL GEO PLATFORM [XGP)

'/ /

Y Y ; v!

Y Y yI

I

Y I ¥I

Y I ¥i

i

Y ¥I

Y YI

Y ¥i

! ;

!

i

Y! Y YIY Y Y Y Y Y

i

I Y

•

Y Y Y Y Y Y

Y Y Y Y Y Y

Y Y Y Y Y Y

Y Y Y Y Y Y

Y Y Y Y Y Y

Y Y Y Y Y Y

Y Y Y Y Y Y

Y Y Y Y Y Y

YYYYYY

YYYYYY

YYYYYY

YYYYVYYYY

Table 6-9. Space Station A_ached andlnternalPayloads Mission Da_ Requirements Summary

1992 1993 1994 1995 1996 1997 1998 1999 2000 2001

Peak Data Rate

(Mbps)

2.4 2.4 312 312 403 403 353 353 53

Scheduled Data

Rate, Low Rate 1

Missions (Mbps)

(Ref 15)

4.3 4.3 7.1 52.9 54.1 39.4 39.4 39.4

Average Data 2.4 2.4 6.3 6.4 55.0 55.7 38.1 38.1 35.6

Rate 2 (Mbps)

Onboard Data 13 13 34 35 297 301 206 206 192

Storage (Gbits)

Peak Command 79 78 79 82 81 77 67 67 67

Rate (kbps)

Average Command 1.6 1.6 2.8 3.3 3.4 3.4 3.0 3.5 3.5

Rate (kbps)

Voice/Video Channel 19.4 21.1 45.8 47.6 71.6 71.3 71.3 71.4 71.4

Time (hrlday)

1. Contains Missions With Data Rates Less Than 200 Mbps, Uses a 1.8 Schedule Factor for Missions

With Data Rates Below 50 Mbps

2. Rate for All Missions Without 1.8 Schedule Factor Applies to Long Term Averages

3. Based on Storage at Scheduled Data Rate for the Low Data Rate Missions for One Orbit

53

39.4

35.6

192

67

3.5

71.4

267
Table 6-10. Coorbiting Platform Mission Data Requirements Summary

Peak Data Rate

(Mbps)

Scheduled Data

Rate (Ref 15)

(Mbps)

Avg Date Rate

(Mbps)

Onboerd

Storage (Gbits)

Peak Command

Rate (kbps)

Average Command

Rate (kbps)

1992 1993 1994 1995 1996 1997 1998 1999 2000 2001

_ _ m

1 1 1 1 1 1 1 1 1 1

1 1 1 1 1 1 1 1 1 1

1 1 1 1 1 1 1 1 1 1

5.4 5.4 5.4 5.4 5.4 5.4 5.4 5.4 5.4 5.4

10 10 10 10 10 10 10 10 10 10

0.6251. 0.625 0.625 0.625 0.625 0.625 0.625 0.625 0.625 0.625

1. Based on Space Station Relay of All COP Data Once per Orbit

Table 6.11.

1992

Peak Oats Rate 393

(Mbps)

Scheduled Data1 28.4

Rate, Low Rate

Missions (Mbps)

(Re| 15)

Average Data 79.6

Rate2 (Mbps)

Onbosrd Storage 347

(Gbits)3

Peak Command 4.6

Rate (kbps)

Average Command 0.05

Rate (kbps)

Polar Platform "1 Mission Data Requirements Summary

1993 1994 1995 1996 1997 1998 1999 2000 2001

393 393 393 395 395 393 669 669 669

28.4 28.4 28.4 30.7 30.7 28.4 28.4 28.4 28.4

79.6 79.8 79.6 80.9 80.9 79.6 154.4 154.4 154.4

347 347 347 353 353 347 450 450 450

4.6 4.6 4.6 24.6 " 24.6 4.6 5.6 5.6 5.6

0.05 0.05 0.05 0.21 0.21 0.05 0.05 0.05 0.05

1. Contains Missions With Data Rates Less Thin 200 Mbps, Uses s 1.8 Schedule Factor for Missions

Below 50 Mbps

2. Rate for Missions Without 1.8 Schedule Factor

3. Assumes Bent Pipe Relay of Missions Over 200 Mbps, Except Exclusion Zone, Twice per Orbit

Oownlink of Remainder

data rates to the payloads are the sum of the command rates to each individual

payload. Voice and live TV channel time also represent the summation of

requirements for individual payloads on the Space Station.

An aggregate allocation for voice, video, and core data is required to

complete the downlink data rates. MDAC has used an allocation based on the

following assumptions:

• An initial combined voice/video allocation is made to the Space

Station and payloads providing one high rate channel of video at 25

268
Table 6-12. Polar Platform 2 Mission Data Requirements Summary

1992 1993 1994 1995 1996 1997 1998 1999 2000 2001

Peak Data Rate 300 300 302 302 302 302 302 302 302 302

(Mbps)

Scheduled Data I 0.1 0,1 3.8 3.8 3.8 3.8 3.8 3.8 3.8 3.8

Rate, Low Rate

Missions (Mbps)

(Ref 15)

Average Data 16.3 16.3 18.3 18.3 18.3 18.3 18.3 18.3 18.3 18.3

Rate 2 (Mbps)

Onboard Storage 108.2 108.2 118.3 118.3 118.3 118.3 118.3 118.3 118.3 118.3

(Gbits)

Peak Command 6.1 6.1 10.1 10.1 10.1 10.1 10.1 10.1 10.1 10.1

Rate (kbps)

Average Command 0.36 0.36 0.41 0.41 0.41 0.41 0,41 0.41 0.41 0.41

Rate (kbps)

1. Contains Missions With Data Rates Less Than 200 Mbps, Uses a 1.8 Schedule Factor for Missions

Below 50 Mbps

2. Rate for Missions Without 1.8 Schedule Factor

3. Assumes Bent Pipe Relay of Missions Over 200 Mbps, Except Exclusion Zone, Twice per Orbit

Downlink of Remainder

Table 6-13. Polar Platform 3 Mission Data Requirements Summary

1992 1993 1994 1996 1998 1997 1998 1999 2000 2001

Peak Data Rate 0.043 0,043 0.043 76 76 76

(Mbps)

Scheduled Data I 0.034 0.034 0.034 41.2 41.2 41.2

Rate, Low Rate

Missions (Mbps)

(Rat 15)

Average Data 0.019 0.019 0.019 41.2 41.2 41.2

Rate 2 (Mbps)

Onboard Storage 0.09 0.09 0.09 103 103 103

(Gbits) 3

Peak Command 3 3 3 4 4 4

Rate (kbps)

Average Command 0.02 0.02 0.02 0.03 0.03 0.03

Rate (kbps)

1. Contains Missions With Data Rates Less Than 200 Mbpe, Uses a 1.8 Schedule Factor for Missions

Below 50 Mbps

2. Rate for Missions Without 1.8 Schedule Factor

3. Assumes Bent Pipe Relay of Missions Over 200 Mbps, Except Exclusion Zone, Twice per Orbit

Downiink of Remainder

269
Mbps for 6 hours per day and one low rate channel at 1.544 Mbps

continuously. Since most payload and surveillance requirements can

use freeze frame, it is assumed that all of the sources can be

multiplexed into a single low rate channel.

Two additional low rate channels are assumed for the growth Space

Station, beginning in 1996.

Space Station core data are assumed to be 160 Kbps for bulk downlink.

An allocation of 16 Kbps is provided for real time downlink under

normal operation.

Platforms are assumed to have freeze frame surveillance video in a 150

Kbps allocation. Note that data are taken continuously, and may be

monitored by an expert system which can automatically increase the

data rate to full band width in the event of a sudden change in the

region surveyed.

Platforms are allocated an additional 50 Kbps for core data.

The combined audio, video and core data rates are 8.55 Mbps through 1995 and

10.30 from 1996 on. These values may be refined by later analyses, but will

be used in this report to provide an allocation for data beyond payload

digital data.

The aggregate ground data handling requirements for the Data Handling Center

(DHC) are developed in Table 6-14, assuming that a single center will handle

data for the Space Station COP and POP. The average data rates from each

facility, as given in Reference l, are shown at the top of the table. The

scheduling factor of 1.8 applied to the averages is used to size the onboard

storage, but tends to be levelized during the transmission and data handling

steps. Therefore, the DHC rates have been redeveloped to use actual

instrument averages with the 1.8 scheduling factor removed. The average DHC

rates range from 32 Mbps at IOC to a peak of 242 Mbps in 1995.

There are few storage duration requirements given in Reference 2:

l) Online storage of customer data for 12 hours.

270
Table 6-14. SSIS/SSDS Data Handling Rates and Storage Capacities

1992 1993 1994 1995 1996 1997 1998 1999 200O 2001

SS Data Rate 2.4 2.4 6.3 6.4 55.0 55.7 38.1 38.1 35.6 35.6

(Avg)

COP Data Rate 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0

(Avg)

POP 1 79.6 79.6 79.6 79.6 82.9 82.9 79.6 154.4 154.4 154.4

POP 2 Data Rate 16.3 16.3 18.3 18.3 18.3 18.3 18.3 18.3 18.3 18.3

(Avg)

POP 3 .... 0.02 0.02 0.02 41.2 41.2 41.2

Audio, Video and 8.6 8.6 8.6 8.6 10.3 10.3 10.3 10.3 10.3 10.3

Core Data

Allocation (Mbpa)

Combined Long- 108 108 114 114 166 166 147 263 261 261

Term Average

Data Rate

SS + COP +

POP 1, 2, 3

(Mbpa)

12-Hour On-Line 4.7 4.7 4.9 4.9 7.2 7.2 6.4 11.4 11.3 11.3

Storage Capacity

(1012 bits)

1.week Short-Term 65 65 69 69 100 100 89 159 158 159

Archive Capacity

(1012 bits)

2-year Long.Term 6.8 6.8 7.2 7.2 10.4 10.4 9.3 16.6 16.4 16.4

Archive Capacity

(1015b_s)+ ......

2) Rapid recall storage for up to one week, pending verification of

receipt of each data set by the customer.

3) Short term archival storage maintained for one week after

verification of acceptable data quality by the customer.

4) Long term archiving for up to 2 years.

There is a potential for the short term archive to be open ended tn duration.

If the data qualtty check by the customer is immediate, durations 2 and 3 are

the same. Table 6-14 Indicates the total storage requirements for customer

data storage capacity to meet each of these three storage requirements.

271
Reference 13 indicates that the science requirements for the two high rate

instruments on the POP (HRIS and SAR) may be met wlth a lower average data

rate than indicated in Table 6-14. It wtll therefore be assumed that:

1) The equivalent of a stngle TDRS KSA channel can support the combined

bulk data transmission requirements of the Space Station, COP, and

POP.

2) The transmissions can be scheduled such that no slmultaneous

transmission is required.

272
Section 7

TASK MAINTENANCE

The functional and performance requirements for the SSIS and the SSDS are

based on mission definitions, customer requirements, operational requirements,

and system configuration plans and assumptions. These requirements, plans,

and assumptions are continually evolving as the total Space Station program

moves forward. As part of the ongoing SSDS Analysis/Architecture Study the

requirements defined in this study will be updated to reflect overall program

evolution as well as reflect inputs from government reviews and to meet

specific requirements definition needs of later tasks in the study contract.

A specific study task (Task 6) has been defined to manage the maintenance of

this requirements task product and other study products.

The management of requirements updating will be facilitated by our electronic

data base system. Requirement changes can be entered at a terminal and will

be immediately available to NASA and to the study team by electronic access

means. This ability to easily modify the requirements set must be tempered by

the need to keep the requirements relativelystable during the critical phases

of other study tasks, such as the system definition tasks.

Our plans for managing and implementing requirements updates is to (I)

accumulate a list of external changes and customer comments that potentially

cause changes to the SSDS requirements, (2) assess each of these changes and

comments for impact and timeliness, (3) coordinate the need for a requirements

change and its timing with the NASA Technical Officer, (4) develop the revised

requirements, and (S) update the requirements data base. Requirements data

base changes will be made in blocks to provide a degree of stability. As a

minimum, major requirements updates will be included in the study iterations

that are planned for month Ig and month 24 of the study. It is anticipated

that several earlier requirements updates will be made to support the trade

study and system definition tasks.

273
Section 8

CONCLUSIONS AND RECOMMENDATIONS

Conclusions resulting from the Task l analyses and generation of SSIS/SSDS

requirements include:

l) An end-to-end, overall SSIS concept has been defined. This concept

includes identification of all SSlS elements and their

interrelationship. The major SSIS elements are:

Orbital elements interfacing with the Space Station for

communications, traffic control and on orbit servicing (COP,

Free-Flyers)

Orbital elements sharing ground facilities and services (POP,

high altitude COP)

• Space Station core systems and payloads

Communications links (TDRSS, DOMSAT, other satellite and ground

links, DSN, Network Control)

• Data handling and distribution elements

Customer support elements providing POCC, archival and data

processing services

• Customer facilities

Space Station ground elements (Space Station Control Center,

platform control centers, other vehicle control centers, Space

Station archives, and development, integration, and training

elements).

27s BL NK iOT
2) Clear boundaries were defined for the SSDS and the SSIS. These

boundaries were codified in a set of criteria that will allow

continued, consistent evaluation at lower levels. The boundaries

identify elements in the SSIS, and divide SSIS functions among SSDS,

TMIS, and SSIS Standard Customer Services. Principal boundary

elements interfacing with the SSDS include:

Customers interface with the SSDS at a point(s) where data are

delivered to the customer's designated end point as raw data

with level 0 processing and where commands and data are entered

by the customer

Payload physical interfaces generally coincide with their SSDS

interfaces. Exceptions may exist where the SSOS provides on

orbit data processing support for the payloads

Space Station core systems interface at the sensors and

effectors, or at embedded, dedicated subsystem processors

Multiprogram or institutional services, such as TDRSS, may

interface with either the SSDS or the SSIS

Services in the SSIS, such as data archiving and customer data

processing support, as well as TMIS interface with the SSDS to

transfer information

3) The functioning of the SSIS was defined through Structured Systems

Analysis. Major end-to-end data paths for command management and

customer data delivery were defined in more detail.

4) SSIS operating concepts were defined for both the total life cycle of

customer involvement, and for the tasks performed by ground and

onboard operations.

276
s)

6)

The team was able to develop a complete set of SSIS and SSDS

functional requirements. The functional requirements are adequate to

support Tasks 2 through S.

The primary SSOS design drivers identified are:

Aggregate average data rates for the Space Station, COP and POP

and their payloads approach 300 Mbps. It will be difficult to

schedule transmissions using only one TDRSS KSA channel at a

time. In addition, ground data handling and relay facilities

must be designed to meet a nearly continuous 300 Mbps data rate.

There are at least four points where data storage amounts and

rates will drive system design:

onboard storage on the Space Station ( 0.5xlO 12 bits) and

POP ( lO12 bits)

online, 12 hour storage on the ground ( lO13 bits)

short term (l week) archival storage (lO 14 to lO15 bits)

two year archival storage ( lO16 bits).

The total video requirements of 54 hours per day peak in 1996

will tax the communications channels. Frame rates should be

minimized, and expert systems utilized to compress the video to

a single equivalent, part time channel.

System transparency and user friendliness for customers will

drive some design concepts and most customer interfaces with the

system.

Planning and scheduling is a major design driver for all

multiple customer systems. The scheduling function must be

automated to the degree that customers and onboard crew may

interactively develop schedules.

Development, integration, and training is also a major design

driver. The Space Station will grow and evolve throughout its

277
indefinite lifetime, and new customers and payloads will join

the program. The Space Station and customers will require

continuing support for software development, hardware and

software integration, system test, and training for both ground

and onboard operators.

The level of physical distribution of functions, both geographic

and local, will drive the selection of networking concepts.

Physical distribution must be designed to enhance developmental

and operational autonomy, especially to facilitate the

anticipated Space Station growth and evolution.

Processing and interpreting payload data, while not an SSDS

function, will require a major expansion of current capability.

Recommendations from Task l include:

l) Structured system analysis has proved to be a very useful tool for

developing system concepts and functions. This approach should

continue to be used for the design of the SSDS preliminary.

2) The concepts from Task 1 should be presented to potential Space

Station customers for comment and feedback.

3) The Mission Requirements data base should be extended and refined to

provide more definitive requirements, such as:

• Live TV frame rates

• Remote, real-time, interactive operating time

• Ancillary data requirements

• Data delivery time, performance, and form requirements.

4) A special emphasis study is needed to identify and characterize

customer classes and to develop operating concepts and requirements

for each customer class.

278
REFERENCES

,

.

.

.

B

e

e

o

1

lO.

If.

12.

13.

14.

"Space Station Definition and Preliminary Design" NASA JSC RFP

9-BF-lO-4-Ol P, September 15, 1984.

"Customer Requirements for Standard Services from the Space Station

Information System (SSIS)" JSC GSFC Space Station Office Revision 2,

March 8, 1985.

"Space Station Program Mission Requirements" Space Station Task Force

Mission Requirements (MRWG) Working Group and NASA LaRC, computerized

data base, May 1984.

Chris Gane and Trish Sarson, Structured Systems Analysis: Tools and

Techniques McAuto, McDonnell Douglas Corporation, St. Louis, Missouri,

1977.

"Space Station Data System Analysis/Architecture Study" NASA JSC RFP No.

9-BC28-25-3-1gP, August 24, 1983.

"Space Station Program Description Document" NASA TM-86652, Bks. 3 and 6,

March 1984.

"E&D Subsystems Definition Study For Space Station" NASA JSC 18740,

December, 1982.

"Data Systems Concepts For Space Stations" Phase l Final Report, NASA

GSFC NAS5-27194, March II, 1983.

"Space Station Information System (SSIS) Final Study Report" NASA JPL

D-1737, August 1984.

"Space Station Subsystem Interface Definition Study" NASA JSC 1909g, July

1983.

"GPS NAVSTAR Global Positioning System User's Overview" U.S. Air Force

YEE-82-O09, April 25, 1983.

"Tracking and Data Relay Satellite (TDRSS) User's Guide" NASA GSFC STDN

No. lOl.2, January 1980.

"Earth Observing System - Status Review" NASA GSFC briefing manual, April

13, 1984.

"Task 4 - System Definition Report Function Design Characteristics,

Appendix G, MDAC Report MDC H1942, dated May, 1985.

279
DICTIONARY OF ACRONYMS AND TERMS

CMS

COP

CPU

DFD

DHC

DMS

DSN

ECLSS

EMU

EVA

GPS

GSE

ICD

IOC

IVA

KSA

MA

MDAC

MMU

MPAC

MRWG

NSTS

OMV

ORU

OTV

POCC

POP

RDC

RMS

R/T

SDE

SPC

SS

SSA

SSCC

SSDS

SSlS

SSP

SSPE

TDAS

TDRS

TDRSS

TMIS

Customer Mission Specialist

Co-orbiting Platform

Central Processor Unit

Data Flow Diagram

Data Handling Center

Data Management System (see Definition)

Deep Space Network

Environmental Control and Life Support System

Extravehicular Mobility Unit (Space Suit)

Extravehicular Activity

Global Positioning System

Ground Support Equipment (used especially here to refer to

integration test support)

Interface Control Document

Initial Operating Capabi.lity

Intravehicular Activity

Ku-band, Single Access

Multiple Access (S-band)

McDonnell Douglas Astronautics Company

Manned Maneuvering Unit

Multipurpose Applications Console

Mission Requirements Working Group

National Space Transportation System

Orbital Maneuvering Vehicle (formerly TMS)

Orbital Replaceable Unit

Orbit Transfer Vehicle

Payload Operations Control Center

Polar Orbiting Platform

Regional Data Center

Remote Manipulator System

Real-Time

Software Development Environment

Stored Program Commands

Space Station

S-band, Single Access

Space Station Control Center

Space Station Data System

Space Station Information System

Space Station Program

Space Station Program Element

Tracking and Data Acquisition Satellite

Tracking and Data Relay Satellite

Tracking and Data Relay Satellite System

Technical and Management Information System

2e_ I_RECEDING PA_... BLAre.;,( NOT Fll._'i_,)
DEFINITIONS

Level 0 Data Processing - Raw data with reconstructed sensor formats, time

ordering, full resolution, and ancillary data.

Level IA Data Processing - Reversibly calibrated in physical units (level 0

can be reconstructed).

Level IB Data Processing - Irreversibly calibrated in physical units.

Constellation - Spacecraft in the same orbit and within communications range

of the Space Station.

Core - That portion of the Space Station system which maintains the

environment in which the customer operates.

Customer - Individual/organization with Space Station payload responsibility;

cradle to grave.

Data Management System (DMS) - Onboard system that provides the processing,

storage, and handling of digital data.

Function - A single duty which is implemented, controlled, sensed, computed,

monitored, or aided by electronic devices.

Operator - NASA or contractor personnel who manage, coordinate and affect

Space Station program operations and assist customers in accomplishing mission

objectives.

User - Any person or organization who requires the transitory use of the

services provided by the Space Station and who is authorized to use those

services.

Data Privacy - Limited access to information to some level short of a complete

guarantee of security.

Security - The protection of resources from damages and the protection of data

against accidental or intentional disclosure to unauthorized persons or

unauthorized modification or destruction.

283 ECEDtNG PAGE BL_o_ NOT FILP,_',:>