General Disclaimer

One or more of the Following Statements may affect this Document

This document has been reproduced from the best copy furnished by the 

organizational source. It is being released in the interest of making available as 

much information as possible.

This document may contain data, which exceeds the sheet parameters. It was 

furnished in this condition by the organizational source and is the best copy 

available.

This document may contain tone-on-tone or color graphs, charts and/or picture

which have been reproduced in black and white.

This document is paginated as submitted by the original source.

Portions of this document are not fully legible due to the historical nature of som

of the material. However, it is the best reproduction available from the original 

submission.

Produced by the NASA Center for Aerospace Information (CASI)
(NASA -CR-175,160-Vol-2) AN ATTACHED NAXLCAD N84-17103

UFEHATIUNS CENTER (APCC) Al ThE GODDARD

.SPACE FLIGHT CENTER (GSFC) , VUUME 2 Final

Report (Engineering and Bccnomics Research, Unclas Inc.) 40 p HC AO.iIMF A01 CSC1 14D G3/14 11657

a

r.

4

e

99

• 

.a

ENGINEERING & ECON®MICR RESEARCH, INC.

9

i
w __

t

p

4

f

P

AN

ATTACHED PAYLOAD OPERATIONS CENTER (APOC)

AT THE

GODDARD SPACE FLIGHT CENTER (GSFC)

Volume II

Prepared for:

National Aeronautics and Space Administration

Goddard Space Flight Center

Greenbelt, MD 20771

Under Contract Number: NAS5-26962 Mod. Six (6)

By:

Engineering and Economics Research, Inc.

1951 Kidwell Drive

Vienna, Virginia 22180

December, 1983

t
TABLE OF CONTENTS

Section Page

1.0 INTRODUCTION 1-1

2.0 APOC OVERVIEW 2-1

3.0 DATA FLOW 3-1

3.1 SIPS 3-5

3.2 APOC Switch 3-13

3.3 MSOCC Switch 3-14

3.4 AP 3-17

3.5 Operational and Support Rooms 3-18

3.6 Access 3-18

4.0 TIMELINE CONTROL 4-1

4.1 SIPS 4-1

5.0 OPUZATIONS PERSONNEL 5-1

ii
LIST OF FIGURES

Fie page

2-1 APOC Overview 2-2

3-1 GSFC Attached Payload Operations Center (APOC) Block Diagram 3-2

3-2 2nd Floor Floor Plan 3-4

3-3 Ground Floor Floor Plan 3-6

1 5-1 APOC Operations Management Structure 5-1

LIST OF TABLES

Table Page

2-1 TDRSS Ku-Sand Downlink for Spacelab 2-3

2-2 HRDM Output Data Streams 2-4

3-1 Planned MSOCC Upgrades 3-3

3-2 Facility Floor Space (Sq, Ft.) 3-7

3-3 HDT Characteristics 3-8

1

^ 

{ s; 111

,.- . ..r - - - ter• -..:. ._. a.. ...
1-1

1.0 INTRODUCTION

A functional design for an Attached Payload Operations Center (APOC) has

been prepared and is documented in Volume I of this report. The APOC was

r designed to support both Spacelab and non-Spacelab payloads. Early

consideration was given to the support of the Office of Space Science (OSS)

-3 thru 7 missions, which were renamed ASTRO following the transfer of

mission management responsibility to the Marshall Space Flight Center 

(MSFC). In addition, the requirements to support other attached payloads

including several assigned Goddard Space Flight Center (GSFC) management

responsibility were considered. These included the Solar Optical Telescope

r

(SOT), OSS-2 (renamed Shuttle High Energy -Astrophysical Laboratory (SHEAL)), 

Environmental Observation Mission (EOM) -A and Starlab.

The APOC concept as designed capitalized on existing and planned GSFC

I facilities and the remote Payload Operations Control Center (POCC)

capability currently being brought to operational status to support free

flyer launch and retrieval from the Space Transportation System (STS).

This latter capability is provided by the Shuttle/POCC Interface Facility

(SPIF). The SPIF provides a centralized capability for supporting specific

STS management functions thereby avoiding the need to duplicate these

capabilities for each POCC interfacing with the STS. The SPIF is the first

remote POCC to be interfaced with the Johnson Space Center (JSC) Mission

Control Center (MCC), which is responsible for the command of Orbiter flight

and flight safety and resources management for the STS. Utilization of this

facility within the APOC is significant since its capability will be

demonstrated shortly in the support of two free-flyer programs in 1984.
The Multi-Satellite Operations Control Center (MSOCC) facility was also

y 

5 

}F

included as an integral part of the APOC functional design. This facility

undergoes continual upgrade to maintain operational capability for the

various free-flyers supported out of the GSFC. It provides a multi-mission

r POCC environment for support of up to six simultaneous missions plus software development. Utilization of this facility provides a proven operational environment and a lower APOC sustaining cost as a result of a distribution of overhead functions.

Channel two (2) and three (3) data from the Spacelab for payloads utilizing

