Skip to main content

Full text of "Implementing the space shuttle data processing system with the space generic open avionics architecture"

See other formats


NASA 

National Aeronautics and 
Space Administration 



NASA CR-1 88254 



Lyndon B. Johnson Space Center 

Houston, Texas 77058 



IMPLEMENTING THE SPACE SHUTTLE DATA 

PROCESSING SYSTEM WITH THE SPACE 

GENERIC OPEN AVIONICS ARCHITECTURE 



in 

«M 
I 

>*■ 
O 
2 



O 

c 

3 



O 
<-* 

o 

O 



December 1993 



•o 



rr, 
O 



John R. Stovall 
Richard B. Wray 



Prepared by: 



Lockheed Engineering & Sciences Company 
Houston, Texas 



Job Order 60-91 1 
Contract NAS 9-17900 



Lb 

X 



2" 

LU 
Cl 

o 



z 



^ l-t 

»— >-i CC 

2 i/l Ui 

LU 1/1 Z 

X UUUJ 

LU O O 

-I o 

Q. QC UJ 

s: a u 

•-. < 

< a. 

*"» < 

•4" Q LU 

m X 

«M LU t— 

iO ►- X 



T3 »* 

a> 

jC --» 

j* • 

O O 

o u 

I*- Ifl 

o 
o 

LU C 

CC <V 

Z3 — 

t- u 

LU 

»- -a 

•- c 

X TJ 
l_) 

< c 



a: x 

i j in 
t 









UJ LU 



>— ' l/> CO 



t- O — 



> c 

< LU 



for 

FLIGHT DATA SYSTEMS DIVISION 
JOHNSON SPACE CENTER 



LESC-30753 



IMPLEMENTING THE SPACE SHUTTLE DATA 

PROCESSING SYSTEM WITH THE SPACE 

GENERIC OPEN AVIONICS ARCHITECTURE 



December 1993 



Richard B. Wray, Advanced Systems Engineering Specialist 
John R. Stovall, Advanced Systems Engineering Specialist 




APPROVED BY: 



C-J A-Jr- 



G.L Ciouette, Project IntegraporTSpecialist D.M. Pruett, Manager, Advanced Programs 
Flight Data Systems Department Flight Data Systems Division 



Prepared by: 



Lockheed Engineering & Sciences Company 
Houston, Texas 



Job Order 60-91 1 
Contract NAS 9-17900 

for 

FLIGHT DATA SYSTEMS DIVISION 
JOHNSON SPACE CENTER 



LESC-30753 



PREFACE 

This document has been produced by Mr. John R. Stovall and Mr. Richard B. Wray of 
Lockheed Engineering and Sciences Company (LESC), the codevelopers of the avionics 
architectures and standards being tailored in this document. The contributions of Mr. Ben 
Doeckel of LESC who participated in early development of the concepts for the avionics 
architectures, standard and tailorings represented in this document is acknowledged. 
Special acknowledgment is also given to Mr. Dave Pruett of the Johnson Space Center (JSC) 
for his support of the Advanced Architecture Analysis, assistance in the development of the 
avionics architecture and constructive criticisms of the proposed standard. 



"f-v.?.. ..>L .<. ■■■■-.. 



Ill 



DOCUMENT CHANGE RECORD 



The following table summarizes the change activity associated with this document. 



ISSUE 

AND 

DATE 


PAGE 
NO. 


CHANGE SUMMARY 


SECTION 











IV 



CONTENTS 
Section Page 

1. INTRODUCTION 1-1 

2 SPACE SHUTTLE DPS SUMMARY 2.1-1 

21 REQUIREMENTS 2.1-1 

2.1.1 MISSION DERIVED 2.1-1 

Z1.2 VEHICLE DERIVED 2.1-3 

22 DATA PROCESSING SYSTEM DESCRIPTION 22-1 

22.1 DATA BUSES 2.2-1 

222 GPC OPERATIONS 22-1 

22.3 MASS MEMORY UNIT 22-4 

2.2.4 MULTIPLEXER/DEMULTIPLEXER UNIT 22-6 

22.5 DISPLAY ELECTRONIC UNIT 22-6 

22.6 TIME MANAGEMENT 22-6 

23 SHUTTLE SOFTWARE ARCHITECTURE 23-1 

23.1 APPLICATION PROCESSING SOFTWARE 23-1 

23.2 SYSTEM SERVICES SOFTWARE 23-1 

3. APPLICATION OF THE SGOAA TO THE SPACE SHUTTLE DPS 3.1-1 

3.1 HARDWARE ARCHITECTURE 3.1-1 

3.2 INTERNAL HARDWARE ARCHITECTURE 3.2.1 

3.3 SOFTWARE ARCHITECTURE 33-1 

3.3.1 SGOAA DATA SYSTEM SERVICES REQUIREMENTS 33-1 

3.3.2 SPACE SHUTTLE ONBOARD FUNCTIONAL SOFTWARE 
ARCHITECTURE COMPARED TO THE SGOAA 33-2 

4. CONCLUSIONS 4-1 



TABLES 

Table Page 

3.2-1 Architectural Interface Classes 3.2-3 



FIGURES 
Figure Page 

2.1-1 Space Shuttle Data Processing System Architecture 2.1-2 

2.2-1 Space Shuttle General Purpose Computer (AP-101S) Data Bus Architecture 2.2-2 

2.2-2 Space Shuttle General Purpose Computer Internal Block Diagram 2.2-3 

2.2-3 Space Shuttle Mass Memory Unit Functional Block Diagram 2.2-5 

« 

2.2-4 Space Shuttle Multiplexer/Demultiplexer Block Diagram 2.2-7 

2.3-1 Space Shuttle Primary Avionics Software Functional Structure 2.3-2 

3.1-1 The Generic System Architecture Model Enables Flexible Use of Standards 3.1-2 

3.1-2 Generic Processing External Hardware Architecture Model and 

Interfaces Are Adaptable 3.1-3 

3.2-1 The Generic Processing Internal Hardware Architecture Can Be Tailored 3.2-2 

3.2-2 The Generic Avionics Architecture Can be Applied to the Space Shuttle 

Processing Elements 3.2-4 

3.2-3 The Generic Avionics Architecture Can be Applied to the Space Shuttle 

Processing Support Elements 3.2-5 

3.2-4 The Generic Avionics Architecture as Applied to Space Shuttle 

Other Processing Elements 3.2-7 

3.3-1 Space Shuttle Primary Avionics Software If Structured Based on 

the SGOAA Model 3.3-3 

3.3-2 Space Shuttle Data Processing System Functions Can Be Tailored 

from the SDSS 3.3-4 



VI 



ACRONYMS 



AGE 

BFS 
BITE 

C&W 

ecu 

CMOS 

CPU 

CRT 

DDU 

DEU 

DK 

DPS 

DU 

E 

EEPROM 

EIU 

EP 

EP(e) 

EP(s) 

PC 
FCOS 

GAP 

GAP(M) 

GAP(S) 

GMT 

GN&C 

GPC 

HAL-S 

ICC 

I/F 

VO 

IOP 

IP 

JSC 

LB 

LESC 

LPS 



Aerospace Ground Equipment 

Backup Flight System 
Built-in Test Equipment 

Caution & Warning 

Computer Communications Umbilical 

Complementary Metal-Oxide Semiconductor 

Central Processing Unit 

Cathode-Ray Tube 

Display Driver Unit 
Display Electronics Unit 
Display Keyboard 
Data Processing System 
Display Unit 

Effector 

Electronically Eraseable Programmable Read Only Memory 

Engine Interface Unit 

Embedded Processor 

EP Effector 

EP Sensor 

Flight Critical 

Right Computer Operating System 

General Avionics Processor 

GAP used primarily as a multiplexer/demultiplexer 

GAP used for standard general purpose use 

Greenwich Mean Time 

Guidance, Navigation and Control 

General Purpose Computer 

High-Order Software Language for Shuttle 

Intercomputer Communication Data Bus 

Interface 

Input/Output 

Input/Output Processor 

Instrumentation /PCM Master Unit Data Bus 

Johnson Space Center 

Launch/boost 

Lockheed Engineering & Sciences Company 

Launch Processing System 



Vll 



MC 

MCIU 

MDM 

MEC 

MET 

MIA 

MM 

MMU 

MTU 



Memory Configuration 

Manipulator Controller Interface Unit 

Multiplexer/demultiplexer 

