DECEMBER 1985

MDC H1343A

SPACE STATION DATA SYSTEM

ANALYSIS/ARCHITECTURE STUDY

Task 2- Options Development, DR-5

Volume III- Programmatic Options

(NASA-CR-177841) 5PACE 5TATICN DATA SYSTEM

ANAL¥SIS/ARCSITEC_gHE HIUD_o _ASK 2:

OPTIONS DEVELCPME_, D_-5, VCLgME 3:

PROGHAMMA_IC CP_IC_S [McDon_e/l-Douglas

AstEonautics Co.) 240 p HE AII/MF AO!

N86-2C477

Unclas

•G3/18 04594
MCDONNELL/___

DOUGLAS

CORPORATION

SPACE STATION OATA SYSTEM

ANALYSIS/ARCHITECTURE STUDY

Task 2 - Options Development, DR-5

Volume III - Programmatic Options

DECEMBER 1985 MDC H 1343A

REPLACES MDC H1940

DATED MAY 1985

MCDONNELL DOUGLAS ASTROIYAUTICS COMPANY-HUNTINGTON BEACH

5301 Bolsa A venue Hun tington Beach, California 926"47 (714) B96-3311
PREFACE

The McDonnell Douglas Astronautics Company has been engaged in a

Space Station Data System Analysis/Architecture Study for the National

Aeronautics and Space Administration, Goddard Space Flight Center.

This study, which emphasizes a system engineering design for a

complete, end-to-end data system, is divided into six tasks:

Task 1.

Task 2.

Task 3.

Task 4.

Task S.

Task 6.

Functional Requirements Definition

Options Development

Trade Studies

System Definition

Program Plan

Study Maintenance

McDonnell Douglas was assisted by the Ford Aerospace and

Communications Corporation and IBM Federal Systems Division.

This report was prepared for the National Aeronautics and Space

Administration Goddard Space Flight Center under Control 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

,nRECEDING PAGE ELANX NOT FILMED

iii
cO

-t"

iii

+>,

+._.+,,.-

iv
Task 2, Volume Ill

TABLE OF CONTENTS

TOPIC PAGE

3.0

3.1

3.1 .l

3.1.2

3.1.3

3.1.4

3.1.5

3.1.6

Programmatic Options

Standardlzatlon/Commonallty Options

Communication Protocol Interface Standards

3.1.1.1 Communication Standards Option Overview

3.1.I.2 Standards Options Within the ISO Layer

3.1.I.3 Standards Architecture

3.1.I.4 Communication Standards References

Data Base Management Systems Standards

3.1.2.1 Relational DBMS Standards

3.1.2.2 Network DBMS Standards

3.1.2.3 Hierarchical DBMS

3.1.2.4 Data Base Standards References

Coding Standards Options

3.1.3.1 Bottom Up

3.1.3.2 Top Down Stub

3.1.3.3 Top Down Statement

3.1.3.4 Model-Drlven

3.1.3.5 Structured Programming

3.1.3.6 Prototyplng vs Specifying

3.1.3.7 References

Software Quality Assurance and Testing Standards

3.1.4.1 MIL-S-52779

3.1.4.2 NASA Guidelines and Federal Information Processing

Standards (FIPS)

3.1.4.3 Industry Methodologies

3.1.4.4 References

Hardware Standards Options

Safety Standard Options

3.1.6.1Mll-Standard 882

3.1.6.2 NHB 5300.4 (ID-2), Safety, Reliability,

Maintainability and Quality Provision for the

Space Shuttle Program

3

5

6

6

15

31

43

45

45

46

47

47

48

49

50

51

51

52

52

54

55

56

57

5B

59

59

69

69

70
TOPIC PAGE

3.1.7 Reliability Standard Options

3.1.7.1MIL-STD 785B, Reliability Program for Systems

and Equipment

3.1.7.2 NHB 5300.4 (ID-2), Safety, Reliability,

Maintainability and Quality Provisions for the

Space Shuttle Program

3.1.8 Logistics Standards Options

3.1.9 Maintainability Standards Options

3.1.9.I MIL-STD 470A Maintainability, Program for Systems

and Equipment

3.1.9.2 NHB 5300.4 (ID-2), Safety, Reliability,

Maintainability and Quality Provisions for the

Space Shuttle Program

3.1.10 Procurement Standards Options

3.1.11 Video Standards Options

3.1.12 Data Interface Standards Options

3.2 System Management

3.2.1 Network Control

3.2.1.I Real Tlme Control

3.2.1.2 Intermediate Time Controls

3.2.1.3 Communications Llnk Schedullng/Prlorltlzatlon

3.2.1.4 LongTerm Planning & Scheduling

3.2.2 Network Monitoring

3.2.2.1 Network Managing Data Management

3.2.2.2 Data Analysis

3.2.2.3 Cost Accounting

3.2.3 Network Administration

3.2.3.1 Centralized Versus D1strlbuted Options

3.2.3.2 Configuration Control Options

3.2.3.3 Space/Ground Functionality Transfer Procedures

3.2.3.4 Network Admlnlstratlon/TMIS Interface

71

72

72

74

76

76

77

78

80

84

87

8"/

88

88

89

89

8g

90

gl

91

92

92

93

93

vi
3.2.4

3.2.5

3.5

3.5.1

3.5.2

3.5.3

Network

3.2.4.1

3.2.4.2

3.2.4.3

3.2.4.4

Maintenance

Network Maintenance

Trouble Shooting & Repair

Hardware Maintenance Options

S/W Maintenance Options

Customer/SSDS Interface Options

3.2.5.1 Simulation Center

3.2.5.2 Mission Integration Planning

3.2.5.3 SSE Interface

3.2.5.40nboard Training

3.2.5.5 Service Restoration versus Service Repair

System Development

Hardware Procurement

3.5.1 l Hardware Commonality

3.5.1 2 Qualification Levels

3.5.1 3 Prototypes/Test Beds

3.5.1 4 Procurement Strategies

3.5.1 5 Summary

3.5.1 6 References

Software Development Options Paper

3.5.2.1 Software Engineering

System Test, Integration and

3.5.3.1 Test Options

3.5.3.2 Integration Options

3.5.3.3 System Verifications Options (IOC)

3.5.3.4 Integration Options (Growth

3.5.3.5 Integration Optlons (Man-Tended)

3.5.3.6 Facilities Options

(Task 2)

Verification

93

93

93

94

95

95

95

95

96

96

96

I03

I05

I05

I05

ll9

ll9

121

121

1 29

129

189

191

194

198

200

202

203

v_
GLOSSARY

A

A&R

A/A

AIO

AIL

AIN

AC&S

ACA

ACO

ACS

ACS/COM

ACTS

AD

AO

ADOP

AOP

AFOSR

AFP

AFRPL

AGC

AGE

AI

AIE

AIPS

ALl

ALS

ALS/N

ANIC

ANSI

AOS

AP

APO

APSE

ARC

Automat Ic

Automatlon and Robotlcs

Analysl s/Archltecture

Advanced Oevelopment

A1rlock

A]phanumer Ic

Attltude Control System

Attltude Control Assembly

Admlnlstratlve Contractlng Offlcer

Attltude Control and Stab111zatlon

Attltude Contro] System/Communlcatlons

Advanced Communlcatlons Technology Sate111te

Anc11]ary Oata

Advanced Deve]opment

Advanced Olstrlbuted Onboard Processor

Advanced Oeve]opment P]an

Air Force Offlce of Sclentlflc Research

Advanced F1exlble Processor

Air Force Rocket Propulslon Laboratory

Automatlc Galn Contro]

Attempt to Generalize

Artlflclal Inte111gence

Ada Integrated Envlronment

Advanced Informatlon Processlng System

Air Lock One

Alternate landlng Site

Ada language System/Navy

Automated Management Informatlon Center

Amerlcan Natlonal Standards Instltute

Acqulsltlon of S1gna]

Automatlc Programml ng

Avalanche Photo 01ode

Ada Programmlng Support Envlronment

Ames Research Center

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&W

ClL

CA

CAD

CAE

CAIS

CAM

Automated Reasoning Tool

American Standard Code for Information Exchange

Airborne Support Equlpment

Advanced Star/Target Reference Optlcal Sensor

Advanced Technology Advisory Committee

Air Traffic Control

Authorlty to Proceed

Advanced Telemetry Processing System

Assembly Truss and Structure

Automated Visual Maintenance Information

Adoptive Wafer Scale Integration

Bridge

Block Adaptlve Rate Controlled

Breadboard

Blt Error Rate

Bullt-ln Test

Bullt-ln Test Equlpment

Buffer Interface Unlt

Bus Interface Unlt

Bullt-ln Unlt

Ballistic Missile Defense

British Thermal Unlt

Bandwidth

Constrained

Command and Control

Command, Control, and Communication

Command, Control, Communication, and Intelligence

Communications and Data Handling

Communication and Tracking Subsystem

Communications and Tracking

Control and Warning

Checklist

Customer Accommodation

Computer-Alded Design

Computer-Aided Englneerlng

Common APSE Interface Set

Computer-Alded Manufacturing
CAMAC

CAP

CASB

CASE

CATL

CBO

CB[MA

CCA

CCB

CCB

CCC

CCO

CCITT

CCITT

CCMS

CCR

CCSOS

CCTV

cdlM 2

COG

COMA

COOS

CDR

CDS

CE

CEI

CER

CFR

CFS

CG

CIE

ClL

ClU

CLAN

CM

CM

CMOB

Computer Automatic Measurement and Control

Crew Activities Plan

Cost Accounting Standard Board

Common Application Service Elements

Controlled Aceptance Test Library

Commerce Business Datly

Computer and Business Equipment Manufacturing Association

Cluster Coding Algorithm

Contractor Control Board

Configuration Control Board

Change and Configuration Control

Charge-Coupled Device

Consulttve Committee for International Telegraph and Telephone

Coordinating Committee for International Telephony and Telegraphy

Checkout Control and Monitor System

Configuration Change Request

Consultative Committee for Space Oata System

Closed-Circuit Television

Candelas per square Meter

Concept Development Group

Code Dlvlslon Multtple Access

Customer Oata Operations System

Critical Design Review

Control Oata Subsystem

Conducted Emlsslon

Contract End-ltem

Cost Estlmetlng Relatlonshlp

Code of Federal Regulatlons

Cambrldge F11e Server

Center of Gravlty

Customer Interface Element

Crltlcal Item List

Customer Interface Unlt

Core Local Area Network

Conflguratlon Management

Center of Mass

Conflguratlon Management Oata Base

xi
CMG

CMOS

CMS

CMU

CO

COF

COL

CO_

COP

COPCC

COPOCC

COTS

CPCI

CPU

CQL

CR

CR

CR&D

CRC

CRF

CRSS

CRT

CS

CSD

CSOL

CSMA/CD/TS

CSTL

CTA

CTE

CU!

CVSD

CWG

D&B

DADS

DAIS

OAR

Control Moment Gyro

Complementary Metal-Oxide Semiconductor

Customer Mission Specialist

Carnegie-Mellon University

Contracting Officer

Component Origination Form

Controlled Operations Library

Commercial Missions

Co-orbital Platform

Coorbtt Platfom Control Center

COP Operations Control Center

Commercial Off-the-Shelf Software

Computer Program Configuration Item

Central Processing Unit

Channel Queue Limit

Compression Ratio

Change Request

Contract Research and Oevelopment

Cyclic Redundancy Checks

Change Request Form

Customer Requirements for Standard Services

Cathode Ray Tube

Conducted Susceptibility

Contract Start Date

Charles Stark Draper Laboratory

Carrier-Sense multlple wlth Access/Collision Detection and Ttme

Slots

Controlled System Test Library

Computer Technology Associates

Coefficient of Thermal Expansion

Common Usage Item

Code Variable Slope Delta (Modulation)

Commonality Working Group

Docking and Berthing

Digital Audio Distribution System

Dtgital Avionics Integration System

Defense Acquisition Regulation

xii
DARPA

DB

DBA

OBML

DBMS

OCAS

DCDS

DCR

DOBM

OOC

DDT&E

DEC

DES

DFD

DfiE

DHC

DID

DIF

DMA

OMS

ODD

DOMSAT

DOS

DOT

DPCM

DPS

DR

DR

DRAM

DRD

DS&T

DSDB

DSDL

DSOS

DSIT

DSN

DTC

Defense Advanced Research Pro_ects Agency

Data Base

Data Base Administrator

Data Base Manipulation Language

Data Base Management System

Defense Contract Administrative Services

Distributed Computer Design System

Data Change Request

Distributed Data Base Management

Discipline Data Center

Design, Development, Testing, and Engineering

Dlgtta] Equipment Corp.

Data Encryptlon Standard

Data Flow Diagram

Display Generation Equipment

Data Handling Center

Data Item Description

Data Interchange Format

Direct Memory Access

Data Management System

Department of Defense

Domestic Communications Satellite System

Distributed Operating System

Oepartment of Transportation

Differential Pulse Code Modulation

Data Processing System

Discrepancy Report

Data Requirement

Dynamic Random-Access Memory

Design Requirement Document

Development Simulation and Training

Distributed System Data Base

Data Storage Description Language

Data System Dynamic Simulation

Development, Simulation, Integration and Training

Deep-Space Network

Design to Cost

xiii
DTC/LCC

DTG

E/R

EADI

ECC

ECLSS

ECMA

ECP

ECS

EOF

EEE

EHF

EHSI

EIA

EL

EM

EMC

EMCFA

EME

EMI

EMR

EMS

EMU

EMUDS

EO

EOL

EOS

EPA

EPS

ERBE

ERRP

ESR

ESTL

EVA

F/T

FACC

FADS

Design to Cost/Life Cycle Cost

Design To Grow

Entity/Relationship

Electronic Attltude Direction Indicator

Error Correction Codes

Environmental Control and Life-Support System

European Computers Manufacturing Assoc.

Engineering Change Proposals

Environmental Control System

Engineering Data Functton

Electrical, Electronic, and Electromechantcal

Extremely Htgh 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 Unlt

Extravehicular Maneuvering Unlt Decontamination System

Electro-optlc

End of Life

Earth Observing System

Environmental Protection Agency

Electrical Power System

Earth Radiation Budget Experiment

Equipment Replacement and Refurbishing Plan

Engineering Support Request

Electronic Systems Test Laboratory

Extravehicular Activity

Fault Tolerant

Ford Aerospace and Communications Corporation

Functionally Automated Oatabase System

xiv
FAR

FCA

FCOS

FCR

FOOI

FOF

FOMA

FEIO

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

_As

GaAsP

GalnP

GaP

GAPP

Federal Acquisition Regulation

Functional Configuration Audit

Fllght Computer Operatlng System

Fllght Control Rooms

Fiber Distributed Data Interface

Fltght Dynamics Factltty

Frequency-Olvlslon Multtple Access

Flight Equipment Interface Device

Floating 6ate Electlon Tunneling Metal Oxtde Semiconductor

Free Flter

Fast Fourier Transform

First In Ftrst Out

Federal Information Processing Standards

foot lambert - Unlt of Illumination

Factltty Management

Fatlure Modes and Effects Analysts

Fatlure Mode Effects and Criticality Analysts

Fiber-Optics

Fall-Operational/Fall Safe/Restorable

Fiber-Optic Cable

Fiber-Optic Data Bus

Fiber Optlc Demonstration System

Federal Procurement Regulation

Formal Qualification Review

Full-Scale Development

Flight Support Equipment

Full Scale Englneerlng Development

Functlonal Simulator

F11ght Software

Fault Tree Analysis

Fault Tolerant Multi-Processor

Fault Tolerant Space Computer

Gallium Arsenlde

Gallium Arsenic Phosphorus

Galltum [ndlum Phosphorus

Galltum Phosphorous

Geometric Arithmetic Parallel Processor

XV
6bps

6BSS

6EO

GEP

GFC

GFE

6FP

GFY

6IDEP

GRM

GMS

6NT

GMM

6N&C

GPC

6PP

GPS

6RO

GSC

GSE

6SFC

GTOSS

H/kl

HAL

HDDR

HDDR

HEP

HFE

HIPO

HIRIS

HNI

HM

HOL

HOS

HPP

HRIS

I

Gtgablts Per Second

Ground Based Support System

Geosynchronous Earth Orbit

6as Election Phosphor

6round Forward Commands

6overnment-Furntshed Equipment

Government-Furnished Property

6overnment Fiscal Year

Government/Industry Data Exchange Program

Geometric Math Node1

6eostattonary Meteorological Satellite

Greenwich Mean Time

Genertc Ratntenance Work Station

6uldance, Navigation, and Control

6eneral-Purpose Computer

6eneral-Purpose Processor

Global Positioning System

Gamma Ray Observatory

Ground Servtce Center

ground Support Equipment

(Robert H.) 6oddard Space F]tght Center

Generalized Tethered Object System Simulation

Hardware

High-Order Algorithmic Language

Help Desk Discrepancy Report

High Denslty D1gltal Recordlng

Heterogeneous Element Processor

Human Factors Englneerlng

H1erarchlcal Input Process Output

High Resolutlon Imaglng Spectrometer

Habltatlon Module One

Habltatlon Module

High Order Language

High Order Systems

High Performance Processors

High Resolutlon Imaglng Spectrometer

Interactlve

xvi
I/F

I/0

IBM

IC

ICAM

ICB

ICO

ICOT

ICS

IO

I0

IOM

IDMS

IEEE

IEMU

IF

IFIPS

ILO

IMU

INS

IOC

lOP

IPCF

IPC

IPL

IPR

IPS

IR

IR&O

IRN

ISA

ISA

ISON

ISO

ITAC-O

ITT

IV&V

Interface

Input/Output

IBM Corporation

Intercomputer

Integrated Computer-Aided Manufacturing

Internal Contractor Board

Interface Control Document

Institute (for new generatlon) Computer Technology

Interpretlve Computer S1mulatlon

Interface Olagram

Identlflcatlon

Intelllgent Oatabase Machlne

Information and Oata Management System

Instltute of Electrlcal and Electronlc Engineers

Integrated Extravehicular Mob111ty Unlt

Intermediate Frequency

International Federatlon of Industrlal Processes Soclety

Injector Laser Olode

Inertial Measurement Unlt

Inertial Navlgatlon System

Inltlal Operatlng Capability

Input/Output Processor

Interprocess Communications Fac111ty

Interprocesses Comunlcatlon

Initial Program Load

Internal Problem Report

Instrument Polntlng System

Infrared

Independent Research and Development

Interface Revlslon Notices

Inertial Sensor Assembly

Instructlon Set Architecture

Integratlon Servlces Olgltal Network

Internatlonal Standards Organization

Integratlon Trades and Analysls-Cycle 0

Internatlonal Telegraph and Telephone

Independent Validation and Verlflcatlon

xvii
IVA

IMS

JPL

JSC

KAPSE

KEE

KIPS

KOPS

KSA

KSC

Kbps

Klpc

LAN

LaRC

LCC

LCD

LDEF

LDR

LED

LEO

LeRC

LIDAR

LIFO

LIPS

LISP

LtsP

LLC

LNI

LN2

LNA

LOE

kOE

LOS

LPC

LPS

LRU

LSA

Intravehlcular Actlvlty

Inte111gent Nork Statlon

Jet Propulslon Laboratory

(Lyndon B.) Johnson Space Center

Kernal APSE

Knowledge Englneerlng Envlronment

Knowledge Informatlon Processlng System

Thousands of Operatlons Per Second

Ku-band, Single Access

(John F.) Kennedy Space Center

K11oblts per second

Thousand Instructlons per cycle

Local-Area Network

Lang]ey Research Center

Life-Cycle Cost

Ltqutd Crystal Dtsplay

Long-Ouratton Exposure Faclllty

Large Deployable Reflector

Light-Emitting Diode

Low Earth Orbit

Lewis Research Center

Laser-Instrument Distance and Range

Last In Flrst Out

Loglcal Inferences Per Second

Ltst Processor

Llst Processor

Loglcal Ltnk Control

LISP Machlne Inc.

Ltqutd Nttrogen

Low-noise Amplifier

Level of Effort

Low-earth Orbtt Environments

Loss of Stgnal

Linear Predictive Codtng

Launch Processing System

Line-Replaceable untt

Logistic Support Analysts

xviii
LSAR

LSE

LSI

LTV

LZPF

M

pP

MA

MA

MAPSE

Mbps

MBPS

MCAIR

MCC

MCC

MCDS

MCM

MCNIU

MDAC-HB

MDAC-STL

MOB

MDC

MDMC

MDRL

MFLOP

MHz

MIMO

MIPS

MIT

MITT

MLA

MMI

MMPF

MMS

MMS

MMU

Logistic Support Analysis Report

language Senslty Editors

Large-scale Integration

LTV Aerospace and Defense Company, Vought M1sslles Advanced

Programs Olvlslon

Level O Processlng Facility

Manual

Microprocessor

Multlple Access

Managlng Actlvlty

M1nlmum APSE

Mllllon Bits Per Second

M1111on Blts Per Second

McDonnell Aircraft Company

Mlsslon Control Center

Mlcroelectronlcs and Computer Technology Corp.

Management Communlcatlons and Data System

Mllttary 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

Multlple-lnput Multlple_Output

Million (machine) Instructions Per Second

Massachusetts Institute of Technology

Ministry of International Trade and Industry

Multlspectral Linear Array

Man Machine Interface

Mlcrogravlty and Materials Process Facility

Module Management System

Momentum Management System

Mass Memory Unlt

xix
MMU

MNOS

MOC

MOI

MOL

MOS

MPAC

MPS

MPSR

MRMS

MRWG

MSFC

MSI

MSS

MTA

MTBF

MTTR

MTU

NASA

NASCOM

NASPR

NBO

NBS

NCC

NFSO

NGT

NHB

NISDN

NIU

NL

NLPQ

NMI

NMOS

NMR

NOS

NS

NSA

Manned Maneuverlng Unit

Metal-Nltrlde Oxide Semiconductor

Mission Operations Center

Moment of Inertia

Manned Orbiting laboratory

Metal Oxide Semiconductor

Multipurpose Application Console

Materials, Processing in Space

Multl-purpose Support Rooms

Mobile Remote Manipulator System

Mission Requirements Working Group

(George C.) Marshall Space Flight Center

Medlum-Scale Integratlon

Multlspectral Scanner

Man-Tended Approach

Mean Time Between Failures

Mean Time to Repair

Master Timing Unit

National Aeronautics and Space Administration

NASA Communications Network

NASA Procurement Regulation

NASA Baseline

National Bureau of Standards

Network Control Center

NASA FAR Supplement Olrectlve

NASA Ground Terminals

NASA Handbook

NASA Integrated System Oata Network

Network Interface Unit

National Language

National language for Queuing Simulation

NASA Management Instruction

N-Channel Metal-Oxlde Semiconductor

N-Modular Redundant

Network Operating System

Nassl-Schneldermann

National Security Administration

XX
NSF

NSTS

NTDS

NTE

NTRL

NTSC

Nd:YAG

O&M

O/B

OASCB

OCN

OOB

OOBMS

OEL

OES

OlD

OLTP

OMOC

OMV

ONR

ORU

OS

OSE

OSI

OSM

OSSA

OSTA

OSTDS

OTV

P&SA

P/L

PA

PAM

PASS

PBX

PC

PCA

National Science Foundation

National Space Transportation System

Navy Tactical Data System

Not To Exceed

NASA Technology Readiness Level

National Television Standards Committee

Neodynlum Yttrium Aluminum Garnet (laser type)

Operations and Maintenance

Onboard

Orbiter Avionics Software Control Board

Operations and Control Network, Operational Control Networks

Operational Data Base

Onboard Data Base Management System

Operating Events Ltst

Operating Events Schedule

Operations Instrumentation Data

On Llne Transaction Processing

Operations Management and Control Center

Orbital Maneuvering Vehicle

Office of Naval Research

Orbital Replacement Unlt

Operating System

Orbit Support Equlpment

Open Systems Interconnect

Orbltal Servlce Module

Offlce of Space Sclence and Appllcatlons

Offlce of Space and Terrestrlal 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 Conflguratlon Audit

xxi
PCA

PCM

PCR

PDP

PDR

PORO

PDRSS

PZLS

PIN

PLA

PLAN

PLSS

PMAD

PflC

PN

POCC

POP

POPCC

POPOCC

PRISM

PSA

PSA

PSCN

PSL

PTR

QA

R

R&D

R&QA

R/M/A

R/T

RAD

RAM

RAP

RC

RCA

RCS

Program Change Authorization

Pulse Code Modulation

Program Change Request

Plazme Display Panel

Preliminary Design Revlew

Program Definition and Requirements Document

Payload Deployment and Retrieval System Simulation

Payload Integration Library System

Personal Identification Number

Programmable Logic Array

Payload Local Area Network

Payload Support Structure

Power Management and Distribution

Permanently Manned Configuration

Pseudonolse

Payload Operations Control Center

Polar Orbiter Platform

Polar Orbit Platform Control Center

POP Operations Control Center

Prototype Inference System

Problem Statement Analyzer

Preliminary Safety Analysis

Program Support Communications Network

Problem Statement Language

Problem Trouble Report

Quality Assurance

Restricted

Research and Development

Reliability and Quality Assurance

ReliabilityMaintainabilityAvailability

Real Time

Untt of Radiation

Random Access Memory

Relational Associative Processor

Rtng Concentrator

RCA Corporation

Reaction Control System

xxii
ROB

RDC

REN

RF

RFC

RFI

RFP

RGB

RID

RID

RISC

RMS

RMSE

RNET

RON

ROTV

RPRS

RS

RSA

RTX

S&E

S/C

S/W

SA

SA

SAAX

SAE

SAIL

SAIS

SAR

SAS

SASE

SATS

SBC

SC

SCR

SCR

relatlonal Data Base

Reglonal Data Center

Roentgen Equlvalent (man)

Radlo Frequency

Regeneratlve Fuel Cell

Radlo Frequency Interference

Request for Proposal

Red-Green-Blue

Revlew Item Disposition

Revlslon Item Description

Reduced Instruction Set Computer

Remote Manipulator System

Root Mean Square Error

Reconftguratton Network

Read Only Memory

Reuseable Orbtt Transfer Vehtcle

Resource Planntng and Management System

Reed-Solomon

Rlvest, Skamlr and Adleman (encryptlon method)

Real Time Executlon

Sensor and Effector

Spacecraft

Software

Single Access

Structured Analysls

Sclence and Technology M1sslon

Soclety of Automotlve Englneers

Shuttle Avlonlcs Integratlon Laboratory

Sclence and Appllcatlons Informatlon System

Synthetlc Aperture Radar

Software Approval Sheet

Speclflc Appllcatlon Servlce Elements

Statlon Accommodatlons Test Set

Single Board Computer

S1mulatlon Center

Software Change Request

Solar Cosmlc Ray

xxiii
SCS

SDC

SOP

SDR

SDTN

SE&I

SEI

SESAC

SESR

SESS

SEU

SFOU

SI

SIB

SIFT

SIMP

SIRTF

SLOC

SMC

SMT

SNA

SNOS

SNR

SOA

SOPC

SOS

SCXMI

SPC

SPF

SPF

SPR

SPR

SQA

SQAM

SQL/DS

SRA

SRAM

Standard Customer Services

Systems Development Corporation

Subsystem Data Processor

System Design Review

Space and Data Tracking Network

Systems Engineering and Integration

Software Engineering Institute

Space and Earth Scientific Advisory Committee

Sustaining Engineering System Improvement Request

Software Engineering Standard Subcommittee

Single Event Upset

Standard Format Data Unit

International System of Units

Simulation Interface Buffer

Software Implemented Fault Tolerance

Single Instruction Multi-Processor

Shuttle Infrared Telescope Facility

Source Lines of Code

Standards Management Committee

Station Management

System Network Architecture

Silicon Nttrlde Oxide Semiconductor

Signal to Noise Ratio

State Of Art

Shuttle Operations and Planning Complex

Silicon On Saphtre

Statement of Work

Stored Payload Commands

Software Production Facility

Single-Point 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 Englneerlng Methodology

Stanford Research Institute

Safety, Rellab111ty, Malntalnablllty, and Ouallty Assurance

Shuttle Remote Manlpulator System

System Requirements Review

Space Statlon

Structural Systems Analysis

S-band Single Access

Space Station Control Board

Station Station Communlcatlon Center

Support Software Change Request

Space Station communlcatlon system

Space Statlon communlcatlons and tracking system

Space Station data management system

Support Software 01screpancy Report

Space Station data system

Software Support Envlronment

Software Support Environment Facility

Space Station Information System

Space Shuttle Maln Englne

Source Selectlon Offlclal

Space Statlon Operations Control System

Si)ace Statlon Operations Control Center

S)ace Station Operation Language

S}acelab Software Operational Notes

S)ace Station Operatlng System

S}ace Statlon Program

S}ace Statlon Program Element

S)ace Statlon Program Office

S)ace Statlon Standard Computer

S}ace Station System Trainer

Self Test and Recovery (repair)

Software Technology for Adaptable and Rellable Software

Standard Number

Standard Technical Institute

xxv
STO

STS

SUSS

SYSREM

SI

SubACS

TAI

TBD

TBU

TC

TCP

TCS

TDASS

TDM

TDMA

TDRS

TORSS

TFEL

THURIS

TI

TH

TM

TMDE

THIS

THP

THR

THS

TPMG

TR

TRAC

TRIC

TSC

TSIP

TSP

TSS

TT&C

TTC

Solar Terrestrial Observatory

Space Transportation System

Shuttle Upper Stage Systems

System Requirements Engineering Methodology

Silicon

Submarine Advanced Combat System

International Atomic Time

To Be Determined

Telemetry Buffer Unit

Telecommand

Transmissions Control Protocols

Thermal Control System

Tracking and Data Acquisition Satellite System

Technology Development Mtsslon

Time-Division Multiple Access

Tracking and Data Relay Satellite

Tracking and Data Relay Satellite System

Thtn Ftlm Electrolumenescent

The Human Role tn Space (study)

Texas Instruments

Technical Manual

Thematic flapper

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 Palr

Tethered Satellite System

Telemetry, Tracking, and Communications

Telemetry Traffic Control

xxvi
TTR

TMT

U

UCC

UDRE

UIL

UON

UPS

URN

UTBUN

UTC

V&V

VAFB

VAX

VHSIC

VLSI

VLSIC

VV&T

WAN

WBS

MBSP

WDM

WP

MRO

MS

WSGT

WTR

XDFS

YAPS

ZOE

ZONC

ZnS

Timed Token Rlng

Travellng-gave Tube

Non-restrlctlve

Unlform Commerclal Code

User Oeslgn Revlew and Exercise

User Interface Language

Unlque Object Names

Uninterrupted Power Source

Unlque Record Name

Unlque Telemetry Buffer Unlt Name

Unlversal Coordlnated Time

Valldatlon and Verification

Vandenberg Alr Force Base

Virtual Address Exchange

Very Hlgh-Speed Integrated Clrcult

Very Large-Scale Integration

Very Large-Scale Integrated C1rcult

Valldatlon, Verlflcatlon and Testing

Wlde Area Network

Work Breakdown Structure

Wldeband Signal Processor

Wavelength Olvlslon Multlplexlng

Work Package

Work Release Order

Workstatlon

Whlte Sands Ground Termlnal

Western Test Range

XEROX Distributed Ftle System

Yet Another Production System

Zone Of Exclusion

Zone Of Non-Contact

Zlnc Sulftde

xxvii
Volume III

TASK 2 - OPTIONS DEVELOPMENT

3.0 PROGRAMMATIC OPTIONS

SUMMARY

This volume contains the options development for the Programmatic Options

Category. The specific programmatic options and their respective volume Ill

section numbers are as follows:

3.0

3.1

3.2

* 3.3

* 3.4

3.5

PROGRAMMATIC OPTIONS

Standardlzatlon/Commonallty

System Management

Deleted

Deleted

System Development

3.5.1 Hardware Procurement

3.5.2 Software Development

3.5.3 System Integration Test & Verification

For the Options Development general approach and methodology the reader is

referred to the introductory sections of Task 2, Options Development, Volume I.

* These items have been deleted or incorporated into other sections.
3.0PROGRAMMATIC OPTIONS

PI_ECEDINGPAGE BLANK I_IOT
April 16, 1985

3.1 STANDARDIZATION/COMMONALITY OPTIONS

The purpose of this report is to describe options

associated with standardization and commonality. Many aspects

of the Space Station Data System are subject to standards. Table

3.1-1 lists those that are discussed in this report.

TABLE 3.1-1

COVERED TOPICS

Communciation

Data Base Management Systems

Coding

Quality Assurance Software

Quality Assurance Hardware

Hardware

Safety

Reliability

Maintainability

Logistics

Procurement

Video

Audio

The Space Station Definition and Preliminary Design Request

for Proposal, August 20, 1984, specifies several requirements

among which are:

"The need for commonality of the system will be a key driver

in the Space Station Program design. The long life on

orbit, the need for maintainability,...all dictate that the

different onboard systems and subsystems need to be

minimized."

"The indefinite life of the Space Station Program imposes

the requirement for management of changing technology."

In a real sense, these requirements conflict as

standardization, implied by the former requirement, will in time

be overrun by technology change. A very important concern about

standardization is the question of how to balance the need for

standard hardware and software elements with the requirement

accommodate new technology. The use of "Standards" can lead

the continued use of obsolete technology if standards are

carefully planned to allow for cost-effective insertion of

technology. Future obsolescence of existing technology and

need for

conflicts.

to

to

not

new

the

infusion of new technology represents potential

The following sections discuss the topics appearing in Table

3.1-1.
3.1.1 Communications ProtocolInterface Standards

This section describes the options for standardization of

communications interfaces in the Space Station Program. The

options are described for both space and ground, and the

International Standards Organization's (ISO) model for Open

Systems Interconnection (OSI) is used.

A comprehensive review of communications standards is beyond

the scope of this paper. The purpose is to:

o restrict discussion to options related to the Space

Station Program, using the results of Task 1 to

focus options

o describe options for the end-to-end standards

architecture

o overview requirements for

each ISO/OSI level

standardization within

o provide references to detailed descriptions of the

standards.

The first part of this section (Section 3.1.1.1) provides an

overview. The second section (Section 3.1.1.2) discusses each

ISO layer in detail and provides SSDS requirements and candidate

standards options for the layer.

Much interest has been expressed in how standards resulting

from the ISO model, and emerging standards for packet telemetry,

might impact the SSDS. The third part of the paper (Section

3.1.1.3) thus concentrates on discussing option_ for how

telemetry and telecommand standards (from the Consultating

Committee for Space Data Systems) and network standards

(consistent with the ISO/OSI model) might be implemented in an

end-to-end architecture for the SSDS.

3.1.i.i Communications Standards Options Overview

The SSIS will include:

o on-board Data Management System including local area

communications networks,

o TDRSS links between space and ground,

o a ground wide area communication network, and

o local area networks on the ground,

NASA facilities.

at NASA and nonCommunication standards will be selected for each of the

interfaces and links for these networks. This section uses the

ISO/OSI model to describe communications functions and standards
options for these networks and links. In addition to providing a

basis for describing standards and their functions, various

organizations (ISO, CCITT, etc.) are developing standards that

are compatible with the ISO/OSI model.

The ISO/OSI model is a natural choice since (a) it is

comprehensive (b) it has international acceptance and (c) it is

expected that many vendors will be producing equipment compatible

with these standards. The fact that a very large base of

worldwide suDDort is exDected to exist outside of NASA for OSI

standards will likely demand lower prices, off-the-shelf hardware

and software, and extendable services and networks.

Standards needed by Space Station have also been proposed by

other organizations. Specifically, the Consultive Committee for

Space Standards has developea standards for:

o Telemetry Packets, Frames, Channel Coding

o Telecommand packets, Frames, Channel Coding

o RF & Modulation

o Time Codes

Specific requirements with respect to

reflected in Section 5.3.8.9 of the Task

illustrated on the next page.

standards, as

1 report, are
Requirements from Task 1 Report

"The SSDS shall provide standardized language, protocol, format,

and transmission rates for all SSDS and all SSDS subsystems."

"As a first preference, customer interface standards

defined in accordance with the International

Organization (ISO) sevem layer model for Open

Interconnect (OSI)."

shall be

Standards

Systems

"The SSDS shall use, for each of the seven layers, existing

internationally accepted standards as a first priority followed

by new standards development (within the OSI model framework)."

"The customer interfaces defined within the first three layers of

the OSI model shall conform to standards defined and controlled

by such sources as:

NBS, National Bureau of Standards

ANSI, American National Standards Institute

ECMA, European Computer Manufacturing Association

CCITT, Consultative Committee

Telegraph and Telephone

for International

EIA, Electronic Industry Association

CCSDS, Consultative Committee for Space Data Systems

IEEE, Institute of Electrical & Electronic Engineers

"When practical, appropriate standards from these sources shall

be used at higher layers of the OSI model."

"The SSIS/SCS (per Figure 1-2, includes SSDS and

elements) shall obtain and/or develop standards for

interfaces in areas such as software, critical/limited

health and safety monitoring, man-machine interfaces,

generation, time code, attitude and position data,

coordinate systems, data base management systems,

non-SSDS

customer

payload

command

pointing

graphics

displays, data handling/archiving/distribution, documentation,

configuration control, cost accounting, data system requirements

definition, operations audit trail, etc. When new customer

standards are proposed, the SSIS/SCS shall present these

standards to a customer panel which will provide an impact

statement on behalf of all customers."
The selection of standards approaches gain importance wren

viewed as broad requirements of the Space Station Program:

o Migration - functions are expected to migrate fro_,

the ground to on-board over time. Thus, initially

one would expect an on-board process to be

communicating with the ground, and later with the

same process implemented on-board. It will be

critical to be able to perform this migration while

minimizing the impacts on the existing on-board