this European Space Agency ('ESA) system are input via the Spacelab Data

a

Processing Facility (SLDPF). This facility was developed to provide the

necessary data proci^:ssing functions and data product generation capability

e

. for data received from Spacelab payloads. The facility is configured with a

Spacelab Input Processing System (SIPS) providing necessary data capture, 

u

demultiplexing, Data Quality Monitoring (DQM) and data accounting functions;

and a Spacelab Output Processing System (SOPS) providing editing/formatting, 

time ordering and overlap removal, input/output decommutation, ancillary 

.^ processing, data accounting and data product generation. To support APOC

additional SIPS capability was included to provide necessary capability for

POCC functions.

Various other GSFC insititutional capabilities were utilized in the APOC

design to provide required capability. These included the Flight Dynamics

f Facility (FDF) providing mission analysis and computational support, and

operational and definitive attituda computation, the Command Management

System (CMS) providing payload command management and a mission planning

system providing the necessary tools and planning capability to support

attached payloads with a link to the CMS.

4'^

1-2
t

a'

H,

2.0 APOC OVERVIEW

An overview of the APOC is shown in Figure 2-1. For Spacelab payloads

channel 2 and 3 data are ;input via a Statistical Multiplexer (SM) to the

various SIPS functions. These include recording of the data on High

Density Recorders (HDR), DQM and demultiplexing of the composite data

stream by the High Rate Demultiplexer (HRDM). This system performs the

inverse functions of the onboard Spacelab High Rate. Multiplexer (HRM)

enabling access to the data streams as multiplexed onboard the Spacelab.

The contents and characteristics of channels one, two and three data as

downlinked by the Tracking and N,ta Relay Satellite System (TDRSS) Ku-band

are shown in Table 2-1.

Channel one data is received by the MCC and processed with selected

information provided to the APOC via the SPIF. This is received via the

MSOCC switch. This includes Payload Data Interleaver (PDI) and Payload

Parameter Frame (PPF) data from non-Spacelab payloads, which are input for

processing by the SPIF or MSOCC as required. It should be noted that the

SPIF is a separate facility, but utilizes several common systems

capabilities with the MSOCC.

Output data from the HRDM are synchronized and input to the MSOCC via the

APOC switch. The HRDM output data streams are shown in Table 2-2. The

APOC switch has the capability for switching data streams up to 10 Mbps.

Higher rate streams are patched on a mission-unique basis. Seven Frame

Sync/Parameter Select (FS/PS) units are integral to the APOC switch and

provide the capability to select subsets of required data streams. These

streams can include selected experiment channels, the Experiment Computer

Input/Output (ECIO) or Subsystem6 +;omputer Input/Output (SCIO) stream.

2-.1:
tfc

G. c

2-2

Q

C'4
f

u

2-3

t" g

N ^

U) O

J a m LC)

W A

