WRPSHT-PAftiRSON AIR FORCS BASg, OHIO

QE/EE/77S-6

v

/la>5tt^i U<s/^

f^Z7 ^£_/

''>, STRUCTUKlsl) AN/Vl.YÜIS itNl) DlsüIOM OF A

SATELLITE SIMULATOR 0

fc; ylM7/,'iVHK/77S-(

THKÜTS

Kenneth T,./Marvin \ rirpuiin—-*—WH**-*

Approved for public release; distribution unlimited.

D D C

JUN 19 I

1 I? ' E

#

o\^ ^^ 166 JJ

.JEidlHHHBiHuyL^^....

QjyEs;/77S-b

STRUCTURED ANALYSIS AND DESIGN OF A

SATELLITE SIMULATOR

THESIS

Preaented to the Faculty of the School of Engineering

of the Air Force Institute of Technology

Air University

In Partial Fulfillment of the

Requirements for the Degree of

. Master of Science «CCCSSIJN tor

Nii:

D C

WAN";!

JUSIIfiCUIOH

,»■' s ■•

!> : in j |

I I

BY

t'lsmiaunoH wiuüuin CODES

BUt. A,,111 a, ,: .„,(:i4l

by

Kenneth L. Marvin, B.S.E.E,

Captain USAF

Graduate Electrical Engineering

September 1977

Approved for public release; distribution unlimited.

mm-mmmmm B^m

Preface

This thesis presents an effective application of a structured

analysis and structured design methodology to a complex satellite

command system. The methodology used combines features of three

different design techniques. The key to the successful develop-

ment is the preliminary design which gives a complete requirements

definition in an understandable diagram form, A series of these

diagrams are combined to form an activity model and a data model

of the simulator using a top-down design strategy. The activity

model is the starting point of the design refinement, A first cut

structure chart is drawn directly from the activity model. A data

flow graph is then created which in turn is converted Into a re-

fined structure chart. The refined structure chart is the primary

vehicle which facilitates the programming phase. Even though the

programming has not been done in this thesis, a structured analy-

sis and design has been performed that presents a satellite simu-

lator that is modifiable, understandable, and free of implementa-

tion constraints,

I thank uy thesis advisor. Captain Peter E, Miller, for his

professional influence and guidance throughout this project. Thanks

must also be extended to Captain J, B. Peterson for sharing his

expertise with me in this endeavor, A very special thanks goes

to my wife, Maryanne, and to our children, Kevin and Cindy, with-

out their patience and love this effort would have been wasted,

I cannot close without thanking God whose eternal wisdom has pre-

vailed throughout.

Kenneth L, Marvin

il

«

Contentg

Tage

Preface 11

List of Figures , iv

List of Tables vi

Abstract vll

I. Introduction 1

Objectives ................... 1 Scope • • ■ • 3 Plan of Development ». 4

II. Requirements Definition .............. 5

Introduction •...« 3 Context Analysis 5 Design Conatraints ... 6 Functional Specifications „.... 7 Summary ...... • 9

III. Preliminary Design ..... 11

Introduction ........ ... 11 Diagram Syntax .< 11 Reading Sequence ,. ....... 13 Activity Model •••••••••••• lif Data Model ...... ...... k7 Summary 70

IV. Design Refinement 71

Introduction .................. 71 First Cut Structure Chart 73 Intermediate Bubble Chart .. . 77 Refined Structure Chart 81 Summary 93

V. Design Analysis 94

Introduction ............ 9k Summary •••••••• 94 Conclusions and Recommendations ........ 96

Bibliography ..... ..... 97

Vita gg

ili

? I.Ist of Figures

Figure Page

1 Module/interfaces Arrow Conventions .... 12

2 OR Branch and Join StructureE ............ 13

3 Simulate Spacecraft ....... .. 15

k Simulate Spacecraft ... ..... 17

5 Procesa Input Word ............. I9

6 Determine Type of Input Word 21

7 Format Spacecraft Command ......... 23

8 Perform General Validity Checks .... 25

9 Determire Type of Command .,,..,,.....,. 27

10 Perform Command Validity Checks ........... 29

11 Update Vehicle Status 31

12 Determine Type of Modification Heuuired . 33

13 Perform Update .......... 35

llf Generate CV Words • 37

15 List Types of Format Errors ..... 39

16 List Types of Sequence Errors ............ u]

17 Determine Proper Vehicle fiessages .r 43

18 Create Output Messages ,. , 45

19 Simulate Data 48

20 Simulate Data 50

21 Input Words 52

22 Spacecraft Uplink Word 54

23 Format Errors .......•••••••••«..• %

24 Status Modification Word •••••••• 30 41

25 Formatted Spacecraft Command .••....•...... 60

iv

List of Fl.':ur''".

Figura

26 Sequence Errors . ,

27 Current Statue Data ••••.•...•••••••••

28 Vehicle Message Data

29 Output Messages

50a First Cut Structure Chart

30b Update Vehicle Status ........

3Cc Create CV Words

30d Create Output Messages

31 Interaediate Bubble Chart ...............

32 Top Level Structure .......

53 STATMOD Module and Subordinates

3ff Spacecraft Command Afferent Branch ..........

35 VEIISTAT Module and Subordinates

36 CVWORDS Module and Subordinates

37 OUTMESS Module and Subordinates

Pa.^o

62

6if

66

68

7 k

76

77

80

82

83

£5

88

90

92

'M^ ^ '^^'^

I First Cut Structure Chart Parametora

II Spacecraft Couunand Afferent Branch raraneters . .

Ill VEHSTAT Parameters

IV CVWORDS Parameters

age

78

89

▼i

. . ..... .. . : ih^ ■"-^':^-;-" '■ .^. . . _

■■ "■

QFyEky77S-6

Abstract

The problem addroesed in this thesis is the analysis of a

complex satellite command system and the design of a software sim-

ulation of that system. The problem is solved in three steps.

First, a written requirements definition establishes a sound view-

point and purpose on which the analyst can base his design. This

requirements definition explains why the simulator is to be cre-

ated, how it is to be constructed, and what it is to do. Second,

a top-down strategy called "structured analysis" is applied to

create the preliminary design. The structured analysis is pre-

sented in a blueprint-type language with activity and data models.

The models represent graphically the functions performed by the

simulator and the information upon which those functions act. A

final design refinement is performed with a structured design meth-

odology called "transform analysis," The structure charts drawn

during the transform analysis reveal system characteristics which

illustrate design quality. The activity model acts as a catalyst

to a successful transition from a top-down analysis to a structured

design which can be evaluated. The resulting simulator design,

with minor revisions, satisfies the design goals establishfll for

the project. The methodology used, is highly recommended for the

analysis and design of any software system.

Tii

__________________

STRUCTURED ANALYSIS AND DESIGN OF A

SATELLITE SIMULATOR

I, Introduction

Objectives

This thesis presents a "•structured*' developnent of the require-

ments and the design needed to create a software simulation of an

operational satellite, A good development technique ie required

to make the final programming easier and more understandable. The

primary objective of this thesis is to avoid all of the negative

effects of a premature system design (Rof ^:2), To meet that ob-

jective, it is necessary to do a complete and understandable require-

ments analysis of the system to be designed, A requirements anal-

ysis is the first step towards the design of a high quality system

that is efficient and rsliable.

Any quality development project, be it hardware or software,

must be based on an orderly, controlled, and disciplined methodol-

ogy, (Ref 6:5). While searching for such a methodology, the top-

down design phases of the software life-cycle are considered. The

first two cteps in the life-cycle are classified as "system require-

ments" and "software requirements" (Ref 2:3-4)« A thorough expla-

nation of the system and the functions it performs must be present-

ed. This explanation is given by a Requirements Definition as de-

fined by SofTech, Inc. (Ref 4:4). The Requirements Definition is

the first portion of SofTech's Structured Analysis and Design Tech-

nique (SADT). It is this portion of the SADT that is used in the

I JUJmiüiiPII I IWWIPI ■ ^ J.ipiiLII UiJlLllll .ULIUIIII ||L._, HPiUÜWraPPi

requlroments analysis and preliminary design of the satellite sim-

ulator. Requirements Definition deals with three subjects: context

analysis, design constraints, and functional specifications. These

subjects give a definition of the requirements for an efficient

and long-range, cost-effective system. The context analysis explains

why the system should be created and why certain technical and op-

erational capabilities set the boundary conditions for the system.

Design constraints explain how the system is to be constructed.

The objective here is not to specify which things will be in the

system, but only to set limits for selection of those things at

a later time. The functional specifications are of primary inter-

est. Those specifications give only the boundary conditions for

requirements taken up in the design phase (Rsf 6:5-6).

The next phase in the software life-cycle is the preliminary

design. The objective is to define system requirements more explic-

itly and to present a functional analysis that is conceptually com-

plete. During this phase in the development, a design is produced

that makes coding, debugging, and modification easier, faster, and

less expensive by reducing complexity (Ref 9:115). After the pre-

liminary design, a departure is made from the SADT. This departure

is required to provide a design refinement that can be evaluated.

A design technique called "transform analysis" is performed which

has characteristics that reveal design quality (Ref 10:254-300).

The combination of the preliminary design based on structured anal-

yaie and the design refinement based on transform analysis creates

a satellite simulator design that is modifiable, understandable,

and free of implementation constraints.

The sponsor of this thesis is the i+000 Aerospace Applications

Group (SAC), 1ccated at Offutt Air Force Baso, Nebraska, They are

responsible for command, control, and analysis of the weather sat-

ellite (Block 5D), which is to be eimulated. Operational require-

ments place a limit on the amount of software development that can

be done "in house." A need exists for a simulator that can be used

as a training device for satellite controllers and as an analysis

aid for satellite data analysts. The purpose of this thesis is

to provide a design of such a simulator.

Scope

The initial investigation of the satellite system shows that

a simulation of all the satellite functions is beyond the scope

of this thesis (Ref 1), However, a simulation of the spacecraft

command "uplink11 and command verification (CV) "downlink" is of

primary importance, A simulator is required that 'will accept space-

craft commands in a realistic format, simulate performance of the

proper functions in response to those commands, and maintain rec-