software. Layering, and a flexible set of services

as reflected in the choice of standards, are

essential to support this.

o High Data Rates - suggest the need to handle and

transport data in as automated a fashion as

possible, with a minimum of re-configuration.

Standards can be a significant aid in reducing costs and

ensuring that customers are well served. For example, one would

not want to require customers to use unusual communications

equipment or to receive their data in different formats depending

on the source. There are also dangers to standardization. For

example, one can get "locked in" to a specific technology. Thus,

a careful selection must be made of where and when to

standardize, based on the requirements.

3.1.1.1.1 ISO/OSI Model description

The ISO/OSI model identifies seven layers which correspond

to levels of abstraction, each layer performing a well-defined

set of functions. The layers of the model are described in Table

I.
ORIGINAL PAGE iS

OF POOR QUALITY

p p i i ,-.---ti o_-,

P r.e.-.er,tat i on

Tr._.nsp oft

Pr.ovi._es r.outi'r, es _peci?ic U.o a'r_

ap F'I ic .---'t i or,. A i i ,_-,,_,._= .=PF'I i c .=-t.i o_-,.-_-

,-n-,._iFFer.e_-,t. _-,o.He.-.t.c, c ommu:,-,i ¢ -_t.e.

Per.Form.-. .--.u{ch.-.er..,.ices as t.e>:t.

,_-,DmF'r-e-.sion, File ?or-matin-,9,

Responsible 6or. est.ablisP, ir,9 .---'r,.d

ma_nagim 9 ,_-omnection-_-. _et._e-=n t._o

pr.oce.-..--.e.--,am_ S"o_ me,:over_ o÷"

?ailu,.r.es at. the t.r-anspor.t l aL4er.

St..=-n._ar_s at this level also

pro%_i.Me For-autt.hen_iFi,,,-ation,

_.-i1 1 it,9, ar, M agmeement, om

par.=:meters iv, eFFect For a

se=_.s i or,.

Accepts _ata in message Fo_m From

session lawer, 5.teaks it do_,r, into

smaller pieces iF required b9

net_,omk, and vice vemsa, Standam_s

at this lewel also pr.oi.-He For hosthost co_ection 8,. ?Io_,. ,,,ontr-ol .

ISO/0SI Layers

Table 1

I0
OR_'G!NAL PAGE IS

OF POOR QUALITY

r,,ie t ,,_,¢,.,'-.I-:

F'_-__vi .-_es For- r.c,u..ti_ 9 .=*._-,._ cc,_-,ge._=ti @_-,

,:o_-,tr-'¢,l. St._-,_.=-r_---. ---t thi-- !evel

-_i Ic,,_,r.ou:t,ir,9, se,guence._ Sel i .,.er.,_

co_ge-t, io_n :o_t_c_l , .-_..-,d=.-cco,a._ti_@

1:ur,c_..io_,_. For .::t.--.ta tr.z,_.Fe_s

Det_,eer, =_ COmF. u.t.er, a_.-_ a _,et._,or.k.

E:,--.t.--:L i;-ik

F'hgs i cal

Responsible For pr'c,vidin? .---.r,er._-or

Fr.ee i i_e. Per._or-.ms _"rami_9, e_r-or-

•_et.ectio_,, se,_uer, cin9, time out an-_

ack_o_le-_geme_t, a_n._ _'Io_ co_t._ol.

Re=_.por, sible _:c,r data tr.ar, smissior,

over- a phgsical i_t.e_+'_.ce.

Table i (Continued)

11
Systems which are implemented with standards consistent with

OSI are "open" in that different systems, from different

manufacturers, can intercommunicate.

Each layer has three interfaces:

o an interface to the layer above

o an interface to the layer below

the "peer" protocol to another instance of the layer

on a different system.

The Application layer has an interface to the applications

processors and proccessors above requesting or responding to the

OSI services below. The physical layer has an interface to the

common communications media below. Application interfaces

between systems is accomplished by the sender calling on services

of the layer below, and the receiving system sending up data

through layers to the application.

Typical protocols apply to the last item only and are the

subject of this section. The ISO/OSI model is, indeed, a model

and not a specification for an implementation. In

implementation, one system might have all seven layers

implemented within one program, while another might have seven

sets of code (Hollis). The definition of the first two

interfaces listed above are thus the responsibility of the Space

Station Program. Although they are not discussed in this

section, their definition is critical and may be a development

driver in the Space Station Program (McKay).

3.1.1.i.2 CCSDS Standards Model Description

The CCSDS standards are oriented to the noisy space-to-space

and space-to-ground links. Standards are described for telemetry

and for telecommands, as outlined in Table 2.

12
ORIGINAL PAGE IS

OF POOR QUALri'Y

z

3

Telemetr._ F'=..cket

T__lemetr._

T r-a_-,_.Fe r. F r-a'Jr,e _.

re i emetr9

C ha_e 1

C o._ ir,9

R F 8,. Mo.::lul at. i on

:-:t.--.r,.dat. d .da _... a s t _ ,J.ct u:r e

u_se.-_ to t.r.a'r,s;,oft ,_,.set.

_at.a, e. 9 .. b.et._,ee_-, .--.e_nsor._

i'm, .sp-_ce a'r,._ u.ser. _at.a

F,moce_si;-,9 F aci ! itiec_.

P ac k et. i _. a;-, " ob.-.er.v=--t.ior,"

to be _eliver.e._ i',-,t._ct t,o

,a.ser.. Packet= mz,_ be broker,

ir, t.o s.egmer, t.-=. _of t.r..=.r, sport..

Stan._ar.-_ .data sbr_ct.u.re For

t.r.ar,smi =-.sior, o? pack et.__.

whet, the_ are trar, smit.te_

Fr" om -_p ac ec _ aF't -t o- _at.a

c$.pt_clr-e e! emer, t. Fr.--.mes

encapsula_e packets.

Mechar, isms applied at

commumicat.ions 9ate_a,ds

to protect, the t,rams?er

?r_mes against error.

RF S t,ar,_ar ¢Is

CCSDS Layers

Table 2

13
ORIGINALPAGEIS

poor quALrrY

F ,=-c _: e t.

T r .Kl-t'-.6__ r

_" r'.aTI1_

St.a_-,._ar.0 ._ata str.uct._Lre. _P, ich

e_c_p __.u.la+_e_ t.el ecomma_O pack e_._.., u.=_.e._

+_o t.r.a_,!.F.c,r% telecomma_,d F,=_cket _,P,er,

the_ ape t.rar,=_._,it.ted f'r.om a co_,_,a._,.di_,9

poi_t. (-_-.pace or _q_o_-,O) _o t.he pa_loaO

St.ar, dar.._ commar,.d oper.atir, 9 pr.oce.du.Pes

a_e e:_:ecut.ed t.o co,_,trol acceptar, ce o_"

Di __ePent 6"r.om Cel e_,etP,_ 6'r.a_,e=.

C h.--:w,_,e!

CoOi_9

Ple,:hanisms _o protec*. Celecommand

Fr.a'me=.. agaiw,=_.t, er-r-or" a=_. t_h,e_H F,a-_s t_hr.c,ugh

•_pace .-_ata cha_el$

i

RF _. _lo.dcdation RF $t_ar, Oar ds

Table 2 (Continued)

14
A discussion is provided on how each CCSDS standard might

map into the ISO/OSI model in section 3.1.1.2 in response to

comments on the draft of this section. There are differing

opinions on how the CCSDS standards map to the ISO. These

differences of opinion likely result from the fact that the CCSDS

standards were developed for a different purpose than standards

developed directly from the ISO model. Specifically, an early

CCSDS presentation stated that (Hooke):

- for the ground, ISO/OSI compatibility was assumed.

for space, commercial standards were viewed as

applicable. However, due to the cost of space data

links, some general purpose ground protocols were

viewed as not applicable, on the grounds of

transmission efficiency.

- accordingly, the CCSDS standards would "wrap around"

the OSI standards.

Specifically, it was expected that standards consistent with

the ISO model would be used to augment the CCSDS standards by

providing (Review Comments):

o services for on-board local area data distribution

o services for the distribution of data

There are several options for how this "wrap around" might

be implemented. These options, which are described in Section

3.1.1.3, describe how one would select and apply the CCSDS and

ISO standards to implement an end-to-end standards architecture.

3.1.1.1.3 Commercial Models Option Description

In addition to ISO and CCSDS, commercial models also exist

for standards. An example is the IBM Systems Network

Architecture. A disadvantage of such frameworks is that, once

used, hardware and software from other vendors is difficult to

interface. The system is, in this sense, not "open." For this

reason, and since the NASA requirements described above state

that the SSDS standards will be described following the ISO

model, these models will not be discussed further in this

section.

3.1.1.2 Standards Options Within The ISO Layers

The sections which follow identify, for each

standards options which exist, and possible areas

standards development may occur.

ISO layer,

where new

Only those aspects of standards involving inter-process

communication are covered within the OSI environment, and within

this section. Thus, standards for application-to-application

communication are covered, while the interface between the

15
application layer and the layers below is not covered.

The trends for within the layer have been:

o a significant amount of agreement on standards for

data communication at the lower levels (one-tothree).

o more standardization over time as one "moves up"

levels 4-7.

Within ISO, a standard has three levels of status:

o Draft Proposal

o Draft International Standard

o International Standard

3.1.1.2.1 Application Layer Standards

3.1.1.2.1.1 Option Description

The application layer provides standards specific

particular application, allowing for applications on

processors to communicate. The application layer

divided into two sublayers:

o specific application service elements

o common application service elements

Common application layer service elements include

Hindin):

- login

- password checks

- set up associations to named peers and agree on

semantics of the information to be exchanged.

Specific application service elements include

Hindin):

- file transfer & access

- virtual terminals

- message handling

- document transfer

- job transfer & manipulation

to a

different

has been

