D180-27935-2 ••

' - - . - • V

SPACE STATION SYSTEMS TECHNOLOGY STUDY

Final Report

VOLUME E .

TRADE STUDY AND TECHNOLOGY SELECTION,

TECHNICAL REPORT

D180-27935-2

Conducted for NASA Marshall Space Flight Center

Under Contract Number NAS8-34893

February 1984

Boeing Aerospace Company

Spectra Research Systems
D180-27935-2

FOREWORD

The Space Station Systems Technology Study (Contract NAS8-34893) was initiated in

3une 1983 and to be completed in April 1984. The study was conducted for the National

Aeronautics and Space Administration, Marshall Space Flight Center, by the Boeing

Aerospace Company with Spectra Research Systems as a subcontractor. The study final

report is documented in three volumes.

D180-27935-1 Vol. I Executive Summary

D180-27935-2 Vol. H Trade Study and Technology Selection Technical

Report

D180-27935-3 Vol. m Technology Advancement Program Plan

Mr. Robert F. Nixon was the Contracting Officer's Representative and Study Technical

Manager for the Marshall Space Flight Center. Dr. Richard L. Olson was the Boeing

study manager with Mr. Paul Meyer as the technical leader, and Mr. Rodney Bradford

managed the Spectra Research Systems effort. A listing of the key study team members

follows.
D180-27935-2

TABLE OF CONTENTS

VOLUME H

Page

1.0 INTRODUCTION 1

2.0 ATTITUDE CONTROL 5

2.1 Introduction 5

2.2 Approach 8

2.3 Technical Discussion 13

2.4 Summary of Results 36

2.5 Conclusions 37

2.6 Recommendations 37

2.7 References 38

3.0 DATA MANAGEMENT 40-.

3.1 Introduction

 4P

3.2 Approach 40

3.3 Technical Discussion 43

3.4 Summary of Results 58

3.5 Conclusions "•

 69

3.6 Recommendations 70

4.0 LONG-LIFE THERMAL MANAGEMENT 74

4.1 Introduction 74

4.2 Approach 74

4.3 Technical Discussion 75

4.4 Summary of Results 121

4.5 Conclusions

 v 121

4.6 Recommendations 123

5.0 INTEGRATION OF AUTOMATED HOUSEKEEPING 125

5.1 Introduction 125

5.2 Approach 125,

5.3 Technical Discussion 139

5.4 Summary of Results 178

5.5 Conclusions 180

5.6 Recommendations 180

111
D180-27935-2

LIST OF FIGURES

No. Page

1.0-1 Program Schedule 3

2.2-1 Space Station Balanced Array Concept With Astronaut Solar 9

Array Deployment

2.2-2 Buildup Sequence Defining Configuration for Control/Structural 9

Analysis

2.2-3 Software Architecture Technical Approach for Dynamic Simulation 12.

Analysis

2.3-1 Modal Reduction Structure Model by Impulse Energy 12

2.3-2 Normal Mode Shapes and Frequencies for Modes In Truncated Model 18

2.3-3 Second Bending Mode 20

2.3-4 Two Axis Parallel Mounted GMG's for Space Station 20

2.3-5 Disturbance Model for Crew Activity 22

2.3-6 Generic Block Diagram for Altitude Regulator for a Flexible 23

Structure

2.3-7 Measurements of Flexible Elements for Reference In Time Histories 25

2.3-8 Orbiter Docking To Space Station Showing Preferred Configuration 25

2.3-9 Open Loop Response To 1000 N-M-Sec Impulse Doublet In Pitch 26

for Configuration 1

2.3-10 Open Loop Response To 1000 N-M-Sec Impulse Doublet In Roll 26

for Configuration 1

2.3-11 Open Loop Response To 1000 N-M-Sec Impulse Doublet In Pitch 27

for Configuration 2

2.3-12 Open Loop Response To 1000 N-M-Sec Impulse Doublet In Roll 28

for Configuration 2

2.3-13 Impulse Response (arc-sec) of Configuration 1 to Docking Load of 2500 29

Newtons at Body Station 1201

2.3-14 Closed Loop Response To 1000 N-M-Sec Impulse Doublet In Pitch 30

for Configuration 1

2.3-15 Closed Loop Response To 1000 N-M-Sec Impulse Doublet In Roll 31

for Configuration 1

2.3-16 Closed Loop Response To 1000 N-M-Sec Impulse Doublet In Pitch 34

for Configuration 2

IV
D180-27935-2

LIST OF FIGURES (Continued)

No. Page

3.1-1 Data Processing, Storage, and Communications Requirements 41

3.3-1 Fiber Optic Backbone Network 45

3.3-2 Multi-Star vs Graph Topologies 48

3.3-3 Transmitter Block Diagram 50

3.3-4 Receiver Block Diagram 51

3.3-5 NIU: Internal Organization 53

3.3-6 NIU: Functional Partitioning -55

3.3-7 Network Operating System Example 56

3.4-1 Criticality of Technologies 64

3.6-1 DMS Closed Loop Simulation 72

4.3-1 Heat Transport Systems 77

4.3-2 Pumped Two-Phase Bus Sizing 80

4.3-3 Optimized Pumped Two-Phase Ammonia Bus Pressure Drop and Pumping 81

Power

4.3-4 Pumped Two-Phase Bus Weight for Optimized Liquid and Vapor 82

Line Sizes

4.3-5 Optimized Capillary Two-Phase Heat Transport Loop (Ammonia-High 84.

Temperature)

4.3-6 Optimized Capillary Two-Phase Heat Transport Loop (Ammonia-Low ,85

Temperature)

4.3-7 Pumped Liquid Loop Weight for Optimized Line Size 86

4.3-8 Heat Exchanger Models 88.

4.3-9 Heat Transport Loop/Radiator Interface 93

4.3-10 Radiator System Weight for Two-Phase Bus 95

4.3-11 Radiator System Weight for Liquid Loop 98

4.3-12 Two-Phase Bus/Water Loop Interface 99

4.3-13 Pumped Liquid Loop/Water Loop Interface 102

4.3-14 High Temperature Two-Phase Ammonia System 105
D180-27935-2

LIST OF FIGURES (Continued)

No. Page

4.3-15 Two-Phase Ammonia High Temperature System Schematic 106

4.3-16 Low Temperature Two-Phase Ammonia System 107

4.3-17 Two-Phase Ammonia Low Temperature System Schematic 108

4.3-18 Pumped Liquid Loop (Feon 11 With 80°F Rad Inlet)

 109

4.3-19 Pumped Liquid Loop (Ammonia With 80°F Rad Inlet) 1 1 1

4.3-20 Optimized Total System Weight for Pumped Liquid Heat 112

Transport System

4.3-21 Pumped Liquid Freon-11 System Schematic H3

4.3-22 Pumped Liquid Ammonia System Schematic 1 14

4.3-23 High Temperature Two-Phase Ammonia Bus With Two-Phase 1 16

Water Loops

4.3-24 Effect of Two-Phase Water Heat Transportation System on High 1 17

Temperature Bus

4.3-25 Low Temperature Two-Phase Ammonia Bus With Two-Phase H8

Water Loops

4.3-26 Effect of Two-Phase Water Heat Transport System on Low 1 19

Temperature Bus

5.3-1 Schematic for Space Station Life Support Subsystem

5.3-2 Interactions Which Affect Housekeeping Functions 143

5.3-3 Interfaces Between an Integrating Controller and Automated 145

Housekeeping Subsystem

5.3-4 Functional Block Diagram for Electrical Power Load Manage- 147

ment by an Integrating Controller

5.3-5 Functional Block Diagram for Materials Transfer Management 151

by an Integration Controller

5.3-6 Functional Block Diagram for Inter-Subsystem Failure Isolation 153

Using Integrating Controller

5.3-7 Functional Block Diagram for Inter-Subsystem Redundant Path

 154

Selection by an Integrating Controller

5.3-8 Functional Block Diagram for Maintenance Schedule Management 156

by an Integrating Controller

Vli
D180-27935-2

LIST OF FIGURES (Continued)

No. Page

5.3-9 Functional Block Diagram for Startup Integration by an 158

Integrating Controller

5.3-10 Processing Functional Diagram of Integrating Controller for 162

Automated Housekeeping

5.3-11 Air Regeneration Unit Diagram 166

5.3-12 Input Processor Concept 168

5.3-13 Trade of Integrating Controller Functions 172

Vll
D180-27935-2

LIST OF TABLES

No. Page

2.3-1 Flexible Element Selection and Material Properties for Space 14

Station

2.3-2 Mass Properties of Space Station 16

2.3-3 Internal Disturbance 24

4.4-1 System Weight Comparison 122

5.1-1 Space Station Autonomy/Automation Philosophy 126

5.2-1 Functions for Housekeeping Controllers .127

5.3-1 Electrical Power Subsystem Automation . 129

5.3-2 Life Support Subsystem Automation 130

5.3-3 Thermal Control Automation 137

5.3-4 Example of Load Priorities 148

5.3-5 Example of Criteria for Functional Criticality 149

Vlll
D180-27935-2

LIST OF ACRONYMS AND ABBREVIATIONS

ARPANET

APSTS

Advanced Research Projects Agency Network

Advanced Platform System Technology Study

BAG

BIT

BTU

Boeing Aerospace Company

Built in test •

British thermal units

CADMS

CAE

CAMPS

CCD

CELSS

Cg

CMC

CO2

CPU

CRT

Communications and data management station

Computer aided engineering

Construction and material processing station

Charge coupled device

Controlled ecological life support system

Center of gravity

Control moment gyro

Carbon dioxide

Central processor unit

Cathod ray tube

dc/ac

deg/sec

DMS

Direct current/alternating current

Degrees per second

Data management system

EASY

EVA

Engineering Analysis System

Extra vehicular activity

ft feet

GL/EP

GR/EP

Glass/expoxy

Graphite/expoxy

HR

H20

Hz

Hour

Water

Hertz (a measure of frequency)

IX
D180-27935-2

IAC

1C

I.D.

IEEE

INDA

I/O

IOC

Integrated analysis capability

Integrated circuits

Inside diameter

Institute of Electrical and Electronic Engineers

Interface from NASTRAN dynamics analyzer

Input/output

Initial operational capability

rise Johnson Space Center

KG

KW

Kilograms

Kilowatts

LAN

Ib

Ibm

LED

LIOH

LISP

LOARS

Local area network

Pounds

Pounds-mass

Light emitting diode

Lithium hydroxide

List processor

Land, ocean, and atmospheric research station

MBPS

MCR

MHz

MIL-STD

MIPS

MSFC

NASA

NASTRAN

NIU

n-m-sec

NOS

ns

Million bits per second

Martin Company Report

Megahertz

Millitary standard

Million iterations per second

Marshall Space Flight Center

National Aeronautics and Space Administration

NASA Structure Analyzer

Network interface unit

Newton-meter-seconds

Network operating system

Nanoseconds (10-9 seconds)
D180-27935-2

O.D.

ORACLS

OTV

outside diameter

Optimum regulator and control of linear systems

orbital transfer vehicle

PIN

PSI

Psia

Psid

Positive intrinsic negative

Pounds per square inch

Pounds per square inch absolute

Pounds per square inch differential

R&D Research and development

RCA-PRICE Radio Corporation of America Price Modeling Program

RCS Reaction control system

RF Radiofrequency

RI Name of expert system to configure VAX installations

R/T Receiver-transmitter

SAR

Sec

SRS

Synthetic aperture radar

Second

Spectra Research Systems

TCC

TDMA

TDRSS

Trace contamination control

Time division multiple access

Tracking and data relay satellite system

VAX

VCD

VHSIC

VLSI

Virtual address extension

Vapor compression distillation

Very high speed integrated circuit

Very large scale integration

XI
D180-27935-2

1.0 INTRODUCTION

This is volume II of the final report on the Space Station Systems Technology Study

conducted for the Marshall Space Flight Center (MSFC) by the Boeing Aerospace

Company (BAG) and Spectra Research Systems (SRS). The overall study objective was to

identify, quantify, and justify the advancement of high-leverage technologies for

application primarily to the early space station. The objective was fulfilled through a

systematic approach tailored to each of the technology areas studied. This volume

presents the results of the technical effort. Volume III discusses the research plans

developed for each of the selected high-leverage technologies.

The current Space Station Systems Technology Study was an outgrowth of the Advanced

Platform Systems Technology Study (APSTS) that was completed in April 1983 for MSFC

by the Boeing/SRS team. The first APSTS proceeded from the identification of 106

technology topics to the selection of five for detailed trade studies. During the

advanced platform study, the technical issues and options were evaluated through

detailed trade processes. Individual consideration was given to costs and benefits for the

technologies identified for advancement, and advancement plans were developed. An

approach similar to this was used in the current study, with emphasis on system definition in four specific technology areas.

The four study areas addressed in the Space Station Systems Technology Study are: (1)

Attitude Control, (2) Data Management, (3) Long-Life Thermal Management, and (*)

Automated Housekeeping Integration. These four areas are extensions of the APSTS and

were conducted to facilitate a more in-depth analysis of technology issues. While each

of the study areas had high-leverage technology identification as a goal, different study

approaches were required. The attitude control study utilized a specific representative
D180-27935-2

configuration and determined by simulation the applicability of a low bandwidth control

system for space station use. The data management study concentrated on the

characterization of the architecture into structural blocks and systems to facilitate

simulation planning. The thermal study focused on characterizing a two-phase heat

transport systems within the long life requirement constraints. Finally, the automated

housekeeping task was structured to characterize the functions of an integrating

controller for an overall management system. Each of these approaches produced useful

advancements in the understanding of technology issues and development needs and are

discussed in detail in the following sections. The topics of discussion include the planned

approach, technical discussion, summary of results, conclusions, and recommendations.

The overall study was divided into four tasks. During task 1 the design concepts required

in each of the four study areas were refined. The concepts were used to describe

specific technology options upon which comparative studies were conducted. Candidate

high-leverage advancement technologies were then selected from the options. The cost,

benefits, schedules, and life cycle costs for each of the options were evaluated in task 2.

Selection of the technology advancement items was made during this latter task.

Technology advancement plans were prepared for each of the selected items in task 3.

All study documentation was prepared in task 4. The overall study schedule is shown in

figure 1.0-1.

Seven potential technology advancement items were identified during this study. These

items were analyzed and evaluated in Task 2, considering technical as well as cost

benefits and schedule criteria. Study plans were prepared for each of the selected highleverage items. These selected items are:
D180-27935-2

STUDY TASKS

MAJOR O

MILESTONES

TASK 1 - TRADE

STUDIES

ATTITUDE

CONTROL

DATA

MANAGEMENT

LONG LIFE

THERMAL

INTG OF AUTO

H/K

TASK 2-

TECHNOLOGY

SELECTION

TRADE

COMPARISONS

TECHNOLOGY

IDENTIFICATION

TASK 3-

TECHNOLOGY

DEFINITION

PLAN

DEVELOPMENT

COST AND

SCHEDULING

TASK 4 -

DOCUMENTATION

ORIENTATION

BRIEFINGS

MONTHLY

PROGRESS

REPORTS

MIDTERM

BRIEFING

FINAL

BRIEFING

FINAL

REPORT

MONTHS AFTER ATP

JUN

RIENTATIO

REVIEW

T

—

•"•"

JUL

N

•"""

AUG

•"•"

SEP

MIDTERM

REVIEW

V

~"~

•—

OCT

••••"

NOV DEC JAN/FEB

DRAFT FIN/

FINAL FINAL REPC

REVIEW REPORT COMF1

V V V

— .

—

mam ^i»

~

.

•""

Figure 1.0-1 Program Schedule
D180-27935-2

1. Data Management System Simulation Package.

2. Data Management Network Interface Unit.

3. Data Management Network Operating System.

4. Two Phase Thermal - Long-Life Pumps.

\

5. Two Phase Thermal - Heat Exchanger.

6. Two Phase Thermal - Two-Phase Water System.

7. Integrating Controller for Space Station Autonomy using Expert Systems.

This volume presents the technical work performed to select these high-leverage items.

The total final report is made up of this volume, Volume I: Executive Summary, and

Volume HI: Technology Advancement Program Plan.
D180-27935-2

2.0 ATTITUDE CONTROL

2.1 INTRODUCTION

2.1.1 Objectives

The objective of the study was to initiate the development of technologies required for

the solution of the control-structure interaction problem in space station design. The

approach was to determine through analysis and simulation the degree to which noninteracting low-band controller technology is applicable to attitude regulation of a space

station with large flexible solar arrays. Primary emphasis was given to identifying the

limitations of low-band controller technology for flexible space station applications.

Passive and active control technologies were to be reviewed as potential improvements

to the damping provided by a low-band controller in the event that attitude stability and

performance were unacceptable.

The term low-band control is somewhat misleading in the present context. The application of low band design usually implies a band limiting of the control signal. In the presence of significant structural interaction with the core station band limiting the control

signal eliminates a significant portion of the attitude error information contained in the

output. In this study all the available attitude information, including flexible effects

measured by a sensor package mounted on the core station, is passed to a linear actuator

that attempts to control the attitude about the center of mass. The sensors are assumed

to measure attitude and its rate about three body axes. The measurements are ideal to

the degree that the sensors are assumed to be error free with infinite bandwidth. The

linear actuators were modeled as ideal control moment gyros (CMC). The low-band

controller will therefore attempt to regulate attitude in the presence of induced disturbance torques due to flexibility without actively controlling the motion of the flexible

elements. The control system is said to be reactive rather than active in the sense that

the core mounted controller reacts to external disturbance rather than actively

influencing the disturbance source resulting from appendage flexing. It will be demonstrated that a core mounted linear ideal controller is stable in the presence of flexibility

and will provide significant damping of most of the major structural modes. However,

some of the modes cannot be controlled with a core mounted controller. The important

question is the amplitude to which the controlled modes are excited and the implications

of sustained vibration of the associated structural members.
D180-27935-2

The objectives of the study tasks are described as follows.

1. Evaluate the stability and performance of reactive CMC control laws for impulsive

internal disturbances during productive work periods as the space station evolves.

The worst case impulsive disturbances are assumed to originate from crew activity

and mechanical equipment. The open loop response of the structure to docking loads

is also evaluated.

2. Suggest methods of improving the pointing performance by passive damping techniques. A secondary task objective is to determine alternate methods to obtain

active damping of structural modes by prudent placement of actuators and motion

sensors.

/

2.1.2 Issues

The principle issues that impact the development of an automatic flight control system

for space station are related to the interaction between the control system and structure.

Tight pointing accuracy requirements produce associated requirements for increased

control system bandwidth. As controller bandwidth increases, many structural modes

will be included within the controller passband. Active stabilization of these modes

without sacrificing pointing accuracy is a major issue. Adapting to variations in mode

shapes and frequencies caused by space station configuration changes is also a major

issue when active damping of structural modes is required. In an effort to reduce control

system complexity, the development of passive techniques for structure mode damping is

a significant issue. Structural stiffness and damping characteristics are, therefore,

crucial to control system design, and early attention must be given to configuration options that increase modal frequency and damping.

Avoiding the interaction of control system and structure is an attractive alternative.

The reactive controller achieves this objective with an attendant reduction in control

system complexity. The important issue is the controllability of the structure and the

resultant lightly damped response to be expected from a reactive controller.
D180-27935-2

2.1.3 Advanced Platform Systems Technology Study Background

This study is the continuation of the Advanced Platform System Technology Study. The

purpose of APSTS was to initiate the control and structure interaction study at the top

level. The goal of APSTS was to establish guidelines for flexible space station attitude

control system- design and to indicate viable technology options requiring further study.

In the process of setting guidelines for control system design, APSTS intimated that lowband controller pass band would be limited to frequencies less than .10 Hz and most

likely less than .01 Hz owing to the lowest solar array structural mode frequency. It was

feared that if the free-free mode control bandwidth interacted with the flex mode

dynamics, instability would result. Therefore a cutoff well below the lowest flex mode

frequency would ensure stability with a performance penalty. However, the results of

this study clearly show that flex mode stability is not an issue of concern when a

reactive controller is used. Rather, the principle concerns with reactive control are the

presence of structural modes with essentially no damping augmentation from the

controller and the implications that accompany the sustained vibrations as previously

mentioned. This study shows that the magnitude of undamped modal vibration can be

reduced by increasing the system bandwidth. However there are obvious limitations

owing to the accuracy which attitude can be determined. These issues will be discussed

in the sections to follow.

2A.it Overview

In the following sections the technical approach to the analysis and simulation tasks

along with a summary of the results and conclusions will be given. Section 2.2 presents

the details of the technical approach used to conduct the study. First, a brief summary

of the configuration selection process will be given. Then the subtasks will be outlined.

Finally, the architecture of the software used for analysis and simulation of the selected

configuration will be presented. Section 2.3 presents a detailed discussion of each of the

elements effecting the attitude control system design. The elements include the structure, controllers, disturbance inputs, and feedback control laws. A stability analysis of

the closed loop system is presented, and the results are correlated with simulated time

response data. Section 2.4 summarizes the results of the analysis and simulation tasks.

Section 2.5 presents the conclusions of the study, and section 2.6 gives recommendations

for continuing effort in the identification of technologies for space station attitude

control. Section 2.7 provides a list of references.
D180-27935-2

2.2 APPROACH

The technical approach is formulated in terms of five main tasks. These tasks are described in the discussion to follow.

2.2.1 Formulate a Candidate Configuration

The major elements required to formulate a candidate space station architecture are the

class option categories, the functional attributes as defined by NASA and the set of

governing assumptions. Class option categories refer to the premises that define the

architectural concept. The two categories are the open class and the limited class. The

premise for the limited class is "a space station as a permanently inhabited facility

engaged in productive work and delivered to low earth orbit in stages the dimensions of

which are consistent with the shuttle cargo bay"., The open class consider applications

such as the use of the shuttle external tank, shuttle derived launch vehicle and tethers.

The first step in the process was to select a class option. The configuration for the

space station technology study was derived from the limited class premise with adherence to NASA governing assumptions. The details of the configuration selection process

along with the set of NASA assumptions and groundrules are given in section 2.7,

reference 1.

The next step was to develop a schematic architecture consistent with the functional

attributes and incorporating various strategies for growth leading to a 12-man configuration representative of shuttle deliverable hardware.

The result was an evolutionary configuration that is controllable and functional as a

space station. The attitude control study considered four operational stages that incorporate two phases of assembly, with and without the orbiter docked. The two phases of

assembly will include the initial habitable stage and the all-up fully operational stage.

A pictorial view of the study configuration is shown in figure 2.2-1. A representative

buildup sequence is shown in figure 2.2-2 along with the stages selected for analysis.

The weight of the all-up configuration is 9*000 kg with solar panels sized for 75 kW
D180-27935-2

STIFFENEB

PANEL

ASTROMAST

CANNBTER

NORMAL TO

ORBIT PLANE

Figure 2.2-1. Space Station Balanced Array Concept with

Astromast Solar Array Deployment

SOLAR I

I

A

• I

I

EXP. PLATFORM

J -n

=LAB 1

(5) LOG ft CMD

QCREW

1 o| CREW EXT 1

1 SOLAR

PANEL

A

1

CONFIGURATION (T)

LOGISTICS + COMMAND + CREW QUARTERS + SOLAR PANELS

FIRST HABITABLE CONFIGURATION

CONFIGURATION @

CONFIGURATION 0 + REMAINING MODULES

ASSUMES NO OTV OR PROPELLANT TANKS

Figure 2.2-2. Buildup Sequence Defining Configurations

for Control/Structural Analysis
D180-27935-2

(actual). The total surface area of panels for 75 kW is 1100 square meters. The inertial

and structural properties of the configuration will be presented in section 2.3.

Initial configurations featured a cantilevered solar panel design, where the entire panel

was pivoted at the end point. As the configuration developed the center pivoted

balanced solar array concept was proposed as a configuration improvement for enhancing

attitude control. The issue of achieving controllability through mass balance was the

primary concern in the configuration of the center mounted solar panels. Mass balance

was a principal design goal in order to ensure that CMC controllers will enable attitude

stabilization with minimal expenditure of energy for momentum management. Dynamic

balance is achieved by center pivoting the solar panels. The balanced configuration considerably reduces dynamic products of inertia for earth pointing that arise as the panels

are tilted and rotated to track the sun line. Rotation of cantilevered panels induces very

large periodic products of inertia at orbit frequency that create secular torques due to

gravity gradient and Euler coupling. The center mounted solar panel also increases the

lowest frequency structural mode by a factor of two, due to halving the length of the

solar panel deployment mast.

2.2.2 Determine Mass and Dynamic Properties

A finite element model of the station was developed and the resulting mass and stiffness

distribution of the structure was input to the NASA Structural Analyzer (NASTRAN).

The output modal data from NASTRAN established the normal mode shapes and natural

frequencies of vibration.

2.2.3 Define Models for Simulation

The second order equations of motion describing the forced vibration of the structure

were cast in modal form using the mode shapes and frequencies from the NASTRAN

model. Ideal CMC controllers and rotational motion sensors were colocated on the space

station near the mass center. The controller configuration, torque distribution algorithms, and feedback control laws along with a model of the internal disturbance torque

from crew activity will be described in section 2.3.

10
D180-27935-2

2.2.4 Develop Program Architecture for Simulation and Analysis

The system of analysis programs for control and structure interaction analysis and simulation is shown in figure 2.2-3. The IAC (integrated Analysis Capability) provides I/O

data manipulation and storage for all major system elements in an automated and interactive fashion. The major system elements are NASTRAN, optimum regulator and control of linear systems (ORACLS), and engineering analysis system (EASY). The synthesis

of a controller for a flexible structure would proceed as follows. First, NASTRAN computes the flexible dynamics of the vibrating structure in terms of normal mode shapes

and frequencies from a finite element model of the space station mass and stiffness

distribution. Next, interface program INDA formats the NASTRAN dynamic model output for input to ORACLS. Programs using ORACLS subroutines generate the linear state

space formulation of the rigid and flexible body dynamics along with the sensor output

matrix that relates the sensor outputs to both rigid and flexible state variables (sec. 2.7,

ref. 2). The system dynamics and sensor output matrix are then used in the design of

attitude control regulator and feedback compensators in the time domain, using Linear

Quadratic Gaussian synthesis. The feedback gain matrices computed from ORACLS

routines along with the disturbance torque model and the system and sensor output

matrices from ORACLS subroutines are input to EASY 5. Program EASY 5 is an engineering analyses system that computes the time response of a nonlinear system and has

the capability of linearizing the nonlinear system about an operating point for the

purpose of stability assessment and other linear time and frequency response analysis

tasks.

It is noted that the IAC was a pivotal factor in the successful completion of this work.

High order models require very large data files that must be manipulated to effect controller design and analysis. Data and model files must be stored and retrieved for performance analysis and graphics presentation. In the absence of a fully automated interactive I/O capability, the analysis and synthesis tasks of designing controller for realistic

structural models is precluded.

^

2.2.5 Conduct Analysis and Simulation

The analysis of attitude control system stability was performed by arguments based on

the theory of positivity of operators (sec. 2.7, refs. 8 and 9). The basic stability theory

was verified by frequency response methods and time response from simulation of the

11
F|.NITE\

ILEMENI

JDEL

NASTRAN

DYNAMICS

D180-27935-2

IAC

. DATA BASE

PLANT

DYNAMIC DYNAMIC

MODES MATRICES

ORACLS

DISTURBANCE

MODELS

EASY 6

TIME

RESPONSE

1

_ JNTROL—

LER

ACTUATOR

MODELS

CONTROL

ANALYSIS

TASKS

OPTIMAL REGULATOR

• AND COMPENSATOR

DESIGN

Figure 2.2-3. Software Architecture Technical Approach

for Dynamic Simulation and Analysis

JE03

.794

LOG £ MAX

E

.148^-154

.095 (§

JOB (I

M

ALL MOOiS RETAINED

10 16 20

MODE NO.

Figure 2.3-1. Modal Reduction of Structure Model by Impulse Energy

12
D180-27935-2

closed loop system. The performance of the closed loop system was determined from

time response data. System performance includes the motions of the central core and

the flexible elements. Stress at the root of the solar array boom and astromast were

derived from time response data. These calculations are especially valuable for evaluating structural integrity due to docking loads.

2.3 TECHNICAL DISCUSSION

2.3.1 Structural Model

A finite element model was constructed using the NASTRAN computer program. The

following is a description of the model. All components described are labeled in figure

2.2-1. Section properties and dimensions are shown in table 2.3-1.

2.3.1.1 Solar Arrays

The solar array booms were modeled as graphite/epoxy tubes, 24 meters long. The solar

array astromasts were modeled as triangular trusses with a design by AEC-ABLE called

Continuous-Longeron Able Boom. Sizing of the boom and astromast was done assuming a

maximum static load of O.lg. The astromasts are housed in round cannisters at the end

of the array boom. The solar array panels are stored in boxes at the near end of each

panel and reinforced at the outboard end by a stiffer. Rods extend from the box to the

stiffener along the center of each panel to simulate the cable along which the panel is

deployed.

2.3.1.2 Modules

The five modules were assumed to be rigid bodies with flexibility at their connection

points with each other and with the orbiter. The stiffness at the ends of the modules was

computed separately for the module and for the docking tunnel, then springs in series

were assumed and the stiffness for the module including the docking tunnel was computed. The stiffness at the module side connection points was computed using equations

for circular rings.

2.3.1.3 Mass Properties

The mass properties of the space station were derived under the following assumptions.

The masses of all the structural members are uniformly distributed along their lengths.

The masses of the solar panels are lumped half at either end of the astromasts and mass

13
Dl80-27935-2

—»

J

r^

*E^^j

Jl

^

j

<

1

2

2

H

£•DE5C

R

ZH

<z

osuj

ii

CO

^S

S

JJ- vO vD <A tx

UJ Ol Ol Ol UJ 'T H3

ON CM a- — «• -a- ol i

o oo a- UN -a- (vi ol

_ f^ NO — 00 J- —

ir\ vo vo vo rx

I I 1 1 1 IX ,

01 Ol OI Ol 01 I

rr\ (VI {VI IX (VI Ol

• • • • ^* • «M

i/"\ r*^ f% fx ^r {VI 4£*

Ol Ol Ol Ol Ol Ol Ol

ON — « ON CO «*> vo UN

ON ON ON o c; "A oo

rs -H " f? tx (vi -^ hs.

C^ "7

a uJ' a, a, a, CL o

Ol ^j Ol Ol Ol Ol «

OL v3 ttJ Di 0- Oi Ol

O vo O CJ O O U

E.. E -E pE E E

— * (vi ^3 i. ,— -a-ra {vi* £•* (--a" — «

oo o uJ E "NO o '• **^ i fc' o

•§ n n .2 3 n ii •§ n n •§ n ii •§ n ii •§ n n •« ii

j-""o+* +-> 4-> "D jz ("""o** HI'D*' HTM*u*j H"*O4rf O"o

