IER 1985

t

MDC H1343A

I

I

I

m

SPACE STATION DATA SYSTEM

ANALYSIS/ARCHITECTURE STUDY

Task 4- System Definition Report

(NASA-CR-1778q4) SPACE STATICN DATA SXSTEM

ANAL_SIS/ARCHZ_C_URE STUDY. IASK 4:

S¥STEB DEFINITICN _EPC_T |_cDoanell-Douglas

AstEonautics Co.) 574 p HC A25/MF A01

CSCL 22B G3/t8

N86-20479

Unclas

04596

i
MCDONNELLL_

DOUGLAS J_

CORPORATION

SPACE STATION DATA SYSTEM

ANALYSIS/ARCHITECTURE STUDY

Task 4 -- System Definition Report

DECEMBER 1985 MDC H1343A

REPLACES MDC H1942

DATED MAY 1985

UPDATED AUGUST 1985

MCDONNELL DOUGLAS ASTRONAUTICS COMPANY- HUNTINGTON BEACH

5301 Bolsa A venue 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 asslsted 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 Flight 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 FAGI_ B_ _K}T

iii
iv
CONTENTS

Section l

Section 2

Section 3

Section 4

Section 5

Section 6

INTRODUCTION

SYSTEM DEFINITION APPROACH/METHODOLOGY

2.1

2.2

2.3

2.4

2.5

2.6

Objectives

Relationships to Other Tasks

Task Approach

Growth Accommodation

Design Traceability

Supporting Tools and Techniques

SSDS TOP-LEVEL ARCHITECTURE OVERVIEW

3.1

3.2

3.3

3.4

3.5

3.6

3.7

System-Level Design Concept and Guidelines

SSDS External Interfaces

SSDS Element Identification and Characterization

Functional Allocation to Elements

SSDS Topology/Connectivity

SSDS Operational Concepts Overview

Key Design Drivers

END-TO-END SSDS DESIGN AND OPERATIONS PERSPECTIVE

4.1

4.2

4.3

4.4

4.5

Payload/Subsystem User Operation Scenarios

Interface Services

Data and Command Transport Services

System Control/Management Definition Within

the SSDS

Command Management

COMMUNICATIONS ASSUMPTIONS AND TRAFFIC ANALYSIS

5.1

5.2

5.3

5.4

5.5

Assumptions

Methodology

Detailed Strawman Scenario Development

Composite Communications Systems Loading

Recommendations for Further Study

ONBOARD SSDS DEFINITION

6.1

6.2

6.3

6.4

6.5

6.6

6.7

Intrnduction and Overview

Partltioning/A11ocation of Functional

Requirements into Onboard Subsystems

Subsystems Allocation into Architectural

Elements

Architecture

Operational Scenarios

Onboard SSDS Architecture

Buildup

l-1

2-I

2-1

2-2

2-3

2-8

2-I0

2-12

3-1

3-2

3-17

3-20

3-30

3-33

3-39

3-52

4-1

4-2

4-20

4-28

4-53

4-67

5-1

5-2

5-6

5-8

5-27

5-37

6-1

6-1

6-6

6-8

6-15

6-54

6-80

6-111
Section 7

Section 8

Section g

Section lO

Memory and Processing Function Sizing

Summary

Onboard Platform SSDS Definition

GROUND SSDS DEFINITION

7.1

"/.2

7.3

7.4

7.5

Overview

Ground System Definition

Key Operational Features

Straw Man Architecture

Summary

SYSTEM DEVELOPMENT CONCEPTS

8.1

8.2

8.3

Hardware Development/Procurement

Software Development

System Test, Integation and Verification (STIV)

TECHNOLOGY RECOMMENDATIONS

ISSUES AND RECOMMENDATIONS

REFERENCES

6-117

6-I 33

7-I

7-I

7-3

7-9

7-29

7-98

8-I

8-I

8-8

8-51

9-1

lO-I

R-l

vi
GLOSSARY

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

Automation and Robotics

Analysls/Archltecture

Advanced Development

Atrlock

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

Automatic Gain Control

Attempt to Generalize

Artificial Intelligence

Ada Integrated Environment

Advanced Information Processing System

Air Lock One

Alternate Landing Site

Ada Language System/Navy

Automated Management Information Center

American National Standards Institute

Acquisition of Signal

Automatic Programming

Avalanche Photo Diode

Ada Programming Support Environment

Ames Research Center

vii

_J
ART

ASCII

ASE

ASTROS

ATAC

ATC

ATP

ATPS

ATS

AVMI

AWSI

B

BARC

BB

BER

BIT

BITE

BIU

BIU

BIU

BMD

BTU

BW

C

C2

C3

C3I

C&DH

C&T

C&T

C&W

C/L

CA

CAO

CAE

CAIS

CAM

Automated Reasonlng Tool

American Standard Code for Information Exchange

Airborne Support Equipment

Advanced Star/Target Reference Optlcal Sensor

Advanced Technology Advisory Commlttee

Air Traffic Control

Authorlty to Proceed

Advanced Telemetry Processing System

Assembly Truss and Structure

Automated Visual Malntenance Information

Adoptlve Wafer Scale Integratlon

Brldge

Block Adaptlve Rate Controlled

Breadboard

Bit Error Rate

Bullt-ln Test

Bullt-ln Test Equlpment

Buffer Interface Unlt

Bus Interface Unlt

Bullt-ln Unlt

Balllstlc M1sslle Defense

British Thermal Unlt

Bandwidth

Constrained

Command and Control

Command, Control, and Communlcatlon

Command, Control, Communlcatlon, and Intelllgence

Communlcatlons and Data Handllng

Communlcatlon and Tracklng Subsystem

Communlcatlons and Tracklng

Control and Warnlng

Checklist

Customer Accommodatlon

Computer-Aided Oeslgn

Computer-Alded Engineering

Common APSE Interface Set

Computer-Aided Manufacturing

.oo VIII
CAMAC

CAP

CASB

CASE

CATL

CBD

CBEMA

CCA

CCB

CCB

CCC

CCD

CCITT

CCITT

CCMS

CCR

CCSDS

CCTV

cdlM 2

COG

COMA

COOS

CDR

COS

CE

CEI

CER

CFR

CFS

C6

CIE

CIL

ClU

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 Relatlonshlp

Code of Federal Regulations

Cambridge Ftle Server

Center of Gravity

Customer Interface Element

Crltlcal Item List

Customer Interface Unlt

Core Local Area Network

Configuration Management

Center of Mass

Configuration management Data Base

ix
CMG

CMOS

CMS

CMU

CO

COF

COL

COMM

COP

COPCC

COPOCC

COTS

CPCl

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

DAR

Control Moment Gyro

Complementary Metal-Oxide Semiconductor

Customer Mission Specialist

Carnegie-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 Unlt

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 wlth 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
DARPA

DB

DBA

DBML

DBMS

DCAS

DCDS

DCR

DDBM

DOC

DDT&E

DEC

DES

DFD

DGE

DHC

DID

OIF

DMA

ORS

DoD

DOMSAT

DOS

DOT

DPCM

DPS

DR

DR

DRAM

DRD

DS&T

DSPB

DSDL

DSDS

DSIT

DSN

DTC

Defense Advanced Research Projects Agency

Data Base

Data Base Administrator

Data Base Manipulation Language

Data Base Management System

Defense Contract Administrative Services

Distributed 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 Syste_a 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

EDF

EEE

EHF

EHSI

EIA

EL

EM

EMC

EMCFA

EME

EMI

EMR

EMS

EMU

EMUDS

EO

EOL

EOS

EPA

EPS

ERBE

ERRP

ESR

ESTL

EVA

F/T

FACC

FADS

Design to Cost/Life Cycle Cost

Design To Grow

Entlty/Relattonshtp

Electronic Attitude Direction Indicator

Error Correction Codes

Environmental Control and Life-Support System

European Computers Manufacturing Assoc.

Engineering Change Proposals

Environmental Control System

Engineering Data Function

Electrical, Electronic, and Electromechantcal

Extremely High Frequency

Electronic Horizontal Situation Indicator

Electronic Industry Association

Electrolumlnescent

Electromagnetic

Electromagnetic Compatibility

Electromagnetic Compatibility Frequency Analysis

Earth Mean Equator

Electromagnetic Interference

Executive Management Review

Engineering Master Schedule

Extravehicular Mobtltty Unit

Extravehicular Maneuvering Unit Decontamination System

Electro-optic

End of Ltfe

Earth Observing System

Environmental Protection Agency

Electrical Power System

Earth Radiation 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

FDF

FDMA

FEID

FETMOS

FF

FFT

FIFO

FIPS

fl

FM

FMEA

FMECA

FO

FO/FS/R

FOC

FODB

FODS

FPR

FQR

FSD

FSE

FSED

FSIM

FSW

FTA

FTMP

FTSC

GaAs

GaAsP

GaInP

GaP

GAPP

Federal Acquisition Regulatlon

Functional Configuration Audit

F11ght Computer Operating System

Flight Control Rooms

Fiber Distributed Data Interface

Flight Dynamics Factllty

Frequency-Division Multtple Access

Flight Equipment Interface Device

Floating Gate Electton Tunneling Metal Oxide Semiconductor

Free Flier

Fast Fourier Transform

First In First Out

Federal Information Processing Standards

foot lambert -Untt of Illumination

Facility Management

Failure Modes and Effects Analysis

Failure Mode Effects and Criticality Analysis

Fiber-Optics

Fall-Operational/Fall Safe/Restorable

Ftber-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

xiii
Gbps

GBSS

GEO

GEP

GFC

GFE

GFP

GFY

GIDEP

GMM

GMS

GMT

GI_

GN&C

GPC

GPP

GPS

GRO

GSC

GSE

GSFC

GTOSS

H/W

HAL

HDDR

HDDR

HEP

HFE

HIPO

HIRIS

HH1

HH

HOL

HOS

HPP

HRIS

I

Glgablts Per Second

Ground Based Support System

Geosynchronous Earth Orbit

Gas Election Phosphor

Ground Forward Commands

Government-Furnished Equipment

Government-Furnished Property

Government Fiscal Year

Government/Industry Oata 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 Fllght Center

Generalized Tethered Object System Simulation

Hardware

High-Order Algorithmic Language

Help Desk Discrepancy Report

Hlgh Density Digital Recording

Heterogeneous Element Processor

Hun_n Factors Engineering

Hierarchical Input Process Output

High Resolution Imaging Spectrometer

Habitation Module One

Habitation Module

High Order Language

Htgh Order Systems

High Performance Processors

Htgh Resolution Ima91ng Spectrometer

Interactive

xiv
I/F

I/0

IBM

IC

ICAM

ICB

/CO

ICOT

ICS

ID

IO

IDM

IDMS

IEEE

IEMU

IF

IFIPS

ILD

IMU

INS

IOC

lOP

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-Aided Manufacturing

Internal Contractor Board

Interface Control Document

Institute (for new generation) Computer Technology

Interpretive Computer Simulation

Interface Diagram

Identification

Intelligent Database Machine

Informetlon and Data Management System

Institute of Electrical and Electronic Englneers

Integrated Extravehicular Mobility Unit

Intermediate Frequency

International Federation of Industrial Processes Society

Injector Laser Diode

Inertial Measurement Unit

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

xg
IVA

IWS

JPL

JSC

KAPSE

KEE

KIPS

KOPS

KSA

KSC

Kbps

Klpc

LAN

LaRC

LCC

LCD

LOEF

LDR

LEO

LEO

LeRC

LIDAR

LIFO

LIPS

LISP

LIsP

LLC

LMI

LN2

LNA

kOE

LOE

LOS

LPC

LPS

LRU

LSA

Intravehlcular Activity

Intelligent Work Statlon

Jet Propulsion Laboratory

(Lyndon B.) Johnson Space Center

Kernal APSE

Knowledge Englneerlng Envlronment

Knowledge Informatlon Processlng System

Thousands of Operations Per Second

Ku-band, Single Access

(John F.) Kennedy Space Center

K11oblts per second

Thousand Instructlons per cycle

Local-Area Network

Langley Research Center

Life-Cycle Cost

L1quld Crystal Display

Long-Duration Exposure Facility

Large Deployable Reflector

Light-Emitting Diode

Low Earth Orbit

Lewis Research Center

taser-lnstrument Olstance and Range

Last In First Out

Logical Inferences Per Second

Llst Processor

List Processor

Logical Ltnk Control

LISP Machine Inc.

Liquid Nitrogen

Low-noise Ampllfler

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

MOMC

MDRL

MFLOP

MHz

MIMO

RIPS

MIT

MITT

MLA

MMI

MMPF

MMS

MMS

MMU

Logistic Support Analysis Report

Language Senslty Editors

Large-scale Integration

LTV Aerospace and Defense Company, Vought M1sslles Advanced

Programs D1vlslon

Level 0 Processing Fac111ty

Manual

Microprocessor

Multiple Access

Managing Actlvlty

M1nlmum APSE

Mllllon Blts Per Second

M1111on Bits Per Second

McDonnell Aircraft Company

M1sslon Control Center

Mlcroelectronlcs and Computer Technology Corp.

Management Comunlcatlons and Data System

Military Computer Modules

Multl-compatlble Network Interface Unlt

McDonnell Douglas Astronautlcs Company-Huntlngton Beach

McDonnell Douglas Astronautics Company-St. Louis

Master Data Base

McDonnell Douglas Corporatlon

McDonnell Douglas M1croelectronlcs Center

McDonnell Douglas Research Laboratory

Mllllon Floating Polnt Operatlons

M1111on Hertz

Multlple-Input Multlple_Output

M1lllon (Bachlne) Instructions Per Second

Massachusetts Instltute of Technology

M1nlstry of Internatlonal Trade and Industry

Multlspectral Linear Array

Man Machine Interface

M1crogravlty and Materlals Process Facility

Module Management System

Momentum Management System

Mass Memory Unit

xvii
MMU

MNOS

MOC

MOI

MOL

MOS

MPAC

MPS

MPSR

MRMS

MRWG

MSFC

MSI

MSS

MTA

MTBF

MTTR

MTU

NASA

NASCOM

NASPR

NBO

NBS

NCC

NFSD

NGT

NHB

NISDN

NIU

NL

NLPQ

NMI

N_OS

NMR

NOS

NS

NSA

Manned Maneuvering Unit

Metal-Nltrlde Oxide Semiconductor

Mission Operations Center

Moment of Inertia

Manned Orbiting Laboratory

Metal Oxide Semiconductor

Multipurpose Application Console

Materials, Processing In Space

Multl-purpose Support Rooms

Mobile Remote Manipulator System

Mission Requirements Working Group

(George C.)Marshall Space Flight Center

Medlum-Scale Integratlon

Multlspectral Scanner

Man-Tended Approach

Mean Tlme Between Failures

Mean Time to Repalr

Master T1mlng Unlt

Natlonal Aeronautlcs and Space Administration

NASA Communlcatlons Network

NASA Procurement Regulation

NASA Basellne

Natlonal Bureau of Standards

Network Control Center

NASA FAR Supplement Olrectlve

NASA Ground Terminals

NASA Handbook

NASA Integrated System Data Network

Network Interface Unlt

Natlonal Language

Natlonal Language for Queulng Slmulatlon

NASA Management Instruction

N-Channel Metal-Oxlde Semlconductor

N-Modular Redundant

Network Operating System

Nass1-Schneldermann

National Security Administration

xviii
NSF

NSTS

NTDS

NTE

NTRL

NTSC

Nd:YAG

O&M

O/B

OASCB

OCN

OOB

ODBMS

OEL

OES

OID

OLTP

OMCC

OMV

ONR

ORU

OS

OSE

OSl

OSM

OSSA

OSTA

OSTDS

OTV

P&SA

P/L

PA

PAR

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

Neodynlum Yttrium Aluminum Garnet (laser type)

Operations and Maintenance

Onboard

Orbiter Avionics Software Control Board

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 Line Transaction Processing

Operations Management and Control Center

Orbital Maneuvering Vehicle

Office of Naval Research

Orbital Replacement Unit

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

Orbital Transfer Vehicle

Payload and Servicing Accommodations

Payl Dad

Pro(_uct Assurance

Payload Assist Module

Primary Avionics Shuttle Software

Private Branch Exchange

Personal Computer

Physical Configuration Audit

xix
PCA

PCM

PCR

PDP

PDR

PDRD

PDRSS

PILS

PIN

PLA

PLAN

PLSS

PMAD

PMC

PN

POCC

POP

POPCC

POPOCC

PRISM

PSA

PSA

PSCN

PSL

PTR

OA

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

Plazma 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

Pseudonolse

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

Reliability/Maintainability/Availability

Real Time

Untt 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

RID

RISC

RMS

RMSE

RNET

ROM

ROTV

RPMS

RS

RSA

RTX

S&E

S/C

S_

SA

SA

SAAX

SAE

SAIL

SAIS

SAR

SAS

SASE

SATS

SBC

SC

SCR

SCR

relational Data Base

Regional Oata Center

Roentgen Equlvalent (man)

Radio Frequency

Regenerative Fuel Cell

Radto Frequency Interference

Request for Proposal

Red-Green-Blue

Revtew Item Dlsposltlon

Revision Item Description

Reduced Instruction Set Computer

Remote Manipulator System

Root Mean Square Error

Reconfiguratton Network

Read Only Memory

Reuseable Orbit Transfer Vehicle

Resource Planning and Management System

Reed-Solomon

Rlvest, Skamlr and Adleman (encryptlon method)

Real Time Execution

Sensor and Effector

Spacecraft

Software

Stngle Access

Structured Analysts

Science and Technology Mission

Soctety of Automotive Engineers

Shuttle Avtontcs Integration Laboratory

Science and Appllcatlons Information System

Synthetic Aperture Radar

Software Approval Sheet

Speclflc Application Service Elemen_:s

Statlon Accommodations Test Set

Slngle Board Computer

Simulation Center

Software Change Request

Solar Cosmlc Ray

xxi
SCS

SDC

SOP

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 Nltrtde 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&QA

SRMS

SRR

SS

SSA

SSA

SSCB

SSCC

SSCR

SSCS

SSCTS

SSDMS

SSOR

SSOS

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

S)ace Station Operations Control Center

S)ace Station Operation Language

S)acelab Software Operational Notes

S)ace Station Operating System

S)ace Station Program

S)ace Station Program Element

S)ace 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

°°°

XXlll
STO

STS

SUSS

SYSREM

St

SubACS

TAI

TBD

TBU

TC

TCP

TCS

TDASS

TOM

TDNA

TDRS

TDRSS

TFEL

THURIS

TI

TM

TN

TMDE

TMIS

TNP

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 Atomtc Time

To Be Determined

Telemetry Buffer Unit

Telecommand

Transmlsslons Control Protocols

Thermal Control System

Tracking and Data Acqulsltlon Satellite System

Technology Development Nlsslon

Time-Division Multtple Access

Tracking and Oata Relay Satellite

Tracking and Data Relay Satellite System

Thin Film Electrolumenescent

The Human Role In Space (study)

Texas Instruments

Technical Manual

Themattc Mapper

Test, Measurement, and Dlagnostlc Equipment

Technical and Management Information System

Triple Nultl-Processor

Triple Nodular Redundancy

Thermal Management System

Test Planning Working Group

Technical Requirement

Texas Reconflgurable Array Computer

Transition Radiation and Ionlzatlon Calorimeter

Trade Study Control

Technical Study Implementation Plan

Twisted Shielded Pair

Tethered Satellite System

Telemetry, Tracking, and Communications

Telemetry Trafftc Control

xxiv
TTR

TWT

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

XDFS

YAPS

ZOE

ZONC

ZnS

Timed Token Ring

Travellng-Wave Tube

Non-restrlctlve

Uniform Commercial Code

User Design Review and Exercise

User Interface Language

Unique Ob3ect Names

Uninterrupted Power Source

Unique Record Name

Unique Telemetry Buffer Untt Name

Universal Coordinated Time

Validation and Verification

Vandenberg Alr Force Base

Virtual Address Exchange

Very High-Speed Integrated Circuit

Very Large-Scale Integration

Very Large-Scale Integrated Circuit

Validation, Verification and Testing

Wide Area Network

Work Breakdown Structure

Wldeband Signal Processor

Wavelength Division Multiplexing

Work Package

Work Release Order

Workstation

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
SSDS SYSTEM DEFINITION REPORT

I. 0 .[IMI"I_ODU('."TIOIM

lhe McDonnell Douglas Astronautics Company has been engaged in a Space Station

Data System Analysis/Architecture Study for the National Aeronautics and Sp_ce

Administration, Goddard Space Flight Center. This study, which emphasizes a

system engineering design for a complete, end-to-end system, is divided i,,to

six tasks:

]-ask 1.

Task 2.

]ask 3.

Task 4.

lask 5.

Task 6.

Functional Requirements Definition

Options Development

Trade Studies

System Definition

Program Plan

Study Maintenance

An update to the Task 1 report along with the revised appendix and the

preliminary reports on tasks 2, 3 and 4, were submitted to NASA on 1 May

1985. As a result of the Review Item Descriptions (RIDs) from the

NASA/Industry review of these reports, the SSDS Workshop Presentation and lhe

continuing study efforts at MDAC, certain sections of Task 1 Appendix, Task 3

and Task 4 Reports have been updated and supplemented with additional data.

In addition, several new trade studies (Task 3) have been completed. The

updates and the newly completed trade studies form the package for this final

submittal.

This volume contains updates to the Task 4 (System Definition) Report.

key task 1 products that form the basis for this definition report are

summarized in Figure (I-1). A summary of documentation availability is

summarized in Figure (1-2).

The

McDonnell Douglas was assisted in Task 1 by the Ford Aerospace and

Communications Corporation, IBM Federal System Division and RCA.

1-I
Non-SSIS Elements

L

Subsystems •

(Sensors and

Eftectors)

Study Design Objective

• SSIS to SSDS Interfaces

• Customer

• Operator

• Payloads

• Subsystems Sensors/

Effectore

• Institutional Services,

Facilities and Functions

• SSDS Functional Requirements

• Function List

(Hlerarchlal and Data Flow

Diagrams)

• Function Data Sheets

• Customer Requirements

(Standard Services)

• Supporting Analysis

• Key Pedormance Requirements

• Traceability Matrices

Figure 1-1. Summary of Key Task 1 Products

• End-To-End SSIS Concept

• Functional Topology

• Functional Architecture

• Operating Concept

• Operator Perspective

• Customer Perspective

This report has been prepared for the National Aeronautics and Space

Administration Goddard Space Flight Center under Contract No. NAS5-28082 as

part o? Task 1 activities.

Questions regarding this report should be directed to:

Glen P. Love

Study Manager

McDonnell Douglas Astronautics Company

Huntington Beach, CA g2647

(714) 896-2292

1-2
"<°tt

C

IIE

t,l

o

Iu

ill,.

1-3
2.0 SYSTEM DEFINIIION QPPROQCH/METHODOLOGY

2.1 Objectives

System definition is the process of analyzing functional/performance

requirements and deriving balanced architectural design concepts that can be

evaluated in terms of their:

a. Ability to meet requirements,

b. Performance and growth potential,

c. Technical feasibility and risk, and

d. Cost-effectiveness.

This requires a systematic decomposition and refinement of design-to

requirements such that a system design can be synthesized from the technology

available in the appropriate time frame. This report is the primary product

of this system definition process and describes the architectural framework to

support the following objectives:

a. Identification of critical long-lead SSDS items,

b, Recommendations for technology development to enhance performance

and/or cost-effectiveness.

c. Cost estimation.

d , Establish technical feasibility within performance envelopes and

physical/environmental constraints.

e. Quantify those architecture design attributes that will support

requirements iteration/refinement leading to a cost-effective balance

between requirements and design.

2-1
2.2 Relationship To Other Tasks

System definition (Task 4) is the natural extension of requirment definition

(Task 1) where design.-to requirements and characteristics are derived from a

baseline set of functional and performance requirements. This is a step-.wise

procedure that progressively leads to increased levels of design detail within

the context of an evolving architecture. The baseline requirements data base

developed by Task l is the primary input to this process and is the foundation

on which architectural concepts are established. However, it is recognized

that this is an iterative process where design attributes serve to measure the

feasibility and cost-effectiveness of the requirements baseline. One of the

key Functions of system definition will be to clearly identify and examine

those requirements that are significant cost or schedule drivers. The intent

is to strive towards an implementable, cost-effective, acceptable risk design

based on a balanced set of requirements.

As shown in figure 2.2-1, system definition is directly supported by options

development (Task 2) and trade studies (Task 3). This is a highly integrated

relationship with the system definition task providing the basic Framework and

identifying architectural needs that focus task 2/3 activities. Options

development provides the information base for technology, design and

programmatic alternatives that are required to support key design/programmatic

decisions and/or trade studies. Based on evolving architectural needs and

requirements, the options development task is a coarse filter that reduces all

possible alternatives to a focused subset most likely to contribute to system

definition. The selection of preferred options is accomplished within the

system definition process either directly or via trade studies. Those design

decisions that have significant architectural or cost implications and/or

require detailed analysis and evaluation are subjected to trade studies within

Task 3. Trade studies are performed within the context of system definition

and provide a highly visible and systematic means of selecting preferred

design/technology options. A further description of task 2 and 3

methodologies is included in their respective task reports.

2-2
Requirements Definition

(Task 1 Products)

/_ _J I Architectural

System Needs Options

//[ Def_ _ Dev_elopment I

I I I (Task 4) I _r L (leEK z) I

IlI-Ana,ysis /Focused

II I -- Partitioning/_ . .- _ /Subset of

I I I Allocation - I "Data Base for Key | I _- .. tt I" I D"ig"Decisi°nsJ_, Vp"°ns

t _ I -- Evaluation I _',---,-_kl Trade I

t I I _ Studies I

_ I I_ectura_l (Task 3) I

\/[

_'--/ Se'_m'_'t'_t_ Options and

_\ _ Supporting Data

System Definition Product_

-- Architecture Definition

-- Define Critical Long-Lead SSDS

Elements

Refined Set of Requirements

Figure 2.2-1. Supporting System Analysis Overview

Foc.sing_

• Response to Requirements

m Key Design/Cost Driver

"_ Tradeoff Criteria

• Performance

• Cost

• Growth

a Standardization

• Physical Environmental

• RAM

2.3 Task Approach

The system definition task approach is illustrated in Figure 2.3-1 and can be

characterized as systematic and incremental in nature. This process is a

controlled step-wise refinement with verification oF viability before

proceeding to the next step oF design detail. Each step is defined as the (1)

analyses/trades, (2) partitioning/ allocation, (3) design synthesis, and (4)

design evaluation necessary to provide a stable Framework For more detailed

system definition. The products oF each step include topology refinement,

Functional allocation, nodal characterization, and interconnection

characteristics. The specific steps represent a systematic

decomposition/refinement of requirements and characteristics and are defined

as Follows:

a. Space/Ground Allocation

b. Network Architecture

c. Local Area/Node Architecture

2-3
Requirements

Space/

Ground _ • Allocation to Space/Ground

[AII.__ocation J __ I_ Lin___kChara.___cteristic__..__s __

_-- _ • Network Topology

\ )t • Allocation to

LD_:_rlib)ftion _'_ I Network | Network Nodes..

and Design _ Architecture _,_" _llhlerrC°tnnrleCtilr©n

Detail/ _ _ lV'"L [.___.e ....... ]

' \1 ,oc.,

_t Area (Node) I I

Architectures __J

Allocation to

Computational/

Storage Resources

Key Trade Studies

• Automation

• Autonomy

• End-to-End Networking

• Standardization

• Distributed DBMS

• Space Communications

• Local Area Networks

• BIU

• Network Media

• Fault Tolerance

Figure 2.3-1. Incremental Design Approach

While design processes are generally iterative in nature, this approach

attempts to constrain such iteration to successive steps thus allowing

traceability oF design and driving requirements.

The first step is the space/ground segment allocation that is supported by

three major trade studies; (11) space autonomy, (2) Function automation, and

(3) AI automation. Functions were allocated to space/ground segments based on

an assessment oF autonomy/ automation goals, cost, risk, and performance

benefits. The Function automation study identified the degree to which a

Function should be automated and the AI automation study considered the

applicability oF AI technology vs. conventional techniques. The product oF

this step is a preliminary space/ground allocation and the characterization oF

Functions to be automated (either conventional or AI). These results will be

re-examined to incorporate Advanced Technology Advisory Committee (ATAC)

recommendations.

lhe second step is the definition oF an SSDS Network architecture and is

supported by a number oF key trade studies. This step includes the definition

of system network topology, the allocation oF Functions to network elements,

and the characterization of elements and their interconnecting communication

24
links. While the allocation of functions to logical elements and their

assignment to physical locations is relatively straightforward for space

elements, a wider range of alternatives is possible for ground elements. The

system neI:work topology trade study evaluated these alternatives and developed

a "reference configuration" that is described in section 3. This study

considered the technical/cost implications of communication data rates, d_ta

buffering, and ease of customer use. Alternatives were evaluated using

simulation and modeling tools. This definition process resulted in some

iteration with the space/ ground allocation step to reflect the additional

insight gained from this level of end-to-end definition.

/

The third and final step is the definition and characterization of the

localized architecture of each element defined by the network architecture.

This is based on well defined interfaces between an element and other SSDS

elements or SSDS external elements. These architectures are described for

space elements in section 6 and ground elements in section 7. The level of

definition provided varies greatly depending on the criticality and perceived

cost implications. For example, the architecture of space elements will

require significantly more design definition than some of the ground

elements. Ground systems can use more commercial hardware and software

products while onboard systems will tend to be more "customized" and _ill have

to deal with additional requirements and physical constraints imposed by the

environment.

1-he following sections describe the key activities performed during system

definition.

2.3.1 Requirements Analyses

Requirements analyses are related activities that support the estimation of

processing, storage and communication resource requirements within the context

of a specific level of architecture definition. This includes the appropriate

traffic analyses and the derivation of function design characteristics. These

activities are supported by the refinement and expansion of the data flow

diagrams initiated by Task I and the development of associated data

dictionaries. This supporting material is included in Appendices D & E.

2-6
n key element of the design process is the transformation of Functional and

performance requirements into design characteristics that can be used to

"size" the system, This generally requires making certain algorithmic

assumptions about how a function will. be implemented and the level of implied

automation. Design characteristics include such essential information as

instruction rates, timing, memory, sequencing, enablements, etc.. The set of

design characteristics estimated for each function is shown in Figure 2.3-2.

These design characteristics have been entered into our automated functions

data base and a complete tabulation is included in Appendix G. The process of

estimating these design characteristics is based on a number of available

models including similar programs (Shuttle, Space Telescope, Spacelab, etc.),

and related NASA studies as well as engineering judgements derived from team

experience.

FUNCTION NO: 4.2,4.1 • NAME: CI'_L F'_ & ATM COMF'

r

DATA SOURCES: RFP

METHODOLOGY: RFP PLUS BACKGROUND EXPERIENCE

RESPON_ TIME: _/0 DELAY ALLOWABLE: I.OE3 msec

COMMAND/CONTROL: LEVEL: A LOC_TION: 0 RATE: 0.05 kbos

DATA QUALITY: MAXIMUM BIT ERROR RAI-E: I.OE-3

SYNCHRONIZATION WITH: N/A

SYSTEM DEPENDENCY CODE: S F'HYSICAL LOCATION CODE: M

DIAGNOSTICS/SELF TEST: REQUIRED: Y NUMBER: 11

DATA PROCESSING INSTRUCTIONS PER CYCLE: _ 1.0 kipc

REPETITION RATE: IOC= I/MIN

PROCESSOR MEMORY: PROGRAM SIZE: IOC= 4 KBYTES

DATA REQUIREMENT: IOC_ 5 KBYTES

DATA STORAGE: SECONDAR¥_: IOC= 0 KBYTES

PERISHABILITY: IOC..I._= 0% IN 0 HRS

ARCHIVAL: IO_ 0 KBYTE5

# OF DISPLAYS: IOC= II

INiERVAL= 29E3 SEC

GROWTH= 1.0 kipc

GROWTH= I/MIN

GROW'[_= 4 KBYTE_

GROWTH= 5 KBYTES

GROWTH= 0 KBYTE$

GROWTH= 0% IN 0 H_S

_ROWTH= 0 KBYTE5

GROWTH= 11

Figure 2.3-2. Design Characteristics Data Base Format

2.3.2 Partitioning/Al location

Fundamental to the system definition effort is the partitioning and allocation

process. This is the process of gradually dividing a complex problem

(described by requirements) into logical groupings that can be allocated to

physical locations and resources. Again, this is an incremental process

consistent with the design approach previously described.

2-6
Fhe end result is the allocation of functions and their associated

requirements and design characteristics to realizable computational/storage

resources. However, this process must consider many factors other than

resource utilization that will directly contribute to system performance,

cost-effectiveness (life-cycle), risk, maintainability, and growth potential.

The primary criteria applied to the various steps of partitioning are

identified in Table 2.3-1. The specific rationale applied to partitioning and

allocation decisions will be described in subsequent sections of this report.

Table 2.3-1. Functional Partitioning Guidelines

Design Step Specific ParUtioning Criteria Generic Criteria

1. Space/Ground

Architecture

2. Network

Architecture

3. Local Area

Architecture

• See Autonomy/Automation

Trade Study Criteria

• Operational Concepts

• NASA Organizational Structure

• Institutional Resources

• Functional Criticality (Onboard)

• Different Computational

• Autonomous, Stand-Alone

Development

• Minimize Interface Complexity

• Measurable and Testable

Inter/aces

• Time Phasing of Buildup to IOC

• Data Base Access and Sharing

• Response Time Requirments

Structures

• Equivalent Resource

Characteristics

• HW/SW Commonality

• Technical Disciplines

• Isolate Cooperative/Highly

Dependent Functions

• Facilitate Growth and

Technology Insertion

• Sequential Control Structures

• Specialized Capabilities (I/O, AI

Machine, FFT, Etc.)

2.3.3 Design Synthesis

Design synthesis is the formulation of physical design structures that apply

hardware resources (processors, storage, interconnections) and software

techniques to the implementation of partitioned requirements. The alternative

techniques and technologies that are applicable to these design structures

were developed and characterized by Task 2 (options development). While

partitioning strives to decompose a system into logical groupings, design

synthesis tends to "recombine" these groupings within the context of a system

design. The adequacy of design concepts (network topology, processor

throughput, storage capacity, interconnection bandwidth) tend to constrain the

2-7
way in which a system is partitioned and/or synthesized. Therefore, this

activity must be highly interactive with the partitioning process to result in

a design that is realizable as well as cost-effective and growth supporting.

In a distributed environment (either geographically or locally), this

interaction is extremely important since there are many potential advantages

of system networking that can be exploited through proper partitioning. There

are also potential disadvantages that must be identified and managed. Thesc_

advantages/disadvantages will be quantified in subsequent sections o? this

report.

2.3.4 Design Evaluation

An essential element of system definition is the quantification of key design

attributes that measure a system's ability to cost-effectively satisfy

requirements. In a well-balanced design approach this includes cost

estimation and risk assessment as well as performance measurement and the

determination of physical characteristics. These programmatic concerns (cost

and risk) are primary criteria For all trade studies and key design decisions.

A credible design evaluation for a system as complex as the SSDS can often be

greatly enhanced by the proper use of simulation and modeling techniques.

Such techniques are only as good as the models employed but they can provide a

level of insight that cannot be easily attained through analyses. This is

especially true for distributed systems where relatively complex network

interactions are important design attributes (buffer sizing, response times,

resource utilization, interference effects, etc.) and are difficult to

quantify. Due to modeling uncertainties that are prevalent at this stage of

program development, such tools and techniques will not provide absolute

"answers". Their real value is in providing a "relative" assessment of

alternative concepts to support trade studies and key design decisions. Two

primary levels of simulation have been developed to support SSDS design

evaluationl This includes an end-to-end network simulation using the Data

System Dynamic Simulation (DSDS) and several LAN simulations. These modelirlg

capabilities and their assumptions are described in Appendix F.

2.4 Growth Accommodation

This Preliminary System Definition Report provides SSDS design concepts for an

IOC space station. However, this should not imply that SSDS growth

2-8
considerations have been ignored in the process. Q primary goal of this study

is to develop an IOC system definition that will cost-effectively grow to

support anticipated Future needs. In fact, the system definition process must

include a "Design.-To-Growth" (DTG) philosophy. This approach recognizes the

basic uncertainties associated with future requirements (core/mission),

projected technology capabilities, and the impact of significantly enhanced

leve].s of autonomy/automation that are necessary to develop a credible

"optimum" design. It also recognizes the inadequacy of merely relying on such

broad concepts as modularity, standardization and extendability.

The DTG approach is based on two key principles: (1) maintain a "growth

perspective", and (2) build growth considerations into all aspects of the

design process. The "growth perspective" is established through the

requirements definition (Task 1) and the options development (Task 2)

activities. Requirements and design characteristics have been developed that

reflect not only anticipated expansion of mission/core needs but also the

transition to high levels of autonomy/automation during growth phases. In

addition, a "growth scenario" was developed to establish design goals and

objectives. The options development task has identified and characterized

those technologies that could significantly influence future growth via

technology insertion. This technology profile contributes to an $SDS growth

path that is a balance of design extendability and technology infusion. The

technology recommendations provided in section g.o are intended to enhance the

SSDS growth scenario.

Growth considerations are integrated directly into the system definition

process including all supporting activities. All trade studies (Task 3) will

include growth (extendable design and technology insertion) as a key criteria

that will be highly weighted. Trade study recommendations will include growth

as well as IOC preferences. The system definition steps previously described

in this section will also include the following DTG considerations.

I , Requirements Analvsis- The derivation of function design

characteristics and traffic analyses will consider the implications

of enhanced autonomy/automation and increased mission/core

requirements.

2-9
, Partitioninq/A11ocation - Growth (design extendability and technology

insertion) is a key partitioning criteria to be applied at all levels

of system decomposition, from top-level architecture to

processor/storage allocation. Specifically, this will include the

accommodation of advanced automation that is likely to enhance

station autonomy.

Design Synthesis - All key design decisions will consider the

implications of growth. Design concepts will be Formulated for a

proposed growth scenario.

. Design Evaluation - Proposed design solutions will be tested against

growth scenarios that include technology profile accommodation as

well as anticipated design extensions (i.e., added resources to a

module, added modules to existing network, etc.).

Particular attention will be focused on ways in which advanced automation (AI

technology) can be promoted by the IOC configuration and its growth

capability. This will include the infusion of related technologies such as AI

machines and knowledge data base storage,

2,5 Design Traceability

lhe merit of an architectural design can be measured by its ability to satisfy

all system, functional and performance requirements in a cost-effective

manner. To accomplish this requires that all key design decision can be

traced to driving requirements and that all requirements can be clearly

allocated to design components. This level of visibility is necessary not

only for design evaluation, but also to identify sensitivities for potenti<_l

requirements/design tradeoffs and to accommodate Future requirement

updates/m,)difications. The system definition described in this document

includes the identification of driving requirements that directly influence a

key design decision. In addition, many such decisions are supported by

detailed trade studies and analyses. These trade studies include relevant

requirements and derived design characteristics.

2-10
The primary means for establishing visible linkages between requirements and

Lhe design process is through functional a11ocation. This is suppor'ted by the

SSDS Functional].y Automated Database System (FADS) that provides the

capability to extract functions, requirements, and design characteristics theft

are currently a11ocated to an SSDS entity (elements., facilities, modules,

subsystems). This includes physical (i.e., module) as well as logical (i.e.,

subsystem) allocations. FADS will extract information based on functional

a11ocation and generate a "minispec" as summarized in Figure 2.5-1. The

current function allocation matrix for the SSDS is included in Appendix H.

Summary reports can be generated for a11 onboard subsystems, for each SS

module (or external entity), or for each element (DHC, POCC, RDC, etc.) of the

SSDS. The mechanism for establishing functional allocation is extremely

flexib].e and will easily accommodate changes as tradeoffs and design decisions

mature. Since allocations may change during build-up and growth phases, this

will also support the development of a function transition profile for growth

considerations.

• _ _._.'_--" -! _ Subsystem I Allocation Matrix I1_-_- -| t J __ Functions Allocated to

_ _-_ [ Selected j%J Functions Subsystem Selected Subsystem

- . -_-_- =:-

.. IL a..D,spayso,, k2

iatrixl_ Input/Output 11 R..equirements jJ

/ / A,mcateato //]

Subsystem I I- Addltlonel _ Functions' //I

Requirements -_

_. II,_ .i.__y R;qu,rements

_uosvstem_ _ I I :_pecmc. Allocated to

nn.tlOut.,t _F_I...i I Re_ _,,_ Ali;her Level

To_;.-,;..... r II I-'- _/ Functions

. Subsystems, J _ / Requirements _ -*

Agencies, and I1 _-III General ' lJl._.-R, eq,u.lr:_le_ ExternalData t ll I I I Reauirements I_....j..._Appllcaoe

_ses k_l I _1 I , '_- ......... I _ All Subsystems

_ 1⁄4 I I I I Subsystem:GN&C ....

Additional El I Functional Descriptions uescr!ptmns ,

Requirements _ I .. _UlOSystem

.... I I _ _ ,--.,,,..b _ nctions I-or Subsystem LI *--.-. - .....

Functions_ _.___..._ ,__._,._.

Figure 2.5-1. Automatic Subsystem Minispec Generation

I

I

Functional

Data Base

2-11
2.6 Sup_p_grtr_tj_'Fools & Techniques

This section provides a summary description of key tools and techniques used

to support the system definition. Where appropriate, references have been

included for further description and/or supporting data.

ao FADS -The FADS is a relational database system that is organized by

SSDS function and includes procedures for generating various types of

reports. "The database includes function descriptions, requirements

and design characteristics. This database was initially established

by Task 1 (requirements definition) and appended to the data base.

Additional capabilities have been added to support the design process

(i.e., extraction of information by logical/physical a11ocations) but

have been kept separate to retain the functional integrity (no

built-in design implications) of the data base and to facilitate

changes in an evolving design process.

b, Data Flow Diagrams (DFD's) - DFD's were initially developed by Task 1

as a logical (nonphysical) model of the SSDS. They specify precisely

"what" the system has to do, leaving the designer free to specify

"how" it can be done. They also promote communications between

requirements developers, the designers and the customers (NASA,

etc.). The top-level DFD's developed by Task 1 have been refined and

significantly expanded during the requirements analysis phase of

system definition. The complete set of current DFD's is contained in

Appendix D. Note that DFD elements are numbered to facilitate

correlation with the function data base. DFD's provide the graphical

model for the connectivity of functions documented by FADS.

C , Data Dictionaries -. Data dictionaries provide additional DFD related

documentation that make up a comprehensive "picture" of a functional

system specification. They provide descriptive information re].ated

to data storage and support the formulation of database structures.

This capability has been automated within FADS and a complete

compilation is included in Appendix E.

2-12
d . Simulations/Mod_is -Simulation and modeling tools have been used

extensively to support tradeoFF analyses and design evaluation.

]hese capabilities are described in Appendix F.

2-13
3 .O SSDS T'OP-I..EVEL ARCHTIECTURE OVERVIEW

The SSDS is the combination of hardware and software that provides data

management services to Space Station subsystems and customers, both in orbit

and on the ground. In general, the data management services provided by the

SSDS are those that are needed by multiple subsystems or customers and do not

include customer unique services. Typical data management services provided

by the SSDS include data transport, data processing, data storage, and

man-machine interfaces. Figure 3-i is a conceptual representation of the SSDS

within the wider scope of a Space Station Information System (SSIS), where the

SSIS also includes customer- and subsystem-unique data services, sensors and

effectors, and institutional (multi-program) services.

JCustomers

m U m m _ i _ m I i m i

SSIS

Unique

Customer

Applications

r

I SSDS

I

I

I

I

I

m_l

Standard

Customer

Services

I

I

Customer and

Core Services

• Processing

• Data Transport

• Storage

• Operator Services

Iv

/

Institutional Services

• STS

• TDRSS

• TMIS, etc

t u.i.u.Ill N

Payload I]_'1 _ensors II

Applicationsll I _.. and II

, II I,="ec'°"II

i_-- !

I

_l Subsystem __ _I subsystem N

and II

"'] ApplicationsJ _ Sens°rs II

, Effectors II

I

._1

Figure 3-1. SSIS/SSDS Model

l'his section provides a top-level overview of the SSDS architecture that has

been developed in the MDAC/FA(SC/IBM/RCA study. The architecture is defined in

terms of (I) system-level design concepts and assumptions, (2) SSDS external

3-1
:interfaces, (3) identification and characterization of the elements of the

SS[)S, (4) functional allocation to elements, (5) SSDS topology/connectivity,

and (6) an overview of SSDS operational concepts. An overview of key design

drivers that have been identified is also included. The onboard and ground

segments of the SSDS architecture are defined in considerable detail in

sections 6 and 7, respectively. An end-to-end SSDS design perspective is

presented in section 4.

3.1S_stem-Level Desiqn Concepts and Guidelines

During the course of our study we have been guided by NASA's goals and

objectives for the Space Station program. We have evaluated these goals and

objectives with respect to their meaning to the SSDS and have derived a set oF

requirements, design concepts and guidelines that are appropriate to ensuring

that the objectives are met. 'These concepts and guidelines have been used to

influence the architecture selection and are recommended as design policy

statements to be used in future Space Station data system design and

development activities. The critical objectives and corresponding

concepts/guidelines are described in the ?ollowing paragraphs.

3.1.1 Autonomy/Automation

The SSDS architecture definition for lOC, as well as evolutionary growth,

requires a comprehensive understanding of: (I) NASA goals and objectives For

space station autonomy/automation, (2) the technology that can be applied to

achieve these goals and objectives, (3) the specific application areas most

appropriate for advanced automation, and (4) the implications that these

decisions have on SSDS architectural design (Table 3-I contains NASh-provided

terminology related to this discussion).

NASA goals and objectives related to autonomy/automation were assumed to be

those expressed in the recent Advanced Technology Advisory Committee (ATAC)

reports. The stated goal is to "create and use a new generation of machine

intelligence, robotics and automation" to maximize space station functional

capability and to promote technology for potential terrestrial applications.

Since advanced automation concepts are not well understood today (although

3-2
'Table 3-1

AUTONOMY: The ability to function as an independent unit or element, over

an extended period of time, performing a variety of actions necessary to

achieve pre-designated objectives, while responding to stimuli produced by

integrally-contained sensors.

AUTOMATION: The ability to carry out a pre-designated function or series

of actions, after being initiated by an external stimulus, without the

necessity of further human intervention.

ROBOIICS: The technology by which machines perform all aspects of an

action, including sensing, analysis, planning, direction/control, and

effecting/manipulation, with human supervision.

ARTIFICIAL INTELLIGENCE: A discipline which attempts to simulate or

duplicate the efficient problem-solving capabilities of humans.

substantial progress is being made), the IOC capability should "be designed to

capture as many advanced concepts that are necessary and available today while

allowing for the hardware scars and the software hooks that will be needed to

accept the developing technology". The report also identified specific

objectives that included the extensive use of expert systems for all onboard

subsystems. The goals and objectives for autonomy/automation will

significantly influence the onboard SSDS architecture in the following key

areas:

a.

b,

c ,

Partitioning/allocation of SSDS functions to promote NASA's IOC

autonomy/automation goals.

Architecture to accommodate evolutionary growth.

Adequate onboard resources (processing, storage) to support advanced

automation for IOC.

3-3
The final ATAC technical reports were not available in time to comprehensively

factor into this document and the system definition presented here is based on

internal trade studies. However, the influencing factors identified above

have been addressed in the system definition process. The key difference is

that onboard subsystem resources were "sized" based on conventional automation

algorithms rather than ATAC recommended expert system implementation. These

algorithmic characteristics are certainly better understood and more

available. Sufficient resource margin has been provided in the conceptual

design but the adequacy of these resources for broad application of expert

systems, as recommended by the ATAC reports, will be investigated in future

study activities.

Recognizing the influence that autonomy/automation concepts must have on the

design process, several key trade studies were initiated early in the SSDS

architecture study. These highly interrelated studies (illustrated in Figure

2-2) result in the following.

a, Function Automation - Determine degree of automation appropriate for

all SSDS functions (IOC and growth).

b. Space Autonomy - Allocation of SSDS functions to space and/or ground

(IOC and growth).

C , AI Automation - Given that a function is to be automated, determine

if AI or conventional techniques should be applied (IOC and growth).

These trade studies are highly interactive and form the basis for many key

design decisions. The preliminary results of these studies are provided in

the Task 3 report. The degree of automation and the application of

AI/conventional techniques are manifest in the ?unction design

characteristics. The allocation of ?unctions to space/ground elements

provides the basis For further partitioning/allocation.

The AI automation study focused primarily on the application of expert systems

and did not address other areas such as robotics, etc. Expert system

approaches were weighed against conventional approaches for the SSP in terms

of cost, risk and required resources. It did not address the more global

3-4
Task 1

Function

Definition

J NASA Advanced Technology

Advisory Committee On

SS Automation f

_' 1April 1985

Ground/Space I Allocated

Results Function I Functions

Allocation and /

-. . Automation I

I-inal.. Trade Study / Ground

Mesuals / Allocated

AI Automation _r |AutomaflonFuncti°ns

Recommendations| _ Decisions

J AI Trade Automation Study I

AI Technology 1L

Options (Task 2)

Degree/Type

of Function

Automation

(Design

Characteristics)

Task 4

System

Definition

Figure 3-2. Autonomy/Automation Trade Study Interaction

goals of the RTRC associated with the development of a technology base for

"terrestrial applications". The preliminary results of the trade study

recommended functions as candidates for IOC and growth advanced automation.

Some of these functions are in addition to those identified by RTAC and are of

considerable magnitude and complexity (planning/scheduling). However, while

technically challenging, their implementation would advance the general

state-of-the-art for expert systems and potentially result in significant cost

savings. We have focused on the planning/scheduling function because of the

very large potential payoff in operational man-hour savings.

Subsystem autonomy onboard the Space Station is enabled and promoted by

several features of the proposed onboard SSDS architecture including the

following: (1) standard data processors (SDP's) that can be dedicated to

subsystem application processing, (2) SDP operating systems that provide a set

of easy-to-use and easy-to-understand s_rvices for subsystem applications

software, (3) a primary data network (bus, NIU, NOS) that provides subsystems

with a predictable, responsive, high-capacity data transport service, and (4)

a set of DMS user support services such as data base maintenance and access,

man-machine interface, caution and warning, and time management and reference

signal distribution.

3-5
In sumn_ary, our preliminary architecture incorporates a high degree of space

and subsystem autonomy, includes selected advanced automation features for

IOC, and provides for the growth of automation throughout the Space Station

lifetime. Additional study will assess the increased use of AI automation in

the IOC system.

3.1.2 Standardization/Commonality

Standardization and commonality are consistently promoted as attributes that

will help the Space Station program achieve its cost and productivity goals.

The following definitions for these terms have been developed to guide our

study.

Standardization is the process of developing a uniform hardware, software,

interface, or procedural approach and enforcing its use across a set of

similar applications.

Commonality is the property that two or more applications or systems have

when they incorporate identical sub-elements (hardware or software units).

Standardization of hardware and software elements enables commonality between

subsystems and systems. Commonality can be an important factor in controlling

development costs in a large program by reducing or eliminating paralle].

development of similar items. Commonality can reduce operational costs by

reducing the training and spare parts costs. Commonality can also improve

system reliability and availability by allowing non-critical applications to

serve as backup to critical units.

Standardization has additional benefits, including improved user familiarity,

and more efficient and effective integration of new payloads and subsystems.

The key to achi(.ving these benefits is the selection of appropriate data

communications standards. These standards define how a user will interface

with the SSDS to take advantage of the SSDS services.

Data system communications standards are applicable in three major areas in

the end-to-end architecture:

3-6
Flight segmentlocal area networks

FDI_SSuplink/downlink

Terrestrial local area and wide area networks

Needsfor customer/user transparency, efficient high speed protocol

translation, and eventual migration of ground functions to the flight segment,

dictate that these standards and related conventions be as compatible as

possible across all three sets of network components. The proposed approach

to achieving this is in an end-to-end architecture that is described in

Section 4. The ISO/OSI reference model is utilized in this description.

The primary set of standards likely to be of use for lower-level ISO layer

flight segment LAN standards are (1) the IEEE B02 family of protocols which

include multiple physical link protocols united by a common logical link

control protocol (IEEE 802.2) and (2) the emerging 100 Mbps ANSI X3T9.5 fiber

optic physical and data link protocols. Although the collision sense and

token ring protocols associated with IEEE 802 may not be appropriate under the

constraints of bandwidth requirements for the SSDS, the use of the medium

access and logical link control protocols are appropriate.

The TDRSS and direct user links essentially should be viewed as noisy links

between the onboard and ground ISO/OSI networks. The selection of standards

for these links is driven by the limitations of the underlying physical

links. It is recommended that the current CCSDS standards be used for these

links with the choices of the many various options supported within the CCSDS,

and that uplink/downlink protocol conversion be supported as outlined in

Section 4. The telemetry/telecommand standards should be adopted as S,gDS

standards. Nhile customers may format the internal content of their data in

any way they wish, the basic structures of the telemetry formats should be

adhered to and the SSDS must certify that the payloads are in fact formatting

the data properly. The SSDS may consider providing source code to do the

formatting of the customer data. Core data should adhere to additional

internal format standards for identification of measurement data as described

in Section 7.

The need for a symmetric uplink/downlink capability is particularly

important. This implies:

3-7
O providing all services (such as verified vs unverified delivery) in

both directions

O using the same packet/Frame format in each direction (currently the

Formats are different For the uplink/downlink)

implementing an addressing scheme that can be used for" either space

or ground

In addition, the possibility of augmenting these telemetry/telecommand

standards should be examined so that the following are customer selectable

options:

quality of transport service (bit error rate)

delivery service (immediate delivery vs store & forward delivery)

reliability services (verified vs unverified delivery)

The ground segment LAN's are likely to be significantly less uniform than the

flight segment LAN's. The IEEE 802 family seems to provide the most

straightforward set of solutions, since they provide a broad set of physical

link layer solutions, and have been implemented on most major vendors'

processors. Additional physical layer protocols (e.g., fiber optics

protocols) can be provided for enhanced bandwidth, but maintaining the same

data link layer protocols.

A leading candidate for a SSDS wide area standard for "low speed" data is the

X.25 packet standard. Current commercial implementations of X.25 provide

service at rates up to 56 kilobits per second. Although higher data rates are

feasible, the bandwidth of X.25 is constrained by feasible switching rates,

buffering requirements, and handshaking procedures. It is unlikely that rates

over a megabit per second can be supported with'.n the forseeable Future. In

addition, portions of the network (e.g., White Sands to Regional Data Center-)

may only require relatively static routing capabilities (permanent real or"

virtual circuit standards). For higher speed data, circuit switching

standards or connectionless ("datagram") standards may be most appropriate.

Another Feasible alternative is to define multiple classes of X.25 services,

3-8
removing elements of the X.25 protocol (e.g., dynamic routing or

acknowledgement services) in order to achieve satisfactory performance for

various data rates. The high rate experiments may or may not be sent in the

form of telemetry packets and wide area standards for this data may be limited

to transport standards.

For" the ground segment it thus appears feasible to adopt an evolutionary

approach to selection of standards, expanding the quality of services as

packet switching technology improves. A distinction between high and low data

rate services that is technology-dependent could be adopted; high data rates

would simply be defined as those for which standard X.25 services could not be

provided with off-the-shelf switching equipment. High data rate users would

be limited to non-dynamic services although they would have access to low rate

command and data transfer channels which would provide fully transparent

packet network support. As switching technology improves (or as new high

performance packet standards are introduced) further capabilities For high

rate services could be introduced with the net effect of removing the

distinctions between high rate and low rate services and standards.

The standards selected for direct interface to customers should be in

conformance with the ISO/OSI model and should use commercially available

standards if possible. Thus if NASA specific standards are used within the

data distribution networks, the SSDS should support protocol conversion to

commercial standards before delivery of data to customers.

These data communications standards are necessary in the Space Station program

so that the user can effectively plan, develop, integrate, and utilize their

Space Station experiment or application. A continuing, focused effort is

needed to further define, publicize, explain, update, and maintain these

standards.

There are several promising areas for commonality that have been identified,

including data processing hardware, operating systems, programming language,

user command and control language, and work station hardware. While it is

recognized that growth versions of the SSP will certainly have to accommodate

heterogenous data system elements, it is concluded that the IOC and growth

3-9
planning for a large degree of standardization/commonality should be

followed. 1his is particularly true ?or the SSPSubsystems. Rigid

justification procedures For any waivers should be established. _t this point

in the development it is not likely that the "off-the-shelf" excuse can be

made palatable. The need for subsystem development and testing independence

will still allow the enforceability of standards/commonality especially at

levels such as accepted data bus standards and processor Standard Instruction

of Architectures (ISA's). Further discussion on selection and application o?

standards/commonality is included in Section 6 and 7. The results of

applicable trade studies are in the Task 3 report.

3.1.3 Security/Privac_

Security and privacy are defined as follows:

Security is the protection of SSDS resources, data, and information I)

from damage, 2) from disclosure to unauthorized individuals, and 3)

against unauthorized modification.

PrivacE is the limitation of access to data or information to some level,

short of a complete guarantee as implied by the term security.

A key design driver with respect to security/privacy implementation is an

assessment of both the threats to security/privacy and the relative value of

data, or loss if its privacy is violated.

The threat assessment involves evaluation of the likelihood of various types

of security/privacy violation at each node and for each data type within the

SSDS network. The threat categories include potential physical damage as well

as logical penetration of implemented safeguards.

The value assessment is the association of a value to each type of data and

information, or equivalent, and a loss value for breach of security/privacy

?or each data or information type. This assessment highlights those SSDS

areas most in need of protection, thereby most impacting SSDS design

features. 'The differing value of customer data suggests that differing levels

3-10
of privacy protect:ion will be implemented within the SSDS depending on data

type and customer.

Detailed threat and data value assessments have not been performed. Q NASQ

threat assessment is being performed under contract to Kennedy Space Center

(KSC) and will be available in preliminary form for the Phase B contractors by

the end of calendar year 1985. As the KSC threat assessment matures, and as

the customer base solidifies and their data privacy requirements become known,

possible security/privacy impacts on the SSDS design will need to be

reassessed.

The following key policy statements define the basic framework for the

security/privacy impacts on the present SSDS system design. Key policy issues

are presented subsequently.

, Different nodes and communication paths will require different levels of

security/privacy. Protection of the Space Station base and platforms is

accorded the highest priority with respect to secure commanding and

operations, i.e., the highest levels of SSDS security required are For

onboard resource control and operations authorizations. The ultimate

control for onboard decisions is presumed to rest with the crew, with

ground takeover possible if the crew become incapacitated.

2. The SSDS will assure privacy of data, audio, and video links, but not

ultimate security of customer information.

3 , The user is responsible for higher levels of information content

protection. Encryption is one technique available to the user. The SSDS

will facilitate user implementation of encryption by providing standard

inter?aces For encryption equipment.

4. No military security requirements are incorporated into the baseline

design.

5. The key constraints which limit the amount of privacy/security provided as

a standard service are life-cycle cost impacts, cost versus benefit of

3-11
6,

protection by customer and data class, and potential system performance

degradation.

International security/privacy requirements have been assumed to be

contained within the spectrum of U.S. commercial and other user

requirements.

Ke_ev___Po_icyIssues

1. The role and extent of National Security Agency (NSA) versus NASA

responsibility for communications system security needs to be determined.

2. The levels of personnel and physical security at each SSDS node needs to

be established.

o

,

,

,

If NSA Trusted Computer System evaluated subsystems are required for the

SSDS, the available computer system options will be significantly reduced.

NASA, NSA, ESA, etc., interagency coordination needs to be established in

the area of security/privacy implementation.

The extent of NASA cooperation with NSA with respect to encryption chip

technology utilization and dependence needs to be determined.

Upgradeability for possible future military requirements needs to be

considered in the SSDS design.

3.1.4 Evolutionary Growth

One of the key requirements imposed on the SSDS is to provide sufficient

growth capability to support the future needs of the program in a

cost-effective manner. This includes growth in functional capability,

available internal resources, and the ability to handle increased external

interface demands. While applicable to both ground and space elements, the

primary focus is on the more constrained environment of space where

improvements and new capabilities may be accommodated by

3-12
modification/replacement of existing modules or the addition of new ones. In

any case, it must be recognized that future data system needs over the

expected life-time of the space station cannot be accurately forecast and it

will be difficult to determine "how much" growth potential is adequate.

Therefore, SSDS architectural concepts need to consider multiple mechanisms

for accommodating growth. The key growth objectives For the SSDS may be

summarized as follows:

l . The SSDS should facilitate growth in data service requirements

throughout the life of the Space Station.

2. The SSDS should facilitate the insertion of new technology.

3 . The SSDS should support the evolution to higher levels of autonomy

and automation.

The system developer's viewpoint of the space station evolutionary process is

that phased development, new customers and improvement needs will result in

data system requirements For more increased functional capability and/or

resources. This section describes the concepts for extending the SSDS

capability to meet these requirements. An alternative viewpoint From the

customer perspective, however, is that "growth" can be measured in terms of

increased information derived from mission data. This can, of course, have

the same effect as the traditional viewpoint if the result is increased data

rates requiring additional SSDS Functional/resource capabilities. The

"information content" of the mission data handled by the SSDS could also be

improved through additional onboard payload data processing and/or data

compression without necessarily increasing data rates. This could be

particularly beneficial if applied to the high data rate missions. It is not

likely that such payload unique Functions would be included in the SSDS;

however, they must be considered in a well-balanced, evolutionary process as a

viable alternative to SSDS expansion.

The SSDS architecture concepts that we recommend to enhance growth capability

are the Following.

3-13
I . Partition systems, subsystems ' and modules for maximum functional

autonomy at each level. The critical partitioning task determines

the degree of autonomy of each functional module, and hence, the ease

by which it can be replaced or expanded for growth reasons without

inter-related impacts on other elements.

2. A hierarchial orqanization of processing elements. This approach

supports both vertical and horizontal expansion and allows functional

autonomy.

, Selection and enforcement of widely-accepted standards for

interfaces, communication protocols, languages, etc_ The standards

that are selected must have widespread support and staying power in

the commercial and/or DOD areas.

4. Extensive "hooks and handles" in the IOC hardware and software.

Machine-readable test-points, status monitors, environmental

monitors, and unit identifiers are examples of these "hooks and

handles" that are needed to allow growth in automation.

Machine-capable controls should be considered for all IOC manual

control functions for the same reason.

. D_esign features to promote increased information content of the

data. For example, allowance for special purpose data processors,

image data compression hardware and software, and robust

general-purpose processing capability. (Programmatic features such

as a user charge policy that provides a strong incentive for users to

maximize the information content of their data should also be

considered.)

6, Large capacity marcjins in the IOC SSDS backbone data networks. We

recommend that the capacity of the IOC core data network and customer

data network each exceed the expected IOC load by a factor of at

least 150%

3-14
These concepts have been incorporated in the onboard SSDS architecture and,

perhaps to a lesser extent, in the ground SSDS architecture since it does not

have the same weight, power, volume, and accessibility constraints. The

ground segment, however, must be uniquely responsive to increasing automation,

to increasing autonomy of the space segment, and to changes in the

communications infrastructure. Program operating costs associated with ground

staffing will continue to be a concern. The ground segment must accommodate

this drive toward lower staffing by supporting increased space autonomy and

increased automation of ground functions. The concepts of modularity and use

of widely-accepted standards are equally applicable to ground and space.

lhe ground segment will also need to adapt to changes in communications

capabilities, such as TDRSS evolution or TDAS in the NASA world, and the

rapidly changing commercial communication environment. Examples of the latter

are more and new kinds of commercial communications satellite service,

expanding commercial fiber optic networks, growing commercial digital

services, and new standards such as Integrated Services Digital Network

(ISDN). The ground segment needs to be capable of supporting Space Station

data distribution in a way that allows the program to take advantage of the

performance and cost benefits o? these new commercial services.

The development of TDAS or a TDAS-like capability that allows direct broadcast

of Space Station data to several regional sites will allow the ground SSDS

data capture, sorting, and routing functions to be re-allocated. First-level

sorting and routing would be moved from the Data Handling Center to the space

segment. Data capture and the next level of sorting and routing would be

distributed to the Level Zero Processing Centers. The IOC ground SSDS

architecture allows this kind of function re-allocation and relocation.

3,1,5 Transparency. The SSDS should have the property that it appears to

be "transparent" to a user; that is, the user should be able to communicate

Hith his payload or subsystem via the SSDS such that the SSDS has minimal

affect on the customer to payload interfaces. For example, when a customer"

connects his work station to his payload at his facility, the operation should

be functionally identical to the on-orbit phase when the customer, at a work

station at his facility, is interacting with his payload on or'bib. Some

imp].ications of this objective on the SSDS are as follows:

3-15
The SSDS should transport customer-generated commands and data to the

payload with no format changes and with minimal delays and

constraints. Any artifacts added by the data transport service must

be removed prior to delivery to the payload.

The SSDS should transport data packets or messages from the payload

to the customer with no format changes and with minimal delays.

Artifacts that are added by the data transport service, such as error

correction coding, bit reversal, or packet sequence re-ordering, must

be removed by the SSDS prior to delivery to the customer.

Several SSDS design concepts are suggested to promote the "transparency" of

the system. These concepts include the following:

i . The use of packet formats with self-contained, autonomous packets

created by the source (customer or payload).

2. The use of standard interface formats and protocols.

. Minimization of command checking by the selection of a command

management approach that allows most commands to pass through

unchecked and applies the constraint/restriction checks to a small,

pre-de?ined set of commands that have mode (resource) change

requirements or hazard/safety potential.

4 , Excluding from SSDS the need to merge payload data with data from

other sources prior to delivery to the customer. This is possible if

the external data is made available to the customer in a form and at

a time that permits him to do the merging expeditiously (either

onboard or on the ground).

, The use of first-in, first-out or random access communication buffers

to avoid data reversal.

6 , Robust communication links to avoid or minimize delays due to

bandwidth limits or link unavailability.

3"16
7, Real-time foward error- correction coders and decoders to provide

essentially error-free data communication.

8 . A network operating system (NOS) for the onboard and ground LAN's and

a wide-area network manager that provides a range of network services

for the user in an invisible manner to the user. The network

services include session control, network resource management,

routing, synchronization, flow control, and error control. Section 4

describes the implementation of these services.

3.1.6 Telescience. Telescience is the capability for

scientist/investigators to (1) control and monitor their space instrumentation

From their institution and (2) to have access to data (bases) in many

locations for analysis at their home institution. This concept involves near

real time operability, transparency, data delivery and data base access across

many differing logical interfaces. The system definition of Section 6.0 _nd

Section 7.0 accommodates the Telescience concept as detailed in Section 4.0.

3.2 SSDS External Interfaces

This section describes the functional relationship between the SSDS and the

key external elements that have direct interfaces with the SSDS. The concept

of SSDS standard services is discussed and the primary SSDS standard services

are described. A summary of the partitioning criteria that were used to do

the interface functional partitioning is included.

3.2.1 Identification of Interfaces. Figure 3-1 showed that the SSDS has

external interfaces with customers, payloads, subsystem sensors and effectors,

space station operators, and institutional services. These interface

categories are expanded in Table 3.2-i.

3.2.2 Functional Partitioning Guidelines. For the external interfaces, the

functional partitioning is driven by the needs and constraints of the external

element For the case where that element is external to the Space Station

program. For instance, the SSDS must, For the most part, adapt to the

existing capabilities, interfaces, and operational procedures for its

3-17
Table 3.2-1 SSDS External Interfaces

Cu s tome r s

f

Customers at customer facilities

Customers at POCC's

Customers at RDC's

Customers onboard the Space Station

Pay load s

• On the Space Station

• On the POP

• On the COP

Subsystem Sensors and Effectors

• On the Space Station

• On the POP

• On the COP

Space Station Operators

Onboard crew

At the SSOCC, POPOCC, or COPOCC

Institutional Services, Facilities, and Functions

• NSTS

• NSTS Mission Control Center

• TDRSS

• Network Control Center

• GPS

• TMIS

• NORAD

3-18
interfaces with institutional services such as TDRSS, GPS, and the NSIS.

Customer and payload interfaces must be adaptable to a wide-range of needs,

capabilities, and operational procedures. Space station operator interfaces

are driven by productivity, flexibility, training, safety, and system security

considerations. The subsystem sensor and effector interface is defined so

that all data services that support sensors and effectors that are generally

considered to be "general-purpose" data processing have been allocated to the

SSDS and "special.-purpose" processing or signal processing functions are

allocated to the sensors and effectors side of the interface. This last

guideline (for sensors and effectors) should not be taken as a recommended

guideline for Space Station subsystem partitioning but is intended to provide

a broadly-scoped definition of the SSDS. Table 3.2-2 summarizes these key

partitioning considerations.

3.2.3 SSDS Standard Services. The SSDS provides a set of standard services

for users (customers, operators, payloads, subsystems). The functional

interface definition is based on the existence of these standard services. It

must be recognized that, in general, the use of standard services by a Space

Station customer is optional. The customer may select from the set of

standard services, using the ones that meet his needs and providing

alternative capabilities when he judges it necessary to achieve his objectives.

In some instances, payloads will be required to use particular standard

services to insure that the overall Space Station integrity can be

maintained. For instance, a payload having a potentially hazardous command

sequence will have its commands screened by the SSDS command processing

service so that risk to Space Station systems and crew are minimized.

Table 3.2-3 provides _ summary of SSOS standard services. The generic

functional interfaces described in the next section assume maximum use of

these services by SSDS users.

3.2.4 Functional SSDS External Interfaces. Figures 3--3 through 3--7

describe the major features of the Functional interfaces between the SSDS and

the major external element categories. The description identifies the key

high-level functions assigned at each side of the interface and the types of

data that must flow across the interface to support that functional

3-19
Table 3.2--2 Partitioning Guidelines for

SSDS External Interfaces

SSDS Interface Category

• Customers and Payloads

Functional Partitioninq Considerations

• Customer/payload operational needs

• Customer/payload data rates,

quantities, types

• Customer development and integration

needs

• Customer physical location

• Degree of Transparency

• Overall cost to SSP and customers

• Space Station Operators • Operator productivity

• Operator training and skill level

• System safety and security

• Overall cost to SSP

• Subsystem Sensors and Effectors • Uniqueness or generality of data

service needed

• Overall cost to SSP

• Institutional Services and

Facilities

• Established systems and procedures

• Overall cost to NASA

allocation. Appendix C contains an expanded description of the functional

SSDS external interfaces.

3.3 SSDS Element Identification and Characterization

The SSDS resides in a more global entity called the Space Station Information

System (SSIS) which includes all of the end-to-end data services for Space

Station customers and subsystems. To define the basic elements of the SSDS,

we began with the basic set of Space Station Program Elements (SSPE's)

identified by NASA, including the core manned station, co-orbiting platforms,

3-20
lable 3.2-3 SSDS Standard Services

Data Handling

Capture raw data and process to level O (routine).

Provide a quick-look capability for level O data.

Process customer data to level IA (customer option.)

Provide data analysis utilities.

Provide data processing hardware and operating systems to support

subsystem applications.

Provide short-term (customer delivery plans one week) archiving of level 0

and SSDS-produced level IA customer data.

Provide a two-year archive of engineering/ancillary data.

Provide catalog, catalog query, inventory, and retrieval services for" all

archived data.

Provide on-line storage for customer data for 12 hours.

Ancillary Data

Collect, format, and process ancillary data (Space Station engineering and

operation3 data).

Provide on-board time management and time reference distribution.

Provide electronic access to ancillary data.

Provide customers a means to electronically access Space Station

administrative, operations, and engineering data files.

Data Distribution

Provide local (within a program element, e.g., Space Station) and

wide-area data transport services to support distribution of mission,

engineering, operations, command and control, and other types of data plus

audio and video data.

Provide distribution network control services.

Provide a means for users to request communications services.

3-21
rable 3.2-3 (continued)

Command and Control

Provide standard work stations for customer and operator control and

monitor, both in space and on the ground.

Provide command management to ensure that all payload and subsystem

commands are compatible and safe.

Provide a capability for real-time interaction between customer and

payload, or between operator and subsystem.

Provide onboard resources to support stored command sequences.

Operations Support

Provide data base access and tools to support mission planning and

scheduling.

Support integrated operations planning, scheduling, and resource

allocation.

Provide users with visibility into future plans, schedules, and resource

availability.

Support fault detection, isolation, recovery, and repair for subsystems

and payload.

Monitor payload and subsystem usage of Space Station resources. Support

appropriate responses to resource usage deviations.

Provide resource utilization history reports.

Provide payload and subsystem event history reports.

Testinc h Simulation, and Trainin 9 Support

Provide hardware and software interface verification tools.

Provide a remotely-accessible real-time simulation of SSDS software

interfaces.

Provide simulation and facilities to support customer and operator

training.

Provide tools to support development of software and procedures.

3-22
SSDS

Key Functions:

a Support Payload

Development

n Integrated Mission

Planning and Scheduling

• Integrated Command

Management

• Mission Data Capture,

Transport, and Level 0

or 1A Processing

a Mission Data Archlving

(Limited)

• Ancillary Date Collection,

Processing, Archiving

• Distribution Network

Management

DATA FLOW

Utilization Dat_

:Simulation Payload Status Models f "_

Quick-Look D_,/

• Mission Data

• Ancillary Data

• Operations Data

• Planning Data

/

\

• Plans/Schedules

• Resource Requests

• Payload Commands and Data

• Database Queries

CUSTOMER

Includes:

• Onboard Customer Crew

end Operators

• Customer• Located at

Their Own Facilities

• Customer• Located at

Regional Data Centers

Figure 3-3. $SDS External Interface With Customers

SSDS

Key Functions:

a integrated Command

Management

• Ancillary Data Collection,

Processing, Distribution,

and Archiving

• Mission Data Captive,

Transport, and Level 0 or

1A Processing

• Man-Machine Interface

• Distribution Network

Management

/

\

OATA FLOW

• Commands and Data \

a Ancillary Data

• Resource Status /

• Resource Requests

• Mission Data

• Engineering Data

• Database Queries

PAYLOAD

Includes:

m Constellation Interface

m Orbital Maneuvering

Vehicle Communication

Interface

• OMV Berth (Umbilical)

• Orbital Transfer Vehicle

Communication Interface

m Polar Orbiting Platform

and Co-Orbiting Platform

• Space Station Attached

Payload•

Figure 3-4. SSDS External Interface With Payloads

and polar-orbiting platforms. Operational analyses led to the identification

of a complete set of elements that constituted the SSIS. This set of elements

is shown in Table 3.3-1 and includes the basic ground system elements required

for mission control and for customer data handling and delivery.

3-23.
SSDS

Key Functions:

a Provide Man-Machine

Interface

a Provide Planning/

Scheduling Support

w Provide Mission and

System Status Reports

• Maintain Online Database

• Maintain Engineering Data

Archive

• Provide Data Transport

Sendce

DATA FLOW

• Subsystem Status

• Missions Status

• Operations Data

a Plans and Schedules

\

/

• Plans/Schedules Updates

• Subsystem Commands

• Resource Requests

• Database Queries

OPERATOR

includes:

• Space Station Core

Operators

• Onboard Crew

a EVA Crew

• Logistics Operators

• Regional Data Center

Operators

• Training Instructors

Figure 3-5. SSDS External Interface With Operators

SSDS DATA FLOW

Key Functions:

• Integrate Command

Management

• Provide Man-Machine

Interface

• Manege DownUnk Data

• Provide Date Transport

Service

• Provide Online Database

• Provide Engineering Data

Archive

• Commands

• Supporting Data

• Sensor Output

• Sensor and Effector Status

Figure 3-6. SSDS External Interface With Subsystem Sensors and Effectors

GENERIC

SENSORS AND EFFECTORS

includes:

• All Subsystem

instruments and Devices

A set of criteria was developed to sort the SSIS elements into two categories;

(I) within the SSDS and (2) external to the SSDS. These criteria are

summarized as follows:

Elements that provide data services for core subsystems or that

provide "standard" (no cost) data services to customers are in the

SSDS. Additional "standard" customers services, such as long-term

archiving, will be available at additional costs. These additional

services are not in the SSD$.

3-24
SSDS

Key Functions:

• Forecast Service

Requirements

• Generate Service Requests

• Provide SSPE Status

DATA FLOW

I Plans and Schedules

• Service Requests

I Mission Data

I Operational Data

I SSP System Status

I Plans and Schedules

I Service Request Response

• InslituUonll System Status

• Mission Data

• Operational Data

INSTITUTIONAL

SERVICE

Includes:

• Tracking and Data

Relay Satellite System

• Technical and

Management Information

System

• National Space

Transportation System

• North American Air

Oefense Command

• Network Control Center

Figure 3-7. SSDS External Interface With institutional Services

Elements that provide data services that are unique to a particular

customer or payload are not in the SSDS.

Elements that are multi-program institutional services, such as

TDRSS, are not in the SSDS.

Using these criteria, the SSDS elements were identified (Table 3.3-2). Each

element and its general role in the SSDS is discussed below. For the purpose

of developing a "strawman" system definition, locations have been assumed for

these elements.

The Space Station - The Space Station node serves as a communications

concentration point for multiple payloads, core subsystems, and other

identified elements. These include the OMV, OTV, free fliers; with

options for STS and the COP. The Space Station receives data from

the payloads and constellation elements, and relays the data to the

gorund, together with core systems data. The Space Station routes

the commands and data for payloads, core systems, and other SSPE's.

The Space Station Network 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.

3-25
Table 3.3-1 SSIS Elements

Space Station (SS)

Polar Orbiting Platform(s) (POP)

Co-Orbiting Platform(s) (COP)

Data Handling Center (DHC)

Space Station Operations Control Center (SSOCC)

POP Operations Control Center (POPOCC)

COP Operations Control Center (COPOCC)

Payload Operations Control Center(s) (POCC)

Regional Data Center(s) (RDC)

Level O Processing Facility (LZPF)

Ground Services Center (GSC)

Engineering Data Center (EDC)

Development, Simulation, Integration, and Training (DSIT)

Global Positioning System (GPS)

Free-Flyer(s) (FF)

Tracking and Data Relay Satellite System (TDRSS)

Orbital Maneuvering Vehicle (OMV)

Orbit Transfer Vehicle (OTV)

Remote Customer Facilities

NSTS Orbiter

Deep Space Network (DSN)

Technical and Management Information System (TMIS)

Launch Integration Facilities

Contractor Facilities

Commercial and Institutional Communications Links

Real-time operations of the payloads require limited two-way data

relay, including audio and video links.

Polar Orbitinq Platform(s) - The POP is a polar platform in

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

atmospheric observation. POP has no interaction with the Space

Station on orbit, but will share some ground data handling facilities.

3-26
Table 3.3-2 SSDS Elements

Space Station (SS)

Polar Orbiting Platform(s) (POP)

Co-Orbiting Platform(s) (COP)

Data Handling Center (DHC)

Level O Processing Facilities (LZPF)

Space Station Operations Control Center (SSOCC)

POP Control Center (POPCC)

COP Control Center (COPCC)

Payload Operations Control Center(s) (POCC)

Engineering Data Center (EDC)

Development, Simulation, Integration, and Training (DSIT)

Ground Services Center (GSC)

The Space Station Network must support real-time transmission of

operations data and commands for the POP payloads as well as near

real-time transmission of quicklook science data and delayed

transmission of stored commands and data. Based on the mission

model, it is assumed that there will be two POP's at IOC, three at

growth.

Co-Orbiting Platform(s) - It is assumed that if the COP maintains

continuous line-of-sight with the Space Station, the station can be

used as a communications relay node. Options also exist for a direct

COP to TDRSS link. It is assumed that the direct TDRSS link will be

used if the COP is not in continuous line-of-sight with the Space

Station. The space station network must support real-time

transmission of operations data and commands for the COP payloads as

well as near real-time transmission of quicklook science data and

delayed transmission of stored commands and data.

Data Handlinq Center - The Data Handling Center receives, buffers and

retransmits uplink and downlink data. High speed downlink data is

3-27
o

routed based on predetermined schedules, low speed downlink data is

routed on the basis of information which is contained in the CCSDS

telemetry packet header. The DHC is located at White Sands.

Space Station Operations Control Center (SSOCC) - The SSOCC is

responsible for ground support of the Space Station operations and

control. The SSOCC is located at 3SC.

POP Operations Control Center (POPOCC) -The POP Operations Control

Center is responsible for ground support of the platform operations

and control. It is assumed that there will be one POPOCC for each

POP. The POPOCC is located at GSFC.

COP Operations Control Center (COPOCC) - The COP Operations Control

Center is responsible for the ground support of the platform

operations and control. The COPOCC is located at GSFC.

Payload Operations Control Centers (POCC's) - The POCC's are

responsible for the ground support of payload operations and

control. This will include interactive real-time commanding and

quick-look analysis of science data. The POCC's will receive a

select subset of core ancillary data and will coordinate operations

with the related Space Station or platform control center. It is

assumed that there will be multiple POCC's. The POCCs are

distributed among NASA centers, RDCs and customer sites.

Level 0 Processinq Facilities - Level 0 Processing Facilities (LZPFs)

functions are standard interfaces (which are basically the same as

for a POCC) and Level 0 Processing. High rate LZPFs are co-located

with RDCs at GSFC, 3PL, and LARC. A low rate LZPF is centralized at

GSFC to serve the other RDCs and customers. High rate LZPFs are

co-located with RDCs at GSFC, 3PL and LARC. A low rate I_ZPF is

centralized at GSFC.

Ground Services Center - The Ground Srvices Center (GSC) provides

communications and common resource coordination for the ground

system. It serves to coordinate the scheduling of the communication

3-28
and ground facility resources shared among the Space Station, COP,

and POP operations control centers. These shared facilities include

•the Data Handing Center, and the Level 0 Processing Facilities. The

GSC also collects status information from these facilities (outages,

data quality monitoring, etc) and prepares reports of this

information to both customers and the Global System Manager at the

OCCs. The GSC also performs SSIS functions involving the collection

of usage information from the ground elements used by customers and

the processing of customer bills. The GSC is located at GSFC.

Q Engineering Data Center - The Engineering Data Center provides

archival storage of Space Station engineering data. This center will

support program and customer requests for Space Station historical

data. One Engineering Data Center is co-located with the SSOCC (at

_SC) and a second EDC is co-located with the POP & COP OCCs at GSFC.

Development. Simulation, Integration and Training - The DSIT will

support the development and integration of new and modified software,

software uplink, integration of customer payloads, end-to-end

communications checkout, use o? flight equipment in lieu of GSE, crew

training, and construction of simulation models for use at remote

sites. The SSE, a key part of this capability, is described in

Section 8. The DSIT functions will be distributed throughout the

ground system; elements of the DSIT will appear at each Control

Center, LZPF, RDC and facilities that involve software development

and simulations.

Regional Data Centers - Regional Data Centers are SSIS elements that

Fall outside the SSDS boundaries, but their location affects the SSDS

architecture. Their basic function, as assumed in this study, is the

support of a single scientific discipline or group of related

disciplines (at each RDC). The RDCs receive, analyze (processing

above Level O) and archive data from many sources, including space

entities as well as non-space sources. It is assumed that the RDCs

are mapped into the following disciplines:

3-29
RDC 1 - Astrophysics

RDC 2 - Solar

RDC 3 - Earth and Planetary

RDC 4 - Life Sciences

RDC 5 - Environmental

RDC 6 - Materials Processing

It is assumed that RDCs will be established at GSFC, JPL, LARC, JSC, MSFC

and customer sites.

3.4 Functional Allocation to Elements

The requirements definition task of the SSOS study derived and validated an

extensive set of functions that define the tasks that the SSDS needs to

perform. The functions were identified by examination of mission

requirements, operational scenarios, and subsystem interfaces, and by

decomposition of high-level functions into lower and lower levels through

structured systems analysis. The top two levels of the function set are shown

in Figure 3-B. The complete set includes over 300 functions and is describ_d

in the task I report (requirements definition).

The implementation of the functions into an SSDS architecture was approached

in an incremental manner as illustrated in Figure 3-g, with the first

allocation defining the space versus ground functions, the next step

allocating functions to elements (see paragraph 3.3), and finally, an

allocation to SSDS nodes within the elements. The key trade studies that

supported these allocation steps are shown in Figure 3.-9. These trade study

results are documented in the Task 3 report.

The space/ground function allocation is intimately related to the degree of

space autolomy and to the degree of automation of in-space functions. The

degree of automation, whether AI or conventional, has a strong bearing on the

degree of space autonomy that is achievable since on-orbit crew time is a

scarce resource. Consequently, there will be a strong motive to assign

functions that cannot be readily automated to the ground segment.

3-30
L6

--I

U.

3-31
Requirements

U

Space/ /

Ground _,_ • Allocation to Space/Ground

All____ocatio£ I _a - Lin.__.kChara.___.cterlstlc____.s __

_-- _ • Network Topology

\ )1 • AIIocaUon to

Leve!.of.. _l / Network Nodes

ulsmou.on _ I Network [ .....

aDndaiDlesign "_ Architecture ['_" Ipnhter.c:t%nlect'i_°n

-- I _.'" I

_1 Local I

Area (Node) I I

Architectures __J

U

Allocation to

Computational/

Storage Resources

Key Trade Studies

• Automation

• Autonomy

• End-to-End Networking

• Standardization

• Distributed DBMS

• Space Communications

• Local Area Networks

• BIU

• Network Media

• Fault Tolerance

Figure 3-9. Incremental Design Approach

Our approach has been to (I) perform a space/ground function a/location based

on a set of coordination criteria, (2) categorize each function implementation

as automated, interactive, or manual based primarily on crew impact, response

time requirements, and automation feasibility and cost. The ATAC draft report

provided guidance for this decision. The Space Autonomy/Function Automation

trade study in the Task 3 report shows the current a/location of functions to

the space and ground segments and the level-of-automation category for each.

Table 3.4-1 shows the criteria used in developing this a/location.

Within each of the two major SSDS segments (space and ground), functions have

been allocated to the next lower level. Ground functions have been allocated

to the various ground elements. The results of this a/location are discussed

in Section 7. Onboard functions have been allocated to subsystems and

modules. This allocation is discussed in Section 6. A current function

a/location matrix is included in Appendix H.

/he primary partitioning criteria that guided this network allocation process

is shown in Table 3.4-2. The applicability of the criteria to ground e].ement

a/location and onboard subsystem allocations are identified. The resulting

3-32
Table 3,4-I

Criteria for SpaceGround Allocation

and Function Rutomation

Criteria Comment

Criticality What is the allowable restoration time for

the function after a failure7

Impact

Co-location

Space/Ground Link Availability

What is the potential impact of a failure of

this function on crew, systems, or missions?

Should the function be co-located with its

input data source?

Is the availability/reliability of the

communications link a determinant in the

function location?

Function Autonomy Does the function have significant I/O

traffic with other functions?

Response Time

Space/Ground Link Bandwidth

Is the communication delay significant to

performance of the function?

Is the finite TDRSS bandwidth a significant

factor?

allocations need to be periodically reviewed and updated as the system

definition progresses to account for changes in program priorities and goals

and to incorporate the improved level of detail in the SSDS definition.

3.5 SSDS .To___p_ogy/Connectivity

The topology of the SSDS defines the connections (data paths) between the

elements of the SSDS. This section provides an overview of the top-level SSDS

3-33
Table 3.4-2

Partitioning Criteria

Ground Onboard

I. Partition so that stand-alone development X

of elements/subsystems is possible.

2. Partition to minimize interface complexity. X

3. Partition so that interfaces are testable. X

4. Partition so that critical and non-critical X

functions are separated.

X

5. Partition to support time-phased buildup X

to IOC.

6. Partition to efficiently use power, weight, X

volume, etc.

7. Partition so that response time require- X

ments can be met.

B. Partition so that resources and data can X

be efficiently shared.

9. Partition to facilitate system growth and X

technology insertion.

end-to-end topology and of the Space Station onboard SSDS topology. The

topology selection has been driven primarily by user data traffic needs and

analysis and growth considerations but is also affected by institutional

t

resources (e.g., TDRSS), and operational flexibility considerations. For

instance, we have assumed that the Space Station will be capable of acting as

a communication node for the COP to allow efficient use of TDRSS, but we have

3"34
included in our topology a direct COP-to-TDRSS link for added operational

flexibility and for contingency modes.

The elements of the SSDS were identified and discussed in paragraph 3.3.

Figure 3-10 shows the top-level SSDS topology that interconnects these

elements. In general, these connections are a11 duplex and are implemented in

a range of capacities and forms to best match the system needs with

capabilities. While the topology shows all space segment-to-ground segment

traffic passing through TDRSS, a direct channel between a space element and a

customer facility is not precluded (outside of SSDS). In addition, system

failure tolerance needs may dictate a direct-to-ground link as a backup to

TDRSS for operational, rather than mission-related, communications. Figure

3-10a illustrates the multiplicity of SSDS elements and identifi.es those data

paths that are expected to be design drivers due to their traffic levels.

Figure 3-I0b describes the supporting data and assumptions used to derive

these network data rate characteristics.

TDRSS

Figure 3-10. Overall SSDS Topology

\

( Customers_

/

3-35
123.6 Avg.

I Space _00 Peak

i Stati°n L _

] Coorbiting L_ /

]Platf°rm I /

POP-1 79.8 Avg./

POP-2 19.3 Avg/

300 Peak

Polar

Platforms

• Data Rates in Mbps

• Includes Audio/Video

Regional Data

Centersl

I i

I Level Zero

Processing

TDRS Facilities

51.8 Avg. Avg.

123.9 Avg. 300 Peak

NASA

Ground

Terminal

Data

Handling

Center

Customers

POCCS

Control

Centers

14.8 Avg.

31.3 Peak

56.7 Avg.

(300 Peak)

Ground Space

Services Station

Center Control

Private

Customer

Facilities

Figure 3-10a. SSIS Data Network Data Rates - IOC

Data rate entry

Space Station peak

POP peak

Space Station average

COP average

POP-t average

Data rah

300

300

23.6

1.2

79.8

All Rates in Mbps

Source or makeup

Remote Sensing Test

SAR on POP-2

Remote sensing test - 2.5

Solar terrestrialobs. - 2,5

Pinhole OccuItor - 0.875

Misc payloads - 0.475

Payload video 2.47

Core data - 0.26

Core audio/video - 14.5

1Mbps payload, 0.2 core

Stereo I.S

High res I.S.

Misc

Core data

- 54.2

- 21.7

- 3,7

0.2

POP-2 average 19.3 SAR - 16.25

Misc - 2.85

Core data 0.2

Figure 3-10b. Supporting Data for SSIS Data Network Rates - IOC

Comments

• Other Ku-band data recorded during

operation

• Other data recorded or transmitted in

S-band

• POP-1 total is 393 Mbps, recording

assumed for excess over Ku capacity

• Record capability required for

exclusion zone adequate to buffer

POP-1

• Consider providing 600 Mbps

capability to improve SAR resolution

by buffering or use of both TDRS SA

channels

• TDMX 2542 corrected to 10kbps

• Payload video 38 hr/day lab coverage

at 1 frame/sec, plus 7 hr/day at

4.5Mbps NTSC

• 2 channels surveillance video at

4.5Mbps plus 6 hr/day at 22Mbps

Duty cycles are expected to be

reduced to less than half for high-rate

missions

3-36
The ground segment topology allows the Data Handling Center to sort and

distribute downlink data directly to users and to collect uplink data from

users for routing to space elements. Many element-to-element links are

provided within the ground segment to handle not only mission data traffic but

system management and administrative traffic.

Growth can be accommodated in the ground segment topology by virtue of the

mesh-like connectivity. This allows routing flexibility as the data traffic

increases. TDRSS enhancement (i.e., TDQS) that provide direct broadcast of

space data to regional sites will be readily accommodated by this topology arld

by the distributed nature of the user data processing in the SSDS ground

segment.

lhe single access channel connectivity is shown in Figure 3-11. This

connectivity assumes that a second TDRSS ground terminal is available. Three

TDR satellites are shown as an example of potential TDRSS space segment

configurations. Either l, 2, or 3 of these SA channels may be carrying SSDS

SS COP POP-1 POP-2

TDRS-C

NGT-1 NGT-2

SS/POP1/POP2

DATA

Figure 3-11. SA Channel Connectivity

SS/POPI/POP2

DATA

1 SA Ch/SSPE Max,

.,=l.

Limited By Line-of-Sight

SSDS Sensitivity to Number of

SA Channels (1, 2 or 3)

TDRS-E • Onboard/Ground Tradeoffs

• Mass Storage Trade Study

(1 SA Worst Case for

Onboard Buffer)

• Network Topology Trade

Study (3 SA Worst Case Peak

Rate)

• Signal SA Possible

(Task 1 Assumption)

• Extensive Onboard Buffering

• Optimal Scheduling

• Core Video Uncertainties

• Recommend Minimum of 2 SA

• Reduce Onboard Buffering

Cost

• Robust Margin

• Schedule Flexibility

3-37
traffic at a given time, depending on the TDRSS Sa allocation. We have

assumed that either TDRSS ground terminal may be acquiring data from any 1DR

satelli.te and that, therefore, SSDS SA traffic can come to the DHC from either

ground terminal.

The space station on-board SSDS segment Topology is shown in Figure 3-12.

This topology, which is also applicable to the platforms, consists of a group

N20 N21

N19

RC5

N4

N5 N6 N22 N23 N24

Transverse ,flCl RC6

Boom

N3

N2 N1

B5

Upper

Boom

Lower

Keel

N7

B1

C2

N28

Lab 1

C4

N32

B8

N8

N30

N27

N31

N29

B6

Lab2

Bll

B9

N33 N10

B12

N34

N36

N37 N38

Figure 3-12. Network Topology

Nll

RC3

N12 N13

Cl

N14

B7

N26

B3

N15

HM1

N16

RC4

HM2

N18

N17

3-38
of interconnected, dual redundant, token-ring busses, with major partitions

between payload (customer) networks and core networks,

A token ring will be needed in each module, at each end of the power tower

configuration and on the solar array truss. It is desirable to separate the

core data traffic from the payload traffic whose growth is difficult to

predict. This will maximize the possibility of using the core network For a

majority of subsystem data transmission (i,e,, minimize dedicated subsystem

local busses by providing a core network with predictable and acceptable

transmission delays to sensors and effectors).

This configuration will provide:

i) Maintainability by allowing network repair and checkout at the

concentrator.

2)

3)

4)

5)

Ease of connectivity during build-up.

Token ring allows for prioritization of token to support real-time

control application.

Token ring performance is superior to CSMA/CD with high traffic loads

(and superior to "voting arbitration" methods).

Emerging ANSI standards (X3T9.5) to promote growth for fiber optic

media.

Safe haven requirements can be met by having separate token rings in each

module. The onboard topology is discussed in more detail in Section 6.

Detail on the ground network topology is in Section 7. Trade studies leading

to the topology selections are documented in the Task 3 report.

3.6 SSDS Operational Concepts Overview

A key component of the SSDS architecture definition is a description of how

the SSDS operates as viewed by the user. This section provides an overview of

3-39
someof t:he key SBDS operational concepts, including mission planning and

s('heduling, payload control, customer data handling, and software

develol:)ment. More detail on these operational concepts, and discussion of

additional concepts may be found in sections 4, 6, 7, and 8.

3.6.1 Mission planning and schedulinq. The planning and scheduling process

is illustrated in Figure 3-13. It begins with identification of significant

milestones in the SSP, herein called Major Events. Major Events, by their

nature, will have an impact on the entire scope of spacecraft and mission

operations. These events include visits by the NSTS orbiter, changes of

payload compliment, changes of spacecraft equipment, and, for the Space

Station, major operations such as OMV and OTV launches and satellite servicing.

The Major Events form a framework into which the normal operations of mission

payloads and core systems must fit. Long term planning will be used to

apportion operating time and critical resources among customer and space craft

objectives. The major events and apportioned resources become the SSP Master

Plan, which is developed and maintained by the SSDS.

Soace Station

Program I rControlCenter/

NASCOM New°rk

i/M m Schedule

aJor I Communication: Allocations

vents Logistics J Requirements

/ ' Maintenance _ '

adServic,ng

" _Needs Communication

Planning

_'_t _ _ Communications

"_/_ Requ'rements

<4 "

_ I . [Allocations N_i,_J

_ 7q I ' [ Paci,it, l

Operating I I _ _ Spacecraft

Allocation _ _ Scheduling

Requests Centers

l On Board

Crew

Figure 3-13. SSPMission Planning and Scheduling

;rew Task

Negotiations

uired Core

Operations

Customers l_

Requests

)eration

Negotiations

Short Term

Schedules

3-40
A Short Term Schedule is developed beginning approximately two weeks in

advance of the time of actual operation. Specific customer mission

requirements, payload and core system maintenance and servicing requirements,

and major events are input, together with anticipated spacecraft capability.

Time scheduling function seeks an arrangement which maximizes the value of

payload output within expected resource limitations. ]his process proceeds in

two hierarchial steps:

i) Communication Link Scheduling - The TDRSS and Space Station Data

network links are shared among the Space Station and platform

systems. The first step is to schedule use of these links. To

minimize onboard storage for the very high data rate missions, bent

pipe relay is preferred. The polar platforms will not be able to

utilize this communications mode in the zone of exclusion, but will

still benefit from its use elsewhere by reducing onboard buffer

requirements. Hence, priority allocations are made to the high rate

missions, consistent with their desired operating times and

availability of appropriate targets and data network links.

The next priority is given to real time and quick look requirements

For interactive control. Real time and quick look are distinguished

by an identified need for communication between space and ground

measured in seconds, as opposed to tens of minutes. The later should

be accommodated in normal, bulk transmissions. Only data rates above

the very low rates accommodatable within a TDRS MA channel are

considered in this grouping.

The final grouping includes bulk space-<3round communication. The

communications are coordinated with the NCC and NASCOM from a single

point of contact within the SSDS.

z) Spacecraft and Facility Scheduling - Nith the communications schedule

established as the only regularly occuring, program wide interaction

among SSPEs, each facility and spacecraft can undertake its own

internal scheduling. It is noted that coordinated operation of

payloads between spacecraft may be required by customers. However,

this operation should be accommodated in the communications schedule

3-41
and within the schedules of the individual spacecraft. The

communications schedule provides for the primary coordinated activity

among the SSPEs.

Developing the short term schedule is expected to involve interaction and

negotiation among customers. This may be especially true for earth

observations, lhe customers will select targets and instruments to be used,

and the control center developing the schedule will be able to determine when

the targets will be observable. The schedule function will attempt to balance

resources available with observation opportunities to maximize the total value

of payload output. Most of the Space Station payloads will be competing for

electric power and crew time. The scheduler function will attempt to allocate

these resources in a similar optimum manner.

A very valuable adjunct to preparing the short term schedule is a set of

prestored templates of recurring operations. These templates cover at least

the use profiles for power, crew time and communications. Other resources may

be included if it is determined that these resources are important to

scheduling. However, details of the process which do not affect resources are

not included.

The templates for requested operations are assembled according to timing, crew

preference, resource demand, and resource availability considerations.

Negotiations among customers and operators are conducted to resolve

difficulties, including potential problems of safety and interference among

operations.

The scheduling and negotiation process is continued until a best obtainable

schedule is developed.' However, the schedule is held open until the last Few

hours (or less) to accommodate targets of opportunity and other unforseen

events. The dynamic result is the short term schedule. It should be noted

that these scheduling/negotiation functions are provided to the customer as an

optional service to enhance the probability of having access to available

resources at the time of need.

3-42
An Operating Events schedule is developed from the short term schedule,

containing the actual commands required to implement the short term schedule.

The origin of these commands and their management is discussed under Section

3.6,2.

3.6.2 Command manaqement. The command management process and the planning

and scheduling process are mutually complementary. Planning and scheduling

provides for the efficient use of critical resources and reserves operating

envelopes For the payload and core operations. Command management provides

the commands to implement the operating schedule. Its objectives are to

ensure that the Space Station syst?m is responsive to user commands and to

prevent damage to the Space Station systems and payloads and to prevent crew

injury as a result of those commands. Our operational concept meets these

objectives by incorporating the following features:

I • Payload and core system operations are classified by a joint

NASA/customer review as:

Restricted - Those which pose a potential hazard to the Space

Station or crew.

Constrained - Those which may interfere with other payloads or

core systems.

Non-restricted -all others.

,

,

Commands implementing these operations assume the classification of

the operation.

Non-restricted commands may be sent directly to any payloads or core

subsystem (or origi,lated by the payloads or subsystems). The SSDS

responsibility will be limited to authenticating the sender and

address.

4 , Restricted and constrained commands must be determined by the SSDS to

be executable at the time of execution. The SSDS may provide user

3-43
friendly aids to the customer and operator to assist in clearing

commands determined to be not executable under conditions forecast at

the planned time of execution.

. The SSDS will not test the customers commands for implementability or

potential damage to the payload. These responsibilities remain with

the customer.

Figure 3-14 illustrates this command management concept. The SSDS is

responsible for authentication of the customer or operator issuing a command

and the payload or core system addressed. All non-restricted commands are, by

definition, executable at any time. These are passed directly to their

destination. Restricted and constrained commands are conditionally

executable. When the planning and scheduling process has been used as an

optional service to create the necessary conditions ?or a restricted or

constrained command to be safely executed, the command is issued at its

scheduled time. I? these necessary conditions do not exist or are not

forecast to exist at the scheduled time, the command is judged to be not

executable. The scheduling process may be re-entered to determine whether the

schedule can be altered to accommodate the command. If so, the schedule is

changed and reissued and the command is reclassified to executable. The

customer or operator issuing the command may be contacted to aid in

accommodating the requested operation. I? it is not possible to accommodate

Not-Executable Restricted,

Customers Commands i] J Constrained

and Commands Authentication Commands

Operators

Non-Restricted

Commands

I

/

• Check For IExecutable

- ExecutabiUty

Restricted,

Constrained

Commands -_] Payloads Cre and Systems

Figure 3-14. Command Management Concept

3-44
the command, the originator is notified and supplied the reasons for the

command being not executable. The executability of these commands will be

subject to resouce availability and constraint conditions at the time of

execution. A "robust" SSDS design will help to maximize the probability of

unscheduled command execution. However, it should be noted that some key

resources are not contained within the SSDS (i.e. power, TDRSS, etc.).

3.6,3 Customer data handlinq. A primary responsibility of the SSDS toward

Space Station customers is to provide a highly reliable, robust, transparent

data transport service. The SSDS also provides data processing, data storage,

and ancillary data services for customers. The architectural features that

implement these services effectively and efficiently include the following:

Standard data communication protocols and formats based on the

ISO/OSI model and the CCSDS recommendations for payload and ancillary

data formatting and transport.

• Onboard buffering of payload and ancillary data.

• Limited onboard mass data storage for payload data bases and software.

Short-term ground storage of customer data to facilitate data

delivery and assurance of satisfactory quality..

Network control, data sorting, data routing, data time-ordering, and

artifact removal services as necessary to make the overall data

transport function transparent to customers.

First-level sorting of customer data at White Sands for separate

transmission to discipline-oriented RDC's.

Ancillary data provided to the onboard payloads to allow merging with

payload data at the source.

Electronic access to an ancillary data base that will be maintained

by SSDS at the EDC and spacecraft control locations..

3-45
Customer data Privacy and customer control of third-party access to

customer data. The SSDS allows customer data encryption, as long as

headers are readable, to permit the customer to provide his desired

level of security.

Customer data processing (beyond the Level 0 processing described above) .lay

be implemented in several ways. Onboard payload data processing may be done

in a payload-provided processor or in an SSDS-provided standard data

processor. In either case the processor has access, through a standard

interface, to the onboard LRN's, the communication gateways, the onboard data

base, and the onboard work stations. Ground data processing beyond Level 0

may be provided as a service by NASR (outside of SSDS) or may be done by the

customer. The RDC's and POCC's will have data processing resources (CPU's,

operating systems, peripherals, etc.) to support customer data processing.

The SSDS data archiving is limited to one week storage after receipt of

verification of acceptable data quality from the customer. Long term

archiving for up to two years is an SSIS service which may be negotiated with

the customer. The archival services will generally not be extended to "bent

pipe" relayed data, as the data capture function is bypassed at all

intermediate nodes. If exceptions to this rule are to be negotiable,

additional high rate equipment for data capture will be required.

The SSDS data transport service is symmetrical in the sense that commands may

be sent from ground to space and from space to ground. Data may likewise be

sent in either direction. For commands, the SSDS implements the CCSDS

protocol that resends the command if a transmission error is detected.

3.6.4 SOFTWARE SUPPORT ENVIRONMENT (SSE)

The purpose of the SSE is to provide an environment to support the development

of software for the Space Station. The SSE is a set of tools which are

portable and will be made available for subsystem and payload developers. The

tools included in the SSE will not dictate a specific methodology or set of

procedures. The users will be able to define their procedures (within limits)

and utilize subsets of the tools as required to support those procedures.

3"46
lhe primary goa].s of the SSE are to reduce the life cycle cost and insure the

quality of all software produced for the Space Station. This includes core,

payload, ground support, and SSE software. This will be accomplished by the

achievement of the following subgoals:

I. Provide a stable, common base for the development of the software.

2 . Provide integrated support of the entire software life cycle, from

conceptual definition through delivery, including configuration management

at all stages.

3. Provide easily attainable status at many levels by providing tools which

facilitate definition, scheduling and tracking of intermediate milestones.

4. Provide state of the art tools for each task in the software life cycle to

increase overall productivity.

5. Provide a common, convenient interface for each of the tools to avoid the

necessity of learning multiple interfaces.

6. Provide an easy way to expand the tool set in order to add new tools.

7. Provide a method of maintaining multiple versions of all documentation

such that it is available on-line or it can be printed.

8. Provide tools which support and encourage commonality and the reuse of

existing components.

9, Provide sufficient flexibility within the configuration management and

software engineering methodology support to make the SSE attractive to

payload customers as well as satisfying the needs of core software

developers.

10. Provide SSE capabilities such that support provided is independent of

users physical location.

3-47
The types of software support by the SSE will include:

Real Time Flight Software

Ground Command and Control Software

Ground Data Processing Software

Support Software

Integration and Test Software

Emulation and Model Software

Customer Application Software

The SSE will be used by development groups to generate software elements, and

by the software integration site to combine the elements into integrated

software loads. The support provided to each development user group will be

identical. This support will be provided in a manner which will allow each

group to develop their applications as autonomously as possible, but will

encourage communications and software commonality among the groups. This is

depicted in Figure 3-15. Each Function in the figure is summarized in the

Following paragraphs and is described in more detail in paragraph 8.2. The

support ?or the integration will consist of many of the same functions as

provided for the development groups, but it will also include facilities to

integrate the software produced by all and it will provide more extensive

system/integration test facilities.

A set of tools will be provided by the SSE to support Configuration Control

and to support management in user activities of planning and resource

allocation. It is assumed that to maintain configuration control over the

Space Station software, the project will utilize a series of NASA and

contractor control boards (similar to what has been used in previous NASA

projects) and an automated data base system for storing and enforcing

decisions made by the boards.

Requirements Generation/Analysis, using tools provided by the SSE, provides a

Foundation For software by identifying interface details, providing

descriptions of functions, determining design constraints, and defining

software validation requirements. On a project as large and complex as Space

3-48
I (.

, -

! •

-,=

._m

It

3"49
Station, each of the afore mentioned are crucial to maintain communication

betwe(_n the requirements initiator and the software developer.

Design and code generation is the process by which programmers create new

software and make changes to previously-created software. Because the process

is a creative one, it tends to rely heavily on manual inputs made by skilled

humans. In order to generate software for the Space Station in the most

cost-effective manner, the SSE must provide tools to assist the human

programmer in designing and coding in the most efficient and error?ree manner

possible. See Figure 8.2-6 for a summary of the process.

The System Build and Integration function of the SSE provides the tools

necessary for orderly and controlled collection and integration of software

systems (and their associated documentation and data) by their developers and

testers and For controlled delivery of those systems to their users.

Testing is the examination of program execution behavior. Testing of the Space

Station software will be very important because of its life/mission critical

nature. Facilities must be provided in the SSE for testing because of the

inability to observe the software in actual use in a safe environment (i.e. on

the ground). These test facilities should include a variety of tools that will

support cost effective testing of the core, application software, and payload

software.

The tools and capabilities provided for test and analysis represent the full

spectrum of test facilities for the project. Subsets may be defined and used

to support various levels such as unit testing, performance testing, and

independent verification and validation.

The documentation function of the SSE will provide online documentation

facilities to create a minimum paper environment with hard copying

capability. This function will be used for viewing as well as creating the

online documents. There will be a capability to assign access levels for

security of nonpublic documents. Examples of document types are:

requirements, user's guides, instruction manuals, test specifications, program

test reports, software build reports, status reports, and working papers.

3-50
Working papers are lost, historically, in most long-lived projects as the

designers move on to newer tasks, l"he documentation capabilities will support

the archiving of background information, such as design rationale and

justification, etc.

The communication function will provide the means to make the SSE appear as a

single facility to each user, regardless of site location. It will enable a

user to send and receive data, e.g., documents, messages, or- software to other"

users or functions of the SSE. This function will field requests from other"

functions to transfer data between functions and to users.

The software on the Space Station will be required to interface with a vast

number of hardware components (e.g. IMUs, rate gyros, etc.). During the life

time of the station, it will be necessary to integrate, test, operate, and

replace hardware components. Each component has specific characteristics

which must be provided for within the software. Reconfiguration data is that

set of data values required to tailor the application software and user

interface language interface environments to be compatible with a specific

hardware configuration. The process of managing the reconfiguration data and

incorporating updates into the target system (e.g. onboard DMS, integration

test sets) is called reconfiguration. The SSE must support this activity.

The SSE will provide the environment for development of the DMS. Once

developed, the DMS will be made available in the SSE for application

software/hardware development and verification. The On-board Data Managemer_t

System will consist of the software and hardware to support crew control of

the Space Station (SS) structure and other SS subsystems, lhese systems

include a set if "core elements" such as housekeeping data (e.g., time), a

data storage system, a Crew Interface system, a network for support of a

distributed processing system, and an operating system which supports many

core and payload systems. The software and hardware of the DMS will be

configured into a network of Standard Data Processors (SDP's), Network

]interface Units (NIU's), and data buses connecting sensors/effectors into a

network(s).

The SSE. can be made available to the customer community as an opt;ional

service. This will be a necessary service for any customer desiring Lo use an

3-51
onboard SSDS-provided standard data processor that may be shared among

customers. This greatly facilitates customer application, software build,

integration and checkout. If a customer provides his own dedicated onboard

processor , his use of the SSE will largely depend on his preferences for

processor type, implementation language and existing development

tools/facilities. Due to the diverse nature of the customer community and

their available resources, it is unlikely that any concensus standardization

will emerge in these areas. /he $SE service will provide little utility for

those customers, that do not adopt the level of commonality imposed by the

SSE. However, for those customers that choose to use the common SSE,

potential benefits include the development of a "reusable" software base that

can be made available to new customers and the availability of a stable

development environment.

3.7 Key Design Drivers

Several SSDS requirements or requirement categories have been identified as

"drivers" in the sense that they have a particularly strong influence on the

design and cost of the SSDS. The purpose o? identifying these drivers is

two-fold: (I) to allow a focus on the requirements so that they will be

specified at an adequate but not excessive level, and (2) to allow a focus on

particular design areas and techniques that might accommodate these

requirements at lesser complexity and cost. The key design drivers are listed

in Fable 3.7-I with the potential impacts of each driver.

All of the requirements must be implemented with a consideration of

aFfordability - in both an initial and a life-cycle cost context. The

identification of the key design drivers is intended to provide some cost

leverage by indicating the areas of SSDS requirements and design which most

significantly affect costs. They provide priorities for requirements analysis

and review, design innovation, and advanced development.

3-52
Fable 3.7-1 Key SSDSDesign Drivers

.Requirement Potential Impacts

High Mission Peak/Average Data

Rates

Communications Bandwidth/Buffering

Processing Throughput

Data Storage Capacity and I/O Rates

Automation/Autonomy • Software Development Costs

• Onboard Processing Capacity

• Flexibility/Adaptability of Onboard

Design

l Geographic Distribution of Elements • Extent of Communication Network

Network Management Complexity

Distribution of Processing and

Data Base

On-Orbit Integration Subsystem and Module Autonom_

Ground Processing/Verification

Capability

Evolutionary Growth/Technology

Accommodation

• Autonomy/modularity approach

• Selection of standards

• IOC Resource margins

3-53
4.0 END-TO-END SSDS DESIGN AND OPERATIONS PERSPECTIVE

By way of review, the approach used to develop the top-level architectural

topology of the SSDS was to: 1) define data processing functions and resource

requirements; 2) iteratively partition/subdivide the functions and allocate

them to .logical entities (nodes, elements, facilities, subsystems .... ), and

3) continue the process until all functions had been assigned to _hysical

entities and a logical interconnection matrix had evolved. The results of

this process were discussed in section 3.0 and lower-level definitions for

space and ground elements are provided in sections 6.0 and 7.0, respectively.

This top-down approach leads to well-_efined end products that can be

characterized in terms of their resource and interface requirements (within

the context of a total system architecture). However, it is equally important

to ensure that the "modularization" of the SSD$ is consistent with SSIS goals

to retain an end-to-end design perspective. This requires the development of

"unifying" design concepts across SSDS entities that facilitate the flow of

data/commands between the onboard payloads/subsystems and the ground or space

based users. This section will describe design concepts at a sufficient level

of detail to identify key end-to-end implications for system definition. This

will be accomplished within the framework shown in figure 4.0--1 and includes a

description of (I) payload/subsystem/user operations scenarios, (2) standard

SSDS interface services, and (3) data/command transport services. These throe

components will be discussed in subparagraphs 4.1, 4.2, and 4.3, respectively.

A key element of this description will be a relatively detailed examination of

the appropriate use of standard communication protocols with an end-.to-end

perspective. The technique employed here includes the step.-by-step tracing c)f

information "threads" through the SSDS network. To accomplish this, design

concepts will be introduced (based on the system definitions established in

sections 6 & 7) that are necessary to provide a detailed understanding of how

standard communications protocols can be effectively used.

4-I
Payload

Standard Payload

Services

Mission Data

Commands

Y

Data Transport Service

(Transparent to Users)

Customer

[.._ Interface

Standard Cust. I/F

Services

-- Ancillary Data

-- Time Management

Processors, Storage

Etc.

I Standard Workstations

Processing, Storage

CMD Management

Etc.

v

Network Control

Scheduling

Resource Management

Figure 4.0-1. End-to-End Architecture (Experiments)

4.1 Payload/Subsystem User Operation Scenarios

4.1.1 Introduction

This section describes an end-to-end design perspective from the customer

payload and subsystems operator points of view; it includes considerations of

the various operational scenarios encountered by customers and operators of

the SSDS, their interfaces and interactions with their payloads and

subsystems, and the end-to-end data flow and routing associated with payload

and subsystem operations. Data flow and routing that support these s('enarios

will be developed later in paragraph 4.3 in terms of a standards model that

il].ustrates the protocols used on an end-to-end basis and the degree of

standardization, compatibility, and commonality that should be realizab].e in

the SSDS.

J

This section will di.scuss only a small subset, but an important one, of al].

'the oper'ational scenarios that could be expected to occur in the SSDS; tNis

subset has been se].ected to show an in-depth understanding of the end-.-to-erld

4-2
protocol requirements. For a complete and comprehensive discussion on a more

extensive set of scenarios, the reader is referred to the Task I report,

Reference I.

The contents of this section are applicable to the ground operations and the

onboard operations for the Information and Data Management Systems (IDMS) on

the Space Station (SS), Co-Orbiting Platform (COP), Polar Orbiting Platform

(POP) and other SS Program Elements (SSPEs).

The design perspective discussed herein was developed using the criterion that

if customer interfaces (onboard and ground, and in all planning, design, test

and operation phases) are designed to be "friendly" and "easy to use" then

.broad acceptance of the SS Program by the commercial and scientific

communities can be expected.

The end-to-end operations perspective encompasses the following physical nodal

extremes: core subsystems and payload packages integrated via point-to-point

links and the onboard local area networks (LANs) in the various SSPEs,

space/ground communications and the use of special TDRSS up!ink/downlink

protocols, and the ground-to-ground worldmwide area communications network.

The wide area network includes the interconnection of subnetworks (e.g.,

ground based LANs in the various centers) via long haul satellite and

terrestrial communication links. The wide area network has unique

characteristics, as compared with public data networks, including:

significant control by NASA,

the use of high level coding such as Reed-Solomon to detect and

correct errors,

transport of both interactive and non-interactive messages,

functions such as data capture which support recovery of lost

application data,

data encryption and customer payload security,

customer data privacy,

d_ta that is transported through the network that can be interpreted

as commands and, hence, must be checked, in some inst_nces :i.n

realtime, for restrictions and constraints (station safety and

4-3
experiment cross-interference), and

.transport of critical data (with retransmission upon detection of

non-correctable error) and non-critical data.

The SSDS provides data transport services for both real time and non-realtime

messages, highly interactive (e.g., teleoperated) and non-interactive

operations, high and low rate quick-look and production data, image and

non-image data and in both realtime and (delayed) non-realtime, commercial

quality imagery, low-resolution freeze-frame and high resolution TV, audio and

teleconferencing among nodes in the SSDS. The SSIS extends the nodes to the

customers facilities, and provides data transfer services among all nodes.

4.1.2 Customer Interface Definition and Interaction

The development/operation cycle of a payload includes the following phases:

Feasibility analysis, mission planning, payload development, ground

integration and verification testing, transportation to space, onboard

integration and verification testing, payload operations (production,

maintenance, etc.) and finally, transport back to earth.

In the feasibility analysis and planning stages, resource requirements,

distribution of resources, cost of resources, and operational constraints must

be established to determine the overall feasibility of a particular mission.

Considerations here include the following:

i . Power Resources Allocation - The user power requirements inust be

known for long range planning and for near term operations control.

2, Timeline Constraints - Constraints associated with orbital position

(earth viewing), daylight or darkness or any other timeline

constraint must be integrated into the plan to develop r,i_alizab]e

operational windows.

EVA Servicing - EVA is treated as a mission resource and, whether

required on a one-time or periodic basis, must be established and

factored into mission planning and crew timeline planning to

determine resource requirements and availability.

4-4
4. Computing and Data Storage Resource Allocation - The data processing

requirements for the experiment must be developed by the user and

factored into his planning. Also any realtime constraints associated

with realtime control (such as transport lag or jitter experienced

through the SSDS network) will be provided to the user so that he carl

develop criteria for space/ground autonomy decisions. If the user

intends to use SSDS hardware resources (processing, I/O, memory,

workstation .... ) then these must be identified and integrated into

the mission plan.

. Crew Monitor and Control - If the payload operations are to be

managed by the flight crew, the crew monitor and control requirements

must be factored into crew mission timelines. In addition, crew

training must be planned and integrated into mission preparation.

. Software Development Resource Allocation - If the user wishes to use

the SSE then he must estimate the resources required to develop the

experiment applications software and these resources must be factored

into programmatic decisions and long range planning.

7° Communication Link Resource Allocation - The user must estimate the

full- and half-_uplex communication resources required to control his

payload and to transport his data from orbit to ground data handling

facilities. This will allow for mission planning and assignment of

communication network resources. These estimates, along with network

communication scheduling constraints, must be planned and integrated

into the mission plan.

, Develop, Simulate, Integrate and Train (DSI&T) --The user must

estimate the resources required in the DSI&T element. Key decisiorls

here will affect how he intends to develop and integrate his payload

(planned use of his facilities, SSDS-supplied interface simulators,

DSI&I integration services .... ).

g. Standard Services - A key decision in the customers planning phase

wi.11 be the selection of standard services provided by the S,SITS(some

4-5
jrof which were discussed above, and all of which are discussed in

paragraph 4.2).

As part of the planning and preliminary design activity the customer will have

to perform automation and allocation trade studies analogous to those

performed For non-payload functions (e.g., core subsystems). Issues to be

resolved here are the following:

° How should a payload's functions (e.g., data acquisition/processing/-

compression, command/control .... ) be distributed between the

customer's supplied payload package, onboard SSDS resources, ground

SSDS Facilities and resources, and the customers own ground

Facilities7 How should ancillary data be acquired (onboard or

ground)7

, What degree of automation should the customer incorporate into his

payload operations phases (quick look verification, production

quality tests, machine diagnostics .... )?

° What development methodology should the customer employ so that he

will have continuity through his proposal, development, Fabrication,

testing, integration, operations, data reduction, analysis, and

archiving phases? For example, can the system be built so that a

user can employ a single set of equipment and software to check his

instruments before delivery, during integration, and periodically

during operation? Can instrument calibration traceability be

achieved?

4. For the various classes of payloads, what should the relative roles

be for the scientist/astronauts, Flight crews, mission controllers,

irlstrument controllers, and the users during the operations phases?

Who will have decision-making authority for different user-relat(_d

activities and For different mission timelines?

For it_.,ms 1 and 2 above, the methodology to be used that implements a

procedure that leads to an "optimal" payload function allocation and

4-6
automation realization is similar to the one used in the Task 3 Function

Allocation and Automation trade study. The exception is that theprocedure

would be interactive between the customer and a customer information support

function. Resource costs and constraints would be clearly identified in this

interaction.

For item 4 above, the roles of crew personnel and their relative authority in

making decisions relative to payload operation, is deferred to a future

programmatic study.

4.1.3 Scheduling and Session Establishment

The customer is an individual or organization with an interest to place a

payload/experiment in an SSPE and to use the standard communication and

processing facilities, and other standard services provided by the SSIS.

Onboard, the customer payload is supported by Space Station or platform

facilities such as a pallet with power, active thermal control, communication

interfaces, and if required, a pointing and tracking capability or a

pressurized module. The customer provides an experiment compatible with the

SSPEs electrical, mechanical, thermal, dynamic and other interfaces, as

specified in the SSPE's Interface Control Drawing (ICD). On ground, the

customer can conduct his payload operations from his own facility or from one

contained within the SSIS.

The end-to-end architecture from the customer's point of view was shown in

Figure 4.0-I. Standard onboard payload services and ground interface services

are provided as shown in the figure and as further expanded later in paragraph

4.2. The data transport service presents a simple, easy-to-use, and

transparent interface both onboard and onground (i.e., the real complexities

of the command and data transport process are, in all cases, hidden From the

customer).

The customer operations with his payload carl be conducted onground from a

Payload Operation Control Center (POCC), Regional Data Center (RDC) or in his

own facility, or in space using an MPAC or his own custom workstation. This

is depicted in Figure 4.1.3-I which shows a payload connected to a local area

4-7
network (LAN) via a standard network interface unit (NIU) and operations being

conducted from onboard. This figure illustrates two standard options for

interfacing a payload: one where the customer connects his payload using only

a standard I/O interface (e.g.', RS422, MIL-STD-1553 .... ) and the other where

he supplies a11 of the data processing equipment except for the network

interface (an $$.-supplied card-set) at the LAN medium.

I Maximal Use of Onboard SSDS Resources J

Standard Service Inlerface

Customer _ L_ Customer I_

SSDS-Supplled

.____ Standard Standard Subsystem Data Processor (SDP) I

I/O

LAN Medium

SSOS-Supplied

Card Set

Minimal Use of Onboard SSDS Resources J

Customer

Work Station

Electronics Package

• I/O

• Processor/Software

• Mm Store

Customer

Supplied

LAN Medium

Figure 4.1.3-1. Customer Standard Onboard interfaces

In either case, when the customer's payload is delivered to orbit, and is

mechanically, thermally, and electrically integrated, communication with the

payload can be initiated via the end-to-end data distribution system. Command

control and sensor data are distributed using this system and data and progr',_m

storage services are available from onboard mass storage devices (for

proprietary and other reasons, the customer may elect to embed his progr'_m

code in his package and make it non-accessible to the external world or" he may

elect to encrypt it and uplink it every time his payload is activated).

4-8
The customer will provide the application software to command and control his

payload; this software can be divided into four components:

i .

2.

B.

4.

Onboard data processing

Onboard workstation processing

Ground data processing

Ground workstation processing

When the payload is active, the data processing software is resident in the

customer's processors (l and/or 3 above) and the workstation processing

software is resident in the customer's workstations (2 and/or 4 above). When

the experiment is inactive the customer's software may be stored on a mass

storage device. Data processing deals with command processing, sequencing,

data manipulation (e.g., transformation, filtering), status monitoring, and

payload production and performance data acquisition associated with the

experiment. Workstation processing includes graphics processing, display,

command entry, and interactive processing to support the experiment for

quick-look, production, diagnostic, and other operations phases.

If the customer uses standard services, including the SSE and a high order

language (HOL), he will then develop application software which may utilize

real-time statements and which must be compiled from HOL source statements

into a machine load module. The customer, therefore, must be familiar with

the software development language, including the real-time features of this

language. Software development will generally be conducted on ground but

onboard development/compilation is not excluded.

P_load Requests for Service

This subsection will discuss the operations associated with activating a

payload and attaching it and its associated control centers, workstations,

.... to the SSDS Data Distribution Network. These discussions will be in

terms of the data flow diagrams included in Appendix D. A brief discussion of

these diagrams is presented here to show the flow of requests for servi(-e.

Customer/operator requests For services or delivery of commands, are iniI:iaI:(_d

in two places (see diagrams and locate blocks 0001); schedule requests (for

4-9
future service or on-demand activation) go directly to Function 3.O, Schedule

and Execute Operations. Payload and core commands (real and non-real time)

pass through Function 2.0, Manage Customer/Operator Supplied Data For

authentication (log-on, etc) checks, and for restricted/constrained tests and

are then transported to Function 3.0 where they are scheduled For future

execution (non-real time) or are sequenced for real time execution. Payload

activation will be controlled by Function 3.4.1, Sequence Payload Operation,

and network attachment will be implemented via Function 3.4.2, Sequence Core

System Operation, whose command outputs are eventually passed to Function

4.2.5.1, Communication Network Control.

Payload sequencing operations (Function 3.4.1) involve functions like

connection of the payload to the TCS, application of prime power ..... and are

not discussed any Further in this section. 'The continuing discussion here

will be directed towards the operations in Function 4.2.5.1, Communication

Network Control, that attach the payload, the customer, and other entities

onto the network and bind these entities into a SESSION.

pa_load Session Services

Payload session services are one component of a set of services collectively

called Network Management (see Figure 4.1.3-2, especially item number 1) that

are distributed between the onboard SS function 4.2.5.1, Communication Network

Control, and various ground element functions. These generic network

management functions are further defined in Figure 4.1.3--.3 which shows a

Function characterization and allocation. In this Figure, Functions 3 and 4

are self explanatory and are not involved in session establishment. Funct:i.on

2 includes setting-up, maintaining, and disconnecting sessions, while Function

I is the implementation of ISOIOSI layers 1-7 after a session is established.

For SSDS, connections are generally established between all the entities that

are involved in command/data transactions between ground components and space

payloads or core subsystems. The tenure of a session may be momentary or it

may be permanent depending on the application. A session binds entities into

a contract to provide resources and services for a data transaction

operation. At session establishment time, protocols and other services to be

4-10
1. Session sendcss

• Request to have sessions are received.

• The session requests are validated.

• Resources are allocated to sessions.

• Subchannels. table entries, session identifiers, etc.. are assigned.

• The route for the session is selected. Alternative routes in case of

failure may also be selected. (This is for systems without dynamic

routing of packets.)

• The communicating parties are boundand their session initiated.

• When session is over, the communicating parties are unbound and

their session terminated.

• When failures Occur, session recovery is initiated.

• Accounting information is gathered for billing purposes.

• Requests for network sessions with devices of foreign architecture are

handled.

2. Handling of physical resources

• A directory of physical resources is maintained (processors. terminals,

cluster controllers, peripherals, channels, circuits, line groups, etc.)

• The management software permits these physical resources to be

activated and deactivated

• Dynamic reconfiguretion may take place when failures occur.

• Recovery action may be initiated.

• Information is provided to the network Operators to enable them to

deal with the physical resources.

• information is provided to the maintenance engineers about the

physical resources.

• Resources are monitored for performance measurement.

3. Maintenance

• Terminal facilities are provided for maintenance engineers to access

the network.

• Errors and failures are logged.

• Reports and analyses of the errors and failures are clone and made

available at the engineer terminals

• Problems are automatically reported to a network operator.

• Diagnostics and confidence tests are run, possibly triggered

automatically, possibly by an operator or engineer.

• Decisions to take down network components or circuits are made,

based on the severity or frequency of errors.

4. Secudty

• A surveillance log is maintained of all security procedural violations.

• The surveillance log is analyzed for the security officer, highlighting

occurrences needing immediate attention.

• Triggering of alarms on detection of certain types of procedural

violations.

• Piles of passwords, cryptography keys, or other security information

are securely managed.

• Terminals are provided for security officer functions,

S. Admlniotrallon

• Terminals are provided for network operators.

• The operators can display details of the network and its various

resources.

• The operator can start and stop the network.

• An operator can activate and deactivate network components.

• An operator can start and stop application programs.

• An operator can reconfigure the network dynamically (i.e., without

shutting it down).

• An operator can change specifications of network control mechanisms.

• An operator can down-line load programs.

• An operator can initiate a clump of programs in peripheral machines,

possibly transmitting the dump to a larger machine for printing.

• An operator can initiate trace or statistics-gathering programs

• An operator can initiate performance measurement aids.

• Network performance can be measured, analyzed, and possibly

experimented with.

• Information is collected for billing users and bills are prepared.

"Reference: Martin, James, Computer Networks and Distributed Processing, Software, Techniques, and Architecture,

Prentice Hall, Inc., Englewood Cliffs, N.J., 1981

Figure 4.1.3-2. Generic Network Management Functions*

Functions

REAL TIME CONTROL Includes operation of the

hardware and software functions associated with

network data flow after a session is established. This

encompasses OSI layers 1-7.

SESSION MANAGEMENT Refers to functions not

included in 1 above that are required to initiate/terminate

sessions, and provide for checkpoint/restart, automatic

recovery, and switchover.

MAINTENANCE Refers to the primarily automated

activity of keeping the network running. Nodes in the

network log errors and provide overall statistics to this

function which responds with commands to execute

diagnostics to fault-isolate failed components.

ADMINISTRATION Refers principally to Ihe human

activities associated with operating the network. The

administrator monitors network performance (e.g.,

statistics for utilization, lost data events .... ). The

administrator is a special type of end user and requires

activity reporting functions throughout the network.

Characteristics/Allocation

Real time, automated, distributed space and

ground NIUs end SDPs

Real time; automated, distributed space and

ground, but principally allocated to function

4.2.5.1, Communication Network

Control.

Real and nonreal time, automated and

interactive, allocated to space and

ground elements

Nonreal time, interactive and manual,

allocated to NCC

Figure 4.1.3-3. Network Management Functions

4-11
used in the session are agreed to by the communicating parties. Examples of

services and resources are as follows:

Full- and half--duplex, and virtual and real communication channels

with requested bandwidths

Protocol selection (EBCDIC, ASCII, NAPLBS .... )

Context selection (Virtual File Transfer .... )

Processing resources (Ops/sec) at DHC, POCC, RDC ....

Memories (main, mass, raw data buffers .... ) onboard or at DHC, POCC,

RDC ....

There are alternatives to the establishment of a session (e.g., connectionless

or datagram services) but it is felt that established sessions will provide

the transport reliability required by most customers (see Figure 4.1.3-4). A

distinction between connection and connectionless service is shown in Figure

4.1.3-5 for an (N)-Layer (N=2,3 .... 7) entity in the OSI model (the customer's

interface with the OSI model is discussed later in paragraph 4.3).

Delay Reliability Transport Service

Data Type Volume Requirements Requirements (Layer 4)

Voice S H L Connection, Class 0

Video L H L Connection, Class 0

Bulk Oigitai Data L L H Connection, Class 4

Payload Data

Quickiook

Production

Commands

Payload

-- Core

Engineering Telemelry and

Payload Performance

Data Base Queries

and Maintenance

M H M Connection, Class 0

L L-H L-H Connection, Class 0-4

S H H Connection, Class 0-4

S H M Connection, Class 0

M H H Connection, Class 4

S = Small H = High (or "Strict") Requirements

M = Medium M = Medium Requirements

L = Large L = Low Requirements

Figure 4.1.3-4. Data Types end Transport Service

4-12
One final point concerning Function 2, Session Management, in Figure 4.1.3-2

is that this function can be implemented in a centralized or distributed

manner as shown in Figure 4.1.3-6. Both approaches are used in modern data

networks and both have desirable features for the SSDS, as shown. In the

distributed approach, the payload, for example, when activated would

autonomously establish and maintain its session with the appropriate elements

(e.g., POCC, SDC, MPRC .... ) and would disconnect those elements when

requested by the POCC or the Function 3.0 scheduler. In this approach the

network nodes do not have the global visibility required for optimal resource

a11ocation and are more susceptible to security breaches. Centralized

management offers other features as shown in the figure. The multi-centered

option has been selected for the SSDS and is discussed further in paragraph

4.5.10

(N)-Layer

il Connect Request • i

Connect Confirm r

Data _-, (N)-Layer

Disconnect Request )I Confirm

Negotiate/Allocate/Reserve

Resources

a Buffers/Processors

i Data Links

i Protocol

• Quality of Service

Connection-Oriented Interaction

0 Peer-to-Peer Processes

(N)-Layer

t Data [

Acknowledge Option

(N)-Layer

Transmission of

Independent/Unrelated

Data Units

• Datagrams

• Best Effort

Activity

Connectionless-Oriented Interaction

Figure 4.1.3-5. Connection/Connectionless Service

4-13
Distributed I

Management I

* Distributed Primary-secondary DECENTRAL PRtMARY-SECONnAFiD MANAGEMENT

Management .. relationship between

Communicating parties J the parties _ _

handle sessions without _-_ . _ --

the aid of a Ihird-party _ Symmetr,cal (peer-coupled) DECENTRAL PEER-COUPLEO MANAGEMENT

• relationship between the

manager parties [--A[--A[--A[--A[--A_ -

Centralized I

Management I

Single centralized

• Sessions are set up and • Network Management

terminated by Netwock /

Management which also < Multiple Network

de•is with recovery \ Management modules

each serving users in

s given area

Key& User process

• Primlry management module

(responsible for recovery)

• Secondary, low tunction

management module

P•lh used when setting up,

terrain•ling or recovering

• session. (The Pat• flow

path my be different)

C|NTII_ UNO

MULTICENTEllED MANAGEMENT

"Martin (1981)

Figure 4.1.3-6. Centralized/Distributed Network Management Options*

• Trend is to Distribute

Session Management

• Used in ARPANET

and DECNET

• Potentially, More

Optimal Allocation of

Resources and Better

Route Selection Ior

Session

• Used in SNA

and DCA

4.1.4 Payload Development and Activation

Ground Tests

The customer software and hardware must be integrated and verified before

being transported to space and ground elements. The integration testing will

generally be done initially in the customer's facility where he can, as

required, employ commercial-quality equivalents for MPACs, onboard data

processors, or a local area network/data network simulator which emulates the

end-to-end wide-area and local-area networks including c()mmunication delays.

A second phase may be conducted where the customer performs crew training and

validates his payload interfaces and operations via the SSDS Develop, Support,

Integrate and Train facility.

Software Transport to S_Space and Ground Facilities

In the development herein, it shou].d be recalled that there are four

components of customer software that support the payload: ground and Sl:)_-_ce

workstations and ground and space processors.

4-14
The ground programs for both workstation and processors are delivered to

ground facilities by electronic transfer or by portable media (tape, etc.).

The programs are loaded into the ground facility mass storage devices and

appropriate directories are updated to allow the ground facilities management

function and system executive to recognize a request (from a ground

workstation or a telecommand from orbit) for these programs to be loaded into

the ground workstation and ground processor for execution. On the ground this

will likely be managed by a modified commercial system executive: lhis

machine management is transparent to the customer.

The customer programs to be uploaded to the space system are loaded in a

similar fashion. An electronic transfer is accomplished via a telecommand

which contains the code and will also contain labels defining restricted and

constrained command sequences embedded in the code. The incoming programs are

addressed to a mass storage utility function which places the programs on ,lass

storage and then updates appropriate directories to allow the onboard

facilities management function and system executive to recognize a request for

these programs to be loaded into the payload processors and on-orbit customer

workstations for execution. The origin of this request for loading and

execution may be a telecommand from ground or from an on-orbit workstation

configured to communicate with the ground facilities management function.

Payload Activation/Deactivation

Payloads are activated via the request sequence discussed earlier in section

4.1.3. Requests can be initiated from ground workstations or onorbit

workstations. Typical scenarios would be 1) where a customer would LOGON from

his workstation in anticipation of his upcoming scheduled session with his

payload and query the schedule function to verify there had been no schedule

changes, and 2) where a customer would LOGON to request a non-scheduled

session with his payload.

rhe sequence depicted earlier in section 4.1.3 will va].idate the authorization

J

of the customer and coordinate the planning for an unscheduled session. .IF

authorization is not approved due to scheduling or unrecognized user II], then

the user would be blocked and his workstation would receive an abort me',_s,_3e

4-15
(with abort reason). If the customer is authorized to proceed with activation

and control of his payload the onboard DMSestablishes a session with all

elements required in the session, and they are automatically configured to

support the payload operations. Workstations and processors throughout the

SSDSwill be loaded with appropriate software communication resurces will be

reserved for the duration of the session.

At this point the customer is now in contact with his supplied application

programs which can power up and sequence the experiment and gather, analyze

and process data. This data can also be acquired and delivered to ground

and/or space processors through the data distribution and communication link

for analysis. The customer may self-buffer his data or use the onboard mass

store and data base manager.

The session establishment may have included a part-time or full-time

high-bandwidth communication channel to route quick-look data to the POCC

prior to entering the production phase. Other scenarios could include

consideration for payload integration, diagnostics, checkout, maintenance,

quality, tests, combined ground crew and space crew operations, and so forth.

When the experimenter has completed his mission or his scheduled time has

elapsed, the payload will be deactivated. Prior to scheduled time expiration

the customer will receive a message alerting him that his payload is scheduled

to be deactivated at time XXX.XXX. If the programs are controlled from the

ground, then the ground site must first request that the onorbit programs be

terminated and entities in the session be disconnected. This will remove

these programs from execution and release the resources used in the session.

]he programs will still remain on the mass storage devices until these files

are requested to be purged. The customer can then deactivate the ground

programs by requesting the ground site facilities management to terminate h:is

programs. This will cause the ground resources to be released.

4.1.5 Interactive Communication

The discussion in this section is in terms of the diagrE_m in Figure 4.1.5-1

which uses processors and workstations both onboard and on ground, in this

ex_mple, at a POCC.

4-16
Core Local Area Network

I I

I"'u%'-',1

_ " !imot_c_rk

IO'°un°O" Distribution Network J

Payload

Local

Area

Network

Space

Station

I Comm

Network

Pro¢

I

I Gateway ]'--_

...__ Work Station'\i

User ]!"

Program IA

POCC

Figure 4,1.5-1. Interactive Operations

When the payload is delivered to the SS and physically connected to the LAN,

the NIUs physical address embedded in the NIU is provided to the network

manager who will associate it with an object name and one or more application

process IDs. At session establishment time, the network manager attaches each

of the customer's tasks (located in processors and workstations) to the

network. At the time a task is loaded into a processor or a workstation, the

system executive recognizes that the object address corresponding to the task

must be attached to the network and requests the network manager to do so. A

message from the network manager to the NIU programs, which are capable of

updating object address tables, accomplishes this attachment. If there (-_re

bridges or gateways that must be informed that they should receive and

retr'ansm'Lt messages for the object address being attached, then this is also

accomplished by the network manager by sending messages to the appropriate

bridge or gateways as sessions are established.

4-17
Real-time monitor and control can be accomplished from the ground or onorbit

or both depending on where the workstation software is resident for a specific

session.

4.1.6 Accommodation of Telescience

The concept of telescience derives from the notions shown in Table 4.1.6-1.

The principal components of the $SDS that accommodate the above telescience

concepts are as follows:

Table 4.1.6-1Telescience and the User

I. Payload Control from home institution

_° Data delivery to user with merged multi sensor and ancillary data,

with SSDS-supplied standard processing (option), for quick-look and

production processed data

. Transparency .....the real complexities of the data system are hidden

from the user

, Easy electronic access to numerous data archives and d_ta bases for

building comprehensive data libraries

5. Interactive and realtime operation

, User operations in concert with colleagues in a coordinated

multi-sensor and multi-discipline data capture activity

7, User selections of equipment (workstations, processors .... ) of his

choice

4-18
j_

, Control ..... A customer will have the capability to control his payload

from his own Facility or a NASa-supplied Facility, home institution,

or he can be mobile and operate at both facilities within certain

constraints such as the man-machine interfaces of the workstations at

the various locations.

2, Access--.-A customer will have free and easy access to his payloads

subject to resources, constraints and restrictions, as described

later. A principal design objective of the SSDS is that it be as

Friendly to users as is possibly; some limitations in this

"friendliness" is necessary based on considerations of safety,

equipment damage, payload cross-compatibilities and quality of data

capture, and other reasons, as outlined later. Electronic access to

SSDS/$SI$ data bases will be provided.

, Transparency---lh@ SSDS will "hide" all of the real complexities of

the command and data packet Formation and the transport of these

data. The intricacies o? the data system (i.e., layering, error

control management, encryption, data synchronization, data

reconstruction .... ) are totally hidden from the user.

4. Interactive and Realtime Operations ....A customer will be able to

communicate and control his payload as though it were physically

located in the same room as his workstation. The $SDS will only add

submseconds-to-seconds delays to the transport delay that would be

associated with an immediately adjacent experiment. As an example,

for the solar flare activity where conditions change rapidly,

capabilities will be in place to implement instrument adjustments in

a matter of minutes.

. Communication and Coordinated Team Involvement ..... Voice and video

teleconferencing will be implemented between multiple ground sit_)s

andthe space station to coordinate multiple team activity in an

integrated multi-sensor data capture of scientific phenomenon.

4-19
, Operation in a Heterogeneous Environment---_he customer will be able

to configure the operations center with the hardware/software of his

choice subject to the constraint that he comply with the network

security requirements and "open" communication protocols specified by

the SSDS. In the heterogeneous environment, computer-to-computer

networking will be accommodated via the use of international and

national standards as opposed to private and proprietary protocols.

4.2 Interface Services

lable 4.2-1 shows a summary of onboard and ground interface services. It

includes the principal SSDS services and only those SSIS services necessary to

show completeness from an end-to-end operations perspective. The services are

discussed in more detail in the following subparagraphs.

4.2.1 Mechanical, Electrical, and Thermal Services (SSIS)

The physical mounting of the payload will be defined in an interface control

drawing (ICD) which is prepared by the customer and agreed to by the Space

Station Program Office. The ICD also specifies power, signal, and thermal

interfaces including connectors. These interface standards must be conformed

to and will be tested during system integration. The power supplied to the

customer is protected against overload by remote power controllers. The

Facilities management function coordinates the use of power and therefore

experiment activation will be blocked when power is not available. This

coordination is accomplished between the system executive and the scheduling

functions.

4-20
Table 4.2-I. Interface Services Summary

ONBOARD SERVICES

i. Pallet - Mechanical, thermal, power, pointing, motion decoupling ....

(SSIS).

2. Crew - Onboard operations, IVA/EVA, servicing, diagnostics, repair ....

(SSIS).

3. TV/Audio Distribution - Internal, external, space-to-ground,

space-to-space, realtime/delayed, conferencing .... (SSIS).

4. Processors - SDPs, local RAM, standard I/O including serial/paral].el and

backplane I/Fs, distributed operating systems ....

5. Mass Store - Programs, files, instrument data, procedures ....

6. Work stations - MPACs with standard software packages: interactive

command/control, graphics, word processing ....

7. Data Base - File management and query.

e. Payload Sequencing - Activation, scheduled, targets of opportunity,

on-demand ....

9. Command Management - Restricted/constrained checks.

I0. Distribution of ancillary data including time.

11. Error Free Data Distribution - Between payload, SDPs, mass store, C&l

gateway ....

12. Logistics -. Sparing of cards/modules for SDPs, standard I/O .... (SSIS).

4-21
GROUND SERVICES

1. Data capture and error-free transport to customer designated facilities,

quick-look and production.

2. Processing level 0 (standard) and level IA (optional), archives

electronically accessible.

4. Ancillary data via electronic access.

, Software Support Environment - Local/remote access, SDP development

support: HOL compiler, simulators, assembler ..... standard programs

(library).

6. Develop, Simulate, Integrate and Train - Payload development, SSDS

integration, crew and mission specialist training, simulators ....

7. Payload Operation Facilities - Workstation, processors, mass store .....

at POCC, RDC ....

ONBOARD AND GROUND COMMON SERVICES

I. End-to-End Error Free Data Transport.

2. Security/Privacy - Physical payloads, programs, data,, procedures ....

3, End-to-End Voice/Video Services.

4. End-to-end scheduling including suport of on-demand services.

5. Control of payloads: onboard, on ground at POCC or at home institution.

4-22
In general, the customer's payload will dissipate energy and active thermal

control will be required. 'The customer will be provided with a thermal

control subsystem (lCS) interface which is activated prior to the equipment

being powered ON. In the event of an overload the customer may be deactivated

to reduce the load on the TCS. The facilities management function coordinates

the use of the thermal control capacity and may block activation of the

payload when capacity is exceeded.

4,2.2 EVA Services (SSIS)

The customer experiment can be serviced by EVA for refurbishment or repair.

4.2.3 Pallet Pointing (SSIS)

Active decoupling of platform motion can be provided by an isolated pallet for

customer payload precision pointing.

4.2.4 Operations and Crew Interaction (SSIS)

The payload can be designed to be operated from space and/or ground, with the

use of onboard/ground crews or a customer supplied onboard payload specialist,

and From the customer's own facility or an SSIS facility.

4,2,5 Ancillary Data

Two options are available for obtaining time stamped ancillary data: it can

be provided onboard For real time merge by the customer, or in non-real time

on the ground via electronic access to data archives.

4.2.6 Command Sequencing

The command and control program for a payload may be stored in an onboard SSDS

mass store, uplinked in real time for interactive operations, or embedded in

the customer's supplied payload controller.

4-23
4.2.7 Payload Activation

Activatior, of a payload carl be schedule driven with near-rea].time adjustments

to the schedule, event driven for acquisition of targets of opportunity, or on

demand subject to availability of resources and checks for cross-.interference

with other payloads and restricted modes of operation.

4.2.8 Space/Ground Communication

Space/ground communications can utilize the standard I"DRSS/T'DAS (a scheduled

resource) or the customer can supply his own space/ground communication link

(which will also be scheduled as a power consuming device and checked for

cross--interference).

4.2.9 Time Management

the customer may provide his own time reference system or use the SSDS

supplied reference which has an accuracy of +I msec. Since this reference is

m

distributed via the LAN the customer will also be required to understand the

statistics associated with delays in receiving this time reference. The

reference may contain ephemeris time plus offsets to other references (i.e.,

universal time) and will be formatted per CCSDS requirements.

4.2.10 Data Transport

Space/ground customer-to-application interfaces will utilize the CCSDS packet

formats (slightly modified, as discussed later) for message transport. Within

the data field of the packet, the customer can package his data using his own

procedures within the following option categories:

I. No processing, package "raw" data

2. Signal processed/reduced

3 : Compressed

4-24
4. Encrypted with own key

5. Error protected beyond the standard SSDS 10-.6 BER

6. Real-time merge of SSDS supplied ancillary data

Fie nlay also elect to package the data using an "open" format specified, for

examp].e, by a CCSDS Standard Format Data Unit (SFDU) or keep the format

"closed" and private to himself.

4.2.1]. Production Data lransport

Production data delivery can be real-time, or delayed by seconds, minutes,

.... next orbit, next shuttle visit, depending on priorities and other

factors. An end-to-end BER of lO-6 shall be provided by the SSDS.

4.2.]2 Ground Processing of Production Data

Standard ground processing of production data will be to Level 0 and with

added cost, to Level 1A.

4.2.13 Archiving

Standard short term ground archiving is for one week after receipt of customer

quality acceptance, and for Level 0 data and Level IA (if specified per

paragraph 4.2.12).

4.2 14 Logistics (SSIS)

Standard card set modules will be stored onboard and available (on a priority

basis as established by function criticality) for maintaining payloads, via

automated diagnostics, or interaction with trained crew person or a payload

specialist. Customers can elect to I) have a sealed payload package with no

intention of onboard servicing, 2) provide spare modules and crew maintenance

training or a payload specialist.

4-25
4.2.15 Standard Programs

"1hecustomer will be able to use standard library programs which can be linked

into his programs by referencing these library programs. Examples could be:

Fast Fourier ]ransform, digital filters, Kalman filter, eigenva].ue and

eigenvector extraction, quaternion routines (multiply, vector transformation,

e|J]ier angle extraction).

4.2.16 Data Base Support Programs

A data base capability is provided as an option to the customer. This

capability includes sequential data file management and a data base query

language. Although the data base structure is hidden from the customer, he

will have to be familiar with the data base command interface when building

application software to store and subsequently retrieve data blocks for

manipulation or transmission to a ground site (delayed delivery).

4.2.17 Customer Program Development

The customer will develop the payload applications software and SSE facilities

are available as an option to accomplish this. The customer can be resident

at this facility or these facilities may be linked to remote sites so the

customer can develop programs from the customer's site with customer supplied

terminals or the customer may subcontract for software development to a

programming organization. In the following subparagraph the term "customer"

refers to whomever is developing the customer software.

4.2.].7.1 Development Support Environment

The customer is provided with numerous options within the software development

support environment; these include:

a) Data set creation/storage capability for source programs and data

b) Security of programs (access control)

4-26
c) Editor to modify and update source code

d) Compiler to convert to object code of target processor

e) Linker to integrate program into processor load module

f) Simulation environment to verify system integration

g) Standard library program which can be linked to customer programs

Spec:ial customer supplied models can be integrated into the simulation

env ironment.

4.2.17.2 Development Language

The development support environment will support commonly used development

languages such as PASCAL and also real time languages such as Ada (Ada is a

registered trademark of the US Department of Defense, Ada Joint Program

Office). A high order command and control language for developing test and

control sequences will also be available.

4.2.17.3 System Executive

If the customer elects to only supply application programs to be executed in

an SDP, then his programs will have to be integrated into an executive

structure and an understanding of this structure by the customer will be

necessary. Included here are the techniques for:

a) Creating tasks

b) Activating a system task (control segment) which controls the

scheduling of aplication tasks.

c) Real-time control such as: events, messages, semaphores

d) Local IlO control

e) Access to distributed resources (mass store, workstation .... )

4-27
The customer will be required to become familiar with the real-time features

of the language; since these include macros that interface with the system

executive. A specification describing these features will be available to the

customer.

4.2.18 Onboard Data Processing Resources

The customer may elect to use a standard onboard data processor, mass memory

and workstation or he may elect to provide almost all of the processing

resources. These options were discussed previously, in paragraph 4.1.3.

4,3 Data and Command Transport Services

This section discusses end-to-end data and command transport services in terms

of a standards model that illustrates the protocols used and the degree of

standardization, compatibility, and commonality that should be realizeable in

the SSPEs and SSDS.

Emphasis will be on the use of international standards, specifically, the

Consultive Committee for Space Data Systems (CCSDS) Recommendations for Space

System Standards, the International Standards Organization's (ISO) Open System

Interconnect (OSI) seven-layer reference model and emerging (international and

national) specifications for the various layers, being developed by the

Institute of Electrical and Electronic Engineers (IEEE), the American National

Standards Institute (ANSI), National Bureau of Standards (NBS), European

Computer Manufacturers Association (ECMA), and others.

The end-to-.end operations perspective encompasses the following physical nodal

extremes: core subsystems and payload packages integrated via point-to-point

links and the onboard local area networks (LANs) in the various SSPEs,

space/ground communications and the use of special TDRSS uplink/downlink

protocols, and the ground-to-ground world-wide area communications network.

The wide area network includes long haul communications that interconnects

ground..-.based local area networks and end-point nodes.

lhe SSDS network has unique characteristics, as compared with public and other

data networks, including:

4-28
• significant control by NASA,

the use of high level coding such as Reed-.Solomonto guard against

errors,

transport of both interactive (realtime) and non-interactive

messages,

functions such as data capture which support recovery of lost

application data,

data that _s transported through the network that can be

interpreted as commands and. hence, must be checked, in some

instances in realtime, for restrictions and constraints (payload

cross-interference).

• high- and low-rate quick-.look and production data,

$ image and non-image data and in both realtime and (delayed)

non-realtime, and

commercial quality imagery, low-resolution, freeze-frame, and high

resolution TV

A preliminary configurations for the onboard data system is given in Figure

4.3-1, and the variety of data types that must be transported through the SSDS

are functionally shown in Figure 4.3-2, with an important subset of these

types also characterized and presented earlier in Figure 4.1.3-4 in terms of

data vo].ume, delay and reliability requirements, and the range of transport

services that will be required.

lhe onboard data network model shown in Figure 4.3-1 is comprised of a series

of LANs dedicated to modules but with a backbone interconnecting the module

LANs via bridges. Specific points to be made are that:

4-29
c

o

J=

o

"o

-z

>

IMPAC

NIU

I "• _ Sensor Data

I _ e_.._.._.1/:- l_,Point.to.Point Links C&T

I High:Rate '--"_'__ " ,/ ........ , I,e..7,.._Space.to_Spac e

rd_lUCU _ I_1 _UIIIIII IIUU_

IN'u/P I-;_- I '_ I Gateway .o.I

' _.-_ '. _' I_, J Buffer _'--'Z,._.-Ground-to-Space

_ INIU/Sequentiall T

(_A-cess,.._ Store ,I --"11

""i NIU/MPAC | IM;ss I _ TV/Audio To/From Ground

TWAud,o _ _ '_NIU/e!:nMda°s_ StoreJ! :"_--_a:r:i 1

"--tNIO/MPAC I ' • MPACs Mon.or,_

• Core Subsystems a TV/Audio Distribution

_.__. • Mass S:ores _ Iie Isolated from Data LANe • , ----------, High Rate Sensors Use

Multipurpose _ I_.L'I *

, . . I Point-to-Point Links to

Applications _ _ I C&T but Controlled Via

Console _ I LANs

Network I

Interface ! _ I

Unit I • Audio I

LAN -- Local Area L-_'e'-_ J

Network

Figure 4.3-1. Onboard Data System

Quick Look/Status

Commands

Other Core MPACs

• "IV _ • Interactive Eng Data Subsystems

• Audio I • Manual

• Electronic

Mail

Bases

Stores

' Program Loads

IGROUNDI • Commands

Other _ • Remote ,Job

Entry

• TV I • Program

• Audio Loads

• Electronic • Data Base Mail Queries

Real-Time

Commands

Del

Payloads

Program LoadsJ

ii Video Text

Graphics

Data Base

Updates and

Queries

Core/Payload Commands

Core/Payload

Data

Figure 4.3-2. SSDS Message Types

4-30
i, _V/audio has it own distribution subnetwork and is isolated from

the LANs.

2 High rate payloads have dedicated point-to-point data links with

the communication and tracking subsystem (gateway to earth station).

Data transport for low rate payloads, core subsystems, and control

of high rate payloads is implemented using the LhNs.

4 RI]. units interfacing with the LRN have a Network Interface Unit

(NIU) which implements the lower layers of the distributed

operating system,

4.3.1 On the Use of International Computer Networking Standards

The CCSDS telecommand (TC) and telemetry (TM) packet standards are documented

in References 2 to 12 and are in various stages of being ratified as

international standards. In the end-to-end space-to-space and space-to-_round

flow developed herein, the customer/operator interfaces with the SSDS is at

the top layer of the CCSDS model (TM/TC Packets) as shown in Figure 4.3.1.-1.

The key points to be noted in this figure are as follows:

, Customeroperator generates telecommand (l"C) packets, either

onboard or ground, which are transparently delivered to his

application on the SS/POP or via the SS, routed to the (SOP, or" to

ground components.

, Onboard the SS, POP or COP, the customer's equipment (or core

subsystems) generate telemetry (TM) packets which are delivered to

ground facilities designated by him (his own facilities, POCC, R[)C,

CC .... ). TM packets can also originate on ground and be delivered

to a space application.

3 , ]in a].l cases, the complexities of the data distribution network are

transparent to the customer.

4-31
fJ_

ORIGINAL P_,GE _;>

_0£POORQUALnY

SS/POP COP

re'no ...c.,,ons

nboa_-D';t; Netw0_k-L..___ IOnboa_-Data N_work I

---_ .... _---1 _."_'_ I ..... _----*---]

I__cd_t_ _tnsaF_°aWn d _ _ TelemetrYlTM Packets FIo_wBidirectionally and Transparently I

ITransparently I _ _1, I IBetween Space/Ground end I

I Between Space/Ground [i_--r;"_D-_e-.-e;-wo__ 1 Ispace/space I

'a°ds"°"s'ic" 'J t

Telecommend Packet

I'-- _ m m,t t

I• , I

w_..o_. _ ,.n, ..., I "= :'_:

, I _ i i i m i.. d

I ,I I _ t I I _ :

I I' I ' I ! ' ' ,

-".' i _ I._....'.-C:-.'. _

Telemetry Packet

i , t I i :

, i _ i,o_.  ̧

rn,*l

Highest Layer

, of

CCSDS Model

I Customer/Operator i

Figure 4.3.1-1. CCSDS Telemetw and Telecommand (End-to-End)

4 ,

The TC and TM packets must conform to the CCSDS formats including

primary/secondary headers, max packet size .....

°

l'M and TC packets are bidirectional, e.g., IM or "FC packets can be

generated onboard/ground and transmitted to ground/onboard.

The three layer CCSDS model is characterized as follows:

, The upper layer (telemetry/telecommand packet layer) is intended

for customeroperator interfaces as described above, for data to be

transported between space and ground.

2. The lower two layers are intended for use in noisy space data

links: space.-to-<3round, ground-to-space and sp,_ce..-to..-space.

4-32
To provide for complete automated internetworking in a heterogeneous

environment, additional capabilities are required which can be Found in the

International Standards Organizations (ISO) Open System Interconnect (OSI)

seven layer reference model. The functions of the OSI layers are summarized

in Figure 4.3.1-2, and draft proposals associated with these layers are also

in various stages of being ratified as international standards (see, for

example, reference 13).

APPLICATION LAYER

Common Appllcatkm-$sreice Elemmmts (CASE)

Log-in

Password checks

Sets up associations to named peers and agreement on the

semantics of the information to be exchanged

Commitment, concurrency, and recovery

Specific Ap_icauoc_-se_lce Elements (SASE)

File transfer, access, and management

Basic-class virtual terminal

Forms-class virtual terminal

Message handling

Document transfer

Job transfer and manipulation

Videotex, teletex, teiefax

Graphics (semantics)

Data base access and transfer

Directory service

System management

Credit-checking protocols '_ mtereat _;rou )ny_',pec

Invoice protocols | _ "-"

Inventory protocols .._

PRESENTATION LAYER

Negotiates concrete transfer syntax (bit-encodings) for character

sets, text strings, and other data types to be exchanged

Session services pess-through (passing Session services to the

Application layer after transfer syntax is negotiated)

SESSION LAYER

Maps aOdresaes to names (users retain same name if they move)

Connection establishment and termination

Data transfer

Dialog control (who speaks, when, how long. half- or full-duplex)

Synchronization between end-usar tasks

Graceful and abrupt closure

TRANSPORT LAYER

Reliable end-to.end bit pipes (transport connections)

Multiplex end-user addresses onto network

End-to-end error detection and recovery

Flow control

Monitoring quality of service

Possibly disassembles and reassembles session messages

NETWORK LAYER

Sets up routes for packets to travel (establishes a virtual circuit)

Addresses network machines on the route through which the packets

travel

May disassemble transport messages into packets and reassemble

them at the destination

Sends control messages to peer layers about own status

Congestion control (regulates flooding within the network)

Recognizes message priorities and sends messages in proper order

Internetworking (both connection-orienteO and connectioniess)

DATA-LINK LAYER

Reliable transfer of data across a single link

Adds flags to indicate beginnings and ends of messages

Adds error-checking algorithms

Makes sure data are not mistaken for flags (transparency mechanism)

Provides access methods for local-area networks

PHYSICAL LAYER

Handles voltages and electrical pulses

Handles cables, connectors, and components (interfaces to media)

Handles collision detection for CSMA/CD access method

TAKEN FROM SYSTEMS& SOFTWARE,MARCH 1985

Figure 4.3.1-2. Functions of the OSI Layers

In the development herein the position taken is that the lower two CCSDS

layers provide the space transport services required in the lower two layers

of the OSI model (i.e., data link layer and physical layer) and the upper

layer 1_/IC packets are transported to/from the customer using interprocess

message tranfer services in the OSI application layer.

Figure 4.3.1-3 shows a bidirectional space to ground packet Flow with the

CCSDS packets originating as a service in layer 7, and using layers 1-4 For

LAN transport services to the communication gateway where (]C,91)Spackets are

then recovered and embedded in the CC,SDS lower two layers for transport to

4-33
ground (space). In the ground (space) segment, the lower two CCSDS layers are

removed, the TM/TC packets are recovered and ISO services are then used again

for data transport to/from the ground terminal node.

Space

I

CCSDS I

Packets

(ISO Layer J 7) Ill G_o_O&f

Space Station I - "c'e_Y

(Local-Area Net) &_ ISO Layers 1-6

i Packets

CCSDS (Frames,

Channel, RF)

Figure 4.3.1-3. CCSDS Packets Standard in ISO Upper Layer Logical View

Ground

CCSDS(RF,

Frames, Channel)

Packets

Ground

(Wide-Area Net)

ISO Layers 1-6

CCSDS

Packet

(ISO Layer 7)

4.3.1.1 Onboard SSDS Interfaces

A generalized interface diagram is given in Figure 4,3.1.1-1 that shows the

end-to-end interface options in a reference model configuration combining the

ISO and CCSDS layered models. The interpretation to be given to the diagr'am

is that data originating in the payload traverses a thread that goes from

Layer 7 to Layer 1 on the LAN (exits the payload NIU) back up to Layer 7

(through the NIU in the communication gateway) down to CCSDS Layer 1 (exits

the SS antenna) up to Layer 2 (frame processing in the earth station) up to

Layer 7 where the packets are recovered for transport as an OSI message, down

to Layer 1 to enter the WAN medium and then back up to the application layer

for final delivery to the ground customer. Various other end-.to-.erld threads

cou].d also be developed in a similar manner For cases of ir_t(_r'networking,

circuit switched networks ..... but are not included here. Other points to be

noted are as follows:

4-34
I Standard Messages I

• Ancillary Data

• Interprocess

-- Commands

-- Quick Look

-- Status/Meas

-- Time

• CCSDS

-- TM

-- TC

• OSI

-- FTAM

-- Data Base

-- Virtual Term

-- Message Handiine

• s

Onboard

IEEE 802.X

FODS

ANSI X3Tg.5

CORE/CUSTOMER PAYLOAD

(SS, COP, POP)

7 Application

6 Presentation

5 Session

4 Transport

I 3 " Ground

Physical Physical

LAN CCSDS WAN

(Onboard/Ground) S-----,- S (Ground)

S-.,--,.- G

Figure 4.3.1.1-1. Onboard Interfaces to SSDS

Public Packet I

sw (x.2s) I

Circuit sw, NASCOM I

Point-to-Point .... I

° Standard message protocols are shown at the application layer which

would be defined by HOL record type or SFDU data type

declarations. CCSDS TM/TC types would be transported through the

space ground medium and the others would be transported onboard,

, Representative onboard and ground LAN and WAN options for the lower

two layers are identified.

, The SSDS Time Management function provides time to the payload with

an accuracy of ± I msec in one of the CCSDS standard formal:s.

4 . A network management function resides at the application layer"

gathering data/statistics from the lower layers and reporting these

to the network manager,

.

lhe user interface at the application layer is further expanded in

Figure 4.3,1.I-2

4-35
OF POOR JA[.nY

Specific

Application Service

Elements

(SASE)

ISO Defined

File Transfer (FTAM) .

Remote Job Transfer (RJTM)

Data Base Access

Virtual Terminal

Electronic Mail (Message)

Example

Primitives

F-Connect

F-Select

F-Create

F-Read

F-Open

USER

Common

Service

Elements

(CASE)

Interprocess Messages

• Generic Interprocess Message Transfer

• Space-Ground Message Transfer

• Voice Transfer

• TV Transfer

.:

I Context Example I

'-_ _T' = =iI CCSDST'i--,'_. _ Packe--t T---- '_=

I I _ I I ¢I'TIOML_ I lOmlmO_.

] I--L I I 10oY,

i ,',

I I I I

I II I II I 18 1 IVIIIIIG_ l_lalbll I Illl

Figure 4.3.1.1-2. User Interface at the Application Layer

4.3.1.2 Ancillary Data

A representative set of ancillary data is shown in Figure 4.3.1.2-1 and its

size is estimated to be 512 bytes. At this time the preferred distribution

approach would be to allocate these parameters to three groups (State,

Activities, and Environment) and to multicast the groups to the appropriate

payloads. The components in each group would "s].owly" change based on payload

cbangeout.

4.3.1,3 Global Addressing: Physical, Object Name, Application Process ID

and SpacecraFt :[D

4-36
DATA TYPES

Time

Configuration Changes

Attitude

Orbit Position

Water Dump Status

Pointing/Orientation

Power Flux/Usage

EMI Map of Station

Thruster Firings

Internal Pressure

Atmosphere Composition

Relative Humidity

DISTRIBUTION OPTIONS

• Payloads Poll for Data

Radioactivity Exposure

Chemical Contaminants

Optical Environment Contaminants

Crew/Operations Activity

Acceleron*eter Data

OMV Berthings/Status

EVA Activity

Internal Temperature

External Temperature

Particulate Count

Particulate Types

• Broadcast Every TBD msec Using Dynamically Changing "Standard"Package(s)

• Combination of Broadcast/Poll

SIZ___[E

Estimated To Be 512 Bytes

OTHER

Use "Open" Format for Data (i.e., SFDU)

Figure 4.3.1.2-1. Ancillary Data

Server Name and Physical Address

In a distributed computer network, nodes are entities that may have resources

that can be globally addressed as object names remotely from other nodes.

Some examples of distributed entities are printers, files, remote jobs,

terminals, peripheral devices, payloads and core subsystems. A service is

implemented by a process called a server who provides requested services to

authorized customers. An example is a file server, printer server, or payload

data server whose logical, or object address, is a character string (a name).

One implementation of the server concept is to have each object (NIU) LISTEN

for its (layer 4) transport (physical/NIU) address; to use a server a customer

requests a CONNECT specifying the appropriate server address. The prob].em for

the customer is to determine which object is listening to which transport

address? The customer will want to request a service by NAME, which is

genera].ly a character string intended for use by operators rather than

machines (NIUs respond to binary..-encoded physical addresses). To obta:[n tlne

4-37
NAME:ADDRESS mapping a DIRECTORY SERVICE whose address is well known and never

changes is consulted and the global physical address is received; this

sequence is all transparent to the customer.

CCSDS Addressinq Structure

The CCSDS packet and transfer frame ID/addressing structures are summarized as

follows:

SPACECRAFT/APPLICATION ADDRESS FIELD

Spacecraft (SSPE) ID (Transfer Frame Protocol)

used for routing in space-to-space

I0 Bits

Telemetry ID (Source ID within one SSPE) II Bits

Telecommand ID (Destination ID within one SSPE) ii Bits

Spacecraft ID is assigned by the CCSDS international ot_anization and an

example of routing data using the spacecraft ID is shown in Figure 4.3.1.3-1

(the case is for earth to COP via Space Station).

The CCSDS packet format for TM and lC is shown in Figure 4.3.1.3--.2 and

includes an 11 bit Application Process ID addressing field that is assigned by

the program office for each SSPE and which is logically equivalent to the

OBJECT NAME entity previously discussed (i.e., a logical address). Tlne 10 bit

SSPE address and 11 bit Application ID assignment concept is i].lustrated in

Figure 4.3.1.3-3.

End-to-End Addressinq

With respect to the end-to-erld SSDS design shown in Figure 4.3.1.3--4, messages

$

are transported onboard the SS within an OSI environment, and on ground within

an OSI environment, between elements that have unique physical addresses.

When ].earing the space or ground OSI environment (i.e., space-to..-ground, or

4-38
ORIGINAL PAGE iS

OF POOR QUALITY

,n.

, 0,1 ,1 ; ;

/ Communication and Track J /

/ Subsystem J /

Process Transfer Frame

• COP Procedures in Effect

• R-S Error Correction (Option)

/

,_ From Earth

w_

m

, j-+-_ CCSDS

Transfer

Frame

Figure 4.3.1.3-1. Space-to-Space Routing Example

• For Bidirectional TM/TC Packet Concept

• Single Packet Type Designated for TM or TC

• Global Application Process ID (Logical Address) Maps to

Physical Address(es) at Session Establishment Time

Ii<_ R_k_¥ _ _>1

L i

I I I i I

II i O_ I L (OlrrlON_ I Clo¢r,[_o.t

I I I I (OPt. I

I-xonlplH¢_. IIPcK:a::_II_Z4_ I$_qu_nc=ll I " S/C Time II

I i lil_l_l %1) I ICo_11¢ I I • Ikl¢ I

I Ill I I I I I _¢ll_ i

I lel I I I I I • li_cl_l

I I I I I I I I lill I

I I Ill 1 I 11 I 2 I li I I I

I__1_1__1, I I__J__l___l-_]__l

' ' ' I

II _lil/e) i I _/lile) 115)

Packet Type ID Function

1 = Telemetry Packet Source of Packet (On Board or Ground) J

I

0 = Telecommand Packet Destination of Packet (On Board or Ground) I

Figure 4.3.1.3-2. CCSDS Packet Format (Revised)

4-39
SSPE1

SSPE= @

SSPEI_ 4 "

SS_ Application ID

Function No.

SAAX0021.1NSTDAT 1

SAAX0021.ANCDAT 2

• j

TM/TC Packets

TM/TC Packets

Ground Element

TM Packets

" (Source ID) _"

TC Packets

(Destination ID)

Application ID

Function No.

COMM1020.POCC.XXX j+l

COMM1020.POCC.YYY j+2

COMM1020.POCC.ZZZ j*3

• 211

Ground

Elements

(GSs)

Figure 4.3.1.3-3. CCSDS Mapping/Assignment Space

TM Packet

TC Packet _

I

I

I

!

Interprocess

Messages

Peer-to-Peer

Bidirectional Processes

Transport of

CCSDS TM/TC

Packets

Transfer

Frame

Channel

Coding

TM Packet

TC Packet

Ground

OSl

Environment

Interprocess

Messages

I management functions.

Sessions are established by onboard facility management function on |

request from user and coordinated with scheduler and resource I

Figure 4.3.1.3-4. End-to-End SSDS Design Concept

4-40
space-to-space transport), TM or TC packets are transported from/to

Application Process IDs which are also unique and which map to a unique

physica], address. Application IDs, like OBJECT NAMES° in general can be

relocated to different physical (NIU) addresses and the mapping at the two

nodes on each end of the layer 2 space-to-ground data link must be determined

(via the DIRECTORY SERVICE) at session establishment time, or the routing

algorithm can use tables that are preset by the network management function to

accommodate a slowly changing network topology.

End-to-End Routing

At session establishment time communication resources including data paths

through the network will be bound for the term of the session (realtime

dynamic routing through a ground packet switched network is not precluded,

however).

Figure 4.3.1.3-5 demonstrates the ISO/OSI and CCSDS protocols used on an

end-to-end basis showing communication within a space or ground OSI

environment and through space in a CCSDS environment. For a connection

(non-datagram) service the end-to-end connection options are shown in Figure

4.3.1.3-6. An example of the mapping concept required in the onboard C&l

gateway to deliver a customer packet from his ground operation center to his

onboard application is given in Figure 4.3.1.3-7.

4.3.1.4 Onboard User Interfaces and Data Delivery to Ground

As stated earlier, the customers principle SSDS interface for message

transport through space is the CCSDS packet and for transport within space or"

within ground the data is transported in standard interprocess messages.

Another item also discussed was data transport transparency, on an end-to-end

basis, to the customer. These two elements will be demonstrated later using a

hypothetical payload and showing the important interfaces that transport the

data through the distribution network.

4-41
ff

! End't°'Enl_

s::.,o..

I

I

I

L

Figure 4.3.1.3-5.

Space

._1 p.ioadI I

a Generates/Receives |

TC or TM Packets J

_-., .....

LAN

Iodiur

m

._.J

Ground

Terminal Node

7

6

4

3

2

1

Ground

Icust°marl I

• Generates/Receives

TC or TM Packets

_ro.._I

Earth Station i -- _I

End-to-End Protocols

Space

| TDRSS/ !

"I" TDAS = I " G round

Terminal Terminal

Node Bridge Gateway Gateway Bridge Node

i-l.. O

Application (_) I

Presentation (_ 14

I

Session® I,

I

Transpo, ® I,

Network (_

Connection

)

Class 0-4 Service

Connection

Connectionless

_. a a o _mm,m_ o o o _mmm,_

Connectionless

,e,-,,,,_ • • a 41,,--,,_ • • • _l_lP

Connection I

'i

I

Connection

I

I. Class 0-4 Service ,,!

'" Connection "

I

Connection or _m'mma_ • • o _lmm_ O O O

Connectionless I

4'-- CCSDS.-I_ Connection or I

_ a • • 4-.-..._ • • • 4i_l_

Connection/ Connectionless /

Connectionles:

Data Link ®

Figure 4.3.1.3-6. End-to-End Connectinn Diagram

4-42
ORIGINAL PP,G_ IS

OF POOR QUALKY

Onboard C&T

MAPPING

%

\

Logical

LAN i _ Path

LAN k'

I

Layer 3 ----,- _ /

Routing _ I.AN | /

• __ - J Transparent

Layer 2 _ _ j_ Packet

Destination _ KJ Delivery

I Application _,. to Application

IO = AELO IO = AELO...

Payload :

Commxxxx

Figure 4.3.1.3-7. End-to-End Packet Delivery (Example)

Core/Pavload Telemetry Interface

Figure 4.3.1.4-1 shows the CCSDS packet that will be used as the payload's

data carrier through the space network. The details of using this message

structure are given in references 2-12 and only the boxes in the diagram wi].1

be discussed here. Source Data and Secondary Header Fields are delin(_ated in

the packet structure; the customer/customer packages data into the primary

Source Data field using the indicated options. Associated with data in the

primary field, the customer may elect to use the secondary field to package

ancillary data, time, various flag designations, and other parameters.

Alternately, he may elect to embed these secondary data items in the primary

field with a unique Application Process ID. The SSDS has a requirement to

transport this message to the ground customer (possibly delayed in which case

it is stored prior to transmission) with an end-to--end bit error rate (I]ER) of

-6

1_ss than 10 lhe customer has several options to improve this BER _s

shown below:

4-43
User installs source data into packet and has the following

options:

• Compress data using his algorithms

• Encrypt data using his private key

• Encode to improve SSDS 10 -0 BER

• Define secondary header and source data using "open"

protocol (i.e., SFDU)

• Ancillary data

• CCSDS time format

• Flags for Data Type

• Sensor Data/Eng Data

• Performance/Other

Data

J TM/TC Designator I

J l Assigned by SS, COP and I

POP program office. Used for J

level 0 and higher Archiving. J

Option: Use different IDs for J

sensory, ancillary, I

performance data types I

, ,T I i I 1

I ) ilb i X 11

I__1_1 r ,_

I000

/User Option-

/SSDS Does Not

i 1 .. /Encode or Decode

SCI.3KZ I

_,ATA I _%qQR

I OQk"n;_L I

i(o_.,

I I

../V'__:__,

i 16 rvazza_e. ';azxa_el _ '161 n

IV_II 'Sec. lApp1_c. ISe<jl_ll:.l$OU¢_ I lq_" o_,nt,_.n:*

I I I _ 1 , wo_t

I 14 I ,

16

J-- _l

I _ User Has Option of

Segmenting Packet

Core/Payload Builds Packet and Uses SSDS to Transport I

to Ground Centers with BER of 10 -0. I

Figure 4.3.1.4-1. Core/Payload Telemetry Interface

,

At session establishment time, specify quality of transport service

desired at ISO layer 4 and CCSDS layer 2.

, Specify forward error correction in CCSDS layer 2 (i.e.,

Reed-Solomon encoding with parameters 255,223) or encode the data

using his own algorithm prior to inserting the data into the source

data field.

, Use the two byte Packet Error Control field (e.g., compute a 16 bit

CRC for the entire message and use for error detection requesting

retransmission at the application layer).

Lost and Out-of-Sequence Packets

As CCSDS data packets (or segments of CCSDS packets) are transported from

their point of origin (e.g., a command From a workstation in a POCC or data

4-44
jl f

from an A/D converter/formatter) to their final destination (end-to-end

transport) they can be transformed enroute in many ways:

I , They can become corrupted by noise-induced bit-reversals so that

the data delivered is not identical to the data at the point of

origin.

, They can become electronically and physically lost at intermediate

points (nodes) in the transport chain due to storage media overlows

(temporary buffers), node processor failures, communication link

(between node) failures, and other reasons.

, Data packets may arrive out-of-order (out-of-sequence) due to their

transport over different physical (e.g., cable) or logical (e.g.,

CCSDS Virtual Channels) links.

The above problems are real ones and are ones that are addressed in commercial

data transport networks (e.g., TYMNET) and in the CCSDS and the ISO/OSI

standards models. Recall that layers one, two, and three of the OSI mod_l

form a Network, with possibly multiple end-to-end paths between any two

connected nodes, and that layer four, thee end-to-end Transport Layer,

considers the Network to be intrinsically unreliable (i.e., noisy and subject

to link failures). The Transport Layer, guarantees in-sequence de].ivery of

packets and provides a class of service that guarantees error free data

delivery on an end-to-end basis. These services are basically provided by

incorporating end-point buffering to re-order packets at the receiving node,

enroute (data capture) buffering which is released only upon positive

acknowledgement of a "window" of data, and fault-tolerant operations to

provide rapid alternatives following communication processor and link failures.

The SSDS will provide the same class of service as above but the

implementation will be more expensive due to the higher data rates and the

larger.end-to--end extent of the SSDS. It is expected that all users do not

require and do not want to pay For the above quality of service and that

reduc(_d classes of services (per CCSDS and the OSI models) can b(_ defined with

4-45
corresponding reduced data transport charges. The extremes in these services

are as follows:

.

The event to be captured is short-lived, is an opportunity of the

century, and no recapture is possible. In this case the user may

w_nt data captured in multiple locations and will want the highest

quality of data transport services. All packets will be

transported to the terminal node(s) in sequence with no missing

data and virtually error free.

The data is extremely redundant and updated at a high rate so that

the loss of a single frame or subframe of data is of little

consequence provided that incomplete frames are so noted and that

frames are delivered in sequence.

In addition to the classes of service specified in the CCSDS and OSI

standards, the customer at the application level (above layer 7) can do the

following:

l, He can encode his data to provide for increased error protection

(forward error correction).

He can provide his own buffer/store and use an end-to-end

application-to-application acknowledgement of receipt.

, He can specify that data be recorded (captured) onboard and

transmitted to ground for capture

4.3.2 System Design for a Hypothetical Payload, COM XXXX

Introduction

Figure 4.3.2-I shows the system design for the hypothetical payload COM XXXX

which has the following features and interface requirements:

A pointing and tracking system, teleoperated from ground or onboard.

4-46
An imaging sensor array of dimension lO0 x lO0 (lO 4 pixels), a lO

bit A/D converter (lO 5 bits per image), so that at an image rate

of 50 per second, the total image data rate is 5WlO 6 BPS.

Payload performance (engineering) data is acquired and packaged for

transport.

The I/0 Electronics, Payload Processor, Memory and NIU circuit

assemblies are integrated via a standard backplane bus (e.g.; VME

Bus).

The memory is divided into several components; one of these, as

shown, is a shared RAM where the sensor and performance data is

stored as directly received from the A/D converter. This segment

of memory is subdivided into LAN packet-sized elements (64 1K

packets) and the payload processor builds the CCSDS and OSI headers

and trailers around the packets without moving the data.

The Time Management Function provides time to the payload via the

NIU and the Payload Processor embeds it in the CCSDS packet, as

required.

• The NIU and processor implement the network operating system.

The payload communicates with other LAN-connected components ,_s

shown and based on sessions established by the network manager.

In this development the customer has provided his own electronics package but

uses certain SSDS standard cards: specifically the card sets for the SDP,

memory, and the NIU. He has provided the custom I/O electronics that have

unique interfaces to his instrument (i.e., torque motors, gyros, scan control

interface, A/D converter, and so on). The sensor data can be displayed on an

MPAC display at the same resolution as the sensor and by mapping the p.ixel

value to the display's color code, the quality of the data can be validated

via quick look by a pre-trained crew person. (By doing this the customer has

provided for both onboard and ground operations.)

4-47
i

S

Instrument

Pointing &

Tracking

1,1 _1,100

i ARRAY

i (Xi, YI)

100,1 _ 100,100

Sensor

instrumentation

Sensor Data Rate

• 12.5 "103 octets

per Frame

• 50 FR/sec

• 5 *106 bps

•, Torque Motors _!

-Rates, Positions v

Sensor Out

104 pixels/FR

• Scan Control

X'i, YJ (i, j = 1 to 100)

Engineering Data

Backplane

Bus I/Fs

_ LAN I/Fs

I/O Electronics

Active

Control

10-bit AJD

50 Frames/sec

Payload

Processor

Instrument

Controller

• Test

• Control

• TM Packet

LAN Medium

' t

I N,u I...

IGroundInterfa©es_ [ Mass Memory I

I-- Telemetry _ , t

I-- Telecommand J _ Onboard Interfaces

Memory

Prom] Self

Test, Init,

Boot-Up ....

Operating

Engineering Build Systems (Local/

Data • TC Packet Dist'b) & Appli-

• Temp Decode cation Programs

• Voltage • Sensor Data I Shar d'RAM' I

_ : • Eng Data ] e I I

• Other Data I • Comm i/F I

I • Packet I

.I-'---'_ ..... I Build I

--, '-- rk ' '-- '

I Ne O

;'l)iManagement ! (_l terfa I._--_ _r *

i I n ce •

I IFunction z /,,.i, (NIUI] _'_--j' 64 lk Packets

I / ..... "---_-/140 nsec Cycle

I _ at 100 mpbs LAN f

Figure 4.3.2-1. System Design for Payload/Mission COM XXXX (Example)

The payload has a duty cycle of 5% so that power is normally disconnected from

the package. When the schedule time For payload activation has arrived the

following events occur:

1. Thermal control to the unit is activated.

2. Prime power is applied and sensed for abnormal current.

, The payload processor is reset to the POWER ON state by an interrlal

power on discrete.

4 ,

5.

In the POWER ON state the processors program counter is reset to memory

location zero, the location of the PROM-embedded self-test routine.

Self-test is then initiated and the results are stored.

The NIU then performs a self-initialization procedure to become ,;xn

addressab]e L.AN entity using procedures such as can be found in

4-48
IEEE Standard 802.5 paragraph 4.2.3, entitled Standby Monitor

Finite-State Machine.

. Sessions between the payload and other devices assigned by the

schedule Function, are now established by the network manager.

This assures that all resources are communicating that are required

to support the session.

7. Numerous scenarios are now possible For payload operations:

Rutonomous payload operation vs step-by-step operator

direction.

Quick look mode via onboard or ground operations Followed by

a production mode with data stored onboard or transmitted to

ground.

Interactive operations in a browse mode (quick look) followed

by an automated inertial track mode (production data

acquisition) Followed by repeats oF this cycle throughout the

whole session.

The processor could have had the command sequences (program) stored in PROM,

booted From mass store, or provided from ground. The processor app].ic.ation

functions include mode control, test, TC packet decode, TM packet build for

sensor and performance data, ancillary data extract and merge, teleoperate

interface For instrument pointing, instrument auto-track, and so forth.

When the session schedule expiration nears, the session entities will be

notified, a11owing for an orderly disconnect: the processor will secure the

instrument, and the core subsystem manager For power and thermal will

disconnect their services in a sequence that provides thermal protect:ior_

against an over-temp condition.

4-49
COM XXX TM Packet Flow - End-to-End

End-to-end TM packet flow for COM XXXX is shown in three parts in Figure

4.3.2-2. This flow is based on the functionality previously described and

illustrates the protocols used in the end-to-end data transport. The

discussion herein will be based solely on this three-part figLre.

Array Ancillary Data

1,1......... 1,1001_ -" _,

i i F PaylOad Xi, YJ Processor

iuUl1"_0'1""100'1;'0-- m Command and , Control

I_.. • Packet Build

EngineeringDataI--"I j

Time

7. Application

S. Presentation

5. Session

4. Transport

3. Network

2. Data Link

1. Physical

Data Type (octets)

I NIU/Instrument

on Space Station

,._ Error Control (2)-

,.P Data Frame (12.5 * 103)

Data

._'_ Ancillary __(256)

Engineering Data

,.P Time (16) m ,,_ --

.,P Misc (28)

SASE, CASE

Context/Syntax,

:ass-Through,...

X.225(BAS): Connect,

Disconnect, Exception ....

Class 0 -- No Ratranamission ....

Class 4-- Critical DataJRetransmlt

Internetwork, Connectionless,...

(DP8473)

FODS, ANSI X3Tg.5,

IEEE 802.X ....

so Packetll

Per Sec J

11

700 LAN

Packets/se(,

LAN Packets

i I

J I I I I T

_i. = . . u i

) ut s 14 I a *. I t i I

mm 0 [ I [ i

I II I I$ I *l I r_Mll,l ll_lllmla Ill

I TM Source Packet I

LAN Packets ]141

12,3, ," ljJIJ

,...,.ccsr

I LAN Medlum

Figure 4.3.2-2. End-to-End TM Packet Flow (1 of 3)

This scenario shows one message type (the 'FM packet) being built and

transported through the C&T mode to the ground terminal node. lelecommands

would traverse the opposite path and the processor would have the "opposite"

function of interpreting the contents of the command packet. Likewise, other

message types from onboard entities would be built for transmission and

received messages would be interpreted based on a message-type labe]..

In the first f:igure (i of 3) 'the 'lM packet is being built using one image scan

(12,5_(10 3 octets) per packet and the processor packages other data

4-50
(ancillary, performance, time ) into the secondary header (an alternative

would be to create individual packets for secondary data). The maximum packet

size (216-.1 octets) easily accommodates the data. Packet segmentation, a

Flow control mechanism, is not required since the NOS at layer 4 will segment

"large" messages prior to transmission on the LAN. In this example the

customer has elected to add the two (optional) Error Packet Control octets

which he will interpret (error detection with/without correction) when the

packet is delivered to him.

The NOS implements services and primitives associated with the seven layer

model shown in the First Figure. For this payload, connections would be

established at the top four layers and Class 2 services would be specified at

layer 4. In this case the Common Application Service Element (CASE) provides

a message service for the indicated 50 packets per second to be transported to

the C&T node. Layer 3 disassembles the 13K octet packet (message) into 14 LAN

packets, adds two routing headers (possibly null if bridges are not involved)

and layer 2 frames the data for transmission by adding the layer 2 header and

trailer. The trailer is a CRC code used for error detection at the receiving

node, and the header includes the address of the C&T node. IF a token ring is

assumed, and for this example a 1Kbyte LAN packet is assumed, then 14 token

acquisitions will be required to transport this image-Frame of data to the C&F

node.

Part 2 of the Figure shows the seven layer processing at the C&T node to

recover the COM XXXX XM packet: the C&T is also receiving packets fom other

sources (layer 2 LAN packets and TM/TC packets From the high rate payloads via

point-to-point links). Additionally, TV and audio is being received From the

l'V/Audio subnet and being digitized and compressed. All of these data are

being segmented (if required) and installed into CCSDS Transfer Frames For

space transport to earth. A virtual channel concept is employed to

time-divide the TDRSS bandwidth to implement Flow control ("link hogging") and

to provide timely access to the channel For realtime data like TV and audio.

lhe output of the virtual channel multiplexer (itself a virtual device) is

serialized and Reed-Solomon encoded (an option exercised at s_ssion

establishment time) and then interleaved prior to entering the modulator and

RF section of the C&T.

4-51
LAN Medium

NIU/Mass Memory }

NIUGateway at C&T

Figure 4.3.2-2. End-to-End TM Packet Flow (2 of 3)

In part three of the figure, the transfer frames are recovered in the receiver"

as they enter the Data Handling Center for routing to their ultimate

destination. At this point the data (TV, voice, TM/TC packets) are embedded

in transfer frames. When Reed-Solomon Sync Codes are detected, real time R-$

decode and error correction is performed prior to frame processing.

Uncorrectable errors would be flagged, and in the event that a

connection-oriented service was in effect for the session associated with the

frame, then a retransmission of the frame would be requested (i.e., this is in

the case that a 1-C packet was transmitted from space ......recall that in the

CCSDS TC concept, retransmission is mandatory when a TC error is detected and

not correctable. In the MDAC concept, Reed-Solomon coding has been

substituted for the Hamming code normally used for TCs). The transfer frame

processing is basically the inverse of the processing initially done onboard.

TV/audio is recovered and retransmitted over point-to-point links and the

IM/TC packets re-.enter the ISO/OSI environment as shown with the indicated

distribution options.

4-52
y. • .y

I Demodulator ..o.,-,, I

Raw Data Record _ L_jITI CCSDSsegmentPacket L_F

T

RS Sync Detected? >

i Reed-Solomon and Error Correction Decode ]

I (Option) TF CRC Check

121314,5,6 CCSDS IPacket [2

I DATA

HANDLING

CENTER

Prod Data

to RDC

POCC/CC

Cust Fac

I i

irmomu°°°vc°I

• Recover Packets at Correct Boundaries Network

• Flag Uncorrectable Errors Processing

TV/Audio !

Ground Distribution

Options

TV: DOMSAT (Analog/Digital),

Fiber, T1 Carrier,...

Voice: NASCOM, Leased Lines....

Low-Rate TLM: NASCGM, Leased

Lines,...

; High-Rate TLM: DOMSAT, Fiber,...

Production/Archive Data Distribution

Low Rate: X.25, DtaI-Up,

Leased Lines,...

High Rate: DOMSAT, Leased

Lines,...

Very High Rate: Optical Disk or

Tape and Overnight

Delivery,...

Figure 4.3.2-2. End-to-End TM Packet Flow {3 of 3)

4,4 S_stem Control/Manaqement Definition within the SSDS

This section provides I) a summary of the systems management and control

decisions and design allocations; 2) a summary of systems management

definitions; 3) a pictorial description of the interrelationships and d_La

flows among the different management functions; and 4) a base].ine systems

management definition and a11ocation among elements of the SSDS.

4.4,1 Summary of System Control/Management Design Decisions and

Functional A11ocations

"lh:i.s section summarizes definitions of systems, facilities, resource, comm_nd,

(-onfiguration, and _dministr'ative managements, tlneir iryt;erdependelncies, and

thel.r functional allocations to the S,(;I:)Es as part of the strawm_n Sf_;DS

('Jefinition

4-53
The basic design approach has been to assign a high level of management

Function autonomy to each SSDS Facility. With the exception of centralized SS

system communications coordination, each facility has responsibility for

managing local resources, validating and executing commands, and monitoring

its performance. R Ground Services Center (GSC) facility is proposed to

coordinate inter-element communications, coordinate management of resources

allocated to common elements (such as the Data Handling Center), and

coordinate customer interactions with the SSDS.

Arguments are presented for space/ground resource management autonomy

(subsequent to the man-tended Space Station era). Key design drivers in

allocating system management functions are discussed. Guidelines for the

scope of management and monitoring function implementation are presented.

summary of key issues, such as potential national security involvement and

accommodation of international customers, concludes this section.

4.4.2 Definition of Key Management Terms

The definitions below are with respect to the strawman system definition

proposed for the Space Station Data System (SSDS) Architecture Study. The key

types of management defined are systems management, facilities management,

command management, configuration management, and administrative management.

SYSTEMS MANAGEMENT: Systems management is the management of the overall SSDS

and its associated elements. The systems management function is the highest

in the hierarchy of SSDS related management functions. Systems management

encompasses inter-facility management; overall SSDS communications network

scheduling; system-wide monitoring and performance assessment; system

maintenance procedures; and overall system control. In support of these

functions a predetermined inference and arbitration rule-set will need to be

established to support efficient resource utilization, to coordinate

operational procedures, and to resolve conflicts.

lhe ultimate system control of the Space Station and other SSPE's is included

in this top level systems management function. System control refers to the

coordilqated control of payloads, core resources, facilities, and all standard

4-54
juser resources via the issuance of controls and the prioritized allocation of

resources to effect desired actions. System control here refers to the higher

level control and coordination functions required to effect orderly actions

within the SSDS, not simply for individual resource or payload-specific

actions of minor importance to overall system functioning.

FACILITIES MANAGEMENT: Facilities management is the management of subsystems

within a specific facility. A facility represents a distinct physical entity

having a well defined focus or goal,.such as a payload operations control

center (POCC), a level zero processing facility (LZPF), or the NASCOM TDRSS

network (strictly speaking, an institutiona], facility utilized by the Space

Station program, and not a part of the SSDS). The facilities management

.function includes most of the above system control, management, and resource

scheduling functions, but at a lower level, i.e., for each specific facility.

The management of facility reconfiguration, i.e., the reallocation of facility

resources for changing mission requirements, is included in the facilities and

systems management. Facilities management will also include resource

management.

RESOURCE MANAGEMENT: The management, control and scheduling of subsystem

resources such as computer processing, data storage, local communications

links and capabilities, crew utilization, and SSDS core functions (such as

power, thermal management, ECLSS). The overall coordination of the

communications network, which may require interfacility scheduling, is part of

the higher level systems management function. The resource management

function controls, schedules, monitors, maintains, and reports on the usage,

performance, and reserve capabilities of the individual resources for each

facility within the SSDS network.

COMMAND MANAGEMENT: The handling, checking, validation, and author'ization for

command execution. Command management can be localized to a particular

payload or core subsystem, or it may extend to a facility or the overall

SSDS. Restricted commands will require more checking and coordination th(_m

unrestricted commands, which can be passed in a transparent manner to the

payload. Restricted/constrained commands can be executed as coi'iditions permit

(safety, interference, resource availabi].ity), where executability is

4-55
determined by the onboard SSDS, scheduling/negotiation functions to reserve

time/resource envelopes for future utilization Command management will

normally be a subset of systems and facilities resource managements and is

discussed in-depth in Paragraph 4.5.

CONFIGURATION MANAGEMENT: The management and control of system upgrades,

updates, and associated documentation. Configuration management deals with

assuring control of hardware and software versions and updates, update

documentation control, and updates logistics. Included are updates to command

and control tables and data access authorization tables.

ADMINISTRATIVE MANAGEMENT: The management of accounting and resource usage

data, the provision of standard system documentation, the facilitation of the

customer interface for SSDS information, etc. Administrative management is

required within systems management and facilities management, but at different

levels.

4.4.3 Interrelationships/Dependencies of Different Management Categories

Figure 4.4.3-I shows a hierarchy of management functions and their

relationships among themselves and among the different SSPEs.

Management-related data flows between the SSPEs and associated management

functions are indicated.

4.4.4 S_stem Control/Management Design Definition

This section presents a rationale for separate, autonomous facilities

management and control functions within the space elements and within the

ground elements of the SSD$ as depicted in Figure 4.4.3-.i. The

characterization of key interfaces among S$D$ elements in the area of systems

management and control is also delineated in this figure.

The definition oF key space and ground elements and the allocation of key

management and control functions among these elements is presented next;. Many

of these allocations will of necessity be repetitive in that many different

elements will require the capability to perform subsets of these functions

autonomously of other elements.

4-56
! I

I • NCC I

I (NASCOM/TDRSS) I

I • Other Institutional I

/ Facilities

Requests"_ F Resource /

and Statu,s I lAIIocations ......

I Ground Services Center | 1

I CommunicationsCommon Resource Coordination _ DHC _.. I • SSDS Inter-Element Communications Mgt and Coordination

Scheduling Coordination

I • Shared Facility Resource Coordination ip.._ LZPFi _$_ I • Network Performance Monitoring Coordination

.t- ,,- .... ' "

j,o,°c I°o,cc I , ..... , ..

v

• Control Center Facility Mgt I

• PL and Ops Scheduling for Space Elements I Common Customer

I I/F

' 0 ' t[ 1,o, I co_ I I ss I L ....

• Space Element Facility Mgt

• Real-Time Scheduling

Customer

" Centralized coordination for shared network resources Interaction

• Distribute management to autonomous facilities

• Promotes growth to autonomous SS

Figure 4.4.3-1. Interrelationships Among SSDS Management Functions and SSPEs

Local

Facility

Management

-I_ LZPFi I

4.4.4.1 Ground and Space Autonomy Philosophy

In the baseline SSDS design, facilities management will be distribut@d among

ground facilities and space facilities. This division will be necessary -.

i) to facilitate Space Station autonomy for normal operations, and to

control space facilities in emergency, real-time critical situations

where transmission delay times to ground might be detrimental and

where the control of operations by trained crew might be invaluable;

and

2) to coordinate and manage the distributed array of ground facilities,

the management of which will be burdensome and inefficient if

centralized in a space node. such as the Space Station base.

4-57
The space segment will require responsiveness and real-time human interaction

capability in emergency situations; the space segment is also best equipped to

perform dynamic onboard command management and onboard resource allocations.

The ground elements will best manage themselves due to the disparate locations

and diversity of functions among these elements and the impracticality of

controlling any portion of them from space.

Since the ground LZPFs and DHC may serve multiple missions and multiple

customers located at diverse facilities, an additional coordinators management

function is proposed, which will coordinate multiple customer requests and

manage inter-facility resources shared in common by a broad spectrum of

customers. In space, multiple customer requests to the Space Station will

also require only the resources of this single facility with the exception of

shared or common communications resources.

With regard to the question of whether space or ground has ultimate control,

for situations where unresolvable systems management conflicts may occur, it

is proposed that the ground be the ultimate location of decision-making

authority for the simple reason that top NASA administrators, who have

ultimate Space Station program responsibility, are almost surely to be on

ground in such situations. This is not to imply that the Space Station crew

will not have definitive decision-making authority for most ongoing and

emergency situations. Backup control capability on the ground is also

valuable, however, in cases of extensive crew incapacitation, severe onboard

facilities damage, etc.

An important area for coordination and priority specification will be the

scheduling of communications resources. Emergency situations will require the

highest communications scheduling priority.

It is proposed that a predetermined set of arbitration rules and procedures be

established to coordinate space and ground communications control and resource

allocation for predictable situations likely to occur during ongoing Space

Station Program operations and missions. A sample set of such rules was

presented at a high level in Section 3.6.

4-58
Another important area for managementcoordination is the control of updates

and access to data bases required by both ground and space nodes. Each data

base will be under control of each facility management function, with shared

data bases controlled by the system management and communications coordination

functions.

4.4.4.2 Definition of SSDS Space and Ground Elements and Associated

Management Functions.

The space SSDS elements which will need to be manage d and controlled include

the Space Station and the Co-Orbiting and Polar Orbiting Platforms, as

discussed in Section 3.3.

The ground SSDS elements needing management and control will include the Space

Station and platform operations control centers (SSOCC, COPCC, and POPCC), the

LZPFs, the Engineering Data Center(s) (EDC), the Data Handling Center (DHC),

the Payload Operations Control Centers (POCCs), and the Develop, Simulation,

Integrate and Train (DSIT) facility, as described in Section 3.3.

In addition, there is proposed on the ground a Ground Services Center (GSC)

which would be responsible for the management of common ground facilities (DHC

and LZPFs); the SSDS network communications coordination and scheduling; and

the interfacing of customer access to other SSDS elements and services.

The common facilities Management function of the GSC will encompass the

resource management condition of the common facilities, the inter-.facility

coordination, and prioritized resource allocation and conflict resolution

among and within these facilities.

The Communications Coordination function of the GSC will coordinate Space

Station Program requests for network communications services with other

institutional facilities such as the NCC, the DSN, the GPS, or the NASCOM

TDRSS network. The GSC wil]. serve as the network scheduling interfa('e between

these existing institutional facilities and the SSDS and Space Station Program

e ].ements.

4-59
The functional architecture proposed here, with significant autonomous

management within individual facilities, should facilitate Function migration

from ground to space with minimal impacts on other facilities.

4.4.5 Major Assumptions/Design Drivers

The management-related SSDS functions and interrelationships developed in the

Task 1 functions data base and data flow diagrams served as the basis for

management function partitioning and SSPE allocations. In addition, four

design drivers had a major impact on the allocation of SSDS systems management

functions. These were the requirements 1) for protection of Space Station

system assets; 2) for system responsiveness and transparency in customer

interactions; 3) for high-level and broad based automation and autonomy

implementation; and 4) for Flexibility of ongoing subsystem upgrades

throughout the life-cycle of the Space Station Program. These are discussed

further below.

4.4.5.1 Protection of Space Station ResourceslRssets

A primary Space Station Program requirement is the protection of onboard and

ground assets and people. Life threatening situations can occur in numerous

ways onboard if adequate safety precautions or subsystem redundancy are not

available in times of emergency or subsystem failures. With respect to the

SSDS, a high level of operational reliability, functional adequacy, and

assured and secure command and control procedures are necessary.

This set of requirements for safety and security imply that system management

functions such as configuration management control, efficient and dynamic

resource allocations and/or conflict resolutions, and well Formulated

inference and arbitration policies and associated technology to effect them

are necessary. The need for efficient management as well as high fault

tolerance and redundancy of functionality escalate the assorted systems

management functions in priority within the SSDS.

4-60
4.4.5.2 S3stemTra,n_sj_arency/UserRe__onsiveness

The priority of transparent data handling and commanding as well as near

real-time responsiveness for customers translates into a very efficiently

managed and coordinated system. This suggests that many functions which may

otherwise have been centralized at remote locations should be distributed to

effect quick, straightforward responses. Command checking and data handling

cannot be extensive for normal non-threatening situations or user"

responsiveness may be impacted. R basic philosophy has been to reduce the

hierarchy and number of management functions so as to reduce necessary

functional and inter-facility interfaces in command management and resource

schedu].ing. R clearly defined set of policies and associated management

?unctions are thereby required for these reasons. This implies rapid

transparent command routing and distribution. In conjunction with the safety

requirements noted above, this implies a highly secure and well engineered

Space Station base DMS operating system, where ultimate control and allocation

of onboard resources will be managed.

Network monitoring and performance ass@ssment will be needed to assure

adequate and reliable system performance, but a highly centralized control of

a11 of this monitoring data may impact system performance. This likewise

suggests a highly distributed monitoring and performance assessment function,

at least at the facility level, with coordination of overall network data

required only for small subsets of higher level performance data.

Similarly, command management is best distributed on the ground, with the

capability For command authentication and final authorization occurring within

the onboard SSDS. In this manner non-restricted commands generated by

geographically separated customers can be efficiently routed within dat:a

streams without the necessity of centralized ground validation and

verification. Ground validation of ground related commands will be r(_quired,

but, as much as possible, in a distributed fashion, and at the facility level

or lower.

$

4-61
4.4.5.3 Operational Autonomy/Automation Key Requirements

A major Space Station Program goal is to maximize autonomy of operations and

to maximize the implementation of automated processes. For many routine

operations, automation is both cost effective and more reliable. Automation

is expected to be implemented stepwise during the Space Station Program as

automation technology processes mature.

An eventual highly automated system will require thorough configuration

management during its development and integration, and ongoing monitoring and

assessment of its functioning. A distribution of the monitoring function is

again valuable in detecting failures in automated subsystems and in providing

quick functional backups.

4.4.5.4 Upgradeability of SSDS Elements

As technology develops, both ground and space SSDS components will be

upgraded, and an ever-increasing number of functions will migrate from a

ground-based implementation to an autonomous space functionality. Again, this

will require a broad and thorough system-wide configuration management

function to assure adequacy of updates, logistical feasibility, and adequacy

of functional redundancy in case of failures. Assurance of inter-subsystem

data exchange and communication compatibility will also be necessary.

4.4.6 Architectural Design Decisions/Management-Related Functional

Allocations

I-able 4.4.6-1 are summarizes the major architectural functional allocation

decisions with respect to systems management and control within-the SSDS. As

can be seen in the ]'able, each facility will have autonomous responsibility

for local performance monitoring, configuration management, and administrative

management. Appropriate subsets of data from these functions will be sent

periodically to the higher ].evel ground facilities management and/or systems

management functions.

4-62
Management Function

Systems Management

1, Communications Coord

2. System Performance Monitoring

Table 4.4.6-1. Systems Management SSPE Allocations

Space SSPE

SS COP POP

Facility Mgt X X X

a. Resource Management X X X

b. PL/Ops Scheduling X

1) Lon_l Term

2) Short Term (2 wks _ 1-2 hrs)

3) Near Term X

c. RT Command Management X X X

d. Performance Monitorin_ X X X

e. Conficjuration Management X X X

f. Administrative Management X X X

Ground SSPE

GSC SSOCC COPCC POPCCs EDC POCCs

X

X

X

X

X

DHCs

X X X X X X X

X X X X X X X

X X X X

X X X X

X X X X

X X X X

X X X X

X X X X X X X

X X X X X X X

X X X X X X X

LZPFs

Each facility will have responsibility for managing its own SSDS resources.

In addition, a proposed ground facilities management function will coordinate

resources and resolve conflicts among ground elements serving multiple SSPEs,

i.e., the DHC and LZPFs. The Space Station and platform control centers will

be dedicated to a single SSPE or mission set and, except for communications

coordination, will not require significant interfacility coordination.

The systems management function, located in the proposed Ground Services

Center, will coordinate the scheduling of IDRSS network communications with

the NCC and coordinate and negotiate space/ground communication requests.

Although space and ground elements will primarily downlink and uplink data,

respectively, some traffic the other way will occur in each case. Onboar-d

payload specialists may request data from the ground and ground customers may

send operational payload information to the station. The systems management

function at the GSC will also perform system-_ide network assessment and

configuration management.

4.4.6.1 Manaqement/Control Hierarchical Desiqn - Ultimate Control Locations

The proposed SSDS design does not encompass much hierarchy above the fa(;ility

level. Each facility will operate autonomously except for- the commur_:i.(;atioi'is

resource scheduling, common ground facilities coordination, and high level

systems monitoring and configuration management.

4-63
The Space Station will therefore have ultimate control over its normal

operations. In the event of emergencies or Space Station subsystem

malfunctioning, the ultimate control can revert to the ground with the Space

Station Operations Control Center assuming a backup role in this area.

4.4.6.2 Extent of Centralization/Distribution of Key Management/Control

Functions

An important design philosophy is the decentralization of function

implementation as much as feasible. This distributed philosophy will

facilitate the user-friendliness and transparency desired of the SSDS. This

distribution will be feasible due to the rapid advances in networking

technology and associated software developments (AI, expert systems, etc.).

The resultant autonomy of operations will require extensive validation and

verification of function implementation as well as rigorous configuration

management control for updates.

4.4.6.3 Scope of Manaqement/Control Allocation per Ground/Space Element

Each SSPE will control itself to the extent necessary. For example, at a POCC

a customer may request Space Station resources requiring coordination via a

mode change. If scarce onboard resources are required, this would need to be

determined either at the SSOCC or onboard, if real time in nature. A highly

centralized or hierarchical command management scheme is not warranted if each

facility has the ultimate control of executing commands and allocating

resources. The Space Station will be the controller of its resources and will

need to protect itself from erroneous or harmful commands, either by physical

means or logical DMS controls.

In genera], each facility may also distribute resource management

responsibilities to individual autonomous facility subsystems and only serve

as an overal], coordinator and monitor of facility operations.

4"64
4.4.6.4 Scope of MonitorinqlAccountinq/Trackinq Performed

The basic philosophies regarding of performance monitoring, data accounting,

and process tracking to be performed within the SSDS are:

i ° These functions should not significantly affect system

responsiveness, impact resource availability, or impact system

development or operational costs.

As a guideline impacts should be less than 10% of that resulting From

functions implemented for basic Space Station operations, unless

these monitoring and accounting Functions are deemed essential for

Space Station.system effectiveness.

o Within these guidelines, monitoring and accounting should be

implemented only to the extent justifiable on cost and utilization

basis. If clear and important uses of the data gathered are not

evident, the data should not be taken or stored.

, The SSDS should be designed as much as possible, however, to

straightforwardly incorporate new capabilities in these areas as

needs arise with time and evolving mission requirements.

4.4.6.5 Coordination of Space/Ground Management Via a Pre-established Set of

Inference Rules for Conflict Resolution

In the man-tended Space Station era, few management related functions or

decision-making will be implemented onboard. AI techniques will still not be

mature and the absence of crew will affects the amount of ground imp].emented

management of space resources. The eventual goal, however, will be a nearly

autonomous manned station, with most management and decisions performed

onboard, either by expert systems or, as needed, by crew intervention.

Conflicts over resource utilization and activity priority, however, will

inevitably arise between the crew and onboard systems and the ground...bas_d

contro], center operators and customers. Inasmuch as possible, the use of a

4-65
prenegotiated, pre-established set of decisions to guide the SSP in these

conflict areas is desirable. The development of these inference rules will

require planning and contingency analysis, as well as pre-mission

negotiations, on the part of customers and NASA prior to mission actualization.

For unforeseen conflicts, it is suggested that the ground program managers

have final decision authority with the exception of time critical or

life-threatening onboard occurrences for which the crew will need to act with

real-time responsiveness. The minimization of onboard conflicts suggests the

development of a thorough DSIT facility.

4.4.7 Key Issues and Recommendations for Further Investiqation

4.4.7.1 Variation of Functional Allocations for Customer Classes/Data T__v__es

No analysis has been performed to determine if different types of customers

or data types will require special management or will be particularly impacted

by the proposed management design. No impacts are obvious. Requirements of

foreign customers have also not been evaluated in this regard.

4.4.7.2 Impact of Possible Future National Security Requirements

If national security requirements become an eventual part of the SSP, a

separate highly secure command and control system may be necessary. Depending

on specific hardware and software architectures selected, compatibility

problems may arise with respect to interfacing to approved national security

processing systems or encryption devices.

Re-evaluation of resource allocation priorities and revised management

strategies would be likely. If the utilization of SSP assets for national

security purposes appears likely, the programmatic issues need to be addressed

as soon as possible.

4.4.7.3 Potential Impacts of International Requirements

A key issue is who has ultimate authority over the commanding of Foreign

4-66
modules or payloads attached to the U.S. Space Station. How can the U.S. be

assured that foreign operations may not inadvertently damage or impact U.S.

space assets? How will common communications resources be coordinated and

allocated?

Another policy issu_ relates to the liabilities on NASA if it impacts foreign

users or causes a loss of data or privacy. This is an extension of

liabilities to U.S. based customers, but program management coordination with

foreign countries and foreign customers will be difficult. Some experience

has been gained with Spacelab but not without policy and programmatic

difficulties.

Another issue is whether NASA will be responsible to foreign customers for the

range of customer services currently specified for the SSDS. Negotiations

with regards to data processing and data delivery responsiveness, data

handling transparency and provision of DSIT services, among others, need to be

initiated as soon as possible to assess possible impacts on SSDS and SSIS

designs.

4.5 COMMAND MANAGEMENT

4.5.1 Introduction

Definition

A definition of an SSDS command is that it is an electronic entity that

conveys information from a user to his payload or core subsystem, to initiate

the execution of a computer directed sequence (program) that results in some

desired action or response. For the present purposes, commands can be thought

of as being initiated by users directly, or indirectly, vocally (voice

recognition), manually (touch panel), automatically (via future scheduled

activity), internal to an SSPE or external at a POCC, CC, etc. via telecommand

initiation, real- and non-realtime initiated, and so forth.

Commands may be batch-assembled onboard or orl-ground for" future automatic

execution and they may be transported indirectly via optical or magnetic

4-67
jr

storage media or directly (electronically) via the SSDS. Commands may be

issued in realtime, on a one-at-.a-time basis, from within the SSPE or from a

ground-based center. Numerous options will be supported by the SSDS as wi].l

be described later.

Commands can also be considered in a hierarchical sense and at a macro-- and

micro-level and can exist in numerous encoded formats at an instant of time,

as illustrated by the following examples:

COMMAND COMMAND ENCODING

"OPEN VALVE 13" 13 ASCII characters in a telecommand packet.

"OPEN VALVE 13" 256 Bytes of MIL-STD-175OA Code.

"ACIIVATE ATTITUDE

CONTROL SUBSYSTEM"

B Bytes in the information field of a LAN

(Layer 2) packet.

COMMAND COMMAND REALIZATION

"ACTIVATE AFI"ITUDE

CONTROL SUBSYSTEM"

64 KBytes of embedded and distributed

subsystem control instructions.

"ACTIVATE SAX O123" A sequence of 20 subcommands that direct the

attachment of physical and communication

resources that support this experiment.

Micro-level commands are the lowest level of commandmfor an effector command,

this would be the voltage signal delivered at an analog or digital output

port. Macro--level commands are then recursive and nested sequences of

sub-macro and micro-commands. Example of these commands are shown below where

the brackets,[], indicate parameters or arguments associated with the command.

MACRO COMMANDS

-. Configure Subsystem 3 []

•- Execute Momentum Dump []

4-68
- Position Antenna K []

- Execute Auto-Calibrate Procedures SAX5678 []

- Deploy UVW[]

- Retract XYZ[]

- Activate Payload Com12B4 []

MICRO CO_WMANDS

- Open/Close Valve [M]

- Position Effector [N ..... ]

As an example, a user might send the command OPEN VALVE 13 as an english

character sequence (e.g., EBCDIC encoded) which could be interpreted in an SDP

by a computer subprogram, or he may send the entire computer subprogram for

execution. Either approach results in the same effector (VALVE 13) action.

Using this same example, the implementation of the command OPEN VALVE 13 is

shown in Figure 4.5.1-I, where: 1) the command is initiated externally and

manually, at a workstation (trace with solid line), and 2) where the command

is initiated automatically and internally (trace with dashed line) in an SDP

program. In both cases a command interpreter (subprogram) is called, with

argument [13], that initiates the I/O subprogram that activates effector

(valve) number 13.

Two final points here are that: I) Command management involves the

consideration of criticality, where commands may be restricted or constrained

based on the current operations being conducted in an SSPE, i.e., criticality

varies with time as a function of SSPE state and possibly other parameters,

and 2) Command management also involves the consideration of the availability

of resources to implement a specific command at any instant of time.

FUNDAMENTAL ISSUES

Some fundamental issues (and options for implementation) in command management

are summarized Table 4.5.1-I in an end-to-end eventsequence in the process:[ng

cycle of a command.

4-69
1._ From Workstation (Interactively)

2._From Subsystem Control Algorithm (Automatically)

_"Open Valve 13'._..jl --- I_,

__ Effector

SS C&eT _-_ _/__SDP P -_'_'r ogra_m "1 _ (1V3alve)

' _, f Memory

r 1

/ ; '"°°

Ground l'r | • :

Commulnication I I I-----II_ i .

I I I Command j+l _,,, ,.

I POCC I | Interpreter i 2 .x. ,n

' II J.I _I LI .L,J/ / Subprogram Activates I/0.. '+- : / II

I / Channel [ ] I+k [END] F / I

_,\\\\_,\\\\',_ _:Workstation::l _- r'Open -.:. valve- _13"] •n [GO T(_• i [13]] [___ J

Figure 4,5.1-1. Micro-Command Implementation with Two Instances of Initiation

Table 4,5.1-1. Issues in Command Management

• Authorization to initiate/transmit commands

• Command Receipt (Data Transport) Validation

- Forward error checking

-. Re-transmit at OSI transport and CCSDS transfer

frame layers

- Re-transmit at application layer

• Checks for executability

- SSIS or SSDS resources may not be available to implement the

command (resources are finite).

4-70
lhe command will result in a mode of operation that interferes

with another payload, i. e., the quality of data captured by one

or more of the payloads is affected. 1-his situation is referred

to as constrained operations

The command will result in a mode of operation that endanuers

the crew, an SSPE's or its payloads---physical damage and loss of

life are possible. This situation is referred to as restricted

operations.

$ Verification of Command Execution

- Application-to-application verification

- Indirect verification (data F/B observations: Video, l/M ..... )

• Command Traceability (Command Logging)

- At sending end

- At receiving end

- At both ends (end-to-end verification/logging)

Command Authorization

Users are required to be authenticated prior to transmitting any command.

This is accomplished by LOGON and possibly other procedures (e.g., voiceprint,

fingerprint, badge, etc.). Specific users identified at LOGON time will only

be allowed to be attached (connected) to specific pre-assigned SSDS entities

(workstations, certain sectors of mass store, a specific payload or subsystem,

etc.); browsing throughout the SSDS will not be allowed and attempts to

violate privileges are reported to the network control center via the

distributed operating system. (Privacy and security are always slgnificant

parts of any private or public data network.)

Onboard Command Manaqement

SSDS Function 3.0 (See Task 1 report) includes all of the user scheduling

activity and subfunction 3.3 (which is onboard allocated) execui:es commands

contained in an Operating Events List (OEI..), an example of which is shown in

4-71
Figure 4.5.1-2. This list is a table of time-ordered commands stored for

future sequencing, and is updated and adjusted in near-realtime as on-demand

requests for payload activations and sequencing are received. This listing

results from user commands and SSDS/SSIS coordination and negotiation for

on-demand and future-scheduled payload and core systems activity.

• Operating Events List (OEL) Is Time-Ordered and Executed in Sequence by Function 3.4

• At Any Point in Time, Resources, Constraints, and Restrictions Are Defined that Can

Support On Demand Event Initiation

• OEL Is Onboard With Identical Copies at CC and GSC

l Current Time I

11:53:08 J

Event

No.

Ej

EIOl

Next --_

Command E_,2

Pointer-------

Ei_3

Ei.4

Operating Events List Function 3.3)

Time

11:40:00

11:50:00

11:53:08

12:15:00

12:28:00

12:38:00

12:42:00

i

Deactivate

SAX XXX

/

Reboost f

Activity Duration Resources Constraints I Restrictions I

Activate 0:58:00 (L,M ..... N) /.

SAX XXXX /

l Last Two

Activate 1:00:00 [O,P,...,Q) _ Commands Executed

SAX YYYY

Excess Resources = (A,B ..... C) l----Resources Available

Activate 4:05:00 [R,S,...,T) _ for On-Demand Service " for Duration of 25 Minute., COMM XXXX

Excess Resources = (D,E ..... F) --,---Resources Available

Activate 8:00:00 (U,V,...,W) i for On-Demand Service COMM XXXX for Next 13 Minutes /

Excess Resources = NIL _'--,-----No Resources Available

for On-Demand Service

Figure 4.5.1-2. Operating Events List

Function 3.3 is implemented in a computer program that receives the OEL from

Function 3.2 and steps down this time-ordered listing based solely on time.

Function 3.2 assembled the OEL taking into account requirements for resources,

restrictions and constraints, however, these components of the OEL are

re-validated in terms of the current real operating mode prior to execut:Enq

each command. The principal points to be noted here are that: I) Functi.on

3.3 steps down the time-.ordered Operating Events Li.st issui.ng the requ:i.red

commands that activate and deactivate payloads, subsystems ..... _nd 2)

commands for" on-demand payload activation and sequencing are coordinated by

Fun('tion 3.2 and when resources, restricted and constrained demands (;z_n be

4-72
satisfied (or when priority allows deactivating an active payload to satisfy

the demands) then the OEL is updated immediatel_ to include the on-demand

request (which was received in the form of a command). Various scenarios are

possible here; one that allows for immediate payload activation, activation

within a short time (e.g., seconds or minutes, whenever the resources,

constraints or restrictions can be satisfied) or the user maybe notified that

based on his priority, and his demand for some specific resource (or

constrained or restricted operation) he cannot be immediately attached and the

next window of operation for his payload is at time XXX XXX, and for a

duration of XXX units of time.

Schedulinq Rctivity

It is the intent here that the SSDS be as friendly to users as is possible and

that he have full access to his payload with the least constraints and

limitations. The scenario envisioned is that after he executes LOC_N

procedures (at a minimum: password, account no., and application process ID)

and is authenticated by the SSDS, he can freely communicate with his payload,

e.g., turn it ON, turn it OFF, execute diagnostics, perform calibration, quick

look ..... Some limitations in this procedure, however, are obviously

mandatory based on common sense safety and engineering principles. These

include the following:

I , SSIS or SSDS space/ground resources may not be available to implement

the command.

, The command will result in a mode of operation that interferes with

another payload so that the quality of the data captured by one or

more of the payloads is affected. (This situation is referred to as

constrained operations.)

, The command will result in an operation that endangers the crew, an

SSPE, or another payload ...... physical damage is possible. (This

situation is referred to as restricted operations.)

4-73
The following key points are reiterated:

I , SSIS and SSDS resources in space and ground are finite and must be

carefully managed.

, Constrained o_erations affects the quality of data captured, the

effects of which may not be immediately observable.

3. Restricted operations involves hazardous situations that endanger"

crew life and/or affect equipment damage.

Obviously, the user may have the priority to adjust the current SSPE's

operations so that his command can be immediately executed or, if not, he must

enter an interactive negotiating phase with Function 3.2 (scheduling activity)

to arrive at an agreed-to future timeline of operation. This scenario is

depicted in Figures 4.5.1-3 and -4 which shows users coordinating with control

centers to develop this agreed-to-schedule.

Function 3.0 - Scheduling

Shared

Resources

• TDRSS

• Comm

,ss,_ r lssP 2 _+_con:,o, I

'{SspE, I,

I Control K L

I _°"= J"-_ Center Ix

Figure 4.5.1-3. Schedule Development

__ SSPE J IA

Control I_-

Center IN

U,;ers

I

u_stse,2I__

;r 1

• ?+°"1I

_Jus r_l I I

4-74
Start I

Customer's Command i Customer Negotiations

is Blocked Based on _ I

Resources, Constraints, __,1 • All Electronic

or Restrictions _J • Interactive

_ - I • Like Airline Reservation System*

Function 3.0 _ • Priority System - Can -

• , I Preempt Lower Priority

I I .......... I Users or Perhaps Pay

I I: 8D_tltioen_tS_r_')l Additional Cost for I ,rem,um,esou.o.

I I Long- and Short-Term K_ •

I _Sc,e_u,e .Oeve,o,_ntJ__

I _ ._oE_ ._ Agr_-to-Scheduie

I Function 3.3 I "_ • Immediate Access - Resources, Constraints,

I _ 1 I _ and Restrictions Can Be Satisfied or Current I _vents I lu¢, _ate_ _ _perations Can Be Adjusted Based on Priority

I .............. _ Execute CommandsII°EL •FutureAccess

m Function 3.4

Sequence SSlS

and SSDS Resources

L L

Fyloads I'°°"

Final

election

I

I

*During Negotiations for Future Schedule, Time Slots Are Sequentially

Reserved and Released Just as Airline Seats Are Reserved and Released

as Options Are Considered By an Airline Customer in Negotiations

Leading to Final Flight Selection

Figure 4.5.1-4. Schedule Development

Realtime Payload Command Manaqement

_t this point a preview and summary of the recommended payload command

management system is given with details to follow later. The management

concept proposed is automated and implemented onboard and in realtime ......users

are given maximum flexibility to interact with their payloads and subsystems,

but will be disconnected (reactive control) if their operations exceed

parameters associated with the original connect/attach commands.

Additionally, the system also includes a priority structure so that lower

priority payloads can be automatically disconnected to provide resources for

higher priority operations. This leads to a totally automated management

system that can be driven by one of the following: schedule, on-demand

requests, and event.-oriented observations experienced by a payload, lhis :i.s

especia].ly important for the unmanned SSPEs.

4-75
Numerous strategies and options for command management have been proposed and

many appear to be reasonable until one attempts to implement them in

realistically sized hardware and software. The problem one encounters is that

the systems become extremely complex with large overheads and time delays and

even then "sneak circuits" may still exist that could allow a restricted

command to be executed in certain extremely remote and in unusual

circumstances. It is expected that safety will be a principal consideration

in the management of commands and that command management systems cannot be

implemented in a way that cannot be analyzed to be proven to be free of hidden

logical and physical paths that could lead to the execution of a restricted

command and a subsequent catastrophic event. For this reason the system

described later will use an independent "electronic key" that controls

resources (predictive control) required for restricted operations.

Core command management is considered separately, later.

4.5.2 Resource-limited, Constrained, and Restricted Operations

This paragraph will introduce a formalism that attempts to capture the problem

of payload command management in terms of a model that allows or inhibits

commands to a payload based on the three considerations previously discussed:

resource limitations, mutual compatibility and cross-interference associated

with multiple payload operations (Constrained Operations), and hazardous

operations that affect crew safety and physical damage to payloads/core/SSPE

structures and equipment (Restricted Operations). Associated with these three

considerations, we shall define a triplet T of vector components RSCRCS,

CONSTR, and RESTRICT, defined as follows:

T = [(RSCRCS), (CONSTR), (RESTRICT)]

where

Resources = RSCRCS = (a I, a 2.... aj),

Constraints = CONSTR = (b I, b 2.... bk),

Restrictions = RESIRIC"I" = (c I, c2.... Cn).

4-76
The componentsof each of the three vectors are an ordered set of

not-necessarily numerical components, as will be described in detail later.

For now a brief description of each vector is given below:

RSCRCS - Has components which are the SSIS/SSDS resources available at

some instant of time or that are required to support a certain payloads

operation immediately or at some future time and in some specific mode of

operation.

CONSTR - Has components that specify the compatibility between payloads;

compatibility here relates to interference between payloads that may

affect data quality captured by one or more payloads.

RESTRICT - Has components that specify non-compatibility of a payload and

other SS functions that affect hazardous operation associated with safety

and physical damage considerations.

The problem in command management can now be stated as follows: At no time

shall an SSPE's payload be operated so that constraints associated with

RSCRCS, CONSTR, and RESTRICT are violated. The implementation of this rule is

discussed later.

4.5.3 Modes of Operation

The normal flow for a payloads space operation is: delivery to space, SSPE

integration, production, and finally disconnect and transport back to earth.

Within the integration and production phases one can usually identify several

modes of operation (e.g., test, checkout, diagnostics, calibration, production

mode 1 (high power), production mode 2 (low power), and so forth) where the

RSCRCS, CONSTR, and RESTRICT vectors may have different values for each mode.

The point here is that at some instant of time, a payload may be allowed to

operate in MODE 1 (e.g., checkout/diagnostics) but not in MODE 3 (e.g.,

production), for reasons associated with violations in these constraints.

These concepts are i].lustrated in Figures 4.5.3-I and -2.

4-77
Example 1 _ State Diagram for Machine

Eight I

Discrete AC2, C6 ACT /

Input C, _'" "C3 ___.'_Cs |

Comman._ _. _r .ac.,.e

Operates

C, • C4 in Three

(i = 1,2,...8) Modes

J Example 2 I ............. S_ate"Di_gr_m for Two-Stage

T Flip Flops i_ l T-FF Machine use /ncr%%enn¢_ , IT 1_1T l_-

_._J-"_ I Oil OI" B _-_S_:?e)

Mac ,neo erat

Figure 4.5.3-1. Finite State Automata (Mode Diagrams)

Externally- I

Generated ;

Commands

PLAN

TDM XXXX

_ Internally- |

Generated _ /

com .o0s, ,ec.ort

NIUISDP

Effector _

Constrained

Operations -

Interferes

With COM xxxx

Restricted

Operations -

Cannot Be

Activated With

EVA in Progress

To

Figure 4.5.3-2.

T, = {(RSCRCS), (CONSTR), (RESTRICT)}_ (i = 1,2,3,4)

Power

Off

T1

Mode T2 I

C_ 1

Mode Cz

2

C5

C4

Mode

3

T 3

Command Classification Example (1 of 2)

T° "J"T1 "/"T J_T2 "/"T3 I

4-78
Mode Resources Constraints Restrictions

NIL NIL NIL

Ti

Mode 0 {(NIL), (NIL), (NIL)I0

(Power Off)

Mode 1 Pwr = xx kW NIL NIL {(a, .... aj), (NIL),

(Diagnostics) TCS = xx GPH (NIL)I,

Crew = xx Mins

Mode 2 Pwr = xx kW Incompatible NIL {u, .... aj), (b, .... bk,

(Calibrate) TCS = xx GPH With SAX 1234 (NIL)I2

SDP = xxOPS and(}. 35 °

Mode 3 Pwr = xx kW Incompatible • No EVA {(a_ .... aj),

(Production) TCS = xx GPH With COM 4567 • Crew Monitor (b, .... bk),

SDP = xx OPS and (! - 25 ° Mandatory (c, .... c.)}3

Command Checking

Resource

Command Availability Constraints Restrictions

C, Y N N

C2. Y Y N

C3 Y Y y

C, Y N N

Y = Yes

Figure 4.5.3-2. Command Classification Example (2 of 2) N = No

4.5.4 Definition of RSCRCS (Resources)

The components of RSCRCS are an ordered set of SSIS/SSDS resources required to

support the operation of a payload(s) or the excess SSIS/SSDS resources that

are available at some instant of time. Figure 4.5.4-1 ilhJstrates the notion

in a table where the rows are the complete set of payloads, and the columns

are the ordered and complete set of resources. /he entries in row i

constitute components of the vector RSCRCS(i) required for a specific mode of

operation For the i'th payload. It follows then that the total resources

required at any instant of time to support a11 active payloads is the vector

quantity

SRES =:

BI

Z

i=1

RSCRCS(i)_A(i)

4-79
RSCRCS = (a. az,...,ai)

Payload

:Power TCS

No. Modes al a2

1

1 i

2

J

1

2

Rscrcs Components (Space and Ground)

Mass Store

Rand I

a3

Work

Seq Station

I ai as

I

I

I

I

I

I

I

i K

• I :

:l :

1

N 2

L

I

' ' II I ', I

I I

! I i i I ,

_ 2 2 4.05 I 2.4 50kB I 0

Example: Payload 2 (SAX XXXX), Mode 2 (Calibration)

OpslSecl TV

a s ! a?

!

i

I

t I

I I

1 I

Audio Crew-EVA/

" V

/

/

/

I

I

1 ch I 2 Ch Mission Spec/

1 Sta 40 k S-G I S-G 15 minutes /'

Figure 4.5.4-1. Resource Requirements

where A(i) is a binary-valued discrete that takes the value 1 if a payload is

active or 0 if a payload is powered OFF. It is a function of the scheduler to

assure that no planned operations exceed the capability of the SSIS/SSDS

resources, and it is the responsibility of the command manager to disconnect

payloads exceeding any one component of RSCRCS(i). Many of the components

will be sensed directly (power, TCS .... ) and others will be sensed indirectly

(e.g., crew time). In the case of crew time the customer may be given arl

option (and the cost, say at $50K/Hr) to continue, for example, diagnost:ics on

his payload, or the SS commander may discontinue the operation once his

allocation for this resource is exceeded. Excess resources are computed by

subtracting the vector SRES from the vector ARES, the available resources at

that instant of time.

4.5.5 Constrained Operations

The definition of constrained operations evolves around the mutual

compatabi].ity of operation between PAYLOAD. and PAYLOAD. and between

z ]

I)AYI.-OAD. and certain core operations. A constraint parameter C.. (see

z ]]

4-80
jFigure 4.5.5-1) is defined to be the constraints that the i'th payload (in row

i) places on the operation of the j'th payload (in column j). For example,

the i'th payload may:

oad/Core

I Payload

.. IOperating

NO. I Mode

1 I 1

2

i

21 i

2

k

CONSTR = (b,, b2,...,bk)

Payload No.IMode

2

lr21...l 

C21

C12

eej el Core

Operations

Ctp C1¢

C_ C_

I

1

P I 2 Cp, Cp2

I

C_

Cp¢

i

Definition: C,j ---Constraints that the i'hPayload Places on the Operation of the j'" Payload or

Core Operations

Figure 4.5.5-1. Payload-to-Payload/Core Constraint Matrix

1 , Place n__ooconstraints on payload j.

, Place limited constraints on payload j (e.g., the j'th payload can

operate in the standby or calibrate modes but not in the productJ.on

mode where it has a spectral emission that interferes with payload i).

. Place total constraints that inhibit payload j from being powered ON

in any mode.

"l"he d:i.agona], matrix elements are not meaningfu], and are not defined and the

matrix is not symmetric.

4"81
]he matrix will be initially prepared during the initial feasibility

discussions with the customer to determine cross-interference impacts between

payloads and realizable windows of operation. The matrix obviously changes

with payload changeout and may be adjusted during space operations when

unanticipated coupling between payloads is observed to degrade the quality of

data coll_cted by a payload.

4.5 6 Restricted Operations

Restricted operations include the hazardous operations resulting from

activation of certain payload operating modes. The commands to activate these

modes will be defined to be restricted and will be inhibited by the SSDS when

incompatible with other operations. These other operations may include:

i • Other payload operations (e.g., possible hazardous operations

resulting from production of incompatible byproducts including

solids, gasses .... ).

, EVA Operation

- Total SS sphere of proximity ops

- Subset of total proximity sphere

- With safety provisions such as laser protective eyewear

3 ° IVA Operation

- Module must be unmanned when payload operating

- Module must be manned to verify correct operation of

payload

4. OMV, OfV, Orbiter Operations in proximity of an SSPE.

This concept is illustrated in Figure 4.5.6-1 with an example definition of

the vector RESTRICT.

4-82
RESTRICT = (c, c2,.., c,)

Components of Restrict

/

Payload cl c= c3 c 4 cs /

No. Mode EVA Ops IVA Ops OMV/OTV NSTS Ops& RMS Ops Pa(_o:d /

1 1 /

2

i

, : j

,,. 2 I - I -

J i /," I-Inhibit

.° - _ ° .

IrrOW_ Laser andEVAand

OMV/OTV/NSTS Ops Are Inhibited or Conversely, if EVA/OMV/OTV/NSTSOpsAre

in Progress, the Command to Activate this Operating Mode Is Restricted and Will

Be Inhibited by the SSDS.

Figure 4.5.6-1. Restricted Commands

4.5.7 Levels of Command Inhibition

The pr'oblem in implementing a command management system is to inhibit commands

that violate constraints/requirements associated with the components of F

(RSCRCS, CONSTR, and RESTRICT). Three levels of control can be identified:

I . Function 3.0 absolutely controls which payloads are consuming

resources and the quantities of resources being used (e.g., power,

flow rates, crew time .... ). The utilization of resources is sensed

directly (e.g., current sensors for each payload) and also indirectly

(use o? crew people vs time). Payloads will be detached from

resources when OEL-specified allocations are violated (reactive

control).

. Payloads are only allowed to communicate with certain

subsystemsservers as determined by the ()EL. Function 3.3 contz_ins

4-83
the negotiated schedule for resources/entities and directs session

establishment (connections) with only these authorized entities.

Payloads will typically communicate (connect to) workstations, mass

stores, C&T, and Function 3.0. Any attempt to communicate with other

payloads/core systems directly will be reported (as an unauthorized

access attempt) to Layer 7 Network Control/Security via l.ayer 4

Reporting Statistics.

0

This level is the problem area; where a payload has direct

access/control over effectors that can violate

constraints/restrictions that were placed on it when it was powered

ON, e.g., a payload may be attached for diagnostics or calibration

only, and is constrained/restricted from entering a mode where its

primary instrument (e.g., a laser illuminator) is turned ON.

4.5.8 Command Management Options and Selected Approach

4.5.8.1 Payload operations

Command management options for payloads are discussed below:

I , Prior to enabling a payload, check its processor's executable code

for restricted/constrained commands. The problems with this option

are:

a. Difficult to implement: II0 can be activated by numerous

addressing options ....directindirectsubroutinerandom number

generator/ .... many possible instruction sets, and so forth.

b° CPU generates "garbage" causing inadvertent I/O operation,

resulting in a uncontrolled restricted operation.

2° For command checking after activation: route all commands thru

Function 3.0 for checking prior" to release to payload/subsystem ......

same problem as above.

4-84
3 . Trust user: He states that his program does not include

constrainedrestricted operating modes and he will label all his

commands in the "OPEN" (e.g., ASCII encoded) for Function 3.0

checking---still have the problem of l.b above even if you can trust

the user.

, Implement "electronic key" that Function 3.0 uses to "unlock"

resources associated with user's requested mode of operation

specified in the OEL.

Command Manaqement - Restricted Operation

It is expected that the NASR safety community will require an independent

safety control function for all restricted operations and for this reas6n

option 4 above (electronic key) is selected for restricted command management;

Function 3.0 unlocks resources required for restricted operations and the user

does not solely control these resources. (It can also be expected that

mechanical locks/stops, locked/guarded safety switches, procedural operations,

and other non-electronic management concepts will also be employed.)

Command Manaqement - Constrained Operations

Constrained operations do not affect safety and option 3 above is acceptable.

The recommended implementation is that payloads report their mode of operation

at all times (when they are powered ON) to Function 3.0 at a rate of between l

I/sec and 1/min. If a payload enters a constrained mode and reports it, or it

does not report its operating mode at the required interval (e.g., software

"bug" may have resulted in a branch to an undefined operating mode) then the

payload will be powered OFF and the event will be recorded in the arch:i.ves and

also distributed via an ancillary data FLRG which alerts all users of the

possible interference problem (recall that safety is not an issue in

constrained operations). The flag will contain adequate information to route

subsequent inquiries to the source and the time at which the anomaly occurred.

The risk in this approach is that a payload will enter a constrained mode of

operation, and not report it to Function 3.0, thereby jeopardizing the quality

4-85
of data being captured by other payloads. This risk is minimized by

implementing NASA procedures for validatinq the reporting system during

qualification/acceptance testing of payloads.

Command Manaqement - Resource Allocation

As discussed earlier, payloads will require different resources for its

different operating modes. If a payload is powered OFF, an activation command

will be routed to Function 3.0 which puts the command in the OEL along with

the resource (specified in RSCRCS) required, and whether it is for immediate

or future execution, as discussed earlier. Thereafter, commands will be

routed directly to the payload with no checking required.

4.5.8.2 Command Management - Core Operations

The management of commands to core subsystems are in a special category since

subsystems are, in general, continuously active and may be required to provide

normal services (e.g., attitude control) in parallel with diagnostic or other

operations. Subsystems are also special since they are developed and operated

by NASA, as opposed to a customer, and must endure for the life of the

program. This last requirement will justify the development of large scale

expert system command checkers whose cost can be "amortized" over the life of

the program. Predictive command checking via expert system checkers will form

the basis for core command management

Because of the complex and time-dependent interaction between certain

subsystems or even within a single subsystem, commands must be rejected (e.g.,

turn OFF the life support system, VENT a crew--occupied modu].e, CLOSE oxygen

valve to a crew-occupied module .... ) based on the physical location of crew

personnel and numerous other SSPE state parameters. This leads to the

definition of yet another vector called SS STATE which is defined, by examp].e,

in Figure 4.5.8-i. The basic procedure for managing core commands requires

the following steps for implementation:

i , Predefine all possible macro..-,and micr'o.-.commarlds, where a command is

designated as CMMDi[ ], i = l, 2 ..... L. '['heinteger L ir_dic_:_tes

4-86
the total number of commands and the brackets indicate parameters or

arguments of the command.

,

Prior to executing any arbitrary command perform a predictive test to

determine the executability of the command given the current SSPE's

state vector using the previously mentioned expert system checker.

An Ordered Set of Not Necessarily Numerical Components that at Any Instant of Time

Characterize the State of an SSPE to the Degree Required to Implement a Command

Management System.

SS State : (d,, d2,...,dm)

= (Payload Status, Subsystem Status, Crew Status,...)

Payload Status Subsystem Status

. I I _.. SDP No. 1, 3, and 5 Active

I I I I Momentum Dump 65% Completed I )

' I _ I GPS Receiver No. 1 Active I [

k ' I . GPS Receiver No. 2 in Diagnostics I

I Inertial Package No. 2 Active I

I Inertial Package No.J Standby I (

Crewperson Status

No. 1

EVA at

Location

XYZ

Time to

Complete Estimate

= 02:00:00

I No. 2

I Hab

I Modulej

Figure 4.5.8-1. SSPE State Vector Definition

The end-to-end flow of core commands is shown in Figure 4.5,8-2 which also

illustrates the concept of a core operator in a hierarchy of authorized

operators that are allowed to transmit certain classes of commands.

4.5.9 Example of Payload Command Management

An example of command management is shown in Figures 4.5.9"1 and 4.5.9-2 for a

hypothetical payload TDM XXXX. An electronic key is used to control the prime

power resources to the high- and low-voltage laser power supply. In this case

the user may enter the restricted mode (via restricted command that he issued)

but no emission from the laser is generated and no hazardous operation

results. Since he is reporting his mode to Function 3.0, he. will be alerted

and/or disconnected.

4-87
I

SSPE Control Center | SSPE

I

/ I I C°mmand I I J Onboard I

Authorizationl _lAuthorizationi . J Command I

/ I I"i°''c'' I ' I °re'ionI

-- I,u,,o:,,,t I '

•-,On |'°"--m"l I

I I lunrestricted I

I I lunc°nstrajned_

O_ '_,r ator) CMMDj[ ] II I Command Preassessment I

, I!Restricted :, I Command Final IPassl , : I [ I

J I CheckerlFilter I Constrained I Checker I I ApplicatiOn I

,o--, I I, °.o._tsst-c,

• I of CMMDi[ ] ! _ I I _ ........ /STATE

l I' I /

I i I sss,,,_I/

Reject Command I- . _ I I Data I /

With Reason I Heject I I Base I |

Stated L I _ /

/ | -I w

Figure 4.5.8-2. Core Command Checking

Laser Off _ : _ Laser On _-

.oloo__ o_..-2_"

Power On_ ,,

/ \ c, y .... \. _:--/

{ Power _ { Standby _- - I "'

_o. ;,o,c \"_e'_o_. C'_

T1

T3

Figure 4.5.9-1.

Disconnect Rule I

For i = 1,2,3

If T, ' TSCHEDNEGOTIATED

Then Disconnect Payload

State Diagram - Hypothetical Payload TDM XXXX

4-88
I Core Subsystems J

/

(

TCS

L_ Sense I-"

TCS

Prime I

Po _er | I

PP

L_+5 VDC High

I Power J'-+15 VDC Power Supply

Instr

Controller

CLAN - Core Local Area Network

PLAN - Payload Local Area Network

PP - Prime Power

TCS - Thermal Control Subsystem

PP

Mechanical

Stops

Upper

Boom

e - Cone of Laser

Pointing Angles

PLAP

TDM XXXX I

Figure 4.5,9-2. Block Diagram -- Hypothetical Payload TDM XXXX

4.5.10 Command Management Scenarios

Numerous scenarios should be developed to validate the command management

system previously described. Parameters that generate ideas For scenario

sequences include:

i .

2.

3.

4.

Manned/unmanned SSPE's.

Onboard/Ground OperatorCustomer.

Payload Duty Cycle: lO0%/under 100%.

Maintenance, diagnostics, payload integration, buildup ....

operations.

5. Typical Core Operations - reboost, OMVIOIV operations .....

6. Ground/Onboard interaction during hazardous operations - fueling,

docking .....

7. Unmanned SS operations.

4-89
Only one scenario is considered at this time and it is developed in the

remaining subparagraphs.

4.5.10.1 Scenario No. I: Payload Operations for COM 1234

In this scenario a customer is defined that operates from a POCC or from his

own facility (he is mobile) and he has a payload (COM 1234 in the SS) that

operates with a duty cycle of less than I00%. The payload has been qualified

by analysis, test and inspection procedures (conducted by the customer and

witnessed by NASA) to operate in these three modes (which are the basis For

command management):

I , Mode 1 - COM 1234 is powered ON and will execute software transmitted

via telecommand or accessed from the onboard mass store. Used For

integration of new software modules and other miscellaneous Functions.

. Mode 2 -The data acquisition electronics (principally the DC offset

and non-linearity in the A/D converter) are calibrated using a

low-power stimulus; while presenting no safety or damage hazard, it

has a spectral emission that interferes with payload C(_ 5678 and

hence places a constraint on the simultaneous operations of these two

payloads.

,

Mode 3 -Used for acquisition of quick-look and production data and

has constraints and restrictions placed on its operation.

In the definition of this payload to the SSIS/SSDS, the resources,

constraints, and restrictions are specifically characterized and quantified

for each of the three modes. In addition, the payload will be required to

report its operating mode to Function 3.0 so that constrained operations c,_xn

be discontinued. To implement this reporting, COM 1234 will be required to

measure parameters in its I/O section that confirm (even in the presence of a

si.ngle failure) the ON/OFF status of the low power (Mode 2) and high power

(Mode 3) stimuli. Recall that Function 3.0 is relying on the payload to

correctly report its mode but in a11 cases has an indepei'ident e].ectroriic key

controlling the restricted operations coi'_ducted in Mode 3.

4-90
On a particular day the customer is at the POCC and logs in for payload COM

1234. He is authenticated and a menu of options is displayed on his t()r'min_l

as follows:

SOFTWARE DEVELOPMENT

SCHEDULE OPERATIONS

PAYLOAD OPERATIONS

He selects the last option and is given a status summary of his payload as

follows:

COMM 1234 IS CURRENTLY POWERED OFF.

NEXT SCHEDUI..ED ACTIVITY IS AT TIME

04:00:12 AT LAT XXX AND LONG YYY

FOR A DURAIION OF 12 MINUTES

The customer wants to activate his payload for calibration only, to

investigate some anomalies he has observed in previously acquired data. He

estimates that approximately 45 minutes will be required for this activity so

he will request one hour of activation time in the CALIBRATE mode.

Calibration for COM 1234 is not automated and the customer" will necessarily

interact with the payload to implement the calibration procedures. COM 1234's

production data, however, is acquired automatically and the customer" need not

be involved (at his option) in this operation. Onboard implemented functions

3.3 and 3.4 will automatically sequence COM 1234 ON, the next time which will

be at O4:00:12 corresponding to coordinates LAT XXX and LONG YYY, and will

automatically sequence down the payload after the 12 minute production data

acquisition cycle is completed.

lhe customer, interacting with the POCCm-resident software develops arP

activation command that specifies the following:

MODE : CALIBRATE

"TIME ON: 60 MII'NS

START rIME : IMMEDIATE:

4-91
The command is transported from the POCC via the following transparent (to the

customer) operations,

1 • A session is established with the SS Control Center (CC) using option

1 in Figure 4.5.10-I. In this option the POCC is a node in an X.25

circuit providing network services (lower 30SI layers) to the CO.

. After the connection is completed, the command is transmitted and

will be automatically processed in the CC. The CC has knowledge of

the operating modes of COM 1234 and retrieves from local memory tlne

triplet T(CALIBRATION) that specifies the resources, constraints and

restrictions associated with the calibrate mode of operation. The

scenario splits into two scenarios (A and B) at this point: GO TO

3.A for the completion of scenario A and to 3.B for the next step in

scenario B.

OSl OSl

U::resso r

Operators r_l k _MO0_40 [_ J_

(Human) | JProcessor(s) 0 300-2400 ' Asyn

' ' ' t32 bit Tel No. (1-xxx-xxxxxxx), 0

_- JAddress(___ l, Direct

rvU_U_m'lP_-rl L" / Public I / baud

•-- _ Modem

SSPE

Function

3.213.3

On-Site _

Terminals J_111111111111

for Users_

Direct - Leased, Scheduled, Dedicated,.. J

®

User ]RS-232C_

Processor

_ Option J

interactive

Operations

Figure 4.5.10-1. Communication Interfaces for Scheduling

4-92
3A. The CC has determined by a simple scan of the OEL and the current

operating mode that T(CALIBRATION) for COM 1234 can be satisfied for

the next 60 minutes: the payload can be immediately attached to all

required resources and no restriction or constraints exist for this

time period. The customer is notified, the onboard OEL is updated

for immediate activation of COM 1234 (the onboard crew is audibly

alerted that a OEL adjustment has been made but this class of change

does not require their approval -- the audible is an indication of a

"for-information-only" type change). At this point two seconds have

elapsed since step 1 was initiated.

3B. At the CC the onboard in-progress operations are scanned and it is

determined that the resources are available, there is no restriction,

but that a constraint exists (COM 1234 has a spectral emission in the

CALIBRATE mode that interferes with COM 5678). It is further

determined that the constraint will dissappear in 12 minutes when COM

5678 is scheduled to be deactivated, but then there will be a

resource limitation in power. At this point two seconds have elapsed

since step 1 was initiated.

4B. Several options for future activity must now be considered since COM

1234 does not have the priority to adjust current in-progress

operations and near future operations.

5B. The scheduling operator at the control center (see Figure 4.5.10-I)

will interact with the scheduling program to develop an agreed-.to

future schedule (scheduling is not a fully automated function). [his

interaction with the customer will, in general, be all-electronic.

The customer at the POCC is informed that immediate attachment of COM .1.234 is

impossible based on his priority (priority adjustments are possible via voice

telecommunications through the NASA hierarchy). The customer now in_.eracts

through his terminal examining the attach options sequentially presei'Yted to

him in a menu similar to the way customers consider and select airline flight

•4-93
options. The scheduling operator in the SSCC develops options for the

customer (after they are computer validated in terms of resources,

constraints, and restrictions). "Limited" changes are authorized to be made

in the CC without onboard crew approval, however, voice communications with

the SS commander will be required for approval of certain options prior to

their being presented to the customer.

ATTACH PROCEDURE IMPLEMENTATION

This scenario is common to most payload operations. The Operating Events List

(OEL) is the master source for primary onboard sequencing (secondary

sequencing is initiated from subsystems or payloads) and identical copies

reside onboard and in the SSPEs CCs. The OEL was described earlier and is

shown in Figure 4.5.10-2 as residing in Function 3.3 and is the driving source

for Function 3.4, as a function of time. When the time of execution for a

command has been reached, the triplet RSCRCS, CONSTR, and RESTRICT are

revalidated against the current actual operating mode and then passed to

subfunction 3.4.1 and 3.4.2 for execution. Resources for restricted

operations are unlocked (as required) and attached in the required sequence

Power

tOn,O. Co°tro,

t .ence

Execute OELI I_ _a_ad

I I I I Operations I _i_Onb°ard_']ttpoint I _)0_ I Pallet

ICommand I / _ Data'_T--_ Est _

_ScSk/_ _ _ Sessions I ( Ground_--'IL--_ Network C°mrnandsl _ 0 N_tta_ e nts'_/)"_

Current Revalidate: • Resources _Sequence _ _._ Via...........

Operating a Constraints Core _ .r,j Communicationl - ( Schedule jr

Mode • OperationsSystems-p11 ControlNetwork II1"_ _

Operating Events List

Resources Network Attach Quality of Time Command Duration Constraints

Restrictions Parameters Service

Workstation Address XXXX, Class 2

11:47:00 Activate SAt XXXX 1:43:00 T = I(X),(Y),(Z)I POCC Address XXXX .... Class 2

Reboost Expected T--

0:30:00

Figure 4.5.10-2. Payload Sequencing

4-94
(e.g., ATTACH TCS (COM 1234), IF TEMP LESS THAN TI, THEN ATTACH POWER (COM

1234), IF CURRENT (COM 1234) LESS THAN 11, THEN ... ).

Since COM 1234 has been powered OFF (duty cycle less than 100%), then when

powered ON it will automatically boot-up via EPROM-embedded code and then

self-test and self-initialize J,tself to become an addressable entity on the

payload LAN (this payload has a dedicated point-to-point data link to C&T for

the primary sensor but is mode controlled via the LAN).

Function 3.4.2 (see Figure 4.5.10-2) indirectly activates Function 4.2.5.1

(see Figure 4.5.10-3) which is distributed between onboard and ground and from

information in the OEL connects a11 of the onboard entities (binds into

sessions) required to support COM 1234's commanded operation.

At this point in the development cycle of a command management system, the

ground elements are assumed to be open-loop controlled via the OEL and no

formal REQUEST/ACKNOWLEDGE message interchange for ATTACHMENT is required.

The SSPE's CC coordinates with the various ground components to support the

OEL and has a permanent session with onboard function 4.2.5.1 to indicate when

a required ground resource will not be available to support the OEL.

I

Function 4.2.5.1 Comm,',nication Network Control

I

Onboard

Session

Control

Program

Session/

Initia

<

Figure 4.5.10-3. Network Control - Session Initiate

_ Permanent (PermanentVirtual Session(s)) Circuit(s) _ SSPE Center Control

CCSDS _ Ground

Environment OSI

Environment

;

I

I

I

I

Status

Monitor

to Support

OEL

4-95
REFERENCES

I. Space Station Data System Analysis/Architecture Study, Task 1 -. Functional

Requirements Definition, DR-5, MDC Report No. MDC-1343, Revised 1 May 1985.

2. "Guidelines for Space Station Data Systems Standardization (Issue-I)," JPL

D-1414, April 1985.

° "CCSDS Reference Document on Space Data Systems Operation with Standard

Format Data Units, System and Implementation Aspects," Issue 1, November

1984.

4, "Recommendation for Space Data System Standards: Standard Format Data

Units -- Concept and Primary Label," CCSDS Document, Red Book, Issue-O,

December lgB4.

5. "Recommendation for Space Data System Standards: Time Code Formats,"

CCSDS Red Book, Issue 2, November 1984.

6. "Recommendation for Space Data System Standards: Packet ]elemetry," CCSDS

Blue Book, May 1984.

7. "Recommendation for Space Data System Standards: lelemetry Channel

Coding," CCSDS Blue Book, May 1984.

B. "Report Concerning Space Data System Standards: lelecommand, Summary of

Concept and Service," CCSDS Green Book, Issue-4, July 1985.

9. "Recommendation for Space Data System Standards: ]elecommar_d, Part--l:

Channel Service," CCSDS Red Book, Issue-l, July 1985.

10. "Recomnlendation for Space Data System Standards: ]elecommand, Part-.2:

Data Routing Service," CCSDS Red Book, Issue-2, July 1985.

4-96
11. "Recommendation for Space Data System Standards: Telecommand, Part-3:

Data Management Service," CCSDS Red Book, Issue-2, July 1985.

12. "Recommendation for Space Data System Standards: Radiometric and Orbit

Data," CCSDS Red Book, Issue-l, April 1985.

13. Proceedings of the IEEE, Special Issue entitled "New International

Standard Architecture and Protocols for Distributed Information Systems",

Volume 71, No. 12, December 1983.

4-97
5.0 COMMUNICATIONS ASSUMPTIONS AND TRAFFIC ANALY,';[S

The purposes of this section are to define the communications-related

assumptions that have been made in the process of defining an SSDS

architecture and to summarize the methodology and results of a communications

traffic analysis. The assumptions are necessary because, at this early stage

of the Space Station program, many design and operating features external to

the SSDS have not been defined. The communications traffic analysis provid,:_s

an estimate of total traffic load on Space station communication links taking

into account the best available definition of mission requirements, core

requirements, and operational scenarios.

The keyresults of this traffic analysis are summarized below:

A single TDRSS SA channel has sufficient capacity to support the IOC

Space Station program.

The allocation of two (or more) SA channels to the Space Station

Program would reduce scheduling competition between the Space Station

and the platforms.

lhe S-band and Ku--band services in the SA channel allocation off:er an

attractive way to keep core and customer communications traff'i.c

functionally separated and to also provide a level of redundancy for

critical communications.

The growth scenario indicates that the currently planned TDI_SS SA

capability may be inadequate. However, there is significarlt

uncertainty in the mission model and operational scenario, esp(_cially

with respect to foreign payloads, for the growth time l:)eri,_d.

Video communicaton requirements will be a significant factor" in the

total communications tr'affic. [here is a need to improve I.l"le

definition and understanding of: the uses, timelines and quality

re(.luiromer_ts associated with this video tr'aff i.c.

5-I
5.1 Assumpt:,,ns

A set of assumptions has been developed to support the communication traffic

analysis and as a basis for the overall SSDS architecture development. For

convenience, these are categorized as (I) TDRSS utilization assumptions, and

(2) traffic analysis assumptions. The assumptions are intended to, be

consistent with the set of references listed in Table 5-i. In addition,

internal team member work (e.9., Shuttle television system), and informal rJ,q!3A

sources were used as background material.

5.1.1 TDRSS Utilization/Capability Assumptions

i. The SSDS design should be compatible with allocation of either i, 2, or 3

SA channels. Figure 5-I uses two examples to clarify this assumption.

2. All Space Station data on TDRSS channels is digital.

3 . The peak uncoded channel capacities for the TDRSS KSA service are 25 M:,ps

(forward) and 300 Mbps (return); the peak SSA channel capacities (with

coding) are 300 Kbps (forward) and 3 Mbps (return).

4, Convolutional coding will probably not be used on the KSA return link.

"-6

lhe Space Station requirement for a 10 maximum Bit Error Rate and

application-specific requirements For a lower 8ER's ('an be met with lo,..,_._r

overhead codes, such as a Reed-Solomon block code.

One candidate partitioning of the communications traffic is shown in Table

5-2. Space-to-ground and ground-to-space communications traff_ic for the

Space Station manned core is allocated to the SA ser_#ices. This ('.andid.,.Le

allocation puts core traffic on the SSA links and payload traffic on the

KSA links, with uoice and uideo b(_ing on both links, l"he capacity for _:e

SSA links _'o handle the core video traffic is doubtful; the KSA links will

have to be used. Other candidate partitions of the communications tra(['i(:

can be identif:[ed, but this one (above) appears to be an attra(:tiue

al] ocat i,_n.

5-2
The SpaceStation (mannedcore) and the COPwill be designed so that the

COP can either access TDRSS directly or can use the Space Station el,; ,-_

relay. Although the use of Space Station as a relay and buffer has

advantages for IDRSS utilization efficiency and for COP system design, the

COP needs to have an independent IDRSS capability to allow it to operate

beyond the Space Station line..-of-sight. This will affect the complexity,

cost and power required for the onboard COP communications system.

Table 5-1 References

I. Space Station Definition and Preliminary Design Request for Proposal,

NASA, Sept. 15, 1984.

2. Space Station Reference Configuration Description, NASA JSC, Aug. 1984.

3. GSFC Document, "Customer Requirements for Standard Services from the SS.I.S".

4. Space Station Mission Data Base (Langley).

5. TDRSS User's Guide.

6. Woods Hole Data Base (Extracted Information by MDAC).

7. Data/Communications Panel Report to the Woods Hole Mission Requiremer,ts

Workshop.

8. Conceptual Design and Evaluation of Selected Space Station Concepts, JSC

December 1u83.

g. RFP and Corollary documents for the OMV.

I0. Proceedings of 1984 Williamsburg Conference on Space Station TechnolL,,]y.

11. [)eep Space Telecommurlications Systems Engineering, M83-.22226, 7. H. Yuen,

Jet Propulsion I_aboratL, r'y.

5-3
1

SA Channel

i 2

SA Channel

3

SA Channel

SS N Min/Day 1440-Tzo e 1440-Tzo e

Example COP (Via SS) (Via SS) 1440-Tzo e No. 1

P O P 1440-N 1440-Tzo e 1440-Tzo e

SS N Min/Day 1440-Tzo e 1440-Tzo e

Example

No. 2 COP 1440-N-M 1440-P 1440-Tzo e

POP M Min/Day P Min/Day 1440-Tzo e

Figure 5-1. Example TDRSS Allocations

lab le 5-2

Allocations to TDRSS Channels

PAYLOAD CMDS & UPI_INK DAFA

PAYLOAD MISSION DA'FA

PAYLOAD HEALTH & SAFETY DATA

KSA-F KSA-R SSA-F SSA-R

X

X X

CORE (_DS & UPLINK DATA

CORE ENGINEERING DAFA

X (backup) X (prime)

X X

VOICE X X X X

VZDI_:;O-HI(;H RAIE X X

VEDEO--LOW RAIL X X X X

5-4
5.].2 Traffic Analysis f_ssumpt.],,ns

1. lhe Langley mission data base, as modified and extended by the Woods Hole

Workshop and by SSDS team analysis, represents the mission requirements.

.

lhe crew size growth profile is as shown in Table 5-4. This assumes a

step increase from 6 to 12 during year 3 based on IVA man-hour growth ,.,nd

a final step to a crew size of 18 in year 7.

3. EVR man-hours per week are an average based on the EVA man-hours per y_ar

specified in reference i.

4. The S'I"Sdocking traffic is one Orbiter per 90 days for every 6 crewmen.

OMV and OTV events are per reference I. Each event provides communicaI, i.on

traffic for B hours.

6 The number of free-flyers grows from O to 8 as shown in Table 5-4.

MRMS operating hours per week is equal to 1/3 of the EVA hours plus I h_Jur

per OMV or OTV event.

Surveillance video time is 4 hours/day per IOC crewman plus 2 hours/day

for each addJ.tional crewm(_n.

The IOC core command and engineering telemetry rates are 4 Kbps and 256

Kbps, respectively, and increase as the crew size increases as slnown i.n

Table 5-4.

IO. Training time is 1/2 hour/day per crew member.

ii. Recreationleisure time is I/2 hour/day on working days, 2 hours/day on

non-working days, for each crew member.

12. Video communications are assumed to be in three categories: (I) I',,II

resolution, full-motion commercial lV quality, (2) fre(-_ze-frame video, and

5-5
(3) an in-between quality with full resolution and slow frame rate. TI'::._e

video signals are assumedto be encodedand compressedinto 22 Mbps, 400

Kbps, and 4.5 Mbpsdata streams, respectively. An extension of _his

assumption is that the 400 Kbps video is adequate to support the OMV

teleoper'ation activity. This assumption is based on our interpret,_tiorl of

OMV documents. A brief discussion of these rates and the corresponding

rationale is provided in paragraph 5 %.i.

5.2 Methodoloqy

5.2.1 Scenario Development

lhe Space Station Traffic scenarios were derived from various operational

functional modes as now understood, and included the following: EVA, orbiter

docking and undocking, OMV operations, OTV operations, Free Flyer operations,

co-orbiter operations, MRMS operations, internal and external surveillance

video, core systems, training, recreation and leisure, and attached or

internal exper'iments.

These scenarios were then individually examined to develop a time and use

baseline which required interpretation of various documents, assumptions wh(,re

necessary, and then linking that to the specific data rates for each class of

traffic. For example, in the surveillance scenario, our baseline assumed ;I.,,_t

there would be fifteen internal cameras used to monitor most aspects of the

interior spaces of the station and crew actions and docking ports, as well ,_s

two cameras used to monitor the external structure. Our thinking has been

changed as a result of some discussions at the Prox Ops workshop in February

1985, since it was indicated that up to 18 external surveillance cameras will

probably be required. (The effect of that information on the overall

communications profile has not been incorporated at this point.)

For purposes of further explaining, the following is a sample discussion using

a surveillance scenario. Several assumptions were made: a 10% duty cycle ..,.,:_s

assumed in terms of vide() use related to communications downlink use; thus,

for 15 internal surveillance cameras, the equivalent of 1.5 full time video

channels was assigned for this group, and the same rationale was used for the

exterr_al cameras, iZt was also assumed that there would be increased us_ of

5-6
the internal cameras based on an increase in the crew size, since there would

be more crew activi, ty.

lhe crew growth was based on the following: a) the RFP indicates an IOC crew

size of six and a crew size not to exceed eighteen, b) in order to del:ermine

the steps in crew increase and the point of increase, information in the RFP

on increases in crew activity was used. An indirect indicator was deri:Jed

from the step functions in crew medical data (from Langley documents). The

changes "Lmplied a crew change (six to twelve) in the third year, while

achieving maximum crew size during the seventh year (see Table 5-4, Crew

Distribution). Finally, the use scenario was related to communicati,.,ns

bandwidth/data rates by assuming that a slow scan TV algorithm could be used

for "normal" surveillance. The use of 4.5 Mbps rate represented a rea_son_d:_l.e

quality, (NTSC) full color picture, which uses a 'slow scan" frame rate of

five frames/sL,, ,:,nd.

5.2.2 Communication Profile Development

Space Station

The time related communications profile, as presented, is based on:

a) a broad scenario for each functional mode related to the C&T system;

b) attempting to quantify the scenario from explicit or implicit sources;

c) developing assumptions on gray areas, which relate to operational use

considerations or reasonableness and reviewing some of th(,se

assumptions in areas of major" criticality (e.g., the major

Communication bandwidth drivers) with customer and study !.<_,11

personnel;

d) _isigning rates to each source or sink which eventually contributes

to the KSA/TDRSS down link based on the Woods Hole projections fur

the experiments, recommended rates for digital video where these are

explicit in NASA related documents or based on filtering uF

5-7
di.scussions with NASApersonnel, and assumptions on quality and

adequacyof pict,,,"es;

e) some attempts at scheduling transmission to the ground where any

specific operational scenario reasonably a11ows that, in order" to

smooth out peak short term (seconds or minutes) demands on the

communications resources; a generic unit period was used as the ly.,._i.s

for the link utilization.

f) placing the resultant profile into two time frames (IOC and "growth")

and comparing each against the KSQ bandwidth constrainks.

COP

The assumption used for the traffic analysis was that the COP would generally

be in view of the Space Station, and that both uplinked (program loading _,,id

commands) and downlinked (experimental data, video, and health/status

telemetry) information would go through the Space Statl.on.

POP

The information on this is derived from the Woods Hole Workshop data base and

attendant experiments/sensors and it is assumed that Polar Orbiters wL,,,Id

access TDRSS (KSA Channel) directly.

5.3 Detailed Strawman Scenario Development

Detailed Strawman communications system connectivity and link ].oading

scenarios were developed-for several Space Station related activities to

provide a basis for a composite traffic profile analysi.s.

5-8
lhose scenarios are as follows:

I) _.:vA

2) Orbiter Docking/Undocking

3) 01"V/OMV

4) Free Flyer

5) MRMS

6) Surveillance (Internal & External)

l) TeIemetry Command & Control (Core Syst_ms)

8) Training

9) Recreation

i0) Internal/Attached Pay loads

II) Co-Orbiting Platform (COP)

12) Polar-<)rbiting Platform (POP)

5.3.1 Standardization of Co,,,,unications for use in Srenarios

Qssuming digitization of all communications with elements external to the

Space Station, several standardized methods of representing communication._ in

the Scenarios were used.

The audio and video data rates used as standard throughout the scenarios are

presented in Table 5.-3. These rates were from NASA sources such as documer,ts,

contracted studies, and discussions with NASA personnel. Other possible

options For audio and video (not used) include: l) 64 kbps voice channel_., fur

high quality speech recognition; 2) 25 Mbps, or higher, video data rates for

high resolution compressed video or uncompressed video; 3) 1.544 Mt,l:)S

compressed video with Tl communication link compatibility; or 56 kbps for"

teleconference-quality' video. Other data rates used in the scenarios, such ,_s

command and telemetry, were selected or derived from the Space Stat:i.on

references identified in Tabl(_ 5.-1.

5-g
\

Table 5-3.

Audio and Video Data Rates used in Traffic Profile

REFERENCE (]able 5-.1)

AU[)IO

-ST S ORBITER 32 KBPS (I)

-ALL OTHER AUt)£O 16 KBPS (1), (10)

VIDEO

-COMPRESSED SLOW SCAN TV

-FREEZE FRAME TV

-N'TSC, COMPRESSED

-NTSC, COMPRESSED

400 KBPS (9)

400 KBPS (2)

22 MBPS (10), (5)

4.5 MBPS (1)

The digital video rates which have been selected should not be considered as

Final rates to be used for the space station for either external or interr_al

communications. These rates are only goals that are being considered for

digital video. However, it is useful to consider how the 22 mbp_ .....,s

selected, as an example of how the rates were selected.

One reference was an article by Tu, Teasdale, Zimmerman, "A Communicatl.on

system conceptual design for a low earth orbiting manned space station" (NTC

1982) which assumed 22 Mbps for quality video. The Reference Configur_li,:,n

uses the value 25 Mbps for compressed NTSC quality video. At this point in

time during a conceptual analysis the difference between 22 and 25 Mbps ir_ ,,:t

particularly significant.

RCA, under contract to,NASA has been studying 27/28 Mbps digital video for use

on the space shuttle orbiter, using a compression algoriLhm.

Before a truly definable digital video rate can be finalized, the compression

algorithm must be selected. The selection of an algorithm will be dt._pend_._nt

on several factors which include but are not limited to:

_)

2)

quality of im,:_ge

speed of algorithm

5-10
3)

4)

5)

O)

volume, power, weight requirements of compression processor and that

of the transmission equil;..,,_nt

cost

definition/resolution of image, and

operational/mi ssion needs

At the current time, it appears to be technically reasonable and consistent

with other NASA sponsored activity to use 22 Mbps as the rate For" compr_s:_d,

NFSC quality video,

]in order to graphically portray traffic profiles and to classify data for

analysis, three symbolic signal distributions were used to represent various

types of data in the analysis. As portrayed in Figure 5-2 data generated

during a unit time period (arbitrary length of time) can be represent_,.I by

different distributions. A uniform representation over a unit period of time

represents a continuous and constant data rate for the duration of the event

or activity under consideration. For example, OMV telemetry rat(_ i.s

anticipated from an OMV while under control of the Space Station. A

triangular representation is used for data generation for which the data _',_te

will vary over a period of time, T. A pulse representation is used for

constant rate data generation which occurs only for a fraction of the _ime

period in question.

• Signal Distributions Are For a Generic Unit Time Period

/ •

e4'# o _ =m _

I

I

I

I I

0 .5 .1

Time

b) Uniform

R

I

0 1.

Peak Rate = R

Average Rate= R

Figure 5-2. Signal Distributions

c) Triangular

0 1.

PeakRate = R

Average Rate = R/2

R

d) Pulse

h I

0 T 1 1.0

Peak Rate = R

Average Rate T 1R

5-11
5.3.2 Detailed Strawman Scenarios

Figures 5-3 through 5-14 portray the 12 strawman communications scenarios.

Each was designed to support the Space Station mission requirements ar=,'Jbe

consistent with requirements outlined in the Space Station Reference

Configuration and Space Station SON, (Ref. 1 and 2). The distribution of _!.,I:_

through the linked systems is indicated with arrows and symbolic plots of

signal distributi,,ns.

5.3.3 §pace Station Activity Intensity

Table 5-4 lists the changes in activity intensity over a period of years F..om

IOC to ten years into the Space Station Program. Assumptions and References

For these values are described in paragraph 5.1.2. Because the l_,lHst

information available on payloads does not provide a year to year listing of

payloads, payload quantities are given only for IOC and a growth year. The

growth year is assumed to correspond to a year shortly after year 6 or year 7

when IB crewmembers may habitat the SS. It is not evident From sour',:es

whether year 6/7 through year lO have significantly different total activity

(i.e., some activities appear to increase, other appear to be reduc(_d).

5.3.3.1 US Payloads (Missions). US attached payload communications

statistics are presented in Table 5-5. The highest possible data rate (r,,,_k

Data Rate) for attached payloads is 433 Mbps during IOC. The Peak Data Rate

was determined by adding up the data output rate of all Payloads, which i_:,'_s

all experiments would operate simultaneous'ly to provide the 433 Mbps, a

demanding upper bound. As such, the Peak Data Rate establishes a max'.,im

bound For data loading of the communications distribution system. With an

average data rate of 26 Mbps For the 33 IOC payloads, scheduling ,,.'_d

int:erleaving of data From the various payload experiments should allow For a

more realisti= loading on the communication distribution system FluctuaTing

around an average rate near the 26 Mbps Figure.

It was assumed that 4.5 Mbps TV (5 fr'ame/sec compressed NI"SC Format) ,,,_Id

support the payloads. In fact many payloads may require lower rate IV while

other may require higher rate FV.

5-12
EVA

6.064 _._

0 1

0 400 I .0.400

_0. II ,

t _ i_ _ .

/ Video, I I Compressed

_;:,'e'm°etry IICommandl _ H==,

I Audio, I 0 1

[ i Video I Duplex.

I External IAud.____.io. I

I Communications I

System

AN SourceJ 0comlan©

TDRSS

,_22 Total Record* T(rlemet------_ I II, 0.400

0.112 _',,_,j 0.048 _,/,,,_j

0 1 0 1

Figure 5-3. EVA Scenario

Signals

400 KBPS TV

Video / 22 MBPS TV

Distribution _ 16 KBPS Voice Network --. 32 KBPS Cmd

48 KBPS TLM

_.016 Audio

0 1

Ao°,o t] Distribution

Network

com--n°TI Telemetry _ I IIc°°°'n° I

I I Telemetry °- _'I

Management | .

System _.---J

* -- Archlvlng Information

Alternate TDRSS or

Direct Links Possible

=,

STS 10_ Audio, 0

Order --

I Audio. ' Video

I/Telemetry

0 1 Duple 1

I External Audio

Communications

System

TDRSS I

i r]:;tal Record

0.,48Hy- _

0 1

I _._.016

0

Comma__nd

|Telemet_/

0.002

0 1

Figure 5-4. Orbiter Docking/Undocking Scenario

Signals

22 MBPS TV

32 KBPS Voice

Video 116 KBPS Cmd Distribution

Network _ 2K.IBPS TLM

AuOot7 Distribution

Network

I

I

Oa,a iJ Management

System _..

* -- 2 Voice Channels to Orbiter

5-13
Signals

400 KBPS TV

48 KBPS Cmd

64 KBPS TLM

, _ j_-i 0.048

OMV _,

Telemetry l Command

Communications

System

TDRSS

m

Video T

(See Note)/

Video 1

Distribution

Network

m

Audio

Distribution

Network

_ A_0.048

T Command

I Io.,. i

-_ Management .

System

Note: Freeze Frame Video May Not Be Adequate

for Interactive Robotic Interface

Figure 5-5. OMV Scenario

Free

Flyer

Illn

I

0 0.3 0.4 1.0

• CMD

|

TLM, Video

-- 5.0

fl --0.064

4"51 N Signals 48K CMD

64__ TLM

I 5M Data/TV

0 0.1 0.2 1.0 Video (25M Data at Growth)

Distribution

Video Network

External

Communications

System

Audio

Distribution

Network

TDRSS

Figure 5-6. Free Flyer Scenario

-- 0.048 Housekeeping

g I--I - 0"02 Data

O.3 0.4

CMD Data

Management

I

TLM. Data System

5.0_] Data

__ 0.064"rLi

0 0.1 0.5 1.0

5-14
MRMS

.002 9.0 I

0 0.5 1.0

j CMD 0

TLM, Video

9

0 0.5 1.0

I

External

Communications

System

I

1.0

Video

TDRSS

Total Record

I_ 9.018

"°i- , "b

0 0.5 1.0

-- 0.002

0Oc o0, I

0.016 _I I

0 0.5 1.0

Figure 5-7. MRMS Scenario

Video

Distribution

Network

Audio

Distribution

Network

Data

Management

System

Signals

I 4 25KMCTMMD( 2 Channels,

u6KTLM

Assume lO%/Hr/Camera 4"5 I H I

Transmitted to Ground I I

0 T T+0.1 1.0

9 1

Video

Distribution

Network

Internal to

Video Network

I

_. 0 S 1.0

low Scan TV

I External

' Communications

System

TDRSS

Total

Record

0.002 _2

0 T T+0.1 1.0

Figure 5-8. Surveillance Scenario

Audio

Distribution

Network

I i_ o.oo_

0 1.0

CMD

4 Data

4 Management

T LM System

0.001 I

0

I

1.0

IJ

CMD

TLM

5-15
Video

Distribution

Network

j Signals

Ver,D:_j:,n_¢g On V-'

External

Communications

System

Audio

Distribution

Network

TDRSS

rl ! r

0 1.0 0

CMD CMD

4 4

TLM TLM

1.0

Z= Data

Management

System

0 1.0 0 1.0

Figure 5-9. Telemetry Command Control Scenario (Manned) For Core Systems

I

p--

I

Video

Distribution

Network

Internal to

Networks

Video

External

Communications

System

TDRSS

Figure 5-10. A Training Scenario

Audio

Distribution

Network

Data

Management

System

Audio

0,16_

5-16
Signals

4.5MTVConf 22MTVCassette 16KVoice

External

Communications System

TDRSS

0 0.5 1.0

Figure5-11.Recreation/Leisure Scenario"

0 0s,oJ

Duplex Video I

0.016_"

o.5 1.o"

.=

r Duplex L

Audio _ I

Video

Distribution

Network

Audio

Distribution

Network

Data

Management

System

Internal to

Networks

Video

22_

0 0.5 1.0

Audio

0,016_

0 0.5 1.0

Signals

Vary Depending on

Payload Requirements

0T1T21.0

Video

Distribution

J Video Network

I0 1

]

Communications i _1/_tlo°r_ tlOn |

, System I _'I

" -I-' _ il

I _°mman" Tl,

R2 Command Telemetry _ i

Io_,/ oa,--;--_l-J

TDRSS • • • _ Management l

Total R I Data System I-,- .-J

0 1

Figure 5-12. Internal/Attached Experiment Scenario

Command

I

Telemetry

5-17
Coorbiting _i

Platform

J Command

I

I

I

TDRSS

Video

Data Video

Telemetry

__ External

Communications

System

Total

._Record

Signals

Vary Depending on

COP Requirements

Video

Distribution

Network

Audio

Distribution

Network

I

I

I

I

I

I

tl I

--11

I

I

__. D-0.048Housekeeping ::

ata Commands I '

I Commands , I

Telemetryl t ] __ J:

Data J I I Data 1---

Teleme---"_-l_ Management / I

,O.O_._zrY I System _.----- J

Figure 5-13. Coorbiting Platform Scenario

h

0

CMD

Polar-Orbiting

Platform

I Signals

Vary Depending On

Requirements

1.0

_ Data, TLM

0 1.0

TDRSS I

I

I

I

To WSGT

Figure 5-14. Polar-Orbiting Platform Scenario

5-18
O

L

c

u

r3

o

L

4_

°_

u

tO

4_

4_

u

o.

o

L

E

E

°

I

u_

O

u'9

N

O

I-I v

u_

n

r_

ee_

0

o3

)- ),- _ ),,,

I-,I I,-I _ _ I,-,,I

I,- I-- I-- I-' I--

I-

-,r

_1 H

I,_ v

I- 0

0 tO _1: I--

I.-4

.

o ,,,

LU n,.

I,Ai

Z CO ="

_l: >" O3 0

>- _1 n_. t,_ I-..I

" ._ t-- .-_ =:" I--

IJ. _ W -0 I-I

I.AJ CO _ LU I-- l--g ,"-"

5-19

O3

,,-.,

0 CO O3 O3

:=" O3 _E _: (Z:

" 0 0 0

_.. _ _1 ..j ..I

0 >- >- >"

•-r o3

r,O _ ,-o _ _._

• 0 0 0 0

_l: r.o ,', ,', c_.
Tab].e 5-5. Attached Payload Statistics

ATTACHED PAYLOADS SUMMARY

Payload Quantity

Peak Data Rate

Avg. Data Rate

IOC

33

433 Mbps

26 Mbps

GROWTH

16

402 Mbps

51 Mbps

P/L Video

Avg. Rate (4,5 Mbps ['V)

61.8 Hrs/Day

11.6 Mbps

80.2 Hrs/Day

15.O Mbps

ATFACHED PAYLOAD COMMUNICATIONS DRIVERS

IOC GROWTH DESTINATION TRIGGER DELAY PEAK AVERAGE

(Mbps) (Mbps)

X

X

X

X

X

COMM 1014 Remote Sensing Land

SAAX OOll Adv. Solar Obs. Sun

SAAX 0207 Solar Terrestrial Sun

SAAX 0227 Plasma Exp. Poisson

TDMX 2542 Tether Const. Poisson

24 Hrs, 300 2.5

O Hrs. 50 31.25

0 Hrs. IO 2.5

O Hrs, 50 16.7

N/A 120 20.0

ATTACHED PAYLOAD VIDEO DRIVERS

X

X

X X

X X

SAAX' 0009 Pinhole Occult Sun

SAAX 0011 Adv. Solar Obs. Sun

SAAX 401 Micro Gravity Lab. Cont.

SAAX 404 Materials Lab Cont.

24 Hrs.

O Hrs.

3 Hrs.

3 Hrs.

N/A = Not Avai],able

Reference 6 and 7 (Table 5-1)

5-20
Payload communications and video drivers were determined to support the

development of a composite payload data profile. Only five payloads were

found to have a peak output rate greater than 1.5 Mbps and/or an average rate

greater than l.OMbps. Four payloads were found to generate video more II,,n

two hours per day.

lhe l'rigger and Delay characteristics of payloads determine when the payload

is assumed to generate data and what delay for delivery of data (L:= lhe

customer) is acceptable. Triggers are of four types. Some payloads are

triggered for land or sun observation only. If the payload should op_.,:"._te

continuously while in view of the land or sun, it would operate 33% of the

time for land or approximately 62% of the time for the sun. Other pay _....,ds

have a continuous trigger, i.e., operate continuously. A fourth trigger

assumes that the probability of a payload operating at any given tim ....is

dependent upon a poisson probability distribution, but than an average data

rate can be determined over a long period of lime.

Figure 5-15 presents attached payload profiles. These profiles portray the

most likely distribution of payload data rates over the period of an o,.l:)[t,

that will minimize channel bandwidth at all times. The growth profile will be

used as an example to show how a profile is determined. Payload COMM iOl _ ,_,n

accept a 24 hour data delivery delay, so to minimize communications bandwidth

the average 2.5 Mbps rate is used over the full period of time. The vide. .... ,n

be shown at an average rate of 15.0 Mbps because all but one of the video

m_ 150

tr 100

{U

5O

10M

20M

1M

Remaining a_ 150

Composite :_

2.5M / _ 100

Comm 1014 /

SAAX0207 / / _ 50

TOMX2542 It

,,---,.--_11.0M Video 0

1.0

Time

lOC

Figure 5-15. Attached Payloads

SAA X0227

_ 2.5M

SAAX001 I I # / 0.SM

Remaining

15.0M Video I Composite

1.0

Time

Growth

5-21
drivers will accept a three hour delay or more, thus allowing tlnr,.)ttl._,,.j ,._F

video data at the average rate. Because payloads SAAX 0011 and SAAX 0227

re(.luire minimal delay, their data must be transmitted at the generat:ion _...._te

of 50 Mbps for the fraction of time these payloads operate. The partial

overlapping of transmission of data for these payloads is due tu Lhe

irldependent triggers (sun or poisson) for the payload. Thus, the figure

primarily reflects the major effects of SAAX 0011, 0227 and COHFI 1014 (?, :.,m

the Woods Hole work), the timeliness requirements and the triggers. Other

experiments contribute little to the load_,ig.

Uplink communications to the space station for attached payloads are

characterized in Table" 5-6.

As indicated in Table 5-7 the communications for the Co-orbiting Platform are

uniform throughout the space station life time. The Woods Hole data base _,_'_ly

presents one payload. It should be noted that the previous Langley MRWG data

base listed several payloads for th (_()P.

TABLE 5-6.

Attached Payload TDRSS Uplink Command and Audio Communications

Simultaneous

Average Data Rate

Voice

Avg. Voice Channels

Avg. Voice Rate

Combined Ave. (Voice & Data)

IOC GROWTH

51.1 kbps 78.2 kbps

ll.g kbps 12.4 kbps

60 Hrs/Day 80 Hrs/Day

2.5 3.3

40 kbps 53 kbps

I01 kbps 131 kbps

Reference 6 and 7 (Table 5-1)

5-22
Table 5-7

Co-Orbiting Platform Payload Statistics

CO-ORBITING PLATFORM PAYLOADS SUMMARY

P/L QUAN'II I'Y

DOWNLINK

IOC GROWTH

1 1

PEAK DATA RA'FE

AVG. DATA RAI'E

P/L VIDEO

1 Mbps i Mbps

I Mbps I Mbps

0 Hrs. 0 Hrs.

UPLINK

PEAK DATA RATE

AVG, DATA RATE

10 Kbps

•67 Kbps

COP PAYLOAD COMMUNICATIONS DRIVERS

IOC GROWTH DESTINATION TRIGGER DELAY PFAK AVG.

(Mbps) (Mbps)

X X SAA_ 004 SIRFF Cont. 24 Hrs. 1.0 1.0

fable 5-8 lists the statistics on the 3 Polar-orbiting Platforms. Because the

communications drivers for each platform can tolerate a full orbit delay (1.5

hours) or more in delivery of data, the average data rate is adequate for the

dal:a transmission profile. Figure 5-16 shows the projected total m:issi(,::,:.!.._l;a

inading of TDRSS return links for the SS, COP, and POP's (IOC and growth).

5-23
Table 5-8

Statistics for Payloads on Polar-Orbiting Platforms

PAYLOADS ON POLAR-ORBITING PLATFORMS (POP) SUMMARY

P/L QUANI:LrY

PEAK DATA RATE

AVG. DATA RAFE

POP-I POP-2 POP-3

IOC GRO_FT'H IOC GROWTH IOC

I0 ii II II -

393 Mbps 669 Mbps 302 Mbps 302 Mbps -

80 Mbps 154 Mbps 18 Mbps 18 Mbps -

GROWTH

4

76 Mbps

41Mbps

POP COMMUNICATIONS DRIVERS

IOC GROWTH

POP-1

TRIGGER DELAY PEAK

(Mbps)

AVG.

(Mbps)

X X

X

X X

X X

COMM 1019 STEREO IS LAND

COMM 1020 STEREO IS/SAR LAND

SAAX 209 HIRIS LAND

SAAX 022B THERMAL IR LAND

24 Hrs 200 54

24 Hrs 276 75

3 Hrs 160 22

3 Hrs 30 3

POP-2

X SAAX 0212 SAR LAND 6 Hrs 300 16

POP-3

X COMM 1023 STEREO SEA SAR WATER i. 5 Hr's 76 41

REFERENCE 6 and 7 (Table 5-1)

5-24
3 SA

Channels

I

c

_ 2SA

Channels

<

1 SA

Channels

COP'

---I !

, Rates Worst- Case

I POP'2 I Single

I POP-1 I Payload Peak

c°Pi ss i Rates

1128 Mbps

POP-1

SS

.=_.........._ Worst -Case Multiple

Payload Peak Rates

POP 3 COPI

POP-1 I Worst-Case !

I Single I

COP _ I Payload I

SS ! PeakRates I

1450 Mbps

POP-3 J

"!

' IOC = = Growth =

Figure 5-16. TDRSS SA Channel Traffic Versus Capacity

5.3.3.2 Foreign Payloads __Mission_ s)_

Tentative foreign payload communications drivers are presented in Table 5-9.

'They are considered tentative because; 1) they have not been included ir, lhe

Noods flole data base information in our possession as of this writing; 2) many

details on the payloads are missing including an SSPE allocation, and 3)

several caveats were provided in the document (i.e., Ref. 7) from which the

data was taken. One caveat was that many foreign payloads duplicate, US

payloads and may not need to be listed separately in later listings of

payloads. It is not apparent whether this moans there are multiple si..,iI,_r

experiments (US and foreign) or time phased use of the same exper:i.mental

equ J., ....,1"_t.

AS carl be seen in Table 5-9 several foreign payloads on polar platforms could

generate data at rates as high as 300 Mbps. The communications loading ?,_.:,m

these payloads will demand more of the TDRSS in terms of management,

scheduling, ,=I,:-.

line "Other Payloads" in Table 5--9 have sufficiently low data rates and/or

sufficient communications delay, that addition of these to the US pay!,,,_,d

scenarios would have rain:finalimpa(;t.

5-25
Table 5-9

Foreign Payload Communications Drivers

GROUP

CANADA

JAPAN

EUROPE

POLAR-ORBITING PAYLOADS

DUPLICA f'E DEt.AY PEAK

(Mbps)

Y COMM 4002 EARTH RESOURCE SENS. 24 Hrs. 300

Y TDMX 4000 RADARS 24 Hrs. 300

Y EO06 EARTH OBSERVATION FACILITY 0 Hrs. 300

N EOB210 OPTICAL INFRARED 24 Hrs. 300

Y EOB220 LAND SAR MULTIPURPOSE 24 Hrs. 300

Y EOB230 LAND APPL. SAR AGR. - 300

Y EOB300 OCEAN SAR 6 Hrs. 300

AVG.

(Mbps)

IO0

100

10

24

75

38

38

OTHER PAYLOADS (PLATFORM UNIDENTIFIED)

CANADA - SAAX4006 24 Hrs. I0 1.5

JA PAN

EUROPE

TO04 SPACE ENERGY EXP. 24 Hrs. 5 2.B

SO01 24 Hrs. 8 B.O

EOBXXX LIDAR

SCN060 ARTIC COMM.

- 150 I.B

0 Hrs. 1.6 1.6

Table 5-10 lists the current estimate of video required for Foreign paylc,,.,,]s

(Avg. 10.4 Mbps). It is not known whether all the payloads generating this

video will be operational during the same years or whether they will be ,:, _1ie

same platform. Again the foreign payload data is only a first cut at defining

the payload requirem,,,,ls.

5-26
Table 5-10

Foreign Payload Video

(Reference 4; Table 5-1)

VIDEO

EUROPE

CANADA

JAPAN

9.8 Hrs/Day

.5 Hrs/Day

45.5 Hrs/Day

TOTAL 5B.8 Hrs/Day

Avg. Video @ 4.5 Mbps 10.4 Mbps

In summary, the primary impact of foreign payloads on communications will

potentially result from POP payloads and perhaps payload video. However,

because of the uncertainty regarding foreign payload definition they will not

be included in the composite analysis, which follows.

5.4 Composite Communications Systems Loading

Composite communications loading and link loading is developed below by

examination of data derived thus ?at.

5.4.1 Internal Distribution System Loadin q for the Space Station

Table 5-11 and 5-12 indicate the communications data inputs and resulting

composite internal distribution systems loading for the IOC and growth space

station scenarios, respectively. Distribution of information in all digital

format on the Space Station has been assumed primarily to simplify analysis of

the digital downlink loading of the TDRSS. Digital distribution channels can

easily be taken out of the potentially several digital distribution networks

on the Space Station and be assigned as analog on analog distribution

5-27
_n

eoF=I

"I0

RIo

.J

a;

-t-

_n

co==I

CL

(JOH

4")

r6

C-O

os..l

c-

,-_E

-QEOO

4_u

o3LE3L

o3

coWUC

C=

C=

s-

(.)

bJ

_jv

H (,d OW v HO "_

=>>

£

od£O

IO

o3Z

b.O

Oz

_

s-

_o

££

s00

od

3¢v

S--

S- oq

oq CN

o_Iv

=;

00!

i°°

5-28

o%

.a¢

_," 04

sco ,_.

,=o

¢,t9 0

CO

O3

.J

U.,I 2

(Z:

-t-

(J

L_0

I--o ,5

I-- ="

cm

o. v

o3

•,w r-.,

u_ co

o'= o3

C'_

01,

o.o

'_" "o O o • •_=I

¢,_ nO

o,I --_

O

_'_ 4_E

4.) I. D O

-,-_ C" L -,._

-,-_

"o0u

0

.,._

u

u

o

Du

tJI

I
_n

"OoJ

r_

QI mo

°F'_u

-F.4EEO

-e_lU

"7c

°r,l

I--

u

e_mcL

QI

eI-I

e.- 3OL

¢- E3L

4_

W

OZ

3

I.iJ C

IE

...1

W_

v

I-.t e,4 _ v O _O

hO

09Z

u.O

Oo

uz

Z_

O

vvvv

u_

v

_D

e,4 _i _O e,q

e'4£

OO

°

5-29

,p..I £00

I-I £0 _n v00

tj)

_1

,-1-

cJ

t._

-_0

I-o ,5

i..-2

,_" (/3 0

o.o

.._

"o

°_,_

e,. o

"o

E

_uL

"_0

=Q q-

.,=I L

_3O

_J

4..) O

U

O r_

(I)

4-_ "O

(_ ,=)

)3 i.)

rjI

I

ro
nel:works. An objective of this analysis is to identify boundary condil.;,,ns

and probable loading levels of the communications systems. This can be done

for both the digital designs and analog designs by identifying data ral ,ncJ

channel quantities.

lhe objective of the data analysis in Table 5-11 and 5-12 was to determine a

probable, or an order of magnitude type determination of an instant in 11,ne

when a heavy instantaneous communications loading would be placed on the Space

Station colnmunications systems. This then provides an estimate of the up_:_._r

bound on communication capacity. The data rates used for each line of the

tables were taken from the detailed strawman scenario diagrams, Table 5-4, or

from the statistics presented on payloads.. The column labeled "No. of Func."

lists the number of functions that would occur simultaneously foF Lhe

composite scenarios developed in each table. In the case of EVA there are two

functions (two simultaneous EVA crewmen) which result in all the data rat(_ En

the EVA scenario (from Figure 2) being multiplied by 2 and listed in the

appropriate communications service column (TV, Voice, etc.). The acl,,al

distribution of functions was determined for both Table 5-11 and 5-12 by

attempting to involve crew members in as many communications-inten,:ive

activities as appears reasonable, and is based on crew work schedules

presented in References 1 and 6. Although the simultaneous involvemenL of

crewmen in the selected activities presented here represents a judgement at

this point, it is useful to bear in mind that the primary objective w_ Iu

establish a heavy loading scenario to determine an upper bound on

communications loa,:1_ng.

In Table 5-11 the attached payload video and data rates were selected from the

highest loading point in the payload data profile of Figure 5-15. The ('oml_.,,id

rate was taken from uplink communications in -Fable 5.-6. Voice interaction for

payloads during this scenario are not significant because none of the crew is

available to interact with the payloads. It is however recognized that

mission specialists may require audio and video interaction with princ pie

investigators whi].e setting up an experiment and at other times.

After summing the input information the required number of voice and ,_.,o

channe].s are listE-_d ;_long with the digital audio/video (123.028 Mbp.'_) and the

5-30
SSDSdata (34.951 Mbps). Again, these rates reflect a created model

reflecting a heavy loading scenario.

In the growth scenario (Table 5-12) the input data rates were selected in a

manner similar to that for the IOC scenario (Table 5-11). As in the IOC

scenario, no OMV or O]V activities have been included for the purpose of this

analysis because crew members have been assigned to functions with more

demanding communications requirements. For other scenarios not included here

crew interaction with the OMV and OTV would be included. The interaction with

free flyers is not well defined for the space station; the command and data

rates for these were arbitrarily assigned a composite average of I Kbps (And

3.5 Mbps, respectively, which are loosely derived from the Free Flyer scenario

in Figure 5-6. The composite upper bounds reflected in this growth scenario

resulted in a 175.476 Mpbs audio/video rate and a 108.2:54 Mbps SSDB rate.

In postulating more realistic communications scenarios, it is useful to

consider replacing some higher payload data rates with average rates and

reallocating crew activity. This is particularly true when one recogn_izes

that EVA and Orbiter Docking activities are not daily activities and the crew

would likely be involved in some of the attached payload functions or a sleep

period. This has been done in 1-able 5-13 and 5-14 for IOC and growth,

respectively, which attempts to postulate a more "typical" scenario. The data

rates for attached payloads have also been changed to the average data rates

for payloads.

The composite communications loading for both the heavy and "typical"

communications loading are summarized in Table 5.-15.

5-31
O9

C_

LU

_. C0 o sLU 5

=-3

LU

ne

t_

coy-4

"OO

-J

t)

O.L

c-OU

(Z/ -_

•-4 _"

t6E

FEO

COO• _..,q

J_

r6u

r_

r6

c-- LH

rr_E3

r_L

j.)

GO

F- C

..J

F--

WO

L_J

r,O "_'

1-- e,_

,mr O

_--O

o') Z

O2

_

i,

u_

eq e,4

e,4v

£

0OOO _" c,_

Z

F-q v

COO '_

c_ _J

O

..J

w >-

_: >- ._100

._l _:0 r_ ._l _'_ ._1

F- a_Z _-w >-

_.__ ILl CO• t_0H e_- _[:

00 _. _- _0 i-- l-- _" _:0

04v

O_

0

0v ut_

o,I

r_

_O>

_-O

0

wh

_0

oo

coELOCLO

4-; °,,I I 1

5-32
m

c-

°l-.I

"Oo

_1

ill

r5

o.

Ira

r-

.i,..4 EO

°l,-I

°_..q

•q- :_E I E

u')oU

@

(D

o.

0_

ill

ELE

..C:

:3OLE

1"8 E3L

LIJ

O _:

:"3WUC

ha: E

_1

I--

I,UU

v

H t_l O

L_I U

v

>E

S- O

I--OZ

OZ

_

E

•vNvN

vv

vvY

AE

2

.j

vwQ >-

UU_ a:Q

0 _- =__ =:_ o.. <=

_ _1: >- ..j00

>- ._1_0 r_ _-I_

_:_ _" _" :_ L_J _'___0

L_00 U.E O0 l-- i-- _"¢U

5-33

l:

ur)

u_

¢N

¢_1 0

0

v

I'_

0

s- E0

0

Go

_Jw

'-t- U0

<=

I-o c_

I--z

v

_.o

v "0 0 0 0 "_

Eo

"o n_

4._L0

._ q..

.,,._ e- L

4-_

U

4-) "_ o _ o _ • E U _ I I

'_ I'N
Table 5-15.

Summary of Space Station Internal Communications l_oading

lOC HEAVY LOADING SCENARIO "TYPICAL" LOADING SCENARIO

Table No. 9 II

Audio/Video 123,O Mbps 56.2 Mbps

SSDS 35.0 Mbps 27.4 Mbps

Total 158.O Mbps 83.6 Mbps

GROWTH

Table 10 12

Audio/Video 175.5 Mbps 108,6 Mpbs

SSDS 108,2 Mbps 56.2 Mbps

Total 283,7 Mpbs 164.8 Mbps

5.4,2 Space Station Oownlink Loadinq of TDRSS

The internal communication load includes communications which is for intra

space station purposes as well as communications from/to external sources.

Table 5-16 addresses the potential TDRSS downlink (KSA) communications loads

for IOC and growth depicting upper level loading and hypothetical "typical"

scenarios. Therefore the methodology used to arrive at external loading was

to subtract internal communications loading that did not require transmission

to the ground.

Table 5-16. Downlink Loading of TDRSS

HEAVY LOADING SCENARIO "TYPICAL" LOADING SCENARIO

IOC 119.8 Mbps 45.4 Mbps

(_ROWTH 207.3 Mbps 88.4 Mbps

5-34
Only 10% of the surveillance video will be transmitted to the ground (see

Figure 5-8). As can be seen in Figure 5-10, no training information is

transmitted to the ground, l-hese two assumptions are based on our development

of those two scenarios; this may require review as various NASA elements

comment on the model. Video for PAO (Public Affairs Office) has not been

specifically identified in the scenarios. It should be recognized that some

PAO video includes the video previously addressed and that other PAO video

would be added to the hypothesized scenarios during special occasions.

5.4.3 SS..Uplink Loading. of TDRSS

The continuous uplink loading of TDRSS is minimal as indicated in Table 5-17.

lhe only possible heavy loading of the channel would result from Space Station

to Ground conversation, video conferencing, transmission of training video or

uplink video instruction for settinq up payloads. The loading from these

would be intermittent and for the most part could be scheduled to be

appropriately interleaved with any unexpected heavy loading of the uplink

channel. Special uplink loading, such as program loading or emergency

information, have not been included since the scenarios pertaining to these

situation are not defined at this time.

Table 5-17. Space Station Uplink Loading of TDRSS

Attached Payloads (Table 5-6) Avg.

SS Command/Control (Table 5-4) Avg.

Crew Member Voice/Video

IOC GROWTH

I01Kbps 131Kbps

2 Kbps 4 Kbps

Variable Variable

5.4.4 Communication Link Loading for EVA

Two crewmen will be on EVA simultaneously while performing activities outside

the Space Station. The communications link to each crewman should support

loading up to 448 Kbps and 22,064 Kbps For the fo_aard and return links (see

Figure 5-3). Lower loading levels would occur depending upon the audio,

video, telemetry and command required for supporting EVA.

5-35
5.4.5 Orbiter Communications Link Loadinq

The Space Shuttle Orbiter (SSO) has a variety of communications capabilit;ies,

many of which may not be required for communication with the Space Station.

Further analysis of the communications requirements is needed.

Based on References I and 2, communications loading between a SSO and the

Space Station should require a communications capability similar to I;hat

presented in Figure 5-4. That scenario requires two voice channels (32 Kbps

each) and some telemetry/command (2 Kbps) on the communication channel to the

Space Station. Video, audio, and command/telemetry to the SSO could require a

composite capacity of 22,080 Kbps.

It should be noted that Reference 2 indicates that 2 analog TV channels (4.5

MHz each) be used for transmission of MRMS video to the SSO. The MRMS

scenarios in Figure 5-7 assumed 4.5 Mbps TV for distribution on the Space

Station. This is not intended as a recommendation for a digital TV link to

the Orbiter; rather, it is a convenient assumption for purposes of this

traffic analysis.

5.4.6 Communications Link Loadinq for OTV/OMV

Both the OTV and OMV will provide similar support functions with the primary

difference being that the OTV will have more extensive transportation

capabilities. Our understanding of the OMV design currently under study by

NASA that it will support transmission of telemetry and/or video at a rate of

approximately 44B Kbps and reception of commands at a rate of approximately 64

Kbps (see Figure 5-5). The average rates could of course be less, depending

on the OMV activity level. The use of this video rate has been questioned on

several occasions because it may not be sufficient to support some OMV

activities, such as robotic repair, maintenance, and docking. A higher" 22-25

Mbps video rate may be required-perhaps even on two channels simultaneously.

Until the design of the OMV is better defined the communications loading will

be uncertain. The communications loading for the OTV, although assumed

similar to the OMV, is even less certain since this will be a growth addit:[on

to the Space Station.

5-36
5.4.7 Free Fl_er Communications Link Loadinc_

Free Flyers are essentially of two types:

,

2.

Satellites being launched and serviced

Special purpose vehicles that may operate in the vicinity of the

Space Station.

Until specific mission requirements can be defined for free flyers,

communications loading cannot be defined except For the link capacities (5 and

25 Mbps IOC and growth as'identified in Reference 2).

5.5 Recommendations for Further Stud3

5.5.1 The baseline and assumptions which are used in this report represent

a viewpoint which is based on the "best" information available to use at this

time. This includes rates and guidelines which in some cases were derived

from explicit NASA sources; in other cases, were arrived at via indirect

sources or engineering judgement. This should be reviewed as new information

and guidance are made available.

5.5.2 Areas where specific further investigation is suggested are discussed

in the Following paragraphs.

VIDEO. An example of the factors relating to the relative "softness" of the

assumed video rates and mission needs is described below, using the OMV for

reference purposes: the OMV requirements document does not identify a

specific quality of video, nor an attendant rate. However, discussions over

the past year with contractors on the Phase B - OMV study, have identified the

use of a relatively low (digital) rate For TV purposes, i.e., 448 KB/S.

Further, this appears to be a total video channel allocation. The OMV

requirements document asks for two TV cameras, and one or both cameras shall

use that channel separately or together. This rate implies a slow scan (e.g.,

5 frames/sec) approach, with either a compression or a "special spot"

algorithm, and probably black-white.

5-37
Discussion with video technology personnel at NASA have indicated that they

believe a much higher resolution video requirement exists - probably requiring

the equivalent of NTSC, Full color; this implies a video rate in the order of

22-25 MB/S, depending on an acceptable compression algorithm (see discussion

in 5.3.1).

These differences are dramatic enough to require a revisit of the

communications profile, since they impact the capacity, power, and Flexibility

of the SSDS, as analysis of video standards determines that rates may be

increased.

EXPERIMENTAL PAYLOADS. The information used for representing communications

profile for the US payloads was derived From the Woods Hole Mission workshop

outputs, which are reasonably complete and are in the available data base.

However, the information related to foreign payloads is much less complete and

also appears to overlap with some U.S. experiments. IOC-9rowth transition

schedule information in minimal. As these Foreign experiments are delineated

in greater detail, the SSDS system requirements may require modification.

END-TO-END DELIVERY DELAYS. The communications profile does not address

end-to-end delivery of data. However, as traffic builds, the delays due to

service queues, buffer delays, and routing increase. Therefore, it is

suggested that this area be investigated with particular emphasis on queue

delays; transmission delays should be essentially constant. If true time

transparency could be guaranteed (i.e., TD specified delay) regardless of

traffic conditions, this could be accomplished by faster processing and buffer

service and/or by assigning different delivery times to various classes of

data.

I'DRSS ACCESS. l"he total TDRSS channel allocation and the access protocol that

is used obviously drives buffer sizes and affects delays. Dynamic sch_dule

algorithms should be investigated in order to reduce the effect of

contention/conflicts as well as For mitigating predictable data throttling

p()riods. These would give some insight into worst case delays and assist in

developing buffer use and sizing options.

5-38
BI'T ERROR RATE/DATA INTEGRITY. ]he end-to-end objectives for" data integrity

(the acceptable BER) may not be the same for the three ('ategories (data,

video, voice) of information; they may even vary within any category. Error

detection and correction codes for individual links in an end-end connect:ion

affects power, processing requirements, effective link efficiency, etc. The

use of error protective codes within the data, within a frame, and/or within a

packet format are areas which requires further investigation.

It is probably worth reiterating that video and audio have sufficient

redundancy (i.e., assuming that compression algorithms are not too severe) in

terms of information patterns that the ability of human senses to integrate

across relatively short errors could reduce error coding requirements to those

necessary for frame, synch, headers, etc.

It is also useful to consider adaptive code strategies to accommodate

different conditions; e.g., in periods of high activity but good quality

links, a reduced code may be acceptable, while in periods of poor quality more

robust codes may be required. Also, within a constrained environment, as

within a LAN on the Space Station, or from a TDRSS ground terminal to a

terrestrial network interface (e.g., COMSAT terminal to a switched network

node) error detection (ACK/NACK) may be adequate rather than a more complex

FEC approach.

5-39
6.0 OBIBOARD SSDS DEF'TNIIION

Section 6.0, presents the definition of the onboard Space Station Data System

(SSDS) and the onboard P1atfor'm (POP and COP) Data System. The Space Station

System is described in sections 6.1 to 6.8; the Platform system is described

in section 6.9.

6.1 Space Station Onboard Introduction and Overview

For the purposes of this study, the onboard SSDS has been defined to include

the onboard networks, the network interface units (NIU's), subsystem data

processors (SDP's), workstations (MPACs), mass storage units and the software

that resides in or supports these elements. It should be noted that the

subsystem application software is included in this definition. The

architecture and system definition described herein are products of the SSDS

A/A Study approach and methodology outlined in Section 2.0. This architecture

definition is preliminary. Some elements are defined in more detail than

others to explore specific design or technology driver aspects of the

architecture. The prime inputs used to develop this preliminary definition

were:

o

lask 1 - Requirements Definition

Task 2 - Options Development

Task 3 - Trade Studies

Space Station Phase B RFP

Space Station Reference Configuration

Team Systems Engineering Practices

NASA Guidance and Feedback

Langley Mission Data Base and Woods Hole Data

[he major metrics utilized throughout this task to evaluate architectural

alternatives and influence key design decisions are also common to all

supporting analyses (options development, trade studies) and include the

following:

6-I
•- Cost

- Standardization/Commonality

•- Technology Insertion and Readiness

- Performance

- Growth and Flexibility

- User Acceptance

The primary steps of the onboard system definition process include:

Partition/allocate the Task i Functional Requirements to onboard

subsystems, physical modules and computing elements For traceability.

- Describe and characterize the onboard elements including rational.

Present an architecture and topology rationale that connects the

distributed elements.

- Document the System Definition and key design decisions made to date.

The supporting trade study results and options development were major inputs

into the system definition process. Recommendations and supporting data in

the following trade studies and related options categories were important

influencing factors in most key design decisions:

Network Media options

NIU options

Onboard LAN trade study and options

Operating System trade study and options

Data Base Man'agement trade study and options

Fault tolerance trade study and options

Time management options

The key design decisions made to date are summarized in Table 6. I-i.

6-2
,u

..J

r"

0

.t..l

-rE.

0

E

O_

Li._!

t

ziO!

._-.41

_t _,'_ • 3

-_ -,'_ _- 0

•,_ _ _ L

4_

_. O • O

-:.u i

§i °eol o

._.! ._

U

¢0

e._ i

A_

• •

C

0

(_ ._

L

._- CO

_-_

(.2,

0 0

..-_. c"

= 0

o."

:- d

.,_ :3

°_-i

L

o..

b5

_a

0

L

0.0

0 E

"_'0

-,-._

0 ._

0"0

0 _ _

v

U

0 L _

U 0

O_ 0 _.

.,_ .,._ _ .,-_

(J (J 0 _- U -i_

GO__[_ _ GO 09 0

4-_ E

.0. 0

.-_ _ r"

L <Z: "._

L O_

,'_-,'_-"_ E

_--_ _ _

E 0 x-,-; _n

_ Lu _C O_

_-_- • O •

<=; -.--_ :_ _ 0

:,--_ O. 0"_._ _ E

,-_ _'_ _ L i ,-_

•,-_ ,_ -,.._ _ i._ _.- _-

_[_ O O O • O •

L

r-<

so

r'-i L L

•_ _._ _ _

_.. ,-_

._ _._ ._ .,-

_ -_ .,_

o_

L

C

6-3
• Zl

O!

0

E

E

0

_J

CO

O

0

-,_ 0 :_

_._ _ ._

Q; L 0 _-,-_

0 _') _ L _-) _-) _i

.-- .,- X ._ _ _ 3

-_-_ _-_ _ 0

3 _ !. • ._ _-

(._v <E • 0 • •

I

ol

L

=h

_J

O.

4_

L

,,_ O..

O

¢: C; r_ L

0-,_-,'_ • ,_

-',_, ._- O .O--'_ _.

• @ • O

4_

v

0

0 _

_'-

0

.r,i

GO

O_ ¢,O GO

r_ "6

_. L L

.d -_ ..J

CO

.J

_r_ . -')

C3 "_

co CD c_ _.._

"O _ L

=_O . r- _

_3'_.-_ G'_ ,_ - _ :_

,-_ @ ,'_, O _ .._ --I

O _r" X 4-_ _

_ _ _ L_ 0 _ _ _ _ <= _"-_

cq0

L

Q;

-O

E

J_

e_ O

t..,.._.

x @

o.. _.

E

O

• _..4 "=

°

6-4
_n

.J

"0 r0

-,_

." cn

0 _.

U

C

0

_ -,w,l

zi

Zi oi

s- I

=i

Oi

-"_i

I

_..

L _.

0 _ ,_ _

• _ 0 ,_

C E C

0 "10 _ 0

•,._ _ _,/ ._ .,._

U"_ _ 0 U

C-,-_ .C L C

C L -" _J C ,_

0 ,_ 0 _.0 i

O. CJ ,IS _ _r

"0

C

"O

COO

"O

r_ C

L O

E -_

L._?,

O -,"4

O. i._

r- _p ,

_- 0

0 .:..-i _.

C L_ 0

0 ._-_

•,_ .C4_

._ r- U

C C

C - _j

d

"O

.._

4_

_0

"O

C

L O

:= O

e"

O

N -_

_" x

OO .':

_o

L

rr0

r"

0

L U

.--- @.,_

C ,'6-,-',

_ .,-- Q

•_ i ""_

_" _,1 x

-,-_ _

• 0 0

E -,-_

_-_

-,_

-_ C _ E

L _ L E-_ >_

0 _ _ _ "_ O

E _ _ "_

@ -'_ _ E _" q-. _,'

• ,._ _ E C _-_ _ -__

.0. 0 0 -,-_ ,_ _-

C._-_ L s- @ _ 0O C

_O

_O

C

O

E

O

OC

E _-- _-

_ 0 0 _

-* L L -C:

-O E E_-

• • 0 •

6-5
6.2 Partitioning/Allocation of Functional Requirements into Onboard Subsystems

Finis section describes the allocation of onboard SSOS functional requirements

to subsystems. Functions were previously allocated to onboard the Space

Station as a result of the Autonomy/Automation Trade Study. For clarity, the

subsystem allocation process is accomplished in two steps:

Functional requirements partitioned into the reference configuration

defined subsystems as a starting point. Some restructuring will be

described in subsequent sections.

Subsystem functional requirements allocated to resources (SDPs, NIUs

and workstations).

The design characteristics (sizing data) of allocated SSDS functions,

functional interface connectivity, discipline orientation, subsystem

(functional) autonomy and the advantage of recognizable subsystem names were

major factors in our core subsystem definition.

Table 6.2-1 presents an "application subsystem" overview of prototype memory

sizing in kilobytes (Kbytes) and mean processing rates in kilo-operations per

second (KOPS) using the reference configuration subsystem names. A detailed

breakout of each of the subsystems are tabulated in Section 6.8. The

exception is "Propulsion" which we assumed contained no software that is

resident in an SDP. The IOC and Growth subsystem summations represent only

the application code and data sizing and computational rates. The operating

system sizing and rates are added later when SDP memory configurations are

presented (total software load).

i

The application memory size for each subsystem is conservative from the

standpoint that it represents an arithmetic sum. Not all elements of each

subsystem are necessarily main memory resident in anSOP at all times. This

also naturally applies to their computational rates.

6-6
Table 6.2-1

TASK l FUNCTIONS MAP TO REFERENCE CONFIGURATION

SUMMARY DATA

SUBSYSTEM

I. ELEC PWR

4.2.1.I-7

MEAN DATA

MEMORY (KBYTES) PROCESSING (KOPS)

IOC GROWTH IOC GROWTH

443 863 76 148

2. GN&C

4.1, 2.5.3.3, 2.5.4.3

878 ll81 267 37g

3. THERMAL CONTROL

4.2.2.1-4

76 131 II 16

4. ECLS

4.2.4.1-7

117 11g 17 17

5. PROPULSION NO SOFTWARE -- CONTROLLED BY GN&C

6. STRUCTURES/MECHANISMS

4.2.3.1-5

108 252 52 106

7. CREW SYSTEMS

4.3.1, 4.3.3, 4.3.4

210 292 50 75

B. COMM & TRACKING

1 .l.l-5, 1.2.1-5,

4.2.5.1-7, 2.5.3.5,

2.5.4.6

851 160B 622 753

9. INFORMATION &

DATA MGMT SYSTEM

2.1, 2.2, 2.3, 3.3, 3.4

4.3.2, 4.3.5, 4.5,

4.1.6, 5.1.1, 5.1.2

257B 4126 45 I13

lO. PL & SERVICING

ACCOMMODATIONS

2.4, 2.5.1, 2.5.2,'

2.5.3.1, 2.5.3.2,

2.5.3.4, 2.5.4, 2.5.5,

4.4

2466 3122 26 49

A comparison of these sizing estimates to Shuttle software memory requiremerrts

illustrates the magnitude oF the problem. The Shuttle AP-IOI onboard computer

application software total code and data size is approximately 400,000 32-bit

words or 1600 Kbytes.The results of the comparison is shown below.

6-7
Current Shuttle

Space Station

IO___C Growth

1600 Kbytes • 8127 Kbytes • 12,404 Kbytes

(Application Code) • 5.1 times Shuttle • 7.8 times shuttle

For reference, the current Shuttle AP-I01 computer capability is 425 Kbytes

and 450 KOPS. The upgraded AP-IOIS is 1081Kbytes and approximately I000 KOPS.

The IOC KOPS values in Table 6.2-I are well within the capabilities of present

space qualified processors for any subsystem. The Growth requirements

indicate the need for newer technology (faster) processors in the Electrical

Power subsystem.

6.3 Subsystems Allocation into Architectural Elements

The following discussion traces the onboard function allocations into SDP's.

Later, workstation functionality is discussed that allows down loading from

SDP's, (Section 6.4.6 and 6.6)

Table 6.3-1 describes the onboard subsystem allocation into SOP memory

configurations. A memory configuration is defined as a collection of one or

more sets of subsystem application software. Most of the subsystem function

groups of Table 6.2-1 are retained intact with respect to the Reference

Configuration names. The most notable exception is that the Information and

Data Management has been partitioned into a DMS Operational Data Base (OO8)

grouping and Facility Management (see Table 6.3-2). The DMS grouping

represents a generic set of services that are available to all core subsystems

and are also available as options For the payload cummunity. Tables 6.3-2 and

6.B-1 (Section 6.B) together, provide the sizing data for these DMS services.

These will be discussed later. The remaining DMS items (Tables 6.2-1/6.8-1)

are considered as standard System Services.

The Facility Management grouping of Table 6.3-2, in conjunction with

8-B
Table 6.3-I

SSDS A/A Core and Payload Memory Configurations

No. Name/Function

IOC

Mem(1)/CPU(2)

(KBYTES/KOPS)

Growth

Mem(1)/CPU(2)

(KBYTES/KOPS)

1. GN&C 1038/307 1341/436

e NAV

• Guidance

• ATT Cont

• Traffic

• Tracking

• OMV & OTV Deploy/

Retrieve

2. • Elec Pwr 1530/815 2852/I055

• Thermal Control

• Communications

3. • ECLSS 595/137 g13/228

• Crew Systems

• Str & Mech

4. DMS ODB 1280/38 2071/62

5. Facility Mgmt 1618/14 2555/68

6. Payload Processing 360/I 650/I

(Function 2.5.1)

7. Payload Processing 360/1 650/I

(Function 2.5.1)

8. Payload and Servicing 2626/30 3372/57

Accommodations

(1)

(2)

Application size from Tables 6.2-I/6.8-1 +160 KBYTES for operating system

(+250 KBYTES for growth).

KOPS from Tables 6.2-1/6.8-1 + 15X of total application KOPS for

operating system overhead.

6-9
Table 6.8.--1, describe functions which are collected together as a required

central service for the Space Station. The functions are global in nature and

allow central status monitoring and command control for both the core and

payload systems.

The remaining subsystem sizes were significantly smaller than the Ill)MS. The

memory configurations of Table 6.3-i were derived by the following rules:

Retain well recognized function group names (discipline oriented)

Reasonable balance of memory and throughput loads (minimize

power/thermal resources required by onboard SSDS)

Grouping of functions that may be required For one or more physical

modules (e.g., power, thermal.and communication and ECLSS, crew

systems and structure/mechanism.)

Separation of functions (as much as possible) between those

identified with core operations and payload operations.

Minimize network interaction

Growth of memory configurations

The Communications and Tracking Subsystem of the reference configuration was

restructured to include only the communications related functions (under

?unction 4.2.5). The tracking function of pointing all steerable hardware

(solar arrays, antennas, payload pallets, and movable mounts) were allocatod

to a tracking Subsystem. The hardware associated with sensing and

self-locking on radiated signals is associated with the Communications

Subsystem.

Appendix C defines all SSDS external interfaces including the SSDS to

subsystem sensors/effectors derived from the Task 1 developed functional

requirements data base. Table 6.3--3 provides cross-correlation of the Task 1

defined externals (abbreviated) to the sensor/effector terminology used in

this system definition report.

6-10
Table 6.3-2

PARTITIONING OF IDMS FUNCTION SET*

DMS ODB FACILITY MANAGEMENT

4.1.6

5.1 .I

5.1.2

5.1.3

TIME & FREQUENCY MGMT.

FIGHT DATA BASE MGMT.

FLIGHT RESOURCE MGMT.

DISPLAYS & CONTROLS

2.1

2.2

2.3

3.3

3.4

VALIDATE PL CMMD

CHECK PL CMMD RESTRICTION/

CONSTRAINTS

VALIDATE CORE CMMD/DATA

DEVELOP OPS EVENT SCHEDULER

SEQUENCE OPS

4.3.2 SPACE STATION SAFETY

4.3.5 OPS AND PROCEDURE SUPPORT

4.5 MONITOR & STATUS SYSTEM

*Sizlng data for these functions appears in Table 6.B-I (Section 6.B)

The data of Table 6.3-1 were used to select the size of the SDP. To cover

growth and provide an adequate margin, an SDP size of 4 megabytes and 2 MIPS

is recommended. Large elements of Payload and Servicing Accommodations (P&SA)

are candidates to be either loaded into an SDP or a workstation For execution

because of their infrequent use. For example, Function 2.6 SSPE Checkout and

Service (Table 6.8-1) is Ii00 Kbytes. If this is saved in secondary mass

storage, the P&SA SDP memory configuration can be reduced by 1100 Kbytes.

Therefore, the largest SDP memory configuration in Table 6.3-1 then becomes

No, 2 (Elec, Power, Thermal and Comm) at 3408 Kbytes (growth). This leaves an

additional margin of more than 33% beyond the estimated growth size. '[his

technique can be applied to the other memory configurations as we11.

The sizing estimates do not include any, consideration of extensive Ai[

processing. The data in our Function Data Base for the onboard functions

generally represents traditional sizing methods. A policy that augments these

base numbers for AI needs, when they become defined, should be addressed.

6-11
TABLE 6.3-3 (Page l of 3)

ONBOARD ARCHITECTURE CONFIGURATION SENSORS & EFFECTORS

MAP TO APPENDIX C EXTERNAL INTERFACES

SENSORS

& EFFECTORS

ABBREVIATION* DEFINITION APPENDIX ABBREVIATIONS

Align Structural Alignment

Sensors and Controller

ALIGN S

MODESENS

=, B ACT Solar Array Gimbal

Control Actuators

PNTG MNT

CMG Control Moment Gyros CMG

Comml/F Communication Gateway COMEQUIP OMVOTVIF

COMM I/F OMV I/F

COMMSYS OTV I/F

CONSTI/F

Crew Sys Crew Systems EMU

MMU

PHYS MON

WASTE AN

ECLSS Environmental Control and

Life Support System

PRESCOMP

AIR TEMP

AIR TOX

AIRCIRC

AIRMAKUP

ATM CTL

GREYWATR

HUMIDITY

TEMP/HUM

POT SUPL

CABNPRES

CONTAMSR

ECLSS

FIRE CTL

FIREDECT

OX LEVEL

*See Figures 6.6-I and 6.6-2

6-12
TABLE 6.3-3 (Page 2 of 3)

ONBOARO ARCHITECTURE CONFIGURATION SENSORS & EFFECTORS

MAP TO APPENDIX C EXTERNAL INTERFACES

SENSORS

& EFFECTORS

ABBREVIATION* DEFINITION APPENDIX C ABBREVIATIONS

GPS Global Positioning System GPS TRAK

MAG Torq Magnetic Torquer MAGTORQ

Mech Mechanical Latches, Connectors AIRLKCTL

AIRLOCK

MECH

STR MECH

MRMS Mobile Remote Manipulator System MRMS

MTU Master Timing Unit TIMEFREQ

PL's Payloads and Pallets

PL Mount

PALLET

P/LCONST

P/LCSTIF

POP/COP

SS P/L

Prox Ops Proximity Operations TRAKSENS

PORT

PROXTRAK

*See Figures 6.6-1 and 6.6-2

6-13
TABLE 6.3-3 (Page 3 of 3)

ONBOARD ARCHITECTURE CONFIGURATION SENSORS & EFFECTORS

MAP TO APPENDIX C EXTERNAL INTERFACES

SENSORS

& EFFECTORS

ABBREVIATION DEFINITION APPENDIX C ABBREVIATIONS

Pwr Power System CHRG/REG PWRSWTCH

ENERGYST SLRARRAY

PWR SYST SWITCHGR

RAD Cont Radiator Control PNTG MNT

RADIATOR

RCS Reaction Control System RCS

Star Tracker Star Tracker STARTRAK

Strap Down Strap Down Gyro or Inertial

Measurement Device

RATEGYRO

THM Thermal Control System THERMCAP THERMCTL

COOL CTL HTEMPCTL

FL LOOPS LTEMPCTL

FLUIDCTL P/L IFHX

RADIATOR

Trk Long Range Trackers L/R TRAK

TRAKSENS

*See Figures 6.6-I and 6.6-2

6-14
6.4 Architecture

6.4.1 Overall Partitioninq

The overall onboard architecture presented here has most of the same

connectivity generalized in the NASA Reference Configuration. However, the

system definition process of this study has resulted in a more specific and

detailed configuration. An overview of the significant architectural features

and a comparison with the Reference Configuration is provided in Table 6.4-1.

6.4.2 Network Confiquration

The onboard local area network (LAN) provides the means for information

transfer between communicating Onboard SSDS elements. Local area networks

basically consist of transmission media, Network Interface Units (NIUs), and

the Network Operating System (NOS) (Figure 6.4-I shows a generic

representation of a LAN). The NOS is discussed in more detail in Sections

6.4.2.2 and 6.4.4.

The Space Station onboard LAN must accommodate requirements for high

performance, reliability, maintainability, and evolutionary growth, in a

cost-effective manner. This results in a design that must provide features

such as high network bandwidth, fault tolerance capabilities, modularity and

the appropriate application of standards to allow design extendability and to

incorporate new technology.

6.4.2.1 LAN Definition

In defining the Space Station onboard LAN, the configuration, level of

standardization, transmission media, topology and media access method, as well

as the functions performed bv the network communication system must be

addressed.

6-15
TABLE 6.4-I

REFERENCE

CONFIGURATION

TWO LAN NETWORKS

- CORE

- PAYLOAD

SSDS A/A

SAME

SINGLE COMM

GATEWAY TO TDRS

AND CONSTELLATION

SAME

PAYLOAD AND CORE LAN

GATEWAY TO COMM NODE

SAME

BACK-END SDP I/Fs TO

SENSORS AND EFFECTORS

NIU I/Fs TO SENSORS

AND EFFECTORS

SINGLE I/F BETWEEN NIU AND SDP

• NO BACK-END I/F TO SDP

• SAME

• SAME

GN&C SET OF SDP's SEPARATED

FROM IDMS SDP SET

GN&C SPLIT INTO TWO MEMORY

CONFIGURATIONS (NAV/TRAFFIC, G/C)

• SIMILAR - - ASSIGNED SDP

TRIAD WITH BACKUP

FLEXIBILITY

• GN&C PRELIMINARY SIZING

DOES NOT DRIVE SDP

SIZING (NO GN&C FUNCTION

SPLIT)

DEDICATED SDP(s) TO SUBSYSTEMS

(H/W INTENSIVE)

COMBINE SMALLER SUBSYSTEMS

INTO SINGLE GPC(s)

(SOFTWARE PARTITIONING)

6-16
I Device I ] I Device 3 1

I

NIU" i

I

I

I ,o.I

i

I Device _ I

I

I NIU °

I

MEDIA

I Device I I

I

I

I Device 3 I

i

NIU" I

I

l NIU*

I

MEDIA

Device 2 J

I

NIU*

I

*Contains NOS

Figure 6.4-1. Generic Local Area Network

6-17
6.4.2.2 Configuration

Onboard the Space Station there are two alternatives for configuring the

network communications: I) one LAN interconnecting all devices and

2) multiple LANe interconnected by bridges/gateways. The multiple LAN option

was determined to be the most suitable configuration onboard the Space Station

per the Onboard LAN Trade Study (Task 3). This configuration provides a

highly reconfigurable system which would potentially handle more data with

minimum resource contention. It not only allows for an easier build-up

(integration, test, verification) with one or more LANs per module, but also

enhances security/privacy since the payload and core devices would be on

physically different LANs.

6.4.2.3 Level of Standardization

The multiple LANe should all conform to the same standard at IOC, but this

does not preclude the use of multiple standards for LANe in the growth phase.

The single standard for LANs at IOC allows for a simple bridge with no need

for gateways while also satisfying the commonality requirement. Having a

single standard for LANs at IOC provides the most cost-effective solution.

Simulation analyses has shown that there would be relatively little

performance gain to warrant matching LAN Topology and access methods to

variations in module network traffic characteristics (i.e. frequency

distribution, mean packet sizes, etc.).

However, since future requirements and technology developments may vary,

multiple LAN standards after IOC should be allowed. This is consistent with

the Onboard LAN Trade Study (Task 3).

6.4.2.4 Transmission Media

The transmission media for the primary LANs onboard the Space Station should

be optical fiber. 'This media has a high bandwidth allowing it to support high

rate applications such as payloads, and also provide a high growth potential.

It is also highly secure and has a high noise immunity, low weight, and an

6-18
extremely low Bit Error Rate (BER). Optical fiber carl be used for inside the

modules and outside. Outside the modules, fiber can be placed along the

structure to allow for the connection of payloads and core devices located on

the structure to the LAN; however these Fibers .nay require additional

shielding For large temperature variations and radiation.

Between the NIU's and back-end devices and between the SDP's and NIU's

(sensor/effectors, workstations, payloads), high bandwidth fiber optics are

not required. Therefore, twisted shielded pair can normally be used For

serial and parallel transmissions. This media is low cost, highly reliable

and can operate above I Mbps which will satisfy most back-end rate user needs.

Specific high rate payloads require data rates that currently exceed the

computational and input/output capabilities of todays NIU's and SDP's. These

cases require dedicated media such as coax or fiber to move their data

directly to the onboard C&T interface to be multiplexed with lower rate data

and transmitted to a ground receiving station(s).

6.4.2.5 Topology and Media Rccess Method

The topology and media access method selected for the LRNs is token passing

rings (e.g., ANSI X3Tg.5, FDDI system) with redundancy paths. The cost and

risk associated with the ANSI X3T9.5 FDDI should be relatively low since this

is an emerging standard. Since this system is not currently available, the

cost, physical characteristics, and environmental characteristics have not yet

been determined and, therefore, could not be evaluated. It is felt, however,

that these characteristics, once defined, will satisfy the Space Station

requirements.

6.4.2.6 Network Communications Functions

lhe functions performed by a network communications system will be described

in terms of the International Standards Organization Open Systems Interconnect

(ISO/OSI) model for layered communications systems. The layered architecture

provides flexibility in revising and augmenting the system. The possible set

of functions performed by each of the seven ISO/OSI layers are shown in Table

6-19
6.4-2. The ISO/OSI model allows for the absence of some of the functions or

layers if they are not required for a given communications system. As the

need arises, however, these functions or layers may be added with minimal

impact to the existing system.

In order to provide a high performance, cost effective system for the onboard

LAN, only the required software services should be provided at IOC. However,

the hardware must be sized at IOC to allow for additional software services to

be incorporated for planned growth.

One significant question regaFding performance addresses the issue of whether

message transfers should be connection-oriented or connectionless or both.

secondary part of the question is what ISO/OSI model layers should support

connection oriented transactions if they are required. Connection-oriented

service at the Data Link layer (layer 2) implies sequencing and error

control. However, due to the robust nature and low bit error rate of the

transmission medium, these services can be performed at a higher layer (layer

4) and still provide efficient yet reliable communications. The Data [.ink

Layer will therefore provide connectionless service.

Connection oriented service at the network layer allows large networks (such

as multiple LANs interconnected by bridges) to be operated as one large

network with deterministic global resource allocation. Nhen routed, each

packet of a message follows the same path. Each packet transmitted throuqh a

connectionless network layer is routed independently. For the onboard LAN,

connectionless service at the network layer will provide efficient services

with less overhead.

At the transport layer', connection oriented service implies end-to--end flow

control, sequencing, and error checking. Since these essential services are

not provided by the connectionless network and data link layers, the transport

layer should be connection-oriented. Of the ISO Transport Layer classes of

service, Class 4 will provide timely and reliable data transfer for mission

critical data. The functions available with Class 4 include data transfer

with segmenting, multiplexing, error detection and recovery, flow control, and

expedited data transfer. Class 2 service, which provides for data transfer

with flow control, may be satisfactory for sensors with over-sampled or

6-20
Table 6.4-2: ISO/OSI Functions (Part 1 of 2)

ISO/OSI FUNCTIONS IOC GROWTH

layer

7

lappl Icatlon

6

Ipresentatlon

5

session

Connection Oriented

-bulk file transfer

-virtual terminal usage

-message handling services

-Job transfer and manipulation

-stream oriented access to devices

Connectlonless Oriented

-data collection

-outward data dissemination

-broadcast / multlcast

-request / response applications

Connection / Connectlonless Services

-IO of communicating partners

-Establishment of authority comm.

-Authorization of intended partn.

-Application Layer Management

-security - encryptlon

-data compression

-character code conversion

-graphics syntax conversion

-presentation layer management

-expedited delivery

-multiplexing sessions

-resynchronlzatlon (checkpolntlng)

-dialog control

-binding

-quarantine service

-sequencing

-session layer management

X

X

X

X

X

X

X

X

X

X

X

X

source x

x

x

x

X

X

X

X

X

X

X

X

perishable data. It is recommended that at least two classes of service be

offered at this layer.

The transport layer connections for NOS-to-NOS messages should be established

when an NIU is initialized with a11 other NIUs on the LAN. These connections

are to remain in effect as long as the NIU is operatlional. Other connections

6-21
Table 6.4-2: ISO/OSI Functions (Part 2 of 2)

ISO/OSII FUNCTIONS IOC GROWTH

layer

4

transport

3

network

2

data

llnk

-connectlonless management

-connection management

-segmentation / reassembly

-sequencing

-blocking / deblocking

-header error control

-data multiplexing connections

-expedited delivery

-resetting

-flow control

-error detection / control

-address mapping

-service type conversion

-transport layer management

-routing / switching / relaying

-congestion control

-packetlzatlon /reassembly

-sequencing

-header error control

-quality of service maintenance

-expedited delivery

-error control

-accounting (financial)

-network layer management

-framing

-error control / notification

-media access

-sequencing

-flow control

-data llnk layer management

determined by medium

are established by tasks and are disconnected when the task terminates. A

conne('tion-oriented transport layer provides the essential error control and

sequencing and also provides a higher throughput by allowing a connectionless

network and data link layer.

6-22
The session, presentation and application layers should offer both

connection-oriented and connectionless service. The type of service requested

at these layers should be the same in a11 three layers. Connections at these

layers should be established for each process-to-process communication and

should have a limited lifetime.

The functions provided at IOC, should be those which support connectionless

network and data link layers and a connection-oriented transport layer. The

higher layers (application, presentation and session) support both

connection-oriented and connectionless service. These functions, which are

necessary to support a reliable data transfer service, are categorized in

Table 6.4-2 as being present at IOC. Other functions can be added as needed

beyond IOC. These.are categorized in Table 6.4-2 as possible growth items.

In the presentation layer, the syntax negotiations should not be necessary at

IOC since common elements (hardware and software) will be utilized wherever

possible. As shown in the table this results in a null presention layer for

IOC. Data compression and encryption services can also be employed by

customer/subsystems requiring such services, but this will not be provided by

the data management system as a standard service at IOC. However, these

services could be provided for growth.

The application layer functions serve both connection-oriented and

connectionless types of data transfers as shown in Table 6.4-2.

6.4.3 NIU Functional Description

As determined by the Onboard Local Area Network Trade Study (Task 3), the NIU

should perform the functions corresponding to the physical, data link,

network, and transport layers of the ISO/OSI. ]he functions corresponding to

the session, presentation, and application layers of the ISO/OSI model should

reside in the host device. The division of layers between the host and NIU

are possible because the session-transport interface allows for transparency

with minimal impact on NIU performance. The NIU software can be standardized

since only common communications services are provided by the NIU. This

6-23
configuration of the NIU is also functional as a bridge/gateway as it provides

For buffering and Flow control in the NIU.

When sensors and effectors are attached to the back-end of an NIU, these NIIJ's

only provide a subset of the software services discussed above. For example,

only the Class 2 transport layer functions may be provided.

6.4.4 Op.eratinq System/Application

The onboard distributed operating system (DOS) will provide the environment

enabling customers, operators, and application processes to share the

capabilities of the resources connected through the Space Station local area

network. The "transparency" of the network will be achieved through a highly

reliable and Flexible interprocess communication facility and layered

communication protocol. In addition to the DOS, each NIU and SDP will run its

own traditional operating system to handle such tasks as interrupt handling,

task management, etc.

The DOS will be physically divided between network interface units (NIUs), and

Subsystem Data Processors (SDPs) in the network. Functions which execute in

every NIU or every SDP may be thought of as the actual operating system (OS)

component. The remaining functions to be performed by the DOS will reside in

certain SDPs and may be thought of as application components of the DOS. This

section will describe functions which may be considered as responsibilities of

the DOS, Figure 6.4-2 illustrates the division of the DOS between the NIU and

SDP, and distinguishes those as Functions which Form the OS component, and

those which comprise the application component. Further, the division o? the

OS component between NIUs and SDPs will also be discussed.

6.4.4.1 Generic DOS Functions

lhe list below is a summary of the wide range of functions provided by the

DOS. Another important component of the DOS, the layered protocol used For

communiation across the network (which is also split between the NIU and SDP),

has been described in context with the discussion of local area n_tworks and

n_twork interface units (6.4.2, 6.4.3).

6-24
I °

°

The management of peripheral resources such as output devices and

file systems.

The reconfiguration of memory loads when necessary. DOS will provide for

automated switching to a cold backup and automated loading of spare

computers in the event of primary failure. If fixed memory configurations

are utilized, it may be possible to employ an expert system or some other

technique to automatically replace lower priority functions with higher

priority functions when all processors are being utilized.

Rn efficient interprocess communication facility (IPC) to obtain data

or to initiate an interactive session with another process. The

syntax and semantics of this facility should make it applicable for

communication between processes on a single machine or ones on

different machines.

4, R method of delivering frequently requested data. R method other

than IPC will be utilized to avoid disturbing the owner of the data

and for potentially ?aster response times. The results of the DOS

N I U Hardware

NIU Software

SDP Hardware ._

SDP Software

Figure 6.4-2. DOS Division NIU and a SDP

Network

Operating

System

(NOS)

(ISO/OSI Layers

1-4)

NIU

Kernal

Operating System

Processor

System

Services

(ISO/OSI Layers

5-7)

SDP

Kernal

Operating System

DOS

6-25
trade study suggest that any of the following techniques may be

utilized:

lhe owner of the data sends the values to a database, from which

the values may be obtained by applications.

• The owner of the data multicasts the values.

The owner of the data broadcasts the values. The content of the

broadcast will be indicated in a special field in the layer 2

header so that every NIU is not forced to read in the packet in

order to determine its contents. This scheme is the most

questionable of the three.

5. Monitoring the network for performance, trending, and errors.

. Network reconfiguration - This includes initializing and shutting

down NIUs/SDPs and keeping a record of where checkpoint information

may be obtained for each SDP. Such a record will be utilized in

reinitializing functions of that SDP in a cold backup. Switching to

hot backups will be application dependent.

7° Scheduling commands and functions. The need for scheduling often

arises in accessing network resources. Such scheduling may be based

on classification as emergency, real time, non-real time, background,

etc.

8 , Verification of commands - determination of whether a command is

restricted/constrained (i.e., potentially hazardous to Station or

crew, or may interfere with other SS or payload operations) or

unrestricted/unconstrained.

9 , The implementation of individual functions associated with network

communication, including addressing, routing, congestion control, and

flow control.

6-26
6.4.4.2 The Application Component of the DOS

Several of the functions listed above need not be performed in every NIU or"

every SDP. Still others require a sufficient amount of available CPU and

memory resources such that it is not feasible to perform the function in every

NIU or every SDP (e.g., such a function is a name server for determining

physical addresses from logical ones). This study has determined that the

following functions will be performed in only certain SDPs and therefore

should be thought of as application functions of the DOS.

Command verification and command preprocessing functions.

All network-wide file management, output device management, and

database management will be at the resource providing the service or

if the device is unintelligent, management will be assigned to a

designated SDP selected to manage that resource.

Global monitoring functions for the purpose of assessing global

network performance, trending, and error logging.

6.4.4.3

Network reconfiguration: i.e, warn an operator to shut down an NIU,

and to actually shut down and reactivate NIUs once such commands are

given by the operator. This function will also provide the means by

which a processor (NIU or SDP) may be initialized with a memory load.

The Distributed OS Components of the DOS

The functions listed below for the component of the DOS which is present in

every NIU and SDP. The portion which is resident in the NIU is defined as the

Network Operating System or NOS. That portion which is resident in the SDP

will be an interface between the traditional operating system running in the

SDP and the NOS. The functions are listed in their probable sequence of

execution.

SDP resident portion of the DOS:

The SDP will contain a set of commands for use by applications in

6-27
Q

specifying requests for data, sensor values, variables, communication with

another process, etc. Such a command may be GET_SENSOR_VALUE_(SENSOR),

for example.

The interprocess communication mechanism. Once a command such as GETSENSOR-VALUE is issued by the application, the SDP resident portion of the

DOS determines whether the sensor is local or remote, and if remote,

issues a message containing a request for the reading of the sensor.

The decision of whether to use broadcast, multicast, or point-to-.point IPC

to deliver the message is made at this point. Such a decision will be

based on the needs of the application sending the message.

Other Layer 7-5 functions of the ISOIOSI protocol are executed as needed.

At layer 6 (presentation), negotiations between the sender and receiver

will determine if any protocol conversions are required. Our

recommendation is that this layer should be null for IOC due to the use of

homogeneous protocols.

Certain layer 5 (session) functions are then performed including

segmentation of a long message into pieces that the NIU can handle, if

necessary. Similarly, reassembly is done on incoming segments. An SDP

header containing at least the following information is then attached to

the message (or segment):

- The segment number of the current transmission.

Source process (physical ID) and destination process, sensor,

effector, etc. (logical ID)

Indication of whether point-to-point, broadcast, or multicast service

is to be used.

Note that this header which is passed to the NIU will be reformatted by the

layer 4 protocol of the NIU. For example, all logical addresses will be

replaced with physical addresses.

6-28
NIU Resident Portion of the DOS:

Once a message or segment is received from the host, the layer 4 functions

are performed, The most important of these is determining a physical

address for the logical destination address. The operating system trade

study determined that a "cache" of frequently requested addresses will be

maintained, with all other addresses being obtained from the centraliz(_d

name server. A request for the address will be broadcast if the name

server is unavailable. Since connection service is to be used at layer 4,

flow control will be achieved through the credit window scheme. The

destination NIU is contacted to determine the length and rate of

transmission which can be accepted.

Q Layer 3 functions will then be executed, including determining routing for

any internetwork messages. If routing tables are not maintained as every

NIU (left as a TBD design decision), all internetwork messages will be

sent to a designated bridge of the LAN where the message originates. The

bridge's routing table will be utilized to forward the packet on its way

to the destination.

Segments will be divided into packets and transmitted through the network

using the layer 2 and layer I protocols. Variable length packets will be

utilized to make maximum use of available bandwidth. Connectionless

service is used at this level.

The NOS software in the NIU will also have the following capabilities:

• The ability to broadcast, multicast, or send point-to-point messages.

• The ability to place connected SDPs on or off-line when commanded to do so.

The ability to monitor the NIU in terms of logging transactions and

detecting errors.

• lhe ability to place the NIU on or off-line when commanded to do so.

6-29
6.4.5 Subsystem Data Processor

The Phase B RFP identifies the need for a standard Subsystem Data Processor"

(SDP). This study concluded that this level of commonality is appropriate for

IOC but should not preclude future options to support growth and technology

insertion. However, any new technology processor brought into the program

should strongly consider maintaining the same instruction set architecture

(ISA) to maximize software recovery/transportability. To support the expected

storage, computation capability and data transfer rates the IOC SDP is

characterized as Follows:

- Main Memory: 4 megabytes

- Computational Speed: 2000 KOPS

- DMA Channel Speed: 1MHZ, 16 bit parallel

These requirements were established based on subsystem sizing estimates (with

a sizable margin For growth) and an evaluation of what the technology should

support at the time (1986) SDP technology will be selected.

6.4.6 Onboard Workstations

The Phase B Reference Configuration indicates three basic types of operator

interfaces to distributed workstations. They are:

m Operations Center in HAB Module 2

• Multi Purpose Applications Consoles (MPACs)

• Portable MPACs

6-30
Our view of the MPAC characteristics is the same as the Reference

Configuration. They are:

Easy to use (keyboard, displays, etc.)

[.ightweight, power efficient

Standard interface (100% interchangeable)

Configurable by operator

Functionally, the MPAC hardware and software should provide the following

capabilities:

Access to and interaction with the onboard data base.

Load and run selected application programs (initiated by operator

actions) that are executed infrequently, thereby reducing SDP loads

and possibly network loads. This could leave the SDPs to execute

mostly cyclic programs.

Common interface for core and payload operators.

Commonality with ground operator interfaces, which simplifies

training for inflight operations.

Ability to define (through the use of a standard User Interface

Language (UIL)) and execute ad-hoc operations on data contained in

the onboard or ground data bases. This would include the generation

of displays for trend analysis, subsystem monitoring, etc.

Finally, the possibility of having the same processor in the SDP, the

Operations Center (in HAB2) and MPAC should be studied to significantly reduce

costs, maintenance and training.

6.4,7 Operational D@ta Base

6.4,7.1 Onboard Operational Data Base Management System (()DBMS)

6-31
Current estimates of the onboard ODBMS Storage Requirements for IOC are as

Fol lows :

I) The DMS must provide the capability for approximately 256 Mbytes of

non-volatile storage for the core subsystems based on the following:

90 Mbytes

10 Mbytes

I0 Mbytes

I0 Mbytes

10 Mbytes

50 Mbytes

76 Mbytes

application program loads

checkpoints

engineering data

procedures

schedules

telemetry data acquisition

margin

2) Storage requirements for the payload ODBMS are not as easily

estimated. For this report we are assuming that the payload ODI3MS

storage requirements are the same as those for the core ODBMS (256

Mbytes). As payload requirements are better understood this estimate

will be refined.

The ODBMS which provides this storage can be structured as presented in Figure

6.4-3. Separate ODMBS services exists in the Core Local Area Network (CLAN)

and the Payload Local Area Network (PLAN). lhese ODBMS's are homogeneous and

communicate to support ancillary data distribution, and other standard core

services.

The data acquisition interface to the ODBMS is presented in Figure 6.4-4. The

subsystems collect data into records and deliver these records to the ODBMS on

a dynamically negotiated.basis. (More details are given in the Data Base

Management trade study, Section 1.5.2.1.) The ODBMS supports Telemetry

Traffic Control (TFC) in building Telemetry Buffer Units (TBU's) for delivery

to the communication toggle buffers. The same interface exists for PL/EXP

except the PL/EXP delivers data in the CCSDS telemetry packet format. The ITC

segments these packets (if necessary) when building the TBU's.

For the build-up of the onboard mass storage configuration it is recommended

6-32
User Interface

Subsystems

I SDP/NIU Node ***

r NIU L]

Local Bus

Network

SDP/NIU

Node

-1

I

I

I

I

I

ODBMS I

L___

LocalBus "1 I'-

Bridge

!XP Network'

II I

SDP/NIU

II Node II

II ... SDP/NIU Node

_ss i I I

Storage J DBMS I PL

I Processing

J I

I Local Bus tin_ 1

ODBMS J

Elements I I

I I

I _ss I

I Storage I

L /

Figure 6.4-3. Onboard Data BaseManagement System Interfaces

PL User

Interface

that the scenario presented in Figure 6.4-5 be used. In this configuration

the SDP/NIU nodes manage local non-volatile memory For the first two flights

and then mass storage units are delivered in the first pressurized modu].e

(HM1). The mass storage units are distributed into the pressurized modules.

6-33
Subsystem Processor

Task 1 Memor,

Task 2 Memory

SDP/NIU Node

Subsystem

Data

Collection

Process

Task 3 Memory

\

• /

Figure 6.4-4. TTC Interface

)r

/

SDP/NIU Node

I

L "°°9

TTC

Toggle to

Comm I/F

The recommended mass storage integration with other Onboard SSDS elements is

presented in Figure 6.4-6. In this configuration the mass storage is on a

standard local bus (serial or parallel to be determined) on the backend of an

NIU.

6.4.7.2 Mass Storaqe Devices

The SSDS will have many applications that will use many diFFerent kinds oF

mass storage devices. The three most driving onboard space station

application areas are:

6-34
Alternative 1

SDP/NIU Node

SDP

I Volatile

J Memory

A

I NIU

I INonI I Volatile

| ] Memory

& A I I

P'/////////A

r

I

I

I000

I

I

L

Figure 6.4-5. ODBMS Flight Build-Up

SDP/NIU Node

SDP I

NIU

w

I

SDP

SDP/NIU Node

1

I

I

I

I

I

I

_1

Local SDP/NIU Non-Volatile

Memory For First Flights

(Recovery of Non-Volatile

Memory By Transfer From

Redundant Elements or

Ground)

Added on Later

Flight in Pressurized

Module

Alternative 1

ODBMS (Primary) ODBMS (Backup) ODBMS (Backup)

SDP/NIU Node

SDP

SDP/NIU Node

SDP

SDPINIU Node

sopI

NIU NIU I

L #_ _'11'

Figure 6.4-6, ODBMS Mass Memory Integration

Standard SDP/NIU Used

With Standard Serial

Local Bus Interface

Local Serial Bus

_f _? f

_ 1 I _ l I _ l I

6-35
I. Onboard Data Base Management System (ODBMS) mass store.

2. High rate data buffer.

2, Payload Local Area Network (PLAN) communication data buffer.

The requirements and design characteristics for these applications were

developed through mission set analysis, simulations, function set analysis,

and engineering design judgement. Zhe derived requirements and design

characteristics for each of the above applications are:

I , DBMS MASS STORE

2x109 BITS CAPACITY

10 Mbit/second transfer rate

40 millisecond access time

, HIGH RATE DATA BUFFER

2xlO 11 bits capacity

300 Mbits/second in

600 Mbits/second out (assuming two KSA links)

3 ° PLAN COMMUNICATION DATA BUFFER

12xi09 bits capacity

10 Mbits/second transfer rate

The recommended mass storage option for all of the above application areas is

eraseable optical disk if the technology can be developed and demonstrated by

IOC° lhis recommendation is based on the desire for hardware commonality

across all onboard mas_ storage applications. The driving requirement is the

high rate data buffer where the optional disk offers random access capability

(eliminate's need for subsequent bit/packet reversal), enhances buffer design

flexibility and provides significant capacity for growth.

If eraseable optical disk cannot be developed as recommended for IOC then

magnetic disk (Winchester Technology) should be used for the O[)BMS m(_ss store,

and magnetic tape For the buffers. Regardless of the technology used For the

IOC configuration, eraseable optical disk should be developed for" use in the

growth Space Station.

6-36
7he Function Data Base contains sizing estimates for secondary storage and

archival storage. These are yet to be evaluated in detail and will be

included in a future update to this report.

6.4.8 Communication Gateway

The "communication gateway" is a term that is associated with the functions

performed to receive and deliver messages into and out-of the onboard local

area networks. These functions are actually distributed into three DMS

functions; data acquisition (DATA AC@), Telemetry Traffic Control (ITC), and

Telecommand Interface (TLMCMD I/F), and also functions in the Communication

Subsystem. The interface is depicted schematically in Figure 6.4-7. lhe DMS

functions are performed in the SDP's attached to the local area networks and

also mass storage devices managed by the DMS. The Communication Subsystem

functions are performed by a baseband processor (possibly an SDP), mass

storage, toggle buffers and RF processors.

The DATA ACQ function collects data from subsystems or PL's on a periodic or

aperiodic basis, as required, in support of the return link. This is done in

cooperation with the ODMBS. The ITC function assembles segments of this data

into Telemetry Buffer Units (TBU's) along with return link telecommands or

telecommand acknowledgements. These TBU's are transmitted to the

communication subsystem for the real-time return link (SSA). The TLMCMD I/F

Function disassembles forward link TBU's.

The TLMCMD I/F uses the addressed provided in segments of the forward link

TBU's to deliver data and commands to core and PL local area networks.

6-37
6.4.9 TRAFFIC ANALYSIS

The following two sections derived the network traffic requirements and

the network packet sizing. The requirements are presented in terms of

messages per second, a more meaningful traffic parameter than bytes per second.

6.4.9.1 TRAFFIC SIZING

Analysis of the network traffic model (both core and payload networks)

shows the communication and tracking NIU receives over 70% of the total

traffic for both the core and payload networks.

The network traffic model was derived from the McDonnell Douglas

Requirements Data Base (Appendlx-l) using an analysis tool developed in PL/I.

The tool allows functions in the Requirements Data Base to be arbitrarily

distributed across a multl-computer environment. The process allows the

operator to Interactlvely specify, for example:

Computer Computer Computer Computer

l 2 N-l N

Function # Function # External l

l.l.l 2.1.1 External 2

l.l.2 4.3.1

External 3

From this input, a search of the data base is made to determine the

following reports:

- Computer l to/from Computer 2

- Computer 1 and 2 to External Sets 1 and 2

- Computer l and 2 to External Set 3

Proper selection of the inputs, functions and externals, resulted in

statistical reports to evaluate the I/O requirements.

following statistics were determined:

Subsystem to subsystem I/O

Subsystem to subsystem s(nsors/effectors

From these inputs the

Subsystem to operational data base, ancillary data

Subsystem to displays

Subsystem to Comm for telemetry, operations instrumentation data

6-38
The network traffic model was developed from several sources:

(1) Analyses of Functions Data Base I/0 Relatlonships

(2) Engineering Modifications to (1) Above

(3) Engineering Judgement

Additions to the Network Traffic Rode1 included:

(1) Telemetry Data

(2) Operations Instrumentation Data

(3) Ancillary Data

(4) Ground Forward Commands

Table 6.4.9.1-1 identifies speclflc assumptions employed in the network

traffic analysis. Figure 6.4.9.1-1 and 6.4.9.1-2 show the processlng

dlstrlbutlon for both the core and payload networks. Figure 6.4.9.1-3 shows

a detalled payload distribution for the payload network. The Illustrated

payload attachments were arbltrarlly made and are not important to the network

traffic load. Only low data rate traffic under 1MBPS was considered in the

payload traffic model. Payload traffic with data rates greater than 1MBPS is

hardwired to the C&T subsystem.

TABLE 6.4.9.1-1 NETWORK I/O TRAFFIC ASSUMPTIONS

Requirements Sources

- Mission data sets for P/L telemetry rates (includes only P/L

instruments with data rates less than 1MBPS)

- Analysis of core traffic results and engineering _udgement to model

remaining non-telemetry payload network traffic nodes.

- Assume all P/Ls run simultaneously (some have duty cycles less than

24 hours/day)

Topology

- Integrated P/L instrument data access off backend of SOPs

- Flies/Data stores in each Subsystem SOP

- ORS ODB has it's own SDP

- P/L files/data stores in P/L SOPs

- P/L data base in P/L network

6-39
TABLE 6.4.9.1-1 (CONTINUED)

o Packet/Message Length

- Message length equals packet length

Telemetry

- 25 KBytes/sec per Subsystem

- 1 KByte Message size to satisfy Consultative Committee for Space Data

Systems (CCSDS) efficiency

- Telemetry messages sent from P/L network to C&T node

Displays

- Multiple panels possible per Subsystem per MPAC

- Four Windows per MPAC possible

- One 2 KByte message/sec per Subsystem to MPAC

Overhead

- OSI/CCSDS message overhead not included

o Ancillary Data (AD)

- Subsystems send AD to DMS ODB

- DMS ODB blocks AD and sends to P/L Network ODB

- P/L's read AD from P/L ODB as required

o Ground Forward Commands (GFC)

- Comm receives GFC for each subsystem

- Comm routes GFC to individual Subsystems

- Dependent on CMD VAL implementation

- P/L GFC are routed to P/L network for response

- O.l message/sec per subsystem

Operations Instrumentation Data (OLD)

- OID collected by each subsystem from backend

- Subsystems send blocked OID to COMM for downllnk

6-40
.ORIGINAL PAGE IS

IllClt'Ul _tiRi

_ORIGINAL _GE i:5

OF POOR QUALITY

F

7

(Mem. Config 3) I

S

ECLSS

Crew Sys k

Str& Mech

(Mere. Config 4)

DMS ODB

1C

12

i

(Mere. Config 1 )

rA'c°n'n? ?

NAV

I Guid

Traffic Co

Tracking

Ioca,

i d

dd

i, d

,_ Cor_ _ Lab1

s=.,o. .., 7o"o"e: "_

/-I',N---__-1

,-.# II._h , I-_CT1 .-I

, E

n m

i ,i ik

i

l 1F 'i F

/_

"",.',,1_ .. _2 _ _

.i II

II I/

// II

U

,

(Mere. Config 2) I_U

Pwr

, i Thermal _k i _ i

I Comm I/F /

" II .s k7-

S P 3 lral I P

'o* _"('2) 6L_ _

, T.acker I--' L CT_J--I ACI____ L ro_q____ II/F

(6) (2) (3) (6)

Transverse Boom Transverse Upper Keel

Boom Ext

16171 NIU

9 18_

Local Bus

(Mere. Config 511

FAC

Mgmt

I I A.gn I I-' Lower (2) Hi2

I _ Keel Lower Keel

/ It and Ext

/

r I Local_ r _ _7

r_:_ ==1-

(3)

Transverse Transverse

Boom Boom

Ext

7 E _] 11[ ]

./_ Core

/ |

r- ._.,_,__.wo._oo

HM2

t

Logi_icl

Module

Figure 6.4.9.1-1. Processing Distribution for Core LAN

FOLDOUT FRAME

_m,DOUT FRAME
-E}-

777

i/j

ii j

ii j

i/j

ii j

i/j

IIi

ill

i/j

ii j

ii j

'_!i:

/

/ .

I o

r,-

.3

I--I, LI_I_ -'_7._ _ _E

O_ _/0 rl u

.dl lb. .d _ "--

•_iII __14-'bl_'_ I_1 s

N

g

g

Z

-J

E

0

o-

_5

e4

,.t

6.42
p_.

x

ul

o

m

o

,=J

.._>

o

,_o

Q.

.__

6-4,3
\

Table 6.4.9.1-2 and 6.4.9.1-3 show the network traffic results for the

core and payload networks, respectively. These tables show for the core

network the traffic due to telemetry is approximately 60% of the total load

and the elemetry traffic on the payload network is over 80% of the total

traffic load.

6.4.9.2 PACKET SIZING

A 2048 byte packet has been selected as the baseline packet size for

network trades, analyses and design tasks. The MDAC function data base was

accessed to identify potential network messages. These were screened to

identify those which enter the network. Figure 6.4.9.2-I shows that the

majority of the messages entering the network are telemetry messages whose

length is less than 2048 bytes. Figure 6.4.9.2-2 shows that a 2048 byte

packet can accommodate 95% of all network messages without segmenting messages.

6-44
II II

II

II

I!

II

II • • •

II _ 0 i--t

II il II

II |1 II

II n II

n i! ii

ii ii ii

oI.I.-: I+.l+.l',Eii I I I ,,"'

-I-II-I-I-;i ,iIIII,,,,,,,,,,,,,,

f,_ iiII

I,- m

P.

A

0

0 _,4

e_ 0

II

II II II II

(30 _1 r_ II O _ Q Q Q II e,I II _O II

• II • • 11 II II '_ .4,,.4 _ _ _ _. _ ,, _ .

II _ II

II II

" _ "

II (..1 II

II II

n II

II II

II II

I1- II II II

II II

II i ,,II

II II

ILl II II

II II

f+#i II- II

II II

II II II

II Z; II II

tl II II

II II

II II II

II II II

II II II

II II II

II II II

II II II

II I_ II II

II = II 11

I _ II II

_l II tl II

"_ II U O

II II U II

II + II I_ _" II II II

{_1 n II

,,.

{_ II II II

II II II

r,_ II II II

,,

_-_ II II II •

GI II II U II N

z m,,II ,,_II _,,II

_ II II O it

H II II "_% ----II

II II _ II •

II +'*'*-II N

0 II . ,-,,,

_i II II II

II II

II II

II II

II _ rJ _ II

II II

II II

II II

n II

II II

II H II N

II Z _ II

II +,k+ II

r_

O P,I

O

+-4

1'='4

1+1

11

II'1 II

• II

II

II

II

II

II

II

U

II

II

II

n

n

II

ii

II

II

II

II

II

II

II

II

II

II

II

II

II

II

n

II

n

ii

Ii

n

II

n

II

II

• ii

1+1 II

1_ ii

II

II

ii

ii

II

• ii

_1 II

ii

II

II

O

II

_ Pt II

• • • II

II

II

II

II

II

II

• II

_O II

H

II

II

II

II

II

_'1 II

II

II

il

II

_ _ n

I|

I!

I!

• • II

_:' m 11

n

II

II

II

II

_ c'_i II _)

II <S .-;c;,.A

II

II

II I II

II ---- II

It II

roll _ IiI,,_,_ <,,° II UII n N P_

II _1 II

II _ II

II _ II

II _ II .Z

II _ I| _r

II k-I II N

II II -_

II II

II II

II II

II II

II II

II _ II

II II

II II

II II

II II I

II II

.II .II !_

0

,d

<.,l

II II

II II

II II

II II

II

II

II II

II P'_ II

It • II

II P_l II

If i,-I II

II II

II II

II II

II II

II II

II

II

n II II

II II _ II

II II + II

II II <_ II

II II II

II II II

II II II

II II -- II

II tl II

n II _-I II

II II -- II

II II _ II

II II II

II II il

II II II

II II II

tl II II

II II _ II

II II II

II I1 I_ II

II II II

II II II

II II II

II II -- II

II II II

II II _ II

II II II

II II _ II

U II II

II II II _¢i

II II II i,_

II II -- II

II II II

II II 13 II

II II II

II II _ II

II II II

II II II

+

II II II

II

II

II II II

II N II <_I II

II II II

.. ,:::; . <.,,, . _] II II I+4 II

II II II

II II II E)

II II -- II

II II II

II II _ II

II II -- II

11 II _1 1"=4

II II i'M

II U i_

n II _1

II II -- P_

II "

II • II -- U

II _ II -_' _Z;

II II _1 I--I

II II

II II _-I

II II -- +1

II II

II _ II

II I1 -- U

II _ II I-I

II II

II II

II II

tl II

II II +,-I

II II • 0

II II I-4

II II

II II

II II -- I

II II

II II <_

II II

II II

II I1 N

II II

II II --

II II

,, c; ., _ +.

II II c_ li_

II il

II II {&'J

II II -- i_.

II II

II N II _+ C_

II _.l II i't'i

II II _-4

I! II

II II

II II II

II II II

II II II

II II II

II II II

o" ..++I,,+,,

II U II II

II _ II II

II Z II II

II II II II

II U II II

II II II [,,-I

II _ It II II

II _ II II II

II II II II

II II II II

II II

,, ,, >-, _

II II U

II II

II II _ i I

,," _ II _ _ Cz,,

U U II _'J ,,+., i+I. tl II U

II II

II _ II

II II

. u

II

II (/l t'_ '_L

II

II

II II

II fJl ,f,i,,l Z _,11 "-- ,f.l_l f.l,.I Ill il

II II II

II
i

Io_

II1,, ii

N

II

N

'lII

m

U

II

ii

#

II

i! "-'1"1"1°_°1"1°1-1_: = ::

;l=i,:n_;:_;l_l._l_l -:.,, _ ::

, , : _ ,

:

II II #

-;_ ..... _,i_,

,.-, :

: ',:

'_"'_"_ _ :i: _ _ """ _": I o . o

oc_ oc; od o_ o. c;: ° • o• . _ _;1 _;

! : :

I ' :

0 0 0 0 0:0 0 _ _i _ ou

: : x

I : : o _

0 0 0 ,-4 O.n 0 0 0

v; _: • o .. • •

,-, ,::; ,-.:o o o c; o_ ,,"; .

I '

oooo :oooo_ _. _

•-; -; -; _ t:c; ..; c; _; c;. ._ ..

: : .

: :

: -: :

o o _. _.:_. _. _. _. _.: _. :

.; ,4 I -_ _:o _ o o o: _ ,,

II

: :

II II

: I ::

: ," ::

o o. o. o_o. o. _. ,_ _. ,_ ,,

I _; N _,, .-,:o .-, o .': _,, " "

::

_ I . _,_ : ,,

_1- _.: _'_ " "

-q,- -I- z n _. _" = " I:

0

-Io _._. _ 8 ,_ :

lii.,...._,o..,,, C,'] o,, _l:E-o

II

it

tO:n

(n =,a; no ::

="' I "< . _ to

"< I {,,-I no it, Ol lO

t i _-, .< ,, ... • ,, ,,

6-46
QNOC)=IS i::13dS30VSS31N

m

o

I-

>.

E

¢1)

¢1

I--

o

E

Z

c_

°

cd

LL

6-47
,3

I,.I

\

C_

C,

o:

w

UJ

_I

_W

I.-w

mo

LU..-I

i,,0

c_z

--JW

_0

z_o

II

g3OVgg3M N3_O_BNn dO 30VIN30H3d

DP_

t,_

I,,,,-

m

O

..,

14,1

N

I,,m =¢Zlm g,I

• D,.

.¢,,_

.N

a..

=E

o

I-

¢15

&

¢d

EL

6"48
6.4.10 F'ault Tolerance

The explicit fault tolerance requirement in the Phase B RFP is that "critical

subsystems" be fail-operational, fail-safe, restorable (FO/FS/R). The final

FO/FS/R decisions of which subsystems or their functions are critical has not

been made. The Phase B SE&I NASA/Contractor teams will study this issue. At

this stage, the SSDS A/A team believes the following functional areas are the

most critical:

m

Docking/Berthing Operations

Proximity Operations (NST$, COP, Free-flyers, OTV, OMV)

F m m m m m m m m m m m m m m m m

I

I NIU

I

,Core Netwq DMS Subsystem

i Local Bus

I

I/F

I

I

I

I

I

I

Local Bus

High Data

Rate Direct

Link

R-SSA F-SSA

Comm Comm

I/F I/F

I _, _ Baseband

i R F Proc

Figure 6.4-7. Communication Gateway

Local Bus

Switch

F-KSA J R-KSA

Comm Comm

I/F I/F

Mass

Store

NIU

Data Acq

TTC

l.u._,Mgmt Communicatio. Subsystem

I I m I m e a I m m I i .J

6-49
-- Transfers of Particular Fuels (e.g., OTV fueling)

A key point is that it is unlikely that any subsystem must be FO/FS/R with no

interruptions in functionality at all times. If this were really true, the

only solution is triple (or higher) redundant simultaneous execution. Shuttle

experience has shown that assigning redundant computers has a large impact on

the system design and verification is extremely costly. This should be

avoided for Space Station.

The Space Station environment on orbit is much more benign than the

atmospheric flight phases of Shuttle. The key to the solution is the

restoration time. It seems reasonable that a design which allows the loss of

a few seconds during recovery is acceptable for most subsystems if not a11.

The Fault Tolerance option development and Trade Study documentation provides

more supporting detail and analysis on this subject. The presentation of

this work is primarily in the form of what could be done to handle various

levels of subsystem availability and fault recovery time. The remaining

sections below summarize the four basic areas of fault tolerance:

• Replication

• Fault Detection

• Damage Assessment

• Error Recovery

6.4.10.1 Replication

Several functions may have the need for a very high probability of detection

i

of faults, with enough time to allow recovery by use of a checkpoint restart.

lhe recommendation is that such functions be designed for duplex operation in

critical time phases with at least one spare SDP. The system configuration is

such that the preferred spare is the SDP in the same triad with the primary

SDP. Reference Figure 6,6-I for the overall architecture that indicates the

SDP triads. However, the network is connected such that any other SDP can

assume the processing task by communications over the network instead of more

directly through an SDP/NIU set. While this connection exceeds FO/FS/R

B-50
requirements, there is a substantial improvement in overall reliability,

especially in man-tendedoperations whenno one is onboard to replace failed

SOPswithin a few hours or days of the failure. The operating system will be

designed so that the application is unaffected by the location of the SOP

(other than time delays for network communications).

Subsystemswhich have no need for very high probability of detecting a fault

will execute in simplex. This modehas the important advantage of minimizing

SpaceStation resources for power and cooling.

6.4.10.2 Fault Detection

The recommendedfault detection is based on separating the "system" function

of detecting a Faulty unit (SOP, NIU, network) From the subsystem Function of

detecting its own processing faults. The First part of fault detection is the

use of common hardware fault detection techniques such as built-in test

equipment (BITE), parity types of detection (including cyclic redundancy

checks, error correction coding, and other multiple bit protection), and

watchdog timers at major hardware interfaces. The recommended second part of

Fault detection is a background or periodic self-test program execution, which

tests as much of the unit (SDP, NIU, or network) as possible without

interference with any application or operating system function. This

combination is usually able to detect solid faults with probabilities of about

g5 percent. The recommended third part of fault detection is the inclusion in

the operating system of a periodic monitor which talks with each SOP and NIU

to assure basic stopped/running status. It is recommended that this monitor

Function execute in the duplex operation mode.

The recommended fourth'part of fault detection requires the help of

application programs executing in duplex or higher redundancies to achieve

fault detection much above the 95 percent level, and detection of trarsient

faults. Presumably, these applications have been designed to cross compare

sensor inputs and computed results as part of the applications' own Fault

detection. A method will be provided For the application to alert the

operating system of failure to compare, especially persistent miscompares,

including the option to request termination of the application followed by a

6-51
reload from mass storage and resumption from a checkpoint. (Note that the

effectiveness of this Fourth part depends on the maturity and thoroughness of

testing of the applications. Use is expected to be restricted to the more

critical core Functions.)

6.4.10.3 Damage Assessment

A two part approach is recommended for damage assessment, The intent is both

to determine which of a duplex pair is faulty (if this is not immediately

obvious) and to isolate the faulty component adequately for repair and

maintenance activities. Many Faults must be assessed immediately in-place in

order to minimize the number of very expensive problems which cannot be

recreated on a test bench. The First part of the assessment is to record any

unusual conditions (such as input/output errors, BITE detected errors, or

machine-check indications). These conditions are routinely recorded as part

of the operating system functions. The second part of the assessment is to

immediately execute a complete self-test of any suspect unit and to record the

results. Unless the unit is totally bad (e.g., loss of a power supply), the

self-test can often both confirm which unit is faulty and isolate which orbit

replaceable unit (ORU) needs to be exchanged to restore the unit to

operational status as a spare.

6.4.10.4 Error Recovery

The recommended approach to error recovery is to have each application

generate any checkpoints which are required for timely resumption Following a

failure. Specification of specific data content and checkpoint intervals will

be a part of the detail design of each application, and is beyond the scope of

the current study. However, the operating system will provide the basic

capability to write and recall checkpoints up to some redundancy level (for

example, keep only the last 5 checkpoints), and to detect the important case

of a checkpoint which was incomplete because the Failure occurred in the

middle of writing. Verification of the contents of the checkpoint is the

responsibility of each application program, beyond the usual checksum or

cyclic redundancy check provided by the operating system or storage medii_m.

6-52
6.4.11 Time Manaqement

The four topics of time management in the onboard data management system are:

time reference source; time distribution; time tagging of data; and Frequency

distribution. Reference the Time Management Option Development report For

more background detail.

6.4.11.1 Onboard Reference Source

Both the global positioning system (GPS) and a master timing unit (MFU) are

recommended as the time reference sources. The local oscillators of each NIU

and SDP are available as emergency references if both the GPS and MTU become

unavailable (which exceeds the FO/F$/R requirement). The order of precedence

is the GPS, the MTU, and the local oscillators. The primary reason for both

the GPS and the MTU is the lack of GPS during early buildup.

6.4,11.2 Time Distribution

The recommended method of time distribution throughout the DMS is via the

network. The three steps are: equalize the time in the NIU attached to the

reference source (GPS or MTU) to match the reference source; distribute time

from this NIU to all other NIUs in the network; equalize time in each SDP to

the time in its attached NIU. Details of the method are described in the

options development report on time management. The expectation is a time skew

within the network of less than one millisecond, and probably less than O.l

milliseconds. The process will be repeated every one to ten seconds to

prevent short term drifts at any NIU or SDP from becoming excessive.

6.4.11.3 Time Tagging of Data

Two forms of time must be provided. One form is continuous, with no

discontinuties at points such as end of day, end of year, or leap seconds.

This time form is the international time (TAI) recommended by CCSDS For

ephemeris time. The other form includes leap second corrections for the

slowing rotation of the earth. The continuous form will be Earth Mean Equator

ig50 (EME-5()). lhe discontinuous form will be Universal Coordinated Time

(UTC).

6-53
Standard time formats will be used for communication. Selection of specific

standard Formats is not a key design driver at this point in the project.

6.4.11.4 Frequency Distribution

Both the GPS and M TU provide precision frequency sources. 'The recommendation

is to use the MTU as the frequency reference source, since the MTU is

available throughout buildup. Frequency distribution will be by direct wiring

to each required user. The communications subsystem is expected to be the

prime user.

6.5 Operational Scenarios

6.5.1 Initialization

The onboard data management system will need to be intialized on orbit when

the first structures are in place, during buildup and operation if an upgrade

requires removing power from existing modules, and as the recovery mode from

major loss of power. The source of software programs is assumed to be one or

more mass storage devices onboard the Space Station, and accessible through

the core LAN. These mass storage devices are initially loaded on the ground,

with subsequent modifications by uplink data (either by onboard requests or

ground initiated updates) or by replacement at a resupply cycle. This section

describes an approach to the "cold start" of the entire data system.

Initialization o? individual subsystems during build-up, upgrades, and failure

recovery is a subset of these procedures.

lhis description assumes that the various units (SDPs, NIUs) may be turned on

in any order. Further, each SDP and NIU is assumed to have a non.-volatile

memory (ROM) that contains the minimal program necessary to load (boot) the

operating system into the SDP or NIU through the network. This initial

program load (IPL) ROM is forced to execute when power is first applied to the

unit, either by direct execution or by First copying the IPL program From the

ROM into main memory.

6-54
The general procedure has three phases. First, each NIU attached to a load

source (mass storage) recognizes this Function by its physical identification,

and uses its direct attachment to load itself with the network operating

system (NOS) and a the Full set of mass storage control programs. Second, the

other NIUs are loaded with the NOS through use of the mass storage on the

LAN. Third, the SDPs are loaded using the NOS contained in their attached

NIUs. At this point the crew or ground will have basic communication with the

data system to control subsystem initialization either by predefined tables or

by manual overrides of these tables.

6.5.1.1 NIU Attached to Mass Storage

The ROM in all NIUs will be the same. Nhen this ROM is given control at power

application, the program will use the physical identification of the NIU to

determine whether this NIU is attached to a mass storage, and Follow this

procedure or the one in the next section.

lhe NIU will first access a predefined location on the mass storage to read

the directory of the contents of the mass storage. The directory will next be

searched for the name of the entry for the network operating system (NOS). If

no such entry is Found, then this NIU is not really a load source, and will

revert to the procedures of the next section, lhe directory entry will

identify key items For loading the program into the NIU, typically the

starting address on the ,lass storage, the load address in the NIU memory, the

length of the program, and the address to branch to after the program is

loaded. This program is then loaded into the main NIU memory and started in

execution to complete the formal IPL procedure of the NIU.

The program which was loaded may be the Full NOS or may be the next step of a

multiple stage IPL procedure. Experience indicates that the maximum

flexibility results from loading only a small initial program through the

formal IPL (perhaps 1024 bytes). This small program then loads the main

program, The current recommendation is to include such a minimal program in

the ROM of the NIU.

6-55
At the conclusion of this step, the NIU will announce itself' to the onboard

LAN (log-on) as a source of program loads for any other device. This

information is needed by bridges or gateways in order to transfer messages

between local area networks.

6.5.1.2 NIUs Not Attached to Mass Storage

Any NIU not attached to mass storage cannot procede until at least one mass

storage has announced itself on the LAN, as above. The ROM in these NIUs will

detect the presence of a load source somewhere in the LAN by periodically

attempting to attach itself to any load source, perhaps once per second. The

request is repeated indefinitely until acknowledged so that if the mass

storage is not currently available, or if the NIU is turned on before the mass

storage, the NIU IPL will simply wait until a load source is available.

Once the attachment is made between the NIU and the mass storage (via the

LAN), the ROM program will request that the file named NOS-IPL (or equivalent)

be sent to the NIU. This request will be repeated indefinitely or until a

successful copy is obtained. After the file is loaded, the ROM program will

branch to a predefined main memory location in the NIU to begin execution of

the loaded program, completing the formal IPL of the NIU.

Again, the file may be only the first step of a multiple stage IPL procedure.

If the NIUs are not all identical, it is likely that the First stage, above,

will load the common part of the NOS, and a later stage will load any device

dependent NOS.

6.5.1.3 SDP Initialization

t

lhe SDP contains a ROM with the minimal program needed to communicate to the

NOS in the attached NIU, and through the NOS to a mass storage on the LAN.

This SDP IPL program may be executed either directly or after being loaded

into the main memory of the SDP.

6-56
The first step of the SDP IPL will be to determine if the attached NIU has

been loaded with the NOS. The SDP IPL will therefore interrogate the NIU

until the status shows that the NOS is available for use. The ROM will then

register (log on) to the NOS, using the physical identification of the SDP to

assure a unique name within the network. Next the SDP ROM will request that

file $DP-IPL (or equivalent) be copied From the mass storage to the SDP by use

of the LAN. At completion of this procedure, the ROM program will branch to a

predefined address in the SDP main memory completing the formal SDP IPL.

As with the NIU, this may be only the first step of a multiple stage IPL

procedure. Other stages may complete the loading of a Full operating system,

location dependent programs, and special applications such as the ODBMS

software.

6.5.1.4 Application Programs

During the early build-up phases the initialization process may wait at

completion of the above steps until a crewman or the ground directs Further

loading of particular programs into each SDP. Alternatively, a set of tables

on mass storage may define a default configuration of SDPs and workstations to

be automatically loaded and executed as the last steps of the IPL. The

approach recommended is to have both a table of default assignments to be

started automatically, and the capability to move subsystem processing within

the onboard network by modification of the tables.

" 6.5.2 Subsystem Control

Control of the onboard SSDS and associated subsystems is nominally automatic.

However manual overrides-via direct keyboard inputs from an onboard MPAC or

from telecommands from the ground will be provided. It is envisioned that all

subsystems can be controlled in this manner. This inplies there will be no

dedicated manual switches onboard.

6-57
The ground telecommands will be in one of two forms:

equivalent MPAC keyboard entries

special commands

The "equivalent MPAC keyboard entries" option has several advantages. First,

it minimizes the onboard impact of ground originated commands since the same

onboard command processing software can be used regardless of the source of

the command. Secondly, this approach provides commonality between ground and

onboard control functions. A ground operator would make the same keystrokes

on his MPAC as would the onboard operator to accomplish a given control

operation.

Special commands would be those for which no equivalent onboard command

capability exists. One example might be the capability to update the Space

Station state vector in the event of a GPS system failure.

Subsystems will normally have pre-built displays and keyboard entries to

manually monitor and control their operations. For unplanned situations, a

user interface language (UIL) will allow general access to subsystem data

through the operational data base and provide the capability to construct

displays and control sequences to monitor and control operations.

6.5.3 Facilities Management

l"his section presents the centralization aspect of our onboard distributed

system definition. The strawman system is primarily distributed as indicated

in the memory configuration summary in Section 6.3 and in Section 6.6.

However, a set of functions were collected together and defined as Facility

Management to basically provide centralized knowledge and control o# onboard

6-58
operations. In summary, the key operations performed by Facilities Management

(Tables 6.2-i16.8-i) are:

Checking of restricted commands generated onboard and from the ground

Onboard coordinated operations control

Centralized collection of key health and status data from subsystems

and any safety related data from the payloads

General diagnostic and systems test and evaluation

The Task I Functional Requirements Report and the above referenced tables

provide more details regarding these functions,

Restricted/constrained commands are those core and payload commands whose

execution scheduling is dependent on specific Space Station event and resource

conditions. Onboard generated commands are checked onboard. Ground supplied

restricted commands may be pre-checked on the ground, but the final execution

decision is made onboard. Command and resource management is addressed in

Section 4.0 of this Task Report.

Facility Management coordinated operations control and system monitoring is

raised to a summary level for crew casual monitoring. The FM caution and

warning system will alert the crew to significant problems and indicate the

problem area. At this point, the crew can bring up system and subsystem

displays for more information. FM also provides diagnostic and system test

support. The operators can request more detailed data, request data For

trends, etE.

FM displays are ideal for the Operations Center presented in the Reference

Configuration which ha_ large display equipment. However, each workstation

will provide caution and warning alerts, so that the crew can access the

nearest unit.

6-59
6.5.4 Telemetry and Commands

lhe onboard SSDS interfaces to other SSPE's through the communication

gateway. This gateway handles the return and forward SSA and KSA links to

IDRS$ as well as other communication links. The SSDS interface to the

communication subsystem for utilization of some portion of the TDRS$ KSA and

SSA links is the subject of this section. Other links are discussed elsewhere

(i.e., links to co-orbiting platform, free-flyers .... ).

6.5.4.1 Core Realtime Return Link

Data are collected from subsystems by data acquisition and assembled into

telemetry packets and packet segments. Telemetry packets and return link

telecommand packets are interspersed. The telemetry packet and telecommand

packets are organized into telemetry buffer units (TBU's). TBU's are

constructed using a prioritization algorithm. Telecommand packets are

inserted with high priority. TBU's are transmitted on a local bus to a set of

toggle buffers at the communication SSA return link interface depicted in

Figure 6.5-1. The TDRSS SSA return link is used for this data, although it

may be redundantly transmitted on the KSA return link.

6.5.4.2 Core Buffered Return Link

The process of storing and merging buffered data into the return link is

depicted in Figure 6.5-2. The data acquisition function is informed by the

communication subsystem when data must be buFFered because of communication

link dropout (zone of exclusion or reconfiguration). The buffered data is

stored on mass memory in the TBU format. When the communication link is

reestablished the SSDS'data acquisition function is informed by

communications. The location of the buffered data is then transmitted to the

communications subsystem. The real time data transmission to the

communications interface start again and the communications subsystem merges

the buffered l'BU's and the realtime data on the TDRS$ SSA return link.

6-60
I

::.:::

!

Subsystems

eee

Core Network

DMS Cont (Data Acq,

Trc)C°reODB, _

i- -I

I

I

R-SSA I

(3 Mbps) I

I

I

I

L_ .J

PL/EXP

:PL Network

I

R oKSA I

(300 Mbps) I

Cont k_j

Communications Subsystem

NIU

DMS

(Data Acq,

PL ODB,

TTC)

SW

Cont

Figure 6.5 -1. Return Link for Core Realtime Data

6-61
Core

DMS

(DataAcq, CoreODB,

"R'C)

r

R -SSA

(3 Mbps)

/ __1

Note 1.

• DMS Buffers Data

• DMS Informs Comm Subsystem of

Data Location

• Comm Merges Buffered and Realtime

Data By Fetching TBU's From MM

PL/EXP

fI

I

I

I

I

I

I

I

I

L.

;PL Network

I

R-KSA I

(300 Mbps) I

T '

sw I

Cont L.

Communications Subsystem

NIU

DMS

(Data Acq,

PL ODB,

TTC)

SW

Cont

Figure 6.5-2. Return Link for Core Buffered Data

6-62
6.5.4.3 P_load Real Time Low Data Rate Return Link (Figure 6.5-3)

Payload low data rate (defined currently as less than IO Mbps) is collected by

the SSDS data acquisition function in the P/L local area network (PLAN). The

data is received from the P/L's in CCSDS telemetry packet format. Data

acquisition builds TBU's by segmenting long TLM packets and handles priority

access to the telemetry stream. Telecommands are given priority over data.

The TBU's are transmitted on a parallel local bus to the communication

subsystem toggle buffers. These TBU's use the KSA return link,

6.5.4.4 Payload Buffered Low Rate Data Return Link (Figure 6.5-4)

During telemetry link dropout payload low data rate is buffered in mass

storage on the PLAN. The buffered data is then merged with realtime data when

the KSA link is re-established. The merge is accomplished by the

communication subsystem.

6.5.4.5 Payload Realtime High Data Rate Return Link (Figure 6.5-5)

The P/L high data rate interface to the SSDS is through a point-to-point link

with the communication subsystem. The communication subsystem merges high

rate data with low data rate TBU's on the KSA link. This data is in packet

telemetry format or it is assigned to a virtual channel by the communications

subsystem.

6.5.4.6 Pgyload Buffered High Data Rate Return Link (Figure 6.5-6)

During communication link dropout the communication subsystem buffers high

rate data on communication subsystem mass storage. The communication

subsystem merges this data with real time data when the link is reestablished.

6.5.4.7 Core Forward Link Telecommands (Figure 6.5-7)

Forward link telecommands and data are merged in the TDRSS SSA channel. The

DMS telecommand interface function (TLMCMD I/F) polls the SSA communications

forward link buffer on a paral].el local bus, The buffer contents are exami.ned

B-63
Subsystems

ee$

Core Network

NIU

DMS

(Data Acq,

Core ODB,

11"C)

I

I

I R-SSA

(3 Mbps)

I

I

I

L _j

PL/EXP

PL Network

I

R-KSA |

(300 Mbps) I

C°ntLlC°omcml 1

_j

Communications Subsystem

DMS

(Data Acq,

PL ODB,

TTC)

SW

Cont

Figure 6.5-3. Return Link for PL Realtime Low Data Rate

6-64
Subsystems

eee

Core Network

DMS Cont (Data Acq,

TTc)C°reODB,

r"

I

I

I

I

I

I

I

R-SSA

(3 Mbps) PL/EXP

PL Network

Communications Subsystem

NIU

DMS

(Data Acq,

PL ODB,

TTC)

SW

Cont

Figure 6.5-4. Return Link for PL Buffered Low Data Rate

6-65
NIU q

DMS

(Data Acq,

Core ODB,

TTC)

R-SSA

(3 Mbps) PL/EXP

[PL Network

I I

I R-KSA I

J (300 Mbps) I

T '

I sw I

J Contl

I

/

Communications Subsystem

NIU

DMS

(Data Acq,

PL ODB,

TTC)

SW

Cont

Figure 6.5 -5. Return Link for PL Realtime High Data Rate

6-66
Subsystems

Core Network:

PL/EXP

fI

1

I

I

I

I

I

I

I

L

PL Network

R-KSA I

(300 Mbps) I

7 _wi_L,

I

Communications Subsystem

NIU

DMS

(Data Acq,

PL ODB,

TTC)

SW

Cont

Figure 6.5-6. Return Link for PL Buffered High Data Rate

6-67
Subsystems

Core Network

Communications Subsystem

Figure 6.5-7. Forward Link for Core Telecommands

and disassembled by TLMCMD I/F. If the buffer contains data segments, those

data segments are delivered directly to the destination mailbox. (As an

example, a segment of a new program load would be delivered to the ODBMS For

storage on mass memory and then transferred to the targetted SDP).

The KSA forward link is used as a backup in the event of SSA forward link

interruption. This interface is also used for growth in the forward link.

6.5.4.8 Payload Telecommands (Figure 6.5-8)

Payload telecommands are delivered through the KSA forward link channel. The

same delivery service is provided by the TLMCMD I/F function. The commands

are delivered to the P/L mailboxes across the core to P/L network bridge.

6.5.5 Examples of Onboard Data Flow

The following sections describe selected examples to illustrate typical

onboard SSDS data flow implications.

6-68
• • •

Subsystems

Core Network

DMS

(TLMCMD r-"

I/F) I Back-_

i (Gro_._) (300 Kbps)

I

I

I

(25 Mbps) !

I

I

I

J

Communications Subsystem

Figure 6.5-8. Forward Link for PL Telecommand$

PL/EXP

6.5.5.1 Payload without an Integrated SOP.

In this example the payload is developed as a separate unit to be eventually

integrated into the SS with a standard subsystem data processor (SOP). The

scenario developed herein is For the case of a very low data rate experiment

(under lO Kbps), one relatively simple so that requirements For onboard crew

resources (after installation) would not be required For interactive control

or maintenance operations. The payload is a university developed experiment

and the interfaces selected are based on minimal use oF SSDS resources (i.e.

graduate students would be available to develop the payload, its interfaces

and Facilities to support its operation).

In this case, the customer's payload operation Facility is on campus and his

interface with the SSDS will be via CCSDS TM/TC packets. SDP application

programs that control his payload, and certain ground Facilities will also be

required.

6-69
After examining the standard SSDS onboard SDP I/O interfaces available, this

customer has elected to use a serial, EIA RS422, synchronous I/F since this

requires the least hardware and easily satisfies his data rate. He has

analyzed the control and data flow involved and has concluded that a personal

computer (PC) will satisfy his Control Center workstation and quick look data

processing requirements and that a mainframe-to-PC interface will satisfy his

production data processing and archive requirements.

Based on the above and on discussions with the SS program office, his

perspective of his interface with the SSDS and with his payload will be as

shown in Figure 6.5-g.

He will have electronic interfaces with his payload via TM/TC packets, with

the OMCC For schedule development and operations, and with the EDC (if

required) For acquiring additional ancillary data beyond that obtained onboard

at the time of original payload operations. Voice interfaces with the OMCC

and for conferencing with the SS crew are also provided.

I CUSTOMER CONTROL

CENTER -- Univ of

Utah, Dept. of Elect.

Eng. Salt Lake City,

Utah

I

Cusomer I

SSDS View From I Payload and I/F

Customers

Perspective I I"_ 25 Meters'_l_ I-_Pwr

 pSM

cx_) I

Winchester I

I

I

' I

I

I

I Customer J

_-- Supplied . m__

HW/SW w I -

I

TC Packets

TM Packets

ASCII

r

Audio

Customer.

Supplied

SDP S/W

NIU/

SDP

I Commands 2 I J), v

_. IOata ,,21

_"J t i

I c,ock , 'fl l

I RS422 I/Fs ,.Q

OMCC/EDC I

• Schedules I I

• OperationsJ I

SS

Audio I I

ConferencingI I

I

I

Customer

Supplied

Payload

and I/F

Harness

Payload

I/O

TCS

Figure 6.5-9. Payload Operations - Customer Perspective(Example)

I

I

I

I

I

6-70
The payload will be approximately 25 meters from the NIU/SDP node and will be

connected using three shielded twisted wire-pairs. Power and TCS interfaces

will also be supplied as shown.

The protocols that the customer will be involved with are those shown in

Figure 6.5-10. The CCSDS protocols For TM and TC are discussed in depth in

Section 4 and are only summarized in the figure (note that a specific

Application Process ID number has been assigned). The RS 422 interface is

serial with 8 bit characters (octets) and the customer will develop his own

data Field assignments for command and data (see examples). His other

e].ectronic interfaces with the EDC and OMCC will use a standard ASCII,

asynchronous protocols, a 300-2400 Baud modem, and a dial-up telephone.

CCSDS I

f Options

/

• Ancillary data /

• CCSDS time format

• Flags for data type

• Sensor/eng data

• Performance/

other data 0

Univ of Utah CC

ID = 59310

I I U II t

N_MIIIIIMIIIIIII_I_III I O_ I

IO bonlel I I _ I lel

lel I ,.,I I I I I._

I It I I

I'lgSl" I • !"

• Commands/Telemetry

• Encode/encrypt

• Compress

• Open/closed protocol

O

L,_--_-,

I mwe,l I

• I

I

!

!

i-" _ ,_-1.._ I ! llI IIl I ' 0 _II 0

L

IL. _ ,L IBM I

PC-XT _, TM Packets

I Main I

I Frame I

I Archive I Winchester

I Standard I

ASCII Text, Asynchronous

Start-Stop. 300-2400 Baud

NIU/

SDP

•so I

• Schedules

• Operations

Command

Data

Clock

Customer Defined

• Asynchronous

• EIA RS422 I/Fs

• 8-bit data fields

100008 100008

Command Data

/

/ i ,IF

/2

v

/ k I

Power

Payload

I I/O

TCS

Figure 6.5-10. Protocols in Payload Operations

6-71
The r e__al physical communication network that the customer does not see

(trar_sparent) is illustrated in Figure 6.5--11. In this example, his link with

the Data Handling Center (DHC) at White Sands will be via public

circuit-switched and packet-switched networks, as shown. His TM/TC packets

are transmitted through space and routed at the DHC and the onboard C&l node

as was described previously in Section 4. Onboard, ISO layers 2 and 3 provide

routing irlformation for transport to the final destination NIU and the upper

ISO layers in the SDP recover the TM/TC packets resulting in the peer-to-peer

IM/TC communications shown in the figure. On the return link the customer

data is separated from other downlink data at the DHC and routed to his

control center where all of his data processing is done. Packets may not

arrive in the correct sequence, but can be readily reordered using packet

headers.

To implement the operations described above, the customer will supply the

control center, the onboard payload and interface harness, and in addition, he

will reserve and provide the onboard resources shown in Figure 6.5-12.

Engineering or ancillary data will be provided through a real time interface

with the core DMS or retrieved from the EDC as required.

CUSTOMER OPERATIONS

A scenario for customer operation will now be described for this customer and

his payload and using the protocols described, and the interfaces shown in

Figure 6.5-9 thru -12. In this case the customer is requesting a session

which is not currently scheduled (his payload is currently powered OFF)

because a scientific event-of-opportunity has just presented itself that he

would like to capture via his payload sensor. This scenario will involve _0._

t

electronic data exchanges with the SSIS/SSDS, no voice exchanges will be

required (since no anomolies occur). Additionally, the customer is providing

his own data link to the DHC which is no__ttimplemented with the full seven

layer ISO model. It includes a two-layer interface through the circuit

switched network (to the TYMNET PaD) and a three-layer interface through

TYMNET's public packet switched network (i.e., he is not willing to pay the

cost for full ISO/OSI services). He is implementing a message passing service

at the Ap_.lication layer, he will not have Session services to recover data in

6-72
OF POOR

Univ of UtahL_ 2400-Baud H Public

Control Modem Circuit Switched

Center I - - J Full Duplex Network

Peer-to-Peer Processes

Public Packet

Switched Network

TYMNET J

Salt Lake

City

White

lRoute On

Layer 3

LAN k

Figure 6.5-11.

Layer 2

Destination

End-to-End Physical Communication Network

Route On

Layer 3

LAN I

User PackagePayl°ad I Standard Service [

I Interface

'' J

TCS Pwr

Mass Store J

• Customer Has Reserved

64 kbytes for Program

Store

• He Has Also Reserved

1 Mbyte for ZOE and

Other Communication

Outages

SDP

-- Standard Subsystem Data Processor (SDP)

- Standard I/O

LAN Medium

Customer Provides

Programs For

• TM Packet Build

-- Ancillary Data

ACQ and Merge

-- Payload Perf. Data

-- Time

• TC Packet Decode

• I/O Interface to

Payload

• Mode Control

• Test and Checkout

MPAC I

/

Customer Will Use Standard /

Display Services (ASCII Data J

Files) if Required. No Special

MPAC Software Requested

as Customer Anticipates

No Onboard Crew Participation

in Payload

Figure 6.5-12. Onboard Resources

6-73
the event of a disorderly disconnect to/from White Sands, and he will not have

end-to--er_derror protection (to/from White Sands) via Transp_Q.r.tlayer

services. I"o provide for a degree of error protection, his payload software

in the SDP that packages the payload data wi11 compute a module 216 check

sum and insert the result into the optional Packet Error Control field in the

CCSDS TM packet (see Figure 6.5-10). Highlights of this sequence are

presented in Table 6.5-1.

TABLE 6.5-I - CUSTOMER OPERATIONS

Negotiate For Non-Scheduled Services

•

.

.

The customer's PC autodials via public telephone to OMCC, prompt

appears on PC screen to LOG ON, provide ID, and then provide

PASSWORD. OMCC authenticates customer•

Service menu appears on screen to select option:

I. Display Schedule

2. Request Schedule

. ...

Customer selects option 2 and via keyboard display, menus,

prompts, HELP,...negotiates a schedule to start in six minutes

and to terminate after a 2.55 hour session. He is informed that

there will be a ZOE outage, but that his data will be stored in

an onboard file which he can request to be downllnked at his

convenience. (The file will be sequential, time stamped CCSDS

TM packets.)

4. Customer LOGS OFF from GSC

•

0

,

Payload Session Establishment

t

Customer has a TYMNET service to White Sands/DHC which he

assesses via local public circuit switched network. (NOTE:

TYMNET is a public packet switched network providing three layer

data delivery services and basically charging on a per packet

basis).

Prompt appears indicating that he is connected to White

Sands/DHC.

He now repeats LOG ON, ID, and PASSWORD sequence for DHC

authentication.

6-74
TABLE 6.5-I - CUSTOMER OPERATIONS (Continued)

. Menu options for services are displayed and the customer

responds that he wants his payload activated. He is informed

that his session is scheduled with no delays and will be

activated in 4.00 minutes, and to standby to initiate operations.

, A countdown clock is displayed and the payload activation

sequence is presented followed by a message that the network

manager has attached his payload to the network and he can now

communicate with his payload.

lO. The customer now initiates his local communication and control

program which generate TC packets for the following commands

that are transported to his payload.

o Bidirectional communication test

o Program load from onboard mass store

o Payload self test

o Sensor activation and TM packet delivery to CC

II. He will now go through the following sequence in his control

center:

o Quick look data with window for display of sensor

performance

data (engineering units and graphic displays).

o Initiate storage of production data on local disk store

o Monitors production data and performance data for

duration of

session

12. As his session nears its scheduled completion a window will

appear on his screen indicating that a message (TM packet) has

been received from the resource manager that he will be

disconnected in 3.00 minutes and that he should secure his

payload for an orderly shutdown. He does so via TC packet, LOGS

OFF from the DHC and disconnects from TYMNET and the local

telephone company.

13. Via his mainframe interface, he transmits the production data

files for processing and archlvlng on magnetic tape. Mainframe

processing provides him with his desired output in his selected

format.

6-75
6.5.5.2 Payload with an Integrated SOP

Onboard operations with an integrated SOP/payload showing data flow from the

payload to the C&T node were discussed in section 4.3.2 for a hypothetio_l

payload, COM XXXX.

In this example, the customer has a more sophisticated payload than in the

previous case and has developed his own package incorporating SSDS standard

circuits and his own unique I/O interface circuits. The payload is normally

powered OFF and the scenario described in Section 4 discussed the

initialization and session establishment sequence.

6.5.5.3 Onboard Inter-Subsystem Data Flow

A generic model (example) for inter-subsystem data flow is shown in Figure

6.5-13 in terms of an SSDS subsystem interface. In order to simplify the

intent of the discussion in this paragraph, the SSDS side is shown without any

replications for fault tolerance considerations.

On the SSDS side shown in the figure, three different configurations of an

NIU, I/O Controller and SDP are shown; in all cases the DOS is distributed

between the NIU (layers 1-4) and the I/O Controller or SOP (layers 5-7).

Implicitly, at least two configurations of the I/O Controller will exist and,

in fact, multiple versions will exist to facilitate the various backend

standard I/O interfaces described elsewhere in this document.

The equivalent of an ICD between the SSDS and the subsystem would be embodied

t

in the requirements thatspecify (in this example) a MIL-STD-1553B interface

for the physical and data link layers (equivalent to layers 1 and 2 in the OSI

model) and at the al)plication layer, the message configurations for the 32

word (16 bits/word) Control Frame and Data Frame. These frames would be

defined to specify the formats that receive sensor data values and those that

6-76
I

SSDS = | I Subsystem

I

DOS I

u

5-7 I

I/O I MIL'STD'1553i _ _=._.{

Controller I

DOS I

' I

5-7 1 .oo 16

Control

Frame

to Node i

1 .t. 16

L

DOS •

t J nlO + ••

NIU 5-7 Dala k = 32 Max 1-I+1 •

,i

!

_' SSDS ' I ' Subsystem

I

1-4

NIU

Node 1

Pwr

Supply

Controller _

Sensors, Effectors ....

Type 1

Sensors

Relays

and

Switches

Linear

Devices

Figure 6.5-13. Intersubsystem Data Flow

._J

I

I

I

I

J

transmit effector or output values. These formats would also be specified for"

various modes of operation in which the subsystem would be required to

operate. DiFferent modes (various operational, test, maintenance, etc.) would

require, in general, different measurement data sets and with various

measurement (update) frequencies.

t

6-77
CASE l: INTRA.--LAN

For this first case, (Figure 6.5-13) k nodes (k = 32 max) would be distributed

tlnroughout a region acquiring sensory data and responding to eFFector ouLput

commands. Each node, as shown, would include a controller and power supply

and various combinations of data acquisition and data output circuits (e.g.,

A/D converter, multiplexers, amplifiers of various types, signal conditioning,

etc.).

By way of review, MIL-STD-1553B is implemented with twisted shielded wire

pairs (TSWP), is transformer coupled at every node, and has a data

transmission rate of I Mbps. The logical link control (LLC) sublayer

specifies a polling procedure between a single master and multiple secondary

stations. Control frames are sent From the primary or master, and data frames

are received from the secondary nodes.

CASE 2: INTER-LAN

The case considered now is for a distributed subsystem, one where sensors and

eFFectors are distributed throughout a module and between modules. In the

example developed here, data acquisition ?rom these distributed sensors is

implemented as shown in Figure 6.5-14 using various standard I/O interfaces as

required by the application. Likewise, the effector values computed in the

SDP would be transmitted using the same I/0 capabilities.

The application program in this example is shown to be resident in only one

SDP, but with distributed data sources and sinks interconnected locally via

standard backend interfaces and throughout the SS via the LANs interconnected

by bridges. Interprocess message transfer via the LAN utilizes the layer 3

NOS services described earlier.

6-78
,_ _ UJ

0<_

(_.-0 _.-_

Oo _.__ .= "" nu_,_ 00 r"

___8

i ¢II C ii_'0

_n Ca

'_

.Un _" C

'a,, ._6_

O. a 0 ^

<_o_

_E

0

s.O

L,3

"0 _1

B

o

r.,

o _,

m

uJNV7

_n_,E

_,8E

1

I --I

u

I

I

|

I 1

_CL

_E

:30

_1_

6-79
6.60nboard SSDS Architecture

6.6.1 Distribution of Processing

The distribution of processing into the onboard SSDS is based on tr'aditiona].

subdivisions of spacecraft functions, Function sizing estimates, function

criticality and fault tolerance requirements, interfunction communication,

safe haven requirements, minimization of DMS elements, and the desire For

subsystem autonomy. The memory configurations and their respective

distribution are presented in Table 6.6-1. The total network that supports

this distribution is shown in Figure 6.6-1 and Figure 6.6-2. The PL/EXP and

core ?unctions are separated to insure the highest degree of traffic isolation

and, therefore, functional autonomy.

The architecture selected is based on derived requirements for growth,

functional subsystem autonomy, the build-up of functionality, and the

flexibility to select fault tolerant options.

The main features of the architecture are: (I) the ability of any SOP to

assume any memory configuration (one or more subsystems allocated to an _DP

memory load); (2) a single high-speed, DMA interface between the SDP and NZU;

(3) the incorporation of the standard, traditional I/O Functions between

computers and sensors and effectors into the NIU (which makes possible feature

I; (4) the workstation as a computing element with potentially the same power

as the SDP plus user interface capability so resources can be shared for"

infrequent interactive tasks.

Processor fault tolerance is accomplished by a system service function which

detects Failures and initiates fault down to preferred spares. NIU Failures

do not require memory reconfigurations since the programs are the same for any

triad group. Only port moding is required or reassignment by the network

manager (this reassignment accomplishes changes in routing which are then

static - no dynamic routing). For failure detection the SDP and NZU are

considered a node.

6-80
.-!

f

¢,_ ,.j .._ "I0

a-O 0

(.)O0

0

m_

EE

8E,,_

8

7

gg

m

Q

0

E E

Q.

>0 _0

EO °_ Q Q Q

0

i'==_

•t = _

Q _ O

_) c/) u3

E

-_-

m a.

_, == =

O_QQ_QQQQ

,-, m

_3 r_

_m

a. _.0

>,<U • •

0000

0 A

_m

_>.

6"81
(Mem. Config 3)

ECLSS

Crew Sys

Str & Mech

(Mem. Config 4)

DMS ODB

1C

11

12

HM1

Core

Work

Station HM1

Local Bus

19

20

21

Upper

Boom

Local Bus Local Bus

25

26

27

Lab 2

LIS

I

I rl

I. =! '

r !

LWj_j

Core

Work

Station

33

34

Lab 1

Network

(Mem. Config 1 )

Att Cont "1

NAV .J

[ou Traffic

Tracking

Cont 1

Local

Bus

4

(Mem. Config 2)

Pwr

Thermal

Comm I/F

DMS

4

5

(2) 6

Local Bus

Lower

Keel

Local Bus

(2)

Lower Keel

and Ext

(Mem. Config 5)

FAC

Mgmt

HM2

Local

Bus

7 11

, PL Network

r-1

/ I

I I Core

j Workstation

1

!

I

Local

Bus

(6) (2)

Transverse Boom

(3)

Transverse

Boom Ext

(6)

Upper Keel

Transverse

Boom

Transverse

Boom

Ext

(3) HM2 Logistics

Module

Figure 6.6-1. Processing Distribution for Core LAN

FGLDGUTFlUmE

6-82

(_- _Z_- FOLDOUT
?7"77

IIII

IIII

IIII

IIII

IIII

lllJ

I_.Ii

loft

////

////

////

////

////

////

///I

-[3-

I I.

_'/

7_.,/

C0

i5

eo_

e4

ig

6-83
The SDP sparing strategy is presented in Table 6.6-1. Spare computers within

a triad are preferred as backups for failures in the triad but safe haven

requirements make it necessary to be able to transfer memory configurations to

another physical module. This is the case for all the SDP's except those on

the transverse boom which only have spares within the local triad. These are

called preferred spares for the following reason: even though it is possible

to use a member of these triads for some other memory configuration for some

period of time, if several failures occur in this triad then the "visiting"

memory configuration is bumped to another SDP (or a degraded mode occurs

because no spares are available).

The triad in HMI operates in a "shared spare" mode. In other words the

preferred spare is the spare in the local triad but this is shared by the two

memory configurations (memory configurations 3 and 4) active in the HM1 triad

1. Additional spares are located in the HM2 triad 1. Safe haven requirements

are met in this sparing strategy. The HM2 triad 1 uses the local spares as

the preferred spares for memory configuration 5 but resorts to the HMI triad

for safe haven backup.

With this architecture it is possible to absorb growth by having a currently

inactive triad member become active and at the same time introduce a SDP into

a "spare pool" on the core network,

The preferred spare strategy used for the transverse boom triad 1 also results

in deterministic I/O timing, a requirement for the hard real-time furlct:i.ons

such as attitude control. Predictability in _I/O delays comes from the fact

that traffic to the local bus is on a string which is not shared with any

other Functions even if a "visiting" memory configuration is executing in this

triad (i.e., no traffic interference occurs in the NIU because traffic only

couples when reaching the core network).

The SDP memory configurations are described in Table 6.6-2. These memory

configurations are distributed into a total network of 16 SDP's. Six

workstations and 38 NZU's are also provided. The memory configuration for the

workstations is described in Table 6.6-3. The core and P/l_ network conl:ain 1.2

bridges. Each bridge has the same software which includes layers 1..-..4of DOS

(See section 6.4.2).

6-84
Table 6.6-2

SDP MEMORY CONFIGURATIONS (IOC)

MEMORY

CONFIG

CONTENT

NAV, A'IT CONT (FL'T 1-2)

GUID, TRAFFIC CONT',

TRACKING, OMV DEPLOY

PWR, THM, COMM IIF

ECLSS, CREW SYS,

STR & MECH

DMS ODB

FAC MGMT

PL PROCESSING

PL PROCESSING

PL ACCOM

PL COMM I/F

PL ODB

SIZE

(KBYTES)___

1038/307

1530/815

595/137

1280/38

1618/14

360/1

360/1

2626/30

RESIDENCE

PRIME FIRST

SDP BACKUP

1 2

4 5

7 9

8 9

i0 11

13 14

14 13

15 16

SEI(]OND

BACKUP

11

12

9

Table 6,6-3

WORKSTATION

MEMORY CONFIGURATIONS (IOC)

MEMORY CONF IG

I

9 I

I

I

I

I

I

I

CONTENT

DMS RECONF[G

SIZE (KBYIES)

(774/36)

I_ESIDENCE

)(" ALL WORKSI'AIIONS ARE CANDIDATE FARGET'S FOR I..OAD & BA(]KUI:)S

6-85
It should be noted that the term "memory configuration" mentioned above

implies an SDP memory load containing the application software for one or more

subsystems. The decision to combine subsystem application software into

memory configurations was motivated by the following considerations:

Desire to minimize the total number of SDP's and NIU's required.

This reduces program costs, power/cooling resource demands and

network complexity.

Group together subsystem application software with high data exchange

requirements.

Group together subsystem application software which must be relocated

to address safe haven requirement.

The ability of a subsystem contractor to design and checkout his subsystem

without significant interface to a central integration facility can still be

accomplished. A functional equivalent of the SDP/NIU and appropriate data bus

interface simulator can be used in a standalone test verification mode. With

a standard DOS the linkage of subsystem applications software within an S[)P

should be (largely) transparent.

6.6.1.1 Data Manaqement Subsystem (Figure 6.6-3)

The DMS "application" functions are resident in two SDP's; SDP4 and SDP8.

SDP4 is backed up by SDP5 and SDP6 in the transverse boom triad 1. SDPB is

backed up by SOP9 in HMI and SDP12 in HM2. SOP4 nominally contains memory

configuration 2 which performs the functions required to interface to the

communication subsystem for the return and forward SSA link. Time m_:,inagement

is also contained in memory configuration 2. The master timing units (MTU's)

used by SDP4 are attached to a local bus. When the GPS receivers are added _o

the upper boom, time management can use the time reference provided b.v GPS as

an addition reference source.

6-86
i I )u. ,,)---I

"r-"

I

!I

Ii

o0 I [

\\

\\

\N.

\\

\\/

\\

\\

\\

\\

\\

\\

\\

1IIIII E0

Q.

I

"0°10 II]

III

I1--

°°I

6-87
The DMS operational data base (ODB) is nominally resident in SDP8 (memory

configuration 4). The mass storage is distributed in HM1, 14M2 and I..AB2. The

DMS stores telemetry data on mass storage during return link dropout. After

the return link has been restored the DMS allows the communication subsystem

to retrieve this buffered data from mass storage for merging with realtime

data.

For illustration purposes; the DMS can be reconfigured as shown in Figure

6,6-3 using the work stations resident in HMI. This control location is

illustrated in many subsequent figures. However. any workstation can be

configured to control any subsystem. Other workstations locations are shown

in Figures 6.6-i and 6,6-2. Menu panels are presented at all active work

stations. These panels allow the work station to be configured by crew

selection. Programs are then loaded in the work station which supports

interaction with the crew for DMS status and reconfiguration.

6.6.1.2 Communication Subsystem (Figure 6.6--4)

The communication subsystem is resident in SOP4 (memory configuration 2) and

backed up by SDP5 and SDP6 in the transverse boom triad I. Telemetry for the

SSA return link is transmitted in packet telemetry format on a local bus to

the communication toggle buffers. Telecommands are also received on this

local bus by a polling process. The forward SSA link buffer is polled by

transferring the communication interface buffer to SDP4. Packet segments in

the forward link buffers are then disassembled and transported to the onboard

destination task.

Re(:onfiguration of the communication subsystem is through programs loaded into

any of the core workstations (similar to description in 6.6.1). This

reconfiguration process is highly automated with (mostly) optional crew

interaction.

6-88
l II

I.IIIII

L.

_m,mm_m_ m_

/

TwI

(J co u_ m v,- r'_

w,- t'_

T_

mm mmm qmm I I!I °0 ! I " 1

lil i L tmmm _

I

_mm

_1"5

m_,O O= i ,

"I"

]_IIIIIIIJ

_I-

4

-_I_

6-89
6.6.1.3 Attitude Control (Figure 6,6-5)

Attitude control is nominally resident in SDPI (memory configuration I) and

backed up by SDP2 and SOP3. All of these computers are in transverse bo_.)m

triad 1. Attitude determination is generally considered to be a navigation

function, but is embedded within attitude control for this description.

Communication with the CMG's, strap-down assemblies, star trackers and solarpanel activators is through a local bus on the transverse boom triad I. When

the solar panel extensions and magnetic torquers are added they also use the

same local bus for communication. The RCS is distributed along the lower keel

and lower keel extension. NIU7, NIU8 and NIUg located on the lower keel are

used to communicate from the transverse boom triad I to the RCS on a local bus.

The user interface to the attitude control function is via the core

workstation shared resources as described previously.

6.6,1.4 Trackinq Subsystem (Figure 6.6-6)

The tracking subsystem resides in memory configuration 1 which is nominally

assigned to SDPI and backed up by SDP2 and SDP3 on the transverse boom. The

•tracking function collects data From various transponders and radars

distributed on the upper boom and also proximity trackers on HM1 and HM2.

This data is conditioned and transmitted to navigation and traffic control

functions.

6,6.1.5 _.avigation (Figure 6.6--7)

The navigation function is contained in memory configuration 1 which is

resident in SDPI and has preferred backups in SDP2 and SDP3. lhe navigation

Function receives GPS data from instrumentation on the upper boom. I-DI_S

tracking data is also received from the TDRS S-band transponder on the

transverse boom (this Function may migrate to the upper boom). User interface

to the navigation function is through any of the core workstations a,s

described previously.

6-90
6-91
mmm

_mmm

I--_ I--_ I--:3--_

-I

RI_Jm_

7

II

m

7

IIIII

0

I10

°1O.

_1

z

iI,-

,1

6-92
6-93
6.6.1.6 Electrical Power Subsystem (Figure 6.6-8)

The electrical power subsystem is contained in memory configuration 2 and

resident in SDP4 with preferred spares SDP5 and SDP6. Electrical power

sensors and effectors are distributed on the truss and within the pressurized

modules. The local buses and associated NIU's are shown in Figure 6.6.--8. The

NIU's within HM2 also have a connector on the local bus for the logistics

module.

6.6.1.7 Thermal Control Subsystem (Figure 6.6-9)

The thermal control subsystem is contained in memory configuration 2 and

resides in SDP4 with preferred backups SDP5 and SDP6. Thermal control is

distributed on the truss and in the pressurized modules. This subsystem

shares local buses with the electrical power subsystem since these subsystems

are similarly distributed. The local bus on the NIU's in HM2 have a connector

to the logistics module in the event thermal control is required in this

module.

6,6.1.8 Environmental Control and Life Support Subsystem (Figure 6.6-10)

ECLSS is contained in memory configuration 3 and resides in SOP7 (HM1 triad i)

with a local preferred spare (SDP9) and safe haven spare SDPI1 in HM2 triad

I. The ECLSS sensors and effectors are distributed in the pressurized modul(_s

and share local buses with power and thermal subsystems. The preferred spare

in the HMI traid 1 is shared with memory configuration 4. Communication with

the logistics module can be on a local bus connected to the HM2 local bus.

6.6.1.9 Traffic Control (Figure 6.6-11)

The traffic control function is contained in memory configuration I and

resides in SDPI and is backed up by preferred spares SDP2 and SDP3, Traffic

control has no sensors or effectors but inputs from other subsystems and ser_ds

commands to those subsystems on the core network. User interfa('e is through

any of the core workstations.

6-94
Z ZZZZ'_

=o

6-95
_ z z

0

-r -r . _j

6-96
mmmmm m mm mmm_m mm 1

J Habitat Module 1 EC LSS

User I I/F

I

I

I

I

ECLSS

User

I/F

ECLSS

User

I/F

Habitat Module 1

Figure 6.6-10. Environmental Control and Life Support Subsystem

ECLSS

S&E

Module NIUA, B, C

HM1 NIU 13, 14, 15

HM2 NIU 16, 17, 18

Lab 1 NIU 31,32, 33

Lab 2 NIU 25, 26, 27

HM2 Contains Connector

to Logistics Module

6-97
r !

I

I

I

I

I

I

I

I

I

Traffic

Control

/ m m Habitat Module 1

Core Network

L

I

I

I

• I

I

I I

L Transverse Boom J

• Backup

m

I

I

I

I

I

I

I

I

L-;---

/

Traff Cont I

User

I/F l

Traff Cont I

_User !

I/F

Tr..ContI

User

I/F I

__ ._ ._.]

Comm

I/F

---3

I

I

I

Habitat I

I

I

I

=ram m _J

Figure 6.6-11. Traffic Control

Airlock 2 Comm

Prox I/F

Ops

I

I

I Habitat Module 2 1

I

I

6-98
6.6.1.10 Facility Management Subsystem (Figure 6.6-12)

The facility management subsystem is contained in memory configuration 4 and

resides in SDP8 with preferred backup SDP9 and safe haven backup in SDP12 (HM2

triad I). Facility management has no sensors or effectors but receives inputs

from other subsystems and sends commands to those subsystems on the core

network. User interface is through any of the core workstations.

6.6.1.11 Structures and Mechanisms Subsystem (Figure 6.6--13)

The structures and mechanisms subsystem is contained in memory configuration 3

and resides in SDP7 of HMI triad i. The preferred backup spare is SDPg and

the safe haven backup is SDPI1 in HM2 triad I. This subsystem has alignment

and mode sensors distributed on the truss and modules.

Habitat Module 1

i

Fac Mgmt J

User

I/F J

Fac Mgmt I

User

I/F J

Fac Mgmt J

User

I/F J

I

I

I

I

I

I

I

Fac

I Mgmt

J Habitat Module 1

Figure 6.6-12. Facility Management Subsystem

I

I

I

I

I

I

I

I

I

iI

*Backup

6-99
:3

_ :3 :3 :3

ZZZZZ

U'J

IiII Ills .-i.

IIIIIIIII

-!

6-100

1

IIII

IU

r4

CD
Interface to the airlock modules is across local bus connectors From the HMI

and HM2 modules. The control of the MRMS is through telecommands transmitted

to the communications system interface. User interface is through any of the

core workstations. Manual control of the MRMS is through the fixed

workstation which is configured for MRMS manual inputs.

6,6,1,12 Crew Systems/Subsystems (Figure 6.6-14)

The crew systems subsystem is contained in memory configuration 3 and resides

in SDP7 of HM1 triad I. The preferred backup is SDP9 (also in HMI triad 1)

and safe haven backup SDPII in HM2 triad 1. Crew system sensors and effectors

are distributed in HM1 and HM2, User interface is through any of the core

workstations.

6,6,1,13 Payload Support (Figure 6.6-15)

The PL support for return link telemetry and data base services are contained

in memory configuration 8 which is resident in SDP15 (LAB2) with backup SDP16

(LAB1). SDP15 interfaces with PL mass storage devices and the communication

interface to provide the return link telemetry service, Buffering is

accomplished on the PL mass storage, Forward link PL services originate in

the core network in SDP4 (memory configuration 2). The telecommand interface

service delivers telecommands to destination tasks in the PL. network across a

bridge.

PL programs can be uploaded to the mass storage devices and execution

initiated in SDPI3 and 14 in LAB2 and SDPI6 in LAB1. A PL workstation is also

provided in LAB1, Communication with earth viewing experiments is

accomplished using NIU 36, 37, 38 on the earth viewing pallet. Communication

with upper boom experiments is through NIU 22, 23, 24. Experiments internal

to the lab module3 communicate using NIU 28, 29, 30, 31 and 32.

Ancillary data carl be obtained by communicating with the core operational data

base across the bridge.

6-101
L L ....,..-.' _m

v._',

I @ :'"

0:3

..J_

m

_J

i

i

I

I

!

I

1

'1

I

!

I

!

°m

6-102
_/ m iu

0 "I

E

0

0

(D

O.

O.

o

I

I

I

I

I

6-103

[

[

J_
6.6.2 Network Architecture

6.6.2. I Topology

?

The "strawman" onboard local area network configuration consists of two major

network partitions isolating PL/EXP traffic from core traffic. There is a

bridge between the network partitions to support core and PL/EXP data

exchange. Ancillary data and forward link telemetry flow from the core

network to the PL/EXP network across the bridge. The topology of the network

is a group of interconnected dual redundant token rings each with a multi-port

ring concentrator. The physical distribution of the network elements is shown

in Figure 6.6-16. The network topology is shown in Figure 6.6-17 a and b.

Dual redundancy exists in the bridges, ring concentrators and optic-to-optic

connectors.

6.6.2.2 Access Protocol

A separate token circulates in each ring. A bypass capability is provided at

the ring concentrator for inactive or failed ports. Port moding a11ows

individual ring ports to switch between the two redundant rings.

The network access is through a priority token circulating within each ring.

The message priority is assigned to periodic traffic on a rate monotonic basis

(higher rate has higher priority). Aperiodic traffic has lowest priority.

6.6.2.3 Network Operating System (NOS)

The NOS supports the interface to the network for object oriented task-to-task

message passing. It is a subset of the overall onboard Distributed Opera t:in(_j

System (DOS) described in section 6.4.4 and consists of the functions

corresponding to layers 1 through 4 of the ISO/OSI model. The NOS resides in

the NIU's. A brief summary of the applicable functions in these layers is

shown below in tabular form.

6-104
Lab 1

C7

I --I I

I I

I I

I

I C1 I

I

I I c2 I

I

I I I I

I I I

I I I

I i

I

l I

I.., I

c8 L_ ......... _1

Transverse Bo

Legend

N -- NIU

B -- Bridge (Dual Re( Jant)

RC-- Ring Concentrator (Dual Redundant)

C -- Fiber-Fiber Conr :tor

I_-- Local Bus Wire Connector

I

I

I

I

!_

Logistics

Module

Local Bus

RC4

HM1 HM2

OQO

Figure 6.6-16. Network Physical Distribution

6-105
Transverse Boom

C7

N20 N21

N19 RC5 Upper Boom

B5 B6

N6

N4 1

N1

Lower Keel

N7

B1

RC2

B2

J

N22 N23 N24

RC6

B7 _ B8

I

I

I

C31 _, C4

r"

t C6

N28

l

N29

B13

Lab 2

N33

N34

N35

N36 N37 N38

N12

Earth-Viewing Pallet

Figure 6.6-17A. Network Topology Backbone

I

I

_f

v

IB3

_1 B9

N13 N14

JE'f

B10

N16 N17

HM2

N18

6-106
N5 A

N4 A

N3

N2 A

N7

Figure 6.6-17b.

To B5A, B5B. B6A. B6 B

N6 B

B1 B2

N8 A N8 B

To C1A. C1B. C2A, C2 B

Backbone Redundancy Example

To C5A, C5B, C6A. C6 B

6-107
I , PHYSICAL LAYER

- Handles voltages and electrical pulses

- Handles cables, connectors, and components (interfaces to media)

- Handles collision detection for CSMA/CD access method

, DATA-LINK LAYER

- Reliable transfer of data across a single link

- Adds flags to indicate beginnings and ends of messages

- Adds error-checking algorithms (CRC., ...)

- Makes sure data are not mistaken for flags (transparency mechanism)

- Provides access methods for local-area networks

3. NETWORK LAYER

- Sets up routes for packets to travel

- Addresses network modes on the route through which the packets travel

- May disassemble transport messages into packets and reassemble them

at the d_stination.

- Sends control messages to peer layers about own status

- Congestion control (regulates flooding within the network)

- Recognizes message priorities and sends messages in proper order

- Internetworking (both connection-oriented and connectionless)

4° TRANSPORT LAYER

- Reliable end-to-end data transfer (connection service)

- Multiplex end-user addresses onto network

- End-to-end error detection and recovery

- Flow control

- Monitoring quality of service

- Possibly disassemblies and reassembles session messages

6-108
6.6.3 Major Qrchitecture Issue

One major feature of the presented strawman architecture needs special

discussion. In the strawman architecture it is possible to communicate with

any NIU local bus from any SDP on the network. The reference configuration

does not allow access to all the local buses from any SDP. Some SDP's h_ve

dedicated local buses that are controlled by that SDP. The flow of

communication in the strawman architecture is shown in Figure 6.6-1Ba and the

reference configuration is shown in Figure 6,6-18b.

In both the strawman architecture and reference configuration architecture the

interface between NIU and SDP is similar. Both architectures also have an

interface to local buses through ports on the back-end of the NIU. This is

for sensor and effector (S&E) communication.The I/O programs to accomplish

this S&E I/O must reside in the NIU and these programs are unique to Lhe

configuration of the back-end S&E configuration.

The key differences in the architectures are in the way local buses are

communicated with when the NIU and SDP are co-located. The ref. config.

allows For a sensor and effector (S&E) interface to the SDP. This means that

only this class of SDP can be used to perform the functions associated with

the S&E attached to the SDP local buses. No other SDP's can backup this

function in case of failure because communication is through the failed SDP.

The spare SDP's with S&E interface back-ends still could be used For other

functions only requiring communication via the network.

The strawman architecture has no S&E interface to the SDP. The strawman

architecture has a configuration with both an SDP and local bus on the same

NIU back-end to accomplish a measure of commonality For SDP's.

In Figure 6.6-1Ba, the configuration with an SDP and local bus on the NIU

back-end is shown. If the co-located SDP's request data from the local _,)_s,

the communication must be through the NIU. The SDP does not know if the S&E's

are co-located or remotely distributed on some other NIU back-end. The local

NIIU knows that the S&E Z/O programs being addressed by the SDP are co-located

and does not use the layered protocol (i.e., network communication) but ju,,_t

6-109
r- - ... ..:::.. 1 ..;.. ii

I "::':':':':" I ..::iii!ii!!_::l

1 "-'-'.'." I :i:i:i:! 1

N,U I _ I ..:::.. ii!i!iiil _' ":':':':'.- ,,,,u i:i:i:i:;I _,

I .':?iiiiiiii!::'. ...... ..::iiiii_iii: I 3 "::_:i:i:i::.. •.:::::::; I :':':':': .... .... 3

•°°,°°,,%° * o,..... ,.%o, I I :!ii_iiiii iiiiii!iii I :::::::::I :':':':': I 4

, ,,,,,,,,,, ::::::::::, --

L j !iiiiiii3 :::::::::: .:.:.:.:....ii!!iiiii...I: I

- - ......... !iiiiiiiii !iiii!iii'::i_!i;::- I

!iiiiiii! ,:::ii!_ii_!;.- .iiiii!iiii.!

:i:i:i:i: +" I ':::=:: I *iiiii_!::iI j

F _ III ::::::::: ":'"

I

Layer I iiiii!i! II I

,,oPrograms,

I

i

I

Programs ',o

6 I sopI I L_ _J

I 7 I I I

I I I I

L J t ._.J

Figure 6.6-18a. NIU Alternative 1 (Recommended Architecture)

r/////////////.

I

I L

NlU I

I

I

V////////////////////X _;_. Lwor _"//////////////////////////////////////_

er

::::::

,,-°..,

:.:.:.:

iiiiii!

"::_iii::"

r-t •.:::;. I

:: iiiiii: ! rI

Layer iiiii I Layer 1 1 I 2 I 2 NIU

iiiiiiii a I

3 .-. I 4

4 iiiiiiii I I

.-.-,,,,

I i.ii_i_i

""°°°' F _

l ] ....

I I/O ::::::::

I Programs "':::i:i:i:i:::'" iii:_i_i I Layer

L_ li_i_ 6 J I SDP

"'_::" I I !

I 7

Backend Local Bus ! I

Layer 1, 2

Layer 1, 2

I

NIU I

I

I

I • m_

I t

SD,:'I L_er I

I I

I I

I I

L J

Figure 6.6-18b. NIU Alternative 2 (Ref Configuration)

6-110
triggers the local I/0 programs directly. This architecture allows any $DP in

the network to assume any Function, a powerful option when dealing with Fault

tolerant strategies.

The hardware to accomplish either architecture is presented in Figure 6.6-19

and Figure 6.6-20. The reference configuration requires an S&E interface For

the SDP's with local buses which is equivalent to the MUX/DEMUX function on

the back-end of the NIU in the strawman architecture. Both architectures

support options for the back-end of the NIU's. The selection of the str'awmar}

architecture can have multiple options resident in the same NIU but the

reference configuration always has a single back-end port.

Table 6.6-4 summarizes the comparison of the two architectures. The strawman

architecture is a distributed system which minimizes hardware by allowing for

full distribution of functions while sacrificing little in Functional

autonomy. Autonomy will be functional instead of physical. The table

hardware count and software size is expected to be similar in either

architecture which leads to the recommendation.

6.7 Buildup

The buildup of the onboard SSDS is partitioned into 7 segments that are

integrated into the 7 launch packages. Each segment is ground tested after

integration with the launch package. The DMS launch segments are then placed

in an unpowered state For launch. The SDP and NIU programs for Flight 1 E_nd 2

are stored on non-volatile memory resident within the SDP and NIU. -I'he

buildup of capabilities and onboard SSDS elements on a flight basis is

presented in Table 6.7-1.

For the buildup sequence discussed in the following subsections reference back

to Figures 6.6-I and 6.6-2 will be required to identify the physical locations

of the onboard SSDS elements discussed.

6-111
Fiber Bus

NIU

Port

Controller

Memory

Controller

*Multiple Backend Ports.

Combinations Selectable

From DMA to SDP,

Local Bus

SDP

I-Bus

Figure 6.6-19. NIU/SDP Configuration For Recommended Architecture

Fiber Bus

Port

Controller

Memory

Controller

*Single Interface

Selectable From

DMA to SDP.

Local Bus

I Backend

Port

Controller

I-Bus

.*

Figure 6.6-20,

NIU

**Single

Interface

to Local

Bus

p

I-Bus

SDP

I r Backend I **

Port

Controller

NIU/SDP Configuration For Ref Configuration Architecture

I

._1

6-112
l'able 6.6-4

Architecture Comparisons

COMPONENTS &

FEATURES REFERENCE CONFIGURATION STRAWMAN ARCHITECTURE

SOP Hardware More (needs IOP) Less (doesn't need IOP)

NIU Hardware Less in any one unit

but same back-end options

More in any one unit but

same back-end options

SDP Software More complex (I/O Programs) Less complex (no I/O programs)

NIU Software Simpler More complex (I/0 programs,

NOS bypass to local buses

Fault Tolerance

Options

Less depth in sparing (could

use same system S/W failure

detection)

More depth in sparing (uses

system S/W failure detection)

Subsystem Autonomy Physical Functional

Total Hardware More (dedicated hardware) Less (combine functions)

The MRMS is activated and checked out for subsequent use in constructing the

Space Station. An operational scenario requires the MRMS software to be

located in an SDP or MPAC located in the orbiter with a hand controller. An

RF link from the orbiter to the MRMS antenna provides the media for video and

crew commands. The MRMS contains the electronics and mechanisms for arm

movement. The software can be recovered for subsequent migration to HM1 Triad

l with backup in SDPI1. The HM2 operations center will be the primary MRMS

control station with a back up in HMI.

6.7.1 1___ht F 1

On flight I the transverse boom is delivered to Space and deployed, lhe

flight 1 onboard SSDS configuration consists of 6 SDP's 6 NIU's, 3 master

6-113
TABLE 6.7-1

BUII_D-UP

I

I FLIGHT

I NUMBER

2

4

5

6

7

DMS

ELEMENTS

DELIVERED

SDP 1,2,3,4,5,6

NIU 1,2,3,4,5,6

RC1

MTUI,2,3

NIU 7,8,9

RC 2

B 1

SDP 7,8,9

WS 1,2,3

NIU 10,11,12,13

14,15

RC3

82

MMU 1

SDP 10,11,12

NIU 16,17,18,19

20,21,22,23,24

NONE

ADDED FUNCTIONAL

SUPPORT

ATT CONT

NAV

CON I/F

THM 'TRANSVERSE

PWR BOOM

RADIATOR CONT

ECLSS HM1

PWR

THM

ODB

PROX OPS

CREW SYS AIRLOCKS

MECH

GUID "TRAFFIC CONT

TRACKING OMV DEPLOY

RCS LOWER

ISSUES

ACTIVATION

MASS MEMORY

DMS BUS INTEGRATION ON TRUSS

MRMS CHECKOUT

COMM INTERFACE

MRMS CONTROL

INTEGRATION OF" PL NETWORK ON

TRUSS

AIRLOCK INTERFACE

WORK STN. NIU/LOCAL BUS PORT'S

CORM I/F TO MASS MEMORY

WORK STN BUILD-UP (NEED 3)

ASSEMBLY OF FIBER-TO-FIBER

CONNECTORS

LOCAL BUS TO RCS AND NAG

MMU 2

iMAG TORQUER

PWR

THM HM2

ECLSS

PWR, THM, GPS

KEEL

UPPER

BOOM

TORQUERS

DIRECT GP_ INTERFACE

COMM I/F CHANGE FOR UPPER

BOOM ADDIT'ION

SDP 13,14,15

NIU 25,26,27,28

29,30,31

RC 7,8

B 6,7

WS 4,5

MMU 4,5

SOP 16

NIU 32,33,34,35

36,37,38

B 8,9,10, 11,12

MMU 3

PWR,THM LOGISTICS

ECLSS TRANSVERSE

SOLAR BOOM

ACT EXT

PWR

THM

ECLSS

' -IPL PROC

PL UPPER BO()M DATA

INTERFACE

AL POINTING

PWR

THM LAB 2

ECLSS

PL EARTH VIEWING

PALLET INTERFACE

t.OGIST'ICS MODULE INTERFACE

EARTH VIEWING PALI_EF

RE@UIREMENTS

6-114
timing units (MIUI,2,3)and a ring concentrator (RCI). This initial portion

of the onboard SSDS is physically located on the Attitude Control Assembly

(ACA). Subsystem functions supported are attitude determination, attitude

control and semi-autonomous navigation (ground update).

The flight 1 onboard SSDS has attitude control and navigation resident in one

SDP of a triad with 2 preferred spares. The other triad has electrical power,

thermal control and the communication interface programs for telemetry.

6.7.2 F!i_ht 2

On flight 2 the lower keel and lower keel extensions are attached. The

onboard SSOS elements on this package are 3 NIU's, a ring concentrator (RC2)

and a bridge (B1) to connect RCI and RC2. The added NIU's are on the lower

keel extension and provide communication to the radiator controls (and

eventually the RCS). This NIU's also support lower keel electrical power and

thermal control. Control of the MRMS is through telecommands originating in

the DMS and sent through RF communication channel.

6.7.3 [light 3

On flight 3 the first habitat module (HM1) and the airlocks (ALl, AL2) are

delivered and attached. The onboard SSDS elements in this package are 3

SDP's, 3 work stations, (WS's), 6 NIU's, a mass storage unit (MMU6), a ring

concentrator (RC3) and a bridge (B2). This configuration supports the ECI_SS

subsystem and extensions to electrical power and thermal control. The

operational data base can now use the external mass storage unit (previously

it was using local memory). The crew systems and mechanisms associated with

the airlocks are now supported, as well as any proximity tracking for

approaching the airlocks. The core network optical fibers are connected

across the HMI bulkhead to the internal bridge (B2) which connects to RC3.

_ork Stations for crew interface are available at multiple stations,

6-115
6.7.4 F1___ht 4

On flight 4 the upper boom is assembled and habitat module 2 (HM2) is

attached. The onboard SSDS elements in this package are divided into the

upper boom package and HM2 package. In the upper boom package there are 6

NIU's (3 core network and 3 PL network), 2 bridges (Bd, B5) and 2 ring

concentrators (RC5, RC6). The core network elements on the upper boom support

remote electrical power and thermal control as well as communication to the

GPS and antennaes. The other elements are put in place for PL support once

the PL network is completed (flight 6).

The habitat module 2 had 3 SDP's, 3 NIU's, a bridge (B3) and ring concentrator

(RCd). These SDP's have the facility management memory configuration. The

NIU's support remote sensing and control by ECLSS, electrical power and

thermal control. R local bus connector is also on these NIU's for the

logistics module. The core network is extended by bringing the optical fiber

into HM2 and connecting to B3.

6.7.5 1_F!j_ht F 5

On flight 5 the transverse boom port and starboard extensions are attached.

No additional onboard SSDS elements are delivered on this flight. Connectors

on local buses already attached NIU1,2,3 support electrical power and thermal

control on the extensions as well as the solar panel actuators. The logistics

modu].e is also attached. Communication to the logistics moduie is on a local

bus connected from HM2.

i

6,7.6 F.Iight 6

On flight 6 labratory module 2 (LM2) is, attached. The onboard SSDS elements

in this package are 3 SDP's, 7 NIU's, 2 mass memory units (MMUd,5), 2 ring

concentrators (RC7,8) and 2 bridges (B6,7) and 2 work stations (W$4,5). The

PC network is connected across the LM2 bulkhead and connected to RC7. The

core network is extended by bringing the optical fiber into LM2 and connecting

to B7. The core and PL networks are connected across B6 in LM2.

6-116
Payload processing is now supported in the SDP's as well as a PL operational

data base. lhe P10DB utilizes two MMU's resident in LAB 2 on the PL network.

6.7,6 C l_ght 7

On flight 7 the laboratory module i (LM1) is attached. The onboard SSDS

elements in this package are I SDP, 7 NIU's, I workstation (WS6), 1 mass

memory unit (_JMU3), three ring concentrators (RC9,10,11) and 5 bridges

(B8,9,10,II,12). The remote communication to core functions such as ECLSS,

electrical power and thermal control are supported on local buses. The SDP

and workstation increase the PL processing capacity.

lhe PL network is extended across a bulkhead fiber-to-fiber connector to reach

the NIU's on the earth viewing pallet.

6.8 Memory and Processing Function Sizing Summary

The data in table 6.8 provide summaries of the memory and processing loads for

the Task 1 onboard functions grouped in terms of the Reference Configuration

Subsystem Names,

6-117
FUNCTIONS

Table 6.8

TASK l FUNCTIONS MAP TO REFERENCE CONFIGURATION

ELECTRICAL POWER

MEMORY (KBYTES)

IOC GROWTH

PROG DATA PROG DATA

DATA PROCESSING

(KOPS)

IOC GROWTH

4.2.1 OPERATE POWER SYSTEM

4.2.1.I Eval. Array Per. 5

4.2.1.2 Conf. Pw. Dist. 50

4.2.1.3 Power Source Mgmt. 30

4.2.1.4 Array Deployment l

4.2.1.5 Project Energy Avail. 15

4.2.1.6 Device Mgmt 50

4.2.1.7 Cmmd I/F Proc. 15

166

12 18 48

150 80 300

lO0 60 200

2 4 8

6 15 6

2 lO0 4

5 15 5

277 292 571

2.5 lO

28 50

19 35

0.5 2

l .2 l .2

25 50

smal I small

76.2 148.2

TOTALS 443 863

THERMAL CONTROL SYSTEM

FUNCTIONS MEMORY (KBYTES)

IOC GROWTH

PROG DATA PROG DATA

4.2.2 OPERATE THERMAL

CONTROL SYSTEM

4.2.2.1 Manage T. Load l l

4.2.2.2 Thermal Device Mgmt 50 2

4.2.2.3 Project Thermal Cop. l 1

4.2.2.4 Cmmd I/F Proc. 15 5

6? 9

TOTALS

1

lO0

l

15

ll?

5

76 131

DATA PROCESSING

(KOPS)

IOC GROWTH

2.5 lO 15

4 O.S 0.?

2.5 0.33 0.33

smal I small

14 10.9 16.1

6-118
Table 6.8 (continued)

TASK l FUNCTIONS MAP TO REFERENCE CONFIGURATION

GN&C (Page l of 3)

PROPULSION

Contains no Task 1 Functions: No Software Functions

FUNCTIONS

4.l.1 NAV

4.1.1.1 Spacecraft Orb. Det.

4.1.1.2 Const. State/Orb Det.

4.1.1.3 Determine Ephemerldes

(Sun, Moon, etc.)

4.1.I.4 Attitude Det.

4.1.1.5 Nav State Propag.

4.1.1.6 Device Mgmt

4.1.I.7 Commd I/F Proc.

MEMORY (KBYTES)

IOC GROWTH

PROG DATA PROG DATA

20 15 30 17

50 40 75 80

2 4 3 5

53 20 60 22

20 4 25 5

30 20 40 25

l___O8 12 9

185 If6 245 163

301 408

DATA PROCESSING

(KOPS)

IOC GROWTH

20 22

12.5 25

0.02 .03

lO 12

5 5.5

15 20

4_L

66.6 89.6

4.1.2 GUIDANCE

4.1.2.1 Reboost/Reentry Targ. 20

4.1.2.2 Maneuver Coord. 18

4.1.2.3 Collision Check 20

4.1.2.4 Reboost/Maneuver IO

4.1.2.5 Tether Control

4.1.2.6 Det. Pntg Mt. Cont. 5

4.1.2.7 Device Mgmt. 4

4.1.2.8 Cmmd Interface Proc. 20

97

5 25 6 2

12 30 20 0.5

lO 25 12 0.83

4 15 06 5

- 15 4 -

l 7 1.5 5

l 5 02 O.l

5 25 07 5

38 147 58.5 18.5

135

6-119

2os.s

2.5

0.9

l.O

6.0

O.l

7

0.2

7

24.7
Table 6.8 (continued)

TASK l FUNCTIONS MAP TO REFERENCE CONFIGURATION

GN&C (Page 2 of 3)

FUNCTIONS MEMORY (KBYTES)

IOC GROWTH

PROG DATA PROG DATA

4.1.3 ATTITUDE CONTROL

4.1.3.1 Control Aft & Trans. 48 07 56.2

4.1.3.2 Gen. Attitude Cmmds 20 4 22

4.1.3.3 Momentum Mgmt 14 1.8 16

4.1.3.4 Pointing Mt. Control 21 4.0 26

4.1.3.5 Device Mgmt 15 4 20

4.1.3.6 Cmmd I/F Proc. 3___004 32

148 24.8 172.2

DATA PROCESSING

(KOPS)

IOC GROWTH

I0.8150

5 2

2.0 l .5

6 5.0

6 5.0

4.56.0

34.3 169.5

225

2.5

2.0

7.0

6.0

6._._55

249

172.8 206.5

4.1.4 TRAFFIC CONTROL

4.1.4.1Comp/Prop Const State 8 l 9

4.1.4.2 Manage Const. Orb Man lO 2 15

4.1.4.3 Sched. Deploy/Rendez. 5 l 6

4.1.4.4 Manage Rendezvous 5 0.5 9

4.1.4.5 Target Coll. Avoid. 5 1 7

4.1.4.6 Cmmd I/F Proc. 15 2 18

48 ?.5 64

2

3

2

1

2

13

l

1.5

O.1

0.05

small

small

2.7

1

1.8

0.15

0.07

smal I

smal I

3.0

55.5 77

6-120
Table 6.8 (continued)

TASK l FUNCTIONS MAP TO REFERENCE CONFIGURATION

GN&C (Page 3 of 3)

FUNCTIONS MEMORY (KBYTES)

IOC GROWTH

PROG DATA PROG DATA

DATA PROCESSING

(KOPS)

IOC GROWTH

4.1.5 TRACKING

4.1.5.1 Long Range

4.1.5.2 Prox.

4.1.5.3 Object Cat. Main.

4.1.5.4 Tracking Data Cond.

4.1.5.5 Device Mgmt

4.1.5.6 Cmmd I/F Mgmt

40 5 50 6

40 5 50 7

25 lO 30 12

15 2 20 4

20 5 25 7

2__0 I5 2__ 5 I_!_8

160 42 200 54

S 6

5 6

.O1 .02

5 6

0.5 0.6

19.6 23.7

202 254

2.5.3.3 OTV Deployment/Ret. N/A 5 lO

15

small small

2.5.4.3 OMV Oeployment/Ret

t

3 8 5 lO

II 15

small small

GN&C TOTAL 878 1181 267 379

6-121
FUNCTIONS

TASK

Table 6.8 (continued)

FUNCTIONS MAP TO REFERENCE CONFIGURATION

STRUCTURES/MECHANISMS

DATA

MEMORY (KBYTES)

IOC GROWTH IOC

PROG DATA PROG DATA

4.2.3 STRUCTURES & MECH SUPPT

4.2.3,1Mechanlsm Control 7 5 14 lO l

4.2.3.2 MRMS Ups 21 lO 42 20 45

4.2.3.3 Manage Dock./Berth. 5 4 15 12 2

4.2.3.4 Device Mgmt lO lO 20 20 0.5

4.2.3.5 Cmmd I/F Proc 2"/ 9 74 2__55 3

70 38 165 87 51.5

TOTALS I08 252

PROCESSING

(KOPS)

GROWTH

1.5

9O

6

l

7.5

I06

ECLS

4.2.4 ECLSS OPERATION

4.2.4.1 Control Press/Atmos 4 5 4 5 0.02

4.2.4.2 Control Temp/Hum 4 5 4 5 0.02

4.2.4.3 Potable H20 Mgmt 4 5 4 5 0.02

4.2.4.4 Grey Water Mgmt 4 5 4 5 0.02

4.2.4.5 Fire Det. & Control 4 5 4 5 0.02

4.2.4.6 Device Mgmt 50 2 50 4 16.7

4.2.4.7 Cmmd I/F Proc. 15 5 15 5 small

85 32 85 34 16.8

TOTALS 117 119

0.02

0.02

0.02

0.02

0.02

16.7

small

16.8

6-122
FUNCTIONS

Table 6.B (continued)

TASK l FUNCTIONS MAP TO REFERENCE CONFIGURATION

CREW SYSTEMS (Page l of 2)

MEMORY (KBYTES)

IOC GROWTH

PROG DATA PROG DATA

DATA PROCESSING

(KOPS)

IOC GROWTH

4.3.1 HEALTH MAINTENANCE

4.3.1.I Crew Phys. Monitor

4.3.1.2 Medical Diag. Supt.

4.3.1.3 Treatment Supt.

4.3.1.4 Nutrition Anal.

4.3.1.5 Exercise Planner

4.3.1.6 Phys. Data Trans &

Anal.

5 2 7 3

lO 5 15 7

5 3 7 5

6 6 8 8

lO 5 15 7

20 __Es 2_Es

56 26 77 37

0.04 0.04

small smal]

0.02 0.03

small small

small small

small small

0.07 0.08

82 114

4.3.3 HABITABILITY

4.3.3.1 Recreation Services

4.3.3.2 Crew/Grd Comm

4.3.3.3 Cmmd I/F Proc

4 4 8 8

0.4 0.4 l O.B

0.2 O.l 0.4 0.2

small small

small small

small small

4.6 4.5 9.4 9.0 small small

9.1 18.4

6-123'
Table 6.8 (continued)

TASK 1 FUNCTIONS MAP TO REFERENCE CONFIGURATION

CREW SYSTEMS (Page 2 of 2)

FUNCTIONS MEMORY (KBYTES)

IOC GROWTH

PROG DATA PROG DATA

DATA PROCESSING

(KOPS)

IOC GROWTH

4.3.4 EVA SUPPORT

4.3.4.1 EMU Contam Control l 0.5 l 0.5 small

4.3.4.2 EMU Monltor/Maint. 50 2 60 4 small

4.3.4.3 EMU Monltor/Malnt. 20 1 30 2 small

4.3.4.4 Safety Interlock M/C l 0.5 2 1 small

4.3.4.5 EVA Real Time M/C 2 l 4 2 small

* 4.3.4.6 EVA Visual Info. SO lO 75 15 lO0*

4.3.4.7 Airlock Atmos Pres. 2 0.5 2 0.5 small

Composition Control

4.3.4.8 Airlock Temp/Hum l 0.5 1 0.5 small

4.3.4.9 Device Mgmt 15 l 20 2 50

4.3.4.10 Cmmd I/F Proc 15 5 2___0 _ small

TOTALS 107" 12" 140" 19.5" 50

small

small

small

small

small

lO0*

small

small

75

small

75

ll9 159.5

* 4.3.4.6 Function separate from DMS System (Excluded)

CREW SYSTEM TOTALS 210.1 291.9 50.I 75.1

6-124
FUNCTIONS

Table 6.8 (continued)

TASK l FUNCTIONS MAP TO REFERENCE CONFIGURATION

COMM & TRACKING (Page l of 2)

MEMORY (KBYTES)

IOC GROWTH

PROG DATA PROG DATA

DATA PROCESSING

(KOPS)

IOC GR_OWTH

1.1 MANAGE REAL TIME DATA ACTION

l.l.l Acquire Real Time

l.l.2 Priorltize Real Time

l.l.3 Monitor Real Time

l.l.4 Dispatch Real Time

l.l.5 Format Real Time

lO 30 20 60

4 2 8 4

5 2 lO 4

lO 5 20 lO

2_._o 1__oo 4.__Q 2o

49 49 98 98

98 196

lO0

lO

20 SAME

50

80

260 260

1.2 MANAGE DELAYABLE DATA RETURN

1.2.1 Acquire Delayed PL

1.2.2 Priorltize Delayed

1.2.3 Monitor Delayed

1.2.4 Dispatch Delayed

1.2.5 Format Delayed

lO 200 20 400

4 2 8 4

5 2 lO 4

lO 200 20 400

20 lO 40 20

49 414 98 828

463 926

50

1

2 SAME

50

5

I08 I08

6-125
Table 6.8 (continued)

TASK l FUNCTIONS MAP TO REFERENCE CONFIGURATION

COMM & TRACKING (Page 2 of 2)

FUNCTIONS MEMORY (KBYTES)

IOC GROWTH

PROG DATA PROG DATA

DATA PROCESSING

(KoPs)

IOC GROWTH

4.2.5 COMMUNICATION

4.2.5.1 Network Control 35 lO

4.2.5.2 Equipment Control 15 15

4.2.5.3 Status Monitor 50 15

4.2.5.4 Failure Detectlon/R. 50 64

4.2.5.5 Cmmd Prve S 2

4.2.5.6 Interface Control S 2

4.2.5.7 Telemetry Control 5 5

165 ll3

50 15

25 lO

70 25

lO0 128

lO 4

6 3

ms _js

266 190

small small

25 35

2 3

lO 20

lO 15

5 6

2o__o 3o__oo

252 379

278 456

2.5.3.5 OMV Status N/A

(To remote customer)

N/A 10 5 N/A 3

2.5.4.6 OMV Status 8 4

(To remove customer)

t

COMM & TRACKING TOTALS 851

lO 5

1608

2 3

622 753

6-126
FUNCTIONS

Table 6.8 (continued)

TASK l FUNCTIONS MAP TO REFERENCE CONFIGURATION

INFORMATION DATA MANAGEMENT SYSTEM (Page l of 4)

¢

MEMORY (KBYTES)

IOC GROWTH

PROG DATA PROG DATA

DATA PROCESSING

(KOPS)

IOC GROWTH

2.1 Validate PL Cmmd 4 20 6 40 O.Ol 0.03

24 46

2.2 Check SSDS Ser. Req.

Restrlction/Constralnt

20 50 30 lO0 1.7

70 130

3.75

2.3 Validate Core Cmmd/Data .l

2.3.1 and 2.3.2 .2

4 20 6 40

I0 2._..55 I___555__.00

14 45 21 90

small small

59 III

3.3 Develop Ops Event Scld.

3.3.1 to 3.3.4

214 510

724

240 590

830

0.6 0.7

3.4 Sequence Operations

3.4.1 to 3.4.4

l

42 18 59 29 sma I1

60 88

small

4.3.2 Space Station Safety

4.3.2.1 to 4.3.2.4

7.5 7 18 19 small

14.5 37

small

4.3.5 OPS & Procedure Supt.

4.3.5.I to 4.3.5.5

140 153 152 152 0.3

293

6-127

304

0.7
Table 6.8 (continued)

TASK l FUNCTIONS MAP TO REFERENCE CONFIGURATION

INFORMATION DATA MANAGEMENT SYSTEM (Page 2 of 4)

FUNCTIONS MEMORY (KBYTES)

IOC GROWTH

PROG DATA PROG DATA

DATA PROCESSING

(KOPS)

IOC GROWTH

4.1.6 Time & Frequency Mgmt.

4.1.6.1 Time Source

4.1.6.2 Time Update

4.1.6.3 Freq. Source Mgmt

4.1.6.4 Device Mgmt

4.1.6.5 Cmmd I/F Proc.

0.5 0.2 0.7 0.3

2 0.5 3 l

l 0.3 2 0.5

0.3 O.1 0.5 0.2

0.2 O.l 0.4 0.2

0.2 0.3

smal I small

0.5 0.7

0.2 0.3

smal I smal I

4.0 1.2 6.6 2.2 0.9 1.3

5.2 8.8

5.1.1 Fit. Data Base Mgmt.

5.l.l.l Update/Access Synch 250

5.1.1.2 Data File Mgmt. 12

5.1.1.3 Mass Memory Res. Mgmt lO

5.1.1.4 Archival Storage 20

5.1.1.5 Device Mgmt l

5.1.1.6 Cmmd I/F Proc. l

294

494

50 500 lO0 sma Il

140 20 200 small

4 20 10 small

5 40 10 sma Il

0.5 2 l 1

O.5 2 1 small

200 584 322 l

906

small

small

small

small

1.5

small

1.5

6-128
Table 6.8 (continued)

TASK l FUNCTIONS MAP TO REFERENCE CONFIGURATION

INFORMATION DATA MANAGEMENT SYSTEM (Page 3 of 4)

FUNCTIONS MEMORY (KBYTES)

IOC GROWTH

PROG DATA PROG DATA

DATA PROCESSING

(KOPS)

IOC GROWTH

5.1.2 Fit. Resource Mgmt.

5.1.2.1 Load Scheduling 5

5.1.2.2 System Executive

- OPERATING SYS. (OS)* 160

- Network OS (NOS)* 410

5.1.2.3 Initialized Conf. Cont 30 18

5.1.2.4 Conflgur. Data Proc. 50 125

5.1.2.5 Facility Status 22 60

5.1.2.6 Recept. Dist. PL 80 175

5.1.2.7 Device Mgmt. IO 20

5.1.2.8 Cmmd I/F Proc I___55 5

212 408

lO lO small small

% of % of

250 Application Application

450 lO0 130

50 30 small small

lO0 200 small small

40 80 small small

lO0 200 30 50

20 30 0.2 0.2

25 l___O 0 .__55 l .0

345 560 30.7 51.2

620 905

"5.1.2.2 Excluded from 5.1.2 total because OS applies to memory

configuration and NOS is contained in NIU.

i

5.1.3 Displays & Controls

5.1.3.1 Device Mgmt

5.1.3.2 Cmmd I/F Proc

0.4 0.2

o._22o.__!

0.6 0.3

0.9

0.5 0.3

o.4

0.9 0.5

1.4

6-129
Table 6.8 (continued)

TASK l FUNCTIONS MAP TO REFERENCE CONFIGURATION

INFORMATION DATA MANAGEMENT SYSTEM (Page 4 of 4)

FUNCTIONS

4.5 Monitor & Status System

4.5.I Monitor Core

4.5.2 Monitor Customer

4.5.3 Mass Prop. Conf.

4.5.4 Diagnostic Suppt.

4.5.4.1 to 4.5.4.3

4.5.5 System Test & Eval

4.5.6 Cmmd I/F Proc.

MEMORY (KBYTES)

IO___CC GROWTH

PROG DATA PROG DATA

4 2 8 4

4 2 8 4

7 3 14 6

45 42 405 82

20 15 20 15

5___22 l___Z7 13__44 5___99

132 81 589 170

DATA PROCESSING

(KOPS)

IO___CC GROWTH

0.5 l

0.4 0.8

O.1 0.2

4.5 40.5

1.0 2.0

3 ..__0 9.0

9.5 53.5

IDMS TOTALS

213

2511.6

759

4036.2

n m

44.8 I12.6

6-130
FUNCTIONS

Table 6.8 (continued)

TASK l FUNCTIONS MAP TO REFERENCE CONFIGURATION

PAYLOAD AND SERVICING ACCOMMODATIONS (Page l of 2)

DATA PROCESSING

MEMORY (KBYTES) (KOPS)

IOC GROWTH IOC GROWTH m

PROG DATA PROG DATA

2.4 Provide Ancillary Data 2 lO 3 20 4.4 9.0

2.5 Support Customer Ops

2.5.I Customer Data Proc.

2.5.2 Customer PLOPS

2.5.3 Support OTV OPS

2.5.3.10TV Service

2.5.3.20TV CO & Diag

2.5.3.40TV Operation

12 23

lO0* lO0* 200* 200* 0.02 0.02

25 25 50 50 small small

N/A N/A 25 lO N/A 0.I

N/A N/A I00 lO0 N/A 0.5

N/_._AAN/A lO 2___00 N/___.AA small

25 25 185 180 O.1 0.7

W/O*

2.5.4 Support OMV OPS

2.5.4.10MV Service

2.5.4.20MV CO & Diag.

2.5.4.3 Remote Ops Co.

2.5.4.50MV OPS

t

2.5.5 Customer Payload

Checkout Service

50* 365*

15 6 25 lO small small

75 75 lO0 lO0 small small

15 6 21 lO lO 15

8 15 lO 20 small small

ll3 I02 156 140 lO 15

215 296

25 lO00 30 1200 small small

I025 1230

2.6 SSPE CO AND SERVICE lO0 lO00 lO0 lO00 small small

llO0 llO0

6-131
Table 6.8 (continued)

TASK l FUNCTIONS MAP TO REFERENCE CONFIGURATION

PAYLOAD AND SERVICING ACCOMMODATIONS (Page 2 of 2)

FUNCTIONS

4.4 Provide Cust. Avionic Sev

4.4.1 GN&C Service

4.4.1.I Grd Track

4.4.1.2 Magnetic Field

4.4.1.3 Pallet Coarse

4.4.1.4 Relative Align

MEMORY (KBYTES)

IOC GROWTH

PROG DATA PROG DAT__._AA

3 l 6 2

l.5 0.5 l .5 0.5

lO 2 20 4

..13 __9 I___3

27.5 12.5 40.5 15.5

DATA PROCESSING

(KOPS)

IOC GROWTH

0.5 l

0.3 l

lO 20

o.__._2 0.2

II 22.2

40 56

4.4.2 Contamination Control

4.4.2.1 Venting Effects

4.4.2.2 Environ. Monitor

8 4

I__22 8

20 12

32

24 12

24 16

48 28

76

0.2 0.6

o.4 o.____B

0.6 l .4

4.4.3 Tracking Services

t

PAYLOAD AND SERVICING ACC.

TOTALS

3 1 9 3

12

O.l 0.3

2478 3158 26.2 48.6

6-132
6.g ONBOARD PLATFORM SSDS DEFINI"['ION

6.g.l Introduction and Overview

[his section presents an overview of the onboard Platform SSDS. The SSDS

includes the onboard networks, the network interface units (NIU's), subsystem

data processors (SDP), mass storage units and the software that resides in or

supports these elements. Subsystem application software is included in this

definition. The architecture and system definition described herein are

products of the SSDS A/A Study approach and methodology outlined in Section

2.0. This architecture definition is preliminary. Some elements are defined

in more detail than others to explore specific design or technology driver

aspects of the architecture. The prime inputs used are the same as those

detailed in Section 6.1

The major metrics utilized throughout this task to evaluate architectural

alternatives and influence key design decisions are the same set described in

Section 6.1.

The primary steps of the platform onboard system definition process proceeded

in a similar manner to that described in Section 6.1 for the Space Station

SSDS.

The supporting trade study results and options developed were major inputs

into the system definition process. Recommendations and supporting data in

the Space Station trade studies and related options catagories were important

influencing ?actors in most key design decisions. Commonality was a key

consideration in all these trade studies and in our platform system design.

6-133
6.9.2 Partitioning of Functional Requirements into Onboard Subsystems

The same process reported in Section 6.2 for the Space Station SSDS was

fo].1owed for the platform,

Table 6.9.2.-1 presents an application overview of memory sizing in kilobytes

(kbytes) and mean processing rates in kilo-operations per second (kops) using

the reference configuration subsystem names. A detailed breakout of each of

the subsystems are tabulated in Section 6.9.8.

The application memory size for each subsystem is conservative from the

standpoint that it represents an arithmetic sum. Not a11 elements of each

subsystem are necessarily main memory resident in an SDP at ali times. This

also naturally applies to their computational rates

6.9.3 Subsystem A11ocation in Architectural Elements

The discussion of Section 6.3 for Space Station in general applies equally

we].1 to the platform. The basic difference is in the sizing values for each

memory configuration. Table 6.9.3-I provides the summary data by memory

configuration. Section 6.9.8 provides the detailed sizing data extracted from

the Task 4, Appendix G which contains the sizing data For a11 the platform

functions.

The major differences between the Platform System and Space Station are the

smaller and Fewer application functions. The following is a brief difference

summary :

1. No ECLS is required for the Platform (Functions 4.2.4.1-7)

2. No onboard Displays and Controls are required (5.1.3)

3. Some Space btation GN&C functions are not required for the platform:

- Traffic Control (4.1.4)

- Tracking (4.1.5 and 4.4.3)

4. No onboard Displays and Controls are required (5.1.3)

5. The remaining onboard functions are required, but are reduced in size.

6-134
Table 6.9.2-1

TASK 1 FUNCTIONS MAP TO REFERENCE CONFIGURATION

SUMMARY DATA

SUBSYSTEM

I. ELEC PWR

4.2.1 .I-7

MEMORY (KBYTES)

IO.___C GROWTH

I03 227

MEAN DATA

PROCESSING (KOPS)

IOC GROWTH

69 127

2. GN&C

4.1, 2.5.3.3, 2.5.4.3

370 468 190 255

3. THERMAL CONTROL

4.2.2.1-4

68 127 3 4

4. ECLS

4.2.4.1-7

NOT APPLICABLE TO PLATFORM

5. PROPULSION NO SOFTWARE -- CONTROLLED BY GN&C

6. STRUCTURES/MECHANISMS

4.2.3.1-5

24 43 3

7. CREW SYSTEMS

4.3.1, 4.3.3, 4.3.4

NOT APPLICABLE TO PLATFORM

8. COMM & TRACKING

l .1.I-5, l .2.1-5,

4.2.5.1-7, 2.5.3.5,

2.5.4.6

606 1077 499 747

9. INFORMATION &

DATA MGMT SYSTEM

2.1, 2.2, 2.3, 3.3, 3.4

4.3.2, 4.3.5, 4.5,

4.1.6, 5.1.1, 5.1.2

2271 3689 42 84

lO. PL & SERVICING

ACCOMMODATIONS

2.4, 2.5.1, 2.5.2,

2.5.3.1, 2.5.3.2,

2.5.3.4, 2.5.4, 2.5.5,

4.4

2231 2801 15 29

6-135
Table 6.9.3-1

Platform SSDS Core and Payload Memory Configurations

No. Name/Function

IOC

Mem(1)/CPU(2)

(KBYTES/KOPS)

Growth

Mem(1)/CPU(2)

(KBYTES/KOPS)

I. GN&C 370/2197 718/293

o NAV

o Guidance

o ATT Cent

2. o Elec Pwr 961/660 1724/1016

o Thermal Control

o Communications

o Str.& Mechanisms

3. Information & Data 2431/48 3939/97

Managememt System

4. Payload and Servicing 2391/17 3051/66

Accommodations

5. Payload Processing 360/1 650/1

(Function 2.5.1)

6. Payload Processing 360/1 650/1

(Function 2.5.1)

(i)

(2)

Application size from Tables 6.2-1/6.8-1 +160 KBYTES for operating system

(+250 KBYTES for growth).

KOPS from Table 6.9.2-1 + 15% of total application KOPS for Operating

system overhead.

6-136
6.9.4 Architecture

6.9.4.1 Overall Partitioning

The overall platform architecture presented here has most of the same

connectivity generalized in the NASA Reference Configuration. However, the

system definition process of this study has resulted in a more specific and

detailed configuration.

6.9.4.2 Network Configuration

A major deviation from the Reference Configuration is the partitioning of the

network into two networks: core and payload. The reasoning for this decision

is the same as for the Space Station as discussed in Section 6.4.2.

The discussion in Section 6.4.2 concerning the network configuration, level of

standardization, transmission media, topology and media access method and

communication Functions equally apply to the onboard platform SSDS.

6.9.4.3 NIU Functional Description

The NIU for the platform is the same one as the Space Station. Again,

commonality was the key driver in this decision. Basic hardware and software

functionality is the same in both systems.

6.9.4.4 Operating System/Applicati0n

The discussion for the Space Station on this subject applies to the Platform

system. As discussed earlier, their are fewer ?unctions on the Platform than

the Space Station. Most of the platform application functions will require

the same support services as the Space Station. The most notable diflerence

are Displays and Controls and other onboard man machine interfaces. A common

DOS and OS as described in Section 6.4.4 zs recommended for the Platform to

take advantage of reduced development and maintenance costs for both systems.

It might be possible to build the man-machine interfaces in the common DOS/OS

so that they can be excluded For the platform system to save memory.

6-137
6,9,4,5 Subsystem Data Processor

It is recommended that a common subsystem data processor (SDP) be used for

both the Platform and the Space Station. The characteristics of the SDP were

discussed in Section 6.4.5.

6.9,4.6 Onboard Workstations

There are no onboard work stations for the Platform. This section was

retained to keep a similar numbering system for traceability to the Space

Station sections.

6.9.4.7 Operational Data Base

The same general needs for an operational base and mass storage exist for the

Platform as ?or the Space Station (ref. section 6.4.7). The size ?or the

Platform system is greatly reduced because the Platform is unmanned and

maintenance will be per?ormed at discrete intervals.

6,9.4.8 Communication Gateway

The discussion for this subject is the same as that for the Space Station

(ref. section 6.4.8).

6-138
6.9.4.9 PLATFORM TRAFFIC ANALYSIS

The following section derived the network traffic requirements for the

platforms. The requirements are presented in terms of messages per second, a

more meaningful traffic parameter than bytes per second. Analysis of the core

network traffic model shows the communication and tracking NIU receives over

2/3 of the total traffic load.

The network traffic model was derived from the McDonnell Douglas

Requirements Data Base (Appendlx-l) using an analysis tool developed in PL/I.

The tool allows functions in the Data Base to be arbitrarily distributed

across a multi-computer environment.

Interactlvely specify, for example:

The process allows the operator to

Computer Computer Computer Computer

l 2 N-l N

Function # Function # External l

l.l.l 2.1.1 External 2

l.l.2 4.3.1

External 3

From this input, a search of the data base is made to determine the

following reports:

- Computer l to/from Computer 2

- Computer l and 2 to External Sets l and 2

- Computer l and 2 to External Set 3

statistical reports to evaluate the I/O requirements.

following statistics were determined:

Proper selection of the inputs, functions and externals, resulted in

From these inputs the

Subsystem to subsystem I/O

Subsystem to subsystem sensors/effectors

t

Subsystem to operational data base, ancillary data

Subsystem to displays

Subsystem to Comm for telemetry,_operatlons instrumentation data

The network traffic model was developed from several sources:

(1) Analyses of Functions Data Base I/O Relationships

(2) Engineering Modifications to (1) Above

(3) Engineering Judgement

6-139
Additions to the Network Traffic Model included:

(I) Telemetry Data

(2) Operations Instrumentation Data

(3) Ancillary Data

(4) Ground Forward Commands

Table 6.9.4.9-I identifies specific assumptions employed in the network

traffic analysis. Figure 6.g.6.l-I shows the processing distribution for the

core network.

Table 6.9.4.9-2 shows the core network traffic results for the platforms.

The traffic due to telemetry is approximately 2/3 of the total load on the

core network.

6.9.4.10 Fault Tolerance

The basic discussion in Section 6,4.10 applies to the Platform

6.9.4,11 Time Management

The discussion in Section 6.4.11 applies to the Platform because this basic

service is needed in both systems with the same degree of accuracy and

availability. R common system design is recommended to save costs.

6-140
TABLE 6.9.4.9-I NETWORK I/O TRAFFIC ASSUMPTIONS

Requirement Sources

- Analysis of core traffic results and engineering Judgement to model

remaining non-telemetry payload network traffic nodes

Topology

- Files/Data stores in each Subsystem SDP

- DMS ODB has it's own SDP

Packet/Message Length

- Message length equals packet length

Telemetry

- 25 KBytes/sec per Subsystem

- 1 KByte Message size to satisfy Consultative Committee for Space Data

Systems (CCSDS) efficiency

Overhead

- OSI/CCSDS message overhead not included

Ancillary Data (AD)

- Subsystems send AD to OMS ODB

- DMS ODB blocks AD and sends to P/L Network ODB

- P/L's read AD from P/L ODB as required

Ground Forward Commands (GFC)

- Comm receives GFC for each subsystem

- Comm routes GFC to individual Subsystems

t

- Dependent on CMD VAL implementation

- O.1 message/sec per subsystem

Operations Instrumentation Data (OID)

- OID collected by each subsystem from backend

- Subsystem send blocked OID to COMM for downllnk

6-141
II _'

_J

r.,t..,

q)

[-i

,,4 _| :'1 I IIO :"_1II)

It

II

I".

I

II

ii | | i il I " ) II * II

il

II

II

: II

',I"

r I!

II

I"

II

": il

,:ti i!

_I II i II I II

II

II I!

II

I It

-I II

I" II

II

- II I i,, U

I

It

II

i, II

It

• II

tl

ili

I!!

F-Ih ':) :) IIi

_1_ _" r'l II { II

II

II

II

:) :),

.-4 ,,-I II

0

0_0

00

•-_00

¢E

o!

!

II

U it_:

II

II

II

II

I!

II

U tl.

I

If

_ I0I

II II

,

{/1 II I|*

II II I

II II II II I

II--II !

II II I

II II_

II {i_ II

II II

II

II II

I

II II III

(..1 II I I

_i1 II

II II II

r_ II II II "1 n II _ II

II II II

II II II

II ",, _IIoo

II IIH II•*

II II fJ il @,I _'I

{/_U II_Z II

I'M II II_ ---- II

{=_11 IIi II

II II 110 _:I

II II_ II••

),=4 il II_ II ('d

II II 1"4 II II II II

II II II

IIU I II

II II II

,, II {,_ II II

II- II _1 II

II II II

I| II

II I-4 IIN

II__ It II II

II ---- ,,II

II II

II II

III II II I|

IIU II

II_ II

II iv -- II

II_ 11 II II ¢_

tl0 It

I| _-_ l|

II I_ II

II II

II II

II -- I1_

u II II

II II II CO

I, t, i_ II_

II il II

II II II

II II II

II

II

U II

II II

II II

II II

II II

IIU

It 11

II II

II

=.41

•I

II

II

_,I II • II

_-I IIn

II

II

II

00 il

•° II

4" ._ It

il

II

li

•• li

_'_n

il

II

II

il

II

¢_1 II_

.,,4_ II I'_

II ,-,4

II

li

II

ii

II

_"

II

_-t II U II (._

U _-I

r.t,,,,

li

tl

II

II

II

11°-I1

il

II II ._ ,i

II

• II I If li II I II II

II_ II

I II ,.., II I li II

II I ii -- I tl i li I_

li

li C_I

II

II

IH

. I1_11

li

II_ II

li

li ¢_ II

II (/_

II II_

li

ii -- li

li

II_ II

B

II

li_ li_

li

II II_

I"

i

li

II II I II _ II

ii li II _ II ,= " _

II ti

li

IIH

II

PiI II

II

(_I IllZ

•-,I" li _-i

_=I li

II

II_ II

II

0 ii_ li f-J

• II I--I

,_ it CO to

ti

"

li

_ It

II -- II [--I

II

II

II

II

m

0

IIm ii

II

II

li -- II

t

,,U_ ,,ii

li

II

OI "_

II ii_ ii

li

II -_

IIII_

II

li

II

II

II

II

il_Z_'_._ ii

II II

v')

v')

..J<z

,<

¢,.)

i,.i

liI,-.,.

I:

c_

t.i.

I'-- <

_JI

I.IJ

--I

I--

6-142
6.9,5 Operational Scenarios

With the exception of the discussion for onboard manned operations, the system

initialization, subsystem control, facility management, telemetry and

commands, and examples of onboard data flow for the Space Station (ref.

section 6.5) applies equally well to the Platform.

6.9.6 Onboard Platform SSDS Architecture

6.9.6.1 Distribution of Processing

The Platform SSDS architecture and Space Station architecture are functionally

the same. They differ only in specific subsystem needs and in physical

configuration of the spacecraft structures. Commonality and the resultant

cost savings were key considerations. Our studies show that commonality with

the Space Station does not significantly compromise the SSDS differences

between specific needs for the two systems. For example, the memory size and

computational speed of the SDP can be based on convenient subsystem groupings

for both systems with adequate margins. Both systems need to support core and

payload functions; both need an operating system (OS) and a distributed

operating system (DOS) to interface similar core sensors and effectors and

payload measurements with their respective application software programs. For

the above reasons, a functionally common architecture is recommended for both

systems.

The main features cited in Section 6.6.1 for the Space Station applies to the

Platform with the exception of using a workstation to offload processing from

the SDP's.

i

The Platform SSDS memory configurations and their respective distribution are

presented in Table 6.g.6.1-I. The six memory configurations are supported by

1B SDP, and NIU pairs. The SOP sparing strategy is two backups for all memory

configurations.

The total network that supports this distribution is shown Figure 6.9.6.1--i

and Figure 6.g.6.1-2. The PL/EXP and core functions are separated to insure

the highest degree of trafffic isolation and, therefore function autonomy.

8-148
U

E v' v

•F-. (.)

Q

Ck. _,-i

,...-(_j

Z

O

l---

m_q

a,

Z

O

m,i

X

m,

..m

D.

e.-

o¢,..

e--

,r,.

E

J(,_)

c

o

E

O °

UZ

,.g

f,.

_ _1-.- "%..

,.-.-o,J

E.._ v

°_'- U U

°_-" U U

mE_ (f) (_') (/)

(,..)

(.,r)c/) (.rl

6-144
_U

"_'__,E

_Uo

"5

0_

t,.

0

6-145
6-146
6,9.6.2 Platform Network Architecture

The Platform "strawman" onboard local area network configuration consists of

two major network partitions isolating PL/EXP traffic from core traffic.

There is a bridge between the two networkpartitions to support core and

PL/EXP data exchange. Ancillary data and forward link telemetry flow from

the core network to the PL/EXP network across the bridge. The topology of the

network is the same as the Space Station; interconnected dual redundant token

rings each with a multi-port ring concentrator. The physical distribution of

the network elements is shown in Figure 6.9.6.2-1. The network topology is

shown in Figure 6.9,6.2-2. Dual redundancy exists in the bridges and ring

concentrators.

6.9.6.3 Major Architecture Issue

The architecture issue discussed in Section 6.6.3 for the Space Station also

applies to the Platform SSDS architecture.

6,9.7 Buildup

The assumption is made that the platform is assembled with one NSTS flight and

to date no impacts have been identified to the Platform SSDS Architecture.

6.9.8 Platform Memory and Processing Function Summary

The data in Table 6.9.8 provides summaries of the memory and processing loads

for the Task 1 and Task 4 onboard functions grouped in terms of the Reference

Configuration Subsystem names. The Task 1 and Task 4 Appendices provide

detailed function descriptions and sizing data.

6-147
III

_z=

.J

6-148

.o

i5&

o,;

¢.D

,=

._=

I,I.
N7 A

Core Network

N8 A N9A N10 A N11A

N12 A

B1

N17 A

N16 A

Payload Network

N18 A N19 A N20A

N21A

Spare Ports RClA RC2 A

' Spare Ports

for Growth

A;N3A N4A N5A ) I"

N14 A N15 A

N8 B N9B iN10B IN1 lB.

N7 B

N17 B N18 B N19 B N20 B

N21B

RC1B RC2 B

Spare Ports

for Growth

N1 N6 B

B N3 B N4 B B

N13BI_

B N15 B

Legend

RC- Ring Concentrator

N -- Network Interface

Unit (NIU)

B - Bridge

Figure 6.9.6.2-2. Platform Network Topology

6-149
Table 6.9,8

PLATFORM TASK i FUNC[IONS MAP TO REFERENCE CONFIGURAIION

ELECTRICAL POWER

FUNCTIONS

4.2 1 OPERATE POWER SYSTEM

4 2 1.1 Eval, Array Per.

4 2 1.2 Conf. Pw. Dist.

4 2 1,3

421.4

421.5

421,6

421.7

Power Source _k3mt.

Array Deployment

Project Energy Avail.

Device Mgmt

Cmmd I/F Proc.

DATA PROCESSING

MEMORY (KBYTES) (KOPS)

IOC GROWTH IOC GROWTH

PROG DATA PROG DATA

5 4 6 6 2.5 2.5

10 12 60 24 28 50

I0 10 20 20 19 35

1 2 4 4 0,5 2

10 2 15 5 1.2 1.2

25 1.5 50 3 18 36

_7 _,_ 7 _3 smal I smal 1

68 34.5 162 65 69.2 126.7

TOTALS 102,5 227

THERMAL CONTROL SYSTEM

FUNCTIONS

4.2.2

4,2.2.1

4.2.2.2

4.2,2.3

4.2,2.4

OPERATE THERMAL

CONTROL SYSTEM

Manage T. Load

Thermal Device Mgmt

Project Thermal Cop.

Cmmd I/F Proc.

"TOTALS

DATA PROCESSING

MEMORY (KBYTES) (KOPS)

IOC GROWTH IOC GROWTH

PROG DATA PROG DATA

1 3

50 2

1 1

7 3

59 9

68

1 4.5 0.13 0.20

100 4 2.5 3.5

1 2,5 0.33 0.33

10 4 small small

112 15 2.96 4.03

127

PROPULSION

Contains no Task I Functions: No Software Functions

6-150
Table 6,9.8

PI..ATI=ORM TASK 1 FUNCTIONS MAP 'to REFERENCE (]ONFIGURATEON

GN&__....C_C (Page 1 of 3)

FUNCTIONS

DAI"A PROCESSING

MEMORY (KBYTES) (KOPS_)__-

IOC GROWTH IOC GROWTH

PROG DATA PROG OATA

4.1.1 NAV

4.1.1.1 Spacecraft Orb, Det.

4.1.1.2 Const. State/Orb Det.

4.1.1.3 Determine Ephemerides

(Sun, Moon, etc.)

4.1.1.4 Attitude Det.

4.1.1.5 Nay State Propag.

4.1.1.6 Device Mgmt

4.1.1.7 Commd I/F Proc.

TOIALS

20 15 30 17 20 22

NOT APPLICABLE TO PLAIFORM

2 4 3.5 5 0.02 .02

35 14 42 16 5 7

20 4 25 5 5 5,5

20 15 25 20 10 12

5 4 6 5 2 3

102 56 131.5 68 42,1 49.5

158 199.5

4.1.2 GUIDANCE

4.1.2 1Reboost/Reentry Targ.

4.1 2 2 Maneuver Coord.

4.1 2 3 Collision Check

4.1 2 4 Reboost/Maneuver

4.1 2 5 Tether Control

4.1 2 6 Det. Pntg Mt, Cont.

4.1 2 7 Device Mgmt.

4.1 2 8 Cmmd Interface Proc.

TOTALS

14 3.5 18 4,5 1.4 2.0

12 8 20 12 .35 O. 6

NOT APPLICABLE TO PLATFORM

7 2.8 10 3.2 3.5 4.5

NOT APPLICABLE TO PLATFORM

0.5 3.5 .75 ,75 1

1.5 .6 .03 .04

7 2 3 4

60 23.1 9.1 12.1

83,1

2.5

1.2 0.3

6 1.5

42.7 16.6

59,3

6-151
lable 6.9.8

PLATFORM TASK I FUNCTIONS MAP FO REFERENCE CONFIGURATION

GN&C (Page 2 of 3)

FUNCTIONS

4,1,3 AI'FITUDE CONTROL

4.1.3 1 Control Aft & Trans.

4,1.3 2 Gen. Attitude Cmmds

4,1.3 3 Momentum Mgmt

4.1.3 4 Pointing Mt. Control

4,1.3 5 Device Mgmt

4.1.3 6 Cmmd I/F Proc.

TOTALS

DATA PROCESSING

MEMORY (KBYTES) (KOPS) _

IOC GROWTH IOC GROWTH

PROG DATA PROG DATA48 7 56.2 10.8 125 175

20 4 22 5 2 2.5

14 1.8 16 2.0 1.5 2.0

21 4.0 26 6 5.0 7,0

10 4 15 6 2.5 3.0

15 4 16 4.5 3.0 3.5

128 24.8 151.2 34.3 139 193

152.8 185.5

4.1.4 TRAFFIC CONTROL

4.1.4.1Comp/Prop Const State

4.1.4.2 Manage Const. Orb Man

4.1,4.3 Sched. Deploy/Rendez.

4,1.4,4 Manage Rendezvous

4.1.4.5 Target Co11. Avoid.

4,1.4.6 Cmmd I/F Proc.

NOT APPLICABLE "TO PLATFORM

4.1.5 TRACKING

4.1.5.1 l,.ongRange

4.1.5.2 Prox.

4.1.5.30bje(t Cat. Main.

4.1.5.4 Tracking Data Cond.

4.1.5.5 Device Mgmt

4.1.5.6 Cmmd I/F Mgmt

NOT APPLICABLE TO PLATFORM

6-152
Table 6.9.8

Pt.ATFORM TASK 1 FUNCTIONS MAP TO REFERENCE CONFI(;URAIION

GN&C (Page 3 of 3)

FUNCTIONS

DATA PROCESSING

MEMORY (KBYTES) .... (KOpS____

IOC GROWTH IOC GROWI"H

PRCK_ DATA PROG DATA

2,5.3.3 OTV Deployment/Ret, NOT APPLICABLE TO PLATFORM

2,5,4,3 OMV Deployment/Ret NOT APPLICABLE 'TO PLATFORM

GN&C TOTAL 370,1 468.1 190.2 254.6

6-153
Table 6.9.8

PI..ATFORM TASK i FUNCIIONS MAP TO REFERENCE CONFIGURAIION

STRUCTURES/MECHANISMS

FUNCTIONS

DATA PROCESSING

MEMORY (KBYTES) (KOPS) ____

IOC GROWTH lOC GROWTH

PROG DATA PROG DATA

4.2.3 STRUCTURES & MECH SUPPT

4.2,3,1 Mechanism Control

4,2.2.2 MRMS Ups

4.2,2.3 Manage Dock./Berth.

4.2.2.4 Device Mgmt

4.2.2,5 Cmmd I/F Proc

2,B 2.0 5,6 4.0 0,4 0.6

NOT APPLICABLE 'TO PLATFORM

2,0 1.6 3.0 2,0 0.8 1,6

4,0 4.0 8.0 8.0 0.2 0.4

5,0 2.0 4.0 B.O 1.0 2,0

13,8 9.6 20.6 22 2.4 4.6

TO"FALS 23.4 42.6

ECLS

4.2 4 ECLSS OPERATION

4 2.4.1 Control Press/Atmos

4 2.4.2 Control Temp/Hum

4 2,4.3 Potable H20 Mgmt

4 2.4.4 Grey Water Mgmt

4 2.4,5 Fire Det. & Control

4 2.4.6 Device Mgmt

4 2.4.7 Cmmd I/F Proc,

NOT APPLICABLE TO PLATFORM

6-154
FUNCTIONS

Table 6,9,8

PLATFORM TASK I FUNCTIONS MAP TO REFERENCE CONFIGURAFION

CREW SYSTEMS (Page 1 of 2)

DATA PROCESSING

MEMORY (KBYTES) (KOPS_____.....

IOC GROWTH IOC GROWTH

PROG DATA PROG DATA

4.3.1 HEALTH MAINTENANCE

4.3 1.1 Crew Phys. Monitor"

4.3 1.2 Medical Diag. Supt.

4.3 1.3 Treatment Supt.

4.3 1.4 Nutrition Anal.

4.3 1.5 Exercise Planner

4.3 1.6 Phys. Data Trans &

Anal.

NOT APPLICABLE TO PLATFORM

4.3.3 HABITABILITY

4.3.3.1 Recreation Services

4.3,3.2 Crew/Grd Comm

4.3.3.3 Cmmd I/F Proc

NOT APPLICABLE TO PLATFORM

6-155
Table 6.9,8

PLATFORM TASK 1 FUNCTIONS MAP TO REFERENCE CONFIGURATION

CREW SYSTEMS (Page 2 of 2)

FUNCTIONS MEMORY (KBYTES)

IOC GROWTH

PROG DATA PROG DATA

DATA PROCESSING

(KOPS) _

IOC GROWTH

4.3.4 EVA SUPPORT

4.3 4.1EMU Contam Control

4.3 4.2 EMU Monitor/Maint.

4.3 4.3 EMU Monitor/Maint.

4.3 4.4 Safety Interlock M/C

4.3 4.5 EVA Real Time M/C

4.3 4.6 EVA Visual Info.

4.3 4.7 Airlock Atmos Pres.

Composition Control

4.3.4.8 Airlock Temp/Hum

4.3.4.9 Device Mgmt

4.3.4.10 Cmmd I/F Proc

NOT APPLICABLE TO PLATFORM

6-156
lab le 6.9.8

PLATFORM TASK I FUNCTIONS MAP TO REFERENCE CONFIGURAI"ION

COMM & TRACKING (Page I of 2)

FU__.NC/TION_S MEMORY _ KBYTES

IOC GROWTH

PROG DATA PROG DATA

DATA PROCESSING

.... (KO ]m_

IOC GROWI"H

m_

i. 1 MANAGE REAL I"IME DATA ACTION

1.1.1 Acquire Real Time 7 21 14 42 70 1OO

1,1,2 Prioritize Real Time 2,8 1,4 5,6 2,8 7 10

1,1.3 Monitor Real Time 3,5 1.4 5 3 14 20

1.1,4 Dispatch Real Time 7 3,5 14 7 35 50

1.1,5 Format Real Time 14 7 28 14 56 80

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

34,3 34.3 66.6 68.8 182 260

68,6 135.4

1.2 MANAGE DELAYABLE DATA RETURN

1.2.1 Acquire Delayed PL 7 150

1.2,2 Prioritize Delayed 2,8 1,4

1.2,3 Monitor Delayed 3.5 1.4

1,2.4 Dispatch Delayed 7 140

1,2.5 Format Delayed 14 7

34.3 299,8

14 300 35 50

5.6 2.8 .7 1

7 2.8 .98 2

14 280 24,5 50

28 14 3.5 5

68.6 599.6 64.68 108

4,2 5 COMMUNICATION

4 2.5,1 Network Control

4 2.5.2 Equipment Control

4 2,5.3 Status Monitor

4 2.5,4 Failure Detection/R,

4 2.5.5 Cmmd Prve

4 2,5.6 Interface Control

4 2.5,7 Telemetry Control

334.1

20 10

10 10

25 15

25 64

5 2

5 2

5 5

95 108

203

6-157

668.2

30 15 small small

15 15 25 35

35 25 2 3

50 64 10 20

5 2 10 15

5 2 5 6

5 5 200 3O0

145 128 252 379

273
Table 6.9,8

PLAIFORMTASKI FUNCTIONSMAPTO REFERENCECONFIGURATION

COMM & TRACKING (Page 2 of 2)

FUNCTIONS MEMORY (KBYTES)

IOC GROWTH

PROG DATA PROG DATA

DATA PROCESSING

(KOPS)

IOC GROWTH

2.5.3.5 OMV Status

(To remote customer)

2.5.4.6 OMV Status

(To remove customer)

COMM & "TRACKING TOTALS

NOT APPLICABLE TO PLATFORM

NOT APPLICABLE TO PLATFORM

605.7 1076.6 498.68 747

6-158
Table 6.9.8

PLAIFORM TASK i FUNC.TIONS MAP TO REFERENCE CONFIGURATION

FUNCIIONS

INFORMATION DATA MANAGEMENT SYSTEM (Page i of 4)

MEMORY (KBYTES)

IOC GROWTH

PROG DATA PROG DATA

DATA PROCESSING

(KOPS____.._

IOC GROWTH

2.1 Validate PL Cmmd 4 20 6 40

24 46

0.01 0.03

2.2 Check SSDS Serv. Req.

Restriction/Constraint

20 50 30 I00

70 130

1.7 3.75

2.3 Validate Core Cmmd/Data .i

2.3.1 and 2.3.2 .2

4 20 6 40

10 25 15 50

14 45 21 90

59 111

.01 .03

.01 .02

3.3 Develop Ops Event Sched.

3.3.1 to 3.3.4

212 455 265 530

667 795

1.33 1.58

3.4 Sequence Operations

3.4.1 to 3.4.4

60 26 95 41

86 136

.2 .4

4,3.2 Space Station Safety

4.3.2.1 to 4.3.2.4

15 3.5 25 11

18.5 36

small small

4.3.5 OPS & Procedure Supt.

4,3.5,1 to 4.3.5,5

130 133

263

6-159

132 132

264

0.3 0.6
Table 6.9.8

PLAIFORM TASK I FUNCIIONS MAP TO REFERENCE CONFIGURAIION

INFORMATION DATA MANAGEMENT SYSTEM (Page 2 of 4)

FUNCTIONS MEMORY (KBYTES}

IOC GROWTH

PROG DATA PROG DATA

DATA PROCESSING

(KOPS) _

IOC GROWTH

4.1,6 Time & Frequency Mgmt.

4.1.6.1 Time Source

4.1.6,2 Time Update

4.1.6,3 Freq, Source Mgmt

4.1.6.4 Device Mgmt

4.1.6.5 Cmmd I/F Proc.

0.5 0.2 0.7 0.3

2 0.5 3 1

1 0.3 2 0,5

0.3 0.1 0.5 0.2

0.2 0.1 0.4 0.2

0.2 0.3

small small

0.5 0,7

0.2 0,3

small small

4.0 1.2 6.6 2.2 0.9 1.3

5.2 8.8

5.1.1 Flt. Data Base Mgmt.

5 1 1,1 Update/Access Synch

5 1 1.2 Data File Mgmt,

5 1 1,3 Mass Memory Res. Mgmt

5 1 1.4 Archival Storage

5 1 1.5 Device Mgmt

5 1 1.6 Cmmd I/F Proc.

250 50 500 100 .25

12 140 20 200 small

10 4 20 10 small

NOT APPLICABLE TO PLATFORM

7 0.4 1.5 0.7 1

0.7 0.4 1.5 0.7 0.1

273,4 194.8 543 311.4 1.35

468.2 854.4

.5

small

small

1.5

0.2

2.2

6-160
Table 6,g,8

PLATFORM TASK i FUNCTIONS MAP TO REFERENCE CONFIGURATION

INFORMATION DATA MANAGEMENT SYSTEM (Page 3 of 4)

FUNCTIONS M__EMORY (KBYTES).

IOC GROWTH

PROG DATA PROG DATA

DATA PROCESSING

.... ....

IOC GROWTH

5.1.2 Fit. Resource Mgmt.

5.1.2.1 Load Scheduling 4

5,1,2,2 System Executive 570w

- OPERATING SYS. (OS)W 160

4

lO00W

- Network OS (NOS)* 410

5.1.2,3 Initialized Conf. Cont 30 18

5.1.2.4 Configur. Data Proc. 25 65

5.1.2.5 Facility Status 22 60

5.1.2.6 Recept. Dist. PL 65 140

5.1.2.7 Device Mgmt. 5 10

5.1.2.B Cmmd I/F Proc 12 4

163 301

B B small small

700w 1300_ % of % of

250 Application Application

450 I00 130

50 30 small small

50 100 small small

40 80 small small

BO 160 30 50

10 15 0,2 0.33

20 8 0.5 1.0

258 401 30,7 51,33

464 659

w5.1.2.2 Excluded from 5.1.2 total because OS applies to memory

configuration and NOS is contained in NIU,

5.1.3 Displays & Controls

5.1.3.1 Device Mcjmt

5.1.3.2 Cmmd I/F Proc

NOT APPLICABLE TO Pt.ATFORM

6-161
lable 6.9.8

PLATFORM TASK I FUNCTIONS MAP TO REFERENCE CONFIGURAIION

INFORMATION DATA MANAGEMENT SYSTEM (Page 4 of 4)

FUNCTIONS MEMORY (KBYTES)

IOC GROWTH

PROG DATA PROG DATA

DATA PROCESSING

_____L_OpS)

IOC GROWTH

4.5 Monitor & Status System

4,5.1 Monitor Core

4.5.2 Monitor Customer

4.5.3 Mass Prop. Conf.

4,5.4 Diagnostic Suppt.

4.5.4.1

4.5.4,2

4.5,4,3

4.5.5 System Test & Eval

4.5.6 Cmmd I/F Proc.

2.4 1.2 4,8 2.4

2.4 1.2 4.8 2.4

0.7 0.3 1.4 0.6

14 14 140 140

14 14 140 28

3.5 1.4 5.0 2.8

14 10 28 15

20 8 60 24

71 50.1 384 215.2

0.3 0.6

0.25 0,5

O.O1 0.02

1.4 14.0

1.4 2.5

0.35 0.50

0.7 1.4

1.2 3.6

5.61 23.12

IDMS TOTALS

121.1 599.2

2246 3639.4

m u

42. tl 84.36

6-162
Table 6.9.8

PI..AiFORM TASK 1 FUNC'TIONS MAP FO REFERENCE CONFIGURAT'ION

PAYLOAD AND SERVICING ACCOMMODATIONS (Page I of 2)

?

FUNCTIONS ME_K)RY (K .BYT__

IOC GROWTH

PROG DATA PROG DATA

DATA PROCESSING

__LKOpS')____

IOC GROWTH

2,4 Provide Ancillary Data 1.4 7 2.1 14

B.4 16.1

3.1 6.3

2,5 Support Customer Ops

2.5.1 Customer Data Proc.

2.5.2 Customer PLOPS

2,5,3 Support OTV OPS

2,5,3,10TV Service

2.5.3,20TV CO & D iag

2,5,3,40l_ Operation

W/OW

lOOW lOOW lOOW 200_ 0.08

25 25 50 50 ,03

NOT APPLICABLE TO PLATFORM

50* 365w

.OB

.03

2.5,4 Support OMV OPS

2,5,4,10MV Service

2,5.4,20MV CO & Diag.

2,5,4.3 Remote Ops Co.

2.5.4,50MV OPS

2,5,5 Customer Payload

Checkout Service

NOT APPLICABLE TO PLATFORM

25 1000 30 1200 small

1025 1230

small

2,6 SSPE CO AND SERVICE 100 i000 I00 I000 smal I s ma 11

ii00 II00

6-163
Table 6.9.8

PI_AIFORM TASK 1 FUNCTIONS MAP TO REFERENCE CONFIGURATION

PAYLOAD AND SERVICING ACCOMMODATIONS (Page 2 of 2)

FUNCTIONS MEMORY .(_

IOC GROWTH

PROG DATA PROG DATA

DATA PROCESSING

__._.__.._o__..EP .s1_._....

IOC GROWTH

4.4 Provide Cust. Avionic Sev

4.4.1GN&C Service

4.4.1.1Grd Track

4,4.1.2 Magnetic Field

4.4.1.3 Pallet Coarse

4.4,1.4 Relative Align

4.4.2 Contamination Control

3 1 6 2

1.5 0.5 1.5 0.5

10 2 20 4

7 4 10 6

21.5 7.5 37.5 12.5

29 50

12 8 24 16

0.5 1

0.3 .3

10 20

0.1 0.15

10.9 2] ,45

0.4 0.8

4.4.3 Tracking Services

20 40

NOT APPLICABLE TO PLATFORM

PAYLOAD AND SERVICING ACC.

TOTALS 2232.4 2801.1 14.51 28.66

6-164
7.0 (.,;ROUND SSDS DEI.:IN[TION

7.1 Introduction & Overview

'lh:[s section provides the preliminary design of the ground Space Station Data

System (SSDS). The ground program elements, the a11ocation of functions to

the elements and element topology are presented in Section 7.2. Section 7.3

highlights the operational data flow between these elements for selected data

types, which include core engineering data, payload data, uplink command data,

and Mission Operations coordination. The ground SSDS architecture is

presented in Section 7.4, beginning with an overview of the system

architecture and followed by subsections devoted to the more detailed

definition and architecture of each of the elements.

The prime inputs used to develop this preliminary definition were:

@

Task 1 - Requirements Definition

Task 2 - Options Development

Task 3 - Trade Studies

Langley Mission Data Base and Woods Hole Data

Customer Requirements for Standard Services from the Space Station

Information System

Team systems engineering

NASA guidance and feedback

Supporting options and trade studies include:

@ AI options

Standardization/commonality options

Communications standardization trade study

Distributed data base management trade study.

System management options

Command and resource management options and trade study

Mass storage options and trade study

Wide area processing options

7-I
Space autonomyand function automation trade study

Network topology trade study

The primary steps of the ground system definition process include:

General buildup from Task l's data flow diagrams and functional data

sheets

Allocate functions to space/ground as performed in the Space Autonomy

and Function Automation Trade Study

Define and characterize the ground elements through the allocation of

functions to the elements

Present a ground system topology and architecture that connects the

elements

Document the system definition and key design decisions made to date

A few points are noteworthy in understanding the scope of the ground

definition process. The First is that wide area communications, considered an

SSIS institutional service outside the SSDS, have been considered only to the

extent necessary to determine the feasibility o? the proposed designs.

Another point is that the system is sized based upon mission data derived from

the Langley Data Base as modified by the Woods Hole Meeting. In many cases,

the data is incomplete and requires supporting assumptions. For example, peak

data rates and duty cycles alone are inadequate to ascertain a true data flow

rate For some missions. Consideration of the interdependence among missions,

observation times, and data delivery times is required. Core traffic has also

been estimated based upon approximate requirements. The assumptions

associated with data traffic as applied to the ground system definition are

described in the Network Topology Trade Study. However, since many of these

assumptions are open to interpretation, the design has emphasized system

flexibility in order to accommodate growth and changes in data requirements.

Finally, it is important to note that each element of the ground SSDS is in

itself a large data processing system. Therefore, the scope of this

preliminary definition for each of the elements has been limited to the

definition of its interfaces, functions, and key architectural features.

7-2
7.2 Ground System Definition

7.2.1 Summary Of Key Assumptions & Approaches

The following major assumptions, and design decisions were made with respect

to programmatic issues, the space segment, SISS institutional elements, and

intepretations of requirements. They are summarized below since they have

major impacts on the system concept.

the KSA-R downlink will operate at constant rates of either i00 or

300 Mbps with fill data added onboard as required.

All low rate payload data will be multiplexed together onboard and

will be sent on one of two virtual channels (real time or playback)

on the KSA-R link.

Each high rate mission will be allocated one virtual channel for real

time and one virtual channel for playback data on the KSA-R link.

The real-time core and payload engineering (housekeeping) data will

be sent on the SSA. There will be one virtual channel each For core

engineering real-time and playback data and one virtual channel each

for payload engineering real time and playback data (four virtual

channels total). The Space Element will be identified in the CCSDS

Frame (Spacecraft ID). If customers have additional needs for real

time core and payload engineering data, it must be included in their"

payload stream.

Customers will be able to receive raw real-time data at any time it

is sent.

Data stored by the onboard SSDS or C&T system will be played back in

the forward direction and will not require reversal.

All core and payload telemetry and telecommand data are packetized,

using an identical bi.-directional CCSDS packet format. All packets

7-3
will be enclosed within bi-directional CCSDSframes. Convolutional

encoding will not be used. All low rate missions will be Reed-Solomon

(R.--S)encoded in CCSDScodeblocks. R-S encoding is optional for high

rate missions only.

Q Ancillary data will be provided on-board to the payloads, with the

Engineering Data Centers (EDCs) acting as a backup. NASA will not

support processing of ancillary data, but rather will provide

ancillary data in a standard form. Per the customer requirements, as

reflected in Task 1, if the standard data is not sufficient for

customer needs, more accurate or non-standard data is a customer

responsibility.

Processing is provided through Level 0 for all missions as a standard

SSD$ service for all packetized data. Data will be returned in the

form it was when given to the onboard DMS or C&T system, on a 24 hour

a day, 7 day a week availability.

It is acceptable to low data rate customers to receive their data

from a Level 0 Processing Facility.

Payload Operations Control Centers (POCC's) will not perform Level 0

processing and will obtain Level 0 data from a Level 0 Processing

Facility

Upper level processing beyond Level 0 will be supported by NASA at

Regional Data Centers (RDC's) but is not a standard SSDS service.

All Level 0 data must be routed to an RDC for upper Level processing.

RDCs are required to receive the level 0 data within at most 24

hours, as spe(ified in the Langley Mission Database. Missions which

specify a data delivery delay of "0" cannot be buffered, but must be

delivered in real-time.

• POCC's will need real-time data for quick look analysis.

7-4
As described in Sections 4 and 7.3.3, uplink payload data including

command are transparent to the SSDS. Uplink payload packets are,

therefore, routed directly to the DHC for transmission to the space

element.

The institutional Space Station data distribution network will be

augmented to support transparent switching of the low rate data, both

payload and core, using standard interfaces

Additional assumptions are listed as appropriate in the subsections below.

These assumptions are consistent within the tasks of the SSDS Study, but are

open to reasonable debate. Changes in some of the above may have a significant

impact on the ground system, as described in the Network Topology Trade Study

and as summarized in section 7.5.

7.2.2 Definition Of Ground System Elements

The Following ground Space Station program elements have been defined as a

result of the SSDS study. Some of these elements, such as Regional Data

Centers (RDCs), are in the SSIS but are listed since their functions have

impacts on the ground system concept. The proposed locations of the SSDS

elements are described in the Network Topology Trade Study. Changes in the

definitions and assumptions about these elements may impact decisions on the

overall topology.

7,2,2.1 Data Handling Center (DHC)

The Data Handling Center serves as the space/ground gateway between the TDRSS

Ground Terminals (WSGT and NGT) and the ground-to-ground data distribution

network. It receives and buffers data, routes virtual channels onto/from the

ground network, and provides uplink service authorization. The proposed DHC

location is at White Sands.

7.2.2.2 Ground Services Center (GSC)

The Ground Services Center (GSC) provides communication and common resource

coordination for the ground system, It serves to coordinate the scheduling of

7-5
the commurlication and ground facility resources shared among the Space

Station, (SOP, and POP operations control centers. These shared facilities

include the Data Handling Center, and the Level 0 Processing Facilities. The

GSC also collects status information from the shared facilities (outages, data

quality monitoring, etc) and prepares reports of this information for both

customers and the mission scheduling function at the OCCs. The GSC also

performs SSIS functions involving the collection of information on customer

usage of ground system elements and the processing of customer bills. The

proposed GSC location is at GSFC.

7.2.2.3 Payload Operations Control Centers (POCCs)

The Payload Operations Control Centers (POCCs) provide ground support for the

operation of a single payload instrument or complement of instruments. Control

and monitoring POCC functions that are unique to the payload applications are

outside the boundaries of the SSDS. However, the POCC functions that provide

standard services -- the interfaces to the DHC and the GSC, and that support

ground system managment are within the SSDS. POCCs are distributed among NASA

centers, RDCs, and customer sites.

7.2.2.4 Regional Data Centers (RDCs)

Regional Data Centers are SSIS elements that fall outside the SSDS boundaries,

but their location affects the SSDS architecture. An RDC's basic function, as

assumed in this study, is the support of higher level processing and archiving

of a single scientific discipline or group of related disciplines (at each

RDC). The RDC's receive, analyze (processing above Level O) and archive data

from many sources, including space entities as well as non-space sources.

Based on an analysis of 1997 mission data it is assumed that RDCs will be

established at GSFC, JPL, LARC, JSC, and MSFC and perhaps at customer sites.

7.2.2.5 Level 0 Processing Facilities (LZPFs)

l hese facilities remove space-to-ground artifacts within payload data. High

data rate LZPFs are co-located with RDCs at GSFC, JPL, and LARC. A low d,_ta

rate LZPF is centralized at GSFC to serve the other RDCs and customers.

7-6
7.2.2.6 Control Centers (CCs)

The Control Centers (CCs) provide ground support of core operations throughout

all mission phases, including man-tended and build up, as well as back-up

support. These centers include the Space Station Operations Control Center

(SSOCC), the Co-Orbiting Platform Control Center (COPCC), and the Polar

Orbiting Platform Control Center (POPCC). The SSOCC is located at %SC and the

POP and COP Control Centers are located at GSFC.

7.2.2.7 Engineering Data Centers (EDCs)

The Engineering Data Centers (EDCs) provide archival storage of Space Station,

COP, and POP core data and support program and customer requests for the

retrieval and analysis of historical data. One Engineering Data Center is

co-located with the SSOCC (at 3SC), and a second EDC is co-located with the

POP and COP Control Centers at GSFC.

The following describe important generic SSDS functions not generally

centralized at a specific SSDS facility.

7.2.2.8 Operations Control Network (OCN)

The Operations and Control Network element (OCN) provides networking functions

above layer 3 of the ISO/OSI model, that support the transparent connection of

applications at the various NASA centers. It provides both software

downloading control functions (linking together Control Centers, POCCs, etc)

as well as Space Station Program information (for customer access) and is

implemeted through a combination of commercially available ISO type software

utilities and gateways at the various faciltiies.

7.2.2.9 Development, Simulation, Integration, and Training (DSIT)

The Development, Simulation, Integration, and Training (DSIT) functions

support the development and integration of new or modified software,

integration of customer payloads, end-to-end communications checkout, crew and

ground controller training, and construction of simulation models for use at

remote sites. While the DSIT is defined as a program element, it is recogniz(_d

7-7
that, similar to the Customer Interface Element (CIE) functions, defined in

7.2.2.10 below, the DSIT functions will be distributed throughout the ground

system and that elements of the DSII will appear at each control center, LZPF,

RDC, and facility that involves software development and simulation. A major

part of this element, the Software Support Environment (SSE), is described in

Section 8.2.

7.2.2.10 Customer Interface Elements (CIEs)

Customer Interface Elements (CIEs) provide a standard interface to customers

and a connection between the customer and the services of the Space Station

Program. The elements allow a customer to "dial in" to a NASA location (RDC,

POCC, etc), access a menu-driven interface describing the services of the

Space Station Program (scheduling, archival data catalogs, etc) and be

connected via the Control Network to a selected service. The actual service

might be local to that center or it might be located at another location.

Specific functions accessed by this single point of Customer Contact to SSP

Services include:

D

Logon/Authorization to access SSIS Services

Communication and common services coordination (access to GSC)

Space Station Program Databases (Authorization and transparent access)

Control Center services (Access to Scheduling)

Archival data catalog services

Uplink Access (Access to DHC)

IMIS Interface

Bulletin boards and electronic mail for sharing information among

users and with the Space Station program

While the CIE is defined as a program element, it is recognized that the

foregoing functions are actually distributed throughout the ground system and

that CIE functions will appear at each NASA center. A detailed design for this

element is therefore not shown. The implementation of these functions should

present an identical interface to customers no matter which NASA center

implements them.

7-B
7.2.3 Partitioning/Allocation of Functions to Elements

Fable 7.2.3-I maps the lower level functional requirements, which were derived

during Task 1 of the SSDS A/A Study, to the ground elements. The tracing from

the 2-digit level Function is shown For completeness. Tracing back to Task 1

source requirements is provided in the Task 1 report. In many cases only a

subset of the lowest level functions of a given portion of the Function list

are implemented, lhis is especially true for the Control Centers which provide

support and back-up to the onboard Functions. The strawman locations of the

SSDS elements are shown on Table 7.2.3-2.

7.3 Key Operational Features

The purpose of this section is to describe data flow between the various

ground elements defined in Section 7.2

7.3.1 Core Engineering Data Management

The SSDS provides core operations/administrative data to support the ground

operations associated with the payloads and the core systems. The ground

Flow of core engineering data is depicted in Figures 7.3.1-I and 7.3.1-2.

7.3.1.1 Payload Operations Support

The onboard SSDS provides time-stamped core engineering ancillary data to the

payloads. The data is provided in standard engineering units, and any

reformatting/refinement of the data is a customer responsibility. The payload

incorporates the ancillary data into its payload CCSDS packets, which are

downlinked and distributed to the Level Zero Processing Facilities and

POCC/customer facilities. (See Section 7.3.2 for a more detailed discussion

of payload data management.) 'Thus, the ancillary data required for the ground

control of the payload and For production data set generation is contained

within the payload packets.

The SSDS also provides a non-real-time service of electronic access to the

core engineering data archives, which are contained within the EDC, For the

retrieval of historical data.

7-9
Table 7.2.3-I

Ground Element Function Allocation

Element Functions

Data Handling

Center (DHC)

Low & High Rate

Level 0 Processing

Facilities (LZPFs)

Level 0 Processing

Facility (LZPFs)

l.l Manage Real Time Data Return

l.l.4 Dispatch Realtlme Data

(reqs 5.3.1.1.a,b)

1.3 Data Distribution

1.3.1 Preprocesslng (Frames) 1.3.2 Data

Capture (Bulk Record)

1.3.3 Routing & Transmission

1.3.4 Quality Verification

2.1 Validate Payload COmmands/Data

2.1.1 Authorized User

2.1.2 Authorized Address

2.3 Validate Core Commands/Data

2.3.1 Authorize Operator

5.2 Manage Ground System Facilities

5.2.1

5.2.2

5.2.3

5.2.4

5.3.5

5.2.6

Interface Management

Schedule/Status Compare

Transmit Reconflguratlon Schedule

Ground Status Database Management

Adjust For Unscheduled Mode Change

Displays & Controls

l.l Manage Real Tlme Data Return

l.l.4 Dispatch Realtlme Data

(reqs 5.3.1.1.a,b)

1.4 Manage Deliverable Customer Data

l .4.1

l .4.2

l .4.3

l .4.5

l .4.6

l .4.7

Customer Data I/F Mgt

Customer Data Capture

Customer Data Handling

Level 0 Customer Data Processing

Customer Data Accounting

Routing & Transmission

5.2 Manage Ground System Facilities

5.2.1

5.2.2

5.2.3

5.2.4

5.3.5

5.2.6

Interface Management

Schedule/Status Compare

Transmit Reconflguratlon Schedule

Ground Status Database Management

Adjust For Unscheduled Mode Change

Displays & Controls

7-10
Table 7.2.3-I

Ground Element Function Allocation

Element Functions

Ground Services

Center (GSC)

Control Centers (CCs)

7.2 Log Customer Usage Of System

5.2 Manage Ground System Facilities

5.2.1

5.2.2

5.2.3

5.2.4

5.3.5

5.2.6

Interface Management

Schedule/Status Compare

Transmit Reconflguratlon Schedule

Ground Status Database Management

Adjust For Unscheduled Mode Change

Displays & Controls

1.5 Manage Deliverable Core Data

1.5.1 Core Data Interface Management

1.5.2 Core Data Capture

1.5.3 Data Extraction

1.5.4 Displays & Controls

2.5 SupportCustomerSystem Operation

2.5.3 Support OTV Operations

2.5.3.4 OTV Operation

2.5.4 Support OMV Operation

2.5.4.5 OMV Operation

2.5.4.6 OMV Status Report

3.1 Develop Recurring Operations Masters

3.1.1 Develop Normal Day Payload Operations

3.1.2 Develop Normal Day Space Operations

3.1.3 Identify Potential Conflicts

3.1.4 Develop Major Event Payload Operations

3.2 Develop Short Term Schedules

3.2.1 Confirm Payload & Core Schedules

3.2.2

3.2.3

3.2.4

3.2.5

3.2.6

3.2.7

Incorporate New/Revlsed Operations

Check For Conflicts

Check For Facilities Capabilities

Resolve Conflicts

Check Unresolved,

Restrlcted/Constralnted Commands

Maintain Short Term Schedules/Develop

Operating Events List

4.1 Operate GN&C Systems

4.l.1 Navigation

4.1.l.l Space Station State/Orblt

Determination

4.1.I.7 Command Interface

Processing

7-11
Table 7.2.3-1

GroundElement Function Allocation

Element

Control Centers

(Cont)

r

(ccs)

4.2

4.3

4.1.2

4.1.3

4.1.4

4.1.5

4.1.6

Functlons

Guidance

4.1.2.1

4.1.2.7

Attitude

4.1.3.1

Reboost/Reentry Targeting

Command Interface

Processing

Control

Control Attitude

& Translation

4.1.3.2 Maneuver Coordination

4.1.3.3 Momentum Mgt

4.1.3.4 Pointing Mount Control

4.1.3.5 Device Mgt

4.1.3.6 Command I/F Processing

Traffic Control

4.1.4.5 Target Coll

4.1.4.6 Command I/F

Tracking

Islon Avoidance

Processing

4.1.5.6 Command I/F Processing

Time & Frequency Mgt

4.1.6.5 Command I/F Processing

Operate Non-GN&C Systems

4.2.1 Operate Power System

4.2.1.7 Command I/F Processing

4.2.2 Operate Thermal Control System

4.2.2.4 Command I/F Processing

4.2.3 Structures & Mechanism Support

4.2.3.5 Command I/F Processing

4.2.4 ECLSS Operatlon

4.2.4.7 Command I/F Processing

4.2.5 Communication

4.2.5.5 Command Processing

Support

4.3.1

4.3.2

4.3.4

Flight Crew Activities

Health Maintenance

4.3.1.2 Medical Diagnostic

4.3.1.3 Treatment Support

4.3.1.7 Command I/F Processing

Space Station Safety

4.3.2.1 Caution & Warning

4.3.2.2 Abnormal & Emergency

Procedures

4.3.2.4 Command I/F Processing

EVA Support

4.3.4.5 EVA Real Time Monitor &

Control

4.3.4.10 Command I/F Processing

7-12
Table 7.2.3-I

Ground Element Function A11ocatlon

Element Functions

Control Centers (CCs)

(Cont)

Engineering Data

4.4 Provide Customer Avionlcs Services

4.4.3 Tracking Services

4.5 Monitor & Status System

4.5.3 Mass Properties Configuration Update

4.5.4 Diagnostics Support

4.5.4.1 Fault Analysis

4.5.4.2 Fault Correction

4.5.4.3 Trend Analysis

4.5.6 Command I/F Processing

5.1 Manage Flight System Facilities

5.l.1 Flight Data Base Mgt

5.1.I.2 Data File Mgt

5.1.I.6 Command I/F Processing

5.1.2 Flight Resource Mgt

5.1.2.8 Command I/F Processing

5.2 Manage Ground System Facllltles

5.2.1

5.2.2

5.2.3

5.2.4

5.3.5

5.2.6

Interface Management

Schedule/Status Compare

Transmit Reconflguratlon Schedule

Ground Status Database Management

Adjust For Unscheduled Mode Change

Displays & Controls

1.4 Manage Deliverable Customer Centers (EDCs)

Data

1.4.4 Ancillary Data Acquisition

1.5 Manage Deliverable Core Data

1.5.5 Engineering Data Analysis

1.5.6 Core Data Accounting

5.2 Manage Ground System Facilities

5.2.1

5.2.2

5.2.3

5.2.4

5.3.5

5.2.6

Interface Management

Schedule/Status Compare

Transmit Reconflguratlon Schedule

Ground Status Database Management

Adjust For Unscheduled Mode Change

Displays & Controls

7-13
Table 7.2.3-2

Proposed Locations Of Elements

(Based on Igg7 Mission Data Base)

Element

Data Handling Facility

Level 0 Processing Facility

(Low Rate)

(High Rate)

Space Station Operations

Control Center

Co-Orbltlng Platform

Control Center

Polar Orbiting Platform

Control Center

Engineering Data Centers

Payload Operations Control

Centers (SSIS)

Regional Data Centers (SSIS)

Proposed Location

White Sands

Goddard Space Flight Center

GSFC, 3PL, LARC

3ohnson Space Center

Goddard Space Flight Center

Goddard Space Flight Center

I) aohnson Space Center

2) Goddard Space Flight Center

Distributed

Goddard Space Flight Center

3et Propulsion Laboratory

Langley Research Center

aohnson Space Center

Marshall Space Flight Center

"This design approach offers the customer the advantage of immediate

availability of the time-homogeneous ancillary data required for payload data

processing and payload control. Other approaches, such as the obtaining of

ancillary data from a ground replication of the onboard database, have the

potential for imposing delays in the delivery of the data. Also, the problems

associated with the provision of the data, be it through queries, broadcasting

of data sets, etc., are the same whether they are to be solved onboard or on

the ground. A ground-oriented approach adds the complexity of managing the

replication of the birthsite, onboard database to satisfy the requirements oF

the payload users and is recommended only if the proposed approach proves

infeasible due to onboard processing or bandwidth limitations.

7-14
®

•,, I I .-

OOoooon___ I _ _

emu*_immn _ _j_nmo _ _ m

OOOOOo O

OOOo0

OOOo O

""

,_o • o ooo°

 _JG

(_) May Be Remotely Located;

Logical Flow Indicated

_) Provides Near-Real-Time

Status Data to Other

Control Centers During

Joint Operations

O0000OO

Space Station Core Data

P/F Core Data

Payload Data (Merged Ancillary Data)

Backup Routing (During Primary

EDC Failure)

Figure 7.3.1-1. Real-Time Core Engineering Data Flow

7-15
SS

EDC

Space

Element

DHC

/

/

/

/

• /

/

!\

\

@

\

\

• \

\

Space Station Core Data

P/F Core Data

• _ Backup Routing (During

Primary EDC Failure)

Figure 7.3.1-2. Retrieval of Archival Core Engineering Data

P/F

EDC

Post-recovery

Data Transfers

/

/

/

/

/

7.3.1.2 Core Operations Support

Core operations/administrative data packets to support the Space Element's

core ground operations are downlinked within dedicated virtual channels (one

7-16
r'eal-tin_e and one playba('l< ) within the SSA return link. ]he DfIC routes

these channels to the appropriate (JSC For Space Station and GSFC for

platform) NASA Center gateway. At the gateway, the packets are extracted

and, based upon the application ID, routed to the appropriate node(s).

These nodes include the Control Center/Mission Scheduling, the EDC, and other

Ground Services.

Packets containing core engineering (Space Element status) data are routed to

the Control Center and the EDC. The Control Center utilizes the data for its

core operation's monitoring and control Functions. It also extracts Space

Element status and incorporates it into operations messages which it sends to

other Control Centers involved in joint operations and to supporting

institutional facilities (e.g. the Flight Dynamics Facility For platform

support).

The EDC creates and manages the full-rate fu11-sample core engineering

database. It serves the Control Center and the Space Element as the highest

priority users For the retrieval of core data sets, report generations, and

common data analyses (e.g. plots). There are two EDC's, and they each

provide a limited backup of the other's Functions. In the event of the

Failure of a Control Center's primary EDC, data destined For the failed EDC

is routed to the alternate EDC. The alternate EDC stores the data and

services requests from the Failed EDC's Control Center and Space Element.

The available data sets are limited to those acquired since the

Failure-induced handover. The alternate EDC continues to provide its normal

services, though it may reprioritize the requests. Upon recovery, the

primary EDC requests the transfer of its saved data sets From the alternate

EDC.

The ground system flexibility is also dependent upon the amount of

preprocessing which is required (and which would have to be duplicated) to

render the core engineering data useful to the EDC's and Control Centers.

is assumed the onboard system provides data with the Following attributes:

It

forward direction, no reversal required

engineering units (level 1A), no PC_ calibrations required

7-17
...... stable formats, air/ground communicated formats, or formats that are

defined by data contents (e.g. parameter ID's and pointers contained

within the data), no offline reconfiguration processes required

..... groupings by subsystem, minimal sorting required for inclusion into a

database manager.

Packets containing Space Station service-oriented data messages are also

managed by the JSC gateway. The gateway processing may include a service

manager that provides protocol conversion and message routing between the

air-to-ground, (]CSDS format and the ground distribution, ISO Format. It is

assumed that there is an onboard service manager, analogous to the ground

service manager, that manages the service-oriented messages. The extent of

the managers' processing is dependent upon the compatibility of the CCSDS and

ISO formats and the ability of the addressed services to handle the two

formats. Source and destination identifiers within the CCSDS format would

simplify the role of the service managers, since the services support

multiple users and any user can choose among multiple services. Rn example

is a scenario where a crewperson at an MPRC wants interactive access to one

of the ground services, such as archival data query/retrieval. For roundtrip

routing, both the user's MPRC and the archive must be uniquely identified. R

multitude of ID's may be required to provide unique mappings for all

possible combinations or application-level processing (service managers) of

the packet data fields is required to determine the routing. R similar

problem exists For space/ground inter-processor communications.

7.3.2 Payload Data Mangement

Payload data procesing will impose the greatest burden on the SSDS; the high

data rates and rapid delivery requirements establish a significant technology

demand on the ground system. Payload data flow is depicted in Figure 7.3.2-I.

As mentioned in Section 7.2.2, all low rate mission payload data (less than 10

Mbps) will be multiplexed together onboard and will be sent on one of two

virtual channels (real time or playback) on the KSA-R link; and each high rate

mission's payload data will be allocated one virtual channel for real time and

one virtual channel for playback on the KSA-R link. In addition, a predefined

subset of core ancillary data will be embedded into the payload packets for

7-18
KSA

SSA

KSA

SSA

Virtual

Channel

Splitter

_Nhite Sands)

/

P/L Engineering >

I

J Low-Rate P/L >

i

I High-Rate P/L /

Low-Rate LZPF

(at GSFC)

7-Day Archive

High-Rate LZP

Facilities

7-Day Archive

KS.___A

2 Virtual Channels for Each High-Rate Payload (1 R/T, 1 PLBK)

2 Virtual Channels for Composite Low-Rate Payload (1 R/T, 1 PLBK)

SSA

2 Virtual Channels for Core Engineering (1 R/T, 1 PLBK)

2 Virtual Channels for Composite Payload Engineering (1 R/T, 1 PLBK)

Figure 7.3.2-1. Payload Data Flow

To POCCs

R/T P/L and P/L Eng (Real Time)

_444 To RDCs

LZP Data Sets / (Upper Level Proc)

R/T P/L Data

LZP Data Sets

To POCCs

(Real Time)

To RDCs

(Upper Level Proc)

use in real time quicklook functions at POCC's and/or upper level processing

functions at RDC's. All payload engineering data will be allocated one

virtual channel for real time and one virtual channel for playback on the SSA

channel. The DHC at White Sands performs the frame synchronization for all

channels and removes ?ill Frames.

Each frame synchronizer has a Reed-Solomon Error Correction Decoder and all

data from the Frame sync is fed to it. If the decoding is successful, the

data is assumed to be R-S encoded, it is so tagged, and all further processing

occurs on the corrected data. If the decoding is unsuccessful, it is so

tagged, and processing is done on the uncorrected data. This is done on a

frame-by-frame basis so that some virtual channel may be encoded and others

not. Subsequent to this correction and check, the virtual channels are

identified, separated and virtual channel accounting begun. The Processing,

Accounting, Quality Monitoring and Fault Isolation Functions can be accessed

by RDC's, POCC's and independent users.

The level O processing would then be performed either at the low rate LZP

Facility located within GSFC or at high rate LZP facilities collocated at

RDC's. This process consists of packet reordering and gap filling to create

7-19
contiguous data sets on a payload-by-payload basis. The real-time data will

be packet routed to POCC's for quicklook purpose as needed.

Processing oF payload data beyond level zero processing is outside the

boundaries oF the SSDS and, therefore, not discussed here.

Payload Data Traffic is provided in Figure 7.3.2.-2 and is based on the Langley

Data Base for the year 1997.

7.3.3 Uplink Command Data Management

In order to understand the ground topology for the flow of uplink command

data, it is important to understand the end-to-end design for command

management. This design is presented in Section 4. Table 7.3.3-I summarizes

the command management functions of each of the ground elements and provides

reference to the sections that define these functions in greater detail.

The design feature which drives the ground SSDS topology is the transparent

handling of the payload command data. Since the SSDS performs no checks on

the payload commands, there is no requirement that they be routed through the

Control Center. The uplink payload command packets generated at POCC's and

customer facilities are routed directly to the ground/space gateway, the

Data Handling Center.

Uplink core command packets generated at the Control Centers are also routed

to the DHC. It is not necessary that COP core command packets be routed via

the SSOCC,

lhe DHC maintains a log of received packets, collects the packets and Frames

them in accordance with the CCSDS formats. Encryption of the uplink Frames

for transport to the Space Element, if required by the Space Station Program,

would also be a DHC responsibility.

The flow of uplink command data is depicted in figure 7.3.3-.I.

7-20
E_

r..1o

r_ml iiiIIIIIIIIIII

a. N

,,,.,.I

C

I,Ll W

w p_

_w

_. _.

8_

,Jco_

E_

W

F- I

o_

o"_.

W

I-- I

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

Ol

I--

7-21

0

I.-

._o"

Itll

_o

>,,

¢11

m.

p,,, P

I.i.
ELEMENT

Control Center

Engineering Data

Center

POCC's or

Independent

Customers'

Facilities

Data Handling

Center

Table 7.3.3-1

Command Data Management Functions Map

To Ground Elements

FUNCTIONS

Mission Scheduling

e Development/Maintenance of Mission

(P/L and Core) Operatlons/Attributes

Database

• Development/Maintenance (Change) of

Operating Events Schedule

Mission Operations: Core Cmd-Management

Operator Authorization

Access Control to Command Sets and

Software Loads

• Command Generation

• Command Validation

- Safety

- Effectivity

- Schedule Compliance

- Etc.

• Verification of Recelpt/Executlon

• Management of Two-Stage and Stored

Program Command Sequences

• CCSDS Telecommand Packet Build

Capture and Archival Storage of

Command Data

• Upllnked Telecommands

• Downllnked Command Logs

Payload Operations: Payload Cmd. Mgmt.

• Payload-Speclflc Functions

Analogous to those performed by the

Control Center for Core Commands:

- Operator Authorization

- Access Control to Command Sets

- Command Generation

- Command Validation

- Verification of Recelpt/Execution

- Management of Stored Program

- Command Sequences

• CCSDS Teleco,nmand Packet Build

Ground/Space Gateway Management

• POCC and Customer LOGON

• Upllnk Authorlzatlon

• CCSDS Frame Build

• CCSDS TC Transfer Layer Services

REFERENCE

SECTION

7.4.6.2.6

7.4.6.2.2,

7.4.6.2.4,

7.4.6.2.5

7.4.7.1,

None (Ground

SSlS functions

listed for

completeness)

7.4.2.2

7-22
Space

Element

SSOCC

©

ss

EDC

DHC

°ooo

° o

o o

o o

o o

°ooo

o o

o o

°°ooo

Space Station Command Uplink Data

P/F Core Command Uplink Data

• • • • • • • Payload Command Uplink Data

ql

Figure 7.3.3-1. Command Uplink Data Flow

o•

\

Q Capture Data for ofArchival Core Uplink Storage

7.3,3.1 Payload Uplink Command Data Management

Payload uplink packets can be issued from customer facilities and POCC's

distributed throughout the ground system.

7-23
In order to issue uplink packets, the customer or POCC logs on to the Data

Handling Center. LOGON includes providing a password ID. POCC's providing

continuous support can remain logged on to the DHC. As an optional service,

the user can request a schedule report containing information on his

scheduled payload activities and information of general interest, e.g

trajectories or TDRSS communication timelines. The report is requested from

the Control Center's Mission Scheduling System which routes it to the user.

The user can also request connection with the Mission Scheduling System to

negotiate schedule changes.

After LOGON, the customer/POCC creates uplink CCSDS packets which are routed

via the ground network to the DHC. The DHC performs an uplink authorization

check on each of the packets by checking the application (destination) I0 vs.

a table listing the ID's which this source, the customer or POCC, is

authorized to address. The authorization table is created prior to the

mission and is controlled by the Ground Services Center (GSC). Packets

which successfully pass this check are input to the frame build process. The

payload frames are uplinked on the TDRSS KSA-F link. Packets which fail the

uplink authorization check are rejected, and notifications are sent to the

customer/POCC and to the GSC communications security monitoring function.

Provision of additional privacy/security measures, e.g. encryption of the

command data, is a customer/POCC responsibility. The SSDS only requires that

the header information remain clear.

7.3.3.2 Core Uplink Command Data Management

Core uplink CCSDS packets are issued from the Control Center. They are

routed over the NASA Center Network, and the Engineering Data Center

captures and archives the packets. From the Center's gateway the packets are

routed to the Data Handling Center, where they are built into CCSDS frames

for transmLssion on the TDRSS SSA-F link.

The Control Center is continuously logged on to the Data Handling Center. A

threat analysis is necessary to determine the security measures required for

the Control Center-to-DHC link. Encryption of the packet data fields, if

required, would be a function of the NASA Center gateway.

7-24
7.3.4 Mission Operations Coordination

lhis secti.on describes the flow of schedule and status data throughout the

?gr'ound SSDS in support of mission operations. The end-to-end design For

system control/management is presented in Section 4.4. ]able 7.3.4-i

summarizes the mission coordination functions of each of the ground elements

and provides reference to the sections that define these functions in greater

detai I.

Figure 7.3.4-1 depicts the interfaces for the flow of schedule and status

data and the general order of precedence for schedule generation and status

reporting. In general, the order reflects the hierarchical nature of the

controlling elements. Each element provides to lower level elements the

scheduling and status information required to perform their functions and

receives from them only the status information which can impact the higher

level schedule.

Considering the many interfaces required for mission coordination, the

standardization of the SSP scheduling and status reporting systems is highly

desirable. Commonality is particularly needed between the Space Station and

Platform Mission Scheduling Systems considering the number of elements and

customers which may require interfaces to both systems.

The types of schedule and status information required for mission

coordination break into two basic categories: operations and communications.

7.3.4.1 Mission Operations

Mission operations information includes the scheduling and statusing of the

mission activities. Mission scheduling is a Function of the centers

controlling the Space Elements. The hierarchy among the control centers is:

•-- STS MCC

..... Space Station OCC

•- Platform _]C

.... POCC

...... OMV/OTV Remote Operations CC

- Free Flyer OCC

7-25
Table 7.3.4-1

Mission Coordination Functions Map

to Ground Elements

ELEMENT

SSOCC

COPCC/POPCC

Ground Services

Center

EDC's

POCC's,

Customers

FUNCTIONS

Space Station Mission Schedullng/Status

• P/L Modes

• Onboard Core Operations

• Proximity Operations

• Ground Resources

SSOCC Facility Management

• Interface to SS Mission Scheduling

• Interface to GSC Comm. Status

Platform Mission Schedullng/Status

• P/L Modes

• Onboard Core Operations

• Ground Resources

COPCC/POPCC Facility Management

• Interface to Mission Scheduling

Communication Scheduling Status

• Interface to Mission Scheduling and

Network Control Center (NCC)

• Status Interface to each Ground

Facility

Common Resource Schedullng/Status

• Data Handling Centr (DHC)

• Level Zero Processing Facilities (LZPF)

Facility Management

• Interface to Mission Schedullng/Status

• Interface to GSC for Comm. Status

Payload (Independent) Operations

Schedullng/Status

Facility Management

• Interface to Mission Schedullng/Status

• Interface to GSC for Comm. Status

REFERENCE

SECTION

7.4.6.2.6

7.4.6.2.5

7.4.6.2.6

7.4.6.2.5

7.4.3.2.2

7.4.3.2.3

7.4.7.2.4

None (SSIS

function)

7.4.4.2.8

7-26
Table 7.3.4-I

Mission Coordination Functions Map

to Ground Elements (cont'd)

ELEMENT

DHC,

LZPF's

NCC

STS MCC

OMV/OTV Remote

Operations

Control Center

Free Flyer

Control Center(s)

FUNCTIONS

Facility Management

• Interface to GSC Common Resource

Schedullng/Status

TORSS/NASCOM Schedullng/Status

• Interface to GSC Communication

Schedullng/Status

STS Mission Schedullng/Status

• Interface to Mission Scheduling

OMV/OTV Remote Operations Scheduling/

Status

• Interface to Mission Scheduling for

Proximity Operations

Free Flyer Schedullng/Status

• Interface to SS Mission Scheduling

for Proximity Operations

REFERENCE

SECTION

7.4.2.3.5

7.4.5.2.5

None (SSIS

function)

None (SSIS

function)

None (SSIS

function)

None (SSIS

function)

where layers are present only as applicable to joint operations. For

operations within the proximity of the Space Station, the SSOCC is the

controlling ground element with the exception that its schedule is generally

dependent upon the STS schedule for operations involving the shuttle.

The mission schedule, as output from the Space Station and Platform OCC's,

drives the scheduling of the ground resources. These resources include 1)

the ground facilities dedicated to mission support, i.e. the Control Centers,

POCC's, and EDC's; and 2) the shared communications and data handling

resources managed by the Ground Services Center. The facility managers

within the dedicated Facilities and the GSC in turn schedule and status

their resources, reporting to Mission Scheduling only the status and change

requests that impact mission operations.

7-27
I

I

m

I

I

I

I

E E._-

_' 9"3

$oo_'6

>,(9 Q 0 _

I

I

I

I

I

o Ec

_Q.. O'--

14.fO v,*

._ Q,,. (.3

:0-_0_

_L _ _

I i

I

E

C

.>o_.

._,

_-o0

r 1

I = I

F-FI I

L j

,E

o "5

i 1[

I II

I Z ._ ii _

0 "5 >=

I _o_ Ii _®

I _o_, I ""

I I I ,,"_

L___ L_ V

_o

0

C

°_

I =

I1

7-28
]he mission operations schedule and status data tends to be low volume and

aperiodic (event driven) in nature. The exceptions are the periodic

reporting of core status among the Control Centers and the periodic

broadcasting of timelined information of general interest, e.g. ephemeris.

7,3.4.2 Communications

The mission schedules, as derived by the Space Station and Platform Mission

Scheduling Systems, are input to the Ground Services Center. The GSC

develops a communications schedule and schedules the common data handling

Facilities as required to support mission operations.

The GSC coordinates with the Network Control Center (NCC), on behalf of all

SSP elements, the scheduling of the TDRSS and NASCOM communication

resources. It also schedules and configures the data handling facilities,

the DHC and level zero processing facilities, for mission support.

The GSC receives status reports from the NCC and from the DHC and LZPF

facility managers and coordinates reconfigurations. The GSC provides data

flow reports to the mission-dedicated facilities' managers and a summary

report to the OCC's Mission Scheduling System. Problem resolution occurs on

the facility level, and only those problems which cannot be resolved and

which impact mission operations are reported to Mission Scheduling.

]he scheduling data and status reports to Mission Scheduling tend to be low

volume and aperiodic (event-driven) in nature. The data flow reports to the

individual facilities are short status messages that are issued periodically

(approximately every five seconds).

7.4 Strawman Architecture

7.4,1 Overview

This section provides an overview of the SSDS ground system. Subsequent

sections will provide detail concerning interface definition, functional

descriptions and design approach for each of the ground elements.

7-29
Figure 7.4.1.-I provides an overview of the ground system. Correspondingly,

Figure 7.4.1-.2 defines the space/ground data as a function of TDRSSsingle

access K and S-Band channels betweenthe ground and SpaceStation/Platform

elements, Figure 7.4.1-3 defines the ground system traffic relative to the

type of traffic which will flow between the ground system elements.

The approach to data distribution from the point of ground system receipt at

the White Sands/NASA Ground Terminals and handling of the level 0 processing

functions features a "hybrid system" m a hybrid of both centralized and

distributed processing. The Network Topology Trade Study that supports this

approach is provided in the Task III report, Volume I, Section III.

To review, the primary dependencies on the space element in implementing the

hybrid approach are as follows:

@ all data is packetized and framed in an identical CCSDS format

all low rate payload data (less than 10 Mbps) is transmitted in

either a real time or playback virtual channel

each high rate payload uses two virtual channels, one for real time,

one for playback

core data is assigned two virtual channels (real time and playback)

payload engineering data is sent as a composite of all payloads

multiplexed on two virtual channels (real time and playback)

With this data definition onboard, the Data Handling Facility at White Sands

splits and routes the virtual channels to the ground elements as follows:

low rate payload data and payload engineering data to GSFC for real

time distribution to POCCs (required for real time operations), and

level 0 processing for data set distribution to designated RDC's.

High rate payload data to high rate Level 0 Processing Facilities

(LZPF) at GSFC, JPL, and LARC for as needed real time distribution to

related POCCs, and level 0 processing for data set distribution to

designated RDCs which are assumed to be co-located with the high rate

LZPFs. Note that this identification is based on the Igg7 Langley

7-30
ORIGIN[_,L PAGE IS

OF POOR QUALITy

COP Core

Commands/Data

V_cleo

COP Core

Sch_fe/Status

POP Core

POP Core

Video

CommandslDa

Archive Retrievals

(Ground to Soace)

SS Core Audio

Audio

Video

Archive

Retrieval

Archive Ret.

Schedule/Status

Schedule/Status

Schedule/Status/Records

Low-Rate PIL Data Archive Retrieval

A rchieve Retrieval

Schedule/Star us/Records

IL Eng

P/L Eng Data

High-Rate

P/L Control

Archiv,

Archive Retrieval

ScheduleStatusRecords

Schedule Coordnidatlor,

Archive Retrieval

Archive Retrieval

Schedule/Status/Records

I

I

Commands

Data P/L Control t

Archive

Retrieval

Archive Retrieval

Schedule/S tatus/R ecords

Schedule Status

Archive Retrieval

Figure 7.4.1-1.

R/T, and

Production

RIT P/L and

P/L Eng Data

Commands

Ground SSDS Topology

Archive Retrieval

SchedgielB illing/R ecord$

Schedule Coordination

7-31
Space Station

SSA Up

SSA Down

KSA Up

KSA Down

POP

SSA Up

SSA Down

KSA Up

KSA Down

/ 6 /

i

l

i

I I

xix x i

x x ix x!

I x

• x i

=

x i x

I

-I

x l

X

i

X X

Figure 7.4.1-2. Space-Ground Data Definition

X

database and could change as high rate missions are added or" de].eted

from the program

core data to the appropriate Control Center for real-.time morl:itor:[rlg

and control, and archive in the Engineering Data Center.

Customers interface into the ground system for payload control thr'ou(.]han

existing POCC (either at the POCC or via remote ter'minals connected via a

Customer Inteface Element) or as independent customers with direct command

interface through the DHC. Customers receive their level 0 processed data

through an LZPF or through designated RDCs (not an S,(;DSe].ement). It should be

not:ed that independent customers, especially for high rate payloads, cou].d

provide their own level 0 processing Furlctior_.

7.4.2 Data Handling Center (DHC)

In the strawman design, the Data Handling Center (DHC) serves as l;he

space/ground gateway ...... receiving, buffering, and routing data to the !..Irourid

data distribution network From the T'DRSS (_round system and vice w_rsa. Fhe

DHC, is ].ocated at White Sands and directly :interf_ac.es to the exisi;:i.ngand

futur'e NASA Ground Ter'minals, and to the Data Distribution Network (e.g.,

7-32
SS Core

COP Core

POP Core

SS Cmd Up

SS Data Up

COP Cmd Up

COP Data Up

POP Cmd Up

POP Data Up

Archive Retrievals

High-Rate Video Up

High-Rate Video Down

Low-Rate Video Up

Low-Rate Video Down

Audio Up

Audio Down

SS Payload Data

SS Payload Eng Down

$S Payload Cmd Up

COP Payload Data

COP Payload Eng Down

COP Payload Cmd Up

POP Payload Data

POP Payload Eng Down

POP Payload Cmd Up

Schedule Coord

xI

xlx

X

X

X X

X X

X

X

X

xl

X:

X!

X

X X

X X

xl

X

X

X

X

X

X

X

X

X

X_

X X

X X

X X

X

X

X

X X

Figure 7.4.1-3. Traffic Link Assignments

x

x

X X X X X X X

X X X

X X X

X iX X

XlX X X X X

X X X

X X X

X X X

iX X X

X X

X X!X

X X X

X X

X X X

X X X

X X

XXXXXX

NASCOM). The strawman design emphasizes a relatively simple DHC which

d:lrectly pipes most data to LZPF's the SSOCC, or platform OCC's at major NA'SA

centers for further processing. Uplink frame build and uplink authorization,

however are performed at the DHC due to its centrality as the ground/space

gateway.

7.4.2.1 Functional Interface Description

1"he functional interfaces for the DHC, illustrated in Figure 7.4.1-i are

discussed in the sections below.

7-33
7.4.2.1.1 NASA Ground Terminal(s)

The Data Handling Center will be receiving and transmitting data to the NGT's,

each of which will be receiving data from the Space Station Elements (SS, COP,

and POP). Data and commands are in the CCSDS packet format, with internal

core and payload data fully independent of transfer frame structure. In the

strawman design it is assumed that none of the physical TDRSS elements

themselves are dedicated to Space Station, including the NGT's. That is,

Space Station data may be received through either of the NGT interfaces, and

the physical interfaces are identical.

7,4.2.1.2 Ground Services Center

The DHC interfaces with the Ground Services Center for purposes of resource

coordination. All communication with the NCC is through the GSC to assure

coordination of SSDS requests. The DHC manages itself using the inputs

provided by the GSC.

Specifically, the GSC provides the following to the DHC:

TDRSS/Data Distribution Network Schedule Information --- for scheduling of

the NGT--DHC and the DHCmData Distribution Network interfaces. The

strawman design attempts to minimize the need for scheduling through the

use of dynamic bandwidth allocation techniques, but automated scheduling

of high bandwidth resources seems inevitable.

• Mission Schedules m also to allow support for high rate missions.

Routing Tables -- tables which map CCSDS application IO's to their

uplink/downlink destinations and thus allow data to be correctly routed

Authorization Tables -- tables which map CCSDS application ID's with

sources allowed to be sending uplink data and commands to that destination.

7-34
The DHCprovides the following information to the GSC:

Equipment Status -- including configuration data and fault reporting which

effects other SSDS elements ?

Data Quality m as determined by the Reed Solomon decoding of CCSDS

transfer frames

• Data Accounting Information m on a CCSDS transfer frame basis

7.4.2.1.3 Level Zero Processing Facilities (LZPF's)

Payload scientific and engineering data are sent directly to the LZPF's. The

DHC acts as a bent pipe for this data, supporting basic services to remove

space, round link communications artifacts, to provide line outage protection,

and to provide rate smoothing. The DHC does not provide store-and-forward

service, hatching, or merging of recorder data. These services are provided

at LZPF's located at major NASA centers. High rate data is sent directly to

the LZPF's associated with GSFC, JPL, and LARC. Low-rate data is sent directly

to the LZPF at GSFC. The downlink CCSDS packets are error corrected and

formatted by the DHC for transport over the ground data distribution network.

The DHC does not require knowledge of the internal data formats since it

routes to the LZPF's according to virtual channel.

7.4.2.1.4 Operations Control Centers (OCC's)

The SSOCC, COPCC and POPCC send uplink data to the DHC and receive downlink

data directly from the DHC. Data traffic includes engineering data, commands,

audio, and video. Payload OCC's interface directly with the DHC for command

uplink as well as audio and video links, but receive downlink engineering and

quicklook data through their corresponding LZPF's. The DHC will accept uplink

traffic only if an appropriate authorization has been issued by the GSC and

the source of the traffic has been identified through a secure session logon.

7-35
7.4.2.1.5 Independent Customers

The Independent Customers send uplink data to the DHC through links similar to

those provided to the payload OCC's. As with the payload OCCs all downlink

data is provided to the independent customers through the GSFC LZPF (which is

responsible ?or the delivery of all low rate payload data).

7.4.2.2 Functional Description

The Data Handling Center is the direct interface between the space-ground

communication link (TDRSS) and the ground data distribution network. Its

functions are essentially limited to those of a gateway. In the strawman

design, it will perform the following functions:

DOWNLINK DATA PROCESSING

Bulk Data Recording -- to provide line outage protection

CCSDS Frame Synchronization m to support routing of CCSDS virtual channels to

LZPF's, SSOCC, and platform CC's on a transfer frame basis

Reed-Solomon Error Correction -- to remove ground-space link noise

Data Accounting -- on a CCSDS transfer frame basis

Virtual Channel Routing -- to pipe virtual channels to appropriate LZPF's,

SSOCC, and platform OCC's

Link Performance Monitoring -- to provide link quality data to the GSC

Retransmission Services m to support retransmission in the event of

communications link or external element failure

Data Distribution Network Interface -- to support distribution of virtual

channels

7-36
UPLINK DA'FA COLLECTION

Data Distribution Network Interface-- to support direct command and data

uplink interfaces with all authorized SS ground elements

Uplink Authorization -- to provide security and coordination of uplink access

according to schedules and authorization tables provided by the GSC

Frame Synchronization/Build -- to format and multiplex commands _nd data on

the appropriate CCSDS uplink virtual channels

Reed-Solomon Error Encoding -- to provide for uplink noise protection

Link Performance Monitoring m to provide link quality data to the GSC and

issues of uplink requests

DHC FACILITY MANAGEMENT

Configuration Management -- to manage equipment and gateway configuration

External Coordination m to accept schedules from and coordinate with other

SSDS elements through the GSC

Cold Start, Restart and Switchover-- to manage startup, restarts, and

switchovers

DHC buffering of data is limited to'functions required to accomplish line

outage protection and data rate smoothing. Downlink payload data is separated

on the basis of virtual channels, corrected, accounted for on a transfer frame

basis, and routed to appropriate LZPF's for further Level Zero processing. The

DHC is responsible for checking authorization for command uplink and merging

data into appropriate virtual channels. However, the DHC has no command

scheduling responsibilities, proceeding only on the basis of authorization

tables issued by the GSC.

7-37
We have not included functions for routing audio and video data since these

functions are not within the scope of the SSDS, but our implicit assumption is

that this data is routed to the OCCs/POCCs and received from the OCCs/POCCs on

dedicated CCSDS virtual channels.

7.4.2.3 Design

This section discusses a high level design approach to the DHC. The Following

key assumptions were made:

Standards from the Consultative Committee for Space Station Data Systems

are used ?or the TDRSS space-_round link, modified as described in Section

4 (end-to-end data ?low). The proposed modifications support space/ground

transparency in formatting and addressing and bi-4irectional telemetry and

commands. The standards include the use of Reed-Solomon coding to guard

against errors. Convolutional coding, however, is not used since it

duplicates some of the Functionality of Reed-Solomon coding at a high

bandwidth cost. Customers .requiring high levels of immunity to Gaussian

noise are, of course, free to implement their own interior coding schemes

independently of standard SSDS services.

The CCSDS virtual channel construct, and not CCSDS segmentation, is used

for all experiments. Individual virtual channels will be devoted to high

rate experiments while low rate experiments will be multiplexed on a

single virtual channel using the CCSDS packet telemetry standard.

Standards compatible with the International Standards Organization (ISO)

seven layer model for Open Systems Interconnect (OSI) are used for the

ground data distribution network.

The ground data distribution network provides OSI compatible services for

d_ta delivery from the DHC to the LZPFs and OCCs. In particular, the

network header structure is independent of data Format and data is

delivered with all network artifacts removed.

7-38
Payload scientific and engineering data is received on links organized so

that individual CCSDS virtual channels may be routed directly to LZPFs and

OCCs.

Command and core engineering data are routed through separate CCSDS links

through the TDRSS S-band forward and return link services.

Data is delivered to the DHC by the NGT at constant rates with fill

inserted as appropriate to maintain data rates.

All audio and video will be sent on separate virtual channels. No

conversion or reformatting is required at the DHC.

A detailed function diagram for the Data Handling Center is shown on Figure

7.4.2.3-1. Briefly, the downlink data is captured on high density data

recorders (for line outage protection), frame synchronization is performed,

Reed-Solomon error correction is done on the transfer frames, and the CCSDS

virtual channels are split and routed to the LZPFs at GSFC, JPL, and LARC and

to CCs (SSOCC, COPOCC, and POPOCC). For high rate data, a rate smoothing

function can be implemented through a pool of magnetic disks or rewriteable

optical disks. The tradeoff between storage costs (an SSDS element) and

communication costs (outside the SSDS) for rate smoothing was addressed in the

Network Topology Tradeoff Study. Expected improvements in communication

technology may make the rate smoothing function unnecessary. No further

processing is done on the downlink data at the DHC. Payload OCC's and

independent customers receive their data through the LZPFs, primarily GSFC,

which is the LZPF to which all low rate data is routed.

The uplink process involves an authorization step similar to those found in

secure network gateways. The DHC routinely receives authorization tables from

the GSC. These tables define uplink access schedules and privileges for SS

users. Since command scheduling and mode change authorization are accomplished

onboard the spacecraft, these tables define only a first line of protection

against unauthorized spacecraft data system access and the user is presented

with transparent access to the onboard system once a session is established.

The DHC serves simply as a secure gateway to the onboard LAN rather than a

7-39
i

CCS DS Dal i

SSA

NGT

Interface

Line I Control

Outage

Recorder

Operational Data Base

i

Figure 7.4.2.3-1. White Sands DHC

"'

I '

RS I _ Chan_

,_ Decoder _

Controi 1 k

Data

Quality

Facilities

Management q

i

9

C CS DS

Formatter

LZPF and OCC

Virtual

Channel

Traffic

f

r- 1

Rate

J Smoothing I

j Buffer j

GSC Scheduling Communication

GSC Retransmission Requests

GSC Uplink Authorizations

GSC Data Accounting

Authorization Tables Uplink

I I I Acknowll I I I edgement

Up nk 1 --4 Authorizationl I. pl'nkData

Ib

High-Rate

Network

Interface

Packet

Network

Interface

command verification station. The DHC will accept commands and uplink data

packets from the data distribution network, multiplex them in dedicated

virtual channels, performing framing, error encoding, and transmitting.them to

the NGTs.

The following subsections discuss each of the major functions within the DHC

and our design approach to these functions.

7,4.2.3.1Preproc_ssing

Preprocessing for the DHC is achieved primarily through the use of custom

hardware (e.g. high speed CMOS or gallium arsenide IC's) to prov'Lde front end

functions such as transfer frame synchronization, Reed Solomon

decoding/encoding, and splitting of virtl}al channels. Use of the CCSDS

transfer frame format for the ground-space communications link will great].y

simplify design of this hardware assuming that a single fixed length is used

7-40
for all transfer frames in a physical link and that all transfer frames are

Reed-Solomon encoded. This efficiency is achieved through the relative

simplicity of synchronizing to and decoding a fixed length format.

The use of monolithic IC's implementing these functions is motivated by the

high bandwidths and associated timing problems. Tools for implementing this

hardware (and presumably a number of off-the-shelf chips) will likely be

available as by-products of the OoO VHSIC program.

7.4.2.3.2 Routing & Transmission

The CCSDS standard does not explicitly define the method for multiplexing

transfer frames. To simplify scheduling and minimize reconfiguration burdens

the design allows for fully dynamic allocation of bandwidth to individual

virtual channels. Transfer frames may be multiplexed in any manner

appropriate to the bandwidth requirements of a particular virtual channel. As

individual transfer frames are received they are routed through the high rate

network links to the LZPF's, and OCC's. Routing is done according to routing

tables received from the GSC. The DHC's function is simply to translate the

virtual channel number of the transfer frame to a network address and pass the

frame and associated destination to the services associated with the high rate

network. It is assumed that the ground network simply delivers the frame to

the address with no communications artifacts added.

The design allows for a possible rate smoothing function. Certain payloads

with high peak and relatively low average bandwidth requirements and no need

for real-time data access may make use of this function to reduce

communications cost.

7.4.2.3.3 Uplink Access Authorization

Since the design provides a sophisticated command management system onboard

the space station elements, minimal command management is required on the

ground. The DHC is required to determine whether a source sending uplink data

is allowed to be sending data to the particular destination denoted by the

application process ID in the CCSDS packet header. This must be done For all

7-41
data, since it will not be possible to determine, with certainty, whether a

particular set of bits is uplink data or uplink commands.

This function would be performed by comparing the origin and destination

address in the network packets, with the application process ID in the CCSDS

header. The processing would thus require the network inter?ace to buffer and

transmit the source ID to the DHC authorization processor.

7.4.2.3.5 DHC Facility Management

DHC facilities are managed by a fault-tolerant processor.

functions are to:

Its primary

Receive schedules, routing tables, retransmission requests, and

authorization tables from the GSC.

• Load routing tables in the virtual channel routing hardware.

• Load authorization tables in the uplink authorization processor.

• Reconfigure the line outage recorders and preprocessing hardware to

implement retransmission.

• Provide equipment redundancy management.

7.4.3 Ground Services Center (GSC)

The Ground Services Center (GSC) provides communication and common resource

coordination ?or the ground system. It serves to coordinate the scheduling of

the communication and ground facility resources shared among the Space

Station, COP, and POP programs. These shared facilities include the Data

Handling Center, and the Level O Processing Facilities.

The GSC also collects status and accounting information from these facilities

(outages, etc) and prepares reports of this information to both customers and

the Global System Manager at the Control Centers. The GSC performs SSIS

7-42
functions involving the collection of billing and usage information for ground

element resources used by customers and the processing of customer bills.

7.4.3.1 Functional Interface Description

BY the nature of its functions, the GSC requires interfaces to the various

Space Station Program Elements and also to elements such as the NCC which are

in the SSIS, as shown on Table 7.4.3.1-I. The traffic along these interfaces

generally consists of low volume configuration, status, and administrative

data, and voice communications. An exception to this may be the usage and

accounting information, which could become voluminous.

The periodic status information is transmitted between the elements on a

regular and frequent (seconds) basis in the form of standard status messages.

Scheduling information will be transmitted between the elements on an

aperiodic and less frequent (minutes and hours) basis as required in the form

of schedule requests, responses, and reports. Usage and accounting information

will be collected on a scheduled, polled basis from each element. That is,

each element will be responsible for recording this information, and the GSC

will poll each element on a routine schedule(e.g., hours or days) and a file

transfer initiated.

Application level protocols for this information are necessary to facilitate

operation of the distributed ground system elements. This is especially true

since the control of the SSDS is split for programmatic reasons between that

under the domain of the GSC (common resources) and that controlled by the

Control Centers (development of mission schedules), leading to significant

coordination issues. Coordination, rescheduling and status reporting to

customers would be very difficult in this distributed environment without

these appliation level interface agreements.

7.4.3,2 Functions

The GSC performs the following functions:

• Coordination Of Shared Resouces

7-43
Table 7.4.3.1-I

GSC Functional Interfaces To SSDS Ground Elements

Element

DHC

LZPFs

SSOCC

POPCC

COPCC

POCCs

EDC

NCC

(SSIS Element)

Customer Interface

Element(s) (CIEs)

Element and

Center Gateways

Interface Traffic

Scheduling Messages

Status Messages

Resource & Data

Quality Records

Routing Tables,

Authorization Tables

Scheduling Messages

Status Messages

Resource & Data

Quality Records

Scheduling Reports

Status Reports

Scheduling Reports

Status Reports

Scheduling Reports

Status Reports

Scheduling Reports

Status Reports

Scheduling Reports

Status Reports

Scheduling Messages

Reports

Status Messages

Resource & Data Quality

Records

Network Status/Schedule

Data Accounting &

Quality Reports.

Usage Reports & Bills

Authorization and

Configuration Tables

7.44

Purpose

Resource & Schedule Coordination

Perf. Monitoring, Redundancy,

Configuration Mgmt

Customer Billing &

Fault Isolation

DHC Configuration

Resource & Schedule Coordination

Perf. Monitoring, Redundancy,

Configuration Mgmt

Customer Billing &

Fault Isolation

Resource & Schedule Coordination

Status Reporting

Resource & Schedule Coordination

Status Reporting

Resource & Schedule Coordination

Status Reportlng

Resource & Schedule Coordination

Status Reporting

Resource & Schedule Coordination

Status Reporting

Resource & Schedule

Coordination

Status Monitoring

Customer Billing &

Fault Isolation

Customer Support for

Mission Coordination. etc.

Network Management
- Scheduling

- Configuration Management

- Redundancy Management

Performance & Status Monitoring

Usage Tracking, Data Accounting (system wide) and Fault Isolation (to

common resource elements)

Shared resources are:

Communications Resources

Data Handling Center Resources

Level 0 Processing Facility Resources

It is envisioned that the driver for scheduling and re-configuration will be

the TDRSS resources. The other common resources will likely be Far more stable

as they are designed and sized to require a minimum of re-configuration in

this design.

7.4.3.2.1 Control Center Facility Manager Interface

The scheduling of the LZPF and DHC common resources will be determined by the

schedules received from the Control Center scheduling systems. Customers

(independently or at POCCs) will first develop their mission schedules by

communicating to the OCt scheduling systems via the Customer Interface

Elements and the Development and Control Network.

The Control Centers will communicate these combined mission schedules in the

form of reports to the GSC. The GSC and the Control Centers will then

negotiate via scheduling messages.

The GSC thus receives the schedule reports for the SS, POP, and COP from the

scheduling functions at each Control Center. It then configures the common

resources of the ground system to support the SSP schedule.

7-45
The GSC receives status reports on communications resources from the NCC,

summarizes them along with the status of other common resources in a manner

appropriate For use by the Control Center_ and provides these reports to the

Control Centers Facility managers.

7.4.3.2.2 Communications Resources

The GSC receives schedule requests from the Control Centers For the use of

communications resources. These include both the TDRSS resources and the

ground-to-_round communications resources. It is assumed that the SSP will be

guaranteed a certain level of TDRS service. Changes to the schedule may

result, For example, in changes to the TDRS schedule, re-configurations of the

Transport Network DOMSAT and other links, and updating routing tables.

GSC thus provides an inter?ace between the elements of the Space Station

Program and the Network Control Center. It accepts the schedule requests From

the Control Centers, integrates them, coordinates schedules and resolves

conflicts with those other common resources, and coordinates on behalf of all

SSP elements with the NCC to develop the schedule For the support of the SSP.

It also interfaces with the SSP elements to communicate NCC initiated schedule

changes. Finally, the GSC receives reports of communications resource use and

data accounting.

7.4.3.2.3 DHC & LZPF Resources

The GSC receives schedule requests from the Control Centers For use of the DHC

and LZPF resources. The GSC interfaces with the DHC and LZPF Facility

managers to assure that the DHC and LZPF configurations are consistent with

other shared resources (e.g., that virtual channels are routed to/From

available communication links) and support the Control Center SS schedule, and

vice versa. It thus accepts the schedule requests From the Control Centers,

integrates them, coordinates schedules and resolves conflicts in scheduling

the communications resouces.

These services implemented by the DHC resources are described in Section 7.4.2:

7_B
Scheduling messages may be needed to assure that the configuration of the DHC

is coordinated with other elements:

TDRSS/NASCOM interfaces

routing tables

authorization data

The services implemented by the LZPF are described in Section 7.4.5. The

configuration of the Level 0 resources must be consistent with other ground

elements to assure support of all payloads. Tables showing the correspondence

between the packet telemetry application ID and the customer or other

destination must be maintained.

The GSC receives status messages from the DHC and the LZPF and coordinates

re-configurations as appropriate to respond to changes in status. An example

of this might be re-routing or buffering of data in the event of an LZPF or

communications failure, or messages to the Control Centers to reschedule

missions if a by-pass configuration cannot be implemented.

The GSC also collects resource usage information from the DHC and LZPF for

both SSDS and SSIS functions. An SSIS use of this data is for the preparation

of bills for the use of chargeable resources.

7.4.3.3 Design Approach

The GSC requires the following components as shown on Figure 7.4.3.3-1:

o Gateways

- DHC, LZPF

- NCC

- Control Centers

- DSIT Environment (Not shown)

The gateways accept the status, scheduling, and usage messages and reports

and route them to/from the GSC local data distribution network (e.g., a LAN),

7-47
(

oJ

r',, ,,.,

a_u_

Q. 11

i

i

.,c

__.J_

!

_=

,,,,n

/

°° __.__{

or_

c

E

(

a.8

..jr_

L

z

]

_o0

ee4

7-48
performing protocol conversion as necessary. The gateways will thus consist of

modems, protocol converters, etc. The status and scheduling messages will be

transmitted over dedicated lines, with dial-up back up, with the usage

information collected on a polled basis.

• Local Data Distribution Network

The local area distribution network provides communication between the

elements of the GSC. At least two processing capabilites are required:

e General Purpose Processor (for such functions as billing)

Scheduling Processor (AI based)

The general purpose processor(s) must support:

m

m

Monitoring of status data (e.g, threshold or outage alerts)

report generators (database reports)

Data Accounting Reports (system wide)

Billing & Resource Tracking

Trending/Utilization Analysis

It is noted that the processing required to support billing and usage

tracking is an SSIS function. However, such usage information can be used For

other functions than billing. For example, it could be sorted by processing

element as opposed to user/customer, and a trend analysis performed to

determine outage patterns and to generate availability reports. Data quality

information could be analyzed to isolate problems to particular ground

elements.

At least two databases and associated storage devices are required:

Database Processor (Accounting & Status)

Operational Database (Scheduling)

A modern database capability, such as relational, would likely be used to

isolate changes in the database format from impacting the

GSC applications software.

7-49
Final].y, workstations are needed for operators support. It does not appear

these workstations would need to be highly intelligent workstatations but need

on].y support access to the processors and databases.

7.4.4 Payload Operations Control Centers (POCC's)

The Payload Operations Control Centers (POCC's) support all ph_._se-s of

operations for a single payload or complement of payloads. These phases

include prelaunch integration and test of payloads, either at the launch site

or at an off-site facility. The POCC must also support ground and flight crew

training during the prelaunch phase. POCC Control and monitoring functions

that are unique to the payload applications, training and simulations are

outside the boundaries of the SSDS. However, the POCC functions that provide

standard services -- the interface to the DHC and the GSC, and that support

ground system management are within the $SDS.

7.4.4.1 Interface Description

Figure 7.4.4-I shows the POCC's interface diagram with six other SSDS

elements. Brief descriptions of each interface are as follows:

Real-Time P/L Data

Level ¢ P/L Eng Data

Voice

L ;l Video

DHC _ POCC

Uplink CMD

and Retrieval

EDC

Figure 7.4.4-1. Payload Operations Control Center Interface

Status and

Control Data J SSOCC

• POPOCC

v[ COPOCC

I Schedule Info I

Facility Staus

Quick-Look Data

P/L Command

GSC

J Customer

7-50
7.4.4.1.1 Level 0 Processing Facility (LZPF)

Both "the real time payload science data and payload engineering data will be

conditioned at the LZPF before routing from the LZPF to Payload Operations

Control Centers (POCC's). The data will then be processed and displayed For

operators in standard operator selected formats upon request. In addition,

quicklook displays would be made available for customer use at this location.

7.4.4.1.2 Data Handling Center (DHC)

Both voice and video data are communicated between the DHC and POCC's in both

uplink and downlink directions. However, the transmission method for both

voice and video are outside the scope of SSDS study. All uplink payload

commands are issued from POCC's to the the space elements via the DHC. The

LOGON command authorization will be done at the DHC.

7.4.4.1.3 Engineering Data Center (EDC)

The operators and/or customers in a POCC may desire either core data not

previously requested in the ancillary data package, or historical data From

the Engineering Data Archives and could request the desired parameters over a

low data rate line from the EDC.

7.4.4.1.4 Control Centers (SSOCC, POPCC, COPCC)

The interface between POCC's and the appropriate Control Centers provides For

schedule coordination to establish the particular POCC's payload operations

needs on the mission schedule.

7.4.4.1.5 Ground Service Center (GSC)

POCC's interface with the GSC for Network status, schedule and data accounting

status, and data quality and usage reports.

7-51
7.4.4. i. 6 Customers

Customers wil]. interface with the POCC's either remotely or" at the location of

the POCC For the purpose of controlling their payloads. These functions will

include quick].ook monitoring of payloads and command control of payload

operations,

7.4.4.2 Function Description

A functional block diagram of the Payload Operations Control Centers (POCC) is

shown in Figure 7.4.4-2. As a11 functions are not within the SSDS, a design

approach for POCC's is not included in this report.

7.4.4.2.1 External Interface Management

The External Interface Subsystem provides the interface to the wide area

and/or local area networks connecting each POCC to the other SSPE's. The

subsystem supports communication link monitoring, transmission error

detection, and protocols requiring acknowledgements and retransmissions.

External I

Interface

Management

I I I I

Payload/Core Interface Data Base

Quick- Look Processing Management

Monitoring System

Communication

Processing

Payload

Svstem

Operation

Figure 7.4.4-2. Payload Operations Control Center Functional Block Diagram

I

Ancillary

Data

Archive

_1_

Facility

Configuration

Management

and Scheduling

7-52
7,4.4.2.2 Payload/Core Quicklook Monitoring

Personnel at a POCC must have the capability to evaluate the performance of a

specific payload. Payload data and preselected subsets of ancillary data will

be processed for quicklook purpose. The quicklook displays are made available

for customers use at the POCC location or remotely for customer evaluation of

payload performance.

7.4.4.2.3 Communications Processing

This subsystem consists of the audio and video processing/distribution systems

within the POCC.

7.4.4.2.4 Interface Processing

This subsystem manages the functional interfaces to the other ground elements

- DHC, LZPF, other Control Centers, EDH, GSC and customers. The processing

consists of interpreting incoming messages, establishing inter?ace connection,

building outgoing response or service request messages, and maintaining

inter?ace protocols.

7.4.4.2.5 Data Base Management System

This subsystem provides the data base definition for interpretation of all

payload data and ancillary data received by

the POCC, and for the bit configuration of all payload commands generated by

the POCC.

7.4.4.2.6 Payload Systems Operation

This function includes the generation of uplink real time payload commands and

command loads from operator's/customer's initiation requests. The command

management functions including authorization check, restricted and constrained

commands check and scheduling conflicts check will be done at the DHC

(authorization check) and onboard.

7-53
7,4.4.2.7 Ancillary Data Archive

Operators/customers may desire either core data not previously selected in the

ancillary data package, or historical data from the Engineering Data Center.

Via this subsystem, the POCC requests data From the EDC, and archives it for

processing and display.

7.4.4.2.B Facility Configuration Management and Scheduling

This subsystem configures the POCC processors for data monitoring, display and

payload command and control operations. It also provides the scheduling

functions and interface with appropriate Control Centers For scheduling

payload operations. Its interface with the GSC provides for network and

schedule status, data accounting and data quality and usage reports.

7.4.5 Level Zero Processing Facilities (LZPF's)

Level zero processing in the proposed design consists of the following

functions:

Capture of data routed as CCSDS virtual channels from the DHC

Reed-Solomon decoding

Extraction of CCSDS telemetry packets

Merging of tape recorder data and deletion of redundancies

Fill insertion

Data completeness and quality accounting on a transfer frame and

telemetry packet bases

Routing of real-time payload science and engineering data

Store and forward service for non-real-time data

Payload data level zero processing is performed at three sites in the strawman

design, GSFC, LARC, and ]PL. Most level zero processing is performed at GSFC,

in particular low-rate data passes through GSFC prior to delivery. This

includes real-time payload engineering data routed to the payload OCC's, but

not core engineering data which is directly routed to the SSOCC and platform

OCC's by the DHC. In particular, all Independent Customers receive their data

7-54
through the GSFC LZPF. Other LZPF's are located at NASA facilities sponsoring

particularly high bandwidth experiments which necessitate local access to

Level Zero working data stores for high level processing. In the Langley data

base the only other candidate facilities are JPL and LARC. However, the LZPF

design presented here may be replicated at other centers as requirements

change. It also may be feasible to colocate the LARC LZPF with the GSFC LZPF.

The design presented in this section is directed toward the GSFC LZPF which

supports both high and low rate Level Zero processing. However, all elements

of the design are appropriate (in scaled down form) to the other LZPF's.

7.4.5.1 Interface Description

The functional interfaces for the LZPF's which are illustrated on figure

7.4.1-1, are discussed in the sections below.

7.4.5.1.1 Data Handling Center

Downlink data in CCSDS transfer frame is routed directly from the DHC to the

LZPF's. It is assumed that the data distribution network delivers transfer

frames in exactly the same form as they are passed to the communications ports

at the DHC with all network artifacts removed. The LZPF sees a stream of

CCSDS transfer frames identical to those which arrive at the NGT interface.

Optionally, Reed-Solomon encoding may be rechecked by the LZPF and appropriate

error correction applied to correct for data distribution network noise.

Expected data rates are as follows:

GSFC -- High rate data 125 megabits/sec, average, 600.00 megabits/sec, peak

GSFC -- Low rate data 5.2 megabits/sec, average

JPL -- High rate data 18.75 megabits/sec, average, 300 megabits/sec, peak

LARC .m High rate data 50.00 megbits/sec, peak

7-55
7.4.5.1.2 Payload Operations Control Centers

Payload OCC's receive all their engineering data through the GSFC LZPF either

as real-time data or in store and forward mode. Audio and video, however, are

received directly from the DHC. It should be understood that the SSOCC, COPCC,

and POPCC communicate directly with the DHC and receive their engineering data

directly through dedicated virtual channels.

°

7.4.5.1.3 Engineering Data Centers

Communications with the EDC's will primarily be to retrieve archived ancillary

data. This will be performed through the packet network.

7.4.5.1.4 Customer RDC's

Customer RDC's receive their data directly from the LZPF's through packet

network or high rate circuit switched links. Requests for data are mediated

through an Access Control processor which isolates the requestor from Level

Zero production activities. In many cases the RDC's will be collocated with

the LZPF's and direct high-bandwidth access to Level Zero working stores

through a LAN will be feasible.

7.4.5.1.4 Independent Customers

Independent Customers will receive data directly from the LZPF's using

procedures similar to Customer RDC's.

7.4.5.1,5 Ground Services Center

The LZPF communicates with the GSC to coordinate schedule for high-bandwidth

communications links and to occasionally request retransmission from the DHC.

The LZPF also delivers accounting and quality data to the GSC.

7-56
7,4,5,2 Function Description

The LZPFis the SSDSnode which captures data and prepares it for distribution

in either real-time or store and forward mode. Processing paths are somewhat

different for low and high rate data. In the stawman design, it will perform

the following functions:

7,4.5.2,1Preprocessing

Reed-Solomon Error Correction -- a repetition of the correction applied at the

DHC to CCSDS transfer frames to reduce noise introduced by the DHC-LZPF link.

Merging of recorder data -- ordering of data and deletion of redundancies, but

not including bit reversal since the onboard recorder is implemented in

eraseable optical disk technology.

Data completeness and quality accounting -- information provided both to users

of data and to the GSC

7.4,5,2.2 Real-Time Data Routing

High Rate Data Routing -- to provide direct routing of high rate data through

the circuit switched links

Low Rate Data Routing m to provide direct routing

7.4.5.2.3 Short Term Storage and Forwarding

Data Capture -- to store data prior to production or quicklook processing and

to capture real-time data for temporary backup

File Management -- to manage both offline and online storage file systems

Batch Forwarding -- to group data into production and quicklook batches and

route them to appropriate destinations

7-57
7.4.5.2.4 Access Control

Data Access Authorization -- to control external access to Level Zero Data and

prevent external interference with production operations ?

7.4.5.2.5 Facility Management

Configuration Management -- to manage computer and communications gateway

configuration

External Coordination -- to accept schedules from and to coordinate with other

SSDS elements through the GSC

Resource Scheduling -- to coordinate internal LZPF facility usage and balance

processing and bandwidth loading among processing elements

Cold Start, Restart, and Switchover-- to manage startup, restarts, and

switchovers

7.4.5.3 Design Approach

This section discusses a high level design approach to the LZPF's. The

following key assumptions were made:

Data is delivered from the DHC to the LZPF in CCSDS transfer frame

format with no network artifacts added.

• No bit reversal of tape recorder data is necessary.

Low rate data is organized as CCSDS telemetry packets within one or

more dedicated virtual channels.

Access to Level Zero processed data is through either a packet

network or through dedicated high rate links.

All requests ?or data retrieval or reconfiguration are routed through

the packet network.

7-58
A function diagram for the LZPF appears as figure 7.4.5.3-1. Briefly, the

system is organized around a high bandwidth LAN (100 megabits/sec) which

serves routing system for commands, interprocessor communications, and low

rate data. High rate data, however, is not carried on the LAN. It instead

passes through separate links managed by a pool of high-speed I/O processors

and storage controllers. External access to Level Zero data is controlled

through an Access Control Processor which is connected directly to the packet

network. The Access Control Processor provides a degree of isolation which is

essential to the health of the LZPF since the high speed processors likely to

be used to handle data typically have operating systems which provide poor

data security. Store and forward data requests are handled through an Archive

Processor which either arranges a direct high-bandwic÷th link From the storage

system or passes low rate data through the LAN directly to the Access Contro].

High-Rate

Network

Interface

Packet

Network

Interface

Comm

Buffers

and

Front-End

Hardware

I

I

Packet

Processors

I

Virtual I

Channel

Traffic

L I/0

v

jv

High-Rate

Data

 Stor Controller

Pool

Processor I

I =Veo

1 __l

I

Data I Access

Control

Retransmission Processor

Requests

On-Line

¢

Off-Line

Storage

Local I

High-Level

Processing

L

High Bandwidth LAN

I

Facility

Management

Processor

Operational

Data Base

GSC

Scheduling

Figure 7.4.5.3-1. Typical Level Zero ProcessingFacility

7-59
Processor. The Facility Management Processor provides system reconfiguration

capabilities, and serves to implement system restarts and ?ailovers.

This configuration is similar to the CDC Cyber/Cyberplus processor being

considered for the GSFC Advanced Telemetry Processor program (with a number of

special purpose processors linked in through the high bandwidth LAN).

However, there are quite a few architectural alternatives which provide

similar types of high bandwidth data paths (albeit with different

cost/performance ratios).

The next few sections describe some of the processing functions and associated

data flow.

7.4.5.3.1 High Rate Data Real-Time Processing

We describe the end-to-end data flow and the steps required to initiate the

processing. Initially, high-rate real time processing is set up through a

scheduling request sent by the customer to the OCC. The GSC is responsible

for arranging the link from the payload through TDRSS through the DHC to the

LZPF to the customer facility receiving the data. This is accomplished

through reconfiguration messages to the SSDS components and the NCC. Full

automation of this process through a network call setup protocol is highly

desireable. We assume that the customer has arranged appropriate high rate

tail circuits to handle the communication with the LZPF.

As CCSDS transfer frames arrive at the High Rate Network Interface, they are

decoded at the front end and sent to one or more dedicated I/O processors.

CCSDS transfer frame headers are stripped, telemetry packets are

reconstructed, data quality and completeness information is appended, fill is

inserted wher_ necessary, and appropriate transport information is appended.

Data is then routed to the appropriate output port. The telemetry packets are

also routed to an appropriate storage channel, depending on customer

requirements for additional backup and/or store and forward service.

7-80
7.4.5.3.2 Low Rate Data Real-Time Processing

Low rate data is subject to a somewhat more complex process since multiple low

rat_ experiments are multiplexed on a single CCSDS virtual channels. However,

scheduling of circuit links through the GSC is not required. The low-rate

real-time customer first enables his payload through appropriate interaction

with the DHC command uplink and mission scheduling system. He then links to

the LZPF through the packet network. Access to the LZPF is controlled through

the Access Control Processor which implements secure access to LZPF facility

(security controlled by the GSC). The customer then sends a message

indicating the payload to which he wishes to link. This is checked against

authorization tables sent from the GSC and serves to initiate a process which

routes low-rate telemetry data to the customer through the packet network.

Several input virtual channels are devoted to low-rate data. The initial

processing is similar to high-rate processing. As CCSDS transfer frames

arrive at the High Rate Network Interface, they are decoded at the front end

and sent to one or more dedicated I/O processors. CCSDS transfer Frame

headers are stripped, telemetry packets are reconstructed, data quality and

completeness information is appended, and fill is inserted where necessary,

and appropriate transport information is appended. If a real-time low rate

link has been initiated the telemetry packets are then routed through the high

bandwidth LAN to the Access Control Processor which then routes them through

the packet network to the customer. The telemetry packets are also routed to

an appropriate storage channel, depending on customer requirements for

additional backup and/or store and forward service.

7.4.5.3.3 Store and Forward Processing

When data are not required in real-time, they are routed to store and forward

processing which provides bot_ quicklook and production services. Front end

processing is identical to real-time processing. As telemetry packets are

received they are grouped into batches and stored. Scheduled production runs

merge batches of telemetry packets received in real-time and through recorder

dumps, removing redundancies, and inserting fill wherever necessary. The

batches are routed to storage and a batch file catalog is maintained through a

7-61
standard DBMS product running on an Archive Processor. A user requiring a

stored data file logs in through the packet network, is connected to the

Archive Processor which supports browsing of file catalog data base. Data

transfer can then be requested according to standard services which support

access to data subsets by time interval and experiment. Transfer is supported

through high-rate or low-rate packet services as appropriate.

7.4,6 Control Centers

The Space Station Program control centers consist of the Space Station

Operations Control Center (SSOCC), the Co-orbiting Platform Control Center

(COPCC), and the Polar Orbiting Platform Control Center (POPCC). The design

assumes that the SSOCC is located at 3SC, and the COPCC and POPCC are located

at GSFC. The following sections apply generally to all the Centers unless

otherwise noted.

The Control Centers must be capable of supporting all mission phases.

Prelaunch activities include the integration and test of the space element

and platform payloads, and flight and ground crew training. Launch phase

activities include the monitoring and control of the Space Station buildup

and deployment of the platforms. On-orbit operations include the supervisory

control of the space element's autonomous operations during normal and

emergency operations, payload integration and checkout, servicing, and the

retrieval of platforms. The platform control centers must also have the

capability of simultaneously supporting multiple platforms in various mission

phases.

7.4.6.1 Interface Description

The functional interfaces of the Control Center are listed in Table

7.4.6.1-I. The interface descriptions are the same for the SSOCC, COPCC, and

POPCC except where noted otherwise.

The traffic along these interfaces tends to be low in volume except for the

uplink and downlink data. As noted in Table 5-4, the Space Station core

telemetry rate is assumed to be 256 kbps, and the command rate is 4 kbps.

For platforms, a telemetry rate of 64 kbps and a command rate of 4 kbps were

assumed. The voice and video rates are undefined.

7-62
Table 7.4.6.1-1

Control Center Functional Interfaces to Ground Elements

Element

Space Element

(via DHC)

GSC

POCC's

Flight Dynamics

Facility

(COPCC, POPCC)

EDC

DSIT

Other CC:

COPCC

(SSOCC)

STS MCC

OMV/OTV

Remote Ops. CC

Free Flyer CC

(SSOCC)

Interface Traffic

Core Upllnk

Core Downllnk

Schedules

Schedul es/Status

Schedule Requests

Schedules/Status

Orblt/Attltude

Core Upllnk,

Computed Data

Querles/Responses

Schedules/Status

S/WLoads

SlmulatlonData

Schedule/Status

Schedule/Status

Schedule/Status

Schedule/Status

7-63

Purpose

Controls, voice, video

Status, voice, video

Resource and operating events

scheduling

Communlcatlons/common resource

schedule coordination

Mission scheduling of Customers

payload mode changes

Mlsslon/payload schedule

coordination

Mission planning

Verification of onboard

comps. (backup)

Archival storage

Archival retrieval

Ground resource mgmt.

OCC modlflcatlons

Onboard s/w modifications

Development -- testing

Flight controller and crew

training Integration testing

Coordination of COP servicing

and utilization of SS resources

Coordination of shuttle visits

Coordination of servicing

(COPCC/POPCC)

Coordination of prox. and remote

ops. (SSOCC)

Coordination of prox. ops
7.4.6.2 Function Description

The subsections of 7.4.6.2, discuss the generic Control Center systems which

accomplish the functions identified in Table 7.2.3-1. These Control Center

systems For the Space Station Program will significantly differ from those of

previous spacecraft programs in the following ways:

the reduction of processing required due to the greater autonomy of

the space element From the ground systems;

the reduction of processing required to perform tracking data

analysis due to the reduction of navigation data sources employed

(GPS and TDRSS), and the improvement in ground navigation techniques;

the addition of an interface to the ground and onboard scheduling

systems for the control of mission operations;

the increase of processing required for the automation of some ground

support functions.

7.4.6.2.1 Communications

The Communications system provides the interface to the wide area and local

area networks connecting the Control Center to the other SSPE's. The system

provides:

a,

b,

External Interface management

Support communication link monitoring

Provide transmission error detection

Support protocols requiring acknowledgements and retransmissions

Provide performance monitoring data to GSC

Data Processing

Perform required preprocessing (e.g.data extraction from CCSDS

packets)

Route data to processing systems

7-84
c. Intra-Center Distribution

@ Voice subsystem

Video subsystem

Local area networks

7.4.6.2.2 Monitor and Control

Monitor and control processing provides support for real-time operations and

trend analysis. For initial Station operational phases (i.e.

assembly/activation and buildup phases), the Control Center provides

monitoring and primary control of onboard systems. As the onboard systems are

implemented and mature, several of the initial ground telemetry functions

take on a supervisory mode of operation.

The capability to perform special computations, limit sensing, logical

processing, and trend analysis of real-time and historical core engineering

data are provided in support of monitoring and control of on-board systems.

Example system capabilities are:

Monitor and Control of onboard Power systems

- Electrical power generation

- Power distribution

- Power storage

- Element lighting

• Monitor and Control of onboard Mechanical systems

q

Docking/berthing systems

Hatches

Vent Doors

Solar array booms

Servicing fixtures

Manipulators

7-65

J
VeriFication of command receipt and execution is also provided through the

monitoring oF the downlinked stored program command buFFers and the command

logs.

7.4.6.2.3 Trajectory

Trajectory computations and display processing are provided by the trajectory

system in support of planning and mission operations. The Control Center's

trajectory system works in coordination with onboard avionics systems to

provide navigation, guidance, attitude control, traffic control, tracking,

and time management. The Trajectory system is capable oF accepting tracking

data From the Global Positioning System (GPS) and TDRSS.

The Trajectory system's planning functions are:

a. Receive planning data For mission segments

$ Nominal state vectors/timelines From flight design activity

• Schedule events data from mission scheduling activity

b, Generate trajectory profile data For mission segments

• Ephemeris

• Orbital events data (AOS/LOS, maneuvers, rendezvous times,

sun/moon lighting, etc.)

c. Provide display capability for planning review of trajectory data

The following Trajectory system capabilities are provided during mission

operations in support and backup of the onboard system:

a, Receive and process tracking data

• T'DRSS S-band tracking

• GPS tracking

b, Generate/maintain trajectory profile data

• Ephemeris

• Orbital events data (AOS/LOS, maneuvers, rendezvous times,

sun/moon lighting, etc.)

7-88
Co Generate/maintain maneuver planning data

• Attitude maneuvers

• Rendezvous/proximity OPS maneuvers

• Orbital maintenance maneuvers

d , Generate/maintain general on-orbit computation data

• Constellation relative states (including line-of-sight

computations for SS to platforms)

$ Mass properties/consumables

• Onboard/ground navigation state comparisons

e° Provide display capability for real-time monitoring/on-demand review

o? current trajectory-related data,

g, Provide for short-term retention of trajectory data

• Tracking data

• As-flown orbital events data

g° Perform orbital analyses (as required)

• Quality of trajectory predictions

• "Best estimate" trajectory reconstructions (of specified

orbit/mission segments

i, Prepare mission trajectory data for archival storage in the EDC

7.4.6.2,4 Command

The Command system:

Issues real-time and stored program commands for supervisory control

o? onboard subsystems during operations;

Supports the building of single-stage and two-stage Commands for

real-time operations and planning

7-67
Provides command validation, safing, and checking to ensure safety,

effectivity, schedule compliance, etc.

Provides for the loading of onboard computers (to main or mass

memory)

7.4.6.2.5 Control Center Facility Management/Scheduling

The higher level interface for this system is the Mission Scheduling System

and the lower level interface is to the subelements of the Control Center.

The Facility Management system manages the Control Center's hardware,

software, and data elements. Its functions include:

a. Configure the Control Center to provide scheduled services

b. Interpret status data and issue appropriate controls to ensure

optimal functionality

C. Ensure that the hardware and software within each node are

appropriate to support its function

d , Verify authorization and provide access control to nodal software

loads based upon:

• operator identification

• functions (e.g. flight director, payloads officer)

• mission phase (e.g. rendezvous, deployment)

• activity (e.g. mission support,training)

e. Provide real-time and historical ground system status

?. Monitor system maintenance

The Facility Scheduling system provides the interface to the Mission

Scheduling System and performs the scheduling of the Control Center. The

Scheduling system provides the coordination of mission operations with

7-68
facility operations such as training, installation of new systems,

hardware/software updates, and maintenance.

7.4.6.2.6 Mission Scheduling

The Mission Scheduling Systems are responsible for the generation,

maintenance, and distribution of the Operating Events Schedule (DES). There

are two systems: the Space Station Mission Scheduling System at the SSOCC

and the Platform Mission Scheduling System at the COPCC/POPCC. Both systems

generate bi- weekly schedules; however, the SSOCC system also coordinates

with an onboard scheduling system which supports the crew in the near-term

(1-2 days) refinement of the DES. It is proposed that platform scheduling

be performed entirely on the ground; however, this design is sensitive to an

assumption that communications coverage is sufficient to support a

ground-based system without seriously inhibiting the autonomy of the

platform and payloads. Both systems process ground-originated schedule

change requests on the ground.

The following design-level functions of the Mission Scheduling System are

derivatives of functions 3.2, Develop Short Term Schedule, and 3.3, Develop

Operating Events Schedule. These ?unctions are common to both the Space

Station and Platform Mission Scheduling Systems except where noted otherwise.

a. Data Base Generation

Provide services for multiple users for local/remote entry and

modification of data

Support a user friendly interface -- menus, help functions,

high level (or natural) query language, checking/validating of

entries

Provide configuration management for various levels of file

certification -- development through master operating files.

Table 7.4.6.2.6-1 lists some of the attributes defined in the Mission

Scheduling Data Base and their sources.

7-69
Table 7.4.6.2.6-1

Mission Scheduling Data Base: Attributes Definition

DEFINED ATTRIBUTES

Mission Requirements Schedule - major

events such as shuttle visits, extensive

modlficatlons/upgrades, crew changes,

gross scheduling of reboosts, etc.

e Manifest - contractual agreements wlth

customers.

Characterization of payload modes -

required resources, constraints,

restrictions (components of vector

triplets)

Characterization of core operations that

require scheduling, such as maintenance,

docklng/servlclng, ventlngs, maneuvers

Characterization of available resources -

crew time, communications, power, data

system, ground support such as POCC

availability

• Trajectory profiles - ephemeris, orbital

events (AOS/LOS, maneuvers, rendezvous

times, sun/moon/earth viewing, lighting,

etc.)

• Priority rulesets

SOURCE

• Space Station Program

• Space Station Program

Mission Scheduling System

(internal) -- customer/NASA

inputs

• Mission Scheduling System

internal) -- NASA inputs

• Mission Scheduling System

(internal) -- NASA inputs

Flight Design Activity -

SSOCC

Flight Dynamics Facility -

COPCC/POPCC

e Mlsslon Scheduling System

(internal) -- NASA inputs

7-70
b. Operating Events Schedule Generation and Maintenance

Resolve conflicts through iteration and operator interaction

to achieve a feasible (as opposed t_optimal) schedule

Support hypothetical, "what if," scheduling

Support multiple users for interactive, electronic,

local/remote entry of schedule change requests

Support rapid replanning for unique payload opportunities

Process schedule change requests and provide dispositions,

which include alternative options if request cannot be met

Coordinate schedule changes with the onboard scheduling system

and crew (Space Station only) including the incorporation of

onboard-originated changes

Coordinate schedule changes that impact joint operations

involving other Space Elements

Coordinate communication/common resource support with the

Ground Services Center

Monitor status returned from onboard and ground facility and

resource management functions and adjust schedule as required

Support maintenance/development of the scheduling system, e.g.

modifications to rulesets

The timeliness of the system's response to schedule change requests depends

upon the characterization of the requested operation and the breadth of its

impact to other operations, i.e. on the amount and nature (automated or human

decision) of conflict resolution required. For example, the response time

should be in the order of seconds to a simple activate/deactivate request for

a payload whose mode is characterized as requiring minimal resources,

offering no interference to other operations, and posing no hazards.

c. Operating Events Schedule Distribution

Uplink modified schedule to onboard system

Distribute schedule reports to ground users and facility

managers -- schedule execution status, schedule changes,

opportunity alerts, orbital events, etc.

7-71
7.4.6.3 Design Approach

The design approach for control centers first addresses the generic design

drivers common to all control centers. The unique design drivers for each

control center are then described. The primary goal is to produce a general

design that is common to all control centers while satisfying the unique

design drivers of each control center. A familiarity with the functions

described in section 7.4.6.2 is necessary in order to understand the design

approach as well as the architecture.

7.4.6.3.1 Generic Design Drivers

The following items represent common design drivers for the SSOCC as well as

the POPCC and COPCC. These design drivers focus on the changing technology

and the evolution of requirements over the life of the project.

FLEXIBILITY - This quality allows a control center to meet changing

needs in a timely and cost effective manner.

TECHNOLOGY INSERTION - As technology changes, upgrades should be

possible without requiring a major redesign of the control center.

GROWTH - As functions become mature they usually increase their

resource requirements. While it is difficult to size all resources

with great precision, a good design can allow for growth without

excessive expense or initial over specification.

LIFE CYCLE COST - The cost of a system reaches far beyond the

purchase price. The operating costs must be considered in order to

provide a cost effective solution.

CORE DATA RETRIEVAL VIA EDC - In order to avoid excessive storage

costs, the EDC will be the storage facility of core engineering data

for all users.

7-72
RUTOMRTION - The system should utilize technologies that allow

equipment to perform an increasing number of tasks in order to

improve productivity and reduce staffing.

COMMERCIRL OFF THE SHELF (COTS) -The use of standard commercial

products in place of custom built equipment is highly desirable.

REUSRBILITY - The design should utilize hardware and software

developed through other projects when possible

CONTINGENCY SUPPORT - Even though the Space Station and

platforms are designed to be highly autonomous, the Control Centers

must retain the capability to provide critical support in the event

of the failure of the onboard systems.

7.4.6.3.1.I SSOCC Design Drivers

Nith the control centers for both Space Station and shuttle located at the

Johnson Space Center, commonality is highly desirable. The major areas of

compatibility are addressed as design drivers for the SSOCC.

COMPRTIBILITY NITH MCC/ERRP - The Mission Control Center is being

upgraded under the current EQUIPMENT REPLRCEMENT and REFURBISHMENT

PLRN. This plan provides for the replacement o? old equipment with a

technology upgrade in about the same time frame as the SSOCC

delivery. The result is the development of two facilities with the

same technologies. Compatibility can be achieved without sacrificing

state-of-the-art designs. Also, the potential for reusability is very

high between these projects.

FCR/MPSR SUPPORT CONCEPT - The support for the shuttle is provided

through a combination of Flight Control Rooms (FCR) and Multi-Purpose

Support Rooms (MPSR). The MPSRs provide support to the FCR

activities with the final authority for operations resting with FCR

personnel. In the case of routine operations or minimal activity

periods, support may be provided by a single FCR or MPSR. This

7-73
allows resources to be used ?or planning or other activities when not

directly supporting a mission. It is highly desirable to design the

SSOCC around this FCR/MPSR concept.

MCC INTER-OPERQBILITY - With the design drivers of compatibility and

the FCR/MPSR concept, inter-operability is simply the next step.

Inter-operability allows MCC and SSOCC resources to be interchanged.

This reduces operational concerns about the training of controllers

and scheduling of ground resources. The current operations concepts

for the SSOCC are generally the same as those of the MCC. The

possibility of using MCC-developed software and equipment For the

SSOCC is virtually assured under inter-operability.

7.4.6.3.1.2 COPCC/POPCC

The design drivers for the various platform control centers are similar to

those of the SSOCC. These control centers will be located at the Goddard

Space Flight Center. While the magnitude of the support requirements for a

platform differ from those of the Space Station, the same concepts of support

are applicable.

SUPPORT ROOM PER PLRTFORM - Since the number of control positions

necessary for a platform are smaller than those for a manned vehicle,

a single support room per platform should be sufficient. This

concept allows for incremental growth as the number of platforms

increases.

SUPPORT ROOM INTER-OPERABILITY - The potential for cost savings

through inter-operability is great. The majority of the development

costs are absorbed by the first support room. The remaining rooms

should be mostly copies of the first. The remaining rooms should be

made operational in less time than the first by using compatible

equipment and software. Inter-operability also allows an unused room

to act as a backup for other active support rooms. Personnel can be

moved from one support room to another with little or no retraining

concerning facilities.

7-74
7.4.6.3.2 Generic Configuration and Architecture

With most of the design drivers being generic in nature, a generic

configuration and architecture is a desirable solution. A common philosophy

makes the actual designs of the control centers consistent and allows

consideration of common equipment and software procurements. The

configuration and architecture are based on the following concepts:

Functional Allocation and Physical Partitioning

Network/Workstation Concept

A great deal of the effort in the design process involves defining functions

and determining methods of implementation. The goal of the designer is that

of isolating a function. This is generally accomplished by determining the

inputs and the products along with the necessary transformations of inputs

to generate the products. Understanding the relationships of all functions

in the system gives rise to functional allocation. In general, the

allocation is made by a global or local qualification. A global function

provides a service or product necessary for all or most of its related

functions. In the design of a spacecraft control center, the air-to-ground

communications equipment represents a global function. In contrast, the

monitoring of a spacecraft subsystem is a local function. Local functions

tend to be unique activities in the system while global functions are of

general interest.

Until recently, the functional allocation represented the major effort in the

design process. Once all of the functions are sized, the only thing left to

do is select a computer and begin development. Over the last few years

communications and small computers have evolved to the point of providing an

alternative to the large, multi-user mainframe. It is now reasonable to

consider hosting a function in its own computer and linking these computers

together by some type of network. This process is called physical

partitioning. The use of physical partitioning can provide many important

advantages. These include:

• Stable interfaces on physical boundaries

7-75
• Ease of growth

• Improved capability to utilize new technologies after implementation

• Improved Flexibility

• Better performance

• Possible cost reductions

Functional allocation and physical partitioning are not without dangers.

Improper hosting oF Functions can result in poor performance and excessive

equipment and expense. However, the flexibility of the design will generally

allow these errors to be corrected without a total redesign or

reimplementation. Schedule and budget concerns strongly encourage proper

allocation and partitioning prior to implementation.

The configuration and architecture used to satisfy the needs oF the control

centers is based on the concept o? networks and workstations. The basic

implementation involves a group oF processors (workstations) connected by

means of a Local Area Network (LAN). Most workstations are manned by Flight

controllers. But a workstation does not have to be manned and may range in

size from a personal computer up to a supercomputer. A general control

center architecture is shown in Figure 7.4.6.3.2-1. In this architecture,

most ?light control Functions are considered to be local and are partitioned

into their own workstations. Communications and the distribution o?

spacecraft data are global ?unctions supported by the LAN. It should be

noted that large ?unctions or processors do not indicate that a ?unction is

global in nature. Uplink collection is a prime example. All commands From

the control center are collected at a single workstation that formats them

into uplink packets. Thus, the ?unction is global in nature; however, a

small computer can easily perform the Function.

The LAN is the "glue" that holds the architecture together. The LAN provides

a general communications service For the workstations. The workstations can

send messages containing data, program_, Files, or any information to each

other without the necessity oF going through a central computer. By meeting

the protocol standards of the network, any type oF device can be connected

and can communicate over the LAN. While Functions that wish to communicate

must agree on information content, the LAN will provide the means oF

information exchange.

7-76
W/S

=,

W/S

I I I

Networks

I W/S I

Main Frame Main Frame

W/S l

Figure 7.4.6.3.2-1. General Control Center Architecture

A generic control center architecture is produced by mapping the control

center systems into the network and workstation concept. Figure 7.4.6.3.2-2

shows the result of the mapping. The front end interface receives the

spacecraft downlink and separates the voice, video, telemetry and general

messages. It also transmits command packets to the spacecraft. The

telemetry is sent to workstations via the TLM net while commands and other

general communications move along the general purpose net. Some

workstations monitor and control spacecraft systems by receiving core

engineering data and building commands. Norkstations of another group

receive tracking data necessary to perform the trajectory function. A third

workstation collects all commands and builds uplink CCSDS packets which are

TLM/CMD TRJ CMD Screen

Front-End I/F

L

TLM/TRK Net

GP Net

Facility Management I Scheduling

Figure 7.4.6.3.2-2. Generic Control Center Architecture

7-77
transmitted to the front end interface. The facility management

workstations provide library and system management functions. Finally, the

scheduler supports various mission scheduling activities.

The selection of workstations is accomplished in much the same way as any

processor. The workstation provides the following capabilities:

CPU/Memory System

Disk Storage

Graphics Display Device .

Keyboard and other input devices

LRN Interfaces

Special Interfaces

Other workstations in the system may have functional requirements that make

them larger or smaller with different configurations. For example, the

facility manager may need to be a mainframe computer in order to support the

library function. While there is economic advantage in reducing the number of

machine types, the architecture allows all machines to be of different types

provided that they can communicate over the LAN(s). Since functions are

hosted in a workstation with only related functions, other functions may grow

and change and even migrate to a larger workstation without impacting other

workstations in the system. The temptation to force a function to remain in

a given processor over the useful life of the function is reduced. This is

due to the reduced cost of equipment and the fact that many small processors

rather than a single large mainframe are utilized. This also allows code to

remain structured and straightforward rather than using special "tricks" to

make modifications fit into the existing system. Equipment has gotten

inexpensive while labor costs have increased dramatically. The lower

equipment costs allow this architecture to be cost- competitive.

7.4.6.3.2.1 SSOCC Configuration and Rrchitecture

The configuration for the SSOCC is shown in Figure 7.4.6.3.2.1-1. The control

center is divided into two parts: monitor and control, and mission

scheduling.

7-78
C

.o0@

O0i

o,i

¢6

"W

i<

=3

EL

7-79
7.4.6.3.2,1.1 Monitor and Control

The monitor and control facility is divided into FCR and MPSR areas as

described in section 7.4.6.3.1.1. The details of each FCR and MPSR are shown

in Table 7.4.6.3,2.1.1-1. It is important to note that these quantities and

configurations can be easily changed to support the buildup and mature

operations without changing the overall architecture. The major functions

performed by the monitor and control facility are as follows:

9

Network Communications

Monitor and Control

Trajectory

Command

Data Presentation and Retention

Facility Management

Joint Operations Support

Table 7.4.6.3.2.1.I-I

SSOCC WORKSTATION QUANTITIES

AREA

SYSTEM DIVISION

FLIGHT DIRECTOR

CAP COMM

EVA

CREW SYSTEMS

TRAJECTORY

PAYLOADS

FLIGHT PLANNING

LOGISTICS/MANIFESTING/SCHEDULING

FC__ R

1

l

l

3

l

TOTAL

( ) - Delta for OMV Proximity Operations

14(1)

MPS__R

14(2)

l

2

6

6

3

3

35(2)

7-80
The network communications system is composed oF the Following items:

Q

Gateway to the 3SC Net

TLM Formatter

General Purpose (OP) Net

TLM Net

Bridges to STS mission Control Center (MCC) Nets

Voice/Video Distribution

The gateway selects the packets of core engineering data addressed to

elements in the monitor and control Facility. These packets are divided into

telemetry/tracking and general message types and routed to either the TLM

Formatter or onto the GP Net. The TLM Formatter converts the

telemetry/tracking parameters into the common 3SC format for broadcast on the

TLM/TRK Net. The GP Net provides standard OSI type network communications

that are compatible with the STS MCC. The TLM/TRK Net provides a broadcast

of information that is not compatible with the OSI seven layer model. It is

Fully compatible with the MCC counterpart, however. The bridges to the MCC

nets allow the SSOCC and MCC to share information.

The telemetry function provides the ground monitor and control of onboard

systems. Activities include trend analysis and limit sensing and other

real-time operations. These activities are performed in workstations which

are manned.

The trajectory workstations provide support for navigation, guidance,

attitude control, tracking and traffic control. The workstation capabilities

are similar to those described ?or telemetry. Both the FCR and MPSRs provide

The command function is divided into two parts. Some controller positions

that _onitor telemetry and tracking data are allowed to command various

onboard systems. Through the use of both conventional and expert system

consultants, a high degree of automation is achieved. This allows a

workstation to generate command sequences and predict the effects of the

command sequences. These predictions can include an assessment of the

7-81
impacts of a command sequence with respect to safety, effectivity, conflicts

with scheduled activities, etc. The commands are built at these locations

and sent to the uplink collection processor. This processor repr'esents the

second part of the command function. This processor validates the command

formats and builds them into CCSDS packets for uplink to the Space Station.

Data presentation and retention is accomplished by the workstations in

support of mission support personnel. Information is displayed on color CRTs

as well as printer or plotter type devices. A •typical workstation of this

type is shown in figure 7,4.6.3.2.1.I-I. Short-term data retention is done by

these workstations in order to recall and process selected information for a

time of at least two hours. Any information older than that stored in the

workstation must be requested from the EDC. Local retention can be increased

by increasing the amount of disk storage of the workstation. Typical

workstation capabilities are shown in table 7.4.6.3.2.1.1-2. R func'tional

block diagram is shown in figure 7.4.6.3.2.1.1-2.

Figure 7.4.6,3.2.1.1-1. Typical Work Station

7-82
Table 7.4.6o3.2.1.1-2. Workstation Capabilities

• Multiple 32-bit CPUs

• Floppy Disk

• 400-Mbyte Hard Disk

• Color Graphics

• Floating Point Processor

• Command/Visual Graphics Control

• Printer-Plotter Access

• Furniture

• LAN Interfaces

The Facility manager provides data management for the workstations. It

monitors and schedules the workstations and related equipment. This system

uses a mainframe computer which collects inputs from workstations and

provides the library services. These inputs are used by an AI (LISP)

processor that produces Facility schedules and supports the management oF

Facility resources.

Joint Operations Support is provided by a group of workstations similar to

those used For telemetry processing. These workstations collect various core

engineering and computed data and transmit the information to other Control

Centers. These workstations can be controlled by users at the other

Centers. As a result, the man-machine inter?ace equipment is not as

sophisticated as those For telemetry processing.

The quantities and descriptions of the support rooms are shown below. These

estimates are based on studies done by the Mission Operations Oirectorahe at

JSC.

I FCR - Primary ?light support

3 MPSR - Flight support

3 MPSR - Planning, training or other activities

The MPSRs For planning are not included in the workstation counts

7.4.6.3.2.1.I-1.

in Table

The data formats of the LANs in the SSOCC fall into two groups based on the

Function of each I_AN. The general purpose net is an implementation oF t:he ZSO

seven layer model used in the STS MCC. ]"he telemetry and trackin(_ L.AN
0

7

J

"0

c

LL O. {1.

rr

(J

r_

_l -I _

113 0.--

_- tJ >0

_[--'i

•._ 0 _3._

-_I_r-7 l°_

_1 Ul _ I I

1_1 _' "; " I

El- ..,I _ I'------'- I

® --_ =i luelL__I _1 _

i tJ (3,,

!

I c

0

"3

..0

Z

o_a -->_

E

_o

LI,,.

.m

U.

7-84
conforms to the JSC implementation in the ST$ MCC. The general message Format

is shown below.

HEADER

DESCRIPTORS

DATA

General block descriptor

Parameter number, type, location, length

Actual parameters

7.4.6.3.2.1,2 Mission SchedulingThe Mission Scheduling System is composed of two types of computers. The

service interface processor collects planning and scheduling information as

well as necessary resource status and schedule requests. This information

comes from various control centers and payload users as well as the onboard

system. Various schedules are distributed to these same locations. Since this

is mostly an information system, a large mainframe computer with a

significant amount of disk storage is a reasonable choice. An IBM 3083

represents the class of machine needed. A group of LISP processors are

attached to the mainframe to produce schedules. Machines of the SYMBOLICS

3670 class are representitive examples. On the order of six of these machines

are required.

7.4.6.3.2.2 COPCC/POPCC Configuration and Architecture

The configuration for the COPCC/POPCC is shown in figure 7.4.6.3.2.2-1. This

is similar to the architecture for the SSOCC described in section

7.4.6.3.2.1. The two major functions of mission scheduling and monitor and

control are identical in nature to the SSOCC.

7,4.6.3.2.2.1 Monitor and Control

The monitor and control of platforms is accomplished through the use of

platform control rooms. Each platform control room controls a single platform.

This allows for easy expansion as the number of platforms increases. The

functions of the monitor and control facility are as follows:

@

Network Communications

Monitor and Control

7-85
..[: .> /L

',r

>

4:

z z

C

0

=l

p,

0

0,.

0

O.

0

N

.I

LL

7-86
Trajectory

Command

Data Presentation and Retention

Facility Management.

The network communications system is composed of the following:

o

O

Gateway to the GSFC nets

TLM Formatter

TLM Net

GP Net

Voice/Video Distribution

The gateway separates the telemetry/tracking data from the general type

messages. The TLM Formatter converts the telemetry/tracking data into a

format of self identifying parameters for broadcast. The TLM/TRK Net provides

the physical means to deliver these parameters to the workstations. The

gateway uses the GP Net to deliver the general type of messages. The message

protocol conforms to the ISO seven layer model for the GP net. The TLM/TRK

Net uses the same broadcast protocol described by the SSOCC.

The telemetry processing provides ground monitor and control support o? the

platform core systems. Workstations similar to those described in section

7.4.6.3.2.1.I are needed to support these activities. The workstations are

capable of storing at least two hours of selected parameters For review and

analysis. The display of information and graphics support the human

interface necessary for decision-making and command activity.

The trajectory functions are accomplished through the use of workstations and

the Flight Dynamics Facility (FDF). The same type of workstations support

trajectory as are used for monitor and control. The FDF provides

computational support For such activities as orbit and attitude calculations.

The trajectory activities include support for navigation, guidance, attitude

control, tracking and traffic control.

7-87
Command processing is similar in nature to that performed within the SSOCC

and includes verification, validation, safing, uplink formatting, etc.;

however, authorization may be limited to a single workstation.

The data presentation and retention are accomplished through the use of

workstations. Section 7.4.6.3.2.1.I also contains a description and figures

depicting a typical workstation used ?or this activity. Long-term data

retention is done in the Platform EDC while short-term retention is

accomplished by the workstations.

Facility management provides library services as well as equipment monitoring

and scheduling for all equipment in the COPCC/POPCC. A mainframe computer

manages the collection and distribution of information while LISP processors

produce the actual schedules and provide conflict resolution and fault

analysis and recovery. The library services provide global storage of files

For the workstations.

The number of control rooms for platforms is as follows:

1 COP

2 POP

1 Training and development.

Six workstations are estimated for support of each platform.

The data formats for the LRNs are the same as those described in

7.4.6.3.2.1.I for the SSOCC.

section

7.4.6.3.2.2.2 Mission Scheduling

The Mission Planning System performs the mission scheduling for all

platforms. The same basic configuration that supports Space Station Mission

Scheduling also supports Platform Mission Scheduling, The number of AI

(LISP) processors is reduced from six to ?our, however.

7-88

_J
7,4.7 ENGINEERING DATA CENTERS

The Engineering Data Centers provide archival storage of core engineering

data. The data is kept within the archive for a minimum of two years with

longer-term retention at the SSP's discretion or as arranged through

negotiations with the customer. Per the design, there are two Engineering

Data Centers m one for the storage of Space Station core data and one for

the storage of platform data. The Space Station EDC is located at JSC, and

the Platform EDC is located at GSFC. The capability exists via the Mission

Scheduling System, in conjunction with the GSC's network management

function, to route data destined for one of the EDC's to the other for

temporary storage in the event of the primary EDC's failure.

7.4.7.1 Interface Description

The functional interfaces of the EDC are listed in Table 7.4.7.1- i. Due to

their near real-time nature, the functional interfaces to the Space Element

and Control Center are managed at a higher priority than are the

non-real-time interfaces to the other elements.

7.4.7.2 Function Description

The following subsections discuss the EDC systems that perform the functions

identified in Table 7.2.3-i.

7.4.7.2.1 Communications

The Communications system provides the interface to the wide area and local

area networks connecting the EDC to the other SSPE's and to the intra-EDC

data distribution networks. The system provides:

a. External Interface Management

• Support communication link monitoring

• Provide transmission error detection

• Support protocols requiring acknowledgements and retransmissions

$ Provide performance monitoring data to GSC

7-89
Element

Table 7,4.7.1-I

EDC Functional Interfaces to Ground Elements

Interface Traffic Purpose

DHC

(as gateway

to Space

Element)

Core Downlink

Queries/Responses

Archival storage

Archival retrieval

Control Center Core Uplink,

Computed Data

Queries/Response

Schedules/Status

Archival storage

Archival retrieval

Ground resource mgmt.

POCC's

LZPF's

RDC's

Customers

Queries/Responses Archival retrieval

Alternate

EDC

Data Records Fault recovery

Central

Catalog

Service

Catalog Updates Maintenance of Central

Catalog

GSC Resource Usage

Records

Customer billing

7-90
b, Data Processing

• Perform required preprocessing (e.g. core data level 0

processing and data extraction)

• Route data to storage/retrieval systems

7.4.7.2.2 Rrchival Storage

The EDC's Archival Storage system provides for the entry of core data into

archives. The services provided are:

a. Two year storage (nominal; longer if negotiated) of audio, video, and

digital data

• Provide data compression (if necessary)

b, Support the central cataloging functions of:

• Inventoring of archive data

• Information on where data is located

• How to get it

• Options on format and transmission media

7.4.7.2.3 Retrieval

The EDC's Retrieval system supports the search for and recovery of archival

core data for transmission to SSPE's. Services include:

a,

b.

C.

d ,

e.

Process stored data request From SSPE's

Provide access control to stored data

Perform requested analyses of engineering data

• Report generation

Support the transfer of data in standard format data units (SFDU))

Maintain usage records for customer billing

7.4.7.2.4 Facility Management/Scheduling

These functions manage the configuration of the EDC resources in order to

minimize the impact of equipment failure and to ensure that the proper

configuration is provided for scheduled support. The EDC's scheduling

7-91
function interacts with its respective Mission Scheduling System, providing

status and accepting and executing schedules. Per a schedule request, these

facility functions configure the EDC to support the entry and temporary

storage of the alternate EDC's data.

7.4.7.3 Design Approach

The design approach for the Engineering Data Center addresses common design

drivers and architectures. Then the unique design drivers and architectures

are addressed for each EDC. Since the basic functions are the same, most o?

the design drivers and architecture are common.

7.4.7.3.1 Generic Design Drivers

The generic design drivers for the EDC's are very similar to those of the

control centers. These design drivers are discussed below.

FLEXIBILITY - This quality allows the EDC to meet changing needs in a

timely and cost effective manner.

TECHNOLOGY INSERTION - As improvements are made in technology, they

should be easy to incorporate.

GROWTH - As demands and requirements increase, the system must allow

additional resources to be added easily.

LIFE CYCLE COST - The design should utilize concepts that reduce

operating costs as well as controlling initial purchase price.

REI_IABILITY - The EDC's should be designed in such a way that one may

at least provide data capture capability in the event that the other

EDC is down.

AUTOMATION - In order to reduce staffing and to improve response

time, the retrieval of data from the archives should be as automated

as possible.

7-92
COMMERCIAL OFF THE SHELF (COTS) - The use of commercially produced

equipment in place of custom built equipment is highly desirable.

REUSABILITY - The design should utilize hardware and software

developed through other projects when possible.

7.4.7.3.1.1 SS EDC

The SS EDC has a stable input data rate and a high retrieval activity as

unique design drivers.

7.4.7.3.1.2 Platform EDC

The Platform EDC data rates and storage requirements change as a function of

the number of platforms.

7.4.7.3.2 Generic Configuration and Architecture

The generic architecture is shown in figure 7.4.7.3.2-1. The primary

components of the EDC are listed below.

Communications

Storage processing

Data storage

Retrieval processing/analysis

Service interface processing

The communications system provides a gateway to select and route the data and

messages. The Data Net provides for the transfer of core type information

like telemetry and tracking data. The General Purpose Net carries the regular

traffic associated with requests and control. Storage processing is

responsible for data capture and any formatting associated with storing and

organizing the data. The data store is the retention media. The

retrieval/analysis handles queries and formats the results as well as sending

the results to the requestor. The service interface processor manages the

system and performs the accounting associated with the services.

7-93
EDC

Other

Backup

Storage Retrieval

Processor and

Analysis

Data Net

Account

ir Files

System

Mgmt

Files

GP Net

Figure 7.4.7.3.2-1. Engineering Data Center

7.4.7.3.2.1 Space Station EDC Configuration and ArChitecture

The storage and the retrieval processors are of the mainframe class. IBM 308X

computers are representitive examples. The service interface processor is of

the same type as well. The data store consists of magnetic disk that holds

Four to six hours of data. This is treated as a circular queue. This allows

data to be replaced by that of better quality should it be available. Once

the data is stable, it is transferred to optical disk for archival storage. A

system like the RCA "Optical Disk Jukebox" identified in the Task 3 report is

representitive of the technology required. By using a library manager, older

data can be stored offline and loaded on demand. The system management and

accounting files are magnetic disk. The amount of storage required is shown

in the following table.

OPTICAL 4000 Gbytes (core engineering data without data compression)

MA(;NETIC 10 Gbytes.

It should be noted that the performance of the storage processor is a .

function of the amount of reformatting necessary to place the data into the

database system. If the downlink data is organized in blocks that are the

7-94
same as database records, the processing is greatly reduced. Thus,

coordination with the onboard system is very important. The cost of the

storage processor could be reduced as a smaller machine could be used. The

use of a database machine to support queries and storage represents a

possible cost reduction by reducing the loading on both storage and retrieval

processors.

7.4.7.3.2.2 Platform EDC Configuration and Architecture

The same configuration that supports the Space Station EDC can support the

Platform EDC. As the number of platforms increase, additional processors and

storage will need to be added.

7.4.8 Operational Control Network (OCN)

An essential component of the design is the Operational Control Network which

ties together all system components, providing facilities for internal

coordination of system functions, downloading of configuration controlled

software and tables, remote fault diagnosis, and access to network components

by internal and external users. The Operational Control Network is

functionally separate from the network associated with the Software Support

Environment/Software Development Environment (SSE/SDE), but supports gateway

functions for transfer of approved software configurations. Although the

functionality of the OCN is somewhat different than the SSE, the design

anticipates that much of the associated software and network interface

components will be identical. In the design the OCN is layered on the same

packet network which supports low-rate data transmission and is supported

through ISO-compatible network services associated with Layers 4 through 7.

7.4.B.I Functional Interface Description

The Operational Control Network interfaces with all major SSDS ground

components either directly through the packet network or indirectly tlnrough

LAN connections to packet network servers. ISO-compatible services for remote

terminal access, file transfer, and remote peripheral access are provided for

all the general purpose processors in the SSDS configuration. The network is

7-95
fully interconnected with network access security provided at all external

gateways.

7.4.B.2 Function Description

The OCN is a backbone network which provides essential services for

coordinating the operations of the ground elements of the SSDS. It will

support the following functions:

Software Downloading -- to provide for transfer o? new software releases to

target processors, and to support startup of software on remote nodes,

particularly microprocessors which do not support local storage of software

images.

Remote Terminal Rccess -- to allow remote logon and system access by internal

and external users through packet network facilities.

External Logon -- to verify the identity and log access to network elements by

external users entering through tail circuits and gateways. The OCN does not

control access to individual components (e.g. DHC or LZPF) but does control

network access.

Customer Interface -- to provide menus of services and connect users to these

services (e.g. in a manner like the Telenet logon menus).

Network Messaging and Reporting -- to provide standard services which support

scheduling of network resources, status and event reporting, and accounting

messages, particularly through communication with the GSC.

Remote Diagnosis _ to support the location and diagnosis of SSDS component

failures.

Remote Device Access -- to support network access of storage and output

devices for remote data base access, reporting, and logging.

7-96
Network Cold Start, Restart, and Switchover N to accomplish essential

coordination functions during network startup and switchovers associated with

network element maintenance and failure recovery.

7.4.8.3 Design Approach

The design approach assumes that the underlying Layers 1 to 3 of the ISO model

are provided by the low-rate services of the data distribution network and all

ground elements of the SSDS have local gateways. Only the additional elements

required to provide the above functionality are described. Issues of network

control center design or network structure, other than those which are

internal to the SSDS or are customer interfaces, are not considered.

7.4.B.3.1 Physical Structure

Each configurable element of the design is connected to the OCN. Connection

may be directly to the packet network, indirectly through a LAN and packet

network server, or through a host processor (for certain special purpose

processors such as the high bandwidth I/O processors at the LZPF). Backup

connections also exist for certain critical activities; for example, the

Ground Services Center is equipped with alternate dialup links to all SSDS

ground facilities for communications during packet network gateway failures.

However, all routine control communication is normally routed through the

packet network. The conceptual model for the physical system interconnection

is similar to the structure currently provided by DECnet, which provides For

multiple high and low bandwidth LAN's with reconfigurable interfaces and

internet gateways for creating subLAN's and connecting them to external wide

area data networks.

7.4.B.3.2 Gateway Functions

OCN gateways are provided at all SSOS facilities and at tail circuit

locations. The structure of the gateways is not an SSDS design element, but

has substantial impact on SSDS design and customer interface. Customer

Interface Elements (CIE) located at tail circuit gateways provide a

menu-oriented choice of network services and support easy access to the

7-97
specialized capabilities of SSOS Facilities (e.g. command uplink at the DHC,

GSC communication, LZPF real-time or store and Forward services). The gateways

also serve to control access to SSDS nodes preventing

entry by "hackers" and logging all sessions established by external users.

7.4.8.3.3 Network Services

OCN services at the Application layer were described in Section 7.4.8.2. The

design uses a set of standard network services similar to the high level

services provided by the NBS standards, DECnet, or SNA. The various

SSDS-speciFic communications which will pass over the OCN were described in

earlier sections on the individual ground system elements.

7.4.8.3.4 Network Management

The GSC provides network management services relevant the the SSDS elements.

The GSC coordinates SSDS element startup and loads authorization and

configuration tables throughout the SSDS utilizing the standard Applications

Layer services provided by the OCN. Status, event, accounting, and data

quality are reported directly to the GSC. A customer experiencing problems

with data quality, data access, or any SSDS service uses the GSC as a single

point of contact For problem reporting. In the event of a reported SSDS

Failure the GSC uses OCN Facilities to localize the problem and coordinate

problem solution working with appropriate data distribution network, NCC, or

local SSOS Facilities to resolve the problem and/or switch over to system

backups.

Although it may be collocated with the packet network control center, the GSC

does not provide packet network security services or fault diagnosis. The GSC

does, however, cooperate with network elements in locating and diagnosing

Faults at the communications gateways and other SSDS boundary elements.

7.5 Summary

In the process of performing the SSDS A/A Study several key issues,

assumptions, and uncertainties have been identified which impacted the choice

7-98
of a ground system architecture, and which should be analyzed in greater

detail in Phase B. Decisions on these areas will have a significant impact on

the cost and operations of the end-to-end SSDS.

7.5.1 Level 0 Delivery Requirements

The definition of the "delay requirement" in the Langley database has

important impacts. Does a "zero delay" requirement include Level 0 processing?

Is it required to deliver the level 0 data for high rate missions within 24

hours, for a particular data set; or are longer delays allowed? In the SSDS

Study, the maximum allowed delay is 24 hours. Longer delays, especially for

high rate data, might allow non-electronic distribution of data, e.g,

distribution of optical disks.

7.5.2 Real Time & Quick Look Data Requirements

An SSDS requirement is that the SSDS must be capable of transmitting the raw

or quicklook data in real time to POCCs and customers. This requirement

favors a distributed level 0 processing architecture, since it implies that

communications are needed to the POCCs and RDCs anyway to meet the real time

requirement.

7.5.3 Definition Of RDC

While assumptions have been made as to the number, locations, and

responsibi.lities of Regional Data Centers, in reality these issues are

uncertain and are in fact significantly affected by programmatic decisions.

Further programmatic refinement of the assumptions regarding RDC's will be

important in Phase B.

For example, in this study it has been assumed that the SSIS capabilities will

be established to provide higher level data processing at the Regional Data

Centers. A current example of this support is the Upper Atmospheric Research

Program (UARS) Central Data Handling Facility. The impact of this assumption

is that, regardless of where the Level 0 processing is done, the data must be

7-99
sent to a few key locations. In addition, the advantages of co-location of

Level 0 and upper Level processing for high rate missions m For example, to

simplify retrieval From the seven day Level 0 archive -- must be explored, as

has been done in the Network Topology Trade Study.

Another contrasting view is that upper level processing support may migrate

to users for some missions. For example, support For low rate missions might

consist of archiving For data products only. An example oF such support is the

National Space Science Data Center. Data would be sent From the Level 0

processing Facility directly to users via the data distribution network. The

Gamma Ray Observatory (GRO) program takes this approach.

Another question is whether upper level processing must do, and have the

capability to do the necessary processing to verify that they have a usable

dataset, within 7 days since the data is discarded by the Level 0 SSDS site at

this time. IF the Upper Level processing sites do not have substantial

processing capability, then they may not be able to verify that the data is

correct within the 7 day period.

Resource sharing between Level 0 and upper level processing is another issue,

and it appears to be more significant For high rate missions. Resources to be

shared include Facilities and people, and it may be possible to share the

processing, working storage, and archival resources between the level 0 and

the upper level processing. For example, it would appear that the high rate

missions would require high throughput processors in order to produce data

products in a reasonable time period. Another example is sharing between 7-day

and long-term level 0 archiving. Such sharing is speculative since the

reliability and processing requirements are different, but the cost impact oF

the high rate missions appears to warrent it being investigated.

7.5.4 Uncertainty of requirements

While the Langley Mission requirements provided valuable input, these

requirements have uncertainties, and these increase over time. Missions will

be added and subtracted over the lifetime oF the Space Station and the

alternatives should be compared in terms oF their ability to accommodate these

7-100
changes. Flexible architectures are favored, and this is one reason the hybrid

approach to Level O processing was chosen.

Definition of required "standard services" are also important. This study has

taken the view that a standard service is one that must be provided to all

customers, as opposed to the majority of customers.

7.5.5 Uncertainty of Ground System Traffic

The Langley Mission Requirements do not specify elements of key concern to the

ground system, such as the ground destination for the data. The ground

destinations for the mission data must be defined to determine the locations,

data traffic to, and processing requirements o? each Level Zero Processing

Facility. An additional SSIS issue is electronic delivery to customer sites.

Do these sites cluster in key geographic regions, or are customers widely

distributed?

In addition to defining user requirements in these areas, the issue for Phase

B is again flexibility -- for example, to support changes in customer

locations.

7.5.6 Sensitivity to Key Missions & Characteristics

A large number (about 60-75%) of the missions operate at fairly low rates

(less than O.1Mbps) while a Few key missions operate at extremely high rates

(up to 300 Mbps). The issue for Phase B is which alternative both meets the

mission requirements of all the missions, but also isolates the architectural

impacts of changes in this mission mix and in the data from those missions.

For example, in this study it was assumed that all data would be packetized,

including that from the very high rate missions. Level 0 processing for packet

data is clearly a standard service.

However, concern has been expressed as to the ability of high rate payloads to

perform packetization, or if packetization is used, whether the packet format

would be identical to that of low rate missions. It may be very difficult to

7-101
perform Level O processing as a generalized standard service unless the

formats are identical. If this assumption is considered questionable or

risky, there will be impacts on the choice of a Level O processing

architecture.

The risk of a centralized Level O architecture approach would appear to depend

in part on a) all data being in packets of identical format, or; b) if the

formats are not identical, being able to build an advanced telemetry processor

which can handle an arbitrary format. The feasibility of both of these issues

warrants further attention in Phase B.

The hybrid approach has less risk since all the low rate missions are served

with a centralized service where there is little concern as to the ability to

packetize. The resources needed for the high rate missions can be phased in or

out, and designed depending upon the requirements of the high rate missions

and the technology then available.

7.5.7 Impacts And Uncertainties Of Communications

The Network Topology Trade Study made parametric assumptions with respect to

communications costs, for completeness in cost analysis, but communications

has only been addressed in terms of feasibility, and not advisability, of the

technologies. This is due to the ?act that the data distribution network was

viewed as an SSIS institutional resource. In reality, both communications and

processing should be examined and designed together, and Phase B studies

should examine both technical and cost tradeoffs between them.

For example, a distributed Level 0 processing architecture might depend on

being able to broadcast the full downlink to all sites. This would depend on

using KR band technology, which may or may not be feasible due to rain

attenuation. That is, any given broadcast site may be out due to rain,

resulting in increased site outage, duplicate ground stations (site

diversity), and/or additional re-transmission requirements all of which should

be studied.

7-102
In addition to the Level 0 architecture, the rest of the ground system will be

distributed and in such an environment processing (Nodes) and communications

(links between the nodes - especially network (ISO layer 3 functions)

become more closely interdependent. The successful implementation of a

distributed processing network could well depend on utilizing a sophisticated

ISO communications architecture, including as packet switching, and could be

viewed as migrating what are currently thought of as processing functions to

the communications subsystem.

Problems also arise in estimating costs. Deregulation could have an

unpredictable impact on communcations costs, affecting decisions as to the

number and locations of processing centers (RDCs).

7.5.8 Optical Disk Technology

The overall cost of the ground system will be greatly impacted by the state of

the art of optical disk technology. This not only includes the cost and

storage size of the disk, but also the use of read-write technologies which

support increasing numbers of writes. The Network Topology Trade Study showed

that advances supporting i00 writes would result in significant savings.

Magneto-optic technologies hold promise of millions of writes) greatly

reducing the overall system cost.

7.5.9 Common Scheduling Statusing, and Database Interfaces

Key subsystems in the ground system must utilize standard interfaces if they

are to inter-operate. Since scheduling is distributed between the Control

Centers and the GSC, at different locations, rapid re-scheduling to support

users requires electronic communication between the various scheduling

systems. This will require application level protocols between the systems.

Monitoring of common resources will also be facilitated by the use of

standardized status messages.

The various databases distributed among the ground elements will need to

intercommunicate easily and with users. The use of common external interfaces

which inclde inter?aces to the central catalog service and common query

languages will facilitate this interaction.

7-103
7.5.10 Key Onboard Sensitivities

Key onboard decisions which impact the ground architecture which warrant

Further study in Phase B are:

7.5.10.I Use OF Virtual Channels

In this study we have Found that virtual channels can greatly simplify the

ground segment design, and we have identified a number of key uses, as listed

in Section 7.2. The wise use oF virtual channels is critical For phase B.

Additional virtual channels over that allowed by current standards may be

needed.

For example, in the initial (strawman) onboard SSDS design, all payload

science data was packetized and merged into one 100/300 Mbps stream. The

manner in which playback data was to be identified was not determined, but

this has a major impact on the ground system design. An important Finding is

that virtual channels be used for this purpose:

@ two virtual channels should be devoted to each o? the high rate

payloads, one For real time, and one For playback data

Q the low rate data can be packet multiplexed onto one virtual channel

For real time and one virtual channel For playback

@ the virtual channels are maintained all the way to the site(s) of

level 0 processing

The Level 0 architecture could be impacted if these assumptions are changed

and this should be studied in Phase B.

7.5.10.:{ Onboard Command Management

The SSDS Study has proposed a command management approach which involves the

scheduling oF capabilities (modes) with enforcement bymeans of electronic

keys and reactive control. Actual payload uplink data is transparent to the

7-104
SSDS. Changes in this approach would have a major impact on the ground flow of

uplink traffic and on missing coordination of the ground system and should be

examined in Phase B.

7.5.10.3 Packetization

Obviously the ground system is most affected by the assumption of all data

being in the form of identical self identifying telemetry and telecommand

packets. Changes in this assumption, for example, if high rate payloads are

not packetized --wouid have major ground system impacts, as noted above.

7.5.10.4 On-board Optical Disks

The proposed ground segment design assumes the use of on-board optical disks,

which allow playback in a forward direction. The backup technology is that of

tape, which plays back in reverse. Level 0 processing is impacted if this

occurs, since tape reversal is required.

7.5.11 Space/Ground Transfer Layer Services

It is recognized that a guaranteed delivery service for the transmission of

error-sensitive data (assumed to be low rate) is desirable for the

space/ground link. Such a service, such as the CCSDS transfer layer service,

would be provided on a frame basis by the Data Handling Center in conjunction

with the onboard C&T system. Design is pending recommendations from the CCSDS

on modifications to the transfer layer standards to support a bidirectional

"command class" service.

7.5.12 Conclusion

In summary, this definition of the Ground SSDS has:

Partitioned and allocated functions to ground facilities:

- Data Handling Center

- Level 0 Processing Facilities

- Control Centers (SSOCC, COPCC, POPCC)

7-105
m

Engineering Data Centers

Ground Services Center

Payload Operations Control Centers

Presented key operational ?eatures ?or

- core engineering data management

- uplink command data management

- payload data management

- mission/operations coordination

o Provided, ?or each ?acility

- an inter?ace description to other ground elements

- a ?unction desciption, describing in more detail what the

?acility will do

- design approach

B Summarized key sensitivities and issues which impact the ground

system.

7-106
8.0 SYSTEM DEVELOPMENT CONCEPTS

B.I Hardware Development/Procurement

Hardware development/procurement strategies can be divided into two

?

categories; those for ground system hardware and those for space element

hardware. Because of differences in the operational environments, it is

expected that, in general, there will not be extensive hardware commonality

between these different domains. There is potential for commonality in the

exploitation of advanced hardware technology development even though the

physical implementation of the technology may be different. (i.e., optical

disk buffering technology may be applied to both ground and space elements).

This study has primarily focused on strategies for space hardware

development/procurement. Ground-based systems will generally use commercially

available hardware products and traditional procurement practices will be

employed. Some specialized hardware development for high data rate

interfacing equipment can be anticipated for certain ground elements but this

does not pose any unique procurement problems. While there are significant

advantages to establishing some level of commonality for ground-based hardware

(especially data processors), it is recognized that there are realities that

will tend to inhibit this strategy (i.e., use of existing equipment, broad

range of requirements, etc.). However, some level of commonality for newly

procured ground hardware should be considered by NASA where appropriate. This

is especially advantageous within each NASA center since training and

maintenance costs can be minimized. In addition, when there is sufficient

functional commonality across multiple centers (i.e., SSE's, control centers,

etc.), common hardware will promote software portability and reusability as

well as simpler interfaces.

The operational environment of space elements impose unique requirements for

hardware procurement/development strategies that include the following:

a.

b.

Space environment (radiation, etc.)

Physical constraints (size, weight, power)
C.

d.

e.

Reliability

Maintainability

New technology accommodation

In addition, the requirements in some areas vary significantly across the

various space elements due to diFFerences in orbit (radiation) and

habitability (reliability/maintainability). These requirements generally

apply to modular hardware components oF the onboard DMS that includes the

Following key items described in section 6:

a.

b.

C.

d.

Network Inter?ace Unit (NIU)

Subsystem Data Processor (SOP)

Mass Storage Devices

Multi-Purpose Applications Consoles (MPAC)

An evaluation of the requirements defined above will reveal many oF the design

Features For an SOP that are common to many prior ?light/space applications.

That is the SOP must be low weight/volume/power, modular design, and space

qualified (to levels required) as well as provide the throughput and storage

capacity that technology will support ?or lgg2 IOC. However, there are

certain aspects oF these requirements that are somewhat unique to the space

station program due to the habitability environment, the goals ?or

automation/autonomy, and the need to plan For substantial growth over the

lifetime oF the space station. The issues related to these unique aspects

that pertain to space hardware development/procurement strategies are

addressed in the Following sections.

B.l.l SOP Commonality

The concept oF a common (standardized within the SSP) SDP For onboard

applications has several cost-eFFective benefits For the SSP. Primary

motivation includes the Following advantages:

B-2
a.

b.

Co

d.

Maintainability and space parts inventory

Enhanced architectural flexibility to support fault tolerance, design

extendability, and other architecture adaptability needs.

Promote transportability and reusability of software.

Lower development and operational costs due to the many advantages

the SSE can provide.

To take advantage of these substantial benefits, it is necessary to address

two important issues: (1) will a common SDP adequately meet the needs of all

subsystems (IOC and growth)?, and (2) how can new SDP technology be

incorporated during evolutionary growth7 These issues were addressed by this

study at two distinct levels of commonality; (i) across space elements, and

(2) within a space element (SS, COP, POP).

In evaluating the commonality of SDP's across space elements, it is clear that

significant differences exist in the operational environment (radiation,

habitability). If a common SOP were adopted it would have to be designed to

meet the more stringent requirements (radiation, reliability, maintainability)

of the POP. It can be argued that if an SDP is to be developed anyway for the

POP (non-recurring cost absorbed), the only penalty is the additional

recurring cost when applied to other elements. However, the potential

advantages identified earlier (a-d) are somewhat mitigated by the autonomous

operation and unique servicing requirements of these elements, The

transportability and reusability of software is still an important

consideration but can be accommodated with a standardized Instruction Set

Architecture (ISA) rather than a common SDP. This study recommends that a

standard ISR be adopted across space elements. However, due to substantial

differences in operational requirements, a common SDP may not be recommended

for all space elements. This will be further evaluated as COP/POP

requirements and designs are developed.

The advantages of SDP commonality are much more apparent within a space

element (i.e., space station). This study strongly recommends that a common

SDP be adopted for IOC. However, there is a related issue yet to be resolved;

i.e., should an SOP be "tailorable" to specific subsystems needs such as

8-3
optional I/O "cards" or variations in memory capacity. Such variations imply

a different replacement and spare parts inventory strategy.

The more important issue is how to realize the benefits oF commonality without

unnecessarily constraining the incorporation of new technology For

evolutionary growth. It is recognized that long-term growth must accommodate

not only upgraded versions of conventional processors (Faster, more memory)

but also radically different architectures. If NASA goals for advanced

automation are even partially realized during growth phases, an AI-oriented

computer architecture may become an essential component of onboard networks.

To maximize the advantages of SDP commonality while promoting growth, this

study recommends the following:

a.

b.

Adopt common SDP for IOC

Accept the Fact that onboard networks will become heterogeneous

during growth and plan for it.

m

m

Minimize and control number of new types of SDP

Standardize ISA for conventional architectures (MIL-STD 1750)

Design networks and related operating system to promote growth

and not preclude heterogeneous systems.

Standardize NIU interfaces.

8.1.2 Space Qualification

Space qualification is that effort required to insure that hardware elements

will meet all performance requirements in the specified operational

environment.

Prior space qualification programs have typically exposed samples of the

target hardware to an exhaustive sequence oF environmental, electro-magnetic

and power tolerance testing with levels significantly in excess o? mission

profiles. A successful test sequence not only demonstrated compliance with

requirements, but also insured that normal acceptance testing did not

significantly Fatigue the subsequent production units.

8-4
The project hardware was generally new development, tailored to the specific

application and influenced by the qualification requirements to provide overly

rugged enclosures, components and mounting. The hardware conservatism of the

design and test requirements, however, were generally applied because:

1) the hardware was operational through the severe mechanical

environments of launch and vehicle staging,

2) failures were generally intolerable, and

3) Fault tolerance was generally limited to static redundancy techniques

because of the continuing physical (size, weight, and power)

constraints.

The Space Station program represents a significant departure from the above

scenario because it will be manually assembled, activated, and repaired on

orbit. This implies that the hardware (electronic) modules within each launch

package need not be operational during the boost operation and can be packaged

to survive the launch and staging stresses.

These differences provide opportunities for innovative qualification

approaches during IOC and growth phases that satisfy identified programmatic

goals of cost, commonality, protoflighting, technology accommodation and

growth.

The key to maintaining program cost goals will be the minimization of

development effort without significantly impacting subsequent operational

costs. This can be accomplished in many cases by "buffering" or isolating the

environment (i.e. shielding, mechanical/thermal isolators, etc.) to match

existinghardware capabilities rather than requiring hardware with inherent

environmental compatibility.

Lower, more tolerable environmental exposure levels will allow reduction or

elimination of selected qualification tests with more reliance on

B-5
qualification by similarity (if used on other programs) as well as computer

based simulation and analysis. This approach will minimize fatigue on

qualification samples and is therefore supportive of protoflighting goals.

The mechanical environments are considered to be primary driver for any space

design. For the Space Station/Platform equipment, these environments are

essentially limited to the boost operation, during which, the transported

packages need not be operational. The launch configuration of each package is

therefore a variable within the constraints of pre-launch checkout and

assembly limitations. This suggests the use of special packaging/handling

equipment to isolate the electronic modules associated with each package For

the boost operation environments.

Space radiation will be a significant factor for some space elements of the

SSDS (i.e., POP), but is not expected to be a driver for the inhabited Space

Station itself unless commonality across space elements is warranted.

Shielding and other design options should be fully explored before discarding

the commonality goals and initiating new development activity.

The qualification program must also address technology insertion and growth

components since they will be subjected to the same basic environments. This

follow-on hardware will generally be transported as loose items, therefore,

the special handling (environmental isolation) equipment discussed earlier,

will be more viable.

With respect to the qualification effort, the study recommends:

a. Utilization of available techniques to reduce direct environmental

exposure (shielding, mechanical/thermal isolators).

b. Analysis/utilization of prior qualification history of commercial

hardware candidates for potential qualification requirement

reductions (i.e., qualify by similarity).

B-6
C. The rigor of testing can be relaxed based on the number of flight

units. Small quantities can be effectively bench tested utilizing

"golden box" techniques as opposed to the required production test

equipment, training and formalization of high volume projects.

8.1.3 Technology Capture

Historically, NASA space programs have incorporated data processing hardware

technology that significantly lags the current state-of-the-art. There are

many contributing factors that combine to cause this situation including

stringent mission/environmental requirements and the availability of space

qualified hardware. In particular, space radiation qualification has always

been an expensive and time consuming activity. This generally does not

present a problem if onboard processing demands are low and sufficient margin

is provided for unanticipated changes during development (almost never the

case). Onboard processing capability has often been traded off for low power

demands, small volume/weight, and high reliability at the expense of

autonomous operation. Failure to minimize this "technology gap" for the space

station program could seriously jeopardize NASA goals for a high degree of

space station autonomy and automation.

While certain space station mission/environmental requirements are unique

(habitation) and offer the enhanced opportunity for capturing commercial

technology, these requirements are also very diverse across space elements

(SS, COP, POP). This may result in substantial variations on the degree to

which commercial technology can be applied across elements. Space radiation

environments are likely to be a key driver ?or the POP.

The following steps have potential ?or minimizing the "technology gap".

at Selection of a standard ISA early in the program and defer the

selection o? the actual target hardware. This will allow initial

software development to commence on schedule (long-lead item).

Initial code and checkout can be accomplished on an

emulator/simulator with target hardware required for subsequent test

and integration.

8-7
b, Adopt widely-supported applicable standards to broader base of

potential suppliers. This will substantially reduce the need For

special development activities which often become long-lead items.

In particular, the use of military standards (i.e., MIL-STD-1750)

will not only provide a rich source of flight/space qualified

components, but a highly visible growth path supported by DOD (VHSIC,

DARPA, etc.).

8.2 SOFTWARE DEVELOPMENT

8.2.1 INTRODUCTION

The purpose of the SSE is to provide an environment to support the development

of software for the Space Station. The SSE is a set of tools which are

portable and will be made available for subsystem and payload developers. The

tools included in the SSE will not dictate a specific methodology or set of

procedures. The users will be able to define their procedures (with NASA

approval) and utilize subsets of the tools as required to support those

procedures.

The primary goal of the SSE is to reduce the life cycle cost and insure the

quality of all software produced for the Space Station. This includes core,

payload, ground support, and SSE software. This will be accomplished by the

achievement of the following subgoals:

i. Provide a stable, common base for the development of the software.

2, Provide integrated support of the entire software life cycle, from

conceptual definition through delivery, including configuration management

at all stages.

3. Provide easily attainable status at many levels by providing tools which

facilitate definition, scheduling and tracking of intermediate milestones.

8-8
4. Provide state of the art tools For each task in the software life cycle to

increase overall productivity.

5. Provide a common, convenient interface for each of the tools to avoid the

necessity of learning multiple inter?aces.

6. Provide an easy way to expand the tool set in order to add new tools.

7. Provide a method of maintaining multiple versions of all documentation

such that it is available on-line or it can be printed.

8. Provide tools which support and encourage commonality and the reuse of

existing components.

9. Provide sufficient flexibility within the configuration management and

software engineering methodology support to make the SOE attractive to

payload customers as well as satisfying the needs of core and ground

software developers.

10. Provide $SE capabilities such that support provided is independent of

users physical location.

The types of software support by the SSE will include:

Real 'Time Flight Software

Ground Command and Control Software

Ground Data Processing Software

Support Software

Integration and Test Software

Emulation and Model Software

Customer Application Software

In this document, the term "user group" will be used to define some set of

users which is working on the same task and requires the same Functions From

the SSE.

8-9
The SSE will be used by development groups to generate software elements, and

by the software integration site to combine the elements into integrated

software loads. The support provided to each development user group will be

identical. This support will be provided in a manner which will allow each

group to develop their applications as autonomously as possible, but will

encourage communications and software commonality among the groups. This is

depicted in Figure B.2-1. Each function in the figure is described in more

detail in this document. The support For the integration will consist of many

of the same Functions as provided For the development groups, but it will also

include Facilities-to integrate the software produced by all and it will

provide more extensive system/integration test facilities. See Figure B.2-2.

8,2.2 CONFIGURATION CONTROL AND MANAGEMENT SUPPORT

R set of tools will be provided by the SSE to support Configuration Control

and to support management in their activities o? planning and resource

allocation. It is assumed that to maintain configuration control over the

Space Station software, the project will utilize a series of NASA and

contractor control boards (similar to what has been used in previous NRSR

projects) and an automated data base system for storing and enforcing

decisions made by the boards. These tools will provide the functions

discussed below.

8.2.2.1 CONFIGURATION MANAGEMENT DATA BASE

The Configuration Management Data Base is the repository for all of the

configuration control and management support data. While thought of as a

single data base, it is in actuality composed o? several logically related

data bases. Each contains the level of information which allows its users

(i.e., management, development, testing) to plan, schedule and track its work.

Proposed software updates will be documented in the data base. The control

boards will coordinate a review of the proposed updates by applicable project

members to determine the benefits, cost and impacts of the update. Results of

B-10
w2@

0e|@&W2

IlL

8-11
i_

_ °_

t,g

_z ¢0

.oCm|

4=

00P

._P=

If.

8-12
the review will be stored in the data base. The boards will then disposition

the proposed updates and determine the implementation schedule. The control

board structure is currently undefined. A proposed structure is depicted in

Figure 8.2-3. The approval levels required for updates will have to be

determined based on factors such as cost of change, number of systems

impacted, etc. All data will be retained in the data base andwill be used as

inputs to other functions. See Figure 8.2-4.

8.2.2.2 SUBFUNCTIONS

8.2.2.2.1 DEFINITION OF SOFTWARE INCREMENTS

The Configuration Control function of the SSE will provide a method ?or

defining and managing software increments. Some of the increments will be

intermediate systems used by the development groups to checkpoint their

progress and others will be released for further integration.

For each increment a set of data is maintained. This data includes the

increment's name, dates associated with milestones in the increment's life

(definition, build, release, delivery), and the increment's status (defined,

baselined, integrated, delivered). This data will provide a means of tracking

and controlling increments and of producing reports about system activity on

the increments.

8.2.2.2.2 DEFINITION OF SOFTWARE CAPABILITIES

The CAM function of the SSE must provide a method of identifying changes which

must be made in the software being implemented. There are two basic types of

changes; those which provide enhancements (and usually imply requirements

updates) and those which correct errors in existing software. All changes

will be documented by a 'control instrument' This is a generic term which

will be used in place of a multitude of specific terms such as Change Request

(CR), Problem Trouble Report (PTR), Engineering Support Request (ESR), etc.

The SSE must provide for maintenance of data pertaining to all control

instruments. The primary information includes identifying information of the

control instrument (number, title) and identification of the software

8-13
8-14
User Planning

• Managers Software

• Req Analysts ,_ Modification

• Developers -(w|- Required

• Software Test W Control

• Reconfiguratlon Instruments

;osts Documents

Schedules Affected

Status Software

Dependencies Affected

Control

instruments

• Release

DefiniUor

• Reieese

Schedule

ImplementaUon

nign Requirements !

Generation _ _//

Basellned

Contractor

Customer

• Control

Local Instruments

Configuration 4-- Dispositions

Data Schedules

Cost Standards

Schedules

Dependencies

Status

• Build Release Definition

• Elements Status and Schedules

Affected • Build Approvals

• Statue Contents External

_R.lease D'pend'nCies

• Release Definition • S/W Discrepancies

Definition • Test Status

• Approvals

Beesllned

Baseiined

Vehicle

Figure 824 Space Station Configuration Control and Management Support

increments to which the instrument applies. Depending on the type of control

instrument and on the needs o? the subsystem to which the control instrument

applies, other data can also be retained. This data might include more

details about the control instrument's initiation (initiator name and address,

reason for initiation, description), assessments (lines of code, core/CPU

impacts, manpower), and affected elements (modules, documents, test cases). A

particular kind of control instrument might have unique data. For example, an

instrument documenting an error might have quality improvement data associated

with it (how error found, where error created, how error can be avoided).

Whenever a control instrument is entered into the CM function, the appropriate

control board is automatically notified and is sent the initial information

regarding the instrument. As the control instrument is evaluated by the

control boards and those affected, additional data is generated and is entered

into the CM system.

8-15
8.2.2.2.3 ASSIGNMENT OF CAPABILITIES TO INCREMENTS

As a result of the control board review, each control instrument is assigned

for implementation on one or more increments. The capability to make this

assignment must be restricted to authorized users who represent the

configuration control boards. The Build and Delivery system (discussed in

"System Build and Integration") which creates each increment will incorporate

only the control instruments assigned to that increment. This provides a

single point of control for each entity to be baselined in a given system

release. A single change can close several control instruments.

8.2,2.2.4 SCHEDULING AND TRACKING OF PROGRESS

The CM function must include the capability to schedule intermediate

milestones of the implementation process. It must also provide the capability

to extract, integrate, format and report scheduling data at all levels of the

Space Station project, from individual module updates to major project

enhancements which span multiple sites and user groups. Through this

facility, managers are able to extract scheduling information with which to

plan the control and use of departmental, project and system resources.

Through the intermediate and final data entered for each change authorization,

a detailed schedule can be produced tracking all steps in the progression

toward the final implementation of the change or problem ?ix. Where conflicts

occur (either with resources or personnel) the scheduling data should enable

the manager to identify problem areas quickly and institute alternate plans.

8.2,2.2.5 DATA AVAILABILITY

The CM function must provide NASA and development managers with visibility

into the capabilities being implmented, their schedules, status, etc. This

will be provided via online data base queries and hardcopy report generation.

Menus and commands will be provided by which the user may:

Q invoke queries and reports predefined in the system;

define and save (if desired), new queries or reports;

invoke the new queries and reports.

8-16
8.2.2.2.6 RCCESS CONTROL

Since control instruments may have dependencies on other instruments not under

the authority of the same user, the query and report facility must include

several levels of access control to prevent unauthorized access to data

belonging to one user by another. Further, the facility should include the

ability to suppress the display and/or print of selected data fields in a

record based on the level of access control granted to a user.

B.2.2.2.7 HISTORICAL REFERENCE.

The capabilities of each increment and all scheduling data must be kept to

provide a permanent record of the activities of the project. This data must

be available in formats similar to that mentioned in the section on scheduling

and tracking.

8.2.2.2.8 INTERFACE WITH TMIS

The CM function must interface with the TMIS system. Many of the

configuration control actions recorded in the TMIS will result in generation

of control instruments within the SDE configuration management system. For

these cases, a cross-reference capability must exist. The TMIS/SSE interface

should also include items such as costing statistics, scheduling data, board

approvals, user groups affected, and status. The disposition (approval,

disapproval, schedule) of a control instrument in the TMIS must take

precedence over local user disposition.

8.2.2.2.9 INTERFACE BETWEEN USER GROUPS

The CM function must be implemented in such a way as to encourage

communication among user groups to facilitate overall project integration and

scheduling while also providing appropriate levels of security. The

capability for one user group to identify dependencies on other user groups

must be included.

8-17
8.2.3.0 REQUIREMENTS GENERATION AND ANALYSIS

Requirements Generation/Analysis provides a foundation for software by

identifying interface details, providing descriptions of functions,

determining design constraints, and defining software validation requirements.

On a project as large and complex as Space Station, each of the afore

mentioned are crucial-to maintain communication between the requirements

initiator and the software developer. Figure 8.2-5 represents the scenario

used to modify requirements.

8.2.3.1 SUBFUNCTIONS

8.2.3.1.1 MAINTAIN MULTIPLE LEVELS OF SOFTWARE REQUIREMENTS

The Requirements Generation Function must provide the capability to support

multiple levels of software requirements such as conceptual, functional, and

detail. The top level of Software(S/W) Requirements is refered to as [.evel A

S/W Requirements or Conceptual S/W Requirements. Next are Level B S/W

Requirements or Functional S/W Requirements and the lowest level of S/W

requirements is Level C S/W Requirements or Detailed S/W Requirements. At

each requirements level, there needs to be a tool to validate that all

input/output table entries are defined.

8.2.3.1.2 PROVIDE SUPPORT FOR INTERFACE CONTROL DOCUMENTS

The Requirements Generation Function must also support Interface Control

Documents(ICD) in the same manner as software requirements. ICD's should have

input/output tables that a tool can verify the consistency across all ICS's.

8.2.3.1.3 PROVIDE TRACEABILITY OF REQUIREMENTS

Software requirements levels must be traceable from Request for Proposal

through software design to insure consistency of requirements. At every level

except the first level, each requirements section must list the reference

requirements sections from the previous level. A tool will validate that the

8-18
8-19
referenced requirements sections exist. Later, another tool will validate

that all sections from the previous level have been referenced at the current

level and the tool will list any unreferenced sections from the previous

level. Multiple versions of requirements must be supported to provide

traceability between CM increments.

8.2.3.1.4 PROVIDE TRACEABILITY TO CM CONTROL INSTRUMENT

Each requirements section to be modified must reference a CM control

instrument, thus providing traceability to all versions of software

requirements that must be supported.

8.2.3.1.5 PROVIDE A STRUCTURED REQUIREMENTS LANGUAGE

Make available a structured requirements language for use if required. This

language should be such that requirements can be described with a

specification language that combines keyword indicators with a natural

language narrative. The specification language is fed to a processor that

produces a requirements specification and a set of diagnostic reports about

the consistency and organization of the specification.

8.2.3.1.6 PROTOTYPING

In order to allow for early checkout of requirements concepts, tools such as

display design and graphic analysis must be available which support rapid

prototyping of executable software representing the requirements.

8.2.3.1.7 PRO3ECTED SYSTEMS PERFORMANCE

Tools must be provided to enable early system performance modeling. Input

requirements to this type of tool are measures in terms of cycles per second,

CFU demand on the system, and queue contention within the system. However,

the original estimates for memory sizing and CPU demand are made by the

analyst based upon knowledge of the system.

8-20
8.2.3.2 CHARACTERISTICS

In order for these functions to be useful to the project, they must be

provided in a simple, consistent, straight-forward manner. All the data must

be stored using a data base manegement system which facilitates on-line

queries, report generation and quick response time. It must also support

assignment o? various levels of security (access, update, create and delete

authority) over the data in the data base. Requirements maintenence must be

configuration controlled (tracked to control instrument approval) and made as

part of the integration process.

8.2,4.0 DESIGN AND CODE GENERQTION

Design and code generation is the process by which programmers create new

software and make changes to previously-created software. Because the process

is a creative one, it tends to rely heavily on manual inputs made by skilled

humans. In order to generate software for the Space Station in the most

cost-effective manner, the SSE must provide tools to assist the human

programmer in designing and coding in the most efficient and errorfree manner

possible. See Figure 8.2-6 for a summary of the process.

8.2.4.1 SUBFUNCTIONS

8.2.4.1.1 DESIGN TOOLS

Tools must be provided to allow software designers to create a representation

of the software at multiple design levels. Tools which allow generation and

presentation of the design in a graphic format must also be supported.

Provision must be made to use textual design languages (e.g., PDL/Ada) in

cases where they are more appropriate than graphics. To ensure that all

documentation is complete and consistent, automatic checks must be made

between the design, the requirements specification, and other documentation

(e.g., users guides).

8-21
l/l' I.,J

OI L_ -'-_"Z) r _: Z--t..) _l_rl /

O! z_:_ <J<-'

. _i ,-_._'-'>" _ _". •

_16._o_ ._J_,_.," 71 I

:_"-_<">-<" ,"-"_/// , / i

"-'!o,,,,, Vl , It._ I I

- ! " b_ v' -- -

_I ,J _L,, ,/_-- - _2__

/ / <o<-> ,_, oi/__ _ t

. V1 _ V1 i r'., Z L__.__]

n_ _ Z Z I -

I , _:-- I I i-:l

I ! --._ _ I _.1<,,.,,,_/fL----L..'_\ I _1

o ',' ___.71 I#11_ '

-_ o """ "u lxl\4 I

I _>0 <.>1 d ._L, _---I

I_L \ 7_?_/ g_-I

,<_ >, . _-_-t- - _., / _0.. _ I Zl

_.,,_ / "J( \ / _l,J!

_7 ---L-1 --=r-' I z_l

_ #"--L4N / odli

zO_ >_2I v I _oI

"J_ ,,,/ / r;/;

z_ :_/ / / !

Z Zol --_ OIo-- _ / -- ,

0 _i _'1 ..=._ ,,,..<,_._ I _ (\ /_c "_

58; __ =!

l.,J'-. _.--: ' t/i i _' l _o_,,,,,., _i.... t , t ._ _ I_1!_t /

0" _0lZo.ooO'.., _1 _ I x,..l_._l j

- _.,

,lI

,=1

IJL

8-22
8.2.4.1.2 EDITORS

Language-reconfigurable "smart" editors must be available to support creation

and modification of software. These editors must be capable of supporting

insertion of software control structures, syntax analysis of entered code, and

local semantic analysis of entered code, all tailored to the project's and

user group's coding standards and to the language of the code being edited.

8.2.4.1.3 STATIC ANALYSIS

Since software errors are less costly to correct when they are found soon

after they are inserted, the SSE must supply tools which provide static

analysis of design and code as early as possible (ideally during or

immediately following an edit session). This analysis will include standards

checking (project and user-group defined), syntax checking, data flow

analysis, complexity measures, and execution performance estimates.

8.2.4.1.4 INSPECTIONS

Since an important part of ensuring quality software is peer review, the SSE

must provide tools which assist in the inspection process. These tools should

aid in distributing the materials to be reviewed (mailing lists, automatic

formatting of text), assist during the review (multiple windows, notepads),

and provide a repository for the results of the review (history data, action

items).

8,2.4.1.5 UNIT TESTING

Unit testing is a specialized part of testing which applies primarily to the

code developer. The SSE must have the capability for symbolic execution of

code and for executing the code with interactive queries and co,ltrol at the

source line level. See "Testing and Analysis" for an expanded discussion of

testing.

8-23
8.2.4.1.6 REUSABILITY

There are two types of tools necessary to support softwar_ reusability. First,

there must be tools which encourage software developers to use existing

components. Second, there must be tools which allow developers of components

which are reusable to make those components available for general use.

To encourage the use of existing components, the software developer must have

easy access to a collection of reusable software components. To make this

possible, three things are needed:

1. a collection of data describing the available components

2. tools which use that data to help find the components needed to solve a

particular problem

3. tools to tailor a component to a user's requirements by asking questions

about the intended use of the component and using the answers with a

collection of knowledge about the component to interactively help the user

create a configuration of the component which solves the user's problem.

Before the library of reusable components becomes useful, it will need to have

a variety of components added to it. To encourage this growth, developers of

potentially re-usable components must be encouragedmto place these components

into the library. To do this, tools must be available which prompt the user

to enter data about the component and then store the data so that it can be

used by the tools described above to find and tailor the component.

Reusable software components will be treated like any other module by the

tools in the SSE (e.g., library management and source element configuration

control will be provided by the normal build tools). The only thing different

about reusable components will be the "reusability" knowledge associated with

them.

B.2.4,1.7 STATUS

To assist in managing his time, the software developer must be able to track

the status of the design and code on which he is working. Tools which provide

8-24
this status from data maintained by the Configuration Management and Build and

Delivery functions must be provided.

8.2.4.1,8 TRANSLATORS

The $SE must provide support for a variety of translators. This includes

translators For the source elements of traditional programming languages

(e.g., compilers) and translators for other types of source elements (e.g.,

documents formatters or data processors). The SSE must support translators

for multiple programming languages and must allow multiple translators for a

single programming language (e.g., for different target environments). The

programmer's interface to each of the translators must be similar.

8.2.4.2 CHARACTERISTICS

For the design and code generation tools in the SSE to be most effective, the

user of these tools must be able to spend the maximum amount of his time using

the tools to generate software rather than discovering how the tools work. To

accomplish this goal the following must be true:

each of the tools must have an interface which is as similar as possible

to the other tools' interfaces.

the user must be able to produce only one form of input to the tools

(e.g., the program source). The tools must be able either to use that

input or to use the output from another tool as input. No manual

reformatting of data ?or the various tools can be allowed.

the inexperienced user must be able to see a view of the tools which

provides step-by-step guidance (e.g., menus).

the experienced user must be allowed to directly invoke tools (e.g.,

commands).

All of the products produced by the programmer must be accessible on line

in the SSE. This includes design, code, and documentation.

8-25
8.2.5.0 SYSTEM BUILD AND INTEGRATION

The System Build and Integration function of the SSE provides the tools

necessary for orderly and controlled collection and integration of software

systems (and their associated documentation and data) by their developers and

testers and for controlled delivery of those systems to their users.

• .2.5.1 SUBFUNCTIONS

8.2.5.1.1 HIERARCHY MANAGEMENT

The Hierarchy Management function allows system coordinators to define and

control the organization and flow of program development and integration

through promotion hierarchies. See the section called "Promotion Hierarchies"

for a more detailed description of promotion hierarchies.

8.2.5.1.2 PROMOTION

The Promotion function provides a controlled mechanism for moving modules and

subsystems from one level o? integration to the next. The promotion function

locks out any further changes and makes the promoted object ready for

baselining into the next higher subsystem in the promotion hierarchy.

Promotion is allowed only if the proper authorization exists in the

Configuration Management database.

8.2.5.1.3 BASELINE

The baseline function takes objects (modules and subsystems) which have been

promoted into a subsystem and makes them a permanent part of the subsystem.

The baseline function is the mechanism by which increments are created (as

discussed in "Configuration Control and Management Support"). All actions

taken by the baseline process are recorded in the subsystem's history file or

in the Configuration Management database.

8-26
8.2.5.1.4 SUBSYSTEM INTEGRATION

Subsystem Integration performs the necessary transformations on a baseline

subsystem to put it in the format necessary for the subsystem's integration

level. For example, the baseline function may only operate on the source

element of modules in the subsystem (as decided by the subsystem

coordinator). The subsystem integration function in this case might be

responsible for performing the translations (e.g., compilations) necessary to

make the subsystem executable.

8.2.5.2 DEFINITION OF TERMS

The following are definitions of terms used in the Build and Integration

section. In many cases these definitions represent extensions to the common

definitions of the terms.

MODULE Any entity which is configuration-controlled as a logical set. For

example, a module may be a program, a data table, a test case or a

group of database records. A module may consist of several elements

(see the definition of element).

ELEMENT One of the pieces associated with a module. Some examples of

elements of a program module are the source, the object, and the

compilation listing.

LIBRARY A collection of modules which are related to each other. A library

may consist of several physical files. Typically, libraries will be

organized by subsystem and by module type (for example, different

applications might store their modules in separate libraries and a

single application might store its source and table modules in

separate libraries.

SOURCE The initially-_enerated element of a module. This is probably

manually generated, but does not have to be. The common example is

program source. Other examples include unformatted documentation,

test case inputs, and unprocessed data records.

B-27
SUBSYSTEM

8.2.5.3

A collection of modules (and associated descriptive and

historical data) which have a common purpose or use. For

example, the modules associated with a particular payload might

make up a subsystem. Depending on the level of integration, a

subsystem might contain other subsystems as subsets. As an

example, a subsystem containing documentation modules might be

made up of subsystems each of which contains the modules for one

of the volumes of the complete document.

CHARACTERISTICS

8.2.5.3.1 CONFIGURATION CONTROL OF ELEMENTS

The build function supports configuration control of all changes to the

systems being built. Changes are tracked at a11 levels; from the

system/subsystem level down to the source line level. No change may be

promoted to or baselined into a subsystem without proper authorization in the

Configuration Management database. Once an authorized change is begun

(through a controlled retrieval process), no other user can make authorized

changes to the same module. Temporary trial changes are allowed at any point

(e.g., for proving a concept), but are not accepted by the build functions.

Information retained about each change includes the reason for the change

(e.g., control number) and the subsystem and version on which the change was

made.

8.2.5.3.2 PROMOTION HIERARCHIES

Promotion hierarchies represent a planned path ?tom development through

integration to a delivered system. A separate hierarchy exists for each

release (delivery) of a system. A system is divided into subsystems which are

developed independently of each other. As each subsystem is completed

(possibly after several cycles of updates to the subsystem) it is promoted to

the next level where it is integrated with other subsystems.

8-28
I

I

I E I

III

4----+l+I--II I I

lul lul lul

I

..,,eo,..,.

D

,..oo.,....

II

I F I

Ill

+----+ I +---+

I I I

lul lul lul

. L, • • , • • . . ,

.Delivered.

. System

, . , . . , . . . , .

I

. ,, . , ° o , . . ,

R

, , , . . . , . • , .

I

. ,. , , • • . . • ,

R

. . . . . ° . • . • •

II

..l.--.,.------k _.............................................................. ---+

-I I

, ° . ° ° • • • . . . J

B I

I

, . . . . , , , , . ,

C

. , . ° . . . • . , .

. , I , , , 0 • , • . °

If

I _-................... I_+

I G I I c I

-_............ -X, -_...................... _'

III III

+---+1_ _---+1;-+

I I I I I I

_--_ _--_ _--_ _--_ .__.)___.)_

lul lul lul lul lul lul

___ .)___ .)__._ .)__.)____ __.)_

Figure 8.2-7. Initial Promotion Hierarchy: This is an example of a promotion hierarchy immediately after initial

definition. Only the user libraries ("U") and the lowest level subsystems are defined (solid boxes).

All other subsystem nodes in the hierarchy are planned (dotted boxes), but do not actually exist.

Changes to a system are done only to the lowest levels of a hierarchy. When

planned change activity and testing for a subsystem is completed, the

subsystem is promoted and then removed from the hierarchy. Users who need to

make maintenance changes to the subsystem's modules are connected to the

higher level subsystem which now contains their module.

Figure 8.2-7 represents a newly-_efined hierarchy for system "A". Note that

the number of subsystems between the users (programmers) and the delivered

system can vary depending on the needs of each subsystem. Also note that

8-29
multiple levels of integration for a single subsystem can be accommodated

(shown by two levels for subsystem "C" and for system "A"). Figure 8.2-B shows

how the system "A" hierarchy looks after some initial baselines have been

established ?or two of the subsystems and Figure 8.2-g shows how the hierarchy

looks when most of the subsystems have been promoted into system "A".

8.2.5.3.3 PROMO'TION

Promotion is the way in which a module or subsystem is made available for the

next level of integration. A module or subsystem is promoted when the current

owner is satisfied that all required testing, inspection, integration, etc.

is completed. Promotion can take place only if the appropriate authorizatiod

exists in the Configuration Management database. Once promotion takes place,

the promoted entity is locked and no more changes can be made to it without

the approval of the coordinator for the target subsystem.

Module promotion moves a module from a user library to the collection pool for

a subsystem. Module promotion can only be initiated by the responsible

programmer defined in the promotion hierarchy for that subsystem. At a

minimum, the module source is promoted, but (depending on the rules determined

by the subsystem's management) all elements of the module may be promoted.

Subsystem promotion sets up pointers in the collection pool for the subsystem

at the next level of the promotion. The rules determined by the next higher

level subsystem's coordinator determine whether the promoted subsystem is

copied or simply pointed to and whether all elements or only source elements

take part in the promotion.

8.2.5.3.4 DELIVERY

When all changes, integration, and testing for a system are completed, the

system can be "delivered". This will be the final promotion iH a given

hierarchy. The system will then either be ready for installation in the final

target environment, or it will become a subsystem in a higher-level promotion

hierarchy.

8-30
,,,,°,°,,,,

.Delivered.

System

..°..o.0.,,

i

,.,....,.,.

A

°,,..,..oo,

i

,°,.,.°,,,,

A

,.,°,,o,,°°

it

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

I

I

. . . , ° • , ° , ° °

D

, ° . , , ° , . ° ° °

II

Jr"................. -'-'I"4.................. "-+

I I

I I

' ° ° ' ' ° ' ° ' ° ' I

B I

' ' ' ' ' ' • ° ' ' ° i

It ...........

i._ t C

. , . , , . , , . . °

I E I I F I I G I I C I

II III III II

•÷---4 ._.--.-+ +'-_ I+_--'," '_'---+1+---+ I.t---+

I I I I I I I I I I

_--_ _--_ _--_ _--_ _--_ _--_ _--_ _--_ -)f__ __)_

lul lul lul lul lul lul Iul lul lul lul

__.)f ___ _--_ _--_ _--_ _--_ _--_ _--_ __.)_ __)_

Figure 8.2-8. Promotion Hierarchy After Initial Builds: This is how the promotion hierarchy for System "A" looks

after builds have occurred for the E and C subsystems. Note that users with no more inputs to a

subsystem have been removed from the hierarchy.

8.2.5.3.5 BASELINE

Until the baseline function is performed all modules and subsystems promoted

into a subsystem's collection pool are in a pending state. The baseline

function takes them out of the collection pool and makes them a permanent part

of the subsystem. This involves updates to the subsystem's descriptor and

8-31

H j
,.,,,...,..

.Delivered.

System

,,,,,.,,,,.

I

.,.,,.,,,.,

A

,.,,,,.,,,o

I

I A I

II

I................ --+I ........................ ----+

I I

I B I i

I I I

Iul lul lul

Figure 8.2°9. Promotion Hierarchy During System Integration: This is how the promotion hierarchy looks during

system integration. The subsystem nodeshave been deleted. Only userswho need to make updates

to the integrated system are in the hierarchy.

history Files and possibly also updates to the subsystem's libraries. The

baseline process does not necessarily make copies of the baselined items In

many cases (especially when baselining a promoted subsystem), updating the

descriptor Files is all that is necessary. The baseline process may also copy

only certain elements of a module (e.g., source, but not object). Nhether to

copy and what to copy are options selectable by the subsystem's coordinator.

Even though the promotion Function checks For proper configuration management

authorization, the baseline Function checks again and then provides the

appropriate Feedback to the Configuration Management Function.

8.2.5.3.6 SUBSYSTEM INTEGRATION

After the baseline function has been performed on a subsystem it may not be

immediately useable. For example, if only source is baselined, modules must

be recompiled before subsystem testing can take place. The Subsystem

Integration function takes care of any translations or re-formatting which

8-32
must be done to the contents of the subsystem's libraries to make the

subsystem ready ?or its users.

Subsystem Integration will check dependencies and (based on local options)

either flag or automatically re-translate modules which are dependent on

modules which have been changed since the last integration. Depending on the

content of the External Dependencies portion of the subsystem's Descriptor

File and on options set by the subsystem coordinator, Subsystem Integration

can use modules from other subsystems to resolve references and produce a

useable subsystem.

8.2.5.3.7 TEMPORARY INTEGRATION

Temporary Integration can be done by any user wishing to create a temporary

copy of a subsystem ?or early testing or consistency-checking. Temporary

Integration differs from subsystem integration in that it operates outside of

configuration control:

1. it does not require any Configuration Management authorization,

2. it does not require a baselined subsystem,

3. it does not update any descriptor or history files,

4. it does not make copies of any of the input libraries.

The user can select any subsystems or user libraries to use as input, select

or reject the subsystems' collection pools as input sources, and choose what

kind o? dependency-checking and re-translations to perform. Depending on the

options selected, temporary integration can be used for a wide range of

tasks. For example, temporary integration can be used to create a prototype

version of a subsystem constructed From existing subsystems and user

libraries. It can also be used to verify that the contents of a collection

pool will be consistent during system integration before the permanent

integration process is executed.

8-33
8.2.5.3.8 SUBSYSTEM CONTENTS

Each subsystem in a promotion hierarchy consists of four major elements: a

descriptor file, a history file, a set of libraries, and a collection pool

(see Figure 8.2-10). The following paragraphs further explain the contents of

each of these elements.

8.2,5.3,8.i DESCRIPTOR FILE

The Descriptor File contains two kinds of data. The module descriptor data

provides information necessary to retrieve, translate, and integrate the

Descriptor File

External

Dependencies

Module

Descriptors

Libraries

.,,,,,,,,,,,°°..,°,.,,°,°,l,

I I I I

I Source I I Object I

I I I I

IOocu- I

I ment- I . others .

I ationl

W W .... W

History File

Subsystem

History

Module

History

Collection Pool

Promoted

Modules

Promoted

Subsystems

Figure 8.2-10. Contents of a Subsystem

8-34
modules in the subsystem. For each module, this data includes a list of the

elements (source, object, design, data) which make up the module, pointers to

the libraries in which the elements reside, control data for the translators

(compilers, formatters) which operate on the module's elements, and a

cross-reference o? dependencies between the module and other modules (for use

in integration processing).

The external dependency data in the Descriptor File describes how to find

external modules (system macros, common subroutines) which are needed by

modules in the subsystem. This data includes a list of external modules

needed and pointers to the external libraries which contain those modules.

8.2.5.3.8.2 LIBRARIES

The libraries in a subsystem are the files which contain the various elements

which make up the subsystem's modules. A library is not any particular type

o? file. It may be a single physical file, a logically-related collection of

physical files, or a logically-related subset of a physical file.

8.2.5.3.8.3 HISTORY FILE

The History File contains a complete record of all changes to a subsystem from

some pre-_etermined base version to the present. This includes change

instrument numbers, source lines changed in a module, modules re-translated

during integration, and subsystems integrated into the subject subsystem.

8.2.5,3.8.4 COLLECTION POOL

The Collection Pool contains updates to the subsystem which have been

promoted, but which have not yet been baselined. These updates include at

least the source element o? an updated module, but may also include any (or

all) of the other elements. Updates to module descriptor data are also

promoted to the collection pool to await baselining.

8-35
8.2.5.3.9 REUSABLE COMPONENTS

The developers and maintainers of reusable software components will use the

same build and integration tools as other users of the SSE. Special functions

are provided to notify users of a reusable component of changes to the

component in the master component libraries. Tools for the retrieval and

tailoring of components are discussed in "Design and Code Generation".

B.2,6.0 TESTING AND ANALYSIS

Testing is the examination of program execution behavior. Testing of the Space

Station software will be very important because of its life/mission critical

nature. Facilities must be provided in the SDE For testing because of the

inability to observe the software in actual use in a safe environment (i.e. on

the ground). These test Facilities should include a variety of tools that will

support cost effective testing of the SSDMS, application software, and payload

software.

There are five steps of a test process (see Figure B.2-11). They are

I. Test Planning

2. Test Design and Development

3. Test Execution and Simulation

4. Data Reduction and Analysis

5. Test Report Generation

The tools and capabilities described in this section represent the full

spectrum of test facilities For the project. Subsets may be defined and used

to support various levels such as unit testing, performance testing, and

independent verification and validation.

B.2,6.1 PLANNING

This involves gathering all data concerning the software to be tested,

analyzing it, and deciding what tests need to be performed. The list of tests

to be performed and rationale for the tests are put into a test plan. The
\ REQUIRE- ,

.-"

\ DESIGN ,

, SPECIFICA-

\'.. TIONS ..//

TEST EXECUTION

AND SIMULATION

' i

o TEST PLANNING I

I

I I

I

TEST DESIGN

AND DEVELOPMENT

L ..... !

_l ANA!YSIS TOOLS

r .....

I

I

III.I

L

l_l--.-Ib

STATIC

: ANALYSIS

TOOLS

TEST CASE

DESIGN/

DEVELOPMENT

TOOLS

DIAGNOSTICS &

MONITORING

EXECUTING

TEST/

SIMULATION

DATA I

I

REDUCTION,

I: AND o

ANALYSIS I

I

TEST REPORT GENERATION

-IANALYSISI

ALL TEST AND

ANALYSIS

INFORMAflON TO

DOCUMENTATION

Figure 8.2-11. Steps in the Typical Testing Process

8-37
rationale is an explanation for why the specified tests were chosen. Possible

explanations are 'to test a specific requirement' or to 'test a high

complexity (high risk) section of the code'. The following is a list of

possible static analysis tools that could be used to facilitate the planning

of tests,

1. Logic Flow Graph Generators

A tool of this type would create a summary of the control flow of the program

to be tested. One use of this information is to plan test coverage.

2. Data Flow Graph Generators

A tool of this type would create a summary of the flow of data in the program

to be tested. One use of this information is to test for errors in the set/use

of variables.

3. Complexity Measuring Tools

A tool of this type would create measures of the complexity of the program to

be tested. This information is useful in identifying high risk areas of the

code. These areas would require a higher test coverage.

4. Interface analyzers

A tool of this type would create a summary of interface information of the set

of modules being tested. This information would be useful for subsystem

integration.

8.2.6.2 DESIGN AND DEVELOPMENT

This involves creating test procedures and a test script that will accomplish

all the tests and testing goals identified in the test plan. Test procedures

will outline the strategy for accomplishing the tests and the test script will

_3B
contain all necessary details. The test script will be directly executed (i,e.

equivalent to code) while the test procedure is the design (i.e. equivalent to

program design).

Many of the facilities necessary to support test case design and development

are the same tools necessary to support program design and development (see

"Design and Code Generation"). These are

i , High level languages to facilitate the design and development of test

cases. This language(s) will support design of the test procedures and the

development of the test script.

2. Syntax Directed Editor

This type of editor would directly support the development of test cases in

the high level test language by providing skeletons of all structures in the

language.

3. Test Script Static Rnalysis Rids

Tools of this type will analyze the test script for potential development

errors. Some examples of potential errors are

a. Incorrect use of the simulator capabilities

b. Incorrect use of the Space Station system capabilities

c. Incorrect references to program variables and locations

d. Incorrect test facility or simulator configuration

Detecting these errors in test cases before the tests are executed will help

eliminate may wasted test executions (which may be expensive) and will help

eliminate analysis of errors that were due to an incorrect test script.

4. Test Libraries and Reusability

l'o promote Reusability in test cases there should be tools to encourage and

8-39
facilitate the use of test case components. The tools will of the same ones

used for software development (see "Design and Code Generation"). These tools

should support the maintenance and use of libraries of test case components.

5. Stub/Driver Generator

A tool of this type would generate skeleton stubs and drivers necessary for

execution of the program being tested. This would need to be done, for

example, when the module calls another procedure that has not yet been coded.

6. Test Data Generators

A tool of this type would generate test data to be used to test the program.

The test data will be generated to accomplish a specific test goal such as

forcing execution down a specific path or testing boundary conditions.

8.2.6.3 EXECUTION AND SIMULATION

This involves applying the test scripts to the software being tested and

creating a set of test results. To support the actual execution of the test

cases a dynamic test facility must provide the following

I. Diagnostic capabilities

The required capabilities vary from unit test to system testing. Unit testing

will require more detailed diagnostics such as traces, stop on address

compare, variable altering, variable snapping, etc. These diagnostic

capabilities allow the programmer to effectively test and debug his software

module. Since it is much cheaper to catch errors in the unit testing process

than it to catch the same errors later in the testing process, it is important

to provide these detailed diagnostics to encourage and facilitate early error

detection. System testing will not require diagnostic capabilities as

detailed as unit testing will.

B-40
2. Performance monitors

These are necessary to monitor performance characteristics of the system such

as CPU utilization, timing/synchronization, and bus traffic throughput.

3. Simulation

To model unavailable parts of the system and environmental effects, a set of

simulation models must be provided. The amount and fidelity required will

vary from unit testing to system testing with system testing having the most

stringent requirements. High fidelity simulation resources will be limited and

a simulator scheduling facility will be provided to optimize use of these

resources.

4. Data Logging

Sampling of many different items will occur during test case executions.

Often, much of this data will need to be analyzed after the tests. Adequate

facilities must be provided for short and long term storage of this data.

8,2.6.4 DATA REDUCTION AND ANALYSIS

This involves formatting and summarizing the test results obtained from the

Test Execution and analyzing the results to determine success/failure of the

software to pass the tests applied. The data logged during the test execution

should be reduced, summarized and formatted into two different possible

formats. The first format will be a report suitable for human viewing and

analysis. This would include a variety of graphical and text Formats. The

second format would be one that is suitable for input to a program to perform

some automated analysis.

8.2,6,5 REPORT GENERATION

This involves assembling all work products generated during previous steps of

the test process into a report. The format and the content of the test

reports will vary across different test groups. They may contain any of the

841
possible work products generated during testing. These include the test plan,

test design, test procedures, test execution configuration, analysis results,

and problems and/or anomalies found. These work products will be

automatically formatted into a preliminary version of the test report. Then

the report can be completed manually.

B.2.7.0 DOCUMENTATION

The documentation function will provide online documentation facilities to

create a minimum paper environment with hard copying capability. This

function will be used for viewing as well as creating the online documents.

There will be a capability to assign access levels for security o? nonpublic

documents. Examples of document types are: requirements, user's guides,

instruction manuals, test specifications, program test reports, software build

reports, status reports, and working papers.

Norking papers are lost, historically, in most long-lived projects as the

designers move on to newer tasks. The documentation capabilities will support

the archiving of background information, such as design rationale and

justification, etc.

B.2.7.1 SUBFUNCTIONS

8.2.7.1.1 PROVIDE ONLINE DOCUMENTATION FACILITIES

Online documentation facilities must be provided to all SSE users. This

includes the ability to create and maintain document source online and the

ability to access formatted documents online. Multiple versions of documents

will be maintained to reflect the multiple versions of software being used (_nd

developed at a time. The users will be able to obtain hard copies of selected

documents.

8.2.7.1.2 PROVIDE MEANS TO "REDLINE" DOCUMENTS ONLINE

With electronic transmissions of review documents, a means will be provided to

facilitate "redlining" a document to indicate desired changes.

8-42
8.2.7.1.3 PROVIDE CROSS REFERENCE CAPABILITY WITH ONLINE RETRIEVAL

A means for users to cross reference topics between the books and volumes,

such as a trace from requirements to a users guide must be provided. It will

enable users to relate the software development phases to categories of

documents to ease the documenting and retrieval tasks. An information

retrieval system would provide an efficient means to locate information by

subject or keywords.

8,2,7,1.4 PROVIDE INTEGRATED TEXT/GRAPHICS SUPPORT

This function will provide integrated document text and graphics support with

a means For identifying revision levels.

8.2.7.1.5 CONFIGURATION MANAGEMENT

An interface the the configuration control and management support system (see

"Configuration Control and Management Support") system must be provided to

support configuration of documents.

8.2.7.2 CHARACTERISTICS

The documentation function will encourage thorough documentation by being easy

to learn and use.

Some uses for the tools, e.g., maintaining working papers, do not require

configuration control and users should be able to perform these tasks

exclusive of the control functions.

B.2.B.O COMMUNICATION

The communication function will provide the means to make the SSE appear as a

single Facility to each user, regardless of site location. It will enable a

user to send and receive data, e.g., documents, messages, or software to other

users or functions of the SSE. This Function will field requests from other

Functions to transfer data between Functions and to users.

8-43
8.2.8.1 SUBFUNCTIONS

8.2.8.1.1 MESSAGES BETWEEN USERS

i. Facilitate inter and intra user group communication

User groups will be conducting reviews of all types (e.g., requirements

review, design/code review, test specification/procedure review). The reviews

require communications between the groups For the scheduling of reviews, and

resolution of review comments.

2. Provide means for users to schedule resources

Users will be able to communicate between sites to coordinate resources for

things such as integrated testing.

8.2.8.1.2 DATA TRANSFER BETWEEN USERS OR SSE FUNCTIONS

I. Support transfer of software between SSE and contractors

This function of the SSE will provide a method for both simulator models and

application software to be transmitted between the SSE and the contractor

sites for review (source) or execution (modules).

2. Interface with TMIS

Many of the SSE functions will send or receive data (e.g., plans, schedules,

documents, status) to the TMIS for Space Station program management. This

function will provide the interface with the TMIS system.

8-44
3. Provide interface to all SSE functions

All other SSE functions use this function to communicate status, schedules,

product dependencies, configuration control instrument status, and to transmit

program software products with other functions.

4. Provide means for document transfer

Users will be able to transfer documents between sites.

5. Provide interface to reusable software library

To promote software commonality, it is envisioned that a reusable software

library will be a part of the SSE. Users will be able to send and retrieve

elements to and from this library.

8.2.8.2 CHARACTERISTICS

For the other SSE functions to be used effectively, communications between

these functions and the users is essential. Therefore, the communications

function must operate in a straight-forward and easy-to-use manner to

encourage such use.

8.2.9.0 RECONFIGURATION

The software on the Space Station will be required to interface with a vast

number of hardware components (e.g. IMUs, rate gyros, etc.). During the life

time of the station, it will be necessary to integrate, test, operate, and

replace hardware components. Each component has specific characteristics

which must be provided for within the software. Reconfiguration data is that

set of data values required to tailor the application software and UIL

interface environments to be compatible with a specific hardware

configuration. The process of managing the reconfiguration data and

incorporating updates into the target system (e.g. onboard DMS, integration

test sets) is called reconfiguration. The SSE must support this activity.

8-45
8.2.g.i SUBFUNC"FIONS

8.2.9.1.1 DATA COLLECTION AND MAINTENANCE

Data pertaining to each hardware unit which will interface with the

application software must be available in the SSE. Data representative of

actual flight hardware components (e.g. IMUs, Rate Gyros) will come from the

TMIS. Other data, for example test unique data, will originate in the SSE.

This data will be maintained in a data base and interfaces must be provided

for the user to update and review the data.

8.2.9.1.2 DATA SELECTION

The data base will contain data for many hardware components, not all of which

will coexist in a single configuration. By identifying a subset which could

coexist, a specific configuration is defined. The ability to define

configurations and subsets of configurations will be provided through the use

of interactive menues and commands. The ability to to define and store

configurations will also be provided.

B.2.9.I.3 DELIVERY

Data from the data base will be extracted and delivered to target

environments. (See "Hardware Interface".) Thre target operating system will

then use the data base to provide the hardware interface services for both the

application and the user interface environments.

8.2,9.2 CHARACTERISTICS

An interface with the configuration control system will be provided to support

configuration control of data representing onboard hardware and some of the

testing configurations. The ability will also exist for users to define data

and configurations for testing without requiring configuration control. After

IOC, a representation of the actual onboard configuration, as well as test and

development configurations, will always be maintained within the system.

8_
8,2.10.O ON-BOARDDATAMANAGEMENT SYSTEM (DMS)

The On-board Data Management System will consist of the software and hardware

to support crew control of the Space Station (SS) structure and other SS

subsystems, These systems include a set of "core elements" such as

housekeeping data (e.g., time),_ data storage system, a Crew Interface

system, a network for support o? a distributed processing system, and an

operating system which supports many core and payload systems. The software

and hardware of the DMS will be configured into a network of subsystem Data

Processors (SDP's), Network Interface Units (NIU's), and data buses connecting

sensors/effectors into a network(s). The SSE will provide the environment ?or

development of the DMS. Once developed, the DMS will be made available in the

SSE for application softwarehardware development and verification.

8.2.10,1 SUBFUNCTIONS

8.2.10.1.1 SOFTWARE SYSTEMS

8.2.10.1.1.1 NETWORK OPERATING SYSTEM (NOS)

The Network Operating System will support process/data distribution and data

base interfaces as a service to the application development. Within the SSE,

the NOS will provide applications with the capability to configure software

into a network compatible to the on-board system ?or development and test.

8.2.10.1.1.2 DISPLAY GENERATION/SUPPORT

The principal interface of the SS crew will be the display unit (MultiPurpose

Application Console (or MPAC)). The DMS display generation/support software

will be provided in the SSE to support the generation and test of displays.

The display generation function will provide the options for diagnostics

sufficient to guide the development and verification of display(s).

8-47
8.2.10.1.1.3 REAL TIME OPERATING SYSTEM (RTOS)

The Real Time Operating System in conjunction with the NOS provides for a

complete application support environment.

8.2.10,1.1.4 DATA BASE MANAGEMENT SYSTEM (DBMS)

The Data Base Management System will provide the data storage and retrieval

necessary (in conjunction with the NOS) to support application archiveing of

data for trend analysis or for transmission via the Tracking Data Relay

Satelite (TDRS) or other Radio Freqrency (RF) means to the ground.

B.2.10.1,1,5 HARDWARE INTERFACE

The DMS must provide the application software and user interface environments

with an interface to the hardware sensors and effectors with which they will

be communicating. This service is necessary to isolate the application and

user interface environments from changes in hardware configurations. This

will be accomplished by maintaining a data base in the target environments

which contains a representation of the current configuration and data unique

to each hardware component present. The data in the data base will be used by

the DMS to provide addressing, scaling and formating of hardware data. Data

base maintenance will be dictated by changes in the configuration. The DMS

will provide an interface for users to indicate modifications to the current

configuration (e.g. replacing one component with another). When new hardware

is delivered to the station, associated data will be delivered from the SSE

and will be processed and stored in the data base by the DMS. An interface

will be provided to enter hardware components that are being discarded so that

the corresponding data in the data base will be deleted.

B.2.10.I.2 DMS HARDWARE SYSTEMS

The DMS hardware must be capable of supporting the functional requirements as

required by the on'board systems (both core systems and application systems).

It is assumed that the On-Board software functions will be a distributed

B-4B
system sharing data over a data link or "BUS". The DMS/SSE will provide the

hardware necessary for application development and test.

8.2.10.1.2.1 STANDARD DATA PROCESSOR (SOP)

The primary application processor will be a Standard Data Processor. The SSE

will provide one or more SDP's for execution of applications in the SS target

language.

8.2.10.1.2.2 NETWORK INTERFACE UNIT (NIU)

The Network Interface Unit will be the standard hardware unit which will

connect all SDP's to the network o? SDP's and sensors/effectors. The SSE will

provide for the NIU's just as it will with the SDP's above.

8.2.10.1.2.3 NETWORK BUS

The processor network will be interconnected with a bus or ring. In the SSE,

the bus(es) necessary for the Formation of a net for application testing will

be provided. The make up of this bus and the network as a whole must be

transparent to the user.

8.2.10.1.2,4 MASS STORAGE

The On-Board systems require a mass storage device(s) for software systems

such as the NOS, RTOS, Display generation and other software elements in

support o? the SS and to support data archival for trend analysis or ?or

retransmission to ground systems when RF transmission is more readily

available. Mass storage sufficient for application development will be

provided in the SSE.

8-49
8.2.10.1.3 DMS/SSE SOFTWARE TOOLS

There is a set of software programs which support any software development

which is normally _hought of as being resident in a host environment such as

in the SSE. Because of the nature of the Space Station, a subset of

development tools must be resident on-board. The Display Generation/Support

could be considered as in this categorary. Other tools include compilers,

linkers, debug, diagnostics, deloggers. This is not a complete list of such

tools. The allocation of these tools to DMS on-board or SSE will be

determined. Both the on-Board DMS and the SSE must support the upload and

download of programs and data. In the life time of the Space Station, a large

range of software and hardware and software upgrades must be supported.

8.2.10.2 DMS CHARACTERISTICS

The Data Management System must be flexible to support an environment where

the nature of the support is critical (involve life support systems, SS

attitude control, etc.) to very simple functions such as providing time and

other parameters to payload customers. Some of the critical systems such as

GN&C must not only be redundant but must be restartable in case o? a bus, SDP,

or other failure situation in which the critical functions are terminated. The

following are other generic requirements of the DMS.

• Software/Hardware interfaces must be well definded, simple and stable.

• The user (crew) interfaces must be easy to use and provide a step by step

method (e.g. menus) for the inexperienced user and a short cut For

experienced user.

• All crew actions must be logged on-board or ground for historical

processing in the SSE.

• Where possible, routine actions must be automated to support a mantended

environment as well as allowing the crew to pursue other tasks. This

automation must also be provided with crew override.

• On-board to ground and ground to on-board communications must be minimized

to conserve RF bandwidth.

8-50
8,3 SYSTEM TEST, INTEGRQTION & VERIFICQTION (STIV)

Previous sections of this report have addressed the various aspects of the

SSDS definition process. This section will discuss concepts associated with

the major steps in the STIV process that can influence key design and

programmatic decisions.

Task 2 (options development) identified and characterized several options

available in the STIV process that provide the opportunity for meaningful cost

and schedule savings throughout the evolutionary lifetime of the SSDS. These

options are being assessed as part of a major trade study (Task 3) to define

preferred techniques, methodologies, facilities and resources required For

STIV.

8.3.1 Test

SSDS testing definition and policies planning will be an integration of Level

SE&I direction and the preferred options identified in associated trade

studies. This integration will be structured around the scheduled

availabilities of SSDS elements. Cost will be a primary driver in structuring

the test program.

Early decisions are required in several areas (as discussed later) to identify

and schedule long lead time Facilities and resources for integration with

fiscal year Funding contraints into DTC/LCC planning.

Hardware should be designed to. maximize the use of commercially available test

equipment for both acceptance and qualification tests.

8.3.1.1 Development Tests

Development tests are engineering evaluation tests to minimize technical risks

and to provide proof of design concepts. They may include material selection,

Failure modes and effects, design/operating tolerances, etc.

8-51
For those elements judged to require engineering development testing, long

lead time requirements must be identified very early in the program. Hardware

development will utilize NASA testbeds, or similar facilities at the

developing contractors location. For software, the long lead items required

first are those development tools ?or the Software Support Environment (SSE).

These include the Higher Order Programming Languages, Support Software,

Operating Systems, Users Inter?ace Language, and the Network Operating System.

8.3.1.2 qualification Tests

Qualification testing, from both the functional requirements and the

environmental requirements viewpoint, can be one of the most costly items of a

large space program. The protoflight concept must be considered for

application to all elements o? the SSDS system to reduce costs.

The most cost-effective method of utilizing qualification units for flight

must be determined in each case. The protoflight concept can be implemented

by: increased design margins to arrive at a "no-test" or "qualification by

analysis" situation; the use o? additional inspection techniques after the

qualification test, such as open box inspections or X-ray examinations;

refurbishment or replacement of critical components in the assembly. Other

cost avoidance techniques are: deferred module testing, i.e., qualification at

the highest assembly level practical; selective environmental qualification

(all assemblies need not be qualified to the same level depending on location,

shielding, etc.); modified qualification levels, considering the criticality

of the assembly. These techniques will be examined early in the design phase

of all hardware assemblies requiring qualification testing.

In parallel with the development o? the SSDS system definition, Phase B Space

Station Systems Engineering will be defining the environmental levels for the

various hardware applications. Qualification testing planning will then move

into a more detailed phase with early emphasis on accommodating the

protoflight concept. Qualification testing should utilize acceptance test

software whereever possible to minimize costs.

8-52
8,3.1.3 System Tests

The anticipated SSDS testing will follow a sequence of ground segment

activation and checkout, integration and test of space segment elements

assigned to modules/launch packages, and integration of those elements within

the module. Some limited end-to-end testing possibly utilizing TDRSS may

occur during pre-launch integration efforts; final testing will occur during

on-orbit assembly/activation of station and platform(s).

Early planning will incorporate NASA SE&I defined policies and preferred test

options identified during trade activities. Key outputs of this planning will

be:

a. definition of simulators and the degree o? fidelity required.

b. definition of SDE support requirements.

C, definition of test sequence, (to be coordinated with

development/production scheduling).

8.3.2 Integration

The methods and degree of, both hardware/software integration, will be

identified initially by trade studies early in the program and refined as the

system matures. Both hardware and software will be under development by

several different contractors at several different locations, and this will

occur over a significant span of time. Therefore, a well conceived

integration plan must be available early in the program to identify GSE,

facilities, and other resources, including provisions for growth, so that

integration tasks and schedules are not impacted by lack of definition or

appropriate support.

The following sections discuss selected integration activities peculiar to

hardware and to software.

8-53
B.3.2.1 Hardware Inteqration

Integration o? the hardware components of the SSDS/SSIS will depend on several

Factors. The protoflight concept dictates that all hardware, in so far as

possible, will be designed and built with the end purpose of being usable as

flight hardware. This concept implies that the hardware will not be

continuously available in a development/integration facility, but rather, may

cycle through such a Facility as it progresses to a launch package onboard the

NSTS. Obviously, enough flight-type hardware must be available at some point

in the development phase to prove out critical issues such as data rates,

processing throughput, standardized payload interfaces, etc.

A policy For the degree oF standardization/commonality of the processors For

Bus InterFace Units, Common Data Processors, etc. must be established as this

will have an influence on the integration tasks by determining how many units

must cycle through the integration process.

Along with standardization/commonality, elements should be designed such that

commercially available test equipment can be used. The "golden box"

laboratory test approach should be used where practical to reduce GSE and

Formal test procedure requirements. This is justified for small production

quantity elements. However For elements to be produced in quantities and

whose interfacing inputs are likely to have significant excursions, then a

more rigorous text approach will be required. This is based on the premise

that For more applications/users, more design margin will be required.

The prelaunch readiness testing at KSC will be limited to that necessary to

confirm no degradation From shipping, depending on integration strategies

implemented. Each package to be delivered on orbit will receive a Functional

checkout before installation in the NSTS, including verification of NSTS

interfaces, as required.

8.3,2.2 Software Inteqration

The software integration process takes place at many different levels

8-54
throughout the system. Starting with the software unit or module level, the

modules will be successively integrated into increasingly larger and

multi-level packages.

To insure that all contractors/subcontractors generate compatible applications

software for their subsystem the SSE will provide a standard set of tools and

resources for general use. The Higher Order Programming Languages. Support

Software, Operating Systems, and the Users Interface Language (UIL), will all

be standardized.

8.3.3 Verification

Verification is the total process of planning and implementing a comprehensive

program to demonstrate that the SSDS satisfies all design, performance, and

safety requirements. The verification process will be an integration of

certification, development testing, acceptance testing, integration, final on

orbit checkout and supplemental analysis to support the total verification

program.

While the final verification of the System will not be established until the

IOC configuration is in place and operating in the space environment, much of

the verification effort will have been accomplished in NASA testbeds and other

development facilities.

The SSE will play a key role in this verification effort in supporting and

Furnishing time critical, long lead time items such as operating systems, and

other software development tools which are essential to the timely and cost

effective usage of the SSE for development, integration/verification, and

continued support.

Based on the SSDS functional requirements defined in Task 1, and the System

Definition of Task 4, all contractors will identify their best estimate of

requirements for the SSE including language processors, simulations,

diagnostic routines, and sizing and loading requirements. These requirements

will be refined and updated as the SSDS system evolves.

8-55
9.0 TECHNOLOGY RECOMMENDATIONS

The objective of this section is to identify and justify (provide supporting

rationale) those technology advancement items that represent a significant

"payoff" to the SSDS. This assessment will consider both SSDS architectural

needs as well as ongoing research and technology development activities (NASA,

DoD, Industry, Academia). The intent is to provide the basis for technology

development planning that will enhance cost-effective capabilities for IOC

and/or growth opportunities.

Technology items that were potentially beneficial to the SSDS were initially

identified and characterized during the options development (Task 2)

activities. Since this effort included the development of projected

capabilities, many advanced and immature technologies were considered. As the

system definition process evolved (supported by trade studies), preferred

technologies were identified based on their availability for IOC or growth.

In addition, an analysis was performed to identify those technologies that

would have been selected for IOC except for uncertainties in their maturity

levels. As a result, they may not have been selected due to an unacceptable

risk element. These items were then examined to determine the payoff for

continuing, accelerating or initiating NASA-sponsored research and technology

development efforts.

Table g-I lists the recommended technology advancement candidates that are

considered to have the highest priority. This assessment is based on the

following generic factors.

a. Benefit/Cost Ratio - Benefits include enhanced performance, lower

risk, improved crew productivity/safety and customer accommodation.

These are then compared to estimated cost at IOC and growth.

b, Levera_ - The opportunity to capture a substantial technology base

from other programs (i.e., VHSIC, etc.) with minimal investment.
Table 9-I

KEY TECHNOLOGY DESIGN/COST DRIVERS

TECHNOLOGY RATIONALE

POOR QIJAL rr_:

REAL-TIME EXPERT

SYSTEMS

ADVANCED SOFTWARE

DEVELOPMENT/MGT TOOLS

& TECHNIQUES

ONBOARD AI MACHINES

INCREASES CAPABILITIES OF EXPERT SYSTEMS AND BROADENS IHE RANGE OF IHEIR SS

APPLICATIONS. MAY REDUCE SS OPERATING COSTS AND IMPROVE PRODUCIIVIFY BY

RELIEVING FLIGHT AND GROUND CREW FROM ROUTINE TASKS.

REDUCE THE CHANCE OF SCHEDULE SLIPS AND COST OVERRUNS CO_N IN MANY LARGE

SOFTWARE INTENSIVE PROJECTS.

o IMPROVE SOFTWARE DEVELOPMENT PRODUCTIVITY

o IMPROVE SUBSYSTEM AUTONOMY AND PERFORMANCE

o ENHANCE AUTOMATION GROWTH POTENTIAL

FAULT TOLERANT FLIGHT o IMPROVE DATA SYSTEM RELIABILITY/AVAILABILITY/MAINTAINABILITY.

COMPUTERS

SMART ADAPTABLE BUS o IMPROVES DATA SYSTEM ARCHITECTURE FLEXIBILITY AND WILL IMPROVE OVERALL

INTERFACE UNITS NETWORK PERFORMANCE

READ/WRITE OPTICAL DISK o REDUCE DATA ARCIIIVAL COSTS, AFFECTS DATA BASE MANAGEMENT DESIGN, MAY ALLOW

DATA CAPTURE OF HIGH DATA RATE PAYLOADS WHEN OUT OF CONTACT WI[H GROUND

USER TEST AND CONTROL

LANGUAGE

o REDUCE PAYLOAD AND CORE SYSTEM INTEGRATION AND CHECKOUT COSTS

o INCREASE CREW PRODUCTIVIIY

o GIVE USERS MORE FLEXIBILITY AND CAPABILI'I'Y TO MANAGE THEIR PAYLOADS AND

SIJBSYTEMS

COLOR FLAT PANEL

DISPLAYS

DISIRIBUTED DATA BASE

MANAGEMENT TECHNIQUES

o IMPROVE CREW WORKSTATION "FRIENDLINESS" AND EXPAND CAPABILIIIES WI]H LOWER

POWER, WEIGHT, AND VOLUME

AFFECTS THE NUMBER, AND PERFORMANCE. REQUIREMEN-[S OF MASS STORAGE AND BUFFER

MEMORY [)EV.[CES AND FHEIR LOCATION WITHIN THE DATA NEIWORK ARCHIIECIURE -

GROUND AND SPACE

o IMPROVES USER ACCESS TO STORED DATA

9-2
C ° General Utility - The extent to which a technology can be applied

within the SSDS, the Space Station Program, or other NASA space

applications. In some cases (i.e., AI technology, etc.), the extent

to which the technology can be applied beyond NASA may also be a

major consideration.

d. Schedule - The urgency of starting an advancement effort to meet

desired use data. Includes benefit of accelerating schedule to be

consistent with IOC, thus eliminating costs associated with later

technology accommodation. Also minimizes schedule risk.

Table 9-i also identifies the rationale and key benefits associated with each

recommendation. Table g-2 summarizes the evaluation of each recommendation in

terms of the above factors.

9-3
Table g-2

IECIINOLOGY CANDIDATE EVALUATION

REAL-TIME EXPERI

SYSTEMS

ADVANL,_ SOFTWARE

DEVELOPMENI/MGT

TOOLS & TECHNIQUES

ONBOARD AI MACHINES

FAULT TOLERANt

FLIGHT COMPUTERS

SMART ADAPTABLE BUS

INTERFACE UNITS

READ/WRITE OPTICAL

DISK

USER TEST AND

CONTROL LANGUAGE

COLOR FLAT PANEL

DISPLAYS

DISTRIBUTED DATA

BASE MANAGEMENT

TECHNIQUES

Benefit/Cost Ratio Leverage

I

i High

I

J .........................................

i

i

i Medium-to-High

i

i

I

i High

i

o Commercial

o DOD

o Other NASA

o Primarily DOD

o Commercial

o Ground AI Hardware

o Other NASA

o DOD

i o

I Medium-to-High o

I °

1

I

I High

I

.L

I

I High

i

I

I

I Medium

l

I

I

I High

i

L

I

I

I High

I

I

Other NASA

OoO

Commercial

° Other NASA

° DOO

o Commercial

o DoD

o Other NASA

o Commercial

o DoD

o DOD

o Commercial

General utility

I

I Yes

I

I

[

Schedule

I

I l(X3/Growt h

I

J.

Yes

I

I

I lOC/Growth

I

i

I IOC (Maybe)

Yes I Growth

I

I

Yes _ IOC

I

J---_.

Perhaps

Yes

Perhaps -

depending on generality of design

IOC

IOC (if feasible)

Yes

Yes

Growth

IOC

IOC

IOC/Growth

9-4
I0.0 ISSUES AND RECOMMENDATIONS

As a preliminary result of the SSDS Analysis/Architecture study a set of

issues has been identified that need to have continuing attention in the

remainder of this study as well as in the Space Station Definition and

Preliminary Design studies and related activities. These issues are listed

below and (in some cases) contain recommendations for action that would lead

to resolution.

°

1) Accuracy and completeness of the Mission Requirements Data Base is

not adequate ?or use as a firm basis for SSDS architectural

decisions. Correlation and elimination of redundancy of nearly

identical proposed missions is still needed; complete, consistent and

accurately timelined mission data is also required. These conditions

are not expected to change in the near-term. Consequently, we have

accepted this data base as a "prototype" and have attempted to

speculate on reasonable excursions for key architectural decisions.

2) The quality, connectivity, and duty cycle requirements for video data

communications requirements have large excursions based on NASA and

contractor analyses information.

3) 'The operational relationship between the Space Station manned base

and the Co-orbiting Platform needs to be clarified so that the

communications network requirements and SS data management support

for COP can be established. The decision as to whether the COP and

Space Station will be at the same, or different, altitudes,hence

affecting line-of-sight connectivity, needs resolution.

4) The impact of design-to-cost (DTC) goals has not been factored into

the study and relative cost data has been used in our design

analyses. The DTC allocation could have major impacts on level of

IOC automation, use of advanced technology, system flexibility,

degree of system redundancy, and growth capability. The DTC

allocation must be developed and established as a key design decision

criteria.

.10-1
5) The need for security provisions has not been fully explored,

especially with regard to potential OOO use, and the potential mixing

of commercial, Foreign, scientific, and OOO users. Our study

considerations have been limited to commercial and scientific users.

Foreign users with technology transfer implications and OoO users

have not been considered.

6) Growth goals are only speculative. A quantification of growth goals

is needed to provide some consistency and discipline across the

various elements, systems, and technologies in the SS program. For

example, the decisions as to whether NASA will implement TDAS and

continue to support ACTS type technology affect SS program growth

planning. Realistic SSOS growth goals need to be established by NASA.

7) The tradeoff between subsystem autonomy and system flexibility/

expandability for onboard architecture configurations has a wide

range of possible solutions. Specific NASA feedback on our proposed

architecture is needed to guide future study activities.

8) The ability o? key technologies to support the IOC goals is not

firmly established in certain areas; e.g., expert system planners and

schedulers, space-qualified AI hardware, high rate data capture and

routing technologies, reliable, cost-effective large volume data

storage technologies. Realistic "selection freeze" dates need to be

established as a basis For IOC recognizing the need to minimize the

"technology gap." We expect that there will be a range of freeze

date because of different technical and programmatic factors for

different components.

g) The nature and degree of foreign involvement in the program needs

better definition. This involvement has potential widespread effects

on the SSD$ architecture. Will NASA be required to capture and

distribute foreign data7 What degree of monitoring and safety

assurance will NASA have regarding foreign module operations cojoined

10-2
to the Space Station? Do foreign users need real-time interaction

From their home Facilities? Future study activities should ensure

the accommodation of Foreign users when their needs and operating

modes are defined.

10) The degree of commitment by NASA to provide special purpose data

routing and processing facilities for the few proposed very high data

rate experiments can greatly affect the rest of the SSDS ground

network sizing and capabilities. We recommend a specified range and

cost bogey for this service be developed for customers to evaluate.

Any further analyses should be deferred pending customer community

assessment.

il) The extent to which the ISO/OSI upper layers should be strictly

applied in the onboard LAN, especially the Specific Application

Service Elements (SASE), needs additional evaluation before firm

design decisions are established.

iz) The division of the OSI layers between the NIU and the SDP has not

been completely resolved and is a key design decision requiring

further tradeoff analyses. Our current recommendations are included

in section 6.

i3) There is still some uncertainty about the extent to which hardware

commonality should be applied across SSP space elements due to

significant variations in operating environments. This will be

further evaluated as COP/POP requirements are developed and SS

architectural concepts are applied and evaluated.

10-3
REFERENCES

1. Space Station Data System Rnalysis/Architecture Study, Task 1 - Functional

Requirements Definition, DR-5, MDC Report No. MDC-1343, Revised 1 May 1985.

2. "Guidelines for Space Station Data Systems Standardization (Issue-l)," JPL

D-1414, April 1985.

° "CCSDS Reference Document on Space Data Systems Operation with Standard

Format Data Units System and Implementation Aspects," Issue I, November

1984.

4. "Recommendation for Space Data System Standards: Standard Format Data

Units -- Concept and Primary Label," CCSDS Document, Red Book, Issue-O,

December 1984.

5. "Recommendation for Space Data System Standards: Time Code Formats,"

CCSDS Red Book, Issue 2, November 1984.

6. "Recommendation for Space Data System Standards: Packet Telemetry," CCSDS

Blue Book, May 1984.

7. "Recommendation for Space Data System Standards: Telemetry Channel

Coding," CCSDS Blue Book, May 1984.

8. "Recommendation for Space Data Systems: Telecommand, Summary of Concept

and Service," CCSDS Green Book, Issue- , April 1985.

9. "Recommendation for Space Data System Standards: Telecommand, Part-l:

Channel Service," CCSDS Red Book, Issue-l, April 1985.

10. "Recommendation for Space Data System Standards: Telecommand, Part-2:

Data Routing Service," CCSDS White Book, Issue-6, April 1985.

R-I
Ii. "Recommendationfor Space Data System Standards: Telecommand, Part-3:

Data Management Service," CCSDS Red Book, Issue-O, April 1985..

12. "Recommendation for Space Data System Standards: Radiometric and Orbit

Data," CCSDS Red Book, Issue-O, November 1984.

13. Proceedings of the IEEE, Special Issue entitled "New International

Standard Architecture and Protocols ?or Distributed Information Systems",

Volume 71, No. 12, December 19B3.

R-2