(Rauchthe

(Rauch18
- video text

- graphics

- transaction control, real time control

- commitment, concurrency & recovery

industry protocols (e.g.. purchase orders, credit checking.

invoice, inventory)

Specific protocols at the application layer are beginning to

be defined. They support communication of the "semantics" or

meaning between two applications. Application protocols under

definition for OSI are:

o Virtual Terminal Service (Lowe) -- several protocols

for distributed terminal applications (RauchHindin):

- Basic Class Virtual Terminal (Draft - 2/85)

- Forms Class Virtual Terminal

o File Service (Lewan & Long) -- defines a standard

for transferring, accessing, and managing

information stored in or moved between systems as

files. (Draft 11/83, Draft International Standard,

2/85) (Rauch-Hindin)

o Management & Job Transfer Services (Langsford,

Naemura, Speth) -- defines standards for control of

distributed processing applications (Draft 7/84 -

Rauch-Hindin)

o Message Handling Protocol -- defines

allow interconnection of electronic

(Draft, fall, 1984 -- Rau_h-Hindin)

standards to

mail systems

o Directory (Draft, 2/85)

o Office Document Interchange Facility

o Commitment, Concurrency,

Rauch-Hindin)

& Recovery (Draft 7/84,

o Formal Description Language & Techniques (Draft

2/85, Rauch-Hindin)

o Common Application Layer Service Elements (Draft,

2/85, Draft International, 12/85, Rauch-Hindin)

o Purchase Order Creation & Update (Draft agreed to in

ANSI, Rauch-Hindin)

17
The CCSDSTime Code Standard maps to the Application Layer.

The CCSDSTelemetry Packet Standard provides the following

services:

o formatt[ng of user data

o support for the services of accounting, correlation,

delimitating and interpretation of customer data

o formatting of ancilliary data

The CCSDS Packet & Telemetry & Telecommand Standards has

been proposed as mapping to:

o the application data, outside of the £SO data system

protocols,

o an application layer protocol, providing an industry

specific standard,

o the presentation layer, providing special purpose

formatting, as described in the previous section

(McKay),

o the transport layer, providing a special purpose

space-to-ground transport standard (Carper),

o a special protocol applied for the downlink, outside

of the ISO data system protocols,

o a standard providing services of the network,

presentation, and application layer combined (CTA).

The standard is viewed as a data formatting convention that

provides the basic, core set of labelling message structures to

support space missions within an adaptive distributed system

(review comments). In this regard, the SSDS is required to

support the need to support multiple payloads, owned by different

customers, in a way that minimizes interactions between customers

and a minimum of software re-configuration as this mix of

customers changes.

Thus, most or all data is required to be multiplexed into a

single TDRS downlink/uplink in the form of complete, autonomous,

self-identifying data units (telemetry/telecommand packets). A

related application requirement relates to the provision of

ancilliary data (Task i, Section 5.3.2.4):

o the SSDS shall provide ancilliary avionics and

housekeeping data (timing, state vector, RF

communication, System Status, Acquisition of

Signal/Loss of signal, moding, pointing, etc.) to

the attached payloads and customers.

18
3.1.1.2.1.2 Applications Options Characterization

Protocols in the application layer are in a less advanced

state than the lower levels. Many de-facto standards exist,

generally tied to vendor architectures (e.g., DECnet), specific

operating systems (e.g., the Unix interprocessor file transfer

services), or specific networks (e.g., the ARANETFile Transfer

and Remote Login services). An approach is being developed to

extend access control requirements of the proposed military

standard for CommonAPSE Interface Set (CAIS) (LeGrand). (The

CAIS is a basic software interface lifecycle for DOD mission

critical computer systems). In this approach, access control is

provided within the ISO framework and building on the ISO Virtual

Filestore.

Single vendor protocols (e.g., DECnet or SNA) generally

extend through all seven layers of the ISO model and vendors have

attempted to map their architectures to ISO. The use of such a

protocol is, of course, an option for the entire SSDS or for

subnetworks, but as discussed previously, we are emphasizing

standards of a more general nature. Of major significance, as

the NBS's cooperative work with more than 30 computer and

semiconductor manufacturers and developing applications layer

standards supporting file transfer protocols for local area

networks based on the IEEE 802 physical and data link standards.

These efforts are the broadest practical attempts to standardize

protocols throughout the ISO hierarchy, with working intervendor

network already demonstrated.

Candidate protocols within the application layer

are:

for SSDS

ISO CommonApplication Services Elements (CASE's) and

Specific Application Service Elements (SASE's);

(ISO/TC97/SCI6) which include File Transfer Service,

Virtual Terminal Service, and the Job Transfer and

Manipulation Service.

ISO Message Handling Services (ISO/TC97/SCIS)

NBS Message Handling Services (ISO/TC97/SC18)

NAPLPS/ANSI Standard X3.110 Graphics Standards

CCSDS Packet Standard (present or modified)

3.1.I.2.2 Presentation Layer

3.1.i.2.2.1 Presentation Layer Options Description

The presentation layer provides independence to applications

from differences in the representation of data -- in its

"syntax." The presentation level protocols negotiate the

transfer syntax for character sets, text strings, data display

19
formats, graphics transfer, file organization,

financial information (Rauch-Hindin).

data types, and

Candidate services for the presentation layer include:

o Code Conversion (e_g., ASCII-to-EBSDIC)

o Privacy Services -- encryption

o Data Compression

o Protocol for negotiation of syntax

Draft OSI standards for the presentation layer are expected

in 1984 (Day & Zimmerman), and a Draft International Standard is

expected 2/85 (Rauch-Hindin).

The SSDS requirements on the Presentation Layer are less

than what may be needed for a public network. For example, while

the SSDS provides privacy, GSFC customer requirements state that

encyrption is a customer responsibility. Similarly, it seems

unlikely that code conversion will be required since customers

are expected to use standard terminal equipment. The CCSDS

Packet Standard might be viewed as within the Presentation Layer.

The information stored or available from the applications

processors above the application layer could be framed in the

CCSDSformat by the Presentation Layer - for example, experiment

data might be formatted using CCSDSwhile queries and virtual

terminal interactions might not be so framed (McKay).

3.1.i.2.2.2 Presentation Layer Options Characterization

Candidate protocols include:

ISO Connection, Cointext, Information Transfer,

Management, Synchronize, Interrupt, and Terminate

described in the draft ISO presentation layer standards.

Dialogue

services

FIPS 46, the NBS Data Encryption Standard

ANSI Standards X.3.4 (Standard ASCII characters), X3.15 (Bit

Sequencing) and X.3.16 (Character Structure and Parity).

AT&T BX.25, which extends into the Presentation and Session

layers.

CCSDSPacket Standard (present or modified).

3.1.1.2.3 Session Layer

3.1.i.2.3.1 Session Layer Options Description

The session layer is responsible for

managing connections between two processes,

recovery from failure at the transport layer.

establishing and

and provides for

The session layer

2O
is responsible for the mechanisms for organizing and structuring

the interactions between application processes. Specific

functions include (Rauch-Hindin):

o connection establishment and termination

o data transfer

o synchronization between end-user tasks

o graceful and abrupt closure of a session

o map user address to names

o dialog control (who, when, how long,

duplex)

o quarantining of data (buffering of

instructed to deliver it(.

half or full

data until

Draft OSI standards are under development (Day & Zimmerman).

3.1.i.2.3.2 Session Layer Options Characterization

Session Layer Protocol candidates include portions of the

previously mentioned protocols (NBS, ISO, AT&T) which map into

the ISO model. The main candidates are the ISO recommendations

for Session Service Definition (X.215) and Session Protocol

Specification (X.225) including services for Normal Data

Exchange, Expedited bata Exchange, Token Management, Dialogue

Control, Synchronization, Resynchronization, Activity Management,

Exception Reporting, Typed Data, and Capability Data. The

Session Layer has not received the attention given to other

layers and standards are only beginning to emerge.

3.1.1.2.4 Transport Layer

3.1.I.2.4.1 Transport Layer Options Description

The transport layer provides the "users gateway" into the

data system and the transport level protocol is to provide a

reliable, end-to-end communication path. The levels below the

transport layer only deal with protocols between "nearest

neighbors" on the communications network, whereas the transport

layer is at a "user machine-to-user machine" level. For the

Space Station, this would mean "payload-to-payload control center

processor", or "core-system-to-operations center processor"

communication. The Transport Layer accepts data in message form

from the session layer, breaks it down into smaller pieces if

required by the network layer, and vice-versa. Transport layer

standards provide for end-to-end (host-to-host) connection

establishment, ordered delivery of data, error control, and flow

control on an end-to-end basis. The transport layer thus

supports (Stallings, Rauch-Hindin):

21
o transfer of data between two transport users,

addressing end-user machines without concern for the

route of the messages or the addresses of machines

enroute between end-user machines.

o grade of service (e.g., acceptable error

delays, priority) as requested by users

levels,

o connection management (establishing,

and terminating logical connections

points)

maintaining,

between end

o handling requests for expedited delivery or security

services

o monitoring of quality of service, status reporting,

end-to-end error detection and recovery

o multiplexing end-user address onto network.

The ISO Transport protocols are linked to three network

types defined by ISO (Stallings):

Type A Network - Network connection with acceDtable

residual error rate and rate of signaled failures

Type B

residual

failures

Network - Network connection with acceptable

error rate but unacceptable rate of signaled

Type C Network - Network connection with residual error

rate not acceptable to the transport user.

The ISO has defined five classes of transport

which depend on the user service requirements and the

network services (Stallings):

protocol,

available

o Class 0 - Simple - no explicit ordering or error

control (used with Type A networks)

o Class 1 - Basic error recovery - provides minimal

error recovery and expedited data transfer (used

with Type B networks)

o Class 2 - Multiplexing - adds the ability to

multiplex multipbe transport connections into a single

network connection, plus explicit flow control since a

single network connection does not control flow for all

transport connections (used with Type A networks)

o Class 3 - Error recovery and multiplexing - union of

Class 1 and Class 2 capabilities and also contains

the resynchronization and reassignment capabilities

needed to cope with failure prone networks (used

with Type B networks)

22
o Class 4 - Error detection and recovery - uses full

range of transport level capabilities to handle an

unreliable, error prone network (used with Type C

networks).

It has been proposed (Carper) that SSDS transport

requirements include provision of the following services:

o quality of transport service:

normal quality

computer quality or

delivery services:

forward services

immediate delivery or store and

o reliability services: verified delivery (with retransmission) or unverified delivery (datagram).

Meeting the requirements for these services might best be

associated with a Transport Layer standard for the SSDS.

Implementation of some of these services would interact with

other layers (e.g., with a network layer having both connection

and connectionless/datagram modes).

A related proposed requirement (Carper) is that these

services should be symmetric for Space Station, that is, they

would be available in either direction. Since many future

payloads are expected to utilize considerable processing, one

needs to view payload-to-ground communication as being computerto-computer rather than computer-to-human. Thus, one could have

"downlink commands" -- such as data base requests issued by a

payload processor, and "uplink telemetry" -- such as data from a

computer data base. This flow will be increasingly true as

functions migrate from ground to space.

One could view the CCSDS Packet Standard as mapping to the

Transport Layer. For example, one could think of the current

CCSDS Packet Telemetry Standard as providing computer quality,

store and forward, unverified delivery, while the CCSDS

Telecommand Standard as providing normal quality, immediate,

verified delivery. Provision of all of the above required

services would appear to require modifications of existing

standards.

3.1.i.2.4.2 Transport Layer Options Characterization

The candidate protocols are:

ISO recommendations for Transport Service Definition (X.2_4)

and Transport Protocol Specification (X.224) which defines the

five classes of service described above.

The ARPANET Network and Transmission Control Protocols

and TCP).

(NCP

23
CCSDS Telemetry Packet Standards (present or modified

version)

3.1.1.2.5 Network Layer

3.1.1.?.5.1 Network Layer Options Description

The Network Layer provides the layers above with

independence from the actual data transfer technology used --

e.g., whether the network uses optical fiber, local area

networks, packet switching, etc., should all be hidden (Day &

Zimmerman). The network layer protocols go from "network portto-network port." For the Space Station, for example, this would

go from the on-board NIU interface, to another such interface, or

to the interface to the ground based remote area network. The

network layer provides routing and congestion control to higher

layers. Standards at this level allow routing, sequenced

delivery, and accounting functions for data transfers between a

computer and the network, and duplicate functions performed at

the data link level, at the network level. Specifically, the

functions include:

o establishing a logical connection between endpoints

on the network, setting up routes for packets to

travel, and addressing network machines on the route

through which the packets travel

o managing the connection

connection after use

and disconnecting the

o delivery of messages over the logical link (control

of the logical channel), in the order in which they

were sent (sequencing), with error control

o transport flow control, so that the receiving point

on the network is not overloaded with messages

o manage the use of multiple

increase throughput

(parallel) links to

o prevent any one user from overload the transmission

resources to that other users are blocked

o alternate routing, to avoid failed or congested

links

o network traffic monitoring, billing

o internetworking

o disassembly of transport messages into packets

re-assembly at destination.

and

A recent development at the network layer has been the

development of "connectionless" protocols for ISO (Rauch-_indin).

24
Previous network standards were connection oriented," meaning

that calls or connections between the two endpoints were made

prior to data transfer. Connectionless mode does not make this

assumption and is used to send single data packets, each packet

having no relationship to other packets. This mode is preferred

by the Department of Defense since they feel it allows (RauchHindin):

greater survivability,

vulnerable in case of

recover

with the network less

attach and more able to

it allows adaptive routing and simpler

operation because most bookkeeping and

integrity controls are performed at the

ends rather than in the network.

network

message

terminal

Connectionless or datagram mode is particularly appropriate

for local area networks due to their high reliability. However,

it is noted that ARPANET functions in datagram mode.

Data base research involving geographically separated nodes

have shown a need for both connection and connectionless

protocols. Many types of real time controls will require

acknowledgements and rapid interchange of signals and data not

supported by a connectionless mode (McKay). Other types of data

transport will not require these services, such as transport of

non-interactive experiment data.

The CCSDS Telemetry & Telecommand Segmentation provides:

o control of channel resources, so that no one source

exclusively captures use of the channel

o segmentation may be performed by the application

process, or by the spacecraft data system using one

of two formats.

One view is that CCSDS segmentation should be mapped to

Layer Three (Network) which were suggested in comments on a draft

of this paper. Other inputs have suggested that segmentation was

added to meet the needs of specific space agencies and might not

be used for the Space Station Program.

The requirements for SSDS end-to-end networking are

significantly different from the past. Requirements from the

Task 1 report that bear on the data distribution network and

indirectly on the selection of protocols are:

o provide real time distribution of real time and near

real time data, including level 0 processing,

demultiplexing, buffering, routing, and

retransmission (Section 5.3.1.3)

25
O provide real time,

(Section 5.3.1.1)

raw payload data to the customer

o support real time re-allocation of data distribution

resources to help meet customer priorities (Section

5.3.3.3).

Additional NASA requirements affecting the choice

communications protocols for the network include (CRSS):

o The SSIS/SCS network data handling shall be

independent of the format or content of the customer

data (CRSS, p3-1)

o The data network shall be able to transport and

delivery customer data sets intact, without having

any knowledge of their internal format or content

(CRSS, p 2.2.3.4)

o customer data shall be delivered without alteration

of its contents. Any artifacts imposed by the data

transport service, e.g., data reversal due to

communications buffering, shall be removed before

data delivery to the customer.

Finally, the mission data base poses stringent delivery

requirements -- data must be delivered to customers within

rather than months.

The above requirements imply:

o for on-board networks, the need to support an

evolutionary expansion of the Space Station with a

minimum of effort,

o

o

a need to rapidly separate the downlink data by

customer ID and distributed it electronically to the

customer, and similarly for the uplink,

the desire to transport the customer data (the

telemetry/telecommand packets) by electronic means

from the payload to the customer's premises, perhaps

in near real time (as well as non-electronic

delivery) with a minimum of network reconfiguration,

o that the selection of which Wide Area Standards are

appropriate is dependent on the data characteristics

and several standards might be used (circuit,

packet),

o compatibility with existing standards and the use of

interfaces compatible with existing customer

equipment.

of

delay

hours

26
Layer three of ISO is responsible for network services as

described above. The protocol must, thus, have a means of

specifying the network address point of the source and

destination of the data to be delivered - the payload address (in

space) and the customer address (on the ground). CCSDS

Segmentation does not provide this information, nor do other

layers. The CCSDS Packet and Frame Headers identify the on-board

application process, and the downlink channel, but not the

customer destination address. This assumes that an end-to-end

route is configured for the period during which the payload is

operating, as opposed to having this information in the packet

header itself.

The emerging design for the SSDS is a distributed processing

network, with many endpoints in space, and many endpoints on the

ground where processing is performed. The ground endpoints

include Data Handling Centers (to perform standard Level 0

processing), multiple Regional Data Centers, and many customers

who receive data electronically. In addition, there will be

control centers for the Space Station, for the COP and POP,

POCC's, and customer control centers.

Furthermore, one customer may have many payloads on the

Space Station. Some customers may receive data from one or many

payloads and some payload data will be routed to different

customers and destinations. Some data will be routed directly to

a single customer's facility, while other data will be held at

Regional Data Centers and distributed from that point.

Network services must thus be provided, in a way that allows

data to be handled in as automatic a fashion as possible and a

minimum of network re-configuration. For example, in the SSDS

operations concept, customers may logon, be connected to a

control center, and send commands to 'their payload. Resulting

data may be returned to their location at a later time. Ideally,

this process would occur transparently as long as the customer is

operating within the resources (such as TDRS bandwidth) allocated

to that customer.

For example, it is possible to infer the destination address

based on a combination of the source, and a schedule. That is,

one could read the source and, knowing the schedule of who was to

receive the data from that source at the time, route the data.

If the re-scheduling was infrequent - for example, when customers

are added to the network - this appears feasible.

3.1.1.2.5.2 Network Layer Options Characterization

Candidate Network Layer protocols include:

X.25 which also effectively encompasses the Data

Physical Layers,

and

X.213/DP 8473, the connectionless standard,

27
X.75 Internetworking Protocol

X.21, Circuit Switching

NASA Specific protocols, such as NASCOM blocks.

We note that some of these protocols which use retransmission strategies are likely to be inappropriate for bulk

traffic on some subnetworks or links (e.g., space-to-ground) but

are potentially applicable to others (e.g., the Wide Area

Network).

3.1.1.2.6 Data Link Layer

3.1.1.2.6.1 Data Link Options Description

The data link layer is responsible for providing an error

free line over any link on the network, e.g., on the link

between the host and the network, or links between network nodes.

It provides the functional and procedural means to transfer data,

and it performs error detection, sequencing, time out and

acknowledgement, and flow control. The purpose is thus to take

the basic transmission line at the physical layer, and make it

appear to the network layer that it has an error free line. The

data link layer performs functions similar to those of the

network layer, but on a link-by-link basis. Specifically, the

data link functions include (Martin):

o establishing,

logical link

physical link,

initializing, and

between two points

disconnecting a

connected by a

o transmission of frames over a physical path,

o control of the link during data interchange,

o detection of the beginning and ending of a frame,

o detection of transmission errors,

(e.g., re-transmission),

error handling

o provision of data transparency,

of data may be sent,

so that any pattern

o link flow control, so that the transmitter does not

overload the receiver with data frames.

It has been suggested that the CCSDS Frame Standard provides

services that could be used for both the uplink and the downlink

(review comments):

o transport of telemetry packets over

ground link,

the space-to28
o time sharing of the links between different data

types,

o a virtual channel which allows segregation of

different data types,

o a status insert so that status and audio data may be

inserted synchronously, and

o a bi-directional transfer mechanism.

The CCSDS Telecommand Transfer Frame Standard provides:

o transport of telecommand packets from ground-tospace,

o Command Operation procedures provide for retransmission of missing frames.

The CCSDS Trasnfer Frame Standard could be thought of

mapping to:

o the data link layer providing transport over the

space-ground links,

o both the data link and network layers (CTA).

The CCSDS Telemetry & Telecommand Channel Coding

provides:

o error protection and correction over the space-toground link.

The CCSCS Channel Coding could be thought of as mapping to:

o the data link layer, providing special error

handling for the space-ground links.

Bit Error Rate requirements range from 10"*-7 (CRSS)

10"*-9 for computer data (Phase B RFP).

The SSDS requirements for the data link layer implied are:

o for the space-to-ground link, standard services to

limit the error rates,

o for ground links, the need to move a large volume of

data over a variety of links, perhaps at very high

rates, to the NASA centers and the customers

premises,

o the use of protocols which can perform error

handling at high rates (e.g., re-transmission

protocols may be difficult for some data types), and

as

Standard

to

29
o the use of interfaces compatible with existing

customer equipment.

3.1.1.2.6.2 Data Link Options Characterization

The main distinction in Data Link Layer protocols is that of

byte and bit oriented protocols. The following are candidate

protocols are:

ADCCP (ANSI X3.66 and FED-STD 1003)

LAP and LAPB, the X.25 data link protocols

HDLC (ISO 3309 and 4335), basis for X.25 data link protocol

BISYNC, widely used IB_i character oriented standard

SDLC, IBM bit oriented standard

ANSI X3.28, control character protocol

IEEE 802.2, logical link protocol for the other 802

standards

ISDN D-Channel Protocol (LAP D)

ARPANET IMP-IMP protocols

ISO protocols being developed for fiber optic LAN's, which

includes work by NASA for the NIU (Network Interface Unit) at JSC

and GSFC.

3.1.1.2.7 Physical Layer

3.1.1.2.7.1 Physical Layer Options Description

The physical layer provides for a physical interface between

the terminal equipment and the data network -- the mechanical,

electrical, functional, and procedural standards to access the

physical medium. The concern is to send bits over a physical

transmission facility. Specifically, the physical layer:

o provides an electrical and physical interface

between the data source and the data communications

equipment,

o establishing and disconnecting a physical

transmission path,

o transmitting bits over the physical path, and

o alert the link layer to physical path failures.

The CCSDS RF Standard maps to the physical layer.

3o
3.1.1.2.7.2 Physical Layer Options Characterization

The protocols in this layer are being affected by rapidly

evolving hardware technology, particularly in the area of fiber

optics, and it is likely that a number of existing standards for

Physical and Data Link interfaces are likely to be translated

into higher bandwidth fiber optic networks in the next few years.

(As noted in the previous section, work is underway at JSC and

GSFC in these areas.) Physical layer standards based on star

topologies are also likely to arise since this structure seems

appropriate to fiber optic LAN's.

Candidate protocols include:

IEEE 802 which includes CSMA/CD, broadband CSMA/CD,

token bus, and token ring standards under a common Data

Link layer.

RS-232-C

RS-449 (including RS-422, RS-423;) and FED STD's 1030,

1020, and 1031)

X.20 and X.21 (physical),

protocols for X.25

synchronous and asynchronous

X.21 bis, interim X.25 physical layer standard similar

to RS-232-C

X.24 DTE/DCE interface

X.26, X.27, and X.29 modem protocols

ISDN physical layer standards

NASA specific flight standards for LAN's such as

MMSbus.

the

Fiber Optic LAN Interfaces, Under Development

3.1.i.3 Standards Architecture Options Description

There are several options for how one can select the various

ISO and CCSDS standards to implement an end-to-end standards

architecture. These options differ in their impacts on the

various elements of the SSDS. This section takes the view that

it is critical to select the standards for each of these elements

using the same model, and with an understanding and balancing of

the impacts on all of the elements of the SSDS. Thus, one should

consider the needs of the ground segment when selecting the space

segment standards, and vice versa, so that no one element is

unduly impacted.

Customer interfaces and impacts are particularly important -

one should not impose new unique standards data formats - or

31
worse, multiple and conflicting -- standards on Space Station

customers unless there is no other option.

The question is thus what the end-to-end standards

architecture should be for the SSDS. How do the CCSDSstandards

and the standards derived from the ISO/OSI model wrap around each

other. Four logical options are presented:

o ISO Compatible Standards for Local &

Networks (space & ground) combined with:

Wide Area

a) CCSDSPackets as an ISO Upper Layer Standard,

b) CCSDSPackets & Frames "Below" On-board ISO,

or

c) CCSDS as Alternate Downlink Standards for ISO

Levels 1-3.

o ISO Standards Only

Before reviewing these options, a final word on terminology.

The word "packet" has been used in this section for two slightly

different concepts:

o a "telemetry packet" means the package of data from

the payload, and the relevant ancilliary data, which

is to be delivered to the payload customer. The

"telemetry packet" may be of variable length but may

be very large - for example, a scan line from the

instrument. (CCSDS packets have a maximum length of

2"'16 - I.) This might better be called a

"message", since the packets may or may not be

packet switched (see below).

o a "packet" in the communications sense is defined by

CCITT as "a group of binary digits including data

and call control signals which is switched as a

composite whole." The data, called control signals,

and possible error control information, are arranged

in a specified format. "Packet switching" is

defined as "the transmission of data by means of

addressed packets whereby a transmission channel is

occupied for the duration of transmission of the

packet only. The channel is then available for use

by packets being transferred between different data

terminal equipment. Note: The data may be

formatted into a packet or divided and then

formatted into a number of packets for transmission

and multiplexing purposes (Martin). The packets are

of variable length up to some maximum (for example,

128 bytes for X.25 packets).

Thus, "telemetry packets" could be either sent on a

dedicated physical path, they could be circuit or message

32
switched, or the telemetry packets could be treated as data,

further broken into packets, and sent over a packet switching

network.

3.1.1.3.1 CCSDSPackets Implemented as ISO Upper Layer Standard

3.1.1.3.1.1 Option Description

The first option is illustrated on the next page. It shows

a "logical view" of how the end-to-end standards architecture

might look -- that is, it does show the hardware and software

elements.
Space Ground

CCSDS

Packets

or Segments

Space Station

ISO Levels 1-7

Local Area Net

CCSOS

Frames,

Channel. RF)

CCSDS

(RF. Fram_,

Channel)

Ground ISO

(Wide Area

Net)

ISO Levels 1-7

CCSDS Packet

or Segment

CCSDS

Frame

Header

ISO

Headers

CCSDS

Packet

Header

First Option

34
In this first option, the CCSDS packet standard (present or

modified) is considered to be an upper layer of the ISO model.

Possibilities that have been proposed are:

o the CCSDS packet standard is implemented as

application data or an application layer standard,

o the CCSDS packet standard is

presentation layer standard, or

implemented a

o the CCSDS packet standard is implemented as a

transport layer standard.

(These possible mappings of CCSDS Standards to the ISO model are

further discussed in section 3.1.1.2).

Each "packet" -- the message containing an observation from

the payload -- is delivered to the Space Station local area

network, which implements some portion protocols in ISO layers i7.

If the CCSDS packet is destined to go off, the Space Station

(e.g., to the ground) then CCSDS segments and frames are formed,

perhaps in a special purpose gateway. A parallel process occurs

on the ground, and the protocols used within the ISO layers will

likely be different than used on-board (e.g., local area network

protocols vs. long-haul communications protocols).

3.1.i.3.1.2 Option Characterization

This option becomes more clear if one examines a possible

physical architecture. There are several possible ways to

implement this option; one is shown on the next page. The way to

read the diagram is as follows:

o the reference configuration for the data system is

shown, as supplemented by ground elements. Thus,

data starts with the payload, connects via

interfaces to the on-board payload LAN, thru C&T, to

a Data Handling Center, and from there to Regional

Data Centers and Customers,

o the formats shown below the figure illustrate how

the data might be formatted at that point in the

data flow.

The diagram is only intended to apply to the

telemetry" downlink.

"traditional

35

The impacts on the major elements are described below.

The payload always has a packet format, whether it is in the

laboratory or in the Space Station or platform. This simplifies

testing for the customers.

The on-board LAN must carry the CCSDS information, e.g.,

headers, trailers, ancillary data. Whether this data is "added

overhead" which of the "suboptions" are used for the CCSDSPacket

formats and may or may not be significant. If the packet format

is considered as part of the application data, then it may

duplicate header information used by other layers (such as

transport). This may not be the case if the

Telemetry/Telecommand standards are implemented, in present or

modified form, as an upper ISO layer standard.

Ancillary data is provided over the LAN to the payloads.

This is consistent with customer requirements.

The impacts are the TDRSSdownlink/uplink, and the Wide Area

Network, are similar to those stated above for the on-board LAN.

The Wide Area Network must route data in the downlink to

some location, e.g., an RDC, (and vice versa for the uplink).

(Similarly, "commands" or data must be routed from a ground

point, the NGT to the Space Station element, and finally to the

payload.) One approach to performing this routing is to read

segment headers and route messages or packets, as illustrated.

As an alternative, it may be possible to route a class of data

(low to medium rate) more or less automatically. It may be

possible to do this by reading the telemetry packet source ID, in

combination with a schedule, as discussed in Section 3.1.1.2.

Alternatives are (a) send each customers data on a scheduled

channel basis, (b) employ application specific software to

process the data, sorting it, and sending it to the destination.

Scheduling could be very complex.

The impacts on the customer of this approach are:

o the payload interface is constant,

o timeliness of delivery will depend on whether the

data can be routed automatically.

3.1.1.3.2 CCSDS Standards Implemented Below On Board LAN/ISO

3.1.1.3.2.1 Option Description

In the second option, the entire set of CCSDS standards are

"below" the on-board ISO local area network. CCSDS Packets,

Segments, and Frames are formed for the downlink. Different

37
Space Ground

Space Station

ISO Level 1-7

(local Area Net)

CCSDS Packets

or Segments

CCSDS

RF, Channel,

Frame

CCSDS RF,

Channel, Frame

CCSDS Packets

or Segments

Ground ISO

(Wide Area)

ISO Levels 1-7

CCSDS

Frame

Header

CCSDS

Packet

Header

ISO

Headers

Second Option

38
0

_'_ .... "l / /if / /I,. 7/i/._//i l.

I P_ < _ ..... <;'/i':'i"'l''<///"<"

t _ ..-...-,,,,,.,,,,..,,, _

t_ -= , iiiiNi!i:!ii:iiiiiifi!

I-'.'_, ._._ _ _,...

, I_. _.,.._ _ ,-_;;:..

:o _.,..v,,,.,._z. -<z "_'t,__;-:../. _- '_- --_ ._."

I__., "'_ ,i.,, ...... ,7,,,,/_

39
telemetry packets might be created for each payload, since each

is intended to be a payload observation. If the same length

packets were formed for each payload, some of the value of the

packet telemetry approach would be reduced.

3.1.1.3.2.2 Option Characterization

The impacts on the major elements are described below.

The payload format is not constant, since the

packets are formed by the SSDS in the Space Station or

This complicates testing.

telemetry

Platform.

The on-board LAN does not carry the CCSDS information, e.g.,

headers, trailers, ancilliary data.

Ancilliary data is provided over the LAN to the gateway

instead of the payloads. This is not consistent with customer

requirements. It is likely that the same ancilliary data would

be provided to each payload in this implementation. The gateway

is now a more complex device over the previous approach.

The impacts are the TDRSS downlink/uplink, and the Wide Area

Network could be high. Duplicate sets of header information

might be necessary.

The impacts on the customer of this approach are:

o implementation and handling of the telemetry packets

is an SSDS standard service, but

o payload interfaces will not be constant,

above.

as noted

4O
3.1.1.3.3 CCSDSStandards Implemented as Lower Layer ISO

3.1.1.3.3.1 Option Description

The third option is illustrated as follows:

Space Ground

CCSDS

(RF, Channel,

Frame)

Space Station

ISO Layers

1-3

CCSDS Segments

Frames, Channel,

RF

CCSDS Packets

or Segments 1

Ground ISO

Layers 1-3

(Wide Area)

CCSDS

Header or

ISO Level 2

CCSDS Packet

or Segment

Header, or

ISO Level 3

ISO Headers

(4-7)

I

I

Third Option

41
®

>_ _ _ _ I I__. i,:-_.i ._._,._.,

_.I___ I _.o::_

_o,

N g r-]

o l lr_ I ,_ _ I V.._////tl/.4s_ l ,-. _ _1 r////////////A I =_ _ I _//_/////,//'_

{,/'i ---I _ . .. ---

I,I.

42
In this third option (analogous to Swingle & McKay), the onboard ISO layers four-to-seven can either interface to the onboard local area network (using ISO layers one-to-three) for onboard communications, or to the CCSDS Packets, Segments, or a

combination of these and relevent ISO information for downlink.

It would require that the IS0 level three (packets) and CCSDS

Packets or Segments be compatible. Information to/from a layer

may be different and conversion can be feasible - the formats

need not be identical, but would have to be possible to do a

transformation.

3.1.1.3.3.2 Option Characterization

The impacts on the major elements are described below.

The payload interface is not constant in a packet format.

The on-board LAN may carry the CCSDS information, e.g.,

headers, trailers, ancilliary data. Whether this data is "added

overhead" which if the "suboptions" are used for the CCSDS Packet

formats.

Ancilliary data is not provided over the LAN to the

payloads. This is not consistent with customer requirements.

The impacts are the TDRSS downlink/uplink, and the Wide Area

Network, are minimized. The impacts on the customer of this

approach are:

o implementation and handling of the packets is

between the SSDS and the customer.

split

The last "logical" option would be to only adopt standards

which are consistent with the ISO model. If one only examines

the "official" standards developed under ISO, this does not

appear practical. Current network standards developed under the

official ISO°umbrella include X.21 (circuit switching) and X.25

(packet switching) which have too much overhead, and which offer

insufficient error protection, for the TDRS downlink. For

example, X.25 performs error correction by re-transmission.

While this may be quite suitable for certain traffic on the Wide

Are Network, it is not applicable for much of the downlink

traffic. However, using a combination of ISO standards and CCSDS

standards appears feasible as illustrated in the other options.

Overhead for applications processors is expected to be

offloaded within the next five to ten years to special purpose

"black box" processors. Although these will not be flight

qualified, some of the software may be transportable to such

hardware (McKay).

3.1.1.4 Communications Standards References

Martin, James, Computer Networks And Distributed Processing,

Prentice-Hall, Englewood Cliffs, NJ, 1981
Goddard Space Flight Center, NASCOM Development Plan - FY 85-1,

September, 1984

Sperry, "FODS Industry Briefing"

Day, J. D., Zimmerman, H. "The OSI Reference Model,"

Proceedinq of the IEEE, Vol. 71, No. 12, December 1983, pp 1334-

1340.

Hollis, L. L. "OSI Presentation Layer", Proceedinq of the IEEE,

Vol. 71, No. 12, December 1983, pp 1401-1403.

Bartoli, P. D., "The Application Layer of the Reference Model of

Open Systems Interconnection", Proceedinq of the IEEE, Vol. 71,

No. 12, December 1983, pp 1404-1407.

Lowe, H., "OSI Virtual Terminal Service", Proceedinq of the IEEE,

Vol. 71, No. 12, December 1983, pp 1408-1413.

Lewan D., Long, H.

Proceedinq of the IEEE,

1419.

Garrett, "The OSI File Service",,

Vol. 71, No. 12, December 1983, pp 1414-

Cunningham, I., "Message-Handling Systems and Protocols",

Proceedinq of the IEEE, Vol. 71, No. 12, December 1983, pp 1425-

1430.

desJardins, R., "Afterword: Evolving Towards OSI",

Proceedinq of the IEEE, Vol. 71, No. 12, December 1983, pp 1446-

1448.

Swingle, W. L., McKay, C. W., "Space Station Information".

CCSDS, "Packet Telemetry", Blue Book, May 1984.

CCSDS, "Telecommand Channel Coding", Blue Book, May 1984.

CCSDS, "Telecommand", Green Book, August 1984.

CCSDS, "Telecommand Channel Coding and Procedures", Red Book, May

1984.

CCSDS, "Telecommand Transfer Frame Formats and Procedures", White

Book, July 1984.

Tannenbaum, A. S.,

Cliffs, NJ 1981.

Computer Networks, Prentice-Hall, Englewood

Hooke, A. J., Space Station Data Network Concept, Presentation,

July 1984.

Conrad, J.

Standards and Protocols for Communications Networks,

We,

Carnegie

Press, Madison, NJ.

44
Stallings, W., "A Primer: Understanding Transport Protocols",

Data Communications, November 1984, pp 201-215.

Rauch-Hindin, W., "Communications Standards:

Its Mark", Systems & Software, March 1984.

ISO Poinsed to Make

Carper, R., Goddard Space Flight Center, Personnel Communications

and Comments on Draft Section 3.1.1.

Computer Technology Associates,

Briefing, January i0, 1985.

Computer Networking Study, Final

Holland, G. L., "NAPLPS Standard Defines Graphics and Text

Communications", EDN, January i0, 1985, pp 179-192.

LeGrand, S., "Approach to Extending Access Control Requirements

of Proposed Military Standard Common APSE Set (CAIS), Version

1.4, Ford Aerospace, Internal Presentation.

McKay, C. W., Comments on Draft of Section 3.1.1.

Review Committee, Comments on Draft of Section 3.1.1.

3.1.2 Data Base Management Systems Standards

A data base is a collection of data which may be stored in a

variety of physical and logical formats. A Data Base Management

System (DBMS) is a set of programs which defines and manipulates

data in a data base as well as providing query, retrieval and

reporting capabilities.

This paper considers a DBMS as a set of special-purpose

programming languages. The same language design principles such

as orthogonality, simplicity, security, efficiency and formal

definitions, apply to DBMS, as to programming languages. DBMS

should also include powerful data operators, integrated data

definition and data manipulation, integrated catalog and

compilation and optimization.

Following is a technical discussion of

categories: relational, network and hierarchical.

three DBMS

In general, there are few adequate standards existing that

should be imposed for Data Base Management Systems.

3.1.2.1 Relational DBMS Standards

Standards can be divided into three subsystems: internal

(physical storage standards), conceptual (logical storage

standards) and interface standards. Query and host language

interfaces represent other DBMS areas that are subject to

standards.

Internal or

Relational DBMS.

storage level standards do not exist for

However, NASA may consider writing its own

45
guidelines for internal data structures. For example,the use or

non-use of indices, whether data sets can be "spanned" across

volumes and whether data compression or encryption should take

place are typical of potential guidelines. There is some truth

to this argument, but as relational technology matures, this

perceived performance gap should narrow or disappear.

Conceptual or logical data level standards refer to the

design and layout of logical tables of data. Table design

involves a tradeoff between retrieval or loading speed versus the

avoidances of unpleasant anomalies.

NASA might consider using guidelines for table design

including a degree of table normalization, number and type of

primary keys, and the support of foreign keys.

Interface or external standards refer to the manipulation of

logical tables by on-line query languages or host-embedded

languages. NASA might consider standards relating to: whether

query and host-embedded languages be identical, how external

views are to be supported and whether data updating through views

should be allowed.

The only relational DBMSstandard was developed by the X3H2

committee of the American National Standards Institute (ANSI).

The standard uses IBM's SQL language as a base document.

SQL has already been adapted by a number of commercial

systems as the Data Base Manipulation Language (DBML) or the

query language for their relational data bases.

The SQL data dictionary is written in logical tables which

may be retrieved and manipulated by ordinary SQL statements.

This feature greatly facilitates the ease of DBMS administration

and control.

The primary advantage of relational DBMS is that they free

the programmer from the physical layout of the DBMS when

manipulating data. Changes in the physical structure or location

of data is hidden from the programmer. The programmer can

concentrate his or her efforts on logical data relationships.

3.1.2.2 Network DBMS Standards

A standard referred to as CODASYL has been prepared for some

network DBMS's. The conceptual and interface CODASYL Standards

are well defined in the literature and consist of a Schema and

Subschema or Schema Subset. Most commercial network DBMS's

follow the terminology and concepts fairly close. Where

implementation is too costly, they generally offer a large subset

of the CODASYL Standard. Even if commercial CODASYL-Iike DBMS's

do not follow these internal storage levels, NASA might consider

issuing its own guidelines to simplify design effort and data

base performance.

46
An internal and storage standard is called a storage schema

under CODASYL, it is written in a Data Storage Description

Language (DSDL).

The key points of the DSDL are:

l , Storage space is partitioned in disjoint storage areas

which consists of an integral number of fixed-sized

pages.

, Record types defined at the Schema level can be

represented by one or more storage record types. All

occurrences of a given storage record type are stored

in the same storage area. Record placement may be

sequential, hashed ("CALC" mode) or "clustered".

3. Schema set types are represented by pointer chains or

indexes.

. Indexes can be used to provide additional access paths

not exposed in the Schema.

3.1.2.3 Eierarchical DBMS

A hierarchical DBMS contains data physically stored in tree

structures. Hierarchical DBMS can model complex network data

models by the use of system pointers among trees.

Hierarchical DBMS do not have a standard. NASA

consider using IBM's IMS DBMS for standard terminology and

concepts.

might

basic

There is no internal level standard.

issuing guidelines relating to:

NASA might consider

o fast-path access

o the use of secondary indices

There is no conceptual level standard. NASA might consider

using IBM's IMS terminology for logical and physical tables.

Most hierarchical DBMS will not offer IMS's great variety of data

constructs, but a common terminology is important.

3.1.2.4 Data Base Standards References

References

Date, C.J., "Some Principles of Good Language Design, with

Special Reference to the Design of Data Base Languages," Siqmod

Record, Vol. 14, No. 3, (November, 1984).

Date, C.J., "A Critique of the SQL Data Base Language," SIGMOD

RECORD, Vol. 14, No. 3, (November, 1984).

47
Hobbs, Robert W., "Space Station Data Base Management Study,"

NASA Contract NAS5-27684, Task i, (November, 1983).

Bryce, Milt, "Data Base Directions II: The Concersion

Problem/Standards," SIGMOD RECORD, Vol. 12, No. 2, (January,

1982).

Bemer, Robert W., "Standards: A Data Base Imperative,"

Proceeding of the Workshop of National Bureau of Standards and

the ACM, ACM, 1975.

Deutseh, R., "Progress Towards Data Base Management Standards,"

AFIPS Conference Proceedings, 1983 National Computer Conference.

Yao, S.B., et al "Data Base Systems,"

Software, IEEE Computer Society Press.

Selected Reprints in

Champine, G.A., "Current Trends in Data Base Systems," Selected

Reprints in Software, IEEE Computer Society Press.

Fry, James P. and Sibley, Edgar H., "Evolution of Data Base

Management Systems," ACM Computing Surveys, Vol. 8, No. i.

(March 1976).

Date, C.J., A__nn Introduction to Data Base Systems r Volume I,

Addison-Wesley, (February, 1982).

Wiederhold, G.N.,

(October 1984).

"Data Bases," computer, Vol. 17, No. 10,

Hecht, Herbert,

(October, 1984).

"Computer Standard," Computer, Vol. 17, No. 10,

CODASYL Systems Committee, "Feature Analysis of Generalized Data

Base Management Systems," Technical Report, (May, 1971), ACM.

Tsichritzis, D.C. and Klug, A. (Eds), "The ANSI/X3/SPARC DBMS

FRAMEWORK: Report of the Study Group on Data Base Management

Systems," Information Systems 3, (1978).

Stonebraker,

Proc. 1974,

Control.

M.R., "A Functional View of Data Independence,"

ACM SIGMOD Workshop on Data Description, Access and

3.1.3 Codinq Standards Options

"It is the intent of NASA that this program be accomplished

in a more cost-effective manner and with a significantly higher

level of productivity than has been typical of prior major

programs."[l] It is recognized that a significant effort (from

17% to 28% is typical[2]) of a program can be spent in the

process of generating the source code. Therefore, rules that

have demonstrated a productivity enhancement are attractive.

Another and possibly much larger saving, can be realized in the

life-cycle costs where analysis has indicated standardized coding

48
rules can simplify code integration, code sharing (re-use), and

maintenance. As stated in the RFP, some of "The unique

characteristics of the SSP...program growth;..." "customer

friendly" "perspective; maintainability, commonality, and test _

and verification concepts; and the need for increased

productivity"[3].

Because of the distributed contracting of the software

effort on SSDS standard techniques for instilling discipline in

the implementation task are critical for project wide management.

Two such standards are currently being developed by the IEEE

Software Engineering Standard Subcommittee (SESS) are IEEE-SESS828 (Configuration management), and IEEE-SESS-730 (Software

Quality-Assurance Plans).

The scope of these standards deals with the specific areas

of : source code generation (in any programming language),

documentation of program source code, data structures (including

COMMON's and INCLUDE files), data structures documentation,

design approach and coding layout.

3.1.3.1 Bottom Up

This begins with the development of several computational

routines whose function is considered important to the

application. Once this is finished, the need is seen for a test

driver to support testing of those modules and their interfaces.

Sometimes the process involves modification of related routines

in an attempt to avoid duplication.

The unique aspect of this approach is the

attention to the most difficult code segments.

immediate

Bottom up does not minimize life-cycle cost as its benefits

are realized in the early stages of coding only. The lack of a

system perspective tends to generate higher level control code

and data structures that are not cohesive. This adversely

affects maintainability because the programmers who must do the

follow-on work have the additional difficult task of determining

how the current code works before they can attempt to modify it.

The lack of early attention to interfaces and overall system

requirements tend to make verification and validation very

difficult.

This approach handles the critical (time or space) code in

the earliest stages, thereby affording the maximum opportunity to

correct bad assumptions and it minimizes their ill effects.

Also, this approach encourages the creation and use of reusable

modules, but integration of these modules can be a problem due to

the lack of a system viewpoint.

By not coding from a overall system viewpoint, many

assumptions can be made with inadequate attention to consequences
in areas such as commonality of different modules and migration

of functions.

3.1.3.2 Top Down Stub

The designer begins by determining what overall functions

will be performed. He/she then makes a working top-level module

containing all the logic controlling the sequencing between

functions, but inserts dummy sub-programs (stubs) for these

functions. Finally, he/she tests this executive program

thoroughly before proceeding to succeeding steps consisting of

fleshing out the stubs. It is important to note that each subprogram can be tested immediately, not only by itself, but as a

part of the software system it joins by replacing the stub. HIPO

(Hierarchical Input Process Output) is one optional aid. Another

is the Walk-Through, an element of "egoless programming,"

intended to eliminate as many bugs as possible before coding

begins.

In this approach, coding proceeds in a hierarchical

with the most abstract control and human interface

addressed first.

manner

issues

The system view is critical for the long life required by

the Space Station Program. The evolution of software and

hardware will only be possible if the original designs and

implementations of the code are created with the necessary

overall objectives constantly in mind.

Traceability from the original requirements down through all

the levels is automatically generated from the top level control

structures. This built-in road map helps direct the maintenance

crew to the problem areas.

No special test programs need be written (and tested), the

top level control root is generated and debugged first. As each

stub is completed, it is simply added to the root and its new

functionality tested. As long as the software configuration is

kept under control, integration and test becomes adding one

function at a time into a running system aiding visibility and

tracking.

Software progress can be tracked with tangible milestones,

the start and completion dates of the root control structure and

each stub. Because there is a running system to use as the final

test of the interfaces and functionality of each stub, as they

are announced, no additional testing within

the system milestones are necessary.

Early integration and definition of interfaces is a major

advantage of this method. Eigh-risk modules are not necessarily

identified early enough to avoid bad assumptions that may require

different approaches and the rewriting of significant amounts of

code. Common modules may not be identified and functionally

equivalent modules may be duplicated under different stubs.

5o
Unforeseen changes in top level requirements may require massive

rewriting of data structures and code.

3.1.3.3 Top Down Problem Statement

In this approach, an attempt is made to define a special

problem domain and establish a set of constructs and capabilities

for expressing, analyzing, and generating programs. Another

variant involves the use of iteratively refined simulations as

successive problem statements which drive program design,

ISDOS, SODAS, DES, and LOGOS are software tools used with this

approach.

In this approach, a problem statement language and its

processor attempt to build a set of constructs to analyze the

code and data structures required.

No general statement language has been developed that is

currently broad enough to support the Space Station Program. A

number of tools have been developed[4] to abstract the design

effort into general classes of steps that can be automated.

The automated tools ensure consistent documentation and

approach but require another learning curve for new users.

Formal data structuring enhances maintainability with improved

visibility and tracking.

3.1.3.4 Model-Driven

This begins with two models. One is a "process model" of

the software design and development, the other is a "properties

manual" of the characteristics of a good software product. Note

these models initially are independent of the specific

capabilities which are required. The process model specifies the

overall sequence of activities, which begin with the

specifications of another model that is problem specific. This

new model is checked via the checklists derived from the

properties model. The resulting functional model is then used to

generate a top-level system model of four parts; control

structures model, data base model, performance model, and a work

breakdown structure.

Process and a properties models are developed first to

define the projected module. A process of step-wise iteration

of first one then the other with walk-throughs and protocols

results in a functional model that is used to generate a top

level system model.

This option attempts to ensure the generation of the most

appropriate top level control program. All the required

information needed for the models may not be available in the

Space Station Program. The limited problem domain of this

approach may exclude this method.

51
The model driven approach has the following charasteristics.

It emphasizes design validation and explicit risk analysis yet

requirements/design/simulation languages must be acquired and

maintained. This approach avoids premature hardware commitment

and emphasizes early integration of functions. On-line analysis

and design aids when available may improve productivity after

they are learned.

3.1.3.5 Structured Programming

The key ideas are: single entry and exit to all modules;

only three basic control structures allowed (sequential, do

while, if then else); programs are organized in a hierarchical,

modular block structure; formal semantic rules (such as variable

declaration, indenting instructions and commentary).

Nassi-Schneidermann (NS) charts are diagrams of the flow of

a program that tries not to allow unstructured methods[8].

This option is a more specifically coded methodology rather

than the coding design option previously discussed. It attempts

to formalize those methods that have proven to generate correct

and maintainable code with less manpower then the ad hoc

approaches common to coding.

A great deal of code will be generated by a large number of

organizations in many remote locations for SSDS. To ensure the

maximum production of "good" code, a discipline of proven methods

makes sense.

The hallmark of this option is maintainability. The code

should be a clear and understandable as possible (i.e., the GOTO

is avoided because it tends to confuse the flow of control

through the code).

Because thecode generated by this option is more easily

understood, testing becomes more systematic. Also, the single

entry single exist constraint on all modules ensures better test

coverage.

Studies[5] have indicated that this option can contribute

significantly to software productivity. Formal modularity eases

the division of tasks and supports integration. Disadvantages

include poor control structure for asynchronous events and error

exists. In addition, common or reusable components may not be

valid and a strict adherence to the standard would require some

code duplication. Also, this approach does not successfully

address the problem of common data structures.

3.1.3.6 Prototyping vs. Specifying

Traditionally, there has been two approaches to specifying

what a code module will be required to do: Build and Fix -

Proceed to build the full system with minimal or fuzzy

specifications when rework and patch until it satisfies the

52
customer (or can't be maintained); and Formal Specifying -

Develop a design specificaton document to follow for

implementation then rework the product until the customer is

happy. A new (for software) method is to build a prototype

system from the usual minimal or fuzzy (strawman) specifications

that the customer can provide. This prototype is allowed to be a

partial implementation stressing the interfaces rather then the

guts of the system. A formal exercise of the prototype with the

customer allows the filling in of the strawman specifications in

light of actual experience. An experiment[6] was run comparing

these methods as applied to seven teams of graduate students at

UCLA. The results indicate that for roughly equivalently

performing systems, the prototyping approach needed 40% less code

and 45% less effort (man hours), but specifying produced more

coherent designs and code that was easier to integrate. The

teams that used the specifying approach stated that it was very

easy to overpromise in their specifications (talk is cheap), in

contrast the prototyping teams fostered a higher threshold for

incorporating marginally useful functions as they had a more

realistic feel for the amount of effort required. Additionally,

the maintainability of the prototyping teams system was rated

remarkably higher. Finally, it was observed that none of the

prototyping teams started fresh after the formal exercise, rather

67-95% of the prototype's code ended up in the final system and

the prototype was 40-60% the size of the final system.

This method addresses the thorny issue of specifications in

an old and reasonable manner. In most areas of engineering, a

prototype is intentionally produced to test concepts and

interfaces in realization that the full scope of the program is

not apparent at its start and false assumptions may lead to bad

choices. Software engineering has not used this approach. It is

long overdue.

The Space Station Program is so large that the effort to

fully specify is not possible. Fuzzy requirements can only lead

to misunderstandings and ambiguities. This option allows

uncertain specifications to be resolved at the format prototype

exercises (User Design Review and Exercise UDRE).

The experiment[6] indicated this method produced

maintainable but less coherent design. More effort was

proportionally in testing and fixing.

a more

needed

This method generated much better human-machine interfaces

and functionality as the users get a hand in the operational

analysis at a stage where their input can have an impact.

The experiment[6] indicated a reduction of the deadline

effect at the end of the project. The prototype provides a

working base that can demonstrate progress clearly.

A more responsive to the customer design is the thrust of

this option. Always having something that works to build upon

provides a great deal of visibility into the progress of the

53
program. A penality is more difficult during the integration

stages and a potentially less coherent design.

3.1.3.7 References

Chevers, E.S. "Program Management of High Technology S/W and H/W

for the Proposed Space Station."

Dijkstra, E.W. "A Discipline of Programming."

Freeman, P. "Software Design Techniques 3rd Edition IEEE."

Gildersleeve, T.R. "Successful Data Processing System Analysis."

Hart, D.A. "The Effects of ADA and the Intel IAPX432."

Horowitz, H.

Systems."

"Practical Strategies for Developing Large Software

Whichmann, B.A. "A Comparison of Pascal and ADA."

Yourdon, E. "Techniques of Program Structure and Design."

[1]SPACE STATION DEFINITION and PRELIMINARY DESIGN REQUEST

FOR PROPOSAL- SECTION B - PROGRAMCOSTAND PRODUCTIVITY.

[2] B. W. Boehm, "The High Cost of Software"

Practical Strategies for Developing Large Software Systems, ed.

E. Horowitz, (Addison-Wesley 1975), page 7.

[3]SPACE STATION DEFINITION and PRELIMINARY DESIGN REQUEST

FOR PROPOSAL - SECTION B - SIGNIFICANT FEATURES OF THE RFP.

[4]B. W. Boehm, "Some Steps Toward Formal and Automated Aids

to Software Requirements Analysis and Design." TRW Systems

Group, Redondo Beach, CA Nov. 1972.

[5]E. W. Dijkstra, "Notes on Structured Programming,"

Structured Programming, O. J. Dahl, E. W. Dijkstra, C.A.R. Hoare,

Academic Press, London 1972.

[6]B. W. Boehm, T. E. Gray, T. Seewaldt, "Prototyping vs..

Specifying: A Multi-Project Experiment," Proceedings 7th Software

Enqineerinq, Orlando, FLA, Mar. 1984.

[7]Loughhead, J.N., Miles, G.A., and Turner, J.R., Practical

Experience of Enqineering Software Production to a Structured

Programming Standard r "Proceedings of ESATESTEC Seminar

Noordwijk, Netherlands ii-14 Oct. '83, p.125.

[8]Loughhead, J.N., Miles, G.A., and Turner, J.R., Practical

Experience of Engineering Software Production __to _a Structured

Programming Standard r "Proceedings of ESA/ESTEC Seminar

Noordwijk, Netherlands 11-14 Oct. '83," p.127

54
3.1.4 Software Quality Assurance and Testinq Standards

Software Quality Assurance is a monitor and control function

whose objective is to ensure that design, implementation,

integration, testing and maintenance standards and approved

practices are established and followed throughout the software

development cycle. SQA tasks are intended to provide a discipline

for monitoring software development from identification of

requirements to software end products that correctly meet these

requirements. This paper addresses the role

55
of SQA during the testing phase of a software project. Testing

can be defined as "the process of executing a program with the

intent of finding errors" (G.J. Myers). Testing activities

include the definition of test requirements, the definition of

test-plans and specifications, module or unit testing,

integration testing, system testing, acceptance testing and

installation testing. SQA participation in software testing

encompasses reviewing test documentation, monitoring, witnessing

the conduct of the test, identifying problems during the test and

verifying and approving test results.

The options for implementing a software quality assurance

function as part of the testing phase of software development

include: application of the following standards and

methodologies:

o Military Specifications and Standards

o NASA Guidelines and Federal Information Processing

Standards (FIPS)

o Industry Methodologies

3.1.4.1 MIL-S-52779

MIL-S-52779, Software Quality Assurance Program Requirements

prescribes the requirements for the establishment and

implementation of a Software Quality Assurance program by

contractors performing on a government software development

contract. Other standards which could be used/referenced by SQA

include:

o MIL-STD-1521A, Technical Reviews and Audits for

Systems, Equipment and Computer programs.

o MIL-STD-490, Specification Practices

o MIL-STD-483, Configuration Management Practices for

Systems, Equipment, Munitions, and Computer Programs.

o MIL-STD-1456, Contractor Configuration Management

Plans.

The functions of SQA related to software

specified by MIL-S-52779, include the following:

testing, as

a. Determining the testability of software requirements.

b. Review of test plans for compliance to contract

requirements and appropriate standards.

c. Review of test requirements and criteria for

adequacy, feasibility, and software requirements

traceability.

d. Review of test procedures for compliance to contract

requirements and appropriate standards.

e. Monitoring of tests and approval of test results.

f. Review and approval of test reports.

g. Ensuring that test documentation is maintained to

allow test repeatability.

h. Assuring that software development tools (i.e.,

56
support software and hardware) have been identified

and are acceptable.

Other functions related to the aforementioned are described

in MIL-STD-1521A, including participating in the following:

a. Functional Configuration Audit (FCA) - a formal audit

to verify that the computer program configuration

item's actual performance complies with its

Development Specification.

b. Physical Configuration Audit (PCA) - a formal

examination of the "as built" version of a computer

program configuration item (CPCI) to verify

conformance to the documentation defining the CPCI.

c. Formal Qualification Review (FQR) - a review to

ensure that testing has been accomplished to verify

that the CPCI's actual performance complies with its

Development Specification.

MIL-S-52779 and MIL-STD-1521A are policy documents

have been used effectively on large software contract.

which

A proposed Military Standard on Software Quality Assessment

and Measurement, MIL-STD-SQAM, has been prepared but have not

been approved; this standard contains requirements for a SQA

program for mission critical software development.

SQA can help ensure the development of correct,

software thus reducing lifecycle costs.

error-free

MIL-STD-1521A (USAF), Technical Reviews an___d Audits

Systemsf Equipments r an___ddComputer Programs, DOD, 1 June 1976.

for

McCabe, T. J., Software Quality Assurance:

Thomas J. McCabe & Associates, Inc., 1980.

A Surveyr

Foster, R> A.,

3rd Ed., 1978.

Introduction To Software Quality Assurance,

MIL-S-52779(AD), Software Quality

Requirements, DOD, 5 April 1974.

Assurance Program

3.1.4.2 NASA Guidelines and Federal Information Processing

Standards (FIPS)

The document, NASA Software Management Guidelines, provides

procedure guidance for the management of NASA software projects.

The guidelines presented provide a generic model which can be

selectively applied to any NASA software development effort. The

functions of SQA related to software testing, as presented in the

referenced document, include the following:

57
a. Reviews/Audits to ensure verification standards

have been met.

b. Reviews/Audits to ensure approved test procedures

have been performed.

c. Participation in software test design to ensure

that all software end items satisfy design,

operational, and functional requirements.

FIPS Publication 101, Guideline for Lifecycle Validation,

Verification, and Testing of Computer Software, presents a

methodology for validation, verification, and testing (VV&T) to

be used throughout the software lifecycle. This document

describes W&T activities and products which relate to and

provide more detail for the SQAfunctions listed above.

References

References are:

"NASA Software Management Guidelines"

National Bureau of Standards, Guideline For Lifecycle

Validation r Verification r and Testinq of Computer

Software, Federal Information Processing Standards

Publication i01, June 1983.

3.1.4.3 Industry Methodologies

Industrial organizations have recognized the need for

software quality assurance; however, the implementation of the

function has been weak due to a lack of established

methodologies. Most companies have developed their internal

policies and standards in response to government requirements.

Thus, the functions of SQA during software testing remain the

same as specified by MIL-S-52779. One difference in

methodologies is the extent of SQA participation during specific

tests. Most organizations have adopted the following:

o Development testing (Unit, Integration, and

System) will be selectively audited with no test

witnessing by SQA.

o Qualification testing (Software Validation/Customer Acceptance) will be controlled and witnessed by

SQA.

Another difference is the role of SQA during test

documentation preparation. In some organizations, SQA writes all

test plans and procedures to be used during qualification

testing.

Industry methodologies are evolving and have been used

effectively on large software contracts.

58
3.1.4.4 References

Dunn, R. and Ullman, R., Quality Assurance for Computer Software,

McGraw-Hill, Inc., 1982.

Foster, R. A.,

Ed., 1978.

Introduction to Software Quality Assurance, 3rd

McCabe, T. J., Software Quality Assurance r A Survey, Thomas J.

McCabe & Associates, Inc., 1980.

Myers, G. J.,

Inc., 1979.

The Art of Software Testinq, John Wiley & Sons,

Electronic Industries Association, SQA

"Implementation Response to Government

Requirements," October 1980.

Panel Report,

Software Quality

Fogel, G.

Presentation,

October 1984.

D., "The Proofing of Data Processing

National Conference on Testing Computer

Systems,"

Software,

3.1.5 Hardware Standards Options

A large variety of hardware standards exists for various

levels of hardware from cabinet, chassis, board, to harnessing

etc.. Standardization of hardware is highly desirable in order

to minimize change-over effects to reconfiguration.

In general, the standards would vary for space and ground

components. This standard would be applied for cabinets,

chasses and card guides. The card guide method has an unlimited

variety in commercial equipment as with cabinets and chassis.

Typically, cabinet standards refer to dimensions, cooling

capabilities, material construction and finish. Chassis level

packaging standards usually relate to dimensions, weight, cooling

and shock/vibration resistance. Chassis specifications are

usually determined by circuit board design. Card specification

usually results in specifications of the motherboard/connector

and harness/connector interfaces. Weight, power and signal

integrity are the principle items specified. In the case of the

mother- board, material selection is usually the same as the

circuit board and connector selection.

Circuit board standards are usually established by either

Milspec or individual company standards. The board dimensions

(X, Y, Z) are generally governed by design goals. The density

demands will determine the Z dimensions - two-sided/multi-layer

up to twenty one layers. The tradeoff between density and

maintainability is exercised as density increases with the high

multi-layer count which makes repair more difficult. The

material is usually specified by standards based on the desired

electrical and mechanical characteristics (flexible versus nonflexible, paper base epoxy glass base to ceramic base) NASA, Mil,

and federal standards and specifications provide a wealth of

59
possibilities on selecting materials.

Standards exist for specifying harnessing, wire-type and

cabling standards. Such factors as size and weight

restrictions, wire and/or signal requirement, material makeup

(copper, aluminum, silver finish .... ), insulation, etc., are

generally established by standard selections.

The following references indicate the breadth of options

available for hardware standardization.

REFERENCES

Metal Standards

QQ-S-698

QQ-W-321

QQ-B-728

QQ-S-763

ASTM-B348

MIL-HDK-5C

MIL-STD-22

AWS-A.2.4

AWS-A.3.0

AWS-D.I.I

ANSI-SR-17

Steel, sheet and strip low carbon

Wire, Copper alloy

Bronze, phospher

Steel Bars, Wires, Shapes and Forging CRES.

Titanium and titanium alloys

Metallic materials and elements for Aerospace

vehicle structures

Welded joint design

Symbols for welding and nondestructive testing.

Welding terms and definitions

Structural welding code -steel

Metric mechanical fasteners

ANSI-B3610-197 Welded and seamless steel pipe.

ASTMA53-75 Welded and seamless steel pipe.

MIL-STD-188 Dissimilar metals

MIL-T-23103 Thermal performance evaluation airborne

80
SURFACETREATMENTSAND INORGANICCOATINGSFOR STEEL

QQ-C-320

QQ-I-716

QQ-N-290

QQ-P-35

QQ-P-416

QQ-S-365

QQ-T-181

QQ-T-425

TT-C-490

MIL-STD-171

MIL-HDBK-132

MIL-A-40147

MIL-C-8837

MIL-C-13924

MIL-C-14550

MIL-C-26074

MIL-C-81562

MIL-C-S1751

MIL-F-14072

MIL-G-45204

MIL-L-13762

MIL-L-13808

MIL-M-6874

MIL-P-14535

Chromium Plating (Electrodeposited)

Iron and Steel; Sheet, Zinc Coated (Galvanized)

Nickel Plating (Electrodeposited)

Passivation Treatments for CorrosionResisting steel

Plating, Cadmium (electrodeposited)

Silver Plating, Electrodeposited,

Requirements for

Terne Plates (for Manufacturing Purposes)

Tinplate (Electrolytic)

Cleaning Methods and Pretreatment of

Surfaces for Organic Coatings.

Finishing of Metal and Wood Surfaces

Protective Finishes

Aluminum Coating (Hot-Dip) for Ferrous Parts

Coating, Cadmium (Vacuum Deposited)

Coating, Oxide, Black, for Ferrous Metals

Copper Plating (Electrodeposited)

Coatings, Electroless Nickel, Requirements for

Coatings, Cadmium, Tin-Cadmium and Zinc

(Mechanically Deposited)

Coating, Metallic-Ceramic

Finishes for ground electronic equipment

Gold plating, electrodeposited

Lead alloy coating, hot dip (for iron and

parts)

Lead plating, electrodeposited

Metal spraying, process for

Plating, Black Nickel (Electrodeposited)

General

Ferrous

steel

81
MIL-P-14538

DOD-P-16232

MIL-P-16961

MIL-P-20218

MIL-P-23408

MIL-P-45209

MIL-P-81728

MIL-R-46085

MIL-S-5002

MIL-T-10727

ASTM-A-153

ASTM-B-183

ASTM-B-254

ASTM-B-633

Chromium Plating, Black (Electrodeposited)

Phosphate Coatings, Manganese or Zinc Base (For

ferrous metals)

Porcelain Enamel Coating for Steel Mufflers of

Internal Combustion Engines

Chromium Plating, Electro-deposited, Porous.

Plating: Tin-Cadmium (Electrodeposited)

Palladium Plating, Electrodeposited

Plating, Tin-Lead (Electrodeposited)

Rhodium Plating, Electrodeposited

Surfaces Treatments and Inorganic Coatings for

metal surfaces of weapons systems.

Tin Plating: Electrodeposited or Hot-Dipped, for

Ferrous and nonferrous metals.

Zinc coating (hot-dip) on iron and steel hardware.

Preparation of low carbon steel for

electroplating, Practice for

Preparation of and electroplating on stainless

steel, Practice for

Electrodeposited coatings of zinc on iron and

steel, Specification for
INORGANICCOATINGSANDFINISHES FOR ALUMINUMAND ALUMINUMALLOYS

QQ-C-320

QQ-N-290

QQ-P-416

QQ-S-365

QQ-T-181

QQ-T-425

MIL-STD-171

MIL-HDBK-132

MIL-A-8625

MIL-C-5541

MIL-C-8837

MIL-C-14550

MIL-C-26074

MIL-C-81562

MIL-C-81751

MIL-F-14072

MIL-G-45204

MIL-L-13808

MIL-M-6874

MIL-P-14535

MIL-P-14538

MIL-P-20218

MIL-P-23408

MIL-P-45209

MIL-P-81728

Chromium Plating (Electrodeposited)

Nickel Plating (Electrodeposited)

Plating, Cadmium (Electrodeposited)

Silver Plating, Electrodeposited, General

Requirements for

Terne Plates (for Manufacturing Purposes)

Tinplate (Electrolytic)

Finishing of Metal and Wood Surfaces

Protective Finishes

Anodic Coatings, for Aluminum and Aluminum Alloys

Chemical Conversion Coatings on Aluminum and

Aluminum Alloys

Coating, Cadmium (Vacuum Deposited)

Copper Plating (Electrodeposited)

Coatings, Electroless Nickel, Requirements for

Coatings, Cadmium, Tin-Cadmium and Zinc

(Mechanically Deposited)

Coating, Metallic-Ceramic

Finishes for Ground Electronic Equipment

Gold Plating, Electrodeposited

Lead Plating, Electrodeposited

Metal Spraying, Process for

Plating, Black Nickel (Electrodeposited)

Chromium Plating, Black (Electrodeposited)

Chromium plating, Electrodeposited, Porous

Plating: Tin-Cadmium (Electrodeposited)

Palladium Plating, Electrodeposited

Plating, Tin-Lead, (Electrodeposited)
MIL-R-46085

MIL-S-5002

MIL-T-10727

ASTM-B-253

ASTM-B-449

AMS-2468

AMS-2469

AMS-2470

AMS-2471

AMS-2472

AMS-2473

AMS-2474

Rhodium Plating, Electrodeposited

Surfaces Treatments and Inorganic Coatings for

Metal Surfaces of Weapons Systems

Tin Plating: Electrodeposited or Hot-Dipped, for

Ferrous and nonferrous Metals

Preparation of and Electroplating on Aluminum

Alloys by the Zincate Process, Practice for

Chromate Treatments on Aluminum, Practice for

Hard Coating Treatment of Aluminum Alloys

Process and Performance Requirements for Hard

Coating Treatment of Aluminum Alloys

Anodic Treatment of Aluminum Alloys, Chromic Acid

Process

Anodic Treatment of Aluminum Alloys, Sulfuric Acid

Process, Undyed Coating

Anodic Treatment of Aluminum Base Alloys, Sulfuric

Acid Process, Dyed Coating

Chemical Treatment for Aluminum Alloys, General

Purpose Coating

Chemical Treatment for Aluminum Alloys, Low

Electrical Resistance Coating

84
MIL-STD-470

MIL-STD-471

MIL-HDBK-217B

MIL-STD-721

MIL-HDBK-472

MIL-STD-415

MIL-STD-481

MIL-W-5088

MIL-STD-1353

DOD-STD-1678

EIA-RS440

DOD-C-85045

MIL-STD-1472

MIL-STD-171

MIL-STD-189

EIA-RS-310

FED-STD-595

MIL-M-13949

MIL-STD-1313

MIL-STD-130

MIL-F-14072

MIL-P-8585

MIL-STD-285

GENERALSTANDARDS

Maintainability program Req.

Maintainability Demonstration

Reliability prediction of Elect. Equip.

Definition of Effectiveness terms for Reliability,

Maintainability, Human Factors, and Safety.

Maintainability prediction

Test pts. and test facilities for elect, sys. and

associated equip, design STD for.

Electromagnetic interference characteristics

requirements for equipment.

Wiring, Aerospace Vehicle

Electrical connectors and Associated Hardware,

Selection and use of.

Fiber optic test methods and instrumentation.

Fiber optic connector terminology

Cables, Fiber Optics, Gen. Spec. for

Human Engineering Design Criteria for Military

Systems, Equipment and Facilities.

Finishes for metals and wood.

Rocks, Elect. Equip. 19 inch and associated

panels.

Racks, panels, and associated equip.

Colors

Plastic sheet, laminated copper, Dual glass-base

epoxy.

Micro circuit terms and definitions.

Ident. marking of U.S. Mil. property.

Finishes for ground sig. equip.

Primer coating, zinc chromate, low-moisture sens.

Attenuation measurement for enclosures

65
MIL-STD-202

ANSI-Y32.14-

1973

ANSI-Y14.5M1982

MIL-STD-454

MIL-E-4158

ANSI/IEEE-STD100-1979

Standard 142

MIL-B-81705

DOD-STD-1686

DOD-HDBK-263

Test methods for electronic and electrical

component parts.

ANSI STD. Graphic symbols for Logic Diagrams

Dimensioning and Tolerancing

Sstd. Gen. Req. for electronic equipment.

Elect.Equip., Ground, General Req. for

Definition of Elect. terms (IEEE)(American

National Standards Institute).

Grounding of industrial power systems (IEEE)

Barrier materials; flexible electrostatic-free,

Heat shrinkable.

Electrostatic Discharge Control program for

protection of electrical and electronic parts.

Assemblies and equipment.

Electrostatic discharge control handbook.
EIA-RS-232

EIA-RS-42

EIA-RS-423

EIA-RS-449

IEEE-488

IEEE-583

IEEE-595

IEEE-596

IRIG-123-72

IRIG-104-70

IRIG-106-60

MIL-STD-188

USAS-X3.4.1977

(ANSI)

DIGITAL DATASTANDARDS

between data terminal and communication

voltage

voltage

position

serial

Interface

equipment.

Electrical Characteristics of balanced

digital interface circuits.

Electrical characteristics of unbalanced

digital interface circuits.

General purpose 37 position and 9

interface for data terminal equipment,

binary data interchange.

Digital interface for programmable instrumentation

Modular instrumentation and digital interface

system (CAMAC)

IEEEStandard Serial Highway Interface System

(CAMAC)

IEEE Standard PArallel Highway Interface System

(CAMAC)

Instrumentation timing systems brochure

IRIG Standard time formats

Telemetry standards

Military Comm. System Tech. Std.

Info. Intechange, Code for

87
Organic Finishes Reference Documents

FED STD 595

MIL-STD-171

MIL-HDBK-132

TT-E-489

TT-P-1757

MIL-C-5410

MIL-C-5541

MIL-C-8514

DOD-P-15328

MIL-C-43616

DES 7.11.4

88-3102

Colors

Finishing of Metal and Wood Surfaces

Protective Finishes

Enamel, Alkyd, Gloss (For exterior and

Interior Surfaces)

Primer Coating, Zinc Chromate, LowMoisture-Sensitivity.

Cleaning Compound, Aluminum Surface, NonFlame-Sustaining

Chemical Conversion Coatings on Aluminum and

Aluminum Alloys

Coating Compound, Metal Pretreatment, ResinAcid.

Primer(Wash), Pretreatment (Formula No. 117

for Metals)

Cleaning Compound, Aircraft Surface

Tropicalizing (Fungus Proofing)

Painting, Varnishing and Lacquering

Steel Structure near-White Blast Clearing Painting.

Council SSPC-10

Guidelines for selection of organic finishes for military using

systems are presented in MIL-STD-171, Type I exposure. Cured

finishes shall conform to the requirements of manufacturing

Standard 88-3102.
3.1.6 Safety Standard Options

Currently, NASA Shuttle Programs tailor their safety

standards and regulations from the two standards mentioned above.

It is, therefore, reasonable to expect a separate NASA Handbook

(NHB) specifically related to all segments of the Space Station

Program.

Contractor Program Plans for individual NASA sites evolve

from a tailoring process which begins with a baseline Military

Standard on the specific area and ends with a Program Plan for

individual contractors. Initially, a general Military Standard

is chosen as a baseline reference document for each discipline.

Specific designguidelines and specifications in the standard are

then tailored to the tasks that need to be described in the NASA

handbook for an overall Program in NASA, such as the Space

Shuttle Program, or the Space Station Program. The Contractor

Program Plans are, in turn, tailored from the NASA Handbook in

accordance with specific needs at each NASA site.

Since this has been the method NASA has utilized for other

program standards, it is reasonable to expect them to follow

suite with respect to safety standards for the Space Station

Program. Therefore, it is recommended that SSDS limit its

comparison of safety standard options to MIL-STD-882 and NHB

5300.4(ID-2).

A preferred option is one that consolidates the

comprehensiveness of MIL-STD-882 with NHB 5300.4(iD-2) elements

ID200-4 (Organization), ID200-8 (Mishap Investigation and

Reporting), ID200-9 (Risk Management), ID201-6 (Hazard Reduction

Precedence Sequence), and 1D201-9 (Human Engineering). A

preferred option is one that also incorporates specific tasks

during the operations and support phases to assure sustained

safety of systems through the operational life period and to

forecast timely replacement/refurbishment prior to excessive

degradation in safety.

3.1.6.1 Mil-Standard 882

This document provides uniform requirements for developing

and implementing a system safety program of sufficient

comprehensiveness to identify the hazards of a system and to

impose design requirements and management controls to prevent

mishaps by eliminating hazards or reducing the associated risk to

an acceptable level. Selective application and tailoring of this

military standard must be accomplished to specify the extent of

contractual and in-house compliance.

This standard provides uniform requirements for developing

and implementing a system safety program to identify the hazards

of a system and to impose design requirements and management

control to prevent mishaps by eliminating hazards or reducing the

associated risk to a level acceptable to the Managing Activity

(MA).

89
Tasks described in this standard are to be selectively

applied in contract-definitized procurement,requests for proposal

(RFP), statement of work (SOW), and Government in-house

developments requiring system safety programs for the

development, production, and initial deployment of systems,

facilities, and equipment.

Task Descriptions are to be tailored as required by the MA

governing regulations and as appropriate to particular systems or

equipment program type, magnitude, and funding.

Application guidance and rationale for selecting tasks to

fit the needs of a particular system safety are included in

Tables 3.1.6-1, 3.1.6-2, and 3.1.6-3 in the appropriate Data Item

Description (DID) and statements of work.

Current use of this standard is with Revision B which went

into effect 30 March 1985. The first revision, A, was released

on 27 June, 1977.

Specific referenced documents required to supplement this

military standard are called out in the following DIDS:

DI-H-7047A

DI-H-7049A

DI-H-7048A

DI-H-7050A

3.1.6.2 NHB 5300.4(ID-2), SAFETY, RELIABILITY, MAINTAINABILITY,

AND QUALITY PROVISIONSFOR THE SPACE SHUTTLEPROGRAM

This NASA Handbook (NHB) establishes common safety,

availability, maintainability, and quality provisions for the

Space Shuttle Program. NASA Centers shall use this publication

both as the basis for negotiating safety, reliability, maintainability, and quality activities at the Centers.

This NHB provides common safety provisions for the Space

Shuttle Program to individual NASA Centers to assure that

applicable provisions of this N_B are imposed in lower tier

contracts.

Applicable safety requirements and tasks shall be included

in the basic management systems, design verification documents,

overall system analysis, system engineering requirements

definition, and design review practices.

Application guidance and rationale for selecting tasks to

fit the needs of a particular safety program are discussed in the

following sections of the NHB:

a. ID200,

b. ID201,

c. ID202,

d. ID203,

SAFETY MANAGEMENT

SYSTEM SAFETY

INDUSTRIAL SAFETY

TEST OPERATIONS SAFETY

7O
This standard was originally released in August, 1974 as

5300.4(ID-I) and revised in October, 1979 as an administrative

updating of 5300.4(ID-I) to incorporate changes approved by the

Program Director.

This NH incorporates provisions of NASA documents:

NHB 1700.1, NASA SAFETY MANAUAL, VOL. 1

NHB 5300.4 (1A), RELIABILITY PROGRAM PROVISIONS FOR

AERONAUTICAL AND SPACE SYSTEM CONTRACTORS

NHB 5300.4 (IB), QUALITY PROGRAM PROVISIONS FOR

AERONAUTICAL AND SPACE SYSTEM CONTRACTORS.

3.1.7 Reliability Standard Options

The options associated with Reliability Standards apply to

the extent that existing standards will be used and if so, to

what extent each may be employed. This options report is limited

to the two most widely used Reliability Standards in military

and/or NASA space programs. These two Reliability Standards are:

a .

b.

MIL-STD-785B, RELIABILITY PROGRAM FOR SYSTEMS AND EQUIPMENT

NHB 5300.4(ID-2), SAFETY RELIABILITY, MAINTAINABILITY AND

QUALITY PROVISIONS FOR THE SPACE SHUTTLE PROGRAM

71
3.1.7.1 MIL-STD-785B, RELIABILITY PROGRAM FOR SYSTEMS AND

EQUIPMENT

This standard consists of basic application requirements,

specific reliability program tasks, and application, guidance and

rationale for task selection. This standard is structured to

discourage indiscriminate blanket application. Tailoring is

forced by requiring that specific tasks be selected and that

certain essential information relative to implementation of the

task be provided by the procuring activity. The tasks can be

tailored to meet specific program needs for space and terrestrial

segments.

This standard provides general requirements and specific

tasks for reliability programs during the development,

production, and initial deployment of systems and equipment.

Tasks described in this standard are to be selectively

applied in contract-definitized procurements, request for

proposals, statements of work, and Government in-house

developments requiring reliability programs for the development,

production, and initial deployment of systems and equipment.

Task descriptions are intended to be tailored as required by

governing regulations and as appropriate to particular systems or

equipment program type, magnitude, and funding.

Application guidance and rationale for selecting tasks to

fit the needs of a particular reliability program is included in

Table 3.1.7-1.

This standard was revised to 785A in March 1969 and to 785B

in September, 1980.

3.1.7.2 NHB 5300.4 (ID-2); SAFETY, RELIABILITY, MAINTAINABILITY

AND QUALITY PROVISIONS FOR THE SPACE SHUTTLE PROGRAM.

This NASA Handbook (NHB)

reliability, maintainability, and

Space Shuttle Program.

establishes common

quality provisions

safety,

for the

The reliability provision in NHB 5300.4(1D-2) sets forth

reliability task requirements. Shuttle Program contractors

utilize the reliability provision as a guideline for program

reliability conduct. Furthermore, NASA centers use the

reliability provisions as a basis for negotiating reliability

tasks with Shuttle Program contractors.

Tasks described in the NHB reliability provision are applied

as an integral part of the design and development process. The

design and development process includes the evaluation of

hardware reliability through analysis, review and assessment.

These tasks are also intended to be tailored as required by,

and in accordance with, the applicable Data Requirement Documents

(DRD).

72
TABLE 3.1.7-1 APPLICATION MATRIX FOR SYSTEM PROGRAMDEVELOPMENT

TASK

TASK TITLE TYPE CONCEPT

PROGRAMPHASE

VALID FSED PROD

i00 System Safety Program MGT G

101 System SAfety Program Plan MGT G

102 Integration/Management of Assoc- MGT S

iate Contractors, Sucontractors

and All firms

103 System Safeaty Program Reviews MGT S

104 SSG/SSWG Support MGT G

105 Hazard Tracking and Risk MGT S

Resolution.

106 Test and Evaluation Safety MGT G

107 System Safety Progress Summary MGT G

108 Qualifications of Key System MGT S

Personnel

201 Preliminary Hazard List ENG G

202 Preliminary Hazard Analysis ENG G

203 Susystem Hazard Analysis ENG N/A

204 System Hazard Analysis ENG N/A

205 Operating and Support Hazard ENG S

Analysis

206 Occupational Health Hazard ENG G G G GC

Assessment

207 Safety Verification ENG S

208 Training MGT N/A

209 Safety Assessment MGT S

210 Safety Compliance Assessment MGT S

211 Safety Review of ECP's and MGT N/A

Waivers

212 Software Hazard Analysis ENG S G G GC

213 GFE/GFP System Safety Analysis ENG S G G G

G G G

G G G

S S S

S S S

G G G

G G G

G G G

G G G

S S S

S S N/A

G G GC

G G GC

G G GC

G G GC

G G S

S S S

S S S

S S S

G G G

NOTES: TASK TYPE APPLICABILITY CODES

ENG - System Safety Engineering

MGT - Management

PROGRAM PHASE

CONCEPT - Conceptual

VALID - Validation

S - Selectively Applicable

G - Generally Applicable

GC - Generally Applicable to

Design Changes only

N/A- Not Applicable

FSED - Full-Scale Engineering Development

PROD - Production

C- _ 73

o,
Application guidance and rationale for selecting tasks that

satisfies the needs of a particular reliability program is

included in applicable DRD's and statements of work.

NHB 5300.4(1D-2) was revised to the current NHB 5300.4 (1D2) in October 1979. As such, NHB 5300.4(ID-I) was canceled in

October 1979.

NHB 5300.4(1D-2) reliability provision incorporates

information from NHB 5300.4(IA), RELIABILITY PROGRAM PROVISION

FOR AERONAUTICAL AND SPACE SYSTEM CONTRACTORS.

3.1.8 Logistics Standards Options

Options associated with Logistics relate to the extent that

the Logistic Support Analyses (LSA) guidelines and requirements

are applied to the Space Station Program.

LSA guidelines and requirements are established by

Department of Defense (DOD) Instruction 5000.2, Major System

Acquisition Procedures, and DOD Directive 5000.39, Acquisition

and Management of Integrated Logistic Support for Systems and

Equipment. The requirements of this standard are applicable to

major and less-than-major system/equipment acquisition programs,

major modification programs, and applicable research and

development projects. The goal of this standard is single,

uniform approach by the Military Services for conducting those

activities necessary to (a) cause supportability requirements to

be an integral part of system requirements and design, (b) define

support requirements taht are optimally related to the design and

to each other, (c) define the required support during the

operational phase, and (d) prepare attendant data products. LSA

is the selective application of scientific and engineering

efforts undertaken during the acquisition process, as part of the

system engineering and design process, to assist in complying

with the supportability and other Integrated Logistic Support

(ILS) objectives through the use of an iterative process of

definition, synthesis, tradeoff, test, and evaluation.

This standard provides general requirements and descriptions

of tasks which, when performed in a logical and iterative nature,

comprise the LSA process. The tasks are structured for maximum

flexibility in their application. In addition to the general

requirements and task description sections, this standard

contains an application guidance appendix which provides

rationale for the selection and tailoring of the tasks to meet

program objectives in a cost effective manner. This document is

intentionally structured to discourage indiscriminate blanket

applications. Tailoring is forced by requiring that specific

tasks be selected and that certain essential information relative

to implementation of the selected tasks be provided by the

requiring authority. Additionally, the user must be aware that

when the LSA process, or a portion thereof, is implemented

contractually, more than the LSA statement of work and LSA

deliverable data requirements must be considered. Readiness and

74
supportability requirements and objectives must be appropriately

integrated and embodied in specifications, general and special

contract provisions, evaluation factors for award, instructions

to offerors, and other sections of the solicitation document.

Defense system acquisitions are directed toward achieving

the best balance between cost, schedule, performance, and

supportability. Increasing awareness that supportability

factors, such as manpower and personnel skills, are a critical

element in system effectiveness has necessitated early support

analyses, the establishment of system constraints, design goals,

thresholds and criteria in these areas, and the pursuit of

design, operational, and support approaches which optimize life

cycle costs and the resources required to operate and maintain

systems. This standard was prepared to identify these early

analysis requirements and foster their cost effective application

during system acquisitions.

Individual tasks contained in this standard shall be

selected and the selected task descriptions tailored to specific

acquisition program characteristics and life cycle phase.

Application guidance and rationale for selecting tasks and

tailoring task descriptions to fit the needs of a particular

program are included in appendix A. This appendix is not

contractual and does not establish requirements.

Unless otherwise specified, the following standards and

handbooks of the issue listed in that issue of the Department of

Defense Index of Specifications and Standards (DoDISS)) specified

in the solicitation form a part of this standard to the extent

specified herein.

Military Standards

MIL-STD-1366 Material Transportation System

Dimensional and Weight Constraints,

Definition of.

MIL-STD-1388-2A Logistic Support Analysis

Element Definitions.

Data

MIL-STD-1629 Procedures for Performing a

Failure Mode, Effects, and

Criticality Analysis.

(Copies of specifications, standards, drawings, and

publications required by contractors in conjunction with specific

procureement functions should be obtained from the procuring

activity or as directed by the contracting officer.)

75
3.1.9 Maintainability Standards Options

This options report identifies Maintainability standards which

are applicable to Maintainability Programs of the Space Station

Data Systems. This options report is limited to two most widely

used Maintainability Standards in Military and/or NASA Space

Programs. These two Maintainability Standards are:

MIL-STD-470A, MAINTAINABILITY PROGRAM FOR SYSTEMS AND

EQUIPMENT NHB 5300.4(ID-2), SAFETY, RELIABILITY,

MAINTAINABILITY AND QUALITY PROVISIONS FOR THE SPACE SHUTTLE

PROGRAM.

3.1.9.1 MIL-STD-470A MAINTAINABILITY PROGRAM FOR SYSTEMS AND

EQUIPMENT

This standard consists of basic application requirements,

specific tailorable Maintainability program tasks, and

application, guidance and rationale for task selection. This

standard is structured to discourage indiscriminate blanket

application. Tailoring is forced by requiring that specific

tasks be selected and that certain essential information relative

to implementation of the task be provided by the contracting

activity. The tasks can be tailored to meet specific program

needs for space and terrestrial segments.

This standard provides task descriptions for

maintainability programs. The tasks, as tailored, will be

applied to systems and equipment development, acquisitions and

modifications. Software maintainability is not covered by this

standard.

Tasks described in this standard are to be selectively

applied in Department of Defense contract-definitized

procurements, request for proposals, statements of work, and

Government-in-house developments requiring maintainability

programs for the development and production of systems and

equipment.

Task descDiptions are intended to be tailored as required by

their users as appropriate to particular systems or equipment

program type, magnitude, and funding.

Application guidance and rationale for selecting tasks to

fit the needs of a particular maintainability program are

included in attached Table 3.1.9-1.

This standard originated in March 1966 and was revised in

January 1983.

Government Documents The following documents, of the issue

in effect on date of invitation for bids or request for proposal,

form a part of this standard.

78
Standards

Military

MIL-STD-280, Definitions of Item Levels, Item

Exchangeability, Models, and Related Terms

MIL-STD-471, Maintainability, Verification/Demonstration/

Evaluation

MIL-STD-721, Definitions of Terms for Reliability and

Maintainability

MIL-STD-785, Reliability Program for Systems and Equipment

Development and Production

MIL-STD-1388-l,Logistics Support Analysis

MIL-STD-1629, Procedures for Performing a Failure Mode,

Effects and Criticality Analysis

Publication None

Military Handbook MIL-HDK-472, Maitainability Prediction

3.1.9.2 NHB 5300.4(ID-2); SAFETY_ RELIABILITY_ MAINTAINABILITY

AND QUALITY PROVISIONS FOR THE SPACE SHUTTLE PROGRAM

This NASA Handbook (NHB) establishes common safety,

reliability, maintainability, and quality provisions for the

Space Shuttle Program. NASA centers use this publication as a

basis for negotiations with Shuttle Program contractors and as

the guideline for conduct of program safety, reliability,

maintainability and quality activities at the centers.

The maintainability provision in NHB 5300.4(ID-2) sets forth

maintainability task requirements. Shuttle Program contractors

utilize the maintainability provision as a guideline for program

conduct. Furthermore, NASA centers use the maintainability

provisions as a basis for negotiating maintainability tasks with

Shuttle Program contractors.

Tasks described in the N_B maintainability provision are

applied as an integral part of the design and development

process. The design and development process includes the

evaluation of hardware maintainability through analysis, review

and assessment.

Tasks described in the NHB maintainability provision are

intended to be tailored as required by, and in accordance with,

the applicable Data Requirement Documents (DRD).

Application guidance and rational for selecting tasks that

satisfies the needs of a particular maintainability program is

included in applicable DRD's and statements of work.

NHB 5300.4(1D-2) was revised to the current NHB 5300.4(1D-2)

in October 1979. As such, NHB 5300.4(1D-I) was canceled in

October 1979.

77
NHB 5300.4(ID-2) Maintainability provision incorporates

information from NH 5300.4(A), Reliability Program Provision for

Aeronautical and Space System Contractors.

3.1.I0 Procurement Standards Options

In the past, Government prime contracts were awarded in

accordance with the applicable Government Agency regulations

in effect at time of prime contract solicitation and award.

These individual agency regulations were incorporated as the

result of statutes, laws, regulations, Federal acquisition

regulation, Agency supplements, etc., developed over the

years.

On April 01, 1984, NASA, DOD and other Government Agencies

adopted Uniform Federal Acquisition Regulations commonly

known as FAR. The FAR, with agency supplemental

regulations, replaces Federal Procurement Regulations (FPR),

the Defence Acquisition Regulation (DAR) and NASA

Procurement Regulation (NASPR). It provides a uniform

regulation for use by all Federal Executive Agencies in

their acquisition of systems, supplies and services with

appropriated funds. The FAR system has been developed in

accordance with the requirements of the office of Federal

Procurement Policy Act of 1974, as amended by Public Law 96-

83. The FAR is issued within applicable laws under the

joint authorities of the Administrator of General Services,

the Secretary of Defense, and the Administrator for the

National Aeronautics and Space Administration, under the

broad policy guidelines of the Administrator for Federal

Procurement Policy.

The FAR is published in (i) the daily issue of the Federal

Registar, (2) cumulated form in the code of Federal

Regulations (CFR) and (3) a separate loose-leaf edition.

The FAR is issued as Chapter 1 of Title 48, CFR. Subsequent

chapters are reserved for agency acquisition regulations

that implement or supplement the FAR.

The FAR provides for coordination, simplicity and uniformity

in the Federal acquisition process. It includes changes

recommended by the Commission on Government Procurement, the

Federal Paperwork Commission, various congressional groups

and others.

In short, the FAR has been developed to make the Federal

procurement process more streamlined, efficient, yet still

protect the Government's interests when dealing with private

enterprise or the Commercial Sector.

It is highly unlikely any Federal Agency would deviate from

the FAR when contracting for services as such action would

be contrary to the intent of Public Law and create problems

of legality or procurement policy implementation problem for

the Federal Agency.

78
A. Options

There are no viable options when dealing with large Federal

Agency Procurement.

Private industry utilizes the Uniform Commercial Code (UCC)

as a standard for commercial procurement activity; however,

it is totally inappropriate for Government procurements.

All companies have their own "Commercial" terms but these

also have broad differences in terms of content and

consistency and do not constitute any sort of standard.

79
There are various standards re].ating to video swsLems which are potenti,_].ly

