DECEMBER 1985

g

/,____,; DC H1343A

I /I4fDAC ]

IBM

SPACE STATION DATA SYSTEM

ANALYSIS/ARCHITECTURE STUDY

Task 3 - Trade Studies, DR-5

Volume I

(NASA-CH-177842) SP_CE ST&TICN DATA SYSTEM

&NALY$1S/AHCHIT_C_gRE 5TUDI. _ASK 3: TRADE

STUDIES, DR-5, VOLUME I _McDonnell-Douglas

&stronautics Co.) 383 p HC AI7/BF AOl

CSCL 22B GS/t8

I186-20474

Unclas

0 _59 1
MCDONNELL/_

DOUGLAS

CORPORATION

DECEMBER 1985

SPACE STATION DATA SYSTEM

ANALYSIS/ARCHITECTURE STUOY

Task 3 - Trade Studies, DR-5

Volume I

MDC H1343A

REPLACES MDC H1943

DATED MAY 1985

MCDONNELL DOUGLAS ASTRONAUTICS COMPANY-HUNTINGTON BEACH

5301 Bolsa Avenue Huntington Beach, California 926'47 (714) 896-3311
PREFACE

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

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

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

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

into six tasks:

Task i.

Task 2.

Task 3.

Task 4.

Tasl< 5.

Task 6.

Functional Requirements Definition

Options Development

Trade Studies

System Definition

Program Plan

Study Maintenance

This report contains the results of Task 3. Trade Studies resulting from

Options Development (Task 2) were performed to aid in System Definition (Task

4).

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

Communications Corporation, IBM Federal Systems Division and RCA Government

Systems Division.

]"his report was prepared for the National Aeronautics and Space Administration

Goddard Space Flight Center under Contract No NAS5.-28082 as a part of Task 3

act:[vities.

Questions regarding this report should be directed to:

Glen P. Love

Study Manager

McDonnell Douglas Astronautics Company

Huntington Beach, CA 92647

(714) 896-2292

p_ECEDING PAGE BLAN;{ NOT FILMED

iii
iv
CONTENTS

TASK 2 VOLUME I

I SPACE AUTONOMY AND FUNCTION AUTOMATION

1.0 INTRODUCTION

1.1 Background

1,2 Issues

1.3 Trade Study Criteria

1.4 Applicable Options

2.0 METHODOLOGY

3.0 RESULTS

4.0 CONCLUSIONS AND REMAINING ISSUES

5.0 REFERENCES

II SPACE SHUI-FLE TO SPACE STATION SOFTWARE TRANSPORTABILITY

1.0 INTRODUCTION

1.1 Background

1.2 Issues

1.3 Trade Study Criteria

1.4 Applicable Option Papers

1.5 Alternatives

2.0 METHODOLOGY

3.0 RESULTS

3.1 Software Cost Model

3,2 Value of Current Shuttle Software

3,3 Size of Transportable Code

3.4 Value of Transportable Code

4.0 CONCLUSIONS/RECOMMENDATIONS

4.1 Conclusions

4.2 Recommendations

5.0 REFERENCES

III SYSTEM NETWORK TOPOLOGY

1.0 TRADE STUDY DEFINITION

1.1 Background and Requirements

1.2 Issues to Be Addressed

1.3 Criteria

1.4 Applicable Options

1.5 Alternative Configurations

v

1-3

1-4

1-6

1-9

1-12

1-14

i-.19

1-20

1-21

2-i

2-1

2-1

2-2

2-5

2--7

2-8

2-8

2-11

2-11

2-16

2-16

2-16

2-.20

2-20

2-20

2-24

3-1

3-1

3-.-1

3-1

3--1

3-2

3--2
2.0 PRELIMINARY ANALYSIS 3-2

IV

2.1 Space Station Network Nodes

2.2 The Traffic

2.3 The Links

2.4 Traffic Assignment

2.5 Topology Options

2.6 Simulation Description

2.7 Cost Assumptions

2.8 Preliminary Results

3.0 DETAILED ANALYSIS

3.1 Detailed Traffic Analysis

2.2 Options Description

3.3 Cost Assumptions

3.4 Sensitivities

4.0 ISSUES AND RECOMMENDATIONS

4.1 Physical Proximity to Higher Level

Processing

4.2 Evolution to ACTS or TDAS Environment

4.3 Sensitivity to Requirements

4.4 Conclusion

CO(I_UNICATIONS STANDARDIZATION

1.0 TRADE STUDY DEFINITION

1.1 Background

1.2 Issues

1.3 Selected Criteria

1.4 Requirements Affecting Selection of

Standards

1.5 Applicable Options

2.0 TRADE STUDY METHODOLOGY AND APPROACH

2.1 Implementation Option

2.2 How Should Standards Be Implemented7

2.3 What Standards Should Be Used?

3.0 RESULTS

3.1 Implementation Options

3.2 How Should Standards Be Implemented?

3.3 Wlnat Standards Should Be Used?

4.0 CONCLUSIONS, RECOMMENDATIONS AND ISSUES

3-4

3-7

3-20

3-22

3-22

3-29

3-34

3-35

3-36

3-37

3--42

3-44

3-66

3-69

3-69

3-70

3-71

3-72

4-1

4-.-3

4-3

4-4

4-4

4-5

4-8

4-9

4-9

4-15

4--16

4-20

4--20

4-20

4-20

4-21

vi
V ONBOARD LOCAL AREA NETWORKING 5-1

VI

1.0 INTRODUCTION

1.1 Background

1.2 Issues

1.3 Trade Study Criteria

1.4 Applicable Option Papers

1.5 Alternatives

2.0 METHODOLOGY

3.0 RESULTS

3 1

3 2

3 3

3 4

3 5

3 6

3 7

3 B

3 9

Configuration

Standards

LAN Topology and Media Access Methods

Voice/Video

Communications Functions (ISO/OSI)

The NIU

Connection Mode

Back-End Interfaces

Protocols and End-to-End Compatibility

4.0 CONCLUSIONS, RECOMMENDATIONS, AND REMAINING ISSUES

5.0 REFERENCES

Appendix A Decision Matrices

Appendix B Local Area Network Analysis

DISTRIBUTED OPERATING SYSTEM

1.0 INTRODUCTION

i.i Background

1.2 Issues

1.3 Trade Study Criteria

1.4 Applicable Option Papers

1.5 Alternatives

2.0 METHODOLOGY

3.0 RESULTS

3.1 Method of Accessing Remote Processes and Data

3,2 Addressing

3.3 Management of Memory Configuration Loads in

Processors

3.4 Presentation Layer Functions

3.5 Network Protocol Functions

4.0 CONCLUSIONS, RECOMMENDATIONS AND REMAINING ISSUES

5-3

5-3

5-5

5-6

5-7

5-7

5-10

5-11

5-11

5-12

5-13

5-24

5-25

5-31

5-36

5-38

5-44

5-44

5-45

5-47

5-55

6-'i

6-3

6--3

6-3

6""5

6-6

6-6

6-10

6-10

6-11

6-17

6-..21

6-25

6-26

6-30

vii
5.0 REFERENCES 6--.33

6.0 APPENDIX

VII SOFTWARE CONFIGURATION MANAGEMENT

1.0 INTRODUCTION

1.1 Background

1.2 Issues

1.3 Trade Study Criteria

1.4 Applicable Option Papers

1.5 Alternatives

2.0 METHODOLOGY

3.0 RESULTS

3,1 Alternative I - Provide a Single Package

3.2 Alternative 2 - Provide Multiple Packages

3.3 Alternative 3 - Provide a Tailorable System

4.0 CONCLUSIONS, RECO_ENDATIONS AND REMAINING ISSUES

5.0 REFERENCES

Appendix A

A.I Onboard Shuttle Software

A.2 Onboard Shuttle Reconfiguration Data

A.3 Kennedy Space Center Launch Processing System (LPS)

A.4 Space Laboratory Experiment Computer

A.5 Earth Resources Budget Satellite and Gamma Ray

Observatory

A.6 Space Shuttle Ground Based Support System

VIII SOFTWARE SUPPORT ENVIRONMENT FACILITY

1.0 INTRODUCTION

I.i Background

1.2 Issues

1.3 Trade Study Criteria

1.4 Applicable Option Papers

1.5 Alternatives

2.0 METHODOLOGY

3.0 RESULTS

3.1 Cost Comparisons

3.2 Risk Comparisons

3.3 Performance Comparisons

3.4 Standardization/Commonality Comparisons

6-34

7-1

7-3

7-3

7-5

7-7

7-10

7-10

7-11

7-13

7-13

7-18

7-20

7-24

7-26

7-27

7--27

7-33

7-35

7-39

8--'1

8-3

8-'3

8-5

8-.5

8-12

8-.12

8--19

8-19

8-19

8-22

8.-24

8-28

viii
3.5 Growth/Technology Insertion Potential Comparisons 8-29

3.6 Data Base Management Comparisons

3.7 Processor Management Comparisons

4.0 CONCLUSIONS, RECOMMENDATIONS AND REMAINING ISSUES

5.0 BIBLIOGRAPHY

6.0 APPENDICES

8-30

8-31

8-32

8-36

8-37

ix
6LOSSARY

A

A&R

A/A

A/D

A/L

A/N

AC&S

ACA

ACO

ACS

ACS/COM

ACTS

AD

AD

ADOP

ADP

AFOSR

AFP

AFRPL

A6C

A6E

AI

AIE

AIPS

ALl

ALS

ALS/N

AMIC

ANSI

AOS

AP

APD

APSE

ARC

Automatic

Automation and Robotics

Analysis/Architecture

Advanced Development

Atrlock

Alphanumeric

Attltude Control System

Attitude Control Assembly

Administrative Contracting Officer

Attttude Control and Stabilization

Attitude Control System/Communications

Advanced Communications Technology Satellite

Ancillary Data

Advanced Development

Advanced Distributed Onboard Processor

Advanced Development Plan

Atr Force Office of Scientific Research

Advanced Flexible Processor

Air Force Rocket Propulsion Laboratory

Automatic 6aln Control

Attempt to 6enerallze

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

xi ;.-"R_CEDING PAGE BLAi'_;( _JOT FIL_ED
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

CAD

CAE

CAIS

CAM

Automated Reasoning Tool

American Standard Code for Information Exchange

Airborne Support Equipment

Advanced Star/Target Reference Optical Sensor

Advanced Technology Advisory Committee

Alr Traffic Control

Authority to Proceed

Advanced Telemetry Processing System

Assembly Truss and Structure

Automated Visual Maintenance Information

Adoptive Wafer Scale Integration

Bridge

Block Adaptive Rate Controlled

Breadboard

Blt Error Rate

Built-ln Test

Bullt-ln Test Equipment

Buffer Interface Unit

Bus Interface Unlt

Built-ln Unlt

Ballistic Missile Defense

British Thermal Unlt

Bandwidth

Constrained

Command and Control

Command, Control, and Communication

Command, Control, Communication, and Intelligence

Communications and Data Handling

Communication and Tracking Subsystem

Communications and Tracking

Control and Warning

Checklist

Customer Accommodation

Computer-Aided Design

Computer-Aided Engineering

Common APSE Interface Set

Computer-Aided Manufacturing

xii
CAMAC

CAP

CASB

CASE

CATL

CBD

CBEMA

CCA

CCB

CCB

CCC

CCD

CCITT

CCITT

CCMS

CCR

CCSDS

CCTV

cdlM 2

CDG

CDMA

CDOS

CDR

CDS

CE

CEI

CER

CFR

CFS

CG

CIE

CIL

CIU

CLAN

CM

CM

CMDB

Computer Automatlc 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

Consultlve 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-Clrcult Television

Candelas per square Meter

Concept Development Group

Code Division Multiple Access

Customer Data Operations System

Critical Design Review

Control Data Subsystem

Conducted Emission

Contract End-Item

Cost Estimating Relationship

Code of Federal Regulations

Cambridge Flle Server

Center of Gravity

Customer Interface Element

Critical Item Llst

Customer Interface Unlt

Core Local Area Network

Configuration Management

Center of Mass

Configuration Management Data Base

xiii
CMG

CMOS

CMS

CMU

CO

COF

COL

COMM

COP

COPCC

COPOCC

COTS

CPCl

CPU

COL

CR

CR

CR&D

CRC

CRF

CRSS

CRT

CS

CSD

CSOL

CSMA/CO/TS

CSTL

CTA

CTE

CUI

CVSD

CWG

D&B

DAOS

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-orbital Platform

Coorblt Platform Control Center

COP Operations Control Center

Commercial Off-the-Shelf Software

Computer Program Configuration Item

Central Processing Unit

Channel Queue Limit

Compression Ratio

Change Request

Contract Research and Development

Cyclic Redundancy Checks

Change Request Form

Customer Requirements for Standard Services

Cathode Ray Tube

Conducted Susceptibility

Contract Start Date

Charles Stark Draper Laboratory

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

xiv
DARPA

DB

DBA

DBML

DBMS

DCAS

DCDS

DCR

DDBM

OOC

DDT&E

DEC

DES

DFD

DGE

DHC

DID

DIF

DMA

DMS

DoO

DOMSAT

DOS

DOT

DPCM

DPS

DR

DR

DRAM

DRD

DS&T

DSDB

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 Oeslgn System

Data Change Request

Distributed Data Base Management

Discipline Data Center

Design, Development, Testing, and Engineering

Digital Equipment Corp.

Data Encryptlon Standard

Data Flow Diagram

Display Generation Equipment

Data Handling Center

Data Item Description

Data Interchange Format

Direct Memory Access

Data Management System

Department of Defense

Domestic Communications Satellite System

Distributed Operating System

Department of Transportation

Differential Pulse Code Modulation

Data Processing System

Discrepancy Report

Data Requirement

Dynamic Random-Access Memory

Design Requirement Document

Development Simulation and Training

Distributed System Data Base

Data Storage Description Language

Data System Dynamic Simulation

Development, Simulation, Integration and Training

Deep-Space Network

Design to Cost

XV
DTC/LCC

DTG

E/R

EADI

ECC

ECL.SS

ECMA

ECP

ECS

EDF

EEE

EHF

EHSI

EIA

EL

EM

EMC

EMCFA

ERE

EMI

ERR

EMS

EMU

ERUDS

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 Htgh Frequency

Electronlc Horizontal Situation Indicator

Electronic Industry Association

Electrolumlnescent

Electromagnetic

Electromagnetic Compatibility

Electromagnetic Compatibility Frequency Analysis

Earth Rean Equator

Electromagnetic Interference

Executive Management Review

Englneerlng Raster Schedule

Extravehicular Mobility Unlt

Extravehicular Maneuvering Unit Decontamination System

Electro-optic

End of Life

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 Actlvtty

Fault Tolerant

Ford Aerospace and Communications Corporation

Functionally Automated Database System

xvi
FAR

FCA

FCOS

FCR

FDDI

FDF

FDMA

FEID

FETMOS

FF

FFT

FIFO

FIPS

fl

FM

FMEA

FNECA

FO

FO/FS/R

FOC

FOOB

FODS

FPR

FOR

FSD

FSE

FSED

FSIM

FSW

FTA

FTNP

FTSC

GaAs

6aAsP

6aInP

GaP

6APP

Federal Acquisition Regulation

Functional Configuration Audit

Flight Computer Operating System

Flight Control Rooms

Fiber Dlstrlbuted Data Interface

Flight Dynamics Facility

Frequency-Dlvlslon Multiple Access

Flight Equipment Interface Device

Floating Gate Election Tunneling Metal Oxide Semiconductor

Free Flier

Fast Fourier Transform

First in First Out

Federal Information Processing Standards

foot lambert - Unlt of Illumlnatlon

Facility Management

Fallure Modes and Effects Analysis

Failure Mode Effects and Criticality Analysis

Flber-Optlcs

Fall-Operatlonal/Fall Safe/Restorable

Flber-Optlc Cable

F1ber-Optlc 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

6alllum Arsenlde

Gallium Arsenic Phosphorus

Gallium Indium Phosphorus

Gallium Phosphorous

Geometric Arithmetic Parallel Processor

xvii
Gbps

GBSS

GEO

GEP

GFC

GFE

GFP

GFY

GIDEP

GMM

GMS

GMT

GMW

GN&C

GPC

GPP

GPS

GRO

GSC

GSE

GSFC

GTOSS

H/W

HAL

HODR

HDDR

HEP

HFE

HIPO

HIRIS

HMI

HM

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 Data Exchange Program

Geometric Math Model

6eostatlonary Meteorological Satellite

Greenwich Mean Tlme

Generic Maintenance Work Station

Guidance, Navigation, and Control

General-Purpose Computer

General-Purpose Processor

Global Positioning System

Gamma Ray Observatory

Ground Service Center

ground Support Equipment

(Robert H.) Goddard Space Flight Center

Generalized Tethered Ob3ect System Simulation

Hardware

Hlgh-Order Algorithmic Language

Help Desk Discrepancy Report

Htgh Density Digital Recording

Heterogeneous Element Processor

Human Factors Engineering

Hierarchical Input Process Output

Hlgh Resolution Imaging Spectrometer

Habitation Module One

Habitation Module

Hlgh Order Language

Hlgh Order Systems

Hlgh Performance Processors

Hlgh Resolution Imaging Spectrometer

Interactive

°..

XVIII
I/F

I/0

IBM

IC

ICAM

ICB

ICD

ICOT

ICS

IO

IO

IDM

IDMS

IEEE

IEMU

IF

IFIPS

ILD

IMU

INS

IOC

IOP

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 generatlon) Computer Technology

Interpretive Computer Simulation

Interface Diagram

Identification

Intelligent Database Machine

Information and Data Management System

Institute of Electrical and Electronic Engineers

Integrated Extravehicular Mobility 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 Polntlng 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

xix
IVA

IWS

JPL

JSC

KAPSE

KEE

KIPS

KOPS

KSA

KSC

Kbps

Ktpc

LAN

LaRC

LCC

LCD

LDEF

LDR

LED

LEO

LeRC

LIDAR

LIFO

LIPS

LISP

LlsP

LLC

LNI

LN2

LNA

LOE

LOE

LOS

LPC

LPS

LRU

LSA

Intravehlcular Activity

Intelligent Work Station

Jet Propulsion Laboratory

(Lyndon B.) Johnson Space Center

Kernal APSE

Knowledge Engineering Environment

Knowledge Information Processing System

Thousands of Operations Per Second

Ku-band, Single Access

(John F.) Kennedy Space Center

Klloblts per second

Thousand instructions per cycle

Local-Area Network

Langley Research Center

Llfe-Cycle Cost

Liquid Crystal Display

Long-Duratlon Exposure Facility

Large Deployable Reflector

Llght-Emlttlng Diode

Low Earth Orbit

Lewls Research Center

Laser-lnstrument Olstance and Range

Last In First Out

loglcal Inferences Per Second

llst Processor

Llst Processor

Logical Llnk Control

LISP Nachlne Inc.

llquld Nitrogen

Low-nolse Amplifier

Level of Effort

Low-earth Orblt Envlronments

Loss of Signal

Linear Predictive Coding

Launch Processing System

llne-Replaceable unlt

Logistic Support Analysis

xx
LSAR

LSE

LSI

LTV

LZPF

M

pP

MA

MA

MAPSE

Mbps

MBPS

MCAIR

MCC

MCC

MCDS

MCM

MCNIU

MDAC-HB

MDAC-STL

MOB

MDC

MDMC

MDRL

MFLOP

MHz

MIMO

MIPS

MIT

MITT

MLA

MMI

MMPF

MMS

MMS

MMU

Logistic Support Analysis Report

Language Senslty Editors

Large-scale Integration

LTV Aerospace and Defense Company, Vought Missiles Advanced

Programs Division

Level 0 Processing Factltty

Manual

Microprocessor

Multiple Access

Managing Activity

Minimum APSE

Million Blts Per Second

Million Blts Per Second

McDonnell Aircraft Company

Mission Control Center

Microelectronlcs and Computer Technology Corp.

Management Communications and Data System

Military Con_uter Modules

Multl-compatlble Network Interface Unlt

McDonnell Douglas Astronautics Company-Huntlngton Beach

McDonnell Douglas Astronautics Company-St. Louis

Master Data Base

McDonnell Douglas Corporation

McDonnell Douglas Mlcroelectronlcs Center

McDonnell Douglas Research Laboratory

Million Floating Point Operations

Million Hertz

Multlple-lnput Multlple_Output

Million (machine) Instructions Per Second

Massachusetts Institute of Technology

Ministry of International Trade and Industry

Multlspectral Linear Array

Man Machine Interface

M1crogravlty and Materials Process Facility

Module Management System

Momentum Management System

Mass Memory Unit

xxi
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

NMOS

NMR

NOS

NS

NSA

Manned Maneuvering Unit

Metal-Nitrlde 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 Fllght Center

Medlum-Scale Integratlon

Multlspectral Scanner

Man-Tended Approach

Mean Tlme Between Failures

Mean Tlme to Repair

Master Timing Unlt

National Aeronautics and Space Administration

NASA Communications Network

NASA Procurement Regulation

NASA Baseline

National Bureau of Standards

Network Control Center

NASA FAR'Supplement Directive

NASA Ground Terminals

NASA Handbook

NASA Integrated System Data Network

Network Interface Unlt

National Language

National Language for Queuing Simulation

NASA Management Instruction

N-Channel Metal-Oxlde Semiconductor

N-Modular Redundant

Network Operating System

Nassl-Schneldermann

National Security Administration

xxii
NSF

NSTSNTOS

NTE

NTRL

NTSC

Nd:YAG

08_4

O/B

OASCB

OCN

ODB

OOBMS

OEL

OES

OIO

OLTP

OMCC

OMV

ONR

ORU

OS

OSE

OSI

OSM

OSSA

OSTA

OSTDS

OTV

P&SA

P/L

PA

PAM

PASS

PBX

PC

PCA

National Science Foundation

National Space Transportation System

Navy Tactical Data System

Not To Exceed

NASA Technology Readiness Level

National Television Standards Committee

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 Llst

Operating Events Schedule

Operations Instrumentatlon Data

On Line Transaction Processing

Operations Management and Control Center

Orbital Maneuvering Vehicle

Office of Naval Research

Orbital Replacement Unlt

Operatlng System

Orbit Support Equipment

Open Systems Interconnect

Orbital Service Module

Offlce of Space Science and Applications

Office of Space and Terrestrial Application

Offlce of Space Tracking and Data Systems

Orbital Transfer Vehicle

Payload and Servicing Accommodations

Payload

Product Assurance

Payload Assist Module

Primary Avlonlcs Shuttle Software

Private Branch Exchange

Personal Computer

Physical Configuration Audit

°°°

xxln
PCA

PCM

PCR

PDP

PDR

PORO

PDRSS

PILS

PIN

PLA

PLAN

PLSS

PMAD

PMC

PN

POCC

POP

POPCC

POPOCC

PRISM

PSA

PSA

PSCN

PSL

PTR

QA

R

R&D

R&QA

R/M/A

R/T

RAD

RAM

RAP

RC

RCA

RCS

Program Change Authorization

Pulse Code Modulation

Program Change Request

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

Pseudonoise

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

Rellablllty/Malntalnablllty/Avallabtllty

Real Time

Unit of Radiation

Random Access Memory

Relational Associative Processor

Ring Concentrator

RCA Corporation

Reaction Control System

xxiv
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/W

SA

SA

SAAX

SAE

SAIL

SAIS

SAR

SAS

SASE

SATS

SBC

SC

SCR

SCR

relational Data Base

Regional Data Center

Roentgen Equivalent (man)

Radio Frequency

Regenerative Fuel Cell

Radio Frequency Interference

Request for Proposal

Red-Green-Blue

Review Item Disposition

Revision Item Description

Reduced Instruction Set Computer

Remote Manipulator System

Root Mean Square Error

Reconfiguratlon Network

Read Only Memory

Reuseable Orbit Transfer Vehicle

Resource Planning and Management System

Reed-Solomon

Rlvest, Skamir and Adleman (encryption method)

Real Time Execution

Sensor and Effector

Spacecraft

Software

Single Access

Structured Analysis

Science and Technology Mission

Society of Automotive Engineers

Shuttle Avionics Integration Laboratory

Science and Applications Information System

Synthetic Aperture Radar

Software Approval Sheet

Specific Application Service Elements

Station Accommodations Test Set

Single Board Computer

Simulation Center

Software Change Request

Solar Cosmic Ray

xxv
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 Nltrlde Oxide Semiconductor

Signal to Noise Ratio

State Of Art

Shuttle Operations and Plannlng Complex

Silicon On Saphlre

Statement of Work

Stored Payload Commands

Software Production Facility

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

xxvi
SRB

SRC

SREM

SRI

SRM&QA

SRMS

SRR

SS

SSA

SSA

SSCB

SSCC

SSCR

SSCS

SSCTS

SSDMS

SSDR

SSOS

SSE

SSEF

SSlS

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, Rellablllty, galntalnablllty, and Quality Assurance

Shuttle Remote Manipulator System

System Requirements Review

Space Station

Structural Systems Analysis

S-band Single Access

Space Station Control Board

Station Station Communication Center

Support Software Change Request

Space Station communication system

Space Station communications and tracking system

Space Station data management system

Support Software Discrepancy Report

Space Station data system

Software Support Environment

Software Support Environment Facility

Space Station Information System

Space Shuttle Main Engine

Source Selection Official

Space Station Operations Control System

Space Station Operations Control Center

Space Station Operation Language

Spacelab Software Operational Notes

Space Station Operating System

Space Station Program

Space Station Program Element

Space Station Program Office

Space Station Standard Computer

Space Station SystemTralner

Self Test and Recovery (repair)

Software Technology for Adaptable and Reliable Software

Standard Number

Standard Technical Institute

xxvii
STO

STS

SUSS

SYSREM

SI

SuUACS

TAI

TBD

TBU

TC

TCP

TCS

TDASS

TOM

TDMA

TDRS

TDRSS

TFEL

THURIS

TI

TM

TM

TMDE

TMIS

TMP

TMR

TMS

TPWG

TR

TRAC

TRIC

TSC

TSIP

TSP

TSS

TT&C

TTC

Solar Terrestrial Observatory

Space Transportation System

Shuttle Upper Stage Systems

System Requirements Engineering Methodology

Silicon

Submarine Advanced Combat System

International Atomic Time

To Be Determined

Telemetry Buffer Unlt

Telecommand

Transmissions Control Protocols

Thermal Control System

Tracking and Data Acqulsltlon Satellite System

Technology Development Mission

Time-Division Multiple Access

Tracking and Data Relay Satellite

Tracking and Data Relay Satellite System

Thln Fllm Electrolumenescent

The Human Role In Space (study)

Texas Instruments

Technical Manual

Thematic Mapper

Test, Measurement, and Diagnostic Equipment

Technical and Management Information System

Triple MUlti-Processor

Triple Modular Redundancy

Thermal Management System

Test Planning Worklng Group

Technical Requlrement

Texas Reconflgurable Array Computer

Transltlon Radiation and Ionlzatlon Calorimeter

Trade Study Control

Technlcal Study Implementation Plan

Twisted Shielded Pair

Tethered Satellite System

Telemetry, Tracking, and Communications

Telemetry Traffic Control

xxviii
TTR

TWT

U

UCC

UDRE

UIL

UON

UPS

URN

UTBUN

UTC

V&V

VAFB

VAX

VHSIC

VLSl

VLSIC

VV&T

WAN

WBS

WBSP

WDM

WP

WRO

WS

WSGT

WTR

XDFS

YAPS

ZOE

ZONC

ZnS

Timed Token Rlng

Travellng-Wave Tube

Non-restrlctlve

Unlform Commercial Code

User Design Revlew and Exercise

User Interface Language

Unlque Object Names

Uninterrupted Power Source

Unlque Record Name

Unlque Telemetry Buffer Unlt Name

Universal Coordlnated Tlme

Valldatlon and Verlflcatlon

Vandenberg Air Force Base

Virtual Address Exchange

Very Hlgh-Speed Integrated Circult

Very Large-Scale Integration

Very Large-Scale Integrated Circuit

Validation, Verification and Testing

Wlde Area Network

Work Breakdown Structure

Wldeband Signal Processor

Wavelength Olvlslon Multlplexlng

Work Package

Work Release Order

Workstatlon

White Sands 6round Terminal

Western Test Range

XEROX Distributed Flle System

Yet Another Production System

Zone Of Exclusion

Zone Of Non-Contact

Zlnc Sulfide

xxix
- ,

TASK 3 - TRADE STUDIES

INTRODUCTION

The primary objective of Task 3 is to provide additional analysis and insight

necessary to support key design/programmatic decision for options

quantification and selection for system definition. This includes: (1) the

identification of key trade study topics, (2) the definition of a trade study

procedure for each topic (issues to be resolved, key inputs,

criteria/weighting, methodology), (3) conduct tradeoff and sensitivity

analysis, and (4) the review/verification of results within the context of

evolving system design and definition.

Trade studies represent a systematic mechanism for deriving preferred

alternatives within a specific domain of interest. These domains of interest

(trade study topic) may be quite global in nature (i.e., standardization) and

cut across many technology/design boundaries or highly localized to focus on a

specific design problem. Such considerations must be organized into a logical

and structured framework to facilitate trade study scheduling, integration

(both with other trade studies and with system design needs), and

validation. This framework is the systematic design approach shown in Figure

I where trade studies are directly supportive of architectural needs both in

scope and level of design detail. Trade studies provide the insight within

specific domains of interest to support the stepwise refinement'of design

detail. This approach promotes interaction between successive design steps

and provides enhanced visibility/traceability for key decisions.

Trade study topics are actually "domains of interest" that include a number of

interrelated issues that cannot be easily "decoupled" or form a logical

technology related subset. These topics may include one or more "tradeoffs"

that attempt to resolve the key issues identified, The primary source of

trade data was developed under Task 2 (options development). This required an

integrated Task 2/3 approach to insure that all trade study objectives were

achieved.
(/)

ii

o o._._ _ _ ..m

°° I "__. I __

• • • • • • • • • •

rE

¢-

]

pee_

¢-

0

,u

e_

_r
In general, trade studies have many aspects that are quite unique to the

specific topic. These unique aspects are dictated by design/programmatic

needs as well as the nature of the issues to be addressed. However, these

needs are addressed within the framework of a systematic trade study

methodology. This includes the following fundamental concepts.

I , The establishment of a set of generic trade criteria as guidelines to

be applied to all trade study areas (see Table l). Trade study

unique criteria will be developed within the context of each area and

will include all relevent Task i requirements.

. The development of trade study definition reports (work packages)

that can be reviewed prior to conduct of the study.

. Adherence to sound system engineering practices that includes

traceability to requirements and sensitivity analysis.

4, Extensive peer group review,

TASK APPROACH

This section will describe the steps that define the task methodology and

approach. The key steps include:

Identify/Prioritize Trade Study Topics

Develop Individual Trade Study Definition Workpackages

Definition Workpackage Review

Conduct Trade Study

Trade Study Documentation

Review and Validation

A list of trade study topics was developed early in the program based on

emerging designprogrammatic drivers that were identified during requirements

definition (Task 1) efforts. The topics were organized to accommodate a
Table 1. Trade Study Criteria

System generic

- Cost

• Development (nonrecurring)

• Unit (recurring)

• Life cycle (training, maintenance, operation)

- Risk

• Development (technology readiness)

• Production (producibility, cost/schedule)

- Performance (specific parameters are trade-study unique)

- Standardization/commonality

• Availability of supported standards

• Degree of commonality potential

- Growth/technology insertion potential

Onboard hardware generic

- Physical characteristics (volume, weight, power, thermal)

- Environment characteristics (radiation tolerance, elc.)

- Reliability/availability/maintainability

Unique criteria for individual trades
logical mapping of option categories into trade study areas. As system

definition (Task 4) activities progressed, this mapping, the list of trade

study topics and the associated prioritization of topics were refined to

reflect evolving architectural needs. Table 2 identifies the current list of

active trade study topics in priority order. Note that the priority ordering

does not necessarily reflect criticality but rather the sequence and

interaction required to support the system definition process. Many of these

topics have a one-to-one correspondence with Task 2 option categories and the

corresponding options information base provides the primary source of inputs.

Other topics represent a mapping of several option categories, some of which

are required for other trade studies or key design/programmatic decisions.

Once a prioritized trade study was initiated, a formal problem definition was

developed and documented in the form of a workpackage. These definition

workpackages were subjected to Team and NASA review as a mechanism For

focusing trade study activities. This definition workpackage includes the

following items:

i ,

Reason for Trade Study. Purpose and objectives of the trade study

with supporting rationale.

, B_ackground. Supporting descriptive data that establishes context for

the study. Includes references to key driving requirements that will

influence the study,

,

I_ssues. This section identifies major issues that the trade stud}/

will address and attempt to resolve.

4. _A.p.plicable Options. Identification of option categories that will be

a primary source of input parameters for this study.

, Trade Study Criteria. Identifies all generic and study-unique trade

criteria that will be considered in the tradeoff analysis. Criteria

will include all relevent requirements developed by Task 1.

Weighting of criteria will be addressed during the trade study.
Tabl e 2

TRADE STUDY STATUS

GSFC Review NASA Review

TRADE

DEFINITION DEFINITION ANALYSIS PRELIMINARY PRELIMINARY

TRAOE STUDIES INITIATED I COMPLETE INITIATED PRESENTATION DOCUMENTATION

SPACE AUTONOMY X I X 11/84 5/85

I

FUNCTION AUTOMATION X I X 11/84 5/85 (1)

I

SOFTWARE TRANSPORTABILITY X I 8/85 X 8/85

I

SYSTEM NETWORK TECHNOLOGY X X 2/85 5/85

COMMUNICATIONS STANDARDIZATION

I 12/84

I

12/84 2/85 5/85

ONBOARD LOCAL AREA NETWORKING X 11/84 X 2/85 5/85

BIU/TRANSMISSION MEDIA X II/84 X 2/85 (3)

DISTRIBUTED OPERATING SYSTEM X 3/85 X 5/85 (4)

SOFTWARE DEVELOPMENT X 3/85 X 5/85

FAULT-TOLERANT COMPUTING X 3/85 X 5/85

SPACE QUAL. COMPUTERS X 3/85 X 5/85

DISTR. DATA BASE MANAGEMENT X 3/85 X 5/85

SYSTEM INT., TEST., & VERIF. X 3/85 X 8/85

I

CREW WORKSTATIONS X 11/84 X 5/85

I

LANGUAGES - HIGHER ORDER & TEST X 5/85

I

MASS STORAGE X 3/85 X 5/85

I

SPACE COMMUNICATIONS X 3/85 X 8/85

l

COMMAND AND RESOURCE MANAGEMENT X 5/85 X 5/85 (5)

(I) Combined with Space Autonomy - New Title: Space Autonomy and Function Automation

(3) Incorporated into Onboard LAN Study

(4) Two Studies: Software Configuratlon Management and Software Development Environment Facility

(5) New Study performed because of importance to System Definition
. Methodology and Approach. General description of procedure and any

special tools or techniques employed.

Once a trade study workpackage had been reviewed and approved, the actual

conduct of the tradeoff analysis/evaluation was initiated. Trade study

procedures were generally tailored to specific topics, however, systemmatic

engineering processes were applied as appropriate. This includes a

sensitivity analysis to determine the factors that contribute most to the

relative ranking of top alternatives. Sensitivity analyses provide added

insight in assessing the study results to determine design and programmatic

driving ?actors. They are also used to identify technology items that could

have significant payoff (performance or cost) but are currently perceived to

have unacceptable elements of risk. These technology items may be candidates

for advanced technology development and demonstration. Once preliminary study

results are available, a trade study report is developed to provide

preliminary documentation from Team/NASA review and validation.

SUMMARY

The preliminary Task 3 (Trade Studies) documentation included in this report

has been organized into separate trade study reports and packaged as two

volumes. Only those trade studies that directly influence major SSDS system

design decisions are included in this report. These are identified in Table 2.

Table 3 shows a summary of the Sections of this report and the respective

Trade Studies for each section. It also shows which sections ,are contained in

the respective volumes,
Table 3

0

1.1.1

.-I

0

SECTION

I.

II.

III.

IV.

V.

VI.

VII.

VIII.

TRADE STUDY

SPACE AUTONOMY AND FUNCTION AUTOMATION

SOFTWARE TRANSPORTABILITY

SYSTEM NETWORK TOPOLOGY

COMMUNICATIONS STANDARDIZATION

ONBOARD LOCAL AREA NETWORKING

DISTRIBUTED OPERATING SYSTEM

SOFTWARE CONFIGURATION MANAGEMENT

SOFTWARE DEVELOPMENT ENVIRONMENT FACILITY

IX.

X.

XI.

XII.

XIII.

XIV.

XV.

XVI.

XVII.

SOFTWARE DEVELOPMENT TEST & INTEGRATION CAPABILITY

FAULT TOLERANT COMPUTING

SPACE QUALIFIED COMPUTERS

DISTRIBUTED DATA BASE MANAGEMENT SYSTEM

SYSTEM INTEGRATION TEST AND VERIFICATION

CREW WORKSTATION

MASS STORAGE

COMMAND AND RESOURCE MANAGEMENT

SPACE COMMUNICATIONS
I. SPACE AUTONOMY AND FUNCTION AUTOMATION

I-I
SPACEAUTONOMYANDFUNCI'IONAUI"OMAI'IONTRADESTUDY

1.O INTRODUCTION

a. Trade Study Objective. This trade study is performed to identify and

develop design requirements (characteristics that reflect level of automation)

for each SSDS function and to allocate the SSDS function in total or in some

distributed fashion, to space or ground, for both IOC (Initial operational

Capability) and evolutionary growth of the Space Station program.

b. Definitions Related to Autonomy/Automation. To facilitate technical

discussions on the trade study, a set of definitions of terminologies related

to automation and autonomy are abstracted from various NASA and other

documents as follows:

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.

Telepresence: The ability to transfer a human's sensory perceptions

(e.g., visual, tactile, etc.) to a remote site.

Teleoperation: Remote manipulation in which humans are responsible for

generating control signals.

Robot: A generic term, connotating many of the following ideas: A

mechanism capable of manipulation of objects and/or movement having enough

internal control, sensing, and computer" analysis so as to carry out a more or"

le_s sophisticated task. The term usually connotes a certain degree oF

1-3 PI_F.CEDING PAGE BLAICK I_OT FilJAED
autonomy, and an ability to react appropriately to changing conditions in its

environment.

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

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

effecting/manipulation, with human supervision.

Space Autonomv: The independence of the onboard subsystems from direct,

real-time control by the ground (crew or machines) for a specified period of

time.

Artificial Intelligence: A discipline which attempts to simulate or

duplicate the efficient problem - solving capabilities of humans.

E.x.pert system: A knowledge-based system which stores, processes, and

utilizes a large data base of information concerning a specific area of

knowledge to solve problems pertaining to that area. Expert systems are not

self.-adaptive but do provide the ability to generate new concepts and

relationship about knowledge already in the data base.

I,I BACKGROUND

a. Advanced Technology Advisory Committee Study. The Advanced

Technology Advisory Committee (ATAC) has provided recommendations on

automation and robotics options for use by contractors in their Phase B Space

Station definitions and preliminary designs [1]. Fhe ATAC final report

published in April 1985, among other things, will assess the impact of the

various automation concepts for use in Space Station. The assessment study

performed by Stanford Research, Inc. (SRI) International, determines the

automation levels which would be technically feasible about 10 years after the

Initial Operational Capability (IOC) has been established. The ATAC studies

not only identify the feasible automation levels but also design features

which are required by IOC to enable the integration of enhanced automation

1-4
capabilities for future hardware/software upgrades, both onboard and ground.

These reports are currently being assessed For impact on SSDS System

definition.

b. Benefits of Automation and Autonom V. Task 1 developed a function

list and the corresponding functional performance requirements For SSDS

functions. Each of these functions will be allocated to onboard and/or

ground. It is likely that all or nearly all of the allocated functions are

automated more or less for software implementation. The advantages of SSDS

function automation can be summarized as follows:

(1) Lower life Cycle Cost

o Functional operations are performed by Data Processing (DP)

hardware/software instead of man.

o Autonomy minimizes (or eliminates) dependence on communication

links.

(2) Increase Productivity

o Minimize chances for human error

o Free crew from monotonous, boring, repetitious activities

o Optimize crew/operator resources in core or payload

o Improve system performance

(3) Time Responsivity

o Meet time critical requirements

o Improve response times

(4) Safety

o Minimize hazardous (human) operations

c. Methods of Achievinq Automation/Autonomy. Automation is the keynote

of this study. Automation techniques, which can be applied to achieve

autonomy, inch.lde artificial intelligence (AI), teleoperation, telepresence

and robotics as defined above. In addition, there are widely applied

1-5
conventional (or often referred to as algorithmic) automation approaches. By

definition, a conventional approach is an automation technique wherebya

machine is programmedto respond to a predefined set of conditions with a

predefined set of actions. The actions, which may be conditional, can be

accomplished by use of such programming language as "IF-THEN-ELSE"

statements. Responses, however, are governed completely by the designer's

ability to anticipate the situations which the machine will encounter.

Therefore, conventional (or algorithmic) automation works best for well

defined situations. Artificial intelligence is known as a branch of computer

science dedicated to the design and implementation of computer programs that

make human-like decisions, and can be adaptive and more proficient at making

decisions. AI systems, such as expert systems, interact with their operators

in a "natural" way which mimics intelligent behavior.

A closely related trade study on AI Automation will determine the

applicability of the advanced AI automation techniques to SSDS functions for

IOC and evolutionary growth of the Space Station program.

1,2 ISSUES

a. Cost. Figure I shows a copy of NASA's Program Planning Guidelines

that indicate a "cost" constraint to achieve an "opportunity autonomous" Space

Station. The issue here is to determine the degree of autonomy consistent

with the cost constraint. For instance, the (]DG's (Concept Development Group)

output report, that specified an autonomy requirement for the total ground

crew to eventually consist of one person on a Monday through Friday, eight

hour per day schedule, clearly satisfied NASA's autonomy goal. However, the

cost to achieve this degree of autonomy at a given onboard productivity level

was not addressed.

It is commonly agreed that high cost is expected for automation/autonomy

software development. Therefore, the allocation of the SSDS Functions to

onboard and the decision on the degree of function automation for an

operationally autonomous Space Station have to be made consistent with the

cost constraint.

1-6
o

o

E

0

0"o

_0

U

_o

$.,+_

I. LI.

_r._

I.

1-7
b. Automation Technoloqy Maturity. - As discussed previously,

conventional approaches for function automation are well understood and have

been widely utilized in many systems. Artificial Intelligence and robotics

techniques show potential for space autonomy applications but are not yet

mature. A few schedulers have already been developed in the aerospace sector

by using expert system approaches and several others are currently under

development. It should be noted that, in general, these expert system

schedulers are not necessarily reconfigurable to a new application, such as

those required for the SSDS. Expert systems are the current state-of-art in

AI technology and are in use in many applications. They are not, however, an

off-the-shelf item. The availability of tools and methodology to build expert

systems tailored to the Space Station applications can be expected for the

lOC.

c. Provisions for Growth Past IOC This trade study, will consider not

only the SSOS function allocation/ automation for IOC; but also for a)

adding/expanding functions as required, b) migrating functions from ground to

onboard, and c) increasing the degree of automation past IOC to the year

2000. To meet the study purpose, two cases have been developed as shown in

the matrix output provided in section 3.0. The first case is to allow an

automated payload/core system in space, if the payload/core commands/data are

originated in flight. The second is that to migrate the diagnostics support

SSDS function to onboard for growth.

For growth past IOC, preliminary results show great potential for expert

systems. As the technology matures, expert system(s) can be used for

developing short-term schedules. They can also be used for core or customer

systems status monitoring, and for OTV/OMV checkout and diagnostics. A robot

may be used in space replacing or supplementing an EVA astronaut to perform

many tasks, offering improved safety, productivity, and performance capability.

A separate trade study on AI Automation will discuss in detail the

applications of advanced automation techniques, such as robotics and expert

systems, to the SSDS functions for IOC and growth of the Space Station

Programs.

1-8
d. Dependence on Communication Link The space-to-ground communication

link is a finite bandwidth resource that must be shared by many users. The

demands of the Space Station Program on this link will be very high just to

transport primary mission data. The link is also subject to outages because

of the zone-of-exclusion and due to system failures. Therefore, minimizing

dependence on this link is an important potential benefit of space autonomy.

1,3 TRADE STUDY CRITERIA

1.3.1 Generic. These criteria are generic and are applied to all SSDS

trade studies.

a, Life Cycle Cost

o Development and Maintenance cost of hardware and software.

b. Risk

o Technical

o Schedule

C • Safety

o Crew safety

o System failure

d , Reliability and Availability

o Hardware

o Software

e , Growth

o Technology insertion

o Design extendability

1-9
1.3.2 Trade Study Unique

Qs shown in Figure I, there are seven key drivers used as the trade unique

criteria for SSDS function allocationautomation. They are criticality,

impact, co-location, communication link availability, ?unction autonomy,

response time, and communication link bandwidth. The way they are used for

allocating the SSDS functions and assessing degree of automation for function

automation will be discussed in Section 2.0. This section provides their

definitions as follows.

a. Criticality. It is defined as a single character code with a fixed

number to indicate the necessary recovery time for failures involving SSDS:

Numerical

Code Oescripio n

No interruption allowed, redundant

Recover within 10 seconds, hot backup

Recover within lO minutes, cold backup

Recover within 24 hours, simple repair, LRU (Line

Replaceable Unit) available

Recover within 21 days, safe haven used until recovered

Recover within 90 days, next logistics supply cycle

No limit on recovery

It should be noted that the smaller is the numerical value of the indicator,

the more critical (shorter) is the time required ?or recovery when SSD$

failures occur.

b. In_.act. It is defined with a fixed number to indicate consequences of

failures of the SSDS as follows:

1-10
Numerical

Code Description

1

2

3

4

5

6

Loss of life

Hazard, damage to Space Station

Damage to Space Station or mission equipment

Mission aborted, loss of key data, or economic penalty

Crew or operator inconvenience

No substantial impact

It should be noted that the smaller the number, the more severe the

consequences of the SSDS failures.

c. Physical Co-location of Function Data Source and Function User

(crew/customer_. This criterion is set for implementing software function in

space or on ground where input data is generated.

d. Space/Ground Communication Link Availability. In checking the

availability of the telemetry/telecommand transmission link, the link related

components, such as blind spot in TDRSS (tracking and data relay satellite

system) coverage, link MTBF (mean time between failure) and link MTTR (mean

time to recovery), should be considered for allocating SSDS functions to

onboard/ground.

e. Function Autonomy. The SSDS functions with significant inter--functiorl

input/output rates should be grouped and allocated as a group for function

automation.

f. Response Time. It relates to data transmission delay due to

space/terrestrial communication links (i.e., the roundtrip 'FDRSS/DOMSAF delay

approximately 2 seconds.

g. Space/Ground Communication Link Bandwidth. During SSDS function

allocation, considerations should be given to the finite bandwidth of the

communication link allocated to the Space Station.

1-11
1.4 Applicable Options. The following options have been defined in detail and

are documented in the options development report (Task 2). They are

applicableto this trade study.

2.2.2 Autonomy/Automation

2.2.2,2 Function Automation Options

2.2.2.3 Space Station Autonomy (Ground/Space)

a. O_ptions for Autonomy Options for autonomy, in general, can be

categorized into three types, viz., space autonomy, ground implementation, and

space/ground shared implementation. As defined by NASA, space autonomy means

that the onboard subsystems are independent from direct and real-time control

by the ground (crew or machine) for a specific period of time. That implies

an onboard capability to perform essential subsystem Functions, many of which

have traditionally been done on the ground. To do these (subsystem) functions

onboard with few or no people requires a high degree of automation. This

degree of space autonomy depends on what level of automation onboard is

achievable and affordable, as it will be discussed in the next section.

b. Options for Automation - Degree of Automation As an SSDS function is

allocated to onboard or ground based on the trade unique criteria given above,

a decision has to be made on whether the allocated Function is to be

automated; if so, to what degree will it be automated? A resolution to this

question, in general, is that for any onboard-allocated function crew and

SSDS resources are required. The degree of automation is an expression of the

mix of crew and SSDS resources. The concept of the degree of function

automation is delineated as shown in Figure 2. The horizontal line on the

figure can be interpreted as a scale for measuring the degree of automation

relative to the required amounts of crew and SSDS resources. The left-.most

point, L, on the scale represents the labor intensive extreme (i.e., the

maximal crew resource) while the right-most point, R, represents the automated

extreme where no crew resource is required, l"he portion of the scale between

1-12
_,¢)I[

t/) (..)

t_

OI.U

-'_nL_

Q_

O Q= I_J

Z (,.) _

" :3[ _

e"

O

E

O

cO

U

O

@,)

_J

_J

t_

O')

olm

L_

1-13
points, S and R, is partitioned into two regions for mapping all the allocated

SSDS functions, by three curved lines. They are manual, interactive, and

automated lines as shown in Figure 2, and abbreviated as M, I, and A,

respectively, to represent the degree of automation for an a11ocated SSDS

function.

The region between points L and S is for any function that requires no SSDS

resource. The region between $ and T represents the M degree of automation

for which an allocated function requires minimal SSDS resource at point S, and

requires increasing SSDS resources (with a corresponding decrease in

crew/operator activities) proceeding towards point T. The phenomena app].ies

similarly to an allocated function at an I automation level in the interactive

automation region between T and R. The automated region at point R, as

described above for an allocated function designed at an A automation level

represents the automated extreme with maximum SSDS hardware and software

requirements for functional implementation.

c. Function Automation and Responsibility/DP Resource Assignment As

noted, the SSDS must provide data processing (DP) resources, both hardware and

software, for implementing the functions allocated to the SSDS. The type and

extent of the DP resources provided for function implementation depends on the

designated level and type of automation. Figure 3 depicts the overall

relationship between responsibilty assignment (onboard/grond crew, machine)

and data system resource assignments (onboard/ground) for the different

degrees of function automation.

2.0 METHODOLOGY

Figure 4 depicts the systematic procedures set up by this trade study for

producing the matrix output as shown in Section 3.0. The key elements of this

procedure are described below.

1-14
I I.,J _.'-

zI

i ,_,.. :_ :_I

=)z h-¢_II

_c_z "_

_r

|.__

II

II

1-15
<:E

co

,=E

I.--

(/1

p- z

LJJ

:E

i.i

L_Z0

I---

(JZ

1.4-

U')

V1

(/1

.v.

(/1

<E

p--

1-16
_. SSDS Function List Task 1 has defined the functions and the

functional performance requirements for the SSDS. The SSDS functional

requirements are organized into a hierarchical set of seven top-level

functions as follows.

1.0 Manage Customer/Operator Delivered Data

2 0 Manage CustomerOperator Supplied Data

3 0 Schedule and Execute Operations

4 0 Operate Core Systems

5 0 Manage SSDS Facilities

6 0 Develop, Simulate, Integrate, and Train

7 0 Support Space Station Program

The organization of functions is carried from the top-level down to the third

and fourth levels to form a complete $SDS function list consistent with the

SSDS data flows. This complete 4-1evel SSDS function list will be used to

develop the function allocation/automation matrix as shown in Figure 4 in

section 3.0.

b. SSDS Function Requirements Data Base Task 1 has developed the

function requirements data base [2]. Included in the requirements data base

for each function on the function list are those functional characteristics

and performance requirements, such as criticality for recovery time, impact,

response time, automation level, a11ocation location, input/output functional

interface, and total data bits in terms of time interval and data rate. These

information data parameters are abstracted and evaluated to formulate the

matrix output, as described in the following sections.

c. Interface of Trade Unique Criteria and Requirements Data Base As

delineated in Figure 4, the matrix output consists of three major portions:

the SSDS function list, the assessment of a11ocation criteria for each

function and the resulting decisions for allocation (onboard vs ground) and

degree of automation, as i11ustrated in Figure 5. Taking SSDS function 1.1.1,

"Acquire Real-Time Data" as an example the following will il].ustrate how to

1-17
interpret time entries under the seven "Allocation Criteria" columns that were

derived from the SSDS Function Requirements Data Base: (the seven trade study

unique criteria were defined in section 1.3.2).

C1 - Criticality is "2" (recover within I0 seconds)

C2 - Impact is "5" (crew/operator inconvenience)

C3 - Co-location is marked with "Y" (where Y is used as a check mark)

This co-location information is obtained from a program "sort"

(through the function requirements data base),that shows all the

functions of l.l.l, 1.1.2, ---, 1.1.5 under function i.I.

C4 - Communication Link Availability is marked with "Y".

This information is obtained by observing the following:

A program "sort" (an input/output function interface).

Function 1.1.1 is output to Function 1.3.2, Data Capture.

Function 1.1.1 is allocated to onboard whereas Function 1,3.2 is

allocated on the ground.

As a result, the communication link availability is required for

functional interface (for data transmission from space to ground)

between these functions, one onboard and one on ground.

(5) Function Autonomy is marked with "Y"

(significant interaction with other SSDS functions)

(6) Response Time is marked with "Y"

(Data base shows a response time of 2000 Ms)

1-18
(7) CommunicationLink Bandwidth is markedwith "Y"

(data base showsdata rate is 1330 K bits/second at a one-second time

interval)

3 ,O RESULTS

Figure 5, SSDS Function Rllocation/Rutomation Criteria and Decisions, is

the final product of this trade study. It contains the preliminary decisions

for function allocation to onboard and/or ground, and for the degree of

function automation for each SSDS function. It also includes the assessment

of criteria extracted from the requirements data base used to derive these

decisions.

The column headings, abbreviations, and markings on Figure 5 under allocation

criteria and decisions related to each SSDS function, are defined below:

o The C1, C2 ..... C7 used on the figure are defined below and correspond to

the criteria described in section 1.3.2.

Cl: Criticality

C2: Impact

C3: Physical co-location between function data source and function user

C4: Space/ground communication link availability

C5: Function autonomy

C6: Response Time

C7: Space/ground communication bandwidth

The numerical code 1, 2, 3 ..... under C1 and C2 represents the level of

significance (ranking) of the allocated function as defined in section

1.3.2.

o ]he check mark "Y" under the other five trade unique criteria identifies

the correlation between the allocated function and the associated

criterion.

1-19
O and G under "Decisions Allocation":

O : Onboard

G : Ground

A, I, and M under "Decisions Automation":

A: Automated (can be any automation technique)

I: Interactive

M: Manual

In case of multiple levels of automation assigned to an allocated

function, such as "A,I", or "A,I,M," it implies that the a11ocated

function (e.g., subfunctions under 5.1.2, Flight Resource Management,

which is relatively large in terms of functional characteristics and

performance requirements), is usually implemented with part of the

function at Manual level, part of it at interactive level, and part of it

at automated level.

o Any markings, such as I, 2 ..... Y, O, G, A, I, and M assigned only to a

higher level function imply that same markings are assigned to ali

subfunctions under it (without repetition).

4.0 CONCLUSIONS AND REMAINING ISSUES

The trade study has developed an output matrix as shown in Figure 5. This

product, however may be subject to updates under the following foreseeable

situations.

a. ATAC Final Report The final report of the Advanced Technology

Advisory Committee (ATAC) was not available at the time of completion of this

trade study. The ATAC report includes recommendations for automation related

to the SSDS and could significantly influence the final results of this trade

study. Those reports are under evaluation.

1-20
b. Task 1 SSDS Function List and Requirements Data Base l"he SSDS

function list provides the basic framework for the allocation/automation

matrix output. The allocation of each function to onboard or ground and the

assessment of degree of automation to each allocated function are determined

by the function characteristics and its performance requirements. Therefore,

when SSDS Function definition changes, function additions and/or function

deletions occur, the SSDS function list and the Requirements Data Base will

change. Consequently, the decisions on function allocation/automation will be

affected accordingly, and the output matrix will be automatically updated.

c. S.pecific Automation Technique for Future Assessment. As noted, when

an allocated function in the output matrix is assessed with an "A" for

Function automation, it implies that the function is at the automated extreme,

by using any automation techniques. If later trade studies show that expert

system (included in AI automation) are cost effective for such functions, then

the automation assignment "A" will be changed to an "E" to reflect this

recommendation.

5.0 REFERENCES

[I] Summary on the NASA's Advanced Technology Advisory Committee Study, by

J. J. Zapalac, as appendix to Options "White Paper" on

Autonomy/Automation, Appendix D in SSDS Progress Report for the Month of

December 1984.

[2] SSDS Function Requirements Data Base, Appendix A-.9 to Task i - Function

Requirements Definition, DR-5, $SDS Analysis/Architecture Study, MDC

H1343, May I, 1985.

1-21
OF POOR QUALG'_

z ..m

C2 0

_J

r:

o

N .

w---_

c_ D--

z

N e_

u

_J

o

f

Z q"

I

J

==

N

=_

o

o

o

la.

1-2,?.
ORIGINAL _'

-,,_ _$

OF POOR QUALITY

>>:>> >>> _>>T._ . _ ,_ " " -- - -

° .

o

m

g

o

o

?,

1-23
oo . _! _'° : " : °

M

..J

Z

0

Z

I.i.

U3

t_1

I 0 I I

:u.,. q . . • . . o., . • . • . . . .

._ ..- _ _, _., _, o, c,..,., _,, _ _ ...... P') I"11"_ P') I") : ................ _- qP _" _" qr _P ql- ._ t/3 till t,'3 tl3 11/3 i_J " -Q......,0 -4_ .0 ..0

_., _ ql - - • - • - ._ :l • • . . • o . . 4._ - • • - • . i.. • • . . . - k. • • • - - - ._ - • - . .

_P

_1 i.') qP I1_ -0

• •

• . °

0

¢J

0

1-24
. o

ORIGINAL =_'_

OF POOR OUALITY

Z

• • o

.91.

0

0

0

_2

1-25
qP

0

41

C.

(,.I

0

:3

v3

U,.

1-26
3=

I--

Z 3

C3 0

l-- G._

lr.

C_

r-i

..". =

z 1

*'3 Pi

N ,-!.

i--{.9

(.J

o. -

ORIGINAL

Oi . POOR QUALITY

o

e_ m

0 0 _0 _ 0

"J

q_ 0 rJ_ (D (D

0 _ O0 O0 (D

o

¢n_c.Drn(_r_cne,m e-J

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

o

Ill

r.

,Ii

m

1-27
Z3

E

0 ....................................... ! ......

_U _ N, N

o

en O

N

Z

hi. U 4g =lull 0

. ........ _ ........ _ "_,

a.

.

m

,11

1-28
SPACE SHUTTLE TO SPACE STATION SOFTWARE TRANSPORTABILITY TRADE STUDY

1 . 0 INTRODUC'TION

This trade study provides a rough first-cut estimate of (i) the current size

of the space shuttle software in the NASA Mission Support Directorate, (2) the

amount of this software which might be transported, either whole or in part,

to the Space Station Program and (3) the value of the transportable software.

i.i BACKGROUND

The space shuttle software (and systems) environment is depicted in Figure

l.l.l. There are two Flight Planning "systems" used to develop requirements

and to support the verification of project software. The production planning

system provides flight specific data to the control center, the spacecraft

system and the crew trainers. Through integrated simulations, the control

center, the trainer and the spacecraft system mutually perform a validation

function. These five systems are very well coordinated, but they are also

very independent. Although there is some compatible hardware among the

systems, there is a minimal amount of common software (in the planning

systems). Additionally, the software development techniques employed are

personalized for each system. The division responsible for the software is

indicated in each box in Figure 1.l.1.

I Control J

I Repr°gram Requirement/Verificati°n IIL Center GDSD _ Validation 1

tFlight-

|Specific

/Data .

[ Planning" I I P'anning-I Flight-Specific Data I

Analysis _ Production h Trainer

MPAD Reprogram or MPAD FSD

Modify Requirements/Verification

SDecific

Data

I Spacecraft I Validation

Reprogram Requirements/Verification _ Software _._

SSD

Figure 1.1.1. Space Shuttle Software Groups

2-1
Further characteristics of the five systems are provided in Figure 1.1.2.

column designated controls illustrates to some degree the personalized

development techniques used for each system.

The

The amount of software in the Directorate is summarized in Figure 1.1.3. Data

has not been gathered for the data bases and program products which

support the space shuttle and are the responsibility of the Directorate.

Program design language (PDL) and prologue comments are excluded from the

sizing data in the figure; thus, what is provided represents executable code.

This sizing data was obtained from each project at a level of detail as low as

IOO source lines of code (SLOC). In some cases, comments were estimated based

upon a simple count and then deleted at the summary level. The picture

presented by this data - a lot of software spread throughout the Directorate -

is correct even if some of the individual sizes are wrong by IO% or even 20%.

This data does not include the cumulative amount of all software that was

developed and later deleted or modified through scrubs; rather, it represents

the size of the software in the Directorate today. In the form presented, the

software has been summarized in categories which generally represent the

complexity (or degree of difficulty in the development process) of the

software. For example, operating system mods and system services are more

difficult to develop and maintain than are support and utility software.

Throughout this study, all size and productivity data have been adjusted to

reflect executable code only. Comparisons of the data presented here w:i.th

other published data should be aware of a possible difference because of this

convention,

1,2 ISSUES

The following issues are addressed in this trade study:

1.2.1 SOFTWARE COST MODEL

A model will be developed - based on space shuttle project experience -to

estimate the development, maintenance and 10 year life cycle cost (t.CC) of a

large software system, lhe model will be used to extrapolate an upper bound

2-2
u')

o

4_

o

.f...

(.1

c/')

e--

O

S.-

O

C..)

Q; O'_

r-- C _::

C _.- I--

,4- E

,-- O O

•_..- r,__ L,_

_ O O

i,l_- z

E

.,-- e- N

(_ °v-.. i..--

X _._ _

I.LIt-_ cXC

•,1_ 4-J c'-

"_ _ O

_.. _..

EEu_

O O,--

O..C=

%

O. I

_ (]L) _'-'*

e'- .4_ eel--

e-

°r,-

Im

e-I._e-

_--,._

(..)

_.. Q;

u,- Q; O_

OOQ;

(..) _-- ._

"_ e--

_¢_ .f-

_--- la.

t_

.I-_ Q.) eQ;.,-- e-

(._ _ _..-

O _,--

_...) r-_ _.

EE EE _U C:_

cO

4_

_" 0

_-- __

_.

I

(U u_ SE

O O _

• ,,-- LI-

•1_ _'-

_._ :_

• r- _" 4-_

O X _J

c-"

O

O

•_-" O

°_.-

OO

c--

O

.,_

O

c- ,..-

_._- _.

_'_ I._ _--_

_..

O_

•,-- _,_ _

•¢_ O ,.C=

_:_ L_- _

c_

°f,,- _

e" X eO

_ 4.._ O

4-

O

O

c'- C__

O_/')

4-

C.)-_

_-

_-0

.r4_

°_

.¢Z

0

--s

S-

.f-.

U2-3
%

O

I--

-)c

C=.)

O

...I

V')

E

S.-

4J

u,-

O

c.c)

C_

O

E

-'-_E E

_,_I-- f--l---fQ O

_..- Q_ --_ _.} _

I I I I

_.._ Q..

S.-

_J

p-.

O

c-'

O

t',OI'-,

e,

,-..4

O

°P=.

u') U

>_-,,

,--'13

¢0 0

C S.-

c'-

"F:

CO

0_

Q

03

"{3

0

u') O

or) (_.

..m

c-' E

O "'" O _:D

c0_

I--

O

CO

t.C)

OOO_O

(,¢')

_._

•_ u'} .T,,.

c-- O

I..-O '_'" u')

(_.}.,'--O u') u')

_,I_-I-_.,-- (...)

E O rI_ -I-.)O

•,--_ .,.- f,..

u') (_.-E .,-" (_

I I I I I

I-- "

_.J _L.

l.L. C.C)

4--

I"4

°r-"

4...

"O O

(_ (.,r}

"O

,-5 ,--

X _

em _

0 c_

(.J

0 S..

,__ --_

0 0

_..

c-- 0

fO ,'_

.--I ,--i

c'_

_L.

_..

I "_

C_} .r'-

"_ L.L.

(.=.

._

r-'-

.f,..

O

4--

O

C.f)

c"

c_

O

I--

"I<

2"4
for the cost incurred by not transporting software between the space shuttle

and space station projects.

1.2.2 VALUE OF CURRENT SHUTTLE SOFTWARE

For cost comparisons, a reference value in manyears (MY) of work will be

established for the current space shuttle software system.

1.2.3 SIZE OF "TRANSPORTABLE CODE

An estimate will be made of the size - in thousands of source lines of code

(KSLOC) - of the software developed for the space shuttle which might be

transported, either whole or in part, to the Space Station Program (SSP).

1.2.4 VALUE OF TRANSPORTABLE CODE

The software cost model will be used to estimate the value (again, in manyears

of work) of the potentially transportable code.

1.3 TRADE STUDY CRITERIA

The following criteria are used to evaluate the options for each of the trade

study issues.

1.3.1 GENERIC CRITERIA

Five generic criteria are common to all trade studies:

i. 3. I. i COST

DEVELOPMENT (NON-RECURRING): This is the cost to select, transfer, build and

test the first working system.

MAINTENANCE (RECURRING): This is the cost to maintain the working system,

upgrade the software to satisfy evolving requirements, train new programmers

and provide user assistance.

2-5
LIFE CYCLE (NON-RECURRING AND RECURRING): This is the sum of the development

and maintenance costs over a i0 year period.

1.3.1.2 RISK

DEVELOPMENT (LANGUAGE INSERTION, DESIGN DIFFICULTY): There is some

uncertainty about the ease with which software modules and portions of modules

coded in many different languages can be embedded into an ADA (or some other

language) environment. The ADA-to-transported module interface may present

unique design problems.

MAINTENANCE (RECONFIGURATION, COST/SCHEDULE, SKILL LEVELS): Multi-language

systems are always more difficult to maintain than single-language systems.

Reconfiguration and upgrades to satisfy new requirements are always slower

(costlier) and incur more risk when a system is coded in more than one

language. Programmers who must work in several languages are seldom as

proficient in any of the languages as programmers who use one language

exclusively. Programmer training is also more expensive.

1.3.1.3 PERFORMANCE

SYSTEM SPEED: This is a measure of the speed at which a software system

performs the task assigned to it. If the interfaces between languages in a

multi.-language system are not clean, then processing speed will suffer.

SYSTEM SIZE: This is a measure of the core memory consumption of a system.

Multi-language systems require language interfaces which make them somewhat

larger than single-language systems.

1.3.1.4 STANDARDIZATION/COMMONALITY

Standard design and programming practices ensure consistent system response.

Sections of transported code which do not meet Space Station Project standards

will have to be modified to satisfy the standards.

2-6
I. 3.1.5 GROWTH/TECHNOLOGY INSERTION

All software systems evolve over time as new requirements surface and new

technology and algorithms becomeavailable. In a multi-language system, it

may prove difficult to insert new technology into modules coded in some of the

languages.

1.3.2 TRADE STUDY UNIQUE CRITERIA

To be a candidate for transfer, a space shuttle software function must

correspond to a similar Space Station Project function proposed in Section 6.0

(Onboard SSDS Definition), 7.0 (Ground SSDS Definition) or B.O (System

Development Concepts) of Reference 3. Each transferred function must be

capable of being embedded in a new host dedicated to space station processing.

1.4 APPLICABLE OPTION PAPERS

Several Task 2 option papers are applicable to this trade study. ]he total

list is:

-i 4.1

-I 4.2

-2 2.2

-2 2.5.1

-2 5.1

-2 5.2

-3 1

-3 2

-3 5.2

Advanced Algorithums

High Order Language

Autonomy/Automation

Payload/SSDS Interface Options

Space Communications

Wide Area Communications

Standardization/Commonality Options

System Management

Software Development

The prime option paper among these is 2.5.2, Wide Area Networks. The others

are of lesser interest.

2-7
1.5 ALTERNATIVES

This trade study assumes that ali space shuttle software transported to the

Space Station Project will be embedded in one or more software systems

dedicated entirely to space station processing. No other options are

considered. Under this constraint, three software re-location alternatives

are available:

1.5.1 RE-CODE ALL TRANSPORTABLE SOFI'WARE

With this alternative, all transportable software would be re-coded in a

single (project) language - probably ADA, This alternative would be taken if

no significant cost advantage could be obtained by transporting software for

any of the five software systems in Figure 1.1.1.

1.5.2 RE-CODE SOME TRANSPORTABLE SOFTWARE

For this option to be chosen, a cost advantage must be available for

transporting software for at least one (but not a11) of the five shuttle

software systems. The remaining transportable software would be re-coded in

the project language.

1.5.3 TRANSPORT ALL TRANSPORTABLE SOFTWARE

This alternative would be taken if a significant cost advantage could be

obtained by transporting software for each of the five shuttle software

systems.

2.O METHODOLOGY

The numbers cited in this study for the amount of transportable code are rough

engineering estimates. Data for the current sizes of the Control Center,

Flight planning, Trainer and Spacecraft Software systems is taken from

Reference 1. Software cost models are taken from Reference 2. The Space

Station project software environment is assumed to be the one proposed in

2-B
Sections 6.0 (Onboard SSOS Definition), 7.0 (Ground SSDS Definition) and 8.0

(System Development Concepts) in Reference 3.

The following example illustrates the process used for obtaining estimates of

the transportable SPF simulator software. It is fairly typical of the

first-cut estimation processes used for all of the software subsystems.

Initially, two assumptions are made about the space station simulator

environment:

i , The current SPF simulator languages (primarily HLAL, PL/I and

Fortran) can be maintained in the SSE.

2 , PLII, Fortran and HLAL generated object code can be embedded within

the primary SSE language environment (Ada).

The following multiplication factors are applied to the current SLOC count for

each SPF simulator function transferred to the SSE:

Environment Models 1.0

Hardware Models 0.8

Control/Initialization Programs 0.7

Monitor Programs o.g

Math Utility Programs l.O

The simulator functions assumed to be re-locatable (along with SLOC counts o?

the transported code) are summarized below. Partial lists of SPF modules

containing re-locatable code are included as some of the functions.

Control/Initialization (Transported Code: 2361 $LOC)

- Provide phased execution of the models within the math model task.

- Math model initialization.

- Onorbit step-ahead

- SMDLEORB

2-9 "
Math Utilities (Transported Code: 630 SLOC)

- Matrix utilities.

- Random number generator,

Monitor (Transported Code: 3300 SLOC)

- Log model data.

- Compute orbital elements for multiple vehicles.

- SMDLERIO

Equations of Motion (Transported Code: 3430 SLOC)

- High rate Taylor series predictor/corrector for vehicle state.

- Low rate precision integrator (Pines' Method).

- Gravity model (J22 + precision).

- Sun, Moon, gravity gradient torque influences.

- SMDLEEOM, SMDLEPRE, SMDLEPLE, SMDLEGRA, SMDLEGGT

Mass Properties (Transported Code: 4122 SLOC)

- Mass, center of gravity, inertia computation for

multiple elements.

- RCS moment arms.

- RMS/payload effects.

- SMDLEMS1, SMDEMS2

Target State Vectors (Transported Code: 442 SLOC)

- Provide equations of motion translational states for up to

five free-flyers.

- SMDLETGT

RMS (Transported Code: B850 SLOC)

- Provide rigid and flex arm dynamics.

.- SMDLSRMS, SMDLSDRS

RCS (Transported Code: 2645 SLOC)

- Force/moment due to RCS firings.

- Jet/vehicle impingement interaction,

- SMDLGRCl, SMDLGRC2

2-10
Star Tracker (Transported Code: 1OO5 SLOC)

- Shuttle star tracker hardware.

- Earth occultation/sun effects.

- SMLDGSTU

Simulation Macros (Transported Code: 50,0OO SLOC)

Simulation Control (Transported Code: 60,000 SLOC)

The amount of SPF simulator software estimated at first cut to be

transportable to the SSE is 136,785 SLOC (see Figure 3.3.1).

3.0 RESULTS

3.1 SOFTWARE COST MODEL

Sections 3.1.1 through 3.2.4 define a model (taken from Reference 2) for

estimating software development, maintenance and life cycle costs for the

space shuttle and space station programs. The model is used in Sections 3.2

and 3.4 to estimate the value of the current space shuttle software system and

the value of the shuttle software which may be transported to the Space

Station Program.

3.1.1 SPACE SHUffLE PRODUCTIVITY EXPERIENCE

Data for the productivity experienced on the shuttle project (Figure 3.1.1.1)

was gathered from the Directorate Divisions, Branches and contractors and

normalized for a work month of 20 days. Where possible (SPF, flight software

and MOC), the data was also adjusted to include all cost elements of the

project (system analysis, quality assurance, project management, etc.). There

was a general lack of data for the productivity experienced with the trainer -.

the 120 St.OC/MM composite was estimated by the FSD Office. This data

inherently represents the cost of developing software in the peculiar

environment of each system -the state of the requirements, the amount of

verification, the skills of the work force, etc.

2-11
Software System SLOC/MM

MOC Operating System Mods 160

Applications IgO

Support 250

Flight Planning Executive 240

Applications 200

Analysis 240

Trainer Operating Systems Mods 120?

Applications 120?

Offline Support 120?

Utilities 120?

IPC Operating System Mods ?

Real Time 198

Support 214

SPF Simulation 16g

Preprocessors 27B

Flight Software HAL 78

Assembler 51

Figure 3.1.i.I: Space Shuttle Productivity Experience

3.1.2 DEVELOPMENT COST MODEL

lhe development cost model partitions the software into categories based upon

complexity, amount of testing employed, status of requirements, etc. Size

(KSLOC) and productivity (KSLOC/MM) estimates are developed for each category,

and then the total development cost is obtained by adding the separate costs:

SIZE I SIZE 2

COST= ............................ +

PRODUCI"IVITY 1 PRODUCTIVIFY2

_- , , °

2-12
The productivities selected for the model are shown in Figure 3.1.2.1. For

the control center, MOC and TPC productivities are assumed to be the same (the

bulk of the software resides in the MOC and the data in the figure is obtained

from MOC experience). The production planning productivity is decreased to

account For common support functions which are not included in the shuttle

productivity experience. The productivities chosen For the trainer reflect a

comparison of trainer software with spacecraft software with a consideration

of less definition in requirements. The productivities For the spacecraft

software are rounded-off values of the shuttle experience.

3.1.3 MAINTENANCE COST MODEl_

The maintenance cost model (Figure 3.1.3.1) assumes that software maintenance

costs represent between 1OO% and 150% of development costs - equivalent to

between 50% and 60% of the total 10 year life cycle cost. To determine the

number of programmers required to maintain the software, an estimate is made

for the number of source lines of code that one programmer can maintain in

each software subsystem. These estimates are chosen (based upon shuttle

experience) to provide a conservative (low) count for the required number of

programmers to ensure that only valid conclusions are developed from the

results.

3.1.4 LIFE CYCI_E COST MODEl_

]-he 10 year life cycle cost (LCC) model simply assumes that the life cycle

cost is equal to the sum of the development and maintenance costs for each

software subsystem:

LIFE CYCLE COST = DEVELOPMENT COST + MAINTENANCE COST

n n n

The total life cycle cost for the project is equal to the sum of the separate

life cycle costs:

TOTAL LIFE CYCLE COST = LIFE CYCLE COSl"

1

+ LIFE CYCLE COST 2 + ...

2-13
A

CJ

O

°f-

°p-

(J

"x

O

13-

E

4-J

St0

O

(./)

_0_0_0

"0

0

E

bo O O

c_ I I I I

S- ¢..)

SO

O

cO

OQ

,_-00

O

°t--

r---'O

_- SctO

OO_O

0") u') 00 O

O3

"O

O

E

qJ ._

0

_- E qJ

°r.- -r.-. _._ °_..-

(I,I rO _._- .,-

z3.. (lJ '_- -_

O_OOQ

_._._

|||1|

_J

e_

O

O

_J

oo

q,;

SO_

LI2-14
,-- K.

qJ

U 0

_C..)

e-- j

0-_

¢.) _n

0

(Uc__

U

e-C_

C 0

or--

E

4-)

fO

3

4-)

0

000000

0

E

•I_ E E

--- 4._ -r- 4-_

0 0

I ! I !

_- ¢_)

(..)

S.-

0

O0

OuO

cO

°_

_n _J

>_-_

,.--'0

_0 0

0"_

0000

_00

"0

0

0

>_ _.

O0 _.

_ (lJ U9 u_

cO or- .r--

_J _0 W-- ",-

i.

qJ

eK-

}--

_0000

_000

b0

(D

tJ u_

•r- _ K.

> c-" 0

K- 0 e" tn

(lJ-," 0 _n _n

I/')4-_',- (I_ (lJ

rO 4m .,- tJ

_ _J _0-_ 0

_n _._-,- (D

I I I I I

;.- ,,

.-3 _-

U. bO

4-J

4-

L

tJ

qJ

_J

bO

qJ

L

"0

(J

S..

0

in

qJ

4m

in

>_

b')

0%

_J _0

,-- KCD.

_- 0

0

-_ _0

_nx3

,-- _0

_0

0 q)

0 _n

z<

CD

0

_J

_J

e"

e"

4m

e0_-.

rO

,o

_J

S.-

O_

o_-

U2-15
3.2 VALUE OF CURRENT SHUTTLE SOFTWARE

Using the software cost model developed in Sections 3.1 - 3.1.4, the total

value of the current space shuttle project software is estimated to be 10,/87

manyears (Figure 3.2.1). The development cost accounts for 4,750 manyears of

the total.

3,3 SIZE OF TRANSPORTABLE CODE

Estimates of the amount of software which can be transported, either whole or

in part, from the space shuttle to the space station project are given in

Figure 3.3.1. The granularity of the numbers in the figure is 1KSLOC; if the

total amount of transportable code in a software subsystem rounds off to less

than 1KSLOC, then it is considered to be too low for comparison and will not

show up in the figure.

Additionally, it has been assumed that the onboard flight software (both

system services and applications) will be re-coded entirely in a new (non-HAL)

language. None of it is therefore considered to be transportable.

Finally, no data was collected for the Flight Planning and Trainer systems.

Thus, the total amount o? re-locatable software is probably larger than the

1,520 KSLOC shown in the Figure.

3.4 VALUE OF TRANSPORTABLE CODE

Again, using the software cost model developed in Sections 3.1 - 3.1.4, the i0

year life cycle cost of the transportable Control Center and Spacecraft (SPF)

code is estimated to be 1,537 manyears (Figure 3.4.1). the relocatable

Control Center software accounts for 1,337 manyears; the SPF software, for the

remaining 200 manyears. No figures are currently available for the Flight

Planning and Trainer systems. The development cost of the transportable

Control Center and Spacecraft code is estimated to be 643 manyears.

2-16
A

Q>-

.-J

4J0

._--

c"

"V_ 0

.:_

Q;

E

_J

QJ

S.- 0

c_

_ CO o_0

c_ O0 _,0 ur_ cO o

°r..

u_ _J

>_ --_

,---

f,- c_0

4-_ c:_ _L.

CO.}

II 4J

_r__ C_

_ C:: f.- f,..

0••_

CO

CO0

kO 0

r'-, %0

pQ;

N-O

Q;

.i_

.-_

<2.)

I_.

_.-

.._ 0

_J

.._ %

°°

_d

.p2-17
u';

r-.-

O

I'-

(.J

O

.-I

bO

x/

E

qJ

4=)

qJ

rO

9-

O

be)

O0

Od

O0

b0

O

=E

E

(lJ _P

E E

(/I o,- 4-.).,=-4-_

0 0

r-- e_e-- e_

! I I I

0

0

cO

_--'0

0

c"

ee_

0

4-_ c_

O

(.F) _U

O'_ _ (J') {/I

_-- E aJ

(I) _0 9-- -e-

_=

cI--"

O,J

OO_O

(/I

L) _/I

•_=- i/I _.=

C O

S.- O c" Ul

0J','- O Ul _

bO-l_.P (I_ 0J

¢O 4_ .p U

E U rO-_-J O

-I_ -'_,-- {3.

I I I I I

I'-- U.=

.--I 0,.

4--

_3

_0

_u

_0

O

C_

m

i==.=

-I_ 0

0

4=)

:_ 0

0

_ "_

e_ pe.-

_j co • e--

_.. e- c-

_ -'_ .r--

,'-- 0

_ m

p.- r"_ h --

N

14-

0

r_

ro

o

(...

ro

0J

im-

(-.

bo

_J

co

be)

o_

co

£=

u2-18
>..

Q>-

C.J

C.J

.--J O

._"

or--

r0

4-)

u') O

._-

_J

E

_J

o'3

QJ

cO

4-O

O 03 O

_J

,... -_

S.. _OO

qJI!

(__O .,- .,-

_. t-- c-- c--

4-_ c-- c--- ._...

S..

_J

_J

rO

bO

03

O3

03

kO %O

O

._

cO

._. O

b0C

nO

"3

I-'-

e--

e-

°'_

_ e'-

r'_reU

--_ e'-

or-.-

r.-- 4-_

e- e-

•tc .tc

.to

ScO

4-J

S-O

(./I

r0

l--

_J

r-..

4_

r-

_J

O0O

(lJ

,°

,g

or...

2"19
4.0 CONCLUSIONS/RECOMMENDATIONS

4.1 CONCLUSIONS

The space shuttle software environment is composed of the five systems shown

in Figure 1.1.1. The current aggregate size of the systems is 9,426 KSLOC,

representing a i0 year life cycle cost of I0,7B7 MY and a development cost of

4,750 MY.

For two of the five systems (specifically, the Control Center and Spacecraft

systems), the amount of space shuttle software which might be transported to

the Space Station Project is estimated to be 1,520 KSLOC, representing a

development cost of 643 MY. No estimates have been made for the transportable

software in the other three systems.

The 643 MY figure for the Control Center and Spacecraft systems should not be

regarded as the amount of effort which would be saved by transporting software

from these systems. Background language interface and multiple language

maintenance costs must be subtracted from the figure to obtain the true

savings. If these costs are estimated to be 20 percent of the development

cost (equivalent to 129 MY), then 514 MY of effort will be saved by

transporting code.

4.2 RECOMMENDATIONS

The preliminary recommendation is to transport space shuttle software to the

Space Station Project. The recommendation is based upon first-cut analyses of

both economic and technical issues (refer to Sections 4.2.1 and 4.2.2)

associated with the problem.

4.2.1 ECONOMIC ISSUES

The following tasks were performed to determine the economic feasibility of

transporting space shuttle software to the Space Station Project:

2-20
i • The total amount of space shuttle software in the NASA Mission

Support Directorate was estimated and divided into logically separate

groups. This task was initially accomplished in Reference 1 and was

presented here again.

2, Based on the space shuttle experience, a model was developed for

estimating the cost (in manyears of effort) of large manned

spaceflight software systems. The model was able to differentiate

between development (short term), maintenance (long term) and life

cycle (total) costs. This task was accomplished in Reference 2 and

was also presented here again.

, The Space Station Project software environment was predicted. This

was done in ReFerence 3.

4, With the data from the previous task, the amount of space shuttle

software which could be transported to the Space Station Project was

estimated for two of the five software groups defined in Section 1.1

(the Control Center and Spacecraft software).

. Using the software cost model, the value of the transportable

software was determined for the Control Center and Spacecraft groups.

. The size of the interface software required to embed the transported

software into a background project language was estimated,

7. Using the software cost model, the cost of the interface software was

determined.

2-21
B o The minimum cost advantage (in manyears of effort) required to

justify transporting space shuttle software was arbitrarily

established as one manyear - that is, if one manyear of effort could

be shown to b.e saved by transporting software, then the decision

would be made to transport it.

g° The interface software cost (obtained in step 7) was subtracted from

the transportable software value (obtained in step 5). The result

was larger than the minimum required cost advantage (determined in

step B), and it was therefore determined to be economically feasible

to transport the software.

I0. If the result o? the subtraction performed in step g had been

uncomfortably close to the minimum required cost advantage (step 8),

then at least one more iteration would have been preformed on steps l

through g. In particular, an enhancement in knowledge of the

predicted software environment (step 3) might greatly improve the

estimate of transportable code made in step 4.

Each of the tasks listed above was performed on a software group basis (refer

to Figure l.l.l). Separate decisions on transportability were made For each

group.

4,2.2 TECHNICAL ISSUES

The following tasks were performed to determine the technical feasibility of

transporting space shuttle software to the Space Station Project:

I • The ADA-to-transported module interface was investigated at a

first-cut level. No major design problems were identified.

2 , System speed and size penalties for transported software were

assessed (refer to Section 1,3,1.9). The software transported into

the shuttle project SPF simulator was used as a yardstick.

2-22
In addition, the following technical issues should be considered as the Space

Station Project requirements evolve:

I • The host computer hardware environment should be investigated. Any

changes to the transported code (I/O, etc.) driven by the host

hardware should be factored into the economic feasibility study in

Section 4.2.1.

, An estimate of the new technology likely to be inserted into the

Space Station Project should be made. Any transported modules coded

in languages which cannot support the new technology should be

identified and candidate work-arounds should be proposed and

evaluated.
5.0 REFERENCES

1. Kidd, R. H., "Space Shuttle Software Commonality," IBMFSD, 1984.

2. Bunde, M,, et al, "SpaceStation Operations ManagementTask Overview," IBM

FSD, 1984.

, "Space Station Data System Analysis/Architecture Study, Task 4 - System

Definition Report," McDonnell Douglas Astronautics Company, MDC H1942, May

1985.

2-24
SYSTEMNE'T_K)RKTOPOLOGYTRADESTUDY

I.O TRADESTUDYDEFINITION

1.1 BACKGROUND ANDREQUIREMENTS

The objective of the network topology trade study is to identify the nodes and

links which will comprise the network. A large numberof requirements drive

this definition. Every function identified in Task i of the SSDS study must

be allocated to a system node. Any communications between functions allocated

to different nodes must be serviced by system links. In addition, mission

requirements have been derived from the Langley data base. The key

requirements provided here are peak data rates, average data rates and

allowable delays. In cases where allowable delays are zero, links may be

sized to meet the peaks. Otherwise, links may be sized to meet the averages.

1.2 ISSUES "TO BE ADDRESSED

This trade study focuses on two issues. The first is the basic network

configuration. The identification of the nodes, links, and traffic is

determined. The second issue is the optimum architecture to manage payload

data. The analysis of the payload data management is divided into a

preliminary analysis and a detailed analysis. ]he preliminary analysis is

described in Section 2 of this trade study report. The detailed cost

analysis is described in Section 3. Section 4 provides a description of

other issues involved and provides the recommended topology.

1.3 CRITERIA

rhe primary criteria used to compare alternative architectures is cost. For

the preliminary analysis, a normalized annual cost is derived. For the

detailed analysis, the cost is divided into fixed costs and recurring costs.

A number of other criteria were also used to select a topology, As a result

of the detailed cost analysis, it was determined that the cost differentials
between the topologies were significant, but not overwhelming. The other

criteria, and how they apply to the topology options, are described in

Section 4. These include growth potential, risk, and overall considerations

of the entire Space Station system.

1,4 APPLICABLE OPTIONS

The following options white papers were used to provide information for this

study:

Space Communications (2.5.1)

Wide Area Communications (2.5.2)

Mass Storage (1,1)

Standards (3.1)

1.5 ALTERNATIVE CONFIGURATIONS

For the preliminary analysis, three topologies were considered (see Section

2.5). These were:

i)

2)

3)

Centralized Processing at White Sands

Centralized Processing at Goddard

Distributed Processing

Of these three, the second option was discarded due to extremely high

communications cost. For the detailed analysis, a new option was considered

which was a combination of the two. This "hybrid" option, provides for

distributed processing of high rate data and centralized processing of low

rate data. The three options studied in detail are described in Section 3.2.

2.0 PRELIMINARY ANALYSIS

The objective of the Space Station Network Topology trade study is to

identify the nodes and links which will comprise the Space Station Network.

This will be determined by the system traffic requirements, and also some key

design decisions. Some of these design issues will be analyzed as part of

3-2
this trade study, while others will be discussed in terms of assumptions

which are made and the effects of these assumptions.

Sections 2.1 through 2.3 identify the network elements and the network

traffic. Section 2.1 describes the network nodes. These correspond to the

Space Station Program elements which were defined in Task i of the SSDS

study. Section 2.2 delineates all of the traffic which ?lows through the

Space Station Network. This is done on a logical node-to-node basis.

Section 2.3 discusses the characteristics of the links which will be

available to carry this traffic.

Assumptions as to which physical links carry which logical traffic for all

traffic are presented in Section 2.4. This table includes the results which

specify the payload data path. It is recognized that the transport and

processing of payload data will be a major topology driver. Options ?or the

routing and processing of payload data are presented in Section 2.5. The

system performance for each option is predicted using a computer simulation.

The model which has been developed for this purpose is discussed in Section

2.6. This model also takes into account the effects of l, 2, or 3 TDRSS

single access channels.

Section 2.7 discusses cost assumptions which were used in assessing the

various options. It is important to note here that the network nodes are

SSDS elements, while the network links are SSIS services. It is outside of

the scope of the SSDS study to analyze in detail the implementation of the

transportation service (DOMSAT vs. Fiber Optics). It is, however, necessary

to assign some type of cost to the communications service in order to

perform a meaningful trade (bandwidth vs. buffer). Thus, a simple measure of

communications cost will be derived and presented.

Given the simulation results and the cost assumptions system elements, each

option is costed and the results of the preliminary analysis are described in

Section 2.8.

3-3
2.1 SpaceStation Network Nodes

The nodes of the Space Station Network coincide with the Space Station

Program Elements as identified in task 1 report. In the case of elements for

which the multiplicity is to be determined, a strawman baseline has been

developed. Brief descriptions o? the nodes along with rationale for the

baseline are provided in this section.

2.1.1 The Space Station

The Space Station node services 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 ground, 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 quicklook data,

and delayed transmission of bulk commands and data. Real time operations of

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

links.

2.1.2 Polar Orbiting 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.

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 current mission model, it is assumed that there will be

two POPS at IOC, three at growth.

3-4
2.1,3 Co-<)rbiting Platform(s)

For the purpose of this study, it is assumed that the COP maintains

continuous line-of-sight with the space station. It is recognized that this

may not be true for certain mission scenarios. The use of a COP-SS link will

be assumed for both COP-ground and ground-COP traffic. The space station

network must support real time transmission of operations data and commands

for the COP and COP payloads as well as near real time transmission of

quicklook science data and delayed transmission of stored commands and data.

2.1.4 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-_round data distribution

network. It receives and buffers data, and routes virtual channels onto/from

the ground netowrk, and handles uplink logon and authorization checking. The

DHC is located at White Sands.

2.1.5 Space Station Operations Control Center (SSOCC)

The SSOCC is responsible for ground support of the Space Station Operations

and Control. The SSOC receives core data and passes it through to the

Engineering Data Center (EDC). It is also the origin of SS core commands.

2.1.6 POP Control Center (POPCC)

The POP Control Center is responsible for ground support of the platform

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

POP.

2.1.7 COP Control Center (COPCC)

The COP Control Center is responsible for the ground support of the platform

operations and control.

3-5
2.1.8 Payload Operations and 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 quicklook

analysis on science data. The POCC's will coordinate operations with the

related platform control center.

2.1.9 Level Zero Processing Facilities (LZPF)

The LZPF's are responsible for science data processing and short term (seven

day storage). The LZPF will support quicklook analysis at the POCC's.

Based on analysis of the Langley Data Base, six candidate locations have been

defined for LZPF's. These are:

LZPF 1 - Goddard Space Flight Center (GSFC)

LZPF 2 - Marshall Space Flight Center (MSFC)

LZPF 3 - Johnson Space Flight Center (JSC)

LZPF 4 - Jet Propulsion Laboratory (JPL)

LZPF 5 - Lewis Research Center (LERC)

I_ZPF 6 - Langley Research Center (LARC)

It should be noted that LZPF's will be used to support Regional Data Centers

(RDC's). These are SSIS elements which perform higher level payload data

processing.

2.1.10 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.

2.1.11 Customer Facilities

Commercial customers, as well as some others, will have their own facilities

for payload operation and control and data reception, archiving, and

_B
analysis. A customer facility maybe connected directly to the SpaceStation

Network, to a Regional Data Center or to a POCC. Whentied to the RDC,the

customer facility can utilize the support services available at the RDC.

2.1.12 GroundServices Center (GSC)

The GroundServices Center (GSC) provides communication and commonresource

coordination for the ground system. It serves to coordinate the scheduling of

the communication and ground facility resources shared among the Space

Station, COP, and POP operations control centers. The GSC also collects

status information from these facilities (outages, data quality monitoring,

etc.) and prepares reports of this information for both customers and the

OCCs.

2.2 The Traffic

The traffic model used for this study is composed of two parts. Section 2.2.1

describes the mission traffic model, which was derived using the Langley data

base. Section 2,2.2 describes the other traffic.

2.2.1 Mission Traffic Analysis

The mission traffic data base was initiated with a set of 74 missions.

Twenty of these missions contained incomplete or questional entries.

are listed in Figure 2.2-1.

These

Additionally, the following changes were incorporated in the data.

I. The downlink data rate for TDMX2542 was set to 10 Kbps.

2. The source for SAAX0220 was set to POP2.

3. The source for SAAXO225 was set to POP2.

The remaining payloads were analyzed for each of the years described in the

data base. Figure 2.2-2 illustrates the total of average downlink data rates

for the active payloads by years.

_7
PAGE NO. 00001

04/17/85

REPORT FOR DOWNLINK FREQ = 0 OR UL RATE = 25000 kbps

MISSION # SOURCE DOWNLINK DOWNLINK DOWNLINK UPLINK

DATA RATE FREQ/DAY DUR HRS DATA RATE

SAAX0202

SAAX0215

C0MM1304

SAAXO021

SAAX0115

SAAX0201

SAAX0302

SAAX0303

SAAX0307

SAAX0308

SAAX0502

TDMX2061

TDMX2072

TDMX2421

COMM1309

SAAX0116

SAAX0117

SAAX0304

SAAX0306

TDMX2064

PP1

PP1

SS

SS

SS

SS

SS

SS

SS

SS

SS

SS

SS

SS

SS

SS

SS

SS

SS

SS

0 O0

i0 O0

0 O0

100 O0

0 O0

0 O0

50 O0

30 O0

50 O0

1 O0

56.00

1000.00

0.00

20. O0

0.00

0.00

0.00

2.00

1.00

1000.00

0.00 0.00 0.00

0.00 24.00 0.01

0.00 0.00 0.00

0.00 24.00 1.00

0.00 0.00 0.00

0.00 0.00 0.00

0.00 0.00 2.00

0.00 12.00 30.00

0.00 24.00 2.00

0.00 0.00 0.00

0.00 0.00 56.00

1.00 0.10 25000.00

0.00 0.00 0.00

O.O0 O.O0 2.O0

0.00 0.00 0.00

0.00 0.00 0.00

0.00 0.00 0.00

0.00 24.00 0.10

0.00 24.00 0.10

1.00 0.10 25000.00

Excluded Missions

Figure 2.2-1

3-8
O_

n

O0

<C I_LI o_

O_

LJ<_

hi-- _-

_0

n

z0

i,I 0

<_

Or)

L.L.I (3

(_9 _z:_

r_ _o

o

C)

<_o ,,,

(/3

r_

bJ

<_- ,_

00

04000

Cq

oR|G_iAL p_G_. _,t';

OF pOOR QUALt'T'V I I I

0000

u'_0 u')0

I'_ 1'_ c,J c',J

I I I 0 0 0

0

I._0 U_

¢0

O_

O_

,¢...

p,..

O_

rY

ILl

co>--

O3

C7_

,¢.,...

":t"

<33

C_

O4

CT_

O,J!

O,J

o,;

°p..

LI..

Lf_

O0\

U1

Q_

3-0
The traffic was further analyzed for the years 1994 and 1997. Figures 2.2-3

and 2.2-4 show the mission sets as well as the assumed data destination for

1994 and 1997. Figures 2.2-5 and 2.2-6 provide detailed downlink traffic

characteristics for the two years by mission. Figures 2.2-7 and 2.2-B

provide point-to-point summaries of the average volumes. Figures 2.2-9 and

2.2-I0 show the command uplink summaries, based on the assumption that the

bulk of the commands originate at the RDC's. Figure 2.2-11 lists all of the

video requirements.

2.2.2 Other Data

Figure 2.2-12 contains a summary of the other space station system traffic.

The derivation of these numbers is provided here.

2.2.2.1 Space Station Core Engineering

It is assumed that core engineering data is generated at a rate of 256 Kbps

(2 w Shuttle). All of this data is assumed to go to the SSOCC. This data,

along with processed ancillary data, must then go to the engineering data

center. It is assumed that the processed ancillary data (definitive orbit,

attitude) will add 4 Kbps data to the traffic From the SSOCC to the EDC.

2.2.2.2 COP Core Engineering

It is assumed that COP core engineering data is generated at a rate of 64

Kbps (2_ space telescope). COP core engineering data also goes to the EDC.

2.2.2,3 POP Core Engineering

It is assumed that POP Core Engineering data is generated at a rate of 64

Kbps per POP. (2w Space Telescope.) POP Core Engineering data also goes to

and the EDC. Note that there are 2 POPS at "IOC", and three at "Growth."

2.2.2.4 Space Station Command Uplink

Space Station Commands go from the SSOCC to the Space Station. It is assumed

that real time commands and stored program commands combine to generate a 4

Kbps stream. This is consistent with current shuttle command rates.

_I0
PAGE NO. 00001

04/17/85

MISSION #

COMM1019

SAAX0208

SAAX0209

SAAX0210

SAAX0216

SAAX0228

SAAX0230

SAAX0238

SAAX0211

SAAX0213

SAAX0214

SAAX0219

SAAX0220

SAAX0229

SAAX0231

SAAX0232

SAAX0234

SAAX0235

SAAX0212

SAAXO005

COMM1014

COMM1202

SAAXO009

SAAX0207

TDMX2542

TDMX2441

COMM1206

TDMX2153

TDMX2311

COMM1201

C0MM1203

COMM1204

SAAX0401

SAAX0404

TDMX2011

TDMX2132

SPACE STATION SOURCE/RDC REPORT

MISSION NAME

Stereo Imaging Spectrometer

Mod. Res. Imaging Spectrometer

High Res. Imaging Spect. (HIRIS)

High Res. Multifreq. MW Radiomet.

Earth Radiation Budget Exp-ERBE

Thermal IR Mapping Spectrometer

Fabry Perot Interferometer

NADIR Climate Interfer./Spectrom.

Laser Atmospheric Sounder and Alt.

Altimeter

Scatterometer

Environmental Monitors

Automated Data Collect./Loc. System

Cryogenic Interfer/Spectrom.

VIS/UV Spectrometer

Microwave Limb Sounder

Interferometer/Spectr./Upper Atm.

Upper Atm. IR Radiometer

Synthetic Aperature Radar

Transition Radiation and Ion. Cal.

Remote Sensing Test, Dev. and Verif.

EOS Production Units

ASO I/POF

Solar-Terrestrial Observatory

Tethered Constellation

Guided Wave Optics Data Sys. Expt.

Biological Production Units

Solar Dynamic Power

Long-Term Cryogenic Fluid Storage

Microgravity and Materials Proc. Fac.

ECG Production Units

Microgravity and Materials Process Fac.

Microgravity and Mat. Proc. Fac. (MMPF)

Microgravityand Mat. Proc. Fac. (MMPF)

Spacecraft Materials and Coatings

Advanced Radiator Concepts

SOURCE

PPI

PP1

PP1

PP1

PP1

PP1

PP1

PP1

PP2

PP2

PP2

PP2

PP2

PP2

PP2

PP2

PP2

PP2

PP2

PP2

SS

SS

SS

SS

SS

SS

SS

SS

SS

SS

SS

SS

SS

SS

SS

SS

RDC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

JPL

MSFC

GSFC

GSFC

GSFC

GSFC

GSFC

JPL

JSC

LEWIS

LEWIS

MSFC

MSFC

MSFC

MSFC

MSFC

MSFC

MSFC

Mission Source Destination 1994

Figure 2.2-3

_ _ 3-11
PAGE NO. 00001

04/17/85

MISSION #

SAAXO004

COMM1019

SAAX0208

SAAX0209

SAAX0210

SAAX0216

SAAX0228

SAAX0230

SAAX0238

SAAX0211

SAAX0213

SAAX0214

SAAX0219

SAAX0220

SAAX0225

SAAX0229

SAAX0231

SAAX0232

SAAX0234

SAAX0235

SAAX0212

SAAXO005

SAAX0233

SAAX0236

SAAX0237

COMM1014

COMM1202

SAAXO011

TDMX2261

COMM1206

SAAXO227

COMM1201

COMM1203

COMM1204

SAAX0401

SAAX0404

TDMX2011

C0MM1208

SPACE STATION SOURCE/RDC REPORT

MISSION NAME

SlRTF Platform Mission

Stereo Imaging Spectrometer

Mod. Res. Imaging Spectrometer

High Res. Imaging Spect. (HIRIS)

High Res. Multifreq. MW Radiomet.

Earth Radiation Budget Exp-ERBE

Thermal IR Mapping Spectrometer

Fabry Perot Interferometer

NADIR Climate Interfer./Spectrom.

Laser Atmospheric Sounder and Alt.

Altimeter

Scatterometer

Environmental Monitors

Automated Data Collect./Loc. System

Solar-Terres. Polar Platform Exp.

Cryogenic Interfer/Spectrom.

VIS/UV Spectrometer

Microwave Limb Sounder

Interferometer/Spectr./Upper Atm.

Upper Atm. IR Radiometer

Synthetic Aperature Radar

Transition Radiation and Ion. Cal.

Submillimeter Spectrometer

Doppler LIDAR

Differential Absorption LIDAR

Remote Sensing Test, Dev. and Verif.

EOS Production Units

ASO II/POF + SOT

Sensor Systems Technology

Biological Production Units

Contained Plasma Experiment

Microgravity and Materials Proc. Fac.

ECG Production Units

Microgravity and Materials Process Fac.

Microgravity and Mat. Proc. Fac. (MMPF)

Microgravity and Mat. Proc. Fac. (MMPF)

Spacecraft Materials and Coatings

Crystal Production Units

SOURCE

COP

PPI

PPI

PPI

PPI

PPI

PPI

PPI

PPI

PP2

PP2

PP2

PP2

PP2

PP2

PP2

PP2

PP2

PP2

PP2

PP2

PP2

PP3

PP3

PP3

SS

SS

SS

SS

SS

SS

SS

SS

SS

SS

SS

SS

SS

RDC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

JPL

MSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

JSC

LANG

MSFC

MSFC

MSFC

MSFC

MSFC

MSFC

MSFC

Mission Source Destination 1997

Figure 2.2-4

3-12
PAGE NO.

04/18/85

SOURCEPP1

PP1

PP1

PP1

PP1

PP1

PP1

PP1

PP2

PP2

PP2

PP2

PP2

PP2

PP2

PP2

PP2

PP2

PP2

PP2

SS

SS

SS

SS

*SS

SS

SS

SS

SS

SS

SS

SS

SS

SS

SS

SS

** TOTAL

00001

RDC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

JPL

MSFC

GSFC

GSFC

GSFC

GSFC

GSFC

JPL

JSC

LEWIS

LEWIS

MSFC

MSFC

MSFC

MSFC

MSFC

MSFC

MSFC

SPACE STATION POINT-TO-POINT DOWNLINK

MISSION # DOWNLINK DOWNLINK

DATA RATE FREQ/DAY

(kbps)

COMM1019

SAAX0208

SAAX0209

SAAX0210

SAAX0216

SAAX0228

SAAX0230

SAAX0238

SAAX0211

SAAX0213

SAAX0214

SAAX0219

SAAX0220

SAAX0229

SAAX0231

SAAX0232

SAAX0234

SAAX0235

SAAX0212

SAAXO005

COMM1014

COMM1202

SAAXO009

SAAX0207

TDMX2542

TDMX2441

COMM1206

TDMX2153

TDMX2311

COMM1201

COMM1203

COMM1204

SAAX0401

SAAX0404

TDMX2011

TDMX2132

200000.00

3000.00

160000.00

50.00

0.24

30000.00

5.00

30.00

40.00

10.00

10.00

2.50

20.00

10.00

2000.00

10.00

10.00

20.00

300000.00

100.00

300000 O0

5 O0

1400 O0

10000 O0

(lO) i0000 O0

20 O0

5 O0

10 O0

64.00

50 O0

2 O0

50 O0

50 O0

50 O0

2 O0

4.00

16.00

7.00

16.00

1.00

1.00

16.00

16.O0

1.00

16.O0

1.00

1.00

0.10

1.00

16.00

1.00

1.00

1.00

1.00

16.00

1.00

1.00

1.00

16.O0

4.00

8.00

1.00

4.00

1.00

1.00

4.00

1.00

4.00

1.00

1.00

1.00

1.00

DOWNLINK

DUR HRS

0.50

0.50

0.25

24.00

24.00

0.20

0.75

24.00

0.75

24.00

24.00

24.00

24.00

0.75

24.00

24.00

24.00

24.00

0.10

24.00

0.20

24.00

1.00

1.50

0.50

2.00

1.00

0.10

24.00

1.00

24.00

1.00

24.00

24.00

0.25

0.10

1017029.74

DOWNLINK AVG

RATE

66666.666660

437.499999

26666.666650

50.000000

0.240000

3999.999999

2.500000

30.000000

20.000000

10.000000

10.000000

0.250000

20.000000

5.000000

2000.000000

10.000000

10.000000

20.000000

19999.999980

100.000000

2499.999999

5.000000

933.333332

2500.000000

1666.666666

1.666666

0.833333

0.041666

64.000000

8.333333

2.000000

8.333333

50.000000

50.000000

0.020833

0.016666

127849.068500

Downlink Traffic 1994 by Mission

Figure 2.2-5

3-13
PAGE NO.

04/18/85

SOURCE

COP

PPI

PP1

PP1

PPI

PP1

PP1

PP1

PP1

PP2

PP2

PP2

PP2

PP2

PP2

PP2

PP2

PP2

PP2

PP2

PP2

PP2

PP3

PP3

PP3

SS

SS

SS

SS

SS

SS

SS

SS

SS

SS

SS

SS

SS

** TOTAL

00001

RDC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

JPL

MSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

GSFC

JSC

LANG

MSFC

MSFC

MSFC

MSFC

MSFC

MSFC

MSFC

SPACE STATION POINT-TO-POINT DOWNLINK

MISSION # DOWNLINK DOWNLINK

DATA RATE FREQ/DAY

(kbps)

SAAXO004 I000.00 1.00

COMMIOI9 200000.00 16.00

SAAX0208 3000.00 7.00

SAAX0209 160000.00 16.00

SAAX0210 50.00 1.00

SAAX0216 O.24 I.O0

SAAX0228 30000.00 16.00

SAAX0230 5.00 16.00

SAAX0238 30.00 1.00

SAAX0211 40.00 16.00

SAAX0213 10.O0 1.O0

SAAX0214 10.O0 1.O0

SAAX0219 2.50 O. 10

SAAX0220 20.00 1.00

SAAX0225 2000.00 4.00

SAAX0229 10.00 16.00

SAAX0231 2000.00 1.00

SAAX0232 10.00 1.00

SAAX0234 10.00 1.00

SAAX0235 20.00 1.00

SAAX0212 300000.00 16.00

SAAXO005 100.00 1.00

SAAX0233 3.00 1.00

SAAX0236 30.00 16.00

SAAX0237 10.00 16.00

COMM1014 300000.00 1.00

C0MM1202 5.00 1.00

SAAXO011 50000.00 16.00

TDMX2261 10.00 1.00

COMM1206 5.00 4.00

SAAX0227 50000.00 1.00

COMM1201 50.00 4.00

COMM1203 2.00 1.00

COMM1204 50.00 4.00

SAAX0401 50.00 1.00

SAAX0404 50.00 1.00

TDMX2011 2.00 1.00

C0MM1208 2.00 1.00

DOWNLINK

DUR HRS

24.00

0.50

0.50

0.25

24.00

24.00

0.20

0.75

24.00

0.75

24.00

24.00

24.00

24.00

4.00

0.75

24.00

24.00

24.00

24.00

0.10

24.00

24.00

0.75

0.75

0.20

24.00

1.00

4.00

1.00

8.00

1.00

24.00

1.00

24.00

24.00

0.25

24.00

1098586.74

DOWNLINK AVG

RATE

1000.000000

66666.666660

437.499999

26666.666650

50.000000

0.240000

3999.999999

2.500000

30.000000

20.000000

10.000000

10.000000

0.250000

20.000000

1333.333332

5.000000

2000.000000

10.000000

10.000000

20.000000

19999.999980

100.000000

3.000000

15.000000

5.000000

2499.999999

5.000000

33333.333300

1.666666

0.833333

16666.666660

8.333333

2.000000

8.333333

50.000000

50.000000

0.020833

2.000000

175043.343600

Downlink Traffic 1997 by Mission

Figure 2.2-6

3-14
GSFC MSFC JSC JPL LeRC LRC Total

SS

COP

POP 1

POP 2

POP 3

Total

7605

97854

2105

107564

119

100

219

2OOOO

2OOO2

64

64

7791

97854

22205

127850

Note: Units are kilobits per second

Figure 2.2-7. Downlink Point-to-Point Summary, 1994

GSFC MSFC JSC JPL LeRC LRC Total

SS

COP

POP 1

POP 2

POP 3

Total

35840

1000

97854

3439

23

138156

120

100

220

20OOO

2OO00

16667

16667

52628

1000

97854

23539

23

175044

Note: Units are kilobits per second.

Figure 2.2-8. Downlink Point-to-Point Summary, 1997

3-15
GSFC MSFC JSC JPL LeRC LRC Total

SS

COP

POP1

POP2

POP3

Total

80O

42

394

1236

2254

2262

167

167

21

23

3227

42

423

3692

Note:Unitsarebitspersecond

Figure2.2-9.UplinkPoint-to-Point Summary, 1994

GSFC MSFC JSC JPL LeRC LRC Total

SS

COP

POP 1

POP 2

POP 3

Total

733

667

42

1061

19

2522

275O

2758

167

167

21

21

333

333

3983

667

42

1090

19

5801

Note: Units are bits per second

Figure 2.2-10. Uplink Point-to-Point Summary, 1997

3-16
PAGE NO.

04/18/85

S/C

SS

SS

SS

SS

SS

SS

SS

SS

SS

00001

RDC

GSFC

GSFC

GSFC

JSC

LEWIS

MSFC

MSFC

MSFC

MSFC

SPACE STATION POINT-TO-POINT VIDEO 1994

MISSION # DOWNLINK D/L D/L UPLINK

VID RATE VID VID VID RATE

(kbps) FREQ DUR (kbps)

COMM1202 22000.00 1.00 0.50 0.00

SAAX0207 2.00 1.00 1.00 0.00

TDMX2542 12000.00 8.00 0.50 0.00

COMM1206 22000.00 2.00 1.00 0.00

TDMX2153 90.00 0.00 0.00 0.00

COMM1201 22000.00 2.00 1.00 22000.00

COMM1203 22000.00 0.10 0.10 0.00

COMM1204 22000.00 2.00 1.00 22000.00

TDMX2132 90.00 0.00 0.00 0.00

U/L

VID

FREQ

0.00

0.00

0.00

0.00

0.00

0.20

0.00

0.20

0.00

U/L

VID

DUR

O.O0

0.00

0.00

0.00

0.00

O. 50

0.00

O. 50

0.00

PAGE NO.

04/18/85

SIC

PP2

SS

SS

SS

SS

SS

SS

SS

00001

SPACE STATION POINT-TO-POINT VIDEO 1997

RDC MISSION # DOWNLINK D/L D/L

VID RATE VID VID

(kbps) FREQ DUR

GSFC SAAX0225 2.00 0.00 0.00

GSFC COMMI202 22000.00 1.00 0.50

JSC COMM1206 22000.00 2.00 1.00

LANG SAAX0227 2.00 1.00 8.00

MSFC COMMI201 22000.00 2.00 1.00

MSFC COMMI203 22000.00 0.I0 0.10

MSFC COMM1204 22000.00 2.00 1.00

MSFC COMM1208 22000.00 0.10 0.10

UPLINK

VID RATE

(kbps)

0.00

0.00

0,00

0.00

22000.00

0.00

22000.00

0.00

U/L

VID

FREQ

0.00

0.00

0.00

0.00

0.20

0.00

0.20

0.00

UIL

VID

DUR

0.00

0.00

0.00

0.00

O.50

0.00

O.50

0.00

Payload Video Requirements

Figure 2.2-11

3-17
TYPE FROM TO RATE

SS CORE SS SSOCC

SS ANCIL SS EDC

COP CORE COP COPCC

COP ANCIL COP EDC

POP1 CORE POP1 POPCC

POP1ANCIL POPI EDC

POP2 CORE POP2 POPCC

POP2 ANCIL POP2 EDC

SS CMD SSOCC SS

SS DATA UP SSOCC SS

COP CMD COPCC COP

COP DATA UP COPCC COP

POP1CMD POPCC POP1

POP2 CMD POPCC POP2

POP1 DATA UP POPCC POP1

POP2 DATA UP POPCC POP2

CORE HR VIDEO SS SSOCC

CORE LR VIDEO SS SSOCC

CORE AUDIO SS SSOCC

HR VIDEO SSOCC SS

LR VIDEO SSOCC SS

AUDIO SSOCC SS

SIM UP DSIT SS

SIM DOWN SS DSIT

ARCHIVE RETR EDC LZPFs

SCHEDULE COORD GSC ALL

256.00

260.00

64.00

64.00

64.00

64.00

64.00

64.00

4.00

256.00

4.00

64,00

4.00

4.00

64.00

64.00

22000.00

1544.00

64.00

22000 O0

1544 O0

64 O0

5 O0

1 O0

4 80

4000 O0

DUI'Y

CYCLE

I00.00

i00,00

I00,00

I00.00

I00.00

I00,00

I00.00

100,00

100.00

10.00

100.00

10 O0

100 O0

100 O0

10 O0

10 O0

100 O0

100 O0

100 O0

100 O0

100 O0

100 O0

5 O0

5 O0

50 0

100 O0

AVG RATE

256.00

260.00

64.00

64,00

64.00

64.00

64.00

64.00

4.00

25,60

4.00

6,40

4.00

4,00

6.40

6.40

22000,00

]544 O0

64 O0

22000 O0

1544 O0

64 O0

0 25

0 01

2 40

4000 O0

Figure 2.2-12. Other Space Station Traffic Data Base

3-18
2.2.2.5 Space Station Data Uplink

The data uplink contains text, graphics, and data base loads. Currently, the

shuttle 216 KbRs command format allows 128 Kbps for text and graphics. It is

assumed that this traffic category will produce 256 Kbps with a ten percent

duty cycle.

2.2.2.6 COP Command Uplink

COP commands go from the COPCC to the COP. It is assumed that real time

commands and stored program commands combine to generate a 4 Kbps stream.

2.2.2.7 COP Data Uplink

Due to the fact that the COP is unmanned, it is assumed that the COP data

uplink will be one-fourth of the Space Station Data Uplink.

2.2.2.8 POP Uplink Commands

POP commands go from the POPCC to the (each) POP. It is assumed that real

time commands and stored program commands combine to generate one 4 Kbps

stream (per). This is consistent with COP command assumptions.

2.2.2.9 POP Data Uplink

The data uplink assumptions for each POP are identical to the data uplink

assumptions for the COP.

2.2.2.10 Space Station Core Video Downlink

It is assumed that there will be one downlink channel dedicated to 22 Mbps

high resolution video and one dedicated downlink channel for 1.544 Mbps

resolution video. This traffic goes From the space station to the SSOCC.

This affects the network topology study because it utilizes IDRSS bandwidth

which is thus unavailable for other traffic.

3-19
2.2,2.11 Space Station Core Video Uplink

It is assumed that all high resolution video uplink will be required for

recreation, public relations, and training. This traffic is assumed to be 22

Mbps with a 5% duty cycle. It is also assumed that there will be one

dedicated 56 Kbps low resolution video channel from the SSOCC and the space

station. This affects the network topology study because it utilizes TDRSS

bandwidth which is thus unavailable For other traffic.

2.2.2.12 Audio Traffic

It is assumed that there will be two hi-directional dedicated 32 Kbps audio

channels between the SS and the SSOCC.

2.2.2.13 Core Archival Retrieval

It is assumed that each LZPF will generate enough requests for archived core

ancillary data to require 4.B Kbps of data with a 50% duty cycle.

2.2.2.14 Schedule Coordination

It is assumed that the GSC will require a continuous 4 Kbps stream to and from

each ground SSPE, and the Space Station.

2.3 ]'he Links

]he links in the space station network are SSIS services. The objective of

this study is to identify key performance requirements for these links.

Section 2.3.1 discusses the assumptions for the space to ground relay

service. Section 2.3.2 discusses the ground to ground links.

2.3.1 Space to Ground Links

It is assumed that the TDRS system will be the main space to ground relay

service. This system provides multiple access S band service, and single

access service which includes both K-band (KSA) and S-band (SSA).

3-20
It is assumed that Reed-Solomon encoding will be applied to the single access

downlinks, and that the effective bandwidth is reduced by I0%. It is also

assumed that each space node will have access to one S band multiple access

link. Figure 2.3-i shows the assumed FDRSS effective available uplink and

downlink bandwidths. Note that the encoding overhead is symmetric.

For purposes of this study, it is assumed that the Space Station will act as

an intermediate node for all COP traffic (if COP is in continual

line-of-sight). This decision was made because the low volume of COP traffic

in the mission set does not warrant the exclusive use of a TDRSS single access

channel.

Service

MA SSA KSA

Uplink

Downlink

10 kbps

50 kbps

270 kbps

2.7 Mb_

225 Mbps

270 Mbps

Note: Single-access channel includes Reed-Solomon encoding

Figure 2.3-1. TDRSS Effective Bandwidth

3-21
2.3.2 Ground-to-Ground Links

For purposes of this study, it is assumed that ground-to-ground links will be

available between any two points at any rate.

2.4 Traffic Assignment

]he traffic which was described in Section 2.2 must flow over the physical

links which were described in Section 2.3. This is done in two steps.

Assumptions are made ?or the assignment of the "other" traffic (Section

2.2.2). Given these assumptions, further analysis is performed For the

payload downlink traffic. Note that the topology used to support payload

uplink traffic is driven by command management philosophy, not traffic volume.

The traffic assignments for the traffic described in Section 2.2.2 are

provided in Figure 2.4-I. The key in performing this assignment is that the

end points of the combined physical links are the same as the end points of

the logical traffic requirement. For example, Space Station core engineering

data logically must go from the SS to the SSOCC. This is physically

implemented with two links; SS-DHC, DHC-SSOCC.

2.5 Topology Options

For purposes of this study, it is assumed that all payload outputs are in the

format of CCSDS packets. For the preliminary analysis, only high rate

payloads are considered. The function of the ground facilities is to

reconstruct the payload outputs and transport them to the customer; not

necessarily in that order.

Figures 2.5-i through 2.5-4 illustrate the four topology options for payload

data transportation and processing. The key difference between the options is

the location of the data set reconstruction, and the imposed communications

requirements. The key issue here is the definition of data set

reconstruction. In the mission data base, there is a field named "Duration."

It is assumed that a data set is the output of the payload For the specified

period of duration.

3-22
SS Core X I

COP Core X X

POP Core X

SS Cmd Up X l

SS Data Up X!

COP Cmd Up Xl X

COP Data Up X X

POP Cmd Up X

POP Data Up X

Archive Retrievals X

High-Rate Video Up X!

High-Rate Video Down X i

Low-Rate Video Up X

Low-Rate Video Down X X

Audio Up X

Audio Down X

SS Payload Data X

SS Payload Eng Down X i

SS Payload Cmd Up X

COP Payload Data X X

COP Payload Eng Down X i X

COP Payload Cmd Up X X

POP Payload Data X

POP Payload Eng Down X

POP Payload Cmd Up X

Schedule Coord X X

Figure 2.4.1. Traffic Link Assignments

X

X

X

X

xl

xl

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

XXXX

X X X X X X

Figure 2.5-5 shows a summary of the processing and communications requirements

for each option.

Option 1 provides for reconstruction of all data sets at White Sands. Once

the data sets are reconstructed, they are then transmitted to their final

destination.

Option 2 provides for the relay of all data from White Sands to Goddard Space

Flight Center. where the data sets are reconstructed and .transmitted to their

final destination, lhe advantage of this approach is that similar processing

and the associated expertise currently reside at (;oddard. The disadvantage is

that there is added communications cost for a WS- GSFC linl<. Most of the

increased expense here is the transport of fill data.

3-23
r

f !

Z

0

r,"

I""

ILl

I---

°r---

LL

3-24
f_

1tI \

../

t

/

zQ

IN

(.DZO

LIJ

p,,,

LLI

tJ')

I--"

I

_J

°r-.

I.J3-25
f_

! U') \

•

\

Z0

I---

:70

LLI

I'--

LU

c.f)

I---

c_

(v)I

_J

or.,-

I.I..

3-26
\

\

\

\

I

,_> /

3.27
Option 1 Option 2 Option 3

Processing

Communications

All at

White

Sands

Data Sets

WS-R DCS

All at

GSFC

All WS-GSFC

Data Sets

GSFC-RDCS

Distributed

at R DCS

Streams

WS-R DCS

Figure 2-5-5. Processing and Communications Implications

Option 3 provides for the transmission of packets from White Sands to Level

Zero Processing Facilities (LZPFs) and the reconstruction of data sets at the

LZPF. The disadvantage of this approach is that the hardware, spares, and

maintenance are distributed. There is also an increased configuration

management burden. The advantage is that communications and buffering costs

are minimized.

Option 4 presents physical links which have not yet been discussed; Space to

LZPF. The disadvantage of studying this option is that there is a large

degree of risk, as well as cost uncertainty. Also, the key cost issues are

clearly SSIS issues. This option is presented in order to mention that there

is a finite probability that data set reconstruction will necessarily be at

the LZPF's in the future.

The first three topology options have been simulated and costed. Section 2.6

presents the simulation model and assumptions. Section 2.7 presents the

assumptions used to derive system cost. Section 2.8 presents the preliminary

results.

3-28
2.6 Simulation Description

Figures 2.6-1 through 2.6-3 illustrate the three models which were used to

analyze the Space Station Network. These correspond to the three options

discussed in Section 2.5. Many key assumptions were made in developing the

simulation. These are not necessarily design decisions, they are assumptions

required in order to make a working model. It is important to understand what

these decisions are in order to evaluate their potential impact on the

simulation results and any trade study conclusions based on these results.

2.6,1 Data Set Reconstruction

Traffic is entered into the system as data sets. These sets are broken into

packets at the symbol labelled "deconstruct." These packets flow through the

network until they reach the symbol labelled "reconstruct," then the data set

flows through the rest of the system.

2.6.2 On Board Storage

Due to the high rates which are being buffered, it is assumed that there will

be optical disks on board. This means that the on board buffer will be

managed on a priority FIFO basis (tapes would be LIFO). As a result, payloads

with low delay requirements are given priority over payloads with less

stringent requirements,

3-29
m

0

• ii

m_

N ,--I_

ff) O.C_U.

0

n

_v_.

II o

II

"_L_

i,.

u'2. 0

II

_-_ ,, m

II

<r. ([_o r-

(J

u)

m

m

m

¢DO

.B

_L

3-30
I °

i II

N _.a ..I w

! (n O.. C,'_ u.

w..

I_ _

M

lq_- _-

i_ __

<_ -r- _ _-

ed

Z

3-31
II

3-32

"->8_

o_cO'J

.>0_

_,_

cp_ {/)

._>o_

l

_1

¢,1

_ee_ /

_1

.->_ "$.®$

t_6zZ

_b

eL
2.6,3 Ground Links

The bandwidths of the ground links is not varied in this study. For each

link, a high bandwidth is chosen which will result in small queues. The

bandwidths chosen are presented with the results.

2.6.4 Schedule Considerations

The good news for the SSDS is that payloads may be scheduled. The bad news is

that many of the high rate payloads perform land observation. Figure 2.6-4

shows the data rates and triggers that were used by the simulation program.

Rate

Mission From To (MIni) Trigger

Comm1014 SS GSFC 300 Land, P = 0.05

Saax0207 SS GSFC 10 Poisson

Comm1019 POP 1 GSFC 200 Sunlit Land

Saax0209 POP 1 GSFC 160 Sunlit Land

Saax022B POP 1 GSFC 30 Land, P = 0A6

Saax0212 POP 2 JPL 300 Land, P = 0.23

Figure 2._4. Simulation Traffic

2.6.5 TDRSS Single Access Channel Model

TDRSS Single Access Channels are modelled as a resource. For this purpose, it

is assumed that the Space Station has two, POP1 and POP2, and POP2 has 1. Fine

method of modelling one, two, or three channels is by having a TDRSS resource

grabber (a.g.a. zone of non-contact (ZONC)) seize these resources with a high

priority. Thus, to mode], a single access channel, the simulation is run with

5-n ZONCs. The ZONCs are sclneduled so that for each spacecraft, the ZONC is

at least as long as the maximum possible zone of exclusion.

3-33
2.7 Cost Assumptions

Each system configuration is assigned an associated cost. This is the

combined cost for processing, buffering, and communications. Costs are

measured on a normalized annual cost basis.

2.7.1 Processing Cost

According to a report by CSC (Advanced telemetry processing system feasibility

study), the required systems will be available at a cost of 10.8 million

dollars with a recurring cost of 465 thousand dollars. If the development

cost is spread over two years with a zero percent interest rate, the

normalized annual cost is $1.545 million-per-year per system. For topology

options one and two, there will be one such system per single access channel.

For option three, these systems, or smaller versions, will be judiciously

distributed to the RDC's.

2.7.2 Buffer Costs

The buffer costs are described in detail in the Mass Storage trade study. 7he

following costs are used here:

On board buffer

Ground buffer

$i0 per megabit

$.20 per megabit

2.7.3 Communications Cost

Communications costs are extremely difficult to predict. Fiber Optic Systems

appear to be the wave of the future, but costs are not quoted on a service

basis. Because the communications service is outside of the scope of the

SSDS, a very simple method has been derived to assign communications cost.

Based on technology trends (see Wide Area Network options) it is expected

that communications costs will be around ten dollars per megabit per mile per"

year. Although satellite costs are mileage independent, this approach should

result in a meaningful measure of cost.

3-34
Figure 2.7-1 shows the distances between the NASA centers. An example of the

cost calculation is provided. The distance between GSFC and WS is 1,728

miles. Thus, the cost of 300 Mbps service is I0 w3OOW 1728 = $5,104 per year.

GSFC MSFC JSC JPL LRC LeRC

GSFC

WS 1728

711

1120

1222

717

2289

670

139

1751

305

1513

Figure 2.7-1. Miles Between NASA Sites

2.8 Preliminary Results

Computer simulations were run for each of the topology options defined in 2.5

for one, two and three TDRSS single access channels. Appendix F of the SSDS

task 4 report provides details of the simulation runs. Appendix A of this

study provides simulation outputs and cost calculations. Figure 3.l-I

provides a summary o? the cost information.

Based on the results in Figure 3.1-i, Options 1 and 3 seems comparable. The

communications costs make Option 2 prohibitive. Also, the cost difference

between 2 or 3 TDRSS single access channels is small. If only one channel is

used, on board buffering will cost an additional five million dollars per

year.

3-35
SPRCE STRTION NETNORK TOPOLOGY

TRRDE STUDY

TOTRL COST ($K/YR)

OPTION TBRSS CO,_IUNICRTIONSPROCESSING

1437 I 3090

I

l

1437

1437

3090

4635

t

BUFFER TOTAL

I0986

5630

4937

15513

I0157

9464

2 2 4523 I! 3090 I0939 18552

2 ! 3090 5545 17180

2 z 4635 4847 22059

3 4635

2 8545

3 12577

l 1437 I

2 1437

3 1437

I0840 16912

t

3 ! 4635 5430 i I1502

3 i 6180 ' 4730 i 12347

Figure 3.1-1

3.o Detailed Analysis

The results of the preliminary analysis of this trade study arrived at two

basic conclusions. The first is that there should be two TDRSS single access

channels. The second is that level 0 processing should be either centralized

at White Sands or distributed to level zero processing centers (LZPFs) which

would be colocated with RDCs. The next step of this trade study is to

consider these options in greater detail. In addition to these two, a new

option was considered which is a hybrid of the centralized and distributed

options. For this "hybrid" option, the proceesing of the high rate payload

data is distributed to the points of higher processing (RDCs) and the

processing of the low rate data is centralized at Goddard. The detailed

analysis of these three new options entails modelling each option in terms of

cost elements and performing an economic analysis of the fixed and recurring

costs. The sensitivities of these costs with respect to technology advances

and requirements will then be analyzed. Section 3.1 provides a detailed

analysis of the Langley data base mission traffic for the growth scenario

3-36
(Igg7). This information is used to size the cost elements. Section 3.2

describes the models of each of the three options. Section 3.3 describes the

methodology which was used to assign costs to each of the model elements and

provides a cost summary. In assigning these costs, it was very important to

know whether or not the data is being rate smoothed. When rate smoothing is

applied, data that does not have a strict (O hour) delay requirement may be

buffered in order to reduce both bandwidth and processing requirements. On

the other hand, smoothing precludes quick-look (within seconds) analysis.

This study analyzed the system costs both with and without rate smoothing.

Section 3.4 describes the sensitivities of these costs to changes in mass

storage and communications cost assumptions. Section 4 discusses the non-cost

issues which were used to pick the Space Station ground network topology, and

presents this selection.

3.1 Detailed Traffic Rnalysis

Figure 3.1-ia presents a data base report which was used to size the cost

elements for the three options. These reports have two added columns which

were used in sizing link bandwidths and smoothing requirements. The column

labeled "required bandwidth" specifies the bandwidth requirement for the given

payload as derived from the peak rate, average rate, and delay requirement.

If the delay requirement is zero, then the required bandwidth is equal to the

peak bandwidth. If the delay requirement is not zero, then it is assumed that

the data can be smoothed, and therefore the required bandwidth is equal to the

average bandwidth. The other column which was used to size the system was

"Observation size". This is used to determine the size of the smoothing

buffer. This is calculated by multiplying the peak rate by the duration.

Figures 3.1-2 through 3.1-4 provide a point to point summary of the peak and

average data rates. Figure 3.1- 2 provides this data for a].l 1997 missions.

Figures 3.1-3 and 3.1-4 provide this data for high (IOMbps) and low rate

payloads respectively.

3-37
ORIGINAL P_ i,

OF POOR QUAL[TV

SPACESTATION TRAFFIC REPORTFOR YEAR 1907

FROM MISSION | 1997 RATE FREQ/DAY DUll (hrs)

OPER (n_ps)

DAYS

* TO GSF¢

COP SAAXDUO4 5 1.00000 1. O0 24.00

PP! C0J441019 365 200.00000 IS.00 0.50

PP! SAAX02ON 365 3.08000 7 • 00 0. SO

PP! SAAX0209 365 160. DUO00 15. O0 0.25

PPI SAAX0210 365 0.05080 1.00 24.00

PP! SAAX0216 365 0.00024 1.00 24.00

PPI SAAX0228 36S 30.ND000 15.00 0.20

PPI SAAXO235 365 O.DU500 15.00 0.75

PPI SAAX0238 355 0.03000 1.O0 24.00

PP2 SAAXO2U 365 0.04000 IS.O0 0.75

PP2 SAAXO213 365 0.01000 1.O0 24.00

PP2 SAAX0214 365 0.01000 1.00 24.00

PP2 SAAXO219 365 0.00258 0.10 24.00

PP2 SAAX0220 355 O.02000 1.00 24. OO

PP2 5AAX0225 365 2.00009 4.00 4. OO

PP2 SAAX0229 365 0.OIDUO 15.00 0.75

PP2 SAAX0231 365 2.00000 1.00 24.00

PP2 _18X0232 365 0.01000 1.00 24.00

PP2 588XO234 365 0.01000 i.00 24.00

PP2 SAAXO235 365 O.02000 I. 00 24. DO

PP3 SkAX0233 355 0.00300 1 . 00 24.00

PP3 SAAXO235 365 O.03000 15.00 0.75

PP3 SAAX0237 355 O.01080 1S. O0 0.75

SS C0lg41014 90 300.00000 1.00 0.20

SS CONM1202 365 0.00500 1.00 24.00

55 SAxXOOIi 365 50.00000 IS.00 !.00

S5 TONX2251 365 0.01000 1.00 4.00

** SUITOTNL **

748.27574 151.10 350.40

* TOJPL

PP2 SAAXQ212

** 508TOTAL **

365

DELAY AVG BAND- REQ RAND- OOSER-

(hrs) WIDTH WIDTH VATION

(Mbps) (Hbps) SIZE

(Gbytes)

24.00 I.ODUOO 1.OOO00 IO.8OOOO

24.00 62.50000 62.50000 45.00000

3.DU 0.43750 0.43750 0.67500

3.08 25.00000 25.00000 18.00000

3.00 0.05000 0.05000 0.54000

3. OO - 0.00024 O. 00024 O. 00259

3.00 3.75000 3.75000 2.70000

3. O0 0.00234 0.00234 O. 00158

3.00 0.03000 O. 03000 O. 32400

3.00 0.01875 0.01875 0.01350

3.00 0.01000 0.01000 " 0.10800

3.00 0.01000 0.01000 O. 10800

O.00 O.00025 O. 00250 0.02700

3.00 O.02080 O. 02000 O. 21600

0.08 1.33000 2.00000 3.60000

3.00 0.00468 0.00458 0.00337

3.00 2.00DUQ 2.0OO00 21.60000

3.00 0.01500 0.01000 O. 10800

3.00 0.01DUO 0.01000 0.10800

3.00 0.02000 0.0.2000 0.21600

• 3.00 0.00300 O. 00300 O. 03240

3.00 0.01406 0.01406 0.01012

3. O0 O.00458 O. 00458 O. 00337

24.00 2.50000 2.50000 27.ODUO0

24.00 O.00.500 O. 00500 0.05400

0.00 31.25000 50.00000 22.50000

0.00 0.00167 O.OIDUO 0.01800

153.00 129.98217 149.41275 153.76903

* TO ,FJC

SS CON41206

** SUOTOTAL**

355

300.00000 IS.00 0.10 6.00 18.75000 18.75000

300.00000 15.00 0.10 6.00 18.75000 18.75000

13.50000

13.50000

0.00500 4.00 1.00 24.00 O.00S00 0.00500 0.00226

0. DU500 4.00 1.00 24.DU 0.00580 0.00500 0.00225

Figure 3.1-1a. 1997 Data Base LiKing

SPACESTATION TRAFFIC REPORTFOR YEAR 1997

_qoN HISSION I 1997

(}PER

DAYS

"* TO LANG

SS SAAXOZ27 365

** SUBTOTAL**

RATE FREQ/DAY OUR (hrs)

(llbps)

50.DU000 1.00 8.00

50.DUDUO 1.00 8.00

* TO HSFC

PP2 SAAXO005 365

SS COMMI201 365

$5 CONM1203 180

55 C014141204 365 "

55 SAAX0401 365

SS 588X0404 365

SS TI)flX2011 365

SS CONM1208 366

** SUBTOTAL**

** TOTAL **

Figure 3.1-1a (Cont'd).

DELAY AVG BAND- REQ BAND- OOSER-

(hrs) UIDTH MIDTH VATION

(Mbps) (Mbps) SIZE

(Gbytes)

O.OU 16.67000 50.00000 180.00000

0.00 16.67000 50.00000 180.00000

0.10000 1.00 24.00 24.00 O. 10000 O. 10000 1.08000

O.05000 4. O0 1. O0 24. O0 O.00833 O. 00833 O.02250

0.00200 1.00 24.00 24.DU 0.00200 0.00200 0.02160

0.05000 4.00 !.00 24.OU 0.00833 0.00833 0.02250

O.05000 1. OO 24. OO 3.00 0.05080 0.05000 0. 54000

0.05000 1. O0 24. O0 3. DU O.OSOOO 0.05000 O. 54000

O.00200 1.00 0.25 I. O0 O.00002 O. 00002 O. 00022

0 • 00200 1• O0 24.09 24. O0 O.00200 O.00200 O. 02160

O.30600 14. O0 122.25 127. DU O. 22058 O. 22058 2. 24842

1098.50574 195.10 481.75

1997 Data Base Listing (Continued)

310.00 165.62785 218.38843 349.51970

3-38
S

POll2

_N31l3

TOI"_

3B7q7

i000

91771

3439_

23

129990

M_C

120

i00

220

RVERRGE

,,TPL

1

1

1875O

1875O

(KBPS)

LIR¢

16667

16667

TOTRI.

50545

i000

9187]

22189

23

165628

PERK (KBPS)

GSIrC I'I_'C ,TSC _ LeRC I.aRC TOTRL

SS

COP

POP !

POP2

POP 3

TOTRL

350015;

i000i

393O85

4132

43

748275

206

100

3O6

5

300000

5 3OOOOO

50000

50000

140026

i000

393185

304132

43

1098585

Figure 3.1-2. 1997 Missions

3-39
GIF'C I_C

RVERRGE (KBPS)

_ L.sRC TOTRL

U

COP

POP !

POP_

POP3

TOI"RL

33750

91250

125000

]8750

18750

16667

16667

5O417

91250

1875O

160417

GI_'¢ M_C

PERK (KBPS)

.I'SC .TPt. LoRC L _RC TOTRL

SS

COP

POP !

POP 2

POP 3

TOTRI.

350000

390000

740000

300000

300000

50000

50000

400000

390000

300000

].0900CC

Figure 3.1-3. 1997 High Rate Missions (> 10 MBPS)

3-40
68FC

RVERRGE (KBPS)

TOTRL

COP

POP 1

POP2

POP3

TOTRt.

7

i000

521

3439

120

i00

128

i000

621

3439

23

4990!

23

220 5211

PERK (KBPS)

GS_F'C HSiF'C ,I'SC 3Pt. LoRC LaRC TOTRL

SS

COP

POP !

POP2

POP 3

TOTRL

15

IOO0

3O85

4132

_3

8275

206

i00

3O6

5 226

I000

3185

4132

4_

8586

Figure 3.14. 1997 Low Rate Missions (< 10 MBPS)

3-41
3.2 Options Description

Sections 3.2.1 through 3.2,3 describe the three options which were considered

in detail.

3.2.1. Centralized Option

Figure 3.2-1 illustrates the centralized processing option. The values in the

boxes are used For sizing and costing the system. These values are derived

?rom the Langley data base, as described in Section 3.1. At the ?ront end of

the ground system is a bulk recorder. This may be used to record all oF the

data which arrives at the ground terminal. The data is then level 0 processed

at White Sands. This process naturally smoothes out the data, and it is then

transmitted to the RDCs at the required rate. It should be noted that

payloads with a zero delay requirement may get their data with zero delay, but

it will not be level 0 processed. Production data sets may be sent to these

users a?ter they have been processed, and as such with some delay.

TO GSFC

TO JPL

.o..-Hv<,,,.. H,.v., o,.o< :.. ,o=

_ ARCHIVE GBYTES 12521

TO MSFC

COMM LINK

MBPS 150.0

--i (OMM LINK

MBPS 1B.75

COMM LINK

MBPS 50.0

COMM MBPS LINK I 0.001

COMM LINK

MBPS 0.22

Figure 3.2-1. Option 1 - Centralized

3-42
3.2.2. Hybrid Option

Figures 3.2-2a and 3.2-2b illustrate the hybrid system with and without

smoothing. "/he differences between these Figures is the peak communications

bandwidth and the peak level 0 processing requirement. In the case where

smoothing is assumed, the peaks are assumed to be equal to the averages For

data with non-zero delay requirements. This will, in turn, be reflected in

the communications costs and the level 0 hardware costs.

For the hybrid option, a virtual channel splitter is used to route high rate

data streams directly to where the RDCs for those streams are located. The

level 0 processing for these payloads is then performed at collocated level 0

processing Facilities (LZPFs). The channel which contains the multiplexed low

rate data is routed to Goddard where it is processed and then transmitted to

the appropriate RDC. Because some of this data has a zero delay requirement,

and there is no mechanism at White Sands to sort down to the packet level, the

entire stream must be sent with no delay. For purposes of this analysis, this

means that the link bandwidth for this stream must be 8.6 Megabits per second.

TO GSFC

-- COMM LINK J__

MaPS 8..__..6_6

_ ARCHIVE I

MBYTES 393

TO JSC

AVG _

TO MSFC

I BULK

RECORD

--! VC SPLIT L

TOICOMM,,NK I ILEVELO"OC t

G_l PEAK 150.0 --

J _MaPS 1S0'0 I_AVG _

--i PEAK 18.7S --

uapsle_7__..__s I AVG

TO_ COMM LINK H L£VEL O PaOC t--

PEAK c-I'l

LARC LMBP. _ S0 I I AvG _!_

ARCHIVE GaYTES 94S0 I

J ARCHIVE

GBYTES 1418 I

t ARCHIVE GBYTES 1260

Figure 3.2-2a. Option 2 - Hybrid (With Smoothing)

F I COMM LINK IM,. 0s I

3-43
lUULK

IIECORID

SPLIT

I I I

TO GSFC | COMM LINK J J LEVEL 0 PROC

! RPEAK 8.6

a IMOPS ILS AVG

COMM LINK LEVEL O PKOC

PEAK 600

_ AVG

_ ARCHIVE i

IdOYTES 393

TO JSC

--[ I

GOYTES 94S0

H ARCHIVE

G|YTES 1410 i

i LAIIC

Figure 3.2-2b. Option 2 -- Hybrid (Without Smoothing)

3,2.3. Distributed Option

Figures 3.2-3a and 3.2-3b illustrate the distributed system with and without

smoothing. For the distributed option, a virtual channel splitter is used to

route high rate data streams directly to where the RDCs ?or those streams are

located. The level O processing For these payloads is then performed at

colocated level O processing ?acilities (LZPFs). The channel which contains

the multiplexed low rate data is processed down to packets at White Sands and

the packets are then sent to the low rate LZPFs ?or processing.

3.3 Cost Assumptions

Figure 3.3-i illustrates the cost breakdown structure that was used to analyze

the cost differences between the three options. It should be noted that this

structure includes cost elements which are not within the SSDS. ]he purpose

oF this exercise is to obtain a consistent measure which may be used to

understand the overall cost implications o? the various options. Any

3-44
TO GSFC ,I..Ps L'N* 1so o ,' !-

,oo,,, I,o..,...

J MIIP$ 8.3

t__l..v.,o_.°c |IAvG PEAK "___0.3!__ II

COMM LINK --] LEVEL 0 FlIOC I

I PEAK ,3 I

..PS 0.3 IAVG _1

VC SPLIT coIdes LN, 0.01 1 t*vo oc PEAK

AVG

.00S t

I

TO LABC 1 COMM LINK

I • _WS SO

I LEVEL O PROC

Figure 3.2-3a. Option 3 - Distributed (With Smoothing)

t ARCHIVE

GRYTES 9450 I

I-GIYTE| 371 I

I-GBYTES 17 I

I,c.E I

CAIYTES 1:60 l

t ARCHIVE

GBYTES 1418 I

TO GSFC

J COMM LINK I--

MIIPS 6O0 I

TO G_FC ICOMM LINK

I MIK 0.3 I--

8ULK RECORD

H VC SPLIT f

PACKET SPLIT

PEAK 0SI_R

_COMM LINK

MSPS 0.3 I--

COMM MaPS LINK0.01 i_

COMM LINK I--

TO*AOcJ,,,_5° I

TO )PL I COMM LINK I--

MRPS 300 --I

Figure 3.2-3b. Option 3 - Distributed (Without Smoothing)

t LEVEL 0 PNOC

t LEVEL 0 PROC I--

I

LEVEL O PROC I

I

PEAK .3

AVG 2T

J LEVEL O PROC I

PEAK ,OOS

AVG

t LEVEL O PROC ]

I

LEVEL 0 PROC |

PEAK

AVG .___IIL25__

300 I

t ARCHIVE GIIYTES 1450 I

t ARCHIVE GBYTES 17 I

I ARCHIVE I GOYTES .08

I ARCHIVE

GBYTES 1418 I

3-45
SSDS Payload Data Processing Cost Elements

I. Bulk Storage (Fixed)

I1. Virtual Channel Splitter (Fixed)

II1. Level O Hardware

A.) Processors, Special Purpose Hardware (Fixed)

B.) Maintenance

IV. Level O Software

A.) SW Development and Test (Fixed)

B.) SW Maintenance

V. Level O Working Storage (Fixed)

VI, Archival Storage

A.) System and Drives (Fixed)

B.) Media (Recurring)

VII. Operations (Recurring)

VIII. Communications Bandwidth (Recurring)

IX. Smoothing Cost

A.) Device (Fixed)

B.) Media (Recurring)

Figure 3.3-1. Cost Breakdown Structure

statement of source of information in no way implies any intent to use the

product specified. It simply specifies the method which was used to obtain

cost estimates. Figures 3.3-2 through 3.3-7 illustrate the costs which were

derived from the cost analysis for each of the three options with and without

smoothing, Figure 3.3-8 provides a summary of this information in the form of

total fixed (development) and recurring costs for each case. Sections 3.3.1

through 3.3.g discuss the cost models which were used to arrive at these

numbers. Each of these sections is divided into subsections which describe

the rationale used in developing the cost model derived for that particular'

element and the application of the model to the systems being analyzed.

3.3.1 Bulk Recorder (fixed)

3.3.1.i Cost Model Ampex is currently developing tape recorder which is

capable of capturing 350 Mbps. It is projected that this recorder will cost

around $250 thousand.

3-46
Cost Rnalysis of Option i

Centralized at White Sands

(assuming smoothing)

I°

II.

III.

IV.

VII.

VI If.

IX,

Bulk Recorder

Channel Splitter

Level 0 Hardware

R) Processors, special

purpose hardware

B) Maintenance

Level 0 Software

A) Develop & Test

B) SN Maintenance

Level 0 Working Storage

Archival Storage

A) System and Drives

B) Media

Operations

Comm Bandwidth

Smoothing Cost

A) Device

B) Media

FIXED

($M)

1.0

3.0

31.2

27.5

7.4

49.9

RECURRING

($M)

3.7

5.5

1,3

1.2

3,6

120.0 15.3

Figure 3.3-2

3-47
Cost Analysis of Option 2

Hybrid System

(assuming smoothing)

I,

II.

III.

IV.

V°

VI.

VIII",

VIII.

IX.

Bulk Recorder

Channel Splitter

Level 0 Hardware

A) Processors, special

purpose hardware

B) Maintenance

Level 0 SoFtware

A) Develop & Test

B) SW Maintenance

Level 0 Working Storage

Archival Storage

A) System and Drives

B) Media

Operations

Comm. Bandwidth

Smoothing Cost

A) Device

B) Media

FIXED

($M)

1.0

3.0

38.7

32.5

7.4

49.9

0.5

133.0

RECURRING

($M)

4.6

6.5

1,3

3.6

3,6

0.8

20.4

Figure 3.3-3

3-48
Cost Analysis of Option 3

Distributed System

(assuming smoothing)

I.

II.

Ill.

IV.

V.

Vl.

VII,

VIII.

IX.

Bulk Recorder

Channel Splitter

Level O Hardware

A) Processors, special

purpose hardware

B) Maintenance

Level 0 Software

A) Develop & Test

B) SW Maintenance

Level O Working Storage

Archival Storage

A) System and Drives

B) Media

Operations

Comm. Bandwidth

Smoothing Cost

A) Device

B) Media

FIXED

($M)

1.0

3.0

40.3

37.5

7.4

4g.9

0.5

RECURRING

($M)

4.B

7.5

1.3

6.0

3.6

0.8

139.6 24.0

Figure 3.3-4

3-49
Cost Analysis of Option 1

Centralized at White Sands

(assuming no smoothing)

I°

II,

IIl,

IV.

V,

VI.

Viii.

VIII.

IX.

Bulk Recorder

Channel Splitter

Level 0 Hardware

A) Processors, special

purpose hardware

B) Maintenance

Level 0 Software

A) Develop & Test

B) SW Maintenance

Level 0 Working Storage

Archival Storage

A) System and Drives

B) Media

Operations

Comm. Bandwidth

Smoothing Cost

A) Device

B) Media

FIXED

($M)

1.0

3.0

31.2

27.5

7.4

49.9

RECURRING

($M)

3.7

5.5

1.3

1.2

3.6

120.0 15.3

Figure 3.3-5

3-50
Cost Analysis of Option 2

Hybrid System

(assuming no smoothing)

I°

II,

III.

IV.

Vo

VI.

VII.

VIII.

IX.

Bulk Recorder

Channel Splitter

Level 0 Hardware

A) Processors, special

purpose hardware

B) Maintenance

Level O Software

A) Develop & Test

B) SW Maintenance

Level O Working Storage

Archival Storage

A) System and Drives

B) Media

Operations

Comm. Bandwidth

Smoothing Cost

A) Device

B) Media

FIXED

($M)

1.0

3,0

53.1

32.5

7.4

49.9

RECURRING

($M)

6.4

6,5

1.3

3.6

13.3

146.9 31.1

Figure 3.3-6

3-51
Cost Analysis of Option 3

Distributed System

(assuming no smoothing)

I,

II,

III.

IV.

Vll.

VIII.

IX.

Bulk Recorder

Channel Splitter

Level 0 Hardware

A) Processors, special

purpose hardware

B) Maintenance

Level 0 So?tware

A) Develop & Test

B) SW Maintenance

Level 0 Working Storage

Archival Storage

A) System and Drives

B) Media

Operations

Comm. Bandwidth

Smoothing Cost

A) Device

B) Media

FIXED

($M)

1,0

3.0

55.6

37,5

7.4

49.9

RECURRING

($M)

6.7

7,5

1.3

6,0

13,3

153.9 34.8

Figure 3,3-.7

3-52
WITH SMOOTHING

FIXED RECURRING

OPTION ($M) ($M)

CENTRALIZED

HYBRID

DISTRIBUTED

]20.N

133.0

139.6

15,3

WITHOUT SMOOTHING

OPTION

CENTRALIZED

HYBRID

DISTRIBUTED

Figure 3.3_. Resu_s, Co_ for D_ined Sy_em Elemems

FIXED RECURRING

($M) ($M)

120.0 15.3

]46,9 31,1

]53.9 34.R

3.3.1.2 Rctual Cost

For each option, the cost for the bulk recorders is assumed to be one mil].ion

dollars.

3.3.2 Virtual Channel Splitter (fixed)

3.3.2.1 Cost Model

The functions of the virtual channel splitter are similar in nature to those

of the Ford TAC. The rates which must be supported, however, are about two

orders of magnitude higher. It is assumed the development and production

costs will be about one order of magnitude higher.

3.3.2,2 Rctual Cost

For each option, the cost for virtual channel splitter is three mil].ion

dollars.

3-53
3.3.3 Level 0 Hardware

Sections 3.3,3.1 and 3.3.3.2 provide the cost model and actual costs for the

three options with and without smoothing. Within this analysis an effort has

been made to determine when redundant systems will be necessary to support

reliability requirements. Redundancy is assumed more often in the case of no

smoothing, because in this case the LZPF is the first place in the system

(other than the bulk record) where the data is stored. Sections 3.3.3.3 and

3.3.3.4 provide the cost model and actual recurring costs for hardware

maintenance.

3.3.3.1 Hardware Cost Model

The functions of the high rate level 0 hardware are similar in nature to those

of the advanced telemetry processing system(ATPS). The actual ATPS studies

assumed that the downlink would contain 5% TDM data and 95% packet data. The

SSDS assumptions call for I00% packet data. The architecture of the ATPS

allows for modular addition o? high performance processors (HPPs) to

accommodate various bit rates. It is estimated by CDC that each HPP is capable

o? handling 8OMbps of packet data. The cost provided for a basic system which

includes two HPPs is 5.4 million dollars. Each additional HPP can be

configured for 1.2 million dollars.

In order to cost low rate level O processing, the PACOR system was used as a

baseline. This system is able to process a peak rate of 1.5 Mbps and the SEI_

hardware costs about $400,000. For the actual PACOR application, level thr_e

protocols are handled in the software. It is estimated that if this function

could be offloaded onto a board, the rate could be increased to 4 Mbps. Many

processor manufacturers offer families of computers which offer a range of

options in terms of capabilities in this range. The cost for low rate level O

processing is thus assumed to be linearly related to the rate ($0.1 per bps)

subject to a floor of $400,000.

3-54
3.3.3.2 Actual Hardware cost

Option one (centralized) with smoothing:

J

At White Sands, one system per SA channel is required with the capability

to handle 300 MBPS. Such a system would require four HPPs. For purposes

of reliability, redundant systems have been assumed. Thus, the total cost

for this option is $31.2 million.

Option one (centralized) without smoothing:

Same as option one with smoothing

Option two (hybrid) with smoothing:

At Goddard, one high rate system is required with the capability to handle

150 MBPS. For purposes of reliability, redundant systems have been

assumed.

At Langley, one high rate system is required with the capability to handle

50 MBPS.

At JPL, one high rate system is required with the capability to handle

18.75 MBPS.

At Goddard, one low rate system is required with the capability to handle

B.6 MBPS.

]'he total cost for this option is $38.7 million.

Option two (hybrid) without smoothing:

At Goddard, two high rate systems are required with the capability to

handle 300 MBPS. For purposes of reliability, redundant systems have been

as sumed.

3-55
At Langley, one high rate system is required with the capability to handle

50 MBPS.

At JPL, one high rate system is required with the capability to handle 300

MBPS. For purposes of reliability, redundant systems have been assumed.

At Goddard, one low rate system is required with the capability to handle

B.6 MBPS.

The total cost for this option is $53.1 million.

Option three (distributed) with smoothing:

At Goddard, one high rate system is required with the capability to handle

150 MBPS. For purposes of reliability, redundant systems have been

as sumed.

At Langley, one high rate system is required with the capability to handle

50 MBPS.

At JPL, one high rate system is required with the capability to handle

18.75 MBP$.

At MSFC, one low rate system

At JSC, one low rate system

At Goddard, one low rate system is required with the capability to handle

B.3 MBPS.

The total cost for this option is $40.3 million.

Option three (distributed) without smoothing:

At Goddard, two high rate system is required with the capability to handle

300 MBPS. For purposes of reliability, redundant systems have been

as sumed.

3-56
At Langley, one high rate system is required with the capability to handle

50 MBPS.

At JPL, one high rate system is required with the capability to handle 300

MBPS. For purposes of reliability, redundant systems have been assumed.

Rt Goddard, one low rate system is required with the capability to handle

B.3 MBPS.

At MSFC, one low rate system

At JSC, one low rate system

The total cost for this option is $55.6 million.

3.3.3.3 Maintenance Cost Model

A long-standing rule of thumb is that hardware maintenance costs one percent

per month of the hardware cost.

3.3.3.4 Actual Maintenance Cost

0

0

0

0

0

0

)tion one with Smoothing:

)tion one without Smoothing:

_tion two with Smoothing:

_tion two without Smoothing:

0tion three with Smoothing:

_tion three without Smoothing:

$3.7 Million

$3.7 Million

$4.6 Million

$6.4 Million

$4.8 Mill

$6.7 Mill

per year

per year

per year

per year

fOR per year

zon per year

3.3.4 Level 0 Software

Sections 3.3.4.1 and 3.3.4.2 provide the software cost model and actual costs

for the three options. Sections 3.4.3.3 and 3.4.3.4 provide the cost model

and actual recurring costs for software maintenance.

3-57
3.3.4.1 Software Cost Model

The total system cost for software is assumed to grow proportionally with the

number of locations over which the software is distributed. Due to the use of

standard CCSDS packets, it is expected that a large quantity of software will

be existing and reusable. Based on these two facts, the following formula has

been derived to predict the cost of the level zero software:

level 0 software cost = $25M w ( 1 + 0.1 w (number of locations))

3.3.4.2 Software Actual Cost

Cost For option 1:

Cost For option 2:

Cost For option 3:

$27.5M

$32.5M

$37.5M

3.3.4.3 Software Maintenance Cost Model

The following formula has been derived to predict the cost of the software

maintenance cost:

Maintenance cost = Development cost w .2

3.3.4.4 Actual Software Maintenance Cost

Cost For option 1: $5.5M

Cost For option 2: $6.5M

Cost For option 3: $7.5M

3.3.5 Level 0 Working Storage (Fixed)

The cost of both working storage and archival (7 day) storage are very

sensitive and very high. For this reason, a parametric cost model has been

constructed for each of these. Given the parametric models, appropriate

parameters which define the SSDS requirements are plugged in to derive the

cost.

3-58
3.3.5.1 Level 0 Working Storage Cost Model

It is assumed that the working storage will be supported using fixed magnetic

disks, The following is an analysis of the cost of magnetic disk based

systems. The costs will be derived as a function of the data rate entering

the system and the duration of time which the data must be stored.

Parameters:

h - Hours of storage required

r - average data rate (megabits per second)

A - "Archive size"(gigabytes)

cl - cost per disk

gl - gigabytes per disk

Calculations

A(gigabytes) = r (megabits/sec) w h (hours) w 60 (min/hour) w 60 (sec/min)

.125 (bytes/bit)w ,OO1 (giga/mega)

=rWhWO.45

System cost = number of disks w cost per disk

= (A/gl)*cl

Cost

(0.45 w r w h w cl ) / gl

3.3,5.2 Actual Level 6 Working Storage Cost

Actual Cost Assumptions (Based on existing RABI 3-pack)

gl = 1.2 gigabytes

cl = $40,000

3-59
Actual Requirements

r = 165 Mbps

h = 3 hours

Therefore, for each option, the cost for level 0 working storage is $7.4

million.

3.3.6 Archival (7 day) Storage

It is assumed that the seven day storage requirement will be supported using

erasable optical disks. As such, in addition to the fixed development cost

there is a recurring cost associated with supplying the media. Sections

3.3.6.1 and 3.3.6.2 provide the cost model and actual costs For both the

development and recurring media costs.

3.3.6.1 Archival Storage Cost Model

The following is an analysis of the cost of optical disk based systems. The

costs are derived as a function of the data rate entering the system and the

duration of time which the data must be stored.

For the analysis of optical systems, it is assumed that the media must be

replaced. This analysis develops parametric cost models for fixed (3.3.6.1)

and recurring (3.3.6.3) cost.

It is assumed that not all disks will be "on-line". "On-line" disks are

mounted in drives. Automatic retrieval (ala jukebox) is assumed. A

percentage of on line storage is assumed based on similar existing systems.

The cost for on-line gigabytes includes high speed drive, support software,

and retrieval system.

3-60
Parameters

h __

r --

A -

p -

C2 -

C3 -

Hours of storage required

average data rate (megabits per second)

"Archive size"(gigabytes)

proportion of on-line storage

cost per gigabyte on-line storage

media cost per disk

g2 - gigabytes per disk

W - Writes per Disk

Calculations

Fixed cost Calculation

On-line gigabytes = p * r w h w 0.45

fixed cost = on-line gigabytes w cost per on-line gigabyte

Recurring cost

Recurring cost = Cost to fill archive w number of times

per yr media replaced

Cost to fill = disks required to fill w cost per disk

= (Alg2)_c2

= (0.45 w r W h w c3) / g2

Times media replaced = times archive filled / writes per disk

Times archive filled = hours per year / hours to fill

= (365- 24) / h

Times media replaced = (365 w 24) / ( h w W)

3-61
Cost

Fixed cost = c2 w p w r w h w 0.45 recurring cost

= (3942 * r) * ( c3 / ( W W g2 ))

3.3.6.2 Actual Archival Storage Cost

Actual Cost Assumptions

p =0.2 ( 20% )

c2 = $20,000 / megabyte

c3 = $400 / disk

g2 = 2 gigabytes

W = i00 writes per disk

Actual Requirements

r = 165 Mbps

h = 168 Hours

Therefore, for each option, the fixed cost for archival is $49.9 Million and

the recurring cost is $I.3M per year.

3.3.7 Operations (recurring)

3.3.7.1 Operations Cost Model

It is determined that six full-time(24 hour) positions will be required to

support the SSDS functions at each LZPF. This translates to twenty-four

individuals. Assuming that each individual costs fifty thousand dollars per

year, the formula For the recurring operations cost is :

Operations Cost = (# OF RDCS) W $1.2M

3-62
3.3.7.2 Actual Operations Cost

Cost For option i : $1.2M

Cost For option 2 : $3.6M

Cost For option 3 : $6.0M

3.3.8 Communications Bandwidth (recurring)

3.3.B.I Communications Bandwidth Cost Model

It is important to note that this is not an SSDS function, and will not be

reflected in the SSDS design. It is necessary to consider this element to

understand cost differences between centralized vs distributed system. It is

also important to understand the sensitivity of the system cost and system

design to the cost of the communications.

In order to measure the communications cost, a variable must be selected which

represents the state of the art of communications. It is assumed that the

communications media will be optical fibers, and therefore the cost is

measured in dollars per Mbps per mile per year. Based on projected fiber

optics costs, the figure $10/Mbps/mile/yr is used.

3.3.8.2 Actual Communications Bandwidth Cost Model

Figures 3.3-9 and 3.3-10 derive the communications cost for each option with

and without smoothing. The following is a summary of these costs.

Option one with Smoothing:

Option one without Smoothing:

Option two with Smoothing:

Option two without Smoothing:

Option three with Smoothing:

$3.6 Million per year

$3.6 Million per year

$3.6 Million per year

$13.3 Millionper year

$3.6 Million per year

Option three without Smoothing: $13.3 Million per year

3-63
Communications Cost Analysis

(assuming smoothing)

Option 1 - Cehtralized at White Sands

Link Mbps Miles Mbps*Miles

WS-GSFC 150.00 1728 259200

WS-]PL 18,75 670 12562

WS.-LARC 50,00 1751 87550

WS.-MSFC 0,22 1120 246

WS-JSC 0,00 717 0

TOTAL

Option 2 - Hybrid

Link Mbps Miles

359558

Mbps*Miles

WS-GSFC 150.22 1728 259580

WS-]PL 1B.75 670 12562

WS-LARC 50.00 1751 87550

GS-MSFC 0,22 711 156

GS-JSC 0,00 1222 0

TOTAL

Option 3 - Distributed

Link Mbps Miles

359848

Mbps*Miles

WS.-GSFC 150,00 1728 259200

WS-JPL 18,75 670 12562

WS-LARC 50,00 1751 87550

WS-AMSFC 0,22 1120 246

WS-J$C 0,00 717 0

TOTAL

Communications Cost

Option MbpsWMiles $/Mbps/Mile/Yr

1 359558 10

2 359848 I0

3 359558 I0

359558

$/Yr

3,595,580

3,598,480

3,595,580

Figure 3,3-9

3-64
Communications Cost Analysis

(assuming no smoothing)

Option I - Centralized

Link

at White Sands

Mbps (avg) Miles MbpsWMiles

WS-GSFC 150,00 1728 259200

WS-_PL IB.75 670 12562

WS-LARC 50.00 1751 87550

WS-MSFC 0.22 1120 246

WS-JSC 0,00 717 0

TOTAL

Option 2 - Hybrid System

Link Mbps (peak )

359558

Miles MbpsWMiles

WS-GSFC 600,00 1728 1036800

WS-;PL 300.00 670 201000

WS-LARC 50.00 1751 87550

GS-MSFC 0.31 711 220

GS-;SC 0.01 1222 12

TOTAL

Option 3 -

Link

Distributed

Mbps (peak)

1325582

Miles MbpsWMiles

WS.-GSFC 600.00 1728 1036800

WS-JPL 300.00 670 201000

WS-I..ARC 50.00 1751 87550

WS-MSFC 0.31 1120 347

WS-JSC 0.01 717 7

TOTAL

Communications Cost

Option

1

2

3

Mbps*Miles

359558

1325582

1325704

1325704

$/Mbps/Mile/Yr $/Yr

i0

i0

i0

3,595,580

13,255,820

13,257,040

Figure 3.3-10

3-65
3.3.9 Smoothing Cost

It is important to note that this is not an SSDS function, and will not be

reflected in the SSDS design. It is necessary to consider this to understand

cost differences between centralized vs distributed system because centralized

system performs the smoothing operation implicitly. This cost is only applied

in the cases where smoothing is assumed.

3.3.9.1 Smoothing Cost Model

It is assumed that the smoothing will be done using erasable optical disks.

/he cost model for this function is the same as the model for the archive.

Only the parameters differ.

3,3.9.2 Actual Smoothing Cost

Actual Requirements

r = I00 Mbps

R = 120 Gbytes

Therefore, for each option, the fixed cost for archival is $0.5 Million and

the recurring cost is $0.8M per year.

3.4 Sensitivities

The major sensitivities in this system are with respect to communications and

storage costs.

3.4.1 Communications Sensitivities

Although a detailed analysis of the ground communications design is outside of

the scope of the SSDS study, the fact remains that this element will be an

integral portion of the ground system. Fiber optic communications appears to

be the wave of the future, however at this point the costs are highly

uncertain. For purposes of this trade study, the parameter XI

3-66
($/mbps/mile/yr) is used to measure the state of the art of communications.

Current communications costs For the White Sands to Goddard link have been

calculated to be about $26/mbps/mile/year. Projections from Fibertrak

indicate that this will go down to $B/mbps/mile/year.

Figure 3.4-1 illustrates the overall 10 year costs of the three options as a

Function of communications cost assuming that no smoothing is performed. The

point here is that a centralized system performs smoothing inherently. The

advantage of this Feature is higher For higher communications costs.

BOO n

700

8 500 m

m

0=

_ 41_

o

300

200

lO0 m

I

5

Figure 3.4-1. Sensitivity to Communications Cost

Sensitivity to Communications Cost

Assuming No Smoothing

_ Option 2

Option 1

I I I I I

10 15 20 25 30

$/Mops/Mils/Yr

3.4.2 Mass Storage Sensitivities

The model used to derive a parametric description of optical disk based system

mass storage costs is provided in section 3.3,6.1. The one parameter which

describes the state of the art of read/write optical disks is :

(cost per disk) / ((gigabytes per disk) _ (writes per disk))

3-67
For purposes of this sensitivity analysis, this variable is known as X2. The

key here is that the only optical disks currently available are write once

disks. At current prices, X2 = $125/Gbyte/Write. According to the mass

storage trade study, it is projected that X2 will go down to

$0.45/Gbyte/write. Figure 3.4-2 illustrates the pro?ound impact on the lO

year cost of the system. The actual design of the system will be highly

dependent on the state of the art o? the optical disk technology. At current

prices, optical disks would not be included in the system design.

Advances are being made in the optical disk technology. One key issue is in

the area of media which can be erased and re-written many times. IF

technology advances to the point where disks may be written to thousands of

times, then the recurring media cost will be neglible. But how much will

these systems cost?

Sensitivity to Archive Cost

Hybrid System (No Smoothing)

1400--

o

(J

o

>-

o

t--

1300

1200

1100

1000

9O0

800

700

600

5O0

400

300

200

100

B

m

w

m

m

m

m

B

m

B

-_-- X2-- 125

X2 -- 40

_--- -_-_X2 -- 20

---- -_---X2- 10

,,. _v--- X2 - .45

I I I I I I I I I I I 1 I I

12 24 36 48 60 72 84 96 108 120 132 144 156 168

Archive Duration (Hours)

Figure 3.4-2. Sensitivity to Archive Cost

3-68
The key point here is that the cost differences as a function of the state of

the art of optical disk systems are far greater than the cost differences as a

function of the topology option chosen. This by no means implies that cost is

an insignificant factor in picking a topology. It simply points out that

these differences are not overwhelming, and that other factors should be

considered in order to pick a topology which will serve as the cornerstone for

the space station ground system end-to-end payload data processing.

4.0 Issues and Recommendations

There are a large number of non-cost issues which are used to help determine

which topology best serves the overall needs of the Space Station ground

system. Many of these are difficult to relate to cost, and others deal with

issues whose scope is larger than the SSDS. Sections 4.1 through 4.3 present

a number of key issues and explain how these effect the choice of topology.

Based on this information as well as the results of the cost and sensitivity

analyses, section 4.4 presents the recommended ground topology for the routing

and processing of payload data.

4.1 Physical Proximity to Higher Level Processing

One key issue is the advantage of co-locating Level 0 processing with the high

rate missions. Upper level processing is unique to the payload, lhis

processing will be performed at Regional Data Centers, and by definition will

be an SSIS function. It is expected that the RDC's will be distributed and,

therefore, the advantages of co-location will be gained if the Level 0

processing is distributed likewise. The advantages of co-location, and thus

of the hybrid or distributed systems are described in sections 4.1.I through

4.1.3.

4,1.1 Ease of Access to Level 0 Data and Re-Transmission

One advantage of co-location is that it provides ease of access to the Level 0

storage from the upper level processing.

3-69
LANDSAT has had the experience that gaps have been introduced not only by the

Space-Ground communications, but also by the ground- to-ground

communications. The data is thus shipped from White Sands to GSFC where Level

0 processing is performed to correct for both kinds of problems. High rate

missions are the least likely to be able to utilize robust transmission

protocols, such as re-transmission, and thus the most subject to have such

problems and require re-transmission. Re-transmission over a Local Area

Network seems less likely to introduce errors.

4.1.2 Archival and Other Storage Duplication

Depending on the design of the SSIS, it may be possible to use the Level 0

storage (7 day) as a source of data for higher level processing.

At 165 Mb/s average, temporary storage for 7 days will be a significant cost

analysis. Significant SSIS cost savings could be achieved if this data store

is shared.

4.1.3 Sharing of Other Resources

Depending on the design and implementation of the SSIS (RDC), it may be very

possible to share a number of resources between SSDS and SSIS. Specific

resources considered here may be high performance processors, spare parts,

hardware maintenance personnel, software maintenance personnel, and operations

personnel.

4.2 Evolution to ACTS or TDAS Environment

It is expected that some time in the future, relay satellites will have the

capability to downlink data directly to distributed earth terminals. This

would tend to favor a hybrid approach, as direct downlinks could be used to

the Level 0 sites, saving on communications costs. Once a centralized

facility is established, it may be programmatically very difficult to migrate

to a more distributed environment, given the investment involved, and

especially if the capability is established at White Sands.

3-70
4.3 Sensitivity to Requirements

Many of the requirements which drive this study are subject to change. The

impacts of changes to these study inputs may be very significant. Sections

4.3.1 through 4.3.4 describe four of these:

4.3.1 High Rate Payload Downlink Format

It has been a study assumption that high rate payloads output CCSDS packets.

If this is not the case, the centralized Level 0 processing may be much more

complex. In the case of distributed or hybrid option, the high rate payload

data processor may be designed to match the downlink format.

4.3.2 The Langley Data Base The data in the Langley Data Base is frequently

changing, and probably will continue to change through launch. In light of

this, the hybrid option has some distinct advantages. If a high rate mission

is added or deleted, the portion of the system which services that payload may

be added or deleted, with minimal impact to the rest of the system. On the

other hand, the marginal cost of adding a low rate payload is minimized

because the resources which service that payload are shared.

4.3.3 Real Time and Quicklook Data

If it is assumed that high rate mission POCC's need the full bandwidth in real

time for quicklook data, then one would tend to co-locate the Level 0

processing and the POCC for that mission, to meet the real time requirements.

The communications costs would be less a discriminator between the Level O

architectures since the communications costs would be borne anyway for the

POCC's. If this bandwidth is required, then there is no advantage to

smoothing and a distinct disadvantage for the centralized approach.

3-71
4.3.4 Level 0 Delivery Requirements

It is required to deliver the Level 0 data For high rate missions within 24

hours, as specified in the Langley Data Base. IF longer delays are allowed, a

centralized system may be preferred. In a centralized system, one could save

bandwidth From the Level 0 site to the upper level site by mailing an optical

disk.

4.4 Conclusion

Based on the costs and the issues described in sections 3 and 4, the hybrid

system has been chosen For the baseline ground system design. The major

reasons For this decision are the fact that the cost differences were not

overwhelming, combined with the fact that the hybrid system demonstrates

significant advantages in the areas of Flexibility with respect to changing

system requirements, potential overall ground system cost savings, and better"

potential for future technology insertion.

3-72
APPENDIX A

Contents

A-1 - A-4 Communications Costs

A-5 - A-13 Buffer Costs

3-73
SPRCE STRTION NETNORK TOPOLOGY

TRRDE STUDY

COHMUNICRTIONS COST

OPTION

SA LINKS

_l _3

FROM

WS

TO MILES RRTE

GS' 1728 75

COST(_)

1296

WS JPL 670 21 141

1437

3-74
SPRCE STRTION NETNORK TOPOLOGY

TRRDE STUDY

COMMUNICRTIONS COST

OPTION 21

SALINKS i

FROM TO MILES RRTE COST(L]

WS GS 1728 233 4032

GS JPL "2289 21 481

4523

3-75
SPRCE STRTION NETNORK TOPOLOGY

TRRDE STUDY

COMMUNICRTIONS COST

OPTION 21

SA LINKS 2

FROM TO MILES RRTE COST(_)

WS GS 1728 466 8064

L,

GS JPL 228,9 21 481

8545

3-76
SPRCE STRTION NETNORK TOPOLOGY

TRRDE STUDY

COMMUNICRTIONS COST

OPTION 21

L_ •

SA LINKS 3

FROM

WS

GS

TO

GS

JPL

MILES

]728

-2289

RRTE

7OO

21

COST(b)

12096

481

12577

3-77
SPRCE STSTION NETNORK

TRSDE STUDY

BUFFER COST

TOPOLOGY

LO(_TION _.,IFT'B_IZ£fQITS_

OPTION

SA LINKS

SS 220 I0 2200

POP1 510 I0 .5100

POP2 352 I0 3520

W 833 .2 166

i

10986

3-78
SPRCE STRTION NETNORK

TRRDE STUDY

BUFFER COST

TOPOLOGY

OPTION

SS

POPI

216

i

82

POP2 245

WS lOOl

•_ SA LINKS

I_R_II

lO 2160

lO 820

lO 2450

2 200

m

5630

2

3-79
SPRCE STRTION NETNORK

TRRDE STUDY

BUFFER COST

TOPOLOGY

LOOn'ION @LlffERSIZE(_IIS]

OPTION

, SA LINKS

dIK_ _E)

°

SS 176 ]0 17.6_0 , ,,

POPI 64 lO . 640

POP2 2i3 lO 2330

WS I036 .2 207

4937

3-80
SPRCE STRTION NETNORK

TRRDE STUDY

BUFFER COST

TOPOLOGY

Ll_il"Imi _TEi_IZEI{IlT$1

OPTION

_ SA LINKS

PER(lit

SS 2200

POP1 51 O0

POP2 3520

GSFC

220 ]0

510 I0

352 I0

494 .2 99

10939

1

3-81
SPRCE STRTION NETNORK

TRRDE STUDY

BUFFER COST

TOPOLOGY

OPTION

SA LINKS

SS 216 .I0 2160

POP1 82 10 820

POP2 245 10 2450

GSFC 578 .2 115

5545

3-82
SPACE STRTION

TRRDE

BUFFER

NETNORK

STUDY

COST

TOPOLOGY

Ll_rlIli •

OPTION

SA LINKS

2

3

SS

POPI

POP2

GSFC

176

64

233

587

I0

I0

IQ

.2

1Z60

640

233Q

,117

4847

3-83
SPRCE STRTION NETNORK

TRRDE STUDY

BUFFER COST

TOPOLOGY

OPTION

_ SA LINKS

SS 220 . 10 2200,

POPI 510 I0 5108

POP2 352 I0 3520

] 0840

3-84
SPRCE STRTION

TRRDE

BUFFER

NETNORK

STUDY

COST

TOPOLOGY

SS 216

OPTION

SA LINKS

EIS'IPZR_IT

lO 2160

POP1 82 lO

POP2 245 ]0 2450

543O

3

2

3-85
SPRCE STRTION NETNORK

TRRDE STUDY

BUFFER COST

TOPOLOGY

L(X:ITrION

SS 176

POPI 64

POP2 233

OPTION

SA LINKS

(ZSII_ _II C_I.

lO 176P

lO .648

lO 2330

4730

3

3

3-86
IV. COMMUNICATIONS STANDARDIZATION

4-'I
COMMUNICATIONS STANDARDIZATION TRADE STUDY

1.0 Trade Study Definition

i. 1 Background

The SSDS will develop as a combination of ground and space data networks

connected through a communication link that involves current and future

satellites, remote-user Ground Stations and onboard stations. Communications

will be by way of existing and future networks for data distribution, serving

both Space Station core and user needs. Data paths will involve several

network media (e.g., RF, wire, and fiber optics) and protocols (e.g., packet

sizes, data rates, and message headers). The SSDS must incorporate existing

and emerging communication standards to promote growth and to realize the

cost-effective benefits of standardization. This trade study will address the

following specific areas related-to communication standards:

i) CCSOS and IOS/OSI compatibility issues

2) Use of CCSDS recommendations for packet telemetry and telecommands,

telemetry/telecommand channel coding, standard format data unit

(SFDU) utilization, and application of CCSDS standard time code

formats

3) Identification/recommendation of standards (developed or" emerging)

for layers 2-7 of ISO/OSI For both space and ground

PRECEDING PAGE BLANK NOT FILMED

4-3
1,2 Issues

The following issues are applicable to this trade study:

I , Use of international and national standards including those from the

following organizations: International Standards Organization,

Consultive Committee for Space Data Systems, American National

Standard Institute (ANSI), Consultive Committee For International

Telegraph and "Telephone (CCITT), European Computer Manufacters

Association (ECMA), National Bureau of Standards, EIA ....

2. Use of commercial non-ISO/0SI standards (proprietary protocols)

3. Identifying the need for new standards development

4. Ground and space commonality/migration issues.

1.3 Selected Criteria

The selection criteria are as follows:

Requirements tradeoffs --- the degree to which the option meets the

requirements of Task l and those derived requirements described in

the Standardization Options paper

Technical feasibility .....any inherent technological limitations,

e.g., packet switching speeds

Impacts on SSDS elements ,-- examining and balancing the impacts on

major SSDS elements. These are:

4-4
- Payload Interface

- On-board LQN & DMS

- Gateways

- TDRS Uplink/Downlink

- Data Handling Center

- Regional Data Center

The options paper summarized a number of requirements from the Task 1 report,

and also from other sources and requirements and implications resulting from

the Task 1 requirements. These were presented in the options paper according

to the ISO/OSI layers. These are summarized in the following section.

1.4 Requirements Affecting Selection of Standards

The SSIS/SCS (per Figure 1--2 includes both SSDS and non-SSDS elements) shall

obtain and/or develop standards for customer interfaces in areas such as

software, critical/limited payload, health and safety monitoring, man-machine

interfaces, command generation, time code, attitude and position data,

pointing coordinate systems, data base management systems, graphics displays,

data handling/archiving/distribution, documentation, configuration control,

cost accounting, data system requirements definition, operations audit trail,

etc. When new customer standards are proposed, the SSIS/SCS sha].1 present

these standards to a customer panel which will provide an impact statement on

behalf of all customers (Task 1, Section 5.3.B.9).

The SSDS shall provide standardized language, protocol, format, and

transmission rates for a11SSDS and all SSDS subsystems (Task 1, 5.3.B.9).

4-5
As a first preference, customer interface standards shall be defined in

accordance with the International Standards Organization (ISO) seven layer

model For Open Systems Interconnect (OSI) (Task 1, Section 5.3.8.g).

The SSDS shall use, for each of the seven layers, existing internationally

accepted standards as a first priority Followed by new standards development

(within the OSI model framework) (Task 1, Section 5.3.B.9).

The customer interfaces defined within the OSI model shall conform to

standards defined and controlled by such sources as:

NBS, National Bureau of Standards

ANSI, American National Standards Institute

ECMA, European Computer ManuFacturing Association

CCITT, Consultative Committee for International Telegraph and Telephone

EIA, Electronic Industry Association

CCSDS, Consultive Committee for Space Data Systems

IEEE, Institute of Electrical & Electronic Engineers

When practical, appropriate standards from these sources shall be used at

higher layers of the OSI model (]ask 1, Section 5.3.8.9).

For customer interfaces, support commercially available standards.

Provide ancilliary avionics and housekeeping data (timing, state vector, RF

communication, system status, acquisition of signal/loss of signal, moding,

pointing, etc) to the attached payloads and customers (]ask 1, Section

5.3.2.4).

4-B
The SSIS/SCSnetwork data handling shall be independent of the format or

content of the customer data (CRSS,3.1.4).

Customerdata shall be delivered without alteration of its contents. Any

artifacts imposedby the data transport service, e.g., data reversal due to

communicatonsbuffering, shall be removedbefore data delivery to the customer

(CRSS, 5.4,3).

Format data in self identifying data units (derived).

Support multiple payloads in a way which minimizes interactions and a minimum

o? software re-configuration (Derived).

Support an evolutionary expansion of the SS DMS (Derived).

Support the end-to-end BER requirements (iOW*-6 to iO_-9).

Support quality of transport service (computer quality vs normal quality)

(Derived).

Provide real-time distribution of real-time and near real-time data, including

Level 0 processing, demultiplexing, buffering, routing, and re-transmission

(]ask 1, Section 5.3.1.3).

Provide real-time, raw payload data to the customer (Section 5.3.1.i).

Support real-time re-allocation of data distribution resources to help meet

customer priorities (Section 5.3.3.3).

Support rapid separation of the downlink/uplink by customer ID (Derived).

Support electronic transmission of data to customers and RDC's (Derived).

4-7
Support delivery service (immediate delivery vs store & forward delivery)

(Derived).

Support reliability services (verified delivery vs unverified delivery)

(Derived).

Support symmetric services (uplink/downlink) (Derived).

Allow or support encryption (Derived).

1.5 Applicable Options

In the description of communications standards options, four options were

presented for implementation of an end-to-end standards architecture:

i) ISO Compatible Standards For Local & Wide Area Networks (space &

ground) combined with:

a) CCSDS Packets Implemented As An ISO Upper Layer Standard

b) CCSDS Packets & Frames Implemented "Below" Onboard !SO

c) CCSDS Implemented As Alternate Downlink Standards For ISO Layers

1-3

II) ISO Standards Only

Upon subsequent reviews, a consensus developed that the most promising design

appeared to be the first (la). The options paper presented a number of

options within each ISO/OSI layer for choices of standards.

4-8
2.0 Trade Study Methodology & Approach

This trade study will:

o comparethe design with its major alternate implementation options

o examinetradeoffs between implementations of the design

examine the characteristics of the local and wide area standards that

should be used

As noted, there were four major options presented for an end-to-end standards

architecture. This tradeoff will provide a high level comparison of the

options. There are several issues within the proposed design option which

will be discussed. While this study was not intended to select specific

standards for the LAN and WAN, this trade will characterize the desired

choices. The choice of standards is driven by the end-to-end topology and the

needs of each subnetwork, rather than the inverse.

2.1 Implementation Options

The following provides an overview of the proposed implementation of an

end-to-end standards architecture that is consistent with option ].a identified

in section 1,5.

The CCSDS Packet Standard is implemented as application layer data. Each

packet is delivered to the Space Station local area network. The On-board LAN

implements some portion of ISO layers 1-7. All headers are added and removed

by the on-board LAN. The layer 4-7 ISO protocols thus apply from one on-board

instrument to another. At the downlink gateway, the CCSDS Telemetry packets

are reassembled into the original source packets. Fhese are framed and

encoded. Framing is done asynchronously to the packetization, i.e., the

boundaries do not line up.

4-9
An inverse process occurs on the ground. The codeblocks are de-coded, and

frames are removed. The framing/de-framing process synch's on the frame synch

code. Packetization and packet recovery is performed using the frame pointer

to the first packet header, using the packet size data in the packet header

to recover the original packet (which may be spread through several frames).

The source packets are then transmitted over the ground wide area network.

The above is a version of the first option for implementation of an end-to.--end

standards architecture. This proposed design will be compared with two of the

three other options presented in the options paper. The fourth option in the

options paper was to only utilize ISO standards. This option was presented

for logical completeness. Existing ISO standards are not suited to the needs

of the space-ground link, as noted in the options paper, and thus this option

implies development of entirely new standards, not a modification of existing

standards. Since this is at best speculative, this fourth option will not be

discussed further in this section.

2.1.1 Requirements Tradeoffs

SSDS requirements affecting the selection of communications standards has been

summarized in the options paper. The options will be compared with respect to

how well key requirements are met.

In their original form, none of the options support the following services as

customer selectable options:

o quality of transport service (computer quality vs normal quality)

o delivery service (immediate delivery vs store & forward delivery)

o support reliability services (verified vs unverified delivery)

o support symmetric services for uplink/downlink

4-10
This does not provide a discriminator between the options,

Using a strict interpretation of the requirements, the proposed design does

not meet the following requirements:

o The SSIS/SCS data handling shall be independent of the format or

content of the customer data (CRSS)

o The data network shall be able to transport and deliver data sets

intact, without having any knowledge of their internal format or

content (CRSS, 2.2.3.4)

These requirements are not met since the CCSDS formats are implemented as part

of the application data. This is interpreted to mean just that - the headers

literally treated as data and not examined by the data system. This may not

be the case if the format were implemented as a standardat some other level.

Whether it makes any practical difference to implement the formats as

application, presentation, or transport standards will be discussed in the

next section.

The requirements above are met by the other options since the SSDS can depend

on using data system required headers to route the data.

The other requirement not met is to provide communications services

symmetrically over the uplink/downlink. The desired autonomy of the space

station extends to processors onboard to be able to send requests for ground

based resources without human intervention .-- computer-to-computer

communication. This requires such services as verification of receipt and

retransmission, services normally associated with uplink telecommands.

Furthermore, the autonomy of the space station is expected to increase over

time, with functions migrating from ground to space. It is desirable to

accomplish this migration without requiring extensive modifications to the

software of functions which intercommunicate.

4-11
'This implies:

providing all services, (such as verified vs unverified delivery) in

both directions

use 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

2,1,2 Impacts On SSDS Elements

The payload always has a packet format, whether it is in the laboratory or in

the Space Station or platform. This simplifies testing. This is not true For

the other two options. The same is true for the core interfaces.

The on-board LAN must carry the CCSDS packet header information, while the

other two options do not. Since the source packets are long, this does not

appear to be significant. For example, take two sample packets lengths of 12,

8OO bits and 4000 bits (taken from the Gamma Ray Observatory). In this case,

the overhead for the primary header is .375% and 1.2%, and the secondary

header (ancilliary data) is 1.375% and 4.4% respectively.

The on-board gateway (uplink/downlink) is less complex for the downlink for

this option than for the other two options. In the design, the gateway must

re-assemble the original source packet (and remove the on-board t.AN headers)

and perform the framing and channel encoding. In the other two options, the

gateway must also create each packet including adding the relevant ancilliary

data. While this approach has been used by some spacecraft (packetization by

central processor), it actually can reduce the value of the packet telemetry

approach. For example, one might add the same ancilliary data to each packet,

and make all the packets of the same length as opposed to making these items

customer or payload specific. Another result is that the payload interface

changes, as noted above.

4-12
The on-board gateway, on the uplink, must read the packet destination ID and

incorporate this into the ISO headers. The complexity appears slightly

greater for the proposed option than for the other options since a translation

must be done between the application address and the on-board location.

The ground gateway for the design, and the ground processing required to route

downlink data is greater For the proposed design than For other options. A

translation must be done for both uplink and downlink between the application

ID and the ground location.

The ground reception point must act as the intelligent interface or gateway

between the data distribution network and the TDRSS uplink/downlink. With

multiple TDRS and two NG]" the mapping between TDRS channels will be very

dynamic. The COP, POP, or SS might be using one NGT at one time, and other at

another time. Scheduling all this may be very difficult, so that the right

data goes to the right customer or RDC.

The gateway, in the DHC will be required to perform:

o data capture

o interface to both NGTs

o separate SS from non-SS data (on a scheduled basis)

o remove the CCSDS frames and channel coding

o read the source application ID on the CCSDS Packet

0 from a look-up table maintained by Ground Facilities Management,

determine the destination

o Based on the destination, send the data to the right port for that

data. Different options exist for network switching and routing L:he

data depending on the data type and characteristics.

4-13
Provide the physical, data link, and network interfaces to the data

distribution network or subnetwork used, e.g.

if the data is sent on a fixed or scheduled point to point link

through a mux, send the data to the right mux port

if the data is sent on a circuit switched link, interface to the

circuit switch and set up the call

if the data is message switched, add the necessary data link and

network headers (based on the inferred source ID) and send it to

the message switch

if the data is to be packet switched, add the necessary data

link and network headers, set up a virtual connection to the

endpoint, and transfer the data

The inverse functions would have to be performed for the uplink. That is,

packets or data streams would be routed to the DHC, these would be put in the

right format ?or the uplink. One might apply the on-board ISO headers at the

DHC, or more likely at the on-board gateway as noted above. The data volumes

for the uplink are much less, requiring less processing.

All these functions are needed to meet the requirement that the customer be

able to intera('t with the payload in essentially the same manner as in the

laboratory, Thus one is required to have an end-to-end session between the

payload and the ground control point,

The functions at the DHC are somewhat simplier for the other options since

they assume a direct translation between the uplink/downlink protocols and the

on-board and WAN protocols. Protocol conversion is required but it may be

possible to do this without scheduling or a table lookup.

4-14
2.2 How Should Standards Be Implemented?

The first issue on implementing the proposed design is whether the CCSDS

standards are implemented as part of the applicationdata or as application,

presentation, or transport layer standards.

One possible difference in terms of requirements is that two additional

requirements are met if the formats are implemented as standards rather than

part of the application data:

o the SSIS/SCS data handling shall be independent of the format or

content of the customer data (CRSS)

o the data network shall be able to transport and deliver data sets

intact, without having any knowledge of their internal format or

content (CRSS, 2.2.3.4)

The practical impact of this view is programmatic:

If the formats are truly implemented as "application data" there

will be no means to insure that the customers actually use these

formats. In fact some advocate that customers may be using many

formats.

Taken to the logical extreme, this view cou].d prevent the SSD<,;

from even delivering the data. 'The SSDS is dependent on being

able to read the source application ID, for example.

If the packet formats are implemented as required SSDS standards,

then:

the SSDS must certify that the payloads are in fact formatting

the data properly

the SSDS may cons:[der providing source code to do the formatt:i.rlg

of the customer data

4-15
Accordingly, it is recommended that the telemetry formats (present or

modified) be adopted as SSDS standards. The only technical impact occurs if

the telemetry standard is implemented as a transport level standards. In this

case, it would be implemented in the NIU. This would also mean that the

packetization would no longer be done by the payload but by the SSDS.

However, instead of being done by a central gateway (as discussed previously)

the telemetry packetization is being done in a decentralized manner.

2.3 What Standards Should Be Used?

We consider standards applicable to three major areas:

o Flight segment local area networks

o Terrestrial local area networks

o Terrestrial wide area networks

This differentiation is essentially driven by limitations of underlying data

transmission media and switching equipment. More uniformity of standards is

feasible in the flight segment LAN's while a diversity of standards must be

tolerated in terrestrial LAN's. Bandwidth contraints and limitations of

commercially available switching equipment are significant constraints for the

terrestrial WAN's and LAN's while realiability and availability of

space-qualified hardware are more significant constraints for the flight

segment LAN's. Although higher-levels of the ISO/OSI model are important,

standards are still poorly developed and we concentrate on the first few

layers (physical, data link, network) in this section.

The TDRSS and direct user links essentially are noisy gateways between these

networks. The design of these links is driven both by the limitations of the

underlying physical links and requirements for protocol translation. Needs

for user transparency, efficient high speed protocol translation, and eventual

migration of ground functions to the flight segment, dictate that these

standards and related addressing conventions be as uniform as possible across

all three sets of network components.

4-16
2.3.1 Flight Segment Local Area Networks

A major tradeoff for flight segment LAN's is in physical media, in particular

whether fiber optics should be used in place of traditional coaxial, twisted

pair, or multiline electrical bus structures. Use of Fiber optics for space

segment LAN's has a number of advantages, including Feasible bandwidths of up

to 10 gigabits/second and immunity to electromagnetic interference. However,

there are a number of disadvantages. Feasible topologies for fiber optics

LAN's are pretty much limited to star and token ring configurations. This

limitation will probably continue until research in methodologies for tapping

fiber optics cables leads to new connector solutions. Unfortunately, there

are no widely accepted standards for fiber optics bus protocols and it seems

likely that NASA will have to create its own (e.g., the Goddard FODS system)

or use a military standard (e.g., MIL-STD-1773).

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

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

include multiple physical link protocols united by a common data link protocol

(IEEE 802.2) or (2) the ANSI X3T9.5. Although the collision sense and token

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

constraints of flight hardware and the bandwidth requirements of the SSDS, the

data link protocol provides the definition of a critical layer of the flight

segment LAN which will make ground and flight segment application transparency

feasible in the later phases of the Space Station program. Alternatives

include use of variants of current avionics system buses (e.g., the MMS bus or

MIL.-ST-1553). The critical element of this tradeoff is the support of a

common set of ground and flight segment protocols which is likely to

substantially simplify development and network simulation activities, provide

a more uniform development environment, and lay the basis for migration of

ground segment functions to the Flight segment.

4-17
2.3.2 Ground Segment Local Area Network Standards

The ground segment LAN structure is likely to be significantly less uniform

than the flight segment LAN. The IEEE 802 family again seems to provide the

most straight forward set of solutions, since they provide a broad set of

physical link layer solutions, and have been implemented on most major

vendors' processors. The IEEE 802.3 protocol (Ethernet) provides adequate

bandwidth and response characteristics for workstations, while the IEEE 802.4

token but protocol provides a more predictable response pattern suitable For

control networks. Additional physical layer protocols (e.g., fiber optics

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

data link layer protocols.

2.3.3 Wide Area Network Standards

The major issue associated with wide area network standards is feasible

bandwidth. A leading candidate for an SSDS wide area standard 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 within the forseeable future. For

example, support of a 50 meagabit/second X.25 data rate with maximum length

X.25 packets requires hardware capable of switching a packet every 20

microseconds, a requirement not easily filled with existing hardware without

extensive use of parallelism. Buffering associated with maintaining virtual

circuits and handling transmission errors at these rates presents similarly

difficult problems.

Alternatives essentially are point-to-point links (such as are currently

provided for high-rate NASCOM services) or circuit switched service. Fhe

weaknesses of these services are their lack of full error correction, and

relative lack of rapid route dynamicism in response to system faults and user

requests for services.

4"18
A major tradeoff for the SSDS thus involves the use of packet standards for

wide area networking versus relatively static switching mechanisms. For

example, links between the White Sands DHC and the Regional Data Centers are

likely to be relatively static and not require sophisticated dynamic or

alternative routing. Circuit switching standards may be appropriate. Another

feasible alternative is to define multiple classes of X.25 services, removing

elements of the X.25 protocol (e.g., dynamic routing or acknowledgement

services) in order to achieve satisfactory performance for high data rates.

This would be more akin to a message switching or datagram ("connectionless")

approach.

The high rate experiments (300 Mp/s) may or may not be sent in this form of

telemetry packets. Wide area standards for this data may be limited to

transport (e.g., statistical multiplexing) as opposed to switching (network)

standards.

4-19
3.O RESULTS

3.1 Implementation Options

The first option (CCSDS packets implemented as an ISO upper layer standard) is

recommended since it appears to have the best fit with requirements and the

most balanced set of impacts. However, some changes must be made to how the

option is implemented.

3.2 How Should Standards Be Implemented?

The telemetry formats (present or modified) be adopted as standards at some

level of ISO structure above the transport layer. This will meet the needs

for programmatic verification of the formats but still meet the full range of

requirements.

The available standards should be selected so that they:

o provide all services, (such as verified vs unverified delivery) in

both directions

0 use the same packet/frame format in each direction (currently the

formats are different for the uplink/ downlink)

o implement an addressing scheme that can be used for either space or

ground

3.3 What Standards Should Be Used7

For the ground segment it appears feasible to adopt an evolutionary approach,

expanding the quality of services as packet switching technology improves. A

distinction between high and low data rate services which 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

4-20
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 service could be

introduced with the net effect of removing the distinctions between high rate

and low rate services.

4.0 Conclusions, Recommendations & Issues

In their current form, none of the options support the following services as

customer selectable options:

o quality of transport service (computer quality vs normal quality)

o delivery service (immediate delivery vs store & forward delivery)

The feasibility of modifying existing standards so that the above services are

supported.

The selection of the wide area network standards is dependent on the detailed

design of the wide area data communications network, which is outside of the

SSDS. The issues discussed in Section 2.3 are drivers to this design and

interact with the design of the SSDS elements.

4-21
V. ONBOARD LOCAL AREA NETWORKING

5-I
ONBOARDLOCALAREANETWORKINGTRADESTUDY

I. INTRODUCT'ION

The purpose of this trade study is to identify and explore the major issues

associated with the Space Station onboard local area network.

1.1 BACKGROUND

A local area network is an information transport system for information

transfer between devices. LANs generally provide high-bandwidth communication

over transmission media. Multiple LANs may be interconnected by gateways/

bridges providing an interconnecting vehicle for a wide variety of

communications devices. The Space Station onboard LAN must provide features

such as high performance, modularity, fault tolerance, and evolutionary growth

capability, all at low costs.

Local area networks basically consist of transmission media, Network Interface

Units (NIUs), and the Network Operating System (NOS) (See Figure 1). The NOS

is also discussed in the Distributed Operating System Trade Study.

The transmission medium of a LAN is the element of the network which carries

the physical signals between nodes. Options for transmission medium include

twisted shielded (TSP) pair, coaxial cable and fiber optics. Concurrent wiLh

the Space Station Reference Configuration Document, this trade study assumes

that the primeLAN transmission medium for the onboard system wi].l be optical

fiber. Optical fiber provides a high bandwidth, highly secure medium for data

communications. However, other media are not precluded for specific subsystem

and payload controlled back-end local LAN's. The 1.7.1.1 Network Transmission

Medium option paper provides media comparisons.

PI_ECEDING PAGE BLAI'_{ NOT FILMED

5-3
[ 'De,." I.ce L!

J

l

I

ORIGINAL F_G:,_ !"3

POOR QUALITY

I OevLce 31I

I

I

O..v,==n]

!

WIU t' I

'Oev:c= _l Oe'.'-ce ]i

, i

t

MEDIA l !

I I

! O.-vt,:,, :* i g,_.,'¢e 4

i =

-x. Contains NOS

FIGURE I. Generic Local Area Network

5-4
Data system components are attached to the transmission media via Network

Interface units (NIUs). The NIU utilizes standard protocols to interface host

devices to other host devices. Host devices are attached to the back-end of

an NIU and can include SSDS standard processors, user-supplied processors,

mass memories, sensors and effectors. Non-homogeneous devices are not

necessarily precluded because an "open system" is a major goal. The 1.7.1.2

Network Interface Unit option paper provides additional background.

1.2 ISSUES

Major issues that were considered in developing alternatives for this trade

study include the following:

i ,

2.

,

4,

5,

6 ,

7.

8.

9,

I0,

11.

Topology - Physical and Logical (star, ring, bus, etc...)

Transmission Medium - TSP, optical fiber, etc...

(baseband or broadband)

Multiple LANs or one global LAN for the Space Station. If multiple,

same or different protocols, data rate, medium...7 What are the

Bridge/Gateway functions?

Performance -The LAN must integrate a wide variety of equipment

types, ranging from sensors with data rates of less than one bit/sec

•to experiments with possibly data r_tes of hundreds of millions of

bits/sec. User data rates are given in the mission data base and

SSDS function-related data rates were developed in TASK 1.

Standardization/commonality - within Space Station and among SSPE's;

can impact maintainability costs

Protocols and end-to-.end compatibility, including use of the

Consultive Committee for Space Data Systems (CCSDS) and the ISO/OSI

reference model.

Media Access Method - Token Passing, CSMA/CD, Laning Poll ....

Connection or Connectionless services

Are voice, video and data integrated onto one network?

What functions does the NIU perform? (versus host?)

Back-end interfaces standards versus subsystem unique

5-5
1,3 TRADESTUDYCRITERIR

Each alternative was evaluated using the following two groups of criteria:

1,3.1 Generic

The generic criteria across ali trades are:

Cost.

- development

- unit

- life cycle

Risk.

- development

- production

- technology readiness

Growth/Technology Insertion Potential.

Standardization/Commonality,

i, 3,2 Trade Stud_. Un_Je

]-he criteria that are unique to this study are:

Environmental Characteristics.

- Radiation Tolerance

- Other Space Qualified Parameters

Performance and Delay Characteristics.

- connectivity

- reconfiguration

5-6
Physical Characteristics.

- weight, power, size

Reliability/Availability/Maintainability.

- fault tolerance

1.4 APPLICABLE OPTION PAPERS

Several Task 2 option papers are applicable to this trade study. The total

list is:

o 1.7.1.1.

o 1.7.1,2.

o 2.1.3

o 2.2.3

o 2.2.5

o 2.3

o 2.4

o 2.5.2

o 2.5.3

o 2.6

o 3.1

Network Transmission Medium

Network Interface Unit

Distributed Operating System

System Growth

System Interfaces

System Security/Privacy

Time Management

Local/Remote Area Communication

Local Area Networks

Network Performance Assessment

Standardization/Commonality

The prime option paper is of course, 2.5.3 Local Area Networks.

particular interest are the first two above, 1.7.1.1 and 1.7.1.2.

Effectively, the subject I_AN Trade Study also covers these areas.

Also of

1.5 ALTERNATIVES

The onboard network trade study will be divided into the nine sections listed

below. The alternatives in each section are also listed.

5-7
(I) Configuration

How is the Space Station onboard LAN configured?

Options: - Multiple LANs interconnected by bridges/gateways.

- A single Space Station LAN,

(2) Standards

If the Space Station network consists of multiple LQNs, should they

ali follow the same standard?

Options: - Single standard for LBNs

- Multiple standards for L_Ns

(3) Topology and Media Access Method

What are the topology and media access method for the onboard I_AN?

Topology Options:

- Star

- Bus

•- Ring

- Mesh

- Star-wired-ring

Media Access Method Options:

- Token Passing

- Slotted Ring

- Register Insertion

- Polling

- Laning Poll

- CSMAICD

5-8
Combinations of the above parameters were evaluated followed by "an assessment

of governmentand industry sponsored technology developments" (Ref.8)

resulting in the following options:

-'Token Ring

ANSIX3T9.5 FDDI

- Token Bus

IEEE 802.4 TokenBus

- Laning Po11Bus (logical)

AIPS

SubACS

- CSMA/CD/TS Bus

FODS

- Langley Mesh

- Others

SAE/AE-gB

(4) Voice/Video

Are voice and video integrated on the data network or handled

separately?

Options: - Voice/Video/Data Integrated

- Voice/Video handled separately from data

(5) Communications Functions

What functions in terms of ISO/OSI Layers are performed by the

communications network?

(6) Network Interface Unit

What functions are allocated and performed by the NIU? Should there

be a less complex NIU for simple I/O devices?

5-9
Options: - OneNIU for all applications (core and payload)

- Less complex NIU for sensors and effectors (core)

- Separate NIU for Customers

(7) Connection .- Oriented vs Connectionless Service

Which type of service best satisfies the needs of the Space Station

LAN users?

Options: - Connection - Oriented

- Connectionless

(B) Back-end Interfaces

How are devices connected to the backplane bus?

(Considered only recognized external connections, no internal)

Options: - IEEE 796

- IEEE 4BB

- IEEE 595

(EUR 6100)

-IEEE 596

(EUR 4600)

- IEEE 683

(EUR 4100)

MIL-STD-1553B

MIL-STD-1773

RS-232

RS-422

Customer Supplied

(9) Protocols and End-to-End Compatibility

2 .0 METHODOLOGY

This trade study incorporated the results of the NIU, Transmission Media, and

LAN Task 2 option papers in determining the major issues to be resolved in

defining the Space Station onboard LAN and the alternatives in each area.

Each of the alternatives was evaluated in order to identify its advantages and

d isad vantage s.

5-10
The advantages and disadvantages were identified through the team experience

base in the data communications field, interviews with experts, and through

literature surveys.

The advantages and disadvantages were then analyzed in terms of the trade

criteria in order to arrive at prioritized options for the onboard local area

network.

3.0 RESULI'S

A summary of all the results in this section is tabulated in a set of decision

matrices in Appendix A of this trade study. The following sections discuss

those results in more detail.

3.1 Confiquration

There are two alternatives for configuring the Space Station communications

system. It could be configured as one large local area network spanning the

entire Space Station or it could consist of multiple LANs interconnect by

bridges/gateways.

One large local area network would provide for easy routing since everything

would be connected to the same LAN. This configuration however, has the

disadvantage of lower reliability. If there is a link failure, the entire

Space Station data communication system could be affected. Another

disadvantage is that changes to the system, such as adding a new node or

reconfiguring it, affects the whole communications system. Also message

delays will generally be larger because there are more nodes contending for a

single network.

On the other hand, multiple LANs interconnected by bridges/gateways would

require more complex routing, but it would be easier to reconfigure. Adding a

new node to a LAN or a new LAN would only affect the local LAN, not the whole

Space Station communications system. Multiple LANs are also more fault

tolerant; if one LAN fails, the other I_ANs are st:ill operational. Mult:ip].e

5-11
LANs would not only enhance security since the payload and core could be on

physically different LANs, but also carry a higher net aggregate overall

traffic rate. Also, local LAN messages stay in the local LAN and do not

impact message rates or'performance on the other LANs. Multiple LANs also

provide easier connectivity for Space Station build-up and allow a lower level

of integration during development and build-up. It is expected that some

grouping of payload sensors will be integrated into a single LAN and thus ease

their attachment to the total network.

Considering the advantages and disadvantages above (summarized in Table A-..I),

the multiple LAN communications system is best suited for the Space Station.

The multiple LAN configuration allows for easy build-up if the system were

designed such that the LANs corresponded to modules. One or more LAN's per

module also meets the safe-haven requirements with each bridge/gateway acting

as an isolator. This multiple LAN approach is basically consistent with the

Space Station Reference Configuration (Reference 5) two network systems ......a

housekeeping (core) network and a payload network.

3.2 Standards

With multiple LANs on the Space Station, should one standard apply to all

LANs, i.e. should they all have the same topology, protocols, etc...? Having

a single standard for the onboard LANs satisfies commonality requirements. It

also allows for a simpler bridge to provide interconnection between the LANs.

Since all LANs have the same protocols, no gateways are required.

This alternative, however, may not be the best solution in the long run. As

the data rate requirements evolve with Space Station growth, a single standard

for onboard LANs may not satisfy these requirements. Also, this may suppress

domestic and foreign customers. If multiple standards were allowed the LANs

could be optimized to meet specific requirements. The costs could also be

lower since commercial standards may be allowed. Multiple standards a].so

allows for technology insertion in growth: new LANs could utilize state of the

art technology.

5-12
However, the multiple standards alternative also has some drawbacks. It would

require more complex gateways to interconnect the LANs. The gateways must

provide flow control and storage since the data rates and protocols may

differ. The necessity for gateways could increase the overall net cost of the

system.

/he advantages and disadvantages of each standard policy alternative are

summarized in Table A-.2.

Each alternative has some advantages. The single standard for LANs provides

the most cost-effective solution while meeting the commonality requirement.

Therefore, at IOC, one standard should apply to ali LANs. This

recommendation, however, does not preclude the use of multiple standards For

LANs beyond IOC. Since future requirements may vary, multiple standards in

growth are the only practical solution. This also allows for easier

technology insertion. As more data becomes available from the customer

community, the need for perhaps a second standard for the payload network

should be studied.

3.3 LAN Topoloqy and Media Access Methods

]he topology of a network determines the manner in which the stations (nodes)

of the network are interconnected. There are many ways to interconnect nodes

depending on the communications requirements, reliabi].ity, medi.um, and

redundancy of the network. The four basic topologies are the star, bus, ring

and mesh (see Figure 2). Variations and combinations of these basic

topologies can yield useful improvements in performance and should also be

evaluated. For a description of the topologies See the Task 2 LAN Option Paper.

5-13
I

I

Star

Ring

BLIS He s h

E

I

I

Figure 2. Basic Topologies

5-14
The active star will not be further considered for primary use on the Space

Station because of its inability to tolerate faults; it relies on the central

node (single point of failure). However a star LAN is not precluded for a

payload user group with provision for a gateway interface.

The manner in which devices gain access to the medium is determined by the

network protocol. Access to the medium may be either controlled or demand

access. With demand access techniques such as CSMA/CD, a node attempts to

gain access whenever it has a message to send. With controlled access such as

token passing or polling a predetermined method is used to award access. The

media access protocol options considered here are:

Token Passing

Slotted Ring

Register Insertion

Polling

Laning Poll

CSMA/CD

The performance, reliability, and complexity vary with each protocol.

description of these media access methods, reference the LAN Option

Development.

For a

Some of these media access methods do not meet the Space Station requirements

as well as the others. The slotted ring, for instance is wasteful of

bandwidth. The register insertion method requires a complex purge mechanism

to discard continuously circulating packets, and the polling protocol has a

high overhead and is not fault tolerant. CSMA/CD is non-deterministic, (the

maximum delay before gaining access to the medium cannot be calculated), has a

low utilization at high loads, and does not allow priorities. Due to the

major disadvantage of these media access methods, they will not be considered

further. It is recognized that other variations on CSMA/CD exist, e.g.,

CSMA/CA (Collision Avoidance) and CSMA/DP (Dynamic Priority). These tend to

be more deterministic, but not as much as a token ring.

5"15
The media access protocol and the network topology are interrelated; not every

topology allows the use of every media access protocol. Since they are

interrelated, they cannot be evaluated separately, and will therefore be

evaluated together. The alternatives considered in this trade study are:

Token Ring

o ANSI X3Tg.5 FDDI

Token Bus

o IEEE 802.4

CSMA/CD/TS Bus

o FODS

Laning Poll Bus

o SubACS

o AIPS

Langley Mesh

Others

o SAE/AE-gB

A description of each is contained in the LAN Option Paper _nd 'Fable I.

lhe advantages and disadvantages of each of the above alternatives are

summarized in Table A-3 of Appendix A.

The LAN speed of each system is not a key factor except for the IEEE 802.4

token bus which typically operates at only 5 Mbps (Ref. 4). This data rate is

obviously too low to effectively meet the Space Station requirements. The

other networks, however, have essentially the same maximum data rate of

approximately 100 Mbps except SAE/AE-gB which has specified the data rate to

be greater than 13.6 Mbps.

5-16
¢/1

U

0s,,--

.4J

G5

u

S,,.

Z

r-..-

t..-..

•,n i _ .-

_ __ o_ "_ ..._

i

_3

_0

-O

r.,4_r_ I_.,_ _

r,,.) (.,-* r,..1 i_' _' O

_"_' _ I_ _ S,,,

i_ _=* ["_ I0

mu_

!

.,.}

Z

_A

,i,J M ,,_

,u ¢p

4v

0

_o

N_ ""=

'_ )4 .._ _

,'-'_ 0 _

i ,-'_ .,._ _ _j

C3

._ ..-,

_ o:_ °=

__ 3 __

°

A

o _

Z

0

0

0

_J

{n

u I_

•,4 Q_

_-, ¢3

,'_ m 00

0 O-'_

O us

I

,.=,

_i_ I

_=

idl "I_

_=_

8.

0._

_U W

,._ W

A

5-17
The cost of the systems does not appear to be a key factor either. The cost

of the standard systems, ANSI and IEEE may be slightly less than the others,

but the difference will not be significant. The AIPS system is proposed for

use throughout the space industry lowering its cost. SubACS is already highly

developed thus, lowering its overall cost too. The FODS system may be

slightly more expensive due to the complexity of the NIU, and the Langley Mesh

may also have a higher cost due to the node electronics. The SAE/AE-9B system

is not well enough defined to be evaluated.

The complexity of the systems vary greatly. SubACS, for instance, has very

complex NIUs. The SubACS NIU contains over Ii00 Integrated circuits. The

FODS system will also have complex NIUs due to the dual modes. The Langley

Mesh may require complex routing algorithms. The complexity of the other

systems is comparable. The complexity effects cost, reliability, risk, and

growth/technology insertion potential. An example of the complexity

variations is the dynamic range problem associated with the number of devices

on a bus.

The complexity of the optical receivers varies as a Function of topology.

Optical receivers have different sensitivity range requirements depending on

the topology of the connecting network. If the strength of the received

signal varies, the receiver must adjust its circuitry to properly convert the

optical signal to an electrical one.

With point to point links such as those in the ring topology, signal strength

varies very little, and simple receivers can be designed. In the linear bus

topology, on the other hand, nodes tap into the network and cause a typical

signal strength degradation of 1 dB. Addition of several nodes in a network

might cause a receiver that does not have automatic gain control (AGC) to

erroneously detect a signal.

A passive star network normally does not have this problem because the loss is

independent of the number of nodes attached to the star. If the number of

nodes that need to be attached is greater than what the system can support and

-the n node star is replaced by an m node star (with m • n), the additional

loss may also require receivers with AGC.

5-18
For this reason, the ring topology has an advantage over the bus and passive

star. The ring's simpler receivers would be lighter, simpler, and more

reliable. The active star generates signals at the central node, so AGC would

not be needed there either. Note that even a receiver with AGC will have some

limitations. A typical sensitivity range with AGC might be 20 dB or more, but

only 2 - I0 dB without AGC.

The fault tolerance/reliability of the onboard LAN must meet the FO/FS/R

requirement. Most of these systems provide some means for fault tolerance.

ANSI allows nodal bypass switches, counter-rotating rings and ring

concentrators. Triply redundant networks exist in the AIPS specification.

The Langley Mesh provides redundant paths as does SubACS. The SAE/AE-gB

system will also provide fault tolerance but the means have not yet been

specified.

However, few of these systems meet the FO/FS/R requirement (RIPS, SubACS and

possibly the Langley Mesh). In order to meet this requirement, the redundancy

of the other LANs must be increased. The ANSI system, for instance, will

operate with one and possibly two faults. In order to guarantee safe

operation after two faults, a third ring must be included, ie. a triply

redundant network. Similarly, FODS provides redundant networks, but to ineet

this requirement a third redundant network would have to be inchded. It is

assumed that a11 systems will be configured with appropriate redundancy ].evels

in order to meet the FO/FS/R requirement.

Consequently, evaluating the reliability/maintainability/availability of the

alternatives requires analysis of the reliability of the components. With the

IEEE token bus, for instance, the failure of a node adversely affects the

logical sequencing of the nodes required for token passing on a bus. The

FDDI, allows wiring concentrators. While providing ease of maintenance and

growth technology insertion, the wiring concentrators decreases the

reliability of the system; if it fails, the connected network could be

disabled.

5-19
The passive star used in SubACS and FODS is also a possible central point of

failure, but since it has no electrical or moving parts, the chances of

failure are much less. While the passive star increases reliability, it

decreases growth/technology insertion potential because of the signal division

amonq the nodes. If the number of nodes (m) that need to be attached is

greater than the number of ports (n) on the passive star, the n port star must

be replaced by an m port star. Passive stars cannot be connected serially due

to the power losses. On the other hand, wiring concentrators in a ring may be

connected serially since each node acts as an active repeater.

The link access performance of the FODS and FDDI systems (ISO Layers I and 2)

were analyzed (Reference 13). Some results are presented in Figure 3. These

two sub-figures indicate that no significant performance differences in mean

throughput and mean service time exist between the two systems. Further

comparisons between FODS and FDDI are shown in Appendix B of this trade study.

A major advantage of some systems is standardization. The ANSI system, IEEE

802.4 and SAE/AE.-gB are a11 (or will be) standards. A system which is a

standard provides a higher growth potential. Standard systems are also

usually lower in cost and risk.

The physical characteristics of these systems are not well enough defined to

be compared. The power requirement for the current SubACS system (300 wahts)

exceed the power specified in the Reference Configuration (Ref. 5). It is

likely that the implementation of any of the other LAN systems with the same

level of SubACS services would require about the same power level (VLSI

technology).

Each alternative was evaluated using the criteria. The criteria were divided

into three categories: Cost, status, and technical. The categories were

a11otted 300, 200, and 500 points out of 1000 respectively. A breakdown of

the categories and points scale follows:

5-20
Jo

_z

FIOO

90

8o

70

60

5o

40

3o

20

2o

/ A FODS

_' 0 Token Ring

I I, ,, 1 ,' ,' I

40 60 80 100 120 140 160 180

Total Offered Load Mbp$ (5 BIUs)

900

3

i:-

:>

80(}

70O

60C

5001

400,

300'

200_

20

-- Legend Z_

A FODS /I

_ O Token Ring _/

I I._ I __1__ I I I.

30 40 50 60 70 80 90 100

Mean Througput Mbps

Figure 3. Performance Comparison for the ANSI Standard X3T9.5 Token Ring and the Fiber Optic Demonstration

System (FODS) Bus Protocols. Network Parameters Simulated Were: 5 BlUs; 2048 Byte Packet Size; 100 Mbps

Transfer Rate

5-21
Cost

Cost

Standardization/Commonality

200

100

300

Status

Risk (Technology Readiness) 200

200

Technical

Performance

Growth/Technology Insertion Potential

Reliability/Maintainability/Availability

Physical Characteristics

Environmental Considerations

I00

I00

I00

i00

IO0

500

Maximum Points I000

The LAN evaluation results are shown in Table 2. Additional data are

necessary to complete the table.

5-22
Z

0

':C

--J

':C

Z

L;J

-.J

==

w')

c.9

z

0g

u'_

a.

Q_

._J

z-rz_

-J

o.

..JP_

(.5

Z_

Zl.-¢

_tQ.

C£Iul

u'; I:Q

,:3

GOZ

uJ ",,"

u.IQ

W.I_-

O_

r_WJ

0

(,9

W.

u_

XZ ,

I--

8

z

z

o

I=-

_>..

Ni---

I--0

,,=,

'.,5 Z

=___

OuJ

2:g:

tJ.Z

I--W.

OuJ

l,-

z

o,,,

++.,_

"p uJ

z

P,_ ioJ

5

Q.

t._ w.J

c3_

Z_I

@

C3Vl

._u3

Z_

)--- I--

u.;w_

@

k,-

z¢)

o_ ___ wO

z

• •

°

Z_

_< ==_

• 0e

z

0

• ee

5_SNN_

@ @e

o

o

x_--

!

I--

z

o _t.u

o_

8

t

J_

==

"%.vl

=z=

•..I Z _-.¢

• • •

o

)..

,+ +

8_o

• @e

_<>

._._____

=_

o

I--

z

F--Qg

(J

Lid

C=

r,_ p.¢

.... j

I--

P.

T_

o_

_z

zo

h- ,

o

r,1 Z

I - - Z

u.J

I

i

- -- -.._ _

i

t(

5-23
After examining the key advantages and disadvantages of each alternative in

Table 2, the highest score was achieved by the ANSI X3Tg.5 FDDI system and it

appears to best meet the Space Station requirements. ANSI X3Tg.5 scores well

across all the criteria, a 15% reduction in each FDDI score would still yield

the highest total score. It is standardized, deterministic, fault tolerant

and has good performance. It handles high data rates (100 Mbps) and does not

require excessively long wiring lengths.

As the Langley Mesh and SAE/AE-gB are defined and developed they should be

re-evaluated ?or possible use on the Space Station in growth.

3.4 Voice/Video

Should voice/video and data be integrated onto the same networks?

If voice and video were transmitted on the same network as data, less wiring

would be required. This would reduce the cost, but more complex hardware

would be required, increasing the cost. The video bandwidth requirements

would load the system and possibly inhibit growth.

Alternatively voice/video could be transmitted on one network and data on a

separate network. This configuration would require more wiring but simpler

hardware since each system would be baseband. Another advantage of this

alternative is that the transmitters and receivers could be optimized for each

application.

The advantages and disadvantages are summarized in Table A-4.

The advantages of separate networks outweigh the disadvantages for application

onboard the Space Station. The electronics for separate networks would be

simpler, better known, and, there?ore, cost less and have a higher

reliability. This configuration also allows for optimization of each system

which will provide better performance.

5-24
3.5 Communications Functions (ISO/OSI)

The functions performed by a communications system can be described in terms

of the ISO/OSI model. The Open Systems Interconnect Model consists of seven

distinct'layers each performing at set of unique functions. The layered

architecture provides flexibility in revising the system. As long as the way

information is passed between the layers is not affected, only the appropriate

layer needs to be altered to implement the change. This provides the ability

to continuously incorporate new technology into the existing system,

The ISO/OSI layers and the possible functions performed by each layer are

shown in Table 3. Some layers or some functions designated to a particular

layer may not be present in some systems. For example, negotiation for

character code conversion (presentation layer) would not be necessary if all

systems used the same character set. If the need arises, functions or layers

not initially present could be added. Similarly, the Space Station onboard

local area network may not require a11 of these functions. In order to

provide a high performance system at the lowest possible cost, only the

necessary software services should be provided at IOC. The hardware should be

sized at IOC so that other software services may be added when necessary as

the system grows. The ISO/OSI functions and their classification of present

at IOC or possible incorporated in growth are shown in Table 4. The growth

column entries in Table 4 are possible services that may be added after IOC.

The column entries in Table 4 represent a collected view among the study team

members and some NASA and other contractor views. It is of note that for I[OC

a null presentation layer is indicated in Table 4 since data compression (if

performed) is assumed to be a user provided function.

5-25
ISO/OSI FUNCTIONS EXPLANATION

7 APPLICATION LAYER

Connection Oriented

-bulk file transfer

-virtual terminal usage

-message handling services

-job transfer and manipulation

-stream oriented access to devices

Connectionless Oriented

-data collection

-outward data dissemination

-broadcast / multicast

-request / response applications

Connection / Connectionless Services

-ID of communicating partners

-Establishment of authority to commun.

-Authorization of intended partners

-Application Layer Management

- This type of communication

involves initial negotiation

of parameters. The following

applications are connectionoriented:

- This type of communication

involves no initial negotiaion of parameters. The

following applications are

connectionless oriented:

- These services are utilized

by both types of data transfer

- management of resources at

this layer

6 PRESENTATION LAYER

This layer provides the means for negotiation of syntax and the need

for the following types of conversion.

- security

- data compression

- character code conversion

- graphics syntax conversion

- presentation layer management

- encryption services

- data reduction

- translating to another

character set

- conversion between

different types of graphics

- management of resources at

this layer

Table 3: ISO/OSI Layers (Part l of 3)

5-26
IS0/OSI FUNCTIONS EXPLANATION

5 SESSION LAYER

- expedited delivery

- multiplexing sessions

- synchronization

•- dialog control

- binding

- quarantine service

- activity management

- session layer management

i

- a quick pass-through for I

time-critical data I

- time division multiplexing data I

- synchonization points in data

- who speaks, when, how long,

half or full duplex

setting up the session

between two entities

- provides the means for two

communicating entities to pass

blocks of data and to agree, in

advance, how many blocks are to

received collectively before an

are transferred to higher layerl

- allows user to break dialogue

into discrete activities which

can be suspended,resumed,begun

- management of layer 5 resources

4 TRANSPORT LAYER

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

- management of connectionless

service

- management of connectionoriented service

- breaks/assembles messages into

smaller units (segments)

- assembles segments in proper

order

- grouping of small messages into

one packet

- monitors errors in transport

header

- multiplexing data streams

- a quick pass-through for

time critical data

- indicates to host loss of

info. due to subnet crash (i)

- prevents data from arriving

faster than receiver can

handle it

- checking for errors

- converting logical addresses

to physical addresses

- converting to connectionless

or connection-oriented service

- management of resources at

this layer

Table 3: ISO/OSI Layers (Part 2 of 3)

5-_
ISO/OSl FUNCTIONS EXPLANATION

3 NETWORKLAYER

- routing / switching / relaying

- congestion control

- packetization / reassembly

- sequencing

- header error control

- quality of service maintenance

- expedited delivery

- error control

- network layer management

- determines which path to send

the packet on

- regulates flooding within the

network

- breaks data into packets and

reassembles them

- arranges packets in proper

order

- monitors errors in the network

layer header

- monitors error rates

- quick pass-through for time

critical data

- error checking

- manages resources at this

layer

2 DATA LINK LAYER

- framing

- error control / notification

- media access

- flow control

- data link layer management

formats data into frames

- error checking

- obtaining control of the

media in order to transmit

- prevents data from arriving

faster than the receiver can

handle it

- manages resources at this layerl

I PHYSICAL LAYER

determined by medium - the mechanical, procedural,

and electical interface to the

medium

Table 3: ISO/OSl Layers (Part 3 of 3)

5-28
ISO/OSl FUNCTIONS lOC GROWT

layer

7

application

presentation

5

s e s s ion

Connection Oriented

-bulk file transfer

-virtual terminal usage

-message handling services

-job transfer and manipulation

-stream oriented access to devices

Connectionless Oriented

-data collection

-outward data dissemination

-broadcast / multicast

-request / response applications

Connection / Connectionless Services

-ID of communicating partners

-Establishment of authority to commun.

-Authorization of intended partners

-Application Layer Management

This layer provides the means for the

negotiation of syntax and the

following types of conversion.

- security

- data compression

- character code conversion

- graphics syntax conversion

- presentation layer management

- expedited delivery

- synchronization

- activity management

- binding

- quarantine service

- dialog control

- session layer management

Table 4: ISO/OSl Functions (Part l of 2)

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

5-29
ISO/OSI

layer

4

transport

3

network

2

data

Iink

1

physical

FUNCTIONS IOC

- connectionless management

- connection management

- segmentation / reassembly

- blocking / deblocking

- header error control

- data multiplexing connections

- expedited delivery

- sequencing

- flow control

- error detection / control

- address mapping

- service type conversion

- transport layer management

- routing / switching / relaying

- lifetime control

- congestion control

- segmentation / reassembly

- sequencing

- header error control

- quality of service maintenance

- expedited delivery

- error control

- network layer management

- framing

- error control / notification

- media access

- flow control

- data link layer management

determined by medium

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

x

i

GROWT 1

I

l

x

x

x

x

x

x

Table 4: ISO/OSI Functions (Part 2 of 2)

5-30
3.6 The NIU

The Network Interface Unit (NIU) is a device that acts as a communications

controller to provide data transmission to one or more attached devices

(subscribers). This NIU transforms subscriber data rate and protocol to that

of local network transmission medium and vice versa. Data on the medium are

available to all devices.

The NIU can function as a gateway (providing interconnection of multiple

networks that use different protocols) or as a bridge (providing

interconnection of multiple networks that use the same protocols). The uses

of an NIU in a communications network are shown in Figure I. The functions

performed by the NIU depend upon what ISO/OSI layers are contained in the

NIU. (Refer to Tables 3 and 4) One view consists of seven layers in the NIU

(shown in Figure 4a) for software portability reasons. Another view,

described below, consists of four layers in the NIU (Figure 4b). Further

study is needed in this area to determine the optimum configuration.

There are two categories of application layer service e].ements: Common

Application Services Elements (CASE's) and Specific Application Service

Elements (SASE's). "Common Application Service Elements provide capabilities

required by application processes for information transfer independent of the

nature of the application (e.g., setting up an association between application

processes, terminating an association between application processes).

Specific Application Service Elements provide information transfer

capabilities (e.g., file transfer, data base access, job _ransfer) or

capabilities to satisfy the needs of particular application processes."

(Ref. lO) In Table 3, CASE's correspond to "Connection/Connectionless

Services," and SASE's correspond to all other connection oriented and

connectionless oriented elements.

Since the SASE's serve specific application processes, these functions should

be provided in the host system. CASE's, on the other hand, are utilized by

all applications processes for information transfers. CASE's should also

reside in the host. This allows for the initialization of the association

between _pplications processes to be done in the device in which the

application resides.

5-31
The presentation layer provides the means for negotiations about the syntax of

information transfers. Where the syntax is incompatible, mapping must occur.

The actual mapping process, however, does not take place in the presentation

layer, but in the SASE category of the application layer. The presentation

layer, therefore, provides the means for syntax negotiations between

communicating entities using different syntax. Since common hardware and

software will be utilized as much as possible on the Space Station,

incompatible syntax will rarely occur. The presentation layer should,

therefore, reside in the host.

The session layer can be viewed as "the user's interface into the network"

(Ref. 5). The session layer provides services such as checking the user's

right to access the destination and collecting groups of messages so that none

are delivered until all have arrived. These services are performed for (_ach

user requiring them. When more than one device is attached to

the NIU, the presence of the session layer in the NIU would unnecessarily

limit the throughput in order to provide these services for each attached

device. On the other hand, if the devices perform these functions, several

messages could be handled simultaneously (one per device) at this layer. This

layer should, therefore, reside in the host.

Unlike the session layer, the transport layer is not user oriented, but

provides the end-to-end communications connectivity of the network. Funct'Lons

such as segmenting messages, multiplexing, and flow contro], are performed.

This layer performs standard communications functions and should, therefore,

reside in the NIU.

The network, data link, and physical layer are concerned primarily with

routing, media access and the physical connection to the media respectively.

These functions are clearly communications functions which should be performed

by the NIU not only to alleviate the loading of the host but also to provide a

standard communications interface. (See Table A-5)

5-32
The division of layers between the host and NIU at the transport-session

layers (shown in Figure 5) provides the network transparency, i.e., the host

need not be aware of the network topology and protocol. This allows for

standardization of the NIU hardware and software. Since the NIU would handle

all of the communications protocol, it could support simple digital I/O as

well as intelligent hosts. This configuration of the NIU is also functional

as a gateway/bridge, which would require only layer 1-3.

7 Application

Resident in

Host

7 Application (Case)

6 Presentation

5 Session

4 Transport

3 Network

2 Data Link

1 Physical

Resident

in

NIU

Figure 4a. Option 1 for Division of Layers Between NIU and Host

5-33
RESIDENT

IN HOST

7 APPLICATION

6 PRESENTATION

5 SESSION

RESIDENT

IN NIU

!

4 TRANSPORT

3 NETWORK

2 DATA LINK

1 PHYSICAL

Figure 4b. Option 2 for Division of Layers Between Host and NIU

5-34
ORIGiNPJ.- =_:_" r _..._ _ _'_'" _J

POOR QUALrri

r- 0 }.-,

•"_ _ _ m - _ _ _ 0

.._ L) t'h,_r) 7__ c_ r.L, bj

o

r-j_ ,.--.

t-'-. ,_.

>.-.

Ca ",'_ E C

:>

,,<

w.1

E--,

0

cO

{.-,

©

-'t

_- rh 0

o _. _ _ _

cJ Ca_ _a-_

c0

_,_'_ 0,-_

¢._ _ L.)_--..I .L) O.,-I

_, bO,-_ _::_0 _.._

o _ _

rj)

.<

o_-

_cUl_

o

¢J

o"0

I_ o

r.,.1 C3 Fi(_ure 5 _ I.(.;O Transport Layer AJ.ternatives

5-35
The NIU shall also time-stamp all messages. This is further discussed in the

Time Management Task 2 Option Paper 2.4.

3.7 Connection Mode

There are two alternative modes of connection for networks,

connection-oriented and connectionless.

Connection-oriented service involves the initial setup of an association

between the parties involved before actual data is sent. Once the association

is established, it is held for the duration of the transfer.

Connection-oriented service "allows for negotiation of parameters and options

(such as grade of service). It provides a context for sequencing and flow

control of transmitted data units, and it has a clearly distinguished

lifetime" (Ref. 3, p. 15) Connection-oriented service provides the

advantage of preallocating resources. At transfer initiation, if the

resources are not available the message is not sent. This, however, requires

more overhead than connectionless service in order to initialize the

transfer. Connection-oriented service also allows for error detection and

retransmission requests earlier than connectionless service (because

sequencing can be done in layer 3).

Connectionless service requires no negotiation of parameters at the time the

service is accessed. Each party has "knowledge of the parties with which it

may communicate" and "has the explicit knowledge of the characteristics of the

service it can expect to be provided with each invocation of the service"

(Re?. 7) Each unit of data is independent and self-contained.

Connectionless service uses less bandwidth since there is no initial transfer

setup. Another advantage is that connectionless protocols are simple to

implement. Error control and sequencing must be provided at a higher layer

(layer 4) since each packet is sent independently. This however, should not

be a major disadvantage on Space Station since the LAN will provide a robust

transmission medium. (The advantages and disadvantages are summarized in

Table A-6)

5-36
Connection oriented service at the Data Link layer implies sequencing and

error control at this layer. Due to the robust nature and low bit error rate

oF the transmission medium, these services need not be performed at layer 2,

but can be provided at a higher layer (layer 4). Therefore, connectionless

service at the Data Link Layer will provide reliable yet efficient

communications at this layer.

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. When routed, each

packet of a message follows the same path. Each packet transmitted through 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 shown in Figure 5, Class 4 will provide timely and reliable data

transfer for mission critical data. The functions available with Class 4

service 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 segmenting and Flow

control, may be satisfactory for sensors with over-sampled or perishable

data. For voice transfers, Class 2 should also be adequate since humans can

compensate For minor transmission errors. OfFering two classes oF service at

this layer may, however, may be more inefficient than only offering the more

reliable Class 4 service due to the greater software complexity oF oFFering

two classes of service. The Class 4 service proposed by NBS may be more

suitable as it supports both connectionless and connection-oriented Transport

service. The current development oF NBS standards For the Transport Layer

should be Followed For possible application to the Space Station.

The session, presentation and application layers support both connection and

connectionless service in order to provide uniform service across these layers.

5-37
A connection-oriented session layer allow for preallocation of buffers. If

the buffers are not available the transfer can be suspended at these higher

layers. A connection-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.

3.8 Back-End Interfaces

How are devices attached to the NIU or SOP (Subsystem Data Processor)?

There are many standard external interfaces, parallel and serial, currently

available. The interface alternatives include:

Parallel Interfaces

NTDS, Navy Tactical Data System

IEEE - 488, General Purpose Interface Bus

Serial Interfaces

RS-232

RS-422

MIL.-STD-.1553B

MIL-STD-1773

MIL-STD-1773 (Additions)

Other Commercial/Spacelab

(CAMAC External Interfaces)

IEEE.-595

EUR-6100

IEEE-596

EUR-4600

IEEE-6B3

EUR-4100

5-38
CAMAC is Computer Automatic Measurement and Control

The above alternatives for back-end interfaces are characterized in Table 5.

The advantages and disadvantages of each are summarized in Table A-.7 in

Appendix A of this study. The Spacelab set is not tabulated in the table but

are obvious candidates particularly for payload customers.

The NTDS interface is used in many naval systems. This interface protocol

requires a large amount of overhead with handshaking after each word. Because

it is tailored to navy tactical devices requires large bundles of wire, _nd

has high overhead, this interface should not be used on the Space Station.

The IEEE-488 interface is widely used with commercial test equipment.

Asynchronous transfer is allowed with handshaking after each byte. Because of

its wide use and relatively high data rate (8 Mbps), this interface could be

used on Space Station but a serial interface would provide the same

capabilities over longer distances with less wire and less overhead.

Of the serial interfaces, RS232 and RS422 are used to allow interconnection of

terminals, computers and peripherals to telecommunications equipment. These

interfaces have limited length and require multiple lines. RS232 also has low

data rates.

The MII..-S]I)-I553B, on the other hand, operates at 1Mbps, has no specified

maximum length (determined by cable length, number of terminals and number of

stubs), and uses only one wire. This is a military standard used for avionics

systems and supported by commercial vendors. It is well defined and should be

able to accommodate a large number of sensors and effectors as well as

standard data processors, etc...that will be used on Space Station. A 1553

like interface is currently in use on the Shuttle (MIA).

MIL-STD-1773 (planned release date end of 1985) specifies the Fiber optic

version of MIL-STD-1553. ]his interface could also be utilized on Space

Station, but the 1773 provides no benefit over the 1553B interf_ce.

5-39
tnucmu

r_

Z_ ZZ

X_ X_

_ z_ z_ _ Z_ Z_ _ ZZZ ZZZ _ Z_ Z_

Z___

_ e,,,e.e I---

,_ "___ &.el

•r-)--_ ,,, l.,J

).-, r,..3 _. I" me.

XZ

,_ i._.l0 t.n0

_r_.l I.N ,.--

L.J

I--"

Dg

I.k.

(/) Z

,v

I--

I--

g=Z

,'_w0

C_ D. r,1

gr U')

Og

W_ Og

a-u; ,"Q.

t.J

ajar"

_"_ 4-)

,-_

.,_

_.l_ _.- f--

tit

a.

EEE

oou'_

ooP-

(MP- i

.Q ..a ._

o_f--

z_ z_

w_ w_ E

z_ z_

_z _z

z_ z_

_z _z _ _-

,,-,, ,.-t

laJ l.¢J

i--4 i...4

i-=i N.=I

I.... I.,J I-. ,.,

oo. _" z r,/') ZU')

tat

_. g3.

r.--

ZZ

EXX

_Z _Z _Z

_Z _Z _Z

l.iJ I.i.I

I ,'__

c) l_l I.i. I.i.

_.._ I._I_

(_ ,", (_o..

,-- zu') ZU')

_._ (_1 ,v 01

_(/1 Ch

C:) "_ ,_

"_0

_r-. "-_ U') U')

C_

-r"

InW

*-t 3

I'--

(%1

(")

-JW

--J

..J

r,-

O.

I'-

I--I

OO

-JW

.-I

..J

r_

O.

..J

Og W

(/1

t_e W

(/)

....I

I--4

r_W

U')

I W

,,.v.

_=I ILl

,':[ U') O::

iJJ

I-- )-- U'I

O. >-Z

._/ r_

Z "-' ILl I--"

_.-JZ .--I

l'-- Z

CO

CO

,q-i W

IJ.J

IJJ

1-.4

(_J

('9I

U')

f_

,,q-I

¢/I

,v

I

,...,

..J s._

I",--

I--

G,')

._I P..-

t.-4 r.....

=I[ ,--

w_ w_ w_

w_ w_ w_

5-40
Z

<

.._I

O9

O

O

O

(.)

o9

A

I.:.

G.) "-_

Zc,._

L m .--J

v

vB (,3

.oQ._

C) CJ ,-,.,

C_L_

Figure 6: CCSD_

oz,_

•---, G,) L._

COL->-

°<_<,

[_o

_9__

v

and ISO/OSI

EU_rc

'u_ ---"

to9 c

to.c:

(0O

0

5-41
Additions to the 1773 standard are currently being developed which would

encompass a dual speed standard, 1Mbps for control and I0 Mbps or 20 Mbps for

data transfer. The development of these additions should be followed for

possible use on Space Station.

The Spacelab CAMAC interfaces of Table 5 represent the best example of current

technology interfaces that have been used and are available for potential

payload use on the Space Station.

The development of the Langley Mesh and the SAE/AE-gB network should be

followed and perhaps re-evaluated For possible application to the Space

Station Program.

It is recommended that voice and video not be integrated with data on the data

network. The cost and complexity of the hardware components currently

available prohibits a completely integrated system. However, as this

technology develops, it should be further investigated.

The Network Interface Unit (NIU) shall provide standard communications

functions at IOC. Two options for configuring the NIU were identified. One

option is ISO/OSI layers 1-4, residing in the NIU, and ISO/OSI layers 5-7,

which are application dependent, resident in the host, thereby allowing the

NIU softwarehardware to be standardized. Another option is to have seven

layers in the NIU_ Layers 1-6 and Layer 7 CASE. This option provides

flexibility in growth since a minimum amount of software would be ported to

heterogenous processors. Further study is required in this area to deterlnine

the optimum configuration.

As a result of this LAN study, there is no evidence that, once interface

standards are established, custom interfaces for payloads could not be allowed

if the existing standards are met.

Connectionless service should be provided at the network and data link

layers. At the transport layers, connection-oriented service should be

provided. The upper layers should support both types of service. As the need

arises, the software services in the NIU can be modified and expanded. This

allows For reliable, efficient data transfer.

5-42
The MIL-STD-1553B serial interface is recommended for use on the Space Station

for the back-end interface to the NIU/SDP where long distances are required.

This-interface will provide 1Mbps data transfer over a single serial

channel. It is a military standard and is widely used in avionics systems.

If desired, MIL-STD-1773 could be used.

The IEEE-4B8 parallel interfaces also provides an alternative for a non-serial

interface to the NIU.

The interface set, used in Spacelab (Table 5) are also available candidates

for Space Station.

It is recommended that the Space Station onboard LAN conform to the ISO/OSI

model. Telemetry packets (CCSDS) shall be transferred through the onboard

local area network in the same manner as other data.

5-43
3.9 Protocols and End-to-End Compatibility

Telemetry should follow the CCSDS standards (See Standards Option Paper).

These standards specify a CCSDS telemetry frame.

The telemetry packet shall be formatted in the host machine. An ISO/OSI layer

7 process which forms telemetry packets shall be invoked by telemetry

messages. The telemetry packets will then appear as data to the network

ISO/OSI layers 1-6. (See Figure 6)

At the communications gateway the ISO/OSI headers (1-6) shall be stripped off

and the telemetry packets shall then be formatted into telemetry frames for

transfer to the ground.

4.0 Conclusions, Recommendations & Remaininq Issues

Multiple local area networks interconnected by bridges/gateways is the most

suitable configuration for the Space Station onboard network. This provides a

highly reconfigurable system which would potentially handle more data. The

multiple networks should ali conform to the same standard at IOC, but multiple

standards should be a11owed beyond I0C for technology insertion.

Of the systems currently defined, the ANSI X3T9.5 Fiber Data Distributed

Interface (Token Ring) best satisfies the Space Station requirements For

performance, reliability/fault tolerance, and standardization. This system

has a high growth/technology insertion potential. The cost and risk

associated with the ANSI X3T9.5 FDDI should be relatively low since this is a

proposed standard.

5-44
5.0 REFERENCES

1 •

Ross, Floyd E. and R. Kirk Moulton. "FDDI Overview - A I00 Megabit per

Second Solution". Towards a Complete Fiber Optic LAN - Part 1: The

System Issues, Wescon 84.

2. Berry, David. "Standardizing Upper Level Network Protocols"

Design, February 1984.

Computer

.

Computer Technology Associates. "Computer Networking Study - Subtask 2 ....

Technical Report". Prepared for McDonnell Douglas Astronautics Company,

February 5, 1985.

4. Graube, Maris and Michael C. Mulder.

October 1984.

"Local Area Networks". Computer,

. "Space Station Reference Configuration Description". NASA Lyndon B.

Johnson Space Center Systems Engineering and Integration Space Program

Office, Houston, Texas August 1984.

6. Myers, Ware "Toward a Local Network Standard" IEEE Tutorial: Local

Network Technoloqy 1982.

7, International Standards Organization/Open Systems Interconnect. "Protocol

for Providing the Connectionless Mode Transport Service Utilizing the

Connectionless-Mode Network Service or the Connection Oriented Network

Service". Telecommunications and Information Exchange Between Systems

ISO/TC g7/SC16 N.2oog Draft Proposal Project 97,6.37.

8. "Space Station Data Management System Analysis/Architecture Study".

Statement of Work May 20, 1983.

9. Tanenbaum, Andrew S. Computer Networks. Prentice-Hall, Inc. Englewood

Cliffs, New Jersey, 1981.

5"45
REFERENCES (Continued)

I0. Bux, Werner. "Local Area Subnetworks: A Performance Comparison". IEEE

Transaction on Communications, Vol. 2g, No. 10, Oct. 1981.

II. "Hart Requirements for the SAE/AE-gB High Speed Data Bus"

Subcommittee, Issue #1, December 14, 1983.

SAE/AE-9B HSDB

12. Murray, Nick. NASA Langley Research Center, Hampton, Va.

13. "Spacecraft Communication and Data Management", MDAC Independent Research

and Development (MDAC Internal), February 15, 1985

14. "SuBACS Distributed System Data Bus, External Audit PDR. IBM, May 2-6,

1983.

15. "AIPS System Specification", The Charles Stark Draper Laboratory, Inc.,

Cambridge, Mass. NASA-JSC NAS9-16023

16. "Local Area Networks: A Review". IBM, First Edition, September 1983.

17. "MDC Local Area Networks Technology Study". McAuto, 5uly, 1983.

18. Joshi, Sunil and Venkatraman lyer. "New Standards for Local Networks Push

Upper Limits for Lightwave Data", Electronics Press, Advanced Micro

Devices.

lg. Bartolli, Paul D., "The Application Layer of the Reference Model of Open

Systems Interconnection," Proceedings of the IEEE, Volume 71, Number 1.2,

December 1983.

5-46
APPENDIX A: DECISION MATRICES

This appendix provides a set of decision inatrices comparing the alternatives

for configurating a local area network,

A-I Configuration

A-2 Standards

A-3 Topology and Media Access Method

A-4 Voice/Video

A-5 NIU Layers

A-6 Connection Mode

A-7 Back-End Interfaces

5-47
0

4-)

{31

0e--

C

0

U

Z

.J

0p,

0

"G

.°

(_

p,.

-Q

L_

/

<{

2=

0

({

¢=:

2:

0

hi

+÷

II

II

II

++

<

<

L_

<

<

>

<

_0

-.- Q.

+ 4-

Z

¢:

0

_J ._

L _ 0

•-- ._ / 0 E

¢_ 0 0 0 0 0

°_

×

Q.

E

0

0

E

0

.- _.}

_--0

._-_

.___.L

_" 0 _ .-'_

0 O _'- 0

----_JE

000

"¢)0 "_

000000

0

V)

0

P..

E

=

!

5-48
¢_

"CJ

e4_

I

Z

--J

St0

°rQ;

I

Q;

F--

_J

.J

<

Z

0

F-

<

nZ

0

_J

r_

I

I

1

Z

>

<

,,I

<

Z

<

>

<

A

<v

Z

0

(._-

e_

0

°--

0

0

0

tO

°-

e-

°--

0

0

e"

0

>

0

0 0 _.o e"

÷÷

.... A

_0_

0 L

OE_O

0

_-0

0 0

0

°- _

--0

•- 0

O0

0_-00

_Z_.

_- .-- <( .--

C) " .._

O_'--m

_'-- 0--

0 0

4- 4-

Z

•-- O

r0_0

--Z

,--_J

c5-49
+

+

0

e--

.pa

u'J

t.;

*r.-

e-0

e--00

;.... Z

.J

°r--

S.-

rO

c- O

-r--

U';

"5

g4I

p,..

I--

w

__1 Z0

l--

e_00

GO

k_J 0<

m,- >

r_

L_J 0<<>

r_<

A

_0 m-

_J0

<_.--

Z_-

no

,.j r-_ Z0

09_

--i_.J

L_J--

r_

5-50
e,-

0

of=.

S.

CU

4J

tO

°r=.

rO

U

"F_

I

Z

S..

0

or-

¢/)

"3

I

I--"

..J

Z

0

Z

0

hi

e_

E

0

+

I

I

I.I

<

Z

<

>

<

<

<

>

<

V) e"

_0

<1_---

0

Q.

0

0

0

N

N

0

0

_ o

X o0 tO'-

0"--

O0

mZ

0

E

0

0

_.. c'-

r-_) 0

0 >'--

_ m _ I-

_.-- _.--

_---_

_. .

0,. 0 *.._

00

> 0.

+÷

@

¢

0 >

5-51
aJ

>_

ro

z

|

z

,o

x

"Z

tO

O

ot,-

o_

U

Q;

r'_

o°

I

(3.;

f--

J_

tO

h--

bJ

.J

Z

O

<

Z

O

bJ

.+

O=O--O_

W

O

<

Z

>

÷+

00

_J

(.9

H-

.=F

>

<

(/)tWO

Z_-

r,- o

_Jr_

Z

O

00_"

--t_J

i.)_--

bJ--

-- "0

E

_ 4..:

_"O --0

e_ r- _O r_j_

E m E

0"-- -- mC

_- 0 _--

,-_ .- _ _.--

•--0 "_ _- _ C

OC O O

E

"O O_

_OO_

QJQ;O

I o-- t00_

_ 0 0_0"--

_ _.O O --s eO O O

--q)

C'O

O'--

O

O

Q;

m

_o

o_

O---

(J

0

++

_o

o_

i.

_J

Z

X

_J

E

0

(J

0

O;

0

_.--

0 C

m

p,,.

5-52
0

cO

0_

r,,,.)

¢1

¢-

0

0

I

Z

,..J

0_

0

.in

o'1

C,

G

!

w

Z

0

k0

e'_

co

u_

',D

,<

.<

_>

.<

u_

,.-,,

o3

hi

¢D

"<

Z

<

,<

U.JO

Z"--

_-_O

U.2 g0

_.--_

__Jr"_

Z

O

¢O:E

C.D_"-

L_m

_X

o_ 0

o

-- O

UO

_-

_,,

_>

_" 0 "-

•-- _ _,..

o0o

i

i

4-+

>

0

0

E

0

0--

o0

o

_.-

OCOO

4,a

_o

.o E'--

r- 0..'_

"00_ EE

0_'-_0

00000

+ +

c0"0

•- (_)

L

O0

0

0

¢J

o

o

o

5-53
¢n

QJ

¢.;

ro

4-

s..

"o

eL_J

I

C.;

rO

rO

cO

°l,--

tn

"G

(I;

°.

I

.Z3

rO

L.d

Z

Z

C

CO

_.J

Z

in

Lu

Z

r_

¢:_.--

n-(j

W

Z

--L.._

E

O0

++

O0

Z

÷+

0

I i-

.._ _J

(J

0

O_

E

"--_0

_;"0

_o--

O0

a_

0

0

_'_

OJ--- .-- u)

_._ _,._ I _. _

.... __ _ .....

@

OD

O0

bJ

_n

I

r_

I

.J

n_

D,-

r_.

0o

!

oJ

r_

O_

r_

_o

r_-- O0

•- a.: cC_J

OJ

5-54
APPENDIX B

LOCAL AREA NETWORK ANALYSIS

FDDI Token Ring

Performance results for the PAWS FDDI token ring simulation model are shown

below. Figure B.1 represents the throughput and response ttme performance

results for 5 active stations, generating all high prtortty messages, For this

particular model, since all messages have top priority, message transmission is

dependent only upon arrival of the token at a statton- no token rotation ttme

constraint ts applied, However, only one message is transmitted for each token

arrival, thus limiting each stattonts transmission time as well as the token

rotation time around the ring to other stations. Input rates shown are mean

values based on an exponential random process. The response time given is the

time a message waits at the top of its source queue until it is transmitted

onto the ring. The results show that for top priority, a higher throughput

performance is reached with larger data fields, however, response times are

also increased. Overall, the ring utilization ts quite high.

FD_ TOKENR_G _ _M£ PERFORMANCERgSUL_

RESPONS£TME= 11_rr T_E - R£ADYTOTRANS_ T_

5 ACTIVESTAllO_ ALL_ HAV£HIGHP_O_Y

i m.

/

/

/

/

f //

../ /

i- /

.... -.-e.._'o-_'"'_" /_

Figure B.I

FOOlTOKEN RINGI//OPERFORMANCE RI_SULTS

5 Acnv£ STAnONS

ALL ME!;SAGZ_HAVE H_,H PR1o_rrY

_ 4t31D_ml[_ _4m,/1' ItAlI _W UIW_

x ,_e_a .

PAWS FDDI Token Ring Model Performance Results - Scenario i

5-55
ORIGinaL P_ _3

_r POOR QUALMS/

Figure B,2 Involves 5 active stations, all sending 3 prtortty levels of data

wtth information fteld lengths of 1000 bytes, All priority 1 messages from one

station are transmitted upon receipt of the token, Priority 2 and 3 message

transmissions are dependent upon the token rotation ttme,or the present data

load, Service ttme ts defined as a messageWs total queue ttme at a statton

before transmission. This shows that, for low rtng traffic (under 100 Hbps

total input rate), throughput and response performances are very destrableo

However, as the total attempted input rate exceeds 150 Mbps, ring utilization

is overtaken by all priority 1 messages.

-]

FOOlgERVCZ11ME_ R_

SIE:RVIC_11ME= _s)drr TIME- I_ GIE]_ TIME

3 PRCRIWLEVELSO_ O_T_k

5 _cnv£ STAnONS

/

I

: /

/ /

TOTAL AT'I_i_O _ _

,

A pmO_l_ 1

X IqeOIIIl_ 2

I-'I I_011_ $

_B I/O P_RMANC£ RESUU_

3 PRIORITY _ OF DATA

5 ACTIVE STATIONS

' _x +i / SZ --

•ro'rAL A_ INPUT RATE

A PmOC_fl'T t

i',i i,,i_ii_ Sl

TOI_L

Figure B.2 PA_S FDDI Token Ring Model Performance Results - Scenario 2

5-56
Fiber Optic Demonstration System

Figure B.3 shows the performance results for the PAWS FOOS slmulatlon model.

The model contained 5 active stations with polsson input rates and varying

Informatlon lengths for messages. Thls shows that performance of the FODS and

FDDI token ring configurations are relatively close. Again, larger data

lengths receive higher throughput and response times.

FO0$ RESPONSE_ PERFORMANCERESULTS

RESP(:)N_ "nldE= TRANSk_ "I'VE - RF.AOYTO "tRANSiT T]I_

5 ACTIVESTATIONS

IO@'I

eo$_ •

emI_

soo4

_4

/

/

"O

°

../" /

_..-'G'" /a"

--

:I _ ........... _ .... "1-----J'_

A A

el

, , , , , , ,

N N 4110 u I_ /11 II N

laEAN0UIYUT RA11_IN 14PS

c_ caw, g_

_ No_

r_ _m_am

FOOS I/0PErFORmANCE RESULI_

5 ACT_E STATIONS

"7

it°

WF_4NA_ INPUTRA11_IN_PS

w

oo_a_

Q N,a mr_

Figure B.3 PAWS FODS Model Performance Results

5-57
TokenRtng

Calibration curves for the RESQ simulation model of the token rtng Are shown

below in figure B.4. The two curves represent simul'atton and analytical

results. The results show that ring utilization peaks at approximately 50% and

transfer ttme ts relatively low until 45Z utilization where it has significant

increase.

TOI(£NRI_ _TION _

64

1

'1

,J

I,J

I

't Y

DATA UTIJZAT_U •

o 46 byte data packets

o 21 byte header

o 3 byte token

o 10 Mbps bandwidth

o 12 Km total ring length

o 5 usec/Km propogation delay

o 1 5 bit delay per node

o 3 byte delay per message

o iO nodes

o All nodes have equal priority

o Non-redundant configuration

o No transmission errors

Figure B.4 RESQ Token Ring Simulation Results

, Carrier Sense Multiple Access wlth Collision Detection (CSMA/CD)

Figure B.5, shown below, are simulation and analytical results for the RESQ

CSMA/CD simulation model. The two calibration curves give a maximum

utilization of only 20% and low transfer tlme up to approximately 18%

utilization. Overall, thls architecture shows poor performance.

m_

44

CS_L_/CDCAL_RAT_NCURVES

N m m m m

OAf&u_ z

L_

o 46 byte data packets

o 3B byte overhead

o 3,47 Km effective cable length

o 10 Mbps bandwidth

o 5 usec/Km propogation delay between nodes

o 100 nodes

o All nodes have equal priority

o 96 byte interframe spacing

o 168 usec delay for retry

o Non-redundant configuration

o No transmission errors

Figure B.5 RESQ CSMA/CD Simulation Results

5-58
Vl. DISTRIBUTED OPERATING SYSTEM

6-I
DISTRIBUTED OPERATING SYSTEM TRADE STUDY

I.O INTRODUCTION

This paper presents the results of a trade study of possible functions of the

Space Station Onboard Distributed Operating System (DOS).

1.1 BACKGROUND

The Space Station DOS is responsible for the management of functions unique to

a collection of devices connected together through a local area network (LAN)

or by a collection of such networks. The DOS will support the autonomous

operation of the onboard data management system (DMS) by providing network

transparency. Operators, customers, and application processes alike

(henceforth collectively referred to as "user") will be able to look upon the

network of many resources as a single entity. DOS will allow users to

communicate with other processes in the network through the use of a layered

communications protocol. The DOS must provide these functions with high

performance, user Friendliness, and evolutionary growth capability, ali at low

costs. Any function, such as memory management or task management, normally

associated with the operating system within a single processor is not

addressed in this trade study.

1.2 ISSUES

This trade study is based upon the results of the task 2 (options

characterization) report on distributed operating systems. As identified in

that report, the issues of concern in designing an onboard DOS are:

i • The management of peripheral resources such as output devices and

f_1_ svstems

The management of memory configurations/loads in processors

PAGE BLA R F;L ED

6-3
3 , The mechanism by which a user accesses a remote resource, whether to

obtain data or to initiate an interactive session with another process

4. The method of obtaining frequently required data5. The network communication protocol

, The implementation of functions associated with a network

communication protocol, such as addressing, congestion control, and

flow control

, The determination of whether a given DOS function should be

centralized, partially distributed, or fully distributed

° The determination of whether a given communication protocol function

should be performed in a host subsystem data processor (SDP) or in a

network interface unit (NIU)

g, Additional issues include monitoring the network for performance and

errors, maintaining a record of network transactions, network

reconfiguration, scheduling commands and functions, and the

verification of commands.

While all the above-mentioned functions are necessary components of the final

system, not all are trade study issues. Issues 2, 3, 4, and 6 are considered

in this report, issue 8 is addressed in the Onboard Local Area Network tra(:le

study, and file management (issue I) is considered in the Data Management

System trade study. The remaining issues will be addressed by the syst_m

definition process (Task 4).

This trade study is concerned only with individual functions and options. Any

determination of whether a given function should be considered as part of Lhe

DOS or" whether it should be an independent application program to be used by

the DOS is left to the System Definition process.

6-4
1.3 'TRADE STUDY CRTTERIA

The following criteria will be used to evaluate options for each of the trade

study issues:

GENERIC ISSUES (common to all trade studies)

I , Cost

o Development

o Life cycle

Risk

o Development

o Production

o Technology readiness

° Performance

o CPU Utilization

o Memory Utilization

o Speed

4. Standardization/Commonality

5. Growth/Technology Insertion Potential

TRADE S"FUDY UNIQUE ISSUES

i. Extent of benefit to a customer

2. Extent of benefit to an operator

3. Extent of benefit to an application programmer

4. Reliability/Availability

5. Maintainability (ease of modification)

6° Effect on network traffic

6-5
1.4 APPLICABLEOPTIONPAPERS:

o

o

o

o

o

o

o

o

1 7.1.2. Network Interface Unit

21.1

21.3

22.3

23

24

25.2

25.3

Data Base Management

Distributed Operating System

System Growth

System Security/Privacy

Time Management

Local/Remote Area Communication

Local Area Network Systems

Of the papers, 2.1.3, 1.7.1.2, and 2.5.3 are the most applicable to this trade

study.

1.5 ALTERNRTIVES

This section will summarize the results of the distributed operating system

options paper by introducing each trade study item and options for same.

(1) Method of Accessing Remote Processes and Data

Should there be multiple methods by which remote data or"

resources may be obtained?

Options: - All remote resources and data are accessed only through

interprocess communication

- Have special access schemes for frequently accessed data

Method of Obtaining Frequent].y Required Data of Remote Origin

- Applicable only if the second option is selected above

Options: - Centralized database of commonly accessed data

- Broadcast of commonly accessed data

- Multicast of commonly accessed data

6-6
(2) Addressing

How do applications specify the address of a process with which

they wish to communicate?

Options: - Flat Addressing (Specify only the name of the process)

- Hierarchical Addressing (address by specifying Net.

[Host or Functions] Process)

- How should address tables be distributed?

Options: - Centralized

- Fully Distributed

- Partially Distributed

If the partially distributed option is chosen, how should

unknown addresses be obtained?

Options: - From a centralized name server

- Through broadcasting a request for the address

-Through a centralized name server, but with the ability

to broadcast a request for the address as a backup

(3) Management of Memory Configuration/Loads in Processors

What is the extent of automated reconfiguration of memory loads in

processors?

Options:

- Automatic load a spare processor in the event of failure in

the active processor,

- Automatically replace less critical memory loads with

higher priority loads when necessary.

6-7
(4) Presentation Layer Services

- Which services are neededonboard at IOC?

Options: - Data Encryption

- Data Compression

- Character CodeConversion

- Graphics Conversion Protocols

(5) Network Protocol Functions

(A) Packet Sizes

- Sizes of packets within the network

Options: - Fixed Length

- Variable Length

(B) Routing

- Should routing tables be dynamically reconfigurable?

Options: .- Static Routing

- Dynamic Routing

•- Distribution of Routing Tables

Options: - Located in all NIUs

- Located at Gateways/Bridges only

6-8
(C) Congestion Control

What is to be done to prevent or handle congestion?

(congestion is the result of an NIU's buffering capacity

being overrun through incoming messages from several

sources)

Options: - Buffer Allocation and Packet Discard

•- Choke Packets with Packet Discard as a Backup

- Connection-Oriented Service Within the Network

(D) Flow Control

What is the method of preventing a transmitting NIU, Host,

or Process from overrunning the receiving capability of

another NIU, Host, or Process?

- At Layer 2 (Flow control between individual NIUs)

Options: - Discard Packets

- Limit Number of Transmissions Per Unit Time

- At Layer 3 (Flow control between source and destination NIUs)

Options: - Sliding Window

- Discard Packets

- At Layer 4 (Flow control between source and destination SDPs)

Options: - Credit Window

- Discard Packets

6-9
2. O METHODOLOGY

This trade study incorporates the results of the Distributed Operating System,

Network Interface Unit, and Local Area Network Task 2 Option Papers in

determining the major issues to be resolved in defining the Space Station

Onboard Distributed Operating System and the alternatives for each such

issue. Additional information not covered by the Task 2 reports have been

incorporated from references 1 and 2 and will be addressed in the task 4

Preliminary System Definition Report.

Each of the alternatives for a given trade study issue were carefully

evaluated in order to determine their advantages and disadvantages. These

advantages and disadvantages were established as a result of the team

experience base at IBM in the area of operating systems, interviews with

experts, and through literature surveys.

The advantages and disadvantages were then evaluated in terms of the trade

study criteria in order to arrive at prioritized options for each issue. The

weighting for each criteria was determined in accordance with the issue under

consideration. The results of this trade study are presented below in section

3.0 and summarized as a set of decision matrices in Appendix A.

3.0 RESULI'S

This section will present the results of the trade study of each of the trade

study issues. For convenience, each of the issues is listed below.

i •

2.

3.

4.

5.

Method of accessing remote processes and data

Addressing

Management of memory configurations/loads in processors

Presentation Layer Services

Network Protocol Functions

6"10
3.1 METHOD OF ACCESSING REMOTE PROCESSES AND DATA

Due to the need for accessing remote resources such as databases and file

servers, it is accepted that some type of Request/Wait/Receive interprocess

communication (IPC) facility will be required as part of the DOS. The trade

issue arises when remote data is considered. Such data may be a sensor value

or value of a variable, for example. For the remainder of this section, it is

assumed that application programs will request data or access to a remote

resource through a set of procedures provided by the DOS. The DOS in turn

determines the actual method of accessing the data or resource.

If the IPC facility is used for accessing all remote objects, be they

resources or data, much bandwidth will be utilized in the form of messages

between requestors of data and owners of same. For data which is accessed on

a frequent basis by several applications, the message traffic can comprise a

significant portion of network traffic. In addition to effects on traffic,

another adverse effect of IPC is the burden placed on owners of data to answer

requests.

In order to overcome these disadvantages of IPC, other means of accessing

frequently required data were considered. While alternatives exist which

could eliminate the need for IPC between a requestor and the owner of data,

such techniques have disadvantages in making the DOS more complex and being

les§ reliable than direct IPC between the processes involved. The trade of

whether or not to have an alternative means of obtaining frequently accessed

data is summarized in Figure i. The results were an alternative method of

obtaining frequently required data.

ALI"ERNAT:I'VES METHODS FOR DELIVERING FREQUENTLY ACCESSED DATA

As the trade study revealed, an alternative method of delivering frequently

accessed data would indeed be beneficial, and alternatives in turn had to be

traded. Three options were found: (1) owners of frequently accessed data

6-11
CO

I--

i,i

Z:

i,i

c_)

,=C

I--

I--

_5 0

oo

hl

llJ

S--

I,I

_J

UJI--"

..J

UJ ""

r"_ UJ

bO

¢--)I./3

I--'0

c:C_J 0

C3

','5"

i.i ¢_)

o.

I--CO

u..

0

bO

>-

-JZ0

I---

LI- 0

i,i z00

I---

I--

i,I

O"

1--

.J

Q-x

i,i

_l.hl

rv" ,._

I_.II.-4

U.,:_

t,l

l--

0---,0

Xl--

.._I[.i.I 0

f.JbO

l--f--

Xt'_

uJOI

C)

I

Q0

I

000

(/)

f--

uJ_

L.I-

>-0

_5

i,i

O:3=

I---0 I

IS)

£.5 Z

¢:C

I-- 00

COr-_ ! 0 I 0

IIII

I

0

I.¢)

I

Q

,.-I

I

0Q

0

eOJ

If) 0

¢.)

r---

OJ

-I

oi--

I,

(/) Z

i.-I 0

I-.i

I--

i--i

00

I--"

l_J -.I

,.J

I.iJ LIJ I I

I-- 0

Z

(..0 0

0_..0

uJO

I--

I.;..¢-)

>.- I.L

f--

,'_ l.l.l

-'1o..

l--O !

I

t/)

00

£.JI

i,i Z0

14-

i,i

Q0

I--

,=_>-

Nl--

,=_ =,-

=,._-

£/) (.J

--J

COI--

Q_

OI--

-r-O_

I'--0

"_- I--

0

ll-- z

Oe_

uJl--

I--_0

x_

0

I--

l--

l..:J

00

i,

0,-_-0

l--l--

uj,-_

_--uJ

xou30

LIJ

0_"

f__--

"I-- C_

U.O

0

01--

I--.£J

hl..J

I--,'_

XO-

>'I--

I'--"_

.--J'=_

(:3 00

I,

I,

I--

>"0 _.I

•..J UJ0

O3

'=_ I--"

I-- _--) .-J

',_ U0

_-- ILl I--

6-12
transmit the values to a central database, (2) data owners of broadcast values

on a periodic basis, and (3) owners of data multicast values, also on a

periodic basis.

Centralized Database of Values

Of the three options, transmitting values to a database has the least promise

of reducing network traffic. Instead of sending requests to the owners of

data, all applications requiring a given value will have to request the

database manager for the data. The only possibility of reducing message

traffic arises if several values are required by each application. In that

case, a single request to the database can return several values at once. The

database approach does offload owners of data from the need to answer requests

for the data. In addition, the cost of development of the database is not a

factor since a database will exist anyway for the purpose of achiving values.

In addition to a large contribution to network traffic, accessing from the

database will be comparatively slower than either broadcast or multicast.

Broadcast of Values

The second option is to have owners of data broadcast values on a periodic

basis. The effect of broadcast on message traffic is dependent on the

configuration of the onboard LAN, the number of applications which require a

particular data value and the location of these applications in terms of the

configuration.

If the onboard configuration consists of a single LAB or two LANs (i.e., one

for core functions and one for payload functions), a broadcast will involve

only two messages at most. If multiple LANs are utilized, such as a L.AN in

every module, the message overhead increases. However, if many applications

require a value, and further, if these applications are distributed throughout

the individual LANs, the message overhead increase of broadcast is negligible.

6-13
A disadvantage of broadcast is that if a given value is required by only

a small number of applications when compared with the total number of

applications onboard the SS, each NIU will have to read in the message and

look at the contents in order to determine if the value contained within is

required by applications running in the NIU or in an attached SDP. If the

number of broadcast values is large, this can result in an unacceptable amount

of overhead.

One way in which this potentially serious overhead may be overcome is to

indicate the contents of the message in a special header field. This approach

violates the International Standards Organization (ISO) Reference Model of

Open Systems Interconnection (OSI) (References 3.-4) by placing information

regarding the contents of the message in the Layer 2 (Data Link Layer)

header. Further, such a scheme may be difficult to implement and maintain as

the special field will have to be read and interpreted by the NIU interface

with the physical medium.

Multicast of Values

The third scheme is multicast of values by the source. This technique

eliminates the disadvantage of broadcast in that a message is specifically

addressed to only those who need it. The disadvantages of multicast arise in

maintaining the list of destinations and in actually indicating all the

destinations in a limited length address field. The latter" problem may be

resolved by allowed addresses to be placed in the data field. This is

particularly feasible as commonly accessed data will occupy only a few bytes

of the data field, leaving much room for addresses.

The results of the trades in this area are summarized in Figure 2. It appears

as if accessing data from a centralized database may be the best choice,

although the bottom line scoring is close for all alternatives. However, it

must be kept in mind that the trade study was performed without the benefit of

actual data concerning the number of applications involved, estimated network

traffic, etc. The actual choice between the options is therefore left until

such data may be available.

6-14
_ZI

II I I

IIIII

hl

I--'

0"'4 Q

I'--4

¢,/)

¢J

t.l.l

0000

_"0_ CO0

0

uJ

I--

C.)

Q

0

O_

_0

OU w_ III_ Oh

II II___

c_0

I-.

i,

l.iJ

i,i

kx..

ILl

UJ l-.-

_t/')

><'--I

14J ¢.J

0

I---

i,

UJ

l.nJ h

Or,"

0

I'--I--"

UJ_

_UJ

xr_

0

I

Q

U

O_

I

0 I OO

133

h-_"

c_

U..O

U_r_

L_

C3lll

I'l .1J

I.-. r'

rl_

"O

q_

4-)

qJ

CT

aJoEEoUo1oO

<3;

_Ju

(J

_J

Idl

6-15
Z0v

I--

i,i

I.--

i,i

.0"

i,i

.-.I Z0

.s- O

u.. 0

"II--

i,i

I.,i.I

L,I.I

I--- z0

i,i

,..-,

I--

I'-"

-.I0

c_

c_

1.1.1 h0

hi

I--" Z0

rl

hi

I

I

w

I

00

_.>..

,-,.0 ._,I

,c¢ ,_]

..J ,,_

I L,I.I

I,..-0

i,i

:Z:: >'- I-- •"_- =_ c,/')

C.,) _.s'),,--4

>.- I.zJ I._J I 00

I--

_0Z

I-- Z

I.iJ 0

--rI--

¢_,,i

i_ -rZ

I-'0

0

0

!

0

C_

I--- =_

I,--. "_ ..l

1,1-I-i.1.,I

_0!

--II,-- 0

I---

In

C_ 1.1.1

1.1.1¢.t) ! m

r_0

e_0ZZ0

I--.

I,.i.I

t.I.

1.1.

t,i

0

O0 000

I,--

i,i 00

.,J

I-- 0

0

v

CxJ

6-16
3,2 ADDRESSING

This category of trade study issues involves three such issues: (a) The method

of addressing employed by application programs, (b) Whether address tables

should be centralized, fully distributed, or partially distributed, and (c)

What is the means of obtaining an unknown address if partially distributed

addressing is utilized.

METHOD OF ADDRESSING BY APPLICATIONS

Two options for addressing by applications were identified. The first is flat

addressing, which provides network transparency by requiring the application

to specify only the logical name of the process with which it wishes to

communicate or the logical name of the sensor or variable whose value is to be

accessed. The second technique is hierarchical addressing, where the

application specifies a logical path to the desired resource. This path may

be specified by NETWORK - [HOST or FUNCTIONs] - [PROCESS, SENSOR, OR VARIABLE]

where function refers to ECLS), N&C, etc. The term HOST is proved as an

alternative since a given process may not be part of a well known function

(e.g., payloads). In both schemes, the DOS assumes the responsibility for

mapping the logical address onto a physical one.

The advantage of flat addressing is network transparency in the eye of the

application programmer. The disadvantages include the need to maintain

globally unique names for a large number of processes, sensors, etc. and the

need for larger address tables. Hierarchical addressing makes it easier for

the DOS to determine a physical address to the desired resource and eliminates

the need for globally unique names. However, the network is no longer

transparent to the application programmer. The results of the trade study oF

this issue is summarized in Figure 3. Once again, both options appear to be

equally good choices.

6-17
0

-.rh-w

_.0 Z

uJ

I-. z0

ILl

0

O_

I---'I

I"-Z

_C3

0'--'*

"" I'--

L...J¢..)

U.IIL

I'--

>--

I--" 0

bOZ

U3

b_0

0.0

LLI

':¢ v

LI.

!

00

i,,bO

.--JI._

l--'Z

bOlaJ

UdC7

r'_Z

r"_ "--J Z

Xl.-i

,,,=_

.--JI--- ! ! 0

UD

I

00

>-0

U.I!0

!

0

u_

Od

LIJ Z

C_Z

>..

..d

.--J

CC_ 0

UJ

L_Z I

0_0

UJZ

t._A

Z

t.IJI._I

C.O ,'_

L_IO.

.--IV') v h-I

UdO

laJ _-" I

OdZ

I.I. 0

l.u;

l-4 0

"-tl--

i.)

0_

bO!

C3

03

Z

--r- 0

I._I1.13

-r" I._

i,i

r..D

r--_Z

1.1.1"r"

Z(,J !I 0

L_

od

0

CO

O0

"0O

r..-

_J

co_..

u'}

Z

i,i

I---

00

0

....I

Or,.D

ZZ

u.:O

l--

u_(.J

_5 k:.l0 ":_

_-¢.j >.,,

_u- I,-O I I I

!

0

°I--

It. 1.1-0

I,.i,.I LI.I I_ Z Z_,.

r'_ r'r_Z >" I""

XO,. >'< _., LI.I_

LI.

I'--

>,-0

I--_ -J

6-18
DISTRIBUTION OF _DDRESS TABLES

There are three options for the distribution of address tables: a centralized

name server, fully distributed tables, or partially distributed tables.

A centralized name server saves memory space in individual NIUs (assuming

addressing is performed in the NIUs) and makes maintenance of address tables

much easier. However, performance penalties include time expended in

obtaining an address and the resulting increase in network traffic as all NIUs

must access addresses From this centralized location. An additional

disadvantage is the cost of the SDP or NIU which is to function as the name

server and the backups (for fault tolerance) of same.

A fully distributed address table means that all addresses of all sensors,

variables, processes, networks, hosts, etc. are stored in every NIU. This can

mean an enormous amount of overhead in terms of memory utilization. In such a

scheme, address updates will be very costly in terms of the network traffic

(update packets and acknowledgements), albeit such updates will not occur

often. A Fully distributed address table presents a great advantage access

speed.

A partially distributed address table is one where each NIU maintains only

those addresses which :it requires. For the general case, this represents the

optimal use of memory to obtain the best access speeds. However, having

partially distributed address tables brings the question "What is to be done

if the local table does not contain a necessary address?". The answers to

this question are the options of the next issue to be resolved.

The trade study of the issue "How should address tables be distributed?" is

summarized in Figure 4. The results of this trade indicate that a partially

distributed address table is the best choice.

6-19
_O

.-J

hbOOZO

hrw

hh-ZO

b-4

D--

r_p

h-

.--I

_J

b-4

l--

r_

IAJ

l--

bO

.-J

..I N

b-4

-JZ

_J

boZ

i-=4 O

r_

LAJ

C_

_J

-J

U.I--

el: _-4

'" I--- I

a.

I-- _/)

O--J

Z_

CD

l---Z

,, ,,,_ II OO

,...'4 O

CD

,.-4

k--

IAJ .-J

_-'(.J

C_ _.._

,,,i,i

>lJ..

,,,,,..4

C_ ..J"

II

I-"-

¢0

I

0

_0

Z

>-

,,1,.i

0.. £.0

_Z

0_..)

hl,,I Z

_..)ZI Q

_.0I

LE)

>-

£.0 0

'_'Z

-r- ,.-,

IAJO

1"-,"4

I--

L.--

I_0

•II

I

0QZ0

I-- N

-J

I--- 0 I 00

C_ 0

I.iJ I.iJ

0.. (..) I 0Q

>-

o.. I._ O. I I I

IAI

¢_)

c_

n."

14.1

_P" f.n

Ou.i

s-., fj'}

I--_

N_•

_: ,_I: l.IJ 0 la. UJ II! 00Z0

I---

N_

I--- ¢=)

!

--J

"_ l.iJ

I._ I--

Wl--- I

l.iJZ

=I= la.l

¢.-) I.--

,,, .-._

n..

C=:l ¢_

,"_ u.i

.-I

-1-_D

,,, ,.-,

II

I._ I._

cI'IZ

W_

Cl_ C:=I

,-.-',Z

_)

ILl,,, !

I

CD0

',_ C) N

____ 1_,

ZZZZ C_l

-J

OZ

_j,,,

Oh-

-r-r_

_J

ud_5

I--0 •.r- L._

__.,,,

0

LI.

0

h-F.-

I-- '.'

XC}.

udO

0

I--

I--

"' I'--

I--- v'l

h-_-" " O

_sr_

_z

CD

I.A._-4

OF--

l--_J

z_-_

,,,..3

xr_

_,- .-I

_'- I,-- ,--,

,-., ..I _:_

,._ _...,,Z

0

-Jl--

,.j ,,I

c_z

_,.,,.

CD

O0

q_

,0

b_

_J

O CO '_O

_.J ',' c-

_-,NO

_- LIJ I-,- _--- Im m ,_

_0

f,_

iT_

O CD O CD

OJ CD

,=.4

_J

bOZ

O '"

hLAJ

O

OZ

h-

(.J ..J

U. h- " O

'" h6-20
METHOD OF ACCESSING AN UNKNOWN ADDRESS

This issue is applicable only if a partially distributed approach is chosen

for address tables. The alternatives for accessing unknown addresses include

maintaining a centralized name server and broadcasting a request for a desired

address. A third alternative is a hybrid a centralized name server scheme

with the ability to broadcast as a backup.

The centralized name server has advantages of guaranteed access to the

address, has potentially less traffic overhead, and is potentially faster than

broadcasting for the address. Disadvantages include the cost of the name

server(s), high memory usage by the name server, the need to keep the name

server up to date, and the remote possibility that the name server(s) could

fail.

Broadcasting a request for the address eliminates the need for an all-knowing

central name server, but is potentially much slower than accessing an address

from a name server. In addition, the formerly mentioned problems of burden on

every NIU to read the message and the message traffic associated with a

broadcast apply. In addition, since broadcasts are generally not

acknowledged, there is no guarantee that the NIU which knows the requested

address ever receives the request or that any reply will reach the requester.

'Fhe hybrid approach is: (1) first attempt to access from a centralized name

server, and if it is not available, (2) then a broadcast request for the

address may be sent. The results of the trade study are shown in Figure 5.

For this issue, a centralized name server or a centralized name server with

broadcast as a backup technique seems appropriate. The former will be cheaper"

to develop, while the latter provides more fault tolerance.

3.3 MANAGEMENT OF MEMORY CONFIGURATION LOADS IN PROCESSORS

This topic was not addressed in the options study. An extended discussion of

the issues is therefore provided.

6-21
I-.

t.,.l

I--

_.I

I--

Q.

V_

t/)

klJ

2_0Z

u')

u*)

I.t.I

£_)

1.1.1

I'-- O

D-¢

¢.=)

LI.I

)-II-=

1,1"--I

u.l-_

¢/_ ,-n

U..I ¢tl

.r,,_

Zl =-

¢/1

,_c.)

ZO

i._ n,*

I-=

U.I

,-v._

I--UJ

c/1 ,-v*

¢=) ,-'_

Qn_

n_u.

I.,J

LIJ

U'}

U.I Z

UJ N

.--I

I--" Z

1.1.1

I-- ZO

nI--

Q::

¢...)

I--- Z

I.ul O

.-I

I.iJ

U=I

r-,

"' I-- ! 0

odI 0

L_J

,_C CX.

Zr-_

0""

OudI 0

030

l---

Zla.l

I._ _.I

.--I

t._ LI3

_I.1.

"--I--.I I ! Q

Z

CO

C3

...J

i.J_"

U.IO

I--

1.;_(.J

>- I./-

I--0

_OCI

I

,J

F_

w

¢.0

_o

C_0

ILlI

C3

LE)

¢.J 0

,_JI00

la.l

>-0

k,3

C.OI0

0,I

C30

03

,._. ,--_

O_

_= u.J _.

_..) "_- v) I I

I

Z

C_

uc_

IJ.I

ZZO

i.-4

_--

N_

,'-I__I

r-_o

h-O

Z

..J

>- _..-

CDZ

OuJ

..dl--

O0

-rbdO

"I-(...)

l..h,

ObO

C_Z

Z0

I---

fla.

25

U.

ILl

h--_--

250

h-- _')

X_

U3C.j

c_Z0

b'-

U.

L_

25 0 "" 0

Lldr_

I--U_

>,_ o,,,

Z

I.LO

_,.Q.

ILl

0

01--

I..13..3

XO.

UJ,_

U.I ._l

Z_

u-Z

_.,_ .--_

"'_ 1.1.1

¢.,j ,._

_u_

r,n ¢._ I

C)

CO

I,.I. U3

Ud,_

I--

Z£-O

r..O ,1_

I--

¢3c_

ZOI

I.n

od

.__.J

ud,_

¢/'_ u3

'"0!

r-..

o_00

>-p.-

c_: ,c¢

I

0

I

0

LI.I LI.I

_"1--

ud_-- 0

l--c_ i o

o30Z

I--

cc_ I--- 0

i-. r_, ! o

ko

o4

ia3

_-c/)

_0

¢.J_0

Or,., i

o,.i Z0

I---

¢..)

I.,iJ

LI.

L.ILIJ

¢,.)

I--- _",

"I',,

¢..51,

_..In,"

bO I,--- I 00

CO

1-...4

13.

i,

r_oZ0

I---

L_

L_d

0

¢0 0

_0

O0 000 m 0Z

I-- 0

(U

b'1

_JQ

ct/)

tn

_J

_J

_J

_3

L_

6-22
The management of the configuration of application tasks both within a single

processor and among the resources of the network is a problem which presents

several opportunities for automation. From the time that application tasks

are initially loaded into the processors of the network, failures,

maintenance, and even entering different phases of Space Station operation may

require reconfiguration of tasks among resources. The most critical need for

an automated reconfiguration facility is in managing redundant computers.

Failures in computers running time-critical applications require that the

switch to a backup be automatic as the applications running in the computer

may not withstand the delay associated with crew or ground controlled

reconfiguration.

Other situations requiring reconfiguration involve the loading of software

either into idle spare machines or into machines in which applications already

reside. Such situations may arise as a result of failures in processors with

no backups or just in the course of time. An example of the later is the use

of maintenance expert system by a crew member. Since expert systems are

expensive in their use of resources, it is conceivable better to load the

expert system software into a processor only when it is to be used. The

decision of where to load the software may be made by the crew member or by

the DOS. It is important to note that any reconfiguration of applications

among processors is meaningful only if the applications have access to

necessary sensors and effectors.

Assuming that the Space Station architecture allocates a pool of processors as

spares, it appears feasible that the DOS be capable of assigning and loading

software from mass memory into such a spare processor as necessary, problems

arise when all available resources are being utilized.

One architectural option is to have fixed memory configurations. The

configurations will allocate certain locations in memory for DOS and other

system software. The remaining locations in memory will be used by

application tasks. Since all processors will contain certain systems

software, the term memory configuration will henceforth refer to groups of

applications tasks to be loaded into a processor at once, with no possibility

6-23
of dividing individual tasks among diFFerent processors. Such configurations

may be amended by an overlay, where a second set of application software

Second configuration) replaces the already resident configuration. If a new

configuration must be loaded into a processor, a Full replacement of preloaded

application tasks is necessary. The task of deciding which configuration is

more important in a given situation may be automated by use of an expert

system or by other means such as priority tables.

The second architectural option is to allow tasks to be dynamically loaded

into processors. This option provides a better solution to the problem of

Fault tolerance (e.g., more flexible) and also has the potential For making

better use of available resources than the Fixed memory configuration scheme.

With this option, if all processors are being utilized and there is a need to

load a new task, then a decision must be to either to (a) Find a processor

which is capable of assimilating the new task without adversely affecting

already resident software, or (b) to partially or Fully replace the resident

software. These schemes require an algorithm to determine where a task may be

moved to, the ability to assign a priority to that task in its new

environment, and a dynamic linking capability. A dynamic task transfer

capability will make verification more difficult since the possible

combination of tasks within a processor will not be predictable. The final

drawback of task migration is the potential inability to meet timing and

jitter requirements due to interference between tasks.

In summary, the results of this trade indicate that the management of the

configuration of application tasks amont network processors will be partially

automated. Certainly, the need to automatically switch to backup computers is

a necessity since time critical Functions may be involved. The choice of a

spare computer into which new software is to be loaded is also recommended For

automatation. The only decision left open is the case when all processors are

6-24
being utilized and new software must be loaded. The extent of automation is

dependant on the architecture which is chosen. The results of this trade

study will be combined with that of potential architectures to determine this

extent of automation. Currently, it appears that the fixed memory

configuration scheme will be the choice of architecture. If this choice

holds, it would mean that an automated decision making capability could be

used to reconfigure the loading processors even when all processors are being

utilized. Of course, a crew or ground override capability must be implemented

to allow manual control in situations where it may be necessary.

3.4 PRESENTATION LAYER FUNCTIONS

The purpose of this trade is to assess which Presentation Layer (6) functions

(if any) will be required onboard the Space Station at IOC. The functions

under question include (1) data encryption, (2) data compression, (3)

character code conversion, and (4) graphics conversion protocols.

The potential need for the functions listed above is based on the requirements

stated in the Space Station Request for Proposal (RFP) (Reference 5). It is

indicated that data encryption is to be provided by the DMS (Paragraph C-3

3.l-O). Further, the need to handle very large amounts of data suggest theft

data compression could be very useful at IOC.

The need for functions 3 and 4 is not clear. The RFP (Paragraphs 2.1.5 and

2.2.5.3-G) indicates that common hardware and software will be employed as

much as possible. Functions 3 and 4 are used explicitly for converting

between non-standard formats. For this reason, functions 3 and 4 have been

chosen as growth items, assuming that the requirements for commonality are

relaxed in time. There may be a need, however, to translate between possibly

incompatible formats employed in onboard and ground systems. For these

situations, it would be much more cost effective to perform such conversions

on the grouhd. The results of this study are summarized by the Fifth decision

matrix in the appendix section.

6-25
B.5 NETWORK PROTOCOL FUNCTIONS

The final area of trade study issues falls under the classification of network

protocol functions. These issues, packet sizes, routing, congestion control,

and flow control, are part of every network protocol implementation. Another

network protocol function, addressing, has been discussed separately. Unlike

the other trade study issues, it is difficult to perform studies on functions

such as routing, congestion control, and flow control without knowledge of

network traffic conditions and the needs of the application programs. For

this reason, an attempt will not be made to select a single implementation

technique for each function, but rather, suggestions will be made as to which

of the options may be appropriate.

PACKET SIZES

The issue related to packet sizes is whether to have fixed length or variable

length packets in the network. Fixed length packets make development and

maintenance easier, but may waste bandwidth and be unfair. If the fixed

length is too high, small messages such as sensor values will waste most of

the packet bandwidth. If the packet length is chosen to be too small, then

long messages, such as file transfers, will have to be broken into many

packets, resulting in longer delivery times as packets wait to get media

access. Variable length packets make better use of available bandwidth and

can be more fair.

However, having variable length packets will make initial development costs

higher. For reasons of growth capability and better utilization of bandwidth,

variable length packets are suggested.

The maximum packet size will be determined once more is known about the

overall network traffic. At present a preliminary value of 2048 Bytes has

been chosen.

6-26
ROUTING

Once a destination address is determined, it is up to the routing function to

determine the physical path which should be taken in order to eventually reach

the destination. In a single ring or bus configured LRN, an address

specifying "NIU_HOST PROCESS" is sufficient for reaching the final destination

as the NIU For which the packet is addressed simply picks it up. However,

when a packet is addressed to a destination in another network, (e.g.,

NET NIU_HOST_PROCESS), a routing table must be consulted in order to determine

the path to reach the destination network. The trade issues associated with

routing include (a) static vs. dynamic routing tables (reference 4) and (b)

the distribution of routing tables.

Static routing tables are those which are determined and loaded into the

appropriate NIUs or SDPs before the network is activated. Such a table does

not change thereafter until an alternative routing table is once again

explicitly loaded (e.g. when reconfiguration occurs). These tables have the

advantage of simplicity and can provide good performance. In addition, it is

possible to construct static routing tables in such a way that alternative

routes can still be utilized. However, static routing tables are not

adaptable with respect to changing network traffic conditions and

configuration.

Dynamic routing tables have the advantage of being adaptive, but require a

more complex DOS and may also cause an increase in network message traffic.

Routing tables may be reconfigured locally or by centralized server. Numerous

schemes exist by which dynamic routing algorithms may be implemented.

Based on the probable ring or bus-connected LRN configuration of Space

Station, the need for routing will be very limited (i.e., routing tables are

necessary only for determining paths between networks). Since the number of

such networks will be small and will not change often, a static routing table

will be sufficient for the needs of SS.

6-27
Distribution of Routing Tables

This issue is the placement of the static tables within the Space Station

network of individual LRNs. Since routing is necessary to determine the path

from one network to another, routing tables should be maintained in every

bridge. The remaining question is whether or not routing tables need to be

maintained in every NIU.

Consider a LAN with only one bridge. In such a LAN, if an NIU encounters a

need to transmit a packet to another network, it may simply forward the

message to the bridge, which then looks up the route to the final destination

and forwards the packet. In a LAN with more than one bridge, a particular

bridge may be designated to forward all inter-network messages. The other

alternative is maintain a routing table in each NIU, so that the load in the

bridges is more evenly distributed.

Since the size of the routing table will be small, placing the routing table

in every NIU will not be extremely wasteful of memory. For this reason, the

choice of whether to place routing tables in every NIU of a LQN with multiple

bridges is left as a design decision.

CONGESTION CONTROL

Congestion is the result of a given NIU's buffer space being overrun by

incoming transmissions from several sources. Various schemes exist for

implementing congestion control (reference 4) including (a) allocating buffers

to incoming packets by the packet's priority, number o? hops traversed by the

packet (seniority), or an a FIFO basis and then simply dropping packets as

buffer space is exhausted, (b) by monitoring the traffic on incoming lines and

as congestion appears likely, sending a message to the sources of the packets

requesting a reduction in the number of packets being transmitted, and (c) by

using connection-oriented service within the network, which prevents

congestion by preallocating buffer space for each message.

6-28
The trade in this area is based on the assumption that congestion will occur

infrequently due to the careful design of the network (i.e. sufficient network

bandwidth, etc.). With that assumption, connection-oriented service (at Layer

4) is suggested for long messages (such as file transfers) while the buffer

discard algorithm may be sufficient for small messages. Note that the latter

scheme requires that end-to-end acknowledgements be utilized. Otherwise,

there is no guarantee that a given packet reaches its destination. The choke

packet scheme will be useful if congestion is likely to occur frequently and

in general, messages are sufficiently long that the source may be requested to

'choke' its transmissions. Since congestion and long messages are not likely

to be frequent occurrences onboard the Space Station, the choke packet scheme

is not recommended.

FLOW CONTROL

Flow control is prevention of a faster NIU, host, or process from overrunning

a destination NIU, host, or process. With this definition, flow control is a

part of Layers 2-4 and the Layer 5/Layer 4 interface of the ISO/OSI reference

model. This section presents options for flow control at each layer as

obtained from reference 6. Once again, more concrete figures for expected

traffic and better knowledge of the needs of the application processes will be

required before effective trades can be performed. As in previous sections,

suggestions will be made regarding the option(s) most appropriate For SS.

Flow control at layer 2 is concerned with transmissions between NIUs. With

the requirements for commonality onboard SS, flow control at layer 2 should

not be necessary as a NIU will likely have matched speeds for sending and

receiving. However, if in growth, flow control becomes necessary, the options

are a discard packet algorithm (flow control at the destination) or to limit

the number of packets which may be transmitted per unit of time (flow control

at the source). If the former is employed in a ring network, very fast

feedback can be provided to the sender by simply modifying a bit in the packet

if it cannot be accepted. Limiting the number of transmissions out of arl NIU

may be helpful in controlling jammed NIUs, but it may be difficult to choose

the optima], limit to provide flow control and yet not unduly restrict the

sending NIU. For these reasons, the discard packet scheme is recommended

instead of the transmission limit scheme.

6-29
Source-Destination flow control is achieved at Layer 3. At this level,

several techniques of flow control exist. These include among others: (a) the

sliding window scheme and (b) the discard packet scheme. The sliding window

scheme is one way of implementing connection service at Layer 3.

The sliding window scheme requires a small number of buffers to be allocated

at the destination NIU, but is an effective means of flow control and

sequencing. This scheme may be used in conjunction with connection service

and is recommended for long messages and critical messages.

Discarding packets is easy to implement, but at layer 3, may be considered to

be too wasteful of bandwidth since a packet may have travelled through several

networks in order to reach the destination. ]"his scheme also implies that the

packet must be acknowledged, otherwise there is no guarantee of delivery. The

discard packet algorithm will be sufficient for messages using connectionless

service.

Flow control at the transport layer (layer 4) may be implemented by at least

two techniques. One method is the credit window scheme, where before

transmission begins, the destination host is contacted and queried as to the

number of packets which may be accepted. This method may be utilized in

conjunction with connection-oriented service at the transport layer. Another

technique, to simply drop packets, may be employed For messages using

connectionless service.

4.0 CONCLUSIONS, RECOMMENDATIONS & REMAINING ISSUES

This trade study has addressed several pertinant issues regarding the

development of a Space Station Distributed Operating System (DOS). The study

has resulted in the following recommendations:

Data Access Method -

Primarily through interprocess communication (IPC),

with commonly acquired data being accessed through a

centralized database, or obtained through broadcast or"

multicast.

6-30
Addressing Choice of flat vs. heirarchical addressing left as a

design decision. Address tables should be partially

distributed, with unknown addresses being accessed

primarily through a centralized name server and

through broadcasting a request for the address if the

name server is unavailable.

Management of

Memory Configuration/Loads in

Processors

Automatic switching to backups, automated loading of

spare processors. Automated replacement of lower

priority loads with higher priority loads is

a possibility if fixed memory configurations are

utilized.

Presentation Layer -

Services

Data encryption and data compression should be

made available if necessary. Other presentation layer

services are null at IOC and may be added as onboard

commonality decreases.

Network Protocol -

Functions

q

Variable length packet sizes with max size = 2048 Bytes

Static routing tables

- Decision of whether routing tables should exist

in every NIU or only in bridges is left as a

design issue.

Congestion control through connection service For

lengthy, critical, and high-priority messages.

Congestion control for other'messages through packet

discarding.

Flow control at layer 2 through dropping packets

Flow control at layer 3 through dropping packets For

connectionless service

Flow control at layer 4 through credit window

protocols for connection-oriented service, through

dropping packets for connectionless service

6"31
A number of issues remain to be addressed in the preliminary system definition

report. Both the Distributed Operating System options paper and trade study

have not dealt with the question of determining which functions should be

considered as part of the operating system and which should be considered as

applications to be invoked by the operating system. In addition, the system

definition report should address the question of division of labor between

SDPs and NIUs and any interfaces between the two. Finally, the system

definition report should present an integrated system composed of the many

individual functions which have been discussed in the context of this trade

study and the options paper.

6-32
5.0 REFERENCES

I. Raymond Turner, "Network Operating System Functional Requirements,"

March 1985

2. Marjory J. Johnson, "Network Control," RIACS TR 84.4, NASA Ames Research

Center, July 1984

3 , Computer Technology Associates, "Computer Networking Study Subtask 2 ....

Technical Report". Prepared for McDonnell Douglas Astronautics Company,

February 5, 1985.

4. Andrew S. Tanenbaum, Computer Networks, Prentice-Hal1, Englewoods Cliffs,

New Jersey, IgBI.

5. "Space Station Definition and Preliminary Design Request for Proposal,"

NASA, September 1984.

6. Marlo Gerla and Leonard Kleinrock, "Flow Control: A Comparative Survey,"

IEEE Transactions on Communications, Vol. COM-2B, No. 4, April, 1980.

8-33
6.0 APPENDIX

This appendix contains a summaryof the results of the trade study in the form

of decision matrices. The matrices list the item under consideration, options

for the item, advantages and disadvantages for each option, choice(s) among

the options, and rationale for the choice(s).

6-34
_D

w_

O

(D

_n

E

_9

cn

c4-)

Q.

O

L

u_

T,

L

O

u_

O

O

E

E

CD

O_

UJ

Z--J

O<

--Z

CnO

UJ<

++

II

II

i,i

_D

<

<

>

<

e_

k_

r_

<

Z

<

>

<

A

(,9:-

_UO

>.-

.jr-,,

Z

0

:n _'c"

--Ld

++

-- _ >,,

> ._ ._

--o>cr o 0 i.

•-_ -_ m_---

_O0(D t- --._¢-

--_._. _ _ _ _ ,,_..___ i..e_ i.

_.00 ._J _n _'_---- 0 _

0 0 0 000

•-- 1_ c-. q- O

_- >_,"_ i e' _ u) .-- ..E ('_..E ...... u_JD

_-- _.D(n m _ _ _ O_ _ %->,

•- _q.- _n 0 _ _ _._>_J _2 0-_ :-

O0 0 0 0 0 0 0

_n _n

__. ¢.. _,_a _ -- _ _; ¢n _ _; _

¢" GOOq- _ 0 c- 0 _0 r" c- _

0 0 0000 0

O_ >_--

L(D _.

• ,0 _OX

c-__ >OQ;

•- _J'_ "_--0

-- (D _cX_ .... _--_

_Q; O0 (D

_-0 _. 0"0 _-

0

_...--

0._

0:

0 _n

r-O_O

-_%-0

_Dr-O

_=.--_

-- Oq-- -" _) _:_ CO I I

0 0 0 0 O0

u9

¢I)

>

0

Q; v) _n

_n

0

%.

0

'->, 0

_> O_

Z: _ T.:

6-35
0

t'J

O_

oO

tQ.

0

"0

"Z

0

0

E

09

O<

,.,<

o_

L,_

0

<

Z

>

O0

L_

<

Z

>

<

A

Z_

n,- 0

..J_

Z

0

_L,J

r,.3 _--

k,_,l --

°_

Z_ O0

0 0 _0

-0

r-_..

-->

Nm

0

+.4-

O0

OO

.

O>

N

•- Q,1

0

O0

0_00

_00_

0_'-

0 O0

_0 O0 > _0_

_# '--_'-- NO _.--

O_ _ _ _ .--_

>--- _ _ _

00 _ _ 0 0 0

"0 t-_

c >_ ._

0 _ tO 0 0

__ __..__-

---_ _ I I I I 0_

6-36
eo

2

=

4-)

09

_D

0

"0

£.

_n

.<-

Z

u9

0

.,.)

=

CO

UJ

Z-J

O<

--Z

U10

(..)n- O -- t.O ,,,

+

09

.<

<

>

r-_

<

U_

-++

09

L_J

O

<

<[

>

<

A

u_ 09

<Iv

Z

0 >_

_-0 (,9 _ C._ --

0 t" _. w _.._ 0 t-

-- _ c- 0_._ _._ -"

0 .... _- 0 _n _-C 0 u_ --_n

>,N'--. _,_ 0 _.- Y-._ _ _- _-/J_

_----O ¢J 0; _-- c-_ _;---- 09

;.,9 _-'- .,_-- _0 -0" "-- _- t_ _D

0 0 0 0 0

OC._O 0

N_

_OQ;_ -_- >, O_

>.---- _'_ _ _. >_ _ _-

0 >,_ _n _ c._._n ---

O0 0 0 0

"-0

0,-- _

0 0 D

%-

0o9 _ 0_

UP _n _ 0

-_o _,_ --

_00

0_0

,<

=e0

-Do _-

0 0

_; _._ :-

j_ .,-

O0

>_.

-- C

_=--

c0 £- c_

0

-- CO

--

t- _n c-

(D_:-

t_

-CO :_

._ -_ -_

--_D ---_

_D:" O r-

_. t- tO •-- tg

_- t--(D 0 _.

_--- 0"-- 0 >,0 u_

--- <D.-- _ _---_D

0"0 O-- _ _-.- q0 0 0 0

O0 --C

--_

_ _X

0_'-- -- O

_n_ ..:-

_nO.-- _:=

_- c-_

_- .-- " C_

I c- _D.

0

c- .-

u9 _ u9

6-37
• o

+

_D

0

r_

E

O_

.m

_J

O.

0

°_

i.

tO

_0

0

o_

E

W

Z.J

O_

--Z

O00

++

¢0

b3

I--

Z

W

0

I--

Z

h- t-_

][

0

mL_

"0

EE "0

O.L _j_

t._ t'- .--i.

O0 _

_- _u_O _j ,-__ _-.-._

_-E O_ o L

cOL ,_ ,_ t-" _j _

Oo" m--- _UOL

• _J X ',_ _-_'_ 0

0 0

E

O"

U

0

O r'- (is_ 0 _-

0_ -- 0_

4-)

rE

O"

_J

l.

U

_)

0 0 0

¢J ¢J_- (J (J

0 O0 0 0

r- r" _" t-'_

_J _J _J OO

E _- E _- E_-._ m_

0"- 0"- 0 .... 0.0_

/

"_- "0¢_. "I0g- I_ ,I-._0

.... t- _'_. _.,. _.,.__

_E

._ f,_

U_

_U

E_

_U

_0

i" n _-

0 0 0 0

0

_ _--_

_, 0_._

_0

_'-- 0

0 _-- t'-

"0_. 0-" f-O

Eo_ E _._- _

0-_ _- 0 _a._ 0

,=[,u_ o: =.-_:

I.

E

0

3

U

--U

_..>

UOJ

UU

_0

U "0

0

6-38

.... O3

e-Om

0,,_ m 0

t,i)

NI,.,

O

O

O

°_

>=

I...

O_

_J_J

m_
q..

0

Q_

Q;

oO

ce.,

0

o

eo

E

i.i

z-J

_0

_0

<

Z

<

>

_m

<

C_

,'m

GO

<

Z

<

>

<

_0 c-

_.J 0

_J _0

Z

0

_.J_

r'-,

++

c0 0_- -_

•_ _. -- _ c- _,._ 0_,_

_ r_ ___

•-- • "- _ ¢-- .m _ N

_-- _ _.-

0 0 0

, -- -- mn_ _

N _-

--0

0

-- - _ cO "-._. _._

=2,

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

O r'-'.- 0_

_.._,-- _ _0 _-_

0 0 0

0_"

-- Cn_

¢;

r-

_'-0 _ _- "_ "--_

--_ _ _---N _*,-_

•_ _--- _ _ _-0_ _ ._¢0

_0 _- .--_ 0 _--- _,.- _ --._ _"

O0 O0 OC O

_" _ 0 >_

_- _00 _ _ _.-

-- 0 _- "-- O_ --- _o--

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

_-- _-_ _-- _ rj __ _0_-

--_o_. _ _ > .----_

0

"m "X

c- c_._

_.-

tm 0--

(._.-

_--

0 0

0 0

c- --

0

OJ 0 0

_ X

-- ...% _1.

0 0

0

_ C

_0 _'--

--0 ]:

u_ 0.)

cO

0 "- _ Q;

C. O0 C) 0

0 _ r.0.-- u_--

Q; 0 0 _-- .--¢0

0 _ 0 O 0 0 @

_'_ _- "_ _'0

- 0 -- ,'m

._ _-,'2_ _ E

"--_ O_

0 0

O0

C;

Z =

*-_

_.-

X _-0

:- _Z

0 0 0 0

cA A

C,J

6-39
_0

u

0

_0

cQ;

e_

0

_J

Z

.o

tO

¢n

0

0J

r_

E

ct_

_..J

O<

--Z

cnO

uJ<

r_Q_

_)

_J

<

M.-

Z

<

>

r_

<

¢/)

r-_

L.J

<

Z

<

Z>

r_

<

_0

_jr_

Z

0

(..) ,--

_..J_

.--_ 0 _

_ _ _ .-

.-_ .- L--

_'-- _ O_

0_ .--_ _

000 0 0

I _.

one- :-0 _--

_-_

_- _ _.- I _ _u_

•_ _ _ .---- _..

0 0 0 0

l 0 _'-- 0

.--_ ,,-_

0 0 _'1_ Q

•--_0 0'-" _0

0 _''- _--_0 O_

-- _'--_ "_ > _'-- 0"--

_ _ _._ _ _ _.--

c,-_O _0.._ t-_.

I

OJ ro

•- _

0 c" e" 0 0

r-.,_

•- 0

O--

0 0 0

,,,_ I 0 t,O

¢,') I rO c_

_._]_ _ c..

I _-- _" "_

l-- 0 _-

_--'--0 _ _

•-- "0 '__ 0 "--

0 0 0 0 0 0 0

=-- 0

_--_ _ _'--_ _0 _l

_.-- _ _

_ _--'--

_'-0 _ _

_-- _ _

0 0 "_

_ _.-_

_.-_ _.-_

_ _--_

_-- .-_ _--

0 "_ 0

m _ m

i | i

>

_ :__ -_-: = _ 0 "-

l _r_ r_

0 0

r" CJ

_¢--J

"n_v

1

6-40
Vll. SOFTWARE CONFIGURATION MANAGEMENT

7-I
SOFTWARE CONFIGURATION MANAGEMENT TRADE STUDY

1,o INTRODUCTION

1,1 BACKGROUND

Configuration Management is the identification of the characteristics of a

computer software system at discrete points in time for purposes of

controlling changes and maintaining the integrity and traceability o? the

system throughout its life cycle. Configuration Management (CM) is important

to the Space Station because it will be the mechanism For NASA to authorize

capabilities, track progress and ensure that the software deliveries are

cohesive. A CM system which provides the functions listed below can also be

considered a tool used by subsystem and customer management to plan, schedule

and track the tasks and resources assigned to them.

There will be a large number of areas using the SSE, including application

software developers, SSE developers, payload developers, ground support

developers, and various test functions. In this study, 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.

The Configuration Management system should encompass the following:

DEFINITION OF INCREMENTAL SOFTWARE RELEASES AND CAPABILITIES. The capability

to define software increments will be required since the Space Station itself

will be built incrementally, and there will be periodic upgrades in technology

and function. A way to define and record capabilities (e.g., CRs-.Change

Requests) will also be required together with a method of associating the

capabilities with projected releases.

b

CONTROL OF CAPABILITIES. The CM system must allow the user group to define

the approval level required for updates. This will vary between user groups

depending on the autonomy level of the subsystems involved. For example, one

subsystem may require multiple control board approval, while a complete].y

autonomous payload system would require no approval or internal approval only.

COSTING CAPABILITIES. The CM system must provide a way to associate a cost

with each requested update. This cost could affect the approval of the upd_te

and the assignment of the update to a release.

7-3

;RZcEDm PAGE BLANK FIL 
TRACKING MECHANISM. The Configuration Management system must allow for

defining a consistent set of development milestones and recording of projected

schedules and actual progress according to those milestones. The capability

to generate reports and graphical representations of this data must also be

provided.

DEPENDENCY IDENTIFICATION. The system must provide a way to record

dependencies among projected capabilities.

COMMUNICATION. A subset of the data maintained by the Configuration

Management system will be of interest project wide and must be made

available. Other parts will remain strictly for the use of the subsystem

developers and their NASA monitors.

TMIS INTERFACE. The interface between the TMIS and the SSE Configuration

Management functions must be defined in such a way as to minimize redundant

data and to provide cross referencing capabilities.

It is assumed that to maintain configuration control over the Space Station

software, the project will utilize a series of NASA, contractor and customer

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. Figure 1 is an example of how the boards may be structured. The

boards are responsible for defining both the software increments and their

contents. They must ensure that the scheduled contents of each increment m_et

the requirements defined for the increment. Lastly, through authorized board

representatives, they are responsible for entering their decisions into the

data base.

This trade study addresses three approaches to providing the data base system

mentioned above. Since the board structure is currently undefined and may

change after it is initially established, the impacts of such modifications on

each alternative will have to be considered.
Some assumptions were required to be made prior to beginning this trade

study. They include:

o There will be a large number of areas using the SSE, including application

software development, SSE development, ground support development and

various test functions. The SSE will also be made available For payload

application development. We will use the term 'user group' to define some

set of users working on the same task. It is assumed that each of the

Four primary Space Station sites may contain multiple user groups and that

user groups may exist at other locations as well. Because of this

assumption, this trade study will be totally independent of the trade

study being performed on the Facilities options.

The basic element of configuration control will be called a 'control

instrument' This generic classification would cover things such as

Change Request (CR), Discrepancy Report (DR), Program Change Request

(PCR), Problem Trouble Report (PTR) and any other type o? document which

might result in a software change.

1.2 ISSUES

There are a number of issues in the area of configuration control. Some of

the issues are:

l) The configuration control board structure across the project and how

much uniqueness will be allowed at each site and within each user

group.

2) Whether the payload customers will be encouraged or required to use

the SSE for their development. NASA may want to make the SSE

available ?or use by all customers and would want to maintain

configuration control over non-autonomous payload software. If this

is the case, the easiest way to accomplish this would be to require

the non-autonomous software to be developed in the SSE under its CM

system. I? the SSE is perceived by potential customers are beirlg

counter-productive, it could discourage them.

3) The level of security (privacy) required among user groups on

detailed planning and scheduling data.

7-5
I

I

I

L .....

I I

I Subsystem I

I I

W .-------_

I

I I

I Subsystem I

I I

I

I I

I Subsystem I

I I

I

I I

I

I

I Site I

I Prime I

I Contractor I

I

I I I

:rsc I I GSFC I I MFSC

Control I I Control I I Control

Board I I Board I I Board

I

I

I

I Space Stat. I

I S/W Control I

I Board I

I

I Non-Autonomous I

I Payload I

I Customer I

I

...... ")(" _ ........................... *

I I LeRC I

I I Control I

I I Board I

I Space Stat. I

I H/W Control I

I Board I

I

I

Space Stat. I

I Control I

I Board I

I

Figure I. Proposed Space Station Control Board Structure

7-6
4)

5)

Software components managed. Traditionally, requirements, design and

source and executable code have been configuration controlled. The

Space Station must address these plus elements of new technologies

such as new DBMS.

TMIS interface.

1.3 TRADE STUDY CRITERIA

Several criteria have been selected to be used in the evaluation and

comparison of the selected Configuration Management alternatives. The

criteria and a short description of each may be found in the following

sections.

1.3.1 GENERIC

COST

This criterion addresses the basic costs for the initial development or

acquisition of the CM system and for maintaining and operating it for the

duration of the project. This cost will be only that amount necessary to

implement the functions described in "Background". Since most of the other

criteria address attributes of the CM system which can be improved if enough

money is invested, this basic cost comparison will not include any cost to

make the CM system easier to use, more adaptable, etc, The cost of these

enhancements will be considered along with the criteria which are affected.

DEVELOPMENT "TIME

The intent here is to consider factors other than available manpower (or

money) which may affect the amount of time required to implement the CM

system. An example may be the amount of time necessary to define a system's

design because of its complexity. Having more manpower available in this case

may not decrease the total amount of time required. Under this criterion,

commercially available systems will be given favorable scores if their

purchase prices are less than development cost.

7-7
TECHNICAL RISK

This will look at each CM system alternative and determine what attributes of

the alternative might influence the chances of successfully implementing that

CM system. Items considered will include the complexityof the required

components and the current state of the technology required to build the

system,

IMPACT ON OTHER TOOLS

This deals with how other tools (part of the SSE or site-specific) are

affected by the structure of the CM database. Items considered will include

ease of extracting data and effect on tools of changes to the database

(especially if a change to the database can affect a site's tools even though

the change does not directly affect the site). The impact of Configuration

Management changes on the interface between the SSE and TMIS will also be

considered here.

MANAGEABILITY OF DATA

This will assess whether a particular alternative will allow tracking (and

enforcement) of the way the data is used at different sites. The aim here is

to allow users from different sites to be confident that a piece of data is

used consistently at each site.

EASE OF USE

This will examine the perceived ease of use of the system, l"he major

viewpoint taken will be that of the users at a site, but the ability to access

data at a site by a user from another site will also be examined.

FLEXIBILITY

The ability to change the definition of the CM database will be examined

here. This will include the ease of adding, deleting, or modifying fields _r_d

7-8
records in the database and the impact of database changes to the various

sites. It is recognized that the requirements for the CM will not remain

unchanged over the life span of the Space Station. Therefore, changes to the

CM software will have to be made. This criterion addresses the impact to the

users of affecting the changes. Part of the impact of installing changes will

be the amount of time the CM system is required to be down during

installation.

1.3.2 TRADE STUDY UNIQUE

AVAILABILITY OF DATA TO OUTSIDE USERS

This will address the ease with which a user at a different location can

access data from a particular site. Depending on the alternative being

addressed, the data may be the actual data from the site or a summary of the

data in a common format. Items considered will include the interface between

sites, integration of data from different sites into reports or a central data

base, and the interface with TMIS.

SECURITY

The ability of each alternative to control access to its functions and data

will be addressed here. Among the items considered will be the ability to

control definition (establishment) of databases and the ability to control use

of the databases (especially updates) from the level of the entire database

down to the field level within the database.

USER A(]CEPTANCE

This will address the level of user acceptance anticipated for the

alternatives. An example might be whether a particular alternative will tend

to be looked on unfavorably because it mandates a set of controls that a given

user group has never used in the past and does not see a good reason to use in

7-9
the Future. This criterion is included because a CM system which is disliked

by its users stands a good chance of not being used or of being used

incorrectly. Either way, the CM system will not help the users produce high

quality software in a cost-efficient manner. In Fact, if the user

dissatisfaction is great enough, the CM system could be a contributor to lower

quality and greater costs.

ADAPTABILITY

This criterion will address how well the alternatives can provide a CM system

which is adaptable to the needs of its users. A system which cannot be molded

to fit the user's normal procedures can cause quality and productivity

problems when the users are Forced to change their procedures or when they

ignore or misuse the CM system so that they can continue to use their normal

procedures.

1.4 APPLICABLE OPTION PAPERS

The Software Development Option Paper, Section 3.5.2, identified four tools.

It is felt that more tools will become available by the time it is necessary

to procure one and it is more advantageous to trade characteristics of the

tools to be procured than the tools themselves.

1.5 ALTERNATIVES

1.5.1 PROVIDE SINGLE PACKAGE

This alternative would provide a single system to be used by all users. The

user group with the most stringent control requirements would drive the

definition of the requirements. Much consideration and coordination would

have to be put into the requirements to best satisfy all the software

developers.

1.5.2 PROVIDE MULTIPLE PACKAGES

This would involve analysis of user needs and the development of multiple

different packages with varying level of control and variety of other

7-10
characteristics. Each user group would then select the one which most nearly

fit its needs, and mold his CM activities to the options provided. For the

purpose of quantification in the comparison of options, the specific number of

packages provided was needed. Four were selected in the belief that it would

be realistic in allowing sufficient variety of characteristics.

1.5.3 PROVIDE TAILORABLE SYSTEM

This option would provide a set of table driven functions. The tables would

be controlled by a 'system administrator' within the user group. The system

administrator would be required to define in the tables the specific options

for his user group. Some potentially tailorable items include:

o Control instrument definition

o Board approvals required

o Milestones tracked

Software elements controlled (e.g. source code, requirements, design,

users guides, etc.)

o Costing units (e.g. SLOCs, man months, memory requirements)

2.0 METHODOLOGY

In order to evaluate the alternatives presented, criteria were established

against which the alternatives could be measured. The criteria used are

defined in "Trade Study Criteria".

Next, in order to gain an understanding of user needs, a survey was taken of

the configuration management procedures used on a number of NASA and DOD

projects. Various generic documents and standards were also reviewed. A

7-11
summary of the major projects included is given in "Appendix A. Survey of

Configuration Management Procedures". The following projects are included in

the Appendix:

SPACE SHUTTLE PRIMARY AVIONIC SOFTWARE SYSTEM (PASS) This project works for

NASA's Johnson Space Center to produce the software for the Shuttle's Primary

Avionics Software System (PASS). This covers three areas of responsibility,

the PASS development, the support software and test tools development, and the

verification of the PASS.

SPACE SHUTTLE RECONFIGURATION DATA SYSTEM This system was developed at Johnson

Space Center to support the generation, maintenance, and configuration control

of data used by the PASS to support the various payloads.

SPACE SHUT-TLE GROUND BASED SUPPORT SYSTEM (GBS)This project is responsible

for the generation and verification of the software which is executed in the

Mission Control Center (MCC) and NASA's Johnson Space Center.

SPACE SHUTTLE LAUNCH PROCESSING SYSTEM (LPS) This is the software responsible

for controlling the Space Shuttle countdown and launch sequence.

SPACE LABORATORY This is the project which generated the operating system for

the experiment computer for the Space Laboratory at NASA's Marshall Space

Flight Center.

EARTH RESOURCES BUDGET SATELLITE AND GAMMA RAY OBSERVATORY Both of these

projects were done at NASA's Goddard Space Flight Center and used the same

Configuration Management system,

Using the findings from the survey and an understanding of the Space Station

generic requirements, the criteria list was revised and a weight proportionate

to its importance to the project was assigned to each criteria. These weights

are listed in Figure 2.

7-12
Each alternative was then evaluated to determine how well it would perform

against the criteria. The results of this are documented in Section 3. A

value was assigned to each alternative for each criteria to indicate its

relative strength among the alternatives. See Figure 2. The relative

strength was multiplied by the weight of the criteria and the products

accumulated for each alternative to indicate the best selection among the

alternatives. This is depicted in Figure 3.

3.0 RESULTS

The results of the Configuration Trade Study are summarized in Figure 2 and

Figure 3. The first figure shows the criteria used, the weight assigned to

each of the criterion (totals to 1OO), and the relative strength with which

each alternative meets each criterion (also totals to 1OO). The second figure

repeats the criteria and the weights, and replaces the the relative strengths

with weighted strengths (the weight ?or the criterion multiplied by the

relative strength of the alternative for the criterion).

As can be seen in the referenced figures, alternative 1 has its greatest

strength in the areas of cost and commonality while alternative 3 is strongest

in adaptability, ease of use, and user acceptance. Alternative 2 tends to

share in the weaknesses o? alternative i without any great strengths to offset

those weaknesses.

The remainder of this section discusses the criteria as they apply to each of

the three alternatives. Particularly emphasized are the strengths and

weaknesses of each of the alternatives.

3.1 ALTERNATIVE 1 - PROVIDE A SINGLE PACKAGE

3.1.1 GENERIC

7-13
COST

For this alternative, the implementation cost would be least. However the

cost of defining the requirements and getting the users to approve them would

probably be more than for the other two alternatives. The cost of maintenance

would be similar in that the requirements approval could be tedious, but the

actual implementation cost would be less than for the other alternatives.

DEVELOPMENT TIME

Like the cost, the impact of this alternative on the development time would be

in the definition of requirements. More care would have to be given to

defining the specific characteristics of the system to make it palatable to

a11 users. The actual implementation of the requirements would be less for

this alternative than for the others.

TECHNICAL RISK

This alternative would involve the least technical risk to implement. There

would be no new technology required over what will be required for the

communication of the data among the user groups, which will also be required

of the other alternatives.

IMPACT ON OTHER TOOLS

The other tools would be least affected by this alternative. Each wou].d have

a consistent interface with the CAM system.

MANAGEABILITY OF DATA

This alternative would provide a consistent definition of the data

maintained. However, one group may decide to apply a different interpretation

7-14
Criteria I Relative Strength

I

Name I Weight I Alt. 1 I Alt. 2 I Alt. 3

--_ I I l t

cost I 12 I 5o I 15 I 35

I I I t

Development Time i 10 i 55 I 20 i 25

Technical Risk I IO I 40 I 40 I 20

t ! I t

Impact on other tools I g I 50 I 30 I 20

I I I t

Manageability of data I

I

4 I ao I 40 I ao

I I _ ......................

Ease of use l 7 { 20 l 30 { 50

t t I t

Flexibility l za l 20 I 20 l 60

I I I I

Availability of data I I I I

to outside users I 4 I 55 I 25 I 2o

........................................................................................................ _............... " ...................... I...................................................... I........................................................ ÷.........................................

Security I 6 I 25 I as I 40

User Acceptance l 18 I 15 I 30 I 55

Adaptability I 7 I 15 I 30 I 55

Figure 2. Relative Comparison of Alternatives

7-15
Criteria I Weighted Strength

Name I Weight I Alt. I I Alt. 2 I Alt. 3

cost I 12 I 600 I 1Bo I 420

I I I I

Development Time I I0 I 550 I 200 I 250

t : I I

Technical Risk i 10 i 400 i 400 i 200

I I I I ..................

Impact on other tools I 9 I 450 i 270 i 180

! 4 I I'_ ........................

Manageability of data I 4 I 120 I 160 I 120

Ease of use I 7 I 140 I 210 I 350

I I I t

Flexibility I 13 I 260 I 260 I 780

•....... t l I _ ....

Availability of data I I I I

to outside users l 4 I 220 I 100 I 80

Security I 6 I 150 I 210 I 240

User Acceptance I 18 I 270 I 540 I 990

Adaptability I 7 I los I 210 I 385

W.................................................................................................................... I........................................... _........................................................ I....................................................... { ..........................................

I Total I 3265 I 2740 I 3995

Figure 3. Weighted Comparison of Alternatives

7-16
to some of the data than what is intended, to compensate for the lack of

flexibility in the system. This occurred in one of the projects surveyed. The

project had two different groups using the same system. One group wanted to

record some data not provided for in'the system, so they began to use the

fields in the data base that were defined for another purpose, but not used by

them. This practice was done before documenting it through the requirements.

Had they not updated the requirements to include the additional use, they

would have run the risk of having undefined data in the data base.

EASE OF USE

The implementation of this alternative could be made as easy to use as the

others, and easier to install (since there would be no decisions to be made at

installation time). However, there could potentially be a learning curve for

users to become accustomed to some of the characteristics which are new to

them. For example, some development groups estimate cost in terms of source

lines of code (SLOCs) and some use manpower (e.g. man months, weeks). Should

all groups be forced to use the same units, the estimates for the groups which

had to change could be inaccurate until they became accustomed to the new

units.

FL.EXIBII...ITY

This alternative would not be particularly flexible. Changes would generally

require system updates, but the down time for installation would not be

different than for the other alternatives. However, there could be potential

problems in accessing data across user groups if one group were using a later

or earlier SSE release than the others.

3.1.2 'FRADE STUDY UNIQUE

AVAILABILITY OF DATA TO OUTSIDE USERS

'The CM data for one user group would be the most readily available to outside

users if this alternative were implemented. This is due to the fact that the

data and the software to access it would be the same across all systems, and

no interpretation or conversions would be required.

7-17
SECURITY

The data could be made sufficiently secure within a given user group. A

subset of data from each user group would be made available to all users

groups. This subset would have to be predetermined.

USER ACCEPTANCE

This alternative would probably be the least popular approach with the general

users. Some of the users would Feel unduly repressed by the level of control

imposed on them by the system. If this were implemented, it would be

difficult to encourage payload customers to use the system.

ADAPTABILITY

This alternative would not be particularly adaptable to user procedures. It

would have to provide support ?or several procedures and methods for bypassing

the ones the user did not want. If not implemented correctly, it could tend

to dictate procedures. The quality of the software produced using this

alternative could be adversely affected if too little control were implemented

or, if too much control were implemented, productivity could be reduced.

3.2 ALTERNATIVE 2 - PROVIDE MULTIPLE PACKAGES

3.2.1 GENERIC

COST

For multiple systems, the requirements cost for the first system would be

approximately the same as Alternative 1. Since the systems each have common

elements that can be identified and reused, the cost of each of the remaining

systems is approximately half of the cost of the first system. Both

requirements and development cost follow this pattern.

DEVELOPMENT TIME

Since there will be many common, reusable elements between the systems, the

development time will be considerably less than developing multiple complete

systems, but will still be greater than Alternative 3. Even more time can be

saved if the systems can be developed in parallel.

7-18
TECHNICAL RISK

This alternative would have more technical risk than Alternative I due to the

multiple systems being developed, but would have less risk than Alternative 3

because each system being developed is not as complex as that alternative.

IMPACT ON OFHER TOOLS

This alternative is easy to interface with local tools because each user group

will have a consistent interface with the CM system. However, there will be

more local tools required in order to compensate for the differences in the

multiple systems. Global tools will need to be restricted to some common set

of data across the multiple systems. This data may be referenced by using a

cross reference between the local name and the global name.

MANAGEABILITY OF DATA

Since each system is developed to closely meet the local user's needs, this

user should have no trouble in managing data. However, the global user may

have difficulty in locating data required for reports. Also, data items

between systems may have different but similar meanings, making combinations

for global reports more complicated.

EASE OF USE

Each system will be easy to use by the local user because it has been closely

designed to meet their needs. However, the global user will have to be

familiar with ali systems in order to produce project level information.

FLEXIBILITY

The multiple system alternative is not flexible. Changes to each system wou].d

require system updates, but the down time would not be different than for the

other alternatives. However, for multiple groups using the same system type, a

potential problem exists if the user groups are using different versions of

that system type.

7-19
3.2.2 TRADE STUDY UNIQUE

AVAILABILITY OF DATA TO OUTSIDE USERS

Since there will undoubtedly be differences between the systems and data names

can probably not be held constant from system to system, some cross reference

must be maintained for global users to use in finding data. One example of

this may be in identification of change requests. CRs, PCAs, DCRs and ECRs

may each be used by different systems to request software changes. Some cross

reference should exist to correlate them when gathering data across systems.

Also, a common set of data between systems should be defined.

SECURI-FY

For each system the data could be made secure within a user group.

of data must be made available to the global user from all systems.

A subset

USER ACCEPTANCE

This alternative will be easier to sell to the local user because it has been

more closely developed to meet the local user's needs than Alternative 1. The

global user may have some loss of control due to data differences between the

systems.

ADAPTABILITY

Each system must be produced so that there is adequate control to ensure that

the software is developed according to requirements and modifications to

requirements. However, for the global user control, a minimum set of common

control data should be required of a11 systems.

3.3 ALTERNATIVE 3 - PROVIDE A TAILORABLE SYSTEM

3.3.1 GENERIC

7-20
COST

A tailorable CM system would be more expensive to build and maintain than a

single non-tailorable system since the tailoring options add complexity.

However, a single tailorable system would be less expensive than four

non-tailorable systems especially in the maintenance phase when the four

systems began to diverge from their common base. The operations cost would be

about the same as for the other alternatives. Any extra operational cost

associated with a coordinator setting up the tailored system for a user group

would be offset by lower costs for the general user of a system tailored to

the user group.

DEVELOPMENT 'TIME

As with the cost, a tailorable CM system would take take longer to build than

a single non-tailorable system because of the greater complexity of the

tailorable system. Also, as with the cost, a tailorable system would not take

quite as long to develop as several non-tailorable systems. But the

difference in development time would not be as great as the difference in cost

since increases in manpower would affect the required time more greatly for

multiple non-tailorable systems than for a single tailorable system.

TECHNICAL RISK

l"he technical risk in building a tailorable CAM system is greater than the risk

in building non-tailorable systems due to the greater complexity of the

tailorable system.

IMPACT ON OTHER TOOLS

With a tailorable CM system, local tools (i.e., those written by the user

group for their use) would be easier to write and maintain since they would

not have to sift through any data other than that used by and known to the

local group. Global tools (those written for use by a large number of user

groups; including TMIS) could be harder to implement since they could not rely

on the same data being available in all user systems. To have any chance of

wide use, global tools will need to be restricted to some common set of data

(possibly using a cross reference between the local name and the global name).

7"21
MANAGEABILITY OF DATA

With a tailorable CM system, global management of data could become difficult

since each user group's CM system might have different data in it. This could

be partially avoided by forcing some subset of the data to be common to all

users. Even this could be made tailorable by providing a cross reference

capability to allow that data to be called by different local names, but still

be retrievable from outside the user group by a common name (for example,

CR,PCR,SSCR are all kinds of change requests while DR,IR,PTR are all kinds or

error reports). As long as tailorability is a goal, there will always be some

data which is available in some user's CM system and not in other user's CM

system.

EASE OF USE

A tailorable CM system would be very easy to use by the local users - they see

only the data they care about and they do not see any other group's data.

That same system might be hard to use by outside users wanting to extract data

from it because of the same issues discussed in "Manageability of data".

FLEXIBILITY

A tailorable CM system should by its nature not need frequent system wide

changes to records and fields in its database. In addition, a tailorable

system should be more likely to have design characteristics (e.g., table

driven) which would make it easier to modify if its capabilities need to be

expanded.

With a tailorable CM system, there would be a greater chance that different

releases could be used simultaneously by different user groups. This in turn

will allow system upgrades to be installed piecemeal and at the user groups'

convenience, resulting in less total system down time than for a system which

requires all groups to come down together for system installation.

7-22
3.3.2 TRRDE STUDY UNIQUE

AVAILABILITY OF DATA TO OUTSIDE USERS

Assuming that some data is available in all user groups' instantiations "of a

tailorable CM system (either directly or through a cross reference) that data

would be available to all users. Other data unique to a particular

instantiation of the CM system might not be as easy to carry outside that

version

SECURITY

With a tailorable CM system, both the level of security and the particular

data items to which security applies should be selectable by the user group.

This includes not only which users have access to the CM system, but also

which users can update particular data items and which users can see

particular data items (privacy). Because of this ability to tailor access to

the database, this alternative would have the greatest security for the CM

database and the data contained in it.

USER ACCEPTANCE

A tailorable CM system will be the easiest to sell to the user groups since it

allows them the greatest control over their own procedures without the n_ed

for a lot of compromises to satisfy external groups. The more globally

oriented groups (contract monitors, integration groups) may have a problem

with some loss of control on their part. But this loss of control should be

more than offset by the global groups' ability to hold the user groups more

accountable for their actions (since the CM system can be tailored to match

the user group's procedures, it can not be used as the scapegoat For missed

schedules or poor quality).

AD_PTABILITY

R tailorable CM system would be very adaptable to user needs. Each user group

should be able to tailor the system to fit their procedures and methodology

for producing software. The only danger would be if the system could be

tailored to have so little control that it adversely the quality of the

produced software. This could be avoided by implementing the CM system to not

allow tailoring outside of certain bounds or by proper management review of

the options selected for an instantiation of the CM system.

7-23
4.0 CONCLUSIONS, RECOMMENDATIONS & REMQINING ISSUES

This trade study examined three alternatives for providing a Configuration

Management system for the SSE.

1. Provide Single Package

2. Provide Multiple Packages

3. Provide Tailorable System.

Several existing CM systems were surveyed to establish a knowledge base for

evaluating the alternatives. The results of that evaluation are discussed in

"Results" and shown in Figure 2 and Figure 3.

The single system alternative would lead to the lowest cost system with the

most data commonality. However, this would be achieved only after a drawn-..

out requirements phase, with much disagreement, and probably very little user

acceptance of the final product.

The multiple system alternative has no outstanding strengths and would likely

have the highest cost. The requirements and user acceptance problems of the

single system alternative would be only slightly improved by the four system

alternative.

A tailorable system has as its greatest strengths its flexibility,

adaptability, ease of use, and expected user acceptance. The greatest

weakness of this alternative is its technical risk, and this can be reduced by

producing detailed plans and specifications before beginning implementation.

The conclusion of this trade study is that the tailorable system alternative

is the most promising. It offers a high degree of flexibility and user

acceptance with only a slight increase in cost and technical risk.

7-24
Below is a review of the issues presented in Section 1.2 and the impacts of

this study on those issues.

1) Control Board Structure - A specific board structure has not been

determined. Although a potential one was suggested, it is not known

that it will be adopted. Nor is it known that all subsystems and

customers will require the same level of configuration control.

However, if the tailorable alternative is used then the board

structure will not drive the software implementation of the CM

system, nor will the implementation drive the board structure.

2) Customer Use of the SSE - This issue has not been resolved by the

trade study. Selection of the tailorable approach optimizes the

flexibility, adaptability and ease of use which would contribute to

the willingness of customers to use the SSE. However, the real issue

not resolved is how to determine if a customer or subsystem is

autonomous. A potential approach could be addressed by static

analysis routines executed against the candidate autonomous software

and by validity checks within the DMS. This issue must be addressed

in the future.

3) Security - No specific requirements have been defined and any of the

three alternaives presented could provide adequate security. The

recommended alternative represents the most likely method for

accommodating the requirements when they are defined.

4) Components Managed - Any of the systems discussed must support all

software components managed. As more definition of the software

components is available, the SSE must address configuration control

of them. New approaches will be required to support some of the

emerging technologies such as relational data bases and expert

systems.

5) TMIS Interface - The TMIS interface remains undefined. The CM

alternative selected must address the TMIS when the interface is

defined.

7-25
5.0 REFERENCES

.

Software Production Facility (SPF) Operations Planning Document, Volume

VII, Book 2, SPF Level B Applications Software Requirements, prepared by

IBM for Johnson Space Center, Data Systems and Analysis Directorate,

Spacecraft Software Division, Systems Engineering Branch, under NAS

9-16920, February, 1984.

o

Ground Based Space Systems Programmer's Guide, Volume V: Managers and

Coordinators, prepared by IBM, for Johnson Space Center, under NAS

9-14350, December, 1984.

3 ° Launch Processing System Configurations Management Reporting System,

prepared by IBM, for Kennedy Space Center, September, 1984.

4. Spacelab Integration Configuration Management Procedures prepared by IBM,

for Marshall Space Flight Center, October, 1983.

,

Configuration and Control Policies and Procedures prepared by Computer

Sciences Corporation, for NASA Goddard Space Flight Center, under NAS

5-27888, December, 1984.

7-26
APPENDIX A. SURVEY OF" CONFIGURATION MANAGEMENT PROCEDURES

A.l ONBOARD SHUTTLE SOFTWARE

The Onboard Shuttle Software project is composed of three areas: the Primary

Avionics Software System (PASS), the Software Production Facility (SPF) which

provided all the support software, and the Independent Verification and

Validation. Ali three areas used the same configuration management system and

special provisions were made in the CM software to accommodate uniqueness.

A.1.1 TYPES OF DATA STORED

The Onboard Shuttle Software project uses two hierarchical data bases to

manage its configuration. One contains the names of all systems, built or

planned and data pertinent to those systems. A11 systems are included,

whether for actual release to the field or for intermediate development. The

other data base contains the control instruments and their data.

instruments managed consist of:

CR

PCR

SSCR

DR

SSDR

HDDR

SAS

The control

Change Request for FSW updates

Program Change Request for FSW updates

Support Software Change Request for SPF updates

Discrepancy Report for FSW errors

Support Software Discrepancy Report for SPF errors

Help Desk Discrepancy Report for commercial S/W, H/W errors

Software Approval Sheet for FSW patches

When a user creates a control instrument, he must indicate the priority, need

date and project milestone driving the need (e.g., a specific flight). The

system stores the date of creation, and based on the type of control

instrument, the list of control boards to review the instrument. The control

boards, requirements analysts, implementers and testers review the control

instrument, and make assessments. The control boards assign a current

disposition and if required, a target date for the next review. When the

control instrument is approved, it is assigned to be built on a specific

system (or set of systems). The data stored in the data base as a result of

the assessment includes:

7-27
o

0

o

o

Documents affected

List of up to ten areas affected by the change

The duplicatesupersedingassociated control instruments

The cost (man weeks) and target and actual completion date For

requirements update

For each error (DR, SSDR)

- Control instrument and development phase which introduced the error

- System in which error was identified

- Activity which identified error (e.g. inspection, test) and which

preceding activities could have identified the error

Verification cost (man weeks) and coordinator

CPU time and simulation time required for development and verification

(itemized separately)

List of up to five areas responsible for implementation and coordinator of

each.

Each module affected (per system) and for each module, the milestones

listed in "Milestones Tracked"; names of the responsible analyst and

programmer; number of source lines of code (SLOC) affected; change (in

fullwords) of code, data and stack memory and accuracy of change; memory

configurations affected (FSW only); manpower cost (man weeks) for analysis

and implementation

Principal Functions affected and for each, the name of the responsible

analyst; the manpower to verify principal Function (man weeks); and names

and status of the test cases required for verification

Date, status and destination of patches

A.1.2 TYPEs OF DOCUMENTS TO BE UPDATED

A large number of FSW documents are maintained under configuration control,

including the Level A requirements, Level C design, Integrated Test Plan, Test

Specifications, and the Flight Computer Operating System (FCOS) Users Guide.

The documents maintained for SPF include the Level B requirements, and the

Level C design. The configuration control of all of these is manual. The

configuration control system has had some recent upgrades which enable it to

manage documents, however, none have been rehosted to the system.

7-28
A. 1.3 MILESTONES TRACKED

For each scheduled release, these milestones are maintained:

Build target and actual date

Build cutoff target and actual date

For each module to be updated, the target date, revised date and status

(uncomplete/complete) are maintained for the following:

o Start work

o Design draft

o Design review

o Design review complete

o Design complete

o Initial code complete

o Code review complete

o Code complete

o Test spec complete

o Test complete

o Test component checkout

A.1.4 CONFIGURATION MANAGEMENT BOARD STRUCTURE

The review board hierarchy is depicted in Figure 4 and Figure 5.

A.I.5 AUTOMATIC VS. MANUAL ANALYSIS

All of the software for the On Board Shuttle project is maintained under

automated configuration control. Software modules to be updated on a given

build must be scheduled in the data base mentioned above. The build tools are

driven by the data base and verify that ali the necessary approvals have been

given before the updates for a module are incorporated into the baseline.

None of the documents are currently under the automated system, however, it

would be possible to use the system to maintain them.

7-29
NASA Boards Contractor Boards

OASCB

Flight Software

Change Control

- Primary

- Backup

- Engine

Controller

- etc.

Orbiter Avionics

Software Control

• Board

SSD CCB

Recommendation/

Assessment for

Primary S/W

Changes

- Impacts

- Schedules

- Deliveries

Spacecraft Software

Division Change

Control Board

T&O Board

- Special

Patches

- MMU Element

Schedules

- Waiver Review

- DR

Disposition

Test and Operations

Board

SSD Management

- Contract

Control

- Schedules

- Release

Contents

Spacecraft Software

Division Management

I I

........................................ I RRB I

I I

•_- ..................... ")("

I I

I BCB I

Figure 4. Onboard Shuttle Control Board Structure (NASA Boards)

7-30
A.I.6 METHOD USED FOR COSTING

Costing is done by manual estimation. As mentioned above, costs for

requirements generation, development and verification are recorded in man

weeks. In addition, estimation of software changes are made in source

7-31
NASA Contractor Board s

Boards

I SSD I

I CCB I--L--"

I I

I T&O I

I Board l .................................

I I

RRB

- Flight Software Req.

Change Impact Assessmentl

- Flight Software Req.

Change Scheduling

- Req. Issues Review

- NASA Control Board

Support

Requirements I

Review Board _..-.------w

I

V

BCB

I SSD I I

I l_jmt. I............................. *

I I

SSRB

- Support Software

Change Impact Assessment

- Support Software

Change Scheduling

- Support Software

Req. Issues Review

I Support Software

w......................... w Review Board

I

V

I - Project Summary Schedule

.................................................... Change Schedule Approval

- Discrepancy Schedule

Approval

- Build/Release Schedule

Approval

- Interproject Technical

Issues

A

I

I

SARB

- Technical Issues Review

- Architecture Analysis

- Programming Standards

- Resource Utilization

Issues

System Architecture

Review Board

Baseline

Control

Board

A

I

I

DRB I

- Discrepancy Impact I

Rssessment I

- Discrepancy Source/ I

Patch Scheduling I

- Technical Interface to I

NASA for Discrepancies I

DR Review Board

Figure 5, Onboard Shuttle Control Board Structure (Contractor Boards)

7-32
lines of code required and in change in ?ullwords of memory required for

execution.

A.2 ONBOARD SHUTTLE RECONFIGURATION DATA

This Configuration Management System is used to control the modification of

payload reconfiguration data via Data Change Request (DCR). The data is stored

in units which are groups of category occurrences. A category is a template of

related items and a category occurrence is one named set of data values for a

given category.

A.2.1 TYPES OF DATA STORED

DCR data stored is DCR number (assigned by the system), title, description,

disposition commentary, entry date/time, change date/time, originator,

organization, phone, and DCR Coordinator identification.

Additional information stored is master data base of all category occurrences

or mission data base of mission specific category occurrences, list of units

and categories authorized for modification, and list of units and category

occurrences modified.

Authorization data is stored for each user indicating categories for which

data may be entered and/or whether or not the user is a DCR Coordinator.

A.2.2 TYPES OF DOCUMENTS TO BE UPDATED

There are no referenced documents managed. All DCR's and data are kept online

and may be viewed at any time by anyone with access to the system. If printed

documents are required, they can be printed at any time.

A.2.3 MILESTONES TRACKED

Board status of DCR is tracked as open, approved, withdrawn, or disapproved.

Status of category occurrences are tracked as working or frozen (a11 data

values within tolerances).

A.2.4 CONFIGURATION MANAGEMENT BOARD STRUCTURE

Internal review of payload data with payload supplier. DCR's are

dispositioned by the Orbiter Avionics Software Control Board (OASCB).

7-33
A.2.5 AUTOMATIC VS. MANUAL ANALYSIS

DCR's are created online by anyone who has access to the system. In order to

have a DCR number assigned a valid DCR Coordinator's identification must be

supplied. The Configuration Management system automatically assigns the DCR

numbers.

Each unit and category has valid suppliers of data assigned in the

Configuration Management system. These suppliers, once a category occurrence

has been modified, are the owner of that occurrence and no one else can update

that occurrence until the DCR is approved and baselined.

When category occurrences are supplied, the potential supplier of category

occurrences is automatically validated and if acceptable, may modify the

data. After each category occurrence data is entered online, the data is

automatically validated against predefined tolerances and if the data passes

the tolerance tests then it is marked as a valid occurrence; otherwise, it is

marked as invalid.

After all category occurrences are entered, an integration processor is run in

order to validate data across category occurrences.

Once all authorized data has been entered into the system, the data

occurrences are frozen by the data supplier or the DCR Coordinator which is

automatically validated by the system. Only valid category occurrences can be

frozen.

After all category occurrence have been frozen, then the DCR Coordinator can

submit the DCR for approval through the online system.

Through the online system, the OASCB then dispositions the DCR. After

dispositioning a baseline processor is initiated to make permanent updates to

the system, if required.

7-34
A.2.6 METHOD USED FOR COSTING

No costing methodology is supported by this system.

A.3 KENNEDY SPACE CENTER LAUNCH PROCESSING SYSTEM (LPS)

The two components of the LPS that were surveyed were the Control Data

Subsystem (CDS) and the Checkout Control and Monitor System (CCMS). The CCMS

is the real time environment and distributed operating system for the LPS. The

CDS is the off line system responsible for maintaining the large amounts of

data required by LPS and generating executable data for the real time system.

A.3.1 TYPES OF DATA STORED

The LPS system recognized the following types of control instruments:

SPA

ESR

SESR

CR/OSCR

IPR

Software Problem Report

Engineering Support Request (user generated)

Sustaining Engineering System Improvement Requests (contractor

generated)

3SC Change Request (changes to KSC S/W generated by changes at 3SC)

Internal Problem Report (problems initially documented by user)

For each, the release affected, implementation phases, responsible department,

affected modules, and documents affected were maintained in a data base.

A.3.2 TYPES OF DOCUMENTS TO BE UPDATED

The documents that were under configuration control were:

o Users' Guide

o Software Design Specifications

o Software Interface Document

o Programmers' Users Guide

o LPS Standards

A.3.3 MILESTONES TRACKED

Milestones were tracked at three levels: high, mid and low. At the high

level, for each ESR, SESR and CR, the origination date, need date, approval

date of each board, release data, validation date, and the assessment date

7-35
were recorded. Release data was maintained at the mid level. Dates

maintained were baseline complete, builds, integration start, validation

start, and date to deliver to user. At the low level, for each module

affected by a control instrument, completion dates were maintained For

requirements, other documents, code and unit test. Dependencies were also

recorded.

A.3.4 CONFIGURATION MANAGEMENT BOARD STRUCTURE

The control board structure used is depicted in Figure 6. The DL DED Board

consisted of the NASA design group. It initially dispositions updates at a

conceptual level. The ESR was a contractor technical board which reviewed

control instruments, high level requirements and Engineering Assessments (ES)

and recommended dispositions and implementation approaches. The Packaging

meeting was attended by contractor management and systems engineers. It was

at these meetings that release schedules and content were formalized and

recommended to the DL DED for approval. Significant changes had to be

approved by the NASA Level 3 Change Control Board. Following this, the

functional groundrules and data flows were developed and presented to the

Internal Contractor Panel and the NASA Design Panel for approval. After these

approvals were given, the high and low level design and the error messages

were generated and presented to the Internal Contractor and NASA Design

Panels.

A.3,5 AUTOMATIC VS. MANUAL ANALYSIS

The software and the documents were managed by the system. Each line of

software changed was associated with the authorizing control instrument. The

builds were done automatically, using the stored configuration data. Regular

reports were generated from the data base for tracking and status reporting.

The data was also available on-line.

A.3.6 METHOD USED FOR COSTING

Change Assessments were made for each module affected by a control

instrument. The units used were manweeks for software and pages for

documentation. The effects of the change on CPU and disk utilization were

7-36
also estimated. Engineering Rssessments were maintained for each department.

They were generated by accumulating the change assessments, adding overhead

?or engineering and management, and converting documentation costs to dollars.

7-37
NASA Boards Contractor Boards

I I

i DL DED I - Concept Approval

I I

I I

w_. II

I

w

ESR

I

V

•W....................................................................................................................................... I Board I

I I I

V

I - Concept Review

i - High Level Req.

i Approval

I Packaging I - Release and

Schedule

Definition

I I

I DL DED I - Approval of Releases and

I I Schedules

I,,°,°,0,,,,,,,o.,,,,,,,,,,,,0,,,,,,,,,,

V

Less Significant Changes

. do not Require Level 3

• CCB Approval

I NASA I

I Level 3 I

I CCB I

V

I_ Product

w.................................................................................................I* Development

_-)(-_w_._)(-x.w-_._

Two Pass Cycle: I

1: Functional Groundrules. V

Requirements, Data Flow w..........................................................

2: High and Low Level I Internal I

Design, Error Messages l Contractor I

I Panel I

I NASA I I

I Design I< .......................................................................................*

I Panel I

Figure 6. LPS Configuration Management Boards

7-38
A.4 SPACE LABORATORY EXPERIMENT COMPUTER

This project was responsible for generating the operating system for the

experiment computer for the Space Laboratory. The work was done by a

subcontractor to the prime Space Laboratory contractor.

A.4.1 TYPES OF DATA STORED

The types of control instruments maintained were:

SOFTWARE CHANGE REQUESTS (SCR) - which were initiated by the subcontractor.

SPACELAB SOFTWARE OPERATIONAL NOTES (SSON) - which document impacts and work

arounds to existing SPRs.

INTERFACE REVISION NOTICES (IRN) which were initiated by the prime contractor

to document changes to external interfaces.

ENGINEERING CHANGE PROPOSALS (ECP) - which are initiated by the subcontractor

at the request of the contractor.

SPACELAB PROBLEM REPORTS (SPR) - which are generated by users to document

problems.

If software impacts result from an IRN or an ECP, an SCR is generated. SCRs

were dispositioned by the ICB and the SRB; the SSONs the SRB; the IRNs by the

Contractor Control Board; the ECPs by the ICB, the Contractor Control Board

and the CCB; and the SPRs by the ICB and the SRB.

A.4.2 TYPES OF DOCUMENTS TO BE UPDATED

The documents that were maintained under configuration control were the

Software Requirements Document and the Level B Spec. The Level C Specs were

maintained, but not under configuration control

A.4.3 MILESTONES TRACKED

The milestones that were tracked were ali at the release level.

o Development release to verification

o Verification complete

o Delivery to KSC

o Test complete at KSC

They were:

7-39
A.4.4 CONFIGURATION MANAGEMENT BOARD STRUCTURE

Four boards existed and not all boards were required to act on all control

instrument type. The boards were:

INTERNAL CONTROL BOARD (ICB) which consisted of S/W subcontract personnel

only.

CONTRACTOR CONTROL BOARD which represented the prime contractor.

SOFTWARE REVIEW BOARD (SRB) which was chaired by the software contractor and

had membership from the subcontractor, NASA Program Office and Payload Office.

CHANGE CONTROL BOARD (CCB) which was chaired by the NASA Space Lab Program

manager and was the highest level board.

A.4.5 AUTOMATIC VS. MANUAL ANALYSIS

The system used very little automation. Early in the project, the data was

stored in a data base which had some report generation capabilities. This was

discontinued later in the project.

A.4.6 METHOD USED FOR COSTING

Initial cost estimates were generated manually and expressed in manmonths for

software development and pages for documentation. These costs were converted

to dollars at the boards.

A.5 EARTH RESOURCES BUDGET SATELLIIE AND GAMMA RAY OBSERVATORY

A.5.1 TYPES OF DATA STORED

Data stored originates from the following forms: Configuration Change Request

(CCR), Component Origination Form (COF), Change Report Form (CRF), Question

and Answer Form, Review Item Disposition (RID) Form, and Specification

Modification Form.

The related types of data to be stored are project milestones and deliverable

schedules, tests and test results, discrepancies and changes, specification

modifications, questions to the requirements or development team, RID's,

external data used For testing, and component development history.

7-40
A.5.2 TYPES OF DOCUMENTS TO BE UPDATED

Documents to be modified are listed on the CRF. The usual set of documents

under Configuration Management are functional specifications and requirements

document, preliminary and detailed design documents, system description and

user's guide, test plans, and development management guide.

A.5.3 MILESTONES TRACKED

The types of milestones to be tracked by this system are milestone and

deliverable dates, date of reschedule, target completion or delivery date, and

responsible person.

A.5.4 CONFIGURATION MANAGEMENT BOARD STRUCTURE

The Configuration Management Board Structure is responsible for approving and

monitoring all items in a project that are under configuration control

(usually these are projects that are related to mission support).

There are two Configuration Control Boards: the Code 500 Board which

processes Level 1 changes that have major effect on external interfaces,

master schedules, or budgets and the Code 550 Board which process Level 2 & 3

changes that have less significant or no effect on schedule or budget.

A.5.5 AUTOMATIC VS. MANUAL ANALYSIS

Three types of information are Configuration Managed: documents, software, and

specific types of related information. System modifications are initiated by

a CCR which are followed by a CRF or COF.

Documents are manually tracked and monitored. When document changes occur,

all concerned parties are informed. The primary purpose of the Configuration

Management procedures is to ensure that there is a master copy of each

document that reflects the current status of development and that change

information is properly disseminated.

Software is configuration controlled by the use of several libraries. Each

programmer has a private library containing all of the software needed to code

7-41
and unit test. The software may be copied from the Controlled System Test

Library (CSTL) into the private library for modification. This library is

controlled by the programmer.

After unit and preliminary integration testing is successfully completed, the

software moves into the Controlled Integration Library (CIL) for system

integration testing with the CSTL. When system testing is completed, the CSTL

is modified by the contents of the CIL.

When a build/release of the CSTL has been successfully system tested, it is

copied into the Controlled Acceptance Test Library (CATL) for testing by the

acceptance test team,

Finally the modified elements are copied into the Controlled Operations

Library (COL) for production use.

When libraries are updated, only source code is copied and then object and

executable code is generated from the copied source.

Certain specific types of related information are maintained such as developer

questions.

A.5.6 ME'I"HOD USED FOR COSTING

'The method used for costing is manmonths.

A.6 SPACE SHUTTLE GROUND BASED SUPPORT SYSTEM

The configuration management system studied for the Space Shuttle Ground Based

Support System (GBSS) project is used to maintain the application software for

that project. Similar configuration management systems used by the (;BSS

reconfiguration and systems support groups were not studied.

A.6.1 TYPES OF DATA STORED

Data is stored for two kinds of control instruments: Discrepancy Reports (DR)

for reporting problems and documenting fixes to problems and Program Change

Authorizations (PCA) for documenting other changes (upgrades) to the

7-42
software. The data below is carried in the GBSS DR/PCA database. Some of the

data applies to both types of control instruments and some to only one. Most

of the data originates on a paper form and is transferred to the DR/PCA

database.

o Originator information (name,address,phone,organization)

o Problem Scenario (type of activity,date/time,hardware/software

configuration)

o Problem description (symptom, impact, analysis result, and fix

description)

o Supporting data (log tapes, dump tapes, attachments, references to other

DR/PCA's).

o Affected area (department application area, and functional area)

o Implementor (programmer initial, subcontractor ID)

o Test case ID's

o Documentation update status (whether or not updates are needed)

o CSECTs updated

o Closure code

o Quality tracking data (software delivery on which problem introduced, type

of error <data, requirements, interface, l, where it should have been found

<detail design, code, IV testJ, and cost to fix problem)

A.6.2 TYPES OF DOCUMENTS TO BE UPDATED

Various documents are maintained under configuration control and updates to

documentation are required along with software updates. The DR/PCA database

contains a flag indicating that documentation updates are required to

implement the control instrument, but there is no indication of what documents

are affected or when the updates are to be made.

A.6.3 MILESTONES TRACKED

The only milestones carried directly in the CAM system are the target and

actual dates for the control instrument to be ready for a build. Build dates

and other development milestones are maintained manually outside the CM

system.

7-4,3
A.6.4 CONFIGURATION MANAGEMENT BOARD STRUCTURE

The major controlling group in the GBSS system is the management team. Changes

to the system must be approved (signed) by the manager of the person making

the update. Changes requested by the customer (NASA) are documented by TIRF's

(Transmittal/Information Request Forms) which are agreed to and formalized by

being signed by the appropriate manager. This control is exercised without

any formal board.

The Change Control Board (CCB) is made of of technical representatives from

each application area. This board collects all changes to the system and

ensures that they have proper management approval before allowing the updates

to be submitted to the build process.

A.6.5 AUTOMATIC VS. MANUAL ANALYSIS

Control of what gets put into the system builds is done manually by management

and area build input coordinators (the CCB). The system build process checks

an Authorization Database built by the CCB before allowing an update to be

made.

A.6.6 METHOD USED FOR COSTING

Costing is done manually. A cost for fixing problems is maintained in the CM

system for use in quality measurements (the cost of making errors). This cost

is maintained in manpower units (mandays, manweeks, etc.).

7-44
VIII. SOFTWARESUPPORTENVIROi_MEi_TFACILITY

8-I
SOFTWQRE SUPPORT ENVIRONMENT FQCILITY TRQDE STUDY

I.O INTRODUCTION

i.I BQCKGROUND

The purpose of this trade study is to identify and explore factors to be

considered when deciding whether the Space Station Software Support

Environment (SSE) is to be centralized or distributed facility.

The scope of the SSE physically is nationwide. Special emphasis has been

placed on 4 NASA centers : JSC, MSFC, GSFC, and LeRC with JSC Providing the

lead role. The scope of the SSE technically is to support the complete range

of software engineering functions from initial concept Formulation to

maintenance. Users will include commercial and academic customers building

systems to checkout and control their experiments/payloads, single contractors

building large computer systems such as the onboard operating system, and

multiple contractors writing onboard and ground applications software.

NQSA desires the SSE to be the single environment for software development on

the Space Station program. This is a cost saving philosophy. It recognizes

the Fact that a significant cost in the development of a complex computer

system is the support environment in which the system is developed. Past

programs have seen each NASA center (and often individual contractors) develop

individual software development environments. This duplication and the

unplanned and therefore complex inter?aces between the environments has

impacted the cost of maintaining these programs.

Given that the SSE is common for all Space Station software development and

given that this development effort will be a nationwide project, the question

of facilities naturally arises. Is the facility one central NASA Facility with

remote workstations at each NASA and contractor site, or is the facility a

network of smaller facilities at multiple sites9 And if it is a network, is

there justification for requiring each node to have compatible hardware?

These are the questions addressed.

P_,_ZC_hN_ P'_GE B_ANX NOT F_,_t)

8-3
Several assumptions have been made and are specified here:

I , The SSE will be contracted to a single contractor. This provides NASA

with a single point of contact for SSE issues. The contractor will

procure the software and hardware utilizing methods he deems appropriate

(e.g., subcontracts, procurement). This allows For the most cost

effective SSE by maximizing exploitation of S/W and H/W commonality.

, In the case of the common distributed option the initial SSE hardware

configuration will be provided to the centers along with the SSE software

system. The size of this system will be based on the centers own

specification of requirements to _SC. Subsequent changes to the

configuration will be under the center's control. These would be clnanges

such as the number of DASD's, printers, CPU's, etc. These changes would

have to be made within compatibility specifications which would be the

responsibility of the lead center.

. It is assumed that SSE support personnel would be provided at each major

host facility.

4 , Workstations for the Space Station will be powerful desk top personal

computers. The goal of the SSE will be that these intelligent work

stations (IWS) will be able to perform many tasks themselves and also act

as a terminal to the host processor to which it is attached. Ideally the

user's interface will be the same wnether on an IWS or a "dumb terminal"

attached to a host.

, The Phase B RFP stated that the onboard O/S, NOS and User Interface

Language will be a part of the SSE. It is assumed these and certain

other user standard utilities (e.g., Data base management system) will be

provided in the SSE.

8-4
1,2 ISSUES

The following are the significant issues addressed in this trade study.

i) Procurement Process - The Phase B RFP states that the SSE contractor will

procure the hardware for the SSE. However, the procurement strategy may

be considerably different if the SSE is distributed among several NASA

centers each using different hardware.

2) Insertion of New Technology - Ada is the suggested language for the Space

Station. Yet neither Ada nor any Ada Programming Support Environments

(APSEs) will be very mature when the SSE is begun. Therefore it is

crucial that the SSE be designed in a way that will facilitate upgrades

of compilers and APSEs. Also, powerful software engineering tools are

beginning to emerge. These should be provided to the software developers

as they are available.

3) Use of Intelligent Work Stations - This is the first major NASA project

since the emergence of the IWS. The allocation of functions to the IWS

and the interface between the IWS and host will play a vital role in the

SSE.

4) Use of the SSE by Customers - It is currently unclear the extent to which

NASA will encourage/require commercial or scientific customers to use the

SSE. If the customers are users of the SSE then the facilities must be

made available to them in an efficient manner.

1.3 TR'ADE STUDY CRITERIR

The criteria used in this study are divided into two groups - generic and

unique. The generic criteria are Cost, Risk, Performance,

Standardization/Commonality and Growth/Technology Insertion Potential. The

study unique criteria are Data Base Management and Processor Management.

8-5
1.3.1 GE_IERIC CRITERIA

1.3.1.1 COST

Costs related to this trade study include development and operational costs

for the Space Station onboard and ground data management systems and the SSE

itself. Distributed or centralized facilities will also have cost differences

as functions of actual computing resources, communication, physical plant, and

support services costs. Several elements of the cost criteria have been

identified that point out differences between the three options. These are

listed below:

I . SSE procurement process - What agencies and procedures will be used to

procure the initial SSE hardware and software. How will subsequent

changes to the hardware and software of the SSE be handled.

Initial SSE S/W development costs - How will the SSE be initially

developed and what cost factors will be variable.

SSE S/W maintenance costs - How will the SSE be maintained and what cost

factors will be variable.

Hardware costs - What factors will affect the cost of the hardware for

the various SSE facilities options.

System support personnel - What organization will the SSE system support

organization take and how efficient and effective will it be.

Physical plant - How will the buildings, rooms, A/C, operations etc, to

support SSE facilities affect the cost of the SSE.

Communications cost - How will communication costs for workstation usage

and data transfer affect the cost of the SSE.

B-B
8, H/W and S/W recovery - Will the SSE design preclude the recovery of any

hardware or software at the NASA sites For possible use in the SSE system.

. Software commonality - Will the SSE foster the "software factory"

atmosphere required for effective reuse of Space Station software.

i0. Educational costs - How will teaching users and support personnel about

the SSE affect the cost of the SSE.

1.3.1.2 RISK

The risks associated with SDE facilities lie in 2 main areas: risks

associated with providing and supporting of the SSE and risks associated with

the use of the SSE.

, State of the art - What hardware and software technologies are required

to develop each type of facility and how mature are they.

. Customer/Contractor acceptance of the SSE - Is there a risk that the

customer and contractors will not utilize the SSE efficiently or react

negatively towards software development methodologies supported by the

SSE. How will the type of Facility affect this risk.

3 , Control over the contractors - Will any type of facility gain NASA an

advantage in the goal of trying to provide the minimum but necessary

control over contractor generated software that will be developed on the

SSE.

4° Control over the customer - Will any type of facility gain NASA an

advantage in the goal of trying to provide the minimum but necessary

control over non-autonomous customer generated software that will be

developed on the SSE.

B-7
. Backup and recovery - What backup and recovery requirements are there for

the SSE and does any type of facility address this process better than

the others.

, Growth limitations - What are the chances of exceeding the limitations

imposed by the SSE.

. Maintenance skills - Because of the long duration of the Space Station

program, it is likely that the life span of the SSE will be 20 to 30

years. Maintenance skills will be required to make needed software and

hardware upgrades. How will the type of facility affect the availability

of applicable skills.

1.3.1,3 PERFORMRNCE

The performance of the SSE is a criteria with two viewpoints. One is the

performance of the SSE in the task of supporting end users. The second is the

performance of the SSE in supporting the task of integrating the end user's

work products into their intermediate or final usable forms (i.e. a DMS memory

load, a set o? design documents, schedules, etc.)

USER SUPPORT - User Friendliness can be addressed by providing

state-of-the-art tools to aid users in each phase oF the software development

process, by standardizing user interface techniques across SSE tools,

providing on-line user documentation, tutorials and help information and by

requiring Fully interactive user workstations even For remote users.

How a facility supports a user is a complex perception issue. Programmers

notice response time and down time. Managers notice lack oF control over" a

resource that is critical to their success. Initial impressions can go a long

way towards user's ultimate acceptance of a system. Having a stable SSE

available early on will be critical. The three different facilities options

a11 have different effects on the following user support elements:

8-8
i, Perceived user friendliness - What factors about the three facilities

options affect the views that the users have of the system.

, User control of SSE resources - Will users feel that they have any

control over the SSE resources. Can additional capabilities and

capacities be requested and received in a timely manner.

, Control over unauthorized use of the SSE - How will NASA control how the

SSE is used.

4° Support for site unique uses of the 5SE - Will the various NASA sites and

contractors be able to use the SSE for unique applications.

. Effectiveness of SSE support personnel - How successful will SSE support

personnel be at solving user's problems.

6. On-board use of the SSE-Will the SSE be able to support onboard users.

INTEGRATION SUPPORT -'The integration process occurs in all aspects of the

software development effort: planning, scheduling, coding, testing, build, and

release. Work products gathered in the integration activities includes

programs, documentation, and status. Each step in the integration activity

abstracts the input data to a higher level. The elements listed below will

help determine which options facilitate the speed, ease, and effectiveness oF

the various integrating functions:

I • Integration testing - How well does the SSE support integrated testing at

the user's site and at NASA sites.

2. Speed - How much time will be required to execute integration functions.

3. 'FMIS interface. - How will the SSE support the TMIS interface.

8-9
. Communication and reviews - How well will the SSE support on-line

documentation access, work product reviews, user to user communication,

and standards definition and enforcement.

1.3.1.4 STANDARDIZATION/COMMONaLITY

Standards and exploitation of commonality allow system designers to implement

cost effective and growth oriented systems.

I. Will any SSE facility option allow greater exploitation of commonality.

2. Will standards be easier to define and enforce on any of the SSE options.

1,3,1,5 GROWTH/TECHNOLOGY INSERTION PqTENTIRL

The Space Station RFP emphasizes a design philosophy which allows for

stepping up to advanced technologies as they become stable. This philosophy,

if adhered to, will make the management of growth of the SSE and DMS as easy

as possible. In this section are the aspects of growth management that are

affected by the type of SSE facility. They are:

I • Limits - Are there any limitations on the growth of processing power,

data communications or software function within the SSE.

. Technology insertion - Will the SSE design allow new technology insertion

with minimum impact.

, Upwards Compatibility - Will there be upwards compatibility of hardware

and software to facilitate growth of the SSE.

4, Distributed intelligence - Will the SSE be adaptable enough to allow the

integration of more and more intelligence into the environment.

8-10
1.3.2 TRADE STUDY UNIQUE CRITERIA

1.3,2.1 DATA BASE MANAGEMENT

There will be many data bases created on the SSE. There is likely to be much

interaction between these data bases. Sharing and communication of data

between these data bases will occur within and between centers, contractors

and customers. How the type of SSE facility affects this creation, storage,

and sharing of data will be important. The following list is used to

determine how well each type of facility supports the data management process:

i. Data storage - How will the SSE handle data base management.

, Data sharing/integrity - How will the SSE handling the sharing of these

data bases between users. How will the SSE ensure that all copies of

data are the same.

3. Security - How will the SSE ensure the security of these data bases.

, Backup and recovery - How will the SSE provide for backup and recovery of

data in the event of a minor and catastrophic failure.

1,3,2.2 PROCESSOR MANAGEMENT

The CPU will be a critical resource of the SSE. How this resource is managed

by the SSE will affect the user's view of the SSE. Insufficient processor

power will result in slower response time for interactive users as well as

lower total throughput. Total processing power is defined by peak demand.

Security and backup configurations also must be considered. The following

factors are affected by the facilities options:

B-11 •
i, CPU contention - How will the $SE handle the distribution of users across

processors in order to optimize the resource and present the fastest

response time to the interactive user and also optimize total job

throughput.

2. Handling peak demand - Will peak demand determine the size of the SSE.

, Backup and recovery - Will the SSE be designed to allow backup of

processing in case of failures (including catastrophic failure).

1.4 APPLICABLE OPTION PAPERS

- 1.4.2 High Order Languages

- 1,4.4 Advanced Tools

- 2,1.1 Data Base Management

- 3.5.2 Software Development

- 3.5.3 Systems Integration Test and Verification

1.5 ALTERNATIVES

Three options for facilities are presented. The first option is a centralized

facility with local and remote workstation access. The second option is a

group of distributed facilities with a common hardware environment and common

software. The distributed Facilities would again be accessed via local and

remote workstations, The distributed facilities would be networked together

For the necessary integration functions. This option shall be called "common

distributed". The third option is a group of distributed facilities with

unique hardware environments.

8-12
1.5.1 CENTRALIZED S£E

A centralized SSE would be located at the 3ohnson Space Center. Use of the

SSE would be via workstations which could be located anywhere in the country.

No limitation is set in this paper on the number or sizes of host processors

which would accomplish this SSE. It is assumed that NASA would provide

sufficient data communication and processing power to meet response time and

throughput requirements of all users. This option is shown in Figure 1.

Because of the distributed and hierarchical structure of SSE users, it is

assumed that a corresponding structure would functionally exist in a

centralized SSE. That is, individual users would promote work products

(software, documentation, schedules, etc) up through higher and higher levels

of integration. Different levels would functionally exist as separate users

but physically might reside in the same processor.

Testing of software products not designed to be executed in the SSE would

either be done in the SSE via simulation or the software loads would be built

in the SSE and electronically delivered to a user test set for execution in

the target environment. Operational software loads would likewise be built

and delivered.

B-13
SSE

Developer

JSC

Central

SSE

Facility

Contractor

• Nodes

Figure 1. The SSE as a Centralized Facility

8-14
1.5.2 CO_N DISTRIBUTED SSE

Once the decision is made to have a distributed SSE, the question "how

distributed?" naturally arises. This alternative provides for distribution of

compatible host hardware and common software at multiple sites. The functions

provided are similar to those in the central SSE option, but are augmented

with communicaton functions between facilities. The lead facility would be at

JSC. The user interface to the facilities will be either INS or "dumb

terminals." The number and locations of facilities will depend on the

distribution of work to be done. All software and hardware will be Government

Furnished Equipment (GFE). Figure 2 depicts one possible distribution.

All host processors and workstations in this option are compatible H/W systems.

8-15
Contractor Nodes

\

\

\

SSE

Developer

\

\

Contractor

/ o' /

/

/

:ommon

Hardware/

Software

Boundary

Contractor

Nodes

Customer

Nodes

(Optional)

Nodes

Figure 2. The SSE as a Distributed Netw()rkof Compatible Systems

8-16
1.5,3 UNIQUE DISTRIBUTED SSE

Most NASA software contractors have developed software engineerin9

methodologies with which they are familiar and comfortable, These

methodologies are often tied to a certain H/W system. The unique distributed

option addresses this fact.

This option allows unique systems at each of the distributed sites within the

NASA. A formal Interface Control Document (ICD) would define the interfaces

(i.e., format of products delivered) between the various facilities with the

lead facility at JSC.

Each facility would have the freedom to select the hardware and software

products which would be most compatible with their installed base thus

minimizing their individual initial cost and training requirements.

Although the hardware/software at each individual center could be different

all SSE functions would be supported in a'transparent manner at the program

level. These functions include integration, CM, build, delivery, DMS user

services, standards enforcement and integrated and system level testing.

Data maintained on these unique local facilities would not be easily

interchangeable among users. Special SSE services would be provided to support

this data interchange if required. The facilities would be accessed via local

and remote workstations and would be networked together. This option shall be

called "unique distributed".

B-17
Contractor Nodes Contractor

SSE

Developer

I

Customer

N odes

(Optional)

Contractor

Nodes

Contractor

Nodes

Figure 3. The SSE asa Distributed Networkof Incompatible Systems

8-18
2.0 METHODOLOGY

This trade study is based on surveys of past NASA software development

environments, research into the current literature, interviews with users and

developers of software development environments, interviews with software

development managers, interviews with large computer system engineers, and the

author's experience base.

Appendix 1 contains a summary of some of these surveys.

3.0 RESULTS

3.1 COST COMPARISONS

3.1.1 CENTRALIZED SSE COST

A centralized SSE would have a centralized procurement process. This single

agency would be responsible for the host computing facility. This agency

would have to respond to all centers' changing requirements for SSE resources

and as much as possible provide the optimum configuration at ali times. This

could require trading off resources among user groups taking into account

various work loads and schedule constraints. This process is very susceptib].e

to intercenter rivalries which might cloud true resource needs and result in

unfair and inefficient SSE resource management.

The following areas affecting cost of the SSE would be minimized with a

centralized SSE :

I. physical plant - buildings, rooms, A/C, power, etc.

2. system support personnel - operators, system engineers, help desks, etc

3. educational costs

8-19
To minimize the software development costs for Space Station, the SSE must

provide an environment which supports a software factory atmosphere. The

generation of reusable software components must be emphasized and supported by

the SSE. A mechanism must be provided to aid the user in finding reusable

software when the SSE is queried about it's existence. A centralized SSE host

facility would allow a program library structure and access methods which

could optimize the reuse of previously designed, coded, and tested software

components. Maximizing this advantage however would required similar

development methodologies and effective standards definition and enforcement

across all space station software development efforts.

A disadvantage of a centralized SSE would be in the area of H/W and S/W

recovery at the various NASA sites. Currently existing facilities that might

be available for Space Station software development use might not be usable

because of incompatibilities.

Communication costs would be higher for a centralized SSE facility, but it is

not Felt that this factor would be significant. Communication costs are

falling and also NASA could possibly utilize some of its existing networks.

Most users would require long distance access for workstation sessions but

there would be no need For long distance communication during integration

processes. Many advances are currently being made in the area of devices to

cluster remote workstations and provide very efficient sharing of

communication lines to the central facility.

There will be much use of the SSE for documentation storage. For documents

that must be available at all sites such as user documentation, tutorials, and

on-line HELP functions, a centr_lized SSE will minimize the cost for DASD to

store this type of data.

8-20
3.1.2 COMMON DISTRIBUTED SSE COST

Given assumption 2 in section "Background" the initial procurement of even the

common distributed SSE would be handled by a single agency thus minimizing the

procurement overhead. However, total processing power required by all

distributed locations might total to greater than the central SSE in order to

handle peak conditions at each center separately. Costs for multiple copies

of commercial software for the SSE can be minimized with commercial licensing

agreements.

Greater costs would be incurred because of the multiplicity of physical plants

and system support environments.

A common distributed SSE could also be designed to support the software

factory environment effectively. And, there would be more of a chance for

centers to reuse currently existing or newly developed hardware and software.

Most terminal usage would not require long distance costs in a common

distributed SSE but integrating functions would require burst of long distance

communications.

3.1.3 UNIQUE DISTRIBUTED SSE COST

The advantage of the unique distributed SSE is that each site could retain

expertise and support software gained in various software development

environments and methodologies. This could be an initial cost savings but is

questionable on a life cycle cost basis. Ada is the proposed language for

most of Space Station development efforts and the cost of multiple versions of

the Ada programming support environments would outweigh benefits of using the

installed hardware base. It would also complicate a software Factory

environment.

Another disadvantage is that several contracts would be required to develop

the SSE due to the diversity of system architecture desires at each center.

8-21
If this alternative were selected, a funding reallocation would be necessary

to provide funds for the support and maintenance of the local systems by the

individual NASA centers.

As in the common distributed SSE option, there would also be the extra cost of

maintaining multiple sets of physical plants and support environments.

Educational costs would be much higher with multiple software development

environments to teach. No common Space Station software development culture

would be formed. This would hinder NASA's goal for the lowest possible

software life cycle costs.

3,2 RISK COMPARISONS

3.2,1 CENTRALIZED SSE RISK

SSE development risk is minimized in a centralized SSE. This is a mature

hardware configuration and would allow the simplest SSE software system.

There is a real risk o? poor user acceptance of a centralized SSE. An

efficient, standard development environment if not used effectively will not

address S/W life cycle costs as predicted.

On the other hand a centralized SSE maximizes NASA control over contractors

and customers.

A centralized SSE runs the risk of large numbers of users left stranded when

processors go down. A catastrophic failure could mean no SSE services For a

protracted time period,

3.2.2 COMMON DISTRIBUTED SSE RISK

A risk exists in designing a common distributed SSE because of the immaturity

of the technology. This is not felt to be a significant risk however. Areas

8-22
of immature technology are mostly limited to distributed data bases.

Constraints becauseof these limitations would not significantly impact the

design of a commondistributed SSE.

The risk of user rejection of the SSEis smaller with a commondistributed

SSE, It is felt that the presence of local facilities will be seen as a

positive effect. It will allow the user to have more control over the SSE

resources,

Multiple SSEfacilities will allow each NASAcenter effective control over

their contractors and customer generated software.

A commondistributed SSEhas the ability to address the risk of failure of the

individual SDEfacilities. If deemednecessary, the overall architecture

could allow facility sites to serve as backups for other facility sites.

3.2.3 UNIQUE DISTRIBUTED SSE RISK

A unique distributed SSE limits the risk of user acceptance of the SSE. With

a Familiar environment the user is likely to feel more comfortable. Initial

software development in languages supported by the existing environments would

also be more efficient. However adoption of Ada would obviate the advantage.

There is a risk in developing the interface between the various facility sites

and the lead facility at JSC. It may be difficult to implement the electronic

interface between incompatible hardware. (See RNET in Appendix) There is

also a risk in defining an incomplete or ineffective ICD which will require

modifications resulting in software impacts at the various facility sites,

The risk in a unique distributed SSE relates to the total life cycle costs

associated with software built in this environment. Commonality across the

project would not be exploited. Standards would not easily be applied in the

different environments.

8-23
There is a risk that if the DMS user services are provided only at the

integration level, users, both contractors and customers, may choose to

develop unique code rather than use some of the DMS services. If this

happened, it would increase cost of the program and effect the capability For

technology insertion.

Unique environments would not allow for the backup facilities by facilities in

other locations in the event of Failures.

3.3 PERFORMANCE COMPARISONS

3.3.1 CENTRALIZED SSE PERFORMANCE

3,3.1.1 USER SUPPORT

User support is viewed from the perspective of each different type of user.

Many users are day to day interactive terminal users. Many other users will

utilize reports and documentation in an off-line environment. In general

off-line users should be unaware of whether the SSE is centralized or

distributed. On-line users can also have a transparent inter?ace to the

facilities with appropriate attention to this factor during the SSE design.

For long distance real time users to have a positive perspective of a

centralized SSE, appropriate attention will have to be spent on acquiring

reliable and fast communication links. This should not be a problem however.

Qnother important factor affecting the usability of a system is the perceived

control a user has over the resource which is critical to the successful

completion of his or her task. Q centralized SSE may cause the fee].ing in

users and managers of users that it will be too difficult to address problems

8-24
with the resource. At one extreme, many more levels of control and therefore

more justification and effort will be required to add capacity or capability

to the SSE if deemed necessary by a remote site. At the other extreme, single

users with daily problems may find long distance help unsatisfactory.

However, by centralizing the system support activity and providing enhanced

communication capabilities, a more efficient and effective system support

organization might result.

A centralized SSE would minimize the ability of remote sites to make unique

uses of the SSE. Site unique applications within the SSE system itself would

be requested of the lead center, reviewed for true uniqueness, and eventually

delivered. Site unique uses of the SSE computing hardware would not be

possible. This would eliminate any "hands-on" type operations such as

required in some testing situations.

A centralized SSE could support on-board use of the SSE as well as any other

option.

3.3.1.2 INTEGRATION SUPPORT

A significant advantage of the SSE over software development in past NASA

programs will be the ease with which the SSE will allow intercenter

communication, review, requirements and interface specifications, and

standards definition and enforcement. This support is optimized in a

centralized SSE. Documents for communication and review are on-line and

available to all users at a11 sites with small time delays and simple

procedures necessary for routing them between centers.

The time required to execute all integrating functions would be minimized in a

centralized SSE. The procedures for promoting all types of work products

(i.e. programs, test cases, designs, schedules, etc.,) to higher levels for

integrated activities would be simpler and faster to implement and execute in

a centralized SSE.

8-25
The TMIS interface is not well understood. There are no apparent advantages in

a centralized SSE to the TMIS interface other than providing one source for

acquiring data that needs to be transferred to the TMIS.

3,3.2 COMMON DISTRIBUTED SSE PERFORMANCE

3.3.2.1 USER SUPPORT

R common distributed SSE probably has the best chance of optimizing both

perceived and real user support. Most problems with long distance usage would

not be a factor - although because of the geographical distribution of SSE

users even a common distributed SSE would have many remote users.

Nith the SSE facility local to each site, users will have more control over

the resource. More capacity could be added without intercenter justification.

More capabilities could be added in two ways. First, "official" !SSE

capabilities would have to be requested of the lead center and delivered at a

later date. Other applications, as long as they met standards, might be added

by the sites For unique processing. A local SSE would allow "hands-on"

operations if necessary. Systems support personnel would be closer at hand in

a common distributed SSE to provide a more effective assistance function. This

assumes that the support function resource is addressed properly and not

diluted by the distribution of the SSE.

More effort and resources would be necessary to maintain security in a common

distributed SSE. Much data would be transferred between sites. Security

efforts might be less effective when handled by many agencies as opposed to

just one. The advantage of allowing site unique uses of the SSE brings the

disadvantage of possible unauthorized or inappropriate uses.

8-26
3.3.2.2 INTEGRATION SUPPORT

Intercenter communications and reviews (for requirements and interface

specifications, standard definition and enforcement, etc) could be well

supported by a common distributed SSE. The logistics and the procedures for

gathering the data would be more complicated and time consuming than a

centralized SSE, but still very practical considering the advantages of this

type of communication.

Other integrating functions such as system builds, planning, scheduling, and

configuration management would also be slower because of the gathering of data

required From the remote hosts. Procedurally however, this is not a

significant factor.

Support for the TMIS interface would be similar to a centralized SSE. A

common distributed SSE might facilitate the TMIS interface if NASA managers at

the sites require site SSE data - the data would not have to be processed

through a centralized interface.

3.3.3 UNIQUE DISTRIBUTED SSE PERFORMANCE

3.3.3.1 USER SUPPORT

User support in a unique distributed SSE would appear similar- to a common

distributed SSE as far as availability, support and site control over the

resource. However, the SSE system provided to run on the distributed

facilities might be limited in function compared to a centralized SSE or

common distributed SSE. A robust, project wide tool set for software

development would not be attainable because of the incompatible environments

of the various machines.

8-27
System support personnel at various facilities would not be able to "compare

notes" and would minimize the possibility of learning from other center's

experience base. Users would have to be educated both on their systems and

also on any integration system that they used.

3.3,3.2 INTEGRATION SUPPORT

A unique distributed SSE would complicate the integrating functions of the

SSE. This is the point where all sites have to communicate and share data and

procedures. Incompatibilities in the SSE's will be a factor here and will

have to be overcome during integration activities. Data bases will have to be

made consistent, communication procedures will have to be designed, and data

will have to be converted to similar formats. Not only will data formats be a

problem but networking different systems presents significant communication

problems (see RNET in appendix). These problems will cause integration

functions to be harder to design and maintain.

3.4 STANDARDIZATION/COMMONALITY COMPARISONS

3.4. I CENTRALIZED SSE STANDARDIZATION/COMMONALITY

A centralized SSE addresses both standardization and commonality well.

Compatible hardware and software systems would allow for commonality of data

bases, communication, development methodologies, procedures, terminology, and

training across all users of the SSE. This commonality would foster creation

of a Space Station software engineering culture which would enhance NASA's

program management task.

3.4.2 COMMON DISTRIBUTED SSE STANDARDIZAIION/(SOMMONALITY

A common distributed SSE has all of the advantages of standardization and

commonality as described above for a centralized SSE.

8-28
3.4.3 UNIQUE DISTRIBUTED SSE STANDARDIZATION/COMMONALITY

Many advantages of commonality would be lost in a unique distributed SSE.

With various software engineering methodologies in place, a common experience

base of procedures, terminology, problem resolution and training would be

lost. No global Space Station software engineering culture would be created.

This would affect Space Station software life cycle costs by requiring

operational contractors to learn multiple software development methodologies.

3.5 GROWTH/TECHNOLOGY INSERTION POTENTIAL COMPARISONS

3,5.1 CENT'RALIZED SSE GROWTH/TECHNOLOGY INSERTION POTENTIAL

A centralized SSE represents a possible growth limitation problem when

compared to a distributed $SE. A centralized design might become cumbersome

if the number of users grows much larger than the number For which the SSE was

originally designed. A important factor likely to affect this limitation is

the evolution in integrated workstation products occurring now. Powerful

workstations, compatible with mainframe processors, are becoming availablel

Response time issues can be addressed by this technology. Growth is

accommodated not only by adding to the central host complex but by adding

workstations. This technology will evolve the SSE From a centralized Facility

to a distributed one. A real danger exists then that an initial centralized

philosophy for the SSE would limit the effectiveness of IWS's and local area

networks of IWS's.

A centralized SSE allows SSE developers to ensure the H/W and S/W is designed

for upward c'ompatibility to allow For significant growth with minimum impact

to the SSE system software.

Another advantage of a centralized SSE is that one agency would be responsible

for controlling growth, This agency would have more power than multiple site

oriented agencies. This agency could attempt to optimize SSE resources across

all sites for the most cost effective growth management.

8-29
3.5.2 COMMON DISTRIBUTED SSE GROWTH/TECHNOLOGY INSERTION POTENTIAL

A common distributed SSE has the best chance of eliminating limits to growth.

She nature of the design for a common distributed SSE would lend itself to

adding or subtracting distributed host facilities with minimal impact to users

and the SSE system. Existing Facilities could expand processor capacities

with a smaller risk of meeting some unexpected upper limit to growth. Upward

compatibility of H/W and S/W here would have to be a part of the SSE design.

A growth in communication rates for the distributed network would be another

Factor in growth management. A risk would exist here that the initial design

of the common distributed SSE might not take into account all necessary data

communication and growth might become difficult and expensive, A common

distributed SSE implies a growth management function being performed at each

site. Current technology however, supports a centralized network management

function which can automatically collect information from distributed nodes to

allow growth management from a central agency.

3.5.3 UNIQUE DIS]'RIBU'TED SSE GROWTH/TECHNOLOGY INSERTION POTEN'I"IAL

Limits to growth for the unique distributed SSE are again similar to the

common distributed SSE. Growth in a unique distributed SSE is liable to

impact more SSE software than in the other two options. [his is because it is

anticipated that more custom SSE software will be required in a unique

distributed SSE to handle functions for which common or centralized SSE's

might be able to use commercial software. Network management in a unique

distributed SSE could not be performed by a lead host. This would impair any

centralized growth management Functions.

3.6 DATA BASE MANAGEMENT COMPARISONS

3.6.1 CENI'RALIZED SSE DATA BASE MANAGEMENT

A centralized SSE enhances data base management throughout the SSE.

bases would exist side by side, structured alike, thereby aiding any

integration of

All data

8-30
the data from the different data bases. Security is enhanced, data does not

have to leave the facility to be shared, although it still leaves the facility

for user access via reports or terminal viewing. Data integrity is enhanced

by the lack of duplication of data which could allow copies to get out of sync.

3.6.2 COMMON DISTRIBUTED SSE DATA BASE MANAGEMENT

A common distributed SSE enhances data base management through the use of

consistent data base structures. Sharing the data is slightly more difficult

than a centralized SSE but could double as a means of backup for other site's

data bases. Security is a consideration since sharing data would require

transmission from site to site. Currently there are no mature distributed

data base management systems. Constraints on the SSEdesign would be required

to assure this immature technology does not affect the SSE adversely.

Therefore data base management in a common distributed SSE would actually be

unique independent data bases at each node. Interchange of data therefore

would be through custom generated procedures.

3.6.3 UNIQUE DISTRIBUTED SSE DATA MANAGEMENT

A unique disEributed SSE could support data base management within each

facility satisfactorily. However, sharing data and handling other sites data

would require significant special processing (see RNEI is appendix). Security

would be affected as in a common distributed SSE.

3.7 PROCESSOR MANAGEMENT COMPARISONS

3.7.1 CENTRALIZED SSE PROCESSOR MANAGEMENT

A centralized SSE would in reality be multiple processors. CPU contention

would be controlled by the SSE to present a fair response time to all users.

Total processing power would be a function of peak use including all

interactive users, simulations, and integrated testing.

8-31
A significant disadvantage of a centralized SSE is that if processor support

is lost, all users will be left unsupported. If this loss is due to a

catastrophic failure, then the SSE would not be available for a long time.

This may not be acceptable with a manned Space Station to support.

3.7.2 COMMON DISTRIBUTED SSE PROCESSOR MANAGEMENT

A common distributed SSE has the advantage that not all users are on the same

facility and a failure will therefore affect a smaller number of SSE users.

If desired the common distributed SSE could be designed to allow sites to

provide backup support for other sites in case of failures.

Total processing power in a common distributed SSE might be larger than in a

centralized SSE because each site would have to be able to react to it's peak

load conditions that if added to all other sites and spread out over time

could be less for a centralized SSE. A common distributed SSE does not allow

for "sharing" of resources. For example, if one center runs out of a

resource, it may require a long time to procure more of the resource. However

in a centralized SSE the resource would be shared equally with between centers

until more can be procured.

3.7.3 UNIQUE DISTRIBUTED SSE PROCESSOR MANAGEMENT

A unique distributed SSE would handle processor management in much the same

way as the common distributed SSE. However, the ability for one site to be

used as a backup for another site would be severely limited.

4.0 CONCLUSIONS, RECOMMENDATIONS & REMAINING ISSUES

Based on the summary of advantages and disadvantages in Figure 4 the

recommendation is that a distributed SSE of compatible hardware and software

would be most effective at both supporting the user and providing NASA with a

means to address software life cycle costs.

8-32
Workstations on the end user's desk will address his or her productivity. A

small host integrating many local users at the contractor's site will support

testing, communication among users, and data sharing and will allow software

managers to effectively use the SSE for project management a_d configuration

control.

Larger hosts at NASA centers will support effective NASA project management,

the TMIS interface, and higher level of integration functions, system builds

and deliveries.

All levels of hardware from the desk top to NASA centers should be compatible

hardware systems with a user interface standardized by the SSE system which

resides at each level. This hardware and software compatibility along with

the design philosophy of a distributed SSE will give NASA the best control

over growth, technology insertion and standards. This commonality approach

will encourage the formation of a Space Station software development culture.

With similar experience bases because of the common methodologies, procedures,

interfaces, data bases, etc users will find it easier to communicate and work

with peers, integrators, and managers. NASA will find it easier to manage the

software from development through operations and maintenance.

Below is a discussion of the issues identified in Section 1.2 and how the

recommended approach addresses them.

l , Procurement Process - If the common distributed alternative were

selected, then each host site would be provided with its initial system,

Then each site would be responsible for procuring additional hardware

capacity as needed.

, Insertion of New Technology - The adoption of the common distributed

alternative would allow the SSE contractor to incorporate new software

technology and distribute it in normal SSE system releases. Use of

compatible hardware makes upgrades to more advanced hardware more

efficient than using mixed hardware would.

8-33
0 Use of IWS - By having common software and compatible hardware, the

possibility oF providing a common interface to the user From both IWS and

terminal is greatly enhanced. It is recognized that many IWSs are

available and customers may want to interface with the hosts From a

variety o? IWS's. Using the common software and compabile hardware

throughout the SSE will minimize the difficulty oF effecting the

interface.

. Use of the SSE by customers - It is believed that selection of the common

distributed alternative would not discourage customers From using the

SSE. The availability oF the DMS user services in the SSE will make it

attractive for them to use. Selection of this alternative For the SSE

For contractors should not preclude the use oF a modified "common

distributed" approach for customers. They could use their own

environments For their development, deliver their software to a NASA

site, where they would test it and then make it available For integration

and delivery to the vehicle.

8-34
I..61

661

r,rm Z

l..mJ

t_

O'3

l---

r.m

r_

r'h ZO

ILl

r'h N

t==._

r_- Z

t.l,J

XZ

_--O

1.61

l--

rap

k-- O

Or=) O

===I

.m--. Z

3=O

,_J!

j-= O

?..=)

_"> 1.61

r--I(_)

>-

U.J

m.

-J!IJ3 O

O

t".JU.l

-=I

LJ

>-

uJ

t.6.

._,I IOO

I'-- O

_Z_

II

tD, OOO

-r"

l.m

C"J r...0 Z

I.ZJ

LZJ

Z

r_" I=-

_Z

t_UJ

_0LIJ

U.mt_

'--'_Z_

_Z

r*.- .=J_--

_=._ _=J Z

Z

r,,,.J 0

HL.)

r_

_J

l,m Z

t_J

C_

ZZ

ZZO

_Z_

!I!II

ZZ

ZO

_Z_

Z_ | I

II

OOZO

Z

_OZ

O__Z

III

I-- Z

%"O

m- m,.*

O'-*'Z

Z"'

'.,,O

u_Zrm

.¢_G u.J

r-_ (.j r.,-' I I I 0

C3 ZO

i--i

_=-

_>-

_-0

_Z_

Z_ O_

_Z

O_Z_ I

II

UJ

m*-

1.61

m.,.

_=.

u.'_ r*hZ

1.61u,J

..--_C..9

r_...z

Z_"

ILlIOO

C_

_m00Z

.-mz

tJO

IJ,J _,-¢

_l-.-

"r" U.._

_z

0,--,

(..0

I--

OLu

nm

l"m l._

_'00 0I

ILl

mm I,---

0 "m_ U._

--"JC._

mm ,.--,

F--"_m-

,:t "m_

", r-.,

GO

C-)Z I

I

00Z

_J

I..61 Z

_-.

m,- o

m..-

r.-.. t_ Zrm.

L-"_ X

l.J.J

L_I

==J

_===_ Z

tJ.J

mm

.,..J Z00

I--- Z

0"'

t=_lZ

¢.J ,_:

Q.

t

m_l 0

_-=

"0

'*0

t_

_50

4_

q--

4-¢

q.I 3

.=_

r_

._=._ L

q_

i.

On

.,.=;

Lu

Lr_ 0

8-35
5.0 BIBLIOGRAPHY

P.S. Newman, "Towards an Integrated Development Environment," IBM Systems

3ournal, 81-I07, Vol 21 No I, 1982.

W.E. Beregi, "Architectural Prototyping in a Software Engineering

Environment," IBM Systems 3ournal, 5-18, Vol. 23, No. 1, 19B4.

Leland Beck and Thomas Perkins, "A Survey of Software Engineering Practices:

Tools, Methods, and Results," IEEE Transactions on Software Engineering,

541-561, Vo1. SE-g, No. 5, September 1983.

Proceedings of the ACM AdaTEC "Future Ada Environment Workshop" Santa Barbara,

California, 17-20 September 1984, ACM SIGAda Ada Letters, Spring 1985.

Daniel ROY, "Software Tools and Methodology Study for NASA MSOCC, Century

Computing, INC., 8101 Sandy Springs Road, Laurel, Maryland 20707, June 1984.

H.G. Stuebing, "A Software Engineering Environment (SEE) for Weapon Systems

Software," IEEE Transactions on Software Engineering 384-397, Vol. SE-IO,

No.A, July 1984.

Ellis Horowitz and John Munson, "An Expansive View of Reusable Software," IEEE

Transactions on Software Engineering, 477.--487, Vol. SE.-IO,No. 5, September

1984.

Michael Ryer, "Developing an Ada Programming Support Environment," Mini-Micro

System, 223-226, September, 1982.

Leon Osterweil, "Toolpack - An Experimental Software Development Environment

Research Project," IEEE Transactions on Software Engineering, 673-685, Vol.

SE-g, No. 6, November 1983.

8-36
6.0 APPENDICES

6.1 SPF

%SC's SOFTWARE PRODUCTION FACILITY (SPF) FOR SHUTI"LE

The SPF is a centralized software development facility at JSC used for

development, test, release, build, and CM control of Shuttle Primary Avionics

Software and the SPF software and the verification testing of the Backup

Flight Software (BFS). Users are local at JSC and remote at Rockwell in

California for the Backup Flight Software, and remote at various other NASA

centers such as KSC.

Problems with remote use of the centralized SPF have centered around a lack of

common culture among the users and the difficulty of users communicating with

SPF support personnel over long distances. The remoteness adds a level of

complexity which increases the time needed to solve problems. Telecons have

been utilized to address the problem but are impaired by the logistics of

getting the right people in attendance and the time zone difference.

An important point for Space Station software development is that at least

during the maturing phase of the SSE support personnel must be readily

available to the end user. This can be accomplished by direct support at the

remote host sites or greatly enhanced video conference capabilities (i.e.

listing and dump avai].ability). The SPF is a custom developed software

development environment hosted on IBM 3033 and IBM 3084 mainframe processors.

Some commercial products have been incorporated into this environment. Because

of its complexity it took a significant time period to achieve maturity.

During this time period, support for users was not optimum and productivity

suffered. The Space Station SSE should be created using as many commercial

products as possible in order to achieve maturity quickly and support user

productivity.

8-37
6,2 LPS

Kscas SHUTTLE LAUNCH PROCESSING SYSTEM (LPS)

LPS has two major software development environments. Programs developed for

the off-line Central Data System(CDS) are maintained on Honeywell 6600

mainframes. Programs developed ?or the on-line Checkout, Control and Monitor

System (CCMS) are maintained in a specialized configuration of the target

machine hardware - Modcomp minicomputers called the Software Development Lab

(SDL). Both environments were custom generated and are centralized facilities.

The current contractor (Lockheed) is experimenting with a network of Apollo

supermicros to decentralize and consolidate the two environments. User

workstations and windowing are being used to greatly increase user

productivity. Workstations are planned for software development, unit testing

and some integration testing.

6,3 RNET

RECONFIGURATION NETWORK (RNET)

The RNET project is addressing a problem that NASA has with the Shuttle

program because of the multiple incompatible software development environments

which were used to develop major Shuttle software subsystems. The

incompat:i.bility of data bases and communication protocols between these

systems presents a severe hindrance to Shuttle software maintenance in the

operational era.

Twenty reconfiguration products such as the mass memory load tape have been

defined as candidates for automatic transfer among the SPF, MCC, KSC CDS, and

SRS. Problems being encountered include a lack of true cross vendor

communication packages and the customized processes needed at each node to

handle the data being automatically delivered.

These experiences support the arguments in this trade study for the SSE being

a system of compatible hardware and software systems.

8-38