Master Events Controller 

Mission Elapsed Time 

Multiplexer Interface Adapter 

Mass Memory Data Bus 

Mass Memory Unit 

Master Time Unit 



NASA 

OPS 
OS 

PCM 

PCMMU 

PL 

PASS 

PROM 

RAM 

RMS 

RTE 



National Aeronautics and Space Administration 

Operational Sequence 
Operating System 

Pulse Code Modulation 

PCM Master Unit 

Payload 

Primary Avionics Software System 

Programmable Read Only Memory 

Random Access Memory 
Remote Manipulator System 
Run Time Environment 



S 

SAE 

SAP 

SATWG 

SCU 

SGOAA 

T&C 



Sensor 

Society of Automotive Engineers 

Special Avionics Processor 

Strategic Avionics Technology Working Group 

Sequence Control Unit 

Space Generic Open Avionics Architecture 

Test and Checkout 



Vlll 



REFERENCES 



[BUS85] Buskirk, Glenn, "AP-101S Space Shuttle GPC Design Handbook", IBM 85-C67- 

005, November 1985. 

[DPS2102] "Data Processing System (Hardware and Systems Software) Training Manual, 
DPS HW/SW 2102, NASA, April 1986 

[HAN89] Hanaway, J. F. and Moorehead, R. W., "Space Shuttle Avionics System", 

NASA SP-504, 1989. 

[ST093] Wray, R. B. and Stovall, J. R., "Space Generic Open Avionics Architecture 

(SGOAA) Standard", Job Order 60-911, Contract NAS9-17900 for the JSC, 
NASA CR-188269, LESC-30354-B, December 1993. 

[MACUNK] Macina, A. J., "Space Shuttle System Overview (Part 1)" Presentation, IBM 

[WRA93] Wray, R. B. and Stovall, J. R., "Space Generic Open Avionics Architecture 
(SGOAA) Reference Model Technical Guide", Job Order 60-911, Contract 
NAS9-17900 for the JSC, NASA CR-188246, LESC-30347-A, April 1993. 



IX 



1. INTRODUCTION 

This paper presents an overview of the application of the Space Generic Open Avionics 
Architecture (SGOAA) to the Space Shuttle Data Processing System (DPS) architecture 
design. This application has been performed to validate the SGOAA, and its potential use 
in flight critical systems. The SGOAA has been proposed as an avionics architecture 
standard with the National Aeronautics and Space Administration (NASA), through its 
Strategic Avionics Technology Working Group (SATWG) and is being considered by the 
Society of Automotive Engineers (SAE) as an SAE Avionics Standard. This architecture 
was developed for the Flight Data Systems Division of the NASA JSC by the LESC, Houston, 
Texas. This architecture includes a generic system architecture for the entities in spacecraft 
avionics, a generic processing external and internal hardware architecture, a six class model 
of interfaces and functional subsystem architectures for data services and operations control 
capabilities. 

The SGOAA is documented in Reference [ST093] for the proposed standard and in 
Reference [WRA93] for the technical guide for the proposed standard. References [HAN89], 
[DPS2102], [MACUNK] and [BUS85] present a discussion of the Space Shuttle Avionics 
System. Section 2 provides an overview of the requirements, design and operation of the 
Space Shuttle avionics. Section 3 provides an overview of the tailoring of the SGOAA to 
the needs of the shuttle avionics. Section 4 provides some conclusions. 



1-1 



2. SPACE SHUTTLE DPS SUMMARY 

The architecture of the Space Shuttle avionics is shown in Figure 2.1-1. It consists of sensor 
and effector devices, general purpose hardware and software, and specialized hardware and 
software. The primary avionics software system (PASS) is the principal software used to 
operate the shuttle. This software contains all the applications and services code needed to 
fly the vehicle through all launch and orbit phases, and to manage the vehicle and payload 
while in orbit. 

The key requirements on the DPS and the PASS are identified below. To meet these 
requirements, the four common (of the five) general purpose computers (GPC) are loaded 
with the same PASS code to perform the guidance, navigation and control functions 
simultaneously, with results compared. The fifth GPC contains a different set of software 
developed by a different company to take over vehicle control if the PASS code should have 
a generic design error. The software in this fifth computer is the backup flight system (BFS). 
It is only needed in critical flight phases such as ascent and descent. During less dynamic 
phases, different parts of the PASS software can be loaded into the four GPCs (allocated to 
the PASS) to support orbit activities. The GPC architecture and the software architecture, 
are summarized below to clarify the goals of the SGOAA tailoring described in Section 3. 

2.1 REQUIREMENTS 

High level requirements for the Space Shuttle are summarized below. The requirements 
fall into two areas: those which are derived from the needs to perform the mission and 
those which are derived from the needs to safely control the vehicle. 

2.1.1 MISSION DERIVED 

• At least two safe methods of return to earth must be provided. 

• An abort after one failure is not acceptable, therefore: fail op/fail safe is imposed. 
This dictates three strings to detect a failure and a backup string to recover; thus at 
least four strings are required 

• Autonomous operation (onboard access for analysis of data) is required. 

• Use of operational data to detect and isolate failures is required. 

• Automatic failure detection and recovery for time critical functions is required. 



2.1-1 



- CD 


C <D 


=> "5. 


91*2 


.2 3 


C f= 


S^ 


CD s: 


UJ S 


>>iE 


(0 D. 


QlJS 


W 3 


OS 


II II 


=32 


LUQ 


OS 




=J 3 


„,!- 


£J >> 


<5 co 


• — 


•2 CD 


-"8 




l><3 


UJ || 


II l- 


3^ 


J5 ! w° 

<D 


o 



c 
o 
O . 

•8E 
c ® 

O 03 

"■5 >» 
SS.W 

fo. 

9 9 

I* 

if 

a 

§<; 

si 

.£ - <o 

■o|w 

3 Q.J; 
" II *= 

3d ii 

OQID 



TJ C 
O CO © 



a. 

c 

CO 

o< 

E 
« 
cc 





(0 
<D 
O 

> 

0) 
Q 



U 

£ 

UJ 

■o 

c 

<0 

o 

c 
© 

0) 



c E 







■o 

CD 


1- 




o 


cc 




JO 


o 




2 



— co 

§2 

S3 







CO 


** 


O 


E 


O) 


E 


& 


U. 


O 

u 


CO 

to 



dXZ 



2 
in 



3 
UJ 
Q 



o »- 

CO = 

f 2 
i ° 



ft o £ 

= £«*. 
2 g Eg 

-St 23 

s « CD CO 



"5 «= 

c c 

O CO 

«E 
2? 

Q.C0 

O = 



1 


V 




CO 


u. 


c 

CJ> 


o 


«n 


> 


** 




UJ 


c 


c 




o 


< 




o 




1 


CO 


CO 


*€ 


CO 


*2* 


Q. 


05 


.2 


CO 


5 



» 