candidates for use in SSIS. Since operational scenarios have not been

explored in any significant detail, the purpose of the compilation below is to

give the salient characteristics of some of the "standard" candidates and

advantages and disadvantage For various SSIS applications.

]it is worthwhile noting that a video subsystem that might be used to support a

docking and berthing operation would require a much higher resolution than a

video subsystem used to act as surveillance within a module. Similarly,

robotic setups of an experiment (a.ttached or remote from the space station)

would probably require a full. real time picture, which it might be acceptable

to receive a slow scan (or even Frozen frame) picture From that same can,era

once the experiment is under way.

Another factor in selecting from the candidate video systems is in the control

of the video systems. Video which is used to monitor payloads will probably

be under control of the mission specialist or personnel at. the POCC; video

which is used For onboard core/Space Station operations will probably be

managed by the responsible crew personnel using a control console/studio like

switcher and mixer. These are to be custom devices, although they should

accommodate standard electrical interfaced, signal levels, losses, etc.

Finally, the selected candidates should, conceivably, be selected so that

various signals can be "meshed" within a channel hierarchy.

Candidate i. RSI7OA, NTSC, EIA Standard -'This is presently utilized at JSC

mission control center, for an in-house 525 live, scan rate,

color system. In compressing the three primary color channels

into one signal, some video detail is sacrificed, which still

yields acceptable entertainment quality.

Advantages

Video is distributed over single coax. interface.

All equipment is available off-the-shel? at the present and probably

will be in the future.

Ease of set up and maintainability.

Video signals can be modulated on RF carriers and distributed for

viewing on color receivers.

Signals would be compatible with the existing NASA ground facilities

and television networks, including satellite transmission links.

Cost effective.

Disadvantages

Requires video switching equipment to route multi-video sources to

multi-users.

User requires a control module to access the video switch.

Horizontal resolution is reduced.

BO
Cand:i.d_te2, R_.I/O "c_ - s EIA Standard (monocl')r'orne) -.. Standard broadc:ast: m, ")((:hrome

studio Facit[t:i.es operate at a 525/60 scan rate. l-he

specifications are s.i.milar to that of the RSI/OA system (above)

but a subcarrier is not used.

Advantages

Video is distributed over single coax interface.

Equipment is available off-the-shelf.

Ease of setup and maintainability.

Video signals can be modulated on RF carriers and distributed For

viewing on monochrome receivers.

Signals compatible with existing NASA Facilities.

Equipment is very cost effective.

Improved horizontal resolution,

Disadvantages

Black-white only

Grey level control is difficult.

Candidate 3. T'TL Video- Used for certain computer terminal applications or

TIL - compatible levels. Equipment is available off-the-shelf.

This candidate requires three separate interfaces (red, green,

blue composite) or four for a non composite signal plus synch; a

subcarrier is not necessary. This type of system is a good

candidate for alphanumeric high resolution display.

(]andidate 4, RGB Color -'This routes red, green , blue over separate cables,

which provides display detail better than is available via

traditional encoded broadcast color. The green signal channel

is usually the composite. Some RGB systems use a non composite

signal format an separate color component cables and relay on a

separate synch interface.

Advantages

* High resolution displays.

* Color

* Equipment available off-the-shelf.

* Can be compatible with standard NTSC television.

* Utilizes video Format.

Disadvantages

Requires triple video switching equipment to route multi-sources to

multi-users.

Control modules required to access video switch.

Requires three or four cable interface for routing video signals.

Not cost effective.

Setup and maintainability more difficult due to timing of the

separate RED, GREEN and BLUE signals.

81
Cand:[date 5, R!,;330A, EI:A Standard .....Thi. s type of system, pri.mar'J..I.y used f'L_r

close.d circuit IV (CC[V), oper'_:{t;es <at the 525/60 scan rate. [t

is used where the signal is generated loca].].y, e.g., on the

Space Station, and where pict;ure quality can be controlled, ,._s

by the C&T system.

Candidate 6, RS353A, EIA Standard -[his system is for morlochr'ome CCTV, used

at rates other than 525 line scan. Recommendations are for 675,

729, 875, g45, 1023 lines, all at 60Hz for the field with a 2:1

interface. JSC Mission Control uses the 945 line scan rat;e.

Advantages

_ High resolution.

w Equipment available off-the--shelf for most scan rates.

Single table interface.

_ Ease of setup and maintainability.

Cost effective.

Disadvantages

Monochrome displays.

Not all equipment available as off-the-shelf.

Not compatible with any other standard.

Option 7. NASA Standard SE-36661

Display Generation Equipment.

DGE converts computer language data into dynamic raster-vide0 displays

containing both alphanumeric (A/N) and graphic information. Equipment

refreshes continually the last information received or until updated by the

computer. DGE output is a digital video signal, 1.4 volt P/P composite For

display on 945 line TV monitors.

This equipment is presently utilized in the JSC Mission Control Center for

converting shuttle tracking data into usable displays which are available to

flight controllers monitoring Shuttle Missions.

Audio Standards

There are a wide variety of Audio Standards that will pertain throughout the

SSDS, particularly on Ground Segment communication. These standards are

described in the following table (3.1.11-1).

A typical standard Audio (Voice) Analog interface is a 3002 (FCC tariff No.

260) and is as follows:

82
lab]e 3. I, Ii-i

FelephoneConditioning Parameters

Non-Cond i t ioned

3002 Channel

With CI With 02 With 04

(]ond:[tioning (]onditioning (]onditio,'_[rlg

F-requer_cy

Range In

Hertz (Hz) 300-.3000 300-3000 300-..3000 300....3000

-A-_-_i-_'_'_'{';_............... F;;q"i................... _'_i"Y?................................................ F_eq. Deci ;............................................... Freq. Deci_............................. Freq _.................... De_i?...............

Distorting Range Vari. Range Vari. Range Vari. Range Vari.

(Net Loss at I000 Hz)

300-3000 -3 to +12 300- -2 to +6 300- -2 to +6 300 .......2 to

2700 3000 3200 _.6

500.--.2500 -2 to +8 i000- -I to +3 500- -i to +3 500- -2 to

2400 2800 3000 .F3

300- -3 to +12

3000

Delay

Distortion in

Microseconds

Less than 1750 s

from 800 to 2600 Hz

Less than I000 s

from I000 to 2400

Hz. Less than

1750 s from 800

to 2600 Hz.

Less than 500 s

from I00 to

2600 Hz.

Less than 1500 s

from 600 to 2600s

Hz. Less than

3000 s from 500

to 2800 Hz

Less than

3OOs from

IOOO to 2600 Hz.

Less than 500

from 800 to

28OO Hz.

Less than

1500 s from

600 to 3000 s

from 500 to 3000

HZ.

Signal to

Noise (dB) 4 " "" 24 24 24

Non-Linear

Distortion

Signal to

2nd Harmonic

(dB)

25 25 25 25

Signal to

3rd Harmonic

(dB)

30 30 30 30

• , _ ..

83
3,1,12 Data Interfaces Standards Options

SpecifJ.cations or" Standards which apply to Data interfaces are as

fol lows :

Federal Standards

Fed--Std-lO03

Fed.....Std-lO20

Fed.-Std-lO30

ELIZAStandards

RS..--.334

RS-363

RS.-...366

RS-234

RS..--422

RS-423

Mil Standards

Mi]...-Std-188-1OO

DOD--C-85045

Mil-Std-188-144

lelecommunications Synchronous Bit Oriented Data Link

(.:entreI Procedur'es

lelecommunications Electrical Characteristics of

Balanced Voltage Digital Interface Circuits

le.l.ecommmunications Electrical Characteristics of

Unbalanced Voltage Digital Interface Cii"cuit

Common Long Haul and 'Tactical Communications System

Technical Standards

Cables, Fiber Optics, General Specificati.ons

Electrical Characteristics of Digital Interf_xce

Circuits

._.n_t._r;na_t3_on.a!___it__and_ards

15..--1745-I. 975 Basic Mode Control Procedures For Data Commun:i.cat:i.orls

C,CIFT Standard s

V. 2

V. 4

V.IO (X.26)

Power Links over Telephone Lines

General Structure of Signals For Data Transmission

over Pub].ic lelephone Network.

I-lectrical characteristics For unbalanced

double-current interchange circuit general use with

ini, egrated circuit equipment in the field of data

commun:i.cation,,_ (and provisional amendments, May 1977),

84
v.lt (x.27)

V.15

V.19

V. 20

V.21

V.22

V.22bis

V.23

V.24

V.25

V.26

V. 26bis

V. 27

V. 27bis

V. 27ter

Electrical characteristics for balanced double-..current

interchange circuits general use with integrated

circuit equipment in the field of data communications

(and provisional amendments, May, 1977).

Use of acoustic coupling for" data transmission.

Modems for parallel data transmission using telephone

signaling frequency.

Parallel data transmission modems standardized For

universal use in the switched telephone network.

200.-.bit/s modem standardized for use in the general

switched telephone.

Standardization of data signaling rates for

syrlchr-onous data tr'ansrnission genera], switched

telephone network.

Standardization of data signaling rates for

synchronous data transmission leased telephone-type

circuits.

600/1,2K bit/s modem standardized for" use in the

general switched telephone network.

List of definitions for interchange circuits between

data terminal equipment data circuit terminating

equipment (and provisional amendments).

Automatic ca].ling and/or answering equipment on t;he

general switched telephone network inc ].ud.i.n(..] d :i.sabl.i.ng

of echo suppressors on manually established.

2.4K/1.2K bit/s modem standard:i.zed For" use on

four-wire leased circuits.

2.4/1.2K bit/s modem standardized for use in the

general switched telephone network.

4.8 Kbit/s modem standard:i.zed for use on leased

circuits.

4.8 Kbit/s modem with automatic eclualizer standard:i.zed

for use ono leased equipment.

4.SK/2.4K bit/s modem standardized for" use J.n the

general switched telephone network,

85
V. 28

V. 29

V. 31

V, 35

V, 36

Electrical characteristics for unbalanced

double-current irlter.-change circuits.

9.6 Kbit/s modem for use on leased circuits.

Electrical characteristics for single-current

interchange circuits control].ed contact closure.