¢^ (D=w ^ ao0 tY 1 H^ O Z

r-+ I = -J== W J

O

(D(MOZA= =QUA CJZWZ

A =M <>UV c** > _-00-4

O

V

V > N

N cn

CL CL w

J J J A F- % cs^

~

CV

ZQLLJQ

Z N

W ^j, Q^ZWW

Q (DLO (D w O 2 W V. V

U A O A O u ►" V 0. O W2cncn>

O O

q

cn cn Q to cn Q ^' J tt n. J ..J o. Cl. J Q

i—Y1 2:v MY f V J

C'3N--r (Y. a 0 C1 C" "' U

► + M LO LL. to CT Ld LL. C) Cn V ""

AW

o a

^ A t--{ ('V U.

W O N

z^Qrr cLa.a)f

.o

v

vAi

t^0w

N ^^

r-1

4 p

I-1 3

H

.b

q

ad

A

E-4

P

is

f
3

Q,

Tab? re 2-2

HUM Output Data Streams

^^ 6i

ii 4 d

Data. Strum Number Bit Rate

Experiment Channel 16 200 bps up to 16 Mbps

High Data Rate Recorder (HDRR) 1 2/4/8/12/16/24/32 Mbps

Payload Recorder (PR) 1 1 Mbps

Experiment Computer 1 200 bps up to 0.5 Mbps1

Input/Output

Subsystem Computer 1 200 bps up to 0.5 Mbpsl

Input/Output

GMT 1 Retrieved from downlink

states words

1 Maximum Input Rate 25.6 Kbps

t

Y_

b

2-4
Data streams may be input for processing by an Applications Processor (AP)

or provided to a user room for processing by experimenter provided

Electrical Ground Support Equipment (EGSE). The AP could typically provide

simple processing such as limit checking of engineering data contained

`r

within the ECIO or arithmetic operations on a subset of an experiment

channel to support an insttiument monitoring function. In general processing of scientific data to support quicklook analysis would be provided by

the EGSE. A maximum of 2000 parameters per second (16-bits per parameter)

may be input to the AP for processing, although this capability is planned

to be increased to 4000 parameters per second in January, 1986. A Near-

. 

Realtime (NRT) capability is provided, whereby STS and payload parameters

are stored for on-demand access on a shared basis. This system has the

K

capability to store 500 STS pa,A arieters per second (extracted from the STS

data contained within Channel one and transferred from the MCC) and up to

w:^ 

9200 payload parameters, where these latter parameters are extracted from

the various data streams and subsets provided from the APOC switch and/or

r° the PDI and PPF.

w

μ Output of the results of the processing within the AP are transferred via a

Virtual Interface Processor (VIP) to various peripherals contained within

the Payload Control Rooms (PCR) and/or Payload Support Rooms (PSR) as

4

x,

required. These include terminal devices consisting of a Personal Computer

(PC) with floppy disk and dot matrix printer, and/or a Strip Chart Recorder

(SCR). Forty PC terminal systems are included in the APOC upgrade of the

MSOCC facility, and a total of seven SCRs will be made available.

Commands may be input via the terminal devices and transferred to the AP 

for processing and uplink 'via the MCC. Other command modes supported

include direct transfer of commands from EGSE to the AP and/or transfer

a

2-5
from a reiaote location to the AP. Command types include, realtime: time

tagged, discrete (on:.Jf), group, procedure, restricted and critical; and

preprogrammed: command memory load, Dedicated Experiment Processor (DDP)

and microprocessor loads, and Experiment Computer Operating Syste% (ECOS)

and/or Experiment Computer Applications System (ECAS) loads/ updates.

The APOC hardware and software processing resources are configured by the

Data Operations Control System (DOGS). This system has the necessary

smiitchi.ng and control capability to meet APOC scheduling requirements and

configuration of required telemetry and command data formats. In addition

the Data Operations Control (DOC) area has communications links (data

lines, SCAMA [switching, c^onfereneing, and monitoring arrangement] ) CCL

[closed-conference loops] and PBX [private, business exchange] telephone) to

establish interfaces with other support facilities as required.

s

.R

2--6

IF
u

t^

I

J

3 , 0 DATA FLOW

A detailed block diagram for the APOC functional design is shown in Figure

3-1. This diagram shows four SIPS processing lines. SIPS A&B are the

present SIPS capability included within the SLDPF. SIPS C is a proposed

augmentation of the SLDPF to provide capability to support the APOC

operational requirements. SIPS D is a planned augmentation to provide

additional SIPS capability to meet the increased SLDPF processing

requirements of the projected flight manifest. SIPS C&D as propooed

utilize the proven design of the current processing lines. The only

difference being a reduction of the number of HDRs from 5 to 2 for the C

and D processing lines. This reduced number was determined to be adequate

to support the APOC operational requirements for data recording and play-

back, The SIPS A&B processing lines provide the NASA wide capability for

Spacel p,', ;:fission support and also support the SOPS.

The layout of the MSOCC including the MSOCC switch, Telemetry and Command 

(TAC), Recorder/Utility Processor/SimzAator (RUPS) and AP units utilizes

the current MSOCC system with planned upgrades. These include the AP, TAC

and DOC processor upgrades shown in Table 3-1 and a local Area Network

(LAN) and VIP switching capability. These upgrades are planned to maintain

required capability to support future free-flyer spacecraft. The VIP is

shown communicating to various terminal devices within the PCRs, PSRs,

Mission Support Room (MSR) and/or user rooms. The layout of these rooms

and the terminology correspond to a revised floor plan for the APOC within

building 14 at the GSFC. Figure 3-2 shows the revised floor plan for the

second floor. The noticeable difference from the current configuration is

the inclusion of two PCRs for APOC support. With this layout inclusion of

the adjacent Mission Operations Room (MOR) with the PCR may be undertaken.

3-1
IME

SWITCH

tAC

orR"

!2/J7

MI UICR

MCC 4

SOI'S /

USERS

D111ST TIME

11. 2 OR 3 IR1, HI

II0I1 A

DATA IIIIRR/1'LRI

VOICE

STAIUS/CONWI,

DATA OUALIIY SCL"A

MONITORS SEL•I

1.1,

90AST

32/D7

tl

COMPUTER

CIII

POI /ANC I LLARY&K

-

4

AP DAY MIA;

(DARE Of 2i

ORIGINAL PAGE 19

OF POOR QUALITY

CI LLMXZRIAS

Iryp 101[ DF

5 NIWI • DEMSITT ^A't

^r^rotrae DATA

WANAEl I All PMA41TY P

2 RESOLVER A

T

ASCOK C

SIAI N

MIIX

C

CNAM[ ^^ 01; f9lAR1TY M

^— 3 KSOLVCR C

sT TIME STATUS/

CIWNIEL^07^ } I^IT

NO"

CCONfRDAtA CO pTER ^

APK SNITCH

PD DATA (IAAR/PLR)T D

VOICE

SiAIUS/COIIIMIOL

°ALA WALITY L C ECIO

MONITORS D P SCIO

MDT ANAL 0 EIP DATA

AffDIM1EAS USER' C

2 N ,. IISItY R

DATA P !-

FAM A

f

----

C

VOICE II

FRAME

SYNC

PARAMETER

SELECT

FOAMATIER

11A ME PARAMETER

-

FORMATTER

SYNC SELECT

FRAME PARAMETER

FORMIAITER

SYNC SELECT

FAAME -P-m-mm MWATTER

SYNC SELECT

FRAME PARAMEIER

SYNC SELECT fOPlIATTER

FRAME PARAMETER FORMATTER

SYNC SELECT

FRAME PARAMETER

FORMATIER

SYNC SELECT

PD DATA (HDRR/PLR)

Df11UK

RK=j P 

CIIAMNEL 2 OR 3 fRf, PI A

BURST flSOPS

N CONfROLIER CGMfROLLER

DSEASE

 '—TRIM, ATUS

L } >10 MR DATA STREAMS

r

0113002 

TRARSIAIOR MARL DISTRIBUTION

Figure 3-1. GSFC Attached Payload Operations Center (A.POC) Block 

FOLDOUT FRWE
r^ Iq0 it

ewru.t. erru A env

ORIGINAL PAGE F

OF POOR QUALITY

r

UIRANU

f'ICCS 1°0.^/PPf/eANCII

FRAME

PARAMETER

MAMATTER SVC T

FRAME PARAMCIER

FORMATTER

SYNC SELECT

FRAME PARAMETER

FORMATTER

SYNC SELECT

ON -PARRVER

FORMATTER

SYNC SELECT

FRAME PAAAMEIER

SYNC SELECr

FORMATTER

FRAME PARAMETER

FORMATTER

SYNC SELECT

FRAME PANNIER

FORMATTER

SYNC SELECT

HIATUS __`. 'LUa lut—t — L >10 me DATA SIREAMS u'"^"ni i"iva IRKS I CONTROL/

^,.._ ^- cY l

-----•^ fNIE OC 2 f^;IUS

u^r SUA

} G1r 01STRIBU110N _

GMr

IgharnnoNS

TRI1NS1 A► OR JJJ

,c DiaeFC Attached Payload Operations Center (APOC) Block Diagram

3-2

FOLDOUT FRAME

^.^JIINMINM I

1 _\^+llJ1 ^

L_ J

j ^MR I'1 ^ j

1 IIIn11M ^

( uzI )

t

1 tlelfNA 1

+f31 I

^MR 2 - 1

1

IIAIIINAI 1 'I "'^fS( I

1

1

^

II.rR11NAl A

fRl 1

1

I IIIH)NAI 1

I 1%1 I

1 1

SCR I

r

-----

WN R4uM2

j^ ICAMINAI 1

^ l31

SCR I

L_ _J

`usEll`ROfNi s^

I

I

AENMIN I

i (31 I

1 SF.R j

L_ _J

r" tGfNINx1M 4^

! IFNMII

1 f21

1

1

1

L

^ (ISER 1100M 5 ^

1 ERNI I

M (2)

sa I

L_ _J

1tSEl1 RUU11 6

1 CAMINAL 1

121 1

1 i

SCR 1

L_ _J

USEA —P 0—ffl 7

1 TERMINA 1

SCR 1
bw

b0aD

t*1 U

H vCC

cd

r-I

P4

IIatC

t"

00

Crr-1

:.s

Lo

00

CT^

II^^

MMW W

Lr%

00 Ln

00

Ol

OHO

D

\

CT

0h

C') 00V

UD

0

t.^

00

00

M

00

m

C.^

nZO

^+

J

Q

FZ

_O

wO

W

i9

H

z

¢

z

z ., z ^.

zz

Q

ao

^-"

0

0.

Q

O

" r-1

w

F_—

^-' W

Kw CK

w

ZO

rl Q r-i zwXQ

ZO—Qw

C9Z

N

>- N)

F-N

>-

W

CL O

ON

aO

v)N

O CL

^' Q

_N

►

-J

CL o

V

¢

V)J

WF—

uOWFO

o:

M W

`.

v<

w

~

J

CL

¢

t/1Y

con

z CL

CL LL

cif

r-

i

3^

z

0-4

N>

Cn

97-1)

p_

LL

i~, z

^1

Q F¢-

A?

c

WNy2U

2Ou

w 0n

a o r u

vi z y ':` o `0 c o

Cl z ?

` w a

O :v

O

2 N Jv < O < t W z W r _s ue• 

_ 1 W K

J < a l^ W ..

4L

Q

w

owe

3-3

r
of P,.- cl kl is„' AL141y

cL

z

rn

N

UQ

^A

U-

^N

N 

^

z

O

1

W

«-+

Q

A W 

'Q

W

O

p..1

d'Ua

C>: O

UO

^^

A

zW

C%4

a

O

^O

OC^

W

MOfVcOL

HzW

^N

N CL

W

CV 111

U

O

Q i U

LL v

W

V) C>: f O U ^

3-4 

sJ ! u

> O W Z U v)0-cctwlo<

W R.^ O I- O O H HI 

l

OG 

C 

CO,' OC0

 N

U) o t o o^`-

Z I- W aa. a a i `'' d arc c^ a iISA x 0. 1-

