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)