Data transmission at 48 Kbit/s using 60.-to-i08 l<l-.Iz

group bi.t/s circuits.

Modems for synchronous data trans-.mission using

60-to-108 KHz group circuits.

86
3.2 SYSTEMMANAGEMENT

The purpose of this paper is to descr:ibe options for managemerrt and

interfacility coordination of the end-to-end Space Station Data System (SSDS),

wlnich includes the following:

o Processing nodes, distributed among Space Station program e].ements

(SSPE's), space and ground

o Local Area Networks in space

o Uplink/downlink TDRSS links

o Wide Area Communication Network

o Regional Data Centers (RDCs), Data Handling Centers (DHCs), Payload

Operations Control Centers (POCCs), etc.

o Local Area Networks on the ground

Each of the elements, facilities, and the links between them must be managed.

Primary management functions are:

o Network Control (including Scheduling)

o Network Monitor:[rig

o Network Administration and Configuration Management

o "Network Maintenance (including Emergency Management)

o Customer/SSDS Interface

Options for the above are presented in this paper. Most of the options

describe the types of decisions wlnich need to be made, since defilnitive option

deF:i.rlition will depend on specific SSDS subsystem designs and ongoing NASA

policy decisions.

3,2.1 Network Control

Network Control options relate to which components of the SSDS will be

controlled and in what manner. 'This control includes scheduling and

prioritized access to SSDS resources and services.

Control coordination will also be needed for tlne TDRSS and DOMSAIlinks/arrterlnae, the existing Wlnite Sands NASA Ground Terminal, the proposed

New IDRSS Ground Terminal, and the NASCOM TDRSS network, etc.

Primary opt:[or_s relate to the enhanced control functions to be implemented

within the existing Network Control Center (NCC) versus elsewhere within the

SS[)S. The extent of this enhancement of functionality within the existing NCC

versus more distributed responsibility For NCC-type control is an iml:)ort_.,:u'Yt

NASA progr'ammai'::i.c option. Additiona]. analysis is needed to determine wh:i.ch

network control Functions can be accel:)tably distributed, in conjunction w:i.I:h

system responsiveness, cost/benefit, security, etc. tradeoffs.

87
Another opi';ion is to develop a newNCOins'Lead of extensively upgrading the

existing facility. As increasing network control function can be feasibly

automated, the NCCcan focus moreon network management,fault detection, etc.

Another important progranlmatic option is the extent of distribution of command

and control responsibility. Restricted commands,for example, mayneed to

pass through a central control and verification node, whereas manyindividual

nodes mayhave authority to validate and send unrestricted commandsto the

different SSPE's.

'Restricted' commands,and commandsaffecting flight SSPE'swill require more

commandand control verification and checking than unrestricted commandsor

commandsfor ground elements.

3.2.1.1 Real Time Control

Options include the extent of real-time control to be provided, for which

functions, and for which SSPE's. Their implementation may also-vary in their

degree of centralization, their space/ground distribution, etc.

Assessments are needed as to the degree of function centralization versus the

ability to perform them in real.--time. Functions specific to a particular SSPE

and autonomously implemented there may be more easily handled in real or near

real--time. Functions which require coordination among SSPE's or other

resources, however, may require some centralized control and may only be able

to be performed in near real-time.

In emergency situations, for example, it may be necessary to re.-_irect

traffic, reallocate resources, or even shut down some users. These are

necessary SSDS control functions. Critical control functions therefore must

have alternative or redundant implementations in the event of failure or the

primary control function path. Redundant functions may often have somewhat

lesser capabilities than their primary implementation, since they wil]. be

invoked only in rare or emergency situations. This must not occur, however,

for critical control functions with real-time requirements. Critical

real-time control functions must also be fully supported in redundancy mode.

3.2.1.2 Intermed:Late l"ime Controls

Many network control functions may not be real-time critical, such as

equipment reconfiguration, long term resource scheduling, etc. In these

instances there may be a wide tolerance in acceptable response times. It is

therefore anticipated that the redundant implementation of these funcLions

will sat:'.sfactorily be able to meet their required response.

3.2.1,3 Commun:ications Link Scheduling/Priorit:ization

Optional prioritization schemes For communication ].ink utilization and

conflict resolution are possible. Emergencies and mission critical situations

presumably will have first priority, and link allocation must be expedited in

these situations.

88
In addition, a system of dynamically allocated priorities, in which link

utilization is automatically and dynamically scheduled according to current

traffic loads and priorities, is desirable. The use of automated software

capabilities for automated scheduling is an attractive option if

technologically mature by IOC. Cost and reliability criteria need to be

evaluated. Increased automation should reduce the required ground suppor't,

however, and may facilitate function decentralization.

The required security and availability of the SSDS communication traffic and

links must be maintained. Prioritized usage of alternative links when primary

links are not available needs coordination and control since capacities of

alternate links may be less than that of primary links. Verified update

procedures are important to maintain system integrity as well as system

transparency to updates. The breadth of checking of updates required is an

important factor.

The everyday schediAling and control of network links will depend on details of

the network design and decisions regarding prioritization of service, lhe

selection of options will depend on SSDS design features and on NASA policy

decisions related to network allocation priorities and function implementation

alternatives.

3,2.1.4 Long Term Planning & Scheduling

t.ong term planning and scheduling of missions, resource utilization, and data

management are important areas of system management. Options for these areas

are discussed throughout the rest of this paper; in general litt].e

time--criticality is associated with long range planning functions.

3.2.2 Network Monitoring

The extent of network monitoring and performance assessment is another

programmatic option. Each node can be assigned different responsibilities for

monitoring and assessing its performance. This distribution in the network

monitoring and performance assessment function will need to be cout}terbalan(-ed

with a need for centralized responsibility for overall network monitoring and

assessment, The decision to maintain responsibility for overall network

performance, analysis, and statistics availability with the Network Centre].

(]enter (NCC) will n(._ed to be reassessed in terms of the breadth of lo('ation

and furlctiona].ity of the SSPE's and the enhanced capabilit:i, es w:i.thin each S,_;I:)E.

3.2.2.1 Network Monitoring Data Management

lhis section describes the options for the collections of system management

data from the network, to be used for the following example purposes:

to support network control (from real-time controls to long term network

planning and scheduling)

-.. to support troub].e shooting and repair"

-- to support network usage and billing

-. to assess ongoing network performance and ongoing resource utilization

B9
Options related to manyof these issues are presented in the 'White Paper' on

'Network Monitoring and PerformanceAssessment', covering options category

2.6. Additional options are discussed below.

3.2.2.1.1 Data Collection

High level decisions are:

What types of data are to be collected for each facility, subsystem,

and component?

Data types will range from resource utilization and performance statistics to

ongoing monitoring and maintenance (data. These data can be reported for each

SSPE, for each SSPE subsystem, and/or for each subsystem component (individual

processors, etc.).

How will the data be transported to the location where analysis is to

be performed?

How much of the data will require real-time or near real-time e].ectr'oi'lic

transmission versus periodic offline delivery? Some (data wi].l require

transport to the central monitoring node, i.e., possible security breach

information, etc. Ongoing performance statistics (not resulting in a fault

detection), on the other hand, may only need to be reported weekly or monthly.

Extensive (data collection could impact the performance of the data system

itself. The extent of data collection and monitoring needs to be evaluated

with respect to the overall performance requirements and capabilities of the

SSDS.

The extent of error detection and correction performed at each node is another

option. The techniques for determining the bit error rates and how these

differ by data type are discussed in the 'Network Monitoring and Performance

Assessment' white paper.

It is also important that the types of data collected should have a direct

relationship to the controls implement, i.e., one should have a real time,

short term, or a long term response based on the evaluated results of the

measurement <data. Th:is may not always be possible. Where it is possib].e, it

suggests the groundwork for future automation of the data system.

3.2.2.1.2 Data Reporting

l"l'lere are options in the periodicity, scope, and breadth of disseminatJ.on of

management and network performance information. Certain types of irlfor'mation

will require more regularity, greater deta'tl, or wider" d:istr:ibution than oi';her

types. Although extensive reporting might affect SSDS perfor'mance, report;:i.ng

is generally expected to represent a sma].1 overlnead compared to its

contribution to efficient system management.

3.2.2.2 Data Analysis

The te(;hniques to analyze the data shou].d be determined pr'ior to its

co].lection. '[he types of reports to be made and to whom, the anticil:)ated

9O
results of analyses, and the types of corrective measuresindicated need to be

dec ided,

3,2.2.3 Cost Accounting

The breadth of accounting performed is another option. The breadth and depth

of resources mon'Ltored will determine the amount of data required.

An important area is the customer accessibility to up-to--date cost information

for services he desires or has used. Standard services such as CPU

utilization, data base management and data storage will normally be monitored

but what will be the accounting procedures to accommodate specialized

services, or do we presume the SSDS will know all possible service requests

before each mission?

Important criteria in deciding the limits of information tracking and

reporting are cost versus responsiveness. Highest SSDS responsiveness and

data accountability are desired on the part of the user community. It is

- nevertheless impractical to track and report on each quantum or packet of data

and/or to track the performance of each component. Development and operations

costs and likely performance degradation will probably be the primary cri.teria

in limiting the extent of information tracking and accounting.

A broader tradeoff is the relative funding priority of the entire function of

data admin:istration and accounting versus choices for better (and more

expensive) technology, increased function redundancy, increased mission

support, etc.

3.2.3 Network Administration

Typical network administration functions are:

o Configuration Control

This includes functions such as resource allocation tracking, system access

authorization control, resource prior itization algorithms, command managernent

tables, etc.

o Integration and Initializlation of Hardware/Software

This includes system startup configurat:[on, tracking of the integration and

implem(_ntation of new capabilities, etc.

o Hardware/Software Ul:)dates Management

lhis includes management and control of system updates in hardware and

software, documentation control and requirements, ma:Lrlter_ance of t(_st

procedures for updates, etc.

Network administration involves integrating and initializing software, making

updates, tracking hardware and software version numbers, etc. Two import_nt

subfurlct:iorls involved in administration are:

o maintenance and update of databases which record the current data

system conf:Lguratiorl, for each faci].ity, subsystem, and componeni:

91
o administration of the software which provides the actual data system

functions ......... modifying routing tables, etc. In addition, checking must

be performed to insure that parameters, software versions, etc., are

correct, up-to-<_ate, and compatible with other facilities,

subsystems, and elements.

3.2.3.1 Centralized Versus Distr.i.buted Options

Configuration databases may vary from totally centralized to totally

distributed. A centralized database is easier to control and update; it may

be difficult to access by remote sites, however. A fully distributed database

is more accessible to each facility, but if there are overlapping needs for

the same database information, it may be next to impossible to keep their

information synchronized, Distributed implementation may also incur increased

costs due to replication of hardware and software.

Similarly, the degree of centralization of network administration can vary. A

centralized administration has the advantage of locating all the relevant

expertise and information in one or few places ...... reducing chances for error

and the required number of staff. Communication costs may increase, however,

if the central administration staff need to access atqy node in the network.

Increased distribution in network administrat_ion will generally result in a

larger staff and greater costs, but more autonomy and self--<Jirection.

3.2.3.2 Configuration Control Options

Configuration control is the tracking of hardware and software modifications

or" updates and administering an orderly management, scheme for these functions.

The control of SSDS updates, both onboard and on the ground, is important.

Options include :

i. ]he extent of simulation and/or checking required before authorization is

granted for insertion or replacement of hardware or software.

2. The amount of concurrency in running the updates s.i.multaneously with the

existing version until adequacy of the update is assured.

3 , The documentation and update control procedures, including the extent of

corroboration of NASA personnel and customers before ul._date insertions are

a p p r o ved.

The options chosen will depend on the exact funct:[ons being updated, their

criticality, the cost of extensive checking, etc.

Optional configurat:Eon management procedures can be implemented.

For critical, potentially life-threatening functions, a centralized, highly

contro].].ed configuration monitoring may be necessary. Distributed update and

function migration responsibilities may be possible, however, in the areas of

pay].oad reconf:EguraLion, non--cr:itica], core subsystem funct:[ons, etc.

The management of function migration from ground to space (which will be an

ongoing process in the Space Station program) is an impor'tant area, discussed

below.

92
3.2.3,3 SpaceGround Funci_ionality Transfer Procedures

In addition to regular updates due to error detection and correction, er_han(-ed

capability insertion, etc., a Space Station program goal is to evolve to an

ever more autonomous Space Station base, with fewer and fewer functions

required on the ground (with associated large ground support staff).

Updated functionality, in}plemented both in hardware and software, will need to

migrate from ground to space as the functionality achieves a sufficient degree

of compactness, reliability, and verification. A broader spectrum of test'Lng

and organizational approval may be required, however, before deciding to

migrate a ground-based function onboard. Efficient and thorough configuration

management of ground-to-space upgrades will require precise record keeping and

adequate check out procedures.

3.2.3.4 Network Administration/TMIS Interface

The TMIS network will be primarily responsible for program management,

configuration control, and data commtinications in the areas of documentation

and systems engineering support.

The overlap of functions and required data between the TMIS and the SSDS needs

to be assessed as the TMIS definition becomes mature. Options regarding Lhe

procedures and controls for information exchange between the two systems need

to be <developed.

lhe breadth of data interchange and replication and the privacy of each data

type will be key options. The degree of compatibility between TMIS security

and SSDS security in areas of management data will require coordination.

3.2.4 Network Maintenance

In addition to updates management, maintenance of hardware and software and

the repair of (detected malfunctions are an important SSDS function. An

expanded discussion of software maintenance options related to the SS[)S is

presented in the options white paper on 'System Development', Section 3.5.

Options for hardware maintenance and selected management issues are presentecl

here.

3.2.4.1 Redundant Function Implementatiorl Op'Lions

In coordination with maintenance and repair procedures, the extent of

redundancy in certa.i.n functions, and the amount of space/ground replicai;ion

need to be decided. Fun('t:'Lon rep].ication to provide redundancy may be

preferred over system repair or replacenlent optior_s. Factors aff-'ecting these

choices are cost, weight and space (onboard considerations), and/or function

critical.i.ty. For critical functions, replication may be required in order Lo

minimize possible downtime of i:hese functional capab_.lities.

3.2.4.2 lroub].e Shooting & Repair

93
3.2.4.2.1 Emergency Management Options

The extent of backup recovery opi:ions upon subsystem or component Failure will

depend upon mission criticality and/or crew and Station safety concerns.

The extent of crew training and responsibility during emergency recoveries

versus the amount of online ground support is an important option area for

each emergency type.

An assessment needs to be made of the relative likelihoods of various types of

subsystem failure before an intelligent set of emergency procedures options

can be formulated.

3,2.4.2.2 Separate Vs Dupli('ate Maintenance Functions

Another option is whether maintenance functions are implemented within the

same data system hardware and software as that which provide the data system

Functions, or whether separate hardware and software are used.

Use of the same hardware and software reduces costs. However, failures of key

components might hinder fault detection, maintenance, or repair. For examp].e,

if the same communication path is used for maintenance as for normal

operation, there may be no alternate way to reach the failed link or node for

testing and fault isolation. The provision of separate access ports and

separate diagnostic software may insure reliable access to processing nodes.

3.2.4.3 Hardware Maintenance Options

The primary options here relate to the extent and periodicity of ongoing

hardware maintenance checking and subsequent repair procedures when problem,,_

occur.

Maintenance checking breadth and periodicity relate to the extent of hardware

devices monitored and the frequency with which this monitoring is performed.

Critical functions will require more thorough monitoring and usually more

frequent monitoring, depending on the time-criticality of associated repairs.

-Fhe repair procedures once problems occur have options oF swit(:hover to

replica components or to alternative function/service implementation, as

discussed in Sections 3.2.4.1, 3.2.4.2, and 3.2.5.5. For certain non--crit:i.ca].

Functions, it might be acceptable to have no backup redundancy but to repair

the prob].em online as it occurs (if little risk occurs for delayed repairs due

to unforeseen problems) performed.

An important aspect of hardware maintenance is the ability to quickly and

accurately iso].ate problems. Normal diagnosti.cs packages, often provided by

vendors, may be adecluate to detect the large majority of problems which may

occur. Some unusual problems may not be detected, however, and it can be

vital to isolate such fau].ts. One procedure, which may be useful, espec:i.al].y

For critical Functions, is to have interface diagnostics available between

each hardware component or subsystem. The interface diagnostics wou].d provide

the capability to send a spectrum of inputs to the device and monitor the

expected outputs. Assuminc_ a sufficiently broad spectrum of inputs to

completely test the fun<'tionality of the device, this pro('dure may help _o

isolate faults which vendor d:i.agnost:i.cs packages may not dete(;t:.

94
The implementation of such interface diagnostics will occur during the design

and assembly of the hardware systems. A decision to incorporate such

procedures needs to be made during the design process to assure efficient and

thorough implementation of this capability.

The other key aspect of hardware maintenance is the set of procedures to

repair detected faults, subsequent to redundant function or component

implementation. For onboard components, a key issue will be whether to have

tile crew repair particular components versus waiting for replenishment of the

components on the next scheduled Shuttle rendezvous. For criti('al components

which fail, decisions will need to be made as to whether single redundancy is

sufficient since the intervals between Shuttle dockings may be many weeks

apart. Will triple redundancy for some components be required, and will this

even be adequate for some items, especially ones for which the crew will be

incapable of repairing.

Key tradeoff factors in these decisions will be the criticality of the

hardware component, the cost, weight, and space requirements of the spare

components, and the likely ease of repair by the crew.

3.2.4.4 S/W Maintenance Options

See options paper on 'System Development", options section 3.5.

3.2.5 Customer/SSDS Interface Options

Options for interfaces between the SSDS and the customer are presented here.

The options related to interface with the SSDS Simulation (]enter (SC), mission

integration, the Software Support Environment (SSE), onboard training, and

alternative service restoration (in case of failure) are discussed.

3.2.5.1 Simulation Center

Basic options relate to the location, responsiveness, and breadth of

Simu].ation Center (SC) services to support customer tests of operational

procedures; software, payload, hardware, and core services interfaces; and

performance estimation and modeling. For each of these functions, the extent

of services provided, the user-friendliness, and cost are key tradeoff

criteria.

The responsiveness, diversity of locations, and breadth of the SC services are

SC cost drivers ...... rapid response requires potent CPU capabilities; wide

location diversity increases replicatiorl costs for hardware and software;

breadth of services implies extensive software development.

3,2.5.2 Mission Integration Planning

Key options are which procedures and system services will be provided to

assist in the integration of new missions. Examples are i) the provision of

s'Lmu].ation capabilities to check.--out instrumentation prior to onboard

integration and 2) a customer interface organizati.on to handle management and

negotiation of new mission requirements and goals. This latter area is

discussed in the 'Wide Area Comi_unicat:Eons' white paper, Section 2.5.2.2.10.

The extent to which new missions _.i.ll need to be validated (at the Silm_lation

95
Center, etc.) before flight approval may involve a tradeoff between SSDS

user.-friendliness and the need for assured and adequate system operations.

The deve].opment of SSIDS software and operations support hardware of sufficient

responsiw,_ness and thoroughness may be an important option. Simplified

checkout procedures and minimal checkout times are desired, however.

Information on the availability and associated costs of using system resources

will be valuable. Other important factors include the capability for

extensive checkout of equipment and software by the customer at his home

facility and the degree and ease of use of standardized interfaces and

procedures.

3.2.5.3 SSE Interface

An interface is needed for the transfer of customer developed (at the SSE)

software to the SC. Both the SS_ and the SC functions may be distributed to a

number of interfaces may be needed. Functionally, a part of the SC may be

within the SSC, i.e., the individual payload models developed by the

customer. Each individual link is presumably a minor system design constraint

since only utility or user software needs to be transferred between the two.

The performance requirements of each link are small compared to the rest of

the SSDS. The logical connectivity is impacted by the extent of function

distribution.

3.2.5.4 Onboard Training

The extent of onboard training supported by the SSDS versus customer-provided

is another option. Onboard training will normally be more expensive than

ground--based simulation; sometimes, however, the SC development and execution

costs may exceed the onboard performance testing costs. Another important

cost factor in onboard training is the loss of usage of the Space Station

resources and crew during the training period.

Live video onboard training support represents a desirable option from a

user-fri.endliness standpoint, but expensive and resource intensive with

respect to communications uplink and downlink.

3.2.5.5 Service Restoration versus Service Repair

An important distinction is between the operat:ion of the data system and the

customers perception of the data system. One can restore service before one

repairs the failure.

For examp].e, the customer may have very high reliab:ility requirements,

resulting in a very short time allowed to repair failures. What the custorner

is interested in, however, is that service be restored within a short period

....... and not necessarily that a particular component be replaced. Thus, in the

event of a failure, an a].ternative to findi.ng and repairing the specific

fai].ed component, is to locate the problem down to a subsystem, port, or

equipment chain, and repla('e or switch in a whole new subsystem or equipment

chain. Service is thus restored quickly. The actual locating and repair of

the failed component or subsystem may not occur for some time afterwards. The

system's service availability appears uninterrupted to the customer. A high

degree of redundancy may be required to achieve th:is, however.

96
In summary, system management is a critical function in order that the SSDS

provide adequate services and meet customer needs. Many of the subsequent

tradeoff decisions will depend on specific subsystem design opti.ons and NASA

programmatic and policy decisions.

97
3.3 DELETED
3.4 DELETED

101
3.5 SYSTEM DEVELOPMENT

103
3.5. 1 Har(:lware Pr'ocuremer_t

Hardware Procurement is that activ:i. Ly associated with the selectJ.orl of,

hardware products to meet program r'ecluirements and the selection of ,supplJ.t_r's

for those products. Procurement involves not only the selection and

associated strategies but also the definition and administration of those

tasks required to insure product suitability, i.e. acceptance and

qualification testing.

Discus,sion of significant procurement issues from the SSP perspecti.ve are

provided :in the following.

Hardware commonality refers to utilization of specific configuration (or

configuration family) hardware in differing applications. The advantages of

commonality include operational gains of reduced spares and support

requirements, narrower expertise requirements, and perhaps reduced procurement

costs. The disadvantages include the inevitable compromises required in

providing blanket solutions for variant requirements and the enhanced program

risk that reliabilities of the selected configuration(s) may be less than

projected and may impact system availability.

This subject is explored at length in the Standardization/Commonality Options

White Paper, Item 4.3.1, and will not be further discussed here.

3._5.1:..2__£)ualification Levels

fhe Space Station represents a departure from prior space projects since the

primary elements will be assembled/activated on-orbit, thus the operational

environment of the DMS hardware will be relatively benign, particularly that

hardware in the Station modules. All of the SSPE space hardware, however,

will be subjected to thermal, mechanical and pressure dynamics during the NSTS

boost to orbit and during subsequent assembly/activation operations. In

addition, the near earth radiation environment and its effects must be

addressed. Actual operating environments will differ significantly based on

hardware application (Space Station, COP, POP) plus their resultant orbital

parameters (altitude, inclination, sun angle, etc.). A rigorous

acceptance/qualification program must therefore be performed on all flight

hardware to insure its mission suitability.

105
',3ysL;ems li-ncjLneerLncj wi. L1 analyze pol:enL_i,_l _(:lUi. l:)m_nt _i_n_/_ronmenL_l expc,_u_':,s

durin£3 launch, deployment, and oper_tiona] life to estab].ish appr'opr'i:_Le

acceptance/qualification test ].evels. Operational Failure illOdeS _nust _Iso t)e

considered in this analysis to define potential worst case envir'onments.

The environments to be considered, as :i.ndicaLed in the reference (I) _IASA

lechnica]. Memorandum, are thermal, pressure, shock/vibration, radiation, and

EMZ.

Fhe Space Station and COP will be boosted into a nominal 500Kin, 28.5 °

incl:i.nation orbit; the POP orbit will utilize a polar (98.25 °) orbit with an

nominal altitude of 705Km. The natural environments for the assembly and

operational phases of these three elements are provi(led in Table 3.5.1 -- i;

note that the POP will be assembled and activated at the Space Station then

transferred to its operational orbit.

ORIGINAL PAGE _

OF POOR QUALITY

106
I,_b].e 13.5.1 .- 1.

Space Station, COP and POP Natural Eir_virorlmerlts

Station & COP POP

As sembl__ O_pe r_a_t_o..n., fls sembly_ _O]__erat i o n

Thermal Source:

Sink:

40OBTU/ft2-hr ...........................................................I

O°K ..........................................................................................................................................I

Pressure

-9 -i0

I0 torr .............................................................................................. I 0 torr

Vibration (Boost to orbit environment- see note 2)

Rad iat ion ,63rad(Si)/day .................................................................. I 5-70rad (Si)/day

Note I. Atm pressure will be dynamic depending on solar activity

Note 2. NSTS boost to orbit vib'n environment estimated to be I0 -12g rms,

IO - 2OOOHz.

Note 3. Daily radiation based on estimates of solar min. and solar max.

dose for nominally shielded equipment.

]here is an inherent dilemma for the procurement process in that the SSDS

hardware definition will specify state of the art designs and technologies

which are not generally available today in space/flight qualified (or

qualifiable) configurations. Procurement options for this case are to I)

rework/redesign hardware to meet projected environments, or 2) drive the SSPE

designs/operational planning to accommodate less rugged/less radiation tolerant

hardware. The rework activity of option 1) could be significant since it will

include comprehensive review and appropriate corrective rework of:

a) vendor processes and materials for acceptibility

b) thermal management techniques and materials

c) component/circuit card natural frequencies and deflections

d) passivation techniques, including zero-g effects

e) enclosure applicability

107
ORIGINAL PP,_.E !3

OF POOR QUALITY

Ihi. s I"___wol"k _:q:)pr'o<ach I111,JSlS _,)e cc_i"(][u]._y _v_.,l].t,h_[;_]d wJ.t,h L.l']e _,_L,Ij:>l:)J.y J.tt, ] \;¢_q,cic_r" !_

assure that the net gains can be achievecJ.

rhis section briefly discusses each enviror_ment and the significant

procurement considerations, then proposes options addressing those procur'emerlt

issues.

3.5.1.2,1 1hermal Environment

lhe space environment provides a near earth solar radiation source of

approximately 440 BTU/ft2-hr and a space sink of approximately O°R. Thus

extreme case temperature variations can be achieved by unprotected equipment

depending on orbit beta angle, equipment orientation and power dissipation.

Mature thermal management techniques utilizing wrapping materials, heaters,

active cold plates are available, however, to maintain equipment case

temperatures within acceptable bands during stable operation. Also, although

station and platform build-up scenarios can include transient conditions such

that non-operating equipment may be subjected to significantly wider

temperature ranges, experience indicates that special handlingequipment and

techniques can be employed to accommodate less thermally rugged units.

This thermal manageability provides a wide lattitude of hardward options with

corresponding potentials For cost savings even if special cannisters must be

provided. In summary, thermal constraints are not considered to be a

significant driver for the DMS hardware therefore no distinct procurement

options are identified.

3.5.1.2.2 Pressure Environment

3.5.1.2.2.1 Description

Rt 4OOKm, the atmospheric pressure is in the range of IO-9 tort, which is a

virtual vacuum for the SSDS equipment. This environment represents a

potential design/procurement problem for platform and truss hardware since

most off-the-shelf equipment is operated with a nominal internal (air)

pressure of 15 psia although actual internal pressure requirements may be much

I08
less for ,_(']equ,_t;e convective cooling, lh_u,-e al:)pe,_r- Lo I:)e I_lnu,t_e C:_l:)ti_._r_s f',Jr"

consideration to overcome this problem: l) prov:i.de equipnlent w:[th

sealed/pressurized enclosures, 2) provide a pressurized envirorlmer_t for I:he

equipment and 3) redesign the equipment to operate with unpre.ssurized.

A qualitative assessment of these options to generic criteria is provided in

]able 3,5,1 - 2.

]'able 3.5.1 - 2

PRESSURE ENVIRONMENT

Option Impacts on Evaluation Parameters

o...p...I[!oN__#1- OPTION #2 .O_PlIlIION #3

RISK PARAMETERS PROVIDE PRESS'D PROVIDE PRESS'D REDESIGN FOR

ENCLOSURES ENVIRONMENT VACUUM

COST MODERA'I'E LOW MODERATE-HIGH

SCHED Ul..E MODER AIE LOW MODER A lE

PERFORMANCE LOW LOW MODERATE

REI_IABILITY LOW LOW MODERA IE

MAINTAINABILITY LOW LOW LOW

S AF E FY LOW LOW LOW

N._O_]"E__':Costs of Qual, program not considered in evaluation.

3.5.1,2.2,2 Options Characterization

a. Seal/Pressurize Enclosures

lhis option reworks/replaces the equipment enclosure to provide a pressure

seal. The internal pressure should be some fraction of 15 psi in order to

limit the strength required by the enclosure, while retaining adequate

convective cooling. Displays/controls mounts must also be sealed.

Qualification testing will demonstrate the suitability of the final

configuration. The advantage of this approach is that it provides a potential

"quick ?ix" with minimal disturbance of existing design/performance; the

disadvantage is the inevitable leakage of seals, relief valves, etc., that

must be resolved by constant purging, or periodic re-pressurization.

I0@
Oper'al;:iorla].].y pres,sur'e sensitive equipment ut.i.].J.zed on the Station str'ucture

or on the COP or POP could be enclosed in a pressurized shr'oud [:o eliminate

the problem of application in compat:i.b:i, lity. 'lhe advantage of this option

would be the reduced impact on the individual hardware; the disadvantage would

be the potential finite leak rate that must be addressed as in the previous

option.

lhis approach appears to be fairly straight forward and could provide a common

solution for spatially local hardware sets. Thermal management of the

enclosed equipment would not present any significant problems; however, a

shroud with sufficient strength to contain a few psid must be designed to

prevent weight concerns.

c..B_!._n_.._.g i_p__._._

This option fully redesigns the selected equipment to operate in a vacuum,

utilizing conduction paths to its enclosure/cold-plate for thermal

management. The advantage of this approach would be the cleaner solution of

providing an environment tolerant design. The disadvantage would be the

significant cost of redesign, and the potential impacts on unit performance.

3.5.1.2.3 Mechanical Environment

3.5.1.2.3.1 Description

The mechanical environments for the SSPE equipment consist of the vibration,

shock and acoustic environments of NSTS launch and staging, handling

operations during acquisition and maintenance, and potentially, the dynamic

affects of Orbiter docking/berthing. It is anticipated that the orbital boost

operation will provide the most severe environment. NSTS lift-off vibration

and acoustic levels are well defined and are provided in Tables 3.5.1 - 3 and

3.5.1 - 4 attached. Typically, the dominant low frequency vibration

environment is mechanically transmitted to the equipment through the orbiter

longerons while the high frequency vibration environment is acoustically

induced. The vibration response is a function of the equipment configuration

and method of mounting. The response of the SSDS equipment to package inputs

From all sources will be derived from tests and/or analysis by Systems

110
I:ih'lgineer:i.r_( _, 1:3as_)d _:_n MI]A(] 1\1',;I'.3 experi._)nc.e wit.h t.he PAM i:)l"_:_£'jr',:lm, [_._

compos:i. Le fl:ight; leve].s are rlo[; expected to exceed 10.-..12 clrms across a derJ. r_ed

10 .- 2000 Hz profile For [;runnion mounL:ed packages. Fhese ].evels are exl:)ecL_d

to enve].ope all vibration, shock and acoust:i.c exposures and are not; considered

t:o be severe for "ruggedized" hardware.

As indicated earlier, the equipment must also undergo some level of

qualification however, the ].evels and durations will be reduced from criter'ia

defined in the standards (i.e., DOD-E-B9B3E) in order to accommodate

protoflighting.

Again, the probability of qualifying available commerical or GF:E hardware may

be low; the available the options are:

I) rework existing equipment to beef up enclosures and component mounting

while providing appropriate isolators at launch package mounts.

2) completely redesign equipment to meet projected profiles.

Table 3.5.1 - 5 provides a qualitative assessment of these options.

ORIGINAL PAGE IS

OF POOR QUALITY

111
l,_ble 3.5.1 - 5

MECHAI_IIC.AL. EIWI RONMEI_T

Opt:ion Impacts On L.;wilu,_tion Par',_meters

OPTION # i .OI_.].-.I:ON_#.2"

REWORK OTS REDESIGN OTS

R_I_s K LP. AR_AM_!I_R.S _9_U_!P__M_E_Z _gUIPMENT

COS r MODERATE IMOI]ERATE - HI(;H

SCI--IEI]UI_E tMODERA]E MODERATE - HTGH

PERI:ORIMANCE LOW I_OW- IMOI_)ERAIE

RELIABILI1Y LOW .- MO[)ERATE LOW

MAIN IAI[NABII...I[IY LOW - MODERATE I..OW

SAFE]Y LOW LOW

NOTE : Costs of Qualification Program not considered in evaluation.

3.5.1.2.3.2 Options Characterization

a. Rework Off-The-Shelf Equipment

]his option addresses the rework of existing equipment that has all the

required attributes (configuration, performance, etc.) except it is not

sufficiently rugged to survive the launch and deployment environment, lhe

concept is to ruggedize enclosures and internal components. This effort

includes:

a) analysis of circuit card natural frequencies providing stiffening as

required

b) analyzing component mounts and adding additional strength (staking) and

conformal coating as required

c) strengthening the enclosure with increased wall thicknesses and

gusseting as required.

112
ORIGINAL PAGE IS

OF POOR OUALrrY

SLnce t:h:Ls i.s a c,.)mpr',::,,ni.,_e ,_l:)l:)r{:,,-_(:h, vi. bt.'at;i.on/shock i.t_,:)Iat,:,rs _n,._V,_1.,_,) b,,-_,

requir'ecJ at the equ:i.pment mount within its launch package. lhe advant,,_!]e of

the approach is the potent:i.ally low (,oat of Lhe rework; the d:i.sadvantage i.s

the resulting risks in qualifying the r'esult:i.ng conf'iguration and the

potential impacts on performance and reliability.

b. _.__d_e._.!9.r_...._o_.£f..:-..t._b.e_.-:..s.'..be t_f_Equ._i_p,_,_.nt..

T'his option comprehensively redesigns the equipment to MIL-Spec criteria such

that qualif'ication testing to uncompromised levels can be confidently

performed, the advantage of this approach is the achievement of a cohesive,

well engineered product; the disadvantage is the high cost of the

redesign/redevelopment.

3.5.1.2.4 Radiation

3.5.1.2.4.1 Description

High energy charged particles that proliferate the terrestrial space region

with their effects on semiconductor technologies, present perhaps the most

severe environment in terms of long term equipment compatibility. These

particle fluences include high energy protons and heavy nucleii From galactic

cosmic rays, protons, electrons and alpha particles produced by solar flare

activities, and trapped protons and electrons of the Van Allen radiation belts.

Ihe galactic particles have the highest energy distributions, up to 1010 eV,

however all three sources have sufficient energy distributions such that their

particles can penetraDe through normal spacecraft skin and hardware

enclosures to deposit energy within the semiconductor material. The

resulting effects on electronics are:

1) the 'single event upset' (SEU) phenomenon where-in a logic state

(single bit) change occurs in a logic latching device, or semiconductor

memory, caused by a high energy particle hit at a critical circuit point.

and, 2) a gradual degradation of device characteristics proportional to the

total dose energy (radiation) accumulated,

113
lhe pr'edomLn_nt c_use ol_ .s:i.n_l].e event upshot; i.s I'_.t<_vy nuc]._i.L ,:_,'_d h.hjh en_',.jy

protons that deposit their" ener-.cly in the form of J.aniz_t;ion in the 1C

material. If the ionization occurs near a depletion region then the ho].es ,_l'_(']

electrons may be collected to produce a charge increase of suffici.ent

magnitude to cause the circuit to change state. In most cases the phenomenon

is transient and the circuit will operate normally thereafter, however, in

some cases, parasitic 4...-layer paths can be stimulated to 'latch-up' resulting

in TC burnout. Tn most cases the fault tolerance design features, i.e. error"

correction codes, parity checks, voting mechanisms, and redundancies will

maintain SSPE operation, but hardware is becoming more sensitive to the

problem as LST densities increase and feature size decreases. The SEU

pl'lenomenon must be comprehensively addressed in hardware and software designs

to minimize potential burdens on fault tolerance mechanisms and on--orbit

servicing.

Electron and proton fluences constitute the primary total dose radiation

problem For spacecraft. The accumulation of this radiation is proportional to

the particle fluxes encountered and is somewhat statistical, based on orbital

parameters and solar flare activity. Its unit of measure is the 'rad',

defined as lO0 ergs/g and it would not be unusual for the total dose of a

polar orbiting spacecraft with minimal natural and intentional shielding to

reach 25K--50K rads(Si) during a solar maximum year. This dose would

significantly degrade transistor gains, increase junction leakages and shift

thresh-hold voltages in MOS transistors of typical hardware. The over-all

result would be a general decrease in performance on digital circuits and a

decrease in accuracy of analog circuits such that mission requirements could

not be achieved.

Optical fibers are also degraded by radiation to varying degrees, The affects

can be a drastic increase in attenuation (dB/km) depending on the fiber type.