ppW.O w, (]

ZC G O O t 0 0 F ^+ 

x 

1^

I N N OG JJ JJ ^t 1^ Q

L N N 

ppW,,, > i .pp

.,11 O O

V A= = 0 6^ d N rn ^ ! I I I 1 1 1 1 1

o°c v^ t^ ce u oc ac ^ 

Q u =zo

b.' dvi

W

N

N

m

Cn Q

4

^

W

C>: t

Q ^

W JQzOQ

t^

W

OO 

^VCLQ 

z A

...1 

F

W

M

0N

2

O

U

(n

O

C>: WX

{

M^

^Y
a

4.

i'

i

E:

P°

to provide increased operational space when required. Figure 3-3 shows the

revised floor plan for the building 14 ground floor. An area is included

for user space where EGSE will be configured for operational support. This

user space may be configured into separate user rooms or areas as requ-.red

to meet mission-unique requirements. An adjacent MSR area is included to

provide office and conference space for the experimenters, Table 3-2

provides details of the floor space provided by this layout.

The APOC switch which is controlled from the DOCS was designed specifically

to meet APOC requirements. This switch provides capability to switch

specific incoming Spacelab data streams and also parameter select of

specific subsets from up to seven data streams according to mission

requirements. The maximum data stream rate which can be handled is 10

Mbps. Data streams of higher rate must be connected via patch panel

capability.

The data flows within various parts of the APOC functional design are

described in more detail in the following sub-sections.

3.1 SIPS.

The data flows to the HDTs, DQM and HRDMs are described in this subsection.

a) HDT

w

The SIPS provides recording of incoming channel 2 and 3 data on HDTs.

The characteristics of the HDTs are presented in Table 3-3. The data

streams are input to the HDTs via an HDT input switch. This system is

essentially a patch panel. To ensure that the data are properly captured a

3-5
b- LU

96 U

V)

zP.—

N 6J

32 

1.17

L" Cd

rl

0

0

0

0

Z

0

Cry

00

3-6

ORIGINAL PAP,,4 t,,7

OF POOR QUALITY

rr

is
F— O O O CD

C=)

W

LO M Mkt

a0

n^

3-7

Q I Lo CT)

d r N

C^

N f N

Ai

W

o'

u

U

N c0

M ^

^ N

r-I

n o

ro F k+

sd

a

CD

tD

N

C=)

A

W Q

Z

LLl