L> l_ L. U t- L, "O

CQ CO 00 cQ CO ffi D«

S w E i.

« g 1 S 1 .

>» o C ^i

W t« t^ ^ .- .T^ ^

LM +•* f \ *- X ^^ ^

IM CO V-/ <W O "Tj (0

< < BJ U CO ^ U

ii

tiUl t*t

J »«\

VO — i

II II

O O

„

CM «(N

^E TM ,E

^ ^ 2*

S ON ON

^ s a s 8 - « 2

O II II II

Q« O] Ol Ol

3

fe _S

rt 3

2 U ?? o

1

ii! S Mi aj

CO *J

C co 5

o jfl •£.

^ 3 £

U «/) W

+3

Ho

I"I«

. V jl

3^

3

v

rx

0)

I

14
D180-27935-2

moments of inertia are added to reflect the actual mass distribution. The module masses

are lumped at their c.g.'s with moments of inertia to reflect the actual mass distribution.

The mass of the radiators was lumped along the boom at either end of the radiator with

moments of inertia included to reflect the actual mass distribution. The mass of the

RCS thrusters was lumped at the outer end of each RCS boom.

The space station mass properties for the test configurations with and without the

orbiter docked are given in table 2.3-2. The principal axis basis vectors are the columns

of matrix M.

From the parameters given in table 2.3-1 and the dimensions shown in figure 2.2-1 the

stiffness of the members in torison and bending can be computed from the relations,

•

= GJ

L

= 3EI (concentrated load at x = L)

L3

where G and E are the moduli of rigidity and elasticity, 3 and I are the axial and transverse area moments, L is the length of the structural member, and A is the cross sectional area.

The stiffness equations for torsion and bending in table 2.3-1 were used to estimate the

frequency and amplitude of oscillation for the elastic members as a check on the

NASTRAN model.

2.3.2 Structural Model Order Reduction

The order of structural model derived by finite element methods is theoretically infinite.

In a practical sense the model is very large, the majority of the modes having negligible

inpact on controller design.

15
Dl80-27935-2

a

1

.0

0

CM

§

s

«?

••4

1

u

CM

|

2

Bfl

S3

5o

U

•^

1

23

•g

O

U

<3

a

fM <M <f> fM

CNO CNO 1^ CNO

• 2 i 2 £ i 2 toO 00 DO ^ tiO ^ TM

N/s JM 9^ N/v s *h 7s*

 J Vb

 P t J SM/ ^ ^ r i*-

 W "S

t^

!2

 s ^Os -^ ^ ^

fSI vft l^ ^^ OO **

CN 5 !?N ^ ^ o *

^.^^.0^0 ^ ° J 0 ^ o

— NO -.

^ g S

1 f^ • 1

1^

>A

eo "^ d- 01

«M »N4 J> O 'Vj

NO ^ NO

<2^0o**\o o cT< ^ o-«o

* " * • 3fr *

°* •> *

®® •» Clj I*"*1

f\ *-* *^ f*» ts*

• («? ^^ *• •

^

<M^.

oo . .. _

CM _H ^ NO 2J o

C*> 00 — < «N 2 •> °°

Jh-»i^ o f M o 5 0-= ^ O — < O

•1 -^ CM *"! J^ —

°°" — ' ot

^* f^\ ^^ ^5 ^^

CM

X >% N ^NN'tX'^pO ^

0<

1

•

DO

VH

S-l

U

en

"3;

1

«_

-2

V

x:

?

4-1

•3

Q.

«" -f,

"-> y fc * O *i

Z

 rt

o

**

cT

o

"^

0)

T3

O

C

2

u

&U)

0)

Lrt

£

"$

C

O••4

ffl

(J

—O «

DO

U

BOM*

^^ C

«^n

-S ~^

en „,

•2 w

g|

2-1 L^ to ^

v e;

•£ -c

*^ 4-"

^H

o o

i s

C (0

5 5

o o 4«* +^

jr ^

H H

1K

««

i

i

CM

«*J

CM

I

2

16
D180-27935-2

To provide ease of analysis and data handling the high order structural model must be

reduced. The goal is to isolate those eigenvalues that have the greatest influence on the

structure input/ output response. The method of impulse energy (sec. 2.7, ref. 3) is found

to be effective in reduction of high-order models. The foundations of the theory for the

impulse energy method are presented here.

Given a high-order, linear, time invarient, asymptotically stable system in modal form,

x = Ax + Bu

y = Cx

Simultaneously introduce unit impulses of the form u = 6 (t) into all controls. Compute the output impulse response energy.

00

y <t)y(t)dt = E(M ,...., Xn)

0

For each eigenvalue Xk of the system matrix A compute the individual contribution

^k(Xk)

 to tne

 total energy E. The eigenvalues X|< with the largest Ej< are usually retained

for model reduction. The impulse energy analysis for the space station structure in configuration 1 is shown in figure 2.3-1. The analysis considered the presence of 80 modes

of vibration up to 30 Hz which represents flexing of the raft structure due to compliance

at the module interface. The semi log plot shows the relative energy contributions expressed as the ratio (Emax/E) for the first 28 modes up to .79 Hz. Values of

log (Emax/E) for mode numbers greater than 28 are all substantially greater than 1.

Based on this analysis, the first 18 structural modes were retained for the simulation

model. It is noted that the method of impulse energy gives a clear indication of those

modes that can be affected by the given combination and placement of sensors and

actuators.

The mode shapes and frequencies of the truncated structural model for Emax/E< 1 are

shown in figure 2.3-2. These are the modes identified by impulse energy as being the

most susceptible to control by core mounted actuators and sensors. The fundamental

torsion and bending modes of all structural members are represented. The first astromast bending mode above the fundamental is present in mode 18. It is interesting to

note that the highest impulse energy is contained in mode 16. This mode of vibration is

dominated by array boom and astromast bending. From this observation, conclude that

bending of the array boom and astromast are the flexible element motions most efficiently damped by the core mounted controller. Also note that mode 6 appears

17
D180-27935-2

\'

18
D180-27935-2

to be dominated by astromast torsion and to a lesser extent by bending. However, from

figure 2.3-3 observe that mode 2 (modes 1, 3 similar) is exclusively dominated by astromast torsion. Therefore from impulse energy conclude that the principle energy contribution to mode 6 is from astromast bending and astromast torsion is not controllable

with the core mounted actuators and sensors. These conclusions will be verified by the

time response of the closed loop control system. It is also clear from mode 6 that bending and torsion are coupled. Therefore a method for actively controlling astromast torsion

with core mounted actuators is indicated and will be presented in the discussion of the

control response results.

It is noted in passing that the structural model made no mechanical provision for coupled

bending and torsion of the astromast section. Recall that all the mass of the solar panels

was lumped at either end with inertias included to reflect the mass distribution of a flat

plate. Because inertia forces and torques act through and about the center of mass the

observed coupling of bending and torsion in mode 6 is a model phenomenon and must not

be linked to a direct mechanical cause and effect. Future models of the astromast section will include inertia forces of the solar panels that are offset from the section centroid, producing torsion as the mast bends.

2.3.3 Controller/Sensor Selection

The controllers selected for the space station simulation are a multiple grouping of Skylab class two axis double gimballed control moment gyros in a parallel mounted configuration. A schematic of the configuration is shown in figure 2.3 -*f. The two axis

double gimballed CMC is ideal for applications where rate loop bandwidth is not essential. In this instance there is a greater demand for H than H and the two axis gyro

approximates a position controller.

The parallel mounting configuration provides a very simple gimbal angle steering law. In

addition, hardware mounting, redundancy management, and failure accommodation are

greatly simplified. The parallel mounting steering law provides reduced rate requirements on the outer gimbal and avoids singularities internal to the angular momentum

envelope. The gimbal angle control laws were taken from reference ^ in section 2.7.

For reference, the distribution of gimbal angles and rates for a typical closed loop

response to an impulsive disturbance is shown in figures 2.3-5 and -6.

19
D180-27935-2

MODE 2

w-.084 HZ Hz

Figure 2.3-3. Second Bending Mode

OUTER

GIMBAL

TORQUER

VEHICLE BODY

AXES

INNER

GIMBAL

TORQUER

PARAMETERS

H -3000 N-M-SEC

<0,/J)MAX-12°/SEC

(flJJ)L-4°/SEC

BANDWIDTH - 20 Hi

Figure 2.3-4. Three Axis Parallel Mounted CMGs for Space Station

20
D180-27935-2

It is noted from figures 2.3-5 and -6 that the initial position of the outer gimbals is such

that all H vectors are 120° apart. This distribution produces zero net momentum state

in spacecraft coordinates which is advantageous for multiple CMC applications to earth

oriented vehicles.

The dynamics of the CMC's were neglected in this analysis because the bandwidth of a

Skylab class two axis gyro is approximately 10-20 Hz. The bandwidth of the attitude

control system is expected to be less than .50 Hz. The phase contribution from a 20 Hz

actuator at rate loop crossover is therefore negligible. The motion variables of the freefree modes (attitude and attitude rate about the center of mass) were assumed to be

derived from a measurement algorithm, for example, quaternion integration where the

bandwidth of the process can be assumed large with respect to the attitude control

system.

2.3.4 Disturbance Input Profile

The disturbance profile for modeling crew activity is shown in figure 2.3-7. The model

represents an astronaut in a soaring maneuver within the space station. A detailed description of crew disturbances is given in reference 5 in section 2.7. The motion is

envisioned as being a pushoff from one wall and a deceleration at the far wall. The parameters for the motion are presented for a large astronaut in the flight within a module

of about 12 ft in diameter. The resulting impulsive momentum disturbance is 400

n-m-sec for each element of the doublet. To establish a highest upper bound from all

internal sources including mechanical equipment a value of T0 = 1000 n-m was used as a

worst case value for simulation and analysis.

The worst case level was derived by considering all the internal disturbances from the

major sources including crew motion. Table 2.3-3 summarizes the momentum contributions from liquid transfer, rotating equipment and crew activity. An upper bound of 1000

n-m-sec seems reasonable.

21
D180-27935-2

;

j

.

y *i^ V - u

-2.

UA

;l

Ik