ords of spacecraft status (i,e, telemetry point values, transmit-

ters on or off, etc), which can be modified at user request. In

addition, the simulator should be designed in a modular fashion

to ensure the modiflability, maintainability, and understandability.

The structured analysis and design techniques used in this devel-

opment effort present a modular system that is functionally inde-

pendent. This independence makes it easy to add or delete modules

to further enhance the realistic nature of the simulation at a later

time. No attempt is made to do the actual programming required

to Implement the simulator. However, the structured techniques

used to perform the analysis and design will facilitate the final

programming phase.

Plan of Development

Chapter II is a presentation of the Requirements Definition

with emphasis placed on the functional specifications. Chapter

III presents a Preliminary Design of the simulator in the form of

activity and data models. The approach used in both of these chap-

ters is based on the technique prepared by SofTech, Inc. called

"structured analysis." Chapter IV presents a refinement of the

preliminary design, which is illustrated with structure charts and

data flow graphs (bubble charts). These charts and graphs are

used to do the transform analysis. Chapter V contains a summary

of results obtained in this development as well as conclusions and

recommendations.

II. Requirements Definition

Introduction

The phase of the software life-cycle most often abused, or

neglected, is the Requirements Definition. The Requirements Def-

inition presented in this chapter is in a written form to show a

dirtinction between it and the illustrative functional design pre-

sented in Chapter III, This order of development allows the ana-

lyst to establish a sound viewpoint and purpose on which to base

hie first phase of design. The lack of a Requirements Definition

usually results in rising costs, missed schedules, waste and dupli-

cation (Ref if:2). In addition, the elimination of this important

step results in the absence of a useful documentation package.

This creates the most common problem with large systems in the Air

Force: a lack of understanding by the engineer who takes over the

project. He typically must spend an inordinate amount of time nearly

"redeveloping" the system to bring his level of understanding to

a point where he can be productive.

Included in this chapter is (1) a context analysis, which

tells why the simulator is to be created, (2) a set of design con-

atraints, to tell how the simulator is to be constructed, and (3)

a set of functional specifications that describe what the syatem

Iß to do.

Context Analysis

To better understand why a satellite simulator is to be cre-

ated, an explanation of the environment (context) in which it is

to be used ie needed. This explanation iß given in the context

analysis which follows.

The ifOOO Aerospace Applications Group (SAC) is responsible

for the command and control of weather satellites in support of

Global Weather Central at Offutt Air Force Base, Nebraska, It is

also responsible for monitoring spacecraft telemetry and data to

aid in detection of any anomalies that may have occurred during

its orbit. Over the years these satellites have increased in com-

plexity and produce more data for analysis purposes. This has in-

creased the need for a good, easy to use simulator to aid in anom-

aly analysis and to function as a training device for new system

controllers.

To FeI,form aB a11 analysis tool, the simulator must display

current telemetry point values upon request» It must also provide

the analyst with current status information about transmitters,

central processing units, and sensors on the spacecraft. This in-

formation must be provided after each spacecraft command is/given

to the simulator and upon request from the user.

The simulator must accept its input in the same format that

is transmitted to the satellite. This formatting is currently done

by an existing hardware device known as the 5D Interface (5DI).

Commands will be input through the 5DI to the simulator. In addi-

tion to the outputs mentioned above, the simulator should provide

the proper command verification words and an explanatory message.

Design Constraints

This section is a summary of the conditions specifying how

I

the simulator is to be constructed. No attempt is made to specify

input or output devices. Those details should be considered at a

later stage in the design (Ref k:k)>

There are four fundamental goals which should be considered

by the software engineer when he begins his development process.

They are (1) modiflability, (2) efficiency, (3) reliability, and

(if) understandability (Ref 5:89). These are the constraints con-

sidered in the process of selecting the analysis and design tech-

niques used. The techniques selected are SofTech's structured a-

nalysis for the preliminary design and a structured design method

for the design refinement.

Functional Specifications

Functior.al specifications are imposed on the functional ar-

chitecture of the system. They differ from system architecture

specifications because they outline the purposes of the system in-

stead of giving the languages, transmission links, and record for-

mats that ai^ in the system (Ref ^8). The following functional

specifications are a first step towards the creation of the func-

tional architecture. The next chapter presents the functional ar-

chitecture as the preliminary design of the simulator.

There are four main functions that should be performed by

the simulator. It should (1) process the input word, (2) update

the vehicle (simulator) status in response to the input word, (3)

create the appropriate command verification words, and (k) create

an output message informing the user what action has been taken.

A brief description of each of those functions follows.

Process Input Word. A eatelllte simulator input should be

classified as a spacecraft uplink command or a user command, A

user command modifies the current vehicle status data, i.e. change

a telemetry point value, add or delete a status table, etc. A space-

craft uplink command must be properly formatted before it can be

executed. The formatted command simulates satellite functions by

updating status data and creating the appropriate command verifi-

cation message. The formatted command must first be checked for

parity and wordlength. If an error is detected, it is saved and

used later by the simulator to generate the proper command verifi-

cation words and output messages.

After the initial format checks are made, the spacecraft com-

mand type must bo determined. This determination will influence

the kind of sequence checks that need to be performed. Some space-

craft commands require a series of sub-coamands iu a specified order,

while others require a specific time interval between them before

they can be executed.

The processing just describad will produce a user command

in the form of some type of status modification word, a spacecraft

command that will contain some errors (invalid command), or a space-

craft command that is error-free (valid command). One of these

inputs will be passed to the remainjn.g functional activities for

appropriate processing.

Jpdate Vehicle Status» Only a user command or a valid space-

craft command effects the current status information. An invalid

command is only acknowledged by the command verification function.

When the required modification is determined, an update request

8

Is issued and the necessary update function is performed. The new

status information is then given to the user.

Create Command Verification Words. Previously detected er-

rors should be listed and used to determine the applicable command

verification (CV) codes. These CV codes are transmitted via the

downlink from the spacecraft after a command has been received»

To make the simulator a more valuable analysis/training device,

an explanatory message should be output with the CV code. There

are also verification codes associated witb valid spacecraft com-

mands which should be handled in the same manner as the erroneous

command codes.

Create Output Messages. The CV words are now translated and

a meaningful output message is produced. Any status modifications

are noted with a specific update message. The messages are assem-

bled and a complete and easily understood output text is produced.

Summary

This chapter presents a context analysis of the problem, de-

sign constraints for its solution, and functional specifications.

The context analysis forms a perspective from which to view the

overall problem. An effort is made not to let the context analy-

sis be functional specifications, however, the context analysis

and functional specifications are closely related and in some cases

it is difficult to separate the two. The design constraints are

imposed by the desired design goals. Analysis and design techniques

are selected that should make the design meet those goals. The

functional specifications are given in nodular sections which are

9

M

the four basic units needed for construction of the next lovel of

design» This construction consists of the SADT activity and data

models presented in the next chapter.

10

Ill, Preliminary Pe^l^n

Introduction

r;he activity and data modele precentod in this chapter rep-

re sen : the results of many attempts to illustrate the conceptuKl

ideas conveyed by the functional specifications. These models,

organized as a sequence of diagrams with supporting text, form the

preliminary design.

The activity model is presented first, followed by the uata

model. These models graphically represent the functions performed

by the system and the data upon which the functions act, Each model

contains ooth data and activities with cocipliraontary emphases.

The combination leads to "a much richer understanding of the sub-

ject than le afforded by a single model" (Ref 7: Chap, 2, p, 5),

Each level of modules is a more detailed decomposition of the level

above. This structured decomposition is the substance of top-down

design. The following is a brief explanation of the diagram syn-

tax to aid the r der in understanding the models, A more detailed

discussion can be found in reference ?•

Diagram Syntax

Structured Analysis diagrams are composed of boxes and arrows

which are a vehicle for clearly expressing activity and data mod-