a `r

w w

^ ^ o

4

C
W

Table 3-3

HDT Characteristics

Parameter

Tape length - total

- usable (minus leading/

trailing)

Value

9200 feet

8543 feet

Density

Gross Capacity

Useful Capacity (minus bits for

synchronization and cyclic redundancy

check)

Capacity [80 percent]

Recording time supported

At 32 Mbps

At 48 Mbps

29 kbpi [kilobits per inch]

with 22 tracks fan-out

65,405 Mbits

59,459 Mbits or

7,400 Mbytes

5920 Mbytes

31 minutes [full]

25 minutes [80 percent]

21 minutes [full]

16 minutes [80 percent]

Time to rewind 6 minutes

i

3-8
^.

i

n

r<

Frame Synchronizer Unit ( FSU) is used with each HDT to monitor the

quality of the data recorded.

The configuration utilized for both the SIPS A&B and SIPS C&D systems

is a function of the operational requirements and input data rates of

channel 2 and 3 utilized. With reference to Table 3-3, it can be seen

that an HDT will support approximately 16-30 minutes depending on mode.

In general,, an HDT is started 3 minutes before the scheduled start of a

transmission.

Various operational configurations have been developed for the HDT

system. In general, proper operation is validated via monitoring of

the FSU outputs by the appropriate Systems Engineering Laboratories

(SEL) 32/ 7780 computer. For instance, if it was initially planned to

record on HDT 1 on SIPS C&D, with changeover on to HDT 2 after 20

minutes for continuation purposes, then the HDT input switch would be

patched accordingly. Following completion of this manual patch, the

sequence would be performed in realtime under the control of the SEL.

Providing all FSU outputs were normal the sequence would be completed

properly. If the FSU for HDT 1 initially indicated an error, the

system would transfer over to HDT 2 early, thereby ensuring data

recording. In general, whenever the HDT availability changes, a message

is provided by the SEL to an operator to take appropriate action. This

could include patching an alternate HDT or changing the planned

sequence. A feature is available to enable the FSUs to be monitored

manually during periods, when the SEL is not available.

The SIPS system provides a number of FSUs for monitoring the HDTs and

HRDMs. For SIPS A & B 23 FSUs are available within each Frame

3-9

C

^u
Synchronizer Subsystem (FSS) [FSS A & B]. Eighteen of these are

experiment FSUs and five monitor FSUs. Any monitor FSU may be selected

by the operator to monitor the data quality recorded on any HDT via an

HRDM and FSU input switch.

b) DQM

The SIPS monitors and reports the quality of all data received as a

standard SLDPF function. Data streams reported on for data quality

include the composite input data stream, the demultiplexed individual

data streams following procesing by an HRDM, and the Direct Access

Channel (DAC). A number of devices are involved in the gathering of

DQM statistics for the SIPS including the SEL, HRDM and FSU input

switch, FSS, HRDM and the disk subsystem. The HDT input switch and

' HDTs are also required when processing data for DQM reporting posttransmission.

4w

The composite data quality is monitored by the FSUs. The demultiplexed A,

data streams output from the HRDM are monitored by eighteen experiment

FSUs. The DAC data stream is monitored by a monitor FSU in realtime

and directly by a monitor FSU during playback. The FSUs can be

operated in a data mode or a monitor-only mode during DQM. During the

s. data mode, the FSU transfers a block of data via a Fast Data Interface

A-1 (FDI) to a designated "buffer area and also transfers a status report.

concerning data quality when the buffer is full. The output of the 

buffer are transferred to an output tape by the SEL computer. The 

input data are triple-buffered to allow output tape error recovery. In 

} the monitor-only mode, the FSU transfers a status report to the SEL

Fi

p`.

3-10

It
0

computer upon request. The history of all DQM statistics collected by

the FSUs is stored for DQM report generation by the SET.

Data quality information is sampled from each FSU once every 60 seconds

and at Acquisition of Signal. (AOS) and Toss of Signal (LOS) of a

transmission. The DQM information is used to determine proper SLDPF

operation and to support DQM reporting to the JSC. These latter

reports are provided on JSC request. Information collected with each

data quality sample includes:

i) sample time

ii) device functional assignment

iii) device status

iv) count of frames

V) loss of lock count

vii) missing sync count

vii) count of frames with sync bit error 

viii) count of frames with sync bit error and bit slip

ix) count of frames with bit slip

X) count of frames with suspected time tag.

r

c) HRDM

Each SIPS system [A & B and C & D] has an HRDM and FSS input switch,

' which can route the channel 2 and 3 composite streams or the playback

from the HDTs to both the HFWDM and the FSS. Both systems have two each