01 (r

ilr

?r

-.1

-.7.

-10

/\

\ I ~ \ /

s/

-10

f\

/ \ / \

^/

101

I A

\ /

v

5<

ROLL, x

(DEG/SEC, DEG)

Pr ^, 10 io.3»

A

1 \

^-s

o • — • ~ x3 ' K

TIIC

PITCH, y

(DEG/SEC, DEG)

Figure 2.3-5. Closed Loop Controller Response to 1000 N-M-Sec Impulse

Doublet in Pitch and Roll for Configuration 1

System Bandwidth

 g .OS Hz

22
Dl80-27935-2

' «

°1 0

_ *

irv

°? 0

"S n

—S>

°r <<

*

2

,

it ft

°2 °

-7-

4i

-

f •'

1

«

.1.

I1 "

n J..

r "

L

SVJ

v-u

y

•^/VA^-

a n .

^

jA/V^-^ ' —

6

ll 5(

.

id

75.

1 25^

9S.-0.

r

1I

2 o.

1

•

I r

f

1

1

3 0

I

1

r 1

if

|

1

11 n.

L,

2 "°

n

t

V

"11

2««_

3

 '?v

9 W

one

IH

225^

A

.

50 100

TIME

PITCH

(DEG/SEC, DEC)

TIME

ROLL

(DEG/SEC. DEC)

Figure 2.3-6. Closed Loop Controller Response to 1000 N-M-Sec Impulse

Doublet in Pitch and Roll for Configuration 2

System Bandwidth " 35 Hz

23
D1SO-27935-2

Table 2.3-3 Internal Disturbance

SOURCE

Liquid

Transfer;

OTV Fuel

Transfer

Cooling

Loop

Rotating

Equipment;

CELSS

Medical

Crew

Activity

DIST.

MOMENTUM

(N-m-s)

200

100

300-500

800

400

2.3.5 Simulation Results

The simulated response of the structure to the single test disturbance impulse doublet

was computed for both open loop and closed loop cases. The resulting time responses are

shown in figures 2.3-11 to 2.3-16. Figures 2.3-11 to 2.3-14 give open and closed loop

responses side by side for easy visualization of the effect of the controller on the

disturbed system. The block diagram for the closed loop system representing an attitude

regulator is shown in figure 2.3-9. The nodal structure indicating the nodes used to

extract measurement data is shown in figure 2.3-8. Motion of the core structure relative

to an inertial frame was extracted from the rotational state of the variables $, Q, \|>

(roll, pitch, and yaw, about x, y, z) of node 100. Measurements of flexible element

motion relative to node 100 are specified as follows. These rotational measurements

indicate the flex and twist of the solar panel boom and the astromast structure,

Mfix = Flex of panel boom ($100-105)

MBv = Twist of panel boom (0100-105)

= Flex of panel boom (\|>i 00-105)

= Twist of the astomast ($100-323)

Ma = Flex of the astomast (9105.323)

MB.,

24
.27935-2

Figure
D180-27935-2

out

^Q^Q ^ ^ fTMUCTUKI

ACTUATOM

 r

 . T

^ "1 J «« T «X t 1 * I

a. HZrJ

COMTMM.LU

ATTITUM '

UNSOftS

. 1 »

•

VECTORS DISTRIBUTION MATRICES

u - TOTAL TORQUE A - CMC TORQUE

g « MODAL COORDINATE B - CONTROL INPUT

y - MEASUREMENT C - MEASUREMENT

f - FEEDBACK TORQUE 0 • MODAL STATE (EIGEN VALVE)

COMMAND ft - EIGENVALUE DIAGONAL

K - FEEDBACK CONTROL

Figure 2.3-9. Generic Block Diagram of an Attitude Regulator for a Flexible Structure

n rv

| QlOOiir - '

Y ^ Y0 CMG.AND wo

* i MOTION SENSORS

^xj LOCATED ON RAFT

.^ \ *»

^ M. >'

° <X. ^ ' <P V 95000 <^

^^^

 Ao , Kg OJ2.

^^s^ 260 m^

^*V «

/**

"/^* lt° \

iX ^IA 1^

^^S-

_^^ je ^^

I N^- PRINCIPAL

_l XXES

x

"p

Figure 2.3-10. Orbiter Docking to Space Station Showing Preferred Configuration

26
•e

-20

Mr

10D

ME

-10

MB,

20

10

f

M.

300

200

-100;

-20oi

OPEN

LOOP

ftfl

7

D180-27935-2

,>-X_x-

/

/

K— ^-^-s_^_x

•0

-40-

Mt

-to

-is

t

M,

-10

-n

V

M,

o

-100

-200

CLOSED

LOOP

-TOO

l\

,

rs. „ • /

vy

A

rfi

50 100

Figure 2.3-11. Response (arc-sec) to 1,000 N-M-Sec Impulse Doublet in

Pitch for Configuration 1

System Bandwidth = .05 Hz
OPEN

LOOP

D180-27935-2

woo

ISO11 mimin

-ISO.

I' Mill

MIC

CLOSED

LOOP

200

100

-too

-ZOO

10

-IS

A . yx

-SO

-100

-10

Me

>y 0

Mc

-*«>

nlll/W r^ - T r

A ^

TIT

__1

\

\j^^

 —

Figure 2.3-12. Response fare-sec) to 1JOOO N-M-Sec Impulse Doublet in

Roll for Configuration 1

System Bandwidth = .05 Hz

28
D180-27935-2

5Sfv

3SO

ISO

SO

-SO

•e

Mc

Mc

ME

too50

-50

-1*

M/

-too

-19O

OPEN

LOOP

Aft

— ^

v

90 100

•0

CLOSED

LOOP

^^

f\

M - - / : \y

to

^

A A A

<\ \ \!\!

\r\\l\ l

v v

\AAA A

V V v v \

M.

-90

-wm

MB,

4fr

2O

&

-»

-40

A /\ j

^ A A /

V T7

M,

-ISO

A A

J7_

A /A A

U W V

Til

Figure 2.3-13. Response (arc-sec) to 1JOOO N-M-Sec Impulse Doublet in

Pitch for Configuration 2

System Bandwidth = .05 Hz

29
D180-27935-2

• 00

c*

200-

-300

' " IIH

bo '*\ 1

 - - 1 y \y • •

flA

^wV\ |V ^l^ - ulr

too

M,

-»

-100

ME

MB,

-300

1IIC

. Response (arc-sec) to 1JOOO N-M-Sec Impulse Doublet in

Roll for Configuration 2

System Bandwidth •* .05 Hz

30
Dl80-27935-2

2500,

1000)

e,

-10

A-ftff

A A

7 \n/ / \J-\ J

MB.

-100

A A

M

-50

-100

M

400

200

Bz o

-200

100

% •

-to

A

1SOO

V m

1000

M

V

20

TIC

F/^a/B 2.3-15. Impulse Response (ai&sec) of Configuration 1 to Docking Load

of 250O Newtons at Body Station 1201 (Force Along X-Axis)

31
D180-27935-2

The quantities

 eA,CQ, ^represent the contribution of the flexible modes to the total

attitude response. For example Q = 9f + EQ is the total rotational response of node 100

about the pitch axis and 9f is the component due to the free - free motion only. It is

noted that quantities MB , Ma, and MA represent the mode slopes at the end of the

associated flexible members. All response quantities in figures 2.3-11 to 2.3-16 are in

arc-sec.

2.3.5.1 Open Loop Response

The uncontrolled response of the structure to the test disturbance in the pitch and roll

axes is shown in figures 2.3-11, 12, 13, 14 and 15 for configurations 1 and 2. In the pitch

axis the contribution of flexibility to core rotation about y,

£

0is dominated by twist of

the solar array boom as evidenced by inspection of Ma and Ma of figures 2.3-11 and

2.3-13. Reference to figures 2.3-12 and 2.3-14 show that in roll the rotation of the core

station due to flexibility,

 e<£, is attriuted to flexing of the astromast about y as seen in

MA . The induced bending of the boom, shown in MB , is reflected directly into E^.

Inspection of MA and comparison with Sb,6^indicates that astromast twist has negligible impact on lateral motions as expected. The'coupling of astromast torsion through

flexing is clearly seen by comparing MA and MA *or pitcn ar>d

 r°U responses. The

x y

inertia effect is clearly indicated by comparing the responses for configurations 1 and 2.

The response of the structure to a typical orbiter docking from impact loading at body

station 1201 only is shown in figure 2.3-15. It is assumed that the orbiter has an initial

rotational rate at docking about its e.g. of $o = .2 deg/sec. with a linear velocity of

v

 o = 0.15 m/sec as shown in figure 2.3-10. assuming the centerline of shock is 1 meter

from the station e.g. and further assuming that the collision is perfectly elastic, the

resulting impact will impart approximately 2500 N-sec to the station. For the deflections shown in figure 2.3-15, the minimum factors of safety in terms of stress at the •

beam root are at least 100 in both astromast and array boom bending and torsion.

The max deflection Mg (figure 2.3-15) was estimated analytically and found to be

within 10% of the simulated value. Therefore the simulation was found to be trustworthy giving additional confidence in the interpretation of the modal quantities that are

output from the structure dynamic equations computed through the I AC.

32
D180-27935-2

2.3.5.2 Closed Loop Response

The simulated response of the attitude regulator to the test disturbance is shown in

figures 2.3-11, 12, 13, 14, and 16. The system bandwidth chosen for presentation is .05

Hz for all configurations except .25 Hz for configuration 2. The controller was a simple

proportional plus derivative feedback of free - free mode attitude measured at node 100

(see fig. 2.3-8). The time responses indicate that regulated free - free mode attitude is

both stable (in accordance with theoretical predictions) and controllable. The controllability of the structure is not surprising because the impulse energy analysis has clearly

indicated that controllable normal modes contain motions of all structural elements with

the exception of twist of the astromast. The time responses support this claim and would

indicate that torsional vibrations of the astomast are not controllable with the controllers and sensors mounted oh the rigid core as expected.

Recall from the impulse energy analyses that vibrations associated with antisymmetric

mode 16 showed the highest potential for suppression by the core mounted controller.

Array boom and astromast bending are the principle components of mode 16 and the time

responses clearly show that boom and mast bending vibrations are effectively suppressed.

However, although antisymmetric mode 4 shows relatively high impulse energy the torsional vibrations in the boom are not as well damped as boom and mast bending vibrations. Note that the pitch axis response exhibits almost pure mode 4 response. Normal

mode ^ is dominated by boom torsion and the mast seems to move as if it were rigid (cf

MA > MB , figs. 2.3-11, -13). Although the flexible state variables associated with this

mode are very controllable, they are weakly observable in the output as expected, which

accounts for the low relative damping of boom torsional vibrations relative to boom and

mast bending vibrations.

It is noted that the rate of suppression of vibration (damping) in the structural elements

appears to be independent of vehicle inertia for fixed free - free mode control bandwidth. However, the magnitude of the vibration is of course inversly proportional to

vehicle inertia as expected. The damping of structural vibrations for a given vehicle

inertia decreases with increasing free-free mode control bandwidth, c.f. figures 2.3-13,

-1*, and 2.3-16. This is due to the fact that with increasing bandwidth the closed loop

modal poles approach the open loop modal zeros that are virtually undamped. The result

is that the residual in the response due to a given modal pole is reduced but so is the

closed loop damping on that pole.

33
Dl80-27935-2

6

-20;

fl

I/

I/

•

i.o

ia

5

MA O

-10

A /\ A/ 1

\7\l \

PITCH

TIIC

1

iv. :..

TV

t

*

«

"it n

-10.

I

f

||A(U/\ ,

I/N/JJVV---. -

I

* 5

i ,

III

I

iii!

1 1S

»

1

A ,

jl/WA/WN

I *

rv\^A/^^/^V^x^v^

M.

1

11 ^n l*\ ^- A- r^ -

lu II * V

1

\ -f t A.A A,»*v *

V " ^^ w v v v v y

-4O

c

100J

ft

. 1 flA/lA A

¥lrP»

5C id

ROLL

Figure 2.3-16. Closed Loop Response (arc-sec) to 1000 N-M-Sec Impulse

Doublet in Pitch and Roll for Configuration 2

System Bandwidth = J25 Hz

34
D180-27935-2

2.3.6 Stability Theory

The block diagram for discussing the stability of a structure with colocated sensors and

actuator is shown in figure 2.3-8. A formulation of the structure equations and the

theorem relating to the nature of the controller required for attitude stabilization is

stated here.

Given the undamped structure dynamics in modal form

a T

with state vector x = | £ £ , system eigenvalues,

and system

. L _

eigenvectors, $ = $1,. . . $j,. . .

Given that the feedback is of the form f = Ky where Kp and Kr are the position and rate

gain partitions of matrix K.

then, if ideal sensors (C) and actuators (A) are colocated anywhere on the structure then

E}T = c and a controller of the form

= [KP Kr] B

o B

T

*

X

stabilizes the attitude of the multi-input, multi-output structure. The gain of the CMG

torque distribution matrix is unity. Ideal sensors and actuators have no phase associated

with their operation and are said to have infinite bandwidth. The theorem is proven for

single-input, single-output system in section 2.7, reference 7 and was derived generally

for the multi variable case using positivity arguments from references 8 and 9 in section

2.7.

35
D180-27935-2

2.4 SUMMARY OF RESULTS

The important control/structure interaction issues for a representative space station

configuration have been addressed. Specifically, the stability and performance of the

station with a core mounted linear controller has been investigated. The inertias are of

order 10^ with solar panel size of 1100m 2 which is consistent with a 75 kW power

requirement. The following statements summarize the results of the study.

1. Analysis has shown and the simulation has verified that the raft configuration is

stable and controllable when ideal sensors and CMC actuators are colocated.

Because the raft is rigid at frequencies of interest (0.5 - .5 Hz), colocation of ideal

sensors and actuator on the raft will guarantee stability.

2. Damping of the structural modes is substantially augmented in most cases by the

CMC core mounted controller. Damping of astromast torsional vibrations is not

augmented by the core mounted controller.

3. The performance of the ideal reactive controller in terms of its ability to suppress

transient disturbances at levels of practical interest, is limited only by the control

authority. The issues addressed in the current simulation work are therefore related

to the assumption of ideal .(infinite band width noise free) sensors and actuators.

4. Simulation shows no extreme motions of flexible elements when subject to the most

severe shocks due to docking loads. The loads were modeled as impact forces at the

docking interface. The max stress at the root of the array beam and astramast are

at least a factor of 100 less than the proportional limit stress.

5. Gimbal rate response to the test impulse doublet was found to be as high as 6°/sec

for controller bandwidth of .05 Hz. Skylab class gyros are rate limited to 4-6°'sec'

Therefore if bandwidth above .05 Hz is required for the class of space station

studied here then three Skylab gyros is the minimum number to insure accuracy of

100-200 arc sec under the assumed level of transient loads.

36
D180-27935-2

2.5 CONCLUSIONS

The purpose of the study was to evaluate the basic stability and pointing performance of

the core station when perturbed by impulsive disturbances that were intended to model

torques produced during a productive work cycle. At the outset of the study, it was

surmised that attitude stability might be jeopardized when the control band interacted

with the flex modes. However, the theory shows that when the core station can be

assumed rigid with respect to the control bandpass then the controlled response is'

asymptotically stable when the sensors and actuators are colocated anywhere on the

core. A simulation of the flexible station and a control system consisting of multiple

two axis double gimballed CMGs ideal attitude sensors was implemented. The attitude

response of the system to impulsive disturbance verified the stability theory and showed

substantial improvement in modal damping in most cases.

The conclusion of the study can be summarized as follows. Control of the free - free

attitude modes using a regulator consisting of colocated CMC actuators and ideal rate

and position sensors is asymptotically stable. However, the response of flex modes associated with the astromast is lightly damped with long settling time. If the resultant lowamplitude vibrations are objectionable, then flex mode damping must be introduced.

Investigation of passive damping techniques should be a first priority. With these results,

the important issues of core station free -free mode attitude control using a simple controller without additional stability augmentation of the flex modes has been addressed.

Alternate technologies for attitude control were intended to supplant the low-band controller in the event that attitude stability and performance were degraded. Analysis has

demonstrated that the space station is attitude stable and performance is questionable

only to the extent that low-amplitude vibrations of the structure are lightly damped. If

the persistent low-amplitude, attitude oscillations are objectionable, then additional

damping must be introduced. Investigation of passive damping schemes reveal that these

techniques might be applied to the solar panel boom to dissipate the energy of the flex

modes. Damping on the order of 10% has been demonstrated in laboratory experiments.

2.6 RECOMMENDATIONS

Continuing effort in attitude control for space station should concentrate on defining

control requirements during buildup and construction phases including configuration with

37
D180-27935-2

the orbiter docked. Emphasis should be given to definition of control modes for each

phase of evolution and schemes for managing the momentum envelope of candidate

momentum transfer systems. Control modes would include electromagnetic sensing and

actuation, momentum transfer, mass expulsion, attitude biasing, and appendage

articulation.

During the configuration development phase of the previous study emphasis was given to

achieving a dynamically balanced design. Mass balance will ensure that momentum

transfer devices can be used for control without excessive propulsion requirements. All

previous structural models will remain intact and no redesign of core station or appendages will be required to accommodate mass balancing. The space station configuration

developed for this study will therefore be used without modification for evaluating candidate controllers for the proposed continuing effort. The simulation will be modified to

include the control laws.

The output of the proposed study will be a control mode survey and trade off evaluation.

Based on the results of the evaluation, recommendations will be made regarding the most

effective attitude control strategy for space station during its evolution and long term

operation. It is expected that the resultant control strategy will be synthesized from a

set of technology elements already in place. The challenge will be to find new and creative applications for the basic elements with suitable modifications to the control laws

that reflect modern computational techniques.

2.7 REFERENCES

1. "Space Station Needs, Attributes, and Architectural Options Study," Volume 4, Final

Report, Dl 80-27477-4.

2. Winkleblack, S., "Construction of State Variable A, B and C Matrices from

NASTRAN output", Boeing Coordination Sheet 2-3634-0040-652, Nov. 16, 1983.

3. "On the Selection of the Eigenvalues to be Retained in a Reduced Order Model", G.

Zhao, P. Rozsa, N. Sinha, Presented at the 19th Allerton Conference.

4. H. Kennel, "Steering Law for Parallel Mounted Double Gimballed Control Mount

Gyros", Revision A, NASA TM-82390.

38
D180-27935-2

5. "Handbook on Crew Motion Disturbances for Control System Design", January 1978,

Contract NASW-2982, Martin Marietta.

6. "Formulas for Stress and Strain", Roark and Young, McGraw Hill 1975, pp. 220.

7. "On the Control of Flexible Mechanical Systems", Stanford PhD Thesis by

G. D. Martin.

8. "B. D. O. Anderson, "A System Theory Criterion for Positive Real Matrices", SIAM

Tour of Control Vol. 5, No. 2, 1967.

9. R. 3. Benhabib, et. al, "Stability of Large Space Structure Control Systems Using

Positivity Concepts", AIAA Tour of Guidance and Control, Vol. it, No. 5.,

Sep-Oct 1981.

39
D180-27935-2

3.0 DATA MANAGEMENT

The data management section of this study was concerned with the data processing,

storage and communications hardware and software that comprise the Space Station

Data Management System (DMS). The study approach, analyses, and results are

described in the following paragraphs.

3.1 INTRODUCTION

Data management includes the data system hardware and software needed to provide all

Space Station data processing, storage and communications for onboard users, subsystems and payloads. This study was based on requirements determined in the previous

study phase as shown in figure 3.1-1, and extended that work in three main areas. The

first area is mission configuration analysis from a data management point of view; the

second is the electronic hardware needed to provide data management services; and the

third is the data management system software. These areas were addressed as three

subtasks in this study.

Section 3.2 describes the study approach, followed by a technical discussion in section

3.3. The study results are summarized in section 3.4, and conclusions and recommendations are presented in sections 3.5 and 3.6 respectively.

3.2 APPROACH

Data management is an extremely broad study area because twenty or more Space

Station subsystems, dozens of payloads and experiments, crew stations, computers, data

storage devices, and communications transceivers are all interconnected through the

data management network. The main function of data management is the integration of

data from such equipment and subsystems to provide an effective, flexible, expandable

and high performance transfer of information. The onboard system will be targeted

toward a high degree of autonomy, but on the early space station, ground control,

ground-based users, and other orbital platforms will also be connected through the DMS.

The on board DMS, therefore, will be a cluster of computer-related equipment and software, within a much larger end-to-end data network. These considerations led to the

conclusion that the DMS could be regarded primarily as a local area network (LAN). The

40.
Dl80-27935-2

SUBSYSTEM

CONTROL

COMMUNICATIONS

DATA BASE

DISPLAY

MAINTENANCE

MANIPULATOR

SPACECRAFT TEST

EXPERIMENT*

AUDIO

DISTRIBUTION

VIDEO

DISTRIBUTION

PROCESSING CHARACTERISTICS

FAULT TOLERANT COMPUTING

SENSING. FILTERING ETC.

SWITCHING/MULTIPLEXING

SEARCHING & SORTING

IMAGE GENERATION

& SWITCHING

AUTO-TEST & SIMULATION

SENSING & MOTOR CONTROL

SIMULATION & SWITCHING

SENSING & SWITCHING

A/D & D/A CONVERSION

ANALOG SWITCHING

STORAGE REQUIREMENTS

SMALL ARCHIVE

SMALL BUFFERS

LARGE BUFFERS

LARGE ARCHIVE

LARGE ARCHIVE

LARGE BUFFERS

LARGE ARCHIVE

SMALL BUFFER

LARGE ARCHIVE

LARGE ARCHIVE

LARGE BUFFERS

SMALL BUFFERS

NONE

COMMUNICATIONS

BANDWIDTH

C1MBPS

MOO MBPS

< 100MBPS

> 100 MBPS

< 10 MBPS

<1MBPS

MOOMBPS

> 100 MBPS

< 10 MBPS

> 100 MHz

•THEMATIC MAPPER. SYNTHETIC APERTURE RADAR ETC

ARCHIVE: PERMANENT STORAGE FOR DATA RECORDING OR REFERENCE

BUFFER: HIGH SPEED TEMPORARY STORAGE

Figure 3.1-1 Data Processing, Storage and Communications Requirements

41
D180-27935-2

LAN concept, identified during the previous study, has been expanded here to include

details of the LAN architecture.

The purpose of the mission configuration analysis subtask, which is the first subtask of

the data management trade studies, was to assess the impact of candidate Space Station

missions on the DMS and to ensure that the concepts developed in the previous study

would meet requirements from those missions. This analysis was used to develop a model

of the DMS for future simulation studies, and also provided an input to subtasks two and

three. The network interface unit (NIU) and network operating system (NOS) were

identified in the previous study and a cost-benefits analysis was conducted to determine

their potential value to the program. It was estimated that a savings of $176M could

potentially be realized if the LAN were developed, prior to space station development,

and if the onboard subsystems and payloads of the station used the LAN hardware and

software for data collection, processing, storage and communications. The higher cost

alternative would have each experimenter develop his own DMS interfacing hardware and

software, followed by a systems integration step to make the payload compatible with

the onboard data management system. This approach results in needless duplication of

effort, when compared to the LAN. Also, the savings of $176M refers only to development costs. It is believed that the LAN would also yield significant savings in

operational costs, due to the ease of maintenance resulting from its standardized,

modular organization and, due to the reduction in logistics requirements brought about

by the use of a small set of common modules.

After completion of the mission configuration analyses, the impact on the DMS hardware

and software systems could be assessed more readily. This permitted the primary hardware element of the DMS to be analyzed and described in greater detail, as subtask 2;

with the primary software element defined functionally, as subtask 3. -These elements

are the "Network Interface Unit" (NIU) and "Network Operating System" (NOS),

respectively.

The studies described above provided the basis for the identification of DMS technologies

and task 2 of the study provided a cost and criticality analysis of the several technology

items or areas identified. The approach taken in task 2 was to evaluate the role of each

item or area from the perspective of the overall Space Station program. This involved

estimates of relative need by the program, lead time, cost for development, and where

possible, estimated value over the life of the Space Station. The most critical items are

42
D180-27935-2

those that are needed early in the program, that also have long lead times. This concept

of need versus lead is explained more fully in section 3.4.

Task 3 was the preparation of technology advancement plans and the results of that task

are reported in volume III.

3.3 TECHNICAL DISCUSSION

This section describes the technical content of the data management portion of the

study. Because this was an extension of a previous study, some background material will

be presented in each portion for clarity and continuity.

3.3.1 Mission Configuration Analysis

The identification of Space Station mission requirements on the DMS considered data

communications bandwidths, data storage capacities, processing requirements, and interfacing requirements imposed by the experiments. Three example mission models were

investigated, each having different data management requirements. These include Construction and Materials Processing Station (CAMPS), Communications and Data Management Station (CADMS), and Land, Ocean, and Atmospheric Research Station

(LOARS).

CAMPS would be used for the construction of large space structures and spacecraft, plus

production of semiconductors, alloys, and Pharmaceuticals. Capabilities required in

addition to a basic DMS functions might include data handling for teleoperators, robots,

and a variety of remote sensors and effectors for construction purposes. The materials

processing payloads would require automated process control capabilities, which would

also require data management.

CADMS would provide command, control, and communications support for onboard and

free-flying payloads and experiments. It would have powerful signal and data processing

capabilities that could be shared by many experiments or spacecraft through a spacebased communications network. It would use large high-speed data storage devices such

as laser disks for archival storage of data generated and utilized on-orbit.

43
D180-27935-2

LOARS would be used primarily for remote sensing of weather, crops, sea state, and

other planetary conditions and phenomena. It would carry high-resolution, high-bandwidth imaging sensors such as the Landsat-4 thematic mapper, and the Seasat synthetic

aperture radar (SAR), but in more advanced versions. Such devices would place very high

requirements on the data management system, providing a kind of worst-case DMS

scenario. Therefore, LOARS was investigated in the greatest detail.

In the Advanced Platform Systems Technology Study (APSTS), a DMS configuration

concept known as the fiber-optic backbone network was presented. This is a local area

network suited for use aboard the Space Station because it is defined to have high

reliability, maintainability and performance, while preserving an excellent potential for

future expansion. This concept is defined to use digital baseband packet switching, as

opposed to broadband or wavelength-division multiplexing. Broadband systems typically

use a remodulator to establish connections between transmitters on one set of

frequencies, and receivers on another. Broadband systems are vulnerable to single-point

failures at the remodulator, and they require periodic adjustments to their analog and RF

circuitry, making them unsatisfactory for use aboard the station. Wavelength division

multiplexing systems typically require laser transmitters and optical multiplexers and

demultiplexers. They have advantages over long fiber runs of a kilometer or more

because many channels can be multiplexed onto a single fiber with considerable cost

savings. But, over short distances such as aboard the station, the savings in optical fiber

are insignificant and do not justify the expense and complexity of lasers and optical

multiplexing equipment.

Figure 3.3-1 shows how the backbone network might fit into a space station configuration called the raft structure. The heavy lines are bundles of optical fibers, that interconnect the network interface units, or NIUs. The NIUs are modular electronic units,

discussed in later sections, that house interface modules for the various digital and

analog electronic devices carried aboard the station. Input data generated by these

devices, such as high-bandwidth sensor data, are acquired by the NIU interface modules,

stored temporarily, formatted, and routed to specific destinations by means of digital

electronic communications or packet-switching. Specific destinations are addressable,

depending on the application. Disk or tape storage devices, tracking and data relay

satellite system (TDRSS) transmitters, and crew consoles are examples of output devices

connected to NIUs.

44
Dl80-27935-2

• INTERCOM

•CAMERA

A4.C4.G4)

OPTICAL FIBER BUNDLE

• CREW STATION

(E3.E4.F2.F3)

• FURNACE

IA2.A3.B2.B3)

• RF COMMUNICATIONS

<C2,D2.D4. E5)

NETWORK INTERFACE UNIT

• DATA STORAGE

(C3.D3.F2.F3)

STANDARDIZED

BERTHING-PORT

INTERFACE

• MEDIUM SPEED SENSOR

(G2.G3.H2)

• HIGH SPEED SENSOR

(H3.H4)

Fiber-Optic Backbone Network

45
D180-27935-2

The NIUs also support and control local data buses within each of the station modules.

These buses could be standard serial buses such as the MIL-STD-1553B; however, present

technology allows the use of higher speed buses, operating at 10-25 million bits per

second (MBPS), such as the IEEE-802 proposed standard bus. Medium-speed devices,

rather than high-speed sensors, would be connected to these buses. For example, small

Winchester disk units typically operate at 10 MBPS, and several could be distributed

about the station by connecting them to buses supported by different NIUs. This would

provide a relatively low-cost, high-performance data base, that could be expanded

almost at will by the addition of disk units.

This topology can be described as a two-level hierarchy. The NIUs and their interconnections provide for communications between station modules, and form the upper level

of the hierarchy. The devices connected to the links and buses within the modules, supported by the NIUs, form the lower level. This approach allows for modularity at both

levels. The NIUs handle inter-module communications through standard berthing-port

interfaces, allowing station modules to be plugged-in at any berthing port. At the lower

level, sensors and medium-speed devices can be plugged into the NIUs by means of standard interface cards and standard buses.

Multiple optical fibers are used for intermodule communications for several reasons.

First, optical fibers have such a large potential bandwidth for existing and projected data

communications applications that the same fiber bundles and connectors could be used

throughout the lifetime of the station, although the NIU optical transmitters and

receivers might be retrofitted at some future date. Second, the use of multiple communications channels provides for fault-tolerance, in the event of a hardware or software system failure. Third, optical fibers are nonconductive, and eliminate many

potential problems with electromagnetic interference (EMI), ground loops, sneak circuits,

or other undesirable electrical phenomena.

Fiber-optic technology is now mature enough to be used on board the station for most

data communications applications, especially if light-emitting diodes (LEDs) are used as

optical sources instead of laser diodes, and if PIN diodes are used as optical detectors.

Laser diodes have a higher power output than LEDs, but they are not as readily available

and have much shorter operating lifetimes. The lower output power of LEDs is not

necessarily a problem if point-to-point communications links are used, or if the number

of ports driven by the transmitter does not exceed a maximum of 20-30 in an optical

46
Dl80-27935-2

star-coupled configuration. Technical details on this topic are covered in the final

report from the APSTS.

At least two fiber-optic backbone network topologies are viable for space station

application and are shown in figure 3.3-2. The set of lines drawn above the boxes

represents the interconnection topology formed by the use of four optical star couplers,

located near NIUs C, D, E, and F. For example, the coupler located at NIU-C interconnects A through E, as shown by the lowest horizontal line. In this example, each of

the couplers would interconnect a subset of five of the eight NIUs, so four five-port

couplers would be required to assure a minimum of two redundant paths per NIU. The

set of lines drawn below the boxes represents a point-to-point interconnection topology.

Each link consists of a bidirectional channel, using two fibers with transmitters and

receivers at opposite ends. Store-and-forward communications techniques are used, as

opposed to the shared-bus techniques needed for the multi-star topology.

Data packets are multiplexed by means of time division multiple access (TDMA)

techniques, so that multiple data streams can share each channel. This approach

requires that a store-and-f orward capability be provided at each NIU, so that packets

can be received and retransmitted by intermediate NIUs in a series of hops to the final

destination. This naturally provides for fault-tolerance because one or more alternate

routes can be provided for use in case of a failure at one of the NIUs. Another

advantage is the low optical power requirement for transmission across a point-to-point

link. The transmitter must drive only a single optical fiber, with a single receiver.

Therefore, both the optical source and the detector can be extremely small, simple,

reliable, and low in cost.

The other viable fiber-optic topology uses multiple optical star couplers to interconnect

the NIUs. It can be thought of as a multiple bus topology, with the star couplers providing the shared bus media; or, it can be regarded as an active-repeater system, with the

NIUs functioning as the repeaters. From either viewpoint, the system is more complex

than a simple passive star-coupled topology. The star couplers are each associated with

an NIU, with several other NIUs attached at the ports. In this configuration, only a few

ports would be needed at each coupler, perhaps five, so the optical power requirements

would be quite low, allowing the use of LEDs as optical sources. This topology also provides fault-tolerance because each NIU has access to multiple star couplers, providing

alternate communications paths in the event of a failure.

47
L_JL

D180-27935-2

RAFT CONFIGURATION

INTERCONNECTIONS FOR MULTI-STAR (4)

D.

INTERCONNECTIONS FOR GRAPH

• BOTH TOPOLOGIES REQUIRE 20 OPTICAL TRANSCEIVERS

• BOTH NEED ROUTING AND RECONFIGURATION CAPABILITIES

• MULTI-STAR USES SHARED-BUS PROTOCOLS

• GRAPH USES TIME-OIVISION-MULTIPLE-ACCESS (TDMA)

Figure 3.3-2 Multi-Star Versus Graph Topologies

48
D180-27935-2

With either topology, a reconfiguration capability is needed in the NIUs so that alternate

links or couplers can be selected in the event of a failure. In both cases, the NIUs must

be able to store and forward messages or packets, because multiple couplers or links are

provided, and the NIUs are not directly connected to each other by means of a single

common bus. Both configurations can use LED sources, and PIN diode detectors. The

transmitter and receiver logic needed is essentially the same in both cases, as shown in

figures 3.3-3 and 3.3-4. These figures are block diagrams of the functions needed to

implement optical transmitters and receivers, with the exception of the control logic.

The transmitter converts digital data residing in memory to a serial bit-stream, encodes

it with clock information, and uses the resulting signal to modulate an optical source.

The receiver uses an optical detector to convert the signal back to an electrical form for

decoding and conversion to a parallel word format that can be stored in a memory

buffer. These examples use a 32-bit memory and a 100 MHz serial data rate, so the

required memory cycle time (320 ns) would be relatively slow.

The two configurations use different access protocols for multiplexing the communications media. The graph topology uses simple TDM A, while the multiple-star topology

may use polling, contention or token-passing. In a polling system, one of the NIUs

functions as a controller, polling each of the other NIUs in sequence to enable them to

transmit data on a given bus, one after the other. In a contention scheme, each NIU acts

independently and "listens" for activity on the communications channel. If the channel is

not busy, the NIU can transmit; however, two may transmit almost simultaneously,

resulting in a collision. They must detect such bus contention, back off, and try again

after a random delay interval. la a token-passing configuration, the system is initialized

so that one of the NIUs "owns" a logical token that enables it to transmit a packet.

After completing its transmission, it then sends the token to another NIU, which may

transmit and then pass the token to the next NIU in sequence.

At this point, no clear reason exists for choosing either a pure graph or a pure multiplestar topology over the other. Communications network simulation studies are needed

before a final configuration can be chosen. The next section describes the NIU concept

in greater detail.

49
D180-27935-2

ENCODED BIT-SERIAL OUTPUT

32

LOW-SPEED

PARALLEL

-3 MHz

OPTICAL

TRANSMITTER

HIGH-SPEED

SERIAL OUTPUT

- 100MHz

(LIGHT-EMITTING

DIODE)

Figure 3.33 NIU: Transmitter Block Diagram

50.
D180-27935-2

ENCODED BIT-SERIAL INPUT

,KEY TECHNOLOGY

OPTICAL

RECEIVER

HIGH-SPEED

SERIAL INPUT

-100 MHt

(PIN DIODE)

X

<

/

DECODERDEMODULATOR

MEMORY

(QUEUES)

\

NIU INTERNAL BUS

DATA

CLOCK

X

X

3Z

» „ -„. ... ,_,_ LOW^3>FFP

PARALLEL DATA

~3MHl

V

>

Figure 33-4 NIU: Receiver Block Diagram

SI
D180-27935-2

3.3.2 Network Interface Unit Internal Organization

As shown in figure 3.3-5, the NIU is defined as a set of standard circuit cards that plug

into a high-speed parallel data bus, housed in a rack-mountable chassis. The cards provide high-speed sensor control and data acquisition interfaces, instrumentation bus interfaces, fiber-optic intermodule communications transceivers, and many other types of

input-output (I/O) interfaces and controllers. A set of standard modules can support a

great many applications such as data acquisition through analog/digital converters, discrete I/O functions such as indicator lamp illumination or switch position-sensing and

man-machine interfacing by means of keyboard and CRT controllers. Customized

modules can also be added to the NIUs to support subsystems, payloads or specialized

sensors.

A central processor unit (CPU) with associated memory is also shown in figure 3.3-5.

Conceptually, this might be a high-performance 32-bit microprocessor if its only function is control of the NIU. However, multiple processors could also be installed in the

NIU or connected to it through interfaces, to handle the onboard data processing tasks.

Some of these could be specialized signal or image processors, or floating-point array

processors, if they are required for onboard applications.

The main design conclusions reached as a result of this study are that the NIU should be

modular, and should have a high performance potential. Space Station requirements will

surely change over a period of many years. The basic NIU chassis and high-speed parallel

bus can support such changes and upgrades if they are designed with flexibility in mind.

The bus should have a 32-bit data path, with a minimum capability to transfer data

words at a 16MHz rate. At 512 MBPS (32 * 16MHz) this bus has a bandwidth about five

time greater than a super-minicomputer bus (e.g., VAX-11/780) of today. This is enough

capacity to handle approximately 20 compressed digital TV channels, or thousands of

digital voice channels. It is possible that future high-speed devices could generate data

at higher rates, but such applications may be quite rare, and could be served by customized interface modules that handle data without involving the NIU bus.

Development of NIU modules .would be a major project, because a dozen or more standard electronic interface modules would have to be specified, designed, and fabricated to

meet most of the potential station applications such as data acquisition or subsystem

interfacing.

52
D180-27935-2

A/*-

s

SENSOR

INTERFACE

j

i

CPU

ft

MEMORY

INSTRUMENT

INTERFACE

COAXIAL

BUS

V

/ NIU INTERNAL BUS: 32-BIT » 16 MHi \

X

_

i

1

FIBER

OPTIC

XCVR

1

OTHER

INTERFACES

FIBER

OPTIC

XCVR

f

•

1. MODULAR NETWORK INTERFACE UNIT

2. STANDARDIZED INTERFACE MODULES

3. HIGH-SPEED INTERNAL PARALLEL BUS

Figure 33-5 NIU: Internal Organization

53.
D180-27935-2

Twelve such modules have been identified this far and they are listed as follows:

1. NIU control processor and cache memory.

2. Fiber-optic communications transceiver.

3. Instrumentation bus interface controller.

4. RF communications transceiver interface.

5. Digital voice communications interface.

6. Crew station console/CRT interface.

7. High-speed sensor data buffer.

8. Magnetic tape mass memory controller.

9. Magnetic disk mass memory controller.

10. Color video & graphics I/O controller.

11. Analog I/O interface.

12. Discrete digital parallel interface.

Figure 3.3-6 shows how typical DMS modules might be supported by the parallel and

serial buses. High speed devices such as a CPU or a video interface would be installed in

the NIU chassis and connected to the internal bus backplane or motherboard. Low and

medium speed devices would be attached to the serial buses. Each NIU could be-configured differently to support the equipment or applications within each station module;

however, each would have a control processor and fiber-optic transceivers for network

comm unications.

Other custom modules would also be needed for specialized applications such as high

speed sensors. The software needed to provide DMS services (i.e., network operating

system) would also require a major development effort, and should be done in conjunction

with NIU development.

3.3.3 Network Operating System (NOS)

An operating system is the collection of software processes that control computer systems, as shown in figure 3.3-7. In a distributed system environment, or in a local area

network, the term "network operating system" is frequently used, and has been adopted

here. Aboard the Space Station, the NOS is conceived to have two major functions.

First, it provides the operating environment for users of the DMS. Second, it manages

54
Dl80-27935-2

I— FIBER-OPTIC XCVR

I— RF XCVR INTERFACE

.— VIDEO I/O

DEVICES WITHIN SINGLE MODULE

F

0

X

C

V

R

R

F

1

N

T

F

V

1

D

E

0

C

P

U

B

U

F

F

E

R

1 .

N

S

T

B

U

S

A

DIGITAL

VOICE

INTERFACE

t

CREW

STATION

INTERFACE

j

ANALOG

I/O

INTERFACE

INSTRUMENTATION BUS (10-25 MBPS)

CPU,J

DATA BUFFER —'

INSTRUMENTATION —'

BUS INTERFACE

CONTROLLER

1

1 1

MAGNETIC

DISK

CONTROLLER

1

MAGNETIC

TAPE

CONTROLLER

r

DISCRETE

PARALLEL

INTERFACE

NIU

CHASSIS

• OTHER EQUIPMENT MAY

BE ADDED AS REQUIRED

Figure 33-6 NIU Functional Partitioning

55
r

Dl80-27935-2

(EACH BOX REPRESENTS SOFTWARE RUNNING ON A SEPARATE PROCESSOR)

R/r COMM SERVER

DATA

COMMUNICATIONS

NETWORK

SUBSYSTEMS AND EXPERIMENTS

Figure 3.3-7 Network Operating System Example

56
D180-27935-2

the overall operation of the devices attached to the network, supporting status monitoring and control functions, and providing data storage, communications and processing

services.

The NOS does not necessarily control the station systems or subsystems. Such functions

depend on the NOS for computational support, and for control of interfaces, displays,

keyboards and other devices that are used to operate the onboard systems. The actual

control software for the various subsystems may be embedded in the devices, or may run

on the applications processors provided by the DMS. Either way, the NOS is only

indirectly involved in control of station subsystem application tasks. However, the NOS

directly provides the user operating environment, as with any other kind of computer

system. That is, in order to use the Space Station DMS resources, the crew, ground control engineers and operators, and remote scientific users will have to interact with the

NOS. The user will enter commands by means of a console keyboard and display device,

and will receive responses or status reports from the NOS by the same means. For

example, commands would be entered to activate a synthetic aperture radar, steer its

antenna to a given azimuth, acquire data for a given interval, process that data to

generate high-resolution imagery, display the image on a video monitor, store it on a

video disk, and downlink it to ground-based operators or investigators. Such a complicated sequence of operations could be initiated by a crew console command, or could be

activated automatically by a command or signal from a ground control station. The NOS

thus provides the capabilities that allow local or remote users to access payload data,

initiate or schedule activities, run programs, monitor status, and to use the facilities

provided by the DMS.

The NOS must also manage system functions within the DMS. This is a particularly

important consideration for critical subsystems that utilize DMS processors, data base

facilities, or communications links. For example, the health and status of the subsystems will be monitored by ground control, at least during the early stages of station

operation. The data collected from onboard sensors such as temperature, pressure and

attitude, will need to be formatted into messages and downlinked to ground sites. The

processors and data communications interfaces and equipment needed are part of the

DMS, and are controlled by the NOS.

Many such functions are critical, in that equipment failures could result in loss of automated control functions, or loss of ground control and communications. Computer and

57
D180-27935-2

electronic systems are subject to random failures, even though space-qualified devices

may be utilized. For example, all known semiconductor devices are vulnerable to upsets

or permanent damage from cosmic radiation, and computer memories are particularly

sensitive. The only solution appears to be the provision of redundant equipment, with a

capability for reconfiguration in the event of a failure.

Reconfiguration of a large distributed system or LAN can potentially be accomplished

automatically, but the impact on system performance may be unpredictable. At a minimum, the basic operational capabilities of the system should be maintained, even though

certain payloads or instruments might have to be shut down. Automatic fault detection

within the DMS may be accomplished by use of built-in test (BIT) logic and software

diagnostics. However, selection of alternate processors or communications paths, and

shutdown of noncritical equipment should be a function of the NOS, under the control of

one or more executive processes running on the DMS computers. Development of an

automated diagnostic and reconfiguration software system, as part of the NOS, appears

to be a major task. So-called nonstop computer systems exist, but they are not in common usage, and are not 100% effective. Considerably more research is needed if such a

capability is to be available for use aboard the station. A key approach needed for such

a technology development is the use of software simulation to model the DMS and the

NOS, and to test the response of the system to the injection of simulated faults.

3.4 SUMMARY OF RESULTS

This section focuses on the specific technologies identified in the study, that are necessary or beneficial in the data management area. They are discussed above, but this

section highlights the key areas, with some discussion of the technical merits of each

item. The discussion is broken into two main segments. First, the results of the technical effort (task 1) are summarized. Second, the analyses of criticality, cost and

program lead-time (task 2) will be discussed. This leads to the conclusion and recommendations in subsequent sections.

3.4.1 Task 1 Results

The technical effort was completed before the midterm review, and a total of sixteen

candidate technology items were reported as worthy of development or extended study.

The items were derived in part, by addressing the mission configuration analysis, the NIU

58 .
D180-27935-2

assessment, and the NOS subtask from three viewpoints: (1) what technologies are

needed for DMS development; (2) what are those needed to provide a basic DMS operational capability; and (3) what are those needed to provide DMS support to missions such

as LOARS, CAMPS, and CADMS. For example, items 2 and 13 below would be needed to

develop the DMS, while items 1 and 5 would be needed to support the LOARS mission.

The breakdown is representative of an advanced DMS; however, the use of modularity

would allow the system to be gradually built-up to this level of capability, with missionspecific technologies incorporated last. The configuration analysis subtask led to the

identification of eight items, as follows:

1. High-speed sensor data buffer.

2. Payload development system.

3. Maintenance expert system.

<f. Space-qualified disk or bubble memory.

5. Onboard digital image processor.

6. Interactive crew workstation.

7. Adaptive digital control system.

8. DMS simulation software package.

The NIU description subtask resulted in the identification of five technology items or

areas, as follows:

9. Decoder-demodulator integrated circuit.

10. Fiber-optic input/output interfaces.

11. Standard NIU data buses (internal and external).

12. Standardized microcomputer board set.

13. Interface verification test set.

The NOS definition subtask resulted in the identification of three software technology

items for development, as follows:

i

M. Real-time NOS executives.

15. Layered communications protocols.

16. Distributed voting/diagnostic algorithm.

59.
D180-27935-2

Task two resulted in some modifications to the priorities for each of the items or areas,

based on program criticality, cost, and estimated lead time. These considerations are

discussed in the next major section. The following paragraphs provide a brief description

of the purpose or need for each item.

3.4.1.1 High-Speed Sensor Data Buffer

The high-speed sensor data buffer is needed for data acquisition from radars, CCD telescopes, and other sensors that will have their signal outputs digitized. The data buffer is

a semiconductor memory that can be loaded with considerable amounts of data at very

high speeds. The data can later be read out of the buffer and stored in an archival

memory or transmitted to the ground, at a much lower speed, whenever convenient. For

example, 800 dynamic memory ICs, with a one-megabit capacity each, would provide 100

million bytes of high-speed data storage. Such chips should be commercially available

during the late 1980s.

3.4.1.2 Pay load Development System

The payload development system would allow laboratories or contractors to develop

flight hardware that is compatible with the onboard DMS, in a straightforward fashion.

The development system would consist of a DMS compatible computer, a version of the

NOS, and a NASA-approved high-order programming language package.

3.4.1.3 Maintenance Expert System

The maintenance expert system is a software package that would be used to aid crew

members in on-orbit repairs or scheduled maintenance. It would have a graphics output

capability for display of technical diagrams, and would also have a set of troubleshooting

rules or techniques programmed in to aid the crew members in fault isolation. Software

diagnostics and BIT circuitry could also be included.

3.4.1.4 Space-Qualified Disk or Bubble Memory

The space-qualified disk or bubble memory would provide online data storage for an onboard database. Currently, tape recorders are used in most space applications, but they

provide very slow access to data, and are unsuitable for many database applications.

Disks would provide the required speed, but reliability, rotational momentum, and uncertainties about head behavior in a microgravity environment might pose problems.

Magnetic bubbles are a potential solution, but commercial availability may be low.

60
D180-27935-2

3.4.1.5 Onboard Digital Image Processor

An onboard digital image processor would have applications in the reduction or compression of data prior to storage or downlink. It could also be used in materials processing and life sciences laboratories for automated inspection of samples such as

crystals or blood cells.

3.4.1.6 Interactive Crew Workstation

The interactive crew workstation would allow convenient access to the DMS database,

and would provide a means for system command and control. It might include color

graphics capability and could also allow access to the maintenance expert system.

Multiple workstations would be located in various station modules.

3.4.1.7 Adaptive Digital Control System

An adaptive (or adaptable) digital control system would consist mainly of a set of standard software routines that could be used for different control system applications aboard

the station. It would provide support for sensor data acquisition through use of control

processes running on DMS computers. The control programs would also monitor the

status of subsystems or equipment and would issue commands to drive relays, pumps, or

other actuators and effectors. The approach would tend to reduce software development

costs by providing a common library of functions that could be used in many control

applications.

3.4.1.8 DMS Simulation Software Package

The DMS simulation software package is described in sections 3.5 and 3.6 and basically

would allow detailed testing of the DMS network hardware and software before a

commitment is made to a specific design approach. That is, software models of DMS

devices, communications links and software processes could be evaluated or traded,

before development.

3.4.1.9 Decoder-Demodulator Integrated Circuit

A decoder-demodulator integrated circuit would reduce the complexity of high-performance digital communications receivers, by replacing many discrete components in each

receiver. This circuit is critical because it extracts data from an incoming modulated

signal, and largely determines the achievable data rate (high) and error rate (low).

61
D180-27935-2

3.4.1.10 Fiber-Optic I/O Interfaces

The fiber-optic I/O interfaces are the transmitters and receivers used in the NIUs to

establish high-bandwidth digital baseband communications throughout the station. They

include buffer memories, modulators and demodulators, optical sources and detectors

and control circuitry. These interfaces plug into the NIU high-speed parallel bus.

3.4.1.11. Standard NIU Data Buses

The standard NIU data buses are described in sections 3.3.1 and 3.3.2, and include the

NIU internal high speed parallel bus, as well as the local serial buses within the station

modules. The.intermodule communications are handled by the fiber-optic I/O interfaces

described above. The internal parallel bus connects standard CPU and interface boards

within the NIU, as described in the next paragraph, while the local buses provide interfacing points for the medium-speed devices (10-25 MBPS) within each module.

3.4.1.12 Standardized Microcomputer Board Set

The standardized microcomputer board set could take two forms. Many system interfacing requirements could be satisfied by a set of common modules that plug into the

NIUs. The other type would be used in payloads, instruments or other station equipment.

The primary advantage in having a set of standard modules is the reduction in life cycle

costs brought about by reduced logistics and maintenance difficulties. Customized

circuit boards could be used where required, but duplication of functions would increase

the number of spares that would have to be carried aboard the station and might cause

supply problems over a period of many years.

3.4.1.13 Interface Verification Test Set

The interface verification test set would be used by station contractors to validate their

equipment inhouse, before installation in the station modules. It would consist of standard interface connectors, circuitry and software, plus diagnostic software to exercise the

various attached devices.

3.4.1.14 Real-Time NOS Executive

The real-time NOS executive consists of the software processes that control the DMS.

Each computer in the system would have an executive process running continuously to

schedule tasks, control attached devices, and handle communications.

62
D180-27935-2

3.4.1.15 Layered Communications Protocols

Layered communications protocols are the commonly accepted method for providing

communications within a network. The lowest layers provide direct control of hardware.

Successive layers are added to provide greater sophistication until the application layer

is reached. The application layer gives users access to the network communications

facilities.

3.4.1.16 Distributed Voting/Diagnostic Algorithm

The distributed voting/diagnostic algorithm would be used for automatic fault detection

in the DMS. Box or module level redundancy would probably be used. For example, if

box level redundancy is chosen for a functional area, critical processes would be

executed on multiple processors with the results cross-checked by interprocessor

communications. If at least three processors execute the same function and reach the

same result, then the critical function can be initiated. If the results disagree, at least

one of the processors must be in error and must be reset, tested, or shut down.

Diagnostic routines could be run periodically, in the same way, to continuously test DMS

health and status for either box level or module level redundancy.

3.4.2 Task 2 Results

/

In task 2 the goal was to evaluate each of the technology items or areas in terms of costs

and benefits to the Space Station program. The specific approach taken in the DMS area

was to estimate the time of need for the technologies, the required lead time, the development cost and risk, and the value or savings over the life of the station. Figure 3.4-1

summarizes the need, lead, cost, risk, and value for each technology, and the following

paragraphs discuss the rationale for that data.

The 16 technology areas identified during task one were scored in five categories, with a

rating of 0, 10, or 20. For example, a technology needed early in the program is more

critical to success than one that is needed late, so a score of 20 would be assigned. The

total scores give a rough estimate of the program criticality of each of the 16 technologies. That is, an area with a high score is an area that has a likelihood of greater

program impact. An area with a low score, such as the high-speed sensor data buffer,

may still be important; however, low cost and risk, combined with a late need and relatively short lead time mean that the relative program impact is quite low.

63
SCORING

Dl80-27935-2

EARLY LONG

MID MID

LATE SHORT

HIGH HIGH HIGH

MID MID MID

LOW LOW LOW

TECHNOLOGY AREA | NEED LEAD | COST | RISVALU K E TOTAL

HARDWARE

•STANDARD CARDS

•STANDARD BUSES

• P.O. TRANSCEIVERS

•DECODER CHIP

20

20

10

10

10

20

10

10

20

10

10

10

10

0

10

10

20

20

10

10

80

70

50

50

SOFTWARE

•SIMULATOR

• EXECUTIVES

• PROTOCOLS

• DIAGNOSTICS

20

20

20

10

10

10

10

0

10

20

10

0

20

10

10

0

20

20

20

10

80

80

70

20

GENERAL SYSTEMS

• PAYLOAD DEV. SYS,

• MAINTENANCE EXP.

• IMAGE PROCESSOR

•CONTROL SOFTWARE

• INTERFACE TEST SET

• CREW WORKSTATION

• DISK/BUBBLE MEM.

•DATA BUFFER

20

10

0

10

20

10

10

0

20

10

20

10

10

0

0

0

10

10

20

10

10

0

0

0

10

20

20

10

0

0

0

0

20

20

10

10

10

10

10

10

80

70

70

50

50

20

20

10

Figure 3.4-1 Criticality of Technologies

64
D180-27935-2

3.4.2.1 High-Speed Sensor Data Buffer

The high-speed sensor data buffer will be needed after the station becomes operational

to support imaging sensor payloads. It seems to pose no great difficulties in terms of

lead time, cost, or risk, except for the possibility of data disruption by cosmic radiation.

This type of sensor data is not flight critical, and the upset problem should be

manageable if error detecting and correcting codes are used to preserve data integrity.

The primary savings will be in the elimination of high-speed onboard recorders, and the

related maintenance and replacement costs because semiconductor memories are very

reliable compared to electromechanical devices.

3.4.2.2 Payload Development System

The payload development system is, by definition, required for development of payloads

for various onboard applications and is therefore an early-need item. Choice of a

processor, language, and a set of I/O interfaces for a wide variety of applications are the

greatest difficulties. The main value is commonality and standardization, with savings in

development cost due to reduction of duplicated effort at different facilities.

3.4.2.3 Maintenance Expert System

A maintenance expert system would be very useful to crew members in troubleshooting

and scheduled maintenance. However, this is an emerging technology that will need

considerable amounts of time and money for development. The value would be high

because it could save one-half of a crew member's time, or more, but it is also a highrisk development item.

3.4.2.4 Space-Qualified Disk or Bubble Memory

This memory would support an onboard database, and would be used primarily for station

operations, rather than for experiment data storage. The disk would be a development

from existing technology and would involve high risk only if its rotational momentum

caused unacceptable torques, or if the microgravity environment resulted in unpredictable read/write head behavior. A magnetic bubble memory is a viable alternative, that

involves no moving parts. It would not have mechanical problems and should be very

reliable, but availability of space qualified bubble memory chips is in doubt. Therefore,

this technology involves some risk, but seems essential for normal station operations.

65
D180-27935-2

3.4.2.5 Onboard Digital Image Processor

An onboard digital image processor would be an advancement from current technology.

Such specialized processors are in use in medical imaging laboratories and at NASA

facilities. With new (VHSIC/VLSI) technology, it should be possible to package and

qualify such a processor for the station, but it would probably be quite expensive to

develop because a considerable amount of software is also needed. The main value would

be a reduction in the need for high-bandwidth imagery transmission to and from groundbased facilities because digital imagery could be enhanced or otherwise processed

onboard.

3.4.2.6 Interactive Crew Workstation

An interactive crew workstation would be an advanced data entry and display console

utilizing advanced microelectronics and software. Examples of advanced technologies

are flat panel displays, high-resolution color graphics, multifunction keyboards, and

expert systems. The workstation would be needed for normal operations and would have

a high value because of potential increases in crew productivity. The risk would be

relatively low if this is viewed as an evolutionary development. That is, only the

essential capabilities would be implemented early in the program, with enhancements

added later.

3.4.2.7 Adaptive Digital Control System

This technology would be needed for development of onboard control systems early in the

program. That is, if a common library of control system software is to be of use, it will

have to be available when the systems are implemented and tested. The risk is probably

less than the risk of developing and integrating ten or more separate and independent

control software packages, and the same rationale appears to apply in terms of life cycle

cost reduction. Therefore, the value could be quite high.

3.4.2.8 DMS Simulation Software Package

If a simulation package is to be utilized in the early stages of DMS design, it will

obviously have to be developed very soon. It could be used later in the program to help

determine the impact of system modifications, but its primary value is in the early

analysis and trade study phases when different system concepts must be evaluated. The

DMS simulation software package has the highest priority of any of the technologies

addressed in this study. The main risk is that the simulation runs might have poor

66
D180-27935-2

verisimilitude, that is, if a true representation of the DMS is not modeled accurately, the

simulations may be useless or detrimental to station development.

3.4.2.9 Decoder-Demodulator Integrated Circuit

This 1C would be needed when the station becomes operational, but discrete logic

circuits could be used to support DMS development. It would not be a tremendously

complicated circuit because it would consist primarily of a phase-locked loop and a few

shift registers. However, it might be difficult to achieve high data rates with current

technology. The primary value would be a reduction in the complexity of onboard digital

communications receivers, including those used for intermodule optical communications

links.

3.4.2.10 Fiber-Optic Input/Output Interfaces

As with the decoder-demodulator 1C, the optical I/O interfaces would be needed at the

IOC point, but the remainder of the DMS could be developed using alternate means of

digital communications. The space-qualified interfaces could be substituted before the

station enters its operational phase. The main risk seems to be the potentially low

reliability of the optical sources and detectors, and the fragility of the optical connectors. The primary values appear to be high bandwidth potential for video and high-speed

sensor data distribution, and electrical isolation between equipment located in different

space station modules.

3.4.2.11 Standard NIU Data Buses (Internal and External)

The primary advantages of bus standardization appear to be ease of systems integration,

and reduced development and life-cycle costs due to equipment commonality. The NIU

internal parallel bus, and the intra-space-station module serial buses will be needed

during system development. They are an advancement from current technology, and

seem to pose no great risks. However, once specified, they will probably have to serve

as standards throughout the life of the station. Therefore, they should be evaluated and

specified very carefully, to ensure that sufficient performance and growth potential are

provided to serve station requirements over many years. The DMS simulation software

package should be of considerable value in this analysis and specification process.

3.4.2.12 Standardized Microcomputer Board Set

A standardized set of circuit boards could be developed relatively easily, and would be of

considerable use in various subsystems, instruments, and experiments. Most such appli67
D1SO-27935-2

cations will require a small amount of data processing capability for status monitoring,

control, or data collection; and microcomputer technology is well suited for these roles.

If standard boards are to be used, then early development is essential. The main values

are reduced development and life-cycle costs, due to a reduction in duplicated hardware,

reduced software development costs, and limitations in the variety of spares that must

be procured and carried onboard the station. Early obsolescence is a potential disadvantage; however, if the boards are configured for a standard parallel bus, such as the NIU

internal bus, then new versions can be introduced as technology developments warrant.

3.4.2.13 Interface Verification Test Set

An interface verification test set would be required early in the development program,

to ensure that different contractors conform to DMS interfacing standards and communications protocols. Lead time may be a problem because the standards and protocols

must be developed first. Development of the test set should be relatively straightforward from that point, especially if the standard board set can be utilized. The

primary value is ease of systems integration over the life of the station.

3.4.2.14 Real-Time NOS Executive

The NOS executive modules provide all DMS control and operational functions and are

needed early in the program to allow integration of equipment into the DMS. This area

involves the greatest potential risk and cost in the software area because flight critical

functions may be involved, as well as all DMS-user support capabilities. Efficiency, high

performance and fault tolerance are crucial to program success.

3.4.2.15 Layered Communications Protocols

The DMS cannot function without communication protocols. They are needed for early

systems integration and should remain constant over the life of the space station. Such

protocols have been in use for several years (e.g., ARPANET) and do not require technological breakthroughs for implementation. However, specification of the protocols

will have significant implications in terms of reliability and efficiency of onboard and

external communications. The protocols must be carefully analyzed and specified; this

process will almost certainly require the DMS simulation package described above.

3.4.2.16 Distributed Voting/Diagnostic Algorithm

If the DMS is to have a fail-safe, fail-operational capability, then some means of automatic fault detection is clearly required, at least for critical functions. An algorithm

68.
D180-27935-2

that uses multiple distributed modules or boxes to cross-check computational results is

needed by the time the station enters its operational phase. The primary risk is that the

algorithm may cause a considerable amount of processing overhead, or that it may

operate unreliability. Its value is in the reduction of risk with respect to crew safety and

mission success.

3.5 CONCLUSIONS

The work performed during this study led to conclusions in three main areas, involving

data management system configurations, system hardware (NIU) and system software

(NOS). Three potential mission configurations were analyzed, with the Land, Ocean, and

Atmospheric Research Station (LOARS) model developed in enough detail for simulation

studies to commence. The NIU was analyzed to the point where component technologies

could be identified; and the NOS was defined to a level of detail that included identification of software functions and their functional interrelationships. These analyses

were then used in the second part of the study, task 2, to help in the evaluation of the

need for each technology in terms of program phase, plus estimates of relative cost, risk

and value to the program. This work is summarized in figure 3.4-1.

In the previous study, development of the NIU was estimated to cost $9.4M and the NOS

development was estimated to cost $6.0M. The RCA PRICE computer model was used

for these estimates, as described in volumes n and IV of the Advanced Platform Systems

Technology Study. During the present study, a third estimate derived from in-house

experience was made for development and use of a DMS software simulation package.

Over a six-year period, leading to space-qualified hardware and software, development

and use of the simulator is estimated at $6.85M, as described in volume III of this report:

"Technology Advancement Program Plan."

Incorporation of the simulator, the NIU and the NOS recommendations provide the greatest cost savings to the program. The total cost of development for the three items is

$22.25M over six years. With estimated development cost savings to the program of

$176M, primarily in reduced systems integration costs, the ratio of benefits (savings) to

cost is 7.9. That is, for every dollar spent on network simulation, hardware (NIU) and

software (NOS), NASA can expect savings in DMS development cost of almost eight

dollars. The potential savings in operating costs are also considered to be quite significant, and are worth investigating in future studies. Space Station DMS development

69
D180-27935-2

involves critical paths. That is, some technologies are needed before others, and are in

fact needed to facilitate their development. The most critical technology area appears

to be computer-aided engineering (CAE), or computer simulation of networks and

complex data systems.

Simulation is an essential analysis tool for DMS development. If an adequate simulation

capability is available, then logical models of system components can be developed and

evaluated in different configurations with optimization as the primary goal. The station

has many potential missions and operational requirements that must be fully evaluated

before advanced development can begin. Hence, a DMS simulation system is the most

valuable analysis tool that could be used in preliminary configuration studies.

After the optimum system architecture has been defined, implementation can begin.

This will likely involve development of engineering models first, with flight hardware to

follow. This will require standardization of system hardware and software interfaces and

communications protocols to facilitate systems integration. DMS system components

and functions will be under the control of software executives that reside on DMS computers. Therefore, the processors, interfaces, buses, protocols, and executives will have

to be specified and developed very early in the program, after simulation studies. Then,

development of applications, payloads, experiments and subsystems can begin, insofar as

the DMS is involved. That is, those areas that require DMS services can be developed

independently up to a point until they reach the place on their critical paths where the

DMS services are absolutely necessary. At that time, the DMS must be up and running,

at least in a preliminary form, or Space Station developmental progress will be hampered

at best, or halted at worst.

3.6 RECOMMENDATIONS

As a result of this study, it is recommended that DMS simulation capabilities be developed first, so that potential mission configurations and the interactions between DMS

hardware and software components can be fully analyzed in time to support space station

full-scale development.

The other technologies needed for DMS development have almost as high a priority as

the simulator. Two such items were identified during this study, as follows:

70
D1SO-27935-2

a. Interface verification test set.

b. Payload development system.

The test set would be of great benefit to contractors, and the development system would

be useful to experimenters or entrepreneurs who wish to develop DMS-compatible payloads. Of the remainder of the sixteen technology items, none could be eliminated as a

result of this study. They are all needed to enter the space station full-scale development phase, but are of a less urgent nature. Simulation is the most urgent technology

item, and because of its early use in space station development, it is discussed in more

detail with second tier recommendations.

Simulation of large data systems is a computer-aided engineering (CAE) technique that

can greatly reduce development costs, while increasing system effectiveness. Almost by

definition, large systems and networks are extremely complicated and are usually quite

costly. Before committing large sums to the design of such a system, a model should be

developed using simulation software package to give an early indication of system

behavior in realistic scenarios and to allow a degree of optimization prior to actual

development.

Selection of the final DMS architecture from the results of this study would be premature but progress has been made in the development of tools to support that decision.

Also, of the three mission models considered in the first part of the study, the Land,

Ocean, and Atmospheric Research Station (LOARS) model has been developed in enough

detail to allow initial modeling and simulation activities to begin as an internal R&D

project supported by BAG.

As mentioned above, one of the purposes of this effort is to determine how fault-tolerance can be implemented in the DMS. Figure 3.6-1 shows how the simulation could be

used to inject errors and hard faults into the model, to determine the impact on system

functionality, and to test the performance of automatic reconfiguration algorithms. The

simulation consists of several software modules, as shown in the diagram. The most

important are the packet producers, servers, consumers, and the instrumentation module.

Producers simulate the production of messages or packets that, in a real system, would

be transmitted by the devices that make up the DMS. The servers simulate the behavior

of the network communications components and software protocols. Consumers are the

71
D180-27935-2

FEEDBACK LOOP

NETWORK

SERVERS

QUEUE SIZE

INSTRUMENTATION

SOFTWARE

(ERROR MODELS)

(FAULT MODELS)

FLOW

CONTROL

ERROR

CONTROL

FAILURE

RECOVERY

DISPLAYS

ft

'' DOCUMENTS

FEEDBACK LOOP

Figure 3.6-1 DMS Closed Loop Simulation

72
D180-27935-2

devices to which the messages or packets are sent. And finally, the instrumentation

module performs data collection and simulated fault injection.

When fully devloped, the simulation package would allow the user to design a network

interactively, using a color graphics terminal. Models of the devices attached to the

network are entered into the system database, and graphical representations will be

displayed on the color monitor, including the network interconnections. The simulation

output consists of statistical measurements acquired by the instrumentation module,

displayed graphically as letters, numbers and colors. For example, the symbol for a

failed device could be displayed in red, and the utilization of a communications link

displayed as a numerical percentage.

Simulation allows the use of modern CAE techniques in DMS design, in the same way

that integrated circuits are designed and simulated prior to fabrication, and for the same

reasons. Simulation can give an excellent indication of system performance before

major resources are committed to production and various concepts can be traded and

compared to produce an optimal design.

73
D180-27935-2

4.0 LONG-LIFE THERMAL MANAGEMENT

4.1 INTRODUCTION

The objective of the present long-life thermal management study was to identify heat

transport system technologies that increase performance, enhance system life, and

reduce system weight and cost. Emphasis was placed on two-phase heat transport systems that may offer significant performance benefits. These systems absorb and reject

heat at a near constant temperature. This isothermal characteristic simplifies thermal

interfaces and allows heat loads to be placed at any available location thereby providing

a high degree of flexibility in reconfiguring the space station. Reduced pump power

requirements and heat transport by latent heat of vaporization provide size and weight

reductions compared to a conventional pumped liquid-loop heat transport system. These

comparisons made possible the identification of new technology areas requiring advancement.

The two technology areas identified were—

1. Two-phase water thermal transport loops for inhabited environments.

2. Pumps and heat exchangers for liquids in the nearly-saturated state in zero gravity.

The study approach, technical discussion of study, results, conclusions, and recommendations are presented in the following sections.

4.2 APPROACH

The overall study was divided into three tasks outlined below:

Task 1

1. Define baseline pumped two-phase heat transport system.

2. Optimize baseline system.

3. Identify optional systems.

a. Pumped liquid loop.

b. Capillary two-phase.

c. Alternate two-phase pumping concepts.

74;
D180-27935-2

Task 2

1. Compare baseline and optional systems.

2. Select technologies for advancement.

Task 3

1. Develop technology implementation plan.

This section of the report describes the task 1 and task 2 efforts.

The study groundrules are described in section 4.3.1, and the basic heat transport

systems are defined in section 4.3.2. The detailed technical discussion for system

optimization and comparison is covered in sections 4.3.3-4.3.8. The summary of results,

conclusion, and recommendations are presented in sections 4.4, 4.5, and 4.6,

respectively.

Detailed analyses were performed for pumped two-phase, capillary two-phase, and

pumped liquid-loop systems. These systems share common elements (pipes, radiators,

heat exchangers) and each must be optimized to provide a valid comparison. Consequently, the technical discussion is based primarily on system elements rather than on a

task 1 and task 2 division.

*.3 TECHNICAL DISCUSSION

4.3.1 Groundrules for Study

The following basic groundrules we're established for the study:

1. Platform total heat load: 25-150 kW.

2. Transport distance: approximately 150 ft one way.

3. Grumman Space Constructable Radiator 1.2 Ib/ft^.

4. Power penalty: 350 Ib/kW.

5. Heat transport fluids:

a. Two-phase: ammonia.

b. Pumped liquid: Freon 11, Freon 114, ammonia.

6. Low temperature (about 40°F) heat rejection for metabolic and battery heat loads.

7. High temperature (about 80°F) heat rejection for remaining loads.

8. Radiation sink temperature: 415°R.
D180-27935-2

9. Pumped water heat transport loop inside pressurized modules.

10. Elements for each system:

a. Radiator.

b. Cold plates.

c. Pressurized module interfaces.

d. Transport loop.

11. Thermal storage interface inclusion is beyond scope of study.

During the course of the study results showed that there were only minor differences

between Freon 11 and Freon 114. Consequently, the detailed analyses were completed

for Freon 11 only. It also became apparent that a two-phase water heat transport

system inside the pressurized modules offered benefits and was added to the study.

The groundrules listed here were augmented by a baseline space station definition (sec.

4.3.7.1). This further definition was required for the heat transport system comparison

on an overall system basis.

4.3.2 Heat Transport Systems

Figure 4.3-1 shows the basic heat transport systems that were analyzed in this study.

The baseline is a pumped two-phase system with a liquid and vapor lines. A mechanical

pump is used to pump the liquid condensate from the radiator to the heat source heat

exchangers (evaporators). Control valverizing a two-phase heat transport systems within

the long life requirement constraints. Each of these approaches produced useful

advancements in the understanding of technology issues and development needs.

The overall study was divided into four tasks. During task 1 the design concepts required

in each of the four study areas were refined and comparative studies were conducted.

The pumped liquid loop is similar to the baseline system except that the heat is

transported as sensible heat rather than as latent heat of vaporization.

Alternate pumping concepts were briefly considered for the baseline pumped two-phase

system. One concept would use an osmotic pump in the liquid line. The liquid would

consist of a solvent and solution separated by a semipermeable membrane. The osmotic
Dl80-27935-2

^

PUMP

1.

—XX

;UMJ>

< -

BASELINE

PUMPED TWO-PHASE

SYSTEM

- COLO

* PLATE MX

PRESSURIZED

J MODULE

WATER LOOP

~" INTERFACE

COLO

~ PLATE MX

H

THERMAL

STORAGE

^H

1 r 1

n

I »

j

.j

n

« ^

r

4

«

PUMP

t

CA

PU

SY

•*

3

PILLARY

MPED TWOPHASE

STEM

COLO

PLATE MX

PRESSURIZED

MODULE

WATER LOOP

INTERFACE

MX

COLO

PLATE MX

THERMAL

STORAGE

^^

1

^M

t 1

«

PU

^

t

p

4

PUMPED

LIQUID LOOP

SYSTEM

COLO

f* PLATE MX

PUMP PRESSURIZED

C ^ MODULE

WATER LOOP

1— INTERFACE

..<M^— M*

L^

Dud .

 COU>

L

I _ _

THERMAL

STORAGE

u

-]

1

^IH

» i

J

»

1

1

J

Figure 43-1 Heat Transport Systems

77
D180-27935-2

pressure across this membrane causes solvent flow through the membrane into the solution. The solvent evaporates from the solution at the evaporators, condenses in the

radiator, and returns to the membrane. The other concept considered uses an ion drag

pump. This pump uses a high voltage probe to generate and accelerate ions in the fluid.

These ions exchange momentum with the fluid and produce the pumping action.

4.3.3 Heat Transport Loop Sizing

4.3.3.1 Pumped Two-Phase Transport Loop

The pumped two-phase loop consists of a pumped liquid supply line to the evaporators

and a vapor return line to the radiator. The weight of the loop includes line weight, fluid

weight, and pump power penalty. For turbulent flow (cases of interest are in turbulent

flow regime) and small wall thickness compared to line diameter, the weight per unit

length of line (vapor or liquid) is given by

T75)

 D^75

Po = density of line material (aluminum in present study)

t = wall thickness

D = inside diameter

P = fluid density

y = fluid viscosity

hf = latent heat of vaporization

o

Q = heat load

H = power penalty

Y = pump efficiency

The factor F includes a factor to account for additional pressure losses due bends,

valves, etc. (assumed to be 25% in this study) and a factor to account for the load

distribution along the line. Two load distribution cases were considered. The most

severe case is that of the load being concentrated at the opposite end of the loop from

the radiator. In this case F = 1.25. The other case is that of a uniform load distribution

along the loop where F = 1.25/2.75.

78
D180-27935-2

The assumed minimum wall thickness is 0.03 inches and is increased as necessary to keep

the wall stress below 5000 psi (based on fluid vapor pressure at 125°F). For the

increased wall thickness cases, t is proportional to D and an analytical expression can be

found for the optimum diameter that minimized the weight per unit length. Otherwise,

the optimum diameter must be determined iteratively.

Two-phase ammonia heat transport loops were optimally sized as a function of heat load

for high (86°F) and low (32° F) temperature systems. The line sizing, pressure drop and

pumping power, and weight per unit length are shown in figures 4.3-2, 4.3-3, and 4.3-4,

respectively.

For the pumped two-phase transport loop the optimization is essentially independent of

other system component (e.g., radiator) optimizations. The vapor line pressure drop will

provide a coupling of the transport loop optimization to other system component optimizations since this gives rise to a difference in evaporation and condensation temperatures (i.e., an additional temperature drop between heat source and radiator). This

temperature difference, however, is insignificant for the two-phase ammonia systems

considered in this study.

4.3.3.2 Capillary Two -Phase Transport Loop

The capillary two-phase loop is similar to the pumped two-phase system except that the

pumping action is provided by surface tension. The loop weight consists only of line and

fluid weight. The weight per unit length (of total transport distance) is

fPo [(tD)v +(tD)i] +{ [(PD2)V

where subscript v refers to vapor and 1 refers to liquid.

The vapor and liquid line sizes are constrained by the surface tension pumping capacity

per total (previously, a detailed analyses of the thermal storage interface was beyond the

scope of the study.)

The capillary two-phase system is similar to the baseline system, except pumps arid

valves are not required. The capillary wicks in the heat exchangers provide the required

transport length.

79
D180-27935-2

0.09

2D

to

ut

I

u

z

7

oc

UJ

UJ

g

tn

Z

FLUID: AMMONIA

LINES: ALUMINUM

PUMP EFFICIENCY: 25%

POWER PENALTY: 350 LBS/KW

MINIMUM WALL THICKNESS: OJD30 INCH

MAXIMUM WALL STRESS: 5000 PSI AT 125<>F

PIPE FLOW PRESSURE DROP INCREASED

25% FOR BEND. VALVE, ETC. EFFECTS

SIZE BASED ON MINIMUM WEIGHT

CONFIGURATION

0.08

VAPOR

LINE ID

1JO

HEAT LOAD AT

OPPOSITE END OF

BUS FROM

RADIATOR

VAPOR LINE

WALL

THICKNESS

HEAT LOAD

UNIFORM

ALONG BUS

0.07

I

0.06 £

I

o

m

0.05 5

o

mCA

0.04

0.03

LIQUID LINE WALL

THICKNESS

0.0

25 50

0.02

75 100

HEAT LOAD - KW

125 150

Figure 4.3-2 Pumped Two-Phase Bus Sizing

80
D180-27935-2

.025

-°2°

I

CL

O

cc

o

Ul

.015

I -

010

LU

e

a.

.005

PRESSURE DROP

25 50 75 100 125 150

0.5

0.4

I

cc

ID

o

I

.

o

I o^

Q.

0.1

0.0

PUMPING POWER

HEAT LOAD AT OPPOSITE

END OF BUS FROM RADIATOR

UNIFORM HEAT LOAD

ALONG BUS

BUS LENGTH IS COMBINED

LENGTH OF LIQUID AND

VAPOR LINES

25 50 75 100

HEATLOAD-KW

125 150

Figure 4.3-3 Optimized Pumped Two-Phase Ammonia Bus Pressure Drop and Pumping Power

81.
D180-27935-2

0.7

OJ6

0.4

o

LU

w 03

to

0.1

OJD

FLUID: AMMONIA

PUMP EFFICIENCY: 25%

POWER PENALTY: 350 LBS/KW

PIPING MATERIAL: ALUMINUM

MAXIMUM WALL STRESS: 5000 PSI AT 125°F

MINIMUM WALL THICKNESS: OJD30 INCH

WEIGHT INCLUDES: FLUID. WALL AND PUMPING POWER PENALTY

PIPE FLOW PRESSURE DROP INCREASED 25% FOR BEND, VALVE.

ETC. EFFECTS

WEIGHT IS BASED ON COMBINED LENGTH OF LIQUID AND VAPOR

TRANSPORT LINES

HEAT LOAD LOCATED AT

OPPOSITE END OF BUS

FROM RADIATOR

HEAT LOAD UNIFORMLY

DISTRIBUTED ALONG BUS

25 50 75 100

HEAT LOAD ~KW

125 150

Figure 4.3*4 Pumped Two-Phase Bus Weight for Optimized Liquid and Vapor Line Sizes

82.
D180-27935-2

FQ l.75

nw/l = _ — - r 75

Pjghfg1'

75

where

hw = wicking height capacity (1-g)

g = acceleration of gravity (1-g)

For a given wicking height to transport length and heat load these equations can be used

to determine optimum vapor and liquid line diameters that minimize the transport loop

weight. The weight and line sizing for an optimized capillary two-phase transport loop is

shown in figure 4.3-5 for the high temperature bus and figure 4.3-6 for the low temperature bus. Also shown are reference points for a 300-ft transport distance with a 100 kW

high temperature load and a 25 kW low temperature load. The reference points assume a

wicking height capability of 1 inch under normal gravity. This corresponds to a wick

pore diameter of 0.020 inches for the high temperature case and 0.025 inches for the low

temperature case.

4.3.3.3 Pumped Liquid Transport Loop

The pumped liquid transport loop sizing is similar to that for the pumped two-phase case

except the flow rate is an independent variable. In this study the flow rate variation is

implicit in the fluid temperature change. The weight per unit transport length is given

by

Wt/1 . Po,D .

where

Cp = specific heat of fluid

AT = fluid temperature change

For a given heat load to temperature change ratio, this equation can be solved iteratively to determine the optimum diameter that minimizes the weight. Figure 4.3-7

shows the optimized pumped liquid transport loop weight for Freon 11, Freon 114, and

ammonia. The transport loop^optimization is coupled to the optimization of other

system components through its dependence on fluid temperature change.

83
Dl80-27935-2

CD

3D

2.5

2.0

1.5

1

K

I

2 1.0

S

0.5

0.0

WEIGHT

0 1 INCH WICKING HEIGHT

300 FT TRANSPORT LENGTH

100 KW HEAT LOAD

CONCENTRATED LOAD F - 125

i i i i i i i

TRANSPORT LENGTH

HEAT LOAD

WICKING HEIGHT (1-g)

CONCENTRATED LOAD

125/225 UNIFORM LOAD

i i i t i i i i

0.1 02 OJ5 0.7 IjO 2D 3.0 5.0 7JO 10JO

v>

Ui

I 4

_

t- 3

UJ

LINE SIZING

334

LIQUID LINE

0.1 02 0.3 0.5 0.7 ID 2.0 3.0 5D 7JO 10D

10"6 F £ Q1'

75

 - FT-KW1'

75/INCH

Figure 4.3-5 Optimized Capillary Two-Phase Heat Transport Loop (Ammonia)

(High Temperature Bus — 86° F)

84
D180-27935-2

15

1.0

0

1

H

O

05

0.0

WEIGHT

© 1 INCH WICKING HEIGHT

300 FT TRANSPORT LENGTH

25 KW HEAT LOAD

CONCENTRATED LOAD F -

.01

0598 LBS/FT

TRANSPORT LENGTH

HEAT LOAD

WICKING HEIGHT J1.9)

I ill

.02 J03 JOS £7 0.1

CONCENTRATED LOAD

125/2.75 UNIFORM LOAD

02 03 05 0.7 1.0

to

u

3.0

25

2.0

HI

iu

< 15

a

LU

z

2

 1.0

05

0.0

LINE SIZING

I i i_

258 IN

1.14 IN

VAPOR LINE

LIQUID LINE

.01 .02 J03 .05 .07 0.1 02 03 05 0.7 1.0

10"6 F £ Q1'

75/ - FT^<W1

-

75/INCH

Figure 4.3-6 Optimized Capillary Two-Phase Heat Transport Loop (Ammonia)

(Low Temperature Bus *~ 32°F)

85
D180-27935-2

30

20

10

7

5

^

£

o

0.7

OS

03

0.2

• PUMP EFFICIENCY: 25%

• POWER PENALTY: 350 LBS/KW

• PIPING MATERIAL: ALUMINUM

• MAXIMUM WALL STRESS: 5000 PSI AT 12S°F

• MINIMUM WALL THICKNESS: 0.030 INCH

• PIPE FLOW PRESSURE DROP INCREASED

25% FOR BEND. VALVE, ETC. EFFECTS

• WEIGHT INCLUDES: FLUID, PIPE

AND POWER PENALTY

AMMONIA

HEAT LOAD AT END OF

LOOP OPPOSITE RADIATOR

HEAT LOAD UNIFORM

ALONG LOOP

0.1

05 0.3 06 07 U) 2 3 5 7 10

HEAT LOAD/FLUID TEMPERATURE CHANGE - KW/°F

20 30 50

Figure 4.3-7 Pumped Liquid Loop Weight for Optimized Line Size

86
D180-27935-2

4.3.4 Heat Exchanger Models

The system heat exchanger weights are a major factor in system optimization and consequently in comparing different systems. Figure 4.3-8 shows the heat exchanger models

used for this study. A discussion of these models is presented in the following sections.

.1 Two-Phase Heat Exchanger

The two-phase heat exchanger model was based on the Grumman prototype design shown

in figure 4.3-8 and no optimization of the design was attempted. The heat exchanger

core weight, assuming a channel height of 0.2 inches (Grumman's design appears to have

a total thickness of 0.2 inches) and equal volumes of metal and liquid in the liquid

channel/support structure region, as

Wtc = WL (Pv/75 +p!/600 +po/600) Ib

W = heat exchanger width - ft

L = heat exchanger length - ft

P = density lbs/ft3

subscripts v, 1, o refer to vapor, liquid, and metal, respectively.

The core weight was used for comparison with liquid heat exchangers where the optimized core weight is used (sec. 4.3.4.2). The cover sheet weight was included (for both

two-phase and liquid systems) in the radiator panel heat exchangers (sec. 4.3.5) where

the length and width are fixed values.

The heat transfer coefficient to thermal conductivity ratio was taken as 6000 (ft)'*.

(This corresponds to a Nusselt number of 5 and a characteristic dimension of 0.01 inches

which is typical of heat pipe evaporators.) Due to the liquid channels the effective heat

transfer coefficient for the heat exchanger is reduced to 80% of this value. Using this

effective heat transfer coefficient the heat exchanger core weight can be related to the

heat transfer rate and temperature difference, for example,

WtC = P2+g(Pl+Pn

105.4k

87
Dl80-27935-2

LIQUID LOOP

HEAT EXCHANGER

PASSAGE DETAIL

—b

DIMENSIONS a>^

SELECTED TO OPTIMIZE

SYSTEM

TWO-PHASE BUS

CONDENSER/EVAPORATOR

\ —

•WICK

VAPOR

CHANNEL

LIQUID CHANNEL &

SUPPORT STRUCTURE

GRUMMAN PROTOTYPE DESIGN

Figure 4^8 Heat Exchanger Models

88
D180-27935-2

where

k = liquid thermal conductivity (BTU/ft-hr-°F)

Q = heat transfer rate across one face of heat exchanger (kW)

AT = temperature difference between vapor and heat exchanger face (°F)

4.3.4.2 Single-Phase (Liquid) Heat Exchanger

The single-phase heat exchanger model (shown in figure ^.3-8) requires a detailed analyses to optimize the design parameters (a, b, and c). The core weight includes the metal,

liquid, and pumping power penalty. For cases of interest the flow through the heat

exchanger is laminar and the core weight is given by

Wtc = CLWP0 ( +

+

b/a a > + ( > - U + b/a) (1 + c/a)2 m2

where m = mass flow rate

For given b/a and c/a ratios the optimum c dimension for minimum weight is

t r?iy> (1 + b/a)2 (1 + c/a)2 .m*

C=

 V P2J P0(P/P0 + b/a) V

Noting that at the optimum c value, the material weight is three times the power penalty weight

where c is the optimum value.

The effective heat transfer coefficient can be shown to be

, . tanhot' .

. 1 + (c/a) -g — ; j_±£/g.

"eff = 1 +b/a -

 ( 2c

where Nu = Nusselt number (taken as 5 in this study)

_, a=

+c/a)/k x . N u

T

ko = thermal conductivity of metal

89
D180-27935-2

CX1 = a for one side only heat transfer

= 2 a for two side heat transfer

The effective conductance to weight ratio is (using the optimum c value)

_ _ _

Wt ~8 pc 24Y m

where

r

* ~ b/aXp/p0

A = LW

For a given c/a ratio, the optimum b/a ratio can be found that maximizes £ , and thus

minimizes the heat exchanger weight to effective conductance ratio.

As the c/a ratio increases the heat exchanger weight to effective conductance ratio

asymptotically approaches a minimum value. For c/a large with respect to unity

^

=

 (1 +b/a)(p/p0 + b/a)K

and the optimum b/a is independent of c/a as is the heat exchanger weight to effective

conductance ratio. This approximation was used for all liquid heat exchangers except for

those coupled to the radiator panels where, due to the coupling with other conductances,

an optimum value of c/a exists (sec. 4.3.5.2).

The heat exchanger core weight can be written as

Wtc =

where Q = heat transfer rate

*

s

 f

90
D180-27935-2

The liquid heat exchanger weight depends on the wall boundary condition. For a uniform

heat flux boundary condition

: Q_

A = heat transfer area ^

ATW = temperature difference between wall and fluid (constant for constant

Nusselt number)

The heat exchanger weight for this case is then

Wtc = 6

w

where

6 = l/^ for one side heat transfer

= 1/2^ for two side heat transfer

This boundary condition case was used for cold plate heat exchangers and balanced counterflow heat exchangers.

For a uniform wall temperature case

w

where, in this case,

ATW = smallest temperature difference between wall and fluid

The heat exchanger weight for this case is then

In (1 + AT )

•

 w

/

This boundary condition case was used for liquid loop heat exchangers interfacing with a

two-phase heat exchanger.

91
D1SO-27935-2

4.3.5 Radiator Sizing

The Grumman space constructable radiator was used as the radiator model for both twophase and pumped liquid-loop heat transport systems analyses. This radiator model is

shown in figure 4.3-9. Heat pipe radiator panels are clamped together with a heat

exchanger unit sandwiched between them. The required radiator area is provided by

placing the required number of radiator panel/heat exchanger units adjacent to each

other. The radiator panel properties (size, weight, emissivity, fin effectiveness, panel,

and contact thermal conductances) are based on Grumman's design values. The environmental radiation sink temperature was set at 415°R for the present study. This value is

representative of a steerable radiator in low earth orbit with a completely degraded ( s

= € ) thermal coating.

4.3.5.1 Two-Phase System Radiator

The two-phase bus/radiator panel interface heat exchanger used for the radiator analyses

is described in section 4.3.4.1. The thermal balance for one heat exchanger unit coupled

with two radiator panels is

Q = 2K(TB - TR) = 2 e OTIA(TR^ - TS^)

Q = heat rejection rate

K = Thermal conductance from vapor to one radiator panel

1

L +L +L

KF KC

Kp = vapor to heat exchanger for conductance

= contact conductance between heat exchanger face and radiator panel (1 167

BTU/HR-°F)

= radiator panel conductance (1000 BTU/HR °F)

£ = panel emissivity (0.8)

F) = fin effectiveness (0.58)

A = panel area (100 ft2)

Tg = two-phase bus temperature

= radiator fin root temperature

= sink temperature

92
Dl80-27935-2

HEAT PIPE RADIATOR PANEL

'

1

1

/v •

V

1

I

f

J

HEAT EXCHANGER

- TR)

HEAT REJECTION RATE PER PANEL (BTU/HR)

Q • Kp (T|y • T|y) " (Tyy • Tp)

C-OJB

n-o.58

A-100 FT2

Ts - SINK TEMPERATURE <°R)

'I'

THERMAL MODEL (ONE-HALF OF SYMMETRICAL MODEL)

CONTACT

CONDUCTANCE

(500 BTU/FT2-HR-°F)

FLUID

CONDUCTANCE

PANEL NOT*: INTERFACE BASED ON GRUMMAN SPACE

CONSTRUCTABLE RADIATOR (NASA JSC

RADIATOR PANEL CONTRACT NAS9-15965)

CONDUCTANCE

KR-10000TU/HR-°F

HEAT

EXCHANGER

Figure 43-9 Heat Transport Loop/Radiator Interface

\

93
D180-27935-2

The vapor to heat exchanger conductance Kp for ammonia is 3200 BTU/HR-°F. This

gives an overall conductance K of 461 BTU/HR-°F.

For a given bus temperature Tg an iterative solution to the thermal balance provides the

heat rejection rate per radiator panels/heat exchanger unit. The radiator system weight

required to reject this heat load consists of heat exchanger and radiator panels weight.

The heat exchanger weight for ammonia as a working fluid and aluminum as the metal is,

including 0.05-inch face sheets, 4.2 Ib. The weight of the two radiator panels (1.2 lb/ft2)

is 120 Ib. The radiator system weight per unit heat rejection rate is the total weight

(124.2 Ib) divided by the heat rejection rate Q found from the thermal balance equation.

Figure 4.3-10 shows the resulting radiator system weight as a function of two-phase bus

temperature.

4.3.5.2 Pumped Liquid Loop System Radiator

The pumped liquid loop/radiator panel interface heat exchanger model is described in

section 4.3.4.2. The thermal balance for one heat exchanger unit coupled to two radiator

panels is (similar to two-phase system).

Q = 2K (Tin - TR) = 2 eOr)>A(TR* - TS^)

v .

where Tjn is the fluid inlet temperature to the heat exchanger unit and the overall

thermal conductance is defined as previously with the fluid conductance Kp now

given by

KF = m^E (1 _e- 2MfjV) r

 2 mCp

m = mass flow rate through unit

AC = contact area (2.33 ft2)

The radiator system weight includes, as before, the radiator panels and heat exchanger

weight. The heat exchanger weight consists of cover sheets (identical to two-phase analysis) and core weight as described in section 4.3.4.2. The liquid loop system radiator

analyses is more complicated than that for the two-phase system because the mass flow

rate through the radiator panel heat exchanger units depends on the flow routing and the

overall fluid temperature change. An additional complication is the weight optimization

for each flow condition.

94
Dl80-27935-2

too

90

7 " *-

su

£ 70

to

S

O 60

60 L,

&

40

40

BUS FLUID: AMMONIA

SINK TEMP: 415°R

RADIATOR SYSTEM WEIGHT

RADIATOR PANELS

HEAT EXCHANGERS WITH FLUID

60 60 70

BUS TEMPERATURE ~°F

80 90

Figure 4J3-1Q Radiator System Weight for Two-Phase Bus

95
D180-27935-2

The pumped liquid-loop system radiator optimization was performed as follows.

1. Select heat rejection rate for a set of radiator/heat exchanger units connected in

series flow. This fixes the relationship between mass flow rate and fluid temperature change for a given fluid.

2. Select a fluid inlet temperature to the radiator system.

3. Select the overall fluid temperature change through the set of radiators.

4. For a given heat exchanger c/a ratio determine the optimum b/a ratio (iterative

procedure) and calculate the fluid conductance Kp and heat exchanger weight.

5. Determine number of radiator panels/heat exchanger units required to reject the

specified heat load. This is accomplished by iteratively solving the thermal balance equation for each unit. The radiator system fluid inlet temperature is used as

the inlet temperature to the first unit and the first unit's outlet temperature is

used as the inlet for the second unit, etc. When the total temperature change

exceeds the specified value, the final unit is prorated (i.e., fraction of a unit) to

provide the specified temperature change.

6. Calculate radiator system weight by multiplying the required number of units times

the weight per unit.

7. Determine minimum radiator system weight by incrementing heat exchanger c/a

value (using an appropriate algorithm) and iterating (from step d.) until the optimum c/a is found.

8. Select new overall fluid temperature change and repeat calculation (from step c.)

to determine the minimum weight for this condition. An iterative procedure could

be used here to find the optimum temperature change for the radiator system.

However, because the fluid temperature change affects the weight of other system

components, the optimum change must be based on the overall system optimization.

96
D180-27935-2

9. Select a new inlet fluid temperature and repeat calculations from step b. The

radiator system weight decreases monotonically with increased inlet temperature.

The absolute maximum inlet temperature is limited by the allowable equipment

temperature and the optimum value must be determined on an overall system

weight basis.

10. Select a new heat rejection rate for a set of radiator/heat exchanger units and

repeat calculation from step a. This would allow the optimum flow routing to be

determined for various conditions.

A limited investigation of the effects of flow routing showed the radiator weight per unit

heat rejection rate to be insensitive to specified heat rejection per set of radiation

panel/heat exchanger units over a wide range of values. Consequently, a convenient (and

near optimal) value of 25 kW per set of series connected units was chosen for this study.

The pumped liquid loop system radiator optimization provides the minimum radiator

system weight as a function of radiator inlet temperature and overall fluid temperature

change. Figure 4.3-11 shows an example of optimum radiator system weight for an inlet

temperature of 70°F. As noted previously, the optimum inlet and outlet temperatures

must be determined from an overall system optimization.

4.3.6 Pressurized Module Pumped Water Loop

The manned (pressurized) modules of the space station have a pumped water heat transport loop that transports waste heat to the main heat transport system by means of an

interface heat exchanger. In order to compare two-phase and pumped liquid main transport systems, these internal water loops and associated heat exchangers must be included

in the system analyses.

4.3.6.1 Two-Phase Main Heat Transport System

Figure 4.3-12 shows the model used to analyze the water transport loop coupled to a

two-phase bus. The water loop is coupled to the two-phase bus by means of an interface

heat exchanger. One side of this heat exchanger is a two-phase heat exchanger (sec.

4.3.4.1) and the other side is a liquid heat exchanger (sec. 4.3.4.2). These heat exchangers are assumed to be in intimate contact (or an integram unit) so that there is no temperature drop across the interface itself. The heat load to the water loop is applied

97
Dl80-27935-2

90

80

i

o

uj 70

8

I

I

60

SO

40

FREON

11 & 114

SINK TEMP: 415°R

RADIATOR SYSTEM WEIGHT

RADIATOR PANELS

HEAT EXCHANGERS WITH FLUID

PUMPING POWER PENALTY

RADIATOR INLET: 70°F

AMMONIA

> HEAT EXCHANGERS OPTIMIZED TO

MINIMIZE SYSTEM WEIGHT

' 25 KW HEAT REJECTOR PER SET OF

RADIATOR PANELS. SERIES FLOW WITHIN

SET OF RADIATOR PANEL/HEAT

EXCHANGER UNITS. PARALLEL FLOW

TO SETS.

10 20 30 40 60

RADIATOR OUTLET TEMPERATURE -°F

60 70

Figure 4.3-11 Radiator System Weight for Liquid Loop Heat Transport System

98
D180-27935-2

VAPOR

TWO-PHASE BUS

TEMP -T

B

INTERFACE

HEAT EXCHANGER

PRESSURIZED

MODULE

WATER LOOP

HOT WATER

^ TEMP-T,H

EVAPORATOR

CONSTANT WALL TEMP

HEAT EXCHANGER

EQUIPMENT COLD

PLATE

(CONSTANT WALL HEAT

FLUX HEAT EXCHANGER)

OHEAT LOAD - Q

LIQUID

INTERFACE

TEMP - TW

COLD WATER

TEMP - To

WATER

PUMP

EQUIPMENT

TEMP-T.

Figure 43-12 Two-Phase Bus/Water Loop Interface

99
Dl80-27935-2

through a cold plate heat exchanger unit. The weight of the pressurized module loop

consists of the pumped water loop itself (lines, water, pump power penalty) and the heat

exchanger units.

The water loop itself can be optimized as a function of heat load to water temperature

change as outlined in section 4.3.3.3. The heat exchangers can be optimized, as a set, in

terms of heat load, water temperature change, and equipment to bus temperature difference. The total weight of the heat exchangers is (see sec. 4.3.4)

Q = heat load

Te = equipment temperature

TB = bus temperature

c = v * l n (See sec. 4.3.4.1)

B = constant for liquid heat exchanger (see sec. 4.3.4.2)

" Te-TB

AT = water temperature change

<fc 9- leilH

" Te-TB

TH = hottest water temperature

= Interface temperature (i.e., two-phase heat exchanger wall temperature)

The temperature ratio variables (£ ,<fi ,and T ) can be optimized to give a minimum total

heat exchanger weight for a given heat load, bus, and equipment temperatures. For

these given conditions, the weight of the water loop is based on the water temperature

difference corresponding to the optimized value for the heat exchangers. A more

refined analysis would include the water loop weight in the optimization of . The overall effect of this refinement, however, is expected to be small.

4.3.6.2 Pumped Liquid-Loop Heat Transport System

There are two cases to consider for the pumped liquid-loop heat transport system interface with the pressurized modules. One case is that in which there are separate heat

transport systems for the high- and low-temperature heat loads. The other case is where

100
D180-27935-2

the same loop is used for both high and low temperature loads. The models for these

cases are shown in figure 4.3-13.

The analysis of the separate loop case is similar to that for the two-phase system

described in the previous section. In this case, the interface heat exchanger is a balanced counter flow device and the optimized set of heat exchangers weight can be written analytically as

WtHX =

where Tjn = radiator inlet temperature and subscripts m and w refer to the main

loop and water heat exchangers, respectively.

The total heat exchanger weight for the single-loop system includes that of the humidity

control heat exchanger in addition to that of equipment cold plate and interface heat

exchangers. The total heat exchanger weight for this case is

T HX

 • T TTr ? (1-)

 +

4>+(Qe/Q) -(f^if1

T =

in

AT

= water temperature change

Q = total heat load

Qe = equipment heat load

humidity control heat load

humidity control temperature

Te-TB

For given Qe, QHC, Te, TJ-JC> and Tjn an optimum <j> value can be found that minimizes

the weight at a given value of the parameter T . The range of values for this parameter

is restricted by the constraints that the main loop liquid entering the interface heat

exchanger must be above the freezing point of water and the water temperature leaving

101
D180-27935-2

SEPARATE (HIGH AND LOW TEMP) SYSTEMS

MAIN PUMPED LOOP

TO RADIATOR TEMP - Tin

PRESSURIZED

MODULE

WATER LOOP

INTERFACE HEAT

EXCHANGER

(BALANCED

COUNTER FLOW HEAT

EXCHANGER)

HOT WATER

EQUIPMENT COLD

PLATE (CONSTANT

WALL FLUX HEAT

EXCHANGER)

HEAT LOAD •= Q

SINGLE SYSTEM

FROM RADIATOR

COLD WATER

TEMP - Tc

WATER

PUMP

EQUIPMENT

TEMP - T.

MAIN PUMPED LOOP

4

TO RADIATOR TEMP «= Tjn

PRESSURIZED

MODULE

WATER LOOP

EQUIPMENT t\

HEAT LOAD V

EQUIPMENT

TEMP-Te

INTERFACE

HEAT EXCHANGER

(BALANCED

COUNTERFLOW HEAT

EXCHANGER)

HOT WATER

TEMP - Tu

EQUIPMENT COLD

PLATE (CONSTANT

WALL FLUX HEAT

EXCHANGER)

COLD WATER

TEMP - Tc

WATER

PUMP

HUMIDITY CONTROL

(CONSTANT WALL

FLUX HEAT

EXCHANGER)

METABOLIC

HEAT LOAD

°HC

HUMIDITY

CONTROL

Figure 4.3-13 Pumped Liquid Loop/Water Loop Interface

102
D180-27935-2

the humidity control unit must be less than the humidity control temperature. These

limits are

Tin-32°F

For given equipment specifications (Qe, QHC» Te, THC)> the total pressurized module

water loop weight (heat exchangers plus loop itself) depends on the radiator inlet temperature Tjn and water temperature change. The optimum value of these parameters

must be based on total system weight considerations.

4.3.7 Space Station Thermal Control System Sizing

4.3.7.1 System Definition

In order to compare space station heat transport systems a baseline space station must

be defined. The following space station parameters were used as a baseline for comparison:

1. Total heat load: 125 kW.

2. Round trip heat transport distance: 300 ft.

3. Radiation sink temperature: -45°F (415°R).

4. Equipment temperature: 85°F.

5. Battery and humidity control temperature: 40°F.

6. Heat load distribution:

a. Equipment (85°F) 100 kW.

(1) five unpressurized 10 kW cold plates.

(2) five pressurized module 10 kW cold plates.

b. Battery (40°F) 20 kW.

(1) two unpressurized 10 kW cold plates.

c. Humidity control (40°F) 5 kW.

(1) five pressurized module 1 kW units.

d. Load distribution along loop assumed to be midway between uniform and

concentrated distribution cases.

e. Separate high and low temperature two-phase heat rejection systems.

f. Capillary system wicking height of 1 inch under normal gravity (1-g).

g. Single pumped liquid loop system (battery cold plate in series flow downstream of radiator in order to maintain a high radiator inlet temperature and

that allows a reduction of radiator area).

103
Dl80-27935-2

h. Water heat transport loop inside pressurized modules.

i. Materials: aluminum for main transport loop and stainless steel for water

loop.

j. Main transport fluid: ammonia for two-phase systems and Freon 11 or ammonia for pumped liquid loop systems.

The heat load and transport distance are representative of a relatively mature space

station. The baseline system assumes use of solar panels with battery storage. (A system utilizing fuel cells would require consideration of a higher temperature heat source.)

Separate high and low temperature two-phase systems are used to minimize total system

weight. The pumped liquid loop systems have the entire flow from the radiator pass

through the battery cold plates before passing through any other heat exchangers. This

constraint, on battery placement and flow routing, allows the radiator inlet temperature

to be maintained at a high level, which minimizes the radiator size and weight. The

pumped liquid loop is representative of current state of the art and the pumped liquid

ammonia loop system allows direct comparison with the two-phase ammonia systems.

4.3.7.2 Two-Phase System Optimization

The two-phase bus (pumped and capillary), equipment cold plates, pressurized module

heat exchangers and water loop, and radiator weights were calculated for the baseline

space station at various bus temperatures. (The details of these calculations were described in the previous sections.) Figure 4.3-1* shows the high temperature system elements and total weight as a function of bus temperature. The pumped and capillary twophase systems are identical except for the bus weight itself. The minimum weight for

both systems occurs at a bus temperature of about 70°F. Detailed sizes, weights, and

temperatures are shown in the high temperature system schematic (fig. 4.3-15).

The low temperature system element weights are shown in figure 4.3-16 as a function of

bus temperature. The minimum total system weight occurs at a bus temperature of

about 36°F. A detailed schematic for this optimum low temperature system is shown in

figure 4.3-17.

4.3.7.3 Pumped Liquid-Loop System Optimization

For the given baseline space station conditions the pumped liquid loop systems have an

optimum liquid temperature change that minimizes the system weight at a given inlet

temperature to the radiator. Figure 4.3-18 shows the pumped Freon system element

104
D180-27935-2

7000

6000

TOTAL WEIGHT

(CAPILLARY SYSTEM)

RADIATOR

SYSTEM

SCALE

1500V CHANGE

1250

1000

750

500

250

> SCALE

10V CHANGE

TOTAL WEIGHT

(PUMPED SYSTEM)

PRESSURIZED

MODULE

PLATE

EXCHANGES

(CAPILLARY SYSTEM)

PUMPED

WATER LOOPS

BUS (PUMPED SYSTEM)

EQUIPMENT

COLD PLATES

60 65 70 75

BUS TEMPERATURE ~ °F

80 85

Figure 4.3-14 High Temperature Two-Phase Ammonia System

105
D180-27935-2

VAPOR

LINE

PUMPED SYSTEM

1.82 INCH ID

0.056 INCH WALL

150 FT LENGTH

60LBS

0.28 PSID

73 WATTS*

70°F

CAPILLARY SYSTEM

3.47 INCH ID

0.107 WALL

150 FT LENGTH

218 LBS

RADIATOR

100 KW

70°F

4805 FT2 (ONE SIDE)

5766 LBS (PANELS)

192 LBS (HX-S)

3JD2PSID

15.8 WATTS

70°F EQUIPMENT

COLD PLATE

85°F, 10 KW

70°F

OJBLBS

14JBLBS

70°F

71J61°F.

81j36°F

PRESSURIZED

MODULE

>- INTERFACE H

HEAT EXCHANGER

10 KW

70°F

-X71J61°F

22J5LBS

1J53PSID

21.4 WATTS 00

OJ942 INCH ID

0.020 INCH WALL

50 FT LENGTH

25.6 LBS

17,3PSID

24 3 WATTS

EQUIPMENT

COLD PLATE

850F. 10 KW

72JB6°F

, , 5.1 PSI

w

 70.1 WATTS

26.4 LBS

1 JO PSID

25 J WATTS

PUMPED SYSTEM

0.496 INCH ID

0.030 INCH WALL

150 FT LENGTH

16.3 LBS

3JB4PSID

14.7 WATTS

CAPILLARY SYSTEM

1.77 INCH ID

OJ054 INCH WALL

161 LBS

TOTAL

PUMPED CAPILLARY

EQUIP 6484 LBS 6777 LBS

POWER 443 WATTS 355 WATTS

TOTAL 6638 LBS 6901 LBS

* INCLUDED AS PUMP POWER IN ANALYSES. HOWEVER. MOST OF POWER

(71.9 WATTS) PROVIDED BY WASTE HEAT

*• PUMPED SYSTEM ONLY

Figure 4.3- IS. Two-Phase Ammonia High Temperature System Schematic

106
D180-27935-2

I-

§8

2800

2700

2600

2500

2400

2300

2200

2100

250

200

150

100

50

10

5

TOTAL WEIGHT /

(CAPILLARY SYSTEM) /

TOTAL WEIGHT

(PUMPED SYSTEM)

RADIATOR

SYSTEM

> SCALE

CHANGE

PRESSURIZED

MODULE HEAT

EXCHANGERS

BUS (CAPILLARY SYSTEM)

BUS (PUMPED SYSTEM

PUMPED

WATER

LOOPS

SCALE

CHANGE

BATTERY

COLD PLATES

30 32 34 36 38

BUS TEMPERATURE ~ °F

40

f/^are 4.3-16 Low Temperature Two-Phase Ammonia System

107
Dl80-27935-2

36°F

VAPOR

LINE

PUMPED SYSTEM

1.305 INCH ID

OJ040 INCH WALL

150 FT LENGTH

30J6LBS

0233 PSID

37.1 WATTS *

CAPILLARY SYSTEM

230 INCH ID

0.071 INCH WALL

150 FT LENGTH

953 LBS

RADIATOR

25 KW

36°F

1885 FT2 (ONE SIDE)

2263 LBS (PANELS)

75 LBS (HX-S)

63 PSID

5j4 WATTS

CO

36°F BATTERY

COLD PLATE

400F.20KW

36°F

•><-

4 LBS

3.7 LBS

36°F

36JBO°F

39J08°F

PRESSURIZED

MODULE

h INTERFACE -|

HEAT EXCHANGE

KW

36°F

-XJ.

36.600F

3J6LBS

0.7 PSID

4.0 WATTS

0.634 INCH ID

OJD20 INCH WALL

25 FT LENGTH

7 LBS

1.1 PSID

62 WATTS

HUMIDITY

CONTROL

UNIT

40°F. 1 KW

36.94°F

CO

24PSID

' 13.6 WATTS

42 LBS

0.6 PSID

3.4 WATTS

LIQUID

LINE

PUMPED SYSTEM

0255 INCH ID

0.030 INCH WALL

150 FT LENGTH

6.8 LBS

6JQ8PSID

52 WATTS

CAPILLARY SYSTEM

1J04 INCH ID

0.032 INCH WALL

150 FT LENGTH

53.6 LBS

TOTAL

PUMPED CAPILLARY

EQUIP 2472 LBS 2533 LBS

POWER 110 WATTS 68 WATTS

TOTAL 2510 LBS 2607 LBS

' INCLUDED AS PUMP POWER IN ANALYSES. HOWEVER. MOST OF POWER

(36J9 WATTS) PROVIDED BY WASTE HEAT.

*• PUMPED SYSTEM ONLY

Figure 4.3-17 Two-Phase Ammonia Low Temperature System Schematic

108
Dl80-27935-2

14000r

13000

12000

11000

10000

9000

<

3000

2500

2000

1500

1000

500

<

100

50

TOTAL

MAXIMUM

 WEIGHT

'LIMIT ON WATER

I SUPPLY TO HUMIDITY

I CONTROL UNIT

RADIATOR

SYSTEM

SCALE

CHANGE

32°F LIMIT ON

BATTERY COLD PLlATE

OUTLET TEMPERATURE

PRESSURIZED

MODULE HEAT

EXCHANGE

PUMPED FREON

HEAT TRANSPORT

LOOP

SCALE BATTERY

CHANGE ^ COLD PLATES

, WATEf

LOOPS

EQUIPMENT I

COLD PLATES

44 45 46 47 48

TEMPERATURE CHANGE (EXCLUDING BATTERY)~OF

t ti t it t

8.8 9.0 9.2 9.4 9.6

TEMPERATURE CHANGE (BATTERY COLD PLATES)~°F

Figure 43-18 Pumped Liquid Loop (Freon 11 with 8CPF Radiator Inlet)

109
D180-27935-2

weights as a function of fluid temperature changes for a radiator inlet temperature of

80°F. (The details of the weight calculations were described in the previous sections.)

The fluid temperature change is constrained by the 40°F humidity control temperature

and the 32°F freezing point of water in the pressurized module loop. The total system

weight reaches a minimum at the 32°F battery cold plate outlet temperature limit. Figure 4.3-19 shows the pumped ammonia system element weights for identical 80°F radiator inlet temperature. In this case the optimum fluid temperature change occurs before

the 32°F battery cold plate outlet temperature limit is reached.

Figure 4.3-20 shows the minimum system weight as a function of radiator inlet temperature for ammonia and Freon systems. The 80°F inlet temperature is close to optimal for both fluids. Detailed schematics for the optimum (80°F radiator inlet) Freon 11

and ammonia pumped loop systems are shown in figures 4.3-21 and 4.3-22, respectively.

4.3.8 Effect of Two-Phase Water System in Pressurized Modules

The interface between the two-phase heat transport bus and the pumped water loops in

the pressurized modules results in a lowering of the bus temperature in order to minimize system weight. The reason for this is that the water temperature change must be

less than the temperature difference between equipment and bus. Consequently, since

the water loop transports sensible heat, higher flow rates (and higher weights) are incurred as the temperature difference decreases. A two-phase water heat transport system allows a higher bus temperature and potentially lighter weight system.

4.3.8.1 Two Phase Water Heat Exchanger and Line Sizing

The two phase heat exchanger weights were based on the analysis outlined in section

4.3.4.1. Because the water vapor density is low for the temperature range considered,

the vapor pressure drop (in the vapor line between the equipment and interface heat

exchanger) effect on vaporization (condensation) temperature was included in the

analyses.

For the high temperature heat rejection system case the vapor line was fixed at an inside

diameter of 2.25 inches and the liquid line at 0.5 inch inside diameter. These line sizes

result in an overall head difference of about 1 inch, which is compatible with capillary

pumping. The vapor line pressure drop produces a difference between vaporization temperature, at the equipment heat exchanger, and condensation temperature, at the interface heat exchanger, of 1.76°F. The heat exchangers were optimized as a function of

110
Dl80-27935-2

10500

10000

9500

800 -

t

MAXIMUM (40°F)

LIMIT ON WATER

SUPPLY TO HUMIDITY

CONTROL UNIT

TOTAL WEIGHT

RADIATOR SYSTEM

SCALE

CHANGE

32°F LIMIT ON '

BATTERY COLD PLATE

OUTLET TEMPERATURE

600

4DuOu r- i r

 ' PUMPED AMMONIA

. HEAT TRANSPORT

200 - LOOP

>SCALE

CHANGE

PRESSURIZED MODULE

HEAT EXCHANGES

HAT 65

60

UPSCALE

<CHANGE

10 -

MODULE WATER LOOPS

BATTERY COLD PLATES

EQUIPMENT COLD PLATES

44 45 46 47 48

TEMPERATURE CHANGE (EXCLUDING BATTERY)~°F

8.8 9.0 9.2 9.4 9.6 n

TEMPERATURE CHANGE (BATTERY COLD PLATES)^°F

Figure 4,3-19 Pumped Liquid Loop \'Ammonia with 8CPF Radiator Inlet)

111
Dl80-27935-2

10,750

CO

CD

X

o

10,500

10,250

10,000

AMMONIA

72J5 75 77J5 80 825

RADIATOR INLET TEMPERATURE - °F

85

12.500

eg 12,250

I

z

UJ

12.000

11.750

FREON-11

725 75 77J5 80 82J5

RADIATOR INLET TEMPERATURE ~°F

85

Figure 43-20 Optimized Total System Weight for Pumped Liquid Heat Transport System

112
Dl80-27935-2

80°F

RADIATOR

125 KW

22JB6°F

1.7B INCH ID

OJ03 INCH WALL

300 FT LENGTH

532 LBS

7.5 PSID

602 WATTS

8035 FT2 (ONE SIDE)

0642 LBS (PANELS)

462 LBS HX

5.5 PSID

440 WATTS

8JDLBS

O.OPSID

7.6 WATTS

18 PSID ^j1470WATTS CD

49J5 LBS

OX PSID

47 WATTS

BATTERY

COLD PLATE

400F.20KW

80°F EQUIPMENT

COLD PLATE

85°F. 10 KW

32°F 32°F

X

42JBLBS

0.4 PSID

688 WATTS

80°F

82J50°F

83.340F

PRESSURIZED

MODULE

^ INTERFACE '

HEAT EXCHANGER

11 KW

32°F

-X34J50°F

EQUIPMENT

COLD PLATE

850F. 10 KW

24.4 LBS

8.6 PSID

23.2 WATTS

113 LBS

4JDPSID

10.8 WATTS

6.4 LBS

23 PSID

6.1 WATTS

3534°F

17.7 PSID

47.8 WATTS

HUMIDITY

CONTROL

UNIT

40°F. 1 KW

39.70°F

0.467 INCH ID

OJ02 INCH WALL

50 FT LENGTH

9 LBS

2.75 PSID

7.45 WATTS

EQUIP

POWER

TOTAL

TOTAL

11343 LBS

1710 WATTS

11,041 LBS

Figure 4.3-21 Pumped Liquid Freon-ll System Schematic

113
D180-27935-2

80°F

RADIATOR

125 KW

24J05°f

123 INCH ID

OJ038 INCH WALL

300 FT LENGTH

145 LBS

4JB PSID

177 WATTS

7900 FT2 (ONE SIDE)

9480 LBS (PANELS)

243 LBS UX

62 PSID

231 WATTS

0.8 LBS

0.2 PSID

OJ WATTS

13 PSID

485 WATTS

6 LBS

0.2 PSID

5.7 WATTS

BATTERY

COLD PLATE

40°F,20KW

80°F EQUIPMENT

COLD PLATE

850F, 10 KW

33°F

•00

LBS

33 PSID

13.6 WATTS

80°F

81J06°F

8231°F

PRESSURIZED

MODULE

• INTERFACE •

HEAT EXCHANGER

11 KW

33°F

34J06°F

EQUIPMENT

COLD PLATE

850F.10KW

16-8 LBS

5JBPSID

16 WATTS

7.1 LBS

2.5 PSID

6JB WATTS

4J6LBS

1.6 PSID

43 WATTS

3531 °F

CD

12.7 PSID

34 J9 WATTS

HUMIDITY

CONTROL

UNIT

40°F. 1 KW

39J58°F

0.469 INCH ID

0.02 INCH WALL

50 FT LENGTH

9.1 LBS

23 PSID

73 WATTS TOTAL

EQUIP

POWER

TOTAL

10,137 LBS

660 WATTS

10368 LBS

Figure 4.3-22 Pumped Liquid Ammonia System Schematic

114
D180-27935-2

equipment to bus temperature difference that included this fixed vaporization temperature difference.

The effect of pressure drop on vaporization temperature is more pronounced in the low

temperature heat rejection case. In this case the vapor line size was optimized in conjunction with heat exchanger optimization to provide the lowest weight system for a

given humidity control unit to bus temperature difference. The liquid line size was fixed

at 0.25 inch O.D. with 0.02 inch wall.

4.3.8.2 Effect on System Weight

Figure 4.3-23 shows the effect of incorporation of two-phase water heat transport systems in the pressurized modules on the high temperature two-phase ammonia system

element weights. The minimum total weight now occurs at a bus temperature of 79°F

compared to the 70°F optimum for the system with pumped water loops. A detailed

schematic showing the effects on the two-phase water system is shown in figure 4.3-24.

The main bus sizes and weights remain unaffected. The equipment cold plate weights

are increased due to the higher bus temperature. The radiator and pressurized module

component weights are significantly reduced. The total system weight is 828 pounds less

than that for the system with pumped water loops.

The effects on the low temperature heat rejection system are shown in figures 4.3-25

and 4.3-26. The optimum bus temperature for this case is 37.5°F compared to 36°F for

the case with pumped water loops. As in the high temperature case the bus weight remains unaffected, the battery cold plate weight is increased and the other component

weights are reduced. The total weight is 79 pounds less than that for the pumped water

loop system.

4.3.9 Cost and Benefits Analysis

In the final report of the study completed in April of 1983 a cost and benefits assessment

was given for developing thermal storage systems for both pumped liquid and two-phase

heat transport concepts. The result indicated that those technology advancements were

among the most desirable of the ones identified in that study. It was indicated in that

study that development costs for the two-phase system would be 50% higher due to the

complexity of:

115
D180-27935-2

7000

6000

I

UJ.

s

J

5 )

5000

600

400

200

20

60

TOTAL WEIGHT „

(CAPILLARY SYSTEM) '/

**^. fl

TOTAL WEIGHT

(PUMPED SYSTEM)

RADATOR SYSTEM

BUS (CAPILLARY SYSTEM)

PRESSURIZED

MODULE TWOPHASE WATER

PLATE TRANSPORT

SYSTEM.

BUS (PUMPED SYSTEM)

BATTERY

COLD PLATES

65 70 75

BUS TEMPERATURE^- °F

80 85

Figure 4.3-23 High Temperature Two-Phase Ammonia Bus with Two-Phase Water Loops

116
D180-27935-2

79°F

VAPOR LINE

RADIATOR

100 KW

79°F

LIQUID LINE

4342 FT2 (ONE SIDE)

5210 LBS (PANELS)

174 LBS INK'S)

79°F EQUIPMENT

COLD PLATE

B50F. 10 KW

79°F

1.4 LBS

LBS

79°F

80.46°F

81JB5°F

VAPOR LINE

225 INCH ID

0.022 WALL

25 FT LENGTH

13.6 LBS

0.95 INCH HEAD LOSS

PRESSURIZED

MODULE

. INTERFACE .

HEAT

EXCHANGER

' KW

79°F

80.46°F

14.4 LBS

B3.610F EQUIPMENT

COLD PLATE

B5°F, 10 KW

81.850F

LIQUID LINE

030 INCH ID

0.02 WALL

25 FT LENGTH

5.0 LBS

0.16 INCH HEAD LOSS

14.4 LBS

EQUIP

POWER

TOTAL

TOTAL

PUMPED

5780 LBS

88 WATTS

5811 LBS

CAPILLARY

6073 LBS

6073 LBS

Figure 4.3-24 Effect of Two-Phase Water Heat Transport System on High Temperature Bus

117
D180-27935-2

2800

28

UJ -J

s?

2600

2400

2200

200

100

20

30

TOTAL WEIGHT

(CAPILLARY SYSTEM)/

RADIATOR

SYSTEM

TOTAL WEIGHT

(PUMPED SYSTEM)

PRESSURIZED MODULE

TWO-PHASE WATER

HEAT TRANSPORT SYSTEM

BUS (CAPILLARY SYSTEM)

BUS (PUMPED SYSTEM)

BATTERY COLD PLATES

32 34 36 38

BUS TEMPERATURE~°F

40

Figure 43-25 Low Temperature Two-Phase Ammonia Bus with Two-Phase Water Loops

118
D180-27935-2

373°F

VAPOR LINE

RADIATOR

25 KW

37J5°F

LIQUID LINE

37.50F BATTERY

COLD PLATE

40°F,20KW

37J5°F

7LBS

4J09LBS

37J5°F

38.043°F

VAPOR LINE

1.686 INCH ID

0.020 WALL

12J5 FT LENGTH

4.65 LBS

0.118 INCH HEAD LOSS

39.485°F

PRESSURIZED

MODULE

INTERFACE

HEAT

EXCHANGER

1 KW

37.5°F

38D43°F

3.88 LBS

HUMIDITY

CONTROL UNIT

40°F. 1 KW

38558°F

LIQUID LINE

0.21 INCH ID

0.02 INCH WALL

12J5 FT LENGTH

Oj82 LBS

0301 INCH HEAD LOSS

3JB8 LBS

EQUIP

POWER

TOTAL

TOTAL

PUMPED

2416 LBS

42 WATTS

2431 LBS

CAPILLARY

2528 LBS

2528 LBS

Figure 4.3-26 Effect of Two-Phase Water Heat Transport System on Low Temperature Bus

119
D180-27935-2

1. Phase change material packaging.

2. Thermal interface with the heat transport system.

In the current study a further assessment of the pumped liquid versus two-phase heat

transport system was conducted. Two technologies were identified for advancement

specifically to support the development of a two-phase system. These are—

1. Two-phase water thermal transport loops for inhabited environment.

2. Heat exchanger for liquids in nearly saturated state in zero gravity.

The quantifiable benefits of these advancements are that the two-phased system is less

complex than the pumped liquid system; that the two-phased system weighs less than the

pumped liquid system and that means lower cost to transport the system to orbit; and

finally the area of the radiator is less for the two-phased system and that means the

assembly labor costs will be lower.

The two systems compared are given by the pumped Freon-11 system of figure 4.3-21

and the pumped two-phased water heat transport system of figures 4.3-24 and 4.3-26.

The complexity factors were compared using the RCS PRICE modelling technique and

the result came out $21.26M for the liquid and $16.08M for the two-phased that results

in $5.18M in favor of the two-phased system.

The transportation costs were calculated using $718. per pound to orbit and the difference in system weights. This resulted in $2.66M in favor of the two-phased system. The

assembly costs were based on $77,000 per 24-hr day for astronaut time and the assessment which was used in the last study of 8 labor hours to assemble 100 square feet of

radiator. This resulted in a $475,000 saving for the two-phased system.

The cost of advancing the technologies involved has been estimated to be $0.8M for the

heat exchanger program and $2.59M for advancing the two-phased water interior loop

system (assuming use of shuttle test data for heat pipes rather than a complete independent flight test). Together these represent an expense for technology advancement for a

two-phased heat transport system of $3.4M.

120
D180-27935-2

Using the above figures the cost over benefit ratio of advancing technologies to support

the two-phased heat transport system is 0.41. This is based on the $3.4M advancement

cost divided by $8.32M benefits.

4.4 SUMMARY OF RESULTS

The weights for the various heat transport systems, applied to the baseline space station,

are summarized in table 4.4-1. The pumped two-phase ammonia system used in conjunction with two-phase water heat transport inside the pressurized modules is the lightest system. The corresponding capillary two-phase system is 359 pounds heavier. The

pumped two-phase system with pumped water loops inside the modules is 907 pounds

heavier. The pumped liquid ammonia system is heavier by 2,126 pounds and the pumped

freon system is heavier by 3,699 pounds. The total radiator area required is: 6186 ft2

for two-phase ammonia systems in conjunction with two-phase water loops; 6690 ft2 for

two-phase ammonia systems with pumped water loops; 7900 ft2 for pumped liquid ammonia system; and, 8035 ft2

 for pumped freon system.

4.5 CONCLUSIONS

A pumped two-phase heat transport system provides approximately a 1000 Ibm weight

reduction and power and size reductions compared to a pumped liquid loop system. More

importantly, the two-phase system offers greater flexibility in configuring the space

station.

A capillary two-phase heat transport system offers the advantages of a pumped twophase system with a relatively small weight increase. The capillary system does not

need the pumps, valves and controls needed for the pumped two phase system. Consequently a capillary system is, in principle, a more reliable system.

For pressurized modules, a two-phase water heat transport system rather than liquid

water system provides an additional weight savings when used with a.two-phase main

transport system. A capillary two phase water system could potentially increase reliability and reduce vibration and noise.

Alternative pumping concepts for the pumped two-phase system were considered briefly.

One concept uses an osmotic pump in place of the baseline mechanical pump. This

121
Dl80-27935-2

Table 4.4-1 System Weight Comparison

TRANSPORT

LOOP

PUMPED LIQUID LOOP

FREON II

AMMONIA

TWO-PHASE AMMONIA

PUMPED

HIGH TEMP

LOW TEMP

TOTAL

CAPILLARY

HIGH TEMP

LOW TEMP

TOTAL

TWO-PHASE AMMONIA

SYSTEM WITH TWOPHASE WATER SYSTEM

IN MANNED MODULES

PUMPED

HIGH TEMP

LOW TEMP

TOTAL

CAPILLARY

HIGH TEMP

LOW TEMP

TOTAL

742

207

107

62

159

389

149

618

107

52

159

369

140

518

COLD

PLATES

119

13

3

4

7

• MANNED

MODULE

WATER LOOPS

59

59

171

46

217

HX't

762

285

400

70

470

RADIATOR

10259

9804

coco

95F9O

2338

8296

SAME AS PUMPED TWO-PHASE

7

7

14

*

93

27

120

220

69

279

5384

2286

7670

SAME AS ABOVE

TOTAL

WEIGHT

11941

10368

6639

2510

9149

6901

2607

9508

5811

2431

8242

6073

2528

8601

NOTE: 125 KW HEAT LOAD (100 KW AT B5°F; 20 KW BATTERY & 5 KW METABOLIC AT 40°F)

300 FT TOTAL TRANSPORT DISTANCE

122
D180-27935-2

concept provides pumping by osmotic pressure that causes solvent to flow through a

semipermeable membrane into a solution which flows to the evaporator. This concept

requires auxiliary mechanical pumps to keep the solution from being diluted next to the

membrane. The weight, reliability, and performance deficiencies of this concept eliminates it from serious consideration as an alternate pumping scheme. The other concept

considered was an ion drag pump that produces fluid flow by creating ions in a corona

discharge. The ions are accelerated in an electric field and impart momentum to the

fluid. This scheme has the advantage of pumping with no moving parts. However, the

pumping efficiency is only about 10%, high voltages are required, transport fluid must be

a dielectric, and the corona discharge may have degrading effects on the fluid and

electrode.

*.6 RECOMMENDATIONS

The results of the study showed that the weight of a two-phase heat transport system is

approximately 1200 Ibm less than that of a comparable single-phase system of identical

capacity. This 12% lower weight alone would probably to be sufficient justification for

the selection of a two-phase system for the space station. The most compelling reasons

for the choice of a two-phase transport system are (1) flexibility in locating heat loads

and reconfiguring experiments, (2) modular growth of the station, and (3) stable temperature interface with cooling and heating loads over an inside range of operating

conditions.

The two-phase system concept, however, has some inherent technical risks that will

require expensive space flight testing to resolve. The developmental costs of the twophase system would therefore be expected to be considerably greater than the cost of

developing a single-phase system.

Additional information is needed before a sound decision can be made as to which

thermal transport system should be selected for the initial space station. It is therefore

recommended that a program be initiated to generate the necessary information to support the selection of a space station thermal transport system. A three-step program is

envisioned. In the first step, system requirements would be established. These requirements would stem from the definition of (1) system loads such as experiments, equipment, etc. (2) planned space station evolutionary growth, and (3) space station mission

planning.

123
D180-27935-2

Candidate single- and two-phase transport system would be designed and optimized in

the record program step. These systems would be developed for a baseline station and

mission drawn from the step one requirements definition study. Dollar cost benefits of

each transport concept would be quantified for all important system attributes including:

1. Mass.

2. Size.

3. Flexibility and growth.

4. Reliability.

5. Maintainability.

6. Constructability.

7. Operation costs.

In the third step, detailed plans for transport system development would be prepared.

Developmental costs would then be predicted and a cost and benefit analysis performed

to identify the best thermal transport system concept.

Regardless of the final selection of the thermal transport system concept for the space

station, the potential benefits of the two-phase systems warrant immediate technology

development. Such developments are necessary to bring the level of technical maturity

up to the point required for space station preliminary design. Because a pumped twophase thermal bus system development program is currently in progress under NASA JSC

contracts NAS9-16781 and NAS9-16782, it is recommended that emphasis should be

placed on development of a two-phase transport loop suitable for thermal management

within pressurized inhabited environments of the space station. The high-performance

fluids (ammonia or freon) envisioned for use in the main thermal transport bus cannot be

used in inhabited areas due to their toxicity. Water would be the first choice for the

working fluid in the internal transport loop. A two-phase design would provide the flexibility, modular growth capability, and isothermal interface characteristics desired for

the overall thermal management system. Both mechanically pumped and capillary

pumped loops should be investigated. Special emphasis should be placed on developing

pump and heat exchanger technology that would benefit both the main bus and internal

transport loop concepts. In addition, capillary pumping for the main thermal transport

system should be investigated because of the potential for increased reliability and reduced power, noise, and vibration by eliminating mechanical pumps. Volume III provides

preliminary plans for the accomplishment of these advances.

124
D180-27935-2

5.0 INTEGRATION OF AUTOMATED HOUSEKEEPING

This section presents the results of the study conducted to characterize a system for

integrating the automation of several housekeeping subsystems on an inhabited space

station. This integration system will be a step toward meeting the automomy/automation philosophy for the space station which has been defined by the Concept Development Group (see table 5.1-1).

5.1 INTRODUCTION

In the Advanced Platform Sytems Technology Study completed in early 1983, the cost

versus benefits of integrating the automation of several utilities producing subsystems on

a space station was assessed. The results of this assessment gave indication that the

function of providing this integration could produce savings to the space station over a

10-year life of $184M. The same study indicated that a large part of the cost of such a

system would be the software development and the probable use of expert systems technology. These cost figures were assessed as being about $9M. Because the system had

not been described at a detailed level and because the cost/benefits were impressive, it

was decided to conduct the current study to take a more detailed look at the functions of

such a controller. The current study also produced a reassessment of'the cost and benefits of the system and generated a more definitive identification of the applicability of

expert systems to the process.

The following paragraphs report on the approach, results, conclusions, and recommendations resulting from this characterization study and also provide a technical discussion of

the study elements.

5.2 APPROACH

The objective of this study was to obtain a characterization of the Integrating Management Controller to allow a better understanding of the benefits possible and the technology needed for implementing such a controller so that it will provide reliable, realtime management of the separate housekeeping controllers on a space station. To

accomplish this objective the results of the initial study were extended by a more

detailed modeling of how a management type controller might be employed. The model

was then examined to identify options in the implementation which better defined the

benefits to be obtained from the integration process.

1'25
Dl80-27935-2

Table 5.1-1

Space Station Autonomy/Automation Philosophy

Subsystem/system monitoring and control will be performed on board.

Systems monitoring and control will be automated.

Fault detection and isolation will be an automated function for all subsystems.

Redundancy management including reconfiguration will be performed automatically on

board.

Reverification of systems/subsystems elements will be performed automatically on

board.

Operations planning and scheduling will be performed on board.

The degree of automation will increase as the space station grows and technology

becomes available.

Collection and analysis of trend data will be automated.

The space station platform shall have the same degree of automation on board as the

manned base.

126
D1SO-27935-2

The following paragraphs indicate in some detail the approach steps used in this study.

5.2.1 Update the Housekeeping Functions List

In performance of this subtask a system analysis was conducted to update the following

list of functions to be performed by each of the three automatic housekeeping subsystem

controllers:

Table 5.2-1

Functions For Housekeeping Controllers

Electrical Power Thermal Life Support

Control voltage at power Control temperature to Control oxygen and nitrouser outlets. set points within cabins. gen supplied to cabin.

Control power levels at Control temperature at Control contamination

power user outlets. heat exchangers for level in cabin air.

specific equipment items.

Switch sources based on Control humidity of cabin Control quality of potable

sensed status of sources atmosphere. and wash water. Removal

of CC>2 from cabin air.

The above list indicates the starting point on independent control functions within each

of the three housekeeping subsystems on the space station considered in this study.

These functions are those which relate to maintaining environment on the space station

for the crew and for the mission peculiar equipment. In this subtask the list was expanded for models of the three subsystems to the level of detail where the control

parameters would be sensed.

To accomplish this expansion, a review was conducted of thermal control automation

progress reports, of briefing material for power system automation (MCR-82-631 dated

2-9-83), and of Space Station Environmental Control and Life Support System—Preliminary Concept Design Report (3SC-17727). This review extracted descriptive information

about those subsystems and their automation that was used to identify the following:

127
D180-27935-2

1. Functions performed by automation of the subsystems.

2. Quantities which would need to be sensed in order to perform the automation.

These items were then listed and are presented as tables 5.3-1, 5.3-2, and 5.3-3 of this

final report. Use of this information was made in the next step of the study as described

in the next paragraph.

5.2.2 Define Functions to Integrate the Automation of the Housekeeping System

A systems analysis was performed to develop a concept for integrating the control of the

three housekeeping functions and to identify the control parameters involved. The analysis process used the control functions list developed by the review described above and

identified where the items on the list had relationship to the control of another subsystem. Outside events, which can effect control of the housekeeping subsystems, were

then identified. Using these lists of functions and data, the functional concepts for the

integrating controller were developed. Figure 5.3-2 shows the relationships considered

and lists the outside events considered.

Based on the interactions identified by the above process functions were identified for

the integrating controller. Functional block diagrams were then developed along with

functional descriptions of each of those identified. These functional block diagrams and

descriptions are also presented under section 5.3 of this report.

5.2.3 Identify Integration Functional Scenarios

Because various mode shifts would be selected and implemented by an integrating controller, it was necessary to identify the mode shifts and to assess the sequencing of the

action. The scenarios for operation of an integrating controller were conceptualized in

this subtask by a systems analysis approach. The scenarios were developed from the

nominal and functional sequences listed below.

1. Management of start-up modes.

2. Management of load sharing for electrical power and thermal control

according to astronaut usage patterns, sunlight/darkside passages, and special

events such as EVA or module reconfiguraiton activities.

3. Management of emergency and redundant path modes.

4. Management of material transfer and shutdown modes.

128
Dl80-27935-2

Table 5.3-1

Electrical Power Subsystem Automation

Functions

o Control solar array orientation

o Control of solar array selection - segment selections

o Regulation of solar array output voltage - shunt regulation

o Control of battery charge-discharge processes

o Battery selections - cell selections

o Load sharing control of regulators

o Shunting for under use control

o Redundancy Management within the electrical power system

Sensed Quantities

o Solar array temperatures

o Solar array positions

o Solar array voltages by sections of the array

o Battery cell voltages

o Battery cell temperatures

o Battery cell pressures

o Battery charge voltage

o dc/dc converter line voltage

o Transformer coupled converter output voltage

o Series resonant inverter (dc/ac) output voltage

o Series resonant inverter fuse status

o Magnetic latching relay position

o Cable temperature

129
D180-27935-2

Table 5.3-2

Life Support Subsystem Automation

02 Generation

Functions

o Control of the flow of water to the electrolysis units

o Valve operation

o Pump operation

o Control of electrolysis current

o Control of the flow of H2 away from the unit

o Valve operation

o Control of the flow of water away from the unit

o Valve operation

o Pump operation

o Control of the flow of oxygen away from the unit

o Valve operation

o Redundancy management within the 02 generator

o Detection of failure

o Abnormal values of several quantities

o Selection of redundant elements: generators/pumps/valves

Sensed Quantities

o Partial pressure of cabin 02

o Flow rate of input water

o Pressure of H2 at output

o Flow rate of water at output

o Pressure of 02 in storage at output

o Selected set point condition

o Status of valves, pumps, generators and storage units

130
0180-27935-2

Table 5.3-2 (Continued)

Life Support Subsystem Automation

N2 Supply

Functions

o Control of the flow of N2 from storage

o Valve operation

o Redundancy management functions within the N2 supply

o Detection of failures

o Abnormal values of several quantities

o Selection of redundant valves

Sensed Quantities

o Cabin pressure

o Pressure of N£ storage tanks

o Selected set point

o Status of valves and storage tanks

CO2 Removal

Functions

o Position of by-pass valves to control air flow to beds

o Position of by-pass valves to isolate beds for desorption from the cabin

o Control of electric heaters to create steam to flow through beds being desorbed

o Control of valves to direct C02 to the reduction system from the beds being

desorbed

o Control of valves to provide hygenic water for steam into desorbed beds

o Redundancy management

o Detection of abnormal sensed values

o Selection of redundant elements: fans, by-pass valves, beds, and steam

generators

131
D180-27935-2

Table 5.3-2 (Continued)

Life Support Subsystem Automation

Sensed Quantities

o Partial pressure of cabin CO2

o Flow rate of water at input to steam generator

o Pressure of CO2 in accumulator at output

o Temperature of steam in steam generator

o Flow rates at desorbed bed

o Status of beds being used for absorption and being desorbed

o Status of valves and fans

o Selected set point

CO2 Reduction

Functions

o Mixing of H2 and CO2

o Flow of mixed CO2 and H2 through filter to the reduction unit

o Pump and valve control for water accumulator at reduction unit output

o Redundance management within the CO2 reduction unit

o Selection of redundant elements: reduction unit, valves, and accumulator

o Failure detection based on abnormal sensed values

o Cooling for unit

Sensed Quantities

o Flow and pressure of gases at input

o Temperature of unit

o Flow and pressure of gases at output of unit

o Flow of water to accumulator

o Capacity filled with water in accumulator

o Flow of water out of accumulators

o Status of valves and accumulators

132
D180-27935-2

Table 5.3-2 (Continued)

Life Support Subsystem Automation

Trace Contamination Control (TCC)

Functions

o By-pass valves to control air flow through beds

o Annunciation of below normal bed status

o Control of power to electric heaters

o Redundancy management within the trace contamination control system

o Failure detection based on abnormal sensed values

o Selection of redundant elements: alternate fans, paths through beds, and

oxidizer

Sensed Quantities

o Level of contamination

o Temperature of oxidizer

o Flow through units

o Status of fans, valves, oxidizer heater and beds

o Selected set point

Potable Water Process

Functions

o Control of water flow to post-treat

o valves

o pump

o Control of cycling in post-treat and Water Quality Monitor (WQM)

o valves

o pumps

o WQM processes

o Control of flow to selected storage tank

o Control of iodine addition in storage tank testing process

o Control of overflow to hygienic water

o Control of water heater

o Control of use flow out of storage tanks

133.
D180-27935-2

Table 5.3-2 (Continued)

Life Support Subsystem Automation

Functions (Cont)

o Redundancy management with the potable water processor system

o Failure detect

o Seclection of redundant elements: accumulators, water quality monitors,

(WQM), tanks, valves, and beds

Sensed Quantities

o Capacity filled in accumulators

o Measured contaminants in WQM

o Capacity filled in storage, test, use tanks

o Iodine level in storage tank test processing

o Post treat valve and bed status

o Water temperatures in system

o Storage tank valve status

o Water flow rates in system

Hygenic Water Process

Functions

o Control of pre-treat pumping

o Control of pre-treat biopal VRG 20 addition

o Control of pumping and valving into the vapor-compression distillation (VCD) unit

o Control of compression in VCD

o Control of heating in VCD

o Control of conductivity testing of VCD condensate and valving for output

o Control of post-treat valving and pumping

o Control of WQM processes

o Control of flow to fill-use tanks

o Control of flow out of fill-use tank

134
D180-27935-2

Table 5.3-2 (Continued)

Life Support Subsystem Automation

Functions (Cont)

o Redundancy management within the hygenic water processor system

o Failure detect

o Select redundant elements: WQM, VCD, valves, fill tanks, pumps and heaters

Sensed Quantities

o PH level in pre-treat

o Flows in pre-treat

o Waste holding tank capacity filled

o Valve status indicators

o Waste tank capacity filled

o Sludge tank capacity filled

o Flows into VCD

o Pressure in VCD

o Temperature in VCD

o Conductivity of VCD condensate

o Flow of condensate from VCD

o Measured contaminants in WQM

o Post treat valve and bed status

o Flow rates in post treat and storage

o Storage tank valve status

o Capacity filled in storage tanks

o Capacity filled in accumulators in system

Wash Water Process

Functions

o Control of pumping to work holding tank

o Control of pumping and valving to hyper-filtration process

135
D180-27935-2

Table 5.3-2 (Continued)

Life Support Subsystem Automation

Functions (Cont)

o Control of heating in hyper-filtration process

o Control of valving and pumping from the hyper-filtration process

o Control of the addition of sodium hypochlorite in post-treat

o Control of the addition of iodine in post-treat

o Control of pumping and valving for post-treat

o Control of pumping and valving for storage of wash water

o Redundancy management within the wash water processor system

o Failure detection

o Selection of redundant elements: pumps, valves, hyper-filtration units, and

tanks

Sensed Quantities

o Flows to and from holding tank

o Flows to and from the hyper-filtration processor

o Temperature of hyper-filtration processor

o Capacity filled in holding tank

o Capacity filled in hyper-filtration process

o Measured contaminants in WQM

o Post-treat valve and bed status

o Flows for post-treat and to storage

o Storage tank valve status

o Capacity filled in storage tanks

o Quantity of iodine and sodium hypochlorite available for use

o Capacity filled in sludge tank

136
D180-27935-2

Table 5.3-3

Thermal Control Automation

Functions

o Control of cabin air flow through heaters

o Control of heaters

o Control of heat exchanger condensate flow to separators

o Control of water flow out of separators

o Control of positions of steerable radiators or selections of selectable radiators

o Control of coolant flow - valve positions or pump speeds

o Redundancy management within the thermal control system

o Sensed failures from abnormal sensor values

o Selection of redundant elements: fans, heaters, heat exchanges, separators,

pumps, and valves

Sensed Quantities

o Temperature of cabin air

o Humidity of cabin air

o Input air flow to heater

o Condensate flow at heat exchanger

o Water flow out of separators

o Air flow out of separators

o Heater temperature

o Set point status

o Equipment status

o Position and rate information for steerable radiator servos

o Valve positions

o Pump speeds

137
D180-27935-2

5. Management of maintenance scheduling and interaction with normal or

emergency modes.

The subtask was conducted at a conceptual level and the results indicated that the scenarios simply reinforced the functional descriptions already being developed under the

previous subtasks. In addition it was determined that scenarios of significant detail

would require a rather complete description of space station configurations, missions and

operations. In the absence of such, the scenarios developed were general in nature.

Tables of section 5.3.4.1 give the scenarios that were developed.

5.2.4 Identify Hardware and Software Elements of Integrating Controller

A systems analysis was conducted in cooperation with data management specialists to

identify hardware and software elements of a concept for an integrating controller for

automated housekeeping functions and to isolate technologies to be considered for advancement in order to implement the concepts. The use of artificial intelligence in the

form of expert systems was explored to implement the flexibility and tolerance for

change needed in this integrating controller.

The following questions were poised for the Data Management technical specialists on

artificial intelligence:

1. Does this concept appear to need expert system implementation?

2. If it doesn't need it, would it benefit from it?

3. Describe how expert systems could be used in implementing this concept.

4. How many rules would be used in your estimation to implement the concept?

5. How much of the implementation would be on space station computers and

how much would be in a ground installation?

6. What would be the characteristics of a space and ground computer system?

Memory? Thru put rate? Anything else?

7. Describe the magnitude of development effort needed to achieve an expert

system of the type needed for this concept; $ needed; years needed.

The answers received are given in section 5.3.6 of this report. In addition, figure 5.3-10

gives an initial cut on how the processing for an integrating controller might be grouped

functionally in hardware systems both on board the space station and on the ground.

138
D180-27935-2

5.2.5 Compare Trade Study Results

The implementation options and system characterizations were analyzed to compare the

benefits associated with the several functions identified for the integrating controller.

This benefits comparison was based on the following considerations:

1. What is the extent of use of the function during space station operations?

2. Is an interactive mode using the function desirable or should it be fully

automated?

3. Is the function essential for safety?

it. What is the extent of deterministic problem solving?

5. Does use of the function appear to increase with mission experience?

Section 5.3.7 gives the tabulation of this comparison and gives the resulting ranking of

the benefits of implementing technologies for these functions.

Assessments of benefits of options for trade in areas architecture, on board versus

ground processing, and human interaction versus fully automatic were also made. These

assessments are also reported in section 5.3.7.

Finally a review of the cost and benefits ratio for expert system technology developed in

the Advanced Platform Systems Technology Study was conducted and is reported in section 5.3.S.

5.2.6" Identify Technologies for Advancement

This subtask produced specific recommendations on the expert systems technologies

advancement to support the development of an integrating controller for a space station.

These technologies were identified at the level of specific procedures for advancement

and this is discussed in section 5.3.9.

5.3 TECHNICAL DISCUSSION

This section presents in a detailed discussion of the study outputs along with the associated data and conceptual illustrations. The output discussion given by the following

paragraphs are structured according to the sequence of the approach subtasks.

139
D180-27935-2

5.3.1 Automated Housekeeping Functions

The automation of three subsystems on an inhabited space station was investigated to

identify the functions to be performed and the sensing that would be needed. The three

subsystems were electrical power, life support, and thermal management and the automation being considered through this subtask is that which would be used internal to each

of these subsystems in order that they can perform their functions automatically. The

integration of these automated systems deals with interactions between them, with outside factors that affect them all or with trends that involve more than one subsystem.

The electrical power and thermal subsystem automations are fairly well understood and

are also the subjects of separate NASA study contracts. For those reasons we used reports on the subjects to identify automation elements and these reports were: (1) MCR

82-631 "Power subsystem automation study" Briefing for program review and (2) Rockwell Monthly Progress Reports - NAS9-16782 "High Efficiency Automated Thermal Control System Program".

The life support subsystem on the other hand is in a conceptual state and the extent of

expendable resupply versus onboard regeneration and the amount of automation that is

practical are still unresolved issues. At present the life support concepts are being

developed and the components are operated separately but not as an overall system.

Figure 5.3-1 is an overall system concept which is reported in 3SC-17727, "Space Station

Environmental Control and Life Support System Preliminary Conceptual Design" DOC

CSD-SS-059, dated 9/82. This concept was used to facilitate our identification of life

support automation functions, but it is only one of several concepts and will undoubtably

by modified before the space station baseline is established.

Referring to figure 5.3-1, the function of the system can be separated into:

1. Oxygen generation.

2. Nitrogen supply.

3. Carbon dioxide removal.

4. Carbon dioxide reduction.

5. Trace contamination control.

6. Potable water processing.

7. Hygenic water processing.

8. Wash water processing.

140
Dl80-27935-2

S

I

i

a:

141
D180-27935-2

These along with the cabin temperature and humidity control supported by the thermal

management system are to provide the life supporting environment inside an inhabited

space station in a regenerative sense. The automation functions and sensing for life

support are identified in our study for each of these categories. Tables 5.3-1 through

5.3-3 give the results of analysis conducted of these subsystem concepts and lists the

functions and sensed quantities for the automations identified.

The functions and sensed quantities in these tables were then used to construct an interface tabulation (see fig. 5.3-2) to identify when interactions between the automated

subsystems could exist and where outside events could influence the overall operation.

These identifications lead to the definition of functions for the integrating controller.

5.3.2 Integrating Controller Functions

The integrating controller is a concept that is intended to provide management level

control of automated utilities subsystems on a manned space station. Initially this controller would be largely an advisory service for the astronauts. As such, it would tend to

replace the advisory service which has been provided by mission control with a more

autonomous interactive system that the astronauts can use on board. Because there will

be actions that will be repetitive and bothersome to the astronauts it is a worthy goal to

seek a fully automatic integrating controller for some functions.

This final report section gives some detail on the identification of functions to be performed by such an integrating controller. Based on the interactions shown by figure

5.3-2, it is clear that the three subsystems affect each other significantly and that there

are outside factors that affect them all. The functions performed by an integrating

controller would then deal with those interactions. Inspection of these indicate the following:

1. Electrical power load management is needed because both thermal and life support

are heavy power users and reduction of their usage to balance loads needs to consider their interacting functions.

2. Materials transfer management is needed because outside factors affect the location of needs as well as the location of the availability of life support materials

around the space station. In many cases transfers need to be considered against

142
Dl80-27935-

2

uu. o§01*

111

</>Oui

•a

I

O. Q I. ^^

in « i_

41 41 2

S 3 £ o o » «- «- 4, •a fc

 a

(0 *j ~"

It) O oIS

I2 s

8. *s

•aI *~ S * n 1! ii * 5 H X O O

$^^s

fe2

UJ: u uo o

ititi

t U) UJ M UJ

o o

UJ

a<u. 06UJ&Ij

Cfi

•a

7? I DO *: i 8

8. g u E 3 flj *^ ** 0) (0 ro> C i io

to i 2 5 S 3 I S o u o £

;

DO3OO

01DOS 2 oC«o2coU u

-

o

So

n)

toi(0uX§U5 |f § Is I •30 2LOo

I

&0)3 .

2

J- 7 aoDO Io"3

g g

DOC£SoU

V%

ra•s"3oU

143-
D180-27935-2

scheduled events and against dumping constraints as well as impacts on power and

thermal loading.

3. Intersubsystem failure isolation is needed because failure diagnosis outside of

subsystem boundaries will have to be conducted in order to trace the cause through

the interacting functions, e.g. an apparent failure of the separator in the

thermal/humidity control system could be caused by an actual failure in the Water

Quality Monitor (WQM) in the life support that is producing a backup into the

accumulator receiving the condensate from the separators. In this case failure

isolation within a subsystem would not be sufficient to find the problem.

4. Intersubsystem redundant path selection is needed because selection of redundant

paths in response to failures or maintenance shutdown will have to consider the

impact on interacting subsystems.

5. Maintenance schedule management is an integrated function since changes to the

timing of maintenance actions for one subsystem can have affects on the operation

and maintenance of other subsystems. This is because maintenance may cause

temporary shutdowns and may result in changes in performance of the maintained

subsystem that affect others.

6. Startup integration is needed to control the interdependent sequencing of bringing

subsystems on line so that outputs are available before the need is created.

The following paragraphs give a more detailed description of each of these functions.

5.3.3 Functional Descriptions

The integrating controller described here is an overall management controller that processes data and commands functions that effect the automation of the following space

station utilities producing subystems: electrical power, life support, and thermal control. It is assumed that each of these subsystems is automatically controlled within

itself to track references in the presence of disturbances that effect the controller variables. The integrating controller then will basically change the references to these automatic controllers or change the configuration of the automatic controllers or of the

subsystems being controlled in an orchestrated or integrated manner. Figure 5.3-3 shows

144-
Di80-27935-

2

II!

OZo-

zOec

<J=0

ifco: lso§!

oc§o

tc. o

o

CO

111oo

=>iu

Off

X.UI«

-

(Ut

I

*

<tu

Ol-

u,wSi 5

0«

OCMW ^-ufO II

1s8V)

Ul...

=s

I!ui

Ul

O

.e

I

5

<0

3Ul

S

£Ig!1!

te

If*

(A

gII!

ui

-ipo

145
D180-27935-2

the overall relationship of the integrating controller to the separate automated subsystems.

The functional goal of the integrating controller is to manage the interactions between

the separate automated housekeeping subsystems so that the overall system may continue to operate through events or conditions that are not nominal. The controller will

not attempt to maintain the subsystems at specific performance levels through these

anomalies, but rather will select a response to the anomaly which will be determined by

the controller to be most workable. The controller will consider current as well as scheduled tasks of each of the subsystems. It will also consider levels of criticallity of the

separate subsystems based on life support of the crew and support of the mission and it

will consider the status of subsystems being controlled as well as expected loads on each

when making its determinations. The following paragraphs describe major functions of

an integrating controller.

3.3.3.1 Electrical Power Load Management.

Figure 5.3-4 shows a block diagram for the electrical power load management part of an

integrating controller's function. For this function, the integrating controller receives

data that shows that the loads imposed on the electrical power subsystem are greater

than the supply. These data could be dropping voltages or rapidly decreasing battery

charge level.

The integrating controller will establish initial priority for those loads which are on line

in the housekeeping area. Table 5.3-* shows an example of such an initial priority list.

Table 5.3-5 gives criteria that are used in determining the initial priority of loads. The

integrating controller then adjusts the priorities for predicted load requirements and also

adjusts according to the status of the subsystem using the power, e.g., the level of produced material that is^in storage, the maintenance status or the failure probability status

for that subystem. This adjusted priority list will be examined to determine which loads

may be either shut down or reduced. The loads that can be shut down or reduced are so

commanded and a time assessment is made by the controller to determine when the loads

need to be resumed. The controller then manages switch on and switch out of loads

through the period of power deficiency. It also makes the determination on whether

degraded or emergency life support modes are necessary, and sets changes to limits on

the individual life support subsystem and thermal control references as needed. In addition, the controller commands annunciation of conditions that relate to those changes in

the life support modes. In summary, the subfunctions of power load management are:

146
D180-27935-2

SOUND ALARM

TO CLOSE

MODULE AWAIT

CREW RESPONSE

Figure 5.34. Functional Block Diagram for Electrical Power Load Management

by an Integrating Controller

147
D180-27935-2

TABLE 5.3-«

Example of Load Priorities^

1. Power to water electrolysis generator for 02* - valves, pumps fans, electrolysis

current.

2. Power to CO2 removal units - valves, pumps, fans, steam heaters.

3. Power to dehumidifiers fans, pumps, valves, separators.

^. Power to cabin air heaters.

5. Power to Hygenic Water System* (this is placed fairly high on the list because, if

production is low there would be a deficiency of hygiene water for O2 generation and

CO2 removal) - valves, pumps, VCD compressor, VCD heater and WQM.

6. Power to TCC unit (oxidizer, heater, fans, valves).

7. Power to CO2 reduction unit (valves, pumps).

8. Power to wash water system* (valves, pumps, hyperfiltration heater, WQM, water

heater).

9. Power to potable water system* (valves, pumps, WQM, water heater).

"Each item on list moves up in priority if high power need is coming up, but moves down

if current need will be reduced in the near future.

*Each with full level of output substance moves down in priority list with respect to any

which is depleted.

148
D180-27935-2

TABLE 5.3-5

Example of Criteria for Functional Criticallity

1. Required to sustain the life oi the crew.

2. Short time allowed without replacement of life sustaining function.

3. Required to maintain continuity of the mission.

4. Short time allowed without replacement of continuity maintaining function.

5. Required to sustain functions of more critical systems.

6. Short time allowed before replacement of sustaining functions.

7. Desired to maintain comfort status of crew.

8. Short time allowed without replacement of comfort maintaining function.

149
D180-27935-2

1. Receive data on power deficiency.

2. Determine loads to be reduced or shut down.

3. Prepare system for shut down or reduction.

a. Transfer of materials in storage.

\

b. Closure of cabins.

4. Select degraded or emergency mode if needed.

5. Annunciate to crew.

6. Implement action.

7. Monitor time and change loads as needed to maintain system balance.

5.3.3.2 Materials Transfer Management

Figure 3.5-5 shows a block diagram for this function of an integrating controller. In

order to perform this function, the integrating controller will receive data on the levels

of water, oxygen, nitrogen, hydrogen, CO2 and any other materials stored in various

places around the space station. ,These data will be compared by the integrating controller with the schedule and location oriented needs for the materials. Any necessary

transferral of such materials about the space station will then be determined and commanded. These determinations will be based on established schedule and location

requirements for material as modified by up-to-date anomaly information. The onboard

transferrals accomplished by this function will allow the space station to share onboard

resources in the most effective manner to survive failures or disruptive events such as

sustained concentrations of the crew or science experiments in a particular part of the

space station. This material transfer process will be an integral part as necessary of any

power shut down, redundant path selection, or maintenance rescheduling action by the

integrating controller. Close off of modules or configuring for degraded or emergency

modes will also be attended by materials transfer determinations and commands provided

by the controller. In the event or over supply, the integrating controller will determine

if dumping is an appropriate solution as well as where and when.

A summary of elements of this function include:

1. Data gathering on storage levels around the space station.

2. Determination of materials transfer needs against schedules or against locations.

3. Command actual transferrals.

^. Monitor time for follow-up transferrals back as necessary.

5. Decisions on the dumping of materials.

150.
D180-27935-2

.151
D180-27935-2

a. Location of dumping.

b. Time of dumping.

c. Alternates to dumping.

5.3.3.3 Intersubsystem Failure Isolation

This function of an integrating controller will be performed after a fault goes undetected

through the fault isolation processes within the subsystems. This diagnostic function will

consider failure indications across subsystem boundaries and will be largely interactive

with the onboard crew to help them trace down those failures. The function will have

numerous paths that will be followed in response to inputs from the astronauts to identify the fault and recommend the corrective action. Figure 5.3-6 illustrates how such a

function could be structured. A summary of elements of this function include:

1. Data gathering on existence of inter-subsystem fault.

2. Annunciation to crew.

3. Interactive process with crew to isolate fault.

4. Annunciate recommended action to crew.

5.3.3.4 Intersubsystem Redundant Path Selection

Figure 5.3-7 shows a functional block diagram for the redundant path management part

of the integrating controller process. For this, the controller receives data indicating a

failed element in one of the automated housekeeping systems. The controller will survey

the configurations existing to determine if a redundant path is available. This will be

done considering any previous failures not repaired or redundant path selections for

maintenance shut downs which may be in effect. Then available paths will be selected,

but preparations will first be commanded by the integrating controller as needed. These

include transfer of materials such as water from a system to be shut down to one that

will experience extra use during the failure, power adjustments, and modifications to the

maintenance schedule. Then the switch of function will be made to the redundant path.

In the event that a redundant path is not available or will only be available for a limited

time (due to materials shortages or essential maintenance schedules), the integrating

controller will decide if a degraded or emergency mode with or without cabin shut down

is needed. It will then annunciate the mode or shut down to the crew and will command

and materials transfer and power adjustments needed to prepare for the selected mode.

The limits on the individual life support subsystem or thermal references will be adjusted

to levels consistent with the selected mode shift. These functions of the integrating

controller are summarized by the following:

152
D180-27935-2

OCOOCL

ui

l!

<0

li

<U.U

<AUI'

&*

M

Oul

UOCH

UIOU

CCO<

O

S=J

W U )\

CO .

^ < ± COIL CD

O

Il

it

^5

UI

15

s

ui

X

UI

153
D180-27935-2

!

1

I

I

11

i?

I

154,
D180-27935-2

1. Receive data on failed system path.

2. Determine if redundant paths are available.

3. Prepare system for switch to the redundant paths.

a. Transferral of materials.

b. Adjustment of maintenance schedules.

c. Power usage adjustments.

4. Select degraded or emergency mode if needed - perform necessary adjustments.

5. Annunciate to crew.

6. Implement action.

5.3.3.5 Maintenance Schedule Management

This function of the integrating controller is displayed by the block diagram of figure

5.3-8. The normal maintenance schedule for all housekeeping subsystems will be established prior to space station deployment. (Usually as the station is being developed.) The

integrating controller will annunciate maintenance actions periodically to the crew in

accordance with that schedule. The controller will also command appropriate adjustments to the subsystems; i.e., power shut downs, materials transfers, or redundant path

selections on schedule to prepare for the normal maintenance actions. Based on data

collected on failure modes, operational conflicts, maintenance supply logistics problems,

or astronaut time conflicts, the normal schedule may be modified by the integrating

controller using coordinated adjustments. Thereafter, the controller will manage

maintenance accordingly and will determine any modifications needed in the logistics

requirements for maintenance materials or manuals. These functions are summarized by

the following:

1. Receive data on schedule problem.

2. Determine if schedule problems are:

a. caused by system failures.

b. incompatibility with operations.

c. failure to serve maintenance needs.

3. Determine schedule change and impacts.

4. Determine logistics changes needed.

5. Annunciate to crew.

This function will be largely interactive with the onboard crew and the integrating controller will be receiving inputs and providing outputs through an interactive terminal.

155.
D180-27935-

2

COUl >

<co

I CL

oo

in|o

•-2

<ui

ice

TMs

it

Ul rw

bui°

< ?»UI

Z^UI

co 5 m

I •**.• II8I

501

*

_|LU TM6

ui

CA

o

-j£S°'

.<S»:ra-

i!

g

o3

X ui

CAO.

a

8Q O < < u

i

Oiuxui cr

Socuco

COui

XUl

CAUl

•Q1S1a'SIII*

156
D180-27935-2

5.3.3.6 Start-up Integration

The integrating controller will support the start-up process by setting parameter levels

for each step of the initialization. These would then be adjusted to account for such

conditions as failure in existence or being handled by workarounds, power load variations,

crew size and dispersement variations, materials levels and deployments and others

which could modify the start up. The controller will then check the parameters against

the set levels and advise the crew when the next step can be taken. Figure 5.3-9 gives a

block diagram illustration of the function and the following summarizes the steps.

1. Receive input that initiates start-up integration.

2. Determine set of nominal parametric values sequenced to the start-up

process.

3. Adjust values to reflect current conditions in the system.

A. Trace parameters against adjusted values.

5. Annunciate instructions on start-up steps to crew.

5.3.4 Functional Scenarios

The following scenarios were developed to describe the operating environment for the

integrating controller. The first scenario is for initialization of a space station system.

This scenario is conceptual in nature and as such is subject to modification as the space

station design develops. The second scenario is for a shift in life support modes on a

space station.

5.3.4.1 System Initialization Scenario

This scenario is to describe events that might occur as a space station module is initialized for habitation by the crew. It is assumed that the shuttle is attached and that the

crew relies on the shuttle systems to support the initial EVA. As can be seen, no

attempt is made to work out the specific number of orbits for this process. The

initialization crew will start out using EVA and then will go to shirt sleeves after orbit L.

The initialization crew would be two or possibly three astronauts and would be joined by

the remainder of the crew after orbit W.

Orbit

1. Close cabins and establish initial atmosphere N

2. Cabin power available . N + M

3. Cabin heat exchangers N+M+1 = L

*. Cabin Trace Contamination Control (TCC) on N+M+1 = L

5. Cabin dehumidifiers on N+M+1 = L

157
Dl80-27935-2

to

U)

cc

<en«

<0

_

UlZCL U.

u.ec

03 5

U1

cc

UI

X

UI

158
D180-27935-2

6. C>2 generators on L+R = Z

7. N2 supply opened L+R = Z

8. Cabin air heaters on L+R = Z

9. CC>2 removal on Z+l

10. CC>2 reduction on Z+2

11. Crew begins cabin occupancy Z+S = W

12. Potable water loop on Z+S = W

13. Hygenic water loop on Z+S = W

14. Wash water loop on Z+S = W

Between 1. and 2., several crew members using EVA will inspect and set up cabin interior

in a physical sense. This will take M orbits to accomplish and then the power to the

cabin will be initialized. After an additional orbit for EVA inspection, the cabin heat

exchangers, TCC, and dehumidifiers will be turned on. This will include astronauts installing LIOH sorbant units and charcoal units in the TCC and inspecting the progress of

the system turn on visually. Sensors in the TCC, as well as temperature and humidity

sensors will be monitored by their respective control systems and the integrating controller will be notified when readings meet specifications. The integrating controller

will then communicate to the initialization crew that the-C>2 generators and N2 may be

turned on. The time required for the TCC, dehumidifiers and heat exchangers to meet

spec will be compared with the expected time by the controller, and if a discrepancy

exists it will advise the EVA crew on possible repairs or adjustments. Once ©2 and N2

are flowing to the cabin the air heaters will be turned on and their operation inspected

by the initialization crew. The integrating controller will be notified when the systems

meet spec, and it will compare performance with the expected time and notify crew on

adjustments to the system. The C©2 removal and reduction systems will be turned on as

soon as the ©2, N2 and air heater systems are determined to be performing properly.

Again, the controller determines if the systems reach specified performance in the prescribed time and notifies the crew that is conducting the initialization of any adjustments which are needed. Once the CO2 removal and reduction systems are on line the

entire crew, may inhabit the cabin. The water loops will then be closed with the integrating controller monitoring elapsed time against the expected period and providing

annunciation to the crew if any repairs or adjustments are needed.

During this entire process, the controller will perform its power, materials transfer, and

redundant path management functions for those systems that are on line.

159
D180-27935-2

5.3.4.2 Mode Shift Scenario

This sequence is the result of a change in the life support subsystem operating mode

between the nominal, degraded, or emergency set points. Again this is a conceptual

sequence of events to be described more specifically after the space station design

becomes more defined.

1. Mode change selected either by crew or the integrating controller.

2. The integrating controller then adjusts control limits for each automatic

system reference to correspond with selected mode.

3. System configured for mode shift as necessary by commands from the integrating controller.

a. Materials transfer.

b. Power adjustments.

c. Path selection.

4. Maintenance schedule adjusted as needed.

5. Annunciation to crew.

6. Implement mode shift.

Astronaut adjusts the life support set point from nominal to degraded or emergency

mode or the mode shift is selected by the integrating controller in response to deficient

operation due to failure, power deficiency, materials enbalance, or maintenance action.

Integrating controller then adjusts control system references to each subsystem automation unit in a scheduled and locational pattern based on the location and status of the

deficiency and the status of the subsystem at the time when the deficiency is detected.

The integrating controller also checks levels of materials in storage, monitors power

deficiencies and failure modes, and commands appropriate transfers, load reductions, or

redundant path actions. The integrating controller reschedules routine maintenance to

occur after the selected degraded or emergency mode is over whenever possible.

If the action involves the shut down of a space station module, the integrating controller

will command the flow of materials from the module to be shut down to ones to be occupied and will verify the egress of all crew members from that module before allowing the

hatch to be closed.

160
D180-27935-2

5.3.5 Hardware and Software Elements

An integrating controller will consist of on-board central and distributed processors that

will initially be supported by an earth-based central data processing facility which can be

used by employing the telemetry link. The processing functions will be largely in the onboard central processor for all decision making and command generating. The distributed processors will be used for data collection and command execution functions. The

earth bound facility will be used for some off-line comparisons and determinations especially for failure diagnostics and logistics control. Figure 5.3-10 shows a typical processor hierarchy and data path connection concept for a integrating controller. The diagram indicates where the functions are in the central processor and where they are

distributed*

The following paragraphs summarize the separate processor functions.

5.3.5.1 Data Collection Processors

These would be distributed processors located near the subsystem elements where the

data is being collected and would perform the following processing functions:

1. Select data to be sampled.

2. Select rate of data to be sampled.

3. Select sequence of samples.

4. Process sample data for presentation to the central processor.

5.3.5.2 Comparison Processor

This would be an entry processing element of a central processor and would perform the

following functions:

1. Compare data received with past data.

2. Compare data received with standard values.

3. Compare data received with other data received.

These comparisons will be used by the decision making processor.

5.3.5.3 Data Storage Processing

This would be an entry processing function of a central processor. The data coming into

a central processor will be stored or discarded and the management of that process as

well as a review of the data in storage for purposes of determining what is to be purged

will be the function of the data storage processor.

161
Dl80-27935-2

»-

8

Ok. w f

si cotOw

2

iii

DNISS33CMM ONVMNOO

ei

'II

2*

IE

r «•>>

-lsbla!

ONIS53XNM WWMITVMUSO

1

1

o

Q

i

I

!

<c

o-

*«k

id

162
D180-27935-2

5.3.5.4 Decision Processor

This is a principle function of. an onboard central processor and includes the following

processing subf unctions:

1. If total power supplied data is less than the total demand data, process a power

reduction decision.

2. If failure data is received process a redundant path selection decision.

3. If materials storage level data is out of agreement with predicted levels, process a

materials transfer decision.

4. If data indicates a change in maintenance schedule as a result of action taken on

failure events, a schedule revision is selected.

5. If data indicates that performance is not being met, a decision on going to

degraded or emergency mode will be processed.

6. If localized performance degradation exists as shown by data received a decision is

processed on closing off a space station module.

7. If a problem indication is detected process a failure isolation interactive routine

and the resulting failure identification decision.

8. If a start-up mode is requested process a start up support and interactive routine

and process start up step decisions.

5.3.5.5 Predictor Processing

The decision processor is supported by several other processor functions. One of these is

the predictor processor. It performs the following actions:

1. Predictions will be made as to the consequences of actions being considered by the

decision processor.

2. Predictions will be processed to identify when an action that has been commanded

must be changed or new decisions must be made.

163
D180-27935-2

5.3.5.6 Priority Processing

Another function that supports the decision maker is the priority processor. As part of

the decision making process, prioritized lists will be established and revised by the priority processor.

5.3.5.7 Command Processing

The actions, sequencing, and quantitative aspects of commands will be processed once

decisions are made. This function will be accomplished in part by the central processor

and in part by distributed processors located where the commands are executed.

The central processor will issue the command in general terms to the distributed processors. Each distributed processor will interprete the general command for the particular

system element that the distributed processor is supporting.

5.3.5.8 Earth Based Processing

Failure diagnosis, logistics modifications, problem solutions for communication to the

crew would be processed initially by an earth-based data processing facility when time

delays from off-line processing could be tolerated. This facility could also be used for

simulation and check out of software modifications prior to implementing them in-the

onboard system.

5.3.6 Expert Systems Considerations

This section consists largely of the responses received to the questions poised under section 5.2.4. The following functions of the integrating controller were indicated by those

responses to be definite candidates for some expert systems processing.

1. Electrical power load management—the MSFC has a study that is being conducted

by Martin Marietta and the indications from that study are that expert systems

apply to this function.

2. Redundant path selection—work is being done to apply expert systems to this

problem for nuclear power plants.

3. Maintenance schedule management—this general area is considered to be a

promising application of expert systems.

164
D180-27935-2

All of the other functions were considered by the responses to be good possibilities for

at least partial application of expert systems.

In theory, expert systems can't do anything that conventional automation can't and vice

versa. In practice, there are differences in application that favor one approach over the

other. Conventional automation seems to be best if the problem is highly deterministic

or when there is a good theory. Expert systems seem to be best in situations where repetii

tive, comparatively low-level judgements are made. Judgements, in this case are decisions for which there are no clear cut guidelines.

The mode select scenario seems to have a substantial judgemental aspect to it. This is

illustrated by the following example:

Assume we have gotten into a situation as shown in the figure 5.3-11. Because there is

no H2» we cannot reduce the CO2- This means we cannot empty the CO2> storage container, which in turn means we cannot purge the SAWD canisters in the CO2 removal

unit. This means that the CO2 level in the cabin may increase to an undesirable level.

There are several responses that may be made to this situation. Some include the following:

1. Dump some CO2 overboard—this is undesirable because it represents the loss of resources, may contaminate sensors, and violates "no dump" space station ground

rule.

2. Generate some 02—this will create H2 so that we can reduce the CO2« However,

this will take time to do, and in the interim, the CO2 may become degraded.

3. Transfer crew to another cabin—this will solve the problem unless the CC>2 removal

unit in the other cabin is operating in a degraded mode, in which case we make

things worse in the other cabin.

4. Transfer CO2 to another cabin—this will also solve the problem unless the other

cabin has a problem too.

165
D180-27935-2

o

(NlU

O O

o

csO

O UJ V

»^ «bi

8

UI

a

UJ .

o

DC

<

2

oc

UI

O

jQ

I

I

I

iri

CO

_l

<

cc.

O

UJ

>

CD

<

u 8

166
D180-27935-2

None of these responses is completely satisfactory. In addition, there may be some secondary factors. For example, a shuttle resupply flight might be delayed, which means that

it is extremely desirable to conserve resources.

It is not obvious that there is a technical answer of what to do in a situation like this.

The approach is to ask what would a space station commander do given this situation?

Design the mode selector to do the same thing. This is the expert systems approach.

On the other hand, not all aspects of the integration control problem require expert systems technology. A hybrid controller may be best. With such a controller, there will be

several expert system components working with conventional parts of an integrating

controller. This is because expert systems are best if applied so that each handles a

single specific type of problem. The integrating controller involves solving several problems that are quite distinct from the standpoint of an expert system. Techniques can be

applied to use expert systems that integrate several other expert systems and the conventional elements using a blackboard concept. Figure 5.3-12 shows how such a concept

might be structured.

Using today's technology, expert systems are not good choices for problems that require

fast solutions (less than minutes). Assuming that life support system operation is synchronized with the sunny part of the orbit, an expert system decision model would run

once or twice per orbit (mainly to set the system up for the transition from shadow to

sun). It would run more often if out-of-the-ordinary situations occurred and that may

require advancement in current technology.

Clearly, the onboard integrating controller needs expert systems, but even if it did not,

there might be advantages to using expert systems technology. For example, the explanation capability often exhibited by expert systems would be helpful during space stations

subsystem development. If an integrating controller were built using conventional automation, it would be so complex and difficult to understand that it would be desirable to

train the crew with an expert system that would explain the behavior of the integrating

controller.

Any estimate of the size of the expert systems parts of an integrating controller is constrained by the following:

167
Dl80-27935-2

168
D180-27935-2

1. The preferred current method of developing an expert system is to use an expert

system language analogous to a programming language for conventional automation. The number of statements in a conventional program can vary drastically

depending on the language. In the case of expert systems, there is probably at

least a 3:1 variation in number of rules depending upon the language used.

2. Expert systems do not have to be developed using rules. Rules are a knowledge

representation technique. There are other ways of representing knowledge including:

a. Logic

b. Networks

c. Frames

d. Hybrid

This is one reason why an integrating controller would involve several expert systems for

its different types of functions.

Given the above caveats, it was estimated that as an example, the inter-subsystem failure isolation function expert system would involve from 1,000-3,000 rules, and in that

case using rules for estimating is probably a good way to go.

Factors to consider when describing whether to use space-borne or ground-based computers for the integrating controller include:

1. Criticality—will the astronauts be threatened if access to the integrating controller is interrupted?

2. Resource usage—does the integrating controller use an excessive amount of space

borne computer resources?

3. Data bandwidth—does the integrating contoller process so much data that transmitting it to earth would jug up the communications channels?

Because of the criticality of the failure isolation function and redundant path selection

function, they would be high priorities for space borne implementation. Maintenance

scheduling could probably be ground based at least in the early stages of the space

station.

169
D180-27935-2

In order to estimate the space borne computational capability required, several assumptions will be made:

1. The expert systems used will be programmed for the onboard system using the LISP

programming language. (LISP is a heavy user of resources).

2. The space station has a distributed processing system consisting of general purpose

as well as special purpose processors.

3. General purpose processors are machines with 32 bit CPUs, 2 MIPS throughput and

1 megabyte of memory.

4. Mass storage will be available to store expert systems rules when not actively

being processed.

Based on these assumptions, it is estimated that an expert system implementation would

require a general purpose processor for active processing of each expert system function

of the type exemplified by inter-subsystem failure isolation system.

Any large expert system might require a special purpose processor, and unless the function was extremely critical for crew safety, it would not be space borne.

To estimate the effort needed to develop an expert system a single function such as the

failure isolation is guessed to require at least 5-10 man-years of effort. Assuming one

expert system per function, 30-60 man-years of effort would be required. (Currently 5

man-years seems to be the quickest any expert system can be developed).

All of this indicates that expert systems have a role to play in the integrating controller

concept, but that they are, when based on current technology, heavy users of computational resources and also of development .effort.

170
Dl80-27935-2

5.3.7 Trade Study Comparisons

The results of the concept characterization studies for an integrating controller are

basically the definitions of functions to be performed by such a controller and concepts

for processing of those functions on board the space station or on the ground using distributed as well as centralized architecture. This paragraph discusses the comparisons

conducted with respect to these characterizations.

Figure 5.3-13 gives a trade of the functions of the integrating controller against five

fairly nonquantifiable criteria. These are:

1. Frequency of use—this means the relative number of usage instances for the function over the operation period of a space station (one time, often, continuous).

2. Autonomous processing-this is an assessment of how much the astronauts will want

the function to be autonomous.

3. Essential for safety-functions are assessed with respect to how essential they are

to maintaining a space station that is safe for the astronauts, the visiting shuttle

and the space station missions.

4. Deterministic processing—this is an assessment of how much of the function is

based on data and how much is based on know-how of people.

5. Durability-this is an assessment of wheather the use for the function will increase

or decrease as the space station matures.

The cumulative rankings of the six functions against the criteria used gives the following

results:

Electrical power load management = 7

Materials transfer management = 9

Intersubsystem failure isolation = 10

Intersubsystem redundant path select =11

Start-up integration = 17

Maintenance schedule management =20

 x

171
Dl80-27935-

2

SB<SsI

KioHI ou.oI

I= ui.

U.U

00

is!i

I- WCDiao

OPTION

STARTUP

INTEQRAT

.Si

• <y>

s 52

I 65

PTION

BSYS INTERS

ISOLATI

§KUI

M ~ > S M§eei§SE

55

IN!§i

HI I•E u. 82

xm

PO

> KM%

fetf sMi tE***=flc

it°3s *•» Ufck•. K — 0g«*ouiK

>

glPil

Isisc!

55£|tS

l!M:

KH.

3|i»B-«

sSggsss

SEoSJ-'t

§1*1153

>K> 3 tfc w i

!!pPUI

aI

- S

23=s;==3 ill I£

fl

isli

II;

l it

!1- S1

II•IiI

iii=is«

§

0

So<

e

°

isiili • TM » «J ^i K

gI

SSo

£ vui

^S«= j-£u*

lis

s=r

Siu<

_<oo

iu.

3.1 3.

«

1E9°-2!

t

SeSSsI

!!i

il

ii

iati53*

.

•zlMt

5tui

=*< sife

§i£

iii|

SffS

^<I x5;g wu. ^5

iiil

i i * s

ss

172
D180-27935-2

This indicates that the start-up integration and maintenance schedule management are

of lower priority than the other four functions. This seems somewhat reasonable since

the space station would need the first four for smooth and safe operation while the last

two would be more like convenience functions.

The trades between distributed versus centralized architecture are based on mass, vulnerability, maintainability, and cost.

1. Mass-greater on-orbit mass with distributed, but modern computer technology may

make the difference trivial.

2. Vulnerability-greater vulnerability to failures with centralized because functions

are not repeated. This means that one location failures could result such as thermal

contact failure, grounding failures, meteroid hits, etc. Even with voting the centralized system would be more vulnerable to failures.

3. Maintainability-distributed system is more easily maintained because repeated

processing allows natural on-line/off-line configurations. Also standardized

components are more easily replaced.

b. Cost—this trade is not clear. There is more hardware with a distributed system but

it is standardized and therefore not as expensive. There is more network operating

system software with a distributed system but interfaces are defined by the

standardized hardware.

In general a distributed architecture is favored where the requirements for computing

capacity indicated by the function do not dictate extremely large units that would not be

practical to duplicate on board the space station.

The trades between onboard versus ground processing are based on the cost of ground

facilities to communicate with the space station as opposed to the cost of placing the

facilities on the station with the mass and logisitics penalties as well as the the qualification costs. Also, onboard mission control would be less labor intensive and therefore

those costs would tend to be less although the labor rates would be higher in space.

173
D180-27935-2

The comparison of a fully automatic system versus one where the astronauts interact

thru a computer terminal involves human preferences. In many cases the astronauts

would probably prefer not to be bothered with routine diagnosis and corrective action but

in others such as scheduling and logistics the astronauts would probably want to maintain

control. In a few cases such as attitude control or some power control the diagnosis and

corrective action could require faster response than that which is consistent with human

capability and that would favor the fully automatic approach. Finally the acquisition of

a knowledge base to develope the integrating controller system will benefit by the interactive experience of astronauts during the early missions. All of this indicates that the

early space station will be characterized by a great emphasis on interactive controllers

but as the station matures many functions will want to become fully automatic.

5.3.8 Cost and Benefits Analysis

Based on the integrating controller characterization developed in this study and the trade

study considerations identified above an update of the cost and benefits for advancing

the expert systems technology can be established. In section 4.1.8 of volume II of the

Advanced Platform Systems Technology Study Final Report a cost and benefits estimate

was made for the expert systems technology for an integrating controller. In the current

study we have developed a more detailed description of the functions of the controller

and have focused on the programatic trades with respect to those functions and that

allows a more realistic estimate of costs and benefits.

The following assumptions are established for the cost update of this current study.

1. Six expert system functional elements plus one expert system selection element

will be considered.

2. Each element is equivilent to one Rl expert system program (850 rules) except the

intersubsystem failure isolation element, which is assumed to be 2,000 rules per

section 5.3.6. This gives a total of 7,100 rules for the integrating controller expert

systems.

3. Based on the productivity of section 5.3.6 each rule requires 2 days of labor to

develop. This is better than the productivity rate of 5 labor days per rule used in

the previous study. We will assume the more conservative 5 days per rule rate.

174
D180-27935-2

4. Assume a labor rate of $400.00 per man-day for expert systems software development (this is nearly double the rate assumed for the last study).

5. Assume $1M for verification of each element for a total of $7M.

6. Based on the estimate of one general processor for each on-line function plus one

for the expert system selector, we can estimate that at least three onboard general

processors would be needed to implement the system. Assuming $1M for each we

have $3M for additional hardware.

Assembling the results of all the assumptions above gives a cost figure for the expert

systems development and implementation of $24.2M.

For the benefits estimate we will consider a phased introduction of the integrating controller expert systems. This means that the yearly savings assumed in the previous study

would be reduced.

The following assumptions apply to the benefits estimates for this study.

1. The labor to monitor the space station systems would be phased out as the integrating controller is phased in as follows.

a. For year 1: Six ground-based mission controllers plus & time astronaut (full

coverage)

b. For Year 2 thru year 5: One ground-based mission controller plus fc time

astronaut. (Reduction of five ground-base mission controllers for 4 years.)

c. For year 6 thru year 10: 1/10 time ground-based mission controller plus 1/10

time astronaut. (Reduction of 5.9 mission controllers arid 0.4 astronaut for~~5

years.)

2. Mission controller labor rate is $1500 per 24-hour day or $550,000 per year for each

controller.

3. Astronaut labor rate is $77,000 per 24-hour day or $28,200,000 per year.

4. Resupply and maintenance cost savings due to the integrating controller are estimated as $25M over a 10-year mission due to more efficent use of resources onboard

and more managed maintenance operations.

175
D180-27935-2

5. Half of the above benefits of an integrating controller can be attributed to use of

expert systems.

Based on the above assumption the benefits of the expert systems part of an integrating

controller are estimated at

The resulting cost to benefits ratio then is 0.44. This is a significant movement from the

0.098 ratio estimate of the previous report but still leaves the expert system development with all the associated unquantified benefits as an attractive tecnhology for

advancement.

5.3.9 Identification of Technologies for Advancement

The technology indicated for advancement is to support the development of an integrating controller for a space station using expert systems for the mechanization of controller functions.

The following tasks are identified to describe the needed advancement in order to provide for an integrating controller on the space station.

1. Define expert system decisions.

Review the functions of the integrating controller and identify where non deterministic deicisions have to be made. These would be decisions that either depend

on more data than is available or on processes that have not been previously

codified. In some cases expert systems decisions will be those in which no clear

process is available and the best, to our expert, process will be used.

2. Acquire initial knowledge base.

Identify and set up interview sessions with a set of experts to provide knowledge

for, each of the decisions identified. These interview sessions would be conducted

by knowledge engineers or specialists who would be trained in the use of natural

language programming and who can interact with the expert to extract the

knowledge. The initial experts will be chosen from candidates who are:

a. Skylab or Shuttle Astronauts

b. Mission Control Center Specialists

c. System designers

d. Technical specialists

176
D180-27935-2

For each decision process, one expert will be selected and used to develop the initial knowledge base.

As a part of developing the knowledge base the knowledge engineers will code

expert systems rules and interact with the expert on the result.

3. Program the integrating controller functions.

Using the expert systems decisions with the initial knowledge bases and the deterministic functions, each integrating controller function will be programmed.

System modules will be identified that can be stored off line and called up by an

expert system selector elements to implement the overall integrating controller.

Initially, the system will be an interactive or advisory type. This means that the

astronauts will be performing functions as data gathers or implementers of action

according to interactive advise given by the system.

4. Exercise the integrating controller with future space station operation astronauts.

Using the integrating controller programmed into an interactive system conduct

exercises with future operations astronauts for the space station using a set of

situations typical of expected space station anomalies. Using the results of this

exercise return to the experts with any needs for updating or adjusting the expert

systems, or the other parts of the integrating controller.

The following tasks are identified to implement the initial integrating controller.

1. Establish the baseline integrating controller for the initial space station.

Using the updated integrating controller program establish flight software that is

tailored to onboard flight hardware and to an operational architecture to be used

on the space station.

2. Verify the integrating controller flight baseline.

By using the system in a space station mockup with operations astronauts and a set

of expected situations, check out the baseline integrating controller.

The following tasks are identified to describe the needed updating of the initial system

to reach the desired configuration.

177
D180-27935-2

1. Update the baseline system.

During the first several years of flight, the operations personnel for each crew

would be interviewed by knowledge engineers as they return from their 90-day

tours. These interviews will be used to update the knowledge base for the expert

systems used on the space station.

2. Automated integrating controller functions.

Based on astronaut experience functions to be automated (rather than being interactive) will be identified. This will be largely in response to astronauts preferences; some things they will want to hang onto others they will want to be rid of.

For those where sensors or actuators are feasible integrating controller functions

v

will be reprogrammed to rid the astronauts of unwanted interactions. An ongoing

program to identify where sensors/actuators are likely to be wanted and to initiate

necessary developments should be defined early in the effort.

5.4 SUMMARY OF RESULTS

This section summarizes the results of the tasks conducted on the Integration of Automated Housekeeping for an inhabited space station as part of this study.

5.4.1 Task 1 Results

The first major result is the identification of automation functions and quantities to be

sensed to perform those functions. Tables 5.3-1, 5.3-2, and 5.3-3 list these for the electrical power subsystem, the life support subsystem and the thermal control subsystem

respectively. These functions and sensor indicators were used to identify the major

result of task 1. This result is the description of six functions to be performed by an

integrating controller. These six functions are described and diagrammed under section

5.3.3 and are listed here as follows:

1. Electrical power load management.

2. Materials transfer management.

3. Intersubsystem failure isolation.

4. Intersubsystem redundant path selection.

5. Maintenance schedule management.

6. Start-up integration.

178
D1SO-27935-2

Another result is that the processing for the integrating controller will be partly functionally distributed .and partly functionally centralized on board the space station. The

exact organization of hardware remains undetermined at this time because the configuration of the space station as well as groundrules for the architecture of the data processing system are undefined. Figures 5.3-10 and 5.3-12 give indicators of how the system

architecture and integrating controller hierarchy might be managed in a functional sense.

The final task 1 result was a review of expert system applicability to the integrating

controller that indicates the following:

1. The integrating controller functions would profit from use of expert systems.

2. That the expert systems would require a large onboard data processing capability.

3. That selection of on-line expert systems elements from a mass memory storage

device by an expert systems selector would be necessary.

4. That expert systems development costs would be significant because this integrating controller application exceeds anything that has been done to date in expert

systems technology both in size and in the breadth of the functions covered.

5.4.2 Task 2 Results

The comparison of integrating controller functions indicated that the maintenance scheduling and start-up integration function were of lower priority than the other four.

Ground-based control and interactive onboard control have advantages in an early space

station program with more autonomy both to the space station and to the automatic

systems on board as the space station matures.

The cost of developing expert system elements for an integrating controller was reassessed based on the characterization developed in this study. The result was an increase

in the estimated cost from $9.0M to $24.2M. Part of this was a more realistic labor rate

figure for knowledge engineers and LISP programmers and part was the inclusion of implementation and post-launch updating costs.

179
D180-27935-2

The benefits from the expert system elements were also reassessed based on the phased

implementation of the integrating controller now seen as a more likely possibility. This

produced a $54.3M benefit as opposed to the $92M benefit estimated in the last study for

the first ten years of the space station program.

The resulting Q.M cost benefit figure for expert systems advancement is not as enticing

as the 0.098 figure produced in the last study, but the greater figure from this study still

indicates a worth while technology for advancement.

5.5 CONCLUSIONS

The conclusion from this study are:

1. The integrating controller has real and useful functions on a space station.

2. The implementation of the controller would profit from expert systems programming.

3. The implementation will be phased and updated during the early years of the space

station operations.

4. The costs are high but so are the benefits.

5. This technology advancement is essential if the space station autonomy/automation

philosophy listed on table 5.1-1 is to be implemented.

5.6 RECOMMENDATIONS

The recommendation from this study is to proceed with the technology development for

expert systems elements and the implementation of an integrating controller as outlined

in section 5.3.9.

Volume ni of this report includes a section that defines a plan for development of this

technology and implementation on a space station during the 1990's.

180