ules (Ref 7: Chap, 3, P« H, Figure 1 Illustrates examples of the

activity and data modules. The "mechanism" arrows are shown for

completeness but are not used at this stage of the design since

they are intended to represent the functions or hardware needed

n

~-—

to realize the module. The "multiple branch" (exclusive OR) is

used to indicate multiple, but not simultaneous outputs. The

"multiple Join" indicates multiple, but not simultaneous inputs.

Both conventions are shown in Figure 2.

In general, data and activity modules are decomposed into

more detailed data and activity modules. Each module that is de-

composed is referred to as a "parent" module and modules that re-

sult from the decomposition are the "children." Tu relate the

arrows of the children to those of the parent, an "ICOM" code is

CONTROL (data) 't

CONTROL (activity)

INPUT (data)

LCTIVITY TITLE

.OUTPUT INPUT t (data) (activity)

t DATA TITLE

T

^UTPUT (activity)

MECHANISM (processor)

MECHANISM (store)

Figure 1, Module/interfaces Arrow Conventions

is used. The acronym is derived from the arrow names: input, con-

'.rol, output, and mechanism. Each arrow at the parent/child bound-

ary is uniquely labeled with the letter I, C, 0, or M with prefix

and euiifix numbers. The prefix number refers to the module within

the child and the suffix number refers to the top-down or left-

right order of the arrow on a module. The boundary is the outer

border of the activity or data diagram. Each diagram is called

12

mm MMMBESC ■MHH ~d

" ■"—' |i< um*vv,-t...,'i-m.mm',t

A +.

B

two-way brsmch

B

three-way Join

Figure 2. OR Branch and Join Structures

a "node.

Reading Sequence

The following is a suggested reading sequence, looking at

each module in top-down order:

1« Scan the boxes to get a first impression.

2« Rethink the message of the parent module, observe the

boundary arrows,

3« Refer back to the current module, checking arrow attach-

ments between it and the parent,

i*. Consider internal arrows. Consider boxes from top to

bottom and left to right.

5» Read the text.

13

Activity Model

Before reading the activity diagrams, it is recommended that

the "node index" given below be scanned. This index serves as a

table of contents, and gives an overview of the decomposition struc-

ture.

Node Title Pa££

A-O Simulate Spacecraft 15

^0 Simulate Spacecraft 17

Al Process Input Word 19

A.11 Determine Type of Input Word 21

Al2 Format Spacecraft Command 23

Al3 Perform General Validity Checks 25

Al If Determine Type of Command 27

Al 5 Perform Command Validity Checks 29

A2 Update Vehicle Status 31

A21 Determine Type of Modification Required 33

A22 Perform Update 35

A3 Generate CV Words 37

A31 List Types of Format Errors 39

A32 List Types of Sequence Errors ^1

A33 Determine Proper Vehicle Messages kJ>

A2f Create Output Messages ^-5

>k

p

15 .1

jimipjipm.... liflHiPU1 «ipi»lftJilJlUil*J! ■PP . i i Jiyii||M|[ip|ij|||iij|B!iBpi!pj|[MBiJPl«!lW|4i''i^^^

■ ■:*;-. ■'

A-0 Text: An input word (II) ie received by the simulator- That

word is either a user comnand or an uplink spacecraft command, but

not both at once. The activity perfornsd ("SIMULATE SPACECRAFT")

is constrained by the type of input word (Cl), or by the parity,

wordlength (C2) and type (C3), if the input is a spacecraft command,

The final product of the activity is a complete and understandable

message to the user (01) for problem analysis or spacecraft inter-

rogation.

16

«PPBPW '■-'"■■ : ,.,- amtammmms ummm. -■^mmmm

AC «

3 * ' P. (0

+> (0 3 (1) o s:

n 0)

P. w

3 0) U O X

" ' c o K>

■H +J i

<D (0 -P T3 o « c •H (H d <n CO 0) f- •H X> c i fn u 0) o a> o es o > at j

u r o

(0 •o a (4 « o o l> o u ^ d, 3

P< a M

/

p.

^5 3 P a

S. 3 XJ \P. U

a o H »

S 0)

O ST.

CO

o 8) o

CQ

-P «s n B

•rH CO

-3-

El

17

AO Text; An input word (II) is received by Proceps Input Word (1).

That word is either a user command to modify vehicle (simulator)

status or an uplink spacecraft command. If it is a user command,

it is passed as a statue modification (101) to control the Update

Vehicle Stalus (2) and Create Output Messages (i+) activities. If

the input word is a spacecraft command, two constraints determine

the type of output. These constraints are parity/wordlength (02)

errors and command type (C3). If there are no format (parity/wcrd-

length) errors, a valid command (103) is used to control the other

activities. Another possibility is an invalid command (10?.) which

results from a parity/wordlength error. Update Vehicle Status (2)

uses the status modification, the valid command, or the invalid com-

mand to determine the required vehicle status updates. The current

status (20'0 is used as part of an output message (^01). A valid

command is acknowledged by a Command Verification (CV) Word (301).

Generate Command Verification Words (3) produces thase CV words

and they are used by Create Output Messages (^), along with the

constraints shown, to produce an output message responsive to tJw

particular input word that is being processed.

13

—

KV u

-a o >: to a

> c o M Ü

/--9

E

I I* h O U

^X

u c d> aS o a <Q E PJ O

T

a) s Pi E

>> B -O -P 1 S-. C -H CO

-^J o «3 -o j«; <M S -H Ü IH B H 0) ' H) O (0 Ä ;

\ PU O > O | \ — -

\ A

1 u i •H T1 1 <M ß •H OS ' U E 1

01 G ; ft O

CO Ü 1

fci C8 nH CO O U ■& X *-• 0) -H O

e «> as A (X, Ü > o

T Ti

© ti •- A O

■H «i se a o t. -P <u 0 3

■p a ft

S^S i

1

f r—

H

I

■a o

o

ft

01 o u o

■

19

Al Text; Determine Type of Input Word (1) is primarily concerned

with whether «in input is in the format nececeary to simulate an

uplink spacecraft command (102), or in a user command format to

be processed as a status modification (101). The spacecraft command

ie first formatted properly for uee by the simulator. The formatted

command (201) is passed to the remaining activities for processing.

After the command is checked for parity/wordlength (C2) it is de-

coded to determine the command type (C3 . Finally, it is checked

for proper sequencing. Determine Type of Command (k) performs its

function on a command even if it contains a format error. Perform

Command Validity Checks (5) outputs an invalid command (501) or a

valid command 502) to be used by the next activity.

20

r

-a o

« 3 Pi P.

\

\

1

«

u a « 0) ü R « li P. o

Vi o

o

^

« © pi. P, O K W O &:

N K o 3 Vi

«S T3 ■P O

o

4 B o ^ a -H o 3 *i *-• -P Ti

« -p o

ru

a o 3 -H

03

(0 Tl u u

■H O

4 -a • o

3 T3

ti o H *

o

"0

o

3

o a»

a)

■ 4' a» P

a' U a w

21

■"I ■■■■■ mn^ tmmmmm—

AH Text: If the Input Word (II) le a user modification, Read Sta-

tus Modification Word (1) outputs a status modification request

(101) which controls Perform btatus Modification (2), Upon receipt

of the particular request, a status modification (201) is output»

upon receipt of a word in tho uplink format, activity (3) reads

the tpacecraft uplink word and outputs the spacecraft command (502)

for use by the next activity.

22

VH

Ü • Ü «J

P« ft

\

a m u a e u

CO

\a ♦* a ■*» <a «e e B 6 h O OCJ tk.\.

\,

^

•c «

+> "0 *> Ö

^ a e -ö : O »H B »^

■P O O O 1 CO t^ O s ,

(V

(0 « v< ►J o

CO -p ■H

•O Vi TJ ,D « rH h 0) «0 O ON « K S: w

U Q T» *- -P

T» V* T3 « iH b VO « « O •-

PC W S: v-^

X)

o

3 P.

CVI

o

s o o

a) c o c CO ft to

e o

El

23

i finiLniij.u i ..-Ä^wtwj^!«.:-. ^mmmmm^-

A12 Text: After It is determined that the input word (II) is a

spacecraft comr.and (C1), the first 16 bits of the word are read

in activity (1) and the spacecraft data (101) is output. The re-

making nine bits oX the word are read in activity (2) and the

spacecraft address (201) information is passed. Both of these out-

puts are stored by (3) and they are the formatted command (301).

24

mm*

^.

4» « u e o u u o u

c ■H B u

0)

K>

03

Ö W EH

«I

« o

o « o

•H

>

0) o

B o

•n

a

CO

to

51

25

A13 Text: The formatted command (11) is input to both activity

boxes (1) and (2) for a wordlength check and a parity check.

There are various error codes that .are associated with individ-

ual commands. After the error checks have been made, any errors

that have been found are used to determine the codes that apply

to the particular command and error (3).

26

«-»■.ULUH . , ^J

■d

ß ^ i o o »

"\,

o

O-

I

CM +> O ft ft 3 ü »H

h •n <B <D «J 4J T» (D ß O K MÜ

x, <ö 3 0 B >< i P 0

o o

o

01 -p

■P a at fn a o

-P M ^ <D O U O PM M

27

AH Text: The command type (C2) must be determined for all cora-

mands. If format errors (C1) exist, they are passed as indica-

tions of an erroneous command (101), or an error-free command (102)

The CPU Interrupt Code (CIC) is read (2) from the formatted

command (II). This code will relate to a certain type of command.

The command words (01) that are output are either invalid or val-

id, depending on ahether a format error has or has not been de-

tected. These determinations must be made before the particular

command can be executed.

28

P"- n'*^1'1 PHPfP II J..miJlI IJ] J JPIMUIMWIUIJIL mwiiiiiium

A- O

■o o axi 1 ■ ^— E O S & 5

K>

r — 'O Q to

o e -H fc c i e

Ä o -^ ü Ü EH

1

^ u ^ ä o <D t. SJ tl o"« a «>

«j , ^*

fH •Ö o

JlJ 3 <D

© e er ja o © o o w

i \

u ■H-ö

(

^§ a u o o

O fci 3> g P« O

\

«!

•-

A C3 \ P< M

n I J o to «j » ^

Ch

eck

A

ddre

IT

■ö 4 • J c '*

IK ) o o »—

Gx U M

0) Al o S

+->

■Ü

'5

o o e u o

a-

o

a) U

El

29

~*~~

A15 Text: Each formatted comnand (.11) that has survived the Gen-

eral Validity Checks without error must go through a series of

Command Validity Checks as controlled by the specific command

(Cl) that is input to the simulator. First it is determined if

a CPU address error exists (1). If such an error exists, that

error is saved for future use. If there is no CPU address error

(101), the command sequence is checked in activity (2), ^nd any

sequencing errors (201) that may arise are saved in a like manner

as the address error. Check Command Timing (5) works in a Bimu-

lar manner as (2) and is added for completenest», A timing error

will result in the same error code as a sequence error. If this

module is implemented, the sequence error and the timing error

should be assigned a different error message so the user can dis-

tinguish between the two when they occur.

30

L 51

k? Toxt: A etatut5 modificj tion (Cl") results from a ueer comBand

Input. Doterralne Typ«- of Modlficatlon Roqulred (1) analyzes it,

or a valid command (C?) that, may havo boon transmit tod, to nee»

what Itind of update requeat (101) is necoceary. After that de-

termination has been made, Iorlorm Update (2) io activated and

the Qtatuü Information iß paened tv-1 thu output modules.

32

(0 o

3 a1

•p a>

♦»

U)

a> 3 a ^

r

■p 0) CO -P 0)

-(Ö pi x) a* Pi at

t=> a

to s « to

ro

-p <D CO P 0)

T3 a« ft 0)

to K

fM

§ T3 at S (D O

p

-

o •H p <M a> (0

<D •H bU 0) 0 o § 3 CO a) o* a QtXi ID MCO ü a

t\l

-1)

a> o

33

A21 Text: lesuo Specific Change Request (1) utilizes tho status

modification (Cl) that is boing performed as a constraint which

detormince whether there should be a request made or not. When

a valid command has boon transmitted, the command data is read

from it by (2) and the appropriato chanfe roquest is passed to

(3). With either request, (3C1) or (3C2), as the deterraininj

factor, a particular update request (01) is then issued.

H

■

M O

■zz— <$

u »' (0 0) a»

EH O

a»

51?