+{, of these latter units to provide redundancy. Each FSS has eighteen

k^

FSUs which are used for receiving demultiplexed data from HRDMs. SIPS

.` A & B has five remaining FSUs (monitoring FSUs) connected directly to

3-11
4

the output of the 11RDM and FSU input switch, These are used for

monitoring the data quality recorded by the HUTS, SIPS C & D has only

2 HDTs and therefore only requires 2 monitor FSUs on each FSS, however

five may be included for consistency with the current SIPS A & B

system.

The HRDMs demultiplex the composite input stream into the data streams

shown in Table 2-1. HDRR and PR data are recorded on HDTs fox subsequent playback as required. The double demultiplexing of the data is

removed on the second transit through the HRDMs. Minor frame synchronization of individual data streams, formatting, data-quality flagging,

and time tagging of minor frames as well as frame and data-flag counting is performed, by experiment FSUs. Each of the sixteen experiment

channel FSUs within each FSS is uniquely interoonnected with one of 16

FD2 units contained within its corresponding experiment channel. Fast

Multiplexer System (FMS). Each of the other seven FSUs of each FSS

(SIPS A & B) is uniquely connected with one of seven FDIs contained

within a corresponding master FMS. 

The experiment channel FMSs and the master FMSs are connected to the

SEL 32/7780 computer in such a way that either master FMS for SIPS A &

B can be accessed by SEL A or B, but each experiment channel FMS can

only be accessed by the corresponding SEL computer. A similar arrange- 

ment is proposed for SIPS C & D.

d) SEL 32/7780 Computers

Each SEL computer system is a dual processor processing unit consisting

of a Central Processing Unit (CPU) and an Internal Processing Unit

3-12

b t! A

F#
C

(IPU). Two private disks are provided for each system, and two shared

disks are provided that are accessible by each computer system and are

used to store SIPS software, mission-related files, and a data base.

The contents of these latter two disks are identical and data are

written to both disks simultaneously. This applies to both SIPS A & B

and C & A and therefore a single point failure is avoided.

3.2 APOC Switch

The APOC switch has been designed to distribute HRDM output data to an AP

within the MSOCC, EGSE within the user area, and /or remote users from the

GSFC. These data include the sixteen experiment channels, the ECIO and

SCIO. The switch can handle data streams with data rates less than 10

Mbps. Higher rate streams must be connected via a patch panel type

capability, The APOC switch provides the capability to select a subset of

data from a given stream with the use of a FS/PS. Following extraction of

the subset the resultant data can be distributed as before to an AP, EGSE

and/or remote. Seven FS/PS units are planned for the APOC functional

design, although the APOC switch design approach is modular and therefore

additional units could be added as needed.

The APOC switch was designed to meet or exceed the Spacelab POCC functional

requirements as initially provided to JSC for the JSC POCC and subsequently

as modified by the MSFC. 'These requirements specified the need for a

capability to extract from up to four streams a total of 2000 parameters a

second for processing. A maximum of 9200 parameters a second could be

extracted and provided to the NRT on-line, data base for on-demand access.

The maximum data .stream input rate for subset extraction was 2 Mbps,

3-13

a

£T

C

C

C.

ell
a,

4'

although this value was reduced by the MSFC to a maximum of 2 Mbps for

three streams.

The subsets to be extracted from a given stream would normally be

determined pre-mission and stored in a data base. During the mission the

required format would be seleetfl and used to configure the FS/PS

accordingly. Other configuration information stored in the data base premission includes the data stream switch connections and frame sync

parameters. The APOC switch is contolled by two microcomputer based

controllers, which report to the DOCS. The configuration data base resides

on these controllers. A design requirement is that the switch can respond

to a configuration and/or format change command is less than five seconds.

The ROCS controls the APOC switch configuration according to the

requirements specified pre-mission or as modified during operational support. New configuration identifiers are transferred to the controller,

which retrieve the required parameters from the configuration data base.

The switch configuration and data quality status are reported back to the

DOCS.

3.3 MSOCC Switch

STS ancillary and non-Spacelab data are input via the MSOCC switch. These

data include Orbiter ancillary date, PDI and PPF extracted from the Operational Downlink (OD) on Channel 1; Orbiter ephemeris including trajectory,

tracking data and Orbiter-attitude information; and JSC status, Command

Acceptance Patterns (CAP) generated in response to GSFC transmitted payload

commands and command history information. These data are normally provided

to the SPIF, but may be provided to other MSOCC systems as required. The

3-14

I

L

5
Q

GSFC generated payload commards are transmitted to the MCC via the MSOCC

switch. Other information available to the APOC via the SPIF interface

include crew activity plans from the Crew Activity Planning System (CAPS),

Orbiter voice and video and communications with the MCC via data facsimile

and teletype. The SPIF also provides a Text and Graphics (TAGS) system for

uplink facsimile type capability to the Orbiter crew.

Orbiter tracking data are received by the SPIF every three minutes under

timeline control or by request. These data are provided to the FDF and

processed to provide Closed Circuit Television (CCTV) displays for users

within the MSOCC or user EGSE area. Two-hour projections are available

containing all planned Orbiter maneuvers. Orbiter attitude data is

received every twelve seconds under timeline control or by request. These

data are provided to the FDF and formatted for user CCTV display.

Projections covering the next Forty-eight hours are provided. 

Auditing of MSOCC generated payload commands transmitted via the MSOCC 

switch is provided by the SPIF. This audit ensures the APOC-to-payload 

command interface validity via receipt, identification and validation of

MSOCC rommand blocks and decode and verification of responding MCC OAPs. A

log of command validation and CAP processing results is maintained in the

SPIF command data base. Command performance reports may be prepared from

w this d;ta base and formatted for hardcopy and CCTV display for users. JSC

t

realtime and off-line command history data are also received by the SPIF 

and formatted for hardcopy and CCTV display.

Payload telemetry data received by the SPIF via the MSOCC switch is

validated for proper NASA Communications (NASCOM) header,, user header and

block error control fields to ensure proper block sequence and non-presence

y33

YR

3-15

C,
It

3-16

of missing blocks and transmission errors, PDI and PPF data extracted from

the OD may be processed, converted to engineering data and diplayed. In

addition, STS ancillary data extracted from the OD and transferred to the

SPIF may be processed to provide user CCTV displays. The received JSC

status blocks containing Operational Instrumentation (0I) and PDI data

quality and routing information may also be processed by the SPIF to

provide user CCTV displays.

Several testing and simulations functions validating the MSOCC switch

interface to the MCC are also provided by the SPIF. These include

coordination scheduling and support of MSOCC/MCC interface testing,

monitoring of the MSOCC/MCC interface during pre-YA ssion testing and flight

operations and simulation of the MCC communications interface for APOC

checkout. Data flow fault analyses may be conducted to report monitored

information. These are conducted following error recognition.

The TAC subsystems support prepk,ocessing both of telemetry and command data

going to and from selected APs and the NASCOM lines via the MSOCC switch.

These subsystems provide a flexible routing capability for incoming data.

In addition to bounding the frame sync, the TAC may perform polynomial

error checking and has a complete set of routing parameters that allow

definition of the type'of data to be passed to an AP. Tolerance on bit

errors in the sync patterns can be set to allows restrictive or general

passing of data of questionable quality. The TAC system also performs

output format and labelling of MSOCC-transmitted commands and acknowledgements. NASCOM line monitoring and recording functions for all data entering and for scheduled data leaving the MSOCC may be provided by the RUPS

subsystems. These subsystems produce an inventory record of all data

blocks and a history tape of all data received in the MSOCC.
G

v

b

+i

fu

3.4 AP

Selected data may be provided to the APs for various types of processing.

These include ECIO, SCIO and /or experiment channel data or subsets

extracted by the APOC switch and transferred via the AP data mux, STS

ancillary data, and PDI and PPF data. In addition, the APs ,p rovide various

command processing functions. The processing conducted includes telemetry 

processing, command generacion, display page generation, history tape

generation, command verification and telemetry limit checking.

The APs provide extensive standard command and telemetry functions, which

may be readily augmented with mission-unique software as required. This

capability has been proven in the support of many free -flyer programs

within the MSOCC multi-mission environment. The various standard functions

may be simply tailored to meet defined mission requirements via input of

appropriate data bases information. This concept is used extensively within 

the MSOCC. 

An NRT data archival capability consisting of a 1.2 GB disk system has been

added to support the APOC. This system was sized to provide on-line

storage and access for the 500 STS parameters and 9200 payload parameters

received over a twenty-four hour period. The system provides on-demand

access on a shared basis for recall and processing of telemetry and history

data. Processing is provided via access to the standard APOC realtime

processing capabilities. Output utilizes the APOC terminals and associated

peripherals.

r

u,

G
M

4>

3.5 Operational and Support Rooms

As described in Section 3.0, the various MSOCC f...cilities have been

redesigned and upgraded in the APOC functional design. Two PCRs, two PSRs,

an MSR and a user EGSE area are provided. These areas are equipped with

upgraded consoles and terminal capabilities including 40 PC systems with

associated peripherals. The VIP network interfaces these capabilities with

the overall APOC system. The VIP network allows a device-independent

interface from the APs, DOCS and APOC switch to the various displays,

printers, graphics terminals, SCRs and other special peripherals.

3.6 Access

r

The access to the various data types within the APOC are summarized below.

a) Realtime

Realtime channel 2 and 3 data from Spacelab are input through the SIPS

C & D system via the APOC switch to appropriate APs and/or user EGSE.

4 These data include the ECIO, SCIO, experiment channel data and/or

subsets and GMT. Non-Spacelab data, STS ancillary and various JSC

planning, operational and history data are received via the MSOCC and

u SPIF. Payload commands generated within the CMS or MSOCC are

transmitted to the MCC via the MSOCC switch.

b) NRT

Data may be accessed in non-realtime via the NRT system. This system 

stores the 500 S"S parameters and 9200 payload parameters for

3-18

w

r
t

t

Q

subsequent recall and processing. In addition, the Spacelab channel. 2

and 3 composite streams may be accessed from the SIPS HDTs,

demultiplexed within the redundant HRDM and processed via the standard

APOC realtime capabilities and/or ;GSE on a shared basis. Other

history data may be accessed from the SPIP and MSOCC data bases.

c) HDRR and PR

HDRR and PR data within the incoming Spacelab composite stream have

been multiplexed on-board twice by tho HRM. On processing by the HRDMs

in realtime or on playback from an HDT the data are demultiplexed once.

The singly multiplexed data streams from the HRDM output are recorded

on the HDTs. On subsequent playback from the N?)T through the HRDM the

demultiplexed HDRR and PR data are obtained. These data may be

processed through the standard APOC processing capability on a shared

basis.

d) Commands

Commands originating from an APOC terminal, the CMS, EGSE or remote are

input to an AP for processing prior to transfer to the JSC MCC via the

MSOCC switch.

U

G

(.

3-19
r,>^a

4.0 TIMELINE CONTROL

The current SLDPF is configured for mission support based on a timeline

generated by the center assigned mission management responsibility. This

timeline is supplied in the form of a Computer Compatible Tape (CCT) for

input to the SLDPF system. The MSOCC and SPIF are controlled by the DOCS.

In developing the APOC concept these control modes were retained. In the

case of GSFC assigned missions the SLDPF timeline information would be

generated by the mission planning system. The DOCS would also configure

the remainder of the APOC based on timeline data obtained from the mission

planning system. The APOC switch was placed under the control of the DOCS.

4.1 SIPS

Three types of timelines are used to satisfy the SIPS requirements:

o Premission timeline

o Operational timeline

o As-flown timeline.

The premission timeline defines all experiments to be processed by the SIPS

during each mission and is developed and delivered to the SLDPF prior to

launch. The operational timeline consists of updates to the premission

timeline. It is provided at periodic intervals of approximately twelve

hours, prior to specific upcoming 12-hour mission segments. Currently

these updates are provided by the JSC Payload Data Manager. The as-flown

timeline consists of annotated versions of the operational timeline. It is

the final record of actual experiment activity, including exceptions to

preplanned data contained in either the operational or premission

4-1

rte=
a

i

ip y

timelines. The as-flown timelines are currently provided by the JSC Payload Data Manager at periodic intervals of twelve hours and record the

actual activity during the immediately preceding 12-hour period.

a) Premission Timeline

There are two types of Premission Timeline Tape (PTT); a downlink configuration PTT and an Experiment/TDRS PTT. The downlink configuration PTT

contains the date of tape creation, a single header record, and one or more

HRM format and downlink schedule records. The HRM format and downlink

schedule record defines a unique HRM format and the associated start and

stop times. One of these records exists for every unique period during the

mission during which the Ku-band channel configuration does not change and

within this configuration, the HRM format does not change.

The experiment/ TDRS PTT contains the date of tape creation, a single

header record and one or morn, of each of experiment on-off records and

TDRS records. The experiment on-off record appears once for every

start-stop operation of an experiment ( format change or rate change)

and defines the start and stop times and associated experiment/format

identifiers. The TDRS record appears once for every TDRS contact/support period and defines the start and stop times and associated TDRS

characCeristics.

b) Operational Timeline

Updates to the premission timeline are provided by the JSC Payload Data

Manager via facsimile and voice link.

4

^. e

4-2
c) As-flown Timeline

The as-flown timeline consisting of annotated versions of the operational timeline are transmitted by facsimile by the JSC Payload Data

Manager. In general, only pages reflecting actual changes or

optionally a small number of changes within a single datafax

transmission are provided

d) Operational Usage

The premission timeline is processed by the SIPS to define the patch

a 

pane. configurations needed to support the mission. Providing these

patch panel configurations are manually performed in proper sequence,

the SIPS can support the mission under the control of the S1EL according

to the timeline. In instances where a patch panel connection is

t incorrect or there is an equipment malfunction or loss of recording

various operator managers are provided by the system. For instance, in

cases of improper HDT recording, the continuation tape could be put in

E

operation early as described previously. In general, operator tatera^

tion ig required to repatch various switches, configure redundant

systems or change various configuration data within the SEL depending

on the problem in question. 

C

When changes to the premission timeline are received in the form of

operational timeline updates an update timeline data base is generated

t-

 by merging the appropriate data. In all cases, this updated timeline

data base which consists of the downlink configuration PTT and

experiment/TDRS PTT information is validated prior to use.

4-3

V,
The various formats capable of being demultiplexed by the HRDMs are

defined pre-mission. Sixteen formats are resident and 64 are available

within an HRDM. The appropriate format is selected by the SEL during

the mission via its corresponding identifiers.

The SIPS has an automated test mode for problem resolution. This mode,

the SIPS Automated Test System (SIPSATS) supports many SIPS functions,

but does not provide the standard data qulaity accounting.

t,

4.2 DOCS

Various hardware and software upgrades to the DOCS are planned as part of

current MSOCC developments. These upgrades are designed to implement an

automated DOCS capable of configuring and monitoring the MSOCC resources.

These upgrades will be available to support APOC. The upgrades include

automatic allocation of MSOCC resources, monitoring of MSOCC host computers

attached to the LAN, internal (and in some cases external) configuration

control of the LAN host computers, monitoring and control of the automated

MSOCC switches, providing the System Test Operations Language (STOL) for

operator control, AP downline loading capability, inclusion of Mission

Planning Terminal (MPT) schedule interfaces, DOC display enhancements, STOL

procedural capability, history event recording, AP history recording and

playback capabilities, error detection and fault isolation capabilities

within MSOCC and increased operational manageability.

4-4
R

5.0 OPERATIONS PERSONNEL,

The APOC operations management structure was configured to support all APOC 

operational requirements, provide required interfaces to the standard JSC

operations structure and provide the necessary environment for the

investigators for payload operations. The APOC operations management

structure is shown in figure 5-1. Several features of this management

structure are significant including.

o The presence of a GSFC Payload Operations Coordinator at the JSC to

enhance payload operations coordination. The Payload Operations

Coordinator interfaces with the JSC Payload Officer and reports to

the GSFC Payload Operations Director. The Payload Operations

Coordinator is familiar with GSFC payload operations requirements 

and practices and provides face-to-face contact with JSC payload

operations personnel as required thus minimizing any problems 

associated with remote POCC operations.

o A Crew Interface Coordinator at the APOC providing coordination of

all crew/APOC communications and interfacing with the JSC CAPCOM,

o A Data Management Coordinator coordinating with the JSC INCO and

the Payload Data Manager and ensuring that the various APOC systems

are configured for proper operational support of incoming data

streams.

e

5-1

e.

i
h

{

4!"

P

fi

F,

ORIGINAL Ct7

QP POOR QUALITY

I

^^ I

^W

r ^ I

I ^ __ II

I I ^I

I I

I I

g W I i IoJJ U'

-^ I a`.^ i I I aA^

I I ^^_ II I

^_ I

 ^_ II I ~

I °^°

I ( II I

Y

0p., II G^ GJ U

z

z II

r-^

I

N VI

Z W I N

O 9 O J I z

J O W LL.

t7 O i O 2 r'.

N! N OG ! I Z J 1'^

N_ Z N_ pW., 

Z

a il.

Wy Z Y N

06.1 I =445

C7

V)

I g^W _= Zz

W Z J ZZ Z

I

< 6 W

z O O

N

N W

N_ ^UU

S N

0

4

tj

M

1J

N

Cl

N

ro

aa0

C.1

O

Q)

OA

W

I&

5-2
a

o A Payload Activity Planner coordinating all premission payload

planning and operational payload plan updates. This individual

interfaces with the JSC FIDO and Flight Activity Officer (FAO)

01

o The Mission Scientist interfacing directly with the GSFG Mission

Operations Manager (MOM). The mission scientist has responsibility

for providing coordination of Principal Investigator (PI)

requirements. 

o PIs and their staff responsible directly for the formulation of

,

payload planning inputs and payload operations. Operational

support would be provided out of the user EGSE area.

t?

i.P

5-3