DECEMBER 1985 • ,_ '.;:_, ",_ 7_ MDC H1343A

[ /t_DAC }

[__}{ IBM }1 .c/Ij]

SPACE STATION DATA SYSTEM

ANALYSIS/ARCHITECTURE STUDY

Task 3- Trade Studies, DR-5

Volume II

{NASA-CR-177843} SPACE S_A_ICN DATA SYSTEM

ANALYSIS/ARCHITeCtURE STUDY. _ASK 3: TRADE

SIUDIES, DR-5, VCIUME 2 {McDor_nell-Douglas

Astronautics Co.) 298 p HC A|3/M_ &01

CSCL 22B G3/|8

N86-20976

Unclas

0_593
/MrCDO/V/_/EL_

DOUGLAS

CORPORATION

DECEMBER 1985

SPACE STATION DATA SYSTEM

ANALYSIS/ARCHITECTURE STUDY

Task 3 - Trade Studies, DR-5

Volume II

MDC H 1343A

REPLACES MDC H1943

DATED MAY 1985

MCDONNELL DOUGLAS ASTRONAUTICS COMPANY- HUNTINGTON BEACH

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

lhe McDonnell Douglas Astronautics Company has been engaged in a Space

Station Data System Analysls/Archltecture Study for the National Aeronautics

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

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

was divided into six tasks:

Task I.

Task 2.

Task 3.

Task 4.

Task 5.

Task 6.

Functional Requirements Definition

Options Development

Trade Studies

System Definitions

Program Plan

Study Maintenance

McDonnell Douglas was assisted by the Ford Aerospace and Communications

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

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

This report was prepared for the National Aeronautics and Space

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

Questions regarding this report should be directed to:

Glen P. Love

Study Manager

McDonnell Douglas Astronautics Company

Huntington Beach, CA 92647

(714) 896-2292

PRECEDING PAGE BLANK NOT FILMED

°..

III
co

o'_

"T"

ii

iii

0

"E_ =o .--,=_

nE

E

o_=

o=.

CO

mll_

0

iv
IX

XI

Task 3 Volume II

CONTENTS

SOFTWARE DEVELOPMENT TEST AND INTEGRATION CAPABILITY

l.O

2.0

3.0

4.0

5.0

INTRODUCTION

l.l Background

1.2 Issues

1.3 Trade Study Criteria

1.4 Application Option Papers

1.5 Alternatives

METHODOLOGY

RESULTS

3.1 Basic Summary

3.2 Background Information

3.3 Options Comparisons

CONCLUSIONS

REFERENCES

FAULT TOLERANT COMPUTING

l.O

2.0

3.0

4.0

5.0

INTRODUCTION

l.l Background

1.2 Issues

1.3 Trade Study Criteria

1.4 Applicable Options

1.5 Alternatives

METHODOLOGY

RESULTS

3.1 Summary

3.2 Related Topics

3.3 Decision Matrices

CONCLUSIONS, RECOMMENDATIONS AND REMAINING ISSUES

REFERENCES

SPACE QUALIFIED COMPUTERS

l.O

2.0

3.0

4.0

TRADE STUDY DEFINITION

l.l Purpose of Trade Study

1.2 Background

1.3 Issues

1.4 Trade Study Criteria

TRADE STUDY METHODOLOGY

TRADE STUDY DISCUSSION AND RESULTS

3.1 Standardization vs Commercial Instruction Set

Architectures

3.2 Special Purpose vs Standard Architectures

3.3 Radiation Qualification LEvel

3.4 Fault Tolerance

3.5 Imbedded vs Stand Alone SDP Options

CONCLUSIONS/OPEN ISSUES

Page

9-I

9-3

9-3

9-3

9-4

9-6

9-7

9-8

9-8

9-8

9-10

9-I 7

9-19

9-20

lO-I

I0-3

I0-3

10-4

10-4

10-5

10-5

I0-7

lO-B

10-8

10-8

lO-11

lO-11

lO-IB

Il-l

ll-l

ll-l

ll-l

ll-5

ll-7

ll-ll

ll-12

11-12

11-15

11-22

11-29

11-33

11-33

V
XII DISTRIBUTED DATA BASE MANAGEMENT SYSTEM 12-1

XIII

XlV

XV

l.O INTRODUCTION

l.l Background

1.2 Issues

1.3 Trade Study Criteria

1.4 Applicable Options

1.5 Alternatives

2.0 METHODOLOGY

3.0 RESULTS

3.1 Data Base Segmentation

3.2 Space/Ground Partitioning

3.3 SSP DB Segment Characterization

4.0 CONCLUSION, RECOMMENDATIONS AND REMAINING ISSUES

4.1 Space Station Operational Data Base

4.2 Remaining Issues

5.0 REFERENCES

APPENDIX A

SYSTEM INTEGRATION TEST AND VERIFICATION (SITV) TRADE STUDY

l.O

2.0

3.0

TRADE STUDY DEFINITION

l.l Purpose of Trade Study

1.2 Background

1.3 Issues

1.4 Trade Study Criteria

TRADE STUDY METHODOLOGY

TRADE STUDY DISCUSSION AND RESULTS

3.1 Ground Integration Effort for the SSDS

3.2 Ground Integration Effort for the Launch Modules

3.3 Pre-Launch End-to-End SSDS Verification Effort

3.4 Pre-Launch Integration Effort for Growth Phase

Elements

CREW WORKSTATION

2.0 CREW WORKSTATION TRADE STUDY

2.0.I Displays Selection

2.0.2 Color Display vs Monochrome

2.0.3 Input Controls Selection

2.0.4 Caution and Warning System Selection

MASS STORAGE

l •

2.

3.

4.

5.

6.

7.

8.

Reason for Trade Study

Background

Issues

Trade Study Criteria

Expected Results

Methodology

Trade Study Discussion and Results

Conclusions

12-3

12-3

12-5

12-9

12-9

12-10

12-2B

12-30

12-30

12-35

12-39

12-40

12-42

12-43

12-46

13-I

13-I

13-1

13-1

13-9

13-10

13-11

13-12

13-12

13-14

13-1B

13-21

14-1

14-3

14-12

14-24

14-29

14-41

15-I

1 5-3

1 5-3

1 5-7

1 5-7

15-10

15-10

15-12

15-51

vi
XVI

XVII

COMMANDANDRESOURCEMANAGEMENT

l.O

2.0

3.0

4.0

5.0

TRADE STUDY DEFINITION

l.l Reason for Trade Study

1.2 Background

1.3 Candidate System Options

1.4 Issues

1.5- Trade Study Criteria

METHODOLOGY

RESULTS

CONCLUSIONS, RECOMMENDATION AND ISSUES

REFERENCES

SPACE COMMUNICATIONS

l.O

2.0

3.0

4.0

S.O

INTRODUCTION

GROUND-SPACE ARCHITECTURE

2.1 Ground to Space Architecture Options

2.2 Conclusion

DOWNLINK TRANSMISSION OPTIONS

3.1 Tradeoff Considerations

3.2 Conclusions

UPLINK TRANSMISSION OPTIONS

4.1 Channel Allocation Scheme No. l

4.2 Channel Allocation Scheme No. 2

4.3 Conclusion

INTERNAL (PLATFORM) ARCHITECTURE OPTIONS

5.1 Bus Network vs Switched Distribution Structures

5.2 Bus/Network Options

5.3 Conclusions

16-1

16-3

16-3

16-3

16-6

16-6

16-12

16-16

16-16

16-19

16-20

17-1

17-1

17-2

17-2

17-7

17-B

17-9

17-12

17-12

17-13

17-13

17-13

17-13

17-15

17-15

17-17

vii
GLOSSARY

A

A&R

A/A

A/O

AlL

A/N

AC&S

ACA

ACO

ACS

ACS/COM

ACTS

AD

AD

ADOP

ADP

AFOSR

AFP

AFRPL

AGC

AGE

AI

AIE

AIPS

ALl

ALS

ALS/N

AMIC

ANSI

AOS

AP

APD

APSE

ARC

Automatic

Automation and Robotics

Analysts/Architecture

Advanced Development

Alrlock

Alphanumeric

Attltude Control System

Attitude Control Assembly

Administrative Contracting Officer

Attltude Control and Stabilization

Attitude Control System/Communlcatlons

Advanced Communications Technology Satellite

Ancillary Data

Advanced Development

Advanced Olstrlbuted Onboard Processor

Advanced Development Plan

Air Force Office of Scientific Research

Advanced Flexible Processor

Air Force Rocket Propulsion Laboratory

Automatic Gain Control

Attempt to Generalize

Artlflclal Intelligence

Ada Integrated Environment

Advanced Information Processing System

Air Lock One

Alternate Landing Site

Ada Language System/Navy

Automated Management Information Center

American Natlonal Standards Institute

Acquisition of Signal

Automatic Programming

Avalanche Photo Diode

Ada Programming Support Environment

Ames Research Center

P_CEDING PAGE BLANK _OT

ix
ART

ASCII

ASE

ASTROS

ATAC

ATC

ATP

ATPS

ATS

AVMI

ANSI

B

BARC

BB

BER

BIT

BITE

BIU

BIU

BIU

BMD

BTU

BW

C

C2

C3

C3I

C&DH

C&T

C&T

C&kl

C/L

CA

CAD

CAE

CAIS

CAM

Automated Reasoning Tool

American Standard Code for Information Exchange

Airborne Support Equipment

Advanced StarTarget Reference Optical Sensor

Advanced Technology Advisory Committee

Atr 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

Bit Error Rate

Bullt-ln Test

Bullt-ln Test Equlpment

Buffer Interface Unit

Bus Interface Unlt

Bullt-ln Unlt

Balllstlc M1sslle Defense

British Thermal Unlt

Bandwidth

Constralned

Command and Control

Command, Control, and Communlcatlon

Command, Control, Communlcatlon, and Intelligence

Communlcatlons and Data Handllng

Communlcatlon and Tracklng Subsystem

Communlcatlons and Tracking

Control and Warning

Checklist

Customer Accommodation

Computer-Alded Design

Computer-Alded Engineering

Common APSE Interface Set

Computer-Aided Manufacturing

X
CAMAC

CAP

CASB

CASE

CATL

CBD

CBEMA

CCA

CCB

CCB

CCC

CCD

CCITT

CCITT

CCMS

CCR

CCSDS

CCTV

cd/M 2

COG

COMA

COOS

CDR

CDS

CE

CEI

CER

CFR

CFS

CG

CIE

CIL

CIU

CLAN

CM

CM

CMOB

Computer Automatic Measurement and Control

Crew Activities Plan

Cost Accounting Standard Board

Common Application Servtce 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 Oevlce

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 Olvlslon Multiple Access

Customer Data Operations System

Critical Design Review

Control Data Subsystem

Conducted Emission

Contract End-ltem

Cost Estimating Relationship

Code of Federal Regulations

Cambridge Flle Server

Center of Gravity

Customer Interface Element

Critical Item List

Customer Interface Unit

Core Local Area Network

Configuration Management

Center of Mass

Configuration Management Data Base

xi
CMG

CMOS

CMS

CMU

CO

COF

COL

CORM

COP

COPCC

COPOCC

COTS

CPCl

CPU

CQL

CR

CR

CR&D

CRC

CRF

CRSS

CRT

CS

CSD

CSDL

CSMA/CD/TS

CSTL

CTA

CTE

CUI

CVSD

CWG

D&B

DADS

DAIS

OAR

Control Moment Gyro

Complementary Metal-Oxide Semiconductor

Customer Mission Specialist

Carnegle-Mellon University

Contracting Officer

Component Origination Form

Controlled Operations Library

Commercial Missions

Co-orbital Platform

Coorbtt Platform Control Center

COP Operations Control Center

Commercial Off-the-Shelf Software

Computer Program Configuration Item

Central Processing Untt

Channel Queue Limit

Compression Ratio

Change Request

Contract Research and Development

Cyclic Redundancy Checks

Change Request Form

Customer Requirements for Standard Services

Cathode Ray Tube

Conducted Susceptibility

Contract Start Date

Charles Stark Draper Laboratory

Carrler-Sense Multiple with Access/Collision Detection and Time

Slots

Controlled System Test Ltbrary

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

xii
DARPA

OB

DBA

DBRL

DBRS

DCAS

DCDS

DCR

DDBN

DDC

DOT&E

DEC

DES

DFD

DGE

DHC

DID

DIF

DRA

ONS

ODD

DONSAT

DOS

DOT

DPCR

DPS

OR

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

Data Change Request

Distributed Data Base Ranagement

Discipline Data Center

Design, Development, Testing, and Engineering

Olgttal Equipment Corp.

Data Encryptlon Standard

Data Flow Diagram

Otsplay 6eneratton 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

Differentia] Pulse Code Modulation

Data Processing System

Discrepancy Report

Data Requirement

Dynamic Random-Access Memory

Design Requirement Document

Development Simulation and Tratnlng

Distributed System Data Base

Data Storage Description Language

Data System Dynamic Slmulatlon

Development, Simulation, Integration and Training

Deep-Space Network

Design to Cost

..°

XIII
DTC/LCC

OTG

E/R

EADI

ECC

ECLSS

ECMA

ECP

ECS

EDF

EEE

EHF

EHSI

EIA

EL

EM

EMC

EMCFA

EME

EMI

EMR

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

Entity/Relationship

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

Electronic Horizontal Situation Indicator

Electronic Industry Association

Electrolumtnescent

Electromagnetic

Electromagnetic Compatibility

Electromagnetic Compatibility Frequency Analysis

Earth Mean Equator

Electromagnetic Interference

Executive Management Review

Engineering Master Schedule

Extravehicular Mobility Unit

Extravehicular Maneuvering Unit Decontamination System

Electro-optlc

End of Llfe

Earth Observing System

Environmental Protection Agency

Electrical Power System

Earth Radiation Budget Experiment

Equipment Replacement and Refurbishing Plan

Engineering Support Request

Electronic Systems Test Laboratory

Extravehicular Activity

Fault Tolerant

Ford Aerospace and Communications Corporation

Functionally Automated Database System

xiv
FAR

FCA

FCOS

FCR

FDDI

FDF

FDMA

FEID

FETMOS

FF

FFT

FIFO

FIPS

fl

FM

FMEA

FMECA

FO

FO/FS/R

FOC

FODB

FODS

FPR

FQR

FSD

FSE

FSED

FSIM

FSW

FTA

FTMP

FTSC

GaAs

GaAsP

GalnP

GaP

GAPP

Federal Acquisition Regulation

Functional Configuration Audit

Flight Computer Operating System

Flight Control Rooms

Fiber Distributed Data Interface

Flight Dynamics Facility

Frequency-Division Multiple Access

Fltght Equipment Interface Device

Floating Gate Election Tunneling Metal Oxide Semiconductor

Free Flier

Fast Fourter Transform

First In First Out

Federal Information Processing Standards

foot lambert -Untt of Illumination

Facility Management

Failure Modes and Effects Analysis

Failure Mode Effects and Crltlcallty Analysls

Fiber-Optlcs

Fall-Operational/Fall Safe/Restorable

Flber-Optlc Cable

Flber-Optic Data Bus

Fiber Optic Demonstration System

Federal Procurement Regulation

Formal Qualification Review

Full-Scale Development

Flight Support Equipment

Full Scale Engineering Development

Functional Simulator

Flight Software

Fault Tree Analysis

Fault Tolerant Multi-Processor

Fault Tolerant Space Computer

Gallium Arsenlde

Gallium Arsenic Phosphorus

Gallium Indium Phosphorus

Gallium Phosphorous

Geometric Arithmetic Parallel Processor

XV
Gbps

GBSS

GEO

GEP

GFC

GFE

GFP

GFY

GIDEP

6_q

6MS

GMT

GMW

6N&C

GPC

GPP

GPS

GRO

GSC

GSE

GSFC

GTOSS

H/W

HAL

HDDR

HDDR

HEP

HFE

HIPO

HIRIS

HM1

HR

HOL

HOS

HPP

HRIS

I

Glgabtts Per Second

Ground Based Support System

Geosynchronous Earth Orbit

Gas Electton Phosphor

Ground Forward Commands

Government-Furnished Equipment

Government-Furnished Property

Government Fiscal Year

Government/Industry Data Exchange Program

Geometric Math Rodel

Geostatlonary Meteorological Satellite

Greenwich Mean Time

Generic Maintenance Work Station

Guidance, Navigation, and Control

General-Purpose Computer

General-Purpose Processor

Global Positioning System

Gamma Ray Observatory

Ground Service Center

ground Support Equipment

(Robert H.) Goddard Space Fltght Center

Generalized Tethered Object System Simulation

Hardware

High-Order Algorithmic Language

Help Desk Discrepancy Report

Hlgh Density Dlgltal Recording

Heterogeneous Element Processor

Human Factors Engineering

H1erarchlcal Input Process Output

High Resolutlon Imaging Spectrometer

Habitation Nodule One

Habitation Module

High Order Language

High Order Systems

Hlgh Performance Processors

High Resolutlon Imaglng Spectrometer

Interactive

xvi
I/F

I/0

IBM

IC

ICAM

ICB

ICD

ICOT

ICS

IO

ID

IDM

IDMS

IEEE

IEMU

IF

IFIPS

ILD

IMU

INS

IOC

lOP

IPCF

IPC

IPL

IPR

IPS

IR

IR&D

IRN

ISA

ISA

ISDN

ISO

ITAC-O

ITT

IV&V

Interface

Input/Output

IBM Corporation

Intercomputer

Integrated Computer-Alded Manufacturing

Internal Contractor Board

Interface Control Document

Institute (for new generation) Computer Technology

Interpretive Computer Simulation

Interface Diagram

Identification

Intelligent Database Machine

Information and Data Management System

Institute of Electrical and Electronic Engineers

Integrated Extravehicular Mobility Untt

Intermediate Frequency

International Federation of Industrial Processes Society

Injector Laser Diode

Inertial Measurement Unit

Inertial Navlgatlon System

Initial Operating Capability

Input/Output Processor

Interprocess Communications Facility

Interprocesses Communication

Initial Program Load

Internal Problem Report

Instrument Pointing System

Infrared

Independent Research and Development

Interface Revision Notices

Inertial Sensor Assembly

Instruction Set Architecture

Integration Services Digital Network

International Standards Organization

Integration Trades and Analysls-Cycle 0

International Telegraph and Telephone

Independent Validation and Verification

xvii
IVA

IWS

3PL

3SC

KAPSE

KEE

KIPS

KOPS

KSA

KSC

Kbps

Ktpc

LAN

LaRC

LCC

LCD

LDEF

LDR

LED

LEO

LeRC

LIDAR

LIFO

LIPS

LISP

LlsP

LLC

LMI

LN2

LNA

LOE

kOE

LOS

LPC

kPS

LRU

LSA

Intravehlcular Activity

Inte111gent Work Station

Jet Propulsion Laboratory

(Lyndon B.) 3ohnson Space Center

Kernal APSE

Knowledge Engineering Environment

Knowledge Information Processing System

Thousands of Operations Per Second

Ku-band, Stngle Access

(3ohn F.) Kennedy Space Center

Kllobtts per second

Thousand instructions per cycle

Local-Area Network

Langley Research Center

Life-Cycle Cost

Liquid Crystal Display

Long-Duration Exposure Factltty

Large Deployable Reflector

Light-Emitting Diode

Low Earth Orbit

Lewis Research Center

Laser-Instrument Distance and Range

Last In First Out

Logical Inferences Per Second

List Processor

Ltst Processor

Loglcal Link Control

LISP Machine Inc.

Liquid Nitrogen

Low-noise Amplifier

Level of Effort

Low-earth Orbit Environments

Loss of Signal

Linear Predictive Coding

Launch Processing System

Line-Replaceable unit

Logistic Support Analysis

..°

XVIII
LSAR

LSE

LSI

LTV

LZPF

M

.P

MA

MA

MAPSE

Mbps

MBPS

MCAIR

MCC

MCC

MCDS

MCM

MCNIU

MDAC-HB

MDAC-STL

MDB

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 Otvlston

Level 0 Processing Facility

Manual

Microprocessor

Multiple Access

Managing Activity

Minimum APSE

Million Blts Per Second

Million Bits Per Second

McDonnell Aircraft Company

Mission Control Center

Mlcroelectronlcs and Computer Technology Corp.

Management Communications and Data System

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

Multiple-lnput Multlple_Output

Million (machine) Instructions Per Second

Massachusetts Institute of Technology

Ministry of International Trade and Industry

Multlspectral Linear Array

Man Machine Interface

Mlcrogravlty and Materials Process Facility

Module Management System

Momentum Management System

Mass Memory Unlt

xix
MMU

MNOS

MOC

MOl

MOL

MOS

MPAC

MPS

MPSR

MRMS

MRWG

MSFC

MSI

MSS

MTA

MTBF

MTTR

MTU

NASA

NASCOM

NASPR

NBO

NBS

NCC

NFSO

NGT

NHB

NISON

NIU

NL

NLPQ

NMI

NMOS

NMR

NOS

NS

NSA

Manned Maneuvering Unlt

Metal-Nltrlde Oxide Semiconductor

Mlsslon Operatlons Center

Moment of Inertla

Manned Orbltlng Laboratory

Metal Oxlde Semlconductor

Multlpurpose Application Console

Materials, Processlng In Space

Multl-purpose Support Rooms

Moblle Remote Manlpulator System

M1sslon Requlrements Worklng Group

(George C.) Marshall Space Fllght.Center

Medlum-Scale Integratlon

Multlspectral Scanner

Man-Tended Approach

Mean Time Between Fallures

Mean Time to Repalr

Master T1mlng Unlt

National Aeronautics and Space Administration

NASA Communications Network

NASA Procurement Regulation

NASA Basellne

Natlonal Bureau of Standards

Network Control Center

NASA FAR Supplement Directive

NASA Ground Terminals

NASA Handbook

NASA Integrated System Data Network

Network Interface Unlt

Natlonal Language

Natlonal Language for Queuing S1mulatlon

NASA Management Instruction

N-Channel Metal-Oxlde Semiconductor

N-Modular Redundant

Network Operatlng System

Nass1-Schneldermann

National Securlty Admlnlstratlon

xx
NSF

NSTS

NTDS

NTE

NTRL

NTSC

Nd:YAG

O&M

O/B

OASCB

OCN

ODB

ODBMS

OEL

OES

OID

OLTP

OMCC

OMV

ONR

ORU

OS

OSE

OSI

OSM

OSSA

OSTA

OSTDS

OTV

P&SA

P/L

PA

PAM

PASS

PBX

PC

PCA

National Science Foundation

National Space Transportation System

Navy Tactical Data System

Not To Exceed

NASA Technology Readiness Level

National Television Standards Committee

Neodyntum Yttrlum 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 Ltst

Operating Events Schedule

Operations Instrumentation Data

On Ltne Transaction Processing

Operations Management and Control Center

Orbital Maneuvering Vehicle

Office of Naval Research

Orbital Replacement Unit

Operating System

Orbit Support Equipment

Open Systems Interconnect

Orbital Service Module

Office of Space Science and Applications

Office of Space and Terrestrial Application

Office of Space Tracking and Data Systems

Orbital Transfer Vehicle

Payload and Servicing Accommodations

Payload

Product Assurance

Payload Assist Module

Primary Avionics Shuttle Software

Private Branch Exchange

Personal Computer

Physical Configuration Audit

xxi
PCA

PCM

PCR

PDP

PDR

PDRD

PDRSS

PILS

PIN

PLA

PLAN

PLSS

PMAD

PMC

PN

POCC

POP

POPCC

POPOCC

PRISM

PSA

PSA

PSCN

PSL

PTR

QA

R

R&O

R&OA

R/N/A

R/T

RAD

RAN

RAP

RC

RCA

RCS

Program Change Authorization

Pulse Code Modulation

Program Change Request

Plazma Olsplay Panel

Prellmlnary Oeslgn Revlew

Program Oeflnltlon and Requirements Document

Payload Deployment and Retrleval System S1mulatlon

Payload Integratlon llbrary System

Personal Identlflcatlon Number

Programmable Loglc Array

Payload Local Area Network

Payload Support Structure

Power Management and Distribution

Permanently Manned Configuration

Pseudonolse

Payload Operations Control Center

Polar Orbiter Platform

Polar Orbit Platform Control Center

POP Operations Control Center

Prototype Inference System

Problem Statement Analyzer

Preliminary Safety Analysis

Program Support Communications Network

Problem Statement Language

Problem Trouble Report

Quality Assurance

Restricted

Research and Development

Reliability and Quality Assurance

Reliability/Maintainability/Availability

Real Time.

Unit of Radiation

Random Access Memory

Relational Associative Processor

Rtng Concentrator

RCA Corporation

Reaction Control System

xxii
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

Reconfiguratton Network

Read Only Memory

Reuseable Orbit Transfer Vehicle

Resource Planning and Management System

Reed-Solomon

Rtvest, Skamlr and Adleman (encryptlon method)

Real Time Execution

Sensor and Effector

Spacecraft

Software

Single Access

Structured Analysis

Science and Technology Mission

Society of Automotive Engineers

Shuttle Avionics Integration Laboratory

Science and Appllcatlons Information System

Synthetic Aperture Radar

Software Approval Sheet

Specific Appllcatlon Service Elements

Station Accommodations Test Set

Slngle Board Computer

Simulation Center

Software Change Request

Solar Cosmic Ray

xxiii
SCS

SDC

SDP

SDR

SOTN

SE&I

SEI

SESAC

SESR

SESS

SEU

SFOU

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 Untt

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 Operatlons and Planning Complex

Silicon On Saphlre

Statement of Work

Stored Payload Commands

Software Productlon Facility

Slngle-Polnt Failure

Spacelab Problem Reports

Software Problem Report

Software Quality Assurance

Software Quality Assessment and Measurement

SEQUEL Data System

Support Requirements Analysis

Static Random Access Memory

xxiv
SRB

SRC

SREM

SRI

SRM&OA

SRMS

SRR

SS

SSA

SSA

SSCB

SSCC

SSCR

SSCS

SSCTS

SSDMS

SSOR

SSDS

SSE

SSEF

SSIS

SSME

SSO

SSOCC

SSOCC

SSOL

SSON

SSOS

SSP

SSPE

SSPO

SSSC

SSST

STAR

STARS

STDN.

STI

Software Review Board

Specimen Research Centrifuge

Software Requlrements [nglneerlng Methodology

Stanford Research Institute

Safety, Reliability, Ralntalnablltty, and Quality Assurance

Shuttle Remote Manipulator System

System Requirements Review

Space Station

Structural Systems Analysis

S-band Stngle Access

Space Station Control Board

Station Station Communication Center

Support Software Change Request

Space Station communlcat_on system

Space Statlon communlcatlons and tracklng system

Space Statlon data management system

Support Software 01screpancy Report

Space Station data system

Software Support Environment

Software Support Environment Facility

Space Station Informatlon System

Space Shuttle Maln Englne

Source Selectlon Official

Space Station Operatlons Control System

Space Station Operations Control Center

Space Statlon Operation Language

Spacelab Software Operational Notes

Space Station Operatlng System

Space Station Program

Space Statlon Program E]ement

Space Statlon Program Office

Space Station Standard Computer

Space Station System Tralner

Self Test and Recovery (repalr)

Software Technology for Adaptable and Rellab]e Software

Standard Number

Standard Technical [nstltute

xxv
STO

STS

SUSS

SYSREM

St

SubACS

TAI

TBD

TBU

TC

TCP

TCS

TDASS

TDM

TDHA

TDRS

TDRSS

TFEL

THURIS

TI

TM

TM

TMDE

TMIS

TMP

TRR

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 Ttme

To Be Determined

Telemetry Buffer Untt

Telecommand

Transmissions Control Protocols

Thermal Control System

Tracking and Data Acquisition Satellite System

Technology Development Mission

Tlme-Dlvlslon Multiple Access

Tracking and Data Relay Satellite

Tracking and Oata Relay Satellite System

Thln Film 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 Working Group

Technical Requirement

Texas Reconflgurable Array Computer

Transition Radiation and Ionization Calorimeter

Trade Study Control

Technical Study Implementation Plan

Twisted Shielded Pair

Tethered Satellite System

Telemetry, Tracking, and Communications

Telemetry Traffic Control

xxvi
TTR

TWT

U

UCC

UDRE

UIL

UON

UPS

URN

UTBUN

UTC

V&V

VAFB

VAX

VHSIC

VLSI

VLSIC

VV&T

WAN

WBS

WBSP

WDM

WP

WRO

WS

WSGT

WTR

XDFS

YAPS

ZOE

ZONC

ZnS

Timed Token Ring

Traveling-Wave Tube

Non-restrictive

Uniform Commercial Code

User Design Revtew and Exercise

User Interface Language

Unique .Ob3ect Names

Uninterrupted Power Source

Unique Record Name

Unique Telemetry Buffer Unit Name

Universal Coordinated Time

Validation and Verification

Vandenberg Air Force Base

Virtual Address Exchange

Very High-Speed Integrated Circuit

Very Large-Scale Integration

Very Large-Scale Integrated Circuit

Validation, Verification and Testing

Wtde Area Network

Work Breakdown Structure

Wldeband Signal Processor

Wavelength Dtvlslon Multiplexing

Work Package

Work Release Order

Workstation

White Sands Ground Terminal

Western Test Range

XEROX Distributed Ftle System

Yet Another Production System

Zone Of Exclusion

Zone Of Non-Contact

Ztnc Sulfide

xxvii
Volume II

TASK 3 - TRADE STUDIES

This volume contains trade studies for Section IX through Section XVII of the

Trade Studies Report. Table I lists all trade studies by subject ?or both

Volumes I and II. The reader is re?erred to the introductory sections o?

Volume I relating to the methodology For conducting the trade studies.
Table 1

kl.l

_,.J

0

SECTION

I°

II.

III.

IV.

V.

VI.

VII.

VIII.

IX.

X.

XI.

XII.

XIII.

XIV.

XV.

XVI.

XVII.

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

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
IX. SOFTWARE DEVELOPMENT TEST & INTEGRATION CAPABILITY

g-1
SOFTWAREDEVELOPMENT,

TESTANDINTEGRATIONCAPABILITYTRADESTUDY

1.0 INTRODUCTION

The purpose of this trade study is to compare and contrast three methods of

providing a test and integration capability. Since more knowledge about the

DMS will need to be known before one method can be determined to be better

than the other, this trade study will concentrate on comparing and contrasting

the different options under various assumptions.

The trades study will only directly address the onboard data management system

including core subsystems and payload applications. Associated space vehicles

and ground systems are not directly addressed. However, one of the trade

study criteria is to evaluate the options for expandability and flexibility so

that they could be used for testing of future systems such as the ground

system, free flyers, etc.

1.1 BACKGROUND

The Space Station data processing system will be large, complex and

distributed. The test and integration capability must be able to support

execution of a large amount of code. Because the system will be distributed

the test facility must support concurrent processes and multiple processors

while providing diagnostic control over ali processes. It must provide this

diagnostic control without seriously affecting the system timing and

synchronization. The communication between the processors will involve a high

volume of bus traffic that must be monitored and diagnosed. Finally, since

the software for the system will be developed by multiple contractors, the

test and integration capabilities must support a coordinated effort.

1.2 ISSUES

The creation of an adequate test and integration capability for a distributed

system will be difficult and some of the reasons are:

P_ECEDiNG PAGE BLAf_ NOT FILMED

9-3
1. The systems will be complex.

2. Multiple processors must be observed (dispersed test objects).

3. Concurrent processing must be observed.

4. System timing and synchronization must be preserved.

5. There will be a high volume of bus traffic (large amounts of I/O).

6. The software integration will involve software from many different

contractors.

7. Test methodologies for distributed system are not well developed or mature.

The test and integration capability may have additional problems to address

due to some of the specific characteristics of the Space Station system. Some

of these problems could be:

i. Lack of sufficiently available target hardware for testing purposes.

2. Lack of appropriate test connectors and other diagnostic equipment to be

provided with the processor hardware.

3, Lack of commercially available diagnostic hardware and software packages

for use with the target hardware.

4. Use of multiple kinds of processors.

5. Use o? multiple programming languages.

An additional known issue specific to the Space Station system is the

requirement to be flexible and expandable enough to support technology

insertion and to be reusable for other future space systems.

1.3 TRADE STUDY CRITERIA

1.3.1 GENERIC

1.3.1.1 COSTS

DEVELOPMENT(NON-RECURRING): These include all costs to design and build the

first working system.

9-4
UNIT(RECURRING):These include costs for providing additional working systems.

LIFE CYCLE: These include all costs to maintain working systems, train new

users to test software using the systems, and providing user assistance.

I. 3.1.2 RISK

DEVELOPMENT(TECHNOLOGY READINESS, DESIGN DIFFICULTY): There is an amount of

risk involved in projecting what the current technology will be when the

system is designed.

PRODUCTION(PRODUCIBILITY, COST/SCHEDULE, EFC): There is also an amount of

risk in projecting the state of technologies (such as high speed processors,

etc.) that will exist when the test system is put into use.

1.3.1.3 PERFORMANCE

This criterion addresses the effectiveness of the testing system resulting

from a given method. For example, the test system could be ineffective

because of being finished too late for software development, insufficient

capability, poor availability, etc. The test system would be effective if it

finds errors, is user friendly, and is cost effective to build and operate.

I .3 .I .4 STANDARDIZAI"ION/COMMONAL:rTY

The possibility of using common available hardware and software will be

considered. In general providing common (and possibly commercially available)

hardware and software building blocks for the system will reduce cost,

training and maintenance.

1.3.1.5 GROWTH/"FECHNOLOGY INSERTION POTENTIAL

The flexibility of the systems resulting from each method will be considered.

This includes the flexibility to:

9-5
I. Upgrade to new target hardware

2. Expand the capability of the test system (insert new test equipment

technologies)

3. Test systems other than Space Station

1,3.2 TRADE STUDY UNIQUE

1.3.2.1 LOANER SET POTENTIAL

For off site testing the SSE must provide a "loaner set". This is a minimum

test capability so that testing can be done at contractor software development

sites, It is to be a stand-alone autonomous test facility, The cost of

providing a "loaner set" based on a given option will be considered.

1,3.2.2 DISTRIBUTED SYSTEM APPLICABILITY

Distributed systems testing is a very immature technology so there will be an

amount of risk with each method. Relative risks of the methods will be

indicated during the comparison. The three levels of risk considered are:

i. Risk of resulting in an unusable system.

2. Risk of resulting in a poorly usable system.

3. Risk o? resulting in an unmaintainable or expensive system.

1.4 APPLICABLE OPTION PAPERS

o Software Development Options White Paper - SSDS A/A study task 2

9-6
1,5 ALTERNATIVES

The three options comparedare

i. Executing the software in an emulation of the target hardware(1).

2. Executing the software in the target hardware.

3. Executing the software in an facility that is partly target hardware and

partly emulated target hardware.

For the remainder of this paper TARGETHARDWAREwill be defined to be the

expected Space Station Data Managementprocessors. These are the Bus

Interface Units, SubsystemData Processors and any unique processors that

might be present for specific application software.

9-7
2.0 METHODOLOGY

Background information was obtained by studying the papers listed in the

reference section and from experience with the following projects.

0

o

0

0

FSD Houston Onboard Shuttle Systems

FSD Manassas SUBACS Project

KSC Launch Processing System

JSC Advanced Project Simulation Interface Buffer (SIB) Study

Next, for each option, the operational concept for the Space Station system

was studied and compared to previous project experience using the trade study

criteria.

3.0 RESULTS

3.1 BASIC SUMMARY

l'he main advantages of the emulation strategy are:

o It allows a great amount of control over the execution of the target code.

By not requiring the use of any special hardware, this strategy is very

available. Since the test facility is just software, it can be used by

many people at the same time at any location where there is a supporting

host computer. For very low level testing such as unit testing the tests

might be run on an intelligent workstation.

o The technology for building an emulation test facility is known.

The main disadvantages of the emulation strategy are:

It requires a significant amount of software development to build the

emulator, lhis relates to a fairly high development cost.

9-8
It is not flexible. If the target hardware (instruction set architecture)

changes then so must the emulator. This relates to high maintenance co,_ts.

It requires an extensive amount of cpu time per amount of simulated run

time. If long simulations are desired then this relates to a high

operational cost.

o It does not provide a realistic operating environment.

The main advantages of target hardware use are:

If the real hardware is available then this would be the easiest facility

to setup. Howeverunless special hardware and software is added to

provide diagnostics, this is unsuitable for testing. For a distributed

system there are somefundamental difficulties(2) in developing add-ons to

the target hardware to develop a usable test facility.

/he real hardware obviously provides a more realistic test facility.

However all the add-ons tend to decrease the realism.

The main disadvantages of target hardware use are:

o If the target hardware is not available until late into the

development/integration cycle then this strategy is not viable.

0 The configured target hardware system may be very expensive to provide in

a reasonable quantity so that it will be available to all testers. This

relates to either a high operational cost or poor availability.

o It will be very difficult to obtain a controlled test capability (e.g.,

diagnostics may alter the timing of software execution in target hardware).

2 VISIBII_ITY INTO THE II_'I'ERNAL OPERATION OF" A DISTRIBUTED PROCESSING SYSTEM

by L. Killingbeck IRAD project 4H02

9-9
The main advantages of target hardware/emulation combination are

It provides a number of design options that may help reduce the

development risk and cost.

o A capability based on this option could be expanded so that problems found

when software is operating in a target hardware processor could be

diagnosed in by running the software in an emulator while the rest of the

system is in target processors.

The main disadvantages of target hardware/emulation combination are

It requires an amount of new technology to interface an emulating

processor with a real hardware processor.

Since both hardware and emulation are used this option, it has the

combined disadvantages of the first two options.

3.2 BACKGROUND INFORMATION

3.2.1 EMULATION

The emulation strategy for an test and integration capability would involve no

use of the target hardware during testing. Instead, an emulation of the target

hardware would be used. A software program would simulate execution of

instructions of the SDP or-BIU in a host computer. This is depicted in Figure

I. The Shuttle Primary software has had experience using a test capability

based on an emulation approach. The onboard operating system (FCOS) was first

tested using a capability that was called Interpretive Computer Simulation

(ICS). The emulation portion of ICS was developed by the designers of the

onboard computer (AP-I01) to test the design of the AP-101. It modeled the

internal logic of the computer. This emulator was brought to Houston where

additional diagnostic features and a user interface were added. ICS was then

used by the developers of the operating system, who were coding in assembly

language, to test their software. This method of testing worked very we11.

The diagnostic Features provided allowed the developers to test and debug

their software very effectively.

9-10
Concurrent Users:

User No. 1

User No. 2

User No. m

m

laa====,

m

Test

Command

User

Interface

Support Com

1

I

I

I

I

I

I Common

I Test

I Functions

I and Models

I

I

I

I

I

purer

Test 1

Emulation

Test 2

Emulation

Test m

Emulation

Figure 1. Emulation option configuration

9-11
There were some disadvantages to using ICS. It was very slow. The run ratio

(amount of host cpu time per time of simulation) varied but was about IOO to 1

(on an IBM $360/75). This was not a significant problem as long as the tests

were only a few seconds in length which was all that was initially needed by

the operating system developers. Another disadvantage was that no

environmental or sensor/effector modeling was supplied. This again was not a

significant problem to the initial operating system testing. However

application developers need longer test run times and modeling capabilities to

do their testing.

Another test facility was provided for application developers. This was

called Functional Simulator (FSIM). The application developers did their

programming in a high level language and could compile their source code into

the host native code for execution. Since the real operating system could not

be supplied because it was written in AP-iOl assembly language, a model of the

operating system was supplied. This caused some difficulty because operating

system development was still going on after FSIM was developed. Thus the

modeled operating system did not always match the real operating system.

3.2.2 TARGET HARDWARE USAGE

This option would involve executing the software in the actual target

hardware. Additional special hardware devices would need to be attached to

the target hardware to provide diagnostics. This is depicted in Figure 2.

While ICS and FSIM were being used to do Shuttle testing, another test

facility was being developed. This new test facility involved using an AP-iO1

computer (GPC) and Input/Output Processor (IOP). The GPC was supplied with

what was called a test connector (or AGE connector). This was used by the

hardware developers to do hardware testing. A device called a Flight

Equipment Interface Device (FEID) was built that interfaced both the GPC via

its test connector and the IOP via its ports to the host computer. This

setup allowed stop/starting of the GPC/IOP, access to their memory and general

9-12
ConcurrentUsers:

i

q

Test Support Computer

I

I

I

Common Common

User Test

Interface Functions

and Models

I

Target

Device

Inlerfaces

HIU = Host Inlerlace Unil

TC = Test Connector

S/E = Backplane Sensors/

Ellectors ,

Figure 2. Maximum Flight Hardware option configuration

9-13
I/O capability. The host ran all the simulator models that generated inputs

for the GPC/IOP, software that interfaced the models and the FEID, and

software that interfaced with the FEID to perform diagnostic actions. This

setup allowed the target processors to be used for testing while allowing a

very large amount of diagnostic and simulation capability. The run ratios for

this setup are close to real time.

The FEID setup is a fairly complex and expensive test facility. For the

majority of the time that development and test were being done only three

FEIDs were available. A facility such as this may not be practical to provide

in a 'loaner set'

There are a significant number of difficulties in using a test facility such

as this for testing a distributed system. A distributed system would involve a

number of processors. Stopping and starting these processors without severely

affecting the timing and synchronization of the system would be extremely

difficult. There is also a problem with losing I/O. When the processors are

stopped, the data coming to it on the bus must be captured until the processor

begins receiving again. Even then the processor must catch up on all the data

it missed. This will be a serious problem because of the high volume of bus

traffic anticipated in the Space Station system.

Another problem would arise if the target processors do not have AGE test

connectors such as the AP-I01 had, There were also a number of other

features(2) that the AP-101 provided that were taken advantage of in the

development of the FEID. The lack of any one of these would make the

development of this type of test capability more difficult.

3,2.3 EMULATION AND TARGET HARDWARE USAGE

This option involves combining the previous two options. The testing would be

done in a configuration where some of the hardware is emulated and the rest is

actual target hardware. Additional hardware and software may be needed to

achieve emulation/target hardware communication. This is depicted in Figure

3. There is no direct experience with using such a system.

9-14
Cooo,,rreo, Ose,s

No. 1 ) I

/" u,er"'L_L

'',._%_ I

No. User m

Test Support Corn )uter

I

I

Common .Common -lardware

User I Test Device

Interace I Functions Interface 4

r

Target

Computer

No. 1

TC

f

land

I Models

I

I

I

Emulation,.,

'

TC ].,

• Target lCounputer

No. 2

I

L_mmmmm_._

I IIU = Host Interface Unit

TC = Test Connector

"S/E = Backplane Sensors/

Efleclors

(S/E)

(S/E)

Figure 3. Combination flight Hardware/Emulation option configuration

9-15
A test capability based on this approach would involve processor emulation

software running in the host along with the models, etc. An interface device

would connect the host and target processor. Some of the software being

tested would run in the emulator and the rest would run on the target

processor. An example of this would be using a target hardware subsystem data

-processor with the BIU and other necessary processors being emulated on the

host. When using this capability, the software that is being tested would be

execute in the emulator. The emulator usually can provide much better

diagnostic capability than the target hardware approach. Since the software

running in the target processor is not the primary test software, less

diagnostic hardware would be requiredfor the target processor.

One of the desired capabilities for the integration test facility(3) is the

following. Suppose during integration testing a problem is isolated to the

software in a particular subsystem. And to diagnose the problem requires

more diagnostic capability than is available with the current configuration.

The test is reconfigured so that the suspect subsystem is running with

detailed diagnostics while the rest of the system is running as before. The

part emulation and part target hardware approach would provide this

capability. The suspect subsystem could be taken out of a target processor

and run in the host emulator while the rest of the system continued to run in

the target hardware.

This approach would be much more flexible while combining the advantages of

the other two options. However a capability based on this approach would be

much more difficult to design and develop. It would require a large dedicated

amount of host cpu to allow the emulation to run at least as fast as real time

so that it would not be necessary to stop the target hardware. If this is not

possible and it is necessary to stop the target hardware, then this would

require the special hardware be used to start and stop the target hardware.

The problems in doing this were discussed earlier.

3 TESTING SOFTWARE IN A TACTICAL BUS-ORIENTED DISTRIBUTED SYSTEM,

Richard F. Rashid and Charles V. Webber, IBM IRAD Project 2M45

9-16
3.3 OPTIONS COMPQRISONS

The purpose of test and integration is to find errors in the interfaces/

communication structure between software modules of a system. When the

modules are interfacing across multiple processes of a distributed system,

integration testing becomes a very challenging and important task. It is

challenging because of the difficulty in creating an adequate test

capability. It is important because of the likelihood of having errors and

the difficulty in locating the specific errors later in system testing. The

likelihood of having errors in the design and code of the distributed

functions is high because designing distributed systems is an immature

technology(3).

Each option has an amount of risk involved. Each would require a significant

amount of time and resources to develop.

The significant development item for the emulation approach would be the

development of the software that emulates the target processor. The

technology For doing this is known so there is little risk of failing to

develop a usable system with this approach. There would be a very significant

amount of manpower needed to design and code the emulator(s). However it is

likely that an emulator can be acquired, as it was for Shuttle, From the

hardware developers.

3,3,1 EMULQI"ION

Since an emulator would not require target hardware, the cost required to

supply additional test Facilities based on this approach would be small. The

only significant cost item is the amount of CPU required to actually run the

emulator.

The potential negative aspects are the Following. If only enough CPU could be

supplied to run the emulator at many times more than real time, then the t_st

capability would be a poorly usable one. As hardware changed, the emulator(s)

9-17
would need to also be changed to correctly model the hardware. Also each new

type of processor added to the system would require the development of another

emulator. This, combined with the complexity of the emulators, might create a

significant maintenance expense. There is a risk in using an emulation test

capability in that the emulator would not correctly model the hardware and the

software system might work correctly on the emulator but not work correctly on

the actual hardware.

3.3,2 TARGET HARDWARE USAGE

There are many significant development items necessary to implement a test

capability that had maximal use of the target processors. Several special

hardware devices would need to be developed to provide diagnostic

capabilities. The additional hardware would require a significant amount of

software to allow users to run test cases using them as the Shuttle project

FEIDs did. Each of these different devices and their associated h_rdware

would involve their own amount of development cost and risk. The test

facility as a whole would require the development of new technology. For

example it is not currently known how to stop/start a distributed system

without seriously affecting the timing of the system.

There is some risk that a test facility based on this approach might not be

able to preserve system timing and thus might not be usable at all. There is

some risk that it might not provide enough diagnostic capability thus

preventing the detection of serious problems until late into the integration,

or they might not be detected at all. Thus it might be a very poorly usable

system. The cost of supplying additional test facilities based on this

approach would be large. For each additional test facility, target processors

and special diagnostic hardware devices would need to be supplied. The

diagnostic hardware would likely be expensive to provide since it is not off

the shelf. Each development group will likely require different mixes and

numbers of processors to do their testing. Rather than providing each

contractor with a common test capability that would have all they would need

and more, it may be necessary (for the sake of cost) to provide contractors

with a customized test facility. As new types of processors are inserted into

the system or new technology is inserted, new problems will need to be

addressed to preserve the use of the test facility.

9-18
3.3.3 EMULATION AND TARGET HARDWARE USAGE

The combined target hardware/emulation approach could be implemented at

different levels. To provide the option to use the target hardware or an

emulation of each type of processor would require as much development effort,

risk, and cost as both previous options combined. An alternative level of use

of this approach would be to first use what is available or is easily

developed. Whatever emulators were already available would be used. An

attempt would be made to use all easily available target hardware. If a

problem were encountered in developing a portion of the test capability using

target hardware, an emulator could be developed instead.

If the host/target hardware interface technology were sufficiently advanced,

this option would provide the least development risk because it offers more

design options. To supply facilities of this type for contractors to use

would cost less than the full target hardware option but more than the full

emulation option. Since there is a significant amount of both software and

hardware to be maintained, this option would result in a high maintenance

cost.

4.0 CONCLUSIONS

In the past software testing and simulations have been done in the same test

environment. Because of the problems in creating a distributed simulation

capability that supports all the diagnostic capabilities needed for software

testing, the two activities may have to be separated.

In the lower levels of integration testing when the processing being tested is

contained in a single computer, the testing can proceed in a conventional

manner using either emulation or the target hardware. Once the level of

integration reaches a point where a high volume of data is passed between

processes operating in different computers, then conventional means using the

actual target hardware may be inadequate for software testing. Instead there

are several alternatives that can be used.

9-19
The system to be tested can be designed so that the functions do not

heavily share data across processors. Clean interfaces can be designed so

that the software in each processor can be tested independently. No

integration testing, other than simulation runs for acceptance testing, is

necessary for these higher,levels of integration.

If the system must be tested using detailed diagnostics and multiple

processors (because of the criticality of the software or because it is

the network operating system), then there are two possibilities. First

the testing could be done using a complete emulation approach. Second,

the necessary diagnostic features could be built into the system being

designed. For example, detailed error logs could be kept by the system

and at specific time could log it to an external device for analysis. The

actual target hardware can still be used with special purpose hardware to

do simulations. These simulations may not support diagnostic capabilities

necessary for detailed software testing.

5.0 REFERENCES

The following papers were studied (note that literature on this subject is not

widely available).

0 VISIBILITY INTO THE INTERNAL OPERATION OF" A DISTRIBUTED PROCESSING SYSTEM,

L. Killingbeck, IBM IRAD Project 4H02.

O TESTING SOFTWARE IN A TACTICAL BUS-ORIENTED DISTRIBUTED SYSTEM, Richard F.

Rashid and Charles V. Webber, IBM IRAD Project 2M45

9-20
X. FAULT TOLERANT COMPUTING

10-1
FAULT TOLERANT COMPUTING TRADE STUDY

1.0 INTRODUCTION

The fault tolerance requirements of the Space Station cannot be met by the use

of a single processing unit, because of the possibility of losing that single

unit through component failure or physical damage. This report compares

several redundancy techniques which can be used to tolerate faults in

computing systems. Since selection of a particular technique depends on the

needs of individual applications, the report is organized to show the methods

available for an application to meet its fault tolerance criteria.

1.1 BACKGROUND

The Space Station will have subsystems with a wide variety of requirements for

fault tolerance. The basic requirement in the Phase B RFP is that all

subsystems which are safety critical (category l) or mission critical

(category) will be fail-operational/fail-safe/restorable (FO/FS/R); i.e.,

fully operational after one failure and operate in a safe mode after two

Failures of the subsystem with the capability to manually restore full

operational capability. Subsystems which are not safety or mission critical

are classified in an "other" category (category 3) and are required to be fail

safe.

The active redundancy implicit in FO/FS/R requires the use of multiple copies

of the critical subsystem elements, which in turn implies penalties of power,

volume, mass and other physical properties, all of which are limited resources

onboard the Space Station. Therefore, less critical subsystems are expected

to use lower levels of active redundancy resulting in, either a lower

probability of isolating the fault to a particular unit or a lower probability

of detecting the fault in the first place. The time needed to recover from a

failure also varies with the particular implementation of fault tolerance,

ranging from sub-seconds for high redundancy levels of active systems to

minutes or hours For physical replacement of units.

PRECEDING PAG£ BLA_ _IOT FILiE:)

10-3
1.2 ISSUES

The basic issues of fault tolerance are:

o

o

o

o

o

o

o

man-tended versus manned operation

the number of faults which must be tolerated

whether these faults must be tolerated simultaneously, or whether

repair or replacement of the fault unit is allowed between failures

the time to recover from a fault

the probability of detecting a fault

the probability of isolating the failed unit after a fault is detected

the nature of the faults to be considered (simple component failure

versus physical destruction of the unit as a whole)

1.3 TRADE STUDY CR:I'TERIA

The trade study criteria used are di'vided in two groups; generic and trade

unique.

1.3.1 Generic

The generic criteria are:

i 0

2.

3.

4.

5,

6.

Cost (Development and Recurring)

Risk

Performance (Probability of error detection and recovery)

Standardization/commonality

Growth (Design extendability and technology insertion)

b

Impacts on user, operator, and subsystem designer

1.3.2 Trade Unique

The trade unique criteria are:

i. Qvailabil.i.ty/reliability of subsystems

2. Speed of recovery

10-4
,

4.

5.

Number of spares required

Ease of implementing and maintaining related software

Susceptibility to unit physical damage

1.4 APPLICABLE OPTIONS

1.1 Data Processing Hardware (Technology Options)

2.2.1 Fault Tolerance (Design Options)

1.5 ALTERNATIVES

The report on options for fault tolerance was organized into four sections.

This format is continued into the summary of the trade study results in

Section 3,0 (Reference Tables 1 to 4). These sections are:

0

o

0

0

Error detection

Hardware replication and reconfiguration

Damage assessment

Error recovery

Both the options report and this trade study treat fault tolerance by listing

possible methods and the characteristics of those methods. (See Table 1 thru

4) Each subsystem may select an appropriate method from the list. In most

cases there is no definite recommendation, as is usually required of a trade

study. The reason is that requirements vary widely among subsystems, and

often even within a single subsystem. It is not practical, for example, to

recommend that every subsystem implement three active processors (for combined

fault detection and isolation of the failed unit) just because the most

critical applications may have such a need. Many subsystems are likely to be

satisfied with running a single unit, possibly with another "system" processor

monitoring basic fault status (running/stopped, power on/off, etc.).

Therefore, Tables 1-4 have generally been arranged with the Decision Item

column meaning "if you need .", followed by a brief description of the

option and its characteristics, and ending with the Decision Rationale column

indicating possible applications.

10-5
The alternatives below are discussed in more detail in the option report and

are not repeated in this trade study.

Error Detection

o Built-in test equipment (BITE)

o Watchog timers

o Parity and related techniques

o Voting or external monitoring

Hardware Replication and Reconfiguraton

o Standby sparing

o Reconfigurable duplexing

o Pair-and-spare

o N-modular redundancy (NMR) voting

o Reconfigurable voting

o Reconfigurable multicomputers

o Reconfigurable multiprocessors

Damage Assessment

o Self test

o Trouble reports correlation

o Remote diagnostics

Error Recovery

o Checkpoint/rollback

o Audit trail

o Information validation

o Recovery block

o N-version programming

o Backup software

o Compensation

10-6
2,0 METHODOLOGY

All of the techniques for fault tolerance use some form of redundancy to

recover from errors.. Most of the techniques also use redundancy in the

hardware or software to detect the presence of a fault. The list of

alternatives in Section 1.5 is based on traditional methods, state-of-the-art

systems, and research areas. The specific method to be used will depend on

the particular needs of each subsystem. Because both volume and power are

likely to be limited resources on the Space Station, the fundamental criterion

may be that the smallest number of units should be selected which will satisfy

the critical needs of the subsystem. Few subsystems on" the Space Station

should require the very rapid detection and recovery time provided by triple

(or higher) redundant execution of programs. Critical subsystems which have

reasonable recovery times (seconds to minutes) are likely to select duplex

redundancy in some form because of its rapid detection of errors, and to use

checkpoints to recover to a known state from which to continue operations.

Subsystems in category 3 are expected to use only a single active unit, and to

rely on internal hardware checks and monitoring by a "system" unit processor

for basic run/stopped status as the error detection technique, followed by

continuation from a checkpoint.

The general weighting of criteria in decreasing order of importance are:

I ,

2,

3.

4.

5.

Criticality of the subsystem

Required recovery time (the primary reason for triple redundancy)

Probability of detecting a fault (the reason for dual redundancy)

Probability of identifying the faulty unit

Ease and risk of writing detection and recovery software

10-7
3. O RESULTS

3.1 SUMMARY

The results of the trade study are summarized in a set of decision matrix

tables (Tables 1 through 4) in section 3.3 for the areas of (I) error

detection, (2) hardware replication and reconfiguraton (two tables), (3)

damage assessment, and (4) error recovery. The areas are not completely

independent. For example, detection of faults by cross comparison of computed

values is only applicable to replication which executes in two or more

processors simultaneously, while detection of errors by built-in test

equipment (BITE) is applicable in all cases.

3,2 RELATED TOPICS

3.2.1 Cross Comparison of Computed Results

The cross comparison of computed results is the basis of detecting faults in

most of the redundant configurations. Experience has shown that this

technique has a difficult practical problem in determining the level of

acceptable difference in computed results before declaring a failure. If the

design is such that results are not guaranteed to be identical, then the

subsystem designer must somehow determine the level which both rejects widely

differing faulty values and accepts widely differing good values. The

appropriate level is usually found only in actual use, not during the design

phase. A long term effort is required following the first operation, which

can impact the life cycle cost.

If the design guarantees identical results, there is a difficult early design

effort to define the technique and a long term effort to assure that these

design assumptions continue to be satisfied as changes are implemented, ]he

Space Shuttle experience shows (i) that identical results can be achieved by

redundant computers but that development of software to assure identical

results is significantly more difficult and costly than a single machine

design, and (2) that eve__ software change must be closely audited for

10-8
potential effects on the entire redundant system. In addition, the designer

has the problem of assuring that inputs to all processors are identical. This

is achieved on Space Shuttle by closely synchronized input operations, with

special hardware that allows one computer to request inputs and the other.

computers to listen to the response. A more general method is for each

processor to read its own sensors, then exchange its inputs with all other

processors to select a common value. Reference I shows that this design

actually requires four processors and a double exchange to assure selection of

the same value even for tolerance of a single fault. Any subsystem which aims

for identical results should be aware that such a design is much more

difficult than simplex software.

As a final observation on this topic, the mixing of different types of

redundancy in a single processor is impractical at best. Even dual redundancy

with tolerance checks will need to consider timing differences in setting the

tolerances. If the loading of the processors is not the same (e.g., the

subsystem is executing at a relatively high priority in one processor but at a

relatively low priority in another processor), the subsystem is unlikely to be

able to find any acceptable tolerance level. This problem has strong

implications on the ability to combine subsystem processing as a strategy for

total system fault tolerance.

3.2.2 Reliability and Sparinq

Fault tolerance on Space Station has been specified as fail-operational,

fail-safe, restorable (FO/FS/R) for critical systems. However, the

reliability of the system is also of importance. One major contrast to Space

Shuttle in this regard is the duration of a mission. Combined with the

potentially larger number of required processors, the effect may be marly

expected Failures between resupply cycles. The implication is either several

onboard spares for replacement offailed units or the ability to repair such

units on orbit (possibly by interchanging parts among the failed units).

10-9
Some reliability estimations show the effects of the larger number of units,

the policy of common processors, and the longer interval of required

operation. The Space Shuttle computers currently have a mean time between

Failures of about 5000 hours. R long misson may last 10 days (240) hours.

Rssuming that two computers must be operational at the end of mission for

safety (one primary and one backup) and that all computers are running

continuously, the probability of having less than two computers after lO days

is about 1 in 43,000.

One possible Space Station growth configuration, for example, has 21

processors (some embedded in work stations), with 17 potentially active and 4

off. R total of g processors are required before functions are lost. If

needed, one processor of a redundant pair may be removed and used as a

replacement for an otherwise failed Function. If the mean time between

failures is I0,000 hours and the resupply interval is I00 (Jays (2400 hours),

the probabilty of having Fewer" than g processors at resupply is about i in

20,000. However, there will be an average of 4 Failures per flight.

If the spare units are not available for use in any subsystem (e.g., the spare

navigation processor is only available for navigation and cannot replace a

failed power" subsystem processor), then the probabilty of loss of a dual

redundant plus one spare triad is about 1 in 130 per triad, which is much

worse than the 1 in 20,000 For the entire system with shared common spares for

the same total number of units.

The primary message is that the requirement for FO/FS/R by itself does not

assure a very high probability of retaining all functions. Either Fewer

processors may be used (with implications on less independence of development

by subsystems), or several spare processors may be included in the logistics

module at resupply time. The crew can expect to have to replace several

processors between resupply cycles. The use of standard processors eases the

problem of spares by allowing the option of moving (or reassigning through

software) processors to other Functions to compensate for Failures.

10-10
3.3 DECISION MATRICES

Tables 1, 2, 3 and 4 summarize the primary results of this study.

contents of the tables are described below.

o

The

l'able 1 (Error Detection) describes methods which can be used to detect

errors/faults in individual orbital replacement units (ORUs). These

methods will be the primary means of detecting errors in simplex systems

and would supplement redundancy management in redundant systems. For

systems in criticality category 3 these methods will provide the only

means for detecting errors/faults.

o Table 2 (Hardware Replication and Reconfiguration) presents an evaluation

of how various levels and organizations of redundant ORUs can be used to

archieve different levels of fault detection, fault isolation, and

recovery times. Category 1 and 2 subsystems will have to be ana].yzed

against the alternatives presented here and selections made based on

individual subsystem requirements.

Table 3 (Damage Assessment) is related to isolating details related to a

failure. In general these methods would not be of much value on orbit

unless ORU are to be repaired there.

'Fable 4 (Error Recovery) describes the methods of recovery or restor:[ng

the operation of the software after a processor failure and methods of

protecting against undetected software requirements, design or

implementation errors.

4.0 CONCLUSIONS, RECOMMENDQTIONS AND REMQINING ISSUES

The general conclusions are as follows:

i , Subsystems which are safety critical (where loss ('ould cause

immediate loss of life or damage to the Space Station) should select

at least triple active redundancy (three computers active), because

10-11
_J

.J

Z

0

0

-÷+

II

!

,:

÷÷

<

Z

,<

_O

,...,

++

U)

w

_0

,<

Z

>

-++

A

U_ C:

-,JO

Ck

r.- (0

kAJ U)

__It',

<v

--++

Z

(3

--W

0

C

O_ U

!

_U_ _

O O

_=

_=_

_OJ_

LE

_E_

Q_

_-_=_

I_U

CU

OQ;

U_-

*-- O

O

L_

Q)--

= "O

_'E

O O

"O

_--

o

_:_>_ .c -

--_ O_ _UX

_-- _ _-'- --_0_

--- U ,m _._ U -OG-

._ _.L _j_ ___ _

O O

.-- _ .-- .._

_.. _._

_ > > Q..-- ;n

--.-- 0.--=

--_'E O>

r_ _) _; _ .....

----- _'_ _- O.

--_--_ E

_'_' _" X 0-- t

•_-- _-- Q_-= ,

!

o o ,,

÷

A u)

_._ ._

q.}.-- ,._

_UUO

'.-_U U

_- Q_ U _-

_-_0

>_.- -_

,--r-._O_

_- _-_ _- _; U

0

cX

_,_

0-_

_--U_

C

0

u

Q;

_-_

L

0

L

k_

I

I

"o

"Io

L

0

L

0

IJ

10-12
w

..J

Z

O

n-

;[

O

m

_J

÷

,_JO

m ,,a

r_ U

_-- Ca

Z

O

ml.J

_.J_

C

O r_

"-- _-X

U t-f,.

•- O0

_C N e"

O n _:_

O

.m

aJ

O'-- L

U_O

_ l-- G.

00>

O.--

¢)rJO

O O O

OJ

÷÷

.-- w

U

_'-- _ 0

EE--_

_X E_O

0 0 0

÷ ÷

L

---E_

_Oi

_--

_Eom_

_o ....

O

_J

°_

eU

_C

O

'÷

!

m

_._-- _ _

L

0

G.

Q).--

E--

._

>,--

0

A .m

L

"C_{_ _.- _._ ",_ .-_

m O. UU_QJ _o m _._Jo_OO

•-- _ Q; -_ _.- J_ --_ _- o '-_-_'oo

_'_ O_am---r_ E E_. {% r_ O_ m.-_ G "

0 0 0 0 0

_ ---

_m

OE_ _

---_O _O_'-

_--_--- m _ _ _

_ _---_ _ 0 _

O O

s. e- ._0 __. "_ .... mO

_- .... {-._ _ _; S. X _ ._)

_-_ n ._,-_ _ E 6._--- "_--- _- m'O _-_ Q: E

0 0 0 0 0 0 0

rm 0

f.. °_

0

_- • _ _- O_ m E

•- _-- I_ .._-- s.. _

O_- E _. .... ._._

_--- _- O _O,E

O O O

_0

°- 0

_'_X ....

_ _C:

"O {% U

m*o X_

r.=o _.

_.)t-

--_._

_X

n

XE

0 0 0

0

elm,

rill

I.

II:

0

e-

÷

', o

m

m

!

L

i--

e"

L

0

I,,-

L

0

_m

10-13
÷ +

w

.J

,<

2:

0

.<

r.-

Z

0

I,.I

÷÷

Ii

I!

II

++

6,J

0

<:

<_

U)

4- ÷

u')

<_

<:

>

?,,

.<

A

(,n

-- ..J

i- r,

:," 6..

-"'U

Z

0

--_.,d

L.J--

r-,

E

O_m U.--U

_0 _ _0_

_O _ .-

_E _--_

•--OU _

0

t_

U

U

O

of,

Ou_

(.__-

0

_m

cnU

u_m

0 0 0

6.,,_ _ _.-- _.-- _. _.-

OE_E_ "0 .,._ _-_ r" ,_ u_ "0

-- _ ...... 0 _ ....

--L--_-_ O_ _._::E E

CJa-_ "-- _0 c-

_.,_ × .-- 0_.-- E _- _-

OE_ _ EU_ O_

.-- _ _ _.-- Q)_. _ _ eo_ U _ r"-----_ _ r" --.-_'o-- _ _-_ _-

0 0 0 0

tn , .-

a.) .,._ I o

._ Q;_--_ 0 0 _r

_--- u.-u _u--

00_ _0_"

•-wJ_ _ -- m 0 _--

O O O

•-- _ ._ ....

_- _ O E_'--

O_ ._ _ ---._

_.- --- _: E_O _,r- rs.r- ;.- O'-- - ;.- =, G)

0 "- _-- 0-- 0 _

_ 0 a:--_ _.._

0 00 0

E ;- UE _n_! 0

C; .- 00-- --

G) O ._ .-- r" _.-- .-- _ _. a.._

0 _. ,u _- UO'.-- _O.---

_" ;- =,C_EDC3_C:u- O.._ mU_

0 0 0 0 0

I

C

0 U "O

0 -_ _.._._ --

• _ o_

0 "-- O¢)

E _).- _ _" _

.... r_

O O O

O

* " 0 a._

X.DO

X _ U

_.E 0.._

._.- _.-_

_--- .._ U

.0_ •

x ._

-_'-_0_

O_

_-);n

X,_U

.--._

XO

E_O

0

_1_- _n_,_.- _n 0

_, _c.., _,_ _._ o

- 0

0_0

_-- O30 •

C_ _O=UE

0

m_O=OCUE

o

.p:

L

01

,gin

o

C.)

ne

era

cO

eli

m

n_

L,

L

¢u

u

L

U.

SQ

0

IFm

u

10-14
÷ ÷

-J

<

0

p=-

z

0

To

w

0 0

+÷

i

i!

ii

Ii

@+

L:

{0

Z

>

<

T,

L J

'<

Z

<

>

<

A

=[

0

O0 c" --_

_" .._ 0 -- Q_ _"_-- _

00_- "0 >_-- o

E _- 0 " >'_.,= O_ r_ _. ,_

0 0

'- _-- "- N O_

O_ --

.... _ _ _U 0_0 _--_

_ O _ _ _ _--- E _ _ O O

__ _'--_0_---

00----0--_ ...... _--

O0 0 0 0 0 0

O'--U U _C

U_'_ e_.-- 0._ _k. 0 _

O O O 0 0 0

¢0

0

E

_--00

_E_ O

O_ E

_U_'-

0 0

0_._

_OJr"

Q_

Q;

,._

I

I

"o

.-i

.IJ

"o

ii=

¢_

o

l--

lii

:3

[-

0

I/I

l.)

10-15
-/

<:

£:

¢>

u_

u_

w

O

<:

u_

U'J

L.J

<:

<

r,

<

--4.1

I-G,

<--

Zl.

.,t "

Z

0

m_

4"

t. =

;.- .% I_ I_--m

mo I-.--C

3: _ / Or._--'-- E >

O O

fJ G.r..) ,_ c -- _ *n .,._ ---- _ x (D f- J::: e

---------- _-_ • --,C0DiD _.8_CP _OO@OO

¢: _ O O O" O O

'2D

¢=

>j --

t. L

O r_--

_--_ rJ

c: r_ --

i °

0

O m ,*J'O ,_.

I.. I: ..i ..i _.. i,t _.1 0

-- O_ I: UOC ='---"

_- _,'C L > r.,: G._ _

¢ 0 0

.,)

O

O.

U

O

U

0

s.

ID _*--

• 0.._

raI. L_.

I.-

<

0

4.,.

_OE_O

_O_

10-16

b

>

O

,¢

EO

0

>_ = --e

I,. Ip I: _.

ra C -----::

(- >----:

_-- G. :_ -" E

0 ¢

_0

C_

!- C _,-

i.l_ - I; _IC

0 I1: _= C

0

o

_J

¢U

S.

O

L

IJJ

I

I

4.t

tn

"O

U

Iu

o
of the abilty to detect the fault, isolate the faulty unit, and

continue immediately with the remaining two units. There may be very

few of these subsystems of this type on the Space Station.

. Subsystems which are mission critical (where loss could aF1=ect the

overall operation if not corrected in a few seconds or minutes)

should select a dual redundant system with the two computers cross

comparing results. Rt a miscomparison, the action will depend on the

ability to identify the failed unit. If the unit is easily

identified (e.g., one just quit running or is indicating BITE

detected errors while the other appears to be good), control is given

to the good unit while the failed unit is replaced. If the failed

unit is not obvious, the best response may be to give control to a

spare unit, using a checkpoint restart, until the failed unit can be

isolated offline. Some possible needs For this option are docking

operations and management of the entire orbital constellation.

, Subsystems with low criticality (where loss for minutes or hours will

not seriously affect operations) should select simplex execution.

This option has the major advantages of minimizing power usage, and

the practical advantage of much simpler software development and

verification. Fault detection is primarily that provided by BITE,

possibly augmented by a "system" process which monitors simple health

of the unit.

.

Recovery techniques are highly dependent on the application. The

most useful technique is expected to be the use of periodic

checkpoints written by the application to a mass storage device.

10-17
5,0 REFERENCES

I. Reaching Agreement in the Presence of Faults, Journal of the ACM, Vol. 27,

No. 2, April 1980, by M. Pease, R. Sho_tak, and L. Lamport

10-18
SPACE QUALIFIED COMPUTERS TRADE STUDY

1.0 TRADE STUDY DEFINITION

i.i Pur__ose of Trade Studv

Space qualified data processing hardware represents a major element of the

SSDS space segment and, therefore, has a pivotal role in supporting the

development and growth of the Space Station, COP and POP. The specification,

selection and procurement of this hardware must be comprehensively evaluated

and defined to provide coherent solutions to the SSDS technical requirements

while satisfying the prominent programmatic drivers. This trade study will

address the key issues associated with this hardware to determine the

preferred options and configurations.

1.2 Background

The SSDS architecture design is the process of translating the Task 1 defined

SSDS Functional and performance requirements into a specific system

definition. It is anticipated that this definition will adopt a distributed

processing approach since:

the station itself has physically distributed modules and subsystems,

processing loads may be too large to be efficiently supported by a

centralized configuration,

network technologies with adequate data rates to support SSP

appli.cations are currently being defined/developed and will be

available for IOC,

a distributed approach provides an inherently more damage tolerant

configuration,

a modularity is provided that supports technology insertion, an

orderly growth, and concepts of standardization/commonality.

Preliminary concepts of the Space Station Data Management system have espoused

a distributed (I_AN) architecture and have also defined a subsystem (stand__rd)

11-1
data processor (SDP) dedicated or assigned to each of the identified onboard

subsystems and separable Functions of the DMS. These SDP's would be a single

configuration, physically identical, and qualified to the same environmental

levels, thus providing absolute interchangeability. This approach is

representative of the "commonality" concept intended to provide significant

program acquisition and operational savings through reduced design,

development, and test efforts, lower maintenance and tooling costs, fewer

spares requirements and a narrower expertise base. On closer inspection,

however, issues surface involving specific SDP configuration, applicability,

environmental qualification, operability, and growth, to suggest that the

above homogeneous concept may be less than realistic. The intent of this

trade study package is to identify and resolve these issues.

A fundamental issue to be initially addressed is the use of homogeneous vs

heterogeneous hardware. The homogeneous concept, as noted earlier, utilizes

only a common processor as noted in option 1 below. The heterogeneous

approach provides the three additional options listed.

• Option 1 - selection of a common processor.

Option 2 - selection of an instruction set architecture without

specifying the physical implementation.

Option 3- relaxation of the commonality concept to allow selection

from a small set of general purpose and special purpose processors.

• Option 4- total selection freedom.

Option 2 is an attempt to capitalize on the software development and

maintenance benefits of the fixed istruction set without confining designers

to specific hardware solutions. Ali technology upgrades are replacement

candidates with this option.

11-2
Option 3 attempts to alleviate the blanket hardware solution approach of

Option 1 by providing a set of common processors. Such a set might include an

AI LISP machine and a "backend" data base machine in addition to the general

purpose SDP.

Option 4 allows total design freedom and would rely on a robust SSDS

distributed operating system to maintain a functional and efficient system

operation,

At this generically high level of discussion, only programmatic arguments are

exposed, however they are sufficient to derive an initial disposition of these

options. In reviewing the complete set of evaluation criteria, provided in

Section 1.4, the only parameter of consequence is that of "maintainability"

which involves the manpower, tools, expertise, and spares requirements.

Option 1 tends to minimize these maintenance requirements while Options 2 and

4 clearly increase them by at least an order of magnitude. The additional

burdens generated by Options 2 and 4 are judged to be too severe, therefore,

these options are not considered feasible and will not be further addressed.

Option 3 remains viable and is discussed as Trade Study No. 2.

Regardless of the outcome of the final IOC configuration, it is anticipated

that the growth configurations will tend to be increasingly heterogeneous

because:

significant cost savings can be realized through continued use of

technically acceptable hardware,

applications may tend to diverge in terms of DP requirements,

particularly with the increasing momentum of Artificial Inte].ligence,

In addressing the SDP, one of the more significant issues is the utilization

of formal Military/DoD standards. The implication is that these standards

provide a more stable product with broad commercial support in both hardware

and software areas. The alternative commercial products, in contrast, are

11-3
perceived to be "moving targets" with less stability and decreasing long term

support. The MIL-STD-1750A ISA standard is currently widely supported and

provides the benefit of direct software portability, however this architecture

is not current and is further limited by a 16.-bit format and a direct

addressability of 1Mword. Commercially available configurations are more

technically attractive but may present a potential liability with respect to

long term hardware and software support; 16-bit/32-bit format decisions are

closely coupled to this issue since the 1750A is the only processor standard

being currently supported.

As indicated earlier, blanket utilization of a "common" SDP will not provide

an optimal or even totally satisfactory solution to all applications. As

discussed, a preferred option may include use o? common special purpose

architectures, i.e., LISP machines for artificial intelligence applications,

or back end data base machines for data base management functions in

conjunction with an SDP.

Environment qualification levels are also considered to be an issue,

particularly since the POP radiation environment is considerably more severe

than that of the Space Station and COP. It may be more cost effective to

utilize a different configuration for the POP with respect to radiation

qualification levels or different components.

Finally, the SDP is generally perceived as a stand-alone, black box unit, and

is addressed from a commonality point at that level. The commercial market is

moving toward general and special purpose single board computers, memories and

peripheral controllers. There are significant architectural and operational

implications to redirecting the commonality control point to a circuit card

format with a corresponding backplane.

An initial activity for this trade study has been the development of a

preliminary and generic set of SDP performance requirements in terms of I/O

rates, memory sizing requirements, and throughput. These requirements were

developed from a survey of the functional requirements provided in the study

11-4
data base. The resulting envelope, shown in Figure 1.2-1, provided an initial

target only for the purpose of conducting this trade study. The envelope

provided is actually an expansion of the generated requirements to provide

typical (100%) growth margins for memory and throughput.

1.3 Issues

The following paragraphs present the issues to be addressed in this study

package.

1.3,1 Trade 1 - Standard Instruction Set Architecture (ISA) vs Commercial

ISA

]'he primary benefit of establishing an instruction set architecture as the

common element is that of software portability. The implications are

substantial for a program of the magnitude of the Space Station because of

replicated software modules and programs, and the potential of reusing

software developed for other programs. Will a Military/DoD standard ISA or a

popular commercial ISA provide the better approach?

1.3.2 Trade 2 - Special Applications vs SDP

The blanket solution of an SOP may satisfy a large number of applications

provided the SDP design/performance requirements are judiciously selected to

provide an adequate envelope. Some applications, however, may either drive

the SDP envelope to unreasonable limits or may be significantly compromised in

their own functional and performance requirements. In such cases, special

purpose machines such as LISP machin6s, or data base machines, may provide

more effective solutions. Does this limited heterogeneous mix of processors

provide a better approach than the homogeneous sets?

11-5
=1_ e4

o •

o

_ o ,. _

Q

&

._g

t_

11-6
1.3.3 Trade 3 - Radiation Tolerance _ualification

The radiation environment of the POP is relatively severe in comparison to

that of the Space Station and COP. Since the overall cost of the high

radiation tolerance components and the associate qualification effort is high,

is it more effective to provide a differing radiation tolerant SDP

configuration for the COP?

1.3.4 Trade 4 - Fault Tolerance Confiquration Control

Clearly, fault tolerance will be a fundamental requirement for the onboard

data processing, however concepts of its implementation are not as clear. One

of the key issues in this area is subsystem/SDP fault tolerance, i.e., should

the SDP include fault tolerance mechanisms to support detection,

reconfiguration and recovery, or should the SSDS control these operations7

1.3.5 Commonality Control Point

The generic processor has been generally depicted as a box level element with

commonality control applied at that level. An option of the current and

developing technologies, however, is to provide high performance single board

computers (SBC) that support a specific back plane. This approach would add

significant flexibilities to the overall architecture while providing a number"

of programmatic benefits. Is it a preferred option to implement SDP/module

commonality at a "standard" circuit card compatible with a defined backplane7

This issue will be addressed purely in discussion form.

1.4 Trade Study Criteria

This section provides a complete dictionary of the parametric criteria used in

this trade study. The criteria set selected for each trade-off activity is

provided in Figure 1.4-1. Also shown in the Figure are the assigned parameter

weights, which, as discussed in Section 2.0 Methodology, provide an assessment

of the relative impact of each parameter to the project success.

11-7
Cost

-Non-recurring

- Recurring

Devel. Risk

Per f or mance

-Throughput

- Addressability

- Accuracy

Rel i abi i i ty

Maintainabi 1 i ty

Physicals

- Size

- Wei ght

- Power

EITV. Tolerance

- Vib/Shock

-Thermal

- Radiation

Vendor Support

S/W Devel. SupporlGrowth

•- Extendabi I ity

- Insertability

Weighting lotals:

Trade i

Std vs

Comm'l ISA

9

9

8

9

9

7

4

9

0

0

c)

2

2

7

10

10

0

5

100

Trade 2

Spec. Purp.

Arch.

9

9

3

15

10

2

3

12

1

1

2

2

2

5

7

7

5

5

I0(')

Trade 3

Rad i at i on

Qual

10

10

!0

i 0

(;)

0

8

10

3

4

0

(-)

8

7

7

100

Trade 4

Fault

Tolerance

9

8

30

5

0

8

8

8

0

0

(-)

0

0

7

8

10 0

Figure 1.4-1. Trade Study Criteria/Weighting

11,,0
1.4.1 Criteria Dictionary

Option Costs - consists of both non-recurrent (development) and

recurrent costs.

a. Non-recurrent: includes basic development and qualification

costs.

b. Recurrent: includes not only the basic unit production costs

but also:

- requirements for special/more expensive hardware items,

- special environmental requirements,

- special reliability screening,

$ Development Risk - Addresses:

a,

b.

Difficulty of implementation and,

Difficulty of achieving design requirements.

Processor Performance - Addresses throughput, addressability, and

accuracy as defined below:

a, This measure has less meaning with the variability of

instruction functionality. For this study, the throughput has

been normalized by estimation to the Digital Avionics

Integration System (DAIS) instruction mix.

b. Addressability: size of directly addressable memory space.

C° Accuracy: number of significant figures in processor floating

point formats.

• Reliability:

Projected operational failure rates of options.

11-9
• Physicals:

a. Size, volume

b. Weight

c. Power dissipation

• Environmental Tolerance:

a°

b.

C.

Vibration/Shock - assessment of ruggedness of option.

Thermal - assessment of option stability over thermal range.

Radiation - assessment of tolerance to total dose radiation and

SEU.

• Fault/Damage Tolerance:

Assessment of the autonomous fault/damage tolerance.

• Maintainability/Repairability:

Ease of maintenance/repair with respect to manpower, tools,

expertise, replacement parts availability, replacement parts costs

and projected down-time.

• Vendor Support:

Assessment of long term hardware support by the vendor or second

sources; addresses not only hardware (end item, module), deliveries,

by vendor or second sources, but also any special screening and/or

repair support.

• Software Environment Support:

Deals with the general vendor and after market software support for

the option in terms of HOL's, compilers, and application software

that can be re-used by the SSP.

11-10
• Growth Accommodation:

Consists of two elements, extendability, and insertability defined as

follows:

a. Extendability is the ability to add modules to an option to

provide more capability/capacity.

b. Insertability is the concept of direct (minimal impact)

replacement of an option with an improved or technologically

upgraded element.

2.0 Trade Study Methodoloqy

For each of the trade areas, the following methodology has been applied.

1) F.ully characterize the options: Each option will be characterized as

fully as possible to allow a fine grained assessment corresponding to each

parameter of the criteria.

2) Se!ect and aRpro_oj_iate set of evaluation parameters: This set has

been taken from the total set listed in Section 1.3 and is tailored for the

specific trade activity.

3) Provide weighting factors for each evaluation parameter: A weighting

factor has been assigned to each parameter of the criteria set based on its

relative impact to the project success. Cost, for example, is a relatively

high impact parameter and will be assigned a higher percentage weight.

Development risk will also carry a higher weight since acquisition phase

problems generally result in significant cost and/or performance penalties.

Reliability, normally a high impact item, is less so on the Space Station

because of the onboard maintainability and therefore carries a correspondingly

lower weighting.

4) Provide a numerical assessment for each option: A numerical

assignment (O-lO) will be entered in each option column, corresponding to each

parameter of the criteria. This assignment provides a relative estimate of

11-11
the suitability or effectiveness of the option based strictly on that

parameter. A "5" indicates an average assessment, a "O" indicates a total

deficiency. Note that inverse parameters, such as risk are inversely rated,

i.e., higher costs and risks generate lower ratings.

5) Score and rank the options: The parameter assignment times its

weighting provides the option score for that element of criteria. The

preferred option is generally identified by the largest criteria score sum.

The exception is when an option has a rating of less than "2" for any

parameter that has a weighting of more than '5'; that option is disqualified

from consideration.

6) Perform sensitivity analysis: An analysis will be performed to

identify the key decision drivers.

7) Re-Evaluate individual trade activities: Each trade study will be

evaluated to determine whether the results are reasonable and expected, to

resolve any perceived inconsistencies, and to eliminate potential coupling of

dependent issues.

3.0 TRADE STUDY DISCUSSIO_ AND RESULTS

3.1 Standardization vs Commercial Instruction Set Architectures

3.1.1 Discussion

Given that a homogeneous processor network is to be implemented, and that a

specific instruction set is to be implemented for the overall software

benefits, this trade activity addresses whether that instruction set

architecture should be a formal Military/DoD standard or a popular commercial

unit.

Military/DoD standards have been invoked to specify requirements to meet

space/weapons systems needs, stabilize specific configurations thereby

11-12
promoting hardware interchangeability and software portability, significant

benefits, provided that the standards are widely supported and therefore have

a projected longevity.

There are currently two DoD processor standards for consideration: the

MIL-STD-175OA 16-bit Instruction Set Architecture (ISA), and the MIL-SFD-IB62B

32-bit (ISA). Industry support for the 175OA specification is broad and deep

representing significant vendor development investments in hardware and

software. A growing number of technology implementations are in work as

tabulated in Options paragraph 1.3.3, including VHSIC. The software

portability provided by this standard would be o? significant benefit to the

SSP not only For the concepts of re-useable programs, but also because of the

effective transparency of hardware growth and technology updates.

The IB62B specification appears to be currently inactive because of a lengthy

and complex instruction set; there are no projections for its resurrection,

therefore it will not be considered as an option in this study.

The commercial market in this tradeof? has been represented by the popular

Motorola MC68000 16-bit and the MC68020 32.-bit microprocessors. Note that the

MC68000 is categorized as a 16-bit unit based on its 16-bit data paths and

ALU's.

The criteria parameters are discussed briefly in the following paragraphs.

• Cost

]he relative development and recurring costs for the three option CPU's are

established by the following:

Commercial vendor specification and application documentation is

generally more comprehensive and the applications are broader.

The 1750A includes floating point data formats, considered to be a

general requirement; the MC68020 must use a true co-processor, the

MC6BO00 must use a co-processor but as a peripheral with attendant

performance penalties.

11-13
• Performance

a) Throughput: The current 1750A performance is in the 0.6 MIP to 1MIP

range; the 1750A VHSIC implementation will provide a 3 MIP to 5 MIP range.

The MC680OO performance is approximately 0.5 MIP while the MC68020 will

execute at approximately 2 MIPS.

b) Addressability: The 175OA is limited by specification to 1Mbyte

which is the probable minimum for SS onboard applications. It is anticipated,

however, that this limit will be increased to 8 Mbytes at the next

specification change. The MC68000 has a direct addressability of 16 Mbytes

while the MC68020 has the full direct addressability of 4 Gbytes. If

necessary, the 1750A and MC68OOO based systems could utilize additional

hardware, i.e., paging or segment registers, to further expand their

addressing capability.

c) Accuracy: Both commercial units have a double precision integer

format, and would use a co-processor for floating point Formats. The 1750A

has a 32-bit and (extended) 4B-bit floating point format, however, the 4B-bit

format has a substantial processing time penalty.

• Environmental Tolerance

There are no identified discriminants with respect to thermal or mechanical

environments. The 175OA implementation in CMOS/SOS or VHSIC are expected to

exhibit total dose radiation tolerances to better than 106 rads(Si) while

the commercial units have a projected tolerance of considerably less. The

68000 utilizes NMOS technology which has characteristically low total dose

tolerance in the range of 1K.-IOK rads (Si). The 68020 utilizes bu].k CMOS

technology which has a higher tolerance potential but must be implemented with

specific design/processing rules to achieve tolerance levels of any

significance. Commercial vendors are not inclined to invest the required

resources for such a low volume market. The 175OA must therefore be assessed

as superior for this parameter.

11-14
• Vendor Support

The commercial units may have an edge in the CPU hardware area, since there is

currently second sourcing. It is anticipated though not guaranteed that VHSIC

1750A units will also be second sourced.

• Software Environment Support

The 1750A must be awarded a significant edge in the area of software support

since the momentum for its applicability is building and it is the target

machine for much of the HOL/compiler development. Although the 68000 also has

wide support, including Ada, the longevity of this support must be in question

as the commercial market moves on the next evolutionary unit.

3.1.2 Results

As shown in Table 3.1-1, the Standard processor is the preferred option.

Sensitivity analysis shows radiation tolerance, vendor support, software

environment support and insertability to be the significant factors.

3.2 S_pecial Purpose vs Standard Architectures

3.2.1 _Background

Clearly, a fixed configuration, general purpose processor cannot provide an

optimum solution for a11 applications but will, with judicious selection,

support a large range of processing requirements. Some applications, however,

may be better served by more specialized machines. Artificial intelligence

(LISP) programs, for example, may be executed by the SDP but at a

significantly speed penalty compared to the current "LISP" machines.

The data base management function with its multiple user, minimal access time

requirements, provides another example where application of the SDP may be

marginal compared to special data base machines or "back end" hardware. These

two areas, AI and D/Base management, will be traded against the SDP in this

section.

11-15
TABLE3.1 - t

TRADESTUDYTZTLE: STANDARDVSCOHHERCIAL IRAPROCESSORS

I : OPTION1: STANDARD I OPTION2: [6-B[T COHH'L: OPTION3: 32-BIT COHH'LI

] CRITERIA : HEIGHT I EVALUATION[ TOTAL [ EVALUATION] TOTAL : EVALUATIONI TOTALI

I

I

5 i

6 I

I

I

7 I

I

I

I

7 I

6 I

6 i

I

!

I

7 I

I

I

I

I

I

I

I

I

I

7 I

7 I

9

I I i

I COST I I

I HON-RECURR]N6sI 9 I

I RECURR]N6s I 9 I

I I I

I I I

I DEVEL.RISK: I 8 I

I I I

I I I

I PERFORHANCE I I

I THROUGHPUT: I 9 I

I ACCURACY: I 7 I

I ADDRESSADZLITY: l 9 I

I I I

I I I

I RELIABILITY: I 4 I

I I I

I I I

: PHYSICALS l I

l SIZE: I 0 I

: NEI6HT: l 0 I

: POllER: I 0 :

I I I

I I I

I ENVTDLERANCE I

: VIDISHOCK: l 2 :

I THERHAL: : 2 :

l RADIAT]OH: l 7 :

I I I

I I I

I HAZHTA[HADILITYI 9 I

I I I

I I I

I FAULT/DAHA6E TOL. I 0 I

I I I

I I I

I VENDORSUPPORT: I 10 I

I I I

I I I

I GiN ENV'TSUPPORT:I tO I

I I I

: GROHTHACCOH, : l

I EXTENDAD]L]TYs: 0 I

l ]NSERTAD]L]TY:l 5 l

I I I

10

: l I I l

I l : : I

45 l 7 l 63 l 7 I 63 1

54 I 7 l 63 l 7 : 63 :

I ] I I l

I I I I I

56 I 7 I 56 l 7 : 56 I

I I I I I

I I I I I

0 1 I I I I

63 I 5 I 45 I 9 : 81 :

42 l 5 I 35 : , 9 : 56 I

54 l 8 l 72 l 10 l 90 l

I I I I I

: I I : l

29 I 7 l 28 l 7 l 28 l

I I I I I

I I I I I

I I I I I

0 I I 0 : l 0 :

0 1 I 0 l : 0 :

0 : l 0 l : 0 :

I I I I I

I I I I l

I _ I I I I

14 l 7 l 14 l 7 : 14 l

[4 : 7 : 14 I 7 : 14 I

63 : 2 l 14 : 3 : 21 :

I I I I I

I I I I I

63 l 7 l 63 : 7 : 63 :

I I I I I

I I I I I

0 I : 0 l I 0 :

I I I I I

I I I I I

90 l 7 : 70 : 7 l 70 I

I I I I I

100 I 7 : 70 l 7 : 70 :

I I I I I

I I I I I

0 : l 0 : l 0 :

40 : 5 : 25 l 5 l 25 :

I I I I I
3.2.2 LISP Machine vs SDP

3.2.2.1 Discussion

The branch of RI utilized on the Space Station is anticipated to be the

Knowledge (Rule) Based Expert System. The estimated generic requirements For

Space Station expert system applications are: 2 MIP - 3 NIPS, floating point

formats, 2+ Mbytes of internal memory and high speed disk capability, and a

high speed I/O. Application of the MIL-STD-1750 class of processor, even the

3 MIP - 5 MIP VHSIC implementation, has an apparently limited utility For this

application even for today's primitive applications. Special purpose LISP

machines For such applications are currently available From Xerox, Symbolics,

LMI, and TI, however. In addition, Symbolics is actively pursuing a flight

qualified LISP machine and TI has a Navy contract to develop a 2-micron CMOS

processor LISP machine that will perform i0 times faster than the current

units. It is estimated that the current LISP designed units with their

tailored architectures and micro-coding would out perform the 1750 by a Factor

of up to 6 to 8 times For true (high level) expert systems applications.

The criteria selected for this trade is discussed in the following paragraphs.

• Cost

The cost of a ruggedized LISP machine including component reliability upgrade

will be comparable to the ruggedized 175OR. Recurring costs should therefore

be similar but the additional LISP development and qualification costs are

applicable to that option.

• Development Risk

Development risk is a low impact issue since acceptable configurations of LISP

units are projected to be available.

11-17
• Performance

Accuracy of the 1750A will be adequate for the expert systems applications,

however its addressability, at 1Mbyte, is marginal and may remain so even

with the anticipated increase to B Mbyte at the next specification change.

And, although the 3 MIP to 5 MIP VHSIC 1750 may appear to have sufficient

throughput, it is estimated that the 1750 will still operate expert system

software a minimum of 6 times slower than the corresponding LISP unit.

• Reliability

The commercial vs standard reliability assessment provided in the initial

trade persists here.

• Maintainability

Addition of a second "common" (LISP) configuration to the SSDS will add to the

program burden in terms of additional tooling, spares requirements, etc.

• Physicals

Circuit card oriented LISP machines are now becoming available, such that the

physicals of the I_ISP and the near term 1750A units will be comparable;

similarly, there will be no significant discriminant between the W_SI(] 1750

implementation and the TI 2-micron LISP unit.

Environmental Tolerance

l'he projected attributes of the LISP units, particularly with ongoing

development, shows no particular concern even in the area of radiation

tolerance,

• Vendor Support

Here, as with the prior trade study, the commercial unit tends to be perceived

as a moving target with potentially less than desirable long term support;

11-18
however, most commercial products provide upward compatibility to avoid loss

of existing software.

• SlW Environment Support

With appropriate selection of the specific LISP configuration the software

support should closely parallel that of the SDP.

• Growth Accommodation

There are no discriminants in this area.

3.2.2.2 Results

Rs shown in Table 3.2-1, the LISP machine is the preferred option.

Sensitivity analysis shows performance to be the key evaluation factor.

3.2.3 SDP vs D/Base Machine

3.2,3.1 Discussion

The function of data base management is to accept, provide access to and

maintain accurate copies of telemetry and engineering data, application

programs, procedures and schedules within the on-board secondary (mass) data

storage. This function includes access (authorization) control, directory

maintenance, file management, plus the compare, merge, and sort operations for

the generation of appropriate responses to subsystem or work-station initiated

transactions. The data base system must have adequate data transfer rates and

data access times to provide efficient transaction response times.

Preliminary planning has assigned Data Base Management to an SDP, however, a

qualified version of a commercially availab].e data base machine or a back-end

data base processors may provide a better solution. This section will examine

this issue.

11-19
J.C

TABLE3.2 - I

)

)

I

I

I.

)

,!

TRADESTUDY TITLE: BOP VS SPECIALPURPOSEAI (LISP)MACHINE

I OPTION I: SDP(1750A) I OPTION2: LISP MACHINE I OPTION3:

I CRITERIA _ WEIGHT I EVALUATION I TOTAL : EVALUATION I TOTAL I EVALUATION I TOTAL

COST I

NON-RECURRIN8: I 9 7 ; 63 3 27

RECURRING: I ? 7 I 63 7 63

OEVEL.RISK: I 3 7 _ 2! 3 9

PERFORMANCE _

THROUGHPUT: I I5 3 ; 45 9 135

ACCURACY: I 2 7 ; I_ 7 14

ADDRESSABILITY:_ I0 3 ) 30 9 90

RELIABILITY: I 3 7 ; 21 7 21

PHYSICALS I

SIZE: I I 7 : 7 7 7

WEIGHT: ) I 7 ) 7 7 7

POWER: I 2 7 ) 14 7 14

ENV TOLERANCE I

VIB/SHOCK: ) 2 7 I 14 7 14

THERMAL: ) 2 7 ) 14 7 14

RADIATION: _ 5 7 I 35 7 35

MAINTAINABILITY ; 12 7 I 84 3 36

FAULT/DAMAGETOL, I O 0 _ 0 0 0

VENDORSUPPORT: _ 7 8 ) 56 7 49

SIW ENV'T SUPPORT:I 7 9 I 6S 7 49

) I

BROWTHACCOM, I )

EXTENDABILITY: I 5 5 I 25 5 25

INSERTABILITY: I 5 7 I 35 6 30

TOTALS: I IO0 ) ) 611 ) ) 639 I 0

) I I I I )

==================================================================================================================

11-20
The currently defined design characteristics for the on-board DBMS mass store

are :

• 256 Mbyte capacity

• 10 Mbit/sec transfer rate

• 40 millisecond access time

• space qualified

Since the non-recurrent space qualification effort for any special purpose

hardware, and the effect of its use on maintainability, i.e. non-commonality,

must all be offset by the resulting increased performance, then the

performance requirements for IOC and growth are necessarily the key evaluation

drivers.

No query/response technical requirements have been established other than to

state that response times should be consistent with commercial data base

systems. Response times, however, are a function of the density and

complexity of the requests. The commercial machines provide faster query

service and excel within a multiuser high demand environment; a general

purpose SDP class unit in the same environment would be intolerably slow. The

Britton-Lee unit, as noted in the Data Processing Options paper, serves up to

64 hosts, utilizing a 10 MIP accelerator for extremely Fast brute force search

operations. No data base scenarios have been provided for the Space Station

detailing timelines and request types however a relatively infrequent query

environment is anticipated at least for IOC. In this environment, special

purpose machines are still faster but the delay will be inconsequential to the

query source. A simple analysis indicates that a crude search operation on a

file involving as much as lOOKbytes, could be performed in less than two

seconds utilizing an SDP.

It must also be noted that software may be more significant than hardware in

the area of data base management. Sophisticated software can provide a depth

of indexing such that the search operations can be accelerated by an order of

magnitude.

11-21
3,2.3.2 Results

It is concluded from this examination that special purpose hardware will not

be required for the data base management function for IOC. The key drivers

are:

i) the increased development costs required to ruggedize a special purpose

unit, and,

2) the inconsequential query response time reduction that would result

from the addition of the special purpose unit.

This issue must be re-evaluated for growth phases when their query/request

environment is better defined.

3.3 Radiation 9ualification Levels

3.3.1 Backqround

As indicated in Options section 3.5.1, the accumulative radiation exposure in

the Space Station and COP low inclination, low earth orbits is minimal because

of the natural shielding of the earth's magnetic field. The POP, in contrast,

passes through the "unshielded" polar regions during approximately 30% of its

orbit and thus is exposed to significantly higher radiation leve].s.

Although radiation is potentially a key driver to the procurement activity,

there is also considerable programmatic motivation to enforce

standardization/commonality for the benefits of reduced spares requirements

and narrower hardware expertise requirements. In this regard, the options,

previously identified in the Procurement Activity white paper, are to:

i) Qualify the SDP to the higher POP 10 year total dose radiation levels

and use the resulting configuration for all SDP applicat:[ons

z) Provide a unique POP SDP configuration that alone has the required

radiation tolerance, and,

11-22
3) Periodically replace the POP hardware following intervals consistent

with its qualified tolerance.

It is initially noted that in addition to total dose radiation tolerance, the

single event upset (SEU) phenomenon, must be addressed for all space hardware

to minimize potentially catastrophic latch-up effects are minimal. Option l,

however, involves only the total dose radiation effects and addresses the net

effort to outfit the entire SOP fleet with components qualified to the POP

tolerance requirements. Based on the current technology realities, this

effort to provide CPU, memory, and I/O components that are radiation tolerant

is significant. The component costs, and qualification costs will be very

high, and will be recurrent involving a larger number of manufacturing lots

because of the utilization of this "common" radiation qualified SOP for all

applications.

Option 2 addresses the effort of developing a differing configuration for the

POP SOP in order to meet its radiation tolerance requirements. This option

can be further decomposed to characterize this POP configuration as:

2a) identical except for component qualification to the higher levels, or

2b) different components and design

Option 3 addresses the potential of periodic replacement of the POP hardware

based on a demonstrated radiation tolerance level and monitoring dose rate

during change-out intervals.

This trade was performed in two stages; first the preferred approach of

options 2a, and 2b was determined, then this preferred option was traded

against options 1 and 3.

3.3.2 Unique POP SDP Confiquration Trade Effort

3.3.2.1 Discussion

()ption 2a involves the effort of qualifying the components of "'common" SDP to

the higher levels of the POP environment. The net gain of this option is that

11-23
the more expensive parts from the qualified production lots would be utilized

only on the POP SDP's. A unique POP would therefore be generated with its own

'spares' requirements, although it is recognized that these spares could be

used in Station and COP applications if required. This option also includes

the potential of selectively shielding components that cannot demonstrate the

requisite radiation hardness.

Option 2b encounters significant development costs and qualification costs of

a fully unique configuration.

The criteria for this trade are discussed briefly in the following paragraphs

• Cost

Option 2b imposes the cost of the unique configuration development.

• Development Risk

Program development risks are increased for the new development of option 2b.

The risks of option 1 may be more than minimal, however, the capability of

selective shielding for components that cannot meet full criteria reduces the

overall option risk.

• Performance

Discriminants are identifiable only in the area of throughput which may be

impacted in option 2b with its differing (higher radiation tolerant)

components.

• Reliabilit V

The component count of option 2b will ,lost likely be higher which will tend to

reduce its reliability.

11-24
• Maintainabilitl

Both options require unique configurations and unique spares; however, since

the 2a option will be physically replicate, except for possible component

shielding, it has an edge in repairability.

• Physicals

Option 2b may in fact require a higher component count, with a resultant

impact on its physicals; size, weight and power'.

• Vendor support

In terms of the hardware support, option 2b will have a lower rating due to

the lower production quantities which generally translates to reduced leverage

on vendors.

• S/W Environment Support

No discriminants have been identified.

• GrowthAccommodation

No discriminants identified.

3.3.2.2 Results

As shown in Figure 3.3 - 1, option 1, the radiation qualification of all parts

is the preferred approach. Sensitivity analysis shows the significant driver

in this evaluation to be development cost, develop risk and to a lesser

extent, maintainability. As discussed in the criteria, although this

preferred approach uses the same parts, a unique POP configuration results.

11-25
TABLE3.3 - 1

TRADESTUDY TITLE: UNIQUEPOP SOP OPTIONS

I I OPTIONI: QUAL PARTS I OPTION2: DIFF PARTS ) OPTION3:

CRITERIA ) WEIGHT I EVALUATION = TOTAL = EVALUATION ) TOTAL _ EVALUATION I TOTAL

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

COST

NON-RECURRING:

RECURRING:

DEVEL.RISK:

PERFORMANCE

THROUGHPUT:

ACCURACY:

ADDRESGABILITY:

RELIABILITY:

PHYSICALS

SIZE:

WEIGHT:

POWER:

ENV TOLERANCE

VIBISHOCK:

THERMAL:

RADIATION:

MAINTAINABILITY

FAULT/DAMAGETOL.

VENDORSUPPORT=

S/W ENV'T SUPPORT:

GROWTH_r-n- Mw_un,

EXTENOABILITY:

INSERTABILITY:

10

tO

I0

I0

0

0

I0

tO

GO

7O

60

70

0

0

56

21

21

28

5O

70

56

0

49

49

30

70

4O

60

0

0

4B

18

IB

2¢

4O

6O

56

42

49

..................... I ............................ t I ¢ . ...............................................................

..................... I ............................ ; ................................................................ I t

TOTALS: _ I00 ) ', 680 ) ', 555 ', i 0

I

, 1 ) _ ', 1 1

I I

................................. ................ I ............................................................... I I l

I ..................... I .................................................................................

|lore
3.3.3 Radiation Environment Options

3,3,3.1 Discussion

This trade effort determined the preferred approach of the previously

identified option I and option 3 listed below with the identified preferred

approach from Section 3.3.2.

Option I - Perform full radiation qualification of all SOP application.

Option 2 - Utilize the above qualified parts only on the POP SDP

applications, with the potential For selective component shielding.

Option 3 - Periodically replace the POP SDP's.

The criteria for this trade is discussed briefly in the following paragraphs.

Note that only Cost and Maintainability are applicable.

• Cost

All three options require component radiation qualification. The net cost

savings would be associated only with the reduced component costs of option 2a.

Option 3 suffers significant recurrent costs of the periodic replacement

activity even though possibly tempered by other servicing requirements.

• Maintainability

Option 2a requires a unique POP SDP configuration and is therefore less

favorable,

3.3.3.2 Results

As shown in Fable 3.3 -. 2, qualification of all (fleet) components is the

preferred option. Sensitivity analysis shows that recurring cost is the

significant driver for this selection,

11-27
TABLE3.3 - 2

TRADE STUDYTITLE: RADIATIONQUALIFICATIONOPTIONS

I I OPTIONI: QUAL ALL PARTS I OPTION2: NEW CONFIB _ OPTION3: REPLACE i

CRITERIA = WEIBNT I EVALUATION = TOTAL I EVALUATION _ TOTAL I EVALUATION I Tn,^, luiML

I

=====================================================================================================================

COST

NON-RECURRIN@: _ 33 7 231 3 99 7 231

RECURRINB: I 34 7 23B 6 204 3 102

MAINTAINABILITY I 33 10 330 3 99 10 _0

I

I

I

I

I

I

I

I

I

)

I

I

I

I

===================== ============================ ==================================================================

i _ 100 _ I 799 ....

11-211
3.4 Fault Tolerance

3,4.1 Background

Fault Tolerance will be a fundamental attribute of the Space Station, to

support the 'fail operational, fail safe, restorable' requirements of the RFP

particularly in support of the "build-up" and potential man-tended scenarios

of the Station,

Fault tolerance techniques are generally distributed across several hardware

levels, i.e. module, processor, and sub-system hardware levels with control of

reconfiguration and recovery, generally residing at the level above the

failure point. Management of sub-system fault tolerance could therefore

reside in the SSDS Configuration Management/Operating System regardless of

whether the SDP's are dedicated or assigned. There is a some consideration,

however, implied by the NASA Reference Configuration, that the sub-systems

should be fully autonomous with little reliance on the SSDS for anything other

than data transfer and time references. This suggests that the sub-system

Fault tolerance implementation should be totally imbedded within, and

controlled by the sub-system. The final resolution may impact the design

requirements of the SDP to include specific Fault Tolerance Features in the

form of replicated modules for to support failure detection, reconfiguration

and recovery. The issue addressed in this section is whether the SDP should:

l) include these additional features to support a more autonomous approach; or

2) rely on the SSDS operating systems to provide the management.

Discussion of the criteria for this trade effort is provided in the following

paragraphs.

• Cost

The cost of additional features both in initial development and recurrent

costs adds significantly to option I. This differential is somewhat offset by

the added complexities to the SSDS Configuration Management function, however,

the evaluation still favors option 2.

11-29
• Development risk

Rgain, the necessity for the added SDP development scope downgrades option i.

• Performance

For this trade, performance is interpreted as the period of latency between

the failure and the restart. This evaluation favors option I because o? the

perceived reduced response time between fault detection and restart,

particularly if 'pair and a spare F/T techniques' have been implemented. In

many applications a relatively long latency may be acceptable however, because

of commonality goals, the evaluation must align with the most stringent needs.

• Growth

No discriminants have been identified for either option.

3.4.2 Results

Rs shown in Table 3.4-1, option 2, control of fault tolerance by the SSDS is

preferred. Sensitivity analysis shows the key drivers to be recurring costs,

and growth parameters.

3.5 Imbedded vs Stand Alone SDP Options,

3.5.1 Background

As indicated in earlier discussions, there is considerable programmatic

impetus toward standardization and commonality, however, these concepts have

not been fully explored for the SOP with respect to potential control points.

The SOP has generally been discussed as a complete, stand-alone unit. With

the growing availability, and projected increases in single board processors

with both general and special purpose architectures, it appears viable to

consider a specific circuit card/back plane format for the SOP and expanded

processing requirements.

11-30
TABLE3,4 - i

TRADESTUDYTITLE: FAULT TOLERANCE

OPTIONI: AUTON.S/S I OPTION2: SSDS O/S I OPTION3:

CRITERIA I WEIGHT I EVALUATION I TOTAL I EVALUATION I TOTAL { EVALUATION I TOTAL

COST

NON-RECURRING:

RECURRING:

DEVEL.RISK:

PERFORMANCE

DETECTION

RECONFIBURATION

RECOVERY

RELIABILITY:

PHYSICALS

SIZE:

WEIGHT:

POWER:

GROWTHACCOM.

EXTENDABILITY

INSERTABILITY

I0

I0

I0

I0

9

8

63

36

4O

I00

90

BO

3O

40

40

40

28

56

45

BI

56

60

70

60

35

64

64

64

63

72

...................... I I

..................... ============================ :::::::::::::::::::::::::::: l I

i !00 I : 643 I l 734 I i 0 ;

TOTALS: i i _ I _ I I

l_l
3.5.2 Discussion

A stand-alone SDP represents a single box, fully tested by the vendor and

containing the standard complement of memory and I/O capability. It

represents, in fact, a common elemept of the commonality concept. It is also

a fixed configuration, pre-defined to envelope the requirements of all

assigned applications, and is, therefore, less than efficient in terms of

technical utilization. It provides an adequate solution for the application

requirements but may be deficient for some growth concepts. Extendability,

for example, would be limited by the relatively few spare module positions

generally available within the unit, and when modules are added, they must be

added for all applications regardless of need in order to perpetuate

commonality. Technology insertion may also be difficult to implement

depending on the design and form of the internal modules; total SDP

replacement may be required.

The missing attribute of this apprach is a flexibility that could be provided

by applying the commonality control at a lower level. The intense competition

between commercial back-plane vendors will generate superior products and

provide at least a de-facto, if not an institutional, (i.e. IEEE) standard.

The growing OEM and after market support for these back planes is producing a

broad variety of processor in both general and special purpose architectures,

along with memory and I/O products sufficient to satisfy demanding system

requirements. 'Standardization' of a specific back plane and card format for

the Space Station Program applications will allow assigned or dedicated

processing nodes to be established that can be tailored as desired.

This approach facilitates:

• extendability

• technology insertion

• maintenance and repair

11-32
• reconfiguration for added memory or I/0 requirements

• re-architecture for the implementation of unique computer approaches,

The penalty for this flexibility are the added configuration management

requirements to track the larger number of common elements, i.e. circuit

cards, and the configurations of the processing nodes.

The pay-offs for this approach are:

decreased operational costs primary due to reduced spares

capitalization and reduced 'scrap' costs, and,

flexible, efficient processing nodes that can be tailored to specific

applications.

4.0 Conclusions/Open Issues

This study effort has identified the preferred options to a number of the

significant issues concerning the space qualified data processing hardware.

These results indicate that the SDP should be:

a standard 1750A unit with an option for at least a common AI

processor

• fully radiation qualified to the POP levels, and,

• designed without special reconfigurabilities for fault tolerance

The use of a 'standard' back-plane and circuit card format should be

considered to implement a lower level of commonality.
XII. DISTRIBUTED DATA BASE MANAGEMENT SYSTEM

12-1
DISTRIBUTED DATA BASE MANAGEMENT

TRADE STUDY REPORT

1.0 INTRODUCTION

I.I BACKGROUND

A basic assumption made in this trade study has been that the Data Base

Management Systems (DBMS's) that will be used in the Space Station Program

(SSP) will not be designed from basic data base principles but rather will be

vendor products (possibly modified for a specific application). This is

necessary to realize cost effectiveness which is a generic trade criteria. The

organization of data structures within the DBMS, sizing of storage and data

processing are design decisions made after selecting a DBMS. A11 commercial

products are targeted to a host environment consisting of a machine and

associated mass storage devices running under some operating system. The

distributed data base system has other elements as depicted in Figure 1,1.1.

The host environment also contains the user interface and network interface

running under a communication software package. The selection of a DBMS is

coupled with the selection of a11 these host environment support elements.

Although it is assummed that the DBMS trade is a commercial product selection

process it is still necessary to understand the characteristics of DBMS's so

weighted trade criteria can be established on the basis of data manipulation

requirements. The data manipulation requirements are user driven. The

characterization of user data manipulation requirements and the

characterization of the data collection method and location(s) are the primary

drivers in determining the desired DBMS characteristics such as:

data structure

distribution/partitioning

replication/recovery

interface

presentations and reports

The details of various vendor options can be traded to estab].ish the best

match to the requirements. The problem boils down to understanding the

features of various vendor options and understanding the diverse requirements

$

of various SSP SSITS data handling entities. These SSIS entities are

distinquishable because of unique data views and locations. Some ,se(jment(s) of

the SSP DB exist(s) at each SSZS entity. At each of these enti.ties there will.

12-3

P_ECEDING PAGE BLANK NOT FILMED
User Terminals

Storage

f

Operating

System

Comm Software

User Interface I Network Interface

08MS

Processor

/,

/

/ ,_Communi-

/ I cation

| Network

I

/

Figure 1.1.1. Distributed Data Base Management Systems

Operating

System

Comm Software

Network Interface [ User Intface

User Terminals

/

/

/

._. Processor

Storage

12-4
be individuals (or teams of individuals) called data base administrators

(DBA's) with the responsibility to make the data base design decisions. These

DBA's will have to understand the requirements of DB users and available

vendor options to make decisions. This trade study will support the DBA's in

these decisions,

1.2 ISSUES

1,2.1 DISTRIBUTION/CONNECTIVITY

One major decision will be to define to what extent each data base is

reachable from various geographic and space locations. This aspect of data

sharing will drive network design and universal naming conventions for the

data structures (data sets or relations). The complexity of DB interfaces

will also be driven by whether we have homogeneous DB's or heterogeneous DB's.

1.2.2 ADMINISTRATION

The issue here is to insure that the authority for data base management

is established early in the program and this authority is not distributed so

widely that DB state becomes difficult to control, The assignment of

administrators needs to be done as DB entities are defined and clear

partitions are established.

There is a continuum of options here ranging over the spectrum of

possible granularities given to the DB segments. Some common sense must be

applied to assigning administrative authority over DB segments.

1.2,3 REPLICATION/RECOVERY

There is a possibility to implement a recovery scheme by augmenting a

commercial product. This option can be considered if the survey of products

establishes that adequate recovery is not provided or if a vendor option is

selected because of superior capabilities other than recovery and augmentation

is appropriate, Additional back-up by replication of the DB is an option, lhis

may be accomplished by replication in the archive.

12-5
1,2.4 PARTITIONING

1.2.4.1 SPACE/GROUND

Partitioning of data between space and ground is a major design decision.

Data storage and large DBMS software packages in space could present a higher

cost for computational and storage devices because they must be space

qualified.This must be traded against the bandwidth needed for space to ground

transfers and queries. The response time for space queries will have to be

analyzed to determine if acceptable times are realizable. For the most part

this seems possible since the majority of data exchange will be noninteractive (i.e., mainly large text block transfers).

1.2.5 ANCILLARY DATA GROUPING

The performance of an O/B system which allows users an option to acquire

ancillary data and append that data to experiment data will be highly

dependent on the nature of the ancillary data blocks. This presents the O/B

DB designer with decisions concerning ancillary file structures and

granularity of ancillary data access.

A common block required by most users is the vehicle state (attitude,

position vector, time). Other groupings need to be established after user

requirements are understood. These groupings should be such that the O/B data

network is not loaded down with data transfers containing a majority of data

that will be discarded.

I. 2.6 ARCHIVE RESPONSIBII..ITY

A major DB design decision that has impact at the program level is to

determine where the functional responsibility for archiving data resides. The

options are some reasonable assignment of the following data groups to the

major data handling centers.

12.-6
DATA

Engineering

Ancillary

Customer

CENTERS

Data Handling

Space Station Control

PL Control

Regional/Discipline

1.2.7 RECORDER MANAGEMENT

The option to provide bulk recording in the space segments of the DB to

aid in managing the telemetry link is an area for consideration and couples

tightly with the O/B DB design. The management of these recorders is another

area needing consideration (DMS or C&T),

1.2.8 O/B DB OF SUBSYSTEM HISTORY DATA

Another decision facing the O/B DB design is to establish how much and

what subsystem history data will be held O/B for O/B status support, This

design decision couples with the need for O/B autonomy and the communication

system capability to support interactive communication with the ground

segments of the DB.

1.2.9 C(_PATIBII_ITY OF DB's

The use of heterogeneous institutional facilities is a major decision.

Existing data base management systems are to be provided to the Space Station

Program by the Level C centers. This means dealing with heterogeneous DBMS's

and the operating systems that they run under.

1,2.10 STRU(]TURE

The selection of a DB structure for each of the SSP DB's will be an

important decision and require a complete understanding of the data

characteristics and user intentions for data manipulation. Any data structure

selected can be abused and result in poor performance if other factors are not

considered. The organization of data within the constraints of the DBMS

features can be called the DB architecture. It may turn out that this

architecture is more important to performance than the DBMS data structure,

The big decision that will be encountered designing the various DB's for _he

12-7
SSP (besides the selection of a DBMS) will be the characterization and desired

organization (i.e.architecture) of the data within each DB segment. Data can

be broadly categorized into three groups:

a)

b)

c)

Sampled data(sequential numerical; sensor data)

Text (alpha numeric; s/w prgms,presentations)

Associable (tables with correlatable data; mission data)

This characterization will aid in determining the DBMS functions needed

to manipulate each category of data. For Category 1 a flat file server may be

an adequate DB manager option. Category 2 requires more DB manager services,

mainly related to word processing. Category 3 represents data which must be

organized into records or tables so additional information can be extracted by

queries which result in presentations(reports) to the user. For Category 3 we

must decide on the data storage structure (i.e. relational, hierarchical or

network). This decision and the organization of data within that structure

(i.e., architecture of DB) will determine the DB performance (throughput and

response).

1.2,11 O/B INTERACTIVE CAPABILITIES

This issue couples response requirements for onboard DB interaction with

the requirement for onboard autonomy. At issue is what DB segments will be

needed onboard because of autonomous operations and what segments will be

needed onboard because interaction through communication links to the ground

have unacceptable delays or the bandwidth is not availab].e.

1.2.12 GROWTH ACCOMMODATION

Predicting growth in data storage is another design aspect which is

critical. Large structures may become unmanageable requiring further

partitioning and the data base managers must be flexible to absorb

restructuring without impacting application software. Vertical growth (i.e,

built-in margin) is an option and horizontal growth (i.e. expansion by adding

capacity without impact to existing structures) is another option. The DB

designer should factor growth into design decisions.

12-8
1.2.13 ARCHIVE STANDARD FORMAT DATA UNITS (SFDU's)

The SFDU recommendations made by the CCSDS may be built into the DB

archive capability. This is especially pertinent to the archiving of ancillary

and scientific data. It is not clear at this time if the SFDU "labels" are

related to catalogue names used by the DBMS to retrieve data blocks. Further

study and decisions are required to integrate the standard formats into the DB

management.

1.3 TRADE STUDY CRITERIA

1.3.1 GENERIC

The generic study criteria are listed below:

Cost

Risk

Performance

Standardization/Commonality

Growth/Technology Insertion

The specific performance criteria considered for the DB trade study are:

Availability

Ease of use (change, query)

Response time (query, update)

1.3.2 TRADE STUDY UNIQUE

Trade criteria unique to the DB trade are:

User interface

Growth Management

Security

1.4 APPLICABLE OPTIONS

Data Base Management (2.1.1)

12-9
1.5 ALTERNATIVES

1.5,1 LARGE RELA'FIONAL DATA BASE PRODUCTS

For many of the SSP DB segments a large relational DB product will be the

answer. The alternatives for relational DB's and associated host environments

are listed below, Each commercial product has unique characteristics which

can be used to evaluate applicability to the various data base segments. The

complete set of characteristics is not included for ali products because of

the volume of material but is included in the referenced option report.

12-10
TABLE 1.5.1 LARGE RELATIONAL DATA BASES

SYSTEM VENDOR CPU/OS's COST DEV HISTORY

SQL/DS IBM * 370/DOS/VSE

CORP with CICS

• VM/CMS

Commercial version

of SYSTEM R

ORACLE ORACLE

CORP

DG/Eclipse

VAX/VMS,UNIX

370-compatable

/VM-CMS

M68000/UNIX

DEC PDP/RSTS,

UNIX

others

Developed as a

DB manager for

SEQUEL (now SQL)

INGRES RELATIONAL VAX/VMS,UNIX

TECHNOLOGY M6BOOO/UNIX

INC others

Based on the system

developed at the

Univ. Calif/

Berkeley

BRITTON-LEE VAX/VMS

INC ZBO/CPM

Univac 1100

Datapoint i00

DG Eclipse

PDP 11/UNIX

Developed as a

back-end database

processor using

a QUEL interface

iDBP INTEL None announced

CORP

Developed for micro

and office

automation appl.

RAPPORT LOGICA 25 mini's

LIMITED and mainframes

NOMAD D&B 370-compatable/

COMPUTERS VM/CMS

INC NONSTOP II

Originally a

reporting system

action processing

system

SMARTSTAR SIGNAL

TECHNOI_OGY

IN(".,

VAX

12-11
1.5.2 ONBOARD OPERATIONAL DATA BASE MANAGEMENT SYSTEM (ODBMS)

An alternative that must be considered for the onboard operational DB

segment is to use a commercial product. Some modification may be required if

the product is not available for the processor being considered as the

interface to the onboard mass storage. Some form of a UNIX based file service

may be adequate for onboard storage of software programs and text files. The

LOCUS system is a possibility and references are provided in the DBMS option

report. Another distributed system to consider is the DOMAIN system described

in reference 29 of the report. The assessment of options for the onboard DB

must consider many factors:

o

o

o

o

communication with the ground DBMS (homogeneous/heterogeneous?)

performance (response .... )

the inherent program requirement to minimize costly onboard storage

technical issues related to autonomy and automation such as: onboard

diagnostics, training, operations manuals ....

The content of the onboard DB will be a prime driver in selecting an

appropriate onboard DBMS. The Task i function list suggests that the

following are potential segments for residence onboard:

ONBOARD DATA BASE CONTENT

DOCUMENT MANA(;EMENT

- MANUALS(PROCEDURES)

•- DAILY SCHEDULES

- DIAGNOS'I"IC SUPPORT(SCHEMATICS)

SOFTWARE

CHECKPOIN'I"S

SUBSYSTEM TREND DATA

REAL-TIME DATA

BUFFERED DATA(RECORDERS)

12-12
User Interface

Subsystems

j SDP/NIU Node eee

NIU

Local Bus

Subsystem

Devices

NIU

Local Bus

Subsystem

Devices

r"

SDPINIU

Node

I

I

i

I

Network

-1

I

I

I

I

I

I

L. __

Local Bus

I

I

Mass

J Stornge

m

SDP/NIU

Node

Bridge

rEXP Network

q

.,. SDPINIU

Node

I

PL

Processing

I

L.__

Local Bus 1

I

I

I

Mass

Storage J

.J

PL User

Interface

Figure 1.5.2.1. Onboard Data BaseManagement System Interfaces

12-13
The ODBMS manages this data in support'of the subsystems, PL's,

experiments and customers as depicted in Figure 1.5.2.1.

Each subsystem has within its own memory space data that consists of:

a)

b)

c)

Sampled data (raw input data from sensors)

Derived data (computed on basis of stored algorithms)

Static data (algorithm constants that may change only For

reconfigurations or mode changes)

The first two categories correspond to subsystem trend data and real-time

data.

If ali the subsystems were totally autonomous there would be no need to

share this data. The subsystems are not totally autonomous but rather

interact with onboard crew members and ground support to varying degrees,

Subsystems also interchange data. Interchange of data between subsystems can

be through predefined messages or through a data base. Predefined messages

are much faster (without data base intervening) and are the preferred

alternative for all subsystem exchanges, There are some exceptions.

Flexibility is needed in defining telemetry and user interface data

retrieval. If a data base is used for interchange, then some form of "data

acquisition" must be supported to place the data in the data base. This is

especially true in a distributed system where the subsystem data is

distributed among many processors. The data acquisition function moves d_ta

segments into one data processor and manages that data.

1.5.2. I DATA AC(_UISTTION

One alternative is to have the Onboard Data Base Management System

(ODBMS) control the storage and retrieval of ali data generated by subsystems

and intended to be used by user interface and telemetry. (Note: in the

following discussion subsystem is interchangeable with PL/EXP) The control of

this storage could be initiated by the subsystems. This is depicted in Figure

1.5,2.1.1. Subsystems could initiate the storage of current and historical

data at the time of initialization (or later as a result of a software

reconfiguration) by sending a request for service to the ODBMS. The details

of this service are explained in Appendix A.

12-14
Subsystems PL/EXP's

Service Sockets Service Sockets

Data Onboard Telemetry

Acquisition Operational Traffic

Data Base Control

Figure 1.5.2.1.1. ODBMS/User Interface/Telemetry Functional Interface

Service

Sockets Telemetry

Buffer Units

I Ground 1

Operational J

Data Base /

IIIIII.,.!

_,,,__ Service

Sockets

12-15
Another alternative is for each of the subsystems to maintain a separate

data base of parameters and accept requests for data from the user interface

(just as the ODBMS would have done) and build the telemetry buffers directly.

This would place more responsibility on the telemetry subsystem to do the data

merging from multiple subsystem inputs (see Section 1.5.2.3 for the ODBMS

interface to the telemetry buffer unit building service). Rlso, the

workstation programs would not have a central directory to interrogate to see

if a parameter was available (unless the directory was kept by ODBMS with a

mapping to the subsystem owner) and therefore would have to communicate with

ali the subsystem data bases until the parameter was located. In addition,

the service to deliver historical data or current data to the user interface

would have to be carried in a11 subsystem processors along with the software

to collect data into a data base. In effect, we would have duplicated the

entire ODBMS in each subsystem computer and still a user would have to

communicate with ali subsystem ODBMS's to find the data. This is a relatively

unattractive alternative.

In the alternative where the central ODBMS keeps the directory of a11

parameters to be shared but the subsystems own the data, requests for data

would come to the central ODBMS and the central ODBMS could go get the data or

alternatively direct the requestor to the data. This would be an alternative

for user interface data where a "one-time" data exchange might occur. The

direction to the data in subsystem memory space would be on a parameter by

parameter basis and could consist of a message returned to the requestor with

a subsystem ODBMS mailbox address where data can be requested. The user must

then go get the data. The potential delays in this approach appears to make

it unattractive. If the central ODBMS gets the data, the potential delays are

still present because the cen%ral ODBMS must go and collect data on a

parameter by parameter basis by communicating with subsystem ODBMS's.

12-16
1.5.2.2 USER INTERFACE

The ODBMS could support user interface programs which are loaded into the

workstations. These programs could support graphics presentation and tabular

formats defined by the user. The workstation could operate in any of three

modes.

One mode would be called the query mode since the data base is queried

and data is retrieved and presented to satisfy the query. The other two modes

would be menu and command. The menu mode supports the user by help panels

which define all the configurations allowed at the workstation. The command

mode presents panels which allow command and control of subsystems. These

panels would be restricted by authorization access codes. The command panels

could be predefined and only allow selection of predetermined configurations

or modes and entry of parameters within predefined limits.

The query mode interfaces to the ODBMS for delivery of data which is then

formatted by workstation programs. The Format (plots, tables, etc.) could be

selectable by the user.

1.5.2.3 COMMUNICATION SUBSYSTEM INTERFACE

Telemetry buffer units (TBU's) could be built and their content

identified by a function called Telemetry Traffic Control (TTC). The ITC

function delivers TBU's to the communication system buffer space for

modulation and transmission through the communication link. TBU's contain

subsystem data, telecommands, and telecommand acknowledgements. The process

of building a TBU utilizes priority assignments and telemetry packet

segmentation. The TBU may contain multiple telemetry packets (as defined by

CCSDS) or a telemetry packet Fragment. The TBU size will be limited to the

communication subsystem toggle buffer size. Sending TBU's close to the buffer

size would be essential to avoid bandwidth loss when a toggle buffer is still

being filled and transmission of the other is complete.

12-17
The TTC interface to the ODBMS has several alternatives. The simpliest

alternative would be to assume that the subsystem records collected into the

OD8 by data acquisition function are identical (rates and content) with the

telemetry requirements to the ground data base. This alternative is depicted

in Figure 1.5.2.3.2 where the ODB supports TTC. In this case the grouping of

data into a TBU would be by rate group and priority. A rate monotonic

priority scheme could be assumed; (i.e., the higher the rate, the higher the

priority).

The identification of the contents of periodic TBU's could be constructed

by TTC using the UNIQUE-OBJECT-NAMES (UON's) defined by the subsystems and

maintained by the ODBMS directory. After deciding what the contents of each

periodic TBU will be (possibly multiple periodic subsystem records), the TTC

would construct a message containing the UON's that would be in the periodic

TBU's and attach a unique TBU name (UTBUN) and transmit to the ground data

base. The ground DB would have a similar server to the ODBMS, accepting

messages to define periodic TBU's.

The layout of this message to the ground data base would have the

following format.

Figure 1.5.2,3,1

UNIQUE TELEMETRY BUFFER UNIT I[)ENTIFICAFION MESSAGE TO GROUND DB

II I_Ill

UTBUN

RATE - GROUP

UON 1 l FIELD i

UON 2 I FIELD 2

I

l

I .....

32 bytes 1 byte

The TTC would then maintain a schedule of TBU's that must be built

periodically and perform this function, Each time the UTBUN would be attached

as a header before transmission of a UTBU to the ground DB, The ground dat;a

base would maintain a directory of UON's available for ground user interface.

12-18
Subsystem Processor

Task 1 Memory

Task 2 Memory

SDP/NIU Node

Task 3 Memory

Subsystem

Data

Collection

Process

Figure 1.5.2.3.2. TTC Interface (Alternative 1)

SDP/NIU Node

I

L "°°_1

Toggle to

Comm I/F

12-19
Subsystem Processor

SDPINIU Node

Task 1 Memory

Task 2 Memory

Task 3 Memory

Subsystem

Data

Collection

Process

Figure 1.5.2.3.3. TTC Interface (Alternative 2)

SDP/NIU Node

TTC

]

I

I

I

I

I

I

I

J

Toggle

to

Comm

I/F

v

12-20
The other alternative is to allow the telemetry parameters to be defined

independent of the ODBMS subsystem record definitions. Within this

alternative are several sub-alternatives. The subsystems could establish an

interface to the ITC (much like the one between the ODBMS and subsystems) and

communicate telemetry records directly. This would take the ODBMS out of th_

loop completely. This alternative is depicted in Figure 1.5.2.3.3.

R1ternately, a list of parameters (UON's) and rates could be sent to TTC which

in turn would gather the data from the ODB and build rate grouped TBU's. The

overhead associated with this sub-alternative makes it unattractive.

Some TBU's will contain aperiodic data. Data for these TBU's could be

communicated directly to TTC and bypass the ODBMS. These TBU's will not be

able to use the unique content identification approach (UTBU can only be used

for periodic data defined with UON's). These TBU's will have to carry content

identification as part of the TBU. The content identification could consist

of a variable length leader defining the number of segments in the TBU and

their locations within the TBU. [The final destination is a part of the TLM

packet format (CCSDS)]. TLM packet fragments delivered in TBU's will have to

be reconstructed in the ground data base before the entire Tt.M packet is

forwarded to the final destination.

1.5.2.4 MRSS MEMORY CONF'IGURRI"ION

There are several issues associated with the configuration of mass memory

onboard the space station; distribution, flight build-up, redundancy <_nd

integration with the other DMS elements (SDP's and NIU's).

The distribution issue addresses the physical distribution within the

space station structure and also distribution on the PL and core networks.

Figure 1.5.2.4.1 shows two alternatives for distribution on the PL and core

networks. The first alternative has a11 the mass memory attached to a SDP/NIU

node on the core network. This alternative would mean that PL/EXP interfaces

with ODBMS would be through the network bridge. This could present a

bottleneck. The ancillary data service would be across this interface in

either alternative since ancillary data originates within the core network.

12-21
Alternative 1

Core

Subsystems

I SDP/NIU I

Node " "

•ISDP/NIUJNode

Core Network

ODBMS

II I MM

SDP/NIU

L__

Mass Memory

Managed I n

Core Network

8R

PL Network'

Alternative 2 [ I

Core

Core I ODBMS I

_u0,_,,e_, ' I _ I'

I SDP/.,oI I SDP/N,OI , I soP/N,o!. + I

INode r.. iNode j . i.ode r.---- I

L_ _!__ '

Co;e'N'et'work'_ _//////////////. _....... Y/////////////_

t

SDP/NIU

Node " •

PL/EXP

PL/EXP Mass Memory

Managed In PL Network

Figure 1.5.2.4.1.

/PL Network'

r m

I SDP/NIU

I Node

I

I PL

ODBMS

L_

MM

ODBMS Alternatives (PL/Core Distribution)

SDP/NIU

Node

PL/EXP

12-22
The first alternative has the advantage of having only one ODBMS resident in

the $DP/NIU nodes. The second alternative has separate mass memory elements

attached to a PL network SDP/NIU node. The ODBMS resident in this node would

service PL/EXP users. This eliminates some of the bridge traffic but

potentially introduces the complexity of communication between two ODBMS's.

In addition, onboard complication wou_d be introduced if these two ODBMS's

were not homogeneous (which would be an alternative).

Another issue is the flight build-up of mass memory. The first flight

delivers the transverse boom structure. It appears to be advisable to

minimize the mass memory on the truss because of difficulty in maintenance and

to minimize the volume of DM$ on the first flight. On the other hand the

ODBMS will have functions required from the first flight that need mass memory

elements, These functions are: SDP and NIU program loads, telemetry

interface buffering for TDRSS loss and checkpoints for restart. The first

alternative depicted in Figure 1.5.2.4.2 is to have the SDP/NIU nodes contain

a nonvolatile memory (as well as working memory) where programs could be

loaded and used at start-up. This non-volatile memory would also have to be

used by ODBMS for the other functions (checkpoints and telemetry buffering) or

else these functions would not be supported. There is an alternative to just

support checkpoints using the SDP non-volatile memory for the first and second

flight. The mass memory units would be added later on a flight with a

pressurized module. One disadvantage of this alternative is that the ODBMS

interface to memory is changed when the external mass memory becomes

available. Also the ODBMS needs to run redundantly otherwise loss of an SDP

would mean loss of the ODB. Communication between ODBMS's in SDP's would be

needed to maintain multiple copies of the ODB.

The second alternative is to have mass memory units delivered on the

first flight. If these are highly reliable units, this is also a viable

alternative. The possibility of adding redundancy at a later flight is

another alternative. A ground uplink to the SDP/NIU nodes can be used to

augment the reduced onboard redundancy.

12-23
Alternative I

SDP/NIU Node

I SOP

Memory

NIU

O00

SDP/NIU Node

I SDPI Volatile

Memory

NIU

Local SDP/NIU Non-Volatile

Memory For First Flights

(Recovery of Non-Volatile

Memory By Transfer From

Redundant Elements or

Ground)

I

I

I

lOgO

I

I

!

NIU

SDP

SDP/NlU Node

gO0 I

I

I

.J

Alternative 2

I SDP/NIU I • • O I SDP/NIU ]

_..'////_/////.I/.I//.ll.'_;o_.',._.us. _////////////..'///A

SDP/NIU • • •

Node Node

Figure 1.5.2.4.2.

I- I'-'I

ODBMS Alternatives (Flight Build-Up)

Added on Later

Flight in Pressurized

Module

Mess Memory

Available From

Flight 1

12-24
The redundancy and integration of mass memory with the other DMS elements

couples tightly with the flight build-up issue. The first alternative

depicted in Figure 1,5,2,4.3 is to have the mass memory units separate from

the SDP/NIU nodes and have communication to the MMU's on a Standard Seri.al

local bus (the same bus used for subsystem sensors and effector

communication). The ODBMS would be resident in the local SDP/NIU node

controlling the MMU's. The redundancy in this alternative would be three

MMU's attached to a SDP/NIU triad. Any of the SDP/NIU's in the triad could be

in communication with any of the MMU's (i.e., multiple ports to MMU's), Since

local buses are used to communicate to the MMU's, the SDP/NIU's and MMU's will

have to be co-located, This would mean that this alternative is coupled with

delivering ali the MMU's on the first flight (transverse boom) or on flight 3

(habitat module). A build-up in redundancy would not be possible without

running local buses from the truss to a pressurized module (which is

undesireable). Alternative two is the same as alternative one except a

parallel bus is used for NIU to MMU interface. This addes a special port to

the backend of the NIU. This alternative would be a fall back for alternative

one if the data rates on a serial bus were determined to be inadequate. The

disadvantage is the addition of a third port to the NIU backend. The NIU

backend already must support serial local buses and the SDP interface.

The third alternative is to have an integrated SDP/NIU/MM node, (See

Figure 1,5,2.4.3) In this alternative the communication between mass memory

and the computing elements is on an internal bus. The disadvantage of this

alternative is the creation of a non-standard node. The advantage is the

potential for a more manageable and higher rate communication to the mass

memory. Another advantage would be the flexibility for redundancy build-up.

One of these special SDP/NIU/MM nodes could be delivered on the first flight

and uplink used as a fall back. The redundancy could be upgraded by

delivering two additional nodes in habitat module one.

12-25
ODBMS (Backup)

fNIU Node J

SDP

ODBMS (Backup)

SDP/NIU Node

SDP

Standard SDPINIU Used

With Standard Serial

Local Bus Interface

Local Serial Bus

.f .f _f

Alternative 2

Same as Alternative 1 But With Parallel Interface Between NIU and MMU.

Alternative 3

ODBMS ODEIMS

Node I • • • Node

Figure 1.5.2.4.3. ODBMS Alternatives (Mass Memory Integration)

Integrated Node For

Mass Memory Interface

to Global Bus

12-26
1,5.3 SPQCE/GROUND PQRTITIONING

The alternatives for each DB entity is to have the DB fully partitioned

(that is each of the DB segments resides at exactly one location) or fully

replicated (that is each segment of the DB resides at all locations) or

something in between. The problem with full replication is that updates must

be exchanged to keep the copies consistent. Also, network delays can mean

slow response. Partitioning the DB can result in improved performance by

allowing a 10cal computer to just handle local transactions (if the queries

concern the local partition, otherwise, the other partitions must be acquired

from the owner).

The alternatives that must be considered for space/ground partitioning is

to replicate partitions of the data base in space when queries in that

partition occur or have the queries relayed to the ground DB and responses

returned to space. The same alternatives exist for ground query of space

partitions. Partitions of the DB originating and being updated on a periodic

basis could be kept in space and relayed to the ground for queries.

12-27
2.0 METHODOLOGY

The approach taken in this trade study is to consider all SSIS DB

entities and then to concentrate on the characteristics of the SSDS DB

embedded within the SSIS, in particular the Space Station Operational Data

Base (ODB) and the interface to the ground data base. For the entire data base

problem this approach translates into the following stages:

i , Define all the SSIS DB entities using the TASK 1 functions list and

the basic premise that partitioning will be along established NASA

institutional boundaries.

, Determine which of these DB's are within the SSDS (exclude IMIS

segments) while still considering required connectivity and

interfaces of a11 segments.

° Characterize the SSDS DB entities by:

a) data content(type and source)

b) functional manipulation requirements

c) connectivity required

, Define alternatives for commercial products applicable to the ground

segments.

, Define alternatives (commercial, modified commercial or "roll your

own") For space segments,

6. Partition the SSDS DB's by space/ground segments

7, Partition the SSDS DB ground segments to as low a level as required

to seperate by utilization (development,operational, scientific/PL)

and also by interest domains, data types and DBMS functional

requirements.

12-28
0 Trade alternatives and define recommended SSDS DB architecture

including for each DB segment:

data structure

distribution/partitioning within segment

replication/recovery

interface

presentations and reports

12-29
3.0 RESULTS

It is not the intention of this trade study to recommend a data base

(i.e., a commercial product) for each of the ground segments but rather to

suggest a reasonable segmentation of DB's and reasonable commercial

architectures for each segment. The selection will be done by the data base

administrators and management based on further evaluation of alternatives. It

is the intent of the trade study to analyze alternatives for the onboard data

segment and connection to the Space Station Control Center (SSCC) data bases

and Payload Operations Control Centers (POCC).

3.1 DATA BASE SEC4MENTAI'ION

Within the SSP all data bases can be separated into TMIS DB's and other

DB's. This separation allows the TMIS to be considered part of the SSIS but

not the SSDS. This trade study is principally concerned with the SSDS DB's.

The data base maintained by the TMIS corresponds to section 7.5 of the

functions list, that is "Configuration Management". The I'MIS is considered to

contain the following data segments:

TABLE 3.1.1 TMIS DATA CONTENT

DATA BASE DATA BASE CONTENT

LEVEL B SE&I

MASTER DATA BASE

(MDB)

LEVEL B SE&I

ENG MASTER SCH

(EMS)

LEVEl_ C SE&I DB

- LEVEL A SPEC

- SSIS CONFIG(CONNEC'I"IVI'I"Y,ICD's)

- REF CONFIG(DRAWINGS,TEXT)

- WP ICD's

- SE&I SCHEDUI_ES

- S/W SCHEDULES

- HARDWARE SCHEDULES

- HARDWARE SPEC's

- SUBSYSTEM ICD's

- SIW REQUIREMENTS

- SSE REQUIREMENTS

12-30
The need for data bases other than TMIS is clear from the Task 1

requirements in Appendix A of the DBMS options report. The segmentation of

DB's other than TMIS is along established NASA institutional boundaries.

TABLE 2.1.2 DATA BASES OTHER "THAN TMIS

DATA BASE DATA BASE CONTENT

SSE DB

TRAINING DB

INTEGRATION SITE

DB

SSCC DB

POCC DB

RDC/DDC DB

SS OPERA'TIONAL

DB

COP/POP

OPERATIONAL DB

DHC DB

- SOFTWARE

•- MODELS

- TEST SCRIPTS

- RESOURCE SCHEDULING

- PROCEDURES

- SCHEDULES

- SOFTWARE

- INTEGRATION SCHEDULES

- PROCEDURES

-TEST SCRIPTS

- SPACE STATION STATUS

- MISSION SEQUENCING

- COMMAND PROCEDURES

- PLATFORM/PL ENGINEERING DATA

- EXPERIMENT DATA

- SS ANCILLARY DATA ARCHIVE

- PLAT ANCILLARY DATA ARCHIVE

- FF ANCILLARY DATA ARCHIVE

•- MANUALS (PROCEDURES)

- DAILY SCHEDULES

- DIAGNOS'T'IC SUPPORT

- SOFTWARE

- CHECKPOINTS

- SUBSYSTEM TREND DATA

- REAL.-TIME DATA

- BUFFERED DATA (RECORDERS)

- ENGINEERING DATA

- SCIENTIFIC DATA

- LEVEL O DATA

.- SHORT TERM ARCHIVE

- LONG TERM ARCHIVE

12-31
]he entities identified and associated connectivity are listed in the

following Table 3,1.3 and shown in Figure 3,1.I.

TABLE 3.1.3 : DATA BASE ENTITIES AND CONNECTIVI'T'Y

NASA HDQTRS

LEVEL B JSC

LVL C JSC

LVL C GSFC

LVL C MSFC

LVL C LEWIS

CONTRACTOR 1

CONTRACTOR 2

CONTRACTOR 3

CONTRACTOR 4

SSE

SSCC

POCC

FtDC

DDC

INTEG SITE

TRAINING

SPACE STN

COP

POP

DHC

HILl LVL

DIVI C

QILI

TI I; G M L

RIBIS S S E

Sl IC F F W

II ccI

CON ISIS

TRACTORISIS

IEIC

1 2 3 41 IC

II

II

II

PIRID

OIDID

clclc

cl I

II

II

II

IITIS

NIRIS

TINI

EIII

GINI

IGI

II

Ixll

xl Ixlx

Ixll

Ixll

Ixll

Ixll

Ixl

X

II

xlxl

Ix

I

I

I

I

I

x I

Ixl

Ix

I

I

I

x I

xl

Ix

X X

Ixl

ixl

Ixl

Ixl

xl Ix

Ixl

I Ix

II

II

Ixl

Ixl

I Ix

I I

I I

I Ix

X

xlx

X

X

X

xlxlx

xlxI

X

X

ClPID

OIOIH

PIPIC

II

II

I I

II

X

Ixlx

X

X

X

X

X X

X

X

xlxl

12-32
MOB

SCHs

SSlS Con fig

WP ICDs

S/W

Models SD E

S/W

Models

DHC

Level 0 Data' I

Short-term Archive I

Long-term Archive J

WP ICDs

Bulk

Recorder MSFt

LeR

Connectivil

way

LAN

i_On-Line

Storage

ComDuter

O,

Major

Archive

Hrdwre Spec

Subsvs ICDs

S/W Reqmt

SSE Reqmt

Figure 3.1.1.

Hardware

Specifications SS Eng Data

Requirements Mission Seq

ICOs Command

SSE, Procedures

Requirement

Contractors

Development

Operational

SSIS Recommended Data Base Distribution

SSCC

I=

PL Eng Data

._S Ancillary

PLAT/PL Eng Data L_

Exp Data IL _

PLAT/PL

Ancillary \

Data

SS Ancillary Data Public

Network

Scientific/PL

Exo Data

RDC/

__ DDC

] I I Ancillary I

,_1 Arch J

12-33
TABLE 3.2.1 DATA BASE SPACE/GROUND DISTRIBUTION

P - PRIMARY OWNER

S - SHARED REPLICATION COPY

- OPERATIONAL DATA HISTORICAL ARCHIVE

SSE DB

TRAINING DB

DATA BASE

INTEGRATION SITE DB

SSCC DB

POCC DB

RDC/DDC DB

SS OPERATIONAL DB

DATA BASE CONTENT

- SOFTWARE

- MODELS

- TEST SCRIPTS

- RESOURCE SCHEDULING

- PROCEDURES

- SCHEDULES

- SOFTWARE

- INTEGRATION SCHEDULES

- PROCEDURES

- TEST SCRIPTS

- SPACE STATION STATUS

-MISSION SEQUENCING

- COMMAND PROCEDURES

- PLATFORM/PL ENGINEERING DATA

- EXPERIMENT DATA

- SS ANCILLARY DATA ARCHIVE

- PLAT ANCILLARY DATA ARCHIVE

- FF ANCILLARY DATA ARCHIVE

I

COP/POP OPERATIONAL DBI

I

I

DHC DB

- MANUALS (PROCEDURES)

- DAILY SCHEDULES

- DIAGNOSTIC SUPPORT

- SOFTWARE

- CHECKPOINTS

- SUBSYSTEM TREND DATA

- REAL-TIME DATA

- BEFFERED DATA

- ENGINEERING DATA

- SCIENTIFIC DATA

- LEVEL O DATA

- SHORT TERM ARCHIVE

- LONG TERM ARCHIVE

DISTRIBUTION/

REPLICATION

SPACE GROUND

P

P

P

P

P

P

P

P

P

P

P

P

P

P

P

P

S

P

P

.)(.

P

P

P

12-34
TABLE 3.2.2 SPACE STATION OPERATIONAL DB

P - PRIMARY OWNER

S - SHARED REPLICATION COPY

OPERATIONAL DATA HISTORICAL ARCHIVE

PARTITION PLACE OF ORIGIN

GROUND

SPACE

GROUND

GROUND

SPACE

SPACE

SPACE

SPACE

DISTRIBUTION

SPACE

MANUALS (PROCEDURES)

DAILY SCHEDULES

DIAGNOSTIC SUPPORT

SOFTWARE

CHECKPOINTS

SUBSYSTEM TREND DATA

REAL-TIME DATA

BUFFERED DATA

S

P

S

S**

P

P

P

P

GROUND

P

S

P

P

NOT NEEDED

** NOTE l: THE LATEST VERSION OF SOFTWARE IS ALWAYS RESIDENT IN THE SPACE ODB

(I.E., A REQUEST FOR AN OVERLAY DOES NOT TRIGGER A TRANSFER FROM

GROUND TO SPACE; OLD VERSIONS ARE AUTOMATICALLY REPLACED UPON

RELEASE OF A NEW VERSION, AUTOMATIC REPLACEMENT IF ACTIVE IN AN SDP)

3.2 SPACE/GROUND PARTITIONING

In Table 3.2.1, the SSDS data bases are listed and a distribution between

space and ground is suggested. Some elements of the data bases are shared

between ground and onboard (e.g., training procedures, Space Station

status, ...). What is suggested here is that some segments of the DB's could

be replicated in space (i.e., the current version could be copied on request

12-35
and held in the space ODB partition). That is the ability to retrieve DB

files (mainly from the ground) could be provided and these files would be held

in the space ODB until another more recent copy was retrieved for a new

session. The space in the ODB for the copy would be released as the session

is closed.

The selection of the partitions of the DB which could use this method o?

controlled replication were determined along the following lines of reasoning.

There are two major types o? data that are maintained in the operational

data base: "realtime data" which is being updated periodically at a high

frequency (e.g., sample subsystem data) and static data which is updated very

seldom (e.g., software, diagnostic aids, etc.). The realtime data originates

in space and some amount must be held there ?or user inter?ace and subsystem

support. There is no need for controlled replication in this case since the

sampled data must be delivered to a ground data base for ground support and

archiving. In Table 3.3.2, we see that the sampled data partitions are

delivered to an archive and do not use the controlled replication method. The

other partitions fall into the "static data" category and can use controlled

replication ?or sharing.

The alternative to shared replication is data query by transmission from

space to ground and response to the user terminal. In Figure 3.2.1, the

capabilities for return and forward links messages are presented. These

channel capacities are shared with other communication requirements (voice,

video, subsystem periodic data, etc. and therefore all this bandwidth is not

available for block transfers). In the shared replication alternative, a

block of data is transmitted on the communication links and then no further

traffic is on the communication link. Interactions occur between the

transferred block and the local terminals. In the remote query alternative,

every query results in communication link transmission. It appears that the

communication link capacities support the selection of block transfers (for

shared replication). There would be an initial delay while the data block is

transfered, but then the delays would be minimized since the local ODB would

service querys. The partitions of the ODB recommended for sharing replication

are all "text" type data (e.g., diagnostic procedures, etc.) and therefore, by

12-36
the nature of the functions being performed the initial delay appears to be

acceptable. If it is determined at a later time that the block sizes are to

large for this alternative, some feature in the ODB could be considered which

selects between the block transfer and the remote query. This would be a

transparent selection process.

12-37
Space

Queries

Ground

Queries

Return Link

[Telemetry/

Telecommand

Messages]

•Forward Link

[Telemetw/

Telecommand

Messages]

Figure 3.2.1. Operational DB Ground/Space Partitioning

12-38
3.3 SSP DB SEGMENT CHARACTERIZATION

The requirements for data base services at each entity is shown in the

following table. The characterization of requirements was extracted from

reference material in Appendix B of the SSDS A/A option report.

TABLE 3.3.1 : DATA BASE MGMT SERVICE REQUIREMENTS

NASA HDQTRS

LEVEL B JSC

LVL C ;SC

LVL C GSFC

LVL C MSFC

LVL C LEWIS

CONTRACTOR I

CONTRACTOR 2

CONTRACTOR 3

CONTRACTOR 4

SSE

SSCC

POCC

RDC

DDC

INTEG SITE

'TRAINING

SPACE STN

COP

POP

DHC

I FILE SERVER IT

I IE

IC

IR

IE

IA

IT

mE

SlRICIM

TIEIOIE

OITIPIR

RIRIYIG

EIII E

IEI

IVl

iE

I

I

I

I

I

DIUIX

EIPIT

LIDI

EIAIP

TITIR

EIEIO

IC

REPORTSIINTERFACEISIA

I LANGUAGEIEIR

CIU

AIS

NIE

NIR

El

DIS

P

E

C

PIGI

LIRIA IIRIP

OIAID NIEIR

TIPI TIAIO

SlHIH EILIC

IIIO RITIE

ICIC AIIID

ISl CIMIU

I IQ TIEIR

I lU IIIA

liE Vl IL

I IR Ell

I IY I I

IClC

IUIH

IRII

IIIV

ITIE

IYI

I I

iRI

IEI

IQI

IDI

I I

I I

Xl

IXl

IXl

IXl

IX

IX

IX

IX

IX

IX

IX

IX

IX

IX

X

Ix

x

Ix

X

X

X

xlxlxlx

xlxlxlx

xlxlxlx

xlxlxlx

xlxlxlx

x xlxlx

xlxlxlx

x xlxlx

xlxlxlx

x xlxlx

xlxlx x

x xl

xlxl

XX

xlxl

XX

xlx

xlx

xlx

xlx

xlx

xlxlxlx

xlxlxlxl

xlxlxlx

xlxlx, IxI

xlxlx x

xlxlx xl

xlxlx x

xlxlx xl

xlxlx x

xlxlx xl

xlxlx x

x xlxl

x xlxl

x xlxl

x xlxl

x xlxl

x xlxl

x xlxl

x xlxl

x xlxl

x xlxl

x xlxl

xlxl

xlxl

II

II

II

II

xlxl

II

II

II

x xlxlx

x xlxlx

x xlxlx

x xlxlx

x xlxlx

x x xlx

x xlxlx

x x xlx

x xlxlx

x x xlx

x xlxlx

X X

X X

X X

Ixl

Ixlx

Ixl

Ixl

Ixl

Ixl

Ixl

Ixl

Ixl

Ixl

Ixl

Ix

Ix

Ix

X

sl

TI

AI

TI

II

Sl

TI

II

Cl

AI

LI

I

FI

C

N

12-39
4,0 CONCLUSIONS, RECOMMENDATIONS AND REMAINING ISSUES

It is recommended that the control of all SSDS data bases (content,

structure, connectivity, etc) be administered by NASA Level B. Local

administrators would be accountable to a DB coordinating authority. The

recommendations for subdivision of SSDS data bases and their connectivity is

presented in Table 3.1.3 and Figure 3.1.1. It is recommended that the

contractors TMIS DB be connected to the JSC Level B DB (containing the NASA

partition of TMIS; namely the MOB and EMS) and to the Level C center

(containing specifications and ICD's). Other connectivity to support data

exchange is presented in Figure 3.1.1.

The recommendations for space/ground partitioning are given in Table

3.2.1. Basically the originating source of data contains the primary data

base with controlled replication at remote sites. It is recommended that a

limited history of engineering data (i.e., sampled subsystem data) originating

in a Space Station be held there for trend analysis and user interface. The

realtime data should be delivered directly to a ground data base in the

Control Center for archive. Engineering data from other unmanned space

elements should be delivered directly to the Ground Control Center for

archive. All ancillary data should be archived at the Control Centers,

Regional Data Centers (RDC) and Discipline Data Centers (DDC). Space Station

ancillary data should be delivered from the SSCC to the POCC's. Experimental

data should be archived at the RDC/DDC.

The recommendations for SSDS data base characteristics are presented in

Table 4.1. Within each data base the general content is presented and a data

structure recommended. In some cases several structures are recommended since

the DB contains partitions with different data applications. An example is

the SSE data base where the software is in hierarchical data sets but the

configuration management is relational.

12-40
I'--

i

d

cPlO

i,_lQ.

O>-

m-e_

,qC_

m,-Gr,.1

Qg

lie

P_

b--

¢.b

-.j

Q_

If'-

Z

I.iJ

I--

Z

0

f.b

W

q[

,IC

n_

I--

0

..Jim

ZO

I I I

_00

! !

OZ_

ZO

Z_

_Z_

_Z

ill

. _

_ 0

i I

z_

i

I I I I

--- _---

_ _Z

II I II

Z

IIIII II

I Ii I

0

Z

Z

ZO

_CQ.

I I !

I.iJ _'

I

I

.J

9[

!

Z I.-

_Q.

I I l I

IIII

I,--

I,-

_Z

II|

I I

Z_

i

_J

Z,-,_

I

me_i

_Z_

_._

ZC_

Z t_._ _

_._

Ii_j_

_.

_ZO

_Z

I I I

I I

_I_

_I_

Z_ IZ_

_Z|_Z

II _11

'eC

=¢e¢

Wl--

="_ e¢

I

0

Z

lie

Id.I

=iI

_. k--,

k- Wi

C_. _I

I I

I II I

0

c._w

wl.-

=°

l.m.I

,v QI_

I--

_ ,--IQII

.J ¢._ ..I

I I I

W_

E_

Z

I I

.z

I I

wl,--_

i I I I I I I 1

I

==.

I _

zo I

i i 'I- I i

In-

_ "_ _'_i '' _'_ I" l

0 _*_" I L_. _ _ I

Z_ ZUJ

I

I

[

Z(-._ _"

I--I i--I

__sL.I_SSL

CO

r-,

1241
All the data base entities are recommended to be centralized with the

capability to share data by transmitting copies of DB partitioning to remote

sites during query sessions. The star of each query session would result in a

fresh snapshot of the DB partition being transmitted so intervening updates

are be incorporated. This recommendation is made with the caviot that if the

partitions blocks turn out to be too large, then the alternative for remote

query be kept in reserve.

At each centralized site it is recommended that multiple replications be

maintained for system and media failures. The depth of replication should be

determined by criticality and established by the DBA.

It is recommended that the user interface to all data bases through

directory query. The directory for ancillary data and experimental data

should be in Standard Format Data Units (SFDU). The ability to perform ad hoc

query on sampled data records should be supported. All DB's should support

help panels, directory panels and standard report formats. Graphics

presentation should be available in the SSCC ODB and Space Station ODB.

4.1 SPACE STATION OPERATIONAL DATA BASE

The content of the Operational Data Base (ODB) is presented in Table

3.2.2 along with the distribution between space and ground of each major

partition. Current estimates of the onboard ODB are as follows:

The DM$ must provide storage for 256 Mbytes on on-volatile memory.

90 Mbytes

IO Mbytes

10 Mbytes

10 Mbytes

10 Mbytes

50 Mbytes

76 Mbytes

application program loads

checkpoints

engineering data

procedures

schedules

telemetry data acquisition

growth margin

12-42
It Is recommended that the onboard operational data base have the

structure suggested in Figure 1.5.2.1. This alternative Is Alternative 1 in

Figure 1.5.2.4.1. A separate ODBMS service would exist In the Core Local Area

Network (CLAN) and the Payload Local Area Network (PLAN). These ODBMS's would

be homogeneous and communicate to support ancillary data distribution, and

other standard core services.

It ts recommended that the alternative presented in Figure 1.5.2.3.2 be

used for the data acqutsttlon interface to the ODBMS. The subsystems would

collect data into records and deliver these records to the ODBMS on a

dynamlcally negotiated basis. (More details tn Section 1.5.2.1 and

Appendix A) The ODB would support Telemetry Traffic Control (TTC) tn butldtng

Telemetry Buffer Units (TBU's) for dellver to the communication toggle

buffers. The same interface Is recommended for PL/EXP except the PL/EXP would

deliver data in CCSDS telemetry packet format. The TTC would segment these

packets (tf necessary) when building the TBU's.

For the butld-up of the onboard mass memory configuration tt ls

recommended that Alternative 1 presented In Figure 1.5.2.4.2 be used. In thls

configuration the SDP/NIU nodes manage local non-volatile memory for the first

two flights and then mass storage units are delivered in the first pressurized

module (HMI).

The recommended mass memory integration wtth other DMS elements is

presented as Alternative I tn Figure 1.5.2.4.3. In this configuration the

mass storage Is on a local bus (serial or parallel to be determined) on the

backend of an NIU.

4.2 REMAINING ISSUES

All of the issues mentioned In Section 1.2 still remain open to some degree

and the following issues also need to be considered. The matter of

integrating text and graphics In DB partitions which contain presentations and

reports needs to be addressed.

The compatibility of ground DB segments needs to be considered In light

of the recommended DB connectivity.

1243
The concept of a switchable interface to mass store for the buffering of

data and then merge in the communication subsystem (as shown in Figure 4.2.1)

needs to be evaluated. This is the proposed interface to the communication

node to get buffered data merged with realtime data.

12-44
,Core DMS Subsystem

NIU

Local Bus

Data Ac(

TTC

TLMCMI

I/F

Local Bus

High Data

Rate Direct

Link

IPL Network'

Local Bus

NIU

R-SSA 1 F-SSA

Comm Comm

I/F I/F

I Comm _ _ Baseband

i R F Proc

Figure 4.2.1. Communication Gateway

__/o!SmA Data Accl

TTC

Comm

Store

I Buffer Mgmt Communication Subsystem

12-45
5.0 REFERENCES

"Space Station Data Base Management Study", Computer Technology

Associates, Inc., November 18, 1983

1246
APPENDIX A

DATA ACQUISITION CONCEPT

This Appendix expands on the data acquisition service concept.

Subsystems could, lnltlate the storage of current and historical data by

sending a request for service to the ODBMS. The service request could be to a

standard mall box (with multiple sockets to service concurrent requests) with

the following layout.

12_7
Figure 1.5.2.1.2 DATA ACQUISITION REQUEST FORMAT

REQUESTORSMAILBOX_ADDRESS

PARAMETER_LENGTH I RECORD_LENGTH

I

PERIODIC/APERIODIC I PERIOD

I

HISTORY_REQUEST I HISTORY_LENGTH

I

UNIQUE_RECORD_NAME

The REQUESTORS_MAILBOX_ADDRESS is an object name where the ODBMS can

request further information about the subsystem storage requirements. The

PARAMETER-LENGTH indicates to the ODBMS how many parameters are in the record

and the RECORDLENGTH indicates the number of bytes in the record. The

Periodic/Aperiodic flag indicates if the record is to be sent to the ODBMS on

a periodic basis or just once. PERIOD specifies the period in seconds. If

the HISTORY_REQUEST flag is set, this indicates that back values are to be

saved. If back values are to be saved, the number of back values is indicated

in HISTORY_LENGTH. The UNIQUE_RECORDNAME (URN) is the name assigned by the

subsystem to identify the records that will be sent to the ODBMS.

The ODBMS then sends a message to the requestor's mailbox address and'

requests a record definition to be returned. The record definition contains

the subsystem parameter object names and the number of bytes for each

parameter (field length). The ODBMS then stores this data in a parameter

directory containing all unique object names (UON) available from the ODBMS.

(See Figure 1.5.7.1.5) Each object name is limited to 32 characters.

Figure 1.5.2.1.3 SUBSYSTEM PARAMETER DEFINITION

I SUBSYSTEM-OBJECT-NAME-1 I Field - 1 I

I SUBSYSTEM-OB3ECT-NAME-2 I Field - 2 I

I I I

I I I

I I I

12148
The ODBMS sets up a mailbox to receive the data record from the subsystem

and also establishes a memory space ?or the historical data on mass storage.

The historical data is maintained in a circular file. Each record from the

subsystems has the following format:

Figure 1.5.2.1.4 RECORD FORMAT

UNIQUE - RECORD - NAME I

UON 1 I

UON2 I

I

I

I

Figure 1.5.2.5 HISTORICAL RECORD FILE

RECORD (K-Z)

Curr. Record

Pointer

Next Record to

be Overwritten

RECORD (2)

RECORD (1)

RECORD (HISTORY-LENGTH)

RECORD (K)

'N' Records

In File

When the records received reach the HISTORY-LENGTH, then the pointer

wraps around and several alternatives exist. If an archive history file is to

be maintained for this subsystem record, then at each pointer wrap, the total

history file could be telemetered to a ground data base for archive storage.

The ground data base would be informed of the data content by a similar

mechanism to the subsystem interface to ODBMS. Alternatively, each record

could have been telemetered immediately that the current record was updated by

the subsystem for ground operational DB support.

The ODBMS could then accept requests to retrieve data from the parameter

catalog on an UON basis. The current value can be requested or any number of

historical records up to HIST-LENGTH.

12-49 r
Figure 1,5.2",1.5 ODBMS PARAMETER DIRECTORY

I uoN1 I

I UoN_ I

I - I

I I

I I

HISTORY-RECORD-LOCATION1 I CURRENT-RECORD-POINTER I

HISTORY-RECORD-LOCATION_, I CURRENT-RECORD-POINTER I

- I I

I I

I I

12-50
System Integration Test & Verification (SITV) Trade Study

1.0 Trade Study Definition

1.1 Purpose of Trade Study

To identify the preferred options for the Integration, Test and Verification

of the Space Station Data System (SSDS) elements, consistent with the SSP

mission and programmatic goals.

1.2 Background

1.2.1 General

The operational SSDS will consist of Ground and Space segments, each designed

to meet the Functional allocation of the SSDS requirements, and linked, at

least initially, via the TDRS system. The integration, test and verification

effort for these segments, both individually and in combination encompasses a

number of significant options to be addressed in this trade study activity.

R reference model for the over-all effort is provided in Figure I. The intent

of this figure is to identify the significant Integration and Test levels to

be addressed while also providing a top-to-bottom chronology. Rs shown in the

Figure, it is prerequisite that the Ground Segment be operational to fully

support pre-launch and on-orbit activities of the Space Elements. The (]round

segment will interface with existing/modified institutional facilities to

provide the data/command management (distibution, processing, archiving, etc),

mission control and scheduling, and configuration management Functions. It is

anticipated that the Ground segment will utilize primarily commercially

available equipment that can be emplaced and activated with few, if any,

difficulties. Target, or functionally representative hardware will be

available, based on well supported commercial product lines, to accommodate

software development requirements.

13,-1
Development

Acceptance,

& Qualifi_itlon

Level

$$D$ Level

Intagration

Leunoh

Puokuge

Integrltion

Station

Build.Up

m

E

H/W

_Auy

SPACE SEGMENT

Module -- - kule !

1

(CE I

I&T

Figure 1. SSDS Integration & Test Overview

HIW

GROUND SEGMENT

Module --- Module

!

t t

-ss°s i l- j Facilities GroundI&T Facilities

The space segment acquisition presents considerably higher technical risks

because of the need for orbital assembly and activation, the limited Station

accessibility, and the space environments. Preliminary concepts For the

On-board SSDS design have proposed a distributed, networking configuration; it

is anticipated that processing nodes (combinations of processors, network

interface units, and mass storage devices) will be embedded into the various

modules and structural elements of the Space Station. These nodes, supported

by man-machine-interfaces (workstations), and interconnected by an appropriate

network design with an interface to the Communication and Tracking sub-system,

must support the Full Functionality of the IOC Station yet must be compatible

with a coherent and eFFicient build-up phase.

The current build-up concept, as discussed in Task i, Section 4.4.3, proposes

at least seven launch packages (driven by NSTS cargo weight and volume

compatibility) to be boosted to orbit in a logical sequence For incremental

13-2
assembly into the IOC Station. As depicted in Figure 1, it is anticipated

that the On-board SSDS hardware will be integrated into its host launch

package and checked out prior to launch.

The acquisition phase environment for the SSDS will be one in which its H/W

and S/W products are procured/developed and delivered by multiple sources.

These deliveries may be chronologically staggered to match the build-up

sequence and to reduce peak funding requirements. The concept of staggered

deliveries may impact apparent goals to verify all Space Segment Flight

inter?aces prior to launch however in some cases this goal may prove to be

less than practical and in other cases may be unnecessary. Payload

inter?aces, for example, may ?all into the latter category on the basis that

such interface must be standard/common; during ground integration testing of

the on-board system, a generic payload simulation should be sufficient, from

an SSDS perspective, to establish the interface compatibility. R symmetrical

verification will suffice For the general payload.

The factor of multiple contractors adds considerable complexity to the system

integration effort, particularly when sub-systems may be distributed, not only

across different modules and structural elements but also across the

contractual work packages. Commitment to an effective program of

standardization and commonality will significantly reduce the number of unique

hardware configurations and interface protocols. Any resulting penalty in

operational efficiency will be more than offset by a cost payoff in the form

of reduced development, certification, test equipment and fixtures, and spares

requirements. The standards however must be sufficiently defined to preclude

inter?ace incompatibility between different contractor implementations.

Standardization on specific programming and user inter?ace languages will

provide a second level of efficiency through, a) minimization of software

support requirements, b) establishment of source and object code libraries,

and c) reduction of expertise requirements.

In summary, the Integration, Test, and Verification and implemented

procurement strategies will be interdependent; cost optimization must, in

?act, be a marriage of options from both.

13-3
1.2.2 Ground Segment Concepts

It is recognized that there are significant design/configuration issues

associated with the SSDS ground segment. For example, incorporation of

existing H/W and S/W capabilities with differing interfaces and protocols must

be accommodated. Integration and Test concepts must be considered within the

systems engineering tasks however the primary obstacle will be that of the

design. Problems will inevitably occur, however, the over-all acquisition

will be relatively routine since:

There are few procurement constraints; environment/qualification is

not an issue, and there are few, if any, critical weight, power or

volume limitations

• Equipment/facility accessibility is not a problem.

e The major SSDS elements will be dedicated and can be

integrated/activated with minimal operational interference with

existing facilities.

Since no significant Integration and Test issues for the Ground Segment have

been identified, this segment will not be specifically addressed further in

this trade study effort.

1.2.3 SSDS Space Segment

The typical space flight hardware has virtually no post launch accessibility

and must be in at least a near-operational configuration at launch since this

hardware typically has minimal automated or remote reconfigurability.

Conservative test programs are therefore dictated that provide comprehensive

demonstations of operational effectiveness and suitability, and include full

"all-systems" integration testing on the operational configuration. Following

comprehensive all system testing, the integrity of flight interfaces must be

maintained (or re-established) through pre-launch checkout and Flight.

The Space Station, in contrast, will be incrementally boosted to and assembled

on orbit. It will be accessible on at least a limited basis during build-up

13-4
(and man-tended phases) and will be fully accessible as a manned facility.

These differences imply that individual launch packages need not be

constrained to an operational configuration for launch. Also, the noted

accessibility implies a maintainability such that a large variety of equipment

problems identified during build-up and activation can be corrected on orbit.

It is therefore concluded that:

Hardware susceptible to the NSTS environments yet compatible with the

Station environments could be provided with special

handling/packaging for NSTS launch/re-entry operations, and,

Reduced _FFBF requirements may be tolerable, particularly with the

NASA imposed fail op/fail safe/restorable design requirements.

Strategies to reduce the rigorous environment/interface compatibility tests

and repetitive performance demonstrations are therefore viable to cost

optimize the Integration, Test and Verification against acceptable risk

profiles. It is this theme that is pursued in this trade activity.

1.2.4 Test Definitions

To clarify the discussions of the subsequent sections, test definitions for

the standard test sequence are provided in Appendix A of this study.

1.2.5 Acceptance and Qualification Test Concepts

The Task 2 System Test, Integration, and Verification options paper discussed

the following acceptance and qualification test deviations to the 'standard'

industry approach:

a) Deferment of selected sub-assembly functional and environmental

testing to the next (assembly) levels.

b) Deletion of selected (e.g. thermal vacuum) environmental tests during

module acceptance testing, and,

13-5
c) Modification of traditional certification (qualification) testing

profiles (levels and durations) to support protoflighting, thus

minimizing non-flight hardware costs.

These deviations are consistent with the above theme of reduced conservatism

and are thus the preferred approach almost by inspection; option (c), in fact,

is effectively a given. Since these deviations can only be discussed from a

relatively high level and on the basis of generic hardware, they are not

readily decomposed into sub options to be traded. Therefore, acceptance and

qualification testing will not be addressed further in this study activity.

1.2.6 Verification Concepts

As indicated by the Appendix A definition, the System Verification effort will

be distributed across all levels of the ground testing; in addition, since

some Space Station operational testing may not be practical or feasible in a

Ig environment, the verification program must be completed during the on-orbit

activation sequences.

The goals of the verification program are to not only insure design compliance

but to efficiently, and cost effectively, provide early and comprehensive

identification of discrepancies. Design compliance must address operational

suitability requirements, e.g. reliability, safety, and maintainability, etc.

in addition to the normal functional, performance, and compatibility

requirements. The typical verification program therefore overlays and expands

on the normal test sequence of the first production units. In general,

however, the verification activities adhere so closely to the structure and

policies of the underlying tests that separate issues with respect to depth

and degree of testing, facilities requirements, and costs can not be

differentiated. Options/trades for the verification effort have, there?ore,

not been generally addressed.

The single exception is the performance of an SSDS end-to-end (Space and

Ground) verification. Such a verification appears to be Favored to insure

full end-to-end compatibility prior to launch. The concept implies

interconnection/assembly of several launch packages to provide an operational

13-6
capability such that the Ground System can operation and monitor selected

'on-orbit' sub-systems and payloads through the TDRSS link. This option may

be unwieldy however with respect to the Space Segment because of the

assembly/tear down operations, the increased facility requirements, and the

potential impact on the TDRSS/Nascom resources. R piece-meal, more

independent approach may be more viable and still provide sufficient

confidence. This issue is discussed and the options traded in Section 3.0.

1.2.7 Integration/Test Concepts

The integration/test process assembles and links hardware and software

entities to form partial or complete systems with specified functional

capabilities which are then verified. This activity will generally be

accomplished through incremental addition of products until a required level

of functional capability is achieved and verified. The definition of these

products may vary widely depending on procurement packages/contracts and will

impact the development/integration methods. Generally, these products can be

characterized as:

a) S/W Packages - separately developed software packages that have been

tested in a 'stand-alone' mode using a target machine, emulator or

functional simulator,

b) Hardware Components - separately procured/developed hardware items

that have been previously acceptance tested and certified. It is

generally assumed that the integration of separately procured

computers and software packages is accomplished prior to integration

and not included in this definition. Examples are hardware items

such as time frequency generators, network media, and NIU's, or,

c) Integrated Hardware/Software - separately developed "subsystems" that

include software already integrated with internal hardware

components, i.e. computers, mass storage, etc. When multiple

computers are required for a 'subsystem' entity, it is assumed that

the same level computer integration testing is performed prior to

integration. However, full integration of subsystem computers may

13-7
become a SITV function depending on availability of network hardware

to the subsystem contractor.

One of the more technically challenging aspect of the On-Board SSDS design

described earlier will be the distributed operating system, (DOS). The DOS

will be developed in software modules corresponding to each of the processing

nodes and software interfaces will be verified using either target hardware or

emulators as indicated in Figure 1. An integration of hardware and software

will occur at the next (SSDS) level; however, there appear to be two basic

approaches. One option is to perform a Full sub-system test utilizing a 'test

bed' to interconnect all processing nodes. A second approach would be a

segmented approach, testing each processing node individually and simulating

the remainder of the subsystem. The key issue of these options is whether a

Full verification of the distributed operating system (DOS) is necessary at

this relatively low integration level.

At the next (launch package) level, the sub-systems and structural elements

including the SSDS will be assembled into their functional elements, primarily

associated with launch packages. Clearly, each individual package will

require a comprehensive Integration/Test effort, however, there is also some

consideration for a more inclusive pre-launch integration of the over-all

Station. The available options, analogous to those at the SSDS level, are:

1) A "segmented" approach wherein the integration is limited to the

hardware and software associated with each launch package; the

interfaces to the rest of the Space Station and ground would be

simulated, and,

2) An "all systems" integration of the full Station wherein all

subsystems and structure are assembled/interconnected to the

maximum practical extent to demonstrate the 'full' SSDS

capabilities.

Clearly, the Station environments for the 'all systems' approach will limit

structural deployment and some sub-system functionality, however there is

precedence and program benefit for such large 'all systems' exercises.

13-B
Growth, with respect to the SSDS will provide vertical and/or horizontal

expansion of capabilities, including added autonomy. Effective systems

engineering will define the appropriate interfaces for the over-all system

vertical/horizontal hierarchy such that hardware and software entities can be

added and replaced with minimal impact to the remaining 'structure'. The

on-orbit Integration/Test effort will be a sequence of hardware (BIT)

verification, interface compatibility checks, and functionality verification.

There must be some ground preparation, however, to minimize the risk of the

on-orbit activity. The options include:

a) utilization of relatively high fidelity simulation or production

spares if available, and,

b) remote integration to the existing operational configuration

utilizing the TDRSS links.

The above integration/test and verification concepts are refined and traded in

the following sections.

1.3 Issues

The issues to be addressed in this study activity are:

What ground integration effort should be performed on the isolated

(on-board) SSDS?

What ground integration effort should be performed on the launch

packages/Space Station (from the SSDS perspective) prior to launch?

• What pre-launch SSDS end-to-end verification is appropriate?

What pre-launch integration effort should be performed on "growth

phase" elements?

13-9
1.4 Trade Study Criteria

The full set of criteria parameters and definitions for the subsequent trade

analyses is tabulated below. The criteria listed is utilized for each of the

trade analyses and has been assigned a weighting as shown in the tabulation.

This weighting, as discussed in the Section 2.0 methodology, is an assessment

of the relative impact of the parameter to the project success.

• Cost (Weighting - 30%)

New Facilities - Cost of facilities if required to support the

option.

$ Manpower - The manpower requirements of the particular option

Duration - The. relative time period required to complete the

option

Test Equipment - the costs of test equipment including fixtures

and software required to support the option

• Schedule (Weighting - 25%)

• The impact of the option on the overall program schedule

• Risk (Weighting - 25%)

Technical - The relative technical difficulty/feasibility in

completing the option requirements

Program - The potential impact to program achievability based

performing or not performing the option.

13-10
• Suitability (Weighting: 20%)

Test Efficiency - The relative efficiency of the option, i.e.

the effort expended vs the probability of detecting problems.

Safety Considerations - The relative personnel and equipment

safety in the performance of the option testing.

2.0 Trade Study Methodology

For each of the trade areas, the following methodology has been applied.

i) Fully characterize the options: Each option will be characterized as

fully as possible to allow a fine grained assessment corresponding to each

parameter of the criteria.

2) Select an appropriate set of evaluation parameters: This set has been

provided in Section 1.4.

3) Provide weightinq factors for each evaluation parameter: A weighting

factor has been assigned to each parameter of the criteria set based on its

relative impact to the project success. Cost, for example, is a relatively

high impact parameter and will be assigned a higher percentage weight.

4) Provide a numerical assessment for each option: A numerical assignment

(O-lO) will be entered in each option column, corresponding to each parameter

of the criteria. This assignment provides a relative estimate of the

suitability or effectiveness of the option based strictly on that parameter.

A "lO" indicates an excellent assessment; a "0" indicates a total deficiency.

Note that inverse parameters, such as risk are inversely rated, i.e., higher

costs and risks generate lower ratings.

5) Score and rank the options: The parameter assignment times its

weighting provides the option score for that element of criteria. The

preferred option is identified by the largest criteria score sum.

13-11
6) Perform sensitivity analysis: An analysis will be performed to

identify the key decision drivers.

7) Re-evaluate individual trade activities: Each trade study will be

evaluated to determine whether the results are reasonable and expected, to

resolve and perceived inconsistencies, and to eliminate potential coupling of

dependent issues.

3.0 Trade Study Discussion and Results

3.1 Ground Integration Effort for the SSDS

3.i.i Discussion

As indicated earlier, the on-board SSDS will be a distributed, networking

design utilizing processing nodes to support the sub-system requirements and

the separable functions of the Data Management System. It is clear that the

Distributed Operating System (DOS) must itself be subjected to exhaustive

validation and verification, however, it is not as clear that the total

onboard SSDS must be tested as a complete entity. The issue is what testing

is required at the SSDS sub-system level to verify its readiness for

subsequent integration efforts. The options noted in Section l.O are, 1) a

segmented, individual processing node Integration and Test, and 2) a full

system integration.

For the segmented option, the integration/test would be essentially limited to

the hardware and software associated with each individual processing node.

The mechanical inter?aces for the hardware would be simulated using fixtures

that also supply electrical power and thermal control. The electrical and

logical interfaces to the remainder of the SSDS (including the DOS) and

sub-systems would be provided by simulation. This simulation could also be of

benefit to the Verification Program since inter?ace parametrics (voltage,

impedances, timing) could be varied to demonstrate processing node

compatibility margin. Appropriate diagnostic programs and stimulus would be

provided to each processing node to verify its built-in test, fault detection,

reconfigurability and performance. The response and output data from each

node would be analyzed to insure it functionality.

13-12
The benefits of this option are the reduced facility requirements, since much

of this simulation and fixtures would be common to each node. Also, this

approach could more easily support a staggered development/delivery schedule

that was 'launch package' oriented.

The obvious disadvantage to this approach is the higher program risk in

deferring the full integration to a higher level (possibly on-orbit) where

detected design deficiencies or incompatibilities will have a more severe

impact.

The second option performs a full integration/test of all On-Board SSDS

hardware and software. A test bed approach is anticipated to accommodate

requirements for power, thermal management, etc. The complete local area

network (LAN) connectivity would be provided and all configurations, modes and

automation/autonomy of the system could be demonstrated against diagnostic

data/command traffic scenarios. Associated sub-system, Payload,

sensor/effector interfaces would be simulated. The test requirements,

procedures, and facilities would all be more complex; however, this option

minimizes SSDS functionality risks at the next integration level.

3.1.2 Criteria Evaluation

The criteria parameters associated with these options are briefly discussed in

the following paragraphs.

• Cost

It appears that option 1 will generate the lower cost. Fixturing will be

required for the mechanical, electrical, and logical simulation of the

processing node interfaces however, fixture(s) may be common for many, if not

all, of the nodes. The simulation effort, i.e. subsystem and remaining $SDS

interfaces, should not be major and may in ?act be part of a coherent test aid

complement provided for the development contractors.

The manpower requirements cannot be differentiated; option 1 may require a

fewer people for an extended period while option 2 would require a shorter

13-13
period with but with perhaps a higher personnel count and more complex

documentation.

• Schedule

Option 1 would provide the more compatible schedule withthe staggered launch

package flight schedule. Also this approach provides an inherent flexibility

in that testing could shift to another processing node if the node under test

failed and required some time to disposition.

• Risk

The technical risk would perhaps be somewhat higher with option 2 due to the

larger set-up requirements but is not a key discriminant in the performance of

either option. The program risk is higher with option 1 since actual

(functional/logical) interfaces will not have been verified and the

distributed operating system will not have been fully demonstrated prior to

proceeding to the next integration level.

• Suitability

Option 2 is clearly more suitable since the actual system interfaces and

functionality is test with a minimum of simulation. Noted discrepancies will

therefore, in general, be real and not by products of the simulations. Safety

is not a concern for either option.

3.1.3 Results

As shown in Table 3.1 - I, the "full system" option is preferred. The

sensitivity analysis shows risk to be the key evaluation factor.

3.2 Ground Integration Effort For The Launch Modules

13-14
TRADESTUDYTITLEs SSDSPRE-LAUMCHINTESRATIONEFFORT

,k

: CgST : 39 : O : 240 : 6 : 189

: SCHEDULE : 25 : 8 : 299 ] 6 : 159 :

: RISK : 25 : 3 : 75 : 9 : 225 :

: SUITABILITY : 29 : 7 : 140 : 7 : .140 i

: TOTALSs : 109 i : 655 : : 695 t

TABLE3.1 - I

3.2.1 Discussion

Rs discussed earlier, the Space Station design must accommodate separable

launch packages ?or incremental boost to orbit and assembly. It is

anticipated, however, that each package will be fully integrated on the ground

as indicated in Figure 1, i.e. corresponding SSDS segments will be

installed/tested and will remain part of that launch package. The actual

launch configuration of these packages will, however, be a compromise based on

Orbiter Cargo Bay volume and weight constraints, the goal to minimize EVA

time during build-up, and special handling requirements for any launch

environment susceptible hardware.

It is anticipated that this launch package level integration will occur at a

KSC facility to minimize subsequent handling prior to launch and because of

potential use of existing facilities.

13-15
Like the SSDS level integration activity, there are two primary options on the

Space Station plane. The first is the segmented approach, where in the

integration is limited to individual launch packages. The second option is

that of a full 'all-systems' ground integrati0n/test effort.

For the first option, all hardware and software, electrical power, thermal

management, ECLSS, communications, etc. associated with the launch package

will be implaced and activated with fixturing and simulation provided to

duplicate the interfaces of the remaining launch packages. This approach has

some significant advantages in that:

• Facilities and manpower requirements are minimized, and,

It accommodates a schedule of staggered development/deliveries that

will in all likelyhood, more closely match NASA fiscal funding plans.

The primary disadvantage of this option is that the actual interfaces and

global functionality verification is deferred to the On-Orbit integration

activity where discrepancies can result in serious program pertubations.

For the second option, all launch packages will be assembled/interconnected

using special Fixtures, extension cabling, etc. Although some structural

deployment and sub-system functionality could not be fully demonstrated in a

Ig, ambient pressure, ambient temperature environment, considerable confidence

can be gained in exercising the sub-systems/launch packages together. This

option would not only support full checkout of operating modes but would also

support crew training and preliminary development of crew schedules and

mission timelines.

The disadvantages of this second approach are the requirements for additional

handling, massive facilities, more complex test documentation, greater

manpower and inherent inefficiencies.

13-16
3.2.2 Criteria Evaluation

The criteria associated with each of the options is briefly discussed in the

following paragraphs.

• Cost

Option 1 would require the lower costs because of the lesser facility

requirements, and more manageable manpower requirements.

• Schedule

Option I is considerably more compatible with the over-all program and allows

a staggered integration effort that aligns with the build-up sequence. This

approach would allow staggered development and/or delivery of launch package

products that would be more compatible with NASA fiscal funding plans.

• Risk

• Option I represents a higher program risk because of the

delayed/deferred assembly and test of the actual interfaces and the potential

of discovering deficiencies and/or incompatibilities on orbit. Option 2

presents a higher technical risk in attempting to assemble and test all launch

packages.

• Suitability

Option 2 is less efficient since inevitable problems with any elements (launch

packages) will result in test downtime. In the segmented approach, there is

the potential of reconfiguring to another launch package (being prepared in

parallel) for testing. The necessary structural complexities and facility

support requirements will generate somewhat greater hazards for the flight

hardware and test crew.

13-17
3.2.3 Results

Rs shown in Table 3.2-1, the segmented approach is preferred. Sensitivity

analysis show cost and schedule to be the key discriminants.

3.3 Pre-Launch End-To-End SSDS Verification Effort

3.3.1 Discussion

The Space Station Data System represents considerable complexity, not only in

the On-Board functionality but also in the data and command transport between

the payload/experiment on-orbit and the customer on the ground. The

data/command flow paths include the On-Board LRN, the ground WAN and the

intervening TDRSS/Ground Station link. The end-to-end transport must support

packetized data formats (encrypted as required), error protection techniques,

TRAOESTUOYTITLE: LAUNCHPACKA6EPRE-LAUNCNINTEBRATIONEFFORT

I : OPTIONJ: I OPTION2: )

[ CRITERIA : WEI6HT : EVALUATION : TOTAL : EVALUATION : TOTAL :

30 9 :

25. B :

25 5 :

20 8 :

i

I

COST

SCHEDULE I

RISK

)

SUITABILITY

270 : 5 : 150 :

200 : 5 : 125 :

125 : ? : 225 :

lbO : _ : 120 :

==========================================================================================

TOTALS: : 100 : : 755 : : 620 :

TABLE,3.2 - 1

13-18
flow control techniques, and distribution based on packet header addressing.

Verification of the data transport has two primary options: l) a piece-meal

approach that verifies sections of the transport path independently and 2) an

integrated end-to-end approach.

Option I relies heavily, of course, on simulation and minimizes impact on the

institutional facilities. The On-Board verification will utilize simulation

to provide the desired diagnostic data to the inputs of the element (launch

package) under test to simulate sub-system, payload and DMS data/commands; the

returned (forwarded) data/commands will be analyzed to insure the proper

handling.

The On-Board Communication & Tracking (C&T) Subsystem/TDRS interface is

critical. This interface will require comprehensive checkout to insure S-Band

and K-Band compatibility and at some point, bit error rate (BER) tests will be

required. The TDRSS has compatibility test capabilities available via

permanent and mobile van systems that can utilize TDRSS ground simulation

support and also provide direct links to the TDRS. Some of this checkout may

be performed to the C & T sub-system level and/or at the prelaunch Space

Station level.

The SSDS Ground segment can demonstrate its processing, storage, and

distribution capabilities through insertion of diagnostic data into the head

end of the system (Ground Station) either directly or via a 'loop back'

capability to TDRS, and monitoring the subsequent data processing and

distribution activity.

The intent of option 2 is to perform an end-to-end verification of the

combined paths in as close to operational configuration as possible. For this

approach a TDRS SA antenna would be slewed down to the C&T antennas to provide

what would normally be the 'space-space' link, as depicted in Figure 2. The

TDRSS/Ground SSDS segments would assume normal operational configurations.

It is recognized, however, that there may be severe limitations in assembling

the total Station as discussed in Section 3.2.1. In the minimum case, the

'Station' may consist of only the Comm & Tracking sub-system and its

13-19
Space

Gnd

Space C&T

Segment

TDRS I

._ COMSAT I

iTDRS HN_ahn_de s i iGnd HGround |

Station Segment|

Figure 2. Prelaunch Gnd-to-Gnd Verification

associated launch package(s) with some interfacing DMS elements. The

remainder of the Station, (as required), platforms and payloads, would, most

likely, be simulated. Another difficulty is that the operational C&T antennas

and their supporting trusses may not be deployable in the Ig environment.

Thus, non-flight antennas may be required to link to the TDRS. In summary,

although there is some added confidence to be gained, ground verification of

the end-to-end system has some dis-advantages in that:

the full end-to-end capability is not practical; much of the On-Board

SSDS would be simulated.

Comm & Tracking Sub-system antennas/mounts are anticipated to be a

non-flight configuration.

this option may impact TDRSS if allocated Space Station resources are

not in place, i.e. additional TDRS's, and Ground Station.

13-20
3.3.2 Criteria Evaluation

The criteria associated with these options are discussed in the following

paragraphs.

• Cost

Option 1 testing will, in all likelihood, be performed in any case which

categorizes all of the Option 2 costs as additional.

• Schedule

Option 1 provides more schedule flexibility since the ground and space paths

could be verified independently.

• Risk

Technical risk is not a discriminant for either option. There is a decrease

in program risk with the performance of Option 2.

• Suitability

Option 2 is considered to be less efficient based on the magnitude of the

effort and coordination required to perform the test. Safety is not

considered an issue.

3.3.3 Result

As shown in Table 3.3-1, the segmented approach is preferred. Sensitivity

analysis shows cost and schedule to be the key discriminants.

3.4 Pre-Launch Integration Effort For Growth Phase Elements

13-21
TRADESTUDYTITLE:SSDSPRE-LAUNCH END-TO-END VERIFICATION EFFORT

COST _ _0 : ? : 270 : 8 : 180 :

: SCHEDULE : 25 I 9 I 22_ ; 6 I 150 [

: RISK l 25 I 5 : 125 i 9 I 225 :

: SUITABILITY l 20 : 7 : 140 : 7 I 140 :

TAgLE3._ - 1

3.4.1 Discussion

Growth phases are planned for the Space Station/SSDS in support of larger

complements of payloads/experiments. This growth ui11 result in additional

structure, HRB/LRB modules and over-all data/command handling capability.

Physical integration of the additional hardware and software with the existing

Station must necessarily be performed on-orbit, however, there are options for

ground activity in preparation for this integration. Program policies cannot

be predicted, however, a high fidelity simulator/mock-up, provided on previous

programs, is not anticipated. This assumption removes the possibility of a

comprehensive ground integration. Instead, simulators and fixtures utilized

in the IOC acquisition phase wilI be available/modifiable for use. There are,

however, options for verifying the functional/logical interfaces of the growth

elements.

13-22
The first option employs the approaches and lessons learned from the IOC

acquisition experience through the use of simulators to verify the

functional/logical interfaces of the new elements independent of the existing

operational Station. The second option is to utilize the TDRS link to more

directly verify the interfaces to the Station.

Option 1 needs little discussion since it has been addressed at length earlier

in this paper.

Option 2 provides an (indirect) interface with its associated Station

elements. From a logical perspective, this approach provides an advantage in

that simulation errors are not involved, however, the link delays may result

in severe disadvantages. As noted earlier, the integration effort is presumed

to occur at KSC, therefore the multi-path link from KSC to the Space Station

and return, could involve delays of several seconds which may impact the test

feasibility. This option has the additional dis-advantages that Station

configuration/scheduling pertubations would be necessary thus potentially

impacting planned operations, and the additional TDRSS traffic could be an

impact to the Station and other projects relying on the TDRSS resources.

3.4.2 Criteria Evaluation

The trade study parameters associated with these options is discussed in the

following paragraphs.

• Cost

The activities of option I would be performed to a large extent whether in

preparation for option 2, thus the option 2 costs (man-power, TDRSS, NAN) must

be considered additional.

• Schedule

Option 2 would be dependent on the Station and TDRSS scheduling where-as

option l could be performed independent of any ongoing operations.

13-23
• Risk

There is some risk to the option 2 approach in that identified discrepancies

could impact the Station. Option 2, if successful however provides a lower

over-all risk to the success of the integration.

• Suitability

Suitability is not a discriminant for either option.

3.4.3 Results

Rs shown in Table 3.4-1, the independent integration approach is preferred on

all criteria.

TRAOESTUDYTITLE: 6ROBTHELEIIENTSPRELAUNCHINTEGRATIONEFFORT

I 8 OPTIONIs f OPTION2s I

I CRITERIA I HEIGHT I EVALUATION ] TOTAL I EVALUATION I TOTAL

I_I_RI_I`I_8_Is_zZz_Ii_zs_I_mm_n8_miIII_IIIIgII_8_1_I_

; COST I 30 I 9 : 270 : 7 : 210 I

I I I I I I I

: SCHEDULE : 25 : ? : 225 I 7 ; 175 I

: I : i [ I I

I RISK I • 25 I 8 I 200 I 7 I 175 I

I i : : I I :

I SUITABILITY I 20 : 7 : 140 : 4 I BO I

I I I I I I I

_IIII_III_I_|__|_|I_|_III|_I_|I_|_z|_I_I|_III_I|_|I_I|I_`_|_|_

I I I I I I I

I TOT_Ss I IO0 I I 835 I I 640 I

TADLE3.4 - I

13-24
Appendix A - Testing Sequence Definitions

DEVELOPMENT - Engineering evaluation tests of various integration levels of

H/W and S/W products. The effort is intended to assist design engineering in

evaluating/validating proposed design solutions. This testing is not

generally subject to the rigors and documentation formality associated with

production flow testing unless, (consistent with the protoflighting concepts),

potential mission operational hardware is utilized. Specific NASA Test Beds

will be available to support development tests.

CERTIFICATION - Effectively synonomous with @ualification testing, this

effort includes those tests and analyses required to demonstrate that design,

materials and components, and manufacturing processes will perform in the

mission operational environment. Testing generally consists of functional

tests in conjuction with environmental exposures to profiles more severe than

those projected for the mission. Analyses may substitute for tests to reduce

costs and support protoflighting when product and environments can be

adequately modeled.

ACCEPTANCE - Testing performed generally at vendor facility to assure that the

equipment meets delivery requirements and to demonstrate a readiness for the

next integration level. Includes functional performance and environmental

exposures to demonstrate immediate capabilities of specific hardware and to

screen out faulty components and workmanship not detectable through inspection

techniques.

SOFTWARE VALIDATION/VERIFICATION - This effort, performed by the vendor or by

an independent agency, is a review of the software design requirements and an

exercising of the generated solution, within specified bounds, to demonstrate

conformance to those requirements.

INTEGRATION - The process of combining H/S and S/W elements into specified

configurations, verifying physical and logical compatibilities, verifying

functionality and performance, and insuring that the configuration is ready

?or the next integration level. This effort is performed at specified (not

necessarily the launch) site(s). This integration may utilize physical

13-25
mock-ups, interface simulation, and access to processors for automation and

maintainability verification.

VERIFICATION - The test/analysis program that proves system conformance to

design, performance and suitability, e.g. safety, maintainability, reliability

and environmental compatibility requirements. This effort is necessarily a

distibuted operation that relies heavily on development, acceptance,

certification, flight demonstration, preflight checkout testing augmented by

analysis. This effort is normally a one time requirement and may expand the

scope of normal test sequences for an early production article.

LAUNCH READINESS - The effort of verifying/servicing launch packages in

preparation for boost to orbit and subsequent operations. This effort may be

a multi-phase operation to:

verify no shipping damage on delivery to launch site

perform a limited checkout while in the orbiter bay.

13o26
XIV. CREW WORKSTATION

14-1
2.0 CREW WORKSTATION TRADE STUDY

The following trade studies analyze display type, color displays vs. monochrome, input controls, and caution and warning techniques for use in the

NASA Space Station Crew Workstation. Figure 2.D depicts the logic flow

followed for each trade study. Initially, all NASA RFP requirements, NASA

reference configurations, NASA standards, and independent technical studies

are consolidated and analyzed to determine a viable set of options. The

majority of this work was completed under Task Two, the options phase.

Using the NASA crew station RFP input requirements and program goals as listed

in Table 2.0, a set of selection criteria is determined for each trade

study. This selection criteria is the basis for which technology will be

chosen. For each selection criteria a weighting factor is assigned that

determines its relative importance to the Space Station program. Each

option is also assigned a relative weighting factor with respect to the

other options for a specific selection criteria. This relative weighting factor (0 - 10.O) defines, in a qualitative manner, the relative goodness of an option with respect to the other options for a specific

selection criteria. The relative weighting is multiplied by the weighting

factor and summed across all selection criteria for each option. The

result is a figure of merit and indicates the most desirable, through the

least desirable option, with respect to the Space Station program. In order

to perpetuate an "intuitive feel" for this figure of merit it is divided by

a perfect figure of merit, i.e., all relative weighting factors equal i0.0.

The figure of merit is still a comparison of the options and also can be

thought of as a percentage of the optimal technology.

14-3
c_

,_J

i,

c',.l C_

.,.I

L_

b_ LD

L_

C_

n..,,

Z(J']

o-i r,_

I,--_

-r" _...

r..._ tj

L.JL_

n,-

C_

r_

|

1'

w

Z

n,-

C_

n.,

bJ

0,.

Z

_-_ Z

Z'-_Z _" __t

U.l _:

?

I.-

;-,=i

..=I

Z

Z

I-=I

n,**

I" T T

_:: Z _-_

o-_ O:: _- _:: ..I

_--_J _- Z _:: v

,\

Z

Z_-_

_==0r_)

_*--l._.J

_.,__

C_l._

(._

>-

o. ,,=,,

cow

,m

r__

C_

--_C:D

_Z

_--

/\

Z

Z

?

),=

I=-

I=,=1

n_

z

I,-,I

,¢

In

Z

I=,=1

.-J

Z

u._

n,,*

I=-

n,*

w

i

-.I

Z

w

n,*

la=

n,*.

>=

.=J

,==1

w

T

i==

...=1

,=.I

I=_

>,-

l=-

Jl._l

T

>..

w

.=1

ZZ

I

Z

L_

n.- n_.

Z

uJ _:

la,J n.*

/\

d&

IF

U_

>-

._1

._1

C_

U')

Z

C=D

__)

Z

'_ L_ ,_:

Z

14-4

>..

.-J

C3

Z

.-_

I.=-

03

Z

_D

Z

_0

I---

Z

Z

U.I r-,

0,= '--_

I._

CO

Z
TABLE 2.0

CREW WORKSTATION DISPLAY & CONTROLS RFP REQUIREMENTS

MPAC RFP REQUIREMENTS

C5 2.2.5.1c DHS General Rqmts, Opnl Intfcs

The operational interface to the DMS shall be through the

Multipurpose Application Consoles (MPAC) and the distributed

computer processing system.

C5 2.2.5.3.c DMS Dsgn and Perf Rqmts

The fixed and portable MPAC shall be a common design functioning as a man/machine interface to the network operating

system. The MPAC shall provide command and control r monitoring, operations and traininq capabilities. Furthermore, the

MPAC shall provide:

i. Visibility into all subsystems.

2. Simultaneous viewing of displays.

3. Crew override for subsystem operations.

4. Annunciation for catastrophic failures, consistent

with established caution and warning philosophy.

The MPAC shall consist of the necessary displays r monitors,

interactive controls and recording devices. The portable

MPAC shall support both EVA and IVA operations.

14-5
TABLE 2.0

CREW WORKSTATION RFP REQUIREMENTS (continued)

C5 2.2.5.).c DMS Dsgn and Perf Rqmts

The fixed and portable MPAC shall be a common design functioning as a man/machine interface to the network operating

system. The portable MPAC shall support both EVA and IVA

operations.

C5 2.2.1!.1.d EVA Functional Rqmts

Portable workstations shall be designed for use with unpreparedwork sites.

C) ).2.d Sys Osgn Featrs, Common, Rel and Maint

A flight data file for crew use during IVA and EVA operation

through portable work stations shall be provided. This

system shall be complemented by IVA hardcopy devices as

appropriate.

14.6
TABLE 2.0

CREW WORKSTATION RFP REQUIREMENTS (continued)

C5 2.2.10.ia Hab/Man Sys, Sys Integ, Standardization

Crew interfaces and associated equipment shail be standardized

throughout the Space Station. Crew stations with muitiple

use._._sshaiibe used. Markings and labeis shali utilize

internationai standards/symbois throughout aii modules.

C5 2.2.10.Ie Hab/Man Sys Sys Integ Dsps & Cntls

Multifunction dispiays and controls shall be used. The

foIIowing shaIi be designed to faciiitate human productivity:

character size, dispiay brightness and contrast, auditory

characteristics; controI size, direction of motion, and types

of controis; dispiay format characteristics such as use of

coior t coior controis T inciudin9 tactiie_ visual, and auditory

feedback requirements. Emergency operation of controIs shall

have a shape, texture, and iocation that is readiiy identifiabie in the dark. The use of manuaIIy operated switches

shaii be minimized. ControIs shali be protected against

inadvertent operation.

14-7
TABLE 2.0

CREW WORKSTATION RFP REQUIREMENTS (continued)

C5 2.2.10.2a Hab/Man Sys, Crew Statns, Work Statns

A crew station shall be defined as any location in the Space

Station where a dedicated task or activity is performed. A

work station is a crew station which is exclusive of

recreation, personal hygiene, food preparation, dining,

housekeeping, and other off-duty activities. Accepted human

factors engineering practices and criteria shall be used to

design the human interface with the individual work stations.

A thorough analysis of the requirements shall be done for

each work station to determine the task, operator activities,

level of automation, tools, equipment, etc. necessary to

meet the requirements. Each work station shall meet the

baseline safety requirements for the Space Station and will

provide utility power. Work stations equipped to perform

identical tasks (e.g., station housekeeping functions) shall

utilize prime/backup logic with appropriate safeguards

aqainst dual functional path commandinq, these work stations

shall also satisfy the fail-safe criteria.

14-8
TABLE 2.0

CREW WORK STATIONS PEP REQUIREMENTS (continued)

C5 2.2.10.2.b Crew stations/Window Work Stations

All work stations associated with windows for operation and

scientific research shall have provisions for the following

items where dictated by the requirements analysis: display

and keyboard.

C3 3.1.3 Command, Control and Comm Support

The information and data management services shall provide

presentation services adequate to accommodate customer requirements. Access to the services shall be provided through

standard network interface nodes and attached work stations.
TABLE 2.0

CREW WORK STATIONS RFP REQUIREMENTS (continued)

4.4.4.2.1.2 Multipurpose Applications Console (MPAC)

Fixed MPACs shall be used for routine operations. Portable

MPACs shall handle operations away from the fixed units such

as maintenance or operations where direct outside viewing

through a window is desired. Both MPAC types will have

multifunctional display screens and programmable controls.

Resident in the fixed MPAC will be the capability to print

data and graphics from the display screen. The crew will

have the capability to plot timed events data which will be

selected from the MPAC. The operator will be able to choose

between raw and processed data. In addition, a method for

recording video images will be provided.

The design of the MPAC must take into account the zero-g

environmental effects and astronaut positions. Granted that

a local vertical is desired, a one-g rigidity in the design

may not be desired. For example, the display screen may be

positioned to any astronaut orientation.

14-10
TABLE2.0

CREWWORKSTATIONSRFPREQUIREMENTS(continued)

• 4.4.3.4 Video System

The configuration, safety, and functional requirements of

the Station call for control stations in each habitable

module so that different crewmembers can perform their

required tasks with minimal or no interruption to or from

others. The system will be simple to operate since there

will be a large number of users specialized in many different

fields and special training for Space Station equipment is

kept to a minimum.

These requirements drive the design of the television system

to a distributed control system where camera controls, video

switching, and other system functions will be controlled from

any workstation or monitoring location. This distributed

control station concept will allow continuous operation even

if parts of the Station become uninhabitable. These workstations will incorporate user-friendly input devices such

as touch screen sensors, joysticks, and voice control inputs

used in conjunction with color graphics generated menus and

displays. The capability to move TV monitors from one

location to another will be incorporated.

1_11
2.0.1 DISPLAYS SELECTION

2.0.1.1 Displa_ -Media Selection Criter ia

The following lists each selection criteria that will be used in the displays media selection trade study. The selection criteria are divided

into eight generic categories; programmatic considerations, performance parameters, risk assessment, maintainability, user-friendly,

reliability, safety and operations support. These selection criteria

are based on requirements and program goals set forth in the NASA RFP.

Trade unique criteria were determined by independent technology research and defined in the Task Two Options Development Phase.

Programmatic Considerations

A. IOC Cost

B. Life Cycle Cost

C. Schedule Impact

Performance Parameters

A. Power

B. Volume

C. Contrast Ratio

D. Resolution

E. Driving Voltage

F. Ruggedization

G. Uniformity

H. Temperature Range

I. Color Capability

14-12
Risk Assessment

A. Technology State-of-the-Art

B. Producibility/AvailabilIty

Maintainability

A. Repairability

B. Replaceability

User-Friendly

A. Readability

B. Response Time

Reliability

A. Failure Rates

Sa rely

A.

B.

Failure Modes

Radiation Tolerance

Operations Support

A. Testability

Commonality

A. Application

1_13
2.0.1.2 DispJla_ Media Selection We iqhtinq Factors

The following lists each weighting factor associated with each selection criteria used in the display media selection trade study. These

weighting factors were determined by a panel of Sperry space station system personnel in conjunction with NASA RFP requirements emphasis.

Programmatic Weighting Factors

A. IOC Cost Weighting Factor = (0.8)

B. Life Cycle Cost Weighting Factor = (0.8)

C. Schedule Impact Weighting Factor = (0.3)

Performance Weighting Factors

A. Power Weighting Factor = (0.5)

8. Volume Weighting Factor = (0.5)

C. Contrast Ratio Weighting Factor = (0.4)

D. Resolution Weighting Factor = (0.1)

E. Driving Voltage Weighting Factor = (0.5)

F. Ruggedization Weighting Factor = (0.7)

G. Uniformity Weighting Factor = (0.1)

H. Temperature Range Weighting Factor = (0.7)

I. Color Capability Weighting Factor = (0._)

Risk Weighting Factors

A. Technology State-of-the-Art Weighting Factor = (0.3)

B. Producibility/Availability Weighting Factor = (0.3)

Maintainability Weighting Factors

A. Repairability Weighting Factor = (0.5)

B. Replaceability Weighting Factor = (0.5)

1_14 -
User-Friendiy Weighting Factors

A. Readability Weighting Factor = (0.4)

B. Response Time Weighting Factor = (0.4)

Reliability Weighting Factors

A. Failure Rates Weighting Factor = (0.5)

Safety Weighting Factors

A. Failure Modes Weighting Factor = (i.0)

Operations Support

A. Testability Weighting Factor = (0.5)

Commonality Weighting Factor

A. Application Weighting Factor = (0.4)

14-15
2.0.1.2 Display Media Trade Study

This trade study evaluates the use and desireability of the following

display media for use in the Space Station Crew Workstations.

A. Cathode Ray Tube (CRT) Display

B. Plasma Flat Panel Display

C. Light Emitting Diode (LED) Flat Panel Display

D. Liquid Crystal Flat Panel Display (LCD)

E. Electroluminescent (EL) Flat Panel Display

Table 2.0.I.2 is the trade study results. Each display type and its

associated selection criteria is given a qualitative rating within the

display type set. Due to the rapid advancement in display technology

and numerous displays which use each technology an overall assessment

of excellent, good, fair and poor for each selection criteria is used.

From the trade study results, the order of display media preference

is:

i. Liquid Crystal Flat Panel Display

2. Cathode Ray Tube

3. Electroluminescent Fiat Panel Display

4. Plasma Flat Panel Display

5. Light Emitting Diode Flat Panel Display

Table 2.0.1.2 is the acutal trade study results. The following lists

the order of preference, and the total dot product of the weighting

factors and trade parameters, for the display media options.

14-16
i. Liquid Crystal Flat Panel Display - 81.8

2. Cathode Ray Tube - 78.4

3. Electroluminescent Flat Panel Display - 76.2

4. Plasma Flat Panel Display - 76.5

5. Light Emitting Diode Flat Panel Display - 65.4

A "figure of merit' is also calculated indicating the percentage of

satisfying all selection criteria. These are as follows:

i. Liquid Crystal Flat Panel Display - 68.74

2. Cathode Ray Tube - 65.88

3. Electroluminescent Flat Panel Display - 64.03

4. Plasma Flat Panel Display - 64.29

5. Light Emitting Diode Flat Panel Display - 54.96

In general, the flat panel displays have an advantage over the CRT in

the resource utilization department such as weight, volume, power and

etc. The significant reason that the liquid crystal flat panel display

is rated number one is that it also has color capability as does the

CRT which is a close second. In reality either the CRT or liquid

crystal flat panel display could be used on the NASA space station.

The remaining flat panel technologies in all probability will not be

suitable for the sophistication required for a space station display.

Refer to the bar graph in Figure 2.0.1.2 for ease in viewing the trade

study parameters in Table 2.0.1.2.

14.,17
Options

CRT

PLASMA

FLAT

3ANEL

LIGHT

EMITTING

DIODE

LIQUID

CRYSTAL

ELECTROLUMINESCENT

Weight ir,g

fact or

IOC COST

Good

R.W. =6. •

R. W.*W. F. =

4.8

Good

R. W. =6.0

R. W.*W. F.=

4.8

Poor

R. W. =0.0

R. W.*W. F. =

0.0

Good

R.W. =6.0

R. W.*W. F. =

4.8

Good

R.W. =6.0

R. W.*W. F. =

4.8

0.8

ORIGINAL PAGE IS

POOR QUALITY

PROGRAMMATIC

LIFE CYCLE

COST

Good

R.W.=6.0

R.W.*W.F.=

4.8

Good

R. W. =6.0

R. W.*W. F.=

4.8

Poor

R. W. =0.0

R.W.*W. F. =

0.0

Good

R. W. =6.0

R.W.*W. F. =

4.8

Good

R.W. =6.0

R.W.*W. F. =

4.8

0.8

SCHEDULE

IMPACT

Excel lent

R.W.=IO. 0

R. W.*W. F. =

3.0

Good

R. W.=6.0

R. W. *W. F. =

1.8

Poor

R. W. =0.0

R. W.*W. F. =

0.0

Good

R.W.=6.0

R.W.*W.F. =

1.8

Good

R.W.=6.0

R.W.*W.F.=

1.8

POWER

Fair

R. W. =_.0

R. W.*W. F. =

1.8

Good

R. W.=6.0

R. W.*W. F. =

3.6

_oor

R. W. =0.0

R. W.*W. F. =

0.0

Excel lent

R.W. =10.0

R. W.*W. F. =

3.0

Good

R. W. =6.0

R. W.*W. F. =

1.8

0.6

PERFORMANCE

VOLUME

Poor

R.W.=0.0

R.W.*W.F.=

0.0

Good

R. W. =6.0

R. W.*W. F. =

3.6

Good

R. W. =6.0

R. W.*W. F. =

3.6

Excel lent

R.W. =10.0

R. W.*W. F. =

6.0

Good

R. W. =6.0

R. W.*W. F. =

3.6

0.6

CONTRAST

RATIO

Excel lent

R.W. =10. •

R. W.*W. F. =

4.0

Good

R. W. =6.0

R. W.*W. F. =

3.6

Good

R. W.=6.0

R. W.*W. F. =

2.4

Exce I Ient

R. W. =10.0

R. W. *W. F. =

4.0

Good

R.W. =6.0

R. W.*W. F. =

2.4

0.6

RESOLUTION

Excel lent

R. W. =10. 0

R. W.*W. F. =

1.0

Good

R.W. =6.0

R. W.*W. F. =

0.6

Good

R.W. =6.0

R. W.*W. F. =

0.6

iExcel lent

R. W. =10.0

R. W.*W. F. =

1.0

Go,-,d

R.W. =6. 0

R. W.*W. F. =

0.6

0.1

DRIVING

VOLTAGE

Poor

R.W.=0.0

R.W.*W.F.=

0.0

Fair

R._.=3.0

R.W.*W.F.=

1.8

Excellent

R.W.=10.0

R.W.*W.F.=

6.0

Excel lent

R. W. =10..0

R. W.*W. F. =

1.0

Fair

R.W.=3.0

R.W.*W.F.=

1.8

0.6

RUGGEDIZATION

Good

R. W. =6.0

R. W.*W. F. =

4.2

Good

R.W. =6.0

R. W.*W. F. =

4.2

Excel lent

R. W. =10.0

R. W.*W. F. =

7.0

Good

R.W. =6.0

R. W.*W. F. =

4.2

Good

R.W. =6.0

R. W.*W. F.=

4.2

0.7

ORIGINAL PAGE IS

OF POOR QUALITY

UNIFORMITY

Excel lent

R.W. =10.0

R. W.*W. F. =

1.0

Fair

R. W. =3. •

R. W.*W. F. =

0.3

Good

R. W. =6.0

R. W.*W. F.=

0.6

Exce I I ent

R, W. =10.0

R. W.*W. F.=

1.0

Exce i Ient

R.W. =10.0

R. W.*W. F. =

1.0

0.1

TEMPERATURE RANGE

Good

R. W. =6.0

R. W.*W. F. =

4.2

Good

R. W. =6.0

R. W.*W. F. =

4.2

E xce i Ient

R. W. =10. •

R.W. *W. F.=

7.0

Good

R. W. =6.0

R. W.*W. F. =

4.2

Excellent

R.W.=IO.0

R.W.*W.F.=

7.0

0.7

COLOR

CAPABILITY

Excel ler,t

R.W. =10.0

R. W. *W. F. =

4.0

Good

R. W. =6.0

R. W.*W. F. =

2.4

Poor

R. W. =0. •

R. W.*W. F. =

0.0

Excel lent

R. W. =10.0

R. W.*W. F. =

4.0

Good

R.W. =6.0

R. W.*W. F. =

2.4

0.4

FOLDOUI" FRAME

.-. ._

, Table _.0. i.

Display Trade Study

14-18
Opt ior,s

[_RT

PLASMA

FLAT

PANEL

LIGHT

EMITTING

DIODE

LIQUID

CRYSTAL

ELECTROLUMINESCENT

Wei ght ing

fact ,=,r

ORIGINAL PA_E IS

OF POOR QUALITY

ORIGINN.

OF POOR

PA_E |S

QUALFI'Y

RISK

TECHNOLOGY

SOA

Excel ler,t

R.W. =10.0

R. W.*W. F. =

6.0

Good

R. W.=6.0

R. W.*W. F. =

3.6

Fair

R. W. =3.0

R. W.*W. F. =

1.8

Good

R. W. =6.0

R. W.*W. F. =

3.6

Good

R.W. =6.0

R. W.*W. F. =

3.6

0.6

PRODUCIBILITY/AVAILABILITY

!Excellent

R.W.=10.0

R.W.*W.F.=

6.0

Good

R. W. =6.0

R. W.*W. F.=

6.0

Good

R. W.=6.0

R. W.*W. F. =

3.6

Good

R. W. =6.0

R. W. *W. F. =

3.6

Good

R.W. =6.0

R. W.*W. F. =

3.6

0.6

MAINTAINABILITY

REPAIRABILITY

Fair

R. W. =3.0

R. W.*W. F. =

1.5

POOr"

R. W. =0.0

R. W.*W. F. =

0.0

Poor

R. W. =0.0

R. W.*W. F.=

0.0

Poor

R. W. =0.0

R. W.*W. F.=

0.0

Poor

R. W. =0.0

R. W.*W. F. =

0.0

0.5

REPLACEABILITY

Good

R.W.=6.0

R.W.*W.F.=

3.0

Excel lent

R.W.=IO. 0

R. W.*W. F.=

5.0

Exce I ient

R.W. =10.0

R. W.*W. F. =

5.0

Excellent

R.W.=IO. 0

R.W.*W.F.=

5.0

Excellent

R.W.=IO. 0

R.W.*W.F.=

5.0

0.5

USER

READABILITY

Good

R. W. =6.0

R. W.*W. F.=

2.4

Good

R.W.=6.0

R.W.*W.F.=

2.4

Good

R. W. =6.0

R. W.*W. F.=

2.4

Excel Ient

R. W. =10.0

R. W.*W. F. =

4.0

Good

R.W.=6.0

R.W.*W.F.=

2.4

0.4

FRIENDLY

RESPONSE

TIME

Excel ler, t

R.W. =10.0

R. W.*W. F. =

4.0

Go,z,d

R. W. =6.0

R. W.*W. F. =

2.4

Excel lent

R.W.=10.0

R. W.*W. F. =

4.0

Good

R.W.=6.0

R.W.*W.F.=

2.4

Excel lent

R. W. =10. 0

R. W.*W. F. =

4.0

0.4

RELIABILITY

FAILURE

RATES

FairR.W. =3.0

R.W.*W. F. =

1.5

Good

R.W. =6.0

R. W.*W. F. =

3.0

Good

R. W. =6.0

R.W.*W. F. =

3.0

Excel lent

R. W. =10.0

R. W.*W. F. =

5.0

Good

R.W. =6.0

R.F.*W. F. =

3.0

0.5

SAFETY

FAILURE

MODES

Good

R. W. =6.0

R.W.*W. F. =

6.0

Excellent

R.W.=IO.0

R.W.*W.F.=

10.0

Excellent

R.W.=IO. 0

R.W.*W.F.=

10.0

Excellent

R.W.=IO. 0

R.W.*W.F.=

10.0

Excellent

R.W.=IO. 0

R.W.*W.F.=

10.0

1.0

RADIATION

TOLERANCE

Good

R. W. =6.0

R.W.*W. F. =

4.2

Fair

R.W. =3. •

R. W.*W. F. =

2.1

Fair

R.W. =3.0

R. W.*W. F. =

2.1

Fair

R. W. =3.0

R. W.*W. F. =

2.1

FairR. W. =3.0

R. W.*W. F. =

2.1

0.7

OPERATIONS

SUPPORT

TESTABILITY

Good

R. W. =6.0

R. W.*W. F. =

.0

FairR. W. =3.0

R. W.*W. F. =

1.5

Fair

R. W. =3.0

IR. W.*W. F. =

1.5

Fair

R.W. =3.0

R. W.*W. F. =

1.5

FairR.W. =3.0

R. W.*W. F. =

1.5

0.5

COMMONALITY

APPLICATION

Excel lent

R. W.=IO. 0

R. W.*W.F. =

8.0

Good

R. W. =6. 0

R. W.*W. F. =

4.8

Good

R.W. =6.0

R. W.*W.F. =

4.8

Good

R.W. =6.0

R. W.*W,F. =

4.8

Good

R. W. =6. 0

R. W.*W. F. =

4.8

0.8

TOTALS

(see Not e)

FIGURE OF

MERIT

Figure of

Merit =

78.4 / 119

= 65.88

Figure of

Merit =

76.5 / 119

= 64.29

Figure of

Merit =

65.4 / 119

= 54.96

Figure of

Merit =

81.8 / 119

= 68.74

Figure of

Merit =

76.2 / 119

= 64.03

NOTE:

Figure of merit = i=_ 3"='-RWi * WFi / i=_3 i=

Table 2 0.1.2 (cont.)

Display Trade Study

RWi(10) * WF i

F_ .___ FRAME

/ t:O£,_;.OUT FRAME

14-19
0

0¢ .T

0

t_o

CO

0

014

GO

2:

14-20
C

,k)Em

0

**ml

,w,I £

r_

.4)

,f,

*lmi

,-.1

ml

in

=1

Z _IZ

[.-i E._ [-,

m ,..10

14-21

r_

in

,ml £

iml 0R

r_

roll

[5/

EZ

[-100

(:'6 6

c:-8

8

¢:-.,

Z.

(2"9 9

¢:-¢:

c:

(: "f;,

f_

¢:';_ Z

G;'T T

c:'O 0

0

[_

,Wl

*lmi

(b

2[m

2[

4,)

ml
o

0

14-22
Ii,ii

111

a

CI

14-23
2.0.2 COLOR DISPLAY VS. MONOCHROME

2.0.2.1 Color Encodinq vs. Monochrome Display Selection Criteria

The following lists each selection criteria that will be used in the

color vs. monochrome display trade study. The selection criteria is

divided into four generic categories; programmatic considerations,

performance parameters, commonality considerations and risk assessment. These selection criteria are based on requirements and program

goals set forth in the NASA RFP. Trade unique criteria were determined by independent technology research and defined in the Task Two

Options Development Phase.

Programmatic Considerations

A. IOC Cost

B. Life Cycle Cost

C. Schedule Impact

Performance Parameters

A. Visual Data Assimilation

B. Information Content

C. Contrast Ratio_

Commonality Considerations

A. Applications

Risk Assessment

A. Technology State-of-the-Art

B. AvaiIabiiity

1_24
2.0.2.2 Color Encodinq vs. Monochrome Display Weiqhtinq Factors

The following lists each weighting factor associated with each selection criteria used in the color vs. monochrome display trade study.

These weighting factors were determined by a panel of Sperry space

station system personnel in con3unction with NASA RFP requirements

emphasis.

Programmatic Weighting Factors

A. IOC Cost Weighting Factor = (0.8)

B. Life Cycle Cost Weighting Factor = (0.8)

C. Schedule Impact Weighting Factor = (0.3)

Performance Weighting Factors

A. Visual Data Assimilation Weighting Factor = (0.4)

B. Information Content Weighting Factor = (0.4)

C. Contrast Ratio Weighting Factor = (0.4)

Commonality Weighting Factors

A. Application Weighting Factor = (0.4)

Risk Criteria Weighting Factors

A. Technology SoA Weighting Factor = (0.3)

B. Availability Weighting Factor = (0.3)

14-25
2.0.2.3 Color Encoding vs. Monochrome Display Trade Study

This trade study evaluates the use of color for information display

against the use of monochrome. Table 2.0.2.3 is the actual trade

study results. Color displays have the advantage with a figure of

merit of 84.63 against 72.68 for monochrome displays. From Figure

2.0.2.3 it is clear the main drivers for color displays is the visual

data assimilation, information content, and application selection

criteria.

Figure 2.0.2.3 is a bar graph representation of the data in Table

2.0.2.3. By visually scanning this figure it is immediately evident

that the main drivers for color display information are the visual

data assimilation, information content, and application selection

criteria. Programmatic considerations tend to be slightly better for

monochrome displays. This is not surprising since older, well

established, technologies will always have lower coat, less schedule

constraints and etc.

14-26
Options

Color

Display

Monochrome

Display

Weighting

factor

IOC cost

IOC cost involves human

factors research and

standards involving color

information

_resentation

R. W.=8.0

R.W. * W.F. =

6.4

Monochrome

information

display is

well established and

less complex

than color

R. W.=IO. 0

R.W. * W.F. =

8.0

0.8

NOTE: Figure of merit

ORIGINAL.pAGE IS

oe eooe QuALrrv

PROGRAMMATIC

Life Cycle

Cost

Color encoding research

Schedule

Impact

Color information encodVisual Data

Assimilation

Human assimilation of

PERFORMANCE

Information

Content

High display

data content

Contrast

Rat i o

Software con-

_- troilable

COMMONALITY

Appl icat ion

Color applicable to all

RISK

Technology Avai labi i ity

SoA

More research

must be done

Color CRT's

are commerTOTALS

Figure of Merit :

(see Note)

Color displays

are desireab ie

and development will be

a continual

profess for

each new

display format

ing and presentation

could increase

schedule

color coded

information

extremely

high

!possible due

to high data

assimilation

contrast ratio through

color combinations

display formats

on informattion enhancement using

color

cially available although

full color

flat panels

are not

and driven by

the information

content and

data assimilation parameters

R. W. =9.0

R.W. * W.F.

7.2

R. W. =9.0

New display

formats will

not require

large informat ion present at ion

deve Io pment

cost s

R.W.=IO. 0

R.W. * W.F. =

8.0

0.8

R.W. * W.F.

2.7

No schedule

increase anticipated

R.W.=IO. 0

R.W. * W.F.

3.0

0.3

R.W.=IO. 0

R.W. * W.F.

4.0

Assimi lat ion

of data improved only

by inforrnaR.W.=IO. O

R.W. . W.F.

4.0

Lower data

assimilation

implies lower

display inR.W.=10.0

R.W.*W.F.

4.0

Fixed contrast ratio

R.W.=10.0

R.W. * W.F.

4.0

Monochrome

has restricted applications

R. W. =9. •

= R.W. * W.F.

2.7

Monochrome

informat ion

enhancement

well est abR. W.=8.0

R.W. * W.F.

2.4

Both monochrome CRT's

and flat panels are comtion positioning

R. W. =2.0

R. W.

format ion req u irernent s

R. W. =2.0 R.W. =5.0

0.4

R.W. * W.F.

0.8

0.4

Rm W.

0.4

R.W. =3. O

R.W. * W.F.

1.2

0.4

lished

R.W.=IO.0

R.W.*W.F.

3.0

0.3

mercialiy avai lable

R.W.=IO.0

= R.W. * W.F.

3.0

0.3

Figure

of merit =

37.4 / 41.0 =

84.63

Monochrome

displays have

rnany adva_t ages but are

not desineabl e

,from a crew

Iper formance

Iviewpoint

Figure

of rnerit =

29. 8 / 41.0 =

72.6a

= i_9 RWi * WFi / i_9 RWi(10). WF i

i=I i=I

Table 2.0.2.3

Color vs. Monochrome Display Trade Study FOLOOUT

14-27
_0

El3

-r-_l 00000

I,,,=1 0

¢D

=M

_0

I=,=1 E0Z

cD00E1⁄2

E_Z

14-28

Z0

i,ml

,¢

,-1

,¢

,¢o

=N000Z

b.1

4

m

_'66

¢='8 8

¢=- .,_

_'9 9

¢_-¢;

¢=

¢='E;

E;

¢_-_ T

c='O 0

00

,=

,=

"T

==
2.0.) INPUT CONTROLS SELECTION

2.0.3.1 Input Controls Selection Criteria

The following lists each selection criteria that will be used in the

input controls trade study. The selection criteria is divided into

eight generic categories; programmatic considerations, performance

parameters, commonality considerations, risk assessment, maintainability, user friendly reliability, and safety. These selection

criteria are based on requirements and program goals set forth in

the NASA RFP. Trade unique criteria were determined by independent

technology research and defined in the Task Two Option Development

Phase.

Programmatic Considerations

A. IOC Cost

B. Life Cycle Cost

C. Schedule Impact

Performance Parameters

A. Positioning

B. Speed

C. Portability

D. Ergonomics

E. Volume

F. Power

Commonality Considerations

A. Application

1_29

o
Risk Assessment

A. Technology State-of-the-Art

B. Producibility/Avaiiabiiity

Maintainability

A. Repairability

B. Replaceability

User Friendly

A. Response Time

Reliability

A. Failure Rates

Safety

A. Failure Modes

B. Radiation Tolerance

14-30
2.0.3.2 Input Controls Weightinq Factor

The following lists each weighting factor associated with each

selection criteria. These weighting factors were determined by a

panel of Sperry space station personnel in conjunction with NASA

RFP requirements emphasis.

Programmatic Weighting Factors

A. IOC Cost Weighting Factor = (0.8)

B. Life Cycle Cost Weighting Factor = (0.8)

C. ScheduIe Impact Weighting Factor = (0.))

Performance Weighting Factors

A. Positioning Weighting Factor = (0.4)

B. Speed Weighting Factor = (0.4)

C. Portability Weighting Factor = (0.4)

D. Ergonomics Weighting Factor (0.4)

E. Volume Weighting Factor = (0.4)

F. Power Weighting Factor = (0.4)

Commonality Weighting Factors

A. Application Weighting Factor = (0.4)

Risk Weighting Factors

A. Technology S.A. Weighting Factor = (0.))

B. Producibility/Availability Weighting Factor = (0.3)

!!

!11

!!

i""

T"

14-31
Maintainability Weighting Factors

A. Repairability Weighting Factor = (0.5)

B. Replaceability Weighting Factor = (0.5)

User Friendly Weighting Factors

A. Response Time Weighting Factor = (0.4)

Reliability Weighting Factors

A. Failure Rates Weighting Factor = (0.5)

Safety Weighting Factors

A. Failure Modes Weighting Factor = (i.0)

B. Radiation Tolerance Weighting Factor = (0.7)

I_32
2.0.3.3 Input Controls Trade Study

This trade study evaluates the use and desirability of current input

controi types for use in the Space Station Crew Workstation. These

input controis were seiected and described in previous sections of

this study, i.e., Task Two, options phase. The options selected were:

Keyboard

Touch Panei

Joystick

Light Pen

Graphics Tabiet

Mouse

Trackbail

Voice

Tabie 2.0.3.3 is the trade study results. The choice of a keyboard,

touch panel, joystick, mouse, Iight pen or trackbail or combination

thereof would all be appropriate. The graphics tablet has deficiencies

in the area of size, and voice in the area of technology State-of-theArt. Either would not be desirable due to insufficiencies in these

areas.

Table 2.0.3.3 is the actual trade study results. The following lists

the order of preference, and the total dot product of the weighting

factor vector and the trade parameter vector, for the input controls

media options.

14-33
i. Keyboard - 96.80

2. Trackball - 96.40

3. Joystick - 94.50

4. Light Pen - 94.40

5. Touch Panel - 94.15

6. Mouse - 88.70

7. Graphics Tablet - 82.30

8. Voice - 72.57

A "figure of merit" is also calculated indicating the percentage of

satisfying all selection criteria. These are as follows:

i. Keyboard - 93.81

2. Trackball - 93.59

3. Joystick - 91.75

4. Light Pen - 91.65

5. Touch Panel - 91.41

6. Mouse - 86.12

7. Graphics Tablet - 79.90

8. Voice - 72.57

The keyboard and trackball are the leading contenders for input control

devices for the space station. In reality a keyboard and another input

control device will probably be used. The trackball, joystic, light

pen, touch panel and mouse are all candidates. Although the trackball

is the preferred device, any of the above have potential for use on

the space station.

For ease in interpreting the trade study, parameters in Table 2.0.3.3

°

refer to the bar graph in Figure 2.0.3.3.

I_34
ORIGINAL PAGE IS

OFPOORquALm'

Opt ions

KEYBOARD

TOUCH PANEL

JOYSTICK

LIGHT PEN

GRAPHICS TABLET

MOUSE

TRACKBALL

VOICE

Weighting

factor

IOC COST

Well established low

cost technology

R.W.=9.5

R.W_ * W.F. = 7.6

Well established low

cost technology

R.W.=10.0

R.W.'* W.F. = 8.0

Well established low

cost technology

R.W. = 10.0

R.W. * W.F. = 8.0

Well established low

!cost technology

R.W. = 10.0

R.W. * W.F. = 8.0

Well established low

cost technology

R.W. = 10.0

R.W. * W.F. = 8.0

Well established low

cost technology

R.W. = 10.0

R.W. * W.F. = 8.0

Well established low

cost technology

R.W.=10.0

R.W. * W.F. = 8.0

High cost - technology needs improver,_ent

R.W. = 6.0

R.W. . W.F. = 4.8

0.8

PROGRAMMATIC

LIFE CYCLE COST SCHEDULE IMPACT

No dramatic technology change foreseen

R.W. = 10.0

R.W. * W,F. = 8.0

No dramatic technology change foreseen

R.W. = 10.0

R.W. * W.F. = 8.0

No dramatic technology change foreseen

R.W.=10.0

R.W. * W.F. = 8.0

No dramatic technology change foreseen

R.W. = 10.0

R.W. * W.F. = 8.0

No dramatictechnology change foreseen

R.W.=10.0

R.W. * W.F. = 8.0

No dramatic technology change foreseen

R.W.=IO. 0

R.W. * W.F. = 8.0

No dramatic technology change foreseer

R.W.=!0.0

R.W. * W.F. = 8.0

High technology cost

associated with

voice improvements

R.W. = 6.0

R.W. * W.F. = 4.8

0.8

No schedule impact

due to well developed technology

R.W. = 10.0

R.W. * W.F. = 3.0

No schedule impact

due to well developed technology

R.W. = 10.0

R.W. * W.F. = 3.0

No schedule impact

due to well developed technology

R.W. = 10.0

R.W. * W.F. = 3.0

No schedule impact

due to well developed technology

R.W. = 10.0

R.W. * W.F. = 3.0

No schedule impact

due to well developed technology

R.W. = 10.0

R.W. * W.F. = 3.0

No schedule impact

due to well developed technology

R.W. = 10.0

R.W. * W.F. = 3.0

No schedule impact "

due to well develiooed technology

R.W. = 10.0

R.W. * W.F. = 3.0

New technology

break.-t hroughs needed for voice

RIW. = 7.0

R.W. * W.F. = o. 1

0.3

I FOLDOUT. F_

Table :_.0.3. 3

Input Controls Trade Study

PERFORMANCE

POSITIONING

Positioning with

keyboard can be extreme ly accurate

R.W. = 10.0

R.W. * W.F. = 4.0

Limited by finger

width and screen

size

R.W. = 6.0

R.W. * W.F. = 2.4

High resolution

R.W. = 10.0

R.W. * W.F. = 4.0

Very high resolution - pen width

R.W.=__10.0

R.W. * W.F. = 4.0

High resolution may

exceed human manipulative" ability

R.W. = 10.0

R.W. * W.F. = 4.0

Some slipoage error

R.W.=5.0

R.W. * W.F. = 2.0

-I Small cursor increment s

R.W.=9.5

R.W. * W.F. = 3.8

Very high resolut ion

R.W.=IO. 0

R.W. * W.F. = 4.0

°0.4

SPEED

Keyboard inputs and

_ositioning is rel_

at ively slow

R.W. = 8.0

R.W. * W.F. = 3.2

Extremely fast

R.W. = 10.0

R.W. * W.F. - 4.0

Rapid displacement

R.W. = 9.0

R.W. * W.F. = 3.6

Push button to act ivate

R.W. =8.0

R.W. * W.F. = 3._

i

Rapid displacement

R.W. = 9.0

R.W. * W.F. = 3.6

Rapid displacement

R.W. = 9.0

R.W. * W.F. = 3.6

Rapid displacement

R.W. = 9.0

R.W. * W.F. = 3.6

Extremely fast

R.W. = 10.0

R.W. * W.F. = 4.0

0.4

PORTAB ILI TY

Somewhat cumbersome

R.W.=7.0

R.W. * W.F. = 2.8

Attached to screen

of display

R.W.=10.0

R.W. * W.F. = 4.0

ISmall device

R.W.=8.0

R.W. * W.F. = 3.2

Pencil size device

R.W.=9.0

R.W. * W.F. = 3.6

Cumbersome

R.W.=I.0

R.W. * W.F. = 0.4

Small device but

need counter space

to operate

R.W. = 2.0

R.W. * W.F. = 0.8

Small device

R.W.=8.0

R.W. * W.F. = 3.2

Software implemented

and essential nonport ab ie

R.W. = 2.0

R.W. * W.F. = 0.8

0.4

ERGONOM I CS

Excellent e_gonomic

characteristics

R.W. = 10.0

R.W. * W.F. = 4.0

Problems include

smeared finger_rint_

and operator fatigut

R.W. = 8.0

R.W. * W.F. = 3.2

Excel lent ergonomic

charact e_ i st ics

R.W. = 10.0

R.W. * WoF. = 4.0

Can cause operator

fat i g ue

R,W. = 8.0

R.W. * W.F. = 3.2

Consumes large area_

of space

R.W. = 2.0

R.W. * W.F. = 0.8

Questionable ooePat ion in zero-G environment

R.W. = 2.0

R.W. * W.F. = 0.8

Excel lent ergonomic

charact e_ i st ics

R.W. = 10.0

R.W. * _4. F. = 4.0

Noise, voice deflections, and patterns

areas of concern

R.W. = 7.0

R.W. * W.F. = 2.8

0.4

"_... FOLDOUT FRAME

1_35(.k.,

t4-
I

Opt ions

KEYBOARD

TOUCH PANEL

JOYSTICK

LIGHT PEN

GRAPHICS TABLET

MOUSE

TRACKBALL

VO I CE

Weighting

factor

ORIGINAL PAG_ 15

POOR QU/ 

PERFORMANCE (cont.)

VOLUME

Tend to consume

space

R.W.=8.0

R.W. * W.F. = 4.8

Occupies virtually

no space

R.W. = 10.0

POWER

Low voltage device

R.W.=9.0

R.W. * W.F. = 5.4

Requires light emitters, receptors, and

ipPc, cessi ng cicuitry

I R.W. = 8.0

R.W. * W.F. = 4.0

Small device

R.W.=9.0

R.W. * W.F. = 3.6

Very small device

R.W.=9.5

R.W. * W.F. = 5.7

Occupies large desk

top areas

R.W.=2.0

R.W. * W.F. = 1.2

Small device

R.W.=9.0

R.W. * W.F. = 5.4

Small device

R.W.=9.5

R.W. * W.F. = 5.7

Associated hardware

consumes space

R.W.=6.0

R.W. * W.F. = 3.6

0.6

R.W. * W.F. = 4.8

Extremely low voltage

R.W. = 10.0

R.W. * W.F. -- 6.0

Requires processing

circuitry

R.W.=8.0

R.W. * W.F. = 4.8

Requires processing

circuitry

R.W.=8.0

R.W. * W.F. = 4.8

Extremely low voltage

R.W.=10.0

R.W. * W.F. = 6.0

Extremely low voltage

R.W.=lO.O

R.W. * W.F. = 6.0

Requires software

and processor

R.W. = 2.0

R.W. * W.F. = 1.2

0.6

I _'OLDOUT FRAME

Table 2.0.3.3 (cor, t.)

Input Controls Trade Study

COMMONALITY

APPLICATION

Can be used for all

applications

R.W. = 10.0

R.W. * W.F. = 8.0

Limited to activating CMD'S from display

R.W. = 8.0

R.W. * W.F. = 6.4

Limited to cursor

movement

R.W.=7.0

R.W. * W.F. = 5.6

Limited to activating CMD's from display

R.W. = 8.0

R.W. * W.F. = 6.4

Limited use

R.W.=5.0

R.W. * W.F. = 4.0

Limited to cursor

movement

R.W.=7.0

R.W. * W.F. = 5.6

Limited to cursor

movement

R.W.=7.0

R.W. * W.F. = 5.6

With correct technology can be used

for all applications

R.W. = 9.0

R.W. * W.F. = 7.2

0.8

RISK

TECHNOLOGY SOA

Well developed technology

R.W.=10.0

R.W. * W.F. = 6.0

Well developed technology

R.W. = 10.0

R.W. * W.F. = 6.0

Well developed technology

R.W.=10.0

R.W. * W.F. = 6.0

Well developed technology

R.W. = 10.0

R.W. * W.F. = 6.0

Well developed technology

R.W.=IO. 0

R.W. * W.F. = 6.0

Well develooed technology

R.W. = 10.0

R.W. * W.F. = 6.0

Well developed technology

R.W.=IO. 0

R.W. *" W.F. = 6.0

Techr, o !ogy r,eeds

PRODUCIBLILITY/

AVAILABILITY

Commercially available

R.W.=10.0

R.W. * W.F. = 6.0

Commercially available

R.W.=IO. 0

R.W. * W.F. = 6.0

Commercially available

R.W.=10.0

R.W. * W.F. = 6.0

Commercially available

R.W.=10.0

R.W. * W.F. = 6.0

Commercially available

R.W.=10.0

R.W. * W.F. = 6.0

Commercially available

R.W.=10.0

R.W. * W.F. = 6.0

Commercially available

R.W.=IO. 0

R.W. * W.F. = 6.0

Produceability no

ORIGINAL p,_,C;_ _S

OF POOR QUALm"

MAINTAINABILITY

REPAIRABILITY REPLACEABILITY

Repair complex Plug-in unit - Replaceable 0_

R.W. = 6.0 R.W. = 10.0

R.W. * W.F. = 3.0 R.W. * W.F. = 5.0

Repair complex Bezel disass_bly

R.W. = 5.0

R.W. * W.F. = 5.5

Repair complex

R.W. = 5.0

R.W. * W.F. = 2.5

Repair complex

R.W. = 5.0

R.W. * W.F. = 2.5

Repair complex

R.W. = 5.0

R.W. * W.F. = 2.5

Repair complex

R.W. = 5.0

R.W. * W.F. = 2.5

Repair complex

R.W. = 5.0

R.W. * W.F. = 2.5

IComplex processor

vast improvement

R.W.=6.0

R.W. * W.F. = 3.6

oroblem or,ce technology developed

R.W.=9.5

R.W. * W.F. = 5.7

0.6

repair

R.W. = 5.0

R.W. * W.F. = 2.5

0.5

R.W. = 8.5

R.W. * W.F. = 4.25

Plug-in unit - Replaceable ORB

R.W.=10.0

R.W. * W.F° = 5.0

Plug-in unit - Replaceable ORU

R.W.=10.0

R.W. * W.F. = 5.0

Plug-in unit - Replaceable O_

R.W. = 10.0

R.W. * W.F. = 5.0

Plug-in unit - Replaceable ORB

R.W. = 10.0

R.W. * W.F. = 5.0

Plug-in unit - Re

placeable O_

R.W. = 10.0

R.W. * W.F. = 5.0

Involves processor

changeout

R.W.=9.0

R.W. * W.F. = 4.5

0.5

14-36 ¢x.,,

 OLDOUT FRAME
i

Opt ions

KEYBOARD

TOUCHPANEL

/

JOYSTICK

LIGHT PEN

GRAPH ICS TABLET

MOUSE

TRACKBALL

VOICE

Weight ing

factor

USER FRIENDLY

RESPONSE TIME

No response time

:roblems

R.W.=10.0

R.W. * W.F. = 4.0

No response time

problems

R.W.=10.0

R.W. * W.F. = 4.0

No response time

problems

R.W.=10.0

R.W. * W.F. = 4.0

No response time

0roblems

R.W.=10.0

R.W. * W.F. = 4.0

No response time

0roblems

R.W.=10.0

R.W. * W.F. = 4.0

NO response time

oroblems

R.W.=10.0

R.W. * W.F. = 4.0

No response time

oroblems

R.W.=10.0

R.W. * W.F. = 4.0

Function of vocabulary and sophisticat ion

R.W. = 8.0

R.W. * W.F. = 3.2

0.4

RELIABILITY

FAILURE RATES

Low

R.W. = 10.0

R.W. * W.F. = 5.0

Low

R.W. = 10.0

R.W. * W.F. = 5.0

Low

R.W. = 10.0

R.W. * W.F. = 5.0

Med i um

R.W.=8.0

R.W. * W.F. = 4.0

Med ium

R.W.=8.0

R.W. * W.F. = 4.0

Low

R.W.=10.0

R.W. * W.F. = 5.0

Low

R.W.=10.0

R.W. * W.F. = 5.0

Med iurn

R.W.=8.0

R.W. * W.F. = 4.0

0.5

FAILURE MODES

Fa i I "Jsa fe

R.W. = 10.0

R.W. * W.F. = 10.0

Fail safe

R.W. = 10.0

R.W. * W.F. = 10.0

Fai I safe

R.W.=10.0

R.W. * W.F. = 10.0

Fai I safe

R.W. = 10.0

R.W. * W.F. = 10.0

i

Fai I safe

R.W. = 10.0

R.W. * W.F. = 10.0

Fai I safe

R.W. = 10.0

R.W. * W.F. = 10.0

Fai i safe

R.W. = 10.0

R.W. * W.F. = 10.0

Fai 1 safe

R. WZ = 10.0

R.W. * W.F. = 10.0

NOTE : Figure of r,lerit=

i=18 / i=_18

Z RW i * WF i

i=I i=

Table 2. 0. 3.3 (cont.)

Input Controls Trade Study

RW i (10) * WFi

SAFETY

i

RADIATION TOLERANCE

None

R.W. = 10.0

R.W. * W.F. = 7.0

Some technologies

are _adiation sensitive

R.W. = 8.0

R.W. * W.F. = 5.6

,

None

R.W. = 10.0

R.W. * W.F. = 7.0

,None

R.W. = 1_0.0

R.W. * W.F. = 7.0

None

R.W. = 10.0

R.W. * W.F. = 7.0

No_e

R.W. = 10.0

R.W. * W.F. = 7.0

None

R.W. = 10.0

R.W. * W.F. = 7.0

Hardware nlust be

iradiation hardened

R.W. = 8.5

R.W. * W.F. = 5.95

0.7

_OLDOUT FRA_

TOTAL

FIGURE OF MERIT

(see Note)

Figure of merit=

96.80

= 93.81

103.00

Figure of merit=

94.15

= 91.41

103.00

Figure of merit=

94.50

= 91.75

103.00

Figure of merit=

94.40

= 91.65

103.00

Figure of merit=

82.30

= 79.90

103.00

Figure of merit=

88.70

103.00

= 86.12

Figure of merit=

96.40

= 93.59

103.00

Figure of merit=

77.75

103.00

= 72.57

14-37

7__.
G'9

r'---i

-r"l p,_

ltl

I=

0

,==1

.,I.;,

¢1

,.=

0

I{LI

iml

ILl t,,.i

=: =:

:_ _ • _ • .,.4

0 0 .,_ _ 0 _ 0

D@ DDNF1

w

14..38

'=::'6

6

,1::;.8 0

0

8

(:: - .,_

,t.. =

c;" 9 ,,=;

ill

¢_-G :Z

¢:

m

¢::-_ =:

c: • E::: ,,,.,

E: "='

*==1

¢: - -IL- _

I11

11;

(::'0

,0
o

,=

0_

lml

_ _ _ ._ _ .,_

0 0 .N _ 0 _ 0

D_HHDND

1°i°

_r..)

r_ x _ o o [..,

o i_ _ ID

,,,_ _ _ _

[.,.i

,-.a

14-39 1:1.4

¢:'_.

t.

¢:'9

9

¢=

c='1_

S;;" E;

¢:-:_

¢:'T

T

G'O

O

,=

:Z

°*=1

:3[

:)

Iml
O

_

.+..> O

-r-4

)-..(

ino

14.40

-6

-8

-z.

"9

"c:

-_:

";_

"T

"0

0

4,)

:Z

4,,;*

-i,)

iml
2.0.4 CAUTION AND WARNING SYSTEM SELECTION

2.0.4.1 Caution and Warning Selection Criteria

The following lists each selection criteria that will be used in the

caution and warning trade study. The selection criteria is divided

into six generic categories; programmatic considerations, performance

parameters, risk assessment, growth and evolution, safety, and user

friendly. These selection criteria are based on requirements and

program goals set forth in the NASA RFP. Trade unique criteria were

determined by independent technology research and defined in the Task

Two Options Development Phase.

Programmatic Considerations

A. IOC Cost

B. Life Cycle Cost

C. Schedule Impact

Performance Parameters

A. Power

B. Volume

C. Aiarm Recognition

D. Controilabiiity

E. Alerts

F. Ergonomics

Risk Assessment

A. Technology State-of-the-Art

B. Availability

14-41
Growth and Evolution

A. Growth Capability

Safety

A. Failure Modes

User Friendly

A. Crew Performance

14-42
2.0.4.2 Caution and Warning Weightin q Criteria

The following lists each weighting factor associated with each selection

criteria used in the caution and warning trade study.

Programmatic Weighting Factors

A. IOC Cost Weighting Factor = (0.8)

B. Life Cycle Cost Weighting Factor = (0.8)

C. Schedule Impact Weighting Factor = (0.3)

Performance Weighting Factors

A. Power Weighting Factor = (0.6)

B. Volume Weighting Factor = (0.6)

C. Alarm Recognition Weighting Factor = (i.0)

D. Controllability Weighting Factor = (0.7)

E. Alerts Weighting Factor = (0.7)

F. Ergonomics Weighting Factor = (0.4)

Risk Assessment

A. Technology State-of-the-Art Weighting Factor = (0.3)

B. Availability Weighting Factor = (0.3)

Growth and Evolution

A. Growth Capability Weighting Factor : (0.6)

Safety

A. Failure Modes Weighting Factor = (i.0)

User Friendly

A. Crew Performance Weighting Factor = (0.4)

14-43
2.0.4.3 Caution and Warninq Trade Study

This trade study evaluates the use and desirability of a distributed

or integrated caution and warning system for use on the NASA Space

Station. The options and characteristics were developed in the Task

Two Options Development Phase.

It is quite clear that an integrated caution and warning system is the

overall preferred system with a figure of merit of 94.59. The

distributed caution and warning system obtained a figure of merit of

65.06 or 29.53 points below the integrated caution and warning system.

This result is a reflection of current problems encountered in current distributed avionic caution and warning systems.

Table 2.0.4.3 is an overall bar chart graph of the trade study results.

It is easily seen that the main drivers in choosing an integrated

system are: alarm recognition, controllability and failure modes.

These areas are also areas of concern in todays avionics caution and

warning systems.

In today_ distributed caution and warning systems alarm recognition is

a problem due to the proliferation of alerts inhibiting the ability to

correlate the alarm to a specific problem area. Distributed systems

also prevent the categorizing and prioritizing alerts; an extremely

important task during periods of high workload. During this period

of high workload non-critical alerts may not be inhibited or controllable in a distributed system, leading to a saturating of crew

members processing capabilities. This may lead to dangerous failure

modes by superfluous or misleading error alerts or alarms.

14-44
OFpOOR

Opt ions

DISTRIBUTED

CAUTION AND

WARNING SYSTEM

INTEGRATED

CAUTION AND

WARNING SYSTEM

Weight ing

factor

PROGRAMMATIC

IOC COST

Cost will be

moderately high

for distributed

system due to

hardware and

orocessing redundancy.

R.W. = 10.0

R.W. * W.F. =

8.0

Although hardware may be reduced for the

integrated system, software

and systems development will

create a high

cost.

R.W. = 8.0

R.W. * W.F. =

6.4

0.8

LIFE CYCLE COST

Cost will be

high over the

life cycle of

the space station due to

prol i ferat ion

of hardware,

power and space

problem areas.

R.W. = 8.0

R.W. * W.F. =

6.4

Cost will tend

to be lower

over- the life

cycle of the

space station.

R.W. = 10.0

R.W. * W.F. =

8.0

0.8

SCHEDULE IMPACT

Distributed advisory, caution

and warning

systems are not

complex and

should not create schedule

constraints.

R.W. = 10.0

R.W. * W.F. =

3.0

An integrated

advisory, caution, and warning system will

require large

amounts of system and software development time

thereby increasing schedule

development

t ime.

R.W. = 7.0

R.W. * W.F. =

2.1

0.3

FOLDOUT FRAM(

Table 2.0.4.3

Caution and Warning TradeStudy

POWER

Power must be

supplied to all

distributed

systems and

some power will

be redundant.

R.W. = 9.0

R.W. * W.F. =

5.4

Power- can be

optimized by

consol idat ing

functions in an

integrated syst era.

R.W. = 10.0

R.W. * W.F. =

6.0

0.6

VOLUME ....

Prol i ferat ion

of alerts and

caution and

warning devices

tends to consume more volume.

R.W. = 6.0

R.W. * W.F. =

3.6

Conso I idat ion

of funct ions

leads to decreased volume.

R.W. = 10.0

R.W. * W.F. =

6.0

0.6

PERFORMANCE

ALARM

RECOGN IT ION

Correlat ion of

alert and system checklists

not straightforward. A lmost impossible

to categorize

and priorit ize

!alerts.

R.W. = 4.0

R.w. * w.#. =

4.0

Facilitates

correlation of

alert and system checklists

needed for"

checkout. Central processor

software improves ability

to categorize

and priorit ize

alerts.

R.W. = 10.0

R.W. * W.F. =

10.0

1.0

COl ITROLLAB IL ITY

Inhibiting aI

lepts not dire_t ly control _

lable.

R.W. = 0.0

R.W. * W.F. =

0.0

Non-cr it i ca I alerts may be

inhibited during a period of

high workload.

R.W. = 10.0

R.W. * W.F. =

7.0

0.7

ALERTS

Has _endency to

prol i ferat e

workst at ion

with alerts.

R.W. = 5.0

R.W. * W.F. =

3.5

Alerts are more

easily consolidated.

R.W. = 10.0

R.W. * W.F. =

7.0

0.7

_OLDOUT F_E

14-4 5

/f: ,ff
ORIGINAL PAGE IS

POORqUALn'Y

Opt ions

DISTRIBUTED

CAUTION AND

WARNING SYSTEM

INTEGRATED

CAUTION AND

JARNiNG SYSTEM

Weighting

factor

PERFORMANCE

(cont.)

ERGONOMICS

Difficult task

to correlate

alert-type ao-

)!ications arid

RISK

TECHNOLOGY SOA

Technology is

available and

in a mature

state.

AVAILABILITY

The technology

availability

factor is relam

tively low.

si gni ficar, ce.

R.W. = 4.0

R.W. * W.F. =

1.6

R.W. = 10. O

R.W. * W.F. =

3.0

R.W. = 10.0

R.W. * W.F. =

3.0

Central processor software

can easily correlate alerttypes and their

si gni ficance.

Technology is

available, although much appl icat ior_s,

systems integrat i:-,n, and

software work

will need to be

The technology

avai labi I ity

factor is higher due t,-, imo!ement ing a

relatively new

and complex

conceDt.

done.

R.W. = 10.0

R.W. * W.F. =

4.'_

0.4

R.W. = 7._

R.W. * W.F. =

_° "_

R.W. = 8.0

_.W. * W. _-. =

c..4

_.3

NO,_. Figure of merit = 'E _W i * WF i / RW i <10) * W_ i

i=l :=I

-a:'e 2. D. _. 3 {_-:ft.

FQLDOUT FRAME

GROWTH AND

EVOLUTION

GROWTH

CAPABILITY

Alerts can be

added oft a_ Jr,-

dependent basis.

R.W. = 10. O

R.W. * W.F. =

6.0

Integrated system hardware/

software must

be modified to

add, delete, ,or

alter alerts.

_.W. = 9.0

R.W. , W.c. =

5.6

SAFETY

FAILURE MODES

Operators may

ignore alarms

if he thinks it

is false.

R.W. = 5.0

R.W. * W.F. =

5.0

_ I

A smart integrated system

would prevent

obvious false

alar_s.

R.W. = 10.0

_.W. * W - =

10. O

1.0

USER FRIENDLY

CREW

PERFORMANCE

Lower overall

crew member

oer fort,lance

level due to

_rol i ferat ion

and non-cat egorization of alerts.

R.W. = 7.0

R.W. * W.F. =

2 8

Higher .overall

crew me_ber

performance

level.

R.W. = 10.0

R.W. * W.F. =

4.0

i

i

TOTALS

!FIGURE OF MERIT

(see Note)

Figure ,of merit

55.3

= 65.06

85. •

Figure ,of merit

80.4

= 94.59

85.0
-E-,

co

,p4

g,

VV

14-47

_'6 6

_'8

_w4

_'9

,p4

9

_'T_

,p4

T_

_'_

,p4

,p4

_-T_

_'0 0
XV. MASS STORAGE

15-1
RASS STORAGE TRADE STUDY

1. Reason For Trade Study

Rass storage devices will be used extensively by the SSDS for both on-board

and ground elements. This trade study will identify preferred options and

configurations for the specific application areas that are expected to drive

the system design and/or stress the available technology.

2. Backqround

The Space Station Program will handle, process, and'store unprecedented

quantities of data. This will require innovative concepts that address a wide

range of data storage requirements from short-term buffering to long term

archival. The type of data will also vary significantly and includes the'

following:

Software

Manuals

Command Procedures

Level 0 Data

Communication (voice, video)

Engineering Data

Real Time Data

Buffered Data

Trend Data

Diagnostics Support Data

Etc.

Nhile mass storage devices will be used extensively throughout the SSDS,

commercially available products will satisfy many of the program needs.

However, specific applications areas have been identified that are expected to

be design/technology drivers. In these areas a more detailed analysis is

required to identify preferred devices and configurations. Since these

applications are likely to have a wide variation in requirements and

architectural needs, it is likely that different technologies may be

appropriate for the different applications.

1_3

_CEDI_G PAGE F.:,L,_.'( i_OT FILMED
The drivers for these applications are requirements (documented in the Task I

report), derived requirements, and design characteristics. The key

application areas to be addressed by this trade study are:

R. Buffering of delayable payload data both in space and on the ground

B. Short term archiving of customer data

C. On-board space station data base

Key buffering design characteristics developed from simulations of a

preliminary end-to-end concept and the LaRC data base as modified by the Woods

Hole update are presented in Table 1. A graphic representation of the

buffering loads driven by mission needs and communication constraints is shown

in figure 2. Table 1 shows that the buffering requirements are separated into

three functional areas, on-board space station, on-board polar-orbiting

platform (POP), and data handling center buffers. POP(l) simulation results

are used as they represent the worst case POP design characteristics. Final

design characteristics for each functional area will be a function of system

design and will be derived during this study and in conjunction with evolving

system definition concepts.

SPACE POLAR-ORBIT DATA HANDLING

STATION PLATFORM CENTER

CAPACITY: 2 X 1011 BITS 5.1X 1011 BITS 1012 BITS

TRANSFER RATE: 300 MBITS/SEC 300 MBITS/SEC IN:9OO MBITS/SEC

-6 -6 -6

BIT ERROR RATE: < 10 < 10 < 10

PHYSICALS: SPACE FLIGHT SPACE FLIGHT NONE

CONSTRAINED CONSTRAINED

RAD HARDNESS

TOTAL DOSE:

RELIABILITY

MAINTAINABILITY:

230 RADS/YERR

MAN AVAILABLE

2K-25K RADS/YEAR

SPECIAL MISSION

NONE

MAN AVAILABLE

Table I: Design characteristics for critical SSDS buffers

164
|

!

T

5

SPACE STATIOtl IOC _IGM RATE |LJrFEQ LOaD

TI_E IN HOU_S

!

!

.ff

$

XlO 11

5.54-

i.tHD ,IA

0.1

POP(I) IOC Hrcd.I RATE IlUlrTER LOmO

24.0

TI_E IN t.40_QS

DICTA _-_I_DLING CEP4TEI_ !-_C _L_'r_'EP LO_D

i l i • • • i i • i

O.O

TI_E IN _OUg5

_4,11

Figure 2: Plot of SSDS simulation buffer load results

15,,5
Requirements for short term archiving were developed by integrating the

mission set average data rate, for both IOC and growth, over the appropriate

time periods. The results of this mission set analysis are given below and

range from the IOC amount to the growth amount.

R. 12 hour on-line storage

5-8 X 1012 bits capacity

60 seconds access time

Rverage transfer rate of 110-179 Mbits/sec

B. 7 day off-line storage

7-10 X 1013 bits capacity

Less than 24 hours access time

Rverage transfer rate of 110-179 Mbits/sec

Storage of manuals and procedures, software, scheduling information, and

storage for customer data are a few of the many types of data the on-board

space station data base must store. As a whole, the mass storage system for

the on-board data base should provide fast access to the numerous kinds of

data. An analysis of the functions presented in Task I and the mission set

indicate that the on-board data base will have the following requirements

Storage capacity of 2 X 109 bits

Access time of 40 milliseconds

Peak transfer rate of 10 Mbits/sec

Results from the following trade studies will also have an impact on the mass

storage trade study:

R. End-to end networking

B. On-board local area networking

C. Distributed data base management

D. Space communications

The results from the above trade studies will directly affect the end-to-end

model used in the simulations that determine design characteristics. As the

trade studies progress, the model will be refined to reflect results from

other trade areas in order to obtain a consistent model.

15-6
3. Issues

The issues presented below are important because they will dictate to some

extent which technologies are used for mass storage in the SSDS. This trade

study will attempt to resolve these issues and determine which technologies

are best suited for the SSDS.

A, Figure 3 depicts the relationship between currently available mass

storage devices and the various SSDS applications. What is the risk

that present devices or new technology can evolve to meet the more

demanding design characteristics imposed by these SSDS applications?

BQ Can a common buffer capability be developed for Space station and

polar-orbit platforms?

Co What kind of on-board buffering configurations are needed to handle:

1. Merging of data from multiple sources?

2. High peak rates of up to 500 Mbits/sec?

D, Which technology will provide the more cost effective media for the

large quantity of data storage needed by the short term archiving

application?

E. Which technology can provide the fast access time needed by the

on-board data base and also provide the necessary capacity?

4. Trade Study Criteria

The mass storage options/configurations for each application will be evaluated

using the criteria presented in table 4. Each criterion is weighted according

to its overall relative importance in each application. For example,

environment and reliability will be given higher weights in the polar-orbit

application than in the space station application because of the man

availability on the space station. After evaluating the various options to

see how well they meet the design characteristics and requirements for each

application they will be ranked from one to ten for each criterion. That

ranking will be multiplied times the weight given to that particular

criterion. Summing the results for each option gives a figure of merit that

should indicate which option is best suited for use in the particular

application being studied. 1_7
1 day

1 week

PRESENT TECHNOLOGY

/

107 108 109 1010 1011 1012

Capacity (bits)

Figure 3. Relationship of Present Technology to Various SSDS Applications

1013

%

%

1014

15-8
CRITERIA

SPACE DATA SHORT

STATION HANDLING TERM

BUFFER POP BUFFER CENTER ARCHIVE

SPACE

STATION

DATA BASE

COST 10 10 15 20

-Development 4 4 4 5 4

-Recurring 5 5 10 5 5

-Media 1 1 1 10 1

10

DEVELOPMENT RISK 15 15 15 10 15

GROWTH

-Extendable

-Tech. Insertion

15 10 20 20

7 4 12 12 7

8 6 B 8 8

15

RAN 15 15 20 20 15

-Reliability 5 8 5 6 6

-Availability 5 5 10 7 5

-Maintainability 5 2 5 7 4

PHYSICALS

-Weight

-Power

15 15 0 0 15

5 6 0 0 5

10 9 0 0 10

ENVIROM_ENT

-Rad. Hardness

-Shock & Vib.

10 15 0 0 10

5 10 0 0 5

5 5 0 0 5

PERFORMANCE 15 15 25. 25

-Capacity 4 4 B 8 3

-Transfer Rate 5 5 9 5 3

-BER 4 4 5 5 4

-Access Time 2 2 3 7 5

15

SPECIAL 5 5 5 5 5

100 100 100 100 100 100 100 100 100 100

Table 4: Weighted set of criteria

i_9
5. Expected Results

By following the outlined methodology, the preferred mass storage device and,

if applicable, configuration can be found for each of the application areas.

Also, through the trade study process the issues presented in Section 3 should

be resolved or result in the identification of technology deficiencies that

need to be addressed by the Space Station Program.

6. Methodoloqy

The basic approach that was taken for the trades on buffering applications

consisted of the following:

R. Fully characterize the options to be traded. This was done and documented

as part of Task 2.

B. Derive the design characteristics for each buffering application. Rs the

mission model is updated, and certain end-to-end options chosen, a

simulation of the end-to-end model was done to further refine the design

characteristics for each buffering application. The buffering design

characteristics are presented in Table 1.

C. Develop candidate configurations. Buffering of delayable data is a complex

function which can be implemented in a variety of ways, thus each buffering

application needs to be looked upon as a system configuration rather than

simple device options. To do this, various configurations were developed

that use one or more of the options (that is, different configurations may

be required to make the most efficient use of a given device technology).

R by-product of this step are design concepts that can be used in system

definition.

D. The configurations were evaluated and ranked according to the set of

criteria presented in Section 4. The result of the ranking was a figure of

merit that indicated which technologies were best suited to meet the

buffering design characteristics.

15-10
E. Perform a sensitivity analysis. After ranking the options, a sensitivity

analysis was done to identify tradeoffs that can be made that influence the

choice of option/configuration and design characteristics. The sensitivity

analysis also identified major discriminators between the options and

supports technology recommendations.

The approach that was taken for the short term archiving trade consists of the

following:

A. Fully characterize the options to be traded. This has was done and

documented as part of Task 2.

B. Derive the requirement for customer data archiving. This was done by

simply integrating the mission set data rates over the appropriate time

period. The requirement was refined as the mission set was modified.

C. The options were evaluated and ranked according to the set of criteria

presented in Section 4. The result of the ranking was a figure of merit

that indicated which technologies were best suited to meet the short term

archiving requirement.

D. Perform a sensitivity analysis. After ranking the options, a sensitivity

analysis was done to identify tradeoffs that can be made that influence the

choice of options and design characteristics. The sensitivity analysis

also identified major discriminators between the options and supports

technology recommendations.

The approach that will be taken ?or the on-board data base trade consists o?

the following:

A. Fully characterize the options to be traded. This was done and documented

as part of Task 2.

B. Derive the design characteristics for driving on-board data base

applications. This depended on the results from the on-board system

definition activity. Preliminary characteristics have been developed and

are presented in Section 2.

I_11
C. The options were evaluated and ranked according to the set of criteria

presented in Section 4. The result of the ranking was a figure of merit

that indicated which technologies were best suited to meet the on-board DMS

mass store requirement.

D. Perform a sensitivity analysis. After ranking the options, a sensitivity

analysis was done to identify tradeoffs that can be made that influence the

choice of options and design characteristics. The sensitivity analysis

also identified major discriminators between the options and supports

technology recommendations.

7. Trade Study Discussion and Results

On-Board Space Station Communication Data Buffer

Space station missions can be divided into two categories; high data rate

missions and low data rate missions. For the purpose of this trade study,

high data rate missions are those with a peak data rate in excess of 10

Mbits/sec. The low data rate missions are those with a peak data rate less

than or equal to 10 Mbits/sec. In the on-board space station payload data

communication buffer model shown in figure 5 it can be seen that there are two

data buffers used to buffer the communication data. These two buffers are the

high rate data buffer and the payload local area network (PLAN) communication

data buffer.

1_12
I

Data,

Moding,

Control

I_owI

I Rata I

I Mi==°nsI

Payload Local Area Network (PLAN)

IM°I

I

t_,ol

I Moding,

Control

I._. I

I Rate I

I Col

Noq

Gal

p

n L TDRSS

KSA

ray _,m m,_ 1

Data I

I

Point to Point Link I

1

Communication Subsystem

1

Figure 5. On-Board Space Station Payload Data Communication Buffer Model

15-13
High Rate Data Buffer

If the communication resource is not available the high rate data must be

buffered in the high rate data buffer. This buffer is a resource that must be

scheduled in advance. R simulation of the end-to-end model indicates the

design characteristics for the high rate data buffer to be:

Capacity:

Transfer Rate:

BER:

Environment:

Size,Wt.,Pwr.:

Shock & Vib.:

Radiation:

2 X lollBits

In: 300 Rbits/sec

Out: 600 Mbits/sec

< 10-6

Inside space station, 28.5 ° Orbit For I10 Years

TBD, Space Flight Constrained

Non-operating Launch Survivable

230 Rads/year

Assuming two KSR channels can be available

The device options for the high rate data buffer are:

1. Magnetic Tape

2. Magnetic Disk

3. Optical Disk

4. Magnetic Bubble

Magnetic Tape

The high rate buffer design characteristics could be met by one magnetic tape

device, or several magnetic tape devices in the proper configuration.

Rlthough magnetic tape is serial access it is still quite versatile. Data can

be recorded at one rate and played back at another. The media can be removed

from the device and transported to the ground via STS when extra data security

is needed or sufficent TDRSS bandwidth is not available. Magnetic tape is

also a mature mass storage device that has been used in space missions since

the start of the space program.

1_14
Even though the design characteristics for the high rate buffer can be

implemented using only one magnetic tape device it is more desirable to use an

arrangement consisting of three magnetic tape devices. The advantages of the

three device arrangement over a single device include:

1. Simultaneous record and playback

2. Redundancy that improves system reliability

3. Less Sophisticated device (don't have to push the technology as hard)

4. Modularity that enhances growth capability

The three device high rate buffer system would have the following

characteristics:

Capacity :

Transfer Rate:

Device Type:

BER:

Rad Hardness

Volume

WQight

Power

Recurring Cost

Risk

Reliability

Raintainability

2 X 1011 Bits/system

6.6 X 1010 Bits/device

300 Mbits/sec/device

Rotary

-8

10 /device

Good

10,000 Inches3/system

300 Lbs/system

500 Watts Peak/system

$750,000/sy stem

Low

Proven High Reliability

Moderate Maintenance Required

All costs are relative for similar ?light_ualified devices on the

assumption that space qualification cost is a constant factor times the

device cost. This was done so that all the options can be compared at the

same level.

The limitations of using magnetic tape include:

1. Magnetic tape is serial access

2. Future technology insertion of a random access device is constrained

3. Moving parts that are less reliable than that of solid state devices

1_15
_netic Disk

R high rate data buffer designed using the projected space qualified magnetic

disk devices would have the following characteristics:

Capac i ty :

Number of devices:

Transfer Rate:

BER

Peak power:

Recurring Cost#:

Volume:

Weight:

Development Risk:

Radiation Hardness:

Reliability:

Maintenance:

2 X 1011 Bits/system

3X109 Bits/device

67

20 Rbits/sec/device

10 -B

13,400 watts/system, 200 Natts/device

$751,212/system

3

40,200 inches /system

3350 lbs/system

I_edium

Good

Consistent with a device with moving parts

Extensive

Cost does not include space qualification cost

R single magnetic disk device cannot meet the transfer rate design

characteristic. It is questionable that a method of paralleling the devices

together to achieve the transfer rate design characteristic can be devised.

Also, the weight and power characteristics quickly rule out the use of

magnetic disk as the high rate data buffer.

Eraseable Optical Disk

Eraseable optical disk is a relativly new technology that has most of the

characteristics that would make it a candidate for the high rate data buffer.

Optical disk devices have high capacity and fast data transfer rates.

Currently they are non-erasable, which would make them unsuitable for use in

the high data turnover application o? data buffering. Techniques have been

developed and demonstrated that would give the optical disk eraseability. RCA

is one company that has been doing extensive work in the optical disk field.

They currently have two non-eraseable optical disk jukeboxes installations;

one at Langley Research Center and the other at Rome Air Development Center.

15-16
RCA has proposed an "Optical Disk Buffer" that would employ an eraseable

_neto-optic technique to produce a buffer that would have a large capacity

and fast data transfer rate in a relativly small package. The "Optical Disk

Buffer" would have the following characteristics:

Capacity:

Transfer Rate:

Power:

Volume:

Weight:

Recurring Cost :

Radiation Hardness:

Risk:

Reliability:

Maintainability:

1012 Bits •

1000 Mbits/sec

500 Watts Rverage

61,000 Inches 3

700 lbs

TBD (R Price model indicates $10,000,000

for a space qualified device)

TBD (Should be good)

Medium High

Consistent with a device with moving parts

TBD

Price does include space qualification cost

Because eraseable optical disk is a new technology the development risk is

much higher than that of magnetic tape, but the technology for the "Optical

Disk Buffer" has been demonstrated in the lab, and with the proper funding the

device can be developed and ready for use in the 1992 space station.

15,17
Bubble Memory

R high rate data buffer designed using magnetic bubble memory would have the

following characteristics:

Capacity:

Device Count:

Transfer Rate:

Number of Devices Needed To

Achieve Design Characteristic

Transfer Rate:

BER:

Peak Power:

Neight:

Volume:

Cost :

Development Risk:

Radiation Hardness:

Reliability:

Maintainability

2 X 1011 Bits/system

16X106 Bits/device

12,500

400 Kbits/sec/device

750

10-14

8 watts/device

> 6000 watt at 300 Mbits/sec

2,500 lbs/system

75,000 Inches3/system

$1,250,OOOlsystem

Medium

TBD (depends on current development

efforts)

Very Good (solid state device)

Moderate, modular replacement of devices.

Rs with magnetic disk, it would take too many of the magnetic bubble devices

to construct the high rate data buffer. The system cost, weight, volume, and

power would be far too much.

On-Board Space Station Hiqh Rate Buffer Results

After assessing the various options to see how well they would fit into the

space station high rate buffer the options were ranked from one to ten (ten

being best) for each criterion. Table 6 presents the results of the

rankings. Magnetic disk and magnetic bubble are not qualified for use as the

space station high rate buffer because of poor physical characteristics. This

leaves magnetic tape and optical disk as candidates for the space station high

rate buffer.

15-18
IOPTIONS

CRITERIA WEIGHT IMAGNETIC IMAGNETIC IOPTICRL IMAGNETIC

ITAPE TOTRLIDISK TOTAL IDISK TOTAL IBUBBLE TOTAL

COST

DEVELOPMENT: 4

RECURRING: 5

MEDIA: 1

DEVL. RISK: 15

GRONTH

EXTENDABLE: 7

INSERTABLE: 8

10 40

9 45

7 7

10 150

9 63

8 64

RAM

RELIABILITY : 5 I 7 35

AVAILABILTY : 5 9 45

MAINTAINABILITY : 5 7 35

PHYSICALS

WEIGHT: 5

POWER: 10

ENVIRONMENT

RAD HARDNESS: 5

SHOCK & VIB: 5

PERFORMANCE

CAPACITY: 4

TRANSFER RATE: 5

BER: 4

ACCESS TIME: 2

SPECIAL: 5

10 50

10 100

9 45

9 45

10 40

8 40

8 32

6 12

0 O

8 32

8 40

10 10

9

8

10

8

7

8

3

4

135

56

80

40

35

40

15

40

45

35

6 24

4 20

9 36

8 16

7 35

7 28

6 30

8 8

9

8

10

105

49

72

45

4O

5O

40

90

45

40

9 36

10 50

7 28

10 20

10 5O

9 36

7 35

9 9

10

7

10

10

9

6

10

120

70

56

50

50

45

20

30

30

50

7 28

6 30

10 40

9 18

6 30

I I I I

TOTALS zoo l e4e I 734 I 826 I 747

TABLE 6: ON-BOARD SPACE STATION HIGH RATE BUFFER

15-19
The most significant discriminators between magnetic tape and optical disk are:

1. Development Risk

2. Special Considerations

Ragnetic tapQ is a mature mass storage device that has been used since the

start of the space program. Today it is still used almost exclusively for

spaceborn mass data storage. If magnetic tape is selected to be used as the

space station high rate data buffer the major development effort will be in

pushing the data rate up to 300 Rbits/sec. This data rate can be met with the

longitudinal recording method at the expense of power and weight, or the data

rate can be met with the newer, not as mature, rotary recording method.

Random access and a capability to simultaneously record and playback several

channels of high ratQ data are the optical disk's main advantages. This

eliminates bit reversal problems asssociated with some magnetic tape

techniques. The development risk of an optical disk high rate buffer is

high. The major techniques involved with the magneto-optic technique that

this buffer would use have already been demonstrated, but a lack of funding

has slowed down the development effort. If proper funding is supplied up

front, the development risk for the optical disk buffer could go down

considerably. Some of the potential payoffs for doing this include:

1. R buffering device with random access

2. No need to incur the extra cost of inserting the optical disk

technology at a later date.

3. Improved performance o? the buffering system over magnetic tape.

Space Station High Rate Buffer Recommendations

It is recommended that advanced development efforts be focused on eraseable

optical disk technology for this buffering application to reduce the perceived

risk associated with this option. With sufficient emphasis this technology

could be demonstrated and considered for the IOC configuration. If such

emphasis is not provided, magnetic tape provides a mature base for IOC,

however, eraseable optical disk development should continue for insertion into

the growth space station because of the benefits it can provide.

1_20
Space Station Payload Local Area Network (PLAN) Communication Data Buffer

An estimate of the design characteristics for the PLAN communication data

buffer was obtained by buffering the total average data rate of all the low

rate missions for one orbit. The sum of all the IOC low rate missions,

including the co-orbitin_ platform mission, is 2.175 Mbits/sec. Integrating

that over one 90 minute orbit results in the need to buffer 12 x 109 bits of

data. The full design characteristics for the PLAN communication data buffer

are :

Capacity:

Transfer Rate:

BER:

Environment:

Size, Wt., Pwr.:

Shock & Vib.:

Radiation:

12 X 109 bits

I0 Mbits/second

< 10 -6

Inside space station, 28.5 ° orbit for J i0 years

TBD, space flight constrained

Non-operating launch surviable

230 Rads/year

The device options for the PLAN communication data buffer are:

1. Magnetic Tape

2. Magnetic Disk

3. Optical Disk

4. Bubble Memory

1_2t
Magnetic Tape:

The PLAN communication data buffer can be built with present technology. An

Odetics DDS-6000 Spacelab magnetic tape recorder is one example of a space

qualified device that could meet the design characteristics of the PLRN

communication data buffer. The specifications for the DDS-6000 are:

Capacity: 3.84 X 1010 bits

Transfer Rate: 32 Mbits/second

-6

BER: 10

Device Type: Longitudinal

Rad Hardness: Good

Shock & Vib.: Space Qualified

Weight: 105 ibs

3

Volume: 4000 inches

Power: 174 Watts Peak

Recurring Cost: $1,500,000

Development Risk: Low

Reliability: Good

Maintainability: Moderate maintenance required

Cost for Space qualified device only

The device presented above has good performance figures, but because it is a

serial access device, the buffer would have to operate as a first in, first

out type of device thus preventing an implementation of a priority

transmission scheme.

15-22
Magnetic Disk

A PLAN communication data buffer designed with projected magnetic disk

capabilities would have the following characteristics:

Capacity:

Transfer Rate:

# of Devices:

BER

Volume:

Weight:

Power:

Recurring Cost:

Development Risk

Reliability:

Maintainability:

12 X 109 bits/system

20 Mbits/second/system

4

< 10 -10

3

2400 inches /system

200 lbs/system

800 Watts Peak/system

$44,400/system

Medium

Consistent with a non-solid state device

Moderate maintenance required

The projected magnetic disk device has good performance figures, but it also

has a high power requirement.

Optical Disk

If development of the "Optical Disk Buffer" proceeds as recommended in the

section on the on-board space station high rate buffer then a smaller capacity

optical buffer could be developed out of the same program for use as the PLAN

communication data buffer. The characteristics of such a buffer could be:

Capacity:

Transfer Rate: '

Power:

Volume:

Weight:

Cost :

Rad Hardness:

Development Risk:

Reliability:

Maintainability:

B X 1010 bits

100 Mbits/sec

200 Watts average

5100 inches 3

200 lbs

TBD (rough order of magnitude: $1,000,000)

TBD (good)

Medium high

Consistent with a device with moving parts

TBD

Price doe____ssinclude space qualification cost.

1623
Because eraseable optical disk is a new technology, the development risk is

much higher than that of magnetic tape, but the technology for the "Optical

Disk Buffer" has been demonstrated in the lab, and with proper funding the

device can be developed and ready for use in the 1992 space station.

Bubble Memory

A PLAN communication data buffer designed using magnetic bubble would have the

following characteristics:

Capacity:

Transfer Rate:

Number of devices needed to

achieve transfer rate:

Power:

Weight:

Volume:

#

Recurring Cost :

Development Risk:

Rad Hardness:

Reliability:

Maintainability:

12 X 109 bits

10 Mbits/second

25

8 Natts/device Peak

• 200 Watts/system at 10 Rbits/sec

150 lbs

4500 inches 3

$75,000

Medium

TBD (depends on current development effort)

Very good (solid state device)

Moderate, Modular replacement of devices

does not include space qualification cost

Bubble memory has good characteristics in all but one area, radiation

hardness. Current bubble memory support electronics use a

Metal-Oxide-Semiconductor technology that is not radiation hard. The USRF

currently has a development program to produce a space qualified chip set that

may have potential application in space.

Space Station PLAN Communication Data Buffer Results

After assessing the various options to see how well they would fit inte the

space station PLAN communicaion data buffer, the options were ranked from one

to ten (ten being best) for each criterion. Table 7 presents the results of

the ranking.

15-24
All of the candidate options are capable of serving as the space station PLAN

communication data buffer. The major discriminators between the options are:

I. Cost

2. Development Risk

3. Power Requirements

4. Performance

5. Special Considerations

Magnetic tape is the most mature of the options, thus it has a lower cost and

development risk. Sequential access is a major drawback to the use of

magnetic tape as a data buffer. Because of the sequential access

characteristic a priority transmission of buffered data scheme is not possable.

Magnetic disk has adequate performance and growth potential, but unless unless

its power requirements can be lowered it should not be considered as an option

for the PLAN communication buffer.

Optical disk has very good performance figures. It offers excess capacity on

the order of 7.6 times the desired design characteristic, thus giving plenty

of capacity for use in the growth configuration. A special consideration is

the random access characteristic of optical disk thus providing improved

performance and the ability to implement a scheme to have priority

transmission of buffered data.

Eraseable optical disk has a high development risk because it is an emerging

technology, but the technology has been demonstrated in the laboratory with

promising results. The development risk and cost will be reduced if the PLAN

communictaion data buffer and the space station high rate data buffer share

the same optical disk development effort. By sharing the development effort

the risk could be significantly reduced because of the increased funding that

could be available. This shared development effort can also lead to device

commonality that would further reduce overall costs.

1625
IOPTIONS

CRITERIA WEIGHT IMAGNETIC IMAGNETIC IOPTICAL IMAGNETIC

ITAPE TOTALIDISK TOTAL IDISK TOTAL IBUBBLE TOTAL

COST

DEVELOPMENT: 4

RECURRING: 5

MEDIA: 1

DEVL. RISK: 15

GRO(4"FH

EXTENDABLE: 7

INSERTABLE: 8

RAM

RELIABILITY : 5

AVAILABILTY : 5

MAINTAINABILITY : 5

PHYSICALS

WEIGHT 5

POWER: 10

ENVIRONMENT

RAD HARDNESS: 5

SHOCK & VIB: 5

PERFORMANCE

CAPACITY: 4

TRANSFER RATE: 5

BER: 4

ACCESS TIME: 2

SPECIAL: 5

10 40

10 50

7 7

10

9

7

8

7

8

10

10

9

9

150

63

56

4O

35

40

50

100

45

45

9 36

9 45

8 32

6 12

0 0

8 32

9 45

10 10

135

56

72

35

40

35

40

70

45

35

7 28

8 40

9 36

8 16

7 35

7 28

7 35

8 8

7

10

9

10

9

105

49

80

45

5O

45

40

90

45

40

10 40

10 50

7 28

10 20

10 5O

9 36

8 40

9 9

8

10

8

10

9

10

9

8

6

10

120

70

64

50

45

50

45

8O

30

50

6 24

6 30

8 32

9 18

6 30

I I I I I

TOTALS ZOO1 846 I 8051 e4e I 823 I

,TABLE 7: ON-BOARD SPACE STATION PLAN COMMUNICATION DATA BUFFER

15-26
Bubble memory has a good figure of merit, but it falls short in the areas of

performance and radiation hardness. A current Air Force development program

might give the bubble memory potential for use this applications.

Space Station PLAN Communication Data Buffer Recommendations

It is recommended that advanced development efforts be focused on eraseable

optical disk technology for this buffering application to reduce the perceived

risk associated with this option. Furthermore, this development effort should

be part of the same development effort that is recommended for the space

station high rate data buffer. This will reduce overall development cost and

increase optical disk development funding that would tend to further reduce

the eraseable optical disk development risk.

If the eraseable optical disk development does not proceed as recommended,

magnetic tape can be brought into the IOC configuration at a later date

because of it's maturity. However, optical disk development should continue

for insertion into the growth space station because of the benefits it can

provide.

1_27
On-Board Polar-Orbit Platform (POP) Communication Data Buffer

R simulation of the end-to-end model indicates the design characteristics for

the worst case POP data buffer to be:

Capacity:

Transfer Rate:

BER:

Environment:

Size,Wt.,Pwr.:

Shock & Vib.:

Radiation:

5.1X 1011Bits

300 Mbits/sec

< 10-6

On POP 90 ° Orbit For 110 Years

TBD, Space Flight Constrained

Non-operating Launch Survivable

2K - 25k Rads/year

The device options for the POP data buffer include:

1. Magnetic Tape

2. Magnetic Disk

3. Optical Disk

4. Magnetic Bubble

Magnetic Tape

The POP buffer design characteristics could be met by one magnetic tape

device, or several magnetic tape devices in the proper configuration.

Rlthough magnetic tape is serial access it is still quite versatile. Data can

be recorded at one rate and played back at another. Magnetic tape is also a

mature mass storage device that has been used in space missions since the

start of the space program.

Even though the design characteristics for the POP buffer can be implemented

using only one magnetic tape device it is more desirable to use an arrangement

consisting of three magnetic tape devices. The advantages of the three device

arrangement over a single device include:

I_2B
I. Simultaneous record and playback

2. Redundancy that improves system reliability

3, Less Sophisticated device (don't have to push the technology as hard)

4. Modularity that enhances growth capability

The three device POP buffer would have the following characteristics:

Capacity:

Transfer Rate:

Device Type:

BER:

Rad Hardness

Volume

Weight

Power

Recurring Cost

Risk

Reliability

Maintainability

5.1X 1011 Bits/system

1.7 X 1011 Bits/device

3OOMbits/sec/device

Rotary

10-8/device

Good

10,0OO Inches3/system

300 Lbs/system

5OOWatts Peak/system

$750,OO0/system

Low

Proven High Reliability

Moderate Maintenance Required

Most costs are for similar flight-qualified devices on the assumption that

space qualification cost is a constant factor times the device cost. This

was done so that all the options can be compared at the same level.

The limitations of using magnetic tape include:

1. Magnetic tape is serial access

2. Future technology insertion of a random access device

3. Moving parts that are less reliable than that of solid state devices

15-29
P_netic Disk

A POP data buffer designed using the projected space qualified magnetic disk

device would have the following characteristics:

Capacity:

Number of devices:

Transfer Rate:

BER

Peak power:

#

Recurring Cost :

Volume:

Weight:

Development Risk:

5.1X 1011 Bits/system

3X109 Bits/device

170

20 Mbits/sec/device

10 -8

34,000 watts/system, 200 Watts/device

$1,906,000/system

3

102,000 inches /system

8500 lbs/system

Medium

Radiation Hardness: Good

Reliability: Consistent with a device with moving parts

Maintenance: Extensive

Cost does not include space qualification cost

R single magnetic disk device cannot meet the transfer rate design

characteristic. It is questionable that a method of paralleling the devices

together to achieve the transfer rate design characteristic can be devised.

Also, the weight and power characteristics quickly rule out the use of

magnetic disk as the POP data buffer.

Eraseable Optical Disk

Eraseable optical disk is a relativly new technology that has most of the

characteristics that would make it a candidate for the POP data buffer.

Optical disk devices have high capacity and fast data transfer rates.

Currently they are non-erasable, which would make them unsuitable for use in

the high data turnover application of data buffering, but techniques have been

developed and demonstrated that would give the optical disk eraseability. RCR

is one company that has been doing extensive work in the optical disk field.

They currently have two optical disk jukeboxes installations; one at Langley

1_30
Research Center a_ the other at Roe Air Development Center. RCA has

proposed an "Optical Disk Buffer" that would employ a magnet_ptic technique

to produce a buffer that would _ve a large capacity and fast data transfer

rate in a relativly small package, The "Optical Disk Buffer" would have the

foll_i_ characteristics:

Capacity:

Transfer Rate:

Power:.

Volume:

Weight:

Cost:

Radiation Hardness:

Risk:

Reliability:

f_aintainability:

1012 Bits

lO00Mbits/sec

500 kkatts Average

61,000 Inches 3

700 lbs

TBD (A Price model indicates $10,000,000

for a space qualified device)

TBD (Should be good)

Medium High

Consistent with a device with moving parts

TBD

Because eraseable optical disk is a new technology the development risk is

much higher than that of magnetic tape, but the technology for the "Optical

Disk Buffer" has been demonstrated in the lab, and with the proper funding the

device can be developed and ready for use in the 1992 Space Station Program,

1_31
Bubble Memory

A POP data buffer designed using magnetic bubble memory would have the

following characteristics :

Capacity:

Device Count:

TransferRate:

Number of Devices Needed To

Achieve Design Characteristic

Transfer Rate:

BER:

Peak Power:

Weight:

Volume:

Cost :

Development Risk:

Radiation Hardness:

Reliability:

Maintainability

5.1X 1011 Bits/system

16X106 Bits/device

31,875

400 Kbits/sec/device

750

10-14

8 watts/device

6000 watt at 300 Mbits/sec

6375 lbs/system

191,250 Inches3/system

$3,187,000/system

High

TBD (depends on current development

efforts)

Very Good (solid state device)

Moderate, modular replacement of devices.

As with magnetic disk, it would take too many of the magnetic bubble devices

to construct the POP data buffer. The system cost, weight, volume, and power

would be far too much.

On-Board POP Communication Data Buffer Results

After assessing the various options to see how well they would fit into the

POP communication data buffer the options were ranked from one to ten (ten

being best) for each criterion. Table 8 presents the results of the ranking.

Magnetic disk and magnetic bubble are not qualified for use as the POP

communication data buffer because of poor physical characteristics. This

leaves magnetic tape and optical disk as candidates for the POP communication

data buffer.

1_32
I OPTIONS

CRITERIA WEIGHT 1MAGNETIC IMAGNETIC IOPTICAL IMAGNETIC

ITAPE TOTRLIDISK TOTAL IDISK TOTAL IBUBBLE TOTAL

COST

DEVELOPMENT: 4

RECURRING: 5

MEDIA: 1

DEVL. RISK: 15

GROWTH

EXTENDABLE: 4

INSERTABLE: 6

RAM

RELIABILITY : 8

AVAILABILTY : 5

MAINTAINABILITY : 2

PHYSICALS

NEIGHT: 6

POWER: 9

ENVIRONMENT

RAD HARDNESS: 10

SHOCK & VIB: 5

PERFORMANCE

CAPACITY: 4

TRANSFER RATE: 5

BER: 4

ACCESS TIME: 2

SPECIAL: 5

10 40

9 45

7 7

10 150

9 36

8 48

7 56

7 35

9 18

10 60

10 90

9 90

9 45

10 40

9 45

8 32

6 12

0 0

8 32

8 40

10 10

9

8

10

135

32

60

64

40

14

3 18

4 36

9 90

7 35

6 24

4 20

9 36

8 16

7 35

7 28

6 30

8 8

9

10

8

8

9

9

8

105

28

54

72

50

16

48

81

90

40

9 36

10 50

7 28

10 20

10 50

9 36

7 35

9 9

10

7

10

9

10

4

3

6

10

120

40

42

80

45

20

24

27

60

50

7 28

6 30

10 40

9 18

6 30

I I I I I

TOTALS 1001 849 I 737 I 834 I 734 I

TABLE 8: ON-BOARD POLAR--ORBIT PLATFORM COMMUNICATION DATA BUFFER

15-33
ThQ _st significant discriminators between magnetic tape and optical disk are:

I. Development Risk

2. Special Considerations

Magnetic tape is a mature mass storage device that has been used since the

start of the space program. Today it is still used almost exclusively for

spaceborn mass data storage. If magnetic tape is selected to be used as the

space station high rate data buffer the major development effort will be in

pushing the data rate up to 300 Mbits/sec.

Random access and a capability to simultaneously record and playback several

channels of high rate data are the optical disk's main advantages. This

eliminates bit reversal problems asssociated with some magnetic tape

techniques. The development risk of an optical disk high rate buffer is

high. The major techniques involved with the magneto-optic technique that

this buffer would use have already been demonstrated, but a lack of funding

has slowed down the development effort. If proper funding is supplied up

front, the development risk for the optical disk buffer could go down

considerably. Some of the potential payoffs ?or doing this include:

I. R buffering device with random access

2. No need to incur the extra cost of inserting the optical disk

technology at a later date.

3. Improved performance of the buffering system over magnetic tape.

POP Communication Data Buffer Recommendations

It is recommended that advanced development efforts be focused on eraseable

optical disk technology for this buffering application to reduce the perceived

risk associated with this option. Furthermore, this development effort should

be part of the same development effort that is recommended for the space

station high rate data buffer. This will reduce overall development cost and

increase optical disk development funding that would tend to further reduce

the eraseable optical disk development risk. If the eraseable optical disk

development does not proceed as recommended, magnetic tape can be brought into

the IOC configuration at a later date because of it's maturity. However,

optical disk development should continue for insertion into the growth Space

Station Program because of the benefits it can provide.

I_34
Data Handlinq Center Buffer

The data handling center buffer will need to buffer data coming from the TDRSS

KSA communication links at rates up to 900 Rbits/second. A computer

simulation of the end-to-end model determined that it is necessary to buffer

1012 bits of high rate data. Assuming TDRSS uses three KSA links evenly, a

separate buffer with a capacity of 3.3 X I0 II bits and a transfer rate of

300 Mbits/sec will be allocated for each TDRSS KSA link. Therefore the design

characteristics for a common TDRSS KSA buffer will be:

3.3 X 1011 bits capacity

300 Mbits/second transfer rate

BER < 10 -6

The options for the data handling center buffer are:

1. Magnetic Tape

2. Magnetic Disk

3. Optical Disk

Magnetic Tape

To design the data handling center buffer using magnetic tape would require a

configuration of three magnetic tape devices per KSA link. One device to

record, one device to playback, and one device would be in between the two

operations. The characteristics of such a device should include:

1. 110 Gbits capacity

2. Data transfer rate of up to 300 Mbits/second

3. Variable playback rate.

It is predicted that such a high performance device can be built and would

carry a price tag of over I million dollars each. In this scheme all data

would be processed first in first out, thus not allowing any priority level 0

processing on the ground. Over the full range of criteria magnetic tape

appears to be a good candidate for the data handling center buffer.

1_35
Magnetic Disk

Because of the requirement to record at 300 Mbits/sec magnetic disk might not

be able to be used as the data handling center buffer. Predicted magnetic

disk devices will only achieve a transfer rate of around 40 Mbits/sec. The

only way magnetic disk could be used is if the data is split into manageable

streams around 40 Mbits/sec. This is possible if real time processing to

split the data into streams of complete packets is done as the data is

received from the TDRSS KSA link. To buffer the expected 330 Gbits of data

would require 10 devices with a capacity of 33 Gbits each. The total cost for

these 10 device would be approximately 1 million dollars.

Optical Disk

The RCA "Optical Disk Buffer" proposed for the on-board space station data

buffer would also have use in the data handling center buffer application.

The "Optical Disk Buffer" characteristics of 1012 bits capacity and and

I09 bitslsec transfer rate make the "Optical Disk Buffer" an ideal candidate

for the data handling center buffer. Drawbacks to the use of the eraseable

optical disk buffer include a high development risk because of the newness of

the technology. This risk can be brought down if the "Optical Disk Buffer" is

developed for both the on-board space station buffer application and the data

handling center buffer application. This would happen because additional

development funding could be supplied to support this common capability.

Data Handlinq Center Results

Rfter assessing the various options to see how well they would fit into the

data handling center buffer application the options were ranked from one to

ten (ten being best) for each criterion. Table 9 presents the results of the

ranking. Execept for magnetic disk in transfer rate and magnetic tape in

access time, all three options scored well in all criteria.

Magnetic tape scored well in the criteria of cost and development risk. The

access time to data should not pose a problem if a first in, first out

buffering scheme is used. R priority processing scheme is not possible with

magnetic tape.

;_36
IOPTIONS I

I

CRITERIA WEIGHT IMAGNETIC IMAGNETIC IOPTICAL I

ITAPE TOTALIDISK TOTAL IDISK TOTAL I

COST

DEVELOPMENT: 4

RECURRING: 10

MEDIA: 1

DEVL. RISK: 15

GROWTH

EXTENDABLE: 12

INSERTABLE: B

RAM

RELIABILITY: 5

AVAILABILTY: 10

MAINTAINABILITY: 5

PERFORMANCE

CAPACITY: 8

TRANSFER RATE: 9

BER: S

ACCESS TIME: 3

SPECIAL: 5

10 40

10 100

8 8

10 150

10 120

9 72

8 40

8 80

10 50

9 72

9 81

9 45

6 18

0

9 36

B 80

10 10

9

9

10

9

9

8

135

108

80

45

90

40

B 64

6 54

10 50

9 27

8 40

10

10

9

7 28

9 90

9 9

8 120

96

64

50

100

45

10 80

10 90

8 40

10 30

10 50

I I I I

TOTALS 1001 876 I 859 I 892 I

TABLE 9: DATA HANDLING CENTER BUFFER

15-37
Magnetic disk scored good marks in all criteria except transfer rate, This

could be a problem if real time splitting of the data into 40 Mbit/sec data

streams is not possible.

Optical disk has the best figure of merit. It scored well in the performance

and RAM criteria. Development risk is a major discriminator against optical

disk. I? optical disk is developed in parallel for both the data handling

center and on-board space station high rate buffer applications the

development risk could be significantly reduced because of the added

development funding it could receive.

Dat_ Handlinq Center Buffer Recommendations

It is recommended that advanced development efforts be focused on optical disk

technology ?or buffering applications to reduce the perceived risk associated

with this option. The development risk is further reduced by parallel

development of the optical disk buffer for both the space station on-board

buffer and the data handling center buffer applications. With sufficient

emphasis this technology could be demonstrated and considered for the IOC

configuration. If the optical disk development does not proceed as

recommended, magnetic tape should be as the IOC option because of its

maturity. However, optical disk development should continue for insertion into

the growth configuration of the data handling center buffer application.

Magnetic disk is not recommended as an option for the data handling center

buffer applications because of the problems assocated with trying to split the

TOR$S KSA link into 40 Mbits/sec stream. Splitting of packets into the

separate streams is the most major of these problems.

15-38
Short Term Customer Data Rrchive

Requirements ?or a centralized short term archive were developed by

integrating the mission set average data rate over the appropriate period for

both IOC and growth. The results from this analysis are shown below and range

from the I0C amount to the growth amount.

12 Hour On-line Storage

110 - 179 Mbits/sec average rate

5 - 8 X 1012 bits capacity

60 second access time (desired)

7 day off-line storage

110 - 179 Mbit/sec average transfer rate

7 - 10 X 1013 bits capacity

Less than 24 hours access time

The options to be considered for the short term archive are:

1. Magnetic Tape

2. Magnetic Disk

3. Optical Disk

Magnetic Tape

R short term archive designed with magnetic tape devices can meet the capacity

and transfer rate requirements, but there are problems that would arise from

using magnetic tape that include:

1. R long access time because of magnetic tapes sequential access

characteristic. The access time can be improved if shorter tapes with less

capacity are used but the tradeoff would be additional devices to make up

the capacity requirement. The cost of such an arrangement, assuming tape

drives with a capacity of 1011 bits, would be in excess of 50 million

dollars. This would be a costly solution to the access time problem of

magnetic tape.

15_39
2. A magnetic tape solution to the short term archive would require many

man-hours of labor to do such things as remove and replace tapes from the

drives, degauss and inspect the tapes, and monitor the system.

3. Access contention could be a problem if two users data are on the same

magnetic tape and they request their data at the same time.

Even though magnetic tape archives exist now it is not recommended that

magnetic tape be used in this application. The major reason for this is the

problems caused by the sequential access characteristic of the magnetic tape

devices.

Raqnetic Disk

Ragnetic disk provides the random access characteristic that is needed to meet

the access time requirement, but it fails to provide the necessary transfer

rate. This problem can be worked around by splitting the data into streams of

a manageable 40 Mbits/sec. To meet the capacity requirement would require

about 140 drives, at a cost of $100,0OO per drive. This amounts to 14 million

dollars in hardware. Assuming these devices have removable disk packs that

store 35 Gbits apiece, it would take about 2900 disk packs, at $900 each to

meet the 7 day capacity requirement. That amounts to a media cost of 2.6

million dollars. Because of the above reasons, it is not recommended that

magnetic disk be used for the short term archiving applications.

Optical Disk

Write once optical disk provides the capacity, transfer rate, and random

access needed for the short term archive. R currently operating RCR "Optical

Disk 3ukebox" installed at Marshall Space Flight Center has the following

characteristics:

Storage for 1013 bits

50 Mbitlsec transfer rate

5.5 second random access to any information

Approximately $2,000,000 recurring cost

I_40
The characteristics of the optical disk jukebox are very close to the 12 hour

on-line archiving requirements, thus makir_j the optical disk jukebox concept a

very attractive candidate for use as the short term archive. Major advantages

to using the optical disk jukebox include:

I. Meet the on-line capacity requirement in one device.

2. Random access characteristic of optical disk.

3. Lower cost than magnetic tape or magnetic disk.

4. Low development risk. Present device characteristics almost match on-line

requirments

5. Data may be transferred to a permanent archive via removable media.

6. Low media cost.

Low media cost is an advantage optical disk has over other options. It is

predicted in the options development report on mass storage that an optical

disk with a capacity of 533 X 109 bits will cost $30. To meet the seven day

requirement about 190 disks are needed, which amounts to $5700. This is far

less than the 2.6 million dollar media cost for the magnetic disk option.

The present "Optical Disk 3ukebox" is designed to hold 128 disks. R future

"Jukebox" could be designed to hold all of the 190 disks required for the 7

day archive, thus giving the 7 day archive an on-line capability. Rlso RCA

has done a preliminary design of an automated "Optical Disk Library". This

library would use the same optical disks that are used in the "Jukebox" This

would allow the optical disks to be transferred from the "Optical Disk

Jukebox" to permanate storage in the "Optical Disk Library".

Present optical disk transfer rate is too low to meet the requirement of II0

Mbits/sec at IOC and 179 Mbits/sec at growth, but the risk is low that

development efforts will provide the necessary transfer rate.

Short Term Customer Data Rrchivinq Results

Table I0 presents the results of the option ranking for the short term

archiving application. Optical disk is the clear choice for use as the mass

store device for the 12 hour on-line and 7 day off-line customer data

archiving applications. Major discriminators for optical disk and against

magnetic tape and magnetic disk are performance, device cost, and media cost.
IOPTTONS I

I

CRITERIA WEIGHT IMA_ETIC IMAC_ETIC IOPTICAL I

ITRPE TOTALIDISK TOTAL IDISK TOTAL I

COST

DEVELOPMENT: 5

RECURRING: 5

MEDIA: 10

DEVL. RISK: 10

GRONTH

EXTENDABLE: 12

INSERTABLE: 8

RAM

RELIABILITY : 6

AVRILABILTY : 7

MAINTAINABILITY : 7

PERFORMANCE

CAPACITY: 8

TRANSFER RATE: 5

;BER: 5

ACCESS TIME: 7

SPECIAL: 5

10 50

7 35

8 8O

8

5

10

90

96

48

48

35

70

72

45

45

28

0

9 45

6 30

5 50

7

7

7

9

9

8

5

6

10

8

5

70

84

56

54

63

56

40

30

50

56

25

7 35

9 45

10 100

8

10

8

10

10

9

10

10

8

10

10

80

120

64

60

70

63

80

50

40

70

50

I I I I

TOTALS 10OI 742 I 709 I 927 I

TABLE 10: SHORT TERM ARCHIVE

15-42
Optical disk also lends itself for use in a permanent archive. After serving

its purpose in the short term archive, the optical disk may be removed and

placed into a permanent archive. The life span of the optical disk media is

reported to be greater than ten years, five time the life span of magnetic

tape.

Short Term Customer Data Archivinq Recommendation

It is recommended that the optical disk jukebox technology that was developed

for Marshall Space Flight Center and Rome Rir Development Center be used for

short term archiving. Optical disk provides a low cost, low risk method of

archiving the data for a short term, on-line with the possibility of

transferring the media to a permanent archive, thus achieving cost

effectiveness. Development effort should be focused on increasing the data

rate and reducing the media cost.

1_43
On-Board Space Station Data Base Mass Storaqe

For the purpose of this trade study, the IOC on-board space station data base

management system (DBMS) will be sized to provide storage for:

30 Mbytes

50 Mbytes

10 Mbytes

5 Mbytes

5 Rbytes

5 Mbytes

144 Mbytes

Application programs

Telemetry data acquisition

Checkpoints

Engineering data

Procedures

Schedules

Growth marx]in

249 Rbytes Total

The full design characteristics for the on-board DBMS mass store are:

2 x 109 bits capacity

10 Mbit/second transfer rate

40 millisecond access time

-12

TBD BER (because of critical nature: 10 ?)

Inside space station, 28.5 ° orbit for>lO years

Space flight constrained phyisicals

230 Rads/year

The device options for the on-board space station DBMS are:

1. Magnetic Disk

2. Eraseable Optical Disk

3. Magnetic Bubble Memory

4. Semiconductor (CMOS)

Other options such as read only optical disk, write-once optical disk, video

tape, ect. may be used for other non-driving DBMS storage requirements

applications such as entertainment and manual updates.

1644
Magnetic Disk

Present Winchester technology characteristics match the requirements of the

DBMS mass store quite nicely, thus making magnetic disk an attractive

candidate. The mass store designed with projected magnetic disk capabilities

would have the following characteristics:

Capacity: 3 X 109 bits

Transfer Rate: 20 Mbits/sec

BER: < 10 -I0

Rad Hardness: Good

Volume: 600 inches 3

Weight: 50 lbs

Power: 200 watts peak

w

Recurring Cost: $11,000

Risk: Low

Reliability: Good/device

Maintainability: Modular replacement

Growth Potential: High

* Space qualification cost not included

Magnetic disk would provide more than adequate storage capacity and easily

meet all but one of the design characteristics. Magnetic disks low score is

in the area of bit error rate, but with improved techniques or coding schemes

this will not be a problem. Space qualification of magnetic disk devises

should not be a problem as there are ?light qualified devices now available.

Technology expandability and insertability look to be very good.

1645
Optical Disk

R DBMS mass store designed with the same eraseable optical disk technology

discribed for the space station high rate data buffer would have the following

characteristics:

Capacity:

Transfer Rate:

Power:

Volume:

Weight:

Cost :

Rad Hardness:

Development Risk:

Reliability:

Maintainability:

8 X 1010-bits

1OO Mbits/sec

200 Watts average

51OO inches 3

200 lbs

TBD (rough order of magnitude: $1,OOO,OOO)

TBD (good)

Medium high

Consistent with a device with moving parts

TBD

* Price doe__s include space qualification cost.

Because eraseable optical disk is a nc:.,,Jtechnology, the development risk is

much higher than that of magnetic tape, but the technology for the "Optical

Disk Buffer" has been demonstrated in the lab, and with proper funding the

device can be developed and ready for use in the 1992 space station.

15_6
Maqnetic Bubble Memory

R DBMS mass store designed with magnetic bubble memory would have the

following characteristics:

Capacity:

# of devices/subsystem:

Transfer Rate:

BER:

Access Time:

Rad Hardness:

Volume:

Weight:

Power:

Recurring Cost

Risk:

Reliability:

Maintainability:

Growth:

2 X 109 bits/system, 667 Rbits/subsystem

125

10 Mbits/sec/subsystem, 400 Kbits/sec/device

10-14

10 milliseconds

Poor to Good (depends on AF development effort)

3

750 inches /system

25 lbs/system

_600 watts

$12,soo

Medium (depends on AF development effort)

High (solid state device)

Modular replacement

High

The OBMS mass store designed using bubble memory would meet all the

performance requirements. The Air Force has a development effort to produce a

space qualified bubble memory.

Semiconductor; Complementarv_etal-Oxide-Semiconductor (CMOS)

CMOS was selected as the semiconductor candidate for a DBMS mass store because

it has the best capacity/power, capacity/volume, and capacity/weight ratios of

the semiconductor options. R mass store designed with 1Mbit CPK)S memory

would have the following characteristics:

1547
Capac ity :

# of devices used:

Transfer Rate:

8ER:

Access Time:

Rad Hardness :

Volume:

We ight:

Powe r:

Recurring Cost :

Risk:

Reliability :

Maintainabi Iity :

Growth:

2 X 109 bits

20OO

10 Mbits/sec

Very good

1 usec/device

105 Rads total dose

1000 inches 3

100 lbs

Depends on memory system design (around 100 watts)

$62,400

Low

.Very High

Modular Replacement

Low to Medium, system designed to specification.

Semiconductor is a good candidate for use as the DMS mass store because of its

good performance figures, low risk, high reliability, and good physical

specifications. The development cost ?or QMOS is low because o? commercial

demand ?or it in the marketplace. Even though CROS is a volatile memory,

non-volatility can be provided with a battery backup.

On-Board Space Station DRS Mass Store Results

After assessing the various options to see how well they would fit into the

space station DBMS mass store the options were ranked from one to ten (ten

being best) ?or each criterion. Table 11 presents the results of the

ranking. Optical disk, magnetic disk, magnetic bubble memory, and CMOS

semiconductor all are good candidates ?or the space station DMS.

15-48
IOPTIONS

CRITERIA WEIGHT IMAGNETIC IOPTICAL IMAGNETIC ISEMICONDUCTOR

IDISK TOTALIDISK TOTAL IBUBBLE TOTAL ICMOS TOTAL

COST

DEVELOPMENT: 4

RECURRING: 5

MEDIA: I

DEVL. RISK: 15

I

GROWTH

EXTENDABLE: 7

INSERTABLE 8

RAM

RELIABILITY: 6

AVAILABILTY: 5

MAINTAINABILITY: 4

PHYSICALS

WEIGHT: 5

POWER: 10

ENVIRONMENT

RAD HARDNESS: 5

SHOCK & VIB: 5

PERFORMANCE

CAPACITY: 3

TRANSFER RATE: 3

BER: 4

ACCESS TIME: 5

SPECIAL: 5

9 36

9 45

8 8

9 135

10 70

10 80

7 42

8 40

7 28

8 40

9 90

8 40

7 35

10 30

9 2-7

8 32

7 35

2 10

7 28

7 35

7 7

105

63

72

48

45

32

35

80

40

40

10 30

10 30

7 28

8 40

10 50

I

I

8 32 I zo 40,1

10 50 8 40

10 10 9 9

6 9O

8 56

8 64

10 60

7 35

10 40

10

7

7

10

7

7

10

9

50

70

35

50

21

21

40

45

O

8 120

7 49

7 56

9 54

10 50

9 36

9

10

8

10

7

8

9

10

45

tO0

40

50

21

24

36

50

O

TOTALS

I I I I I

zoo l 823 I 824 I 777 I e20 I

TABLE 11: ON-BOARD SPACE STATION DBMS MASS STORE

15-49
The most significant discriminators between the options are:

1. Development Risk

2. Development Cost

3. Reliability

4. Power

5. BER

6. Special Considerations

Magnetic disk provides the needed characteristics in current devices. This is

a major factor in it's favor because it lowers development risk and

development cost. Factors against magnetic disk include: moving parts that

make it more unreliable than a solid state device and a higher bit error rate

than that of a solid state device.

Eraseable optical disk has very good performance characteristics. The

projected characteristics will provide for growth.

Bubble memory meets most of the requirements of the space station DBMS.

Bubble memory would need the most development of the three candidates for the

DBMS and current efforts in bubble memory development are not adequate to make

bubble a low risk option. Bubbles main advantages are in the criteria of

reliability and maintainability.

CPK)S semiconductor is a close second according to the figure of merit. It has

good performance, high tolerance to radiation, low development cost, and low

power requirements. As with magnetic disk, present CMOS devices can be used

to build the DBRS mass store, thus giving CMOS a low development risk. There

are no major factors against the use of CMOS as the DBMS mass store.

Space Station DBMS Mass Store Recommendations

It is recommended that eraseable optical disk be used for both IOC and growth

space station DBMS mass store. Eraseable optical disk provides more than

adequate storage capacity and transfer rate. Eraseable optical disk also

lends itself to growth and modular replacement.

1650
Ragnetic Disk can also meet the design characteristic for the DBMS mass store

requirement and should be used if optical disk development does not take place

as recommended.

CROS semiconductor can also meet the requirements imposed by the DBMS but does

not have the growth capability of magnetic disk. Bubble memory currently has

too high a development risk to be considered for the IOC space station, but

with proper development funding might make a good candidate for use on the

growth space station.

S. Conclusions

Eraseable optical disk, because of its high performance and small size, is the

recommended option For these application areas provided sufficient technology

development and demonstration can be accomplished for IOC-Regardless of the

final IOC configuration this technology should bQ developed for the growth

space station.

1. Space station high rate buffer

2. Space station PLAN communication data buffer

3. PolaP-orbit platfon, data buffer

4. Data handling center buffer

5. Space station DBMS mass store

If the eraseable optical disk devices are developed as recommended, the

perceived development risk associated with this option will lessen. This is

due to the increased development funding that can be supplied while still

holding down overall development cost. The recommended development approach

will bring about commonality between devices and spare parts that will

further reduce costs.

If development does not proceed as recommended then magnetic tape should be

used for all the above application areas except the space station DBMS mass

store, in which case magnetic disk should be used.

Write-once optical disk should be used for the short term archiving

application. The technolo<jy is already being used at Rarshall Space Flight

Center and Rome Air Development Center. It is a low cost, low risk option.

15_51
XVI. COMMAND AND RESOURCE MANAGEMENT

I@1
COMMANDAND RESOURCE MANAGEMENT

TRADE STUDY REPORT

1.0 TRADE STUDY DEFINITION

1.1 Reason for Trade Study

The command and resource management capability provided by the SSDS will be

used extensively by the customer to functionally interact with his payload

from his own institution/facility, including both on-board and ground

elements. This trade study will identify and evaluate five candidate system

designs for command and resource management that represent a spectrum of

attractive concepts.

1.2 Background

The SSDS allocates Command and Resource Management to two major functions:

2.0 Manage Customer/Operator Supplied Data, and 3.0 Schedule and Execute

Operations. A command management and resource management system must be

innovatively improvised to address a wide range of requirements. Requirements

for command management include the following:

o Authenticate Command Sender and Address. (Reference I)

Determine Command Classification (Restricted, Constrained, or

non-restricted). (Reference I)

0 Pass non-restricted commands and data directly to their destination

with no further checking. (Reference I)

0 Determine whether restricted and constrained commands are

executable. (Reference I)

,0 Pass executable, restricted and constrained commands to their

destination at appropriate times. (Reference 1)

I&3 ,_}R_CED_NG PAGE BLAIr,,(_IOT FILMED
o Attempt to resolve problems with not-executable commands. (Derived)

o Return not-executable commands to sender. (Reference l)

Allow customer to be able to cancel any command he initiated.

(Derived)

o Report all command disposition and status to sender. (Reference i)

o Provide for command data privacy. (References 1 & 2)

Process all commands in a manner consistent with customer real time,

interactive operation. (Reference l)

Support generation and real time change of stored command sequences.

(Reference 1)

o Support customer payload commanding. (Reference i)

o Make command entry and resolution user friendly. (Reference I)

Enable customer payload control to be essentially the same as if the

payload were in his own laboratory. (Reference l)

Requirements for resource management functions include the following:

Accept and verify operations requests from customers and station

operators. (Reference l)

o Receive and confirm Major Event requirements from SSP. (Derived)

o Negotiate Communications Requirements with NCC. (Reference i)

Develop an optimum schedule consistent with constraints of power,

crew task selection, communications bandwidth, and non-interfer(_nce

among payloads and Space Station systems. (References 1 & 2)

16..4
0

0

Revise schedule in accordance with changing requirements, priorities,

opportunities, and capabilities. (Reference I)

Hold scheduled commands and dispatch at appropriate time.

(Reference 1)

o Support onboard, near term planning by the crew. (Reference 2)

0 Provide customers and operators data on Space Station resources and

availability. (Reference 1)

0 Provide a single point of contact for customer communication

reallocation requests. (Reference 1)

o Accommodate a phased degree of Space Station autonomy. (Reference 2)

o Make Resource Management user friendly. (Reference 1)

o Ensure customer payload and core system do not interfere with each

other and do not endanger the health and safety of the Space Station

system. (Reference l)

Most of the above listed requirements are contained within the Customer

Requirements for Standard Services (Reference l) and/or Space Station RFP

(Reference 2). Some additional requirements are included as derived from MDAC

analysis,

Communication (especially real time), power,, and crew time have been

identified as being the limiting resources in resource management. A

comprehensive analysis is used to identify preferred system design

characteristics in this area. It is desired to minimize customer requirements

(outside of initiating commands) through provisions for "customer transparent"

checking, scheduling, etc. That is to say, the customer is kept oblivious of

operations not concerning command initiation as much as possible. These

features are to be maximized while drivers such as limiting resources are

accommodated when selecting an optimum system.

16.B
1.3 Candidate System Options

The five systems and their key features to be addressed by this trade study

are shown in figures 1 through 5. System #1 represents full SSDS

responsibility for payload functions and customer responsibility for

determination of command executability. No command checking exists between

the customer and payload. System #2 represents SSDS checking of all

restricted/constrained commands. Single tier checking exists between the

customer and payload along with support for customer interactive planning of

the space station schedule. System #3 enables payloads and core systems to

originate commands. It contains a single tier checking function onboard the

spacecraft. The payload sends restricted and constrained commands out for

approval. System #4 contains multiple tiers of restricted, constrained command

checking. R separate path exists for non-restricted and executable commands.

Each tier may dump a checked command to the "executable" path. Some checking

may be performed by the customer prior to entering the SSDS. The payload must

reject improperly checked commands. System #5 provides apriori resolution of

problem commands and multiple tier checking through its integrated command

checking and scheduling. Again, this system incorporates a separate path for

non-restricted and executable commands. It also provides for a scheduling

service at the customer's request.

1.4 Issues

The following items represent major areas of concern relative to making value

judgements on the candidate systems capability for command and resource

management and are incorporated into the trade study criteria (See section 4):

a, What is the risk that present or new technology can meet development,

production (producibility), and cost/scheduling requirements?

b. What level of standardization/commonality should be achieved?

c. How much growth/technology insertion potential should be instituted?

16.6
"v"

(.J

L_

"I- 0

rv" 0

r_

r,," O

I--"

C13 O

r_

t/3

C_

I,m

i,i

m,

O

I"--"

e.-

£_ Eou

.4..)

0emv

c-

¢.)

c'- EE0U0Z

0

(J

eqU9

bO

(.J

{3% 00

(.- L0

4-L

qJ

"00

CO

C"

qJ

_J

_..

.-_0

t_

_J0

0_,,, 00E

0re"

01-,-

0r4-)

.._ UX

l.m.]

e'- O

e0f-,.

.l..I

,...,

0l,m.

¢/% O

¢/1 O

¢/)I

=14=

4-)

¢/1

>I

¢/')

01-,,

l.m.

16,.7
(]323

-NON N

I

0

_0_

zi_o

_zO_

_z_o

OZz_

vo

c.) ¢._

L;J

CO,,,

I--

0','

m-,-_

l,, r,-

,, . j

__._ -__ /

\ /

/HA _3H10 SONVWWOD_

f . ,

=l _ \

""t I---I _ _ -'

/ o,'ll I u i

16-8

"0

to

0

Q;

0

>s

i'm

u

Q;

L

-r-.

c

Q;

t--

Q;

0

g

t_

o

ee0rm

I

Z

_2

4-

0

cO

n_

°i'm

Q;

--.i

v

oo

r'_

c/)

oo

Q;

IJ

Q;

l..i

c-

•I_ e-

¢._

e- '-_

o

e- m

e'-e_

"_4=

N m

e-

_" E

o o

-_ o

co

e= ... _J

_g

e=

0

4-.

0

.p..

o

o

r_

¢-.

o

i

N

Q;

6_

Q;

c_
4-)

UU

16-9
_cr)

,,,rm

l--Z

• ILl • I.LI_

vF

,_l:¢.J

\\ ,,/

¢-EE0

_J

(1;

J3X

_J

rO

"0

(1;

_J

.rbO

qJI

c-- 0

c'- 0

q-

(1)

cO

tO

(1;

(./)

O0

113

"0

4-: 0

p.,-

°p...

"0 (J

u_ "X3

c'-

•r'- -h_

_J

,-.. e-

,..-- (.J

r_ o;

C" 0r'- N

_J

ee"0

C.J

"0

(1;

el.

e-o

,2

IU

4_

,t-O

,rF--

,r-

,g!
#

#

orl,.

(J

I

¢.J

i

,E, =

I

_o

o

o
d. What level of performance in the areas of reliability,

maintainability and responsiveness is needed to be attained?

e, What will be the cost effectivity in the development (nonrecurring),

unit (recurring) and life cycle (training, maintenance and operation)

operations?

f, Which resource drivers will be most significant in determining the

optimum system trade offs?

go What factors are to be included for a realistic sensitivity analysis

of all candidate systems7

h. Which systems carry more weight from a customer accommodation

perspective?

i , What is the most cost-effective integration scheme that will satisfy

performance requirements, buildup sequence, scheduling, and checking

of application functions?

1.5 Trade Stud V Criteria

The Command and Resource Management systems will be evaluated in two separate

steps. The first step addresses the degree to which the system meets

requirements. The applicable requirements and their sources are:

A.

B,

Does the customer receive assurance of error free delivery of his

command to his payload?

Does the customer know whether a command is delivered? (Reference I:

i.i.8).

C. Can the customer cancel any command he initiated?

!6-1.2
D, Is resolution performed on not executable commands (e.g., develop

time slip requirements to enable a formerly not executable command to

become executable) (Reference i: 6.1.6.2).

E° Does the customer receive reasons for not executable commands?

(Reference I: 7.3.4.1).

F. Are all not executable commands negotiable by the customer7

G, Are all not executable commands returned to the customer? (Reference

1: 6.1.3.1)

H. Is the customer (sender of commands) and address authenticated?

(Reference 1:1.1.4 & 6.1.4).

I, Can classification be determined on all commands (e.g., restricted,

constrained, or non-restricted)? (Reference i: 6.1.6 & 7.2.5).

3. Is there assurance that all commands will be properly classified?

K, Are non-restricted commands passed through the SSDS without any

further checks imposed on them? (Reference i: 6.1.6.3).

L, Can a customer functionally interact with his payload in the same

manner as if the payload were in his laboratory and enable him to

conduct his experiment(s) from his own institution/facility

(Reference l: 6.1.3).

M, Does SSIS provide adequate servicing of command processing so that

the customer requirements is minimized within the command management

system framework? (Reference i: 1.1.4, I.I.B, 6.2.1)

N, Can command privacy be maintained at all times? (Reference 1:

2.2.2).

16-13
O, Is there adequate security against disclosure of command information

to unauthorized personnel7 (Reference i: 0-3).

P0 Are restricted and constrained commands logically separated from the

general uplink? (Reference l: 7.3.4.1).

_J Does the system support customer interactive planning of the Space

Station schedule? (Reference I: 7.2.1 & 7.2.2.1).

R. Is customer allowed to enter his commands in bulk? (Reference 3).

So Is real-time interaction available? (Reference l: 6.2.1, 6.2.1.2 &

6.2.1.3).

The second step addresses the following qualitative evaluation criteria:

Cost - What relative cost level is associated with the buildup, operation and

future growth of the system?

Schedule - What is the probability for successful implementation of the

system within the available seven year total program schedule?

Performance - Is the level of performance satisfactory? Performance includes

real time command (no substantial increase in response time over that

necessary for communications - estimated to be approximately one second) and

the ability of a system to handle throughput.

Resource Effectiveness - Are spacecraft resources used efficiently, i.e, to

what degree can a system facilitate resource management?

Customer Accommodation - Can the customer be accommodated effectively, i.e.,

to what extent can a given system maximize the value of customer payload

product?

FMEA - What failure mode effects exist, i.e., what is the relative potential

For catastrophic failure modes ?or a given system?

16-14
Resource Availability - Is there a suitable availability of resources

including considerations such as the location of required resources,

criticality o? required resources, and the type of required resources?

Flexibility - Does the system have adequate flexibility to handle future

growth and technology upgrade?

1_1R
2.0 Methodoloqv

The basic approach which will be utilized for the trade study on candidate

command and resource management systems consists of the Following:

Fully describe the systems to be traded showing their intrinsic

Features.

ModiFy systems to Fully meet all application requirements i? possible

without altering each system's basic essence.

Evaluate the candidate systems relative to qualitative evaluation

criteria specifically designed ?or the command and resource

management trade study.

In the Future, a computer simulation model should be developed to

Facilitate the sensitivity analysis. This would greatly enhance a

capability to gain Further insight into all possible acceptable

combinations with regard to the practical operation.

3.0 Results

As indicated in Section 1.4, the trade study was conducted in two steps.

The requirements evaluation is shown in Table 1. The ratings against

requirements are: Yes, No, Partially, and Maybe, indicated by Y, N, P, and

7. Systems #4 and #5 are shown to successfully meet all criteria. Systems #2

and #3 will require some modification so that all criteria can be met. System

#I will not be able to meet all the criteria without substantial

modifications. Note that modification required For systems #I, 2, and 3 would

change these systems intrinsically.

The evaluation oF the systems against the qualitative evaluation criteria is

shown in Table 2. The ratings made were as Follows: High, Low, and Medium,

indicated by H, L, and M. Systems #4 and #5 appear to handle most o? the

criteria the best. With limited modification these two systems would be able

to score well with respect to all criteria. Systems #I, #2 and #3 would

16-16
Table 1

System Evaluation Against Requirements

Requirement ISystem #1

IY N P I?

I

A IX

B IX

c Ix

D I X

E I X

F I X

G I X

H IX

i Ix

J I x

K IX

L I IX

M I IX

N IX I

0 IX I

P I IX

q I IX

R IX I

S IX I

System #2 System #3

Y IN P ? IY IN P I?

X

X

X

X

Ix

I

Ix

xl

xl

Ix

Ix

xl

HI

I I

Ix l

Ix l

Ix l

I Ix

Ix l

x Ix l

Ix l

Ix l

Ix l

I Ix

Ix

Ix Ix

Ix

Ix

Ix

I x

Ix

Ix

Ix

System #4

y IN P I?

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

Ix

Ix

Ix

Ix I

System #5

Y N P ?

I

X

Ix

x

Ix

x

Ix

x

Ix

x

Ix

x

Ix

x

Ix

Ix

Ix

Ix

Ix

Ix I

1_17
Table 2

Qualitative System Evaluation

Evaluation

Criteria

COST

SCHEDULE

(7 year probability)

PERFORMANCE

-Real time

CommandW

-Ability to

Handle Through

put

RESOURCES

(Can facilitate

resource managreement)

CUSTOMER

ACCOMMODATION_

POTENTIAL

FOR CATASTROPHIC

FAILURE

MODE

SYSTEM_W

AVAILABILITY

OF RESOURCES

GROWTH/

TECHNOLOGY

UPGRADE

Overall Ratings

System #1

H IM L

X

X

X

X

X

X

X

X

X

System #2

IH M IL

I

Ix

I

I

Ix

X

System #3

IH M IL

I I

Ix

I

I

Ix

X

X

X

X

X

X

X

System #4

IN IM IL

I I I

Ix

I

I

Ix

X

X

Ix

I

I

I

Ix

I

I

I

I

I

Ix

I

I

I

I x

I

Ix

System #5

IH IM IL

I I I

IX

I

I

IX

Ix

Ix

x

x

* No substantial increase in response time over that necessary for

communication: + 1/2 second.

x_ Location, criticality and type of resources are considerations.

Maximize value of customer payload product.

1_18
require extensive modification to score well against the qualitative

criteria. This would mean these three systems require alteration from their

basic intrinsic features.

Systems 4 and 5 appear to be intrinsically adequate in satisfying the

requirements and qualitative evaluation criteria. Systems I, 2 and 3 fail in

totally satisfying all of the requirements and qualitative evaluation criteria

based on their individual intrinsic features. Therefore, they are not

acceptable as designed.

4.0 Conclusions, Recommendations and Issues

A* Further trade study effort should be performed on systems 4 and 5

through a sensitivity analysis.

B, Systems i, 2 and 3 need not be explored further unless modifications

to alter their basic intrinsic features is decided upon as being

acceptable.

16-19
5.0 REFERENCES

I. "Customer Requirements for Standard Services from the Space Station

information system (SSIS)" NASA 3SC Level B, Revision 2 dated March l, 19B5.

2. "Space Station Definition and Preliminary Design" NASA ESC RFP

G-BF-IO-4-OIP, September 15, 1984

2. "Space Station Mission: Requirements." Space Station Task Force Mission

Requirement Working Group (MRWG) and NASA LaRC computerized data base, May

1984.

16-20
SPACE COMMUNICATIONS

1.0 Introduction

End to end communications service for any user information precesses across a

number of communications links as well as undergoing processing at a number of

nodes during the ?low towards the "sink". The end to end aspect includes on

board (POP/COP/SS) connectivity, the link to (and from) the ground, the NASA

distribution network (NASCOM, land satellite service, local links), as well as

level "0" processing for format/error protection/routing/queue service, signal

processing, and also the linkage of engineering support information (event,

time, environmental conditions and/or settings, etc) to the actual payload

data.

The information itself may also suggest different modes of handling, i.e. some

may require precedence handling (e.g., emergency events), some may be

constrained to real time delivery as opposed to delayed delivery; some may

require a high degree of error protection while other information (e.g.,

video) may be sufficiently robust that error handling doctrine may be minimal.

The growth patterns which are anticipated as the SSIS matures, (see Task 4,

SSDS report), must be accommodated by the communications system in a

relatively straightforward manner. Therefore, there must be a level of

flexibility and adaptivity (near real time and also as events are scheduled)

built into the basic architecture. In addition, the Space Station will

generate video and audio information which will require distribution both

on-board and to ground facilities (users, POCC's, public affairs, etc). This

information, in conjunction with core data and payload data, are the

components of the communications portion of SSIS. Command and control, video

and audio, and program uploads are the primary contributory components of the

"forward" link to the Space Station. The COP and POP communications needs are

dominated by experiment data, however, command and control are also required

for the uplinks to these platforms.

17-1
Finally, processing at various locations in the end to end chain, if not

adequately addressed, can cause delivery delays, create multiple levels of

processing which affects S/W (and H/W) cost and development uncertainty, and

perhaps create an institutional rigidity which will be difficult to change as

the Space Station program evolves. It should be an objective that processing

points in the end to end chain, be located where ground level processing can

be most efficient. Level "O" and "IA" processing is discussed in Task 4

Section 7.0 (Ground SSDS definition).

This section concentrates on space communications, identifies various high

level options for efficient use and implementation of the space to ground

links, and via comparative tradeoff identifies the most attractive options.

2.0 Ground-Space Qrchitecture

In order to support the maturing of the Space Station program and the likely

changes in emphasis, mission experiments, and the presence of payloads on the

COP and POP platforms, as well as the Space Station, the TDRSS return (down)

link is addressed here as the primary link to ground. The discussion below

considers the Ku band (single access link) as the primary down trunk because

of its 300 MBPS capacity; the availability of S band links (single and

multiple access) are implied but except for information partitions and

therefore processing simplification, these add minimal capacity to the

required band width.

The primary emphasis below is on the use of TDRSS, TDRSS enhancements, or

augmentation to the down link to accommodate special loading or service

demands.

2.1 Ground to Space Rrchitecture Options

The followinglist of options have been identified:

a,

b.

1,2,3,4 satellite TDRSS configurations.

TDRSS augmented by enhancements or TDAS.

17-2
C,

d,

e.

TDRSS augmented by a commercial satellite utilizing a combination of

TDRSS and ACTS technology.

TDRSS augmented by direct downlink to the DSN.

All users required to provide for their requirements in excess of

TDRS8 capacity.

The capacity characteristics of the TDRSS links are shown in Table I.

TABLE I - TDRSS DATA RATE CAPACITIES

SERVICES AND PARAMETERS MA SSA KSA

FORWARD LINK SERVICES

QUANTITY OF LINKS PER TDRS

TOTAL LINKS FOR THE TDRSS

RETURN'LINK SERVICES

QUANTITY OF LINKS PER TDRS

TOTAL LINKS FOR THE TDRSS

1 2 2

1 4 4

20 2 2

20 4 4

FORWARD LINK

MAXIMUM USER DATA RATE

RETURN LINK

MAXIMUM USER DATA RATE

i0 KBPS 300 KBPS 25 MBPS

50 KBPS 3 MBPS 300 MBPS

PER TDRS TOTAL FOR TDRSS

TRACKING LINKS

ONE-WAY DOPPLER 10

TWO-WAY RANGE AND DOPPLER (MR) I

TWO--WAY RANGE AND DOPPLER (SA) 4

iO

2

6

NOTE: THIS TABLE IS BASED ON 2 SATELLITES DEDICATED TO TDRSS SERVICE;

SOURCE: SPACE NETWORK TDRSS DATA BOOK, APRIL '85.

17-3
2.1.1 Four Satellite (TDRS) Configuration

TDRSS utilization in 1,2,3, or 4 satellite configurations requires examination

of the impact of Zone of Exclusion (ZOE), hardware impact and operations

effect. Table 2, based on projected locations for these various TDRSS

options, summarizes these considerations. In summary, the ZOE means that any

data collected during this period cannot be "sent down", thus suggesting two

general strategies. The first is to continue to collect such data, buffer

until TORSS returns to view, and then transmit. This means, for example

(using the 15% exclusion zone) that the down link must handle, in the worst

case, 1.15 (the normal) data rate. This leaves unresolved such questions as

to whether a First In-First Out (FIFO) protocol is to be followed once TDRSS

accessibility is restored, or whether a level of source data throttling should

be introduced during ZOE. These are issues which can best be addressed by

mission oriented tradeoffs.

Another issue is the fact that multiple TDRSS "birds" suggest the use of at

least two TDRSS antennas on the user platform so that maximum use can be made

of the available channels. In this case, the handover process becomes a

factor, probably requiring covering signals from two (or more) TDRSS platforms

(using the forward link for establishing a reference). Signal acquisition and

re-acquisition (how long7 how to point?, how to know which antenna/TDRSS is in

view?) are the implementation considerations.

Finally, one general factor in the architectural equation is the desire to

time share (COP, POP, and Space Station) the linked TDRSS resources; event and

access scheduling are essential to service all three platform types.

The TDRSS capacity is listed in Table 1; the major downlink (Ku, SA) is rated

at 300 MBPS. One of the major factors in the data rate is the modulation

scheme (QPSK). By the use of a different modulation method (eg. 8-ary), the

data rate can be substantially increased.

A 50-100% increase (depending on whether the channel is encoded or not) is

theoretically possible; the technology is reasonably well known.

17-4
TABLE 2 - TDRSS OPTIONS VS ZOE

# TDRSS

SATELLITES

APPROX.

LOCATION

ZOE

% OUTAGE

CHARACTERISTICS

41 W APPROX.

(40-50)%

A) Large data buffers and/or throttling

during ZOE;

B) Re-acquisition required

41W

171W

15% A)

B)

C)

Throttle back/buffer data during ZOE

Have East-Nest handover problem:

One - SS antenna requires Fast slow rate

and fast acquisition

Two - SS antennas minimize data loss

during handover.

41W

61W

171W

15%

A)

B)

Increased data capacity 50% of orbit

Complex antenna handover procedures

(could run at 300 MBPS 85% of time through

1 & 2, using third TDRSS to dump ZOE data

also at 300 MBPS).

4i w (2)

171 w (2)

15% Doubled information capacity 85% of

orbit; East-West handover problems; changes at

ground terminals antenna system.

Basic Source: TDRSS User Guide

2.1.2 TDAS Augmentation of TDRSS

The TDAS satellite, which is now in the planning phase could be available in

the early phases of the Space station program (e.g., Iggs-2ooo). A comparison

with TDRSS is shown in Table 3. It is obvious that it offers substantially

more capacity than TDRSS (approx. I GBPS vs 300 MBPS for the single access

return (down) link) and projects the use of steerable regional or spot beam

antenna which could reduce the terrestrial network load by directing data to

regional locations.

17-5
TABLE 3 - TDRSS vs TDAS CAPABILITY SUMMARY

(SOURCE: TDAS FOR THE 1990's; 5/31/83)

STI REPORT TO GODDARD

TDRSS TDAS

MULTIPLE ACCESS

• 1 FORWARD CHANNEL

• 20 RETURN CHANNELS (SYSTEM MAX)

• BEAMFORMING AT GROUND

• 2 FORWARD CHANNELS

• 10 RETURN CHANNELS PER S/C - LINK

GAIN INCREASES BY 4.5 dB

• ONBOARD BEAMFORMING

SINGLE ACCESS

• 2 K-(OR S-)BAND PER S/C

• DATA RATES TO 300 Mbps

• K-(OR S-) BAND

• 5 W-BAND PER S/C

• 1 LASER

• DATA RATES TO 1Gbps

SPACE-TO-GROUND

• SINGLE BEAM ANTENNA

- 1 FIXED LINK

• Ku BAND TO WHITE SANDS

• DOMSAT RELAY

• MULTIPLE BEAM ANTENNA (5 FIXED

HORNS, 4 STEERABLE)

- 5 FIXED LINKS

- 1 MOBILE LINK

• ONBOARD TWO-WAY SWITCH

• RETAIN Ku AT WHITE SANDS, USE

Ka AT ALL OTHER SITES

• NO DOMSAT RELAY

CROSSLINK

• NONE • 1 FORWARD PER S/C (25 Mbps)

• 1 RETURN PER S/C (1.8 (Gbps)

• LASER OR 60 GHz

The problems are technical uncertainty and programmatic (will it be funded and

when will it be available). Network management complexity will also be a

factor in addressing operational level decisions.

17-6
2.1.3 COMSAT/ACTS Augmentation of TDRSS

TDRSS augmented by a commercial communications satellite capability on the

Space station (or the POP or COP), where that satellite could use the multiple

access and antenna pointing technology of the Advanced Communications

Technology Satellite (ACTS) Program, could offer an increase in down link

capacity and allow for connection to regional or user facilities. ACTS

technology is being developed under NASA contract, and is to be tested in the

19B8-1990 time frame. A potential application of ACTS technology is to

support the distribution of TDRSS return link data from White Sands to

regional user sites.

2.1.4 Direct Downlink To DSN

Rugmenting TDRSS by links to a network such as the Deep Space Network is

possible for off loading the TDRSS. DSN is not a high capacity network, but

could be used for additional coverage for moderate data demands. However, at

best it might be used for emergency down links, rather than as an integral

part of the SSIS communications structure.

2.1.5 User Provided Downlink

Customers might want to or be required to provide for direct down links from

the Space Station (or COP or POP) rather than depend on the SSDS/SSIS

constraints. This alternative would affect the platform communications

requirements and also offset other auxilliary areas such as power budget,

electro-magnetic interference patterns, antenna and structural factors.

2.2 Conclusion

The changing traffic profile of the projected experiments makes the future a

little unclear. However, the projected satellite TDRSS configuration

(essentially two each stationed at East and West stations) would probably be

adequate for the IOC plus some reasonable growth. This is a relatively low

technical risk solution, with the caveat that the ground terminal and network

would have to be modified to support both the traffic increases and the

antenna footprints. Careful scheduling to avoid conflict between POP, COP,

17-7
and Space Station is essential to take advantage of this robust TDRSS downlink

capability.

If real time delivery delays cannot be met by this approach, then the addition

of antenna steering (as in TDAS and/or ACTS technology) to delivery to

regionally located data handling centers, must be considered.

3.0 DONNLINK TRANSMISSION OPTIONS

The discussions below describe options, some tradeoff criteria, and finally

the advantages and disadvantages of each, as related to the link

organization. The primary criteria although implicit, is in the ability to

accommodate changing requirements over the mission life and on a near real

time basis to accommodate special conditions. The discussion below also

assumes that audio and video information will be digitized, and that data

using the return (downlink) TDRSS links will probably fit into three

categories. The first is facilities/housekeeping telemetry data, which

requires modest capacity (e.g., 5MBPS or less). The second is continuous and

relatively high rates (e.g., 10-50 MBPS payload data); and, the third is

payload data reflecting more modest requirements (e.g. iOO KBPS to 5 MBPS).

The question of packets for all data or a combination of packets with

implications of 5-10% overhead (e.g. using a modified CCSDS format) and

virtual/direct connection is considered. Packets impose a processing load

(and associated delay); virtual connections require an adequate quality

channel (within SSIS), and dynamic allocation of virtual channels to minimize

scheduling and control of the experimental payload activity.

Packetization requires that onboard processing and the counterpart location in

the ground network have responsibility for keeping the discipline of the

packetized data; a virtual connection assumes that the end addressee will

collect and process the data - i.e. the POCC/PI or data handling center, and

requires minimal overhead in the SSIS information flow. However, the virtual

connection implies no error control in the path between source and sink. The

options below address these possibilities.

17-8
3.1 Tradeof? Considerations

The trade study options presented in the discussion on uplinks and downlinks,

must be evaluated keeping in mind the particular characteristics of the

transmitted data. Each option must not only provide for current data rates

but must be evaluated as to their ability to handle increased data rates as

the SSIS grows. In addition to planned events, the data transmission formats

should be flexible enough to handle various emergency or contingency

situations as they arise. Nith SSIS channel bandwidths at a premium,

efficient channel utilization is an important consideration when evaluating

the various options. Other factors such as routing complexity, data overhead,

and the ability to redistribute data loads must also be considered. Finally,

the availability of technology to support the various options must be

considered; in particular, new technology presents risk for the implementer

and, implicit, is the impact of uncertain costs for new technologies.

3.1.1 TIME MULTIPLEX SCHEMES

a. DEDICRTED TIME SLOTS (FIXED FRRME)

This scheme is characterized by the fixed boundary within each frame which

separates the low rate data packets from the high rate data stream (virtual

connection), see Figure 4.1. Each frame has the same ratio of low rate data

to high rate data. The scheme is tailored to the data characteristics and

allows simple handling procedures since there are well defined data

ooo

I

Low l Data ] High Rate

Rate I Data

Packets

b

I I

I

_L

Synch

_m_

Synch

, i- iraillM_

I

Low I

Data I

Rate I

Packets I

I

Fixed Boundary

Figure 4-1. Time Multiplex Schemes - Fixed Frame

High

Rate

Data

ooo

17-9
boundaries. The fixed boundaries within each frame however, do present the

difficulty with channel capacity utilization,and provides limited flexibility

for contingencies and growth.

Frame synchronization is very important, so that a small overhead exists to

determine and acquire synch, at the start of each frame.

b. DYNAMIC ALLOCATION

This scheme is similar to the previous scheme in that each frame contains a

boundary between the high rate data stream and the low rate data packets. The

difference is that the position of the boundary from frame to frame is

dynamically allocated according to the scheduled data rate requirements, see

Figure 4.2. The scheme requires a coordination packet at the beginning of

each frame to identify where the boundary is located. The

coordination/signalling packet notifies the ground entry node when a change in

the dynamic boundary is to occur; thus it requires a coordinating hand shake,

which takes a minimum of time equal to round trip delay plus processing. The

scheme provides efficient use of channel capacity and there is inherent

flexibility for contingencies and growth. As a result of the dynamically

changing data boundary however, relatively complex data handling procedures

are required.

Dynamic

Synch Boundary

• • • Rate r_ate • • •

,Coor_ J----

Packet Synch

Dynamic

Boundary

Figure 4-2. Time Multiplex Schemes - Dynamic Allocation

17-10
c. TOTALLY PACKETIZED

In this scheme both the low rate data and high rate data are packetized and

then multiplexed into the frames. As a result the scheme allows the use of

standard protocols and formats. R significant overhead is required with this

scheme in order to identify the contents and destination of each data packet.

Discussions of various packet candidates are made in the Task 3, Section IV,

Communication Standardization Trade Study, but in general the use of a

standard packet (e.g. CCSDS) would simplify network transversal and

intermediate processing. It is not apparent at this point, that low rate

payload data and high data rate, continuous data should be enveloped into the

same packet format. Thus, in the latter case, the overhead penalty would be

more closely in balance with the amount of data; in the former case,

processing complexity is less than with a non-standard packet format and

structure.

3.1.2 Channel Allocation Scheme #1

The downlink capabilities in this scheme have been divided into three links.

The first is the S-band link which will be reserved for core data. The

Ku-band, I channel (150 Mbps) will be used for the second link and will be

reserved for high rate or bulk data. The third link will be the Ku-band, Q

channel (150 Mbps), and will be reserved for additional experimental data

and/or video. As a result of the well defined data boundaries the scheme

allows for simple data handling procedures. The disadvantages of this scheme

include possible poor channel capacity utilization and poor flexibility for

change contingency and growth.

3.1.3 Channel Allocation Scheme #2

Downlink data in this scheme will be divided between two channels. The first

channel will be the S-band link and will be reserved only For core data. The

Ku-band link will be the second link and will be dynamically allocated. This

scheme conbines well defined data boundaries and reasonable channel capacity

utilization. There is an inherent flexibility for contingencies and growth

and data handling procedures are only moderately complex.

17-11
3.1.4 Channel Rllocation Scheme#3

This scheme utilizes the Ku-band link for all data transmission with the

S-band link reserved to smooth peak loads. Rs a result of dynamic allocation

there is inherent flexibility and good channel capacity utilization. The

primary disadvantage to this scheme is that the data handling procedures

become quite complex.

3.2 Conclusions

. Rmongst the three possibilities discussed under Time Multiplexed options,

the dynamic allocation is the most flexible and gives a relatively

efficient channel usage mode. The dedicated time slot approach is

somewhat inflexible and a major overhead penalty is required to support a

fully packetized channel. Therefore, option b (Dynamic Allocation) is

recommended at this time. The method of coordination between the Space

Station commmunications subsystem and the ground terminal will have to be

analyzed to determine complexity and capability required at the ground

entry terminal.

. It is premature to determine how to partition the downlinked (return)

traffic which will use TDRSS. If throttling during excessive traffic

periods is acceptable, then allocation method #3 is not necessary.

However, more operational/mission user liaison is required to make any

specific recommendation at this point.

4.0 UPLINK TRRNSMISSION OPTIONS

The uplink to the spacecraft, could be considered in a number of categories:

Space Station - uplink to include command data, uplinked event information

data, program uploads data, and voice and video information; Co-orbiting

Platform (COP) - If it is connected directly to ground via TDRSS, then the

uplinks are for data only; if Space Station acts as a relay to the COP for

uplinking, then the Space Station will be responsible for "parsing" the

information stream and relaying the data to the COP; Polar Orbiting Platform

(POP) - direct uplink through TDRSS for command, data and program uploads.

17-12
It is assumed that a packet format will be used for commands and program

uploads data; audio and video should not require that format.

4.1 Channel Allocation Scheme #1

This scheme utilizes the S-band uplink for all core commands and utilizes the

Ku-band uplink for user commands and video. The scheme possesses well defined

data boundaries and inherent flexibility for contingencies and growth. The

data handling procedures are only moderately complex.

4.2 Channel Allocation Scheme #2

This scheme employs the Ku-band link for all uplink information with the

S-band link reserved for overflow at peak times. There is great flexibility

with this scheme and good channel capacity utilization. With all data

multiplexed on one channel complex data handling procedures are required.

4.3 Conclusion

Channel Allocation Scheme #1 is the lower risk approach. The partitioning of

the uplink into Ku-Band and a clearly defined user group and the S-Band for a

clearly defined user (core station commands) makes for a clear organization.

The only concern would be to examine the user command requirements, based on

the changing user data base, and determine whether there might be conflict

with the uplink video requirements. 3udicious scheduling could eliminate that

concern.

5.0 INTERNAL (PLATFORM) ARCHITECTURE OPTIONS

It is recognized that the Onboard Local Area Networking Trade Study, Task 3,

Section V, also addresses architecture options, however this section addresses

only partitioning concepts of the three classes of information (data, voice

and video) from a communications perspective.

The major components of the information which traverses the SSIS are data,

video and audio. The on-platform communications is also composed of those

17-13
elements, although, in the use of the Space Station, part of this information

does not go to ground but is used to support on board and corollary space

operations.

Three options exist; a distribution system (switched or bus/ring which does

not partition between the three classes of information, a system which is

partitioned so that each class traverses its own path, and finally a hybrid

where perhaps video and audio are on one distribution system while data is

distributed via a data bus (quasi-LAN) throughout the craft and to video

interfaces.

Examining these options it is necessary to characterize the information

traffic. Video if digitized, will require major bandwidth allocation - thus a

standard broadcast quality, color, TV picture will require approximately BO

MBPS. Through various compression techniques, a highly acceptable picture can

be achieved at approximately 22 MBPS. A similar condition exists for

audio/speech - i.e. a straightforward (PCM) digitization technique yielding

"toll" quality speech requires about 64 KBPs but the use of a different

algorithm (CVSD) affords good, understandable quality of 16/32 KBPS. Although

other voice digitization techniques (e.g. OPC) offer reasonable quality at

somewhat lower rates, the 16/32 KBPS rate represents an easily achievable

design, the 32 KBPS is used on STS, and voice loading is not a major

contributer to the SSIS loading. Further, video and voice are rather robust -

i.e. there is sufficient redundancy so that random errors will have little or

no effect on intelligibility, resolution, etc. In addition, they are

continuous (not bursty) sources.

The data tends to fit into three categories: core or facility data tends to

be relatively low rate - e.g. sensors typically have rates between lO bps and

5 KBPS. In addition, the information in this area will probably continue

throughout the life of the space craft and its appearance will be highly

predictable (e.g. once/minute, once/hour, etc.). Payload data tends to fit

into two categories: relatively continuous, high rate, data such as would be

derived from mappers and relatively modest rate sources such as materials

processing.

17-14
Further, an assumption is made that data will require protection - i.e. error

detection/correction coding; video and audio do not require that protection.

5.1 Bus Network vs Switched Distribution Structures

Rlthough a switched structure is feasible it does have certain disadvantages

which mitigate against it, at this stage of the SSIS development. First, it

tends to be a centralized function and even though redundancy techniques are

possible, this becomes a point of concern in terms of single point failure.

Second, recognizing that the SSIS/SSDS will evolve as missions change and

perhaps module changeover is required for the Space Station, a switched

structure is more difficult to rewire and to reconfigure in a large sense.

R bus or distributed LRN, if properly designed, allows for adding or deleting

terminals, payload sources, processing elements (such as data base units,

memory elements) and also is more flexible as space assembly of a Space

Station is considered. Further, by using by-pass techniques or even a network

of smaller networks, single point failure is not a serious factor.

5.2 Bus/Network Options

The audio/video distribution can either be digital or analog on the Space

Station; it is assumed that when that information merges with SSDS data on an

external RF link that the information will be digitized.

I? all information on the Space Station were digitally transmitted on the

craft, even with compression techniques, the rates (based on traffic

projections) would be well in excess of i00 MBPS, (depending on scheduled

events, could be 200 MBPS) which taxes the state of the bus technologies

available - even that of fiber optics. Although it is anticipated that the

technology will advance over the next five years, a conservative approach is

to assume separate data and audio/video distribution networks. It is also

assumed that an analog distribution system, on board, using CCTV or broad

band/FDM techniques, is low risk and modest cost, and could be acceptable for

TV and audio interconnect service.

17-15
The primary concern at this juncture is that of the format of the on board

data networks. Three generalized options appear and are listed below:

a) All data transmitted on parallel on board SSDS busses utilizing a

packetized format.

b) Parallel data buses with different characteristics.

Core data bus utilizing a packetized format for low rate

transmission.

User data bus using virtual connections for high rate/bulk data

transmission.

Direct memory access data bus for bulk transfer of stored data or

bulk uploads.

c) Rnother option would combine data, voice, video, in a digital format

on the same bus structure; however, the very high rates which would

be required would require some major technology improvements.

In the first option,the packetized format might be different than that used on

an RF link, because the internal network connection performance is much more

predictable.

The use of a standard format has the advantage of simplifying processing.

However, the use of a single network structure for all SSDS information might

cause problems where high volume, continuous users gain access, denying access

to lower rate users. To avoid this, either timeout or precedence is required

and this complicates the processing. Further, there is a significant overhead

imposed on all users (i.e. everyone uses packets).

In the second option, the core data bus would allow SSDS information to be

transferred internally and to/from RF interfaces in a relatively timely and

predictable manner. The "user data" bus would be set up for a specific

experiment or group of experiments and would not impose a packet type overhead

penalty on this data stream. This "virtual connection" has the value o? being

relatively efficient, but does require set up for the experiments which would

17-16
' fit into this category. The other element of this option is that bulk

transfer could use a direct memory access into assigned buffers or memory

fields. This removes a potential heavy traffic load From the internal, common

users SSDS structure, and obviously is a high speed/low connect time service.

Of the two primary options, b (above) is the most attractive for the following

reasons:

The internal distribution system is most closely tailored to the

characteristics of the users. Thus, by segregating by user groups,

it is relatively efficient.

It does not impose the risk that high volume data users will either

be limited in the time that they may occupy the channels, or that

there is a substantial packet processing penalty to be paid by the

high volume users (where the stream would have to be broken into

packet sizes regardless of the data characteristics).

It affords adequate service ?or low speed/low rate users, payloads,

and sensor telemetry information.

The ability to accommodate major changes in payload requirements is

only limited by the implemented bandwidth.

• Low priority users are not "locked out".

5.3 Conclusions

Option c), where voice, video, and data appear on the same bus is not very

practical from two viewpoints:

i ,

,

Digital video is exceedingly bandwidth consuming and would require a

major improvement in the technology.

Traffic generated by different uses exhibits characteristics

(distribution, occupancy, etc.) which are very different.

17-17
Option a) and b) address a distribution structure where video and voice are

either on separate (or perhaps) on a common distribution system.

Option a) combines all data on one bus structure; this means that low priority

users or short duration data needs might not get adequate service i? long

duration users (e.g., heavy use users) occupy the bus.

Option b) partitions these data groups and thus allows ?or a design which is

closer to these user needs by class o? needs, discussed at the end o? the last

paragraph, above. There?ore, option b) is the presently recommended system.

17-18