a> (Q •»J 0)

T3 or* P. 0)

u

^

0) H X) ^3 0) CO Ö -P 3

(ü -o to

«i! n to

l ^\ x o to

m bü a> ;' rt i..'

(0 (0 00 -P 0) Ä to 2: o

<\J

CO IS

a) m bo « 3 <ö d +> (0 tö CO 10 Ä -(-» 0) Ü CO S

- >, (4 p

a) a> CO so a o Ö 0) 3 «Ö H H -: .p ^

O H !>

3

O

a»

a? ■9 t -

s O

o

r*^

35

,_—*«„*«

A22 Text: An update request that is issued as a result of either

a user command or a valid spacecraft command, can require telem-

etry value changes to be made (1), status message changes to be

made (2), or both. The changes that aro made are assembled to

form a list of current statue data (01) to be used to create an

informative output as a final product of the simulator.

36

K\

0) a o

■H 0) (0 B U r-i to f-l 0) U tf <D P^-H (0 +> o A ta «n (4 a> o O Ck > s

v r

m u a) d P« <D >» pj

En a4 to (D U

■P CO o 10 f. ■H *-< fc iJ o w

o o ^

■H »H M W •H Ü <D (1) o Pi a to <D

a1

a; 03

U)

> O 0

e a

ü

0

| El

cr-r

_ n 0) 4J P* a)

^gco O tl

p Pn o (0 u •H V« tn H3 OM

XI 0

37

A3 Text: An invalid command (Cl) can be the result of a parity

error, a wordlengtli error, or some type of command sequencing

error. List Types of Format Errors (1) extracts errors listed

as a result of the general validity checks performed earlier.

The specific format errors (101)' which are output are used

to aid in determination of the proper CV words (01) to be pass-

ed. The other constraining factors are the specific sequence

errors (3C1), and the valid command (C3) when there are no errors.

Almost all of the spacecraft commands require a command verifi-

cation (CV) message, whether they be valid or invalid.

38

■^

o

CQ

U o u u

ü -P <D «Ö ft a

to u o

+> o •H U

hü U Ö o 0) ^

u w Cl

EC

3

f^

0)

^2 4-> co B tti h © B O CQ tH f-i ttl (^ fH <! fe W

c

id o

«\J

►-1 & w

■P ts ■P -H O 03 ^ ti

.-q OH W

O

0) Ö o

ra o u

i u o

ft,

tu 0) p.

17 -p

ITs

B

g El

39

A31 Text; A parity error (101) and/or a wordlength error (201)

is listed by Assemble Format Errors (3), The specific format

errors (01) tnat are ouput are used to create the proper command

verification words that will be placod in the simulated downlink.

This node presents a decomposition that is almost down to

the coding level. Even though a small amount of new information

is introduced, it is included to enhance the clarity of the par-

ent node (A3)•

kO

"■"»»■"SäliPB

O

i

'^^^

H > B^ Iß O

ß

■ a a o u o o c h u w SJ o ®

M \,

r

o c (D 3

B C »H O vi' fc. ü tO W

c (0

o

U 0) •H t>

T-< a> b U 9 O O er ^

to w w

0) a o ^ c

a> « (-1 0 3 0

to w

i B

o

a» ü 0 9 O 3 ^

© M CD C0

K>

O »4 3 TJ

t0 E B

*» O

<\j

«8 ü rj

o o B U O U s: w ♦* n c «t •H O

Ä

fi

>■>

.' M

u!

5) O d

a> to

p.

r—

8

&

41

wi*m*mm^mmmm.

.

A3^ Text; An Invalid commadn (C1) is generated due to a command

sequencing problem. List Memory load Errors (1) is activated if

the invalid command is an erroneous memory load command. A distinc-

tion is made between secure commands and non-secure commands by

activity blocks (2) and (3)» These two types of commands generate

their own set of command verification (CV) codes as a result of

errors. The various sequencing errors that occur during a command

process are assembled in (4) and the specific sequence errors (^-01)

are used to determine the proper vehicle message codes required to

generate the CV words.

42

mmmm mmm

<r>'

13

> CJ)

o •H

o s o O I* t-4 Pi o <-. to h M