114
I.li.gh n(_ul::i-'(._n fl.uenc_s ,:_rx:t (:lose r'al:es ,-lssoc:i.(._l:ect w:i.l:h nucl_._r (:tet:on(_t:i_,n ,,_re

not considered as part of the miss:ion environment _nd are not addre,ssed.

Fhe availability of semiconductor _,echnologies _ith a radiation tolerance of

].K rads(Si) and above is extremely limited as shown in the F:[gure 3.5.1 -1

test data. Fortunately For the Space Station and Co-orbiting platform, Lhe

natural magnetic field of the earth provides an effective shield for the

galactic and solar Flare particles in the lower inclination orbits up to

approximaLely 40 ° , and altitudes below 500Km, such that with normal

enclosure material, negligible radiation will be accumulated From these

sources. These orbits can still provide measurable radiation, however, from

passes through the 'South Atlantic Anomaly', a region centered at 35 ° south

latitude and 35 ° west longitude where the protons and electrons from the Van

Allen belt are in closer proximity to the earth due to the main magnetic Field

dipole offset. Since this region is localized, the dosage will remain fairly

small. The reference [2] study has shown, for example, that with a shielding

thickness of 4mm A1, the daily radiation for the nominal Station and COP

28.5 ° orbit is .628 rad(Si)/day or approximately 230 rads(Si)/yr. This

environment can be tolerated by a wide selection of components and will not be

a procurement issue.

At higher orbital inclinations, shielding from the magnetic Field is reduced

as the orbit approaches the magnetic poles such that a polar orbit intercepts

the Free--space Solar Cosmic Ray (SCR) particle fluence over approximately of

its orbit. POP Hardware with 3mm AI shielding, for example, would accumulate

approximately 2K rads(Si) per year under solar minimum conditions and

approximately 25K rads(Si) per year during solar maximum conditions yielding

an estimated total lO year dose of lOOK rads(Si). This environment represents

a severe design/procurement hardship.

115
Full sh:iel.di.ncj Ls not a v:i.abl.e sol.uLion because uf wei.cjht _,'_d volt._,n_

penalties. Figure 3.5.1 .-- 2 prov:Ldes data on the ef:fectiveness of sl'_i.e].d:in(]

and indicates, for example, that the reduct:lon of: the lOOK rads(Si) r'ef:er'enc_d

above to a more tolerable 1K rad(Si) dose wou].d require shielding thickness of:

approximat;ely 4.5 ins A1. _luminum is typically the shield material for these

studies however, other more efficient materials may be deve].oped. The problem

is complex in that secondary effects must also be considered :in the low Z/high

Z shieldi.ng equation.

The options therefore available are: (1) select hardware (components and

circuit designs) to exceed the specified requirements, (2) provide selective

shielding, or (3) perform periodic hardware replacement. Table 3.5.1 -6

provides a qualitative assessment of these options.

lable 3,5,1 - 6

RADIATION ENVIRONMENT (TOTAL DOSE)

OPTION #I OPTION #2 OPTION #3

SELECT TO SELECTIVE PERIODIC

RISK PARAMETERS MEET REQ'TS SHIELDING REPLACEMENT

COST HIGH (3) LOW HIGH (1)

SCHEDULE HIGH (3) LOW LOW

PERFORMANCE HIGH (3) HIGH (2) LOW

RELIABILITY LOW LOW LOW

MAINTAINABILIFY LOW LOW HIGH (1)

SAFETY LOW LOW LOW

I) Due to repetitive (replacement) effort and costs

2) Feasibility risk

3) High development risks

116
3. ,5. L. 2.. 4.2_ <)p.L_..J:.On.S........C!_¢_>_c.t._._..!,z,_.iL.z..i...!_r !

a. S_.eL.e.c___..H.._a_.r d__..a_r e _o _..ee__.t.__%e__ctuk_:.e_mt.n t_S_

Fhis option addresses the task of prov:lding components and hardware with a

tolerance to the projected total dose requirements and that exhibit an

aw)idance of latch-up when exposed to the radiation environment.

Unfortunately, as the component industry moves toward increasing densities to

satifisFy the industry needs For Faster, more integrated parts, the resulting

susceptibilities to radiation, particularly the single event upset, increases.

[here is a concern For the developing VHSIC technologies for example, in that

the reduces Feature sizes will provide a susceptibility that is orders of

magnitude higher than that of previous parts.

The validation of radiation tolerant parts requires a comprehensive test and

analysis program on samples of the target lots. This effort will be required

on components no matter what level of tolerance must be guaranteed, however,

there appears to be a considerably lower probability of success in meeting the

higher levels. This effort will clearly be one of the key development issues

For the SSPE's and in particular the polar platform.

b. Selective Shieldin9

rotal shielding, as discussed in the description section, is not viable,

however, it may be Feasible on a very limited basis on the polar platform to

provide shielding on selective components that cannot meet the required

radiation tolerance. The advantages of this approach is that it can salvage

an otherwise unacceptable design. The disadvantage is the additional design

effort, weight and volume penalties of the shielding.

1,17
c. !!'.._,_:._Lod. ! 5.....R!_._.lac.e.!_.e.n

Ibis opt:ion addresses replacemerll:/refl_rb[shrnent of Sl_scept:i.b].e hardware on a

periodic basis to preclude system failures. This approach would be compatible

with the servicing programs established for platform hardware. In addition,

technology insertion programs may also take advantage of improvements in

radiation susceptibility. The net effect is that hardware may not. in

reality, be required to demonstrate a I0 year total dose tolerance.

3.5.1.2.5 Spacecraft CharcLin9

Space craft in orbit can build up electric potentials to thousands of volts

with reference to ambient plasma, such that large differential voltages can

appear between packages/circuits and structure. Electrical arcing can result

to permanently damage the associated electronics. The required conditions for

this phenomenon are a complex combination of high altitude (geo-synchronous).

sun.-angles, particle flux densities and magnetic storm activity. At the lower

altitudes of the SSPE's. this phenomenon is not as applicable such that use of

appropriate conductive materials and effective grounding practices will

eliminate the potential problem. No particular procurement issues have been

identified for this subject.

3.5.1.2.6 Electro-Maqnetic Interference

This subject addresses the emission of noise levels either radiated or

conducted on signal or power busses that may interfere with other equipment

and the susceptibility of equipment to radiated and conducted noise. There

are spectral bands in. the solar spectrum that must be reviewed in the

design/qualification tasks, however, the primary RF spectral regions are the

man-made earth based and on-board sources. No particular issues have been

identified. Sound engineering practices will be employed, coupled with

adequate EMI controls such that there will be no significant risk to SSPE

operational performance.

118
From the vieuJpoint o IF procurement activ:iIties, the test beds may serve a

Function during the selection process of insuring compatibility and

performance of candidate hardware/software products. The only identifiable

issue is that of the availability of test-beds and their utilization within

the program controls requirements, i.e. quality control, configuration

management, etc.

3.5,1.4 [).roc_ur.e.me_ n_t S._trat.ei_

lhere are four basic procurement strategies in hardware/software procurement

I) commercially available (off-the-shelf) products, 2) contractor/vendor

provided hardware, 3) Government Furnished Equipment, and 4) se('ond sourcing

Table 3.5.1 - 7 provides a qualitative assessment of these options; the merits

and applicability of each is discussed below.

RISK PARAMETERS

TABLE 3,5,1 - 7

PROCUREMENT STRATEGY OPTIONS

OPTION #I OPTIONS #2 OPTION # OPRION #4

OTS PRODUCTS C_ONTR/VENDOR GFE 2ND SOURCE

PROVIDED

COST LOW MOO - HIGH LOW MOD - HIGH

SCHEDULE LOW MODERA['E L.OW MODERATE

PERFORMANCE MODERATE LOW MODERATE LOW

RELIABILITY MODERAFE LOW MODERATE LOW

MAINTAINABILITY MODERATE LOW MODERATE LOW

SAFETY MODERATE MODERATE LOW LOW

NOTE. Qualification costs not considered in evaluation

3.5,1.4.1 Off-The-Shelf Products

This option addresses utilization of commercially available products that

match Space Station requirements to a reasonable degree. The major

difficulty, as discussed earlier, is the suitability of such hardware to the

potential space environments. Special installations and/or handling equipment

will in general be required to utilize such hardware; however, the additional

effort may be a relatively small cost, thus rendering a clear advantage to

this approach.

119
This opt:i.orl is typical of special project hardware where., in the products are

uniquely specified and competed between several contractors, The effort

generally requires concept definition, documentation and progress review plus

some level of effort management overview, the costs are significantly higher,

particularly for low production run efforts, however, the resulting products

have the unique configurations/capabilities/suitabilities required by the

program.

3.5.1.4.3 Government Furnished E_uipment

This option addresses hardware that is provided by the government with no

development/procurement activity by the integrating agency. Equipment in this

category may be immediately available 'off-the-government-shelf' or may

require additional production runs by associated contractors/vendors. In

either case, the design/development effort is complete, therefore acquisition

of such hardware can represent a significant cost savings to the program

provided the appropriate qualification can be successfully completed.

Additional potential advantages are that the government procurred equipment

will generally be ruggedized and may also adhere to SSP applicable standards.

Another potential scenario is that the hardware may be procured by NASA and

imposed on the Space Station program to enforce particular programmatic

issues, i.e. commonality, standardization, etc.

3.5.1.4.4 S_gDd._Sg.grciE8

This strategy is regularly employed by both industry and government in cases

where a product produceability risk is projected or has been demonstrated to

be moderate to high. Production problems may be due to materials, state of

the art processes, or even limited vendor/contractor resources, that are not

applicable to the second supplier.

The disadvantages of this approach are the start-up costs for the second

source, the additional resources required to oversee two suppliers, and the

arbitration of configuration/performance change requests.

120
]Ihe above desi(,]i'i/procurenlent J.ssues w_.11 all be reso].ued wJ. Ch nor'n}(_] (÷,_s

required) trade--offs in progr<_m costs, performance and operational

requirements, plus execution of appropriate options.

l-he issues of commonality and the goal of replicating subsystems with the

SSPE's may be in jeopardy however, particulary when addressing the radiation

envir'onments.

3.5. I. 6 References

[I] W. W. Vaughan "Nat:Eonal Environment Des:[.c]n Criteria For the Space Station

Definition And Preliminary Design (First Edition)", IM.--86460, NASA,

Marshall Space Flight Center, Alabama, September 1984.

[2] K. A, Pfitzer, W. R. Yucker "Extravehicular Crewman Work System Study -

Final Draft", MDC-.H1660, MDAC, Huntington Beach, CA, Dec 1978.

[3] R. E. Smith, G. S. West, "Space and Planetary Environment Criteria

Guidelines For Use In Space Vehicle Development", 1982 Revision (Volume

I), NASA, Marshall Space Flight Center, Alabama, 1983.

121
OF POOR QUALfrf

Table 3.5.l-3 a) ,

Orbiter Cargo Bly-l_ndol Vibration

Trunnion Supported Payloads - On P/L Keel rln

Payload _el_ht _Les$ Than 10,000 Lbs.

o All Axes 20 to 60 HZ

60 to 100 HZ

100 co 300 HZ

300 to 2000 HZ

ovz_.L - I. 9"c_s

.0023 Ga/HZ

+9 dS/OCT

0.01G_/HZ

-9 dBIOCT

Payload Ve/$ht *Greater Than I0,000 Lb=.

o All Axes 20 to _80 EZ

480 co 2000 BZ

OVEEALL - 1.2 GRP_

.0023 G2/HZ

-9 dB/OCT

The assoctmted =Ime duration is 20 seconds per fltghc chlch includes a fatigue

scarcer factor of A.

*Total payload _dght is irresFec=Ive of the number of =ountlng _Incs.

122
:.:_. :,_ _. _. :- : _.i' OF POOR QUALfry

Orbiter Cdr&o Bay P_tndom VJbratlon

Longeron/AdJpter Supported Payloads - At Orbiter Interface

o X ._ls 20 to 100 RZ 46 dB/OCT

I00 to 500 HZ .03 GzlEZ

500 to 2000 HZ --4 dBIOCT

e

OVERALL- 5.4 C_IS

o Y Axis

(Fwd of Sta. Xo - 919)

o

20 co 40 EZ

40 to 100 HZ

100 to 170 H/

170 to 600 HZ

600 to 2000 HZ

OVERALL- 4.5 G_S

+12 dB/OCT

.06 GZlHZ

-6 dB/OC"T

.02 Ga/EZ

-9 dBIOCT

Y Axls 20 to 40 HZ ' " -12 riB/OCT

(A_t of STA. Xo - 919) 40 to 500 EZ .06 G=IEZ

500 to 2000 HI -_ dS/OCT

0TE.KAiL - 7.8 GF_;S

o Z Axis 20 to lOO HZ +6 dB/OCY

I00 to 20C0 HZ .03 G2/EZ

0VEKALL - 7 . 6 GP¢IS

The a_seclaced :t=e duration Is 20 se:onds per axis per flight _hlch Incl_des a

scatter factor of 4.
¢;_#_i_ i:_:_:4._  ̧ _

".:_}e 3.g.i. __ .:; OF _ ,:f,..,. •

Orbiter Cir£o Bay Rlndo_ VibrJ_ion

Trunnion Supported Paylold= - on P/L Trunnion

P.ylo.d _elsht ILess Than I0,000 Lbs.

o X Axis 20 to 50 HZ

50 to 125 HZ

125 to 300 HI

300 to 2000 HZ

OVERALL - 3.0 GF_

.0015 G_/IIZ

+9 dB/OCT

.025 G2/HZ

-9 dB/OCT

0

0

And

O

T Axis

(Fvd of Sti. Xo - 919)

T Axis

(Aft of St•. Xo 1 919)

Z Axis

20 to 68 BZ

68 to I00 HZ

100 to 380 RZ

380 co 2000 EZ

OVERALL - 2.5 GR.v-_

20 to 68 HZ

68 to 125 HZ

125 to 300 HZ

300 to 2000 EZ

OVEFd_LL - 3.0 GK."-S

.004 Gz/HZ

+9 dB/OCT

.013 GZ/HZ

-9 dB/OCT

.004 G2/HZ

+9 dE/OCT

.025 G=/I!Z

-9 db/OCT

Payload _ci_ht *Creater Thzn I0,000 Lbs.

o X Axis 20 to 50 RZ

50 to 80 E2

80 to _80 HZ

480 to 2000 HZ

OVERALL - 2.0 GKY_

.0015 G2/RZ

_9 dBIOCT

.0063 C21RZ

-9 dB/OCT

o Y and Z Axes 20 co 68 BZ

68 to 80 I_Z

80 to 430 RZ

480 to 2000BZ

OVERALL - 2.6 GK_LS

.004 G=/EZ

*9 dB/OCT

.0063 G=/HZ

-9 dB/OCT

The'associated time duration Is 20 seconds per axis per flight vhlch tncludep •

fatigue scatter factor of &.

*To_ll payload weight is irrespective of the number of mounting points.

124
Tab]e 3.5.1-4 OILBITgR C_CO BAT IN'I'ERJ%kLACOUSTIC E'brVIRO,h_

1/3 OCTAVE

BJnd Center

Frequency

(Hz)

31.5

40.0

50.0

63.0

80.0

100.0

125.0

160.0

200.0

250.0

315.0

400.0

500.0

630.0

.800_0

1,000.0

1250.0

1600.0

2000.0

2500.0

Overall

Sound Pressure Level (dB) ref. ZXlO -5 N/m 2

Lift-off Aeronolse

5 Seconds/Flight* i0 Seconds/Fli_ht*

122.0

124.0

125.5

127.0

128.0

128.5

129.0

129.0

128.5

127.0

126.0

125.0

123.0

121.5

120.0

117.5

116.0

114.0

112.0

110.0

138.0

112.0

114.0

116.0

I18.0

120.0

121.0

122.5

123.5

124.5

125.0 **

125.0 **.

124.0 **

121.5

119.5

117.5

116.O

114.0

112.5

110.5

108.5

133.5

_Time per flight does not include a scatter factor.

**NOTE: Narrow band dlscrece noise is radiated from =he cargo bay

vent doors during =ransonic/iov supersonic flight. The

noise radiated from any one vent is described belou:

This enviro_men= is no= intended for full payload exposure

bus only Co =hose areas of =he payload adjacent to a

cargo bay ve=c opening.

One-=bird Octave Band

Center Frequencies, IL:

I

250

315

4OO

dB re _tts

8 Seconds/Fllght

12a

236

Z30

125
ORIGINAL PAGE IS

OF.POORQUALIFY

Figure l

TOTAL DOSE HARDNESS

126
e_

v

l.l'l

o

c

o

/.)

•/o

/

t i : i

ORIGIN;d. P_G= IS

OF POOR QUALITY

-.-_,-_.._ +×re -- . .

o

Fluence : I0 I0 p/cm 2

Spectrum = I00 MV

E > HeV

I

=-P--i:-+..+i!..-!:----,=-:I=_+m,-+ --_W:+_-J u:..

-i=:I::--1--i£q == I:-u.-_--i--'i:=P: _ --_'L:E-_-= _"

o

Figure 2,. Solar Cosmic Ray Proton Dose in Free Space

|.'_I_-_T:. I.I---_4--c-I -J l--l-I ,,I----L " I

--- ". ........ l I--_ 4 "+ * ---L'--+" -:':'-: :t"-"- '--'-"::+-" '='.' .... .--t:-----= . .: +-, ".'-t.

Shie!_T_ickness (e/cm 2 AI) I_o =P 4.+"

127

"7

b_

v

m
3.5.2 Software Development Options Paper" (lask 2)

rhe Phase B RFP for the Space Station states Lhat "for software, commona].ity

of prograrnming languages, support software, oper'ating systems, and user"

interface languages are major goals. ]he SSE (Software Support)

Environment) is defined as the common software required for the development of

appli('ations software for Space Station flight and ground systems."

lhe goal of this paper is to identify those tools currently used by the

software population which have demonstrated a significant productivity

increase. In addition, where possible, specific aspects of the software

development tools which show promise for Future productivity gains will be

stressed. Also, a certain amount of 'blue-sky--dreaming' will be incorporated,

tempered with real-world activities, to project where software development

will be in the near future.

Since the users of the SSE will be a large population of analyst, designer,

programmer, tester, and tracker experts it must be emphasized, that these

tools and controls should be integrated to provide an environment which

facilitates their use.

Many tools examined here have evolved over the last decade to aid the software

development process and many more integrated tool sets are on the horizon.

Along with the tools, management and acquisition strategies options are

characterized. The characterization of (I) tools, management and acquisition

strategy options, (2) options for facilities to host the SSE, and (3)

ergonomic issues are included.

3.5.2.1 Software Engineering

Software engineering is the disciplined application of methods, principles,

procedures, and tools to ensure the development of reliable, understandable,

modifiable and efficient software. This process as depicted in figure l, is

an iterative process of requirements definition, design, code, test and

release. Because of the rising cost of software development, initiatives
within NASA and OoD comb:i.ned with indust;r'y and academJ.c efif'or'L,,_ have provided

much study of the software engineer.[ng phases. fhese erFor'ts have provided

insights into the phases of the development effort, the life cycle costs of

those processes, and ways to automate and integraLe the funcLions. The Ada_

language and environment, the SIARS initiative (Software Technology for

adaptable and Reliable Systems) and the DoD-STD-SDS (Joint Logistics

Commanders, Joint Policy Coordinating Group on Computer Resource Management)

are three examples of DoD initiatives which wilt have large impacts on

software engineering.

*Ada is a registered trademark of the Ada Joint Program Office

130
Software Plans and_

Req_ati°n

Preliminary Design

Verification

Detailed DesiGn

fication

Code

Unit Test

Integration and

Test

ro,_uzZ

rifica_i_n

Acceptance Testing

System Test

Operations and

Maintenance

validation

Figure I - The Software Life Cycle

131
ADA

There are approximately 38 Ada compi].ers currently in various stages of

development, test, and use today (February 1985). I'n 1984, 14 compilers

passed the DoD certification tests. Two significant 0o0 contracts for Ada

software development environments are currently being worked. These are the

AIE and the ALS. The ALS compiler has been validated and a preliminary MAPSE

is being installed on VAX systems. Preliminary indications are that an AIE

will soon appear which is designed for the IBM 370/VM architecture. Tools for

the APSEs can be generated independently, and because they are done in Qda,

they can be transported to all APSEs. This wide market feature will greatly

encourage the development of APSE tools and should ensure a rich tool set for

Ada users.

Software Technoloc_ for Adaptable and Reliable S_stems CSTARS__

The STARS program plans to look at all phases of the software life cycle, from

both technical and management viewpoints. Through the STARS program, the DoD

is seeking an integrated and automated software environment which covers the

software life cycle. Technically, the program uses Ada and its environment as

a foundation. Beyond that, it will address management practices, software

acquisition strategies, increased personnel skill levels, increase the use of

tools, and make advances in both software systems methodologies and software

theory.

A product of the STARS program, the Software Engineering Institute (SEI), has

already been formed. It is intended to be a vehicle through which emerging

technologies will be developed, validated,and brought into practice.

DoD-STD-SDS

This is a joint services effort to standardize the way software is developed.

DoD standard 2167 was recently released to address this issue. This standard

will be used to describe how all software will be developed on DoD contracts.

It identifies the produced documents, required methods, and techniques used

when developing DoD software. This standard was initiated to avoid

redundancy, improve productivity and increase management visibility for

software development.

132
IHE II_IEC._RAIHI)PROGRAMMI]\IC_ DEIVEt..OPMEI_I EI_V1.ROI_MENI

Environments to support program development are too].sets which attempt to

address all the functions which must occur in a large software development

project.

No toolsets automate all aspects of software engineering. (See Figure 2.)

Major toolsets like UNIX have taken many years to mature. Many new toolsets

are currently being developed and are attempting to present an integrated

environment to the user. Some examples are: SEF by IBM/FSD, FAGS by Feledyne

Brown, TEAMWORX by Cadre Technologies, FPE by Soflool, USE.I-f by HOS, APCE by

PRC, Structa by Tektronix, and ProMod by GEI.

Current NASA and DoD initiatives are concentrating on the Ada language and

environment. The Ada Programming Support Environment (APSE) is currently

being defined by the DoD. It will eventually address the total software life

cycle model. It will be many years before full APSE's are addressing all

phases of software engineering.

The minimal toolset or MAPSE has been defined and many are in varying stages

of development. According to the DoD's STONEMAN, the MAPSE includes a text

editor, formatted printer, translators, linkers, loaders, set-use static

analyzer, control flow static analyzer, dynamic analysis tool, terminal

interface routines, file administrator, command interpreter, and configuration

manager.

Ada compilers are becoming common place and will be maturing rapidly. It was

originally predicted that this would happen in lg80. Ada MAPSE's are, in the

author's opinion, 3-5 years from mature releases. Other, more mature

development environments such as UNIX and VM/CMS must be considered for the

Space Station's initial SSE. Most software life cycle costs are not code

related (rather specification, test, maintenance, CM) and can be addressed in

these more mature environments. The Ada compilers could be immediately

integrated into one of these environments and MAPSE tools added later as they

mature.

133
ORIGINAL PAGE IS

OF POOR QUALrrY

0_

0

Q.

==

E

E

=E

E

o

C..)

==

o.

E

, c

q3

P

=:_.E

xoql!el_

aJedLuOO a!!:l X X x

Jalu!J_ AllaJ d x X

Jo},!p:l lxa.L X X

JaBeue_ aH:l ase8 elec] x x X

JalladS

saA=_,_ uJ!J d ;xaj.

Ja_uaLun30C] aoej.Ja].u I x

saleldLUa/ uo!leluauJn30(] X

JallasadAJ.

6u!sseooj d pJO M r,..

_oleJaua9 oads/111AI X X

JO_eJaua_ so!4deJ _

Jol!pn V spJRpue_ S X

_JodaH _lne4 X

IOJ_UOO _3a!oJd X

_uew_6eue_ uo!_eJ n_!juo 0 X X X X X

@oueuJJoJJed/(_u!uJ!.L X X

JazkleU_" aJn_onJ1s IleO

Jalq,,,asses!o

aouaJa_a_-ssoJo leqol_) X x

Jo_.eln,,,!S _.ua,,,uo_!^u =j

JolelnuJ!s laAa-I uo!13nJlsul

aolnoax::l O!loq_k S

Jo:l.eaaua_) aseo _.saj.

Lua_s,_s uo!leo!_!JaA IeuJJo_ X

Onqa(] aoJno S X X X

aolelnLu!s aoej.Ja_.Ul X X

_o_!uo_ uo!inoax_ _,uauJele:_S x x x X

Jo_e_aua_) aosseoo._dea d X

aoleJeue_) ]Joda_l X

JazAleu_ ' _o1-1 IoJluoO X

uo!_,el!dwoo IRUO!I!puo0

Japeo-l/_a_u!'l X X

X X

X

X

X X

X X

X X

X

X

X X

X X X

X X X

X X

X X

X X X X X X

X X X X X

X

X X

X X

X

X

X

X X

X

X X

X

X

X

_. X

_" X X

X

X X

X X

X

X

X

X

X

X X

X X X

_. X X X

X

x x

X X X X X X X X X X

X X

X X

X

X

X

JalquJass_/Jal!dUaoo X X X X X X X X X X X X X X X X

1Joddn S uR!sao X X X X X

a_enfiue-t sluatueJ!nba_l X

6u!_eJl sluauJaJ!nba_l X

< o. > -t- -- Q m j=

Oo Oo ,_ z ,_ m Z < _ L9 ,'_ u. _L :D

,m

U.

134
lhe DoD Ada Proc3ranmlinc] Support ErlvJ.ror_ments that are urlder-.-.c3oJ.r_(_ deve].opm_r,t.

include the Ada Integrated Environment (.IBM 370/VM) the Ada I...anguage System

(VAX 11/780/VMS), and the ftda Language System/Navy (VAX/VMS).

Fhe Ada Integrated Environment (AIE)

In April 1982, the Air Force (Rome Air Development Center) contracted

Intermetrics, Inc. to implement a Minimal Ada Programming Support Environlnerlt

(MAPSE) entitled "Ada Integrated Environment" (AIE). The AIE is designed For

use in the development of embedded computer system software and can

accommodate a variety of users, skilled and unski].led, from project managers,

program designers and developers to documentors and clerical personnel. The

AIE contains a virtual operating system called the kernel or KAPSE (Kernel Ada

Programming Support Environment) that isolates tools (both system and user)

from hardware dependencies. The system tools consist of a production quality

Ada Compiler and symbolic debugger; a program integration facility with

program library management and linking/loading tools used to develop Ada

programs; a data base manager with a complete file management system; and a

command language processor which allows user interaction with tools and other

operating system routines. The AIE will be hosted on the IBM 370 architecture

and can co-exist with other operating systems (e.g., OS/VSI, CMS, UTS, etc.).

The Ada Language System (ALS)

In April, IgBO, the Army contracted SofTech, Inc. to develop the Ada Language

System (ALS), an integrated programming environment designed to aid in the

development and maintenance of Ada programs. The ALS is designed to support

large software systems throughout their life cycle. In particular, the AI_S

was designed with the requirements of embedded computer system development in

mind. The three major components include a file structure (called the

environment database), a set of tools, and a mechanism through which the tools

are invoked (i.e., the command language interpreter). The ALS will be hosted

on DEC VAX 11/7B0 architectures.

125
Ada L._ngu_geSystem/Navy(AL.SIN)

lhe Ada Language System/Navy is a minimal Ada programming support environment

designed to provide support For program generation and execution of Ada

application programs targeted for Navy standard embedded computers and

peripherals. Fhe system is composed of extensions to the Army's ALS that are

the minimum required to support projects using the Navy's standard embedded

computers. [5]

3.5.2.1.1 Requirements Analysis Tools

3.5.2.1.i.I Requirements Analysis Description

Traditionally, requirements for software systems have been hard to produce.

Prose specifications are generated by developers and reviewed by customers.

However, written requirements cannot reveal important aspects of the final

system such as performance, function, usability and reliability. Not until

system integration can it be demonstrated that the proposed system meets the

customer's requirements. By then, problems are costly to detect and correct.

Ideally, requirements analysis tools should allow for a precise and verifiable

specification of software requirements and allow an automatic analysis of the

features of the system. This will keep faulty design decisions from being

propagated through the system during implementation. Tools should also allow

For automatic tracking of requirements through system design, implementation

and testing of the final product.

Currently all requirements analysis tools support a methodology for developing

or demonstrating software analysis.

The following options are discussed:

I

m

SA - Structured Analysis

SREM - Software Requirements Engineering Methodology

PSL/PSA - Problem Statement Language/Problem Statement Analysis

Warnier/Orr

Table 1 compares key characteristics of these options.

L_
ORIGi;_AL F:_',Sc" IS

DE. POOR quALrrY

::::::::::::::::::::::::::::::::::::: ...... _=_=-..= .... ===================== ..... == ....... .-.._

Feature I SA I SREH PSL/PSA WARNIER/ORR

I I

HOSt I IBM PC I VAX IBM IBM PC

System I VAX I VAX

I APOLLO I HP

I I UNiX

I I

Maturity I lligh I Hedium Low Low

I 1 (10 years) (6 years) (2 years)

I I

Methodoloqy Loses

data flaw diagrams

Iterative

rer i nemunt

Key

Features

Control flow

methodo fogy

Data base of

processes and

transfer function

Consistency

checks

Simulat ion

SREM users group

Object oriented

methodo Iogy

Maps real world

system into

data base of

entities and

relationships

Provides graphical

depictions

Code generation

may be coming

Formal requi rement

speci fications

Code generation

Data structure

diagrams

Program structure

c_art

User

Experience

Can be used in

con,junctiofl with

PSL/PSA

User's group (SDF)

Many companies

have classes

Easy to modify

Thoroughmethodology

Initial manual

p roce s s

Not easy tO modifyl

Complexity similar

to PSL/PSA

User's grouo is

addressing user

friend I iness

TRW has classes

Time consuming

Large resource

Loser

Lots of options

Expertise requiredl

for effective

and efficient use

New graphic

i nte rface

Formal classes

requ i red

Graphic interface

co st S900- S30,000 $lO_0O01y.r Sb.5,000 S2fJoo

Table I - Requirements Analysis Tools

137
3.5.2.1.1.2 Requirements (_na].ysis Tools Opt:i.ons Char'acter':i.zat;:ion