(0 

o 

3 

o 

(A 

>• 
C 

s 

2 

E 

o 



s 

< 



CO 
UJ 
CO 

3 
CD 
-l 
O 
CC 

I- 
z 
o 
o 

o 

z 
< 

< 




)-. 

5 

< 
I 

to 

CD 

60 

C 
•^* 
<n 
w 
cu 



(0 

cu 



3 

cu 
u 
re 
(X 
CD 



CN 

ai 

5, 



2.1-2 



>. 

o 

k. 
O 

O 



2.1.2 VEHICLE DERIVED 

• Full-time flight control augmentation is required dictating fly by wire placing the 
digital flight control computation system in the safety critical path. 

• Engine actuator hardover commands are extremely critical requiring redundant 
summed inputs for voting to prevent erroneous commands. 

• Data buses and remote power control devices are required to save weight. 



2.1-3 



2.2 DATA PROCESSING SYSTEM DESCRIPTION 

The DPS consists of the following key hardware and software: 

• Multiplexed data transmission with standardized subsystem interfaces over the 24 
digital data buses 

• 5 GPCs with interfaces interconnected by digital data buses into a parallel-redundant 
digital computation system 

• Mass software program storage in two tape mass memory units 

• Distributed I/O through remotely located multiplexer/demultiplexer (MDM) units over 
the digital data buses 

• Communication with multifunctional displays and keyboards via the Display 
Electronics Unit (DEU) 

• Time management using two Master Time Units. 

• The PASS software. 

2.2.1 DATA BUSES 

The use of GPC data buses is critical to operation of the shuttle DPS, and to safe and 
successful operation of the vehicle. The data bus architecture for the shuttle is shown in 
Figure 2.2-1. The shuttle data bus network consists of 24 twisted shielded wire pairs (data 
busses) which support the transfer of digital commands from the GPCs to vehicle hardware 
and the transfer of vehicle systems data to the GPCs. Each GPC has 24 serial digital data bus 
interface ports with functions allocated by criticality and use with no Hamming-type error 
protection. There are seven groups of busses. They consist of 8 flight critical (FC), 2 payload 
(PL), 2 launch/boost (LB), 2 Mass Memory Unit (MMU), 4 display keyboard (DK), 5 
instrumentation/PCM master unit (IP), and 5 intercomputer communication (ICC) data 
buses. 

2.2.2 GPC OPERATIONS 

The GPC internal structure is depicted in Figure 2.2-2. As noted above, all 4 common GPCs 
operate in a redundant set. To prevent divergence while operating in this set, the 
synchronization method selected is to insert "sync points" at appropriate locations in the 
software. When a computer reaches one of these sync points it stops execution, notifies the 



2.2-1 



m 

U 
a. 

O 



3 
Ol 
O 



o 

0. 

o 



0. 

o 



CO 

O 
0. 
CJ 



3 

0. 

o 



CM 

o 

Q. 

o 



3 
0. 
O 



0. 
O 



CI 

en 

^ '■""''»" i ' it * 

:r i i i i i l l . 






ii i i ii 



1 



ii i i ii i i a 



J ||iiiH|i ||i i 
II (I II I 



f It "It 



1 



PZR 



Q.fcx 



I I I I M I 



II II H It I 




3E 



II 



run \\ 



C 



i ii ii i i n 



i n ii ii 



±c 






nni 



LuEjfDEJ 



I II I I II 



ir n i 



■iniMiKi^i 



!■ m i ^ i e:-5 1 s& i ssss ■ 



yJ 



Si 



5 



i i i ii 



1 



g C r |iyillll|lllll|| 



» » " " » 



; ijn i i ii 



XX 



o 



CM 




3 






«0 
0) 

8 

CD 

I 
o 

o 
cc 

"O 









_l 


a 


CO 


_l 


-i 




s 


s 




Q 

2 


Q 

S 





— 2. 
On 
0. «g 



CM 

Q- a 



1 1 1 1 1 1 r 


< 


3 


< 


LL 


S! 


2 


2 





o 


O 


o 


o 





S 


E 


s 


s 


s 




E 


a 


Q Q 


q a □ 


a 


s 


S 


E 


s 




s 


s 





N 


m 




,_ 


CM 


M 


3 








3 


3 


n 


JJ 


LXJ 


LU 




Q 


Q 


Q 



TTT 



I 




1 
















J. 


N 


m 






5 


3 


P> 


* 




rM 




J. 










LL 


UL 


LL 


LL 


O 
LU 


L) 
LU 
























□ 










Q 


□ 


Q 


Q 


2 
















S 














MM 




Mil 


1 


1 



c g-5.5 s 



3 J =o"!= 
c c « s c o i 




sJ-Sslfili! 



X • 

sz c 

3 O 

?!" 

S > 
2 ui 



S 






E*^ 2-2 



22 



2.2-2 



223 = £{2g;i lag 

uqqqojSs 55 5. 



3 O 
>«.2o> 

§«« 
£ u< 

(8 



2 



CO 

3 
CO 



</> 

r- > 

O 

»-« 

i 

< 



I- 
3 



o 
U 

0) 
CO 

o 
a. 



c 



3 

CT> 

0) 

u 
CD 



cN 
tN 



§ 



CM 

i 



o 




2 
&o 

.2 

O 

M 
u 

o 

s 

£ 

c 



0) 

3 

e 

o 
U 
cu 

CO 

O 



3 
P- 

CU 

C 
cu 

U 

cu 



3 

cu 
u 

(S 

en 

tN 

■ 

tN 
tN 

CU 

u 






2.2-3 



other computers by way of sync discretes that it has reached that point and waits for receipt 
of corresponding sync discretes from the rest of the redundant set before continuing 
processing. If all discretes are not received within the preset time the synced computers 
resume execution and declare any non-responsive computer to be failed. The synch 
method is a software or soft sync approach as opposed to a hardware sync approach which 
utilizes a common clock to lock the processors in sync. In addition, all Shuttle GPCs receive 
the same data to prevent divergence of computed results since computed results are also 
compared to detect a computer failure. 

For the flight critical input channels, a group of four buses, each of the four redundant GPCs 
controls one bus and listens on the other three buses. Control here means simply that only 
the controlling GPC transmits commands on the bus controlled. The transmitter for that 
bus is disabled in each of the other three GPCs so they can not transmit, but can only receive 
or listen on the bus. Each GPC will send a wakeup command over the bus it controls to each 
of the other GPCs before it transmits a request for sensor data. This wakeup command cues 
the listen only GPCs to receive and record the returned sensor data. Since the GPCs are 
synchronized, all computers request data from its sensor simultaneously with each of the 
other GPCs. Each GPC also controls one of four flight critical output buses. Critical outputs 
from each of the four GPCs are sent on the bus it controls to the effectors where the four 
inputs are voted providing only one output. Each GPC also controls one of the five ICC 
data buses. Once per cycle a summary word consisting of the sum of all critical outputs for 
that cycle is transmitted by each GPC to the other three GPCs in the redundant set. Each 
GPC compares its summary with the summary words of the other GPCs. If it does not agree 
with at least one other GPC it declares itself failed and removes itself from the set. There 
are also several other logical processes to determine a computer failure that have been 
implemented. A complete description of these processes can be found in [HAN89]. 

2.2.3 MASS MEMORY UNIT 

The mass memory unit (MMU) is shown in Figure 2.2-3. Two are installed in each orbiter. 
They are magnetic tape units with random access storage capacity of 4.2 million 32-bit words 
each. They provide nonvolatile storage for the following: 

• System software 

• Duplicate copies of application programs 

• Overlay program segments 

• Cathode-Ray Tube (CRT) display formats 



2.2-4 






1 


f 


CM 




>- 


<0 


£E 


o 


o 


■o c 


UJ 


Rea 
ctro 


3g: 


o 


(/} 


LU 


CO 





ttttt 

E co t-Q. 




l_ 


>» 


5 


Q. 
Q. 


o 


3 


Q. 


0) 




&2 o 

is ** 



O) 