u « •H O •H C Ü1 •H O (4 O 3 O O O1 (4 P* a> (-. W CO w

\ u

\^§^ O B O O B U P< O to Ü

« OS

•H J-

(S Vi OD B -H X» B (H (4 O «) O

Ü Ü > *

o e o •p -H Ta

(4 -H CO O u B C 0) B a> p< o o to o

o

43

.—_-_ . Ü

-■-- -.■WWI^.^WUIJ-* ■ IWiwlF^'

A33 Text: The specific errors, (C1) and (C2), that are generated

by sin invalid command, are used to control the generation of the

applicable error codes in activitios (1) and (2). If a valid com-

mand (C3) is processed, Generate Specific Command Code (3) is acti-

vated to provide the required code for Generate Command Verifica-

tion Words (if). All of the codes generated contribute to the crea-

tion of the appropriate CV words (MDI).

hk

a 3 bOV P. cö \

-P a

o ©

i"

M

o

■rl 60

I B U

§ 4 ca

o (D a> i o > s: , \

\,

a>

(0 O CO 4J CC CO (0

m a) -H «;

i\J

t>0 a a> a 3 «»0-rt

■P Ö -P (ä cd u P Ä -H to o ^)

P c 0)

u O

o ca % / V p CO

7

- 0) p (0 «d xi H h <0 o § SC

h > E-t ü

a)

> ^ o o-

o T-l P

TO O

•rH Vl •H

o

4 3(

X) a

M O

ca

+->

Pi

=3 o

45

.4 lmmmjmm^J>^m^mifT-rl^^Mi ^^±imm^m^mm^mMmmu^.^^j^j^^Wimmfi1,v> ™mm

A4 Text: CV words (11) are input to Translate CV Words (1) in

a 16 bit hexidociraal code. The words are translated, and the

CV mossage (101) that results is determined by the currert sta-

tus (C1), and the valid command that may bo present (C3). The

status modification (C2) inputs to 1'roduce Status Change listing

(2) and, under control of the current status, a list of status

changes (201) is produced. These status changes, combinad with

the CV message, aid in producing a meaningful output message (01)

k6

«w»^ -J-JJ.IJ, ...l^-XI^J-l^-rf -l..,iJL^ij«^mij.|^y|iw^HiiJu^upiiJji^^

Data t To del

Again, as with the activity model, it Is recommended that

the following "node index" be scanned for an overview of the de-

comnosition.

Node

D-0

DO

D1

Dll

D12

D13

Dli^

D15

D2

D3

Title

Simulator Data

Simulator Data

Input V/ords

Spacecraft uplink Word

Format Errors

Status flodification Word

Formatted Spacecraft Command

Sequence Errors

Current Status Data

Vehicle Message Data

Output Messages

Page

^8

50

52

54

56

58

60

62

6L

66

68

^7

,.P.,.IP„ iLw^un»! jMpjp.iMiiijiwfm ■mm mmijimmpmmm < Mpp-5"

48

wm^mmmiiiMmm'.nim' 'M ''l«***»!-!! pi!fl(PPl^-UiJ^ii!l.l»«(^ppg|^p^^lM_4»**»4WJJ«WllJ«tl«.1

D-0 Text: The Input activity that creates or modifios the Simulator

Data is the loading of the input word (II). What is done as a result

of the input word is constrained by the determination of the type

of input word loaded (Cl), the type of error (parity, wordlength,

or sequence) that exists (C2), and the type of spacecraft command

that is transmitted (C3). Any input that is loaded results in the

printing of an output message (01) for user information.

k9

mifmmmmmmmmmmmmmBmilmt*' wmmmmmfm ^i

r J? id

-M U)

a

>

CO U)

U

•H U

♦»art

M 3 © a^ o s

s

a a t; ® o o o o

°A

s

> « <D

■P bO y cö P, (Q

+> CO 3 © OS

V * 7 H i.

ro

© ai H tul O w id

■H a +' ,c| tu 0( © © * > > £

OJ

■P a <Q © y »H 4-> CO (H CÖ 4J 3 -P CO O t/3 Ö

nt

H 0)

o

o y ■P Ot P< © >, fl O E-t H

p

o

50

DO Text; An input word is loaded (11) which iß either in the

.form of a user command or a spacecraft command. The Input '.VordB

(1) that are created are then used by one of three possible act-

ivities. The activity that uses the Input Word is constrained

by the type of input word (Cl), type of error (C2) that may e/~

iot, and type of cominand (C5) that aay be present.

If the input word is a user command, some type of status

modification or vehicle information update wil^ be performed (101)

This results in either the creation of some Current Statur Data

(2), or a change to some data that already exists. If a space-

craft command it input, either an invalid or a valid command will

affect the Current Status Data.

The valid or invalid command process determines what type

of vehicle message will be delivered (301). The Vehicle Message

Data (3) is shown without an input process to create it. This

data will have been created as an external function and will re-

side in the simulator for access. The data consists of command

verification and error codes that will never be altered as a

function of the simulator.

The status changes and vehicle messages created during the

command process are assembled as Output Messages (4) and used to

print output messages (01).

51

m

52

DI Text; If tue input word (11) iß a spacecraft command the Space-

craft Uplink Word (1) is created. If it is a user command a Status

Modification Word (3) is created. The Status Modification Word

is used to perform the particular status modification (501). The

Spacecraft Uplink Word (1) is delivered in the required format to

create a Formatted Spacecraft Command (/*) and Format Errors (2) if

they exist. The Formatted Spacecraft Command is used to process

the invalid command (402) or it is delivered as a specific command

which generates Sequence Errors (5). Sequence Errors are fed back

to the Formatted Spacecraft Command (4) and used to process the

invalid command.

?3

wtmmmm^mm .-**-• 3

hü

5%

'

DTI Text; An input word will either create an Uplink Data Word

(1) or an Uplink Command Word (2). Whichever of the two is cre-

ated, it must be placed in the proper format and wordlength to

be used by the simulator. After the Formatted Commands (3) are

created they are delivered for further processing (01).

55

. ii

« ö U o o

o- <u (^ > w •H H

* o

OJ

ja +> 60 Ö 0) CO H U XJ O u u 0 ^ & w

u 0) (0 > u •H O H ^

CD

' O (4

■p

g : o

51

0) •ö o

S5

' 56

w* NH ~— mmmm

DI2 Text; When processing the formatted command (11), parity and

wordlength are checked. The occurrence of either or both types

of errors results in the creation of Parity (1) »nd/or Wordlength

Krrors(2). These errors are then used to create the Error Data (3),

?7

o 3 0

■P O « -H *» 4* CO Ö

o tH ^« O -H Vi -O u o

o

o o

CO o •H

• P^-ö ßs

» « Ö -P ia (4 a e M

■P ®i^ «\o

\ ö — \ o N •H \ 4* \ (It

O -P 10 -H CO O ^ ^ S ^t ® P -H 3 a» -ö C POO üj S«

o

CD

P

id +-■ CO

3 OJ

p 3 »_- Ö-Ö H U

O -XJ B: « o *1

«5

o

53

.

PfHtilw^MiiHijlipiipM W-MW M MilWIMH^pipiillilpi

Dil_Text: After it has been determined by (C1) that the input

word (II) is a user command, a Status MüdifiCc,tion Request (1)

±s created. This request is then processed to determine the par-

ticular modification required, and the Modification Information

(2) is created to be used to perform the modification (01).

It should be noted at this time that much of the software

required to perform the modifications or updates to the simula-

tor may already exist. The node is included as a reminder that

the function must be incorporated in the simulation.

59

A^ « XJ o « 3 m_-—i__—

o i ) b ^ 13 i

o fi o o i » (0 ^ ^ > -H 03

&5 , w w rr 0) P, o

•o

y S O CO O ^ i

•H -* •3 u ► ■H TJ fl TJ

■H 0 ' M C a

Q E 0) Q o (0 ET —■-- P« O

■H • o ^— 1 CO O 1

O Ü ri O T»

o u a* > •a p. Q /

W Ec O s «4 D

J « E

« }•■ •H t3 E > 9 O fr, O

1Ü ffl 0) o o

T3 K\ 9 Tl ■*J o to • -•■»

q-< a m «5 +» *-( \ 9 ^ -^ a -ö rt

\ •3 ID 0) 01 > Ö o

\ H «B ^\ ■rl E 0)

\ , P4 U A ..-) E o

O T3 O ^\ S O P« Ü -<

I \ i o o

CQ

1 il i 1 » ■p

4 s&~ E

f \ o

t \

1^

<^ a> », e o

•

. r 0)

1 P.T) •H Ü

^S 4 H

1 • i fl o T Ü

o .o

1 « O H -P | (■ ̂ PC o <d

A I t \

i| T. « ■P

\ 4J -t K\ L , as o w CQ

|^ o

<VJ . .^. 0) t< f*. U It rj o

g ■ •o TJ o

"• 1 m ^^ «< as o B5 u k| \ ► o

•M A ■H »« o WT »-I « fl1 «0 Q)\-l-> CO 1 -0)

-• A v< d o -H a o ' r-l O* IH rl U UI .—"'— 0 0) u a» C Q w M A »x W ^r

60

D\k Text: The formatted conmand (II) is made up of an Address

Word (1) and a Data Word (2), The specific content of these

words is determined by Cl, C2, and C3. Many different things

could be the cause of a particular command to be complimented.

The complimenting is dependent upon the type of command word pre-

sent, and on the existance of some kind of error in that command.

It is also dependent upon any combination of the two circumstances.

The same constraints apply to the comp]imenting of the Data Word

(2). The Complimented Command (3) created by both the address

word and the data word is used to further process the invalid

command (301). By knowing a priori which commands are to be com-

plimented and which commands are not to be complimented, a means

of detecting commanding errors is provided. The Specific Command

(4) is made up of a good address word and a good data word. It

must be processed (^01) to determine if any sequence errors exist.

61

V o « <D a 0 CO 0) ^ (0 O

U u u ►

N>

o -a o 0 f. ^ ti 0) o E! ^1 ^ U a' t. O a> M O «J

O TJ

cfl

o

ai (0 0) <■•< O H O Ü b 0)

U3

i a> -o o

be

IL ________ -adiaH

D13 Text; After a command is found to have no pari ty or wox'dlength

errors, it must be checked for proper sequencing. If a sequence

problem is detected, either a Memory Load Error (1), a Secure Com-

mand Error (2), or a Command Sequence Error (3) is produced. When

these errors are created, they are delivered (301) back to the pre-

vious node (D14) for further processing. When a command is received

that has no sequence problem, an Error-Free Command (k) is created

and used to process the valid command (/f02).

63

r

<\J

n « 00 H CO ö O S -H

■H -P -P -a cö u) © -P -H > to ^

p © a

©

a

•H r-i O CSS 04 >

p «s

CO

o

u 0) 04

o ■H

•^^

X) ■H f-j

>9 to e a i © o o Ü o u a*

04

0)

o 2;

cö P

p

P CO

P

Ü

00

6k

*

■

D2 Text: Telemetry Point Values (1) are the main source of sta-

tus information. A valid command (12) must be processed to de-

termine which telemetry indications are affected by its execution.

Once the telemetry changes are performed (101), they are used

in the update of the Vehicle Status Listings (2). The status

changes (201) are then used to aid in compilation of the output

messages. Performance of status modifications (H) requires the

same data processes as above.

65

a: (D

CO CO

SB

H 03 Ü

>

o

\.

1— 1 1

CO © 60

(H a O CO f-t CO Li <D W S

o

•Ö o (0 CO

§ «C H -H CO S (H CO 0 0)0 OS.

o

CO -p

o

CO

m

O

>

CO

66

D3 Text; The processing of a valid or an invalid conrr.and causes

the delivery of a command verification (CV) message (101). These

messages are derived from a file of CV codes that are available

for access during simulator use. The invalid command also ac-

cesses error codes that are on file for creation of proper Error

Messages (2), These vehicle messages are passed on be assembled

into a meaningful output message.

67

■ o

•P «0 •P 3 05 C ft £Q ■H -P O

ft o s:

o ii

K>

o MP as € 1 a -H (0 ^q o £

7^

(\J o

o a> H 60 o as ^1 w X co e a> >s

00 o a> 3 60 •P C (0 «s P Ä CO O

3 •P (Q a

■p o «} «o

u as • JS >o

5 T3 O

»u

to 0) bO £0 a a £

ft 4-1

o

B

68

-

iimU-,,. II--*1WM»MIJ|I1J.J)^^

Dk Text; Status Changes (1) and Vehicle Messages (2) are created

as a result of spacecraft command or user command processing. A

Message List (3) is created which is comprised of all the user or

vehicle generated changes that have occurred as a result of a com-

mand. This Message List is printed (01) for use by the system op-

erator.

69

W|!)»*»iW,J-. «i*»^^ «lMWW;«»*M4i!HPiW«W^^

Summary

After a brief introduction and explanation of eome diagram

syntax, this chapter presents the activity and data models of the

simulator. They are given as a complete functional specification

of the software. None of the box titles or arrow labels are bind-

ing, however, and in the design refinement of the next chapter some

names and labels are changed to better meet the software engineer-

ing goal of understandability.

70

L-ULJ,-_L.I«ail!l,4l...J1,a-. |^^B^■i^Ps^^^■W■^^Bpwpi■P«IW«^iPlp■^Wl■i^^^m!^■- ■■■5^i^aii»M^Bi«B^»Pfi*i!piB«!^WlBillWW^^a*iia«lPn(!ipp^

IV. Design Refinement

Introduction

In the previous chapter, a top-down design strategy is used

to create activity and data models which Identify a basic design

structure. To better prepare the design for easy implementation,

a structure is needed which reveals the relative "goodness" of the

design. This goodness is measured by observing the following at-

tributes: (1) coupling, (2) cohesion, (3) span of control, and (4)

scope-of-effect/scope-of-control (Ref 10:340). If two modules are

totally independent of each other, and one can function completely

without the other, then they are loosely coupled, or uncoupled.

Loosely coupled modules are more maintainable than tightly coupled

modules. Low cohesion occurs when an isolated module has Internal

elements that are loosely related. Coheslveness and coupling are

interrelated. The greater the coheslveness of individual modules,

the lower the coupling between any pair of modules will be (Ref

10:144), Excessive span of control is bad because it indicates

too much decomposition of a module into subordinates. This is

caused by a failure to Identify intermediate levels of abstraction.

Finally, scope-of-effect/scope-of-control should be examined to

get a measure of how well the system has adhered to the subordinate

structure required of any decision process: all modules that are

affected by a decision (scope of effect) should be subordinate to

(scope of control) the module which makes the decision (Ref 10:240).

To recognizJ and isolate the existence of these effects, and then

to eliminate them with a design refinement, a technique is employed

71

;' "ll"UM»l illiMIHl llllli 11,11 iJLilillMI

which is baeed on a top-down, structured design strategy called

"transform analysis." This strategy should lead to system struc-

tures which are fully factored and ready to code (Ref 10:25i+),

Transform analysis produces a "structure chart" which reveals

design goodness measures. The structure chart contains modules

arranged top-down and left-right which represent the processing

functions of the system. The first step is the restatement of the

problem as a data flow graph or "bubble chart," The basic elements

in a bubble chart are called "transforms" which are represented

by circles labeled with short descriptions of the trajisformation.

Interconnections between transforms are labeled arrows which rep-

resent "data elements" to be transformed. Two or more data elements

required simultaneously by a transform are indicated with an aster-

isk ("*") between the data elements. The "ring-sum" operator (M®")

is used to denote exclusive-OR relationships between data elements.

Bubbles and arrows are drawn which represent input branches and

output branches. These branches are connected by bubbles that are

the "central" transforms of the system. The second step is to iden-

tify "afferent" and "efferent" data elements. An afferent data

element is an input to a central transform and an efferent data

element is an output from a central transform. The third step is

top-level factoring. A "main" module is specified and it is decom-

posed into afferent, efferent and central modules. The fourth step

is the decomposition of the afferent, efferent and central modules.

The top-level modules and their subordinates form the "first cut

structure chart." Finally, the first cut structure chart is exam-

ined for goodness and revisions are mads to produce the final struc-

72 i

«wppwuiwi|j«*uuini,jiii

ture chart (Ref 10: Chap. 10).

After the preliminary deeign is complete the first cut struc-

ture chart is drawn from the activity model, bypassing the creation

of a bubble chart. This decision is based on the conceptual resem-

blance of the activity model to the bubble chart in that both tie

activities together with data elements. Reference 3 explains a

method of design which creates an "intermediate" bubble chart fro^

the first cut structure chart. Iterations of bubble-to-structure-

chart and structure-to-bubble-chart transformations are made to

further refine the design. This iterative process advocates start-

ing with a structu chart and then creating the bubble chart for

the transform analysis.

In the remaining sections of this chapter, nhe first cut struc-

ture chart is constructed as a direct translation (input for input,

output for output) from the activity model in Chapter III. The

afferent and efferent data branches are identified to aid in con-

struction of the intermediate bubble chart. Finally, a "refined"

structure chart is constructed and examined to determine the rel-

ative goodness of the design.

First Cut Structure Chart

Figures 30a, 30b, 30c and 30d illustrate a direct translation

of the activity model of Chapter III to a structure chart. Deci-

sions and loops are not identified at this time; they are included

in the refined structure che~ :■ derived later. The number to the

left of each arrow identifies the input and output parameters listed

in Table I. Controls are not indicated in this list because they

73

w mmmmmmm

*1 u]

^

D

C »3

Uli ' J li w

t) t.) t/> ^

..1 10

M 41

• r3 £ J3 O, V O I) 4

V4 01 ** <>

L-^

1^ C r 4 U O tt» .3 nil ^ o > u

—sv

IL. «. « i. o «> .' I, p.

lÄÜfr

>*

-*■ S ') o u.

4*

>. n O i. II 1. ♦> o o o

l-\

AJ O

•^ i« .-« P, ^ *> 01 ».) »,> IX Oi H J*

4>

[,]

0)

3 ■i >

u a f.

-p 0)

Si

a H

7^

O +» V4 a)

<0 Pi

-(B" H -0 ^3 <D ta ß -P ^ o rt 4J w -ö a5 CO PtV

««! t=> W

+> O

ft 0) o >

P

4'

CO

0) © (0 to

-p a (Ü o o

u Ä >> «0 •v.) u 0) y; a) 4' a 3 r 1 OJ rj

.<■: o OS o I' Jjl

-P a >i> a

0) ;■« • ^ >p ^ *' aj (Q flj -U i r"

ta t' ri u. | MM tD K |

to

■p aS *J tu

© H o

a)

I

■u ^ 3 id

■Ö § -p cd i fl5 0) o a

L.inv 1 —-

p V( a< CQ

©•H bO 0) pio s ^ (0a> o1

COrt^ 0) »HC/J Ü «

75 I

a> a)

>, 0' l'^ . .•

*J O (0 "O « (^ <D O ö A, s: o

a> Cl ■M ■H -0 (Ö «M

B u -,< to 0) Ü H T3 v; S) ti O 0) a O t 1

LilW O

0) O

U o a> S-{ o

LO ^ H P j "IP a1

! (Ö Ö ^ 0 b (D S o © A (.v ►H -O a- B u o

1 Oü} W Ü |

^ -* 9 ^ -$

(0 U (0 cl Pt 0)

H a« u -T?S

-d- © »^

■p to o a> u h~~"———

^ oä Al

^S a a> -P ft a

1? M a o u ON

+» fN O NS a »■«

S^Ö 'S.

■■»

H f* -P B m M * i O -P n ^. '< U]

5 P«. M i-l

^1 P O

1 W tn p K w: o tu (•. ID u •H O i * u ^

w

c rH tS

9 > a f.

0) O p ai f* u to v> u TH -< o w ^

%< u w

(0

*' :•' t [ o ■ U ; | ^ »1 a- V1 u i-^ W O M

£• u ■f' O Tl o a B (0 u TH © o u ►J S ^1 w

(0

o a»

(0

o

o Q

M

5 ...

76

mm.

\

17\

-

Create Output Messages

/

15/ 16

\

Translate CV

Words

Produce Status Change Listin«

Assemble Message List

Figure 30d, Create Output Messages

are not considered when creating a bubble chart for transform anal-

ysis. However, a control element in an activity module may be ueed

ae an input element in a bubble chart.

Intermediate Bubble Chart (Data Flow Graph)

The bubble chart transforms "conceptual inputs" into "concep-

tual outputs," which implies that the detail in the structure chart

may be higher than in the bubble chart (Ref 3: Chap. 2, p. 251.

A scan of the parsuneters in Table I shows some repeated input and

output names that may have to be altered to clarify the data flow.

If there are any errors in the structure chart, they should be cor-

rected while drawing the bubble chart. Looking at the top level

in Figure 30a, the afferent data branch is recognized as that branch

which consists of the subordinates of the Process Input Word module.

77

wmmmmmmmm mmm ppHJUUJUlllil mm

Table I

First Cut Structure Chart Parameters

Input Output

1 Input Word 2 . 3 k CV Words 5 Input Word 6 Input Word 7 Formatted Cmd 8 Formatted Cmd 9 Formatted Cmd 10 11 12 13 }k

15 CV Words 16 Status Mod 17 — 18 User Cmd 19 S/C Uplink Cmd 20 21 Input Word 22 Input Word 23 2if Formatted Cmd 25 Formatted Cmd

27 28 Formatted Cmd 29 Formatted Cmd 30 Formatted Cmd 31 Formatted Cmd 32 33 3k

36 37

39 kO lf1 42

45 -—

47

Status Mod, Invalid Cmd, Valid Cmd Current Status CV Words Output Messages Status Mod, S/C Cmd Formatted Cmd Format Error Invalid Cmd, Specific Cmd Invalid Cmd, Valid Cmd Update Request Current Status Specific Format Errors Specific Sequence Errors CV Words Command Verification Message Status update Message Output Messages Status Mod Request S/C Cmd Status Mod S/C Data S/C Address Formatted Cmd Wordlength Error Parity Error Format Error Erroneous Cmd, Error-Free Cmd Command Words Address Error Sequence Error Command words User Status Change Request Commanded Status Change Request Update Request Telemetry Changes Status Message Changes Current Status Parity Error Wordlength Error Specific Format Errors Memory Load Errors Secure Command Error Command Sequence Errors Specific Sequence Errors Sequence Error Code Format Error Code Specific Command Code CV Words

MiMMHi

78

Jn Figure 30d, the efferent data branch consists of the subordinates

of Create output Messages. This leaves Update Vehicle Status and

Create CV Words as the central transforms. The afferent data branch,

which identifies the major input data flow to the central transforms,

is the first to be drawn in the bubble chart. Following that branch

down to its lowest level, the first input parameter seen is a "User

Cmd." It is the input to Read Status Mod Word and the output is

a "Status Mod Request." This identifies the input, first bubble,

and output in this portion of the bubble chart. To locate the next

bubble, the module which uses "Status Mod Request" as an input must

be found. It cannot be located as an input in Table I, but it may

be a control element in the activity model. Looking back to Fig-

ure 6, which is the activity node that contains the modules of in-

terest, "Status Mod Request" is a control on Perform Status Mod.

"Status Mod Request" is used as an input to the next bubble, which

is Perform Status Mod. The output of Perform Status Mod is shown

in the activity model as "Status Mod." Looking in Table I "Status

Mod" is found as an input to Produce Status Change listing which

is in tho efferent branch. The activity model is examined to see

if "Status Mod" is used for control in any intermediate activities

and it is found as a control input to Update Vehicle Status which

is a central transform. Continuing this process, the bubble chart

in Figure 31 is constructed. The completed bubble chart is now

reviewed to ensure that it accurately represents the processing

illustrated in the structure chart (Ref 3: Chap. 2, p. 28), then

the refined structure chart is drawn and analyzed.

79

a o

rH

n

^> Ö

■H ■O 09 H

0)

a

■

.

80 ^

m^HMiwniNiw mi.immwmmvmvmiMm^ i. mmm^mmmmmm*

Refined Structure Chart

luput and output arrows have been included on the structure

charts In Figures 32, 33, 34, 35, 36 and 37 to enhance the clarity

of each diagram. A dot at the end of the arrow indicates a control

element, while a circle indicates a piece of data being passed be-

tween modules. The charts are presented in a top-down, left-right

structure starting with the "main" or top-1 ^l modulo and each

of its subordinates. Then each of those subordinates is decomposed

and analyzed as independent sections of each branch. Accompanying

each chart is a parameter list which adds to the understandability.

The main module in Figure 32 identifies the afferent data branches

by showing only inputs to the main moduJ -. The efferent branch

has only outputs from the main module and the central transforms

have data going in both directions. The following is a brief de-

scription of each module and the interconnections with its subor-

dinate modules. At each level any decisions or loops that may oc-

cur will be explained and Justified if necessary,

SIMULATE SPACCRFT. This is the main, or executive module.

Its function is to control and coordinate the afferent, transform,

and efferent modules dealing with the highest level data of the

system. All of these subordinate modules are in the executive's

scope of control. When the executive is invoked it will load the

top-level afferent modules and output a "ready" message response

yrhen that loading is complete. This is a signal to the user that

the simulator is ready to accept user command or spacecraft command

inputs,

GET STATMOD. Loose coupling exists between this module (Fig-

81

^ mum ppnp

H EH

K Ü

Hi fc

Ü CO

o ^ K P P^ o

03 CO CO O

o o O 5S K > P^ ü

EH !

K^ - M CO Ö w o w s >

Q (Q s: h o <D

-P rv 0)

H E

£ ä a.

ri

O

o

n5

-a o

CD 3

02

0) P-

£ -o -0 s d

a u i; H i 0 0 u u

O T3

y a a

® o O Ü

■H

t)

Ü

o u

o

w

a (^ o

o 3

d +> CO

■P d o IH

3

(0 T3 fH o

>

-p

CM d

<D p

o o

o ■H

O ■H

•H ■O O

'J} 3

+-> «d

-M «0

ti

o o

>

■d

o o

•H g >

I H o o

■u •H

-P cd -u CO

-p d 0)

o

o o

-o

H cd

•• o CO T) t( CO O 3

Bt +» to

> -p

d •p u 3

■P

o

a)

3 to

.- <\1 K> -3- ITN VO C^-

82

GET STATMOD

GENERATE ISTATMODREQ

PERFORM STATMOD

INPUT USERCMD

SETUP STATMODWRD

Parameters

Input Output

9 Status Modification Request

20

21 User Commarid

Status Modification Request

Status Modification

User Command

Status Modification Word

Figure 33. STATMOD Module and Subordinates

ure 33) and the executive. This allows the exclusion of the module

from the simulator without affecting the performance of the rest

of the system. The module is designed to perform functions such

as adding entries to existing status and telemetry tables, delet-

ing those entries, or changing them. These are functions that could

85

wm^mg^m$immmm®mmm.rmmi!ff,.

be performed externally if the operating system had an editing rou-

tine,, If the option to use this module as part of the simulator

is taken, a means of distinguishing between user and spacecraft

commands should be devised. One way to do this is to prefix each

user command with some identifying character,

upon receipt of a "User Command" from INPUT USERCMD, GENERATE

STATMODREQ controls its acceptance and the subsequent "set-up" nec-

essary to pass the request to the PERFORM STATMOD module where the

request is translated and the proper modification is performed.

The "Status Modification" is then used as constraint data for other

processes. INPUT USERCMD and SETUP STATMODWRD may be "dummy" modules

whose implementation is so trivial that they may be compressed into

their superordinate (Ref 10:3^)» Dummy modules are a common prod-

uct of a top-down design. Although dummy modules rarely degrade

system performance, they should be reconsidered before implementa-

tion.

Spacecraft Coamand Afferent Branch. This afferent data branch

performs the major task, of the simulator: spacecraft command proc-

essing. To enhance its description, the entire branch is drawn in

Figure 3k» The left-right construct convention has been violated

in some places to avoid crossing arrows. The parameter list in

Table II should be referenced while reading the following descrip-

tion.

The diamonds in the diagram represent decision processes.

The presence of a decision requires examination of the scope-of-

effect/scope-of-control attributes discussed earlier. GET VALCMD

has PERFORM CMDVALCKS and ACCEPT SPECCMD in its scope of control.

&h

wm^mm^mm^smmi^miimmmmim^^mmmmmi^^iimw^' ^pfwwpüPifi »HJwpjiJ

I GET

SEQERRCMD GET

VALCMD GET

FMTERRCMD

ACCEPT SPECCMD

PERFORM CMDVALCKS

GET GOODCMD

DETERMINE TYPECMD

GET FMTUPTODS

PERFORM GENVALCKS

GET UPWRDS

FORMAT UPWRDS

GET ERRCMD

Figure 3^» Spacecraft Command Afferent Branch

A "Specific Command" must be accepted by GET VALCMD and the command

validity checks (sequence checks, timing checks) must be performed

by PERFORM CMDVALCKS before a "Sequence Error" can be detected.

Since PERFORM CMDVALCKS determines the existence of a "Sequence

85

..

^m^mmmmmiv iu.^iivmimmmm^Aymmm»wlm^mxK . .i...w*vm*

Table II

Spacecraft Command Afferent Branch Parameters

Input Output

10 Sequence Error, Specific Command 11 Sequence Error Specific Command, Command Type 12 Specific Command Sequence Error 2.2. Good Command 23 Good Command Specific Command, Command Type 2^ Erroneous Command Format Error Command 25 Erroneous Command k? Formatted Uplink Words if8 Formatted uplink Words Good Command 49 Erroneous Command 50 Uplink Command 51 uplink Command Formatted Uplink Words

Error," it is the only module within the scope of effect of GET

VALCMD, The next decision process takes place in the GET GOOBCKD

module. Its scope of control includes GET FMTUPWRDS and PERFORM

GENVALCKS. PERFORM GENVALCKS is in the scope of effect of GET

GOODCMD, No other module is effected by the process. Control

coupling exists between GET VALCMD and GET SEQERRCMD because a se-

quence error, if one exists, is passed throvgh GET VALCMD to GET

SEQERRCMD before the "Sequence Error Command" can be transmitted

up to the executive. This coupling could reduce maintainability

and should be examined before implementation to see if it can be

eliminated. This entire afferent branch is the most complex of

the whole simulator. However, the loose coupling between modules

resulting from the design methodology yields a structure that is

relatively easy to implement. The relationship between coupling

and cohesion implies that the loose coupling produces high cohesion

in each module which is a desired attribute, A brief explanation

of the spacecraft command processing follows.

86

MM!

An "Uplink Command" is received by GET ÜPWRDS and the FORMAT

ÜPWRDS module does necessary formatting of the uplink, command words.

GET GOODCMD accepts these "Formatted uplink Words" and passes them

to the PERFORM GENVALCKS module where they are checked for parity

and wordlength. If either one of those errors exists the "Errone-

ous Command" is received by the GET FMTERRCMD module and passed

to DETERMINE TYPECMD where the type of command is determined. The

command with the format error is then passed to the executive for

further processing. If, after the general validity checks are per-

formed, no errors are found, the "Good Command" is passed to the

control of the GET VALCML module and held for sequence checking.

The sequence checks are performed after the specific command type

is determined. If a sequencing error occurs, control is passed to

the GET SEQERRCMD module where the "Erroneous Command" is passed

upward to the executive. Erroneous commands are used to generate

the appropriate command verification message and output message

which gives the user a description of the errors, but they do not

affect the performance of any other modules.

MODIFY VEHSTAT. The scope-of-effect/scope-of-control is more

obvious in this module than it was in the afferent branch. Figure

35 and Table III should be referred to while reading the explana-

tion of the functions performed.

If READ CMDDATA receives a "Valid Command," the "Command Data"

portion of the command is read and a "Status Modification Request"

is generated. The "Status Modification Request" is then passed as

control data to PERFORM MODIFICATION. The loop indicates the pos-

ibility of multiple telemetry changes and status message changes

87

M 3 fj a «! S EH H CO w o to o 4 s

CO H co O tt to £ 3 F K «! o Ü EH ro CO

CO

w 3 1 D

-4 hj UM

EH

H EHC^ «s! W X S | B a Ü w a C!3 U

cy ■ H « EH O <JO H 1 B EH 11 a w

to o -p rf d •H

o ^>

co

O H

I o i EH

E-i CO m B >

•

« »H

60

88

Table III

VEHSTAT Parameters

Input Output

13 Valid Command, Command Type Status Modification Hequest 14 Status Modification Request, Current Status

ChanpjQ Requost 26 Valid Command Command Data 2? Command Data Status Modification Request 28 Status Modification Chanfio Heguoi-it 29 Change E^oquest hodlfiod Status 30 Status Müüification Roqgest Modified Status 31 Modified Status Current Status

.

required by one command. The status modifications generated by

a valid spacecraft command are assembled and the "Current Status"

18 relayed to the PRODUCE OUTNESS module and a explanatory message

is produced. A modification request could also result from a "User

Command," in which case the "Status Modification" is used to gener-

ate a "Change Request." The portion of the module which consists

of GENERATE CHGREQ can be omitted if an edit routine is used for

"User Command" processing.

PROCESS CVWORDS. Command verification (CV) codes exist for

most commands. The subordinates of PROCESS CVWORDS creates appro-

priate "CV Words" that are used to produce output messages (see

Figure 36 and Table IV). The transform analysis has revealed a

possible weakness in the design of this portion of the simulator.

This weakness is indicated by the "pancake" structure that has

occurred. "Pancaking" is & common phenomenon that results from

a top-down design. It usually indicates a lack of sufficient de-

composition. The FIND TYPSEQERR module should be decomposed fur-

ther because it requires intermediate processing that is not shown.

89

WJ CO

W V Q ^ o ss v» « >

a< o

90

-U-i

Table IV

CVWORDS Parameters

Iiiput Output

15 Format Er^or Command 16 .Sequence Error Command 17 Valid Command, Format

Errors, Sequence Krrors 32 Parity Error Command 33 Wordlength Error Command 3if Parity Error. Wordlength

Error 35 Memory Load V/ords 36 iJecure Command 37 Timed Command 38 Memory Load Error, Secure

Command Krror, Sequence Error 39 Sequence Errors 40 Format Errors 41 Valid Command lf2 CV Codes

Format Errors Sequence Krrors CV Words

Parity Krror Wordlength Krror Format Error List

Memory Load Error Secure Command Krror Süqucnce Error Sequence Krror List

Sequence Error Code Format Error Code Specific Command Code CV Words

A command with format errors (parity, wordlength) is processed

by FIND TYPFMTERR to determine the types of errors it contains.

The iterative decision suggests a sequential check of both parity

and wordlength. The "Format Error List" created is accessed by

DETERMINE VEHMESCODES and the specific "Format Errors" are used

to determine the proper CV codes needed to produce a CV message.

The FIND TYPESQERR module Is required to process a variety of er-

rors that are classified as "Sequence Errors." These include (1)

"Memory Load Errors" resulting from Improper memory word lengths.

(2) "Secure Command Errors" generated when a "Secure Command" is

not preceded by the proper "prologue" command (Ref 1), and a (3)

"Sequence Error" that results from Improper timing between the pro-

logue command and the executed spacecraft "Secure Command." These

errors must all be recognised and assembled in the same manner as

91

X PRODUCE OÜTMESS

GENERATE STATMODMES

GENERATE CVMESÖ

PRODüCI: STATLIST

4?

CONVERT CVWORDS

Parametei'E.

Input Output

18 Valid Command, Current Status, Status Modification

19 CV Werde

43 Valid Command, Current Status, Status Modification

kk Modification Message

*,; CV Words

46 CV Message

Status Listing

CV Message

C Figure 37. OÜTMSSS Module and Subordinates

parity and wordlength errors. DETERMINE VEHMESCOÜES accepts the

errors that have been found during the command proceet '.ng and lo-

cates the proper command 7eriflcation codes that adequately describe

92

the error,

PRODUCE OUTMESS. This is the efferent, or output branch of

the simulator. It accumulates all errors and status modifications

generated during command processing and provides a meaningful out-

put message. The module and its associated parameter list are shown

in Figure 37.

The "Valid Command" and "Current Status" information are used

to produce a current "Status Listing" which is an explanatory state-

ment of changec made and commands executed, "CV Words" are also

listed with descriptions cf their meaning.

Summary

Three previously tried design techniques are combined into

one design methodology in this chapter. The activity model created

during the preliminary design is converted directly to a first cut

structure chart with no design modifications. An intermediate bub-

le chart is constructed from the first cut structure chart. During

construction of the bubble chart a reevaluation of each module is

made with emphasis on the conceptual representation intended by

the bubble chart. After ensuring the bubble chart properly illus-

trates the desired system data flow, a new structure chart is cre-

ated which represents a design refinement. This structure chart

in then analyzed for "goodness" of design by looking for deficien-

cies in coupling, cohesion, scope-of-effect/scope-of-control.

93

V. Design AnnlyslB

Introduction

This chapter Is a summary of the information gained through-

out this thesis project. The value of the design is discussed and

ST'ggestionB to Improv the design are givon. Deficiencies noted

during phases of the design are pointed out, and recommended rom-

edi*JB for those doficiencios are presented. Since the software

design methodology employed in this project is relatively new and

untried, this chapter also contains observations sind recommendations

for its continued usage.

Summary

The first problem addressed in this design project is the need

for a souud analysis procedure that aids in defining requirements

for a design. A study of SofTech's Structured Analysis and Design

Technique shows that their methodology yield« a top-down, nodular,

hierarchic, and structured design. Those desirable design charac-

teristics facilitate prograimning for implementation. The activity

and data models are constructed with satisfactory results. Through-

out the construction of the activity model an inability to define

the input, output, or control is an indication of a lack of under-

standing of the particular activity. Consequently the system is

studied further to a level of understanding that allows progress

to continue. The same is true when constructing the data model.

The data model iß useful as a continuity check between blocks in

the activity model. The two models are excellent tools that make

94

N

a complete, underetandabla requlrementü definition posaiblo and

provide a well defined preliminary design.

Structure charts are used as efficient neans of refining the

simulator design to prepare it for the programming phase of devel-

opment. The structured analysis (.activity and data models) leaves

the question of "goodness" of design unanswered. The question is

answered by the construction of structuro charts. The problem is

how to make a smooth transition from the SAPT mothodology to the

Transform Analysis used to derive the structuro charts. The acti-

Tlty model is redrawn into a structure chart. This transition yields

a structure chart that bettor identifies the essential elements in

the system. NJxt, an "intermodiato" bubble chart is drawn based

on a structured design method by Hughes Aircraft (Ref 5). The re-

evaluation of intermodular connections at each stage of bubble con-

struction results in the location and correction of poorly defined

connections. Now Transform Analysis (Ref 10: Char, 10) can bo usod

to derive a more refined structure chart. Upon completion of the

refined structure chart, a thorough examination of each module re-

sults in identification of some areas that nood further analysis.

The combination of the three design mothodolgies, structured

analysis, structured design, and Hughes' iteration of structured

design results in a simulator design that moots or exceeds the or-

iginal design goals. The system is modular and understandable.

The loose coupling between modules enhances the modifiability and

maintainability of the simulator. The well defined scope-of-effeet/

scope-of-control within a branch of the system maintains th« func-

tional independence desired, even ir. the most complex branches.

95

After incorporating the recommendations give:, below, the structured

design can be given to a programming section with full confidence

that the system requirements will be met.

Conclusions and Recommendations

In Chapter IV, the first cut structure chart would be easier

to understand if the control elements wore included in the parame-

ter list. It is recommended that all inputs, outputs, and controls

be included in the first cut structure chart as a central reference

for bubble chart construction.

The TYPSEQERR module shown in Figure 36 on page 90 needs fur-

ther decomposition to better define its function. This module can

be examined independently and modified as required without affect-

ing the other subordinates of PROCESS CVWORDS, That examination

should be made before coding is attempted.

To be consistent with a software life-cycle, each module in

the given structure charts should be flow-charted for coding. Be-

fore this is attempted, however, the structure charts should be

studied by the coders to clarify any vague portions of the struc-

ture. This clarification should be made by reading the Design Re-

finement in Chapter IV. If further clarification is needed, another

iteration from a new bubble chart to another structure chart should

be performed.

This thesis addresses the simulation of the command section

of the Block 5D satellite with successful results. It is recommended

that other spacecraft functions be analyzed using the methodology

presented in this design. Each main function can be designed in-

dependently and added to this design at a later time,

96

Bibliography

1. Annex I. SytUenu' ^ViK-ovts and "r^codures. Offutt Air Vorc© Base, Nebraska: H«adquartera IJOOO Aorospaco Applications Group (SAO, March 1976,

2. Boehra, B. '.V, Sof111£| :■'flgiru'oring. Redende Beach, California; TRW, 197b.

3. Jensen, B« "Structured Deslccn." 1^7^ IK^? Structured ?pi>t;-p Methodolojsy. £'% llughes Aircraft Company, April 1976«

k* Ross, D. T., aad K. V. Schoman, Jr, Stnu-1 \ifev'. An.-'.'.N^-:- t'^r RequironenU. nofir.i tion. iVultham, Massachusetts: SofT«ch, Inc., April 1976«

5, Roes, P. r., il ül. "Software Englnoerlng: Process, Prin- ciples, and Goals," Cotnputor: 89-99 (

1O75)

6. Roüs, P. T. ^uaU<-y g^flCtl "'iti: ' H.nir;^. nt^ :\-fl^Vti^n. Waltham, Kft«MOhuä«vtä: SofToch| Inc., Xobruary lw,";,

?, SofTech, Inc. Structured Annly^l^ Moador vuide. Walthan, Massachusetts: Ma^' 107r>,

8« SofTech, Inc. An Introduction to ^tructurod Analy^ii' and Pesign Tochnlouo. Waltham, : a^^aciiusotts: Novonbor 1976«

Q6 Stevens, W« P., et al. "Structured Design." I^M Sy^tert. Journal. £: 115-139 097^)«

10. Yourdon, K., and 1. I. Constantine. Structured Poi'ign. New York: Yourdon, Inc., February 1076.

m^ 97

me] laauiM SECURITV CLASSIFICATION OF THIS PAGt (»Tl«! Pmlm KnftrU)

REPORT DOCUMENTATION PAGE 1 «ePORT NUMBER

GE/ES/77S-6

a OOVT ACCESSION NO

X • TITLE (■«»<« SubHII»)

STRUCTÖRED ANALYSIS AND DESIGN OF A

SATEMITE SIMULATOR

Kenneth 1 , Marvin Captain USAF

'i-PERFORMING ORGANIZATION NAME AND ADDRESS

Air Force Institute of Technology (AFIT-KN) Wright-Patterson AFB, Ohio 45433

tl, CONTROLLING OFFICE NAME AND ADDRESS

4000 Aerospace Applications Group (SAC) Offutt AFB, Nebraska 66113

RKAD INSTRUCTIONS BEFORE CVAU'LETING FORM

S RECIPIENT'S CATALOG NUMBER

5 TYPE OF REPORT ft PERIOD COVERED

MS Thesis

6 PERFORMING ORO. REPORT NUMBER

S CONTRACT OR GRANT NUMBER(a>

10. PROGRAM ELEMENT, PROJECT. TASK AREA A WORK UNIT NUMBERS

li REPORT DATE

September, 1977 IS NUMBER OF PAGES

108 li MONITORING AGENCY NAME « ADDRESSi i( JlKoMKit Iwi Cenltolllnt Olltc») IS. SECURITY CLASS, (ol thtt «port'

Unclassified

Tsi, DECLASSIFICATION OOWNGRADIN0 SCHEDULE

16 DISTRIBUTION STATEMENT (o( lf>la R»pof(l

Approved for public release; distribution unlimited

17. DISTRIBUTION STATEMENT (of Ihm mtolrmct •nt»r»d (n Block :0, II Jlll»r»nl from K»por()

18. SUPPLEMENTARY NOTES

iKMA release; I AW APR 190-17 Ajtproved fo

JSRRAI(F. GUESS^ Captain, USAP Directo^ of Information

1« KEY WORDS (ConHnu» Ml rev«»» »Id* II ntcntty ««* Idfntlly by bleck monbni

Structured Analysis Structured Design Bubble Chart Structure Chart

55 ABSTRACT (C'^ndnu» tui r»v»ri» »M» M n»c»»»»fy and ld»nlll\ by block inimi>»r>

\l The problem addressed in this thesis is the analysis of a complex satellite command system and the design of a software simulation of that system. The problem is solved in three steps. First, a written require ments definition establishes a sound viewpoint and purpose on which the analyst can base hie design. This requirements definition explains why the simulator is to be created, how it is to be constructed, and what it is to do. Second, a top-down strategy called "structured analysis" is applied to create the preliminary design. The structured analysis is _ __•/

DD I JAN 73 1473 EDITION OF t NOV»» IS OBSOLETE

ftmiiiiiiiMi iiüütiiiiiiii lüiiiim

UNCLASSIFIED fi**~

SECURITY CLASSIFICATION OF THIS PAoF fWtmi Oatm Bntfd)

UNCLASSIFIED

^

SECURITY CLASSIFICATION OF THIS PAOEfHTiim Ptil* F.nlmrmd)

jji'eaented In a blueprint-type language «1th activity and data models. The models represent graphically the functions performed by the simula- tor and the information upon which those functions act. A final design refinement is performed with a structured design methodology called "transform analysis." The structure charts drawn during the transform analysis reveal system characteristics which illustrate design quality. The activity model acts as a catalyst to a successful transition from a top-down analysis to a structured design which cen be evaluated. The resulting simulator design, with minor revisions, satisfies the design goals established for the project. The methodology used is highly rec- ommended for the analysis and design of any software system. -^

UNCLASSIFIED SECURITY CLASSIFICATION OF THIS PAGEfWi.n O.t. Enf.r.d)