Structured Analysis - SA is a discipline in('orporating simplified systL, m

modeling and the early use of data oriented techniques. [1][7] lhe

underlying concept is the building of a logical (nonphysical) model of a

system, using graphical techniques that enable users, analysts, and

designers to get a picture of the system and how its parts fit together

to meet the user's needs. This is accomplished with logical data flow

diagrams (DFD) (See Figure 3) that specify precisely "what" the system

has to do, leaving the designer free to specify "how" it can be done.

[he methodology involves building a system model top-_own by successive

refinements, first producing an overall system data flow, then detailed

data flows, and finally defining the data structure and process logic.

The DFDs and related documentation (data dictionaries, data immediate

access diagrams, and process logic) make up a comprehensive account of a

system in terms of a logical, function specification. They also provide

the basis for step-wise refinement of requirements in a structured and

controlled environment. Structured Analysis has become extremely popular

and as such, many tools to support the technique have been developed or

are in development. The following is just a few examples of current

systems.

Com_ Tool Host Cost

Tektronix,"Inc. Structa VAX/VMS/UNIX $14.2K

Cadre, Inc. Analyst Workbench Apollo $24K

StructSoft, Inc. PCSA IBM/PC $g00

McDonnell Douglas DFD Draw IBM/PC $500

Yourdon, Inc. Analyst Toolkit Wang PC $3.5K

Intech, Inc. Excelerator IBM/PC $10K

GEI, Inc. ProMod VAX/VMS $25K

IBM/PC
[ f LO_ZSTrCS _S J I . " '

I _AT:CN i M,Z.TEMXNCE,_oOt '_ I I |_;E L PJ+LOL_OATA [_Q_) I

I _o;_*. L_EEI3S Iu I t I I c,;sTo,._/ r / I

I " "F I I I O._-_T._ / Ex'EC_TLnLE / PA_Le_3S I

L J 0.ER:i _FI r P 0lr'L. [ vE_ I_T_ICTE0. ,_9I ,:,.,s,o_v L ,'o,_ ,',,-o,,', o,, I ° o,,, / _,,,_,,_o ,,/,.+.osJ ,.o,,_, I

m== L jjr

• -- OPTgSTE EXE.,_'TAGLE A'_:_L£_ 1_9_i

m'_'T-_"-8 I CO_E I C0'EC_ns. I EXECUTE [SO*E33ULES r ,o 1 / iooot I

C:_NANU_ _ STSTEM / OATA /OP_TZOi_5 F: --_ / " t t _ i

r_ I r rt 1[o0,,i-,_,, ,.-,.,,/=.=.:Z_, .1 _,,_,o._,,, I

I t . .J nECO,+t=umeI'_ , . -' I o_,tm l,,,,o,,_m+w f I +E'_tOm L---..

-- +=,,. Ot -_=:mmecT _ I TnESmZCTEO ¢_cs'r_z_:3 /s_.z_ Luz'-"+=`'`+'s I ,4

_oo; Ico_ S_STE_/ '_% I /PA. ¢QOS. v_.z0 / OAT+. I _-- _. "- I

/ I++'ms +_ II I to,E',,,,==,,._,o'.',, I - L,VL, _=_re+s, o,-,_I I

/ I _Ol_lliNli ,UU= _1 |REII'JTREuENTS [ P=IOCEOU_E5. t/O ..)

t _ _ / Is_._m._ I

/_oot%iCOnE ST_,_S t / " 014

i" l = +

,, |

 o,o ,+,,,,+ , t +o JI

/ / -IF.,":LtT:+"/ _ J " . . '

OATI h IqEC:MFtQUnE I _1_ | McV 50F'Tl&n_ DEVELOP.

/ aESOu_cEs i J J D4F/t, c_¢=- [NTEG_=TE. _ I_']-¢_,_,E$ ,'/0 )

pot

LS_WULATE_ ST:WG%US _! I_R3w_;;E

I SOF_?_,_E

OR;GINAL PAGE iS , .n_o,,sE _FNTEG_ATIO= _o_

OF pOOR QUALri'Y

FIGURE 3 - DRTR FLOW DIAGRAMS CSTRUCTURED RNRLYSIS)

139
SREM- SREM (software requ:[r'ements engirleerirl9 methodo].ogy) [2] is the

requirements definition tool :[n t;he DCDS (distributed comput;er design

system) tool set. DCDS provides a software engineering and developmenL

environment For the definition of requirements, specifications, designs,

code, aids for verification and validation, and documentation of

real-time software. It consists of unified systems of methodologies,

supporting software tools, utilities, and analysis techniques. The

system covers the entire data processing life cycle, starting with a

definition of the system requirements and ending with the tested

data-processing hardware and software, including operation and

maintenance requirements.

DCDS procedural techniques define the sequence of steps to be taken in

the development of software systems (See Figure 4). These steps

represent a Formalism which identifies the data base contents, produces

outputs in increments, and provides the criteria for

completeness/correctness of outputs. The steps are

Ao

Bo

C,

D,

E.

System Requirements Engineering Methodology (SYSREM): defines

system requirements.

Software Requirements Engineering Methodology (SREM): defines

system software requirements.

Distributed Design Methodology (DDM): develops a distributed

design.

Module Design Methodology (MDM): defines detailed design.

Test Design Methodology (TDM): defines test plans and

procedures against SYSREM and SREM requirements and records

test results.

PSL/PSA - PSL/PSA is a tool to aid in the precise definition of system

specifications [3]. These specifications can include both requirements

and design. PSL/PSA is composed of two components. PSL (problem

statement language) is a language used to specify software systems

requirements and designs. The model as defined in the PSL is maintained

in an entity relationship (E/R) data base. The PSA tool (problem

statement analyzer) is used to inspect the model For consistency and

completeness. PSA supports report generation and query capabilities.

See Figure 5.

140
A system is defined with PSL. by mapping its objects and re].ati.o1'_shi.ps

into the entities (e.g., process, processor, event, set, input arid

output) and relationships (e.g., generates, performs, interrupts, and

collection of) of a conceptual PSI_ E/R model. Fhe objects and

relationships are stored in the data base in a way which defines their

dependencies and interactions and allows PSA to automatically act on them.

ISDOS now has a data flow diagramming tool to interface with PSLIPSA to

graphically represent the analysis of a software system. The tool is

called STRUCTUREO ARCHITECT.

Warnier/Orr -The Warnier/Orr technique for developing, analyzing, and

representing software systems involves a technique for decomposing the

system observing the data and data structures. This technique often

called Data Structured Systems Development (DSSD) has been an accepted

method since 1970. DSSD incorporates the data architecture or data

structure approach to design and has evolved into a complete systems

development methodology,

The tool which supports the DSSD technique is called STRUCTURE(S) and is

used throughout the software lifecycle. It automates the production and

maintenance of systems from analysis through code generation.

141
Allocate System

Requirements To

DP (SSL)

System

Segment Spec

Define S/W

Requiremenls (RSL|

Software

Requirements

Spec Distributed

• Partition/

_ Decomposition

_ Anolvsis

_, • Functional

Process

Design (DOLl

Top-Level

Oes,gn Docun_nt

S/W Design

(MOL|

OP H/W Identificetion

I

I

Integration &

Te_t (TSL)

Test Plant &

Proceduret

& _¢$ults

r

Users

Figure 4 - Overview of DCDS

142
'r

Systems Engineer )

l o,.o,-'_I

Commands _ Disciplines,//

I Commands f

Management

Quality ._4sur.4nce

S/W Engm_-er,ng

Test Engmeenng

Cost Engmeenng

Cu._,tomet

Etc.

Techn#cal

Management

Re'pens

r

[" Speclai_zea

| Queries

| And

Figure 5 - The PSL/PSA System

143
3.5.2. 1.1.3 Requ:i. remer,ts Analysis l oo].s Projected Capabi].it:ies

Great strides in requirements analysis for bo_h systems and software systems

are certainly on the near horizon. Many colleges, universities and private

corporations are developing Formal Specification Languages (FSL). One such

FSL is being generated by Reasoning Systems, Inc., A. in Palo Alto,

California. These FSLs will demonstrate before implementation the exact

functions a system will have, then the system will automatically be generated

from the specification.

With the advent of knowledge based and artificial intelligent systems within 5

years time an analyst will be able to sit at an automated workbench and

verbally input the system and have it checked for accuracy and consistency.

This type of system will even be able to generate a prototyped system for

Further evaluation by the analyst/customer.

3.5.2.1.1.4 Requirements Analysis Tools References

[I] Chris Gane and Trish $arson, Structured Systems Analysis: Tools and

Techniq__s McAuto, McDonnell Douglas Corp., St. Louis, Missouri, 19/7

[2] Mark Alford, "Requirements for Distributed Data Processing Design", IEEE,

6/79, CH1445, 001500.75

[3] W. E. Beregi, "Architectural prototyping the software engineering

environment", IBM Systems Journal 23, No. I, 4-18 (1984)

[4] Pieter Mimno, "A New Technology for Mathematically Provable Software",

Computerworld, Oct. 11, 1982

[5] DoD APSE Analysis.Document Version 1.0, 18 September 1gB4

[6] DoD "Stoneman" requirements for the APSE

[7] Tom DeMarco, Structured Analysis And System Specification, Yourdon Press,

1978.

144
3.5.2.1.2 Design Tools

3.5.2,1.2.1 Design Tools Description

Design tools assist the designer in implementing an interpretation of the

system from WHAT the system should do into HOW the system will implement the

user's needs. This activity of transformation is the design process, of which

there are several well defined and mature techniques or methods. These

methods all have automated tools except in the case of the object oriented

technique developed to support the Ada environment. With the advent of the

_PS£ tools, automated support of object oriented design will be commonplace.

Design tools tend to be graphic in nature, since we deal with pictures better

than text, and represent the relationships of the system and its structure.

The following options are discussed:

m Structured Design

Object Oriented Design

Data Structures Design

DCDS

Rapid Prototyping

PDL/Ada

3,5.2.1.2.2 Design Tools Options Characterizations

Structured Design - Structured (or Composite) Design is a software

design methodology which seeks to characterize the problem decomposition

or modularization process [I]. It does so by analyzing the fundamental

types of decomposition: source/transform/sink, transactional, functional,

and data structure. Structured design proponents feel that certain types

of decomposition yield systems which are easier to implement and

maintain.
Str'uctiJred Des.[c3n also addresses the relationshi.ps between modules and

Ehe strength of modules (See Figure 6 .- Structure Chart). Module

coupling (content, common, external, control, stamp and date) is an

analysis of all the kinds of ways that modules may be dependent on other

modules. Module strength (coincidental, logical, classical, procedural,

communicational, functional and informational) is an analysis of the

relationships among the elements within a single module. Once again good

structured design implies creating modules with high strength and using

informed judgement when deciding on the type of coupling to create

between modules.

The strength of Structured Design is its 'rules' for evaluating a given

design. A designer can refine the requirements into a design. Then a

tool can assess the design against a set of criteria. [7]

Tektronix, Inc. and Cadre, Inc have tools in development which support

the Structured Design methodology. Hughes Aircraft Company has

proprietary tools which support the Structured Design methodology, and

Intech, Inc. has developed a tool which supports the drawing of structure

charts, but does not support the 'rules' for Structured Design.

148
ORIGIN_ FAGE iS

OF POOR QUALITY

COM.CODE

PAR.LIST

IAssIGN

re,_u) l.

RTAB

Figure 6 - StructUre Chart

147
Object Oriented Design - Object oriented design is a software design

methodology which emphasizes data objects and design decisions in the

modularization process rather than function and processes [2]. All

functions that process the objects or reflect the design decision are

then included in one module. The goal is to have changes impact only the

single module.

It has been shown that decomposing a system based on a flowchart of a

process produces modules that are coupled in ways which cause change to

be more difficult [2]. However by modularizing around the data and the

manipulation of the data, the difficult design decisions (which are

likely to change) are hidden from the rest o? the system. These modules

however will not correspond to the flowcharted steps of the process and

execution implies many more calls and returns among modules than in a

flowchart decomposed system. Efficiency concerns can be addressed by

having the development environment create the run time flowchart oriented

system by collecting the necessary code and data from the object oriented

modules.

Data Structures Design - This decomposition technique is based on the

premise that the program's structure should reflect the correspondences

between the structures of the input and output data of the program. The

program decomposition, therefore, is based not on data flow, but on data

structure of the input and output streams. The technique is primarily

oriented towards the design of the program logic rather than the drawing

of boundaries defining module interface. [3] [I] [6]

The Warnier/Orr technique supports this methodology. The STRUCTURE(S)

tool supports the data structures design by describing a design by means

of a diagramming technique.

- DCDS - (See SREM under requirements and analyses tools)

148
Rapid Prototyping - Rapid prototyping [4] is the process of building a

model of a final system. The model exhibits the external and some

internal characteristics of the system and is generated in a fraction of

the time of a conventionally built software system. The model is then

used to verify that the design meets the users requirements effectively.

This allows systems designers to experiment with more options and reduces

design errors which are very expensive to remove if not found until the

implementation phase. Prototyping has become an excellent method to

test, review, and evaluate portions of the system under development [B]

and is used extensively, especially to demonstrate the user interfaces

and timing conditions of a system. There are several tools in

development which are being used for system prototyping. The following

companies are actively involved: DARTS Technology, General Dynamics, San

Diego, California and USE, Anthony Wasserman, University of California at

San Francisco.

If the rapid prototyping is done in a language such as Ada then much of

the prototype may actually be used in the final product after addressing

areas which the model indicated would not meet performance requirements.

PDLIADL - PDL (Program Design Language) is a method of design

specification which uses English language to represent the design. PDL

is used as a detail design technique, once a module decomposition process

has taken place the data and processes of each module are specified in a

PDL. PDL has the advantage of being totally text oriented and is very

easy to automate compared to pictorial design specifications such as

structure charts.

The following tools are some of those available for processing PDL;

PDL Formatter - Caine, Farber and Gordon

SDDL - Jet Propulsion Labs/Cal Tech, Pasadena, California

PDL Formatter - Software Engineering Facility, IBM/FSD

149
ADL - Ada Design Language uses Ada as the PDL which has the added

advantages of enforcing the object oriented design methodology, providing

the strong data typing capabilities, promoting the program library

reusable code aspects of Ada, and providing the package oriented program

structure [53. Ada is a high level language and also a candidate for a

prototyping language. When the appropriate tools evolve, doing the

design in ADL allows for prototyping and a very fast and error free

program development phase. One of many ADL's on the market is BYRON by

Intermetrics, Inc., Cambridge, Mass.

3.5.2.1.2.3 Design Tools Projected Capabilities

The transition from analysis to design (from the WHAT to the HOW) has become

increasingly easier. With the advent of rapid prototyping, design evaluation

and graphic oriented tools the design phase of software development is

becoming shorter and more refined. Surely, we will see within the next few

years a tool which takes the analysis of a system and produce a 'first cut' of

the design. In fact, GEI's ProMod tool already does this in textual form.

Until we can add the knowledge based rules to a design, the intuitive process

of the knowledge worker is necessary. The five year prediction certainly will

include automated tools to produce a design based upon the analysis, along

with the required documentation.

The impact of reusable software packages, specifically the Ada packages, will

see a distinct shortening of the design phase as evidenced by the projects

looking into common software which is built everyday. (Common Ada Missile

Packages, McDonnell Douglas Corp. - a DoD contract). When Ada packages become

commonplace, we will see an amazing productivity increase both in shortening

the development time and the increase of 'futuristic' software development.

150
3,5.2,1,2.4 Design Tools References

[i] G. F. Myers, Composite Structured Design, New York, N.Y., Van Nostrand

Reinhold, 1978

[2] D. L. Parnas, "On the criteria to be used in decomposing systems into

modules", Communications of the RCM 15, No. 12, I053-I058 (1972)

[3] M. A. 3ackson, Principles of Proqram Desiqn, London: Academic Press, 1975

[4] W. E. Beregi, "Architectural prototyping in the software engineering

environment", IBM Systems 3ournal 13, No. I, 4-18 (igB4)

[5] Grady Booch, Software Enqineerinq with Ada, Menlo Park., CA.,

Benjamin/Cummings, 1983

[6] Ken Orr, Structured Requirements Definition, Topeka, Kansas, Ken Orr and

Associates, Inc., 1981

[7] Ed Yourdon, Larry Constantine, Structured Design, Englewood Cliffs, N.3.,

Prentice-Hall, Inc., 1979.

[8] Bernard Boar, "Applications Prototyping", SDFV Presentation, February

1984.

151
3.5.2.1.3 Code Generation

3.5,2.1.3.1 Code Generation Description

The process of code generation takes the detailed design specification and

creates source code in a programming language which executes on a target

machine to perform to system requirements. Certain characteristics of code

generating techniques arise independent of the programming language used.

Some of these techniques are characterized here:

m

M

Interactive

Automated

Production libraries

3.5.2.1.3.2 Code Generation Options Characterization

Interactive - Interactive code generation is a process where an automated

tool aids the programmer in generating code by providing a template to

help define the structure of the program. The coding process is speeded

up and made more error free because the programmer has less work to do in

specifying the loops (IF-THEN-ELSE, etc). The Language Sensitive Editors

(LSE) from Digital Corporation support several languages, including

FORTRAN, Ada, C, and Pascal. The LSE in the IBM/FSD Software Engineering

Facility is called DSS. DSS is table driven and supports several

languages including Ada and PDL/Ada. The VI editor which is the standard

editor on the UNIX systems supports interactive code generation for the

LISP language. All LSE's are aware of the language syntax required ?or

the code being entered on an automated system. All correct prefixes,

suffixes, structure and specific syntax for the given language is

automatically entered by the LSE during the entry of the code by the

programmer. This eliminates the minor problems of misplaced or missing

syntax which ultimately cause major compile or runtime errors. Easy

access to terminals is a requirement of this option.

152
Automated code generation, seemingly futuristic, is in use today by many

private companies and universities. The code generation field includes

at least two major areas; (1) Formal specification languages which can be

checked for accuracy and completeness - USE.IT from High Order Software

is an examples of this type of code generator. (2) DARTS Technology from

General Dynamics is an example o? a code generator which is able to

interpret the changes which must take place when an additional function

is made to a given system. The code is then generated and an entirely

new system is ready for use.

Production libraries - Certain programming environments like Bda and Unix

support a production library capability [I]. This allows all programs to

be entered into a data base as they are generated. The details of their

inputs, outputs and functions provided are maintained with the data

base. This allows others to make use of the designs and programs that.

already exist. Reusing software in this way optimizes the coding process

by taking advantage of previous design, code, and testing efforts.

The entire field of reusable software has mushroomed recently. The

productivity increases which can be derived from the reuse of design,

code, test, and all parts of the development is fundamental. Several

programs and projects which will be contributing to this arena are:

Pro t C_om__P_anyor Rqency

SEF (Software Engineering Facility)

CAMPS

Reusable Software Implementation

Program (RSIP)

DARTS Technology

DRACO

IBM/FSD

McDonnell Douglas

Navy Research Laboratory

General Dynamics

University of California

at Irvine

153
3.5.2.1.3.3 Code Generation Projected Capabilities

All of the above options are being used today. [he least mature is the

automated generation of code from formal high level specifications. Several

systems exist today and by Ig87, it can be expected that others will be

available and more target languages and machines will be supported.

Ada will also advance the production library technologies as it matures in the

19B7 timeframe.

3.5.2.1.3.4 Code Generation References

[i] Michael Ryer, "Developing on Ada programming Support Environment",

Mini-Micro Systems, Sept 1982, 223-226
3.5.2.1.4 Software lest, Integration and Verification

3.5.2.1.4.1 Software T, I & V Description

Testing is the examination of program execution behavior to ensure that

requirements are satisfied. Testing of the Space Station software will be

very important because of its life/mission critical nature. Facilities must

be provided in the SSE for testing because of the inability to observe the

software in actual use in a safe environment (i.e. on the ground). These test

facilities must support a more cost effective approach to testing than has

been achieved in past manned space programs. This description of the testing

function will apply to the most rigorous testing. For less critical, less

complex software less rigorous testing may be done.

Testing may be performed by the developer or by an independent agency.

Independent verification and validation (IV&V) makes sense many times at the

integration and systems level. IV & V is the procedure of evaluating the

quality of the software and demonstrating that the functionality of the

requirements have been satisfied by an autonomous agency. This agency should

be involved from requirements specification time, and is independent of the

development team and therefore, less affected by any biases. This agency

looks at the system from the user's perspective.

Three levels of testing are described:

m Unit test

Integration testing

Systems testing

3.5.2.1.4.2 Software T, I & V Options Characterization

Unit testing - The purpose of unit testing is to find errors in a single

module of software. Errors found in this phase of testing can be

corrected more cost effectively than in the other two phases.

155
Unit Test Tools - Tools that facilitate unit testing include:

Logic Flow Graph Generators - A tool of this type reads the source

code for the program to be tested and generates a directed graph

that represented the execution flow of the module (in some sense

this is similar to a flow chart). One use of these digraphs is to

analyze test coverage.

Data Flow Graph Generators - A tool of this type reads the source

code for the program to be tested and generates a graph that would

represent the flow of data through a program. Some uses of these

graphs are to analyze set/use of variables and debug other variable

usage errors,

Complexity Measuring tools - A tool of this type reads the source _

code for the program to be tested and generates a number that

represents the complexity of sections of the code. This information

is useful in identifying high risk areas of the code. These areas

would require a higher test coverage.

Stub/Driver Generator - A tool of this type takes the source code of

a module and generates skeleton stubs and drivers necessary for

execution of the program being tested. This would need to be done,

for example, when the module calls another procedure that has not

yet been coded.

Test Data Generators - A tool of this type generates test data to be

used to test the program. An example of how these test data values

would be generated would be the following. The test data generator

reads the source code and/or digraph and generates a set of input

data that will force execution of the program to go down a certain

logic flow path.
Source Level Debugger- A tool of this type provides diagnostic

capability during test execution of the software. These

capabilities would include start-stop at a given statement, display

a variable's value and changea variable's value.

Test Design Language- This is a language to be used to design the

test case procedures. It should be the interface to the source

level debugger. This should be the samelanguage that will be used

for integration and system testing. To support the design and

development of test case using this Test Design Language, a set of

development tools very similar to program development tools should

be provided. These tools include a syntax directed editor, static

analysis aids, cross reference data generators, etc.

Performance Monitoring Tools - A tool of this type is used to

estimate CPU and space usage of the module.

A Symbolic Execution Tool - A tool of this type symbolically

executes the program being tested. This means that a simulation of

the programs execution is performed with symbolic values placed in

the program variables.

Integration Testing - The purpose of integration testing is to find

errors in the interfaces and communication between software modules.

Integration and integration testing of Space Station software will be a

more important aspect of the software engineering process than in

previous manned space efforts. This is because of the distributed nature

of the system as well as the extensive use of advanced technology

hardware. The integration testing should proceed in small well defined

steps. At each step the system execution should be less controlled and

more realistic than the previous step.

157
Integration Test Tools - Several tools facilitate integration testing.

These tools include:

Interface analyzers - A tool of this type reads the interface

portion of the software being tested and either analyzes for

potential problem areas or prints out a summary of interface

information for manual analysis. This information would include

cross reference data, calling sequences and parameter lists.

Integration Test Environment - This is a set of hardware and or

software tools to provide diagnostics during execution of the

software being integrated. This tool provides the same support that

the source level debugger provides for unit testing. This tool may

or may not be the same set of tools used as a source level

debugger, I? it is not the same set it may have pieces that are

common with the source level debugger.

- System Test - The purpose of system testing is to take a completely

integrated software system and execute it in an environment that is close

to the real operating environment in order to find errors in the system.

These errors may be code, design or requirements errors. This phase of

testing includes the final acceptance testing of the system. This

testing includes performance as well as functional testing.

System Test Tools - System testing tools are not so widely available as

unit and integration test tools and most current system test tools are

specific to the system being tested. The system test to be provided for

testing of the Space Station software should be flexible enough to be

used for system testing of other space systems and flexible enough to

provide for technology insertion. The types of tools that should be

provided are:

158
A System Test Environment - This tool provides the same function as

the source level debugger and the integration test environment. The

two significant differences between the system test environment and

the other two tools are the following. The system test environment

should provide a cost effective means of executing the entire

software system with sufficient diagnostic capabilities. The system

test environment should provide a means of executing the system in a

way that is very close to the expected real operating environment.

Data Logging and Reduction Tools - A tool of this type saves data

obtained from a system test and format, reduce and summarize the

data. These type of tools may be used for unit and integration

testing but they are most necessary in system testing because of the

amount of data saved from a system test.

Data Analysis Tools - A tool of this type takes outputs from the

data reduction tools and provide various kinds of automatic

analysis. These include software programs that perform engineering

calculations and compare the results with the data from the system

test, software programs that correlate simulator data with data

calculated by the system, software programs that format data into

graphical form, graphics hardware and software packages, and expert

systems that use rule base knowledge to analyze results.

Each of the above mentioned testing techniques uses one or all of the

following types of test and test options which are included in the tools.

m

Static Analysis

Path Analysis

Auditing

Flow Analysis

159
Fortran Programming Environment (FPE) by Sofl'ool, Inc., incorporates all the

above testing options. In addition to these it also includes compilation,

optimization, instrumentation, tracing, and guarantees thorough test coverage.

The Maintainability Analysis Tool (MAT) by Science Applications, Inc., also

supports Fortran and incorporates the above options plus (I) locating module

interface problems, (2) configuration management, (3) parsing and analysis of

the source code, (4) produces calling trees, and (5) quantifies the

maintainability of modules.

3.5.2.1.4.3 Software T, I & V Projected Capabilities

Software testing and verification along with integration is the most time

intensive phase of software development. Developers agree that if the

beginning phases can guarantee the accuracy of the requirements and design,

this phase could be greatly reduced and the reliability of the software will

increase. Therefore, because the automated tools to assist in the beginning

phases of software development are becoming more robust, and testing will be

incorporated into the development phase we will see these levels of testing

accomplished in a smaller portion of the software life cycle.

3.5.2.1.4.4 Software T, I & V References

[1] Gerald M. Berns, "The Mat Program", Proceedings of the DECUS Symposium,

Dec. 19B4

[2] David Hamilton, "Space Station Integration Test Environment", IBM FSD

Houston, lgB5.

ISO
3.5.2.2.1 Acquisition Strategies

3.5.2.2.1.1 Acquisition Strategies Description

A combination of methods for acquiring software will be utilized on the Space

Station because of the wide variety of systems required. Wherepossible,

commercially available software products and software from previous NASA

projects can be used when justified by lower life cycle cost projections.

Otherwise new software maybe developed under contract.

The following options are discussed:

m

m

Commercially available

Software recovery

Multiple Contractor

Single Contractor

Table 2 compares key characteristics of these options.

3.5.2.2.1.2 Acquisition Strategies Options Characterization

- Commercially Available - Commercially available off-the-shelf software

(COTS) is the least expensive acquisition method. Total life cycle costs

and schedule risks are much lower than other methods. Growth and

technology advancements can be accommodated easier with commercially

available software. See Table 3 for examples of some commercially

available software.

When acquiring software from the commercial world several issues must be

addressed:

- Performance and resource constraints

- Changing requirements

- Licensing the software

- Use of the software in the final product

- Multiple locations of the SSE

161
COMPARISON OF SOFI'WARE ACQUISITION OPTIONS

FEATURE

Relative

Cost

RISK

ADVANTAGES

Problems

COTS

LOW

LOW

- Growth

iaccommodat ion

- Fastest

development

- Changing

requirements

- Performance

- Integration

of commercial

products

RECOVERY

MEDIUM

MEDIUM

- Fast

development

- Builds on

itself

- Prejudices

- Requirements

mismatch

- Logistics

- Availability

of maintenance

skills

MULTIPLE

CONTRACTOR

HIGHEST

HIGHEST

- Varied

resources

- Communication

- Multiple

customer

interfaces

- Less able

to exploit

commonalities

SINGLE

CONTRACTOR

HIGH

HIGH

- Fewer

communication

problems

- Single

NASA interface

- Risk of

limited

resources

- Possible

narrow

vision

- Lack of

diversity or

expertise

Table 2

162
COMMERCIALLY AVAILABLE SOFTWARE

Type of Software Example of Product

Operating Systems

Data Base Systems

Communication Systems

VM - IBM

MVS - IBM

VAX/VMS - VAX

NOS - CONTROL DATA

MCP - BURROUGHS

GCOS - HONEYWELL

PC/DOS

UNIX

DB II - IBM

DMS II - Burroughs

DM IV - Honeywell

SQL/DS - IBM

Accent R - DEC

ADABASE - IBM

AMBASE - DEC

CLIO - IBM, DEC

DBMS II - DEC, PDP

DMS - SPERRY

NDL - Burroughs

CICS/VS - IBM

ADR - IBM

CMS 1100 - SPERRY

Com-Plete - IBM

DNS - HONEYWELL

Table 3

163
Software recovery - Related projects often have related software

requirements. Ideally, software generated by one should be usable on

another. In reality many factors make software recovery more difficult

than it sounds. Many times the "not invented here" syndrome creates a

negative atmosphere for software recovery. However, if it can be

determined that an existing software package satisfies or nearly

satisfies a new project's requirements, then it may be the cost effective

approach. Costs and schedule risks will not be as low as a commercial

product. [1] An example of a software product which has been

successfully reused is the RTX real time operating system which was

developed initially for NASA, but has been used on several DoD S/W

development projects. [2]

Multiple Contractors - If custom software must be developed to support

unique requirements then NASA will accomplish this via contractors. In

the Space Station program, there will be four NASA centers each with

contractors performing software development functions for NASA. The

multiple contractors approach is, therefore, not an option, but a given

for the Space Station program. Interface and dependency problems must be

addressed in this environment. Schedule risks are greater.

Communication must be enhanced in order to maintain standards and to

exploit commonality between elements.

Single Contractor - A single contractor, whenever possible, holds the

most promise for low cost, quality custom software. Interface and

dependency problems are contained within a single management structure.

Planning, scheduling and tracking also take place within that structure.

A single interface for NASA exists. Standards are easier to define and

enforce. Commonality is easier to exploit. Single contractors, however,

run the risk of hitting many pitfalls such as narrow vision, lack of

diversity and expertise, and the "not invented here" syndrome.

IB4
3.5.2.2.1.3 Acquisition Strategies Projected Capabilities

The key factor here is commercially available software and the single most

important projected capability in the 1987 timeframe is the Ada programming

language and its support environment. The Ada environment has the following

advantages:

w

m

w

Standard development tool set

Portability of the software (tool sets and developed software)

Future reusable packages library

Designed for real.-time embedded systems

The availability of Ada will have a significant impact on how NASA acquires

and manages software. When Ada becomes commercially available the acquisition

of its tools will limit the risk and cost of constructing the SSE itself. Ada

then would be used to increase the quality of contractor generated custom

software for the Space Station data management system.

3.5.2.2.1.4 Acquisition Strategies References

[1] R. C. McCain, Software Reusability Study Report, FSD Houston, 3/26/84

[2] George Gaxiola, "Commonality of Real Time Command and Control", IBM FSD

Technical Directions, 1971, Vol. 7, No. 3.

IB5
3.5.2.2.2 Configuration Management

3,5.2.2.2.1 Configuration Management Description

Edward Bersoff [2] defines configuration management as "The discipline of

identifying the configuration of a system at disc_____r.e_te points in time for

purposes of systematically controlling changes to this configuration and

maintaining the inteqrity and traceability of this configuration throughout

the system life cycle". Figure 7 depicts configuration management as 4

elements. [3]

All large software development projects require a mechanism for controlling

changes to the product. Historically the change process has evolved from a

simple programmer controlled process at the beginning of the project to a

sophisticated customer managed, data base controlled configuration management

(C71) process at the maturation of the project. These CM systems have normally

been developed along with the software product and were tailored to the

environment present, i.e. control boards, change request forms, problem

reporting forms, program library structures, etc.

Current trends in configuration management tools are similar to other tool

areas - more general purpose tools commercially supplied and integrated with

the other software development tools and data bases.

Configuration Management comes in several different 'flavors' and each type

comprises minimum through maximum amount of control over the software.

Support Software - the management of developed or acquired software which

is used in the SSE to develop additional software. In particular, this

can include; compilers, editors, linkers, testers, etc.

166
t_HAT IS HY SYSTEM CONFIGUPJ_TION

HOW DO I CONTROL CHANGES TO MY

CONFIGURATION? IV

WHAT CHANGES HAVE I MADE TO

MY SYSTEM? "_

DOES THE SYSTEM I AM BUILDING _jL

SATISFY THE STATED NEEDS?--Ir

CONFIGURATION

HANAGEMENT

IDENTIFICATION

CONTROL

STATUS ACCOUNTING

AUDITING

YOUR SYSTEM CONFIfiURATION CONSISTS OF THE

FOLLOWING ITEMS: (ITEM1, ITEM2..... ITEM )

THE STEPS IN PROCESSING CHANGES THAT

prDIRECTLY OR INDIRECTLY AFFECT YNUR CNNFIGURATION ARE (STEPI, STEP2,.....STEPn)

._YOUR SYSTEM CONFIGURATION AND RELATED CHANGES

AT THIS TIME ARE: (ITEMI, ITEM2....... ITE_m)

+ (CHANGE1, CHANGE2......CHAN&Ep, PE_DIqG

CHANGE I....... PENgING CHANGEq)

4YOUR SYSTEM AS CURRENTLY BUILT DIFFERS FROM

THE STATED NEEDS AND DERIVATIVE SPECIFICATIONS

AS FOLLOWS: (DIFFERENCE I, DIFFERENCE 2......

DIFFERENCE n)

Figure 7. The Four Component Elements of Configuration Management

167
Product Software - the management of software developed or acquired For

the Space Station Program activity.

Documentation - the management and control of all documentation

generated, or delivered for all software.

Controls over the software and documentation will and should take on different

levels at different locations of this program.

A minimum amount of control is desired over Space Station customers that

generate autonomous software (i.e. the programs do not interface with other

Space Station DMS subsystems and the DMS is not dependent on the programs).

More controls, such as integrated testing and means of tracking problems and

changes, will be needed if their software is not autonomous. The most control

will be exercised over core and system level software packages. Also to be

considered are aspects of configuration management as they apply to whatever

onboard support of changes is eventually provided in the Space Station DMS.

Location of control will be a Factor in Space Station software configuration

management. With four NASA centers contracting software development, the CM

process must be tailorable to some extent to each center's special

requirements.

The following options are discussed:

D

m

SPF

MMS

CCC

Source Tools

168
3.5.2.2.2,2 Configuration Management Options Characterizations

SPF -'The Software Production Facility is the tool used to produce the

Primary Avionics Software System (PASS) for the Space Shuttle. It is

comprised of commercial and custom hardware and software products.

Configuration control is maintained over the commercial software, the

custom development tool software and PASS software.

Configuration control of software produced within the SPF' (both the SPF

and the PASS) is effected by an extensive set of tools, which are

integrated into a package to support the planning, development, build and

test phases of a software project. The elements which are under

configuration control are the source modules, the executable load

modules, and descriptor data for each source module (e.g. library

residence, language translators, linkage editor module type, cross

reference data, and program function). All changes must be associated

with one or more 'Control Instruments' There are many different types

of control instruments (Change Request (CR), Discrepancy Reports (DR),

Program Change Authorization (PCA), etc.). All control instruments are

stored in an IMS data base called the Configuration Management Data Base

(CMDB). A set of control boards is associated with each control

instrument and the control instrument must receive approval from each of

its boards before the affected software is baselined into the system.

See Figure B.

169
CMDB ACTIONS

ENTER CHANGE REQOEST

PRINT AGENDA

CHANG[ REQUEST (CR)

+

",AS, CONnOURATION I

CO.TROLBOARDl

..k

DISTRIBUTE CR i

_'X)PII[$ ,_ J"

IBM

PROJECT OFFICE

IBM

COORDINATING

BOARD

,kEXTERNAL

ASSESS_4ENTS

ENTER ASSESSMENT IBM ASSESSMENT

ENTER CR STATUS

(APPROVE0, ETC.)

ENTER SCHEDULING,

REASSESS_ENT. &

SOFTWARE UODULES

J_ i

I

REVIEW BY NASA/ J

I

SSO BOARD

6

IMP,_CTS TO NASA

CONFIG. CONTROL (DISAPPROVED OR WITHDRAWN)---'--'

BOARD I

! IBM SCHEDULING/ REASSESS_ENT

1

I REVIEW WITH SSD

I REPORT TO NASA

CONFIG. CONTROL

BOARD

,_ EXIT

CHANGE REQUEST PROCESSING FLOW

Figure 9

170
Interactive panels are provided using the Application Development

Facility (ADF) to allow the users to enter the control instruments, board

approvals, affected modules, and module submission. Access to the panels

is controlled through profiles, so that only authorized users can enter

board approvals, schedules, etc. Verification that approval has been

given is done automatically by the build tools. If an update has been

submitted for a control instrument that is not approved, it will be

automatically withdrawn from the build.

A large number of printed reports are available from the CMDB and several

products exist to facilitate additional report generation from the IMS

data base.

A change in the commercial software must be preceded by the creation of a

Change Request (CR) or an Incidence Report (IR). These are stored in an

information management data base. CRs are normally generated by the user

community and must be approved by the Change Control Board staffed by the

customer and users prior to implementation. Incidence Reports are

created as the result of a problem being reported to the central 'Help

Desk' which is staffed by the organization responsible For the commercial

products. The software modifications are provided by the commercial

vendors. These are incorporated onto a set of system disk packs which

are then frozen, tested and then released into production.

Module Management System (MMS) is a product of Digital Equipment

Corporation which supports the configuration of a software library

system. This includes the changes of versions for different site

locations, rebuild capabilities, change tracking, and avoids redundancies

in the database. The tool uses flat files and runs on VAX hardware.

Change and Configuration Control (CCC) is a product of Softool which

provides a comprehensive change control environment for a software

library system. CCC controls who can make changes, handles source code,

object code, test data, and documentation and can deal with any

171
language. The programs comprehensive features include automatic

reconstruction of previous versions, problem tracking, difference

reports, management reports, access control, archiving, compression,

encryption, and automatic recovery.

SourceTools is a product of Oregon Software which supports the

development and maintenance of software program libraries. It consists

of a collection of programs which function with any computer language,

coordinates changes made by several programmers jointly, and uses

standards text files and documentation. The tool set consists of (1)

control, creation and modification of source files, (2) a mechanism to

build an entire system, (3) a maintenance program.

3.5.2.2.2.3 Configuration Management Projected Capabilities

The future of CM systems appears to be general purpose tailorable systems

working on data in a distributed data base (distributed to the extent of the

development environment). These systems are available today and should be run

as a background process to track the software changes and documentation. The

metrics for evaluating and assessing configuration issues will also be

included by IgBT.

3.5.2.2.2.4 Configuration Management References

[i] System Engineering Tools Compendium - IBM FSD Bethesda, MD IgB3

[2] Edward Bersof?, "Software Configuration Management", Prentice Hall,

Englewood Cliffs, N3 07632, 1980

[3] Daniel Roy, "Software Tools and Methodology Study for NRSR MSOCC",

Century Computing, Laurel, MD 20707, June lgB4

172
3.5.2.2.3 Standards Definition and Enforcement

3.5.2.2,3.1 Standards Definition and Enforcement Descriptions

A common SSE will provide NASA with the best chance for defining and enforcing

standards. Definition and enforcement are very different issues and must be

approached using distinct processes. Standards, while necessary for

communication and uniform implementation, should not lead to restricting

productivity. Therefore, care needs to be taken defining and enforcing

standards only where history has proven the need.

Standards should be defined for many different aspects of software

development. It is first necessary, however, for an analysis of the software

development process to be done to decide where standards show the most promise

of helping to attain program goals. Once determined, standards must be

documented. This can be accomplished by publishing the most rigid standards

in a formal standards document which is carefully change controlled. These

standards specify design and code methodologies to be followed, review and

testing processes, documentation required, and compliance and deviation

aspects. Less rigid standards and conventions can be documented and

distributed in a more dynamic manner.

Standards for software requirements and design documentation are often a

function of criticality o? the software. Critical software systems may be

required to maintain documentation through the detailed design specifications

for the life of the project.

Automated standards enforcement will truly improve productivity in software

development standards, since both the software and documentation can be

updated at the same time, eliminating the need for dual changes.

A unique problem that the Space Station DMS system will have to address is the

definition and enforcement of standards to apply to the customer supplied

software that will execute in the SSDS resources. NASA has recently published

a directory of 25 standard documents and guidelines from a variety of source:

IEEE, National Bureau of Standards, DoD and ESA. [5]

173'
The following options are discussed:

m

Control boards

Inspections

NMI 2410.6

ICD's

3.5.2.2.3.2 Standards Definition & Enforcement Options Characterization

Control boards - Control boards are a means of assigning a group of

"concerned" individuals the responsibility of reviewing submitted

material to ensure it meets the standards applied by the control board.

For this method to work the control boards must have authority,

knowledge, and time to do the job. Submission must be a requirement and

submitters must view the board as informed and fair. A process for

review, pass or fail, and tentative resubmission must be set up.

Inspections - Inspections address standards enforcement via peer review.

Any level of software engineering (i.e., requirements, design, code,

etc.) has products which may be reviewed for conformance to applicable

standards.

Inspections are a proven manner to catch errors and insure standards

conformance since their introduction in 1973 by IBM [3]. Inspections

have taken place in varying degrees of formality. Their success has been

recognized and inspections are being used more often. [4]

Standards enforcement is only one reason for inspections. Inspecting for

product correctness, performance concerns, efficiencies, etc., are other

reasons for inspections [1].

174
NMI2410.6 - NMI2410.6 is a NASA document which specifies standards to be

applied to software development for mission critical systems developed

for NASA. [2]. NM12410.6 specifies a plan that contains a management

approach section and a technical approach section. Within the management

approach section should be information about the following:

I)

2)

3)

4)

5)

6)

l)

B)

Identification of all S/W elements and corresponding

organizational responsibilities

Approach to categorization and classification policies

Management mechanisms in the areas of: requirements

development and control, schedules development and control,

resource development and control, internal review concepts, and

external review concepts

What documents will be generated

What CM techniques will be used

What quality assurance plans will be made

Deviation and waiver procedures

Method of maintaining the management plan

Within the technical approach section should be information about the

following:

1) Top level functional requirements

2) Hierarchical view of system elements

3) Plan for software requirements definition process

4) Plan for software design & implementation process

5) Plan For test and delivery process

6) Plan for maintenance & updating process

7) Plan for software engineering approach

Finally NM12410.6 provides for specific reviews of the project management

plan.

175
ICD's - Interface Control Documents (ICD's) are documents that specify

the details of hardware and software interfaces in an exact manner. All

affected parties have to agree on the details and thereafter the

interface is fixed and becomes a standard which must be adhered to by all

users.

3.5.2.2.3.3 Standards Definition & Enforcement Projected Capabilities

The Standards Definition and Enforcement process will be aided by the

automation of the software development process. Rs programmers, designers and

testers begin to utilize the paperless electronic tools being developed,

several of the problems with standards will be lessened. Communication among

inspection items, for example, will be facilitated by the SSE and inspections

can be done on line with comments and corrections being fed back automatically

to the programmer. With electronic documentation, all reviews by control

boards for standards compliance will be made more effective. Interface

control standards will be easier to track and verify, especially when the

interfaces are between centers where long distance communication is involved

in the definition and compliance process.

Means to aid these communication problems in standards definition and

enforcement are available today and should be incorporated into the SSE.

One tool which enforces standards is the Fortran Programming Environment (FPE)

by SofTool, Inc. FPE guarantees that all source code meets required standards

by auditing the code, incorporating user defined standard formats, and

includes PDL statements as developed during the detailed design phase. This

last feature supports the inspection team concept, so that evaluation of the

code can be accomplished by comparing it to the accepted detailed design.

176
3.5.2.2.3.4 Standards Definition & Enforcement References

[1] Weinberg, Gerald M. and Freedman, Daniel P., "Reviews, Walkthroughs and

Inspections," IEEE Transactions on Software Engineering, Vol. SE-IO, No.

1, 68-72 (1/1984)

[2] NASA NS/Information Systems Divisions, NMI2410.6, NASA Software

Management Requirements for Flight Projects, Feb. 1, 1979

[3] IBM, "Structured Walkthroughs: A Project Management Tool," Bethesda,

Maryland, 1973

[4] Edward Yourdon, Structured Walkthrouqhs, Yourdon Press, New York, NY 1979.

[5] Directory of Software Standards, NASA Office of Chief Engineer, Software

Management and Assurance Program, D-DI-D9, January 1985.

177
3.5.2.2.4 Development Environment Structure

3.5.2.2.4.1 DevelopmentEnvironment Structure Description

Software productivity increases can be mappedto several actual items; (1) use

of automated tools, (2) computer facilities and their availability, (3)

techniques and methods for development, and the most influencing factor, (4)

work environment.

3.5.2.2.4.2 DevelopmentEnvironment Structure Options Characterization

A TRWstudy headed by Barry Boehm[I] and by the Atlantic SystemsGuild, Inc.,

headed by TomDeMarco[2] have demonstrated the necessity to evaluate the work

environment and ergonomics of the software development group. Areas which

must be considered and evaluated are:

- Private work space - recommend100 square feet

- Furnishings - desk, table, chairs

- Modular vs enclosed rooms

- Communications - electronic mail, telephone

- Terminals, workstations, personal computers, and printers

- Support personnel - secretarial staff, computer operations, etc.

- Support areas - conference rooms, lunch areas, technical libraries

178
Programmer team structure - The team structure for the programming group

has a significant effect on the efficiency of the group. One option is

the chief programmer team which emphasizes a strong technical leader in

the programming group. Requirements analysis and top level design is