(0 

CO -- 

2 o o S 





CO 


UJ 


3 


1- 


% 


m 


CO 



CO 



T3 "- C 
w <D m 

2cc2c 




o 

hi 
CO 

3 



_l 




£ 


UJ 






z 




(0 


< 

GL 




D 






u 

o 

s 

"(3 

c 
o 

u 

c 
c 
o 

s 
s 

CO 

CO 

«a 

s 

.C 
CD 

01 

u 






(Q 






D- 


^2 




cn 


£ffl 






tn— : 




CD 






i 


ct 




(N 


en « 




O) 


s Q. 




l-l 


£ « 




3 
60 


SI 


c 
o 


U, 


s § 




cOfi 




Ie 


c 




*§ 




00 




s> 


« 




jlAb 




a 






»- 







2.2-5 



• Prelaunch test routines 

• Fault isolation diagnostic test programs 

• I-loads (mission and hardware unique data) 

• Checkpoint data 

• Downlink data formats 

2.2.4 MULTIPLEXER/DEMULTIPLEXER UNIT 

The shuttle MDM is shown in Figure 2.2-4. It is a flexible multipurpose interfacing device. 
The MDM recognizes and responds to valid, correctly addressed data bus transmissions. Its 
sequence control unit (SCU) controls operation of the MDM in acquiring blocks of data. The 
16 Input/Output (I/O) slots can be populated with a mix of 9 different types of analog, 
discrete, digital and special-purpose I/O modules. 

2.2.5 DISPLAY ELECTRONIC UNIT 

The DEU is the hardware/software unit which drives the general purpose displays and 
accepts crew inputs from the alphanumeric keyboard. Each DEU has one digital data bus 
input and a special purpose processor with Random Access Memory (RAM). 

2.2.6 TIME MANAGEMENT 

The GPC uses a stable, accurate time source based on Greenwich mean time (GMT) for 
scheduling processing. Each of the five GPCs uses the Master Time Unit (MTU) to update 
its internal clock. There are three accumulators in each of the two MTUs on an orbiter. 
Each of the accumulators maintain both GMT and Mission Elapsed Time (MET), which can 
be updated by an external signal. Each accumulator is tied to a different flight critical 
forward MDM. Because of this arrangement, any one of the GPCs which is at least 
"listening" on strings 1,2, or 3 will receive MTU time and Built-in Test Equipment (BITE) 
status. Software compares internal GPC time with the MTU time sources and updates the 
internal clock as needed. Each GPC checks internal clock once per second against the MTU 
accumulator. If within tolerance (<= 1 millisecond), the internal clock is re-synchronized. 
If outside of tolerance, the GPC checks the other accumulators and GPC clocks until a 
within-tolerance time is found for updating. Procedures are available for resynchronizing 
out-of-tolerance clocks. 



2.2-6 



2 i 











w w 


CO 










0) 
































s 








♦ 






• 








* 








o 








s£- 














— o 










2 














o 








Q^^ 










— o 










s 








+* 




** 






®c^ 




Oc 






gDP S 




g=>«s 






©75DO 




S> o30 






S-JsOCC 




S-Socc 






ST cCOQ. 
CO o 




IT CCOQ. 
CO 






o 













. 


Multiplexer 
Interface Adapter 


(MIA 1) - 

Transmitter 

Receiver 




Multiplexer 
Interface Adapter 
_ (MIA 2) - 


Transmitter 
Receiver 






£ 


£eo 




CO w t© 


« 3 




E «3 


"O CD 

§5 






Q. 












a* 
5° 





sS 

S >00 

1 Em 

§*« 

sen ^ 



2 

to 

to 



u 

o 

s 

X 

<u 



3 

s 

D 

J- 
<D 
X 



3 

•2J 

^-» 
*j 

3 

A 
CD 

0) 

(J 
re 
£X 
en 

"«* 

1 
c4 

0) 

3) 



2.2-7 



2.3 SHUTTLE SOFTWARE ARCHITECTURE 

The architecture of the Space Shuttle software is shown in Figure 2.3-1. There are two sets 
of software resident is the GPCs: the system service software and the applications software. 
Key functions provided are summarized below. 

2.3.1 APPLICATION PROCESSING SOFTWARE 

This is the application software to be executed to perform the activities needed to fly and 
operate the shuttle. The major categories of application processes are Guidance, Navigation 
and Control (GN&C), System Management and Vehicle Checkout. Only one major function 
at a time can operate in each GPC; however, different functions can operate in different 
GPCs in non-critical flight phases. GNC will usually operate in more than one GPC. Major 
functions are subdivided into mission-phase oriented blocks called operational sequences 
(OPS). Each OPS is associated with a specific memory configuration (MC) which can be 
loaded into a GPC from the MMU. Thus, all the software in a GPC at one time consists of 
the systems software and the OPS software (i.e., a MC). Transitions from one MC to another 
is called an OPS transition when the crew requests a new set of applications software to be 
loaded. 

2.3.2 SYSTEM SERVICES SOFTWARE 

2.3.2.1 Flight Computer Operating System S oftware Description 

The Flight Computer Operating System (FCOS) performs the same type functions as the 
SGOAA "Operating System" and consists of a synchronous foreground executive with a 
structure that uses an asynchronous priority driven background. The asynchronous priority 
driven background accommodates growth and the synchronous executive is predictable. 

The FCOS kernel consists of the following three major functions. 

• Process management: controls allocation of all internal computer resources. 

• I/O Management: Controls allocation of I/O processing. This function performs all 
of the I/O functions including UIL, data bus management, and data base manager. It 
also includes the I/O error processing, special tests for other failure conditions and 
failure annunciation. I/O transactions are usually performed cyclically, except for 
those critical to vehicle safety, which are processed at a higher cyclical rate up to 25 
Hz. Asynchronous requests from software are also handled. 



2.3-1 



<0 



o 

CO 



EE 

i- 
(0 

o 
m 

c 
O 





** 


o 


3 




o 


o 


.2 


o 


8 


> 


£ 




o 




O) O) 

gg 8 .2>S 18 

?S I" 2 25 ji 

0)0. (OO. Q-O OO 



Z (0 

** CD *■* C 

E «c o-S a 

S) |o fg .sg. 

a> o .2 2 a. o 

- « QO. (OO 



OS Q.5 



O) 

c 
■o "5 

CO i- 

OC 0-0. 







^^ 


s 


c 
o 


2 


c 


*rf 


c 


CO 


.2>o 


3 

a 


> 

CO 

Z 


C 
CO 



c 
o 

« s 

©2 



O 
CO 

3 

c 
o 
o 



o 



Si £ 

CO c o 

e ■= O ». "O © c 

■§ .2» £ to 3 55 3 



8 .2 o 



O Z Li. C/)(£2 00 O 



a. 
(/} 

> 
a 

Q. 
0) 

5 



• • 



• • 



Eo 
«» 5 



c 
o 



I 

o> 




** CO 

E.S Elg Ea.2 

275 So.2 So? 

o~ w y o *° 2 c 

(/)£ COOC 3 (/)</) u. 



3 

a 
c 

C-S 

cog 



On 
°>? 

CO *- 
8 CO C 

.2- 2'lg 
■5 o ts co~ 



co 

c 



Eo a £ 3 o 

Eg oc S-go 

o 2 0.0 3 8 o 

oo. OO O0.O 



is 

«) « 
: a. 



0) 

2 

u 

2 

OO 

"3 

c 
o 

"G 

e 



8 

c 
o 

> 

< 






3 

U 
(0 

(X 



CD 



c 

CD 

c E 
to I g 
og s 



Q.5 



5c 
■5 ® 
2 E 

3 CD 
TOO) 
!C CO 






y 

c 

oEc 

£&£ 

Sco a. 



§ QO 



2.3-2 



• DPS Configuration Management: Controls loading of computer memories and 
sequencing and control of the GPC and IOP operating states. 

2.3.2.2 User Interface System Services Software Description 

This segment manages the sequencing of all processing and defines the associated CRT 
displays and keyboard options. These are the same type functions as the SGOAA I/O Data 
Services. 

One of the key User Interface services is the Command Input Processing. This is the same 
type function as SGOAA I/O Data Services Data Acquisition. Command Input Processing 
includes crew inputs and the launch data bus used to communicate while on the ground. 

Another important User Interface service is the output message processing and 
coordination software. This provides the same type functions as SGOAA I/O services data 
distribution. 

2.3.2.3 System Control System Services So ftware Description 

This segment performs initialization and configuration control of the data processing 
complex including the data bus network. These are the same type functions as SGOAA Data 
System Management. 



2.3-3 



3. APPLICATION OF THE SGOAA TO THE SPACE SHUTTLE DPS 

The SGOAA System Architecture is presented in Figure 3.1-1. This can be compared to the 
shuttle system architecture shown in Figure 1.1-1. A key difference in these architectures is 
the reliance (in the SGOAA) on the 6 classes of interfaces and use of standards in imple- 
mentation. The SGOAA approach establishes independence between hardware and 
software entities at different interface levels to facilitate future change. The shuttle uses 
older methodologies and architectural concepts, with applications and services designed as 
monolithic or integrated entities which resist changes. 

The SGOAA hardware and software architectures can be compared to and overlayed on the 
shuttle architectures to demonstrate the utility of the SGOAA in actual systems. Such 
comparisons and overlays are described below. 

3.1 HARDWARE ARCHITECTURE 

The SGOAA Generic Processing External Hardware Architecture is shown in Figure 3.1-2. 
This can be compared to the shuttle hardware architecture shown in Figure 2.2-1 . The 
hardware architecture diagrams are very similar. The following relationships of the 
various hardware units between the two systems can be established: 

SGOAA External Hardware Architecture Space Shuttle Data Bus Architecture 

• GAP(S) = GPC (CPU/IOP), DEU, MMU 

• LOCAL INTERCONNECT = MIA (DATA BUS) 

• GAP(M) = MDM, PCMMU MEC, EIU, DDU 

• SAP = MCIU 

The General Avionics Processor (GAP) is a modular general purpose computer architecture 
as illustrated in Figure 3.2-1 and can be configured to all of the Space Shuttle Avionics 
requirements at the system architecture level. A GAP has one of two forms: one for 
standard general purpose use [GAP(S)] and one dedicated to the handling of multiplexing 
and demultiplexing I/O signals [GAP(M)]. A GAP(S) always includes a general purpose 
application processor modular function. A GAP(M) may contain a special purpose 
Programmable Read Only Memory (PROM) programmed processor, but its primary 
function is always the receipt, conditioning and distribution of I/O data. The Special 
Avionics Processor (SAP) is a special purpose processor designed to perform unique, not 



3.1-1 






to 
73 




i« 




<o 




73 




C 




iS 




C/l 




V4- 




o 




0) 




CO 




P 




0) 








.n 








X 




<u 




E 




W 




<u 








.o 




CO 




c 




W 




^^ 




0) 




•g 




s 




ai 




i- 




2 


1- 
o 


tt 


LU 




z 


y 


z 
o 


< 


o 


£ 


oc 


0) 

4-1 


LU 

1- 


CO 

C/5 


z 


# y 


_J 




< 


c 


o 
o 


0) 


_l 


at 



3 



3 



> 



3 



o 



3.1-2 



s**\ 




O 

*H 

B 



ai 

«s ™ 

a, < 

►*" (J 

bOJS 

•53 iJ 
8 c 

O T3 

ft. c 



<C 



c 
U 

CM 



e 



at 
at 

c 
a 
-> 

CM 



> 

««> 

8 

5 



3 



3.1-3 



general purpose processing functions and also does not have as its primary function the 
multiplexing and demultiplexing of I/O signals. 

A description of the application of the SGOAA architecture to the internal Space Shuttle 
hardware architecture is contained in the Section 3.2 which discusses the internal hardware 
architecture. 

The SGOAA and the Space Shuttle architectures function in basically the same manner. 
GAP(S) type units communicate with each other, with SAP type units and with GAP(M) 
type units over multiple local interconnects. The SGOAA system interconnect is not 
required for the Space Shuttle. GAP(M) type units perform intelligent multiplexing and 
demultiplexing of signals similar to the shuttle MDMs. GAP(M) type units such as the PCM 
Master Unit (PCMMU) communicate over dedicated local interconnect buses, Multiplexer 
Interface Adapter (MIA) data buses, to lower level EP type units such as the MDM OA1. 

The Class 1 SGOAA hardware interfaces in Figure 3.1-2 also apply to the Space Shuttle data 
bus architecture shown in Figure 2.2-1. All hardware units communicate over a local 
interconnect bus. The SGOAA local interconnect path is required to be an accepted industry 
standard. The Space Shuttle multiplexer interface adapter (MIA) data bus is a modified 1553 
standard bus. The video monitor interface from the DEU to the Space Shuttle Display Unit 
(DU) is another point where an interface standard could be applied. Interface standards 
could also be applied to the dedicated buses/signal lines from the MDM type units to the 
lower level Embedded Processor Effector (EP(e)) and Embedded Processor Sensor (EP(s)) 
units and to sensors/ effectors. User definable nonstandard interfaces from a SAP type unit, 
such as the Manipulator Controller Interface Unit (MCIU) to the manipulator, are also 
provided in the SGOAA architecture. 



3.1-4 



3.2 INTERNAL HARDWARE ARCHITECTURE 

Figure 3.2-1 shows the SGOAA GAP internal architecture. As illustrated in this figure, the 
architecture is based upon an internal interconnect interface standard internal to the GAP 
and standard external interfaces from the modular GAP functions to external hardware 
entities. The interfaces are all SGOAA Class 1 hardware interfaces. The SGOAA interface 
classes are defined in Table 1. Figures 3.2-2 and 3.2-3 illustrates how seven of the Space 
Shuttle hardware units can be functionally built from the SGOAA GAP architecture. Figure 
3.2-4 addresses two additional Space Shuttle Hardware units. Functions internal to SGOAA 
modules are not required to be standardized. Inputs and outputs to and from SGOAA 
modules are required to be standardized. 

• GPC - This unit as shown in Figure 2.2-2 (AP-101S Block Diagram) contains three of 
the GAP(S) modular functions as shown in figure 3.2-2. They are the IOP equivalent 
to the GAP Local Interconnect Processing, the Central Processor Unit (CPU) 
equivalent to the GAP Application Processing and the Aerospace Ground 
Equipment (AGE) interfaces equivalent to the GAP Test and Checkout System 
Interface. When installed in the Shuttle, all test and checkout ground interfaces are 
by way of 2 dedicated data busses. 

• MMU - This unit as shown in figure 2.2-3 contains three of the GAP(S) modular 
functions as shown in figure 3.2-3. They are the MIA equivalent to GAP Local 
Interconnect Processing, Mass Memory Control Logic equivalent to GAP Application 
Processing and the Read/Write Electronics and Tape Transport Mechanism 
equivalent to the GAP Auxiliary Memory Storage. 

• DEU - This unit contains four of the modular GAP(S) functions as shown in figure 
3.2-3. They are the MIA equivalent to GAP Local Interconnect Processing, processing 
of display data and formats in a special-purpose processor equivalent to GAP 
Application Processing, conversion of digital data to video /graphics form for display 
on the CRT equivalent to GAP Video /Graphics Processing, and interface to the 
keyboard equivalent to GAP I/O Processing. 

• MDM, MEC, EIU, DDU - These four units all perform different tasks; however, each 
of these units contains only two of the modular GAP functions. These functions are 
MIA equivalent to GAP Local Interconnect Processing, and special processing of 
input and output data equivalent to GAP I/O Processing as shown in figures 3.2-2 
and 3.2-3. Since the primary purpose of each of these four units is the handling of 



3.2-1 




13 
S 

U 

c 

c3 

a 

5 

< 

u 

re 

•s 

re 

X 

"re 

E 

C 

M 

too 

c 

8 

o> 
u 
o 



e 
U 



CM 

CO 

J- 

3, 



> 






3.2-2 



Table 3.2-1. Architectural Interface Classes 



Cass 



Description 



Hardware-to-Hardware Direct: 

Class 1 hardware direct interfaces are the direct connections between different 
types of hardware such as needed to enable buses and communications links to 
address processors or needed to enable processors to address memory registers. 



Hardware-to-Operating System Exten sion Software Direct: 



Class 2 hardware to operating system extension software direct interfaces are the 
direct connections between hardware registers and operating system extension 
service software or other software performing that function, such as drivers 
needed to enable address registers to move data packets from hardware to system 
service software, and service drivers which can respond to the data packets. 



Operating System Servic es Software-tn-Snftware (Local) Direct: 
Class 3 operating system service software to other software direct interfaces are the 
direct connections between operating system service code and other local software 
code sets, which enable operating system software to receive and interpret data 
packets, and pass them on to other software code which will process them locally. 



Data System Services Software-to-Data System Services Software Logical: 

Class 4 system service software to other system service software logical interfaces 
are the indirect connections which enable local service software to determine the 
address of the intended software in other local or remote locations which need 
the register data being stored and to pass the data appropriately. Enables the 
handling of logical data transfers from source to user service 



Data System Services Software-to-A pplicarions Software Direct 

Class 5 system service software to applications software direct interfaces are the 
direct connections which enable software service code to access and process data 
from local application software code. 



A pplications Snftware-to-Applicati nns Software Logical: 
Class 6 applications software to applications software logical interfaces are the 
indirect connections which enable an application originating data to pass it to an 
application which needs to use the data, or enable an application needing data to 
determine the source from which the data must be obtained. These are logical 
data transfers from source to user. This interface provides the indirect 
connections that allow applications in different systems or in the same system to 
communicate, thus enabling applications software to interact across or within 
system boundaries to accomplish a mutual purpose. These interfaces may be 
applicable to applications executing in the same processor, in different processors 
in the same node or in different systems. 



3.2-3 




> 

T 
Q 

>> 
o 

Ol 
CO 



3 
Q 

Q 






ts 

C£ 

uj o 
ii <g 
3 • 

ii 
M 

oo 
uig." 

af = 
« ctr 
II "I — 

ill 

k « c 
• o • 
a-c S 

i • £» 

£ 3 B 

£ot 

3 30 

2°E 



a; 



"8 

a. 

a. 

< 

c <2 

™ c 
U at 

£ £ 



Ii 



en 

en 

-». 8 
« S 
c 

o «> 
> ±2 

i s 

a> 

X, 
H 

CN 

i 

tN 

CO 

<U 

§> 



tilS'lf 