under control of the lead. Programmers in the group produce the detailed

design and then implement and test. The Chief programmer coordinates,

controls, and enforces standards on the group. The group acts as a team

participating in peer group reviews (inspections), testing each others

implementation, and exchanging implementation techniques.

3.5.2.2.4.3 Development Environment Structure Projected Capabilities

Since the development environment holds such an important role for software

productivity, each of these areas must be studied and the best solution For

each should be incorporated into the SSE as part of the entire concept.

Powerful new software engineering tools are beginning to emerge and should be

encorporated into the SSE as they are available. Other issues, such as quiet

time to concentrate, training for tools and techniques, and support groups

(in-house gurus), should be considered when dealing with the work

environment.

The encouragement of group dynamics, communication techniques, and feelings of

ownership must be taken into consideration when setting up a development

environment.

3.5.2.2.4.4 Development Environment Structure References

[I] Barry Boehm, Software Engineerin q Economics, Englewood Cliffs, N.3.,

Prentice-Hall (lgBl).

[2] Tom DeMarco, "The 1984 Coding Wars", presented at the Structured

Development Forum VI, February 1985, Atlantic Systems Guild, New York, NY.

179
3,5,2.2.5 Development Facilities

3.5.2.2.5.1 Development Facilities Description

The facility for software development is normally a "host" processor(s). Here

the system is built for a target machine where it will ultimately reside. The

various types of host facilities all present different perspectives to users.

The type of facility may affect the integration functions which occur in the

SSE. The means for handling growth of the SSE will be different. It is,

therefore, important to critically review the options for SSE facilities.

Three options for the distribution of SSE host processing are discussed:

Centralized

Distributed with unique hardware environments

Distributed with common hardware environments

Table 3 summarizes the characteristics of the facilities options.

3.5.2.2.5 Development Facilities Options Characterizations

Centralized - R centralized SSE implies one large host facility with

local and long distance workstation usage. The central host has

computing power in one location sufficient to handle peak loads of all

users plus any integrated testing/simulation. Long distance access is

handled via long distance telephone lines or DOMSAT links.

A centralized facility implies that the whole set of growth and resource

management functions are controlled by a single agency in the most

efficient manner. System procurement is facilitated under one agency.

Hardware incompatibilities are minimized. A single physical plant exists

- one building, A/C, operators etc.

1BO
FEATURE CENTRALIZED COPtMON UNIQUE

DISTRIBUTED DISTRIBUTED

RISK MEDIUM LOW HIGH

GROWTH MEDIUM HIGH HIGH

POTENTIAL

H/W COSTS NO DIFFERENCES SIGNIFICANT

INITIAL LOW MEDIUM HIGH

S/W COSTS

LIFE CYCLE LOW LOW HIGH

S/W COSTS

USER - Limited tool set

SUPPORT

INTEGRATION

SUPPORT

- Perceived lack

of control

- Limited site

unique uses

-No hands on

- Best

- Good support

for reviews and

communication

- More direct user

control

- Effective support

personnel

- Allows hands

on use

- Good

- Less effective

support personnel

- Allows hands

on use

- Poor

- Incompatible

systems

DATA

MANAGEMENT

- Best support - Problems:

- communications

of data

- security

- dependencies

- Problems:

- communication

of data

- security

- dependencies

Table 3 - Comparison of Facilities Options

181
In use, a centralized SSE facilitates the speed, ease, and effectiveness of

all integrating ?unctions such as intercenter reviews, standards

enforcement, inter?ace control, system builds, configuration management,

high level planning, scheduling and the TMIS interface. Rlso, a

centralized facility allows ?or more exploitation of hardware and software

commonality. Data bases are more easily integrated together and all users

have the same data available on-line and up to date.

Distributed with unique hardware environments - This option would allow

each center to use whatever processing facilities it had or desired to

procure. Tools or methodologies which the center and its contractors had

found most effective could be carried forward into the Space Station

program. The SSE tools would have to be designed and coded to run in all

the various facilities. Commonality o? hardware and software factors would

not be achievable with the resultant savings lost. SSE development would

be a much larger challenge with increased cost and schedule risks.

Rn advantage of a distributed with unique hardware environment SSE is that

each facility would have maximum control over the SSE resource. The least

expensive system ?or that center could be procured. Rnd it could be more

effectively tailored to the job assigned to that center.

Distributed with common hardware environments - A distributed SSE implies a

network o? host processors integrated together by a controlling center.

Each host site has the control necessary to manage the computing resources

it feels are needed to handle its user requirements. Rccess to the

distributed sites is via local or long distance lines or domestic satellite

links. R lead center provides the overall integrating ?unctions by

gathering data from all hosts on the network.

182
This environment gives the host site control over the resources necessary

to accomplish its job with the exception of the SSE system itself which

would be supplied by the lead center. All center unique requirements of

the SSE system would also be provided or approved by the lead center.

This would allow for a maximum exploitation of commonality resulting in

this lowest cost full function SSE.

Nith each center responsible for procuring its own system, a chance exists

?or making use of existing facilities - within compatibility constraints

of the SS£ system. Center unique software might be recoverable.

Growth is easily accommodated in a distributed designed SS£. Larger host

processors or new host sites can handle increased work loads and network

data rates can be increased without significant impacts to the SSE system.

In use, a distributed SSE requires each site to provide the lead center

with all data necessary for integrating functions such as intercenter

reviews, standards enforcement, interface control, system builds,

configuration management, high level planning, scheduling, and the TMIS

interface.

Some functions in a distributed SSE might appear slower to the users or

have outdated data. Certain intercenter data bases would have to be kept

at the lead center to reduce the problems associated with data

duplication. This would require a network request to the lead center for

data from these data bases.

183
3.5.2.2.5.3 Development Facilities Projected Capabilities

All capabilities discussed for both distributed and centralized facilities

exist today. The future will see greater host processor capabilities for less

cost and greater network communication capabilities and standards. One

technology sure to play an important role in the future will be intelligent

workstations. Whether the SSE is distributed or centralized the intelligent

workstation should be considered in the design of the SSE. As these

workstations evolve more power and memory they will be able to take over much

of the jobs typical SSE users will be repeatedly doing-edits, compiles, and

low level testing.

°

3.5.2.2.5.4 Development Facilities References

Ill Tannenbaum, Andrew S., Computer Networks, Englewood Cli??s, N.J.,

Prentice-Hall, Inc. lg81

184
3.5.2.2,6 Project Management Tools

3.5.2.2.6.1 Project Management Tools Description

Project management implies the management of a project using techniques to lay

out the plans, evaluate the progress, and provide the "what-ifs" for a

project. All aspects of a project are taken into account; resources, tasking,

costing, milestones, burden rates, and tracking the actuals against the

estimates. The most ideal situation is to have an automated tool which will

query the project in someway and automatically generate the reports

necessary. This automation should be accomplished without the intervention of

a third party, and should be capable of generating accurate reports based upon

the needs of the project manager or supervision.

3.5.2.2.6.2 Project Management Options Characterization

All of the project management tools currently available on the market run on a

variety of hardware and were developed specifically for business systems. The:

software development world has been basically ignored as far as project

management is concerned. Currently, there is only one (known to this author)

available for tracking the project exactly as it progresses m APCE an

automated tool developed by PRC, Inc. The unique aspect of this tool is its

ability to track the progress of a project without the interference of the

management or a dedicated person to track the project. It queries the project

data base for expected vs. accomplished, evaluates the current status of a

project, charts the critical path, and estimates futures based upon the

current status. This is all done by using the typical software project

life-cycle from requirements through software maintenance and evaluating the

project as it progresses in time.

185
3.5.2.2.6,3 Project Management Projected Capabilities

Software development has become a major effort in project management and will

continue to become more and more important in all future efforts which are

automated. As demonstrated in some of the semi-integrated tools available on

the market, software project management, along with project metrics, is an

extremely necessary and important part of delivering software on-time and

within-cost. Therefore, within the next three to five years the addition of

software project management tools will see a major increase in their

availability.

3.5.2.2.6.4 Project Management Tools Reference

None

186
Acronym List

AIE

ALS

ALS/N

APSE

CCC

CM

CMDB

COTS

CR

DCDS

DFD

DMS

DR

E/R

HOS

ICD

IV&V

KAPSE

LSE

MAPSE

MMS

PASS

PCA

PSA

PSL

RFP

RTX

SSE

SPF

SREM

SA

SSDS

STARS

SYSREM

TMIS

Ada Integrated Environment

Ada Language System

Ada Language System/Navy

Ada Programming Support Environment

Change and Configuration Control

Configuration Management

Configuration Management Data Base

Commercial Off-the-Shelf Software

Change Request

Distributed Computer Design System

Data Flow Diagram

Data Management System

Discrepancy Report

Entity/Relationship

Higher Order Systems

Interface Control Document

Independent Validation and Verification

Kernal APSE

Language Sensity Editors

Minimum APSE

Module Management System

Primary Avionics Shuttle Software

Program Change Authorization

Problem Statement Analyzer

Problem Statement Language

Request for Proposal

Real Time Executive

Software Support Environment

Software Production Facility

Software Requirements Engineering Methodology

Structured Analysis

Space Station Data Systems

Software Technology for Adaptable and Reliable Software

System Requirements Engineering Methodology

Technical Management Information System

187
3.5.3 System Test, Integration and Verification

Successful acquisition and operation of any large project is critically

dependent on its Test and Verification plan. This plan provides the test

sequences and requirements for all levels of hardware and software

development/integration to insure the operational effectiveness and

suitability of SSOS ground and flight systems. Test and verification on

flight hardware of the typical space program is generally extremely

conservative and intensive; however, the Space Station program has the

opportunity to follow a less conservative and more cost-effective approach.

This does not imply a lack of rigor to insure initial achievement of the

operational system; but concentrated implementation of standards, commonality,

and fault tolerance techniques coupled with the on-orbit accessibility of the

flight system will allow consideration of some significant schedule and cost

savings options.

Within the traditional "high reliability" program, acceptance tests,

(including mission derived environmental and "burn-in" screens) are liberally

applied to all hardware from piece parts through assembly (black box) level in

order to expose faulty components, processing and workmanship. Special test

equipment including mounting fixtures, cabling, etc., is required to support

these various levels of tests along with a set of comprehensive functional and

environmental test software: Ground hardware is generally subjected to less

comprehensive testing without environments because of its accessibility and

its benign handling/operation environment. Software products are subjected to

comprehensive "verification and validation" testing that begins at the module

level and progresses through module integration and system level tests.

Hardware qualification (acceptance profiles plus margin) testing is performed

on initial production Flight assembly samples to insure hardiness of the

production h_rxJware. These qualification units are generally dispositioned as

"non-flight' since their exposures represent lO0_ of the assembly demonstrated

fatigue life and because such hardware is useful in supporting software

development, special testing, etc.

189
Verification is that effort (test, demonstration or analysis) performed to

insure that the system, with all its hardware and software components;

complies with its design requirements. Whenever feasible, hardware

verification is distributed down to the subassembly level to provide early

exposure of deficiencies and minimize cost and schedule associated with their

corrective action. Similarly, the software verification is initiated at the

module level. Verification activities that do not coincide with acceptance

testing are necessary only on the initial hardware/software set.

The final activity is that of system(s) integration which is performed

(1) to insure compatibility between all subsystem and system hardware and

software interfaces, including payload interfaces, and (2) to complete the

verification of the system design and performance requirements. (Note that

this document is generic in the sense that it does not address the onboard

Space Station 0ata System (SSOS) interface and interaction with any specific

subsystem or payload. All tests, integrations, verifications, and interfaces

are intended to apply to all functions of all subsystems and payloads.)

Review of potential test and evaluation scenarios for the SSOS ground

segment indicates that its acquisition phase will follow traditional flows

therefore no options will be discussed. In contrast, the Space Station

represents a departure from the typical space project in that:

o the Station will be assembled, activated and upgraded on orbit,

o the Station is less sensitive to subsystem total weight, thus

mechanical strengths of enclosures, etc., can be designed to meet the

mechanical environments,

o the Station has no critical, real-time operations required during

ascent, re-entry, etc., but only in the remote event of life

threatening or major damage situations, thus a higher level of faults

can be tolerated,

o the Station will be manned so that hardware replacement, repair, and

reconfiguration will be a primary capability,

o the Station will have the capability to modify/upgrade software

on-orbit,

19o
0 the Station will have several different levels of criticality in both

hardware and software, thereby allowing for the possibility of some

verification to be completed on-orbit.

These factors stimulate a number of options to the normal acquisition and

growth phase for the onboard SSDS that can result in meaningful schedule and

cost savings.

3.5.3.1 Test Options

3.5.3.1.1 Description

There are three areas in the testing (pre-system integration) sequence

where deviations from the traditional test sequence offer significant cost

savings with manageable risk. The first option addresses the elimination of

selected testing at the lower hardware levels based on test sequences of

subsequent levels. The second addresses the elimination of selected

environmental tests based on their marginal effectiveness and the third

addresses the modification of qualification testing to accommodate

protoflighting.

Specifically, these identified options are:

o Deferred Module Testing

o Selective Environmental Testing

o Modified Qualification Testing

3.5.3.1.2 Options Characterization

Deferred Module Testing

The typical waterfall hardware test and evaluation sequence performs

acceptance testing at each level of hardware. Modules (Circuit Card

Assemblies, etc.) are subjected to comprehensive functional and environmental

191
screens to expose production problems and move the hardware further along the

reliability curve. Considerable effort, in time, special test equipment,

adapters and software are required to support this effort, with attendant

costs, yet subsequent failures are not precluded.

With the limited production quantities of the Space Station, the costs

(particularly non-recurring) of these tests will be significant. A viable

option would be to defer the module (card level) testing until the next level

(subassembly or assembly). Additional inspections plus utilization of high

pedigree (rescreened?) components will minimize any added risk. A coherent,

hierarchial built-in-test (BIT) scheme is anticipated for the SSDS

hardware/software products. In such a scheme, higher level assemblies will

monitor responses of the lower level modules to the normal or background

diagnostic stimuli. Anomalous data will be captured as required and the fault

incidents will be flagged to the next higher assembly level. The BIT

capabilities will be verified early in the integration sequence using module

simulation in order to gain the required confidence in their operation. The

BIT will then become a verification tool at all subsequent levels of

integration/verification providing adequate checkout of the modules.

The advantage of this option would be the elimination of special module

fixturing and software development costs plus the individual test time; the

disadvantage would be the potential of failures at the subassembly and

assembly level which would net out to the disassembly and reassembly time

required for the module repair/replacement time.

Selective Environmental Testing

As indicated previously, the typical "high rel" test sequence performs

thermal environment (temperature-altitude and/or temperature-cycling) testing

at several levels of hardware build-up. The justification is the accelerated

exposure of component, material or workmanship faults that would normally

occur during operational life. A viable option would be to perform thermal

environmental testing only on the qualification unit to verify the hardware

material and fabrication processing tolerance to thermal environments. The

random failures of other production units would be acceptable within the

framework of the Station fault tolerance requirements.

192
The advantages of this approach would be reduced testing, documentation

and manpower; the disadvantage would be the reduced opportunity to expose

hardware faults prior to utilization.

Modified Qualification Testing

Hardware qualification testing is generally performed on the first

production units of an assembly (black box) as representative samples of the

components, materials and fabrication processes. This testing demonstrates

capability envelopes to establish a high confidence that, with a typical

distribution of component and workmanship quality, subsequent production units

will meet acceptance and mission requirements. These "qual" units are

normally dispositioned as "non-flight" since they have expended 100% of the

demonstrated environmental fatigue life and they have been subjected to the

exceptional handling required for the qualification sequence, mechanical,

thermal environments, EMC, etc. With the relatively small production runs on

some of the SSP equipment, however, non-flight hardware may represent a large

percentage of the production run costs.

The modified qualification test option would retain the flight status of

this protoflight hardware by subjecting it to less than the traditional

qualification levels/durations such that confidence in "the fleet" is

established yet the risk of failure during subsequent operations is low. For

example, the +6 dB qualification levels could be performed, but only for

acceptance test durations. Also, the fact that the Space Station is not

subjected to the usual external environments of ascent, re-entry and landing,

mitigates the normal qualification levels. The various launch packages must,

of course, be boosted to the assembly orbit however the hardware packages will

generally not be operational during the ascent and can therefore be specially

packaged/handled to significantly reduce the launch environments. The risk

may be reduced further by applying "over-design" factors and also by

performing additional confidence activities (open box inspections, etc.)

following the qualification sequence. In some cases, the "over-design" factor

may be sufficient such that qualification can be by analysis rather than

testing.

193
The advantage to this approach is the reduction in production hardware

cost. The disadvantages are (1) normal full confidence in production hardware

could not be achieved by demonstration, (2) capability to assess production

unit fatigue life would be limited, and (3) no production workhorse unit would

be available for use in troubleshooting, special tests or mockups.

The issue of protoflighting/non-flight units must be carefully evaluated for

each equipment type with appropriate weighting applied for:

the Local Area Networks (LAN) could greatly facilitate this distributed

effort. Final integration of the onboard SSDS is therefore dependent of the

integration activity of the overall Space Station.

o the degree of commonality achieved (the number of unique hardware

configurations,

and,

o the hard requirements for non-flight elements.

NOTE: Software testing is covered in the Software Development Plan.

3.5.3.2 Integration Options

3.5.3.2.1 Description

It is anticipated that the hardware and software products for the onboard

SSDS (excluding application software for payloads) will be the responsibility

of NASA or a single support contractor (or contracting team). These products

will be procured (built or bought), tested and integrated into the individual

assemblies (black boxes) of the onboard SSDS. In this development effort, the

contractor will utilize the SSP developed test beds and other simulation and

test facilities in order to perform the interface compatibility and

performance verification of the individual assemblies.

194
In addressing the integration options for the onboard SSDS, it must be

acknowledged that this is not a stand-along system; it will be installed into

elements (modules and structures) of the overall Station that will be

developed in geographically separate locations. The nature of the designs of

the Normal Operation System (NOS), the Data Base Management System (DBMS), and

the Local Area Networks (LAN) could greatly facititate this distributed effort

Final integration of the onboard SSDS is therefore dependent of the

integration activity of the overall Space Station.

The Station integration testing will be the single most expensive

operation of the test and evaluation sequence because of the complexities of

set-up, hardware and software problems on both the SSDS and supporting test

equipment. Difficulties will arise from sheer magnitude of the system, the

total coordination required, and the need to simultaneously satisfy all the

facility and test equipment requirements. The basic options therefore relate

to the degree of integration and the location of the integration/verification

effort.

The options associated with the integraiton effort are:

o full integration at a central facility

o a segmented, serial integration effort

o on orbit integration

3.5.3.2.2 Options Characterization

Full Integration at a Central Facility

This options addresses the traditional approach of performing the overall

integration and verification at a central facility. The approach would have

all SSP elements, payloads, modules, station structural, and assemblies

shipped to the central facility for Full IOC station integration performed

within the limits of the Ig environment. This test would also utilize special

TDRS system configurations/operations to provide a communication interface

between the assembled station and TDRS.

This central facility could be located at a contractor's plant or at any

one of several NASA installations. The major advantages and disadvantages of

195
full integration at a central facility are basically the samewhether at a

contractors or at a NASAfacility. Of major importance is the geographical

location of the facility, considering material transportation costs, personnel

resources required for TDYsupport, and facilities availability.

This approach provides the primary advantages of:

o a comprehensive verification of the station in its assembled

configuration

o a common point of coordination for problems involving multiple

contractors

o a high degree of pre-launch confidence in the IOC station

o an opportunity for the crew to experience the integrated capabilities

of the actual IOC system

o a tool to support on-orbit operations, modifications,

troubleshooting, etc.

The disadvantages are:

o high planning/schedule cost

o the test is difficult to perform, inefficient to manage and therefore

costly

o new facilities will be required

o expensive special handling/cradling equipment will be required

o large support contracts for personnel and equipment required

o transient on-site NASA and support contractor staffing will be

required

o test failures could result in excessive delays

o all elements may not be available at the same time

Segmented, Serial Integration

As noted in the previous option, large integration efforts tend to be

inefficient and therefore expensive due to the requirements to simultaneously

manload and provide facility/equipment support for all involved elements. A

viable option would be to perform a series of smaller integration efforts.

There appears to be sufficient segmentation and available physical interfaces

within the Station such that the integration could be performed in a more

piece-meal fashion; i.e., interconnection and checkout of only one to two

196
modules with its onboard SSDS equipment at a time. Systems simulation will be

available in sufficient fidelity to support these smaller integration packages

through substitution of missing elements/interfaces. The requirement to

intermate and verify the interfaces of each station element would be satisfied

by a staggered sequence of the segmented integration.

This option has inherently more schedule flexibility since only a fraction

of the integration effort is affected if one SS element fails. The

acquisition phase may in fact be designed to take advantage of the Station

"build-up" sequence; i.e., elements for the final launch package may not be

ready for integration when the early packages are being assembled on orbit.

Another consideration for the segmented integration is the required

interface compatibility and performance support of institutional resources,

TDRSS and the Data Distribution Network, etc. These resources will have a

limited availability for these tests and must be scheduled in advance. These

constraints would be more easily accommodated within the segmented format

proposed by this option.

Full assembly of the SSP elements (modules and structure) will not be

performed in this approach, however through the use of CAD techniques and

designed in mechanical flexibilities, the risks levels should be acceptable.

The advantages of this option would be:

greater flexibility and less schedule impact from detected

incompatibilities

less handling and fixturing equipment requirements

small work force requirements

shorter on-site durations for support personnel

The disadvantages are:

0

O

possibly more simulation software required

higher risk for on-orbit success

197
On-Orbit Inteqration

For this option, outfitting/integration of the Station modules would be

followed only by a module checkout during ground testing. This checkout,

supported by the Space Station system simulation would verify only the general

module capabilities. Performance testing, will have been demonstrated at the

subsystem level utilizing SS simulation and test facilities. Module/structure

interfaces will be mated to insure physical compatibility followed by brief

operation tests to verify functionality of power, thermal, fluid, network and

logical interfaces. Following module testing, the Station elements will be

assembled into their respective launch packages for pre-launch integration and

checkout. Full station integration/verification will occur on orbit.

The advantages of this approach are:

0

0

0

reduction of integration facilities, fixtures, etc.

reduction of integation manpower, documentation, schedule

provides a more serial operation that is compatible with the buildup

sequence

The disadvantages of this approach are:

0

0

0

0

higher risk during on-orbit integration

first integrated end-to-end performance checks on orbit

most severe penalty for integration detected incompatibilities or

deficiencies (includes wait period until next STS flight)

no crew exposure to actual system operation on ground

3.5.3.3 System Verification Options (IOC)

3.5.3.3.1 Description

In the traditional system, hardware and software verification is a

distributed effort, performed as early as possible during system development

such that there is a high confidence when the final prelaunch integration/

verification is performed. Consistent with this conservatism is the

198
independent verification/validation of critical system software. The

incentive to substantially reduce acquisition phase costs of the Space Station

leads to options to:

o minimize system level verification

o eliminate independent software verification/validation

3.5.3.3.2 Options Characterization

Minimized System Level Verification

It is anticipated, if not given, that the development environment for the

Space Station will be rich in simulation and development tools including the

end-to-end models and test bed capabilities such that each contractor can

develop and comprehensively verify hardware and software at the subsystem

level. Detailed verifications of hardware signal characteristics (signal

levels, frequencies, etc.), BIT and fault-tolerance operation would be

performed as predefined in an overall system test and verification plan. When

completed, each verification item would be mapped onto appropriate data bases

within the TMIS to provide current visibility on the system verification

status. Within this option, only residual performance verification would be

performed during the final integration tests. This residual testing would be

limited to overall functional capabilities with their timing requirements to

validate the accumulation of tolerances allocated to the individual

subsystems. Detailed subsystem hardware functional and fault tolerance/

redundancy testing other than power up and BIT diagnostics would not be

performed. Neither would "programmed failure u tests be performed to

demonstrate system operability/recoverability to hardware/software

discrepancies.

The advantage of this option, would be the obvious scope reduction of the

integration testing, while the disadvantage would be the lack of repeated

detailed testing to insure that there have been no performance shifts as a

result of transportation damage, or the integrated environment. Also, there

would be no opportunity for contractors/crew to experience system level

responses to induced failures.

199
Elimination of Independent Software Verification/Validation

Within the typical large space project, outside agencies have been

commissioned to review software specifications and perform an independent

verification/validation of the generated code. This activity is intended to

provide an objective review and test of the software without the designer

"biases" This option proposes to eliminate the independent review. Instead,

the normal sequence would be followed wherein software designers would fully

verify individual modules and integrated programs then pass the programs on

for system validation. The software would support the system integration

process in either case, however the risk of redesign, recoding operations and

residual (post integration) errors may be higher. The corrective action for

such errors could be significant if PROM components must be reworked in

addition to the recording, and recompiling activity.

The advantage of this option is strictly cost; the disadvantage is the

increased risk of design/coding errors detected at the system level.

3.5.3.4 Integration Options (Growth)

3.5.3.4.1 Description

The growth phase presents an additional complexity and potential risk

since the actual station hardware will not be accessible. The available

options for the growth phase relate to the degree of risk mitigation

activities performed prior to the final on-orbit integration. The growth

hardware/software products will be contractor supplied to NASA with full

design/performance and interface compatibility verification completed. The

options range from a comprehensive pseudo-integration in a high fidelity

system mock-up/simulator and/or use of the TDRSS link to the Space Station to

a very limited checkout that only demonstrates interface compatibility

utilizing crude mockups, fixtures and available simulation facilities. These

options may depend somewhat on the magnitude, complexity, criticality of the

integration effort. A small set of non-critical assemblies and/or software

packages, for example, could be installed, integrated and checked out serially

on the station, with little concern for impact to system operation. A more

critical hardware/software package, or critical payload, may dictate

additional ground "integration" testing.

200
These options are:

o intensive ground integration

o minimal ground integration

3.5.3.4.2 Options Characterization

Intensive Ground "Integration"

In this option, the hardware and software products will be fully checked

out using a high fidelity mockup/simulator, a replication of the station built

essentially from production hardware, or use of the TDRSS link to the Space

Station. This approach, of course, relies on the availability of these

facilities/tools (see section 3.5.3.6).

The testing sequence would install the hardware in the mockup, perform its

power up, and BITE diagnostics, load its applicable software (as requied) then

perform appropriate set of system diagnostics to verify the physical

attributes and performance of the growth products. The advantages would be a

high confidence in the effectiveness and compatibility of the products and a

high capability for evaluation team (ground and orbital crew) to gain

operational experience. The disadvantages are primarily the cost/schedule

impacts of developing and maintaining the high fidelity simulation and the

additional effort to perform the extensive ground checkout.

Minimal Ground Pre-Integration

In this option, the products are merely (re-)checked for interface

compatibility utilizing a minimal set of test fixtures, crude mockups, and the

resources of the Software Support Environment to validate the software.

The advantages of this approach are the basic economics of the sparse checkout

equipment requirements and the reduction of the ground activities. The

disadvantages are the higher risks of successful integration.

201
3.5.3.5 Integration Options (Man-tended)

3.5.3.5.1 Description

The man-tended option is assumed to be a 3 to 5 year interval that delays

the continuous manned presence in the IOC Space Station. The buildup of the

man-tended reference configuration could use the same initial launch sequence

as that proposed for the manned Space Station, with two exceptions: in

Flight 3 the man-tended system would have laboratory module delivered rather

than a habitat module, and it would have one airlock rather than two.

Flight 4 would deliver the externally mounted payloads and supporting

structure for payload mounting. The man-tended configuration would then be

operational.

The man-tended option will have many similarities, in both hardware and

software, to the manned IOC reference configuration. However, further

definition is likely to identify some required differences, such as an

expanded use of Automation and Robotics (A&R) for both Payload support and

Space Station housekeeping. Also, the fact that crew members will not be

continuously present means that less time will be available for the checkout

of those non-critical functions that may have been intentially deferred from

the pre-launch checkout.

The need for intensified ground controlled functions will have an effect

on the SSIS, primarily in the amount of manpower required at the ground

station.

The man-tended option definition must also include the planning for the

transition to a permanently manned configuration.

3.5.3.5.2 Options Characterization

The integration options for the man-tended configuration are not

dissimilar from those for the manned reference configuration discussed in

Section 3.5.3.2. The on-orbit integration option discussed previously may have

2o2
an added disadvantage of a longer elapsed time to complete the on-orbit

integration depending upon the parameters of NSTS crew size, length of stay

time, and the Frequency of revisits.

The man-tended version presents an additional option concerning Payload

accommodations, in that the crew support capability will be seriously

curtailed.

0

0

Forego the accommodation of those payloads requiring crew intensive

support

Increase the use of expert system technology and A&R to service those

payloads, with the attendant increase in hardware and software

complexity and integration resources.

3.5.3.6 Facilities Options

Large projects associated with flight hardware generally beget large

facilities for the purposes of H/W development, S/W development, System

Simulation, Systems Integration, and Training that are distributed across the

sites of the prime contractors, the project control center and the launch

centers. Although these facilities and associated equipment are

comprehensively planned to support the project in an efficient and cohesive

manner, final configurations generally surpass expected costs and functions

are often duplicated (not replicated) or overlapped in several locations.

Such facilities have served their purposes well but at high cost.

A set of Space Station facilities must serve the same functions, however,

with the projected minimal funding, more cost effective approaches must be

employed.

3.5.3.6.1 Software Support Environment

A software support environment (SSE) system is a given that must

provide the normal development and analysis tools, with supporting data base

and configuration management functions, etc. In addition, the system software

2O3
simulation will be housed by the SSE. Clearly, there will be simultaneous

demands by a large number of users and the facilities options must address

whether this system will be a centralized facility with local and

telecommunications access or whether a distributed or hybrid system would be

more serviceable and cost effective. These issues have already been

comprehensively discussed within the "Software Devel-option" options category

and will not be reiterated here.

3.5.3.6.2 Hardware Development

3.5.3.6.2.1 Description

Hardware development of the Station subsystems will be a concurrent effort

at many separate contractor locations. The development must be supported by a

number of tools and capabilities to allow contractors to perform early

verification of interface and performance compatibility with the overall

system. These tools could be distributed (individualized) in the form of

fixtures and adapters supported remotely by the SSE or a centralized,

relatively high fidelity system (or hybrid) could be provided. The options

are therefore:

o

o

Distributed capabilities

Centralized capabilities

3.5.3.6.2.2 Options Characterization

Distributed Capabilities

As the preliminary designs are developed, contractors will need to

evaluate their products in terms of compatibility and performance and in some

cases will need to develop access and routing options for their equipment.

Interface evaluations including mating, signal level, timing and protocol

compatibility could be supported by interface fixtures with adapters remotely

driven from the systems simulation capability of the SSE. This capability

2o4
assumes the availability of a remote work station(s) or MPAC's at the

contractor site to schedule and control the SSE configuration. This full

capability work station/MPAC would also be used to: interface the TMIS,

access the SSP data bases to update program documentation and status, etc. The

fit checks, routing and access evaluations would be performed on mockups that

provide dimensional accuracy only for access, supports and mounting surfaces.

The advantages of this distributed approach would be the relative

independence of the contractor (except perhaps the scheduling conflicts for

the system simulator) and the immediate accessibility of the SS support

capabilities without travel or transportation requirements. The disadvantages

would be the quantities and control of fixtures, adapters and mockups to be

used by the contractors. Each item must be under configuration control, thus

system changes could be reflected into a continuous flow of rework and

modifications at the contractor or NASA site.

Centralized Capabilities

For this approach a centralized hardware development facility would be

provided that would not have the fidelity/capability of the SAIL for example

but will be sufficient to allow installation of hardware products for ground

integration/evaluation. Relatively high fidelity mockup(s) of the Space

Station would be provided that are semi-operational in that appropriate

fixtures would be pre-integrated to allow remote support by the SSE system

simulator. The mockups will be segmented such that several independent

activities could be simultaneously supported. This facility, most likely

located at the NASA SE&I center, would be used to evaluate all intercontractor

interfaces in addition to allowing each contractor to perform the normal fit

checks. This capability will be supplemented by the NASA test beds available

to test and evaluate DMS concepts, fault tolerance concepts, etc.

The mockups would also support preliminary mission definition and some

crew training.

2O5
The advantages of this approach would be the tighter configuration

management of the mockups and a higher visibility of potential incompatibilities between contractors. The disadvantages would be the travel and

transportation requirements for each contractor.

3.5.3.6.3 Test Beds

Test beds represent those NASA facilities that are or will be used to

explore or validate design concepts. They will be available to contractors in

support of any advanced development, however, it is not clear that they will

play a role in the downstream development either during acquisition or the

growth phases. To do so would detract from their role in advanced development

and would require them to fall under the purvue of external configuration

management and quality control functions. Their value may be somewhat limited

to a specific design production when the facilities planned for the Space

Station should accommodate any assembly or subsystem integration/verification.

3.5.3.6.4 Integration Facilities

Integration Facilities are discussed in Section 3.5.3.2.

3.5.3.6.5 Training

Flight crew training will involve the following areas:

0

0

0

Station operation and maintenance

payload operational support

Station habitation

A large part of this training for each of these areas will involve

utilization of the fixed and portable MPAC's which will be available in

quantities in all facilities. For training purposes, these MPAC's will be

driven by the SSE to simulate the tasks of station and payload support in both

normal and "failure" operational modes.

2o6
Another segment of training will be devoted to maintenance, repairs, and

removal/replacement of equipment from structure and modules. This training

effort could be accomplished via the detailed mockups of the Hardware

Development Facilities in conjunction with equipment supplied by contractors.

Separate training facilities for the DMS oriented functions could be provided;

however, it is anticipated that the commonality between space development and

test capabilities and the actual system capabilities will minimize the need

for such special facilities.

Training for payload operations, zero-g environments, etc., that are not

associated with the DMS are not applicable to this paper.

Tables 1 through 6 provide summaries of the options discussed above along

with a tabulation of their advantages/disadvantages.

207
c/I

==

0

I--.

0.

C_

l---

ILl

I'--

i,mI'--

if.&.l...i

•---,._I I--"

_14J

CD" I--

i

l'--

m=

Whl

0

i.J

0

Z_

.-..0

U

0_..;

O.-._

r,J "-_

rm_ _,..

Z

0

I"

U.J C:C

'_ZW

la.ll-- _.

u i/j u _-

ey- i i i

,-_ ,4

--J

,-., 1.6

Z

I.-- O_

'-r-

!_, ,ll

:DO

I_),(

e

LL ."_ _,_

Z

0

I-,-

.e

u_

,.',

_._L

C,._ ,..J

I_I laJ

I_I_ O_ ""

-- ,4 ,4 -: ,4

S3_V.LNVAOV

2O8

539V.LNVAQVSXO
0

l---

_L

0

0

-q

2

u.l

--JZO

0o

t

535VINVAOV

,,; _ ,-:

2O9

$39VZNVAQVSIQ
Q

t-.-

Z

O

l,--

If.

L.J

I"

I"

-z

uu.' "_"

tJ

-uJ _

"

,,J_ °

_ F..- uJ

_ CJP-

',J_ _LmJ

I"- 3_3VJ.NVAQV

=..,

QI--

(.,.) v1

e-_w

t.,_[_"zLAJI--"

I'--

Q

V'_ l"

t'--'

"" Q t._t

Z W

_W QW

Z W

,..:

39¥.LNVAQV$IQ

210
i--I

0

0

to.

0

z

o

I--

c_

I--

z

t-i

I--

2_

I--

b-0w

2_1--

,-4 Z

EI--_

2_

0

r_

0

I_P-q

z

0

Q.

z

w

t.4J

0-q Z

.J I.iJ Ix

L_Pww I_

0 w

I-- a._

I._ t--0 a. &._l

M.._ zl--

$]gVJ.NVAQV

_._

u.

0

,.2

0

w

_>--

h LIJ I"

0,.-_

0 _" _..._ X

539V.LNVAOVSIO

211
f"Z

,,,-,,

w

la6J

t--

!

,...,

6.,I

Q

I--

z

I--

,..,.

t.aJ

t--

:.=o

m O tt,,,,,.O

t,. t,-,0 e"_

< t-" 0

'-QO

Z_ "l-

.- t,,J Q

_ I-- LL_

,.,.,_

0-,4 t--

,=.. ,,,-,,

,,-4Q

t.-t ..l

,,.J t2.

Z

0

t-"

Q

!0.=., ,...

,.-,_

t,/'b W

.--J¢_

._=:

_L,iJ

_z

Xo-.4

z

I--

I.mJ

Q

U.

w

>- I'-

x=,: >"

w_

..j _.._ _.m

m.m. ,,_

m_ L,mJ 0

S39VJ.NVAOV

,.o,

I'm .

>-o

_J ,,--t

0 ""

_m

W_6.

pm _.._

z

212

$3gVLNVAQVSXO
vt

O

I--I

1--

O

v)

I.iJ

I--

..I

(J

,<.

f..

I--

L.!

t"

..I

":E

_L

":C

(.J

LIJ

N

..I

I--"

Z

I.i.I

Vl

laJ

I'--

I--I

cz.

P,

I.i.I

I--

I---

vt

O i

,.=,

_L

I=C ...I t--t_l

r_,._ e..4 ,-_ r-t

_(_ .--I I--- Z

r_,._ e-4 o.._ c:C

_-4 O.. _._J

_-._ =,=., '-'5"

,.= _= N,.,

,.=, ,.:,o =- -=

$3_.'.'JV.LNVAQV

QI--

I--._

c:{E

I-- J--

,'_Z

QQ

r'L (.3

C::U

I.. L._

Ze

,_.J

....it*.,"

j-.

w

O0

,_=E:

.1--

_j.,-

o

J,l. 1_

,_eed

539VZNVhQVSZQ

213