fillsis 



en 



10 

o 

>\ 

5 



3.2-4 



is?? 



8g Jtljl 



a a. 
o.< 
« O 
5 • 

*! 

si 

Q.O 

(0 • 
Ul 



lil 



4 



ill 



I Hill 



Hj* 



?e 2 




III? 


<3 •£ 


cii; 


•.sgS 




si !s!i- 



*i 



= II 
ilfiii 



^ 



« O IE ■ 



fiv 


s 




£ 


Sx: 

3£- 


IS 


S*I 


c 


in 


• 
O 


!!*» 


■a 
5 


fill 


^ 


« 



E 3-S 

> « » w 

! 2.5 1? 




c 

3 

a 

> 
•c 

Q 

>> 
a 

a. 
» 

a 

it 



Q 
O 



sill 



o 
E 
o 

2, 
•> c 



I 



III 

II? 
js!]|J 



co ■ 

8 

a 
a. 
co 



ifi? 

O U 3 S 
KCL 



c II 

lift! 




• »_ 
Ifi 

m 

IP? 

llii 

Ulf 



» c » » 
»5J« 



2S.I1 




c 

I£ 

.2 
= Si 

C£ 

WO 

ii a 
3 « 

. 3 
2(0 

is 

o On 
>- S-2 

« « 3 
•» o O) 

•eil 

* • c 

II -E- 

o • S 
sll 

o •* 
X •) c 

o o o 

i 3 c 

• o © 
5-E3 
— -"5 

3 3 O 

S o £ 
""2 c 

QSS 
SOP 



o 
z 



ai 



1 

a. 
a. 

< » 

u« 

St 
3 O 
u O. 
a; CL, 

■S 3 
»- 60 

<.s 

8 S 

.2 2 

< <u 

u " 

•c S 
c * 

QJ CO 

T <-> 

H CD 



cr> 
■ 

CN 

CO 

(LI 



3) 



en 



u 



3.2-5 



I/O data, they are designated as GAP(M) type units. The MDM was shown in figure 
2.2-4. It can handle up to 9 different types of I/O processing and also contains a PROM 
programmed sequence control unit to control MDM operation. The Master Events 
Controller (MEC) has special control logic for processing of critical liftoff and stage- 
separation functions. The Engine Interface Unit (EIU) converts commands received 
from the GPCs over the data busses to engine bus protocol. The Display Driver Unit 
(DDU) converts the serial digital data stream received over the data bus to 
appropriate analog signals required to drive the various flight instruments. 

PCMMU - The PCMMU performs three of the modular GAP(M) functions as shown 
in Figure 3.2-4. The first is MIA communication over the data busses equivalent to 
GAP Local Interconnect Processing. The second is special I/O processing in which 
data received from the GPCs for insertion into the telemetry downlink data stream is 
formatted, commutated and configured. Additional special I/O processing is 
performed in the gathering of instrumentation data for use by the GPCs over 
dedicated instrumentation data buses from lower level MDMs. The third function is 
the Optional Functional Growth Interface to the MTU and distribution of the timing 
data over the data busses. 

MCIU - The MCIU is the control computer for the remote manipulator system 
(RMS). It has one data bus port used for receipt of moding and outer loop control 
signals from the GPCs. It is considered a SAP as its single function is to act as a 
control computer interface. The MCIU performs three of the modular GAP(M) 
functions as shown in Figure 3.2-4. The first is MIA communication over the single 
data bus equivalent to GAP Local Interconnect Processing. The second is application 
processing in which the moding and outer loop control signals from the GPCs are 
interpreted, RMS position data interpreted and the appropriate RMS digital 
commands created. The third function is special I/O processing in which the digital 
commands are sent and received from the RMS and analog RMS position data 
digitized. 



3.2-6 




o 






?.SEtS§ 
or So 



fo 




S. 


M = 


I 


PI i 
III ! 


U 




19 
S 


Still i 


I 





*» at 
o K * » 



a <» < a 




Hi 



c 
3 g, 

8 « 



2 £ 
o • 



ti 
is 

"s • 

So." 
.■s a fe 

2 ='« 

fl a s 

s i'5 

c • — 
.2 *3 
■S •* 
Jie 

3 O • 

— £ • 

u* 

03E 

• "O •» 

(A O « 
3 E 3 

in 

K C X 



S 



2 
o 



"O 




<u 












Cu 




a 




< 






eft 


<n 


.*-» 


(0 


C 




0) 


3 


cu 








w 


•** 


60 


X 


c 


1 1 




>-c 


(fi 


< 


U2 

ai 


tfi 






C 


P- 


O 


>-, 


> 
< 


01 

-4-* 


CJ 


O 






>- 


<u 


a> 




c 


-fc-» 


<u 


3 


U x 


ai 


CD 


X 


a> 


H 






a. 


■<* 


en 


CM 




m 




CD 




1- 




3 




M 





CO 

a> 



10 

1 

>t 

o 

a 



3.2-7 



3.3 SOFTWARE ARCHITECTURE 

The following requirements are extracted from paragraph 4.3.9 of the SGOAA Standard. 
"An architecture prepared in accordance with this standard shall include requirements for 
data system services. This shall consist of at least requirements for input /output data 
services management, network services management, data base management, data system 
management, and an operating system." All systems will not require all services provided 
by the SGOAA data system services architecture. For these cases, the data system services 
architecture may be tailored to satisfy specific system requirements. 

3.3.1 SGOAA DATA SYSTEM SERVICES REQUIREMENTS 

The SGOAA data system services provides all the interfacing services needed by 
applications to operate and control the vehicle, and is comprised of the elements 
summarized below. 

• Input /Output Data Services Management shall include at least requirements for 
Input/Output Data Services data acquisition, Input/Output Data Services data 
distribution and reports generation. 

• Network Services Management shall include at least requirements for network 
services, network management, remote operation, network directory service, and 
network association control. 

• Database Management shall include at least requirements for file services, 
distributed file transfer services, file transfer access and management, and node 
directory. 

• Data System Management shall include at least requirements for configuration 
management, timing service control, initialization startup and reconfiguration, and 
health status and fault detection and recovery. 

• Operating System shall include at least requirements for an Operating System (OS) 
kernel, a run time environment (RTE) and OS/RTE extensions. 



3.3-1 



3.3.2 SPACE SHUTTLE ONBOARD FUNCTIONAL SOFTWARE ARCHITECTURE 
COMPARED TO THE SGOAA 

The Space Shuttle onboard functional software architecture structure was shown in figure 2.3-1. This 
architecture differs from the SGOAA "Operating System" architecture requirements in that the FCOS 
was developed expressly for the Space Shuttle, and does not satisfy open standards criteria as required 
by the SGOAA. In addition, in order to satisfy SGOAA requirements, the Space Shuttle architecture 
would have to be modified at a functional level as shown in Figure 3.3-1. The primary changes are: 

• Change "System Services" name to "Data System Services" 

• Change "User Interface" name to "Input/Output Data Services Management" 

• Change "System Control" name to "Data System Manager" 

• Add a second level entity called "Data Base Manager" 

• Move "DPS Configuration Management" from FCOS to be a subset of "Data System 
Manager" 

• From "Application Processing Systems Management" move "Data Management" to 
be a subset of the "Data System Services Data Base Manager" 

Figure 3.3-2 shows how the SGOAA Space Data System Services would be tailored to 
provide the Space Shuttle software system services. Shaded areas are SGOAA data system 
services not required by the Space Shuttle DPS. The SGOAA Network Services Manager is 
not required as all Space Shuttle DPS communication is over the 24 data buses and not via a 
system interconnect network. The other deleted elements are self explanatory. 

The Space Shuttle FCOS presently performs all SGOAA OS Kernel and OS/RTE functions. 
To be compliant with the SGOAA, the FCOS would be upgraded to meet open standards 
criteria or a waiver would be obtained to allow continued, unmodified FCOS usage. 



3.3-2 





** 


o 


3 




o 


o 


J2 




O 


0) 


0) 


> 


o 



(0 

o 
en 



1- 

cs 
o 

CD 

I 




© c 

3 8 « 8 ulo oo 

*2 f S 25 %1 

Q. (OIL Q.O OO 



TO 

1 II II 



« 



o 

£ o 

o © 
0.2 



o 
o> p 

5i 



0) 

c 
o 

•c 
to 

« s 

o c 

ao 
(OO 



TO 

c 
•o'w 

CD *- 
DC Q.Q. 



c 
o 



u g 

•= a. 



.2 g a) 



3 

c 
o 
o 



O ~ O 



2 >=* 

c - 



O in TO *; 

a E o CO 
O ^-2® - 



o 

■2 > to e tj c o"» 
(D z u. cooes <o a 
• • • • • • 







fa 


4 


S 




-*) 


(U 


« 


< 


ID 


2 

< 




W 


£ 



c 
o 



E.S 



I 



co£ 



■£ 2 
■- £ 
E75.2 



El= 

5Jo.2 2oo 
to o "S co © c 



i * 



>» ® s 



£ tocc s 




>.Q.3 
CO COLL 






c 

TO O 



CO 

1 l_ *■§ 

(0 *- O X S/t0 

s ^ Ms 

2 &§ =|2? 

a. OO OS a. a 



CO 

c 



o 
o 
o 



i 



9 
_a 
CO 

T 
s 



S 
J 



3 


«• 
« 


eg 


Sf 


JS 


4 


< 

Q 


S 






1* 

O "8 



C 
o 

•8 

co 

(0 

CO 

■8 



en 

(0 

CO 

o 

c 
o 

> 
< 



0) 

o 

< 

o 



$% 



£ 
•c 

v 



3 
(/> 

CD 



CD 

c*i 

<u 

tin 






s- 



3.3-3 



}*! 


(0 cc 


fit 


HI LU 


§ 

lu 


OVNV 
0IAU3 




0)5 




o 
o « 

■* 3 

I If I 

O O 





£ CO O O 

3 CO £ £ 

o o o o 

SBoB 

£2 2 £ 

O Q 5 O 

O O O 




■2 .2 := 



UJ OC ii ii 


LL 


> d 3 <* 2 


CD 


FILE SER 
CONTRO 

o Sequer 

Service 

o Structu 


Service 
Distribu 






c 

Ba> 

m o 
$ H 55 

e 2 co 

o=§ 



UJ 
Uj o 

d> 
E oc 

uj V) UJ 
CD t 2 

OHO 



E £> 

© a> 

X3 15 

0) TJ 







2 


«/> 


c 


a 

> 


O) 


M 


c 


Ui 


"E 


c 


8 


3 

o 


© 


ij. 


cr 


© 


o 


O 



Q. 

< 

a 

.c 

o 
a 

UJ 




1 



a 




z 


2 


H 


UJ 


< H 


DC 


(0 


UJ 


> 


a. 


(/> 


O 





(0 

o 
o 



UJ 

z 
oc 

UJ 

(A 
O 

• 



c 



Be 

2 J2 
S2 "S 

CO N 

© -.= 
u a 

a. £ 



<D 

.2 I B)».a 



B 



CO 



IS 

o s 



E3.-&I 
ffl o. ~ .g 

2 O Z> 0- 













■c 


x 


C 


&s 


CO 


£ 


o. X 


o 


c 


wS 


a. 


£ 


«- < 


to 


> 


ompile 


is 

i s 


c 

UJ 


>ARTE 
ADAC 
ADA/N 


|«x 


£ 


5< 


a 


S*00 


o 




• 







CO 

o 
o 

U. w -J 

W Q.08 

£|I 

uj £ o 

I— 5 <" 

S- ® CD 

O 





c 


"O 




CD 


C 




E 


CO 


E 


© 
re 


g 


F 


m 




o 


c 


JS 


O 

(0 


CO 

5 


"55 


(A 


CO 


« 


8 
p 


3 


c 


m 


UJ 


n 


CO 


1- 


i 


fcoc 


<D 


<D 


c/5 


C 


C 


o 



c 
o 



•c 
22 

b 

<D 

E 

,2 1 
© £ 

CO CL 







(0 

H 
ey 
CO 

c 

(0 

U 

C 

o 

I 

4-J 
CO 

C/J gj 

11 



m 
Q 



2 




UJ 

H 
(0 
>- 
(/) 


DC 
UJ 

< 


< 

< 


Z 
< 


O 





<D =■ 
I- 0- 



o o o o 




T3 

c 

CO 



CO 

3 



<u. CD 
uj ?i 



» 



CO 

3 

OC ro 
"J CO 



5 CO 

co gj o cS 

•<= is a a 

co c BQ 



co 

3 UJ 

cr S 

CO 

a 



o 
oc 



®- (oPE^^ 1 ^ °crT 

rnStf'vnnnSI m CD 



S CD S 



Bl82 

co .!2 



O 
U 

OC 

So 



co a 

CD t 



to £ 



= O 3 o E -S 
•g S « 3 « S- 

ILQ.U.< 5 D 

) o o o 



C/3 

0) 

u 

(0 
C/5 



CN 

I 

CO 





00 




J* 




5 ? 




s 1 


OC 

g 

3 
CD 

I 

Q 


istributed Da 
ead (to DB) 
autlon & Wa 
rocessinq 


otcua. 


O 



o 
c 
'co o> 

C CD 

t2 
is o- 

Ii 
i- i 

O 



oc 

< 

oc 

UJ 

z 

UJ 

o 

h » c 3 
55Ef 

O <0 O 3 

CL t- "- O 
UJ 

OC O O 



O 

o 


Q 

(0 

c 
o 

E 

UJ 

II 



5 



3.3-4 



As in the SGOAA, applications processing is a function of user needs. To comply with the 
SGOAA requirements, the Space Shuttle application software would have to be modified to 
comply with the requirements of the SGOAA Class 5 and 6 interfaces as defined in Table 
3.2-1. A key requirement of the SGOAA is that direct application to application commun- 
ication is not allowed. All application to application software communications shall be 
implemented by use of system services. All communication must be through a Class 5 
direct standard interface to system services to provide the direct communications path 
between applications. An estimate of the extent of the modifications that would be required 
is outside the scope of this paper. 



3.3-5 



4. CONCLUSIONS 

As was shown above, the SGOAA was found to be capable of satisfying the functional 
architecture requirements of the Space Shuttle DPS. The SGOAA GAP internal and external 
architectures can be tailored to satisfy the Space Shuttle DPS hardware architecture 
requirements. In order to be compliant with the SGOAA, accepted industry standards are 
required to be used at all interface points or waivers be obtained. The Space Shuttle does not 
satisfy this requirement since it was designed at a very early stage in the development of 
standard interfaces. Were it to be designed today the requirement for the use of standard 
interfaces could be met. The SGOAA Space Data Systems Services architecture was also 
shown to be capable of being tailored to satisfy the Space Shuttle requirements. 



4-1 



DISTRIBUTION LIST FOR LESC-30753 

IMPLEMENTING THE SPACE SHUTTLE DATA 

PROCESSING SYSTEM WITH THE SPACE 

GENERIC OPEN AVIONICS ARCHITECTURE - CONTINUED 

LMSC . 1111 LOCKHEED WAY, SUNNYVALE, CA. 94088-3504 
ROY PETIS, 0/ 73-12, BLDG 564 

LMSC (RD&DV 3251 HANOVER STREET, PALO ALTO, CA 94303-1191 
BILL GUYTON, 0/ 92-20, BLDG 254E 
STEVE SHERMAN, 0/ 96-10, BLDG 254E 

LOCKHEED-SANDERS . 95 CANAL ST., NASHUA, NH 03061 

RAY GARBOS (NAM5D-5002) JEFF E. SMITH (PTPZ-B002) 

JOHN MILLER (NCA 09-1 1 06) DUNCAN MOORE (MER 24) 

WALTZANDI 

LADC . P. O. BOX 250, SUNLAND, CA 91041 
ALEX LOEWENTHAL, DEPT. 25-14, BLDG 31 1 

LAD . P. O. BOX 17100, AUSTIN, TX. 78744-1016 
CURTIS WELLS, ORG. T2-10, BLDG 30F 

LOCKHEED CORP . 4500 PARK GRANADA BLVD, CALABASIS, CA 91399-0310 
MICHAEL CARROLL 

LAS Ontario . P. O. BOX 33, ONTARIO, CA. 91761-0033 
C. R. (BOB) FENTON 

LFWC . P. O. BOX 748, FORT WORTH, TX. 76101 
PAUL DANIEL, MAIL ZONE 2640 

LSOC . 1 100 LOCKHEED WAY, TITUSVILLE, FL 32780 

L J. (LEWIS) BOYD, 0/ 32-40, (Z/LSO-183) 

ARTHUR EDWARDS, 0/11-42, BLDG. B/DX-D, Z/LSO-284) 

ROME LABS/OCTS . GRIFFIS AFB, NY 13441-5700 
RICHARD WOOD 

C. S. DRAPER LABS. 555 TECHNOLOGY SQUARE, CAMBRIDGE, MA. 02139 
J. BARTON DEWOLFE/MS 61 

ASC/ENAS . WRIGHT-PATTERSON AFB, OH. 45433 
FRED WILSON 

AMSEL-RD-C2-TS-I . FT MONMOUTH, NJ 07703 
DOUG JOHNSON/ACC #66 



DISTRIBUTION LIST FOR LESC-30753 

IMPLEMENTING THE SPACE SHUTTLE DATA 

PROCESSING SYSTEM WITH THE SPACE 

GENERIC OPEN AVIONICS ARCHITECTURE - CONCLUDED 



NAVAL AIR WARFARE CENTER . AIRCRAFT DIVISION, 
WARMINSTER, PA 18974-0591 
RICHARD J. PARISEAU/CODE 102A 
RICHARD S. MEJZAK/CODE 2021 

MITRE CORPORATION. 202 BURLINGTON ROAD, BEDFORD, MA 01730-1420 
JACK SHAY/DIRECTOR OF SYSTEMS DEVELOPMENT 

MR. AL ANDERMAN. (ROCKWELL), 930 3rd STREET, APT. 302, 
SANTA MONICA, CA 90403 

WESTAR CORP.. 6808 ACADEMY PKWY EAST, NE, BLDG C, SUITE 3, 
ALBURQUERQUE, NM 87109 
CHRIS DE LONG 

BOEING CORP. P.O. BOX 3999, SEATTLE, WA 98124-2499 
RICHARD FLANAGAN 
AL COSGROVE 

COMPUTING DEVICES INTL . 8800 QUEEN AVENUE SOUTH, 
BLOOMINGTON, MN 55431 
JIM JAMES, M/S BLCS1 D 
DOCK ALLEN, M/S BLCW2S 

TEXAS INSTRUMENTS . 6550 CHASE OAKS BLVD. PO BOX 869305, 

PLANO, TX 75086 

DR. CHUCK ROARK/MS 8481 

MCDONNELL DOUGLAS CORPORATION . 1801 E. ST ANDREW PLACE, 
SANTA ANA, CA 92705 
TERRY RASSET/MS A208 

HUGHES AIRCRAFT. P. O. BOX 92426, LOS ANGLES, CA 90009-2426 
JOHN GRIFFITH, RE/RI/B500 

FAIRCHILD SPACE . 20301 CENTURY BLVD., GERMANTOWN, MD. 20874 
JOHN SCHNEIDER, FLIGHT DATA SYSTEMS 



REPORT DOCUMENTATION PAGE 



U-S. Gov t 



Form Approved 
OMB No. 0704-0188 



Public reporting burden for this collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and 
maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information, 
including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for information Operations and Reports. 1215 Jefferson Davis Highway, Suite 1204, Arlington, VA 
22202-4302, and to the Office of Management and Budget. Paperwork Reduction Project (0704-0188). Washington, DC 20503. 



1. AGENCY USE ONLY (Leave blank) 



2. 



REPORT DATE 

July 1993 



REPORT TYPE AND DATES COVERED 

Contractor Report 



4. TITLE AND SUBTITLE 

Implementing the Space Shuttle Data Processing System with 
the Space Generic Open Avionics Architecture 



6. AUTHOR(S) 

Richard B. Wray 



5. FUNDING NUMBERS 



7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES) 

Lockheed Engineering and Sciences Company 

2400 NASA Road 1 

Houston, Texas 77573-3799 



8. PERFORMING ORGANIZATION 
REPORT NUMBER 

LESC-30753 



SPONSORING / MONITORING AGENCY NAME(S) AND ADDRESS(ES) 

National Aeronautics and Space Administration 
Lyndon B. Johnson Space Center 
Flight Data Systems Division, EK . 
Houston, Texas 77058 



10. SPONSORING /MONITORING 
AGENCY REPORT NUMBER 

NASA CR- 188254 



11. SUPPLEMENTARY NOTES 



12a DISTRIBUTION /AVAILABILITY STATEMENT 

Unclassified/unlimited 

Available from National Technical Information Service 

5285 Port Royal Road, Springfield, VA 22161, (703) 487-4600 

Subject Category 66 



12b. DISTRIBUTION CODE 



1 3 . ABSTRACT (Maximum 200 words) 

This paper presents an overview of the application of the Space Generic Open Avionics 
Architecture (SG0AA) to the Space Shuttle Data Processing System (DPS) architecture 
design, this application has been performed to validate the SG0AA and its potential use 
in flight critical systems. The paper summarizes key elements of the Space Shuttle 
avionics architecture, data processing system requirements and software architecture as 
currently implemented. It then summarizes the SG0AA architecture and describes a 
tailoring of the SG0AA to the Space Shuttle. 

The SG0AA consists of a generic system architecture for the entities in spacecraft 
avionics, a generic processing external and internal hardware architecture, a six class 
model of interfaces and functional subsystem architectures for data services and 
operations control capabilities. It has been proposed as an avionics architecture 
standard with the Nation Aeronautics and Space Administration (NASA), through its 
Strategic Avionics Technology Working Group, and is being considered by the Society of 
Aeronautic Engineers (SAE) as an SAE Avionics Standard. This architecture was developed 
for the Flight Data Systems Division of JSC by the Lockheed Engineering and Sciences 
Company, Houston, Texas. 



14. SUBJECTTERMS 

avionics, space shuttle, generic avionics, architecture, data 
processing system, interfaces 



15. NUMBEROF PAGES 



16. PRICE CODE 



17. SECURITY CLASSIFICATION 
OF REPORT 

unclassified 

S'.ancard Form 298 (Rev. 2-89) 
P-escnbed by ANSI Std. 239-18 
298-102 



18. SECURITY CLASSIFICATION 
OF THIS PAGE 

unclassified 



19. SECURITY CLASSIFICATION 
OF ABSTRACT 

unclassified 



20. 



LIMITATION OF ABSTRACT 

UL 



DISTRIBUTION LIST FOR LESC-30753 
IMPLEMENTING THE SPACE SHUTTLE DATA 

PROCESSING SYSTEM WITH THE SPACE 
GENERIC OPEN AVIONICS ARCHITECTURE 

NASA 

EK1 1 1 /D. M. PRUETT (1 0) EG1 /D. P. BROWN 

PT4/E. M. FRIDGE (5) EG1 1 1/K. J. COX 

AMES/E. S. CHEVERS JM-2/S. McDONALD (30) 

EK3/J. BELL (2) EK3/R. S. DAVIS 
EK3/D. JIH 

LESC 

C18/J. R. THRASHER C18/G. L CLOUETTE 

C1 8/E. A. STREET C1 8/R. W. WRAY (1 0) 

C18/R. E. SCHINDELER C18/M. W. WALRATH 

C1 8/J. STOVALL (1 0) C1 8/B. L DOECKEL 

B1 1/G. J. MOORMAN C29/P. HOPKINS 
C106/P. G. O'NEIL 



C87/M. W. BRADWAY 
(FOR SATWG REDISTRIBUTION) 

C1 8/JEAN FOWLER B1 5/LESC LIBRARY (2) 

(MASTER + 2 COPIES) 

LESC. 144 RESEARCH DRIVE, HAMPTON, VA 23666 
ROY WENDE 
PHIL MARTIN 

SAE/ASD. SAE INTERNATIONAL, 400 COMMONWEALTH AVE, WARRENDALE, 

PA. 15096 

BARBARA ROTH (FILE) RICH VANDAME 

MITRE CORPORATION . 1120 NASA ROAD 1, HOUSTON, TX 77058 
STEVE BAYER (2) 

UHCL . UNIVERSITY OF HOUSTON - CLEAR LAKE, 2700 BAY AREA BLVD. 
BOX 444, HOUSTON, TEXAS 77058 
CHARLES HARDWICH 

NIST/CSL . FRITZ SCHULTZ, BLDG 225, ROOM B266, 
GATHISBURG, MD 20899 

LASC. 86 S. COBB ST., MARRIETTA, GA 30063 
RICK HARWELL, D/73-D2, ZONE 0685