00001.tif

PDF

Download

Open document

Transcript (if available)

Content SPECIFICATION AND DESIGN METHODOLOGIES FOR
• SEMI-HARD REAL-TIME CONTROL SYSTEMS
by
Alice H. Muntz
A Dissertation Presented to the
FACULTY OF THE GRADUATE SCHOOL
UNIVERSITY OF SOUTHERN CALIFORNIA
In Partial Fulfillment of the
Requirements for the Degree
DOCTOR OF PHILOSOPHY
(Computer Science)
May 1990
Copyright 1990 Alice H. Muntz
UM I Number: DP22805
All rights reserved
INFORMATION TO ALL USERS
The quality of this reproduction is dependent upon the quality of the copy submitted.
In the unlikely event that the author did not send a complete manuscript
and there are missing pages, th ese will be noted. Also, if material had to be removed,
a note will indicate the deletion.
Dissertation Publishing
UMI D P22805
Published by ProQuest LLC (2014). Copyright in the Dissertation held by the Author.
Microform Edition © ProQuest LLC.
All rights reserved. This work is protected against
unauthorized copying under Title 17, United States Code
ProQuest LLC.
789 East Eisenhower Parkway
P.O. Box 1346
Ann Arbor, Ml 4 8 1 0 6 - 1346
UNIVERSITY OF SOUTHERN CALIFORNIA
THE GRADUATE SCHOOL
UNIVERSITY PARK Q
LOS ANGELES, CALIFORNIA 90089 V K . V .
CfS
M97/
This dissertation, written by
f i L l C S H • M v N T Z
under the direction of h & C Dissertation
Committee, and approved by all its members,
has been presented to and accepted by The
Graduate School, in partial fulfillm ent of re
quirem ents for the degree of
D O C TO R OF PH ILOSOPH Y
Dean of G raduate Studies
Date
DISSERTATION COMMITTEE
TABLE OF CONTENTS
LIST OF TABLES...............................................................................................................iv
I
LIST OF FIGURES.............................................................................................................v i
i
A B ST R A C T ........................................................................................................................xii
l
I
4. INTRODUCTION............... 1
2. BA CK G R O U N D ...................................................................................................... 6
2.1. System C haracteristics............................................................................... 6
2.1.1. E xternal E n v iro n m en t................................................................ 6
2.1.2. C om putational C haracteristics............................................... 12
2.2. Survey of Existing Specification A p p ro a ch ......................................19
2.2.1. C om parison C riteria.................................................................. 21
2.2.2. T eam w ork From C adre Technologies Inc.......................... 33
2.2.3. CARDTools From R eady System s.........................................50
2.2.4. Statem ate From i-Logix..............................................................62
2.2.5. RDD-100 From Ascent Logic C o rp o ratio n ..........................73
2.2.6. S u m m a ry ...................................................................................... 81
;3 . A REQUIREMENTS SPECIFICATION METHODOLOGY........................84
3.1. G raphical Prim itives for specifying R equirem ents.......................87
3.2. R equirem ents Specification M e th o d ................................................. 97
3.2.1. Data G rap h .................................................................................... 99
3.2.2. A ctivity G ra p h ................................................. 103
3.2.3. A tom ic A ctivity.........................................................................108
3.3. T im ing A nalysis A pproaches.............................................................116
3.3.1. A ctivity T axonom y.................................................................. 117
3.3.2. Effect O f M odeling A daptive T im ing A ctivities By
Periodic A ctivities.................................................................... 125
3.3.3. T uning Scheduling P aram eters...........................................128
i i
3:3.4. Exam ples of U sing the P roposed T im ing A nalysis
A pproach...................................................................................... 129
4. A DESIGN METHODOLOGY FOR REAL-TIME SOFTW ARE..............136
4.1. G raphical Prim itives for Specifying D esign.................................... 140
4.2. Design Specification M ethod.............................................................. 156
4.2.1. Restricted Data G raphs............................................................ 156
4.2.2. R estricted A ctivity G ra p h s.....................................................160
4.2.3. D ecom position of an A ctivity G raph into M axim al
R estricted A ctivity G ra p h s 163 j
4.2.4. A n Exam ple of Partitioning an A ctivity G rap h................175
4.2.5. Task G rap h s................................................................................ 178
4.3. D eriving an Initial Task G raph from R eq u irem en ts................... 187
j
4.4. S u m m a ry 193 j
5. A N EXAMPLE SENSOR SYSTEM....................................................................194 '
5.1. R equirem ents Specification...............................................................194
5.2. Design Specification................................................................................ 213
6. SUMMARY A N D FUTURE RESEARCH.................................................... 221
6.1. S u m m a ry ............................ 221
6.2. F u tu re W o rk ............................................................................................225
REFERENCES.................... 230
i i i
TABLE 2-A:
i
TABLE 2-B:
TABLE 2-C:
I
i
!
jTABLE 2-D:
1
I
TABLE 2-E:
TABLE 2-F:
TABLE 2-G:
jTABLE 2-H:
TABLE 2-1:
TABLE 2-J:
TABLE 2-K:
Table 2-L:
Table 2-M:
Table 2-N:
Table 2-0:
LIST OF TABLES
R e q u i r e d P r o p e r t i e s o f n o t a t i o n s f o r r e p r e s e n t i n g
DATA MODELS................................................................................................. 25
R e q u i r e d p r o p e r t i e s o f n o t a t i o n s f o r r e p r e s e n t i n g
DATA MODELS.................................. 26
REQUIRED PROPERTIES OF NOTATIONS FOR REPRESENTING
Static pr o g ra m m o d e l s......................................................................... 26
INFORMATION WHICH CAN BE MODELED BY THE ENTITY-
RELATIONSHIP MODEL................................................................................37
P r o p e r t ie s w h i c h C a n b e m o d e l e d b y d a t a / c o n t r o l
FLOW DIAGRAMS...........................................................................................41
PROPERTIES OF SEQUENTIAL PROGRAMS WHICH CAN BE
m o d e l e d B y S t r u c t u r e C h a r t s a n d m - S p e c s ............................ 42
PROPERTIES OF DATA WHICH CAN BE MODELED IN
CARDTOOLS...................................................................................................51
PROPERTIES OF CONTROL FLOWS WHICH CAN BE MODELED
IN CARDTOOLS............................................................................................. 55
PROPERTIES OF STATIC PROGRAMS AND THEIR RELATIONSHIPS
WHICH CAN BE MODELED IN CARDTOOLS..........................................56
P ro per ties o f d a t a W h ic h C a n b e m o d e l e d i n
St a tem ate...................................................................................................... 63
P roperties o f c o n t r o l Flow s W h ic h Ca n Be m o d e l e d
in St a te m a te.................................................................................................65
P r o p e r t i e s o f S t a t i c P r o g r a m s a n d T h e i r
R e l a t io n s h i p s w h i c h C a n b e m o d e l e d i n S t a t e m a t e . 66
P r o p e r t ie s o f D a t a W h i c h C a n B e M o d e l e d i n R D D 75
P r o p e r t i e s o f C o n t r o l F l o w s W h i c h C a n B e m o d e l s in
R D D ................................................................................................ 76
P r o p e r t ie s o f S t a t ic P r o g r a m s a n d their
Relatio nsh ips W h ic h Ca n be m o d e l e d in r d d .......................77
IV
I ----------------
TABLE 3-A:
TABLE 3-B:
TABLE 3-C:
jTABLE 4-A:
jTABLE 4-B:
|
TABLE 4-C:
SUPPORT IN SPECIFICATION OF DATA MODELS.................. ...............
SUPPORTS IN SPECIFICATION OF CONTROL FLOW MODELS............
SUPPORTS IN SPECIFICATION OF SEQUENTIAL PROGRAM
MODELS...........................................................................................................
PROPERTIES SUPPORTED BY RESTRICTED DATA GRAPHS..............
P roperties su ppo r t ed by t a sk G r a ph s a n d R estricted
ACTIVITY GRAPHS.....................................................................................
P roperties su p po r t e d by Restricted a c tiv ity G r a p h s
AND THE TASK DEFINITION TEMPLATE..............................................
113
114
114
185
185
186
v
LIST OF FIGURES
Figure 2-1: The in t e r r e l a t io n sh ip betw een se n s o r System s a n d
External En v ir o n m e n t ..................................................................... 7
jFlGURE 2-2: A DATA ACQUISITION AND ANALYSIS LOOP.................................... 15
FIGURE 2-3: TIME INSTANTS RELATIONSHIP OF ACTIVITY AK FOR THE
NTH ITERATION OF THE ITH MONITORED PROCESS........................16
FIGURE 2-4: AN EXAMPLE MODEL WITH WEAK SEMANTICS...............................27
i
FIGURE 2-5: AN EXAMPLE OF AMBIGUOUS CONTROL STRUCTURES....................40
FIGURE 2-5: ENTITY-RELATIONSHIP DIAGRAM (ERD) NOTATIONS....................42
i
I
FIGURE 2-6: AN EXAMPLE ENTITY-RELATIONSHIP DIAGRAM...............................43
FIGURE 2-7: NOTATIONS FOR BUILDING CONTROL MODELS...............................44
FIGURE 2-8: ALTERNATIVE WAYS FOR EXPRESSING C-SPECS............................... 45
I
I
FIGURE 2-9: NOTATIONS FOR BUILDING STRUCTURE CHARTS .......................47
'F igure 2-10: A n Exam ple o f a Part of a Structure Ch a r t............................ 48
'FIGURE 2-11: NOTATIONS FOR CONSTRUCTING TASK MAPS.................................57
FIGURE 2-12: A PART OF AN EXAMPLE ROBOT CONTROL SUBSYSTEM................. 58
FIGURE 2-13: INFORMATION FLOWS BETWEEN ACTIVITY-CHARTS ARE
CONTROLLED BY STATECHARTS............................................................64
jFlGURE 2-14: NOTATIONS FOR BUILDING STATECHARTS, ACTIVITY-
CHARTS, AND MODULE-CHARTS.......................................................... 67
'F igure 2-15: N o ta tio n s fo r Expressing x o r / a n d Su b-sta tes................68
FIGURE 2-16: EXAMPLES OF CONNECTORS................................................................... 69
F ig u re 2-17:
Figure 2-18:
!
t
I
Figure 2-19:
Figure 3-1:
Figure 3-2:
1
<
1
figure 3-3:
FIGURE 3-4:
FIGURE 3-5:
Figure 3-6:
'FIGURE 3-7:
FIGURE 3-8:
FIGURE 3-9:
FIGURE 3-10:
(l) O perator Primitives, (2) n o d e prim itives...........................77
Two E xam ples f o r M o d e llin g C o n c u r r e n t D a t a ................78
A H ig h Level sp e c if ic a t io n f o r a c o m m u n i c a t i o n
pr o t o c o l.....................................................................................................79
G r a ph ic a l n o t a t io n s for b u il d in g A c t iv it y / D a t a
G r a p h s..........................................................................................................87
A d a t a G r a p h C o n s t r u c t e d w i t h i t e r a t i o n ,
Seq u en c e, a n d d a t a Item primitives............................................ 88
A d a t a G r a p h C o n s t r u c t e d w i t h r e p l i c a t e ,
Selection, d a t a item, a n d Co n c u r r en t O bjects of t h e
Sam e C lass pr im itives.......................................................................... 89
TWO CONCURRENT ACTIVITIES COMMUNICATE VIA 'MSGS' 90
DATA GRAPHS REPRESENT POSSIBLE DECOMPOSITIONS OF
MSGS.................................................................................................................90
ACTIVITY GRAPHS REPRESENT POSSIBLE DECOMPOSITIONS OF
ACTIVITY A AND ACTIVITY B ................................................................. 91
MSG, MODELED WITH A JUNCTION CONNECTOR, IS NOT A
SHARED DATA ITEM.............................. 94
A DATA ITEM WITH TWO DECOMPOSITIONS, ONE FROM THE
PRODUCER'S POINT OF VIEW AND THE OTHER FROM THE
CONSUMER’S POINT OF VIEW............................................................... 95
AT EACH EXECUTION ITERATION, ACTIVITY A BROADCASTS
MSG TO ACTIVITY B AND ACTIVITY C.................................................... 96
TIMING INSTANT VARIABLES ASSOCIATED WITH A N
ACTIVITY INSTANCE................................................................................ 109
v ii
I
Figure 3-11: r elatio n sh ip betw een tim ing in s t a n t variables a n d
TIMING SPECIFICATION FU NC TIO N S.........................................................I l l
F i g u r e 3-12:
FIGURE 3-13:
!
i
I
FIGURE 3-14:
I
I
i
F ig u r e 3-15:
i
I
FIGURE 3-16:
I
j
FIGURE 3-17:
FIGURE 3-18:
I
FIGURE 3-19:
FIGURE 3-20:
FIGURE 4-1:
F igure 4-2:
FIGURE 4-3:
FIGURE 4-4:
AN ACTIVITY TAXONOMY VIA CLASSIFICATION OF
CONSTRAINTS ON ARRIVAL TIMES....................................................... 118
RELATIONSHIPS OF CPCD ACTIVITIES' TIMING ATTRIBUTES
AND STATE..................................................................................................120
RELATIONSHIPS OF RCPCD ACTIVITIES’ TIMING ATTRIBUTES
AND STATE..................................................................................................121
RELATIONSHIPS OF ATC ACTIVITIES' TIMING ATTRIBUTES
AND STATE............................. 123
RELATIONSHIPS OF ATS ACTIVITIES' TIMING ATTRIBUTES
AND STATE..................................................................................................123
SCHEDULING PARAMETERS SPECIFICATION OF AN EXAMPLE
STRICT ATS ACTIVITY..............................................................................130
A 'SEARCH ALERT ’ACTIVITY REPETITIVELY SCANS A SEARCH
FRAME........................................... 131
THE CONTROL FLOW MODEL OF A SEARCH ACTIVITY................... 132
THE WORKLOAD MODEL TRANSFORMED FROM THE ACTIVITY
GRAPH SPECIFIED IN FIGURE 3-19.......... 134
G r a p h i c a l n o t a t i o n f o r R e s t r ic t e d A c t i v it y / D a t a
G r a p h s ...................................................................................................................... 140
G r a p h i c a l N o t a t i o n s f o r T a s k G r a p h s ......................................141
Two p o s s i b l e C a s e s o f c o n c u r r e n t t h r e a d s ...........................144
TWO CONCURRENT THREADS OF ACTIVITY CHAINS...................147
'F ig u r e 4-5: A t a s k G r a p h d e r i v e d f r o m M a p p in g E a c h t h r e a d o f
ACTIVITIES INTO A TASK....................................................................... 147
F igure 4-6: A n o t h e r A ctivity Gr a ph C a n h a v e a D erived Ta sk
G r a p h ..........................................................................................................149
[F igure 4-7: A n A ctivity m a y Pr o duce t w o O u tpu t s or C o n s u m e
I T w o in p u t s ................................................................................................150
FIGURE 4-8: TWO TASKS COMMUNICATING WITH TWO DATA FLOWS
Via O n e Pa ir o f p o r t s .................................................................... 150
FIGURE 4-9: TWO THREADS OF ACTIVITIES 'CONCURRENTLY ACCESS' A
DATA ITEM X ...............................................................................................152
FIGURE 4-10: A DATA MANAGER TO ENSURE THE DATA INTEGRITY OF
Sh ar ed d a t a it e m ................................................................................. 153
FIGURE 4-11: A PERIODIC ACTIVITY, ITERATING EVERY 2 SECONDS................ 154
FIGURE 4-12: A PERIODIC TASK ENABLED BY WATCH DOG TIMER EVERY 2 j
Se c o n d s 154 ,
FIGURE 4-13: GIVEN ACTIVITY GRAPH A G .................................................................166
I
I
FIGURE 4-14: MAXIMAL RESTRICTED ACTIVITY GRAPHS DERIVED FROM
AG............................................................................................................ 168
Figure 4-15: T w o pa ir s o f c o n c u r r e n c y vertices m a r k e d w it h ’3 ’
A N D ’4 ’.........................................................................................................176
FIGURE 4-16: MAXIMAL RESTRICTED ACTIVITY GRAPHS FOR A G ......................177
FIGURE 5-1: A N ACTIVITY GRAPH REPRESENTING THE INTERACTION
Betw een a A d v a n c e d Ra d a r System a n d its External
e n v ir o n m e n t...........................................................................................195
FIGURE 5-2: AN ACTIVITY GRAPH REPRESENTING A SENSOR SUBSYSTEM.. 196
ix
FIGURE 5-3:
FIGURE 5-4:
FIGURE 5-5:
I
I
i
F igure 5-6:
Figure 5-7:
|f i g u r e 5-8:
FIGURE 5-9:
FIGURE 5-10:
'Figure 5-11:
'FIGURE 5-12:
'F ig u r e 5-13:
'F ig u r e 5-14:
'F ig u r e 5-15:
a n A c t i v i t y G r a p h R e p r e s e n t i n g C o m p u t a t i o n a l
BEHAVIOR OF SENSOR M ANAGER............................................................... 198
D A T A G RAPHS REPRESENTING PROPERTIES OF EXTERNAL
REQUESTS................................................................................................................... 200
D a t a G r a p h s R e p r e s e n t i n g P r o p e r t i e s o f F r o n t e n d
PLANNING DIRECTIVES......................................................................................201
a n A c t i v i t y G r a p h R e p r e s e n t i n g a F r o n t e n d
REQUEST M A N A G ER .............................................................................................202 '
A d a t a G r a p h R e p r e s e n t i n g P r o p e r t i e s o f f r o n t e n d
DIRECTIVES.............................................................................................................. 203
D a t a G r a p h s R e p r e s e n t i n g F r o n t E n d R e q u e s t s ................. 204
a n a c t i v i t y R e p r e s e n t i n g f r o n t e n d p l a n n e r ................... 205
d a t a G r a p h s R e p r e s e n t i n g S i g n a l P r o c e s s i n g
REQUESTS................................................................................................................... 206
A n a c t i v i t y R e p r e s e n t i n g S i g n a l P r o c e s s i n g
M a n a g e r .................................................................................................................207
A n a c t i v i t y r e p r e s e n t i n g S i g n a l P r o c e s s i n g J o b
M a n a g e r .................................................................................................................208
d a t a G r a p h s R e p r e s e n t i n g d a t a P r o c e s s i n g
r e q u e s t s ................................................................................................................... 209
A n a c t i v i t y R e p r e s e n t i n g D a t a p r o c e s s i n g m a n a g e r . 210
a n activity Representing t u J ob M a n a g e r ....................... 211
•F ig u r e 5-16: t i m i n g c o n s t r a i n t s D e f i n e d b a s e d o n t h e g r o w t h
TREND & BOUNDS ON ERROR VARIANCE...................................... 212
I ------------------
'FIGURE 5-17:
!
F i g u r e 5-18:
I
i
'FIGURE 5-19:
I
i
I
FIGURE 5-20:
FIGURE 5-21:
i
i
I
F i g u r e 5-22:
M RA G S C O N T A IN IN G O N L Y 'F O R K ' AN D 'JOIN'
ACTIVITIES.................................................................................................................213
A PART OF THE TASK GRAPH FOR THE SENSOR SUBSYSTEM.... 214
A N EXAMPLE HARDW ARE ARCHITECTURE FOR AIRBO RNE
R a d a r S y s t e m s .................................................................................. 216
MODIFIED MRAG OF THE FRONT E N D REQUESTS M ANAG ER. 218
TH E TASK REPRESENTING THE FRO NT E N D REQUESTS
M A N A G ER ................................................................................................................. 218
T h e D a t a M a n a g e r c r e a t e d f o r t h e s h a r e d T r a c k
d a t a b a s e ..................................................................................................................219
xi
ABSTRACT
In this thesis, I investigate a d ass of real-tim e control system s in w hich a
variety of types of tim e constraints are im posed on com putational activities. A
subset of critical activities m ust alw ays m eet the tim e constraints; other non-
i
i
critical activities can violate tim e constraints w ithin allow able bounds; still
i
I
others do not have tim e constraints. These system s are called semi-hard as only
a portion of the activities m ust m eet stringent tim e constraints.
I
I The classical w ay of designing real-tim e system s m ake several key
assum ptions th at in practice are false. Three of these assum ptions are that (i)
the w orkload is not data dependent, (ii) tim ing can be a priori determ ined, and
(iii) there is no feedback loop betw een observations an d com putation. In
practice, the system objectives can be dynam ically altered either by the external
inputs (from the system operators or other related subsystem s) or by changes
detected by processing previously collected data, tim ings vary depending upon
:he system state; and the control of data collection and d ata processing form s a
: eedback loop.
F urther, th e eventual softw are test and integration phases of real-tim e
system s are difficult and expensive. It is difficult (and som etim es im possible) to
generate test d ata in a testin g /sim u latio n environm ent. To detect errors of
such system s in their operational environm ent are extrem ely difficult and
expensive. For exam ple, the cost of a single flight test for avionics ra d a r
system s is on the order of hundreds of thousands of dollars.
In this thesis, I develop a softw are requirem ents specification m ethod.
: or sem i-hard real-tim e control software. I also present a design m ethodology
:hat, given a softw are requirem ents generated using this specification m ethod,
it allows one to derive a softw are design directly.
| The specification m eth o d w as arrived after p erform ing a thorough
analysis of the characteristics of sem i-hard real-tim e control system s, doing a
I i
survey of theoretic m odels of parallel program s, an d doing an evaluation of
real-tim e specification m ethods su p p o rted by com m ercial tools. Based upon
these studies I introduce a 3-part com putational m odel for sem i-hard real-tim e
control software. The three parts are:
• the d ata to be m an ip u lated th at allow s one to express spatial
parallelism (i.e., the relationships betw een the locations w here data !
are produced) and tem poral parallelism (i.e., the tim e order in w hich
d a ta are p ro d u ce d ), enabling conditions, a n d stru c tu re d type
inform ation.
i
• the functions w hich m anipulate the data th at allow s one to express i
h o w these fu n ctio n s in teract, th eir en ab lin g a n d term in atin g
conditions, and their tem poral properties (e.g., a function m ust start
before the tim e at w hich the error covariance of its in p u t d ata reach
their m axim um allow able limits).
• the interrelationships betw een functions th at allow s one to express
precedence relatio nships, spatial and tem p o ral parallelism , and
enabling conditions. I
The d esig n m eth o d o lo g y in tro d u c ed in this th esis p ro v id es for
rep resen tin g a design at m u ltip le levels of abstraction. The notations and
sem antics for design specification m ake these different levels of abstraction
ideal for m ultiple levels of design validation via sim ulation. Furtherm ore, since
the design is a natural derivation of requirem ents, requirem ents and design are
i
th u s linked. I believe that this traceability together w ith different levels of
design validation w ill enable softw are designers to identify crucial design
errors.
In sum m ary, the key contributions of this thesis research are:
• m ethods an d notations for specification of softw are requirem ents,
w hich capture the functional, behavioral and tem poral properties of
softw are,
I • m ethods an d notations for describing the dynam ic behavior of a
softw are design,
• a w orkload m odel w hich characterizes the resource dem ands of of
com putational activities (including adaptive, periodic, and sporadic ,
activities) in a system ,
• an activity taxonom y w hich characterizes m ajor activity classes in
engineering sem i-hard real-tim e control system , !
*
• a strateg y for tu n in g sch ed u lin g p aram eters to lim it reso urce
utilization of an activity under a given bound,
• a strategy and algorithm s for deriving an initial task graph (i.e., the
control flow m odel of softw are architecture) from a given activity
graph (i.e., the control flow m odel of requirem ents),
• u se of a n o n -triv ia l ex am p le to d e m o n stra te th e p ro p o se d
m ethodologies.
xiv
t
1. INTRODUCTION
The system s considered here use sensors to m onitor the state of the
external environm ent. D ata acquisition an d analysis system s used in
nuclear physics, in high-energy physics ([Busse81], [Holm81]) and airborne
ra d a r system s ([Blackman86], [Stimson83]) are exam ples of such system s.
These system s sam p le d a ta via sensing devices a n d process the d ata
according to in p u t requests from other subsystem s or from system operators.
M oreover, th e system o p erato rs m ay dynam ically set policies for d ata
'collection and processing. For exam ple, they m ay set a specific priority for
m o n ito rin g som e ex tern al processes, change th e level of perform ance
required for som e data processing, alter the allocation of physical resources
(e.g. due to failure or requests of other subsystem s). Therefore, the system
(processing dem ands and perform ance requirem ents are both data and state
dependent. For exam ple, if the observation data of a sensor system reveals
th at the targ et being tracked is beginning a s u d d e n m an eu v er, then the
su b seq u en t sam pling rate m ust increase and the processing accuracy m ust
also increase accordingly. These perform ance req u irem en ts are based on
system requirem ents and dynam ic requests from the system o p erator or
other subsystem s.
As described in [Marinescu84] and [Berk89], in these system s, external
requests define th e 'to p level' system objectives an d tim ing constraints
associated w ith these requests are the external constraints. A n external
request is satisfied by the execution of som e set of activities. Efficient,
practical schedulers typically deal w ith the w orkload in term s of dem ands to
l
execute these activities. The objective is to couple the scheduling of 'low
level’ activities and high level system objectives in a sim ple w ay. The high
level external constraints are translated, w ith best effort, into the internal
constraints. The external constraints co rrespond to th e arriv al rate of
external requests, the tim ing control requirem ents of h ard w are units, and
th e response tim e as specified in the perform ance specification. U sually,
these types of constraints im pose strict tim e lim itations on com putational
[activities. H ow ever, the internally generated constraints im pose only soft
tim e constraints for com putations based on estim ates. Therefore, internally,
only a subset of tim e constraints m ust be strictly m et for only a subset of
activities, p articu larly in heavy loading or tran sien t overload situations.
A lthough the tim ing constraints of non-critical tasks m ay be violated, there
is a cost associated w ith each violation, an d th e cost is a function of the
sem antic im portance of the activity. These system s are called semi-hard
real-time system s in [Marinescu87].
In ([D u 8 8 ], [L iu 7 3 ], [M o k 8 3 ], [S h a 8 6 ], [ S p r u n t8 8 ],
[Cheng& Stankovic88]), specification, design, an d sch ed u lin g are m ainly
concerned w ith hard real-time system s. These approaches cannot be directly
applied because several key assum ptions are false for sem i-hard real-tim e
system s. These false assum ptions are:
• that tim ing and resource requirem ents are n o t state-dependent; in
fact an external in p u t can radically alter the scheduling priorities
of tasks; in fact tim ing requirem ents are data dep en d en t, i.e., they
are dynam ically d e te rm in e d based on th e sa m p le d d ata, the
observations inferred from the data, and the type of function being
perform ed;
2
• that all deadlines m ust be m et; in fact som e deadlines are flexible;
som e tasks m ay be perm itted to m iss som e deadlines as long as
their required com putational accuracy is m aintained (usually this
m eans non-burst m isses, e.g. no m ore th an n consecutive m isses
for som e specified value of n);
• th a t a task has only one type of inputs; in fact a task m ay have
d ifferen t types of inputs: som e in p u ts are req u ire d in p u ts for
enabling the task; som e are sporadic inputs, i.e., their arrivals are
state dependent; som e are sh ared inputs, i.e., synchronization of
access is required to guarantee their integrity.
In this thesis, I u se ad v an ced ra d a r system s as a case stu d y to
in v estig ate th e relatio n sh ip b etw een external in p u ts an d the d em an d s
im posed on the various resources in advanced sensor system s. Based on an
u n d e rsta n d in g of the com putational characteristics of advanced sensor
sy stem s, I h a v e d e fin e d a d e v e lo p m e n t m e th o d o lo g y to s u p p o rt
specification an d design of sem i-hard real-tim e control softw are an d to
e n a b le s e m i-a u to m a te d m a p p in g of re q u ire m e n ts in to an A d a
im plem entation. The m ain features of this m ethodology are:
• m ethods and notations for specification of softw are requirem ents,
w hich capture the functional, behavioral and temporal p ro p erties1
of software.
1 The functional properties include what functions software is to provide, and the static
relationships between functions. The behavioral properties include how the software
interacts w ith its external environm ent, how software functions interact, etc. The
temporal properties include when functions are to be triggered, how long functions are
allowed to compute, etc.
3
• m ethods and notations for describing the dynam ic behavior2 of a
softw are architecture.
• a w orkload m odel w hich characterizes the resource dem ands of a
system ,
• rules for execution of a design specification.
In th e p ro p o se d m eth o d o lo g y , re q u ire m e n ts sp ecificatio n s are
constructed using the graphical m odel proposed in [Alford85] and extended
by a form al textual notation. W hile useful for expressing req u irem en ts,
[M untz89] has show n th at the g rap h m odel is by itself in ad e q u ate for
rigorously describing a softw are architecture. A n alternative task /a c tiv ity
g rap h form alism has been developed w hich I believe can m ore effectively
express the behavior of softw are system s.
The rem a in d e r of this thesis is o rg an ized as follow s. C h ap ter 2
describes the relevant characteristics of the system s u n d er consideration. I
use the com putational properties of advanced -sensor system s to show that
the classical w o rk lo ad m odel (i.e., p erio d ic an d sp o rad ic tasks) is not
sufficient for describing the com putational requirem ents. Based on a study
of the theoretical m odels of parallel program s an d an evaluation of real
tim e specification m ethods su pported by com m ercial tools, I conclude th at
existing form al specification approaches d o n o t com pletely su p p o rt the
2 The run-time behavior includes the dynam ic structure of the run-time entities; the
synchronization and comm unication between these entities; time constraints of these
entities.
4
requisite com putational view s and that there exists a sem antic gap betw een
softw are requirem ents and design specification.
In C hapter 3, I present a requirem ents specification m ethodology for
su p p o rtin g large scale, sen so r-b ased , real-tim e control system s. This
m ethodology provides graphical notations for expression control flow and
data flow, a language for expressing sequential program execution, a m ethod
for tim e constraints specification, and an approach for classifying w orkload
characteristics of com putational activities. In this chapter, I also illustrate
how a specification of softw are requirem ents can be system atically derived
from a high level system requirem ents using this m ethodology.
In C hapter 4, I p resen t a design specification m ethodology w hich
p ro v id e s n o ta tio n s a n d ru le s for e x p re ssin g so ftw a re a rc h ite ctu re ,
approaches to m ap p in g a requirem ents m odel to a softw are architecture,
algorithm s for g ro u p in g activities into softw are tasks, and a strategy for
design of resource m anagers for m anagem ent of heterogeneous types of
system resources.
In C hapter 5, I illustrate step by step how a softw are architecture can
be system atically d eriv ed from a high level system req u irem en ts for an
exam ple advanced sensor system .
C h ap ter 6 su m m arizes m y cu rre n t resu lts a n d describes fu tu re
research.
5.
2. BACKGROUND
In this chapter, I first use an advanced sensor system as an exam ple to
'abstract the relevant characteristics of sem i-hard real-tim e system s. Based
on the u n derstanding of system characteristics, a set of criteria is defined for
com parison of real-tim e specification m ethods. Based on these criteria, real
tim e specification m eth o d s su p p o rte d by com m ercial tools are, then,
ev alu ated .
2 .1 . SYSTEM CHARACTERISTICS
i
In this section, I describe the characteristics of a sensor system 's
external environm ent and the relationship betw een th e environm ent and
the functional and com putational properties of the system softw are. The
im plications of these properties w ith respect to the definition of a w orkload
m odel are then discussed.
2 .1 .1 . EXTERNAL ENVIRONM ENT
T he ex tern al en v iro n m en t consists of tw o classes of p hysical
processes: the monitored processes and the command processes. M onitored
iprocesses are p a s s iv e w ith respect to the sensor system since in p u ts from
m o n ito red processes need to be explicitly solicited by the sensor system .
T argets, g ro u n d terrain , or w eath er statu s are exam ples of m o n ito red
processes. The command processes are the external sources m onitoring the
^systems and a c tiv e ly or u n s o lic ite d ly in p u t requests. These requests can
come either from individuals or from other com puters, or even from other
6
sensor system s. From the tem poral point of view , all processes (m onitored,
com m and, and sensor) operate concurrently.
Figure 2-1 depicts the interrelationships betw een a sensor system and
its external environm ent.
k input
requests
results
C o m m an d
Processes
Sensor
S y stem
(com puters
&
softw are)
'Figure 2-1: The Interrelationship Between Sensor Systems and External Environment
The basic elem ents of Figure 2-1 are:
(1) the m onitored processes, such as target
(2) the sensors and preprocessors, labelled 1 and 2,
(3) the actuators and post-processors, labelled 3 and 4,
(4) the com m and processes.
The interface betw een the sensor system and the m onitored processes
is a set of sensors and actuators. The monitored processes are objects w hose
state is estim ated by obtaining inform ation via sensors. The collected data
or signals are transform ed by preprocessors (for exam ple, A /D converters)
to com puter-readable form s. These data or signals are then com puted. The
sensor system form s observations from the collected inform ation and then
7
predicts the fu tu re behavior of the m onitored processes. R esulting from
this processing, com m ands and d ata are generated and then transform ed by
a post-processor (for exam ple, D /A converters) to externally acceptable
form ats; these transform ed signals or d ata are then read by actuators to
influence m onitored processes. The focus of this thesis is the specification
and design of the softw are that fits in the sensor system .
In a d d itio n to m o n ito re d p ro cesses, co m m an d p ro cesses can
d y n a m i c a l ly specify th e d esired top level system objectives an d th eir
associated timing or performance requirements to th e sensor system via
in p u t requests w hich m ay be im plem ented as in terru p ts or m essages. Each
input request from a com m and process w ill trig g er a set of low level
activities. The exact set of low level activities is a fu n ctio n of the type and
p a ra m e te rs of th e in p u t re q u e s t and a fu n c tio n of th e state of th e
e n v iro n m e n t (e.g., the in p u t request is to track targets b u t the num ber of
targets is a function of the environm ent). The selected low level activities
i
form the w orkload. These m ust be executed to satisfy the top level system
objectives an d th e p erfo rm an ce req u ire m e n ts. T he o b se rv atio n s an d
predictions of m onitored processes are, then, rep o rte d to the com m and
processes. The in p u t requests, in ad d itio n to triggering a set of low level
com putational activities, can also set a specific priority for observing som e
m o n ito red processes, change th e level of perform ance req u ired for d ata
processing, alter the allocation of physical resources (e.g., due to failure or
requests of other subsystem s), etc.
8
In the follow ing, I use a sam ple set of in p u t requests of an advanced
sensor system to illustrate the relations betw een in p u t requests and internal
com putational activities of the sensor system . A ssum e th at an advanced
sensor system can accept 5 in p u t requests: SEARCH, DELETE-TRACK-FILE,
|S E T -R E S O U R C E -U S A G E - B O U N D , S E T -P E R F O R M A N C E -
REQUIREMENTS, and SET-IMPORTANCE-LEVEL. The details of these five
input requests are described below.
1. S E A R C H (im portance, fram e size, fram e center, R9 0 ) w here
im portance e INTEGER, fram e size = [azim uth, elevation], fram e
center = [azim uth of fram e center, elevation of fram e center ]
This request enables a search activity w hich searches the specified
region of airspace, detects targets, estim ates the target's states, and
in itiates tracks on th e detected targ ets, fram e is a num ber of
degrees in azim uth an d in elevation; importance is a m easure of
strategic value; R$o is the range at w hich the p o w er signal-to-
noise ratio of an uneclipsed target w ith rad a r cross section of one
square m eter is 1.
2. D ELETE-TRACK-FILE (n, trackidi, . . ., trackidn) w here n is the
n u m b er tracks to be deleted; trackidi is the identifier of the ith
track for i e [l..n]
This request enables a delete-track activity w hich deletes a track
file. This file is a database in w hich the observed and estim ated
s ta te of each m o n ito re d p ro c e ss a n d th e c o m p u ta tio n a l
param eters (e.g., com putational accuracy, the h ig h level system
objective) of each m onitored process are m aintained.
3. SET-RESOURCE-USAGE-BOUND (k, resourceTypei, am ount], ..
. , resourceTypek, am ountk) w here k is the num ber of resources
9
This request enables a se t-u p p er-b o u n d activity w hich sets the
u p p e r b o u n d of the specified set of resources. N ote th at in a
m u ltip le ta rg e t tracking system , m u ltip le sensor system s m ay
share system resources (e.g., processors and m em ories); resources
m ay be d y n am ically allocated to a p a rtic u la r sensor by th e
com m and processes w hich have know ledge of the global system
state.
4. S E T - P E R F O R M A N C E - R E Q U I R E M E N T S (o p e ra tio n T y p e ,
perform ance) w here operationT ype e {search, trackU pdate} and
perform ance e REAL
This request enables a set-performance activity w hich dynam ically
sets the perform ance requirem ents of a p articu lar track -u p d ate
activity or search activity on com m and. N o te th a t for targ et
tracking, performance is specified as u p p er lim its of the tracking
error variances, and for search the perform ance is specified as
R 9 0.
5. SE T-IM PO RTAN C E-LEV EL (operationT ype, im portance) w here
o p e ra tio n T y p e e {search, trackU pdate) a n d perform ance e
INTEGER
This request enables a set-im portant a c tivity w hich dynam ically
set the im portance level of a p articu lar track -u p d ate activity or
search activity on com m and.
W hen a search activity detects the existence of targets, for each
detected targ et, a trac k -u p d ate activity is in itiated . T hen, a th rea d of
execution of the track-update activity is continually perform ed until either
com m and processes explicitly request the deletion of this activity or the
sensor system internally decides to delete this activity. N ote that each track-
10
u p d a te activity is associated w ith a specific track en try w hich m u st have
certain track quality on th e a ttrib u te s re p re se n tin g th e sta te of the
m o n ito red processes. The track q u ality is specified by a track qu ality
indicator (or a score) w hich m ay be com puted by various functions such as
m axim um -likelihood score function.
A n exam ple set of p erfo rm an ce req u irem en ts for th is exam ple
system is as follows:
• Ro3 and P f a 4 are given as the perform ance specification of the
sensor hardw are. These tw o param eters together w ith a specified
R90 define the tim ing constraints of the search activity.
• the im portance level for track update and search are specified (e.g.
track u p d ate is m ore im portant than search).
• a fixed period is specified for the output-track activity.
• th e u p p e r b o u n d s for u tilizatio n of sensors, processors, and
m em ories are specified (e.g., no m ore than 50% of the sensor can
be used).
• a com pletion deadline is specified for activities enabled by in p u t
requests (3), (4), and (5). This deadline defines th e n u m b er of
m illiseconds by w hich the specified perform ance req u irem en ts
shall be in co rp o rated into the p rediction for associated tracks
(m easured from the tim e the input is received).
3 Ro is the range at which the pow er signal-to-noise ratio of an uneclipsed target with
radar cross section of 1 square meter is 1.
4 PFA is the single-look probability of a false alarm.
11
T he re a d e r sh o u ld o b serv e from th is ex am p le that (1) tim e
constraints are eith er explicitly specified by th e in p u t req u ests or the
constraints im posed by the hardw are (e.g., the refreshing rate of a display) or
interface specification (e.g., the rate to o u tp u t tracks to a com m and process);
(2) tim e constraints of low level activities m u st be derived from the system
perform ance of their associated high level system -objectives; an d (3) each
low level a ctiv ity has a trig g e rin g co n d itio n , in p u ts, o u tp u ts , tim e
c o n strain ts, and reso u rce req u irem en ts. The d e ta ile d sp ecificatio n of
activities is considered in the next section.
i
In the follow ing, I use the com putational properties of an im p o rtan t
function in advanced radar system s to show that periodic and sporadic tasks
are not sufficient for describing the com putational requirem ents. This leads
m e to define the concepts of adaptive tasks and scheduling windows.
2.1.2. COM PUTATIONAL CHARACTERISTICS
In an advanced rad a r system , a system 's state m ay reflect one of
several operational phases, e.g., passive, sem i-active, or active. For som e
I
phases, e.g., passive or sem i-active phases, the frequency at w hich pulses are
transm itted m ay be restricted to be below specified lim its. This is to avoid
being detected by hostile forces because the transm itted pulses reveal the
p resen ce of a rad a r w hich in tu rn reveals the o w n sh ip (i.e., th e aircraft
'hosting th e sensor system ) to hostile forces. The o p eratio n al ph ases are
selected by com m and processes. In each phase, a specific set of in p u t
'requests (i.e., the 'top level’ system objectives) m ay be issued by com m and
processes, an d typically an in p u t req u est set defines a specific system
12
objective, term ed a sensor mode. Thus, a mode has an associated set of 'low
level' activities executed to achieve a specific system objective. Exam ples of
rad ar m odes are M ultiple-T arget T racking (MTT) and T errain A voidance.
Exam ples of rad a r functions executed as low level activities are an ten n a
|
control, w aveform generation, data collection, signal processing, an d data
processing.
Tracking the state of m onitored processes is accom plished by sensing
activities w hich are perfo rm ed by a sensor to generate radio w aves and
t
collect retu rn ed signals. These activities can be classified as, for exam ple,
u p d a tin g existing targ et tracks, searching for n ew targets in a specified
fram e, perform ing specialized target updates (e.g., target identification), and
m issile guidance. Perform ance req u irem en ts for each activity w ill vary
d epending on the state of the associated m onitored processes, the activity
type, an d the p rio rity (w hich is in h erite d from the high level system -
objective defined by the com m and processes).
It follow s from the above description th at the system w orkload is a
:unction of the n u m b er and in p u t requests, the param eters of the in p u t
requests, the n u m b er of m onitored processes to be observed, the state of
each process, an d their interrelationships. A 'SEARCH' in p u t request for
exam ple defines a high level system -objective w ith som e specified accuracy
and prio rity for detecting targets in the specified search fram e. This high
level system -objective activates a set of periodic 'alert search' activities w ith
soft deadlines. Each 'alert search' activity is responsible for detecting if there
are targets in its designated 'search segm ent' in the specified search fram e.
Each scheduled 'alert search' activity has som e strategic value, and the total
13
strategic value of scheduled 'alert search' activities w ithin a specified fram e
m ust be equal or exceed that specified in the perform ance requirem ents of
'SEARCH.' W hen th e observation form ed from th e d a ta collected by an
'alert search' activity indicates th e existence of targ ets, several s p o ra d ic
'a c q u isitio n ' activ ities are initiated to execute until the target is considered
<
to be stably tracked. Follow ing that, a 'track u p d a te ' activity is scheduled
a d a p tiv e ly , i.e., the tim e in stan ts of successive execution instances of a
targ et's 'track u p d a te ' activity are determ in ed from th e resu lts of the
previous execution instance. Therefore, sim ple periodic an d sporadic tasks
are not sufficient to m odel the w orkload of these system s. The notion of
adaptive activity is required to bring the target u n d er stable observation.
In the follow ing, I w ill illustrate adaptive activities in detail using an
im p o rta n t fu n ctio n in a d v an c ed ra d a r system , i.e., M u ltip le-T arg ets
Tracking (MTT) to illustrate this type of activity and ho w it differs from a
periodic activity. The MTT track loop, depicted in figure 2-2 [Blackman8 6 ],
consists of w aveform generation, data collection, signal processing, and data
p ro cessin g , an d these activities are executed on v ario u s resources, i.e.,
antennas, in p u t processors, signal processors, an d d ata processors. Each
com putational activity in an iteration is enabled only after its predecessor
activities have com pleted and the required data are available.
.14_ _
Direct Radar
Sensor for
Sampling
request for more information on the tracked target
1
Sensor Data
Collection
samples
Data Association,
Measurement
Data
Correlation
Track Initiation,
Confirmation,
Preprocessing
a 4
a 5
and Deletion------
t
Filtering
Gate Formation
<4—
(Prediction and -ft
a.
Update)
Figure 2-2: A Data Acquisition And Analysis Loop
Each activity has a set of ’ constraints' on the tim e in s ta n ts . These
co n strain ts form th e specification w hich the resource m an ag ers use to
allocate resources. As show n in Figure 2-3, there are six tim e in stan ts (i.e.,
a rriv a l tim e, re a d y tim e, sta rtin g tim e, sc h e d u lin g d e a d lin e tim e,
com pletion tim e, and com pletion d ead lin e tim e) an d tw o tim e intervals
(i.e., sch ed u lin g w in d o w and execution tim e). R eady tim e, sch ed u lin g
deadline, and com pletion deadline are constraints w hich are intrinsic to the
com putational characteristics of an activity. The arrival tim e (i.e., the tim e
at w hich an activity is know n to the m anager of a specific resource) is a
function of both how the activity is executed and its intrinsic com putational
characteristics. Execution tim e is a function of the state of the m onitored
process and the intrinsic characteristics of the activity. Scheduling w indow
is the tim e interval w hich begins w hen the activity can start, and therefore
is th e w indow in w hich a resource m anager can schedule th e activity to use
its req u ire d resources. Finally, startin g tim e an d com pletion tim e are a
fu n ctio n of sy stem w o rk lo ad , sc h ed u lin g policies u se d by reso u rce
m anagers, and the intrinsic characteristics of the activity.
15
e
sw
4
a i s j sd c cd
/scheduling! execution
: window \ time
arrival / start
time I time
completion
time
ready
time
(i.e., first
start time)
scheduling
deadline
time
(i.e., last start time)
completion
deadline
time
(Figure 2-3: Time Instants Relationship of Activity a^ For the n^1 Iteration of the i ^
Monitored Process
In the n th iteration of the loop show n in Figure 2-2, let:
i = i.d. for a m onitored process;
n = iteration;
a j<= activity;
sdi,ak,n = the Scheduling Deadline by which activity fljt for the i**1 monitored process
must begin execution;
si,ak>n ~ Starting time, i.e., actual time that activity afc for the i ^ monitored process
begins;
e ifik,n ~ the Execution time of activity afc for the i ^ monitored process;
ci,ajfc,n = the Completion time, i.e., the time at which activity for the i ^ monitored
process completes.
16
In each iteration, processing for the i* * 1 m onitored process consists of
a set of activities. Each of the follow ing is an activity of MTT.
(a-L ) p o sitio n in g an ten n as for sam p lin g in fo rm a tio n p rio r to tim e
s d , > l r „ (based on the estim ated p red ictio n of th e state of the
m o n ito re d process from o b serv atio n o b ta in e d in th e (i-l)tb
iteration);
(a2) collecting m easurem ent d ata w hich w ere p lan n ed to be sam pled
by tim e sdj ^ n b u t actually sam pled at tim e );
(a3) p rep ro c essin g m easu rem en t d a ta to form o b serv atio n s (e.g.,
perform ing Fast Fourier T ransform ation);
(a4) u sin g gating techniques (i.e., se le c tin g to c o rre la te th e
observations from m easurem ent obtained at tim e cir a2,n w ith the
tracks in w hich states w ere predicted in the (i-l)th iteration);
(as) p erfo rm in g data association to initiate, confirm , or delete tracks
for these observations;
(a6) determ ining sdi^jn+j), (i.e., the tim e after w hich the inform ation
obtained in the n th iteration w ill bfc invalid), and predicting the
associated tracks' state at tim e sdir ajr(n+i);
(a7) defining gates (i.e., a range of allow able u n certain ty for state
inform ation) for correlation in the next iteration.
To su m m arize the characteristics of th e co m p u tatio n al flow and
m o n ito red processes d escribed above: (i) th e m o n ito red processes can
change state at any time; (ii) the m ethods used to interrogate the state of
m o n ito red processes m ust u se the m ost recent in fo rm atio n (such as the
physical position of the sensor system relative to the m onitored processes,
velocity, etc.) w hich is obtained via other in p u t devices; (iii) the execution
tim e of a sensing activity d ep en d s on the interrogation m ethod and the
17
predicted state in the n th iteration (com puted in the (n -l)th iteration); and
j(iv) the com puted inform ation an d the p redicted state of th e 'm onitored
processes' in the (n -l)lh iteration are only valid for a lim ited in terv al of
j
tim e. It is not useful to schedule an activity before th e req u ired d ata for
|
executing the activity is available. Sim ilarly, there is also a deadline beyond
w hich execution of the activity has little or no value. T hese intrinsic
properties lead to the notions of adaptive activity and scheduling window.
In the classical, h ard real-tim e com putational m odel, consisting of
periodic and sporadic tasks, a periodic activity has a constant interval length
!
b e tw ee n tw o successive re a d y tim es. A sp o ra d ic a c tiv ity h as an
unpredictable ready time. The com pletion deadline of all activities (periodic
jand sporadic) is the sam e as the next ready time. In m y m odel defined in
C hapter 3, an adaptive activity has a ready tim e w hich is a function of the i
p rev io u s ready tim e. All activities (adaptive, periodic, an d sporadic) m ust
I
be sch ed u led before a co m p u ted sch ed u lin g deadline. The com pletion
deadline m ay be earlier then the next ready time.
18
2 .2 . SURVEY O F EXISTING SPECIFICA TIO N APPROACH
This section w ill com pare four CASE (C om puter-A ided Softw are
E ngineering) system s w hich are targ eted to su p p o rt the specification of
j
'requirem ents and the design of real-tim e system s. The com parison presents
th e relativ e stre n g th s an d w eaknesses of each system w ith a d d itio n al
inform ation on the u n d erly in g com putational m odel, graphical notations,
the supported analyses, and their recom m ended use.
The CASE system s com pared are:
• T eam w ork from C adre Technologies Inc.
• C A R D Tools (C o m p u ter-A id ed R eal-T im e D esign Tools) from
R eady System s
• Statem ate from i-Logix
• RDD -100 (R eq u irem en t D riven D esign) fro m A scen t L ogic
C orporation.
A m ong existing CASE system s, th ese fo u r tools rep re se n t four
different design approaches. Teamwork p ro v id es the design m ethods, the
m odeling approaches, and the specification notations w hich are com m only
su p p o rte d by o th er com m ercial CASE system s. CARDTools p ro v id es
sim ilar capabilities as Teamwork except a d d in g task m ap s an d tim ing
analyses. Statemate also provides sim ilar capabilities as T eam w ork except
th a t (1 ) state tra n sitio n d iag ram s are rep la ce d w ith sta te c h a rts (i.e.
h iera rch ica l sta te tra n sitio n d ia g ra m s a u g m e n te d w ith co n cu rren cy ,
com m unication, etc. concepts) and (2 ) it in clu d es som e functional an d
19
behavioral correctness verification and validation capabilities. The design
■methods and design notations supported by RDD-100 are distinct from other
|CASE system s. H ow ever, its u n d erly in g m odel is m o re expressive for
■representing the time sequence and concurrency of real-time computations
‘ and their inputs and outputs. From th e specification p o in t o f view , RDD-
1 0 0 is m ore appropriate for the specification of requirem ents and design of
■real-time system s.
O ne key factor to characterize a CASE system is the class of models
[which can be specified via th e notations p ro v id ed by the system . The
■information w hich is representable by the m odels reveals the strengths and
the w eaknesses in specifying and analyzing the behavior, the requirem ents,
and the constraints for real-tim e com putations. For exam ple, the tasking
map of CARDTools provides the basis for (i) the design an d analyses of the
synchronization and com m unication betw een tasks; (ii) the design, analysis,
and validation of specifications of w orst-case tim ing of task s. Task m aps are
constructed from data-flow diagram s [Schindler87]. D ata-flow diagram s are
in h e rita n tly in ca p ab le of d e scrib in g th e c o n d itio n a l seq u en ces an d
concurrency of d ata transform s [Alford et al 85] and therefore so are task
m aps. A lthough task m aps can describe precedence relationships betw een
tasks, som e properties (such as detailed tim ing characteristics, conditional
predecessors, conditional successors, etc.) can not be expressed. Therefore,
the perform ance analyses w hich can be perform ed in CARDTools are crude.
20
2 .2 .1 . COM PARISON CRITERIA
M y com parison criteria are: (i) form al fo u n d atio n s, (ii) sem antic
so u n d n e ss of th eir co m p u tatio n al m odels, (iii) g rap h ic n o tatio n s, (iv)
perform ance design, (v) correctness analysis and validation techniques, (vi)
reusability, an d (vi) m aintainability.
F orm al F oundations
]
The "form al foundation" of a CASE system refers to the basic form al
m odels p ro v id ed designers to a b strac t the behavior of real-tim e softw are.
D ifferent system s m ay use the sam e u n d erly in g form alism b u t p resen t
different user interfaces. The theoretical lim itations is a function of these
u n d erly in g form al m odels. W hile very im p o rtan t in a practical sense, the
u ser interface p resen tatio n does n o t change the theoretical p o w er of the
system . Functional decomposition an d finite state automata are exam ple
form alism s.
Sem an tic Soundness o f Their C o m p u ta tio n a l M odels
A c o m p u ta tio n m o d el describes th e functions, the enab lin g and
exiting conditions, inputs, an d o u tp u ts of each function, the relationships
am ong functions (such as precedence, concurrency, etc.), and th e required
resources (including processors and m em ory). As real-tim e softw are's role
is to im p lem en t b o th th e functional a n d p erfo rm an ce req u ire m e n ts, a
c o m p u ta tio n a l m o d e l for re a l-tim e s o ftw a re m u s t c a p tu re th ese
characteristics for real-tim e system s. In so m ew h at m ore d etail, these
characteristics are sum m arized as follows:
. 21
cl: C om plex, highly parallel, and highly frequent interactions w ith its
e n v iro n m e n t
c2: Rigid perform ance requirem ents
!
c3: Stringent physical resource constraints
c4: H eterogeneous m ultiprocessors architecture
j
c5: Sequencing and tim ing of inputs an d o u tp u ts p artially determ ined
by its environm ent
c6 : A dherence to functional correctness and tim ing correctness
i
c7: Long system life span
c8 : O perability in norm al and degraded m ode
c9: Inability to be tested and integrated in the operational environm ent
A c o m p u ta tio n a l m o d el fo r re a l-tim e sy ste m m u st c a p tu re
inform ation listed above except c7 and c9. A CASE System m ust su p p o rt the
m a in ta in a b ility a n d reu sab ility of d esig n s a n d p ro v id e facilities for I
analyzing and v alid atin g designs to su p p o rt arg u m en ts c7 and c9. The
tim ing specification is a p articu la rly im p o rta n t issu e in specifying the
requirem ents an d design of real-tim e system s. Real-tim e softw are is tim e-
Jdependent and resource-dependent, specifically:
(1) th e ex ecu tio n tim e re q u ire d for a p ro cess to h a n d le an ev en t
associated w ith a m onitored object d ep en d s on the event type and
the am ount of data to be processed.
22
(2 ) the frequency of activation of a softw are process, w hich m onitors
occurrences of events associated w ith an object, d ep en d s on the state
and the dynam ic priority of the object and other activities, etc.
(3) the com putation accuracy required for a m onitored object depends
on the age of d ata to be processed; to have a co m p u tatio n result
I
j w ith in a specified accuracy, the associated d a ta lifetim e can not
exceed an u p p e r bound; th e perform ance specification includes a
j sta te m e n t of c o m p u tatio n accuracy req u ire m e n ts; th e in trin sic
tim ing characterization of softw are processes is deriv ed from this
specification.
(4) processes are dynam ically ad d ed or deleted, based on the num ber of
the m onitored or controlled objects and their states in the external
environm ent; and
(5) the physical resources available for com puting are constrained by the
un d erly in g h a rd w are architecture; these resources are u sually not
sufficient to avoid contention for use of these resources; therefore
resource allocation is based on specified criteria, such as the age of
data, priority, and available resources.
W h en th e CASE to o ls d o n o t a d e q u a te ly s u p p o r t tim in g
specifications, the design specification is incom plete and it is essential that
tim ing inform ation is captured in the com putational m odels used in design
specifications.
A n objective of com putational m odels is to rep resen t th e functional
(such as w h a t functions so ftw are is su p p o sed to p ro v id e, th eir static
23
relatio n sh ip s, etc.), behavioral (such as h o w the softw are interacts w ith its
external en v iro n m en t an d how in tern al functions interact), and temporal
(such as w hen functions are to be triggered, how long functions are allow ed
to co m p u te, etc.) properties of software. T herefore th e a rg u m e n ts for
m o d e lin g p a ra lle l p ro g ra m s w ill be a p p lica b le to be a d a p te d for
co m p u tatio n al m odels. T hus I w ill a d a p t those arg u m en ts id en tified in
([Baer73], [K arp& M iller67], [K arp& M iller69], [Pratt83], [Estrin et al 8 6 ],
[Gomaa84], [Stotts8 6 ]) for com putational m odels. ([Baer73], [Karp&Miller67],
[Karp&M iller69], [Pratt83], [Estrin et al 8 6 ], [Gomaa84], [Stotts8 6 ]) analyzed
p a ra lle l p ro g ram s by usin g parallel program schemata in w hich three
aspects of com putations are represented: (1 ) the d ata to be m anipulated; (2 )
j
the se q u en tial (su b )p ro g ram s w hich m anipulate data; and (3) the c o n tro l j
s tru c tu re w hich govern the allow ed parallelism an d in teractio n s of the
sequential program s. The d ata to be m an ip u lated are expressed by a data
model in w hich the com position and perm issible values of th e d ata to be
m an ip u lated are defined. The sequential (sub)orogram s are expressed by a
I static program model in w hich the com position of th e basic blocks is
expressed. The control structures are represented by a control flow model in
w hich th e d y nam ic n a tu re of th e softw are is cap tu red . I a d o p t this
classification of the aspects of a com putational m odel, b u t th e discussion
w hich follow s on each aspect will address the representational requirem ents
for describing the characteristics of real-tim e system s specifically.
A data model for real-tim e system s, in ad d itio n to static d ata types,
■must allow representations of parallelism an d the tem poral p ro p erties of
data (input and output) sequences. As indicated in Table 2-A, the notations
24
•for rep resen tin g d a ta m odels should p ro v id e for rep resen tatio n of tim ing
c o n s tra in ts sp e c ific a tio n , tim e se q u e n c e s, c o n d itio n a l se q u e n c e s,
concurrency, m ultiple instances of the sam e type, and com positions of in p u t
an d o u tp u t d a ta item s d u e to the com plex, h ig h ly p arallel, an d tim e
sequenced interactions of a real-tim e system w ith its environm ent. The
d ata m odels p ro v id e d by m ost existing CASE system s do n o t su p p o rt
•representation of parallelism and the tem poral properties in d ata m odels.
E x p r e s s ib le P r o p e r tie s
i n D a t a M o d e l s
C h a r a c t e r is tic s o f
R e a l- T im e S y s t e m s
C o m p o s it io n c l , c5
C o n d it io n a l S e q u e n c e s
c l , c5
P a r a lle l S e q u e n c e s c l , c5
M u lt ip le I n s ta n c e s o f T h e S a m e T y p e c l , c 5
T im in g S p e c ific a tio n c l , c 2 , c 5 ,c 6
Table 2-A: Required Properties of Notations for Representing Data Models
A control flow model for real-tim e sy stem s m u st p ro v id e , in
addition to static structures for describing calling sequences, structures for
re p re se n tin g p a rallelism , com m unication, sy n c h ro n iza tio n , an d tim in g
p ro p erties of functions (for processing) sequences sh o u ld be p ro v id ed .
I
Table 2 -B, sum m arizes the notations for representing control flow m odels
req u ire d to p ro v id e rep re se n ta tio n s for tim in g , co n d itio n al sequence,
concurrency, co o rd in atio n , com m unication, en ab lin g conditions (for c6 :
adherence to the functional and tim ing correctness), term inating conditions
Tor c6 an d c8 : o p e ra b ility in n o rm al an d d e g ra d e d m odes) , an d
com position of functions.
25
Expressible Properties
in Control Flow M odels
Characteristics of
Real-Time System s
Composition
cl,c5
Conditional Sequences
cl,c5
Parallel Sequences cl,c5
Multiple Instances of The Same Type cl,c5
Timing Specification cl, c2, c5, c6
Enabling and Exiting Criteria c6, c8
Table 2-B: Required Properties of Notations for Representing Data Models
The static p rogram m odel for a real-tim e system , in ad d itio n to the
static interconnections betw een program s (calling and caller relationships),
'should specify the stim u lu s an d response p ro p erties, th e state change
properties, and the tem poral properties in a (sub)program . Table 2-C depicts
the required properties of the notations for representing static program s.
E xp ressib le P roperties
in Static program M o d e ls
C haracteristics o f
R eal-T im e S y stem s
Stim u lu s and R esp on se R elationship
£ 6
State C h anges
c6, c8
T im ing Specifications
c6
Interconnections B etw een Program s
c6
V alidation P oints and Criteria
c6, c9
Table 2-C: Required Properties of Notations for Representing Static Program Models
Sem antic soundness addresses how tightly the design specifications
capture the designer's system concept and how closely the control structures
expressed in the design specification b in d to the control constructs in the
p ro g ra m s. T he co m m o n ly u se d d a ta flo w m o d e l is an ex am p le
26
jC o m p u ta tio n a l m o d e l w it h w e a k s e m a n tic s . T h e d a ta f lo w g r a p h in F ig u r e
2-4 w hich contains tw o processes and one data store.
a
s
Figure 2-4: An Example Model With Weak Semantics
T he sem antics of a d ata flow g ra p h does n o t clearly define the
'relationship betw een tw o in p u t sequences ("a" an d "b") an d th e o u tp u t
leq u en ce ("c") of process "X”. In this exam ple, X m ight require a single "a"
and a single "b" to produce one "c"; X m ight require m "a's" and n "b's" for
each "c".; X m ight require "a" follow ed by "b"; etc. "X" and "Y" m ay have to
execute concurrently d u e to perform ance constraints b u t the data flow graph
only specifies th at "Y" processes data produced by "X". The sharing of "s"
im p lies th a t sy n ch ro n izatio n is req u ire d d u e to th e c o n ten tio n of "s"
betw een "X" an d "Y". But the sharing of "s" m ight n o t cause contention
w hen (1) "X" requires "a”, "b" an d "s" to p ro d u ce "c" and (2) "Y" requires
only "c" to pro d u ce "d". O n the other hand, "s" m ay cause contention w h en I
(1) "X" requires tw o "a's", tw o "b's", and one "s" and (2) "Y" requires one "c"
and produces "d" an d "s". A lot of variations of tim ing and sequencing of
'input an d o u tp u t d ata an d processing tim e for "X" an d "Y" can n o t be
represented. The resu ltan t specifications for requirem ents and design are,
therefore, incom plete.
27
O ne m ight think the strongest sem antics w ould be the m ost desirable
since the concise sem antics w ill b etter su p p o rt autom atic v alid atio n by
either sim ulation or form al verification. As an exam ple, the sem antics of
Statechart in Statem ate is form ally defined. T here are, how ever, tradeoffs
that have to considered. Strong sem antics are u sually very m athem atical
in n a tu re an d req u ire a longer learn in g process. A lso, a considerable j
am ount of effort is required to express the design specification. Further, the
specifications are often n o t easily m odifiable. For a sm all system w ith
com plex behavior, the tight sem antics will enable autom ated tools to verify
the design specification. O n the other hand, w eak sem antics tend to allow
t
p ro g ram m ers too m uch freedom to in te rp re t th e m ean in g of a design
specification. If the coding is to be done by a large group, then a sem antically
w eak rep resen tatio n can be dangerous. For sm aller g ro u p s, w ith good
com m unication channels a less rigid sem antic stru ctu re w o u ld be easier to
accom m odate.
G raphic N o ta tio n s
G raphs are useful for com m unicating relatio n s (by arcs) betw een
objects (nodes). This v isu alizatio n of relatio n sh ip s is a m ore clear an d
I
efficient w ay th an tex t for com m unication w h en it is a p p lic a b le . As a
consequence, an overview of the system can be form ed in a shorter tim e.
G rap h notations (just like a textual language) have syntax an d sem antics.
W hen th e concept associated w ith a g rap h ic n o tatio n is n o t n a tu ra l or
fam iliar to the users or the review ers or w hen there are too m any different
types of grap h ic notations, an ad d itio n al b u rd e n of learn in g a pictorial
28
lan g u ag e w ill be required. F urtherm ore, w h en the sem antics of graphic
notatio n s are o v e rlo a d e d , the specified system is difficult to u n d erstan d .
Then, English descriptions m ust accom pany the graphic specification.
The graphic notations in Statem ate are an exam ple in w hich there is
a lot of sem an tic in fo rm atio n in th e g ra p h m o d el b u t it's g o tte n so
com plicated th at u n d erstan d in g has to be com m unicated by text. Sym bols
(such as triggering events and conditions) used in the statecharts are defined j
in form s or tables. T herefore a sim ple sym bol used to specify a triggering I
conditions m ay rep resen t a set of com plex conditions; as a result, in order i
for a review er to u n d erstan d the Statechart it m ust be an n o tated w ith text
d escrip tio n s. O n one h a n d , S tatecharts in d eed p ro v id e a vehicle for
an aly zin g and v alid atin g stim ulus-response p ro p erties, b u t on th e other
h an d the designers can not quickly com m unicate an overview of the design
to review ers w ith o u t text descriptions accom panying the graphic design.
W hen the sem antics of g raphic notations are u n d e rd e v e lo p e d , the
designer can not concisely com m unicate w ith review ers. As a consequence,
properties of the system are partially represented, an d again text description
m u st accom pany the graph ic specifications. A n exam ple in w hich the
g rap h m odel is sim ple b u t doesn’ t specify enough (so text is used to specify
th e rem ainder) is the d ata flow diagram w hose w eak sem antics has been
discussed in the previous section an d illustrated in Figure 2-4.
Perform ance D esign
T his area a d d re ss e s th e d e g re e to w h ic h c o n sid e ra tio n s of
com putational accuracy and response tim e are integrated into the graphic or
29
textual notations of the CASE system . The consideration of com putational
accuracy on the surface doesn't seem to be a perform ance issue. H ow ever,
the com putational accuracy requires d ata to be processed w ithin a certain
tim e p erio d an d therefore tran slated into response constraints. O ne m ay
tradeoff com putational accuracy for response tim e, for exam ple processing
d a ta less often b u t sp e n d in g m ore cycles each tim e to pro cess m ore '
accurately. In real-tim e system , som e d ead lin es for resp o n se tim e and
accuracy requirem ents for com putations m ust be m et.
A lthough real-tim e softw are usually can not be tested or integrated in
its o p e ra tio n a l e n v iro n m e n t, th e p e rfo rm a n c e m u st, th e re fo re , be
g u aran tied by analysis and not rely on testing in operational environm ent.
By ex p erim en tin g w ith different scheduling techniques or w ith different
designs, a designer can analyze the feasibility of m eeting the tim ing and
accuracy req u irem en ts. H ow ever, m ost CASE system s do n o t p ro v id e
sufficient facilities to allow perform ance analysis in enough detail. O ften
m issing feature are for exam ple, (1 ) the ability to specify the m ap p in g of
tasks to processors, (2 ) specification of scheduling or checking if the specified
scheduling policies satisfy the required tim ing constraints.
As an exam ple, the tim e-out m echanism of Statem ate is a prim itive
approach for specifying tim ing constraints; how ever, the sim ulation facility
does not allow representation of resource contention (i.e. it assum es infinite
h a rd w a re resources). A nother exam ple is th e su p p o rt for perform ance
validation in CARDTools. It does a reasonable job, b u t it is tailored to a
p articu lar op eratin g system and the analyses are prim itive. It allow s the
static allocation of functions to logical processes (tasks). A designer can
30
specify the m apping of logical processes to physical processors for real-tim e
sc h e d u lin g , b u t C A R D Tools does n o t allow th e d e sig n e r to specify
scheduling rules. The tim ing analyses are b ased on: (1) th e p re e m p tiv e
scheduling policy of the Ready system 's operating system kernel (VRTX) for
e ith e r th e M IL-STD 1750A a rc h ite ctu re o r th e M o to ro la MC6800X0 j
m icro p ro cesso r fam ily an d (2 ) th e w o rst-c a se tim e -lin e of a selected ]
com putational path by incorporating the operating system overheads caused ■
i
by resource co ntentions (such as bus, processors, etc.), sch ed u lin g and I
l
in te rru p t latency, an d com m unication. i
For perform ance design, the functionality req u ired from a design-aid j
environm ent can be sum m arized as: i
i
(1 ) algorithm s for analysis of proposed design, (for exam ple, analyses of
design p artitio n in g w hich divides th e so ftw are functions (at the
algorithm ic level) into tasks; analyses of feasibility of m eeting tim ing
req u ire m e n ts for a specified set of t^sks, a specified h a rd w are
architecture, and selected scheduling strategies; etc.)
(2 ) algorithm s for syntheses (i.e. perform ing p a rt of design), (for exam ple,
p artitio n in g the specified softw are functions in to tasks; selection of
m apping of tasks to processors or choosing scheduling strategy; etc.).
Correctness A n a ly sis and V alidation Techniques ^
1
I
A nalysis an d v alid atio n include: (i) syntactically an d sem antically j
I
checking and analyzing the m odel specification; (ii) d eterm in in g liveness
an d safety properties such as deadlocks, livelocks, etc. through, for exam ple
31
reachability analysis or sim ulation of the specified m odel; and (iii) checking j
I
for co n sisten cy w ith p e rfo rm an c e c o n stra in ts (in clu d in g tim in g an d
capacity).
R eu sability
R eusability m eans that products of one project can be reused on other
projects. In developing real-tim e system s, reuse of code m odules is of great
im portance. To be able to reuse code m odules in a new system , not only
m ust the interfaces (input and output) be respected, b u t the m odules tim ing
a n d accuracy beh av io r m u st m eet th e co n strain ts of th e n ew system .
Sim ilar concerns are also valid for reu sab le designs. Facilities for the
I
m anagem ent an d search of stored libraries of reusable com ponents (design !
or code) are essential to su p p o rt reusability. The m ain focus of reusability in
this com parison is the reuse of requirem ent and design specifications.
M a in ta in a b ility
\
i
This refers to th e ability to accom m odate changes in req u irem en ts
and design specifications. These changes m ay occur du rin g any phase of the
life cycle. Since real-tim e system s w ill h av e a v ery lo n g life sp a n ,
requirem ents are likely to change. Therefore, a CASE system m u st su p p o rt
m aintainability in all phases that it supports.
32
2 .2 .2 . TEAM W ORK FROM CADRE TECH N O LO G IES INC.
F orm al F ou n dation s
T eam w ork like o th er CASE tools is based on the Structured Design
method [M yers76, Y o u rd o n & C o n stan tin e7 8 ], th e Structured Analysis
method [De M arco78] (SD /SA ) an d H ately an d W ard-M ellor's extensions
[Hatley84/ W ard& M ellor85, W ard 8 6 ].
SD and SA are data-flow -oriented m ethods w hich are geared tow ard
D P (D ata Processing) ap p licatio n s. The goal of th ese m eth o d s is to
l
sy ste m atica lly stru c tu re so ftw are w hich is v iew ed as b lack box for j
transform ing inputs into outputs. [Cerf72] proposed a directed grap h m odel '
w hich uses nodes and arcs to specify both control flow s and d ata flow s of
c o m p u tatio n s. But th e concept of u sin g g ra p h m o d els to re p re se n t
com putations in softw are w as popularized by Y ourdon and De Marco. The
graphical rep resen tatio n for describing softw arp behavior is the d a ta -flo w
d iag ra m (D F D ) w hich is know n as Y ourdon-D eM arco d ia g ra m (or G an e-
S a rso n c h a rts) in th e CASE w orld. W ard-M ellor or B oeing-H atley
methodologies [H atley84, W ard& M ellor85, W a rd 8 6 ] are extensions to
S D /S A w ith c o n tro l f lo w s /n o d e s and s ta te -tra n s itio n d ia g ra m for
representing control flow structures of softw are.
The S tructured D esign m ethod consists of tw o sets of criteria and tw o
desig n approaches. The tw o sets of criteria, cohesion an d coupling, are
defined for evaluation of the quality of a design. The tw o design approaches
are: Transform Centered Design an d Transaction Centered Design. The
T ransform C entered D esign ap p ro ach is applicable w h en the d a ta flow
consists only of (passive) d ata inform ation. The stru ctu rin g of a system is
based on the d a ta flow s in the system . W ith this m ethod, d ata flow s are
d e riv e d by identifying (1 ) external in p u ts an d th eir tran sfo rm atio n s, (2 )
external o u tp u ts and their transform ations, and (3) the correlations betw een
in p u t stream s and o u tp u t stream s. Each m ajor in p u t stream , an d each I
m ajor o u tp u t stream , and each m ajor transform corresponds to a branch in |
the structure chart (i.e. a tree in w hich nodes represent (sub)program s, arcs
rep resen t invocations, and labels represents data flows; program s at level i
call those program s w hich are at level (i+1 ) w hen they are connected by
arcs). The Transaction C entered D esign m ethod is applicable w hen the data
flow consists of data or control inform ation. This inform ation m ay trigger a
chain of actions, an d each action is re p re se n te d by a tran sfo rm . The
S tructured A nalysis m eth o d [ DeM arco78, Gane79] uses data flow diagram s. I
a d a ta dictio n ary , an d h ierarch ical d e co m p p sitio n of tra n sfo rm s: th is
m ethod is com m only used together w ith the S tructured D esign m eth o d . In
this m eth o d , d ata flow diagram s describe the functions (transform s) of a
system , the d ata flow betw een functions, and the d ata stores accessed by
functions.
N eith er m ethod has an underlying m odel for expressing parallelism ,
tem poral properties of data and control, com putational accuracy, sequencing
properties of in p u t data an d o u tp u t data. Also neither provides guide-lines !
34
for decom posing a system into sub-com ponents executing sim ultaneously.
Thus they are not sufficient for design of real-tim e system s.
Sem an tic Soundness o f Their C o m p u ta tio n a l M o d els
The ap p ro ach taken by T eam w ork to im plem ent each aspect of its
underlying m odel is as follows.
<
• data m odel: entity-relationship m odels (ERMs) and d ata dictionary j
are used; j
i
• control flow m odels: d a ta /c o n tro l flow diagram s (w hich m ay be
augm ented w ith P-specs) and finite state m achine (w hich m ay be
rep resen ted by state transition diagram (STD), state event m atrix
(SEM), process activation table (PAT), or decision table(DT));
• static p ro g ram m odels: stru ctu re charts (SCs) and M _specs are
used.
1
I
A CASE system m ust describe the d ata involved in the com putations.
i
For this p u rp o se, a d ata m odeling form alism is required. M ost existing
CASE tools use the Entity- Relationship model fC hen80] (ERM) to describe
the data. I begin by briefly review ing this m odel and later show th at it is not
sufficient for real-tim e system CASE tools.
ERM is set-o rien ted , i.e. it m odels relationships betw een sets and the
m e m b ersh ip p ro p e rty . Entity rep resen ts a "thing" th a t exists a n d is
d istin g u ish ab le. T he p ro p erties of an en tity are called attributes . The
values of each attribute are from a defined domain . U sually, the dom ain
for an attribute w ill be the set of integers, real num bers, or character strings.
In an en tity set, an attrib u te or set of a ttrib u tes w hose values uniquely
35
. , 1
i d e n t i f y e a c h e n t i t y i n a n e n t i t y s e t i s c a l l e d a key o f t h a t e n t i t y s e t . A
relationship am ong entity sets is an ordered list of entity sets. If there is a
relatio n sh ip , REL, am ong en tity sets E j, E2, Ek, th en a set of fc-tuples
n am ed REL, called a relationship set, exists. Each k-tuple (el7 e2, ek) is in
set REL; ex is in E lr e 2 is in E2, ..., and ek is in Ek. is a is a "built-in"
relationship. For exam ple, "A isa B" ( read "A is a B,") if entity set B is a
generation of entity set . For exam ple, to m odel "subcontractor w orks for
b uilder, an d bu ild er follow s architect's plan.", it w ill need three entity sets:
"su b c o n tra c to r", "b u ild er", a n d "arch itects_ p lan "; tw o re la tio n sh ip s:
”w orks_for” and "follow s”. The three classes of relationships are described
as follows:
• o n e -to _ o n e : The one-to-one relatio n sh ip w hich m eans th at for
each entity in either set there is at m ost one associated m em ber of
the other set. For exam ple, there are tw o entity sets EMPLOYEES
a n d D EPA RTM EN TS; th e re la tio n sh ip H E A D _O F b e tw ee n
EM PLOYEES a n d D EPA RTM EN TS is o n e -to -o n e if each
d e p artm en t has only one head and each p erso n can only be the
head of one departm ent.
• m a n y -to -o n e : W hen Ej and E2 has m any-to-one relatio n sh ip , it
m eans th at each entity in E2 is associated w ith zero or m ore entities
in Ej and each entity in E! is associated w ith at m ost one entity in
E2. For exam ple, COURSES and TEACHERS has m any-to-one
relationship for the T A U G H T B Y relationship.
• m any-to-m any: W hen Ej and E2 has m any-to-one relationship, it
m eans each entity in E2 is associated w ith zero or m ore entities in
E! and each entity in Ej is associated w ith zero or m ore entities in
E2. For exam ple, the EXPORTS relationship for COUNTRIES and
PRODUCTS has a m any-to-m any relationship.
36
T a b l e 2 - D s u m m a r i z e s t h e p r o p e r t i e s o f d a t a r e q u i r e d i n a r e a l - t i m e
j
CASE tool an d th e degree to w hich it can be m o d eled b y an E ntity- ;
R elationship M odel (ERM).
D esired Properties
in Data M odels
Expressiable Properties
in Entity-R elationship M odels
C om position
• attributes describe properties of
each entity in a entity set.
• sub-entity or super-entity can be
defined.
• attributes are not decom posable.
C onditional Sequences
• the entity-relationship m od el is set
oriented.
• it is very difficult to express the
sequence relationships betw een
entities.
• can define conditional relationship
b etw een tw o entity sets
Parallel Sequences
• can express that an entity in entity
set E l is parallel w ith an entity in
entity set E2.
• can't express the parallel sequence
r ela tio n sh ip .
M ultiple Instances of The Sam e Type
• an entity set effectively expresses
this.
T im ing Specification • no support.
Table 2-D: Information Which Can Be Modeled By the Entity-Relationship Model
A CASE system m u st also describe the functions involved in the
com putations. For this purp ose, a control flow m odel is required. M ost
existing CASE tools use th e Data Flow Diagram (DFD) a n d the State
Transition Diagram (STD) to d e sc rib e th e fu n c tio n s a n d th e ir
interrelationships. I begin by briefly review ing this m odel and later show
th at it is not sufficient for real-tim e system CASE tools.
A DFD is a netw ork of nodes w hich are connected by arcs; a no d e
rep resen ts a process w hich takes a set of in p u ts and tran sfo rm s a set of
o u tp u ts; the processes in DFD are decom posable; a process rep resen ts a
j partial function (i.e. not each set of in p u ts w ill p roduce an o u tp u t; this has
1
'been illustrated in Figure 2-4) w hich corresponds to a partial com putation to
be perform ed by a system . This is based on th e specification concept th at a
system can be m o d eled as a h ierarch y of fu n ctio n s. A function can be
considered as a black box w hich transform s a set of inputs to o u tp u ts w ith
rules for transform ation.
The specification process starts from identifying a system function
w hich has a set of all possible inputs (w hose values com e from som e in p u t
dom ain) an d has a set of all possible o u tp u ts (w hose range from som e
o u tp u t dom ain). This system function is then decom posed into a collection j
i
of interacting functions. The interactions betw een functions are rep re se n te d
by m eans of d ata flow s an d control flo w s. This m o d elin g ap p ro ach
basically treats a n o d e as a m athem atical function which:
• is not an algorithm ; how ever, a function can be specified w ith an
alg o rith m ;
• can be decom posed; and
• is m em oryless.
N o t only can functions be decom posable, b u t also in p u ts and o u tp u ts
are decom posable. The fundam ental deficiencies of using DFD to represent
th e control flow m o d el in clu d e (1 ) p a ra lle lism an d o rd e rin g of d a ta
sequences of in p u ts and o u tp u ts are not expressed; an d (2 ) concurrency and
38
sequencing of processes (com putations) are not expressed (w hich has been
illu stra te d in F igure 2-4). M ost co m p u tatio n s in real-tim e system s are
req u ire d to in teract w ith the external en v iro n m en ts in h ig h ly com plex,
jfrequent, and parallel fashion, and each interaction d ep en d s on the current
(state of com putations and the previously co m p u ted results (w hich im ply
th at each process is required to rem em ber the state of com putations). Each
node of a DFD is view ed as a function (transform ation) an d therefore is
m em o ry less; th ereafter DFDs are m em oryless. W ith th e deficiencies of
im em oryless and inability to express parallelism and sequence of processes
and their in p u ts an d o u tp u ts, DFDs alone are not sufficient for describing
real-tim e com putations.
I
i
M ost CASE tools au g m en t DFDs w ith state-transition diagrams (i.e.
finite state m achines or FSMs) for supporting real-tim e system design. The
p u rp o se is to ad d ress (1) the m em oryless p ro b lem of DFDs an d (2) the
inability of representing the parallelism and o rd erin g of d ata sequences of
'inputs an d o u tp u ts. H ow ever, a finite state m achine has th e follow ing j
properties: (1) it accepts one in p u t sym bol at a tim e; (2) the transitions for
jeach com bination of state and in p u t sym bol m u st be defined; and (3) it has a
flat (non-hierarchical) structure.
FSMs are used m ost often to m odel the above properties for relatively
sm all p arts of the system . H ow ever, a system is m ade u p of a large num ber
of such com ponents. The FSM approach quickly becom es im practical as one
attem p ts to encom pass m ore and m ore of the system . These are three m ain
problem s: (1) the state space cardinality grow s as th e p ro d u ct of the state
39
space cardinalities of th e com ponents; (2) sequencing constraints such as
th o se re su ltin g from p rio rity sc h ed u lin g , sy n c h ro n iz a tio n , in te rru p t
h andling, etc. can be represented only im plicitly th rough the set of allow ed
state transitions; and (3) only sim ple tim ing constraints can be represented
im plicitly th ro u g h the set of allow ed state transitions resu ltin g from tim e
o u t th ro u g h th e set of v irtu a l clocks. T hese p ro b lem s in d ic ate the
com plexity and cum bersom eness of using FSM for representing sequencing
an d tem poral behavior of real-tim e system s of any practical size. This not
only im plies difficulty in constructing the m odel, but also indicates it is not
useful for com m unicating the design requirem ents to designers. !
alarm
dock
time
alarm
time
/clo ck
time
Data
Flow
Diagram
check
alarm
stop
alarm
alarm
expired
^
alarm
reached
C-Spec sound ali
STD
alarm set
Figure 2-5: An Example of Ambiguous Control Structures
F ig u re 2-5 show s an exam ple of a d a ta flow w ith am b ig u o u s
specifications of concurrency and sequences for both d ata an d processes. For
exam ple, it does not state (i) if "check alarm " accepts "alarm tim e" an d
"clock tim e"; (ii) if "check alarm " accepts "alarm tim e" or "clock time"; (iii)
40
if "check alarm " accepts "alarm time" after "clock tim e"; or (iv) if "check
alarm " accepts "clock time" after "alarm time".
To com pletely describe the relationship betw een "check alarm " and
"stop alarm ", all possible com bination of states an d possible transactions
'should be identified, and a state transition diagram constructed accordingly.
iTable 2-E lists the properties of control structures w hich are rep resen ted by
d a ta /c o n tro l flow diagram s and state transition diagram s.
Desired Properties
in Control Flow Models
Expressible Properties
by Data Flow Diagram and
State Trnasition Diagram
Composition a hierarchy of transforms
Conditional Sequences not expressible
Parallel Sequences
identify all possible states of each
transforms; then construct STD with
all combinations of these states.
Multiple Instances of The Same Type not expressible
Timing Specification
not expressible
Enabling and Exiting Criteria use PAT (Process Activation Table)
Table 2-E: Properties Which Can be Modeled Data/Control Flow Diagrams ;and
State Transition Diagrams
A CASE system m u st also describe th e alg o rith m s in v o lv ed in
im p lem en tin g functions. For this p u rp o se , a static p ro g ram m odel is
required. M ost existing CASE tools use the Structure Chart (SA) to describe
the algorithm s an d their interrelationships.
41
Desirable Properties
in Static program Models
Expressible Properties
Stimulus and Response Relationship
• use PDL (Program Description
Language) to specify in M-Specs.
State Changes
• use state variables to express
them in M-Specs.
Timing Specifications • not supported.
Interconnections Between Programs
• INVOCATION lines between
modules represent this property.
Validation Points and Criteria • not supported.
Table 2-F: Properties of Sequential Programs Which Can Be M odeled By Structure
; Charts and M-Specs
As show n in Table 2-F, by using structure charts and M-Specs, m ost
desired pro p erties can be represented; how ever, tim ing specifications and
validation criteria can only be expressed as com m ents w hich do not provide
any "interpretable" m eaning to T eam w ork/R T .
G raphic N o ta tio n s
F igure 2-5 depicts th e th ree types of g raphical n o tatio n s used for
representing entity-relationship m odels.
1<=N
RELATIONSHIP RELATION
Name: Noun Verb Cardinality String
Example: subcontractor works_for 1 <= N
Figure 2-5: Entity-Relationship Diagram(ERD) Notations
A rec tan g le re p re se n ts a e n tity set; a d ia m o n d re p re se n ts a
relatio n sh ip ; the card in ality strin g s on the edges w hich are lin k ed to a
diam o n d define the type of relatio n sh ip (i.e. one-to-one, m any-to-one, or
m any-to-m any). For each entity, th ere is a d ata d ictio n ary en try (DDE)
w hich contains the descriptions of the attributes of the entity set. Figure 2-6
illu stra te s an exam ple ERD for re p re se n tin g "su b co n tracto r w o rk s for
b u ild er, an d b u ild er follow s architect's plan.". In this exam ple, th ere are
tw o types of relationships: a m any-to-one relationship, called "works_for",
betw een the entity set "subcontractor" and the entity set "builder"; an one-
1
to-one relationship, called "follows", betw een th e en tity set "builder" an d j
the en tity set "architects_plan". In o th er w o rd s, there are zero or m ore
"su b co n tracto rs" w o rk for a "b u ild er", a n d a "b u ild er" fo llo w s an
"architects_plan".
works_for
follows builder
subcontractor
architects_plan
Figure 2-6: An Example Entity-Relationship Diagram
T he n o tatio n s for describing a ttrib u te s of an en tity are rich, i.e.
operators in DDE allow one to define d ata structures for an attribute, so th at
43
one can describe data w ith the required details for the detail softw are design
specification.
4 -----► o
D A T A
F L O W S
S T O R E P R O C E S S T E R M IN A T O R C O N T R O L C - S P E C
F L O W S
Name: Data
Data Number Source/Sink Control DFD_
Signal n u m b e r
sheet_
number
.1 Customer alarm_
Example:
alarm
time
customer
database
set .1-sl
Figure 2-7: Notations For Building Control Models
For re p re se n tin g control flow m o d els, six classes of g rap h ic al
notations are used. Figure 2-7 depicts these six classes of notations.
As illustrated in Figure 2-8, the representations for expressing process
triggering are: Process A ctivation Table (PAT). D ecision Table (DT), State
E vent M atrix (SEM), an d state transition diagram . A state event m atrix
captures the sam e inform ation as a state transition diagram .
44
cn
State Transition Diagram
Decision Table
c2/cn
State3
State2
State1 c l c2 cn
"on" "off' "true"
"off" "on" "false"
"on" "on" "false"
"o ff’ " o ff "false"
Process Activation Table
cn 1 2 3
"true" 0 1 1
"false” 2 0 1
state/
event
c l c2
state 1
null/
stale2
"NA"
state2 "NA”
null/
state3
state3
cn/
state 1
"NA"
Figure 2-8: Alternative Ways For Expressing C-Specs
In T e a m w o rk /R T , th e re are no ru les for d e fin in g states at a
hierarchical level, alth o u g h sta te s are su p p o sed to rep resen t th e status of
p a rtia l c o m p u ta tio n s w h ich are re p re se n te d b y c o n tro l a n d /o r d a ta
processes. The results of this un d erd ev elo p ed sem antics for states are th at
(1) T e a m w o rk /R T d o e s n o t p ro p e rly check th e c o m p le te n e ss of
specifications of control flow m odels; (2) th e states in sta te tran sitio n
diagram s (or state event m atrices) do n o t necessarily describe the status of
45;
c o m p u tatio n s; a n d (3) th e seq u en ce an d c o n cu rren cy of c o m p u ta tio n
expressed in state transition diagram s m ay conflict w ith those described in
the refined d a ta /c o n tro l processes. Decision tables describe the relationships
betw een in p u t events(or in p u t control flow s) and o u tp u t events (or o u tp u t
control flows). N ote th at W ard and M ellor treat arrivals of control signals
as o ccurrences of d iscrete events a n d H atley trea ts co n tro l signals as
co n tin u o u s co n tro l flow s. In th e sequel, I w ill u se th e term "event"
exclusively. In Figure 2-8, the first ro w of the decision table show s that
in p u t event "cl" w ill p rodu ce an o u tp u t event "cn". In Process A ctivation
T ables each ro w describes the trig g erin g sequence of processes for each
com bination of in p u t events. A ctivation num bers w hich are non-negative
integers rep resen t the triggering sequence of process. The first row states
th at process 2 an d process 3 w ill be trig g ered sim u ltan eo u sly w h en cn
becom es "true"; the second row states th at process 2 will not be triggered and
th at process 3 w ill be trig g ered first th en process 1. The fo u r different
m ethods used in a C-Spec p ro v id e freedom to express control flow m odels.
H ow ever, conflicts in different representations of control stru ctu res are not
obvious to detect w hen th e system is large and com plex. In F igure 2-8,
assum e th at si is a decision table and s2 is a state transition diagram . The
th ird colum n of the decision table states th at event "cn" is g en erated only
w hen event "cl" occurs. Yet in the state transition diagram , it states that the
occurrence of ev en t "c2" at state3 w ill cause a tran sitio n to s ta te l an d
pro d u ce event "cn". C learly, a conflict exists betw een the decision table and
the state transition table.
46
c r e a t e _
p a y r o 11
r e a d _
r e c o r d
c h e c k
s t a t u s
e m p l o y e e ^
r e c o r d
a d d _
e m p l o y e e .
r e c o r d
d e l e t e _
e m p l o y e e .
r e c o r d
e m p l o y e e . r e c o r d
d a t a
f lo w
c o n t r o l
f lo w
o '
/
N a m e :
E x a m p l e :
M O D U L E
m o d u l e
n a m e
e m p l o y e e .
r e c o r d
Figure 2-9:
I N V O C A T I O N
( p a y r o l l : I
k a r t _ t i m e J
COUPLE CONNECTOR
Notations For Building Structure Charts
For expressing the static p ro g ram m odel, four classes of grap hical
notations are provided. Figure 2-9 depicts these four classes of notations.
In F ig u re 2-10, m o d u le "A" is in v o k e d w ith tw o p a ra m e te rs:
"in_out" a n d "cm d_y" w h ere "in_out" is u se d for p assin g an in p u t an d
re tu rn in g an o u tp u t; a n d ''cm d_y" is u se d for re tu rn in g a c o n tro l
com m and. F u rth er, m o d u le "A" w ill read in d a ta via "Record_X". The
structure of an M -Spec for m odule "A" is also depicted in Figure 2-10.
47
in_out
cmd_y
Record_X
Record_X
A correponding M-Spec
TITLE: A(in_out, cmd_y)
PARAMETERS:
in_out: DATA_INOUT
cmd_y: CONTROL_OUT
LOCALS:
a
b
GLOBALS:
Record_X: DATA.IN
BODY:
Figure 2-10: An Example of a Part of a Structure Chart
Perform ance D esign
T eam w o rk /R T does not su p p o rt design, analyses, an d syntheses of
the perform ance of real-tim e softw are. j
i
Correctness A n a ly sis and V a lid a tio n Techniques
W ith resp ec t to su p p o rt for correctness analysis a n d v a lid atio n , !
T eam w o rk /R T only su p p o rt syntactic checking of specifications [Cadre88].
1
For exam ple, all nam es u se d in specifying d a ta m o d els, control flow s j
m o d els, static p ro g ram m o dels m u st be d efin ed in th e d a ta d ictio n ary
according to th e syntax of d ata dictionary entries. T he consistency checks
pro v id ed can be sum m arized as:
• the consistency b etw een th e interface on th e stru ctu re chart and
th at specified in the M-Spec;
• existence of the process num bers used in process activation tables;
4 8
j • th e consistency of th e flow s an d th eir c o n stitu en ts b etw een C-
j Specs and DFDs.
| ;
i !
i i
j Reusability
i '
! The defined m odels can be brow sed graphically or are accessible via !
i ^
!"C" interfaces and "C" run-tim e library (called ACCESS). j
I
i
i M aintainability
i
; I
C o n fig u ratio n m an ag em en ts an d traceability for all p h ases of life |
t
cycles are not supported. j
I
i
S u m m a ry
j
I
j T e a m w o rk /R T m a in ly p ro v id e s facilities fo r sp e c ific a tio n an d .
I
| docum entation. Its form al foundations are not a p p ro p ria te to su p p o rt the
| specification an d analysis o f req u irem en ts and high-level design of real-
itim e softw are. F urther, there is no su p p o rt for (i) analyses of liveness an d ,
Jsafety properties, deadlocks, livelocks, ..., etc.; (ii) specification and analysis j
| of perform ance constraints; (iii) design aid (i.e. au to m atin g analyses an d ^
j 1
syntheses of design). j
49
.J
1 2 .2 .3 . CARDTOOLS FROM READY SYSTEMS
i
1 t
I F orm al F ou ndations
j The form al foundations of CARDTools are basically the sam e as those
I
I of T e a m w o rk /R T (i.e. S D /S A ex ten d ed w ith th e concept of explicitly
\
se p a ra tin g co n tro l from d a ta ). For e x p re ssin g c o n cu rren t so ftw are
. . . I
: com putations, th e multi-tasking model (via task graphs) is used to explicitly
| describe concurrent threads of com putations and their relationships (such as
' synchronization, com m unication, tim ing pro p erties, etc.) in stead of using
.sta te tra n s itio n d ia g ra m s to i m p l i c i t l y e n c o d e c o n c u rre n c y a n d j
r “ “ ” '
! C o m p u ta tio n a l M o d els and Their S em an tic Soundness
j The ap p ro ach taken by CARDTools to im plem ent each aspect of its ;
underlying m odel is as follows:
' • d ata m odel: tw o different approaches are used for expressing data
i and d ata types: (1) Ada-style specification for d ata item nam es, data
j types, an d decom position of aggregated d ata item s are supported;
(2) templates for specifying the d etailed characteristics (including ,
units, range, accuracy, resolution) of logical an d num eric d ata for i
h ard w are and softw are interfaces. j
!
• control m odel: data/control flow diagrams (i.e. sta n d a rd Y ourdon- j
D em arco d a ta flow g rap h s au g m en ted w ith th e W ard-M ellor's j
co n tro l flow extension), task graphs, an d the extended PDL (i.e.
Program D esign Language w ith extensions for concurrency such as
i CO begin, C O end, interrupt handling, etc.) are used.
• static program m odel: structure chart and PDL are used. !
50
I In section 2.2.1, I described the criteria for e v alu atin g CASE tool
I
e x p re ssiv e p o w e r w ith re sp e c t to th ese th re e c o m p u ta tio n a l m o d el
requirem ents. In the rem ainder of this section I w ill p resen t an evaluation
j
of the expressive pow er of the com putational m odel of CARD Tools based
on those criteria.
Desired Properties
in Data Models
Expressible Properties
in CARDTools Data Model
Composition
• the Ada-style data and data type
specification can express the de
composition of aggregated data
items.
Conditional Sequences
• expressible in Ada-style textual
specification.
• difficult to express the sequen
ce relationship between data items
defined in a template for hardware
and software interfaces.
Parallel Sequences
• parallel sequence relationships
can not be expressed .
Multiple Instances of The Same Type • multiple instances of the same
type are expressed; however,
interrelationships (e.g., parallellism,
constraints, etc.) are not expressible.
Timing Specification • not supported.
Table 2-G: Properties of Data Which Can Be Modeled in CARDTools
T able 2-G su m m a riz e s th e p ro p e rtie s of d a ta w h ic h m u st be
expressible in real-tim e CASE system s and the degree to w hich it can be
i
m o d eled by th e A da-style d a ta specification an d the h a rd w a re /so ftw a re
interface tem plates of CARDTools.
| T he follow ing is th e set of facilities w hich s u p p o rt th e softw are
req u irem en t specification(SRS):
51
i • a control m aps b u ild e r allow s d esig n ers to express functional
I d e c o m p o sitio n s w ith c o n tro l m a p s (w h ich a re sim ila r to
! T eam w ork's stru ctu re charts); 1
I :
J • a d ata flow diagram bu ild er allow s designers to express the d ata
j a n d /o r control flow o f com putations, o r these diagram s m ay be
autom atically constructed from control m aps.
i • a h a rd w a re /s o ftw a r e in te rfa c e facility fo rces d e sig n e rs to
: com pletely specify so ftw are/h ard w are interface data.
i
i
i i
; D u rin g th e so ftw are re q u ire m e n t specification p h a se, Y o u rd o n - j
I
D em arco d ata flow diagram s w ith W ard-M ellor's control flow extension are
. u sed to rep resen t the control flow m odel of real-tim e com putation. From
| m y analysis of d a ta flow diagram s in Section 2.2, I have concluded th at the
j sem antics of d a ta /c o n tro l flow diagram s are n o t sufficient to express the j
! concurrency, sequence, conditions, sy n chronization, com m unication, an d
tim ing p ro p erties of real-tim e com putations. T herefore, CARDTools do not ]
I
adequately support the specification of the control flow model of real-time I
i
software.
<
For the high-level design phase, tw o additional tools are ad d ed , they
j
are:
• a task m ap builder w hich allow s system architects to construct task
m a p s w h ic h e x p re s s c o n c u rre n c y , c o m m u n ic a tio n , a n d
synchronization am ong tasks. A task m ap m ay be autom atically I
co n stru cted from a d a ta /c o n tro l flow d iag ram a n d d a ta item 1
defin itio n s.
• a p ack ag e d e fin itio n facility w h ic h p ro v id e s th e m ea n s for
softw are architects to construct A da package or abstract data types.
i
i
i
i 1
i
i 52 .
The difference betw een a d ata flow d iag ram an d its corresponding
task m ap is m ainly th e specification of m eth o d s for sy n ch ro n izatio n and
^ com m unication (i.e. m essage queue, sem aphore, ren d ezv o u s, m ailbox, etc.)
: of d ata an d control betw een nodes. But when task maps are automatically
I
constructed from data/control flow diagrams, they contain no more j
I
information then those of data/control flow diagrams. T herefore, these task !
m aps in h erit sem antical incom pleteness from d a ta /c o n tro l flow diagram s
>
, (e.g. the m ethods of synchronization an d com m unication, the parallel an d ,
, conditional sequencing of functions and their in p u ts an d o u tp u ts, etc.). The
m issin g in fo rm a tio n in task m ap s h as to b e m a n u a lly a u g m e n te d , j
; H ow ever, this inform ation gap is n o t easily b rid g ed since p eople involved j
4 1
| in these phases are usually in different organizations for large-scale system s. '
I
, T h erefo re, o th e r m ea n s are n e e d e d for e x p re ssin g th e c o n cu rren cy ,
c o n d itio n a l seq u en cin g , sy n c h ro n iz a tio n , c o m m u n ica tio n , a n d tim in g i
: !
p ro p erties of softw are functions in real-tim e system s. A lthough task m aps I
can express som e of these properties. Task m aps sh o u ld not be used for
sp e cify in g so ftw a re re q u ire m e n ts since tasks are sch ed u lab le ru n -tim e
! e n tities an d a task m ap im plies decisions as to th e im p le m e n ta tio n of •
j so ftw a re functions (specifically, th e p ack ag in g of functions in to tasks). I
i
R e q u ire m e n t sp ecificatio n s sh o u ld o n ly c o n ta in so ftw a re fu n c tio n a l
re q u ire m e n ts relevant to the interactions between a real-time system and its
external environment a n d a req u irem en t specification in term s of a task
i
m ap w o u ld be over-constrained.
i
I
I
I
The sem antics of a task in CARDTools are am biguous. From the ru n
tim e p o in t of view , a task is an entity w hich consum es resources (such as
processor cycles, com m unication b an d w id th , m em ory, etc.) an d is m anaged
b y th e o p e ra tin g sy stem k ern el. T he e x ec u tio n of a task m ay be
in terru p tib le, b u t an execution th rea d is a single seq u en tial c o m p u ta tio n .
For an autom atically constructed task m ap, a n o d e co rresp o n d s to a DFD
,node w hich is decom posable to an o th er d ata flow diagram . T hus a node
i
(task) in a task graph of a data flow diagram m ay then hav e a corresponding
a task m ap. As a resu lt, a task is rep re se n te d as m u ltip le th re a d s of
e x e c u tio n . F urther, th e am biguity of in p u t/o u tp u t relatio n sh ip s in data
flow diagram s are also inherited by task m aps. Thus, task m aps alone are
not sufficient to express the conditional and parallel conditions for in p u ts
an d o u tp u ts of a task; PDL specifications are re q u ire d to a u g m e n t the
m issin g in fo rm atio n . Table 2-H lists the properties of control structures
w hich are rep resen ted by the com bination of d a ta /c o n tro l flow diagram s,
task m aps, and PDL specifications.
54
Desired Properties
in Control Flow Models
Expressible Properties
by Data Flow Diagram,
Task Maps and Extended PDL
Composition
• a hierarchy of transforms
Conditional Sequences
• IF/THEN/ELSE /D O LOOP constructs in
PDL can express this.
• this is not expressible in task maps.
Parallel Sequences
• parallelism, synchronization, and
communication are expressible in
task maps or PDL.
Multiple Instances of The Same Type
• each instance can be represented by
a node in the task map, but the num
ber of instances is static.
• the coordination can be expressed by
predefined primitives(e.g. message,
semaphore, interrupts).
• the coordinator of a set of tasks can not be
explicitly expressed.
Timing Specification
• maximum response time associated
with a task can be specified.
Enabling and Exiting Criteria
• enabling interrupts or messages can
be defined via task maps or PDL.
• exiting criteria can be expressed via
PDL.
Table 2-H: Properties of Control Flows Which Can Be Modeled in CARDTools
For describing th e algorithm s involved in im plem enting in d iv id u a l
functions, a static p ro g ram is required. As show n in Table 2-1, b y using
jcontrol m ap s (co rresp o n d in g to T eam w ork's stru c tu re charts) a n d PDL 1
specifications, m ost desired properties can b e represented; how ever, tim ing
specifications an d v alid atio n criteria can only be expressed as c o m m e n ts
w hich d o n o t p ro v id e any "interpretable" m eaning to CARDTools.
55
Desirable Properties
in Static program Models
Expressible Properties
Stimulus and Response Relationship
• use PDL (Program Description
Language) to specify them.
State Changes
• use state variables to express them
in PDL specifications.
Timing Specifications • not supported.
Interconnections Between Programs
• INVOCATION lines between
modules in structure charts represent
this property.
Validation Points and Criteria • not supported.
Table 2-1: properties of static programs and their relationships which can be modeled
in CARDTools
i
I
| Graphic Notations
CARDTools has graphical notations for rep resen tin g the control flow
m odel (i.e. via control m aps, d a ta /c o n tro l flow diagram s, and task m aps)
and the static program m odel (i.e. control m aps). For d ata m odels, graphical
notations are not used.
The notations for d a ta /c o n tro l flow diagram s are th e sam e as those of
T eam w o rk /R T . A s to the control m aps, th ey hav e less p rim itiv es th an
T eam w ork's stru c tu re charts. For b u ild in g co n tro l m ap s, tw o g rap h ic
p rim itiv es are used: box an d arc. A box rep resen ts a function an d arcs
connect a function to sub-functions w hich are in v o k ed b y it. T herefore,
C ARD Tools' control maps convey less information than Teamwork's
structure charts (w hich w as discussed in section 2.2.2). The task m aps of
CARD Tools replace th e state tran sitio n d iag ram s, th e process activation
tables, the decision tables, an d th e state event m atrices of T eam w ork/R T . In
the sequel, I will describe the graphical notations for task m aps.
T here are tw elve types of icons used for constructing task m aps. They
are depicted in Figure 2-11.
(
)
TASK SEMAPHORE ---- ► DATA
SUBSYSTEM EVENT FLAG / ► EVENT
o
SERVER MAILBOX
□
DEVICE QUEUE
o
ISR RENDEZVOUS
(
Figure 2-11: Notations For Constructing Task Maps j
The first colum n contains n o tatio n s for rep re se n tin g five ty p es of |
functions: task, sub-system , serv er (i.e. for controlling sh a red resources),
device, an d ISR (in terru p t service routine). M athem atically functions are
fu n d a m e n ta lly th e sam e (i.e. to m a p a d o m a in to a ra n g e ), w h a t
distinguishes these "five types of functions" are how they are controlled and
t
w h a t control m ech an ism s are u se d b y them a t ru n -tim e. T he second
colum n contains n o tatio n s for re p re se n tin g m eth o d s o f sy n ch ro n izatio n
a n d c o m m u n ic a tio n : se m a p h o re , e v e n t flag , m a ilb o x , q u e u e , a n d
57
___ l
ren d ezv o u s (i.e. synchronized com m unication). The th ird colum n contains
notations for rep resen tin g the ty p e a n d direction of inform ation flow: d ata
flow or control flow . F igure 2-12 illu strates an exam ple task m ap for
representing a p a rt of a robot control subsystem .
CONTROL
PANEL
INTER- resume
suspend
control
MASTER
CONTROL
motion command run_sensor
CONTROL
SENSORS
CONTROL
MOTION
o
3
3
>
c
4 >
Figure 2-12: A Fart of an Example Robot Control Subsystem
P erform ance D esign
For su p p o rtin g p erfo rm an ce analysis, th e R eal-Tim e P erfo rm an ce
V erification (RTPV) tool is p ro v id ed . T he architect selects th e p a th s of
in terests in task m aps a n d specifies in fo rm atio n in clu d in g th e h a rd w a re
c h a ra c te ris tic s , th e p a ra m e te rs fo r in te r-ta s k s y n c h ro n iz a tio n a n d
com m unication, an d tasks' m axim um execution tim e. RTPV w ill calculate
tim in g in fo rm atio n for the selected p a th s b ased on th e specified tim in g
pro p erties an d estim ated overheads of th e specified system . T he estim ation
for system 's overheads is b ased o n th e u ser su p p lied tim ing characteristics
or th e tim in g in fo rm atio n of R eady sy stem 's o p e ra tin g sy stem k ern el
5 8
(VRTX) w h ic h in c lu d e s p ro c e sso r cycles, co m m u n ica tio n b a n d w id th s,
m em ory access sp eed , context sw itches (in cu rred d u e to eith er in te rru p t
handling, 1 /O device handling, task sw itches, etc.). j
If th e im p lem en tatio n of th e system u n d e r d esig n w ill use R eady
i system 's VRTX, this approach is reasonable for o b taining the estim ation of
i
tim ing inform ation. But if th e operating system is a p a rt of the design, this
■approach ju st p ro v id e s a sim ple cap ab ility for a d d in g tim es alo n g an
!execution p a th . E ven if VRTX is u sed , this a p p ro a ch does n o t p ro v id e
assistance in analysis of global perform ance of the entire system .
Correctness A n a ly sis and V a lid a tio n Techniques
W ith re sp e c t to s u p p o rt for co rrectn ess an aly sis a n d v alid atio n ,
C A R D T ools o n ly syntactically checks completeness and consistency of
control m aps, d a ta /c o n tro l flow diagram s, task m ap s, h a rd w a re /s o ftw a re
in terface d efin itio n s, d a ta ty p e d efin itio n s, PD L listin g s, a n d p ack ag e :
i
definitions .
R eu sa b ility
The Package D efinition Facility su p p o rts reusability by th e m eans of
A da-style packages an d abstract data types. A da package perm its the generic
definition of p ro g ram u n its (i.e. generic p ro g ram s or generic package w ith
w h ich tem p lates are d efin ed to re p re se n t a d e sig n u nit). T he generic
defin itio n can be tailo red to specific im p lem en tatio n n eed s at tran slatio n
tim e. P rivate d a ta type an d abstract d ata type in A d a package su p p o rts d ata
59
abstraction, in form ation h id in g , a n d m o d u la rity w hich are im p o rtan t for
su p p o rtin g reusability.
To s u p p o rt reu sab ility , in a d d itio n , th e reu sab le en tities m u st be
explicitly characterized a n d stored in a database. T he p ro p erties of these
i
i
entities a n d their relationships can be queried so th a t (1) u sers can easily
i identify th e reusable entities w hich satisfy their needs; (2) reusable designs
i i
I can be form ed from th e characteristics of som e reusable req u irem en t or vice
j i
versa; a n d (3) th e id en tificatio n of a reu sab le d e sig n can lea d to th e i
identification of reusable im plem entations. CARD Tools does n o t p ro v id e
th e inform ation m anagem ent to su p p o rt reusability.
M a in ta in a b ility
i
l
i
C o n fig u ratio n m an a g em en t an d traceab ility for all p h a ses of th e
softw are life cycle are n o t supported.
S u m m a r y
F o r r e p r e s e n tin g c o n tro l flo w m o d e ls , C A R D T o o ls a n d
T eam w o rk /R T are b ased on th e sam e form alism (i.e. Y ourdon-D em arco's
d a ta flow diagram s au g m en ted w ith W ard-M ellor's control flow extensions)
except th a t CA RD Tools u ses tasks m ap s a n d e x ten d ed PD L listin g s for
e x p re ss in g c o n c u rre n c y , sy n c h ro n iz a tio n a n d c o m m u n ic a tio n wTiile
T eam w o rk /R T uses state transition diagram s, state ev en t m atrices, process
activation tables, an d decision tables. The CARD Tools’ ap p ro ach for control
6 0
flow m odels has m ore expressive p o w er th a n T eam w o rk /R T for specifying
concurrency, synchronization an d com m unication .
A lth o u g h C A R D T ools’ a p p ro a c h fo r p e rfo rm a n c e a n a ly sis is
1
jp rim itiv e, th e c ru d e estim ate of p e rfo rm a n c e a t lea st p ro v id e s som e
q u a n tita tiv e m easu res for architects to ex p erim en t w ith d ifferen t desig n
alternatives w h en inform ation of o p eratin g system overheads are available
(from either statistical data, estim ation, or th e specified requirem ents).
*
I
i
i
i
i
i
I
6‘
2 .2 .4 . STATEM ATE FRO M I-LO G IX
F orm al F ou n dation s
The form al foun d atio n s of Stalem ate are basically th e sam e as those
of T e a m w o rk /R T (i.e. S D /S A e x ten d ed w ith th e co n cep t of explicitly
separating control from data). For expressing the control flow behavior of
com putations, Statecharts [Harel86, H arel e t al 87, H arel88] (i.e. finite state
5
autom ata w ith b o u n d e d state variables an d decom posable states) are used to
express concurrency, synchronization, and com m unication.
C o m p u ta tio n a l M o d els an d Their S em an tic Soundness !
I
The ap p ro ach tak en b y S tatem ate to im p le m e n t each asp ect of its |
underlying m odel is as follow s [i-Logix87]:
i
I
• d a ta m odel: Forms are u se d for ex p ressin g elem en ts (such as
events, data-item s, conditions, etc.) w h ich are referen ced in the
control flow m odel and the static program m odel. ;
!
• c o n tro l m odel: A ctiv ity -ch a rts an d Statecharts a re used. A n j
A ctiv ity -ch art su p p o rts th e W ard-M eller's n o tio n of fu n ctio n al j
d e c o m p o sitio n w ith d a ta /c o n tro l flo w s a n d d a ta stores. A i
Statechart , v iew ed as a control en g in e for an A ctivity-C hart,
functionally corresponds to a state transition diagram in a W ard-
M ellor's d a ta /c o n tro l diagram .
• static p ro g ram m odel: Module-charts are used.
In th e sequel, I w ill p resent an evaluation of th e expressive p o w er of
th e S tatem ate's co m p u tatio n al m odel according to th e criteria d efined in
section 2.2.1.
62
Table 2-J sum m arizes the properties of d ata w hich m ust be expressible
in real-tim e CASE system s an d the degree to w hich it can be m odeled by the
form s of Statem ate.
Desired Properties
in Data Models
Expressible Properties
in Statemate's FORMs
Composition
• the decomposition of compound
events, conditions, data-items, and
information flows are expressible
in "form definitions".
Conditional Sequences
• the sequencing relationship is not
supported, but the condition for the
occurrence of an event or a data item
is expressible.
Parallel Sequences
• the sequencing relationship is not
supported, but concurrency can be
derived from the information in a
Statechart.
Multiple Instances of The Same Type • not supported.
Timing Specification • not supported.
Table 2-J: Properties of Data Which Can Be Modeled in Statemate j
To su p p o rt the specification of control flow m odels, S tatem ate allow s
o n e to express th e functional view an d the behavioral view of the system
u n d e r design. The functional view is expressed via Activity-charts w hich
re p re se n t a se t o f d eco m p o sab le functions, in fo rm atio n flo w (d ata an d |
co n tro l) b e tw ee n fu n ctio n s, a n d d a ta stores. T he b e h av io ral v iew is
expressed via Statecharts w hich rep resen t a set of hierarchical, concurrent
or m utually-exclusive su b -states activ ated by b ro ad c asted events. Each
A ctivity-chart is com prised of a set of activities (i.e. th e ch ild ren A ctivity-
charts) w hich are controlled by a statech art (i.e. th e "engine" th a t pow ers
a n d controls the activities). E vents generated by activities in an A ctivity-
chart m ay cause state transitions of th e associated Statechart.
i
I
I
6 3
A lth o u g h A ctivity-charts are b ased o n Y ourdon-D em arco's S A /S D
w ith th e W ard-M ellor's control flow extension, th ey do not hav e the sam e
deficiencies as DFDs. This is d u e to (1) the rep resen tatio n of sp littin g or
jm erging d a ta /c o n tro l flow s (via Join, Fork, R ecord connectors); a n d (2) the
i
explicit association of a Statechart to the activities in an A ctivity-chart.
Figure 2-13 illustrates how the explicit association of a S tatechart an d
its co n tro lled A ctivity-charts clarifies th e relatio n sh ip b etw een activities |
j (functions) an d their in p u ts and outputs.
rc o
^ /w r ite _ d a ta ( x )
L -c b
w ritte n (Y ) X w ritte n (Y )
h ^ .
— r~ r . _ ____
/w r ite _ d a ta ( Y )
■CD-,
^ r i t t e n ( x )
Check X J
c o m p u te !
d o n e /w r ite _ d a ta ( Y )
Figure 2-13: Information Flows Between Activity-Charts are Controlled By Statecharts
T he u p p e r p a rt of Figure 2-13 is an activity-chart w hich consists of
tw o activities: "AA" an d "BB" and three flow lines: "Y^', "Y2", an d "X". The
flow lines in an activity-chart id en tify th e source a n d targ et, an d each is
labeled w ith a u n iq u e nam e. The event a n d /o r conditions for trig g erin g
6 4
each activity a n d for p ro d u cin g the event an d o u tp u ts are described by the
controlling statechart of an activity. The low er p a rt of Figure 2-13 contains
tw o statecharts: SA an d SB w here SA controls activity "AA" an d SB controls
activity "BB". In SA, w h en the action "write_data(x)" occurs, in fo rm atio n
Y flow s from activity "AA" to activity "BB" (via flow line "X" ) an d SA
I
itran sitio n s from sta te "A" to sta te "B". S im u lta n e o u sly , th e e v e n t
l
\'written(x)" is broadcast; this, then, triggers th e tran sitio n from state "D" to
sta te "C heck X" if SB is in state "D". H ence, th e c o n su m p tio n a n d
p ro d u ctio n of Yj an d Y2 d ep en d on th e com putational states of AA and BB
(i.e. states in statechart "SA" an d statechart "SB"). Therefore, no am biguities ;
(e.g. w h e th er YT an d Y2 are need ed for A A to p ro d u ce X, or if only Ya is
needed to pro d u ce X, etc.) exist in Statem ate.
T able 2-K lists th e p ro p e rtie s of co n tro l stru c tu re s w h ich are
rep resen ted by A ctivity-charts an d Statecharts for describing the functional
an d behavioral properties of th e system u n d er design.
Desired Properties
in Control Flow Models
Expressible Properties
by Activity-charts and
Statecharts
Composition
• a hierarchy of activities.
Conditional Sequences
• use Statechart to control data/control
flows.
• use connects to express splitting or
merging of flows.
Parallel Sequences • use Statechart to express concurrency.
Multiple Instances of The Same Type • not expressible
Timing Specification • not expressible
Enabling and Exiting Criteria • use Statechart to express.
Table 2-K: Properties of Control Flows Which Can Be Modeled in Statemate
65
The p u rp o se of M odule-charts is loosely d efin ed in S tatem ate. A
m o d u le can be a physical co m p o n en t such as a "radar" or it can be an
im p lem en tatio n of an activity. A s dep icted in Table 2-L, a M o d u le-ch art
| m ainly su p p o rts the rep resen tatio n of the in terrelatio n sh ip of m odules. A
i
| m od u le encapsulates th e im plem entation of a user-specified set of activities,
[and th e in fo rm a tio n flo w s b e tw e e n activ itie s are p re s e rv e d in th e
I
l
[inform ation flow s betw een the associated m odules.
I
Desirable Properties
in Static program Models
Expressible Properties
Stimulus and Response Relationship • not supported.
State Changes
• not supported.
Timing Specifications • not supported.
Interconnections Between Programs
• the flow-lines between modules
in module charts represent this
property.
Validation Points and Criteria • not supported.
Table 2-L: Properties of Static Programs and Their R elationships W hich Can Be
M odeled in Statemate
G raphic N o ta tio n s
S tatem ate has g rap h ical re p re se n ta tio n s for S tatech arts, A ctivity-
c h arts, M o d u le-ch arts, a n d form s. In F ig u re 2-14, th e second colum n
contains sym bols for expressing d a ta /c o n tro l flow s, a n d th e th ird colum n
contains connectors. These sym bols can be u se d to construct Statecharts,
i
A ctivity-charts, an d M odule-charts. As show n in the first colum n of Figure
2-14, the oval sym bol is used for rep resen tin g states in S tatecharts w hile a
rectangle w ith a solid b o u n d ary can represent either an activity or a m odule.
6 6
Since Statechart is a novel idea for rep resen tin g the state of com putations,
in th e sequel the em phasis of m y discussion w ill be o n Statecharts.
CD
State
Conditional
Splitting
Activity
or
Module
Data
Store
Data
Flow
Connector
type 1
* * . Control key
' •/ j l Flow
S .
Default
Data
Flow
S selection
connector
Record
Connector
© Hi
story
Deep
History
- <
- <
Juction
Fork
J oin
Figure 2-14: Notations For Building Statecharts, Activity-charts, and Module-charts
A state is decom posable into eith er A N D o r XOR sub-states. In
Figure 2-15(a), state "A" is decom posed into tw o m utually-exclusive states
"B" and ”C", i.e. to be in state "A" is to be in either sub-state "B" or sub-state
"C". The "arrow w ith a d o t at the tail" rep resen ts a default arrow . The H
connector p o in te d to by th e d efau lt a rro w denotes th a t sub-state "B" is
en tered if there is no history (i.e. state "A" is en tered for th e first tim e.) As
an exam ple, w h en the system is in sub-state "C" a n d ev en t "E" occurs, the
system w ill exit fro m b o th sub-state "C" an d state "A". H ow ever, w h en
state "A" is en tered the second tim e, sub-state "C" w ill be entered instead of
sub-state "B". Therefore, th e default arrow an d th e H connector can be used
6 7
to m o d el th e n o tio n s of in te r r u p t an d re su m e in a m u lti-ta sk in g
e n v iro n m e n t.
XOR State
j
i
AND State
Figure 2-15: Notations For Expressing XOR/AND Sub-states ;
|
In Figure 2-15(b), state "A" is decom posed into tw o orth o g o n al (i.e. j
I
co n cu rren t a n d in d ep en d en t) sub-states "B" an d "C". In o th er w o rd s, to j
en ter state "A” m eans to en ter both sub-state "B" a n d su b -state "C". The j
system exits from state "A" w hen it exits from eith er sub-state "B" or su b
state "C"(e.g. the occurrence of event "E" w ill cause th e exit of sub-state "C”, ,
i
sub-state "B", an d state "A”.).
Each arc b etw een tw o (sub)states represents a tran sitio n . The label
attached to an arc is called a reaction. The form at of a reaction is "E[C]/A" j
w h e re "E" sta n d s for a trig g e rin g ev en t, "C" sta n d s for th e trig g erin g
condition, an d "A" stan d s for th e resu ltin g action. T he exam ple reactions
are "D” an d "E" in Figure 2-15.
J
(a)
6 8
[Cl]
[c3
(a)
ame
place
Figure 2-16: Examples of Connectors
Since tran sitio n s m ay d e p en d on th e ir conditions, th e C connector
can be u sed for this p u rpose. In Figure 2-16 (a), w hen ev en t "E" occurs, the
next state w ill be T, U or V d ep en d in g on w h eth er condition c l, c2 or c3 is
tru e as is indicated in the figure. A set of events m ay be g ro u p ed to define a
event set T hen th e transition for an e v en t ty p e is parameterized, (i.e. each j
i
i
event in the set has an associated transition). In figure 2-16(b), th e set "key"
has fo u r key events: type, q u an tity , place, a n d nam e. T he sub-state to be
en tered , resu ltin g from tra n s itio n 's ->U" , d ep en d s on th e m em ber of "key”
(e.g. if event "type" occurs, state "S" transitions to sub-state "T").
6 9
I- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
P erfo rm a n ce D esig n
S tatem ate does n o t su p p o rt d esig n , analyses, an d syntheses of th e
perform ance of real-tim e softw are.
C o rrectn ess A n a ly s is a n d V a lid a tio n T echniques
For correctness analysis an d valid atio n of the specified m odels, tw o
tools: A n a ly ze r a n d Prototyper, are p ro v id e d . T he A n a ly ze r allow s a
designer to specify in p u t sequences for m odeling the external environm ent,
i
checks consistency an d com pleteness of Statecharts, A ctivity-charts, m odule- j
i
i
ch arts, a n d p erfo rm s analyses in clu d in g reach ab ility , n o n -d ete rm in ism ,
deadlock conditions, an d the usage of transitions. The Prototyper p ro v id es
links to the u ser-su p p lied program s an d autom atically generates A da code
fram es such th a t the specification m ay be executed to validate the functional
an d (control) behavioral of the system u n d e r design.
I
R e u sa b ility
A re la tio n a l d a ta b a s e is u se d to sto re e le m e n ts (e.g. e v e n ts,
conditions, data-item s, etc.) and the specified m odels. The defined m odels
or elem ents can th u s be queried. j
M a in ta in a b ility
The configuration m an ag em en t facility is c ru d e an d n o t very useful
[King et el 88].
7 0
I
A dvantages and D isadvan tages
The strengths include:
• concise sem antics for graphical notations;
• hierarchical decom position of states;
• tw o ty p es of states: A N D states (for ex p ressin g concurrency of
com putations) an d XOR states (for expressing conditional state of
co m p u tatio n s);
• an im atio n of statech arts(n o te: the c u rre n t v e rsio n of S tatem ate
can only anim ate one Statechart at a time);
• th e a b ility to p e rfo rm c o rre ctn e ss a n a ly sis a n d v a lid a tio n
(although th e c u rren t version can only h an d le sm all problem s, it
is still u sefu l w h en th e d iv id e-an d -co n q u er d esig n ap p ro ach is
used to deal w ith m ed iu m or large system s); an d
• th e prim itive b u t high expressive p o w er p ro v id ed b y Statechart.
The deficiencies include:
• the over-sim plified d ata m odel;
• no su p p o rt for defining interfaces b etw een su b sy stem s (or su b
com ponents);
• n o scoping or m odularity;
• in co m p lete co n cu rren cy m o d el (i.e. rep lic a tio n of co n cu rren t
processes, pipelined p ro ce sses,..., etc.);
• restricted com m un ication (i.e. only b ro ad cast a n d sy n ch ro n ized
com m unications are supported); and
• th e reachability analysis is only useful to sim ple problem s.
in ad e q u ate m odel for specifying d istrib u te d system s (alth o u g h
delays for the event p ro p ag atio n can be encoded by a d d in g extra
steps of transitions, th e re su lta n t specification is n o t obvious to
review ers);
no local scoping of events an d conditions;
n o explicit p rio rities associated w ith event; A lth o u g h p rio rities
am o n g events can b e en co d ed via boolean ex p ressio n s (e.g. if
ev en t "el" has h igher p rio rity th an "e2", "el" an d "e2 a n d n o t e l"
e n co d e s th e p rio rity b e tw e e n "el" a n d "e2"), th e r e s u l t a n t !
specification is com plex an d n o t obvious to review s;
no explicit queueing for events (A lthough queueing of events can
be en co d in g b y a d d in g o rth o g o n al states, again th e re s u lta n t J
specification is com plex and not obvious to review ers); an d
no su p p o rt for th e tim ing specification or analysis.
A s com pared to the o th er three CASE system s, S tatem ate has m ore
concise sem antics for its underlying m odels, an d it is the only system w hich
su p p o rts th e concept of executable specifications. A lthough S tatechart has
high expressive pow er, th e m echanism is prim itive. It is u n su itab le to be
u se d as user-interface for CASE system s. F urther, th e deficiencies in its
c o n cu rren c y m o d el, th e c o m m u n icatio n m ech an ism , an d tim in g a n d
p rio rity specifications leave Statem ate deficient for specification a n d design
of real-tim e system s.
72
2.2.5. RDD-100 FROM ASCENT LOGIC CORPORATION
F o rm a l F o u n d a tio n s
RDD-100 is an en v iro n m en t w hich su p p o rts th e design, m odeling,
land an aly sis of d istrib u te d real-tim e system s. T he RDD (R equirem ent
i
j D riven D esign) m eth o d o lo g y is th e core of this d esig n -aid en v iro n m en t.
[This m ethodology includes:
• a system atic ap p ro ach for decom posing problem s to be solved b y I
real-tim e system s; j
• an a p p ro a c h fo r s u p p o rtin g th e co n cep t th a t th e rea l-tim e
com putations are to m onitor th e external stim uli an d to generate
responses to its environm ent;
• a m echanism for expressing perform ance indices an d constraints; I
i
• representations for expressing various concurrency m odels;
• a m echanism for allocating functions to com ponents;
• a uniform an d system atic approach for th e interface design; j
• a system atic ap p ro ach for fault m anagem ent; j
• a m echanism for traceability; and
• a m echanism for rep resen tin g project m anagem ent.
C o m p u ta tio n a l M o d e ls a n d T heir S e m a n tic S o u n d n ess
7 3
In the RDD m ethodology, th e g rap h m odels rep resen t three aspects of
real-tim e com putations. The representations for describing th e three aspects
are p ro v id ed by:
• the I-Net (Item N et), th e rep resen tatio n for ex p ressin g th e d ata
m o d el, w h ich describ es th e tim e sequence, co n cu rren cy , a n d
j com position of d ata item s;
I
j • th e F-Net (Function N et), th e rep re se n ta tio n for ex p ressin g the
i co n tro l flow m o d el, w h ich d escribes th e tim in g , a n d control
s t r u c tu r e s (i.e s e q u e n c e , c o n c u r r e n c y , c o o r d in a tio n ,
c o m m u n ic a tio n , e n a b lin g a n d te rm in a tin g c o n d itio n s , a n d
com bustion of functions); and
j !
• th e R-Net (R equirem ent N et), th e re p re se n ta tio n for ex p ressin g
th e sta tic p ro g ra m m o d el, w h ic h d escrib es th e stim u li a n d
response relationships of a sequential p ro g ram and allow s one to
express the validation points an d conditions.
i
j
A discrete data item is either one d ata item or a com posite of d ata
item s referred to as a group. The prim itives of th e control flow m odel are
the discrete functions. A discrete function accepts a discrete d a ta item ; A j
discrete fu n ctio n w ill be activ ated w h e n th e enabling co n d itio n an d th e I
req u ired in p u t is available. It w ill generate one or m ore discrete d ata item s.
W hen a discrete function exits, it m u st satisfy one of its exit conditions.
Such an exist condition, o n a d irected arc w hich connects this fu nction to i
th e successor function, is th e enabling condition of the successor. R-N et
can be u se d to describe th e state tran sitio n s of a discrete fu nction w hich
corresponds to a sequential program .
74
T able 2-M su m m a riz e s th e p ro p e rtie s of d a ta w h ich m u st be
expressible in real-tim e CASE system s an d th e d eg ree to w hich it can be
m odeled by the I-N ets of RDD.
Desired Properties
in Data Models
Expressible Properties
in RDD's I-Net
Composition • time (data) items are decomposable.
Conditional Sequences
• supported by the "selection",
"iteration", and "data item"
primitives.
Parallel Sequences
• supported by the "concurrency",
"iteration", and "data item"
primitives.
Multiple Instances of The Same Type
• supported by the "replication" ,
"iteration", and "data item"
primitives.
Timing Specification
• not supported with formal syntax
and semantics.
Table 2-M: Properties of Data Which Can Be M odeled in RDD
A time function accepts a stru c tu re of in p u ts over a tim e in terv al
un til one of possibly several exit conditions are satisfied. A tim e function i
m ay be decom posed. A time item , on the o th er h a n d , is an aggregate for
describing a sequence of d ata item s over a tim e interval.
C o n d itio n al sequences of functions or d a ta item s can be m o d elled
w ith th e selection, iteratio n , a n d fu n ctio n o r d a ta item p rim itiv es. The
concurrency m odels w hich can be expressed include:
• concurrent d ata item s;
• concurrent interleaved stream of d ata item s;
• replicated concurrent d ata item s;
i
75 J
• in d e p e n d e n t co n cu rren t functions;
• p ip elin ed co n cu rren t functions;
• c o n c u rre n t n o n -id e n tic a l fu n c tio n s w h ic h a re e x p lic itly
coordinated by a coordinating function; and
• c o n c u rre n t id e n tic a l fu n c tio n s w h ic h are c o o rd in a te d b y a
coo rd in atin g function.
Desired Properties
in Control Flow Models
Expressible Properties
bv RDD's F-Nets
Composition • supported by "time functions".
Conditional Sequences
• supported by the "selection",
"iteration", "function" primitives.
Parallel Sequences
• supported by the "currency",
"itemation", and "function" primitives.
Multiple Instances of The Same Type
• supported by the "replication
function" and "iteration" primitives.
Timing Specification • formal syntax and semantics are
not supported.
Enabling and Exiting Criteria
• supported as part of the
"function" primitive.
Table 2-N: Properties of Control Flows Which Can Be M odels in RDD
Table 2-N sum m arizes th e p ro p erties of control stru c tu re w hich are j
rep resen ted by F-N ets for describing th e functional an d behavior properties
of the system u n d er design.
A s sh o w n in T able 2 -0 , RD D p ro v id e s m o st of th e d e sira b le
p ro p erties for specifying static p ro g ram m odel w ith th e deficiency for tim ing
specifications.
76
Desirable Properties
in Static program Models
Expressible Properties
in RDD's R-Net
Stimulus and Response Relationship
• supported by the simulus-response
graph (i.e. R-Net).
State Changes
• supported by using "state item".
Timing Specifications • no formal syntax or semantics for
specifying timing constraints.
Interconnections Between Programs
• An F-Net defines relationships
between programs.
Validation Points and Criteria
• supported by the "validation point"
primitive.
[Table 2-0: Properties of Static Programs and Their R elationships W hich Can Be
! Modeled in RDD
I
1
! G ra p h ic N o ta tio n s j
T he co n n ecto r p rim itiv e s for b u ild in g th e s tru c tu re of a tim e
function an d a tim e item are depicted in figure 2-17.
i
A Function
Replicated
Concurrent
Functions
A Data Item
Sequence
©
Selection
Iteration
©
Concurrency
©
Replication
(1) (2)
Figure 2-17: (1) Operator Primitives, (2) N ode Primitives
7 7
Pilot
Command
f Mission
I Computer
VjCommand J
Pilot Command and Mission
Computer Command
will occur concurrently
G J
Airplane
Airplanes Arrives Concurrently.
Figure 2-18: Two Examples for Modelling Concurrent Data
Figure 2-18 depicts tw o types of concurrent d a ta item s. The top one
m eans th a t th e occurrences of "Pilot C om m and" a n d "M ission C o m p u ter
C om m and" are concurrent. The bottom one m eans th at a set of "A irplane"
m ay occur concurrently; how ever, each of them has its o w n state (such as
altitude, speed, etc.).
F ig u re 2-19 show s th e top level specification for a com m unication
protoco l in w h ich a set of Send Message functions a n d a set o f Receive
Message functions cooperatively tran sm it m essages. The tran sm ittin g state
of each m essage m ay be different in this specification of th e com m unication
protocol.
Number of
Messages
Number of
Messages
Transmitted
Message
M essage)
Receive
Message
Send
Message
i
t
I
ACK/NACK
Figure 2-19 : A High Level Specification For a Communication Protocol
P erfo rm a n ce D esig n
RDD p ro v id e s a g en eric m ech an ism for asso ciatin g p erfo rm an ce
indices to d ata item s an d functions. H ow ever, it does n o t form ally define
the syntax an d sem antics of tim ing specifications. F urtherm ore, it does not
su p p o rt analyses and syntheses of th e perform ance of real-tim e softw are.
A n a ly s is a n d V a lid a tio n T echniques
RDD su p p o rts syntactic checking of th e consistency an d com pleteness
of specifications.
R eusability
I
i
| T he d efined m odels can be brow sed graphically an d im p o rted from
the und erly in g file system .
I M a in ta in a b ility
\
j C o n fig u ra tio n m a n a g e m e n ts are n o t s u p p o rte d c u rre n tly , b u t
j traceability is m aintained for both F-N ets, I-Nets, an d R-Nets.
j A d v a n ta g e s a n d D is a d v a n ta g e s
In a d d itio n to p ro v id in g a rig o ro u s se t of re p re se n ta tio n s for
describing sequencing an d concurrency of d a ta an d functions, RDD also
allow s one to textually describe perform ance indices a n d constraints. The
deficiencies of the RDD's g rap h m odels are that:
• th e syntax or sem antics of node and connector prim itives are not
form ally defined;
• th e re p re se n ta tio n s for p erfo rm an ce in d ices are n o t form ally
defined; and
• the representations for constraints are n o t form ally defined;
80
2 .2 .6 . SUM M ARY
P revious approaches to defining tim ing are not directly applicable to
ad v an ced real-tim e system s since an avionics softw are specification m u st
a d e q u a te ly re p re s e n t th re e c o m p u ta tio n a l view s: 1) th e d a ta to be
i
1 m a n ip u la te d , 2) th e fu n ctio n s w h ich m a n ip u la te th e d a ta , a n d 3) th e
(interrelationships betw een functions. T he rep resen tatio n for d escribing the
!
data to be manipulated m u st allow o n e to ex p ress sp a tia l a n d te m p o ra l
p a ra lle lism , e n ab lin g co n d itio n s, a n d stru c tu re d ty p e in fo rm a tio n . F or
i j
functions which manipulate data, o n e m u st be ab le to e x p re ss th e ir
b e h a v io r, th e ir e n a b lin g a n d ex itin g c o n d itio n s, a n d th e ir te m p o ra l
p ro p erties. Finally, for describing interrelationships between functions, one
m u st b e able to express p reced en ce rela tio n sh ip s, sp atial a n d tem p o ral
parallelism , an d enabling conditions.
M ost form al specification approaches do n o t com pletely su p p o rt the
th ree co m p u tatio n al view s. In ad d itio n , softw are req u irem en ts a n d design
i
specifications often have different u n d e rly in g co m p u tatio n al m odels. The I
existence o f such a sem antic gap b etw een these tw o softw are d ev elo p m en t
p hases can lead to a design w hich is incom plete an d inconsistent w ith the
o rig in al system req u irem en ts. In an avionics system , th e re su ltin g erro rs
can be ex trem ely difficult an d ex p en siv e to d e te c t d u rin g th e test a n d
in teg ratio n phases (e.g. th e cost of a flight test is in the o rd er of m illions of
dollars).
81
A specification m ethodology m ust b rid g e the gaps betw een softw are
req u irem en ts an d im plem entation. In th e follow ing chapters, I p resen t a
specification m eth o d w hich allow s au to m atio n of th e tran sfo rm atio n of
specifications into A da PDL. The approach entails three key concepts:
(1) a com prehensive com putation m odel w hich cap tu res requirem ents
an d p erfo rm an ce goals of avionics ap p licatio n s (in clu d in g tim ing
c o n stra in ts) a n d p ro v id e s a u n ify in g fo u n d a tio n for re la tin g
re q u ire m e n ts , to p lev el d e sig n , d e ta ile d d e sig n , a n d co d e
rep resen tatio n s.
(2) a unified graphical representation for specification and design w ith a
form al textual notation.
(3) the use of rules to m ap the requirem ents onto a specification of a
softw are arch itectu re an d for au to m atically p ro d u c in g code from
such a specification.
In a d d itio n , I w ill a d d re ss th e p ro b le m s of sp e c ify in g th e
requirem ents an d th e design of a com putational m odel in a real-tim e CASE
tool, specifically: *
• w ith respect to specifying th e functional req u irem en ts, how the
e x te rn a l e n v iro n m e n t of a ta rg e t sy stem is specified; w h a t
n o tatio n s are to be used; how to specify e n v iro n m en t beh avior
(state changes);
• w ith re s p e c t to sp e cify in g th e d e sig n , h o w th e e x te rn a l
e n v iro n m en t is rep resen ted (view ed) in a targ et-sy stem m odel;
w h at notations are to be used; how to specify the estim ated state
changes (from the target system ’ s p o in t of view);
• d e fin in g d ecisio n fu n ctio n s fo r d e te rm in in g task sc h ed u lin g
priorities; ho w to dynam ically incorporate th e externally defined
task priorities, th e tim ing constraints, th e en v iro n m en t state, and
the target system state into a decision function; and
82
• h o w tim ing req u irem en ts are defined; tim in g req u ire m e n ts are
in fe rre d fro m th e e stim a te d ra te of sta te ch an g es in th e
environm ent, the com putational accuracy in th e targ et system for
tracking the en v iro n m en t state, th e m axim al lifetim e of observed
d a ta (w hich are interrogated from th e environm ent), etc..
83
3. A REQUIREMENTS SPECIFICATION M ETHODOLOGY
The ev alu atio n of com m ercial CASE tools in section 2.2 show s th at
i A lfo rd 's g ra p h m o d el [A lford85]) is m o re co m p re h en siv e th a n o th e r
: approaches. H ow ever, the g rap h notations defined in [Alford85]) are still n o t
su ffic ie n t for specification of the req u irem en ts an d desig n of h a rd /s e m i-
h a rd real-tim e softw are. T he specification m eth o d d efin ed in this ch ap ter
uses A lfo rd 's g rap h ic n o tatio n s. H o w ev er, in o rd e r to rig o ro u sly a n d '
I !
I co n cisely d e sc rib e in te ra c tio n s b e tw e e n a ctiv itie s a n d tim e -o rie n te d |
j
b ehaviors, 3-aspects are extended. T he th ree aspects are: (i) th e g rap h ical
notations for representing interactions betw een activities; (ii) the syntax and
sem antics of graphic notations; an d (iii) th e textual notations for specifying
tim ing constraints, pre-conditions, and post-conditions form ulas .
In this m ethodology, requirem ents are specified w ith three parts: the
<
d a ta m odel, th e control flow m odel, an d th e seq u en tial p ro g ram m odel, i
i
G raphical notatio n s are u se d for rep resen tin g relations betw een d a ta item s i
in a d ata m odel and relations betw een com putational activities in a control
flow m odel. T he tim in g sem antics of g rap h ic notatio n s are declared w ith
tim in g c o n strain ts fo rm u las w hich are fo rm ed b y a set of tim e in sta n t
variables (defined in Section 3.2) and predicates.
The data model is expressed w ith d a ta g rap h s in w hich each n o d e
re p re se n ts e ith er an atomic data item or a composite (i.e., non-atomic) data
item. A n atomic data item is a ty p ed stru ctu re an d the d ata entities in the !
stru c tu re are referenced via the nam e of the d ata item . A composite data |
item h as an asso ciated d a ta g ra p h w h ich d escrib es a tim e seq u en ce
84
r e l a t i o n s h i p b e t w e e n i t s c o m p o n e n t d a t a i t e m s . D u r i n g r e q u i r e m e n t s
a n a l y s i s , t h e d e s c r i p t i o n s o f e a c h c o m p o s i t e d a t a i t e m m a y u n d e r g o
I successive refin em en t until all d ata item s hav e been expressed com pletely
1
in term s of atom ic d a ta item s. S u b seq u en tly , each atom ic d a ta item is
re p re se n te d in term s of d a ta stru c tu re s (such as A d a T ype S tru ctu res
D efinition). The type structures for a com posite d ata item is an aggregated
j type stru ctu re (such as an A da Type Package) w hich are to be transform ed
i
, from the topological structure of the associated d ata graph.
The control flow model is expressed w ith an activity g rap h in w hich
lea ch n o d e re p re se n ts eith er an atomic activity or a composite (i.e., non-
atomic) activity. A n atomic activity is a sequential (sub)program w hich is a
i
| p rim itiv e for constructing a control flow m odel. A n atom ic activity o n ly j
accepts atom ic d a ta item s. A n atom ic activity can be activated w h en the
enabling conditions and the required atom ic d ata item s are available. It m ay
I
j g en erate one or m ore atom ic d a ta item s. U p o n com pletion, an atom ic j
i * - i
activity m u st satisfy one of its exit conditions. Such an exit c o n d itio n ,,
i associated w ith a directed arc connecting the activity to its successor, is also j
t
th e enabling condition of th e successor. A p ro g ram d escrip tio n language
(e.g., a subset of A da language constructs) can be u sed to describe the state
transition of an atom ic activity. A composite activity is a p ro g ram w hich
J accepts the in p u ts, has tem poral and spatial parallelism and sequence (i.e., j
| i
i tim e d ata item s), an d can be further decom posed. !
t
The sequential program model describes im p o rtan t p ro p erties (e.g.,
■ th e p re- a n d p o st- conditions for activ atio n , th e tim in g a n d reso u rce !
| I
| requirem ents) of a sequential program u n it in textual notations. ;
! 85 1
I a s s u m e t h a t d u r i n g r e q u i r e m e n t a n a l y s i s , t h e t e m p o r a l p r o p e r t i e s o f
i
! com putational activities an d their associated d ata are defined com pletely in
■ I
! term s of d ata g rap h s a n d activity graphs. The specification process m ay
i u n d e rg o su ccessiv e re fin e m e n t u n til sy stem re q u ire m e n ts h a v e b een
i expressed com pletely in term s of atom ic activities a n d d ata item s.
I
I In Section 3.1, I define the graphical n o tatio n s w hich form the basis
1 for constructing activity graphs and data graphs.
i
! In Section 3.2, I define the syntax for rep resen tin g logical and tim ing j
, behaviors of atom ic activities (i.e., sequential program m odels) and rules for
, constructing activity graphs (i.e., control flow m odels). I also au gm ent Type
Structures to rep resen t atom ic d ata item s and ag gregated d ata structu res to
' rep resen t com posite d ata item s.
: i
, I
I I
| In Section 3.3, I classify tim ing properties of activities an d thus define ,
j a taxonom y of constraints on the arrival tim es of activity instances. U sing
I i
th is tax o n o m y as a fo u n d atio n , the w o rk lo ad of system resources (e.g., I
processors, I /O processors, etc.) can be analyzed. !
3.1. GRAPHICAL PRIMITIVES FOR SPECIFYING REQUIREMENTS
In this section, the graphical notations for expressing d ata g rap h s and
' activity graphs. Figure 3-1 depicts the three sets of graphical prim itives: the
:'n o d e ’ p rim itiv e s, th e 'o p e ra to r' p rim itiv e s, a n d th e 'co m m u n icatio n '
p rim itiv es. N o te th a t th e first tw o sets are a d o p te d from A lfo rd 's g ra p h
m odel [Alford85], an d th e th ird set is a d d ed for rep resen tin g interactions
j betw een activities.
Data Flow
Sequence
Activity
merge
connector
Concurrency
O Data Item
split
connector
Iteration
\ junction
connector
Concurrent
Objects of the
same class
Q Selection
equivalent
connector
(a) Node Primitives (b) Operator Primitives (c) Communication Primitives
Figure 3-1: Graphical Notations for Building Activity/Data Graphs
The node prim itives, depicted in Figure 3-1(1), in clu d e activity w hich
re p re se n ts a c o m p u ta tio n a l e n tity co n su m in g in p u ts a n d p ro d u c in g
o u tp u ts , data item w hich rep resen ts an in p u t to be c o n su m ed a n d /o r an
o u tp u t to be p ro d u c e d , a n d concurrent objects w hich rep re se n ts a set of
activities o r d a ta item s w ith th e sam e ty p e of p ro p erties. T he o p e ra to r
p r i m i t i v e s , d e p ic te d in F ig u re 3-1(2), in clu d e sequence, concurrency,
8 7
iteration, a n d selection w h ich can b e u se d for e x p re ssin g sp a tia l a n d
te m p o ra l p a ra lle lism a n d se q u e n c in g of activ ities or d a ta item s. T he
sequence an d concurrency operators are used for expressing th e partial o rder
relatio n w ith respect to tim e. A p air of iteration operators encom passing a
set of activities (or d ata item s) represents th eir repetitive occurrences. A pair
of selection o p e ra to rs e n co m p assin g a set of activities (or d a ta item s)
sp ecifies th e ir m u tu a lly e x clu siv e o c cu rren c e. T he c o m m u n i c a t i o n
p r im itiv e s , d ep icted in Figure 3-1(3), include data flow, merge connector,
split connector, an d junction connector.
1.0 Front End directions
I number of phases in dwell
1.1
D
Antenna "N
Pointing J
Coordinates S
Timing and Control
table
1. '
Figure 3-2: A Data Graph Constructed With Iteration, Sequence, and Data Item Primitives
T he d a ta g rap h , show n in Figure 3-2, graphically describes h o w the
co m p o site d a ta item — ’F ro n t E nd d irectio n s' g ets p ro d u c e d . Its elem en ts
consist of a sequence of T im in g a n d C o n tro l table' d a ta a n d 'A n te n n a j
P ointin g C o o rd in ates’. T hese elem ents are p ro d u ced , one after th e other, as j
th e d ia g ra m clearly show s. Timing and Control table d a ta an d A n te n n a
Pointing Coordinates instances m ay arriv e at different tim e in stan ts. W hen
th e ty p e stru ctu re, the arriv al tim e of each instance, th e initial trig g erin g
co n d itio n s, a n d th e ex itin g co n d itio n s of Timing and Control table an d
8 8
A ntenna P ointing Coordinates are d e fin e d , F ro n t E nd directions is
considered to be com pletely specified.
I
Figure 3-3: A Data Graph Constructed With R eplicate, Selection, Data item , and
Concurrent Objects of The Same Class Primitives
com prised of a set of concurrent objects. Each object m ay be one of th ree j
i !
possible d a ta item s: 'D w ell Set-up statu s', 'Signal Processing S tatus', an d
'D ata P ro c essin g S tatu s'. T he a rriv a ls of Dwell Set-up Status, Signal,
i
j Processing Status, an d Data Processing Status are m u tu ally exclusive. Dwell j
Set-up Status w ill be w ritte n only if dwell_scheduling_activity is ru n n in g ; J
J Signal processing status w ill be w ritten only if signal_processing_activity is
data_processing_activity is ru n n in g .
A data flow is com posed of a unidirectional arc a n d a label, x. The
u n id ire c tio n a l arc re p re se n ts a o n e -to -o n e c o m m u n ic a tio n (i.e., o n e
p ro d u c e r a n d o n e consum er). T he activ ity at th e tail of th e arc is the
l.J Activities Status
[Max#Activities,
current#Activines]
dwell_
scheduling
activity^
f Dwell \ ( Signal Data N
I Set-up I j processing II Processing I
V status J V status J V Status_y
F ig u re 3-3 d ep icts th e d a ta g ra p h of 'A ctivities S tatus' w hich is
ru n n in g ; s im ila rly , Data Processing Status m ay be w ritte n o n ly if
89
pro d u cer of x, the activity at the head is x's consum er, x m ay be a com posite
d ata item or an atom ic d ata item . W hen x is an atom ic d ata item , it is not a
necessary condition for the p ro d u cer or the consum er activity to be atom ic.
H ow ever, if both the consum er and th e p ro d u cer activities are atom ic, th en
x m u st be an atom ic d ata item .
Activity
Activity
Figure 3-4: two concurrent activities communicate via 'msgs' j
Figure 3-4 depicts tw o concurrent activities: A ctivity A com m unicates i
w ith A ctivity B via msgs w hich m ay be an atom ic d a ta item , as show n in J
!
Figure 3-5 (a), or a com posite d ata item w hich has an associated d ata g r a p h ,;
such as one of g rap h s depicted in Figure 3-5(b)- F igure 3-5(f), to rep resen t j
tim ing and spatial parallelism of msgs' com ponent d a ta item s.
f msgs
msgs
(^T)
msgs msgs
( <%* * -
msg end M error J
f msg
Q
5 s 'N
H -----
( " 0
I J
(a) (b) (c) (d) (e) (0
Figure 3-5: data graphs represent possible decompositions of msgs
The topological stru c tu re of m sgs' d a ta g ra p h does n o t necessarily
have a one-to-one m ap p in g w ith th at of either the activity g rap h of A ctivity
90
A or of A ctivity B. For exam ple, to p ro d u ce m sgs w ith properties such as the
one depicted in Figure 3-5(b), A ctivity A m ay have an activity g rap h such as
one of those show n in Figure 3-6(a)-Figure 3-6(c), w hile A ctivity B m ay have
an activity g rap h such as one of those show n in Figure 3-6(d)-Figure 3-6(f).
N o te th a t in Figure 3-6(a)-Figure 3-6(c) th e p ro d u ctio n beh av io r of m sgs is
rep resen ted w ith a 'm erge connector' w hile in Figure 3-6(d)-Figure 3-6(f) the
c o n su m p tio n b eh av io r of m sgs is rep re se n te d w ith a 'sp lit connector'. N o
m atter h o w A ctivity A is decom posed, th e com ponent activities of A m u st
p ro d u c e m sgs w ith th e p ro p erties specified in the d a ta g ra p h of m sgs.
S im ilarly , n o m a tte r h o w A c tiv ity B is d e co m p o se d , th e c o m p o n e n t
activities of B m ust consum e m sgs w ith th e properties specified in the data
g rap h of m sgs.
i
Figure 3-6: activity graphs represent possible decompositions of activity A and activity B !
I
A merge connector is com posed of n labeled fan-in arcs: Xj, ..., xn
i
w here n > 1; an d a d ata item x. x is a com position d ata item w ith com ponent
91
Activity B Activity B Activity B
msgl
msgs
Activity
Activity Activity Activity Activity
msgl
msg2
msgl
Activity
B2
msgs
msgs Jrnsg2
(d) (e) (f)
Activity A Activity A
Activity A
Activity
A1
status Activity
A2
Activity
A2
Activity
A1
Activity
A1
msgl
msgl
Activity
A2
msgs
msgs
msgs
error
(c) (a) (b)
d ata item s: x-j, x2, an d xn. For each labeled arc Xj, there m u st be an activity
at the opposite en d of the d ata item x to 'w rite' o r 'access'5 th e com ponent
d ata item xi. The write behavior of xi is rep resen ted b y the unidirectional arc
associated w ith xi, and an activity is at the tail of th e arc w hile the d ata item
x is at the head. The access behavior of xi is rep resen ted by th e bidirectional
arc associated w ith Xj. The spatial an d tem poral parallelism an d sequencing
of d ata item s Xj , x ^ are represented by the d ata graph associated w ith x.
! !
i A spit connector is com posed of n labeled fan-out arcs: x - j , x n; an d a
j d a ta item x. x is a com position d ata item w ith com ponent d ata item s: x-j, x2,
I
an d xn . For each labeled arc Xj, there m u st be an activity at th e opposite
en d of the d ata item x to 'read' or 'access' the com ponent d ata item Xj. The
read behavior of Xj is rep resen ted by the unidirectional arc associated w ith
xir an d an activity is at the head of the arc w hile the d ata item x is at the tail.
The access behavior of Xj is rep resen ted by th e bidirectional arc associated
!
w ith Xj. The spatial an d tem poral parallelism an d sequencing of d ata item s
xl , ..., xn are represented by the data g rap h associated w ith x.
For b o th th e sp lit connector an d th e m erg e connector, w h en n is
equal to 1, th e fan-in arc is unlabled since x a n d its com ponent item Xj are
identical. The single arc m erge (or split) connector rep resen ts th at x is a n
in p u t to th e activity if th e activity is at th e h e ad of th e unidirectional-arc.
The single arc m erge (or split) connector represents th at x is an o u tp u t to the
5'access' corresponds to 'read and write'. The sequence of read and write is unrestricted.
92
activ ity if the activity is at the h ead of the unidirectional arc. The single arc
m erge (or split) connector represents that x is a buffer u sed by th e activity if
t
j the activity is connected w ith x via a bidirectional arc.
I
i A junction connector is com posed of n labeled fan-in arcs: x-^ ..., xn; a
l
; data item x; and n labeled fan-out arcs: Xj, ..., xn. x is a com position d ata item
<
i w ith com ponent d ata item s: xl7 x2, an d xn. For each fan-in labeled arc x{,
! there m u st be an activity at the opposite en d of th e d ata item x to 'w rite' or
'access' th e com ponent d a ta item x {. For each fan-out labeled arc Xj, there j
m u st be an activity a t the opposite en d of the d ata item x to 'read' or 'access’ ;
th e com ponent d ata item Xj. Sim ilarly, the spatial an d tem p o ral parallelism j
a n d sequencing of d ata item s Xj, ..., xn are rep resen ted b y the d a ta g rap h |
associated w ith x. j
i
I
In Figure 3-7(a), th ere are tw o activities, b o th iteratin g an d executing
in parallel. A ctivity A com m unicates w ith A ctivity B via msgs. As depicted
in Figure 3-7(b), msgs is com prised of a sequence of m sg w ith arrival rate of
o n e p e r 2 seconds. Each m sg is a d a ta item w h ich is co m p o sed of tw o
com ponent d ata item s, i.e., com m and an d observation in F igure 3-7(c). As
sh o w n in Figure 3-7(d), com m and a n d observation, b ein g d e n o te d as tw o
c o n c u rre n t d a ta item s, are p ro d u c e d by c o m p o n e n t activ ities of tw o
m u tu a lly exclusive th read s of activities, i.e. A1-A2 a n d A3-A4. Intuitively,
co m m an d an d observation sh o u ld be specified as tw o m u tu a lly exclusive
d ata item s. H ow ever it is possible th at the tim e of the tw o execution threads,
i.e., A1-A2 an d A3-A4, m ay be longer than tw o seconds. T herefore a value of
command (observation) m ay be w ritten to msg w hile a v alu e of observation
93
(com m and) is being w ritten to msg. In a d d itio n , command is n o t a sh ared
d a ta item since A1 w ill n o t concurrently w rite a v alu e to command w hile
A2 accesses it. This is because th e sequence o p e ra to r b etw een A1 an d A2
specifies th a t A2 w ill sta rt only if A1 com pletes. Sim ilarly, observation is
n o t a sh ared d a ta item . R eaders also observe th at in Figure 3-7(e) com m and
a n d observation, being d en o ted as tw o co n cu rren t d ata item s in F igure 3-
7(c), are co nsum ed one at a tim e. A ctivity B1 consum es observation w h en
o b serv atio n is re a d in first, a n d A ctivity B2 consum es co m m an d w h en
com m and is read in first.
every
very
seconds
>nds
msgs
Activity
Activity
(a)
msgs
C * * * % j
X J
every
seconds
msg - 0 -
^command^ (observation)
(b) (c)
Activity A obs^ £ £ o b s
Activity
A1
“ready
Activity
A3
C O
Ihs^nd obseprtffion
f msg J
oompadnd o^sbc^tion
Activity
Activity
A2
A4
Activity B
G D
immand observatio,
read in /
observatio;
Activity Activity
B2
(e) (d)
Figure 3-7: m sg, m odeled with a junction connector, is not a shared data item.
94
_____I
T he equivalent connector p ro v id e s th e c a p a b ility o f a llo w in g
m ultiple d ata m odels for a specific d ata set is req u ire d because th e m anner
in w h ic h a d a ta se t is p ro d u c e d o r c o n su m e d d e p e n d s o n th e
im p le m e n ta tio n (i.e., th e d e co m p o sitio n w h ich re p re se n ts th e selected
J algorithm ) of th e p ro d u ce r activities or th e consum er activities. Figure 3-8
depicts an exam ple in w hich a d ata item , i.e., msgs, has tw o d ata m odels. As
sh o w n in Figure 3-8(a), A ctivity A iterates once p er second w hile A ctivity B
iterates once p er tw o seconds. The d ata item msgs has tw o d ata m odels, i.e.,
one, as show n in F igure 3-8(b)-(c), for th e p ro d u c e r— A ctivity A a n d the
other, as show n in Figure 3-8(d), for the consum er— A ctivity B.
every
very
seconds
>nds
Activity Activity
(a)
[every \
2 seconds
msgs
msg every
1 seconds
msgs
command 1 (observation]
, . consumer view
producer view
(b) (c) (d)
Figure 3-8: a data item w ith tw o decom positions, one from the producer's point of view and
the other from the consumer's point of view
9 5
F or m odeling broadcast (i.e., a sp e c ia l ty p e of o n e -to -m a n y
com m unication), a junction connector w hich has one u n lab eled fan-in arc,
a d ata item x, and n unlabled fan-out arcs are used to rep resen t the broadcast
of x from th e activity at the tail of th e fan-in arc to the activities at the heads
o f fan -o u t arcs. A s sh o w n in F igure 3-9(a), A ctivity A b ro ad casts msgs to
A ctivity B an d A ctivity C. The m an n er th a t a m sg is b ro ad cast is expressed
by th e d a ta g ra p h in Figure 3-9(b) in w hich a m sg is refin ed as a set of
I
re p lic a te d copies of c o m m an d s a n d o b se rv atio n s. T he re p lic a tio n of
com m and an d observation are rep resen ted via a 'C o n cu rren t O bjects of the
sam e class' n o d e prim itive (w hich has be depicted in Figure 3-1(1)).
every msgs
msg
every
2 se :onds
every
2 sec >nds
Activity
Activity Activity
(b)
(a)
Figure 3-9: at each execution iteration, activity A broadcasts m sg to activity B and
activity C
G iv en th e se g rap h ic n o ta tio n s, in th e follow ing, I sh o w h o w a
d a ta /a c tiv ity g rap h can be form ed. T hen, a tem plate for com pletely specify
atom ic activities is also defined. Finally, th e textual n o tatio n for specifying
tim ing an d state changes behaviors of atom ic activities is defined.
96
3.2. REQUIREMENTS SPECIFICATION METHOD
In this an d next chapter, I w ill use th e concepts of g rap h theory to
fo rm ally define a n d an aly ze d a ta g ra p h , activ ity g ra p h , restric te d d a ta
(graphs, restricted activity grap h s, an d task grap h s. T herefore, im m ediately
below I first define specific g rap h theory notions w hich w ill be used.
A g rap h G, G = [V, E], is a collection of p oints a n d sim ple curves w ith
certain properties. T he set of points associated w ith G is called th e v e rtice s,
d en o ted by V = {v-j, v2, ..., vn}. The set of sim ple curves associated w ith G is
called e d g e s, d en o ted by E = {ex, e2, ..., em}. A n ed g e is u sed to indicate the
rela tio n sh ip b etw een vertices. For exam ple, if Vp a n d v^ are related , the
relation w o u ld be indicated b y an edge = (vp, vq ). In addition, the edges j
i
in E have no p o in t in com m on except those co n tain ed in V. Tw o vertices !
are said to be a d ja ce n t if th ey are joined by at least one edge. A set of vertices
are said to be in d e p e n d e n t if they are not joined by any edge. The num ber of
edges incident w ith a vertex is called the d e g re e , d(v), of the vertex v. I V I
represents the n u m b er of vertices in V. I EI represents th e n u m b er of edges
in E. A p a th is defined as a finite alternating sequence of vertices and edges,
beginning a n d ending w ith vertices, such th at each ed g e is incident w ith the
vertices p reced in g an d follow ing it, n o edges ap p ears m ore th a n once, the
term in al vertices are distinct, a n d n o vertex a p p ea rs m o re th an once. A
directed graph (or a diagram for short) is a g ra p h w h ich has a m ap p in g
function 'P to m ap every ed g e into som e ordered p air o f vertices (vir vj).
9 7
____I
Like m o st m athem atical en tities, a large g ra p h can b e co n stru cted
from sm all ones an d to derive its p ro p erties from those of th e sm all ones.
Since g rap h s are defin ed in term s of th e sets of vertices a n d edges, the
com m on o p e ra tio n s in set th eo ry are u se d to define o p e ra tio n s b etw een
f
j g rap h s. In th e follow ing, I briefly describe those o p eratio n s w hich w ill be
! useful in m y discussion on construction of restricted d a ta /a c tiv ity g rap h s,
p artitio n in g of an activity g rap h into m axim al restricted activity grap h s, an d j
construction of task graphs. i
i
i
I
The u n io n of tw o g rap h s G j = (V |, E j) an d G2 = (V2, E2) is an o th er j
g rap h G3 (w ritten as G3 = G j u G 2) w hose vertex set V3 = V | u V 2 an d the !
I
ed g e set E3 = Ej u E2. Likew ise, the intersection of tw o g rap h s is an o th er j
l
g ra p h G4 (w ritten as G4 = G j n G 2) consisting only of those vertices a n d i
I
edges th at are in b o th G j an d G2, i.e., V4 = V j n V 2 an d E4 = E1 n E2. A S
g rap h G is said to have been decomposed into tw o graphs g j a n d g2 if G = g 1 :
u g 2 and g j n g 2 = a null graph (i.e., a g rap h w ithout any edges.) A v ertex v - '
is sa id to b e deleted from a g rap h G if a subgraph of G (w ritten as G - V j) is I
I
ob tain ed by deleting (i.e., rem oving) v t from the vertex set of G an d all edges j
incident on Vj. A n e d g e ej is sa id to b e deleted from a g rap h G if a subgraph !
of G (w ritten as G - e{ ) is o b tain ed by deleting (i.e., rem oving) e^ from t h e }
1
edge set of G. N ote that the deletion of an edge does not im ply deletion of its J
e n d vertices.
A g rap h g is said to be a subgraph of a g rap h G, denoted as g cz G , if
all th e vertices an d all th e edges of g are in G, an d each ed g e of g has the
9 8
sam e en d vertices in g as in G. S ubgraphs th a t d o n o t hav e vertices in
com m on are said to be vertex d isjo in t. C learly, g rap h s th at have no vertices
in com m on cannot possibly have edges in com m on.
I
I
I
i
U sin g th e g rap h ical n o tatio n s d efin ed above, d a ta g ra p h s can be
constructed u sin g th e rules defined im m ediately below .
I
3.2.1. DATA GRAPH
*
i A d ata graph DG is a 5-tuple,
DG = [G, f, g, s, e] j
w here: G = [V, E] is a directed g ra p h in w hich V is th e set of I
nodes and E is the set of edges. j
i
f is a function from V into the set of allow ed n o d e types i
Vdp. (Vdp is defined explicitly below .)
g is a function from V in to th e set of positive integers.
This essentially provides a label for each node.
s is a distinguished node called th e 'start n o d e ’.
e is a distinguished node called the 'end node'.
The set of n ode types perm itted in a restricted d ata g rap h is Vdp = {D,
D e fin itio n 1: A w e ll-fo rm ed d a ta g ra p h DG ( = [G, f, g, s, e], can be
recursively defined as follows:
(1) Let DGk = [Gk, fk, g k, sk, ek] be any single vertex d ata g rap h w ith
Gk = [{vk}, 0 ]
fk(vk) = D j
gk = 1
sk = vk
e k = vk
9 9
(2) Let D G j, DG2/ — , DGk be w ell-form ed d ata graphs,
DGi = [G{/ fi7 gj, vs., ve.]. For the p u rp o se of generality,
the labeling function 'g' I need the follow ing notation.
Let m k = th e m axim al value in the range of g for RDk.
W ithout loss of generality, I also assum e the sets of nodes in
D G lr DG2, ..., DGk are distinct.
k-1
Let M , = X m ..
i =1
T h en :
(a)
DG = [G, f, g, v s, ve] is a w ell-form ed d ata grap h w here:
G = [V,E]
f. (v) if v e Vi
100
_ Expression.
1
(b)
DG = [G, f, g, vg/ ve] is a w ell-form ed d ata grap h w here:
G = [V,E]
E = £ i U { (Vs'V s i ’(Vek Ve>,(Ve’Vl>}
\ (v) if v e Vk
f(v )= < f(vs ) = @ s
.f(ve)
g(v) =
(c)
g (v)
k
g(vs ) =
if v e Vk
gk(v) + 1
= g ,(v ) + 1
DG = [G, f, g, vs, ve] is a w ell-form ed d ata g rap h w here:
G = [V,E]
m
V = U V .
i =1 1
101
£ = (^,S f(v) = f . (v) if v e Vj
g (v )= M i + g i(v ) if v e Vt
(d)
DG = [G, f, g, v s, ve] is a w ell-form ed d ata g rap h w here:
G = [V,E]
v = r 5 v . W f M
Z E . '|u { (V^ VV , ' - ,(Vi’ Vsm:i! = 1 1 J
E =
r fj (v) if v e Vi
f ( v ) = < f(vs ) = @ s
V f(ve) = ( S e
Mi + g j(v ) if v e Vi
g(v) = 8^vs ) =
g(v ) = M
m
(e)
( p [MaxN, N]
102
-DG-=-[G7 f r g r v — V gl'isaw ell-form ed-data-graph-w here:
G = [V, E]
v *u { vj - M
. £ - V ' { (v' V (vV v '}
l k (v) if v e v k
f(v)= { f ( v j = ( 2
s ,
_f(ve) = © e
gk(v) if v € Vk
g(v) = g (vs > = Sk(v> + 1
g(ve ) = g k(v) +1
□
N ote th at w ith the above definition, m atching p airs of nodes (xl7 x2)
(e.g., ( 0 S/ @ }e )) can be identified by g(xj) = g(x2).
3 .2 .2 . A CTIV ITY GRAPH
In th e follow ing definitions of activity grap h s, I assum e the details of
d ata graphs an d com m unication betw een activities are defined. Therefore, I
d o not in clu d e the com m unication connectors a n d in p u ts / o u tp u ts of each
activity in an activity graph.
A n activity g rap h AG is a 5-tuple,
AG = [G, f, g, s, e]
w here: G = [V, E] is a directed g ra p h in w hich V is th e set of
nodes and E is the set of edges.
103
f is a function from V into the set of allow ed n o d e types
Vap. (Vap is defined explicitly below .)
g is a function from V in to th e set of positive integers.
This essentially provides a label for each node.
s is a distinguished node called the 'start node'.
e is a distinguished node called the 'end node'.
I
The set of no d e types perm itted in a restricted activity g rap h is Vap = j
{A, < 0S, {||)e/ © s / © e / © s / © e / © s / © e )-
D e fin itio n 2: A w ell-fo rm ed activ ity g ra p h AG ( = [G, f, g, s, e], can be
recursively defined as follows:
(1) L et A G k = [Gk, fk, gk/ sk, ek] be any single vertex activity g rap h
w ith Gk = [{vk}, 0 ] i
fk(vk) - A |
8k = 1 ;
s k = v k
e k = v k
(2) Let AG 1a AG2, ..., AGk be w ell-form ed activity graphs,
AGj = [Gj, fj, gj, v s., ve.]. For the p u rp o se of generality,
th e labeling function 'g' I need the follow ing notation.
Let m k = the m axim al value in the range of g for A G k.
W ithout loss of generality, I also assum e th e sets of nodes in
AG-j, AG2, ..., AGk are distinct.
* - l
Let M = X m ..
k i -1 *
T h en :
AG = [G, f, g, vs, ve] is a w ell-form ed activity g rap h w here:
104 i
~G = [V, E]
v = ( i' i i v O u { V i ,v e}
E = ( u ^ E . v s ^ '
’•»(vj» Vj \ ( v e ,v e) ,...,( v e ,V e)
m 1
e ’ e
m
}
f. (v) if V e Vj
f(v)=<( f(vc) = © s
f(ve) = © ,
g(v) =
M j + g i(v ) if v e Vi
g(vs ) = M m
g(v ) = M
m
Expression.
(b) AG,
AG = [G, f, g, v s, ve] is a w ell-form ed activity g rap h w here:
G = [V, E]
E = £ u { ( v*-v s j ' & e * v*)’(ve’v s )}
1fk (v) if v e Vk
« v ) = y f(v .) = @ s
f(v ) = m )e
105
g (v)
k
if v e Vk
g(v) =
g = S k^ + 1
g(ve } = g k(c)
AGi
~1
A G 2
AG m
AG = [G, f, g, vg, ve] is a w ell-form ed activity g rap h w here:
G = [V, E]
m
V = u V .
i=l 1
f(v) = f . (v) if v e Vj
g(v) = M j + gj (v) if v e Vj
(d)
AG = [G, f, g, vs, ve] is a w ell-form ed activity g rap h w here:
G = [V, E]
106
f(v) =
g(v) =
(e)
f. (v) if v e V {
f(vs ) = © s
f(ve) = ® e
M i + g j(v ) if v e Vj
g(vs ) = M m
g(v ) = M
m
( p [MaxN, N]
A <\
AG = [G, f, g, vs, ve] is a w ell-form ed activity grap h w here:
G = [V,E]
V k u i v s-
E = £/tu{ (V r V
s ) ’(v e ’ v e
}
f(v)
g(v) =
f k (v) if v e Vk
f ( v j = © s
-f(ve) = © e
g (v)
k
if v e Vk
g(vs ) = g k(v) + 1
g(ve ) = g k(v) + 1
□
107
3 .2 .3 . ATOM IC ACTIVITY
T he d e fin itio n im m ed iately b elo w is u se d in th e tem p late for a
com plete specification of requirem ents of an atom ic activity. T he definition
of the tem plate is defined im m ediately afterw ards.
D efin itio n 3: T extual notations for specifications of th e T im ing C onstraints
a n d Logical B ehaviors (i.e., state tran sitio n b eh av io rs) are d efin ed in th e
follow ing: !
i
< activity_variable> j
|
A n activity variable is an activity-class-nam e startin g w ith u p p e r-c a s e !
letter (e.g., T rackupdate). All activities w ith th e sam e activity_variable j
have the sam e attributes, i.e., having th e sam e data m odel, control f lo w !
m odel, an d sequential pro g ram m odel.
< activ ity _ id en tifier>
>
j A n activity id en tifie r for an activity class is an u n i q u e id e n tifie r
I assigned to an activity class. For exam ple, '1.5' m ay be an assig n ed
identifier of T rackupdate.
< state_variable>
A state v ariab le is an id en tifier sta rtin g w ith low er-case letter (e.g.,
range an d elevation).
< state_ v ariab le_ list>
A state variable list is a list of state variables separated by
< state_ in stan ce_ id en tifier>
A state v ariab le w ith su b scrip ts rep resen ts th e state id en tifier o f the
a c tiv ity in sta n c e sp e cified b y th e first su b sc rip t. F o r ex am p le ,
ran g e x rac k U p d a te i re p re se n ts a sta te v a ria b le of activ ity in stan ce
'TrackUpdatej'.
108
< tim e _ in sta n t_ v a ria b le >
The follow ing seven variables are pre-defined tim e-instant variables.
ay is th e a rriv a l tim e, i.e., th e tim e a t w h ich th e re q u e st for
execution of th e jth iteratio n of activity-instance i arrives, i.e.,
sch ed u lin g p aram eters for th e jth iteration, w h ere j > 1, becam e
know n to the scheduler. These param eters are described next.
rjj is the read y tim e, i.e., the tim e before w hich th e execution of the
jth ite ra tio n of a c tiv ity -in sta n c e i c a n n o t sta rt. T his is a
scheduling param eter.
sdij is th e scheduling deadline, i.e., the tim e by w hich the execution
of th e jth ite ratio n of activ ity -in stan ce i m u st start. T his is a
scheduling param eter.
cdij is th e com pletion deadline, i.e., the tim e b y w hich the execution
of the jth iteration of activity-instance i m u st com plete. This is a
scheduling param eter.
ejj is the execution tim e , i.e., the am o u n t of execution tim e of th e |
jth iteration of activity-instance i. This is a scheduling param eter, j
Sij is th e sta rtin g tim e, i.e., th e tim e at w h ich th e jth ite ratio n of J
activity-instance i begins execution. This variable rep resen ts the 1
execution state of an activity. j
C ij is the com pletion tim e, i.e., the tim e at w hich the jth iteration of 1
activity-instance i com pletes execution. This variable represents
the execution state of an activity.
a ijV t j j, s d ^ , anc* cdjj are com puted dynam ically d e p en d in g u p o n the
state of Ai> d e p en d s o n th e state of A i b u t is k n o w n a priori. Sjj and
d e p en d on th e system w orkload, r^ , s d ^ , cd ^ , an d e^. F igure 3-10 depicts
relationships b etw een tim e-instant variables for activity-instance i (assum ed
to be non-preem ptive).
Figure 3-10: timing instant variables associated with an activity instance
109
E xpressions are bu ilt inductively as follows:
< fu n ctio n >
f (exj, ex2,..., exk), w here k > 0 an d ex i, ex2,..., ex^ are expressions of
tim in g in sta n t v a ria b le s o r sta te v ariab les o f a c tiv ity in sta n c e i.
C onstants such as 1 and 2 are treated as zero-place functions.
For exam ple, +', V , an d 'm od' are functions; 'a+b' or 'a + b ’ is a
function of tw o-place functions th a t exj is 'a' and ex2 is 'b'.
The follow ing T im in g S p ecifica tio n F unctions can u sed to specify t h e '
tim in g p ro p erties of an activ ity instance 'i'. Z ero-place function s are j
c o n stan ts. A lso, e x j, ex2,..., exk are e x p ressio n s of tim in g in sta n t j
variables or state variables of activity instance 'i'', w here k > 0. j
s w j( e x |, ex2,..., exk), th e scheduling w indow fu n ctio n , swjj is t h e 1
sch ed u lin g w in d o w of th e jth iteration, w h e re j > 1, of a c tiv ity !
instance T, i.e., sw ij(ex1, ex2,..., exk) = sdjjfexj, ex2,..., exk) - r ^ e x j, j
ex2,..., exk). !
rdjC exj, ex2,..., exk), th e ready distance function, rdij is th e length ofj
tim e b etw een th e arriv al tim e a n d th e re a d y tim e of th e jth ,
iteration, i.e., r d ^ e x ^ ex2,..., exk) = r^Cexj, ex2,..., exk) - aij(ex1, ex2/— /:
exk). ;
efjCexj, ex2,..., exk), the execution frame function, efjj is the execution j
fram e of the jth iteration, i.e., efjjCexj, ex2,..., exk) = cdjjCexj, ex2,...,,
exk) " rij(exF ex2,..., exk). j
e jfe x j, ex2,..., exk), th e execution tim e function, e^ is th e execution
tim e of the jth iteration. j
9 1
i
I
F ig u re 3-11 depicts th e relatio n sh ip s b etw een th e fo u r tim e in sta n t j
variables: a^-, rjj, sdjj, and cdjj an d th e tim ing specification functions: s w ^ rd i,
efi, an d ei.
110
S^j
! Figure 3-11: relationship betw een tim ing instant variables and tim ing specification
: functions
' sw i, rd i, efi, an d ei d epend u p o n the tim ing or state expressions tuple
i
; [ex-^ ex2/..., exk]. T he tu p le h as k elem ents. O ne can derive the possible
values for each elem ent. A ssum e th at th e n u m b er of possible values of the
first elem ent is n l7 th e num ber of possible values of th e second elem ent is
e x 2,..., exk] h as n j* n 2*...*nk p o ssib le co m b in atio n of v alu es. H ence, th e
tim ing constraints of activity instance i can be specified as a table of n k row s
an d 4 colum ns th at each row rep resen ts a possible state an d each colum n
represents one of sw i, rdi, efi, and ei- j
F orm ulas are b u ilt inductively as follows.

PiCexj, ex2,..., exk), w here k > 0 an d exa, ex2,..., exk are expressions of
activity instance 'i'. Predicates include <, <, >, an d >. I
n 2,..., the nu m b er of possible values of the kth elem ent is n k. The tu p le [exj,
< eq u ality >
exj = ex2, w here exi an d ex2 are expressions,
clo g ical connectives>
->w, w^ a an d w, v w2 w h ere w , W j, an d w 2 are form ulas.
I l l
______ i
tim in g _ c o n s tra in t_ fo rm u la is a form ula w ith only tim e_instant_variables.
p re _ c o n d itio n _ fo rm u la s and p o s t_ c o n d itio n _ fo rm u la are form ulas w ith
only state_variables. The follow ing tim ing_constraint_form ula m u st hold.
ajj < ri- < sdij < cdjj (3-El)
rjj < Sjj (3-E2)
(S jj + ejj) < qj (3-E3)
(equality holds for non-preem ptive execution)
sij - ai(j + 1) (3-E4)
sw^ < efjj (3-E5)
These relatio n sh ip s ap p ly to all activity instances. Specific typ es of
activities are characterized by additional constraints as described in the next
subsection.
D efin itio n 4: A n atom ic activ ity is a sequential (sub)program u n it w hich is
declared as follows:
activ ity ;
re q u ire < pre_condition_form ula> ;
en su re < post_condition_form ula> ;
p re e m p tio n ;
state v ariab les ;
im portance level ;
tim in g c o n stra in t ;
resource req u ire m e n ts ;


e n d < activity_nam e>;
In D efin itio n 2, th e fo rm u la asso ciated w ith require defines-T he 
p ro p erties w hich m u st be satisfied by th e values of in p u t variables; the 
fo rm u la asso c iated w ith ensure d efin es th e p ro p e rtie s w h ich m u st be 
satisfied by th e values o f o u tp u t variables. T he preem ption flag if TRUE, j 
indicates th a t th e execution of this activity is p reem p tiv e; o th erw ise the
112
activity is non-preem ptive. The , containing d etailed behavior 
o f each atom ic activity, is th en rep re se n te d u sin g a p ro g ram d escrip tio n 
lan g u ag e (such as a subset of A da). T hat is, all of the in p u ts n eed not form 
| p a rt of the enabling function. The resulting sim plified A da PDL is lim ited to 
; th e follow ing types of statem ents: assig n m en t, if, lo o p , case, n u ll, exit a n d
! re tu rn .
!
1 In su m m a ry , th e p ro p o se d sp e cifica tio n m e th o d h as a 3 -p a rt
co m p u tatio n al m odel. In th e follow ing three tables, each table sum m arizes 
h o w each p a rt of com putational m odel is supported.
In T able 3-A, h o w th e re q u ire d p ro p e rtie s of d a ta m o d els are 
su p p o rted by using data graphs is described.
Desired Properties 
in Data Models
Expressible
Properties
Composition
• non-atomic data items are 
decomoosable.
Conditional Sequences
• supported by the 'selection', 
'iteration', and 'data item' 
primitives.
Parallel Sequences
• supported by the 'concurrency', 
'iteration', and'data item' 
primitives.
Multiple Instances of 
The Same Type
• supported by the 'replication', 
'iteration', and 'data item' 
primitives.
Timing Specification
• predicates expressed by time 
instant variables.
Table 3-A: support in specification of data models
I
113
In Table 3-B, ho w the req u ired properties of control flow m odels are 
su p p o rted by using activity graphs is described.
liesirea rro p eru es 
In Control Flow 
Models
Expressible
Properties
Composition
• Supported by composite 
activities.
Conditional Sequences
• supported by the 'selection', 
'iteration', 'activity' primitives.
Parallel Sequences
• supported by the'currency', 
'iteration', and 'activity' 
primitives.
Multiple Instances of 
The Same Type
• supported by the 'replication', 
'class object’, and 'iteration' 
primitives.
Timing Specification
• predicates expressed by time 
instant variables.
Enabling and 
Exiting Criteria
• supported by pre-condition & 
post-condition formulas.
Table 3-B: supports in specification of control flow models
Table 3-C show s ho w the req u ired properties of control flow m odels 
are su p p o rted by using the atom ic activity concept.
Desirable Properties 
in Sequential 
program Models
Expressible
Properties
Stimulus and 
Response Relationship
• supported by pre-condition & 
post-condition formulas 
defined in Section 3.2.
State Changes • supported by using ADA PDL 
and 'state variables'.
Timing Specifications
• timing constraints formulas 
defined in Section 3.2.
Interconnections 
Between Programs
♦ A unrestricted activity graph 
defines relationships between 
programs.
Validation Joints 
and Criteria
• supported by pre-condition & 
post-condition formulas 
defined i n Section 3.2.
Table 3-C: supports in specification of sequential program models
114
T he sy stem s I co n sid er h e re are larg e scale system s, em p lo y in g 
m u ltip le h etero g en eo u s processors to achieve th e re q u ire d perform ance. 
F u rth e rm o re , in su ch system s, th e h ig h level (m acro) system fu n ctio n s 
Require m u ltip le resources and, at a single resource, th e w orkload can have 
a v ariety of tim in g p ro p erties w hich can n o t be re p re se n te d by a single 
m odel (i.e. a single type of activity). Therefore, designing schedulers for such 
a system involves in teg ratin g m acro- an d m icro-level w hich at th e m acro 
level involves scheduling of activities req u irin g m u ltip le resources a n d at 
the m icro level involves scheduling m u ltip le types of activities in a single i
i
resource. N o single scheduling policy can effectively m an ag e all types of | 
activ ities. To fin d a 'g o o d ' a lg o rith m fo r sc h e d u lin g c o m p u ta tio n a l 
activities to co n su m e reso u rces, o n e m u st be able to ch aracterize th e 
w orkload (i.e., h o w resource are consum ed b y these activities) im posed on 
each ty p e of resource. Then select a scheduling policy w hich can effectively 
satisfy the resource dem ands of com putational activities. In th e next section,
I classify activities w ith the goal th at m ajor activity classes are of interest in 
eng in eerin g sem i-h ard real-tim e control system s. Each class characterizes 
the tim ing p ro p erties w hich in tu rn define th e scheduling problem of each 
class of activities.
115
3 .3 . TIM IN G ANALYSIS APPRO A CH ES
O ften, th e arriv al tim es are n o t tak en in to acco u n t in specifying
i
; sc h ed u lin g p ro b lem s. H o w ev er, th e a rriv a l tim e d e te rm in e s w h e n th e 
param eters of an activity instance becom e know n to a scheduler an d hence 
' th e am ount of advance notice in w hich to plan. It is easy to see th at this can
t
j be an im p o rtan t aspect of the scheduling problem .
i
The tim ing and resource specification of an activity is defined as a set 
of 'c o n stra in ts’ o n th e tim e in sta n ts for each a ctiv ity in stan ce. T hese 
co n strain ts affect th e p o ssib le legal 'schedules' g e n e ra te d by a specified 
scheduling policy. For exam ple, as show n below , b y specifying constraints ! 
o n th e re la tio n sh ip s b e tw e e n th e (j-l)th ex ecu tio n of Ai a n d th e jth 
execution, I can define th e tw o classical types of activities, nam ely, 'periodic' J 
a n d 'sporadic' activities .
It is com m on to th in k of activities as being executed sporadically o r i 
perio d ically . T he classic n o tio n of a p erio d ic activ ity is th a t successive 
instances are reg u larly spaced. A t th e other extrem e, instances of sporadic 
activities are relatively u n c o n strain ed 6. These classic notions involve quite 
sim p le co n strain ts o n th e tim in g in stan ts w hich w ill be d efin ed shortly. 
T here are, how ever, m any possible variations b etw een these tw o extrem es. 
For exam ple, frequently, th e p erio d icity of a p erio d ic activity can change
6For example, [Mok83] only restrict the interval between successive arrivals to be no less 'x' 
units of time.
116
w h e n the system changes its m o d e 7. T here are relatively few m odes an d 
m o d e changes are relatively slow , co m p ared to the p erio d of each m ode. 
H ow ever, if th e m ode can change frequently or an arbitrarily large nu m b er 
of m o d es can b e in te rle a v ed , th e re is an im m en se v a rie ty of p o ssib le
i
•execution seq u en ces. In th is case, it is n o t p rac tic al to u se ju st som e
I
m o d era te n u m b er of m odes to classify all situations. T herefore, u sin g th e 
; classic n otion - th a t arrivals of successive activity instances to be sch ed u led i
I ,
;are predictable an d the interval betw een successive instances is a constant - j
I t
can n o t com pletely m odel th e state change b eh av io r of activities. As a J 
so lu tio n , I su g g est one generalizes th e n o tio n of p erio d ic by relaxing th e 
constraints of constant intervals as described below .
3 .3 .1 . A CTIV ITY TAXONOM Y
I classify activities based on a taxonom y of constraints o n th e a rriv a l 
itim es of an activity's in stan ces. A lth o u g h m an y v ariatio n s of co n strain ts
j
m ay be im p o sed on tim e in sta n ts a n d , th u s, form d iffe re n t ty p es of j 
activities, the goal of o u r classification is to identify m ajor activity classes j 
w h ich are of in te rest in en g in eerin g sem i-hard real-tim e control system s. 1 
M y choice is b ased o n an extensive stu d y of sensor b ased, sem i-h ard real
tim e system s for avionics applications. A d etailed application exam ple is 
described in Section 3.4 to justify th e tax o n o m y p resen ted here. T ypes of 
activities are rep re se n te d as n odes in th e taxonom y in F igure 3-12. The
7 A m ode represents a system state in which a set of com putational activities cooperatively 
executed to achieve a specific system objective.
117
d e fin itio n of each n o d e in th e tax o n o m y w ill b e fo rm a lly d e fin e d 
afterw ards. The figure is m ean t for reference as th e definitions are given to 
aid in keeping track of the context of each definition.
Figure 3-12: an activity taxonomy via classification of constraints on arrival times j
As show n in Figure 3-12, activities are d iv id ed into tw o m ajor classes: |
'N o n -R ep etitiv e S poradic' a n d 'repetitive'. T he 'N o n -R ep etitiv e S poradic' j 
activities are expected to execute once - this co rresp o n d s to one notion of ! 
sporadic activity [Cheng& Stankovic88]. A n activity is specified as repetitive 
by en clo sin g a n ite ra te r co n stru ct in its activity graph. By characterizing the 
rep etitio n p ro p erties, 'repetitive' activities can be fu rth e r d iv id e d in to -tw o 
classes: (1) those for w hich each instance's arrival tim e is u n p red ictab le and 
(2) those for w h ich each in stan ce's arriv al tim e is p red ictab le. A lth o u g h 
sp o rad ic activities can be 'rep etitiv e w ith u n p red ictab le arrival tim es', in 
th e classical n o tio n [M ok83], a sim ple co n strain t m ay be im p o sed on the
activity
Non-Repetitive
Sporadic
repetitive
Adaptive Sporadic General
predictable unpredictable
arrival
Periodic Timing
Sporadic Spaced 
Sporadic
NRVPcd RYPcd NRCP^ RCP^ N R V P j RVPsd N R C P^ R C P ^
118
low er b o u n d of arrival intervals. In the follow ing, each activity class in the 
activ ity tax o n o m y is d e fin e d fo rm ally in term s of th e sch ed u le tim e 
in stan ts. A lso, successive definitions, co rresp o n d in g to n o d es 'd eep er' in
| th e taxonom y, are m ore constrained th an their p a re n t class.
i
D efin itio n 5: A n activity w hich is expected to occur once an d n o constraints 
a re d efin ed on th e arriv al tim e is term ed a N o n - R e p e t i t i v e S p o r a d ic 
j activity.
i
!
D efin itio n 6: A n activity w hich is expected to execute u n b o u n d ed n u m b er of 
tim es is term ed a re p e titiv e activity.
D e fin itio n 7: A repetitive activity for w hich a constraint on th e arrival tim e 
of th e jth ex ecu tio n is d efin ed in tu rn s of tim e in sta n ts of th e (j-l)th 
execution instance is term ed a p re d ic ta b le a r riv a l activity. O th erw ise it is 
term ed a n on -predictable a rriva l activity.
D efin itio n 8: '
(1) A s p a c e d s p o r a d ic activity is a n o n -p red ictab le arriv al rep etitiv e J 
activity Aj w hich has a constant m inim um interval m such th at [
aij" a^j-D * m Vj > 0.
(2) A S p o r a d ic activity is a non-predictable arrival rep etitiv e activity 
Aj w hich has arrival intervals in a range of values o r are stochastically 
d istrib u ted values.
D efin itio n 9:
i
t
(1) A g e n e r a l p e r io d ic activity is a predictable arrivals a ctiv ity Aj | 
w hich is constrained by aij = cdi(j-i) Vj > 0 or a^ = sdi(j-i) Vj > 0.
(2) A G P cd activity is an activity Aj w hich is constrained by
aij = cdi(j-i),
efij = cdij - aij Vj > 0.
119
(3) A GPsd activity is an activity A i w hich is constrained by 
aij = sdi(j-i), 
efij = sdij - a^ Vj > 0.
In th e follow ing, I u se 'v ariab le' generally to rep re se n t values w hich are 
! 'u n k n o w n ' or 'restricted to a range of values'.
D efin itio n 10:
(1) A constant period GPC d activity, i.e., 'CPcd' activity, is a GPcd activ ity 
w hich has a constant period p such th at
aij - ai(j_i) = p Vj > 0.
O therw ise, it is a variable period GPcd activity, i.e., /VPC < J ' activity.
(2) A constant period GPsd activity, i.e., 'CPsd' activity, is a GPsd activity 
w hich has a constant period p such th at
aij - ai(j_i) = p Vj > 0.
O therw ise, it is a variable period GPsd activity, i.e., 'VPsd' activity.
Figure 3-13 depicts the relationships b etw een the tim ing attrib u tes for 
a CPcd activity.
period
Figure 3-13: relationships of CPcd activities' timing attributes and state
120
Definition 11:
(1) A restrictive VPC £ activity, i.e., a 'R V P cd' activity, is a /VPcd' activity 
w hich is further restricted by:
i-ij = aij.
O therw ise it is a unrestricted VPcd activity, i.e. a 'N R V P cd' activity.
(2) A restrictive CPcd activity, i.e., a /R C P cd' activity is a 'C Pcd' activity 
w hich is further restricted by:
rij = aii-
O therw ise it is a unrestricted CPa$ activity, i.e. a 'N R C P cd' activity.
(3) A restrictive VPSd activity, i.e., a 'R V P sd' activity is a 'V Psd' activity 
w hich is further restricted by:
rij = aij.
O therw ise it is a unrestricted VPSd activity, i.e. a 'N R V P sd' activity.
(4) A restrictive CPsi activity, i.e., a 'R C P sd' activity is a 'C Psd' activity 
w hich is fu rth er restricted by:
rij = aij.
O therw ise it is a unrestricted CPg^ activity, i.e. a 'N R C P sd' activity.
period ^ ^_________ period
------------- i ------------------------ ► -  c ----------- ------------- -------------
\7 7rn T \  777\ V71
s i(j-l) f c i(H> / V ' i
preem pted preempted
3i(j-l) ~ T i(j-l) ~ ^10-2)%
/ a i i - r ii~ A
/a iij » )
Figure 3-14: relationships of RCPcd activities' timing attributes and state
121
N ote th at th e RV Psd an d RV Pcd activities co rresp o n d to th e n o tio n of 
'p e rio d ic ta s k s ' w ith m o d e ch an g es w h ile R C P sd a n d R C Pcd a ctiv itie s 
co rresp o n d to th e classic n o tio n o f 'p e rio d ic ta sk s'. Figure 3-14 depicts the 
relationships of these tim ing attributes for RCPcd activities.
F ro m th e d e fin itio n s, th e jth arriv a l tim e of a ’G en eral P erio d ic’ 
activity d e p en d s m ainly o n the intrinsic p ro p erties of th e activity ra th e r 
th a n h o w its (j-l)th in stan ce w as executed o r sc h ed u led . But, as w ill be 
d efin ed im m ed iately below , for an ’ A d a p tiv e T im in g ’ activ ity th e jth 
a rriv a l tim e d e p e n d s o n th e (j-l)th ex ecu tio n in stan c e of th is activity. 
F u rth e rm o re , the rea d y d istan ce an d th e u tilizatio n fram e of a ’general 
p erio d ic’ activity are predictable, b u t for an ’A daptive T im ing’ activity the 
jth arrival tim e d ep en d s on its (j-l)th execution instance.
D e fin itio n 12: A n A daptive Tim ing activity is an activ ity A i w h ich is 
restricted by:
a ij = ci(j-l) or aij = si(j-l) V1 > °/ 
efjj are dynam ically determ ined.
D efin itio n 13:
(1) A n 'A T C ' activity is an 'a d ap tiv e tim ing' activity w hich is fu rth er 
restricted by:
efjj = cdjj - ajj.
(2) A n 'A T S ' activity is an 'ad ap tiv e tim ing' activity w hich is further 
restricted by:
efij = sdfj - ajj.
122
The relationships of tim ing attributes of an ATC ad ap tiv e activity are 
illu strated in Figure 3-15, th at of an ATS ad ap tiv e activity are illu strated in 
Figure 3-16.
iC j-l)
sw.
i(j-l)
i(j-l) i(j-l) i(j-l) i(j-l) i(j-l) i(j-l)
cd.
a.. C;;
1 execution in this interval
Figure 3-15: relationships of AT£ activities’ timing attributes and state
r 4 (j-i) 
<— >
e f i(H> J
S W . 
i(j-l)
-------------- 1 -----------------
<--------■ ------>-
------- 1 -----------
ai(j-l) ri(j-l) S i(j-1) Sdi(j-1) ci(j-l) C di(j-1)
rdjj
* * 'W
e f ij J
sw ij
I 1
\ rij s i
4 - “
1 execution in th is interval 
Figure 3-16: relationships of ATg activities' timing attributes and state
123
If an activity has a constant execution tim e an d th e execution of the 
activity is n o n -p reem p tiv e, th en th e ATC an d ATS types of activities are
identical.
R eader can observe in Figure 3-13 to 3-16 th at activity A4 executes 
exactly once in th e interval (r^ - a^j.-j)) for every tw o successive iterations (j- 
1) a n d j. U sin g th is fact, in th e fo llo w in g , I first define th e n o tio n of 
u tiliz a tio n factor. By u sin g this n o tio n , I sh o w th e effect of m o d e lin g j 
ad ap tiv e tim ing activities by periodic activities. T hen, I show h o w one can ! 
! tu n e scheduling param eters of an activity such th a t th e am o u n t of resource 
usage is u n d e r a given bound. i
D e fin itio n 14: Let T = {Tj I Tj = (aj, Ty sdj, cdj, e^, Sj, Cj), j > 0} be a set of tim e j 
instants tu p les of activity Ai. Each tim e instants tu p le represents the tim in g j 
characteristics in th e jth iteration of of activity Ai.
Let Uj be the utilization factor of activity Aj in the jth iteration, th en j
e . I
u = 7 ------ (3-E6) j
J 0 + D J . 1
L et u be the total utilization of Aj and n b e the n u m b er of execution 
iterations of A i , then
n
u = ^ «• (3-E7)
7 = 1 1
124
3.3.2. EFFECT OF MODELING ADAPTIVE TIMING ACTIVITIES BY 
PERIODIC ACTIVITIES
i
j A n atu ral question is w h y it is necessary to in tro d u ce the concept of
i
'a d ap tiv e tim ing' activities rath e r th a n sim ply u se p erio d ic activities. As 
w ill be show n in th e follow ing analysis, to use a periodic activity to m odel
an ad ap tiv e tim ing activity w ill increase, even double, th e utilization factor
i
of an activity an d significantly degrade system perform ance.
S u p p o se th a t an activ ity n e ed s 2 u n its ex ecu tio n tim e a n d tw o 
successive execution instances of th e activity m u st n o t exceed 8 tim e units. 
The d iag ram im m ed iately below depicts an acceptable schedule for this 
activity.
W e can m odel this activity as an ATS activity w ith the execution tim e 
e = 2, the read y distance r = 2, the scheduling w in d o w = 6, the utilization 
fram e ef = 8. W ith this definition, in a feasible schedule w hich includes this 
activity, th e tim e in terv al b etw een tw o successive execution instances w ill 
n o t exceed 8 tim e units. If th is activity started at th e scheduling d ead line, 
th en th e u tilizatio n factor u has the sm allest value; if th e next iteration of 
1 his activity sta rts rig h t at the com pletion, th e u tiliz a tio n factor has the 
argest value. H ence,
O ne m ig h t try to m o d el this activity as a R C Pcd activity (i.e. the 
classical periodic activity) w hich has a period p = 8, an d an utilization factor 
= 0.25. The d iag ram im m ed iately below illustrates a feasible schedule for 
this periodic activity.
  8 ------------------------ 8 ---------------------  8  H
1 " I 1 I —r— i— i—i—i— 1 1 1 —i—i —i—i—i—i—i—i—i —i—i—j— t ~ 1 —i
0 5 10
15 20 25
T herefore, m o d eled as a RCPcd activity, th e tim e in te rv al b etw een
tw o successive execution instances could have a m axim um tim e interval of j
|
16 tim e u n its. This clearly violates the requirem ents of tim e constraints. j
i
In o rd e r to m o d el this activity as a RCPcd activity a n d g u a ra n tee i 
m eeting tim e constraints, the p erio d m u st be decreased. L et p ' be th e new 1 
p erio d , and j
( P+ e) !
f = t — .
Then for this exam ple, p' m u st be less than or equal to 5, i.e. 2 < p ’< 5. 
T herefore, 1 > u > 0.4. A feasible schedule, e.g. th e o n e illu strated in the 
d ia g ra m b elo w , can n o t h a v e a tim e in te rv a l b e tw e e n tw o successive 
execution instances exceeding 8 tim e units.
I
5
10 15 20 25
126
D ecreasing the periodicity of a RCPcd activity can m ake it satisfy the 
req u ired tim e constraint, b u t th e new utilization factor can be double, i.e.
e 2e
w =
(P+ e)\ (p + e)
( ^ )
u' 2 p
u p + e
W hen p » e, then — « 2 
r u
T herefore, to force an a d ap tiv e tim in g activity in to a RCPcd m odel, 
can resu lt in excessive resource utilization. This m ay resu lt in a non-feasible 
schedule particularly w hen the total w orkload is high.
127
3.3.3. TUNING SCHEDULING PARAMETERS
O bserving eq u atio n 3-E6, for a given execution tim e, th e u tilizatio n 
factor decreases as th e interval b etw een th e arriv al tim e to th e next rea d y 
[tim e increases. This w ill resu lt in a sm aller scheduling w in d o w in th e next 
i iteration. O n th e o th er h a n d , if th e sm aller scheduling w in d o w is in each 
ite ra tio n , i.e. th e in te rv al b e tw ee n th e re a d y tim e a n d th e sc h e d u lin g 
d eadline, m eans less o p p o rtu n ity for a rea d y activity to be sch ed u led a n d ; 
gives th e scheduler less flexibility. O ne m ight conclude th at the rea d y tim e | 
sh o u ld be set eq u al to th e a rriv a l tim e, i.e. rd = 0, w h ich g iv es th e j 
scheduling w in d o w the largest possible length. W ith rd = 0, th ere are tw o | 
draw backs: (i) this activity can dom inate th e u se of a resource an d (ii) th e |
sch ed u lin g o v erh ead m ay be h ig h er since th e n u m b er of rea d y activities j
i
th a t are exam ined in a scheduling decision increases in p ro p o rtio n to th e I 
size of th e scheduling w indow . As stated earlier, utilization of a resource 
m ay be constrained to a specified bound. In the follow ing, I w ill derive a set 
of c o n strain ts for th e re a d y tim e b ased o n th e fact th a t (i) exactly one 
execution is allow ed b etw een th e arrival tim e a n d th e next read y tim e, (ii) j 
th e re a d y tim e of th e jth iteratio n is th e first sta rta b le tim e, (iii) th e j4* 1 j
iteratio n m u st start by th e scheduling deadline, (iv) th e u tilizatio n factor in !
t
each iteration cannot exceed a specified b o u n d b . j
W ith g iv en sc h ed u lin g p a ra m e te rs (sw j, rdj, efj, e ^ a n d reso u rce 
u tilizatio n b o u n d b (i,e., Uj < b < 1) of activity Aj, at the jth iteration, a tim e 
in stan ts tu p le (ajj, r^, sdjj, cdjj, e^, s^ , c^) exists an d satisfies th e follow ing 
equation derived from 3-E6.
128
T herefore,
(3-E8)
T herefore, for an activity w hich is req u ired to use less th an or equal j
th a t rj(j+i) ^ sd i(j+1) m u st hold according to equation (3-El).
3 .3 .4 . EXAM PLES O F USING TH E PRO PO SED T IM IN G ANALYSIS 
A PPR O A C H
I
In th e follow ing exam ples, th e w o rk lo ad of a system can h av e a (
activity. T he tw o exam ples illu stra te ho w to describe th e v ariatio n s of
I
tim in g c o n strain ts of activities for th e sensor reso u rce in an ad v an c ed j 
sen so r system an d h o w th e tim in g constraints of these activities can be | 
rep resen ted .
i
E xam ple 1: critical adaptive activities w ith rigid tim in g constraints.
W eapon su p p o rt activities are an exam ple of this ty p e of activity. To 
su p p o rt an 'X' ty p e of m issile, a ra d a r system m u st p e rfo rm a sensing 
activ ity (e.g. se n d in g a m issile m essag e a n d th e n illu m in a tin g targ ets) 
successively, a n d th e tim e in te rv al b etw een th e sta rtin g p o in ts of tw o 
successive sensing activities m u st be w ith in a in te rv al of [6.. 10] u n its of 
tim e. In a d d itio n , th is ty p e of sen sin g activities is c o n sid ere d th e m ost 
critical activity. H o w ev er, w h e n m u ltip le m issile s u p p o rt activities are
to 'b %' of a resource, its read y tim e m odified according equation 3-E8. N ote
v ariety of tim ing properties w hich cannot be rep resen ted by a single type of
129
requested, th e im portance level of each activity is defined by the im portance 
level of th e targ e ts to be illu m in ated . F igure 3-17 illu stra te s th e tim e 
in stan ts for this exam ple "m issile su p p o rt" activities.
\
p = 0 - i.e. this activity is non-preemptive 
level = 1 - i.e. this activity is most critical.
! V j ,j > l
ar s< h>
rd , = r)-aJ = 6
swj = sdj - r 4
ef p cd. - r .= 1 2
e .= 6 
J
 1 ---- 1 ----- 1 ----- 1 ----- 1 ----- 1 ----- 1 I 1 ----- 1 ----- 1 ----- 1 -----1 -----
t t+2 t+4 t+6 t+8 t+10 t+12 t+14 t+16 t+18 t+20 t+22 t+24 t+26
a (j-D r (j-D S C(j-D 0(1 (j-1)
I -------1 — M-----1 I - ;
ai rj si ci aii j
Figure 3-17: scheduling parameters specification of an example strict ATs activity 
E x am p le 2: a d a p tiv e ac tiv ities w ith so ft tim in g c o n stra in ts.
T he h ig h level objectives of th is class o f activities are to m ain tain a 
m in im u m o verall system perform ance w ith in a specified tim e interval. A n 
ex am p le is an 'alert search’ activity in w h ich th e h ig h level objective is j
specified in term s of R9Q for a specified 'search' fram e from w hich efgp, the |
!
m ax im u m a llo w a b le e la p se d tim e b e tw e e n tw o su ccessiv e c o m p lete : 
scanning of a search fram e, can be com puted. j
130
a search frame- a SF activity
SDk
SBl
SB2
f:
SB4 SB3
Figure 3-18: a ’search alert ’activity repetitively scans a search frame
Figure 3-18 depicts th a t a search activity rep etitiv ely scans a search 
frame, i.e., perform s Search Fram e (SF) activity. Each SF activity consists of 4 
Search Bar (SB) activity. Each SB activity consists of 5 Search D w ell (SD) 
activity. T he d e co m p o sitio n is b a sed on th e k n o w le d g e of th e sen so r
j
capabilities, the n u m b er of integral segm ents (i.e., search bars), n SB, an d the j
n u m b er of atom ic sensing activities (i.e., search dw ell activities), n BD, in ;
i
each search fram e can also be estim ated. Therefore, eBD, the p erio d betw een j 
each scan, can be also be com puted. In Figure 3 -1 8 ,1 assum e nSB = 4 and n SD 
= 20.
131
level = 15 - i.e. this activity's importance level is less than the 'track 
update’ activities.
A search fram e (SF) activity is decom posed into 4 search b a r (SB) 
activities.
A SB activity is decom posed into a sequence of search dw ell (SD) 
activities.
[Max#SF, Current#SF] Search
Alert
e f c F< Maximum 
^ Revisit 
Time SD
Requests
Search
Alert
Scheduler
(Coordinator)
SF
control"
com m a:
(a) (b)
SBk
SDm
SBl
SD(m+l)
SB2
SB3
SD(m+3)
S B l
SD(m+4)
(c) (d)
Figure 3-19: the control flo w m odel o f a search activity
F ig u re 3-19(a) specifies th a t th e sy stem u n d e r c o n sid e ra tio n is 
req u ire d to h an d le a set of co ncurrent Search Alert A ctivities. T he system 
m u st be able to h an d le u p to M ax#SF concurrent Search A lert A ctivities. A 
Scheduler keeps tracks of th e n u m b er of enabled Search Alert A ctivities in 
state variable CurrentttSF. Scheduler is also responsible for coordinating the
132
execution of all Search Alert activities. SD Requests (i.e., the SD activities 
to g eth er w ith th eir sch ed u lin g p a ra m eters) are se n t to Scheduler . The j
I
sch ed u ler w ill select th e h ig h est sch ed u lin g p rio rity w hich is c o m p u ted I
i
•from th e sch ed u lin g policies (such as those to be discussed in C h a p te r 5). !
I
i
iThen, an a ctiv a tio n co n tro l c o m m an d w ill b e se n t to th e selected SD
i
t
j activity. Figure 3-19(b) specifies th at each Search Alert activity rep etitiv ely 
p e rfo rm s an SF , i.e., Search Fram e. T he tim e in terv al b etw een each 
iteratio n can n o t exceed th e Maximum Revisit Time w hich is d eriv ed from 
th e com putational accuracy specified in the system requirem ents. Figure 3- 
19(c) specifies th a t each SF activity consists of a sequence of Search Bar (SB) 
activities: SB l, SB2, SB3, and SB4. For 2 < k < 4, each SBk activity cannot 
start until SD (k-l) activity com pletes. Figure 3-19(d) specified th at each SBk
I
{activity consists of a coherent sequence of Search Dwell (SD) activities. The 
rela tio n sh ip b etw een th e m th SD and th e kth SB in a search fram e is m = 
5*(k-l) +1. A lso SDm is a non-preem ptive atom ic activity for 1 < m < 20.
Based on F igure 3-19(b), an SF activity is an ATc activity since its 
arriv al tim e (i.e., th e tim e at w h ich all th e sc h ed u lin g p a ra m e te rs are 
kn o w n to the scheduler) of th e jth iteration is th e com pletion tim e of th e (j- 1 
l ) th iteratio n , i.e., aSF j = CgF ( j - 1 ) V > 3 > L A lso, th e read y tim e of each | 
instance is th e tim e at w hich the activity arrives, i.e., r SF j = aSF^ j V j, j > 1. J 
In every iteration, the arrival tim e of the first search b ar ( i.e., SBl) an d the 
first search dw ell activity ( i.e., SD1) is equal to th a t of th e search fram e, i.e., 
aSF,j = aSBi,j = aSDi,j 1 - 1- The com pletion deadline of th e last search bar
(i.e., SB4) an d th e last search dw ell (i.e., SD20) is equal to th at of th e search 
fram e, i.e., cdSF^ = cdSB4 j = cdSD20 j V j, j > 1. This pro p erty also holds for the
133
c o m p l e t i o n t i m e , i . e . , c S F j = c SB4 j = c S D 2 0 / j V j, j > 1 . E a c h s e a r c h b a r i s a n A T C
activ ity since aSBk^ > cSBkj Vj, j > 1 an d 1 < k < 4. Sim ilarly, each search 
dw ell activity is also an ATC activity. Figure 3-20 depicts th e w orkload m odel 
d eriv ed from the tim ing constraints specifications associated w ith the search 
fram e (SF) activity, the search bar activities (i.e., SBl, SB2, SB3, an d SB3), and 
jthe search dw ell activities (i.e., SD1-SD20).
a SB4, j
Figure 3-20: the w orkload m odel transformed from the activity graph specified in 
Figure 3-19
V j > 1,1 < k < 4,1 < m < 20, m = 5*(k-l) +1 
rS F ,f 3 SF, j = a SBl, j = a SDl, j 
r SBkTJ a SBk, j 
rSDm,j~ a SDm,j 
SBk, j SDm, j 
CdSF, f c d SB4, j = c d SD20, j 
CSF,T C SB4, j = C SD20,j 
aSDm, jC SD(m-l), j
^F,j C SF,(j-l)
1 :dSBl, j
cd
SB4,j
aSBl,j CgBl j
c d SB2, j
aSB2, j SBl, i
cdSB3, j
a.
SB3, j
c
SBl, j
134
In th e a p p lica tio n u n d e r co n sid era tio n s, th e effective u se of th e 
jsensor has a m ajor im pact on th e o verall system perform ance. O ne of the
i
jm ain o b jectiv es is to fin d a 'g o o d ' a lg o rith m fo r sc h e d u lin g se n so r 
|activities. M ost sensor activities fall into the ATC ty p e of n o n -p reem p tiv e
activity since (i) th e execution tim e of sensor activities is state d e p e n d e n t 
(i.e. b ased o n th e o w n sh ip m otion an d th e estim ated targ e t state) a n d is 
u su ally d eterm in ed a t th e latest possible m o m en t b ased on th e m o st u p-to- 
jdate in fo rm atio n available, (ii) th ey are n o n -p reem p tiv e activities, an d (iii)
I th e sensor u tiliza tio n is subject to an u p p e r b o u n d w hich is d y n am ically 
d eterm in ed b ased on the high level system objectives. The m ain objective 
of d esig n a so ftw are arch itectu re for ad v an ced sensor system s is to fin d 
'g o o d ' sen so r m an ag em en t ap p ro ach es w h ich in tu rn s are to find 'g o o d ' j
i
algorithm s for sch ed u lin g the n o n -p reem p tiv e ATC ty p e of activities. In th e j 
follow ing, I w ill define a design m eth o d o lo g y w hich allow s d ev elo p ers to 
ad eq u ately allocate th e com putational activities in a requirem ents m o d el to
t
th e ru n-tim e entities in a design m odel such th a t a d irect m ap p in g relation 
exists b e tw e e n req u ire m e n ts a n d d esig n . T his m eth o d o lo g y also a llo w 
designers to validate their design iteratively at different levels.
4. A D ESIG N M ETHOD OLO GY FOR REAL-TIME SOFTWARE
j The design m ethodology p resen ted in this chapter treats a softw are
| a rc h itectu re as a set of ru n -tim e entities, in clu d in g tasks a n d ex tern al
| | 
in p u t/o u tp u t elem ents, w hich interact either via m essages or sh ared d ata j
I
i structures. A task is a p ro g ram u n it th a t m ay be executed concurrently w ith 
i o th er tasks. A task has a single th re a d of execution a n d is a com putation
I .
; u n it schedulable b y th e o p eratin g system . E xternal input elements p r o d u c e !
1 i
I !
i in p u t req u ests w h ich in tu rn trig g er a set of low level activities to be j 
! ex ecu ted by tasks. E xternal output elements co n su m e resu lts w hich are j
I
produced by tasks. J
\
i
f
Specification m eth o d s for describing th e d y n am ic stru c tu re of t h e ! 
ru n -tim e entities, th e sy n ch ro n izatio n a n d co m m unication b etw een these j 
entity, and resource consum ption an d p ro d u ctio n p ro p erties (w hich in c lu d e ! 
tim ing and sizing) are defined. The specification m ethods allow designers to j
f
e x p ress th e ir d e sig n of a so ftw a re a rc h ite c tu re at m u ltip le levels o f . 
a b stra c tio n s d ep en d in g on th e ty p e of analysis is em p h asized in a specific j
i
desig n p h ase of th e softw are d ev elo p m en t process. In a d d itio n , softw are ! 
a rc h ite c tu re sp e c ifie d in th e sim u la tio n a n d p e rfo rm a n c e a n a ly s is ! 
en v iro n m en t has a direct m ap p in g to the entities in th e actual code. H ence, i 
m o d ificatio n s to a so ftw are arch itectu re b ased o n conclusions from th e 
sim ulation a n d /o r perform ance evaluation can be easily in co rp o rated into 
th e actual code. Finally, th e sem antics of the re p re se n ta tio n s are d e fin e d . 
T he form al sem an tics fo rm th e b asis o n w h ic h to c o n stru c t tools for 
feasibility analysis of a design u n d e r a specific o p erational env iro n m en t or
136
code generation of resource m anagem ent softw are. These can be au to m ated 
via application of the rules to in terp ret design specifications.
| A n atu ral question is w h y it is necessary to introduce softw are design
| m eth o d s ra th e r th an a sim ple, direct m a p p in g approach, i.e., associating a
task w ith each th re a d of activities u sin g th e sam e resource. T w o key
i
! problem s h in d e r this approach.
i
• D irect m ap p in g can p ro d u ce an excess n u m b er of tasks.
| T he h a rd w are a n d /o r the o p eratin g system s used b y sem i-h ard
1 re a l-tim e sy ste m s g e n e ra lly h a v e a lim it o n th e m ax im u m
n u m b e r of softw are tasks. T herefore, system atic stra te g ie s for 
c lassify in g activ ities in to g ro u p s a n d m a p p in g g ro u p s in to 
softw are tasks are required.
• D irect m ap p in g does n o t p ro d u ce necessary tasks to h an d le d ata 
integrity an d d ata transform ation problem s.
D ata can be accessed by co ncurrent th read s of activities. A d ata 
m an a g er m u st be created to co n tro l access to sh a re d d a ta b y 1
concurrent activities such th at th e integrity an d consistency of the !
d a ta can be m aintained. In addition, a specific d ata item can have 
tw o d ata m odels— one from the p ro d u ce r view an d the o th er from 
th e consum er view . A d ata tran sd u cer m u st be created to receive 
d a ta according to th e p ro p erties specified in th e p ro d u c e r d a ta 
m o d el an d , then, tran sfo rm th e d a ta in to th e d esired p ro p erties 
specified in th e consum er d ata m odel.
A softw are architecture is specified in three parts: the d a ta m odel, the 
control flow m odel, an d the sequential p ro g ram m odel. The data m odel is 
expressed w ith a restricted d ata g ra p h . The control flo w model is expressed 
w ith a task g rap h in w hich each vertex rep resen ts a ru n-tim e entity, i.e., a
task or an in p u t/o u tp u t d ata elem ent, a n d each arc rep resen ts th e d ata
13 Z J
p ro d u c tio n /c o n su m p tio n relations b etw een tw o co m m u n icatin g entities. 
T he sequential program model is expressed w ith a restricted activity g rap h 
| w hich is a sub g rap h of an activity graph, i.e., the requirem ents specification, 
j G raphical n o tatio n s are u se d for rep re se n tin g (i) relatio n s b e tw ee n d a ta 
! item s in a d a ta m odel, (ii) relations b etw een tw o com m unicating entities 
| an d the te m p o ra l/sp a tia l parallelism of in p u ts /o u tp u ts of each entity in a
i
co n tro l flo w m o d el, a n d (iii) th e in te rn al c o m p u tatio n al stru c tu re of a 
i se q u en tial p ro g ra m m o d el (i.e., a task). T extual n o tatio n s a re u se d for
I :
specifying tim ing constraints, pre-conditions, an d post-conditions. j
i
1
Section 4.1 show s how to take th e graphical notatio n s in tro d u ced in j 
Section 3.1 an d m o d ify /re stric t them so th a t task grap h s, restricted a c tiv ity , 
graphs, and restricted data graphs can be created. i
I
In S ection 4.2, I d e fin e a lg o rith m s fo r c o n stru c tin g re s tric te d j 
activ ity / d a t a g ra p h s a n d p re se n t an a lg o rith m fo r d e riv in g m ax im al! 
restricted activity g rap h s from a given activity g rap h . I define th e tem plate 
for specifying a task and the textual notation for describing attributes (such 
as enabling p aram eters an d conditions, tim ing constraints specification) of a 
task. Then, I p resen t an algorithm for d eriving attrib u tes of a task from its 
associated restricted activity graph. Finally, I define the form al g rap h m odel 
for a task.
In Section 4.3, I define a set of ru les for m a p p in g a req u irem en ts 
m odel to a softw are architecture. I th en define an alg o rith m for d eriving a
i
task g rap h from a given activity g rap h using these m ap p in g rules. |
138
W ith th e task g rap h , restricted activity a n d d a ta g rap h , th e resource 
m anager, and tim ing constraints specification, a com plete softw are design is 
'produced.
4 .1 . G RA PH IC A L PR IM ITIV ES FO R SPECIFY IN G DESIGN
i
j The graphical notations p resen ted in this section are for specification
'of restricted data graphs, restricted activity graphs, a n d task graphs. F igure 4-
i
I
1 c o n ta in s th e g ra p h ic a l p rim itiv e s fo r sp e c ific a tio n o f re s tric te d 
! d a ta /a c tiv ity graphs. These prim itives are a subset of th e n o tatio n u sed for 
're q u ire m e n ts specification a n d sh o w n in F igure 3-1. T he X in d ic ate s a
i
i
n o tatio n th at is disallow ed. In each colum n, one prim itive is disallow ed.
i
------Sequence
----- ► - Data Flow
V j - p . merge 
j / — ' connector 
n
r ~ X «P»*
v— 'N* connector 
x n
junction 
* 1 x I * connector
n n
j | Activity
( } Data Item
© Iteration 
© Selection
i i i u T T H u li i|
(1) node primitives (2) operator primitives (3) communication primitives
Figure 4-1: Graphical Notation for Restricted Activity/Data Graphs ,
A s sta te d earlier, a task has a sin g le execution th re a d a t any tim e j 
instant. H ence, d ata item s w ill n o t be concurrently p ro d u ced b y a task. Based j 
on th e se a ssu m p tio n s, th e concurrent objects of the same class n o d e is 
ex clu d ed from th e node p rim itiv es in Figure 4-1(1), a n d th e concurrency ,
I
o p e ra to r is e x clu d ed fro m th e o p e ra to r p r im itiv e s in F ig u re 4-1(2). i
I
I
l
1 4 0 .
Therefore, the a c tiv ity /d a ta graphs, constructed from prim itives in Figure 4- 
1, w h ich are associated w ith a task, in a sense, is m ore r e s tric te d th en 
a c tiv ity /d a ta g ra p h s specified in req u ire m e n ts. H o w ev er, th e en fo rced 
re stric tio n s can p re v e n t o n e fro m o b v io u s m ista k es su c h as h a v in g 
i concurrent execution threads in a task an d hav in g concurrent consum ption 
| a n d /o r pro d u ctio n of d ata item s by a task. Since the restricted activity graphs 
are m eant for describing execution behavior of an im p le m e n ta tio n of a task, 
the exact interface betw een th e task's com ponent activities m u st be resolved
1
d u rin g d esign. T herefore, th e equivalent connector is ex clu d ed from th e j 
co m m u n ica tio n p rim itiv e s in Figure 4-1(3) to force th e definition of th e j 
exact interface betw een tasks so th at a com plete specification of a task can be !
i
en su red .
Activity
Concurifent 
Objects o L the
same das
©
n
x
n
.x , x.
Data Flow
merge
connector
split
connector
junction
connector
rx x 
n n
cor
j Task
\ Input/Output 
Data Element
Mandatory 
Input Port
\<
Optional 
Input Port
Output Port
(1) node primitives for (2) operator primitives (3) communication (4) node primtives
activity/data graphs for activity/data promitives for task graphs
graphs
Figure 4-2: Graphical Notations for Task Graphs
141
As show n in Figure 4-2, the notation in (1) an d (2) is replaced by the 
n o tatio n in (4). The n o tatio n in (3) is from F igure 3-1 an d th a t n o tatio n is 
retained except for th e equivalent connector. Therefore, for specification of a 
j d e s ig n , tw o se ts o f p rim itiv e s , th e 'n o d e ' p rim itiv e s a n d th e 
j 'com m unication' prim itives, can be used.
O bserve th a t the node p rim itives in F igure 4-2(1) are only u sed for 
cre atin g re stric te d o r u n re stric te d a c tiv ity /d a ta g ra p h s. In th is d esig n 
m ethod , a run-tim e entity is a set of activities, com prising a single execution 
thread. This set of activities is encapsulated by th e task p rim itiv e in Figure 
4-2(4), a n d th e in te rac tin g b eh av io rs of th e e n c a p su la te d activ ities are 
d efin e d u sin g th e rem a in in g p rim itiv es in F ig u re 4-2(4). T herefore, the 
p rim itiv e s in F ig u re 4-1(1) are co m p letely e lim in a te d from th e n o d e 
prim itives for creating task graphs.
The operator p rim itives in Figure 4-2(2) are elim inated com pletely.
!
The rationale for doing so is as follows: j
• D iffere n t ta sk s a re k n o w n to be c o n c u rre n t. T h erefo re, th e j 
concurrency o p e ra to r is e lim in ated to red u c e re d u n d a n c y a n d i 
com plexity in task graphs.
I
• T he d a ta co n su m p tio n an d p ro d u ctio n relatio n sh ip , re p re se n te d |
I
by the data flow prim itive betw een tw o tasks is eq u iv alen t to their 
precedence (i.e., sequencing) relationship. T herefore, th e sequence 
operator is elim inated.
• T im in g c o n stra in t sp e cifica tio n s can e x p re ss th e re p e titiv e 
beh av io r of tasks. Therefore, th e iteration operator is elim inated.
142
______ i
• Pre-conditions, post-conditions, and p o rt connections of tasks can 
ex p ress th e m u tu a l exclusion of tasks. T herefore, th e selection 
operator is elim inated.
The co m m u n ic a tio n p r im itiv e s in F ig u re 4-2(3) hav e th e sam e 
n o tatio n s in F igure 4-1(3). H ow ever, for each fan-in arc lab eled xi7 th ere j
i
m u st be a task, n o t an activity, a t th e o p p o site en d of th e d a ta item x to J
t
'w rite' or 'access' the com posite d ata item Xj. For each fan-out arc labeled x{,
th ere m u st be a task, not an activity, at the opposite end of th e d ata item x to j 
're a d ' or 'access' the com ponent d ata item Xj. !
i
i
i
The node prim itives set in Figure 4-2(4) contains five elem ents: task, j 
input/output data element, mandatory input port, optional input port, an d i 
output port. A task rep resen ts a p ro g ram u n it w hich has a single execution !
i
th re a d an d consum es a b o u n d e d am o u n t of resources su ch as p rocessor J 
cycles an d m em ory capacities. U nlike data item s w hich are passive entities, j
i
in p u t/o u tp u t d ata elem ents are active entities w hich d o n o t consum e any
p ro cesso r resource. A n input data element only has a set of o u tp u t ports, j
i
Each in p u t data elem ent represents a source of instances of a specific set of J 
in p u t d ata item s. For exam ple, an antenna receiver can be rep resen ted b y an j 
in p u t d a ta elem ent. A n output data element only h as a set of in p u t ports, j 
Each o u tp u t d ata elem ent represents the repository of instances of a specific 
set of o u tp u t d ata item s. For exam ple, a d isp lay can b e rep re se n te d b y an 
o u tp u t d ata elem ent.
143
The mandatory input port an d optional input port define th e in p u t 
in te rfa c e s of a task to other tasks or d ata elem ents. A mandatory input port 
represents a logical location at w hich m an d ato ry in p u ts for enabling th e task 
attached b y the in p u t p o rt arrive. A n optional input port rep resen ts a logical 
lo catio n a t w h ich o p tio n a l in p u ts o f th e task arriv e . A n output port 
rep resen ts a logical location at w hich o u tp u ts are to be deliv ered w h en the 
specified conditions are m et.
AG12
A2 A1
A ll A21
A22 A12
A13
A14
Casel: (1) A11->A12->A13; (2) A21->A22
Case2: (1) A11-»A12->A14; (2) A22->A22 
Figure 4-3: Two Possible Cases of Concurrent Threads
144
C onsider Figure 4-3 in w hich there are tw o possible com binations of 
co n cu rren t th re a d s of activities. In th e first case, one th re a d consists of 
A 1 1 ^ A 1 2 — »A13, i.e., A l l follow ed b y A12 a n d A12 follow ed by A13. The 
other consists of A21 — » A22, i.e., A21 follow ed b y A22. In th e second case, one 
th read consists of A 11-*A 12— »A14, and the o th er consists of A21-»A22. The 
distin ctio n is th at, in th e th rea d containing 3 activities, one case contains 
! A13 and the o th er case contains A14.
i
i
| T here are five w ays to g roup A ll, A12, A13, an d A14. M ethod 1 is to
form fo u r p rim itiv e activity g rap h s, i.e., (A ll), (A12), (A13), a n d (A14). 
M eth o d 2 is to form one chain (A 11-*A 12) a n d tw o p rim itiv e activ ity 
g ra p h s— (A13) m u tu a lly exclusive w ith (A14). M eth o d 3 is to form tw o 
prim itive activity g rap h s— (A ll) follow ed by A(12) an d one activity subgraph 
(A 130A 14) w here A13 is m u tually exclusive w ith A14. M ethod 4 is to form 
o n e chain (A 11-»A 12) an d one activ ity su b g ra p h (A 130A 14). F inally, 
m eth o d 5 is to form a chain ( A ll— »A12-»(A 13© A 14)) in w hich a m u tu ally 
exclusive activity su b g rap h (A 130A 14) is em beded. Sim ilarly, there are tw o 
w ays to g ro u p A21 an d A22. M ethod 1 is to form tw o p rim itiv e activity 
graphs, i.e., (A21) an d (A22); m ethod 2 is to form one chain (A21— »A22).
W hen o n e's d esig n objective is to m in im ize o v e rh e ad s fro m task 
context sw itch, then, th e objective for m ap p in g an activity g ra p h to a task 
g ra p h w o u ld be to m inim ize th e n u m b er of task s. T herefore th e n otion of 
m axim al restricted activity grap h is needed to define the criteria for deriving 
a task g ra p h fro m a g iv en activ ity g rap h . C o n sid e r th e activity g ra p h
145
d ep icted in F igure 4-3. W ith this activity g rap h , restricted activity g rap h 
(A 11-A 12-((A 13® A14)) a n d restricted activity g ra p h (A21-A22) are tw o 
m axim al restric te d activ ity g rap h . T he th ird m axim al re stric te d activity 
I g ra p h can be d eriv ed by rep lacin g th e startin g concurrency n o d e w ith a 
i 'fork' activ ity a n d rep lacin g th e e n d in g co n cu rren cy n o d e w ith a 'join'
I
[activity. T he 'fork' activity an d th e 'join' activity are co n n ected w ith a
i
j sequence node p rim itiv e. T he d e ta ile d alg o rith m fo r d e riv in g a set of 
; m axim al restricted activity g raphs from a given activity g rap h is described in
i
Section 2.
i
i
In F igure 4-4, activity g ra p h AG12 has tw o co n cu rren t com posite 
activities (A l, A2), re p re se n te d by a chain of tw o atom ic activities. The 1
associated activity g rap h of activity A l is a restricted activity g ra p h since j
I
n e ith e r th e concurrent objects of the same class n o d e p rim itiv e n o r th e | 
co n cu rren cy o p e ra to r p rim itiv e is u se d in th e g ra p h . S im ilarly , th e !
i
t
associated activity graph of activity A2 is also a restricted activity graph.
AG12
A2
A ll A21
A22 A12
Threadl: A11-»A12; Thread2: A21->A22
Figure 4-4: Two Concurrent Threads of Activity Chains
G iven a set of co ncurrent m axim al restricted activity g ra p h s of an 
activity g ra p h AG, one can use a task m a p p in g ru le th a t each m axim al j
i
restricted activity g rap h is m ap p ed to a task. T hus, the n u m b er of tasks in ! 
the d eriv ed task g rap h is equal to or g reater th an the n u m b er of m axim al j 
restricted activity graphs in AG. The reason for th e existence of the ’ g reater |
th a n ' re la tio n is th a t a d d itio n a l task s m ay b e c re a te d for d a ta b a s e ;
i
m anagem ent, d ata transform ation, etc. By using th e above rule, task g rap h j 
TG12, depicted in Figure 4-5, consists of tw o tasks, each co rresponding to a j 
m axim al restricted activity g rap h in Figure 4-4. j
‘ TG12
D
c * > - h > < 3 H * J > < 4 — < jD
C c ^ > ~ 4 > 7 1 < f | D 1 2
Figure 4-5: A Task Graph Derived From Mapping Each Thread of Activities Into a Task
147
A n i n p u t/o u tp u t m a p p in g ru le for p reserv a tio n of th e in p u t an d 
o u tp u t req u ire m e n ts states th a t in p u ts to a n d o u tp u ts from a m axim al 
restricted activity g rap h s are in h erited b y th e associated task. The re a d e r 
sh o u ld observe th a t there are tw o in p u t d a ta item s, i.e., A an d C a n d tw o
I
i o u tp u t d a ta item s, i.e., E a n d F. T1 consum es b o th in p u t d ata, a n d T2 
p roduces b o th o u tp u t data. A is read in via T l’ s first port, a m andatory in p u t 
p o rt; B is re a d in via T l's second p o rt, also a m a n d a to ry in p u t p o rt.
i
j S im ilarly, E is w ritten o u t via T2's th ird port, an o u tp u t port; F is w ritten 
o u t via T2’s fourth port, also an o u tp u t port. Please n ote th at the in p u t A to
J
th e first p o rt of T1 corresponds to th e in p u t to th e atom ic activity A l l in 
Figure 4-4. The in p u t C to T l’s second p o rt co rresp o n d to th e in p u t to the 
atom ic activity A12 in Figure 4-4. A sim ilar correspondence also ho ld s for E 
an d F. The n o tio n of m a n d a to r y specifies ho w T1 is to be e n ab led . T he 
selection of e ith er a m a n d a to ry or an optional in p u t d e p e n d s on th e 
algorithm s selected to im plem ent the atom ic activity co rresp o n d in g to the 
in p u t, a n d th u s, th e selectio n d ecisio n is a d e sig n issu e (i.e., n o t a 
req u irem en ts issue).
A n in te rfa c e m a p p in g ru le fo r p re s e rv in g th e d a ta flo w 
com m unication characteristics states th a t th e d a ta flow prim itives b etw een 
m axim al restricted activity g rap h s are to be in h erited by th e d eriv ed 4ask 
graph. A lso, the activity at the tail of a d ata flow prim itive is replaced w ith 
an o u tp u t p o r t, an d the activity at th e h e ad of a d a ta flow p rim itiv e is 
rep laced w ith an in p u t p o rt. O bserve th a t B and D are th e tw o d a ta flow s 
b e tw ee n th e tw o m axim al re stric te d activ ity g ra p h s in F ig u re 4-4 b y
148
application of the inheritance rule. The task g rap h in F igure 4-5 also has B 
an d D as the tw o d ata flow s betw een the tw o tasks.
AG12
A l A2
A22
A21
A ll
A12
A23
Figure 4-6: Another Activity Graph Can Have a Derived Task Graph
N o w , consider th e activity g ra p h d e p icted in F igure 4-6 w hich is 
com prised of tw o co n cu rren t m axim al restricted activity grap h s. In each 
m axim al restricted activity g rap h , there are tw o atom ic activities, executing 
in a m u tu a l exclusive m anner. By ap p ly in g th e m a p p in g ru les described 
earlier, the g rap h in Figure 4-5 is also the derived task g ra p h of this activity 
graph. U sing tw o sep arate in p u t p o rts in d eed indicates th a t A an d C are 
consum ed at tw o logical locations. H ow ever, in Figure 4-4,A an d C w ill be 
consum ed in th e o rd e r of A follow ed b y C. But, in Figure 4-6, A or C , not
I
both, w ill be consum ed. C learly, this in p u t consum ption behavior in Figure 
4-4 is different from th a t in Figure 4-6, yet th e p o rt rep resen tatio n s are n o t
sufficient to m ake the distinction. Based on this observation, I conclude th a t j
*
textual notation m u st b e p ro v id ed such th at one can au g m en t th e g rap h to j 
describe the relationship betw een ports. The textual notations for describing 
th e p o rt relatio n s w ill be d efin ed in Section 4.2. F u rth erm o re, the p o rt
149
j
relatio n can also be d eriv ed from th e task 's associated restric te d activity 
g rap h by a set of direct m app ing rules such as those defined in Section 4.3.
L
Figure 4-7: An Activity May Produce Two Outputs or Consume Two Inputs
A ctivity g ra p h AG34, d e p icted in F igure 4-7, h as tw o c o n cu rren t 
m axim al restricted activity g rap h s, A3 an d A4. A3 has one in p u t an d tw o 
o u tp u ts; A 4 has tw o in p u ts a n d no o u tp u ts. B oth o u tp u ts of A3 are 
p ro d u ced by the single atom ic activity (i.e., A31) of A3. Both inputs of A4 are 
consum ed by the single atom ic activity (i.e., A41) of A4.
TG34
.xw w w w xw vxxxxw w w w xv
A
I
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
T4
Figure 4-8: Two Tasks Communicating With Two Data Flows Via One Pair of Ports
In F igure 4-8, th e tw o tasks T3 a n d T4 are d e riv e d from th e task 
m a p p in g ru le. T he first in p u t p o rt of T2 is c reated b y a p p ly in g th e 
in p u t/o u tp u t m a p p in g rule. The tw o d a ta flow s A an d B are created by
150
a p p ly in g th e in te rfac e m a p p in g ru le. O b serv e th a t in F ig u re 4-8 th e 
fo llo w in g in fo rm a tio n is n o t ex p ressed : (i) th e te m p o ra l rela tio n sh ip s 
betw een pro d u ctio n of A and B (i.e., if both A an d B w ill be p ro d u ced or one j 
of them w ill be p ro d u ced ); (ii) th e conditions for p ro d u c in g A; (iii) th e j
co n d itio n s for p ro d u c in g B; a n d (iv) the tem p o ral relatio n sh ip s b etw een |
i
co n su m p tio n s of A and B (i.e., if b o th A an d B w ill be consum ed o r one of 
th em w ill b e consum ed). B ased o n th ese o b serv atio n s, I co n clu d e th a t
i
[textual n o tatio n m u st be p ro v id ed such th a t one can a u g m e n t g rap h ical \ 
n o tatio n s describing th e relationship betw een in p u ts to an in p u t p o rt an d 
the relationship betw een o u tp u ts from an o u tp u t port.
A ctivity g ra p h AG56, d ep icted in F ig u re 4-9, h as tw o co n cu rren t 
m axim al restricted activity graphs, A5 and A6. A5 has one in p u t A an d one
o u tp u t X; A6 h as tw o inputs: B a n d X , a n d one o u tp u t C . A junction
/
p rim itiv e w ith a d ata item X rep resen ts th a t th e o u tp u t of atom ic activity 
A52 w ill be co n su m ed by atom ic activity A62. H ence, X is a sh a re d d a ta 
w hich m ay be accessed concurrently by A52 an d A62.
151
AG56
A6
A5
A51 A61
A62 A52
1 I
Figure 4-9: Two Threads of Activities ■'Concurrently Access' a Data Item X j
E arlier I p o in te d o u t th at the n u m b er of tasks in th e d e riv e d task | 
g rap h is equal to or greater th an the num ber of m axim al restricted activity ; 
; g rap h s in the p aren t activity graph. C onsider the task g ra p h in Figure 4-10 | 
| w hich is derived from the activity g rap h in Figure 4-9 by u sin g th e m ap p in g I 
! rules described earlier. It is clear th at activity g rap h A5 is m ap p ed to task T5 !
j « *- t
| |
an d activity g rap h A6 is m ap p ed to task T6. H ow ever, in o rd er to ensure the j 
d ata in teg rity of the sh ared d a ta X, a Data Manager of X task is created to j
i
m an ag e X. O nly this task has a direct access to X (i.e., the rig h t to read and j
i
I
w rite to X) because th e d ata item X has neither in p u t p o rts nor o u tp u t ports I 
1 for in terface w ith o th er tasks. T herefore, to access X, o th e r tasks m u st 
! acquire services (e.g., getY and putY ) from the Data Manager of X task. !
I
I
152
Manager
v v \ \ \ \ \ \ \ \ \ \ \ \ \ v v \ \ \ \ \ \ \ v
^ TG56
I
I '
i
Figure 4-10: A Data Manager to Ensure the Data Integrity of Shared Data Item |
i
A n a tu ra l question m ay be asked. H o w w o u ld putY , getY, an d Y in {
I
F igure 4-10 be im p le m e n te d in a p ro g ra m m in g la n g u a g e (e.g.,, A da)? I i
i
suggest th at putY an d getY are im plem ented as p ro ce d u re calls w ith in the ^ 
context of T5 an d T6. For instance, one could code a function such as put(Y: j 
in d a ta _ stru ctu re) o r get(Y: in d a ta _ stru ctu re) w h e re th e datajstructure ' 
could be declared as an unconstrained array type. E ither function w o u ld be 
called by specifying the exact range bound. For exam ple, get(Y(5..10). Each of 
th ese fu n ctio n s w o u ld th en co n stru ct a m essag e (e.g., w ith th re e fields 
< destination, from , to>) by using A da attributes specifier such as Y 'address, 
Y’ size, a n d Y’ size. T he task creation rules such as those aforem entioned 
w ill be defined in Section 4.3.
153
AG7 every 2 seconds
A 7
Figure 4-11: A Periodic Activity, Iterating Every 2 Seconds j
|
In Figure 4-11, there is one activity, iterating every 2 seconds. In each !
t
ite ratio n , activ ity A 7 p ro d u ce s a d a ta item B. A ctiv ity AG 7 itself is a j 
m axim al restricted activity graph. |
s TG7 4%v\.vvvvvvvvv\v
. , j " N k semaphore 
j watch dog  r
^timer
-»>p>T 7  * C j L )
Figure 4-12: A Periodic Task Enabled by Watch D og Timer Every 2 Seconds
In F igure 4-12, there is a task T7, an in p u t d a ta elem en t watch dog 
timer, a d ata flow semaphore, an d an o u tp u t d a ta elem en t B. Task T7 is 
associated w ith atom ic activity A 7, not the m axim al activity g rap h enclosing 
A 7, in Figure 4-11. This is d u e to the fact th at the tim e interval taken by the 
atom ic activity A 7 m ay either be shorter th an 2 seconds or exceed 2 seconds 
d e p e n d in g o n th e o v e ra ll sy ste m w o rk lo a d . M a k in g sem aphore a 
m an d a to ry in p u t for en ab lin g T7 a n d m ak in g watch dog timer g e n erate 
semaphore allow s the execution of T7 to be controlled b y a local scheduler. 
F urtherm ore, th e iteration interval (i.e., every 2 seconds) can be specified as 
a p a rt of the tim ing constraints associated w ith watch dog timer an d can be
154
m ad e kn o w n to th e scheduler. T he attrib u tes associated w ith each ty p e of 
no d e (i.e., in p u t data elem ent, o u tp u t d ata elem ent, task, etc.) w ill be defined 
in the follow ing section.
A s sh o w n in th e p rec ed in g exam ples, it is clear th a t in o rd e r to 
rigorou sly an d concisely describe interactions betw een tasks an d 1 /O devices 
a n d rep re se n t tim e-oriented behaviors, each p rim itiv e m u st be au g m en ted 
w ith attributes. For exam ple, h o w in p u t p o rts are in terrelated , h o w o u tp u t 
Sports are in terrelated , ho w in p u ts to a p o rt are in terrelated , h o w o u tp u ts 
ifrom a p o rt are in terrelated can be expressed via textual n o tatio n s (w hich
I
w ill b e d e fin e d in th e n e x t se ctio n ). F u rth e rm o re , th e te m p o ra l
relatio n sh ip s am ong in p u ts an d the tim ing p ro p erties of each in p u t m u st |
]
also be au gm ented via tim ing constraints specification. For active elem ents, j
i.e., in p u t d ata elem ents, o u tp u t d ata elem ents, an d tasks, a set of execution ! 
ru le s m u s t be d e fin e d . T he fo llo w in g se ctio n w ill a d d re s s issu e s 
a fo re m en tio n e d .
I
155
______ i
4.2. DESIGN SPECIFICATION METHOD
The restricted d a ta /a c tiv ity g rap h defined below has the sam e type of 
com ponents as those defined for non-restricted except that the n o d e types of 
th e vertices in a g rap h are restricted to those defined in Figure 4-1.
i
4.2.1. RESTRICTED DATA GRAPHS
i
j A restricted d ata graph RD is a 5-tuple,
i RD = [G, f, g, s, e]
t
w here: G = [V, E] is a d ata g rap h in w hich V is the set of nodes
a n d E is the set of edges.
f is a function from V into the set of allow ed n o d e types 
Vrdp. (Vrdp is defined explicitly below .)
g is a function from V in to the set of positive integers. 
This essentially provides a label for each node. j
s is a distinguished no d e called the 'start node'. i
i
*
e is a distinguished no d e called the 'end n o d e ’. I
The set of no d e types p erm itted in a restricted d a ta g rap h is Vrdp =
^dp ” { © s / © e / © s / © e ) w here Vdp = {D, © $ / © e / © s / © e / © s / © e /
© s / © e )/ i e., the set of node types allow ed in a d ata g rap h except for those
associated w ith concurrency.
D efinition 1: A w ell-form ed restricted d a ta g rap h RD ( = [G, f, g, s, e], can be 
recursively defined as follows:
(1) Let RDk = [Gk, fk, gk, sk, ek] be any single vertex d ata graph 
w ith Gk = [{vk}, 0 ] 
fk(vk) = D
i
156
gksk = vk 
e k = vk
(2) Let R D j, RD2, ..., RDk be w ell-form ed restricted data graphs, 
RD t = [Gj, fj, gj, vg., ve.]. For th e p u rp o se of generality,
the labeling function 'g' I need th e follow ing notation.
Let m k = the m axim al value in th e range of g for RDk. 
W ithout loss of generality, I also assum e th e sets of nodes in 
R D l7 RD2, R D k are distinct.
RD = [G, f, g, v s, ve] is a w ell-fo rm ed restricted d a ta g rap h
k- 1
Let M k = X m ..
i =1
T h en :
(a)
w here:
G = [V, E] 
E =
157
g(v) = '
M j + g j(v ) if v e Vi 
g(vs ) = M m
g(v ) = M
m
Expression.
(b)
0 —
RD = [G, f, g, v g/ ve] is a w ell-form ed restric te d d a ta g rap h 
w here:
G = [V,E]
E = VA (ve’v * )}
f(v) =
"ik (v) if v e Vk
f(vg) = © s
_f(v ) = m)e
g(v) =
g(vs ) =
if v e Vk
gk(v) + 1 
g k(v) +1
158
d jS )
(c) ( s E )
RD = [G, f, g, vs, ve] is a w ell-fo rm ed restric te d d a ta g ra p h 
w here:
G = [V, E]
m
V - u V .
;= i 1
f(v )= £ .(v ) if v s V,
g(v) = Mi +gj(v) if v s Vj n
N o te th at w ith th e above definition, m atching pairs of n o d es (xj, x2) 
e-g-' ( ® s , © e ^ can be identified by g(xj) = g(x2).
T he above definition is sufficient for construction of tools to check 
w h e th er a restricted d ata g ra p h is w ell-form ned. I am only in te reste d in 
w ell-form ed restricted d ata grap h s an d in the sequel I will dro p the adjective 
w ell-form ed' although it w ill alw ays be u nderstood.
In th e follow ing sections, th e form al definitions of restricted activity 
graphs a n d m axim al restricted activity g rap h s are p resented. In ad d itio n , I 
present algorithm s for deriving a set of m axim al restricted activity g rap h s
159
from a g iv en activity g ra p h a n d checking w h e th e r m ax im al re stric te d 
activity g rap h s are w ell-form ed.
4 .2 .2 . R ESTR IC TED ACTIVITY GRAPHS
j In th e fo llo w in g d isc u ssio n o n re s tric te d a c tiv ity g ra p h s , th e 
jem phases are on th e aspects of th e tem p o ral relatio n sh ip a n d th e sp atial 
[relationship b etw een activities. I assu m e the details of d a ta g rap h s an d 
com m unication b etw een activities are defined. T herefore, I d o n o t include 
th e com m unication connectors an d in p u ts / o u tp u ts of each activity in th e 1
i
g rap h m odel of an activity graph. j
I
A restricted activity graph RA is a 5-tuple, !
RA = [G, f, g, s, e] |
w here: G = [V, E] is an activity g rap h in w hich V is th e set of ;
nodes and E is the set of edges. ;
f is a function from V into th e set of allow ed no d e types j
Vrap. (Vrap is defined explicitly below .)
g is a function from V in to the set of positive integers. 
This essentially provides a label for each node.
s is a distinguished n o d e called the ’ start node'. j
i
e is a distinguished no d e called th e 'end node'.
The set of n o d e types perm itted in a restricted activity g rap h is Vrap = 
^ a p " (© S ' © e / © s / © e ) w here Vap = {A, © s , © e/ © s / © e / © S ' © e / 
© s / © e )/ i-e., the set of n o d e types allow ed in an activity g rap h except for
those associated w ith concurrency.
160
D efinition 2: A w ell-form ed restricted activity g rap h RA ( = [G, f, g, s, e], can 
be recursively defined as follows:
(1) Let RAk = [Gk, fk, gk, sk, ek] be any single vertex activity graph
(2) L et R A j, RA 2, ..., RAk b e w ell-fo rm ed re stric te d activ ity
RAj = [Gj, fj, gj, v s., v e.]. For the p u rp o se of generality,
the labeling function 'g' I need the follow ing notation. 
Let m k = the m axim al value in the range of g for RAk. 
W ithout loss of generality, I also assum e th e sets of no< 
R A j, RA2, R A k are distinct. 
k-1
Let AT, = X m ..
* i =1 1
T hen:
RA = [G, f, g, vs, ve] is a w ell-form ed restricted activity g rap h 
w here:
w ith Gk = [{vk}, 0 ]
fk(vk) = D 
g k(vu) = 1
s k = vk 
e k = vk
graphs
(a)
G - [V, E]
i
i
i
161
f(v) =
g(v) ='
(b)
f (v) if v g Vj 
f(vs ) = © s 
f(ve) = © e
M i + g j( v) if v g Vi 
g(vs ) = M m
g(ve ^ =
Expression.
RA k
RA = [G, f, g, v s, v e] is a w ell-form ed restricted activity g rap h 
w here:
G = [V,E]
ViUl vS ’ve}
e = :
k L k k J I
"f k (v) if v g Vk 
f(v)= { f ( v „ ) = @ s
.f(v') = @)e 
g k(v) if v g Vk 
g(v) = S(vs > = 8k(v) + 1 
g(ve> = g k(v) + 1
162
(d)
RAi
□ z
RA2
J L ,
RA„
RA = [G, f, g, vs, ve] is a w ell-form ed restricted activity g rap h 
w here:
G = [V, E]
m
V = u V . 
i =1 *
E = V S2UV » )}
f(v)= f. (v) if v s Vi
g(v) = Mj + g i(v) ifve Vi
□
4.2.3. DECOMPOSITION OF AN ACTIVITY GRAPH INTO MAXIMAL 
RESTRICTED ACTIVITY GRAPHS
In th is section I p re se n t an alg o rith m fo r d eco m p o sin g a g iven 
activ ity g ra p h in to a set of m ax im al re stric te d activ ity g ra p h s. The 
significance of a restricted activity g ra p h is th a t it rep resen ts a sequential 
process an d therefore is natu rally associated w ith a task. The set of m axim al 
restricted activ ity g rap h s therefore co rresp o n d s to a m inim al set of tasks 
corresponding to th e given activity graph.
I first in fo rm ally describe th e a lg o rith m a n d th e n give a d etailed 
d escrip tio n . As w ell be seen, th e com plexity of th e alg o rith m is 0 ( I E I )
1 6 3
w h ere E is th e se t of ed g es in th e activ ity g ra p h . I can achieve this 
com plexity if I ’ visit' each edge in the activity g rap h only once. As in m any 
g ra p h trav ersin g algorithm s a stack is useful for rem em b erin g p a th s th at 
have y et to be explored. In m y case, I w ill n eed tw o levels of stacks. The 
reason is th at w hile 'exploring' the nodes of the activity g rap h I m ay need to 
|halt th e b u ild in g of one m axim al restricted activity g rap h a n d start a new 
one. The activity g rap h th at I w as w orking on w ill be rem em bered in a stack
land re su m e d later. T his is th e 'to p le v e l’ stack in th e alg o rith m . The
i I
jelem ents in th is stack are com plex d a ta stru c tu re s th a t reco rd all th e j
!in fo rm a tio n re q u ire d to resu m e b u ild in g of th e (in co m p lete) m ax im al j
restricted activity graph. O ne of the com ponents of this stru ctu re is itself a
stack; nam ely, a stack of nodes th at have yet to be v isited in this partially
com pleted m axim al restricted activity graph.
Som e notations:
PSS (Partial S ubgraph State)
T his is th e d a ta stru c tu re u se d to reco rd all th e in fo rm atio n 
re q u ire d to resu m e th e c o n stru ctio n of a m ax im al re stric te d 
activity graph.
i
PSS_stack j
i
i
This is th e 'top level' stack in w hich PSS elem ents are p u sh e d for i 
later resu m p tio n . J
I
V ertex_stack
164
T his is th e 'low er level' stack an d th e re is o n e in each PSS. 
V ertices th a t h a v e y e t to b e v isite d in th e m ax im al restric te d 
activity g rap h are stored here. j
i
i
The alg o rith m has an 'o u ter loop' a n d an 'inner loop'. In the in n er j 
loop a 'cu rren t p artial g rap h ' is being constructed as n o d es in th e original 
'activity g ra p h are trav e rsed . H o w ev er, if a n o d e is e n c o u n te re d w h ich 
jindicates concurrency (i.e., © s ,€ > s ) th en construction of the cu rren t g rap h j
|is su sp e n d e d (the PSS for this g rap h is placed o n th e PSS_stack) an d also
Jnew PSS stru ctu res are initialized for each of th e successors of th e © s o r 
' (&)s n ode an d the algorithm retu rn s to th e outer loop.
I
|
In the o u ter loop, th e algorithm takes the top PSS stru ctu re from the 
PSS_stack (it term inates w hen the stack is em pty) and calls th e in n er loop to
continue construction of the graph. j
I
I
I
In itia liz a tio n of th e a lg o rith m consists sim p ly of c o n stru ctin g an 
initial PSS w hich corresponds to th e start n o d e of the activity g rap h b ein g I 
the next n o d e to visit, p u sh in g this PSS on the PSS_stack, an d in v o k in g the
I
o u ter loop.
Before p resen tin g the d e ta ile d alg o rith m , a sm all ex am p le m ay be 
useful. C onsider the activity g rap h in Figure 4-13.
165
AG
Figure 4-13: Given Activity Graph AG
The algorithm will basically processes as follows:
initialization: C reate a PSS w ith n o d e A j in the vertex stack.
(call this PSSj for easy reference.)
o u ter loop: P op the PSS_stack entry, i.e., PSSj,
Call the in n er loop.
in n er loop: ad d a copy of A j to graph, 
find successors.
Since it is an © s n o d e,
(a) a d d a 'fork node' to the current g rap h
(corresponds to the © s node) 
p u sh th e current PSS on th e PSS_stack.
(b) initialize a PSS for branch to A 2
(call this PSS2.) 
p u sh onto the PSS_stack.
(c) initialize a PSS for branch to A 3
n o d e
th e
(call this PSS3.) 
p u sh onto the PSS_stack.
(d) re tu rn to th e outer loop.
o u ter loop: p o p PSS from PSS_stack. (PSS3) 
invoke in n er loop.
in n er loop: expand node corresponding to A 3. 
this w ill be the © e node.
This signals the end of this g raph, an d it is outputted, 
retu rn to the outer loop.
o u ter loop: p o p PSS from PSS_stack. (PSS2) 
invoke in n er loop.
in n er loop: expand no d e corresponding to A 2. 
this w ill be the © e node.
This signals the end of this g raph, an d it is outputted, 
retu rn to th e o u ter loop.
o u ter loop: p o p PSS from PSS_stack. (PSS!)
N ote: w h en PSS^ w as p u sh e d on th e stack its c u rre n t
w as (§)s node. A t this point, it sh o u ld continue w ith
th e (§)e n o d e w hich w ill be tran sfo rm ed to a join node. 
In the detailed algorithm , this is accom plished by having 
a global variable in w hich, w h en a g ra p h is com pleted,
'end node' is recorded, 
invoke in n er loop.
in n er loop: convert (g)e to 'join node'.
got to next node A4 an d copy to graph, 
no successors, vertex stack is em pty, so o u tp u t graph, 
re tu rn to o u ter loop-
o u ter loop: PSS_stack is em pty.
167
T erm in ate.
F igure 4-14 d ep icts th e m axim al restricted activity g rap h s d eriv ed 
'from the given activity g rap h AG.
PSS2:
PSS2:
PSS1:
fork
join
Figure 4-14: Maximal Restricted Activity Graphs Derived From AG
Algorithm 2: G iven an activity g rap h AG = [G, f, g, s, e] a n d G = [V, E], a set of 
(restricted activity graphs are produced.
In p u t: G raph is represented by:
(1) start vertex s,
(2) en d vertex e,
(3) a list of vertices, each w ith the follow ing attributes:
(i) type,
(ii) a list of successors,
(iii) id,
(iv) address of this vertex in the o u tp u t su b g rap h
O u tp u t: (1) A set of m axim al restricted activity g rap h s (M RAG) an d a 
taskid is assigned to each.
(2) N M R A G re p re se n tin g th e n u m b e r of m ax im al re stric te d 
activity g rap h s produced.
168
M ethod:
pro ced u re B uildM R A G (AG):
1. if C urrentV ertex is n u ll th e n
begin
2. call In itializa tio n
to create a stack StackJPSS,
set C ur vertex of this PSS to s
3. this PSS is p u sh e d onto the Stack_PSS;
end;
4. w h ile Stack PSS is n o t em p ty d o
5. p o p a PSS from Stack_PSS;
6. call ProcessVertex(PSS);
7. call BuildM RA G (A G ):
e n d lo o o
8. o u tp u t MRAG; increm ent NM G RA by 1
9. delete PSS and Stack_PSS;
10. re tu rn :
The d ata structures and procedures used by the algorithm are given below .
Global Data Structures:
(1) A partial subgraph structure (PSS)
Each PSS is represented by:
(i) address of start vertex (Start_PSS)
(i i ) address of end vertex (End_PSS)
(iii) a list of vertices (RA) that each has:
(a) type
(b) a list of successors
(c) address of corresponding vertex in the 
original graph
(iv ) taskid
(v) current vertex (Cur_vertex)
(v i) a 'vertex to expand' stack (Vertex_stack) 
containing address of vertex in PSS and address of 
corresponding vertex in the original graph.
(2) NodeType = {A,  rk/
join)
(3) Start_fork_activity_id = IVI +1
169
(4) The id which can be assigned to a fork activity (Next_forkid)
(5) A stack of PSS stacks (Stack_PSS)
Each entry in StackJPSS contains address of a PSS
(6 ) Last visited ending concurrency vertex (Last_C_end) 
procedure Initialization:
(i) create and initialize a Stack_vertex_to expand stack
(ii) set taskid to a newly generated id
(iii) set start_PSS to s
{i v ) set Cur_vertex to s
(v ) setNM RAtoO
1. create a new PSS (C_PSS) for the start vertex of AG , i.e..
2 . push address of C PSS to StackJPSS
procedure ProcessVertex (PSS):
1. w hile (Vertex_stack * empty) do 
begin
case TRUE of ; expand the current vertex 2 .
3. (f(Cur_vertex) =
4. (f(Cur_vertex) = 
begin
5.
6.
set Last_C_end to Cur_vertex
if the pointer for (address to the vertex in the
output graph) of corresponding vertex in
7.
original graph is not null 
then set that pointer to Cur_vertex 
exit
end
8 . (f(Cur_vertex) = <§)s ),
(f(Cur_vertex) = © s > :
9.
10.
begin
push all successors onto Vertex_stack 
push address of Cur_PSS to Stack_PSS
170
I T for each successor do
12. create and initialize a PSS
13. append taskid of this PSS to a taskid list
14. push address of PSS onto Stack_PSS
endloop
15. create a fork vertex by setting its type to fork,
its successors to the taskid list
16. set Cur_vertex to the fork vertex
17. return
end
18. (f(Cur_vertex) = © e ) :
begin
19. if the pointer for (address to the vertex in the
output graph) of corresponding vertex in 
original graph is null then
begin
20. set that pointer to Cur_vertex
2 1 push all successors but the first onto
Vertex_stack
end
22 copy this vertex to MRAG
(i.e., the subgraph being created)
23. pop a vertex from Vertex_stack
to Cur_vertex
24. exit
end
25. (f(Cur_vertex) = fork):
begin
26. create a join vertex by setting its type to join,
27. set the id of the join vertex to Next_forkid
28. set the successor of the join vertex to
the successor of Last_C_end
29. set the successor of fork vertex to the join vertex
30. set type of this vertex to ’A'
31. set id to Next_forkid
32. copy this vertex to MRAG
33. increment Next_forkid by 1, and
34. set Cur_vertex to the successor of Last_C_end
35. exit
end
171
36. (f(Cur_vertex) = join):
begin
37. set type of this vertex to 'A',
38. copy this vertex to MRAG,
end
39. otherwise:
begin
40. copy this vertex to MRAG
(i.e., the subgraph being created) 
1 41. if (f(Cur vertex) then
set the successor whose type is not (f|)s
1 to Cur_vertex
. else
i begin
, 42 push all successors but the first onto
I Vertex_stack
j 43. set the first successor to Curjvertex
end
44. exit
end
end
endloop
T he next th ree theorem s p ro v e several im p o rtan t p ro p erties of the i 
p a rtitio n in g algorithm .
Theorem 1: G iven an AG , th e set of restricted activity su b g rap h s, RAj =
[Ga, f, g, (sj, e j ) ] ,..., RAj^ = [Gm, f, g, (sm, em)], p ro d u ced by A lgorithm 1 are 
m axim al restricted activity graphs.
Proof. A ssu m e th a t som e Gj is n o t a m axim al restric te d activity
graph.
172
If Gj is n o t a m axim al activity graph, then there exists a vertex v in G 
and v not in Gj such th at G.^>{v} is a restricted activity graph. If v is n o t in 
V rap, th en G .u { v } could no be a restricted activity graph. H ence v m u st be j
| i
tin Vra p . C o n sid er th a t v is in V . Since G . v { v }is a restricted activity j 
g rap h , v is either a successor of a vertex in Gj or a predecessor of a vertex in
I
,Gj. T hus, Let vertex q in Gj be adjacent to v.
i
I
i
Based on (Stepl9-Step24), (Step26-Step35), (Step37-Step38), or (Step40- 
Step44) of procedure ProcessV ertex, if v is the predecessor of q, then v w ould 
have been included in Gj since q, i.e., the successor of v, w as p u t in Gj. If v is j 
the successor of q, then v w ould also be p u t in Gj since q has been p u t in Gj. i
i
H ence, v m u st be in Gj w hich is a contradiction. T herefore, Gj is a m axim al j 
restricted activity graph. □
Theorem 2 G iven an AG w ith IVI = n an d IE I = e, A lgorithm 1 requires 
O(e) tim e to construct all the m axim al restricted activity subgraphs of AG.
Proof. T he In itializatio n step is com pleted in a b o u n d e d tim e C j. ;
T he in n erL o o p trav e rses A G v ia th e o u tg o in g arcs w hich lea d to th e J
i
successors of each vertex. T here are 'e' arcs w hich im plies th e total n u m b er j 
of arcs traversed to find successors is e. W hen each successor is reached, it is ' 
m ark ed an d som e com putation is n eed ed to keep track of vertices yet to be 
traversed an d th e state of the associated partial subgraph. This com putation 
tim e does n o t exceed som e constant C2. T herefore, the total co m p u tatio n 
tim e n eed ed is C j + e*C2. Therefore, A lgorithm 1 requires O(e) tim e. □
173
Theorem 3: G iven a A G w h ich to tally h as ’m ’ p a irs of co n cu rren cy
vertices an d rep licatio n vertices, th e to tal n u m b e r of m axim al restricted 
activity subgraphs generated b y A lgorithm 1 is th e sum of out-degree of all 
jStarting concurrency vertices and starting replication vertices in AG. H ence,
. m
i NMRA= 1 + X d(v.) w here d(vd is the n u m b er of out-going arcs 1
: i= i 1 I
associated w ith v^ |
I
P roof. The p ro o f is by ind u ctio n on m . For m = 0, neither © s n o r
1 0 s is en co u n tered . N o n ew PSSes are created. T herefore, the processing ■
j I
stays in the in n er loop, an d only th e given activity AG is th e only m axim al 
restricted activity g rap h produced. The hypothesis is true.
i
For m = 1, the hypothesis is tru e since at step 9 th e only successor of © s (or 
0 s ) is p u sh e d to V ertex_stack w h en (S)s (or 0 s ) is visited as the cu rren t | 
vertex. T hen, at th e next iteratio n in the 'w hile (V ertex_stack) # em p ty )' j 
loop, the successor p u sh e d in the p rev io u s iteratio n becom es the c u rren t 
vertex to be exam ined. Since the only <§)s (or 0 s ) has been visited at step 9,
hence, th e rem a in in g v ertices of AG w o u ld b e co p ied in to th e o u tp u t 
restricted activity grap h at either Step 22, or Step 32, or Step38, or Step40.
A ssum e th e in d u ctio n h ypothesis tru e for (k-1) > 1. Let AG be an activity 
g rap h w ith k pairs of concurrency vertices and replication vertices. Then AG 
m u st have an innerm ost concurrent su b g rap h AGj w hich is constricted by a 
start concurrency v ertex Vj an d has no c o n cu rren t co m p o n en t activities. 
Based on Step9, d(vj) tasks (subgraphs) are created. The starting concurrency
174
(replication) vertex in AG is replaced b y an activity vertex w ith a special id 
to denote th at d(vj) tasks are forked an d synchronization activity (i.e., join)
are to follow . The en d in g concurrency (replication) vertex in AG is replaced
I
| w ith an activity vertex w ith the sam e id as its corresponding vertex. Let the 
Im odified AG be AG'. A G ', then, has (k-1) pairs of concurrency or replication
i
ivertices. By th e in d u ctio n h y p o th esis, th e n u m b e r of re stric te d activ ity 
Igraphs generated for AG', N M R A ’, is:
l
1 , (*-D
! NMRA = 1 + X d(v.).
| i - i 1
i
H ence th e total num ber of restricted activity activity g rap h generated for AG 
is:
N M R A - d(y ) + NM RA =>
(* -l)
NMRA= d(v.) + 1+ X d(v.)= > 
k
NMRA= 1+ X d(v.). □
i = l 1
4 .2 .4 . AN EXAM PLE O F PA RTITIO N IN G AN A CTIV ITY G R A PH
In the follow ing I u se an exam ple activity g rap h in w hich th ere are 
tw o p a irs of c o n cu rren cy n o d e s to illu stra te th e re su lts of a p p ly in g 
A lgorithm 1. I also dem onstrate h o w T heorem 3 can be a p p lied to check if 
sufficient n u m b er of restricted activity g rap h s p ro d u ced from p artitio n in g a 
given activity graph.
175
F ig u re 4-15 contains an activ ity g ra p h AG in w hich th e re are 20 
vertices and 26 arcs. O bserve th at there are tw o pairs of concurrency vertices, 
one m ark ed w ith 3 an d th e o th er m ark e d w ith 4. The o u t-d eg ree of th e
1
i
|sta rtin g co n cu rren cy vertex m ark ed w ith '3' is 2. The o u t-d eg re e of th e
i
i startin g concurrency vertex m arked w ith '4' is 3.
AG
Figure 4-15: Two Pairs of Concurrency Vertices Marked With '3' and '4'
F ig u re 4-16 d ep icts th e re stric te d a ctiv ity g ra p h s g e n e ra te d b y 
A lgorithm 1 for th e given activity g rap h AG. A ccording to T heorem 3, the 
total n u m b er of restricted activity g rap h s generated should be 6, i.e., (1+ 2 + 
3) = 6. O bserve that the num ber o f restricted activity g ra p h in Figure 4-14 is 
in d eed 6. T he restricted activity g ra p h RA6 contains tw o pairs of fork-join 
activities: fork(21)-join(21) a n d fork(22)-join(22). E ach fork-join activ ity 
chain is u se d to replace a co ncurrent subgraph. This is d u e to the fact th at
176 : i - ,
each c o n c u rre n t su b g ra p h in sta n tia te s a se t of c o n c u rre n t th re a d s of 
activities. Each th read of activities is executed b y a task. In the activity grap h 
containing the co n cu rren t su b g rap h , th e activity w h ich is the successor of 
th e e n d in g c o n c u rre n c y v ertex can n o t s ta rte d u n til all th re a d s are 
co m p leted . T herefore, a join activ ity is a d d e d for sy n ch ro n izatio n . For 
exam ple, activity H cannot start until C an d D exit. T he fork(21) p revents the 
task executing RA6 (i.e., task6) from p erfo rm in g activ ity H . T he join(21)
i enables the execution of activity H w hen task l an d task2 notify task6 of their
i
co m p letio n .
i _ _ _ _ _ _ _
RA1 
C
W r
RA3
|~ E |
task3
RA5
r~G
Figure 4-16: Maximal Restricted Activity Graphs for AG
RA6
fork fork
task6
RA2
D 1
task2
RA4
F
task4
177
4.2.5. TA SK GRA PH S
E arlier in Section 4.1, I inform ally described th e p ro p erties of a task, 
th e b u ild in g blocks for rep resen tin g h o w a task interfaces to o th er tasks or 
external devices, a n d ho w a restricted activity g ra p h is rela te d to a task.
!
|N ow , before g ettin g in to th e form alism of a task g ra p h , I first form ally
j
define the necessary inform ation for describing a task.
A ta s k is described by a task descriptor w hich in clu d es th e follow ing 
types of inform ation: (i) p o rts — its interfaces to o th er tasks, external devices, 
a n d to th e ru n -tim e system ; (ii) a t t r i b u t e s — sta te v a ria b le s a n d th e ir 
properties; (iii) b e h a v io r— its functional specifications (e.g., pre- an d p o st
c o n d itio n fo rm u la s) a n d tim in g c o n strain ts sp e cifica tio n s (e.g., state- 
d ep en d en t execution tim e); and (4) stru c tu re — its associated restricted activity 
graphs. Task descriptors m ay be w ritten in different p ro g ram m in g languages
(e.g., A da, C, etc.), an d executable on different processors. D uring execution j
I
tim e, p rocesses, w h ich are in stan ces o f tasks, ru n o n p o ssib ly sep arate j
processors and com m unicate w ith each other via a specific set of d ata flow s, i
i
w hich m ay be im p lem en ted as m essages. The task tem p late defined in this 
jSection is n o t in te n d e d to be d irec tly tra n sla te d in to object code. The 
in ten tio n is to allow one to b u ild a tool w hich generates resource allocation 
a n d sc h e d u lin g d ire c tiv e s by sy n th e siz in g th e first th re e classes of 
in fo rm a tio n afo rem en tio n ed or a tool to g e n erate a co d e skeleton from 
in te rp retatio n of th e task's restricted activity graph. I also assum e th at the
178
task descriptors, w ritten an d stored in task libraries, are b u ild in g blocks for 
task g rap h description program s.
D efin itio n 3: A ta s k is a seq u en tial p ro g ram u n it w h ich is d eclared as 
follow s:
ta sk  
p o rts
< po rt_ d eclaratio n s>
[ < p o rt_ rela tio n _ d ec lara tio n s>
attrib u tes
state v ariab les 
| im p o rtan ce lev el < im portance_declarations>
! stru c tu re
< activ ity _ g rap h _ d eclaratio n >
< d ata_ g rap h _ d eclaratio n > 
e n d 
D efinition 4: A d ata ele m e n t is a sequential p ro g ram u n it w hich is declared 
as follows:
d ata elem en t  
p o rts
< p o rt_ d eclaratio n s>
attrib u tes
state v ariab les  
im p o rtan ce lev el < im portance_declarations> 
e n d 
D efinition 5: A c h an n e l is an interface pro g ram u n it w hich can be specified 
as follows:
< data_item > := < nam e>
< channel> := < data_item > : fro m < port_nam e> to  ;
179
A channel represents an arc w hich connects tw o vertices in a task 
graph. A vertex m ay be a task or a d ata elem ent.
D e fin itio n 6: T extual n o tatio n s for sp ecificatio n s of p o r ts , a t t r i b u t e s , 
b e h a v io r, tim in g co n strain ts, and s tru c tu re are defined below . A lso in the 
follow ing d efin itio n , th e context-free syntax of the n o tatio n is describ ed 
u sin g a v a ria n t of B ackus-N aur Form (i.e., '{' a n d enclose a re p e a te d 
item ; th e item m ay ap p ear zero or m ore tim es; th e repetitions occur from 
left to right. A vertical bar , ' I', separates alternative item s, unless it occurs 
im m ediately after an opening braces, in w hich case it stands for itself.)
< n am e>
A nam e is a string starting w ith upper-case letter.
i
< co n d itio n _ fo rm u la> := < p re _ co n d itio n _ fo rm u la> I '
I
< p o st_ c o n d itio n _ fo rm u la > j
R efer th e syntax for specifying pre- an d post- condition form ula in i 
D efinition 3 of Section 3.2.3. '
I
i
< p o rt_ b eh av io r_ d eclaratio n > := j
w h e n < co n d itio n _ fo rm u la> I
w ith < tim in g _ co n strain t_ fo rm u la> j
T he p o rt b ehavior declaration defines th e con d itio n of w hich an ! 
in p u t (output) p o rt is to be enabled an d th e tim ing p ro p e rty w ith 
w hich an in p u t (output) is to be enabled.
 := m an d ato ry in I o p tio n a l in I out
This attrib u te identifies if the specified p o rt is a 'm an d ato ry in p u t’ 
p o rt, an 'optional in p u t' port, o r an 'o u tp u t p o rt’.
< p o rt_ n a m e >
180
A p o rt n am e is a string.
< p o rt_ d e c la ra tio n > :=
< p o rt_ n a m e > : < p o rt_ ty p e > < p o rt_ b e h a v io r_ d e c la ra tio n >
In each p o rt declaration, one specifies th e p o rt nam e follow ed by
f . i
< p o rt_ d e c la ra tio n s> := {< port_declaration> } < p o rt_ d e c la ra tio n > ;
< p o rt_ re la tio n _ o p e ra to r> := — > I @
'A — »B' represents th at p o rt B is read after p o rt A. ’ A@B’ represents 
th at either p o rt A or p o rt B is read b u t n o t both. J
< p o rt_ re la tio n _ p re d ic a te > I
A p o rt relation predicate is a predicate expressed w ith port_nam e !
an d port_relation_operator. For exam ple, ( p i— »p2)©p3 states that 
either p o rt p i or p o rt p3 w ill be read. If p i is read, then p2 w ill be ■ 
read som e tim e later w hen the enabling condition of p2 is m et. i
< p o rt_ re la tio n _ d e c la ra tio n s> := !
I
n u l l l { < p o r t _ r e l a t i o n _ p r e d i c a t e > } j
< p o rt_ re la tio n _ p re d ic a te > ;
W hen there are m ore th an tw o in p u t p o rts or tw o o u tp u t p o rt, a 
set of port_relation_form ula can be u sed to describe the tem poral 
re la tio n sh ip b e tw ee n in p u t p o rts o r th e tem p o ral relatio n sh ip 
betw een o u tp u t ports.
< a c tiv ity _ g ra p h _ d e c la ra tio n > := < g ra p h _ id > ;
< g ra p h _ id >
A g rap h identifier is a un iq u e positive integer.
< g ra p h _ id _ list> := {} < g ra p h _ id > ;
< d a ta _ g ra p h _ d e c la ra tio n > := n u ll I < g ra p h _ id _ list>
181
O b s e rv e th a t th e o p e ra to r s u s e d fo r c o n s tru c tin g th e 
p o rt_ relatio n _ p red icate co rresp o n d to the sequence o p erato r p rim itiv e an d 
th e selection prim itive. T his suggests th at the p o rt_ relatio n _ p red icate of a 
task could be synthesized from the associated m axim al restricted activity. 
I A lgorithm 2 defines a m eth o d for deriv in g the port_relation_predicates for 
jail in p u t ports and o u tp u t po rts of a task.
I
, A lg o rith m 2: G iven a task Tj an d its associated m axim al restricted activity 
jg ra p h M R A G j, a set of in p u t p o rts, a set of o u tp u t p o rts, an in p u t 
!p o rt_ re la tio n _ p re d ic a te , a n d a n o u tp u t p o rt_ re la tio n _ p re d ic a te are 
produced.
1.
2.
14.
5.
6 .
7.
8.
9.
10
II
use the 'Depth First Search’ to identify each vertex in MRAGi do 
begin
if type(vertex) = © s ' then
begin
put '©' to the in port relation predicate expression buffer 
put ’©' to the out port relation predicate expression buffer
end
if type(vertex) = 'A' then 
begin
if the activity is at heads of some com. primitives then 
begin
if predecessor(vertex) is an activity has input then 
put to the ’ in port relation predicate 
expression buffer' 
create an input port and generate a port identifier 
put portid to the 'in port relation predicate 
expression buffer'
end
if the activity is at tails of some com. primitives then 
begin
if predecessor(vertex) is an activity has output then
182
12.
13.
j end
;14. STOP
; T he task g rap h d efined below is a directed g ra p h w hich h as n odes
Ibeing tasks o r d ata elem ents. A n arc b etw een tw n o d es rep resen ts a d ata
|flow, and th e direction of the d ata flow corresponds to th at of the arc.
I
i Form ally, a task graph TG is a 6-tuple,
TG = [G, f, g, t, h, s]
w h ere: G = [V, E] is a d irected g rap h in w hich V is th e set of
nodes and E is the set of arcs.
f is a function from V into the set of allow ed n o d e types 
Vtp (Vtp is defined explicitly below .)
g is a function from V in to the set of p o sitiv e integers, i 
This essentially provides a label for each node.
t is a function from V into th e set of tim in g functions 
(the
m a p p in g ch arac teristics of th is fu n c tio n is d e fin e d 
below .)
h is a function from E into 2-tuple, i.e.,
1. the set of positive integers p ro v id in g a label for 
each arc;
2. the set of positive integers providing size 
of data associated w ith each arc.
s is a distinguished n o d e called the 'start node'.
put to the ’ out port relation predicate 
expression buffer' 
create an output port and generate a port identifier 
put portid to the 'out port relation predicate 
expression buffer'
end
183 '
The set of no d e types perm itted in a task g rap h is Vtp = {T, Dj, DQ }, i.e., 
th e set of n odes allow ed are tasks, in p u t d a ta elem ents, an d o u tp u t d ata 
elem en ts.
T he fo u rth com ponent t of th e tu p le [G, f, g, t, h, s] is a function
j
im ap p in g each e le m e n t Vj in V in to tim in g specification functions. If a 
v e rte x Vj is in Vt, th en t (vj) is an execution fu n ctio n e (e x i, ex2 ,..., exk)
w here k > 0 an d exi, ex2 ,..., exk are ex i, ex2 ,..., exk are expressions relatin g I 
tim ing in stan t variables or state variables of vertex v^ If a vertex Vj is in Vd, | 
th en t (vj) is a tu p le of tim ing specification functions [% , sw (exi, ex 2,..., exk), 
rd (e x i, ex2 ,..., exk), ef(ex i, ex2 ,..., exk)] w h ere x is th e initial arriv al tim e 
relative to system start-up tim e (i.e., t = 0) an d sw , rd, ef, an d e are tim ing 
specification functions as defined in D efinition 3.2-1.
In su m m ary , th e p ro p o sed design specification m eth o d h as a 3-part 
com putational m odel. H ow each p art is su p p o rte d is described in Table 4-A, 
Table 4-B, an d Table 4-C.
184
_____ 1
Desired Properties 
in Data Models
Expressibli
Properties
Composition
• non-atomic data items are 
decomposable.
Conditional Sequences
• supported by the ’ selection’, 
'iteration', and 'data item' 
primitives.
Parallel Sequences
not supported, 
(implies non-sequential 
execution')
Multiple Instances of 
The Same Type
not supported.
(implies non-sequential 
execution')
Timing Specification
• predicates expressed by time 
instant variables.
Table 4-A: Properties Supported by Restricted Data Graphs
Desired Properties 
in Control Flow 
Models
Expressibli
Properties
Composition
• supported by composite 
activities and tasks.
Conditional Sequences
• supported by the ’ selection’, 
’iteration’ , ’ activity’ , ’ task’, primitives.
Parallel Sequences
• supported by the ’ task ’ and 
’ communication’ primitives.
Multiple Instances of 
The Same Type
not supported.
Timing Specification
• predicates expressed by time 
instant variables.
Enabling and 
Exiting Criteria
• supported by pre-condition & 
post-condition formulas.
Table 4-B: Properties Supported by Task Graphs and Restricted Activity Graphs
185
Desirable Propertie 
in Sequential 
program Models
Expressibli
Properties
Stimulus and 
Response Relationship
• supported by pre-condition & 
post-condition formulas.
State Changes • supported by using ADA PDL 
and 'state variables'.
Timing Specifications • timing constraints formulas.
Interconnections 
Between Programs
• A restricted activity graph 
defines relationships between 
programs.
Validation Points 
and Criteria
• supported by pre-condition & 
post-condition formulas.
Table 4-C: Properties Supported by Restricted Activity Graphs and the Task Definition
Template
G iven definitions of activity g rap h an d task g rap h an d algorithm s for 
d eriving a set of m axim al restricted activity grap h s from a activity g raph, in 
the follow ing, I discuss how a task g rap h can be autom atically derived.
186
4 .3 . D E R IV IN G AN IN IT IA L T A S K G R A P H F R O M
t
R E Q U IR E M E N T S |
I
i
So far I p resen ted a req u irem en ts specification m eth o d w ith w hich 
th e requirem ents specifications are expressed in the form of activity graphs, 
jdata g ra p h s, p ro g ra m d e scrip tio n lan g u a g e, a n d co n strain ts (in clu d in g 
jtim ing c o n strain ts, p re-c o n d itio n , a n d p o st-c o n d itio n fo rm u las). I also 
ipresented a design specification m ethod w ith w hich a design is expressed in 
term s of restricted d ata graphs, restricted activity graphs, task tem plates, and 
task g rap h s. The general scenario described in th e follow ing o u tlin es the 
softw are req u ire m e n ts specification, to p level d esig n , detail design, an d 
coding phases of the softw are developm ent process.
Step 1: D efine S oftw are R equirem ents: T he tim e sequence p ro p erties of a 
system are expressed com pletely in term s of d ata graphs an d activity 
g rap h s. The decom position process is com pleted w h en all activities 
are d e co m p o se d in to atom ic a ctiv ities, all ato m ic activ ities are 
sp e c ifie d w ith p re - a n d p o st- c o n d itio n s, all d a ta ite m s are {
i
d eco m p o sed in to atom ic d a ta item s, a n d th e req u ire d tim in g a n d j 
resource constraints are specified. J
Step 2: P erform P a rtitio n : A n activity g rap h , rep resen tin g a req u irem en ts J 
specification, is p a rtitio n e d in to a set of m axim al restricted activity 
grap h s usin g A lgorithm 1.
Step 3: D efine a Softw are A rchitecture: G iven this set of m axim al restricted 
activ ity g ra p h s, th e o rig in al activ ity g ra p h , d a ta g rap h , an initial 
softw are architecture, expressed in term s of a task g rap h , is d eriv ed 
based on a set of task derivation rules.
1 8 7
Step 4: E valuate the A rchitecture: A ssess if the p ro p o sed design satisfies the 
tim in g an d sizing constraints a n d o th er p e rtin e n t properties. If the 
p ro p o sed design does not m eet the specified requirem ents; go to S tepl ; 
if the designer determ ines th at the requirem ents are not realizable for j 
a given h a rd w a re architecture; go to Step2 to com bine som e set of | 
tasks into a bigger task if for exam ple the n u m b er of tasks p ro d u ced j 
exceeds th e lim it im posed by th e h a rd w are o r th e o p eratin g system ; j
i
go to Step2 to p artitio n a task in to a n u m b er of tasks if for exam ple 
som e tasks p ro d u ced are too large to fit in to m em ory; or go to Step3, 
for exam ple, w h en th e tim ing constraints cannot be satisfied an d an 
alternative h ard w are architecture is allow ed.
A fter an initial softw are architecture has been autom atically derived, 
sim ulation m ay be used to assess the realizability of th e task g rap h w ith a 
d esirable degree of accuracy. Based on sim ulation resu lts or o th er criteria, 
th e designer m ay u p d a te the task g rap h , effectively o v errid in g any existing 
d e sig n choice. T he m o d ifie d ta s k g ra p h m ay o r m a y n o t sa tisfy 
requirem ents. A gain, sim ulation m ay be used to v alid ate if the new design j 
is realizable. j
In the follow ing, before I outline the p ro ced u re for deriving an initial 
task g rap h from a given activity graph. I first identify a set of synthesis rules j 
w hich are u sed in th e derivation.
• task m ap p in g rule
The p u rp o se of this ru le is to define a baseline set of tasks based on 
a given activity g rap h . The ap p ro ach is to create a task for each 
m axim al restricted activity graph. T he restricted activity g ra p h is 
labeled w ith a unique task identifier.
188
in p u t/o u tp u t m ap p in g ru le
T he p u rp o se of this ru le is to p reserv e th e in p u t a n d o u tp u t 
req u irem en ts. T herefore,
- if a task is created from a m axim al restricted activity g rap h , the 
task inherits all the in p u ts an d all the o u tp u ts from its associated 
m axim al restricted activity graph;
- if a task is created from a junction connector, the fan -in arcs 
becom e the in-com ing d ata flow s of the task an d th e fan-out arcs 
becom e the out-going d a ta flow s of the task.
|
- if a task is created to replace a m erge connector, an equivalent j 
connector, an d a split connector, then the fan-in arcs of the m erge j 
connector becom e the in-com ing d ata flow s of th e task a n d the 
fan-out arcs of th e split connector becom e the out-going d ata flow s ;
I
of th e task.
p o rt_ relatio n _ p red icate d eriv atio n ru le
The p u rp o se of this ru le is to preserve th e tem p o ral p ro p erties of ! 
d a ta c o n s u m p tio n a n d p r o d u c tio n . T h e r e f o r e , th e ! 
p o rt_ re la tio n _ d e c la ra tio n of a task is s y n th e siz e d b y a p p ly | 
A lgorithm 2. J
i
tim in g conversion ru le
T he p u rp o se of th is ru le is to p reserv e th e tim in g co n strain ts 
represented in th e execution fram e function associated w ith a pair 
of iteration prim itives w hich enclose a set of atom ic activities. For 
each p air of iteratio n prim itives w ith a c o n sta n t execution fram e 
fu nction in th e associated restricted activity g ra p h o f a task, a
189
synchronization m echanism (e.g, signal, sem aphore) is selected to 
be in co rp o rated into th e task g ra p h a n d m o dify th e associated 
restricted activity g rap h (e.g., w ait o n a signal or a sem aphore). For 
n o n -c o n sta n t execution fram e, an activity is ad d ed as a successor 
v ertex of th e en d iteratio n vertex. For b o th co n stan t an d n o n 
constant execution fram e, b o th the start vertex an d th e en d vertex j
are deleted from the graph. I
!
I
• interface m ap p in g rule j
I
T he p u rp o s e of th is ru le is to p re s e rv e th e d a ta flo w j 
com m unication characteristics. T herefore, tasks in h erits all d a ta ! 
flow prim itives betw een m axim al restricted activity graphs. j
• d ata integrity rule
The p u rp o se of this rule is to m anage data integrity for sh ared data 
item s. For each d a ta item X w h ich is associated w ith ju n ctio n 
c o n n ecto rs, a data m anager task is created for X to p ro v id e 
concurrent accesses to X an d m aintain integrity and consistency of 
X. T he d a ta item X becom es a p riv a te d a ta item of th e d a ta 
m anager task an d o th er tasks sen d req u ests to th e data manager 
for obtaining inform ation from or depositing inform ation to X.
• d a ta transform ation rule
T he p u rp o se of th is ru le is to tran sfo rm a d a ta item from th e 
p ro d u c e r's view to th e co n su m er's view . For each d a ta item X 
w hich is associated w ith m erge connector, eq u iv alen t connector, 
a n d sp lit connector, a 'd a ta tran sfo rm er' task is created for X to 
receive d ata according to th e properties specified in th e associated 
d a ta g rap h an d split connector, an d then, transform th e d a ta into 
th e d esired p ro p erties specified in th e associated d a ta g ra p h of 
m erge connector.
190
G iven an activ ity g rap h AG, its associated set of com m unication 
prim itives CP, an d its associated set of d ata g rap h s DG, th e follow ing is an 
outline of steps taken for deriving a task g rap h TG.
S tepl: ap p ly Algorithm 1 to obtain a set of m axim al restricted activity 
g raphs from AG.
Step2: d eriv e an initial set of tasks by a p p ly in g th e task mapping rule
such th at a task is created from each m axim al restricted activity 
graph.
for each task d o
begin !
(1) a p p ly th e input/output m apping rule to o b ta in all th e 
in p u ts an d o u tp u ts of the task.
(2) a p p ly th e port_relation_derivation rule to d efin e all the 
i n p u t p o r t s , a ll th e o u t p u t ports, the in p u t 
p o r t _ r e l a t i o n _ p r e d i c a t e , a n d t h e o u t p u t | 
p o rt_ relatio n _ p red icate.
(3) ap p ly th e tim ing conversion ru le to replace each p a ir of 
ite ra tio n v e rtice s w h ic h h as a c o n sta n t e x ec u tio n fram e 
function w ith a given synchronization m echanism .
e n d
Step3: derive the precedence relations betw een tasks. 
for each com m unication prim itive c in C P d o 
begin
if type(c) = d ata flow then 
begin
a p p ly th e interface m apping rule to create a c h a n n e l to 
connect
191
t h e t a s k s o n e a c h e n d o f t h e d a t a f l o w c :
o u tp u t this channel to a 'channel_list' buffer. 
e n d
if type(c) = junction th en 
begin
apply the data integrity rule to create a data manager task. j
create tw o in p u t ports: j
- one for the request to rea d from the d ata item an d i
- th e o th er for th e req u est to w rite in fo rm atio n in to th e ! 
data i
item 1
i
c re a te o n e o u tp u t p o r t fo r re tu rn in g th e re q u e s te d j
in fo rm a tio n i
to the requestor of the read) for the data manager. j
i
change th e junction connector into a m erge connector w hich j 
has the sam e d a ta item as th at associated w ith the junction j 
connector. T here is only one bi-directional arc betw een j
the d a ta item an d the data manager.
i
ap p ly the input/output mapping rule to obtain all th e j
in p u t and o u tp u t d ata flow s of the data manager and 
at the sam e tim e a p p en d these d ata flow s to CP.
e n d
i
if type(c) = equivalent th e n i
I
begin. j
i
ap p ly the data transformation rule to create a data transducer i 
task. J
l
create one in p u t ports an d one o u tp u t port. !
apply the input/output mapping rule to o b tain all th e |
in p u t an d o u tp u t d ata flow s of th e transducer manager an d | 
at the sam e tim e ap p en d these d ata flow s to CP. j
t
I
192
e n d
delete c from CP.
I e n d
A fter one goes th ro u g h several iteratio n s of d efining th e so ftw are 
arch itectu re, a task g ra p h is d eriv ed . T here still is th e issu e of h o w to 
m a n a g e re s o u rc e s su c h th a t th e tim in g c o n s tra in ts a n d re s o u rc e 
requirem ents of activities in a task can be satisfied.
4.4. SUM M ARY
I
In this chapter, I d ev elo p ed th e m eth o d o lo g y for tran sfo rm in g th e J 
activity g rap h and d ata graph to a softw are design. I defined the concepts of a 
m axim al re stric te d activity g rap h . T hese w ere sh o w n to c o rre sp o n d to 
se q u e n tia l p ro cesses or tasks. In a d d itio n , an a lg o rith m fo r d e riv in g ; 
m axim al restricted activity g rap h s from an activity are p resen ted as w ell as 
th e m eth o d s for con stru ctin g task g rap h s b ased on th e d eriv ed m axim al 
restricted activity graph. i
i
J
i
In th e n e x t c h a p te r, I p re s e n t an ex am p le a p p lic a tio n of th e 
m eth o d o lo g y in som e detail. The ex am p le is d ra w n from avionic ra d a r 
system s an d represents a non-trivial application.
i
i
193
5. AN EXAMPLE SENSOR SYSTEM
J A dvanced avionic rad a r system s w ere in tro d u ced in C hapter 2 as one
im p o rtan t exam ple of sem i-hard real-tim e system s. In this chapter I w ill use 
the m ethodology d ev elo p ed in C h ap ters 3 an d 4 for th e specification an d
j
design of an exam ple avionic rad a r system w ith an electronically scanned 
an ten n a. T he req u ire m e n ts specification is given first u sin g th e activ ity 
g rap h form alism . A n initial softw are design b ased on this specification uses 
A lg o rith m 1 from C h a p te r 4 to g en erate th e m axim al restricted activity 
g ra p h s fro m th e req u ire m e n ts. I th e n u se th e ta sk g ra p h d e riv a tio n 
algorithm defined in Section 4.3 is to generate th e corresponding task graph.
|
The results of this initial design phase are presented. !
i
I
5.1. REQ U IREM EN TS SPEC IFIC A TIO N
I
A dvanced avionic rad ar system s typically interface w ith tw o classes of i 
external physical processes: com m and processes a n d m o n ito red processes. 
Exam ples of com m and processes are a pilot, o th er sensor subsystem s w hich 
h a v e c o m m u n ic a tio n lin k s w ith th e ra d a r su b sy ste m , o r a m issio n 
com puter w hich gives the rad a r subsystem directives on w h at d ata to obtain 
a n d h o w to process it. E xam ples of m o n ito red physical processes are an 
airplane, a specified air space, a specified g ro u n d space, or a w eather object. 
As show n in th e activity g rap h in Figure 5-1, a sensor subsystem interfaces 
w ith command processes directly, b u t interfaces w ith monitored physical 
processes via a fro n t end. T hese fo u r co m p o n en ts: com m and processes, 
sensor su b sy ste m , fro n t end, a n d m onitored physical processes, are 
concurrent w ith each other an d com m unicate th ro u g h data.
194
&
External
Requests
Monitored
Physical
Processes
Front
End
Command
Processes
Sensor
Subsystem
r Front 
End 
t Status
Figure 5-1: An Activity Graph Representing the Interaction Between a Advanced Radar
System and Its External Environment
T he sensor su b syste m c o n su m e s external requests issu e d by |
i
command processes an d pro d u ces track files w hich co n tain in fo rm atio n on | 
th e state of cu rren tly m o n ito red physical processes. T he sensor subsystem I
I
i
p ro d u ce s front end directives w hich contain a set of firm w are com m ands to j 
control the tim ing an d w aveform of signals to be tran sm itte d in o rd er to I 
sen se m o n ito re d processes. R eturned waveforms are p ro d u c e d w h en the 
transm itted w aveform s are reflected b y th e monitored physical processes.
i
T hese re tu rn e d signals are th en received by th e front end receiver w hich 
tran sfo rm s th e collected signals in to digital form at an d , th en , deposits the 
tran sfo rm e d in fo rm atio n in to th e d a ta stru c tu re s re fe rre d to as collected 
returns. D u rin g d ata collection, th e front end p ro d u ces front end status to 
indicate if the collection of th e specified signals w as com pleted norm ally or 
th e collection of sig n als has en co u n tere d som e a b n o rm a lity su ch as the
195.
signal to noise ra tio exceeding th e allo w ab le lim it. T hen, th e collected 
r e tu r n s are p ro cessed b y th e sensor system to fo rm o b se rv a tio n s for 
pred ictin g the fu tu re state of the m o n ito red physical processes such th at the 
sensor subsystem can d e te rm in e w h e n to ag ain o b serv e th e p h y sic al
| i
I processes in o rd er to n o t lose track of them . Also, b ased on th e collected
i
j retu rn s, the state of each observed physical process is stored in a database, 
j called a trackfile. The inform ation in track files are retu rn e d to com m and
i I
! processes eith er on d em an d or periodically at a specified tim e interval.
f
I
3 component s: (1) Sensor Manager, (2) Signal Processing Manger, (3) Data Processing
Manager.
Figure 5-2: An Activity Graph Representing a Sensor Subsystem
F igure 5-2 contains a refinem ent of the sensor subsystem . T he three 
in p u ts: External Requests, Front End Status, an d Collected Returns, an d tw o
Signal A f D ata ^ 
Processing Processing
^R equests y ^ R e q u e sts j
4 \ \
Front
End
Status
^ Front 
End 
^Requests^
Data
Processing
^Manager^
Signal
Processing
M anager
Track
Files
External
Requests
Sensor
M anager
f Front ^ 
End 
l D irectives j
Collected
Returns
Track
D atabase
A bort
196
o u tp u ts: Front End Directives and Track Files in Figure 5-1 are in h erited by 
the refined activity g rap h of the sensor subsystem.
A s show n in Figure 5-2, a sensor subsystem is com prised of a Sensor
I
,M a n a g er, a Signal Processing M anager, an d a Data Processing M anager, 
executing co n cu rren tly w ith each other. In ad d itio n to the 5 in p u t/o u tp u t ;
i
jd ata item s, th e re are 5 co m m unication connectors: (1) signal processing 
\requests, (2) abort, (3) data processing requests, (4) front end requests, a n d (5) 
track database. The sensor manager co n su m es th e tw o ex tern al in p u ts , 
external requests an d fro n t end status, a n d track database; from th is 
in fo rm a tio n it th en p ro d u ce s th e ex tern al o u tp u t front end directives to
I
direct the fro n t en d tran sm itter as to h o w to tran sm it signals. The signal 
processing manager accepts th e signal processing requests from th e sensor 
manager; then, consum es an d processes collected returns according to th e 
directions specified in the signal processing requests. Signal processing for a 
specific signal processing request w ill be aborted if an abort is received from 
th e sensor manager. By com paring inform ation in th e track database, it can 
be d eterm in ed if the observation form ed from collected returns is associated 
w ith k n o w n m o n ito re d processes. A track u p d a te (T U ) data processing
J
request is issu ed to th e data processing manager w h en th e o b serv atio n is 
associated w ith a k n o w n m o n ito red process. A search confirm (SC_act) 
front end request is issu ed to th e sensor m anager fo r o b ta in in g m o re 
detailed a n d /o r accurate inform ation w hen th e observation is n o t associated 
w ith k n o w n m o n ito re d processes. F inally, th e data processing manager 
correlates the given observation w ith m o n ito red physical processes u sin g 
som e sco rin g fu n ctio n , e stim ates th e fu tu re sta te of th ese m o n ito re d
_________________________________ 19 7 _
p ro cesses a n d u p d a te s th e sta te in fo rm a tio n in th e track database. In 
ad d itio n to u p d a tin g th e track database, the data processing manager is also 
responsible for deleting a specific set of m onitored processes on d em an d and 
o u tp u ttin g the track database to track files periodically.
Sensor
M anager
c
Front
End
Requests
External
Requests
Front End 
Planning 
Directives^
f Front End
A Front 
End 
Directives
Track
Database
W orkload 
List
W ork
U nit
Front Front End 
Requests 
M anager
Front 
End 
Planner
Front 
End 
Scheduler
Data 
Processing 
Requests
Front 
End 
^ S ta tu s
Abort
X o- 
r Signal
Processing
I Requests
Figure 5-3: An Activity Graph Representing Computational Behavior of Sensor Manager
Figure 5-3 contains an activity g rap h rep resen tin g the refinem ent of 
the sensor manager in w hich th e 3 in p u ts and the 4 o u tp u ts of the sensor 
m a n a g e r are in h erite d . T his is d u e to th e ru le th a t, at each level of 
refinem ent, th e in p u ts an d o u tp u ts of an activity m u st be in h erited b y its 
associated activity g rap h rep resen tin g the refinem ent of th e activity. A lso 
each in p u t m u st hav e a com ponent activity in th e refin em en t to consum e 
it; sim ilarly, for each o u tp u t th ere m u st be a c o m p o n en t activity in the 
refinem ent to p roduce it.
198
A lso the sensor manager in Figure 5-3 is com prised of a Front End
Requests M anager, a Front End Planner, a Front End Scheduler, an d a Front
End Setup. In a d d itio n to th e 7 in p u t/o u tp u t d a ta item s, th e re are 3
a d d itio n a l co m m unication connectors: (1) front end requests, (2) front end
jplanning directives, and (3) front end workload list. The front end requests 
I i
m a n a g er co nsum es external requests. B ased on th e in fo rm a tio n in an j
i
external request, it th en p ro d u ce s front end planning directives to d irect j 
j usage of the front end resource, how each type of front en d activity should j
i
be p lan n ed , or w h at front en d activities are to be aborted. A t this level of j 
j refin em en t, only w hat are p ro d u ce d by the front end requests manager is j 
|specified. T he details of w h en , w h y , an d h o w abort, fro n t end planning j
directives, data processing requests are p ro d u c e d are specified at th e next j
l
level, i..e, th e refin em en t of th e front end requests manager. T he front end j
l
planner accepts 5 in p u ts an d produces 2 o u tp u ts. Based on th e inform ation 
in the track database, the front end planner assesses th e tactical situ a tio n 
b a sed o n k n o w led g e of th e sta te of each m o n ito red processes. It th en 
determ ines th e relative tactical im portance level of each fro n t en d activity 
associated w ith each front end request by u sin g som e v alu e fu n ctio n and 
d e te rm in e s th e tim in g c o n strain ts of each fro n t e n d activ ity . T h en it 
p ro d u c e s a front end workload list in w h ic h fro n t e n d activ itie s are 
d escribed in clu d in g inform ation such as tim in g specification function s ef, 
sw , a n d rd , im portance level, a n d g ro u p id, etc. T he front end scheduler 
read s in th e front end workload list, uses a real-tim e sch ed u lin g algorithm , 
such as E a rlie s t D e a d lin e F irs t , R a te M o n o to n ic a lg o rith m s 
[Liu& Layland74], to select a work unit w hich is th e m o st im p o rtan t, tim e-
199
critical, an d tim e-inflexible activity to be perfo rm ed next by th e front end. 
B ased o n th e in fo rm a tio n in th e work u n it, th e front end setup th e n 
produces a set of firm w are com m ands to direct th e front en d tran sm itter as
j
to w hich w aveform s are to be transm itted an d the tim ing properties of each 
I w av efo rm .
f
i
i
I
A lth o u g h each in p u t (each o u tp u t) of an a ctiv ity m u st h a v e a 
co rresp o n d in g com ponent activity to consum e (produce) it, this does n o t 
m ean th a t the consum er com ponent activity for each in p u t. For exam ple, 
the front end planner consum es tw o in p u ts, one b ein g the track database 
an d the o th er b ein g th e front end status. T he front end requests manager 
co n su m es external requests an d p ro d u ces data processing requests. T he i
i
tem poral and spatial parallelism properties represented in the d ata graphs of ;
t
in p u ts an d o u tp u ts of an activity suggest h o w the activity can be refined ! 
such th a t th e co m p o n en t activities consum e th e in p u ts an d p ro d u c e th e i 
o u tp u ts according to these sam e tem poral and spatial parallelism properties, j
External
Requests
ef > 0 .1 ^
Request
External
Request
' Etelete 
Track 
File
J
Performance j! Im portance 
uirem ent Bound
J \
(a) The Data Graph for External Requests, (b) Refined Data Graph for External Request. 
Figure 5-4: Data Graphs Representing Properties of External Requests
For exam ple, th e d ata g rap h in Figure 5-4(a) is th e refinem ent of the 
external requests w hich are th e in p u ts to th e sensor manager. T he d a ta
onn
g rap h specifies th at the external requests are a sequence o f external request. 
The expression 'ef > 0.1' associated w ith th e sta rtin g ite ratio n p rim itiv e 
specifies th at th e tim e interval, represented by the execution fram e function 
ef, betw een tw o instances of external requests is at least 0.1 second. The data 
g ra p h in F igure 5-4(b) is the refinem ent of the external request. The d ata 
g ra p h in F igure 5-4(b) specifies th a t an external request m ay be eith er a 
search request, a delete track file request, a set resource bound req u est, a set 
\performance requirements request, or a set importance level req u est.
Front End 
Planning 
Directives
ef > 0.1 
< —
^Front End 
Planning 
Directive
D
Front End 
Planning 
Directive
^ Bound 
Front End 
^ Usage
\ f Set Activit^VA Set Activity 
Performance II Importance 
J R eq uirem en t^ Level
(a) Front End Planning Directives, (b) Refined Front End Planning Directive 
Figure 5-5: Data Graphs Representing Properties of Front End Planning Directives
T he d a ta g ra p h in F igure 5-5(a) is a refin em en t of th e front end 
planning directives w hich are th e o u tp u ts from th e sensor manager. T he 
d a ta g rap h specifies th a t the front end planning directives are a sequence of 
front end planning directive. The expression 'ef > 0.1' associated w ith the 
startin g iteratio n p rim itiv e specifies th at th e tim e interval, rep re se n te d by 
th e e x ecu tio n fram e fu n ctio n e f, b etw een tw o in stan ces o f front end 
planning directives is at least 0.1 second. The d ata g rap h in Figure 5-5(b) is 
the refinem ent of the front end planning directive. The d a ta g ra p h in Figure 
5-5(b) specifies th a t a front end planning directive m ay be eith er a bound 
 201_
front end usage directive, a set activity performance requirements d irectiv e, 
or a set activity importance level directive.
Front End 
Requests Manager
ef > 0.1
External
Request
External
Requests
Perform 
Search 
Frame 
Planning 
Activity to 
Divide a SF 
into a 
Sequence of 
Search Alert 
(SA-act) 
activities
Abort
Broadcast 
Abort
Front End
Planning
Directives
Generate 
a Delete 
request
Generate 
Front End 
Planning 
Directives
Generate 
an SA_act 
request
SA act
Figure 5-6: An Activity Graph Representing a Front End Request Manager
F ig u re 5-6 is a refin em en t of th e front end requests manager. This 
refin e m e n t h as a n ite ratin g loop w h ich is b a sed o n th e ite ra tin g loop 
defined in Figure 5-4(a). The su b g rap h w hich starts w ith a selection operator 
a n d en d s w ith th e selection operator) in F ig u re 5-6 is b ased on th e d ata 
g rap h d ep icted in Figure 5-5(b) for front end planning directives an d th a t an 
external request is com prised of eith er a search, a delete track file, o r a d ata
202
item rep resen ted in a front end planning directive, as d ep icted in Figure 5- 
|4(b).
f^Front End ^ S c .r - 2 .1 ^
Directives
r Timing ^
Control 
Command 
V Tables J
v _______ 0 ~ ~ _ _ J
Figure 5-7: A Data Graph Representing Properties of Front End Directives
!
The d ata g rap h depicted in Figure 5-7 specifies th a t every 0.1 second a ;
!
set of firm w are com m ands m u st be p ro d u ced by th e sensor manager. Since :
th e tim in g of th e fro n t end request manager is n o t strictly p erio d ic, a !
I
sep arate com ponent (the front end setup contained in Figure 5-3) is defined j
i
to p ro d u ce th e front end directives..
T he d a ta g ra p h in F ig u re 5-8(a) is a refin e m e n t of th e fro n t end 
req u ests w h ich are th e o u tp u ts from th e fro n t end planner, th e sig n a l 
processing m anager, an d th e data processing manager. T he d a ta g ra p h 
specifies th a t th e front end requests are a sequence of front end request. The 
tim e in te rv a l b e tw ee n tw o in stan ces of front end requests is at least 0.1 
second. The d a ta g ra p h in F igure 5-8(b) specifies th a t a front end request 
consists of a set of search alert activity (SA_act) req u ests, a set of search 
confirm activity (SC_act) requests, and a set of track u p d a te activity (TU_act) 
req u ests, all a rriv in g concurrently w ith each other. F urth erm o re, the total 
n u m b er of concurrent SA _act requests is lim ited b y th e m axim um nu m b er
203
of search fram es, denoted by m ax#fram es. The total n u m b er of concurrent 
SC_act requests is lim ited by the m axim um n u m b er of m onitored processes 
to be o b serv ed , d e n o te d b y m ax#obs. T he to tal n u m b e r of co n cu rren t
i
T U _act re q u e sts is lim ite d b y th e m ax im u m n u m b e r of m o n ito re d 
processes to be tracked, denoted by m ax#tracks.
^ Front 
End 
Request
Front
End
Requests
'[max#frames, 
current #]
[max#obs,
current#]
Tmax# tracks, 
current #]
r Front 
End 
t Request
(a) Refinement of Front End Requests, 0?) Refinement of Front End Request 
Figure 5-8: Data Graphs Representing Front End Requests
Figure 5-9 depicts a refin em en t of the front end planner w hich is a j 
co m p o n en t activity of th e sensor manager illu strated earlier in Figure 5-3. j 
The front end planner consists of tw o loops. The o u ter loop indicates th a t , 
th e tim e interval betw een tw o activations of the front end planner is greater 
th an 0.1 second. D uring each activation, the activities in th e in n er loop are 
th en perform ed.
204
Front End Planner
ef > 0.1
r
 Track 
Database
for each activitj
Front 
End 
Requests
Select a 
Front End 
Request
Front
Abort
Compute 
SA 
Workload 
Parameters
Front
End
Status
Compute 
SC Workloac 
Parameters 
&
Decide 
Waveform 
for SC
Workload
Specificatio
Compute
TU
Workload
Parameters 
&
Decide 
Waveform 
forTU
&
Decide
WaveForm 
for SA
Generate 
Next 
SA act
SA acl
Append 
to Workload 
List
Front End 
Capability & 
Waveform 
yC now ledge Bas^
Figure 5-9: An Activity Representing Front End Planner i
1
i
In each iteratio n of th e in n er loop, a front end request is selected i
i
based on som e selection criteria such as first-in-first-out (FIFO). The selected 
front end request is th en p ro cessed acco rd in g to its type. T he front end 
capability & waveform knowledge base is a local static d a ta stru ctu re w hich 
contains inform ation ab o u t th e p ro p erties of th e fro n t en d h a rd w a re an d
205
firm w are. B ased o n in fo rm atio n in th e k n o w le d g e b ase an d th e state 
inform ation ab o u t m o n ito red processes in th e track database, the types and 
param eters for w aveform s to be g en erated by th e fro n t en d are co m puted 
an d then the w o rk lo ad specification of the fro n t en d is p ro d u ced . N ote th at 
the next instance of a search alert activity req u e st (SA_act) is issu ed here. 
'T his is d u e to the fact th a t a search ex tern al re q u e st c o rre sp o n d s to a 
{sequence of search alert activities a n d each search alert activ ity is an 
: ad ap tiv e activity. Refer to E xam ple 2 in Section 3.3.4. for details of h o w to 
derive a sequence of search alert activities from a search external request.
ef > 0.1
Work
Unit
Processing
Requests
Type-1 ^ 
Work 
Unit j
Type-m
Work
Unit
Work
Unit
J
(a) Refinement of Signal Processing Requests, (b) Refinement of Work Unit 
Figure 5-10: Data Graphs Representing Signal Processing Requests
T he d a ta g ra p h in F igure 5-10(a) is th e refin e m e n t of th e sig n a l 
processing requests w hich are the o u tp u ts from th e sensor manager The 
d a ta g ra p h specifies th a t th e signal processing requests are a sequence of 
signal processing requests The tim e interval b etw een tw o instances of signal 
processing requests is at least 0.1 second. The d a ta g ra p h in Figure 5-10(b) 
specifies th a t th ere are m types of w o rk units a n d th a t each work unit m ay
be one of t y p e l ,..., or type-m . Each type of work unit corresponds to a signal ;
!
processing job g rap h in [Berk et el 89]. Recall th a t in Figure 5-3 the fro n t j
 _________________________________________________________________ 2 0 6 J
end scheduler com ponent activity of th e sensor manager b ro a d c a sts the 
work unit to both the front end setup co m p o n en t activ ity in th e sen so r 
m anager an d the signal processing manager. T he p u rp o se of b ro ad castin g 
th e work unit is to let th e signal processing manager k now th e ty p e of signal 
p ro cessin g re q u ire d for th e u p co m in g collected returns so th a t th e signal
i
iprocessing manager can p re p a re to in itiate the ty p e of so ftw a re tasks 
{required to perfo rm signal p ro cessin g a n d to allocate sufficient am o u n t
storage to hold the upcom ing collected returns.
Signal Processing M anager
Signal 
Processing 
^ R e q u e sts _
c
A bort
Signal
Processing
Requests
M anager
Signal
Processor
Global
Job 
Processing 
^ Status _
Collected
Returns
Track
D atabase
Signal
Processing
SC_act
Job
M anager
Front
End
/* .............N
Job
Job 1 ^
G raphs
v K J
List J
Data 
Processing 
. Requests
Figure 5-11: An Activity Representing Signal Processing Manager j
i
F igure 5-11 dep icts a refin em en t of th e signal processing manager J
l
w hich consists of three com ponent activities, th e signal processing requests 
m anager, th e signal processor global scheduler, and th e signal processing 
job manager, executing concurrently in a pipeline fashion. A t each iteration 
of th e signal processing requests manager, it selects a work unit usin g a FIFO 
policy, in terp rets this work unit, a n d instantiates a job g ra p h based on its 
ty p e [Berk et el 89]. This job graph is then sent to the signal processor global
207
scheduler w h ich w ill, u sin g reso u rce allocation policies such as lo n g est 
distance first (LDF), allocate jobs to each signal processor. A job list is the 
d a ta stru ctu re u sed to hold the jobs allocated to a signal processor. H ence, 
each signal processing job manager receives a job list for it to schedule.
Signal Processing Job Manager
c
c
c
c
Collected
Retains
Job
List
Abort
Signal
Processor
Local
Track 
Database
Signal
Processing
Job
Exec
Data 
Processing 
Requests
SC act
r Signal 
Processing 
^Requests
Job
Processing 
. Status
Figure 5-12: An Activity Representing Signal Processing Job Manager
F ig u re 5-12 d ep icts th e activ ity g ra p h o f a signal processing job 
m anager w hich consists of a signal processor local scheduler an d a sig n a l 
processing job exec, executing concurrently in a pipeline fashion. The signal 
processor local scheduler selects a job fro m th e job list u s in g so m e 
sch ed u lin g policy such as FIFO. T hen, the selected job is disp atch ed to the 
signal processing job exec to be processed based on the p aram eters associated 
w ith the job. W hen th ere is inform ation o b serv ed in th e collected returns, 
th is o b se rv atio n is c o m p a red w ith th e track s in th e track database to 
d e te rm in e d if th e o b serv atio n m ay b e asso ciated w ith a se t of k n o w n 
m o n ito red processes. If th e ob serv atio n can be associated w ith a set of
208
k n o w n m o n ito red processes, a track update data processing request (TU_act) 
is issued; otherw ise, a search confirm front end request (SC_act) is issued.
(a) Refinement of Data Processing Requests, (b) Refinement of D /P Task Request 
Figure 5-13: Data Graphs Representing Data Processing Requests
T he d a ta g ra p h in F igure 5-13(a) is th e refin e m e n t of th e d a ta 
processing requests w hich are the o u tp u ts from the sensor manager and the 
signal processing job exec in the signal processing manager. The d a ta g rap h 
specifies th at th e data processing requests are a sequence of D /P task request, j 
The tim e in terv al b etw een tw o instances of signal processing requests is at 
least 0.1 second. The d ata g rap h in Figure 5-13(b) specifies th a t a D /P task j 
request m ay be either a delete or a T 17.
F ig u re 5-14 d ep icts a refin em en t of th e data processing manager 
w h ich consist of five co m p o n en t activities, th e signal processing requests 
m anager, th e signal processor global scheduler, the signal processing job 
m anager, the delete tracks, a n d th e output tracks, e x e c u tin g c o n cu rren tly , j
i
T he fu n ctio n ality of com ponents of this refin em en t is sim ilar to th a t in I 
Figure 11 except for th e delete tracks an d the output tracks. The delete tracks
Data
Processing
Requests
D /P
Task
Request
f Task 1 f Delete TU ^
V Request y V A J
are trig g e rre d w h e n th e front end requests manager c o m p o n e n t in the
209
sensor manager determ ines th a t a delete track file external request h as been 
received from a command process The output tracks send o u t a copy of th e 
track database to a command process a t a fixed tim e interval( e.g., 1 second).
D ata Processing M anager
Enable
TUJob 
Processing 
^ Status .
Track
D atabase
D ata
Processing
Requests
M anager
D ata
Processor
Global
Scheduler
r D ata 
Processing 
l Requests
O u tput
Tracks
Delete
Tracks
Delete TUJob
M anager
i
i
t
A bort
\ Track |
L _ fE J
r Front ^ 
End 
^R equests j
TU 
Job List
TUJob
G raphs
Figure 5-14: An Activity Representing Data Processing Manager
F igure 5-15 depicts th e activity g ra p h of a TU job manager w hich 
consists of a data processor local scheduler an d a TU job exec, e x e c u tin g
I
concurrently in a pipeline fashion. T he data processor local scheduler selects j 
a job from the job list using som e scheduling policy such as earliest deadline j 
first (EDF). T hen, th e selected job is d isp atch ed to th e TU job job exec to be 
processed based on the param eters associated w ith the job.
210
TU Job Manager
Front End 
Requests
TU 
Job List
Data
Processor
Local
Scheduler
TUJob
TU 
Job EXEC
Abort
Track
Database
^TU Execution^ 
Frame 
Function 
^ValueTable^
Figure 5-15: An Activity Representing TU Job Manager
The TU job exec correlates the observations w ith tracks in the track 
database, u p d ates the associated tracks w ith the n ew ly d eriv ed inform ation, I
i
f
e stim ates th e e rro r covariance, p red ic ts th e ta rg e t p o sitio n at th e next i 
u p d a te , a n d co m p u tes th e n ex t u p d a te tim e. In o rd e r n o t to lose a 
m onitored process and to keep the tracks w ithin the prescribed accuracy, the 
d u ratio n betw een tw o consecutive d ata collections fo r a m onitored process 
m u st be dynam ically c o m p u ted by d eterm in in g th e tim e in terv al d u rin g 
w hich the erro r variances deriv ed in th e K alm an filters grow s to reach the 
m ax im u m allo w ab le trac k in g e rro r variances. F ig u re 5-16 d e p ic ts the 
relationship b etw een th e perform ance requirem ents (w hich are specified as 
'com putational e rro r tolerance) an d tim ing constraints.
p = 0 - i.e. this activity is non-preemptive
O C = 12 - i.e. this activity's importance level is less than the 'confirm after an alert
search’ activity.
tracking
error
variance
maximum
allowable
error
sw
Figure 5-16: Timing Constraints Defined Based on the Growth Trend & Bounds on Error
Variance
B ased o n th e n o tio n th a t th e e rro rs a sso c iated w ith th e sta te 
j in fo rm a tio n of a m o n ito red p ro cess g ro w w ith tim e a n d e rro rs have 
allo w ab le b o u n d , a TU execution frame function value table is form ed. In j 
th e table, each colum n rep resen ts th e tim e d ead lin e for th e track u p d a te j 
fro n t e n d activ ity (TU_act) a n d each ro w re p re se n ts a v ecto r of e rro r j 
covariances associated w ith each state attrib u te defined in the track database,
T he next step is to apply th e design m ethodology (defined in C hapter 
4) to p ro d u ce an initial task g ra p h from th e activity g ra p h o f th e sensor 
subsystem defined in this section.
212
5 .2 . DESIG N SPE C IFIC A T IO N
I ap p lied the first tw o steps of the task g rap h derivation algorithm on 
jthe Sensor Subsystem activity g ra p h d efin ed F igure 5-2 w h ich is straig h t 
fo rw a rd . S te p l p ro d u ces 22 m axim al restric te d activ ity g rap h s. A m ong 
Jthem, 8 m axim al restricted activity g rap h s basically have th e structure, i.e., a j
1 j
J ’fork' activity follow ed by a ’ join’ activity, as show n in Figure 5-17. These 8 i
i !
M axim al restricted activity graphs are listed below w ith the assigned taskid i 
follow ed by th e activity nam e in the original graph.
(1) taskl (Sensor Subsystem), (2) task2 (Sensor Manager),
(3) task3 (Signal Processing Manager), (4) task4 (Data Processing Manager),
(5) taskl 1 (Replicator of Signal Processing Job Managers), (6) taskl 2(Signal Processing 
Manager),
(7) taskl7(Replicator of TU Job Managers), and (8) task20(TU Job Manager).
jom join
(task2. task3, task4)
fork
(task5 task6, task7, task8)
fork
Sensor
Manager
task2
Sensor
Subsystem
taskl
(a) (b)
(a) MRAG of the Sensor Subsystem, (b) MRAG of the Sensor Manager 
Figure 5-17: MRAG s Containing Only Tork* and loin' Activities
213
N ext, I ap p lied th e task mapping rule to this set of g rap h s, and an 
initial task grap h is derived. Figure 5-18 depicts a p a rt of this task graph. (For 
ease of exposition, only a portion of the task g rap h is show n explicitly.)
t a s k 5 < ^
(Front 
End 
Requests 
Manager
External Request
task6 < 3
(Front
(Front 
End 
Scheduler
task8
task3
W taskl
(Front
End (Signal 
Processing 
M a n a g e ^ ^ (Sensor 
Subsystem)
task20 (Data 
Processing 
Manager)
taskl 7 (TUJob
Manager#!)
(Replicator 
of 
TUJob 
M a n a g e * ? ^
^ ]^^ t ask 18
(TUJob 
Manager#2)
' taskl9<^
(Output
Figure 5-18: A Part of the Task Graph for the Sensor Subsystem
214
O bserve th at task l in Figure 5-18 has one optional in p u t p o rt an d one 
o u tp u t port. The optional in p u t p o rt is u sed to receive en d in g m essages or 
signals from its forked tasks (i.e., task2, task3, an d task4). The o u tp u t p o rt is 
lused to send m essages or signals to enable these forked tasks. N o w observe 
task2. It has one m an d ato ry in p u t p o rt and one optional in p u t p o rt, an d one
1
o u tp u t p o rt. T he m an d ato ry in p u t p o rt is u se d to receive the d a ta o u tp u t 
from ta sk l. The optional in p u t p o rt is u sed to receive m essages o r signals 
from its forked tasks (i.e., task5, task6, task7, an d task8 as show n in Figure 5-
|
17(b).) The o u tp u t p o rt of task2 serves th e sam e p u rp o se as that of ta sk l. The 
other six tasks listed above all have sim ilar stru ctu re as task2. Based on this
I
'observation, one m ig h t think th at these 8 tasks can be m erged into 1 task to
i
red u ce the n u m b er of tasks. This is not a b a d idea if the h a rd w are selected
!
h a s single processor. H ow ever, if th e h a rd w a re arc h ite ctu re consists of
I I
heterogeneous m ultiprocessors, then these tasks should n o t be m erged since |
I
they should create the forked tasks on the specific types of processors th at are j
i
specified in resource requirem ents. :
i
I
[Berk et el 89] describes th e h a rd w a re arch itectu re of an existing 1
i
a irb o rn e ra d a r sy ste m in w h ic h a h e te ro g e n e o u s m u ltip ro c e s s o rs j 
architecture is em ployed. Figure 5-19 depicts this architecture. A s sh o w n in 
th e figure, there are three types of processors, i.e., the d a ta processors, the 
signal processors, an d th e signal processor controller. T w o d a ta processors
|can co m m u n icate w ith each o th e r v ia e ith e r th e sh a re d m em o ry or
!
co m m u n icatio n buses. Signal p ro cesso rs are sp ecialized p ro cesso rs for
i
signal processing, they are u n d e r the control of the S /P controller.T he signal
I
p ro ce sso r controller is a general pro cesso r w hich can com m unicate w ith
215
(data processors via a com m unication b u s, a n d it can com m unicate w ith 
J signal processors via either com m unication bus or the sh ared m em ory.
Shared Memory
I I
Data Data
Processor Processor
1
-------- 2 -------
2
Bus to External Device
S/P Controller
h
V
f
3
I
C / 5
tn C / 5
1
1
p m m t 1
J
3
n
" S
3
re
re
$ s
g
• 1
C / i
O
• - t
$
• - I
i — »
N >
Shared Memory
Figure 5-19: An Example Hardware Architecture for Airborne Radar Systems
U sing th e h a rd w are architecture d ep icted in F igure 5-19, th e sensor 
m anager task in itiated th e front end request manager task (task5), th e fro n t 
end planner task (task6), th e front end scheduler task (task7), a n d th e fro n t 
end set up task (task8) on d a ta processors. The signal processing manager
216
in itiates th e signal processing requests manager task (task*?), th e sig n a l 
processor global scheduler task, an d th e replicator of the signal processing 
job manager task on th e S /P controller. S im ilarly, th e data processing 
m anager task initiates th e data processing requests manager task, th e data 
■processor global scheduler task, th e replicator of the TU job manager task, 
|
In th e process of a p p ly in g Step 2 of th e task g ra p h d e riv a tio n 
jalgorithm , several tasks are m o d ified b y ap p ly in g th e tim ing conversion
Jrule. For exam ple, as show n in Figure 5-20, the front end requests manager
l
w as m odified in such a w ay th at a p a ir of iteration vertices w as rem oved, an 
enable signals req u est w as a d d e d , an d a generate a scheduling request 
activity w hich produces a DPRM_act request w ere also added. Th read er can 
co m pare this figure w ith F igure 5-6 w hich contains th e o rig in al activity 
graph.
i
A lso observe th at in Figure 5-20, th e front end requests manager has 
tw o external in p u ts an d 4 external outputs. The tw o in p u ts are consum ed by 
the sam e activity (read external request), an d b o th in p u ts m u st be available
t
to enable th e read external request activity. H ence as show n in Figure 5-21, j 
b o th in p u ts arrive at the sam e m an d ato ry in p u t port. Since each o u tp u t is j
i
p ro d u ced by a d istin c t activity, each o u tp u t is delivered a t a d istin ct o u tp u t J 
port. I
217
Front End 
Requests Manager
[ External 
I Requests
External
Request
Read
External
Perform 
Search 
Frame 
Planning 
Activity to 
Divide a SF 
into a 
Sequence of 
Search 
Alert(SA-ac) 
) activities
Abort
Broadcast 
Abort
ront End 
Planning 
Directives
Generate 
a Delete 
request
Generate 
an SA_act 
request
Front End 
Planning 
Directives
SA act
Generate 
a scheduling 
request
DPRM act
Figure 5-20: Modified MRAG of the Front End Requests Manager
Command
Processes
External
Requests
Task5
(Front End 
Requests 
Manager)
Enable
Signals
> Abort
Front End
riannmg 
' Directives
SA_act
Figure 5-21: The Task Representing the Front End Requests Manager
218
A fter the initial task graph is derived, th e next step is to exam ine all 
th e com m unication p rim itiv es u se d in th e req u ire m e n ts an d d eriv e the 
p reced en ce relatio n s b etw een tasks. D u rin g th is p ro cess, a se t of d a ta 
m anagers m ay be created to m aintain d ata integrity of the sh ared data. O ne 
[may question w hy a d ata m anger should be im plem ented as a task and n o t 
ju st use a critical region. This can be an option of the designer. H ow ever, in 
this design, m y design decision is based o n the assum ption th at th e m em ory
i
u sed by the sh ared d ata m ay n o t be in th e sam e h a rd w are m odule. T here 
w ere 15 data m anagers created d u rin g this process. They are listed below .
(1) Track data base manager, (2) Abort queue manager, (3) Signal processing requests queue 
manager, (3) Data processing requests queue manager, (4) Front end requests queue 
manager, (5) External requests queue manager, (6) Collected returns data manager, (7) 
Front end status handler, (8) Front end planning directives data manager, (9) Front end 
workload list data manager, (10) Job graphs queue manager, (11) Job list data manager, J 
(12) Job status queue manager, (13) TU job graphs queue manager, (14) TU job list data ! 
manager, and (15) TU processing status queue manager.
i
j
T hese 15 d ata m anager all have structure sim ilar to th at of the d ata J 
m anager for the track database as depicted in Figure 5-22. I
Tracks
Track
Database
M anager
suspem
Track
D atabase
Figure 5-22: The Data Manager Created For the Shared Track Database
.219 J
In this chapter, I u sed a non-trivial realistic exam ple to illustrate the 
p ro c e ss o f u s in g m y re q u ire m e n ts a n d d e sig n m e th o d o lo g ie s to 
'sy stem atically d eriv e an in itial d esig n o f a so ftw are arch itectu re. The 
exam ple developm ent has d em onstrated the feasibility of the m ethodology. 
It seem s clear th a t these m eth o d o lo g y can fo rm th e basis fo r n e e d e d 
co m p u ter-aid ed design tool in w hich m a p p in g algorithm s, such as those 
defined in C h ap ter 4, an d design heuristics can be encoded to aid a designer 
to d ev elo p a n d an aly ze so ftw are arc h ite ctu re of larg e-scaled real-tim e 
system s.
i
I have com e to th e e n d o f th e p resen ta tio n of th e resu lts of th is j
|
research. In the next chapter, I present a sum m ary of m y thesis research an d j 
describe m y view s on the m ost prom ising directions for research to p ro v id e j 
the technology req u ired in developing softw are for th e cu rren t an d fu tu re 1 
generation of sem i-hard real-tim e system s. I
6. SUM M ARY A N D FUTURE RESEARCH
In the thesis abstract I listed th e m ajor contributions th a t have been 
m a d e a n d in th e in te rv e n in g c h a p te rs I h a v e la id o u t th e d e ta ile d 
d ev elo p m en t of these results. In this chapter, I w ill briefly sum m arize the 
resu lts th at have been achieved an d also p o in t o u t w h at I see as directions 
for fu tu re research.
6 .1 . SUM M ARY
In su m m a ry , in th is th e sis, I h a v e d e v e lo p e d m e th o d s for 
specification of softw are req u irem en ts and design for sem i-hard real-tim e j
j
control system s. I also p resen t a design m ethodology th at, g iven softw are | 
req u irem en ts specified u sin g this m ethodology, it allow s o n e to derive a i
i
softw are design directly. j
i
The requirem ents specification m ethod defined has A lford's graphic ! 
n o tatio n s as a p o in t of d ep artu re. To rig o ro u sly an d concisely describe ' 
in te ra c tio n s b e tw ee n activities a n d tim in g b e h av io rs, I e x te n d e d th is } 
sp e cifica tio n m e th o d in th ese areas: (i) th e g ra p h ic a l n o ta tio n s for j 
rep resen tin g interactions betw een activities; (ii) the syntax an d sem antics of j 
g rap h ic n o tatio n s; a n d (iii) th e tex tu al n o tatio n s for sp ecify in g tim in g j 
constraints, pre-conditions, an d post-conditions form ulas .
T he classical w orkload m odels an d th e associated n o tatio n s in the 
req u irem en ts specification for real-tim e system s in clu d e only periodic an d 
sporadic activities. This I found to be insufficient to describe m any real-tim e 
system s. I ex te n d ed th e classical w o rk lo ad m odel w ith th e n o tio n of
221
ad ap tiv e activities an d also defined th e n o tio n of tim e in sta n t variables 
w ith w hich tim ing constraints predicates can b e expressed. T im e in sta n t 
variables are: (1) th e arrival tim e (i.e., th e tim e at w hich the req u e st for
i
; execution of an activity), (2) th e ready tim e (i.e., th e tim e before w hich the
'execution of an activity cannot start), (3) th e scheduling d ead lin e (i.e., the
!
tim e by w hich th e execution of an activity m u st start), (4) the com pletion 
d e a d lin e (i.e., th e tim e by w h ich th e e x ec u tio n o f an activ ity m u st 
com plete), (5) th e execution tim e (i.e., th e am o u n t of execution tim e of an 
activity), (6) the sta rtin g tim e (i.e., th e tim e at w hich an activity begins 
execution), an d (7) the com pletion tim e (i.e., the tim e at w hich an activity 
com pletes execution.)
I
In a d d itio n , I defined three tim ing specification functions to allow 
one to relate th e arrival tim e, the read y tim e, the scheduling deadline, and 
th e com pletion deadline. The scheduling w indow (sw ) function defines the 
set of possible values of th e in terv al b etw een a p air of read y tim e an d 
sch ed u lin g deadline. T he read y distance (rd) fu nction defines th e set of 
possible values of th e in terv al betw een a p a ir of arriv al tim e a n d read y 
tim e. The execution fram e (ef) function defines th e set of possible values of 
th e in terv al b etw een a p a ir of rea d y tim e an d com pletion deadline; an 
activity m u st be scheduled and com pleted in each execution fram e interval. 
H ence th e w orkload m odel of system resources can be represented by using 
th e tim e in sta n t variables an d the tim in g specification functions. U nlike 
th e classical w orkload m odel, this specification m eth o d for w orkload m odel j
i
does not assum e th at (i) the w orkload is d ata in dependent, (ii) tim ing can be j
*
222 I
a p rio ri d e te rm in e d , a n d (iii) th e re is n o fee d b ac k lo o p b e tw e e n 
observations an d com putation.
B ased o n th e n o tio n o f tim e in s ta n t v a ria b le s a n d tim in g 
| specification fu nctions, I d efin ed an ap p ro ach to classify th e w o rk lo ad
i
j b e h a v io r of activity. I d e fin e d fo rm u las for an aly sis o f th e reso u rce
i
u tiliz a tio n of an activity a n d tu n in g tim in g specification fu n ctio n s. I I 
classified th e tim in g relatio n sh ip s an d d efin ed a tax o n o m y of activity j 
classes b y re la tin g th e a rriv a l tim e of an ite ra tio n to th e sc h ed u lin g j 
d e a d lin e , th e sta rtin g tim e, th e co m pletion tim e, o r th e co m p letio n
i
deadline of the previous iteration. In m y classification, I identified ad ap tiv e j
I
activities w hich cannot be m odeled by the classical w orkload m odel. I also 
show ed th a t if one forces an adaptive activity to be scheduled as a periodic . 
activity, th e utilization of resources can be excessive for an ad ap tiv e activity, j
an d few er activities can share th e resource. Finally, I d em o n strated ho w a [
j
specification of softw are requirem ents can be system atically d eriv ed from a 
h ig h level system requirem ents using this m ethodology.
F u rth e rm o re , sin ce th e d e s ig n is a n a tu r a l d e riv a tio n of 
requirem ents, requirem ents an d design are th u s linked. I believe th at this 
traceability together w ith different levels of design v alid atio n w ill enable 
softw are designers to identify crucial design errors.
In m y d esig n m ethod ology, a softw are arch itectu re is specified in 
th ree p arts: th e d a ta m odel, the control flow m odel, a n d th e sequential 
p ro g ram m odel. The d a ta m odel is expressed w ith a restricted d a ta g ra p h . 
The control flo w m odel is expressed w ith a task g rap h in w hich each vertex
223
rep resen ts a ru n -tim e entity, i.e., a task or an in p u t/o u tp u t d a ta elem ent, 
a n d each arc re p re se n ts th e d a ta p ro d u c tio n /c o n s u m p tio n re la tio n s 
b etw een tw o co m m u n icatin g entities. T he seq u en tia l program m od el is 
| expressed w ith a restricted activity g ra p h . G raphical notations are used for 
j rep resen tin g (i) relations betw een d ata item s in a d ata m odel, (ii) relations
j
b etw een tw o com m unicating entities an d th e te m p o ra l/sp a tia l parallelism
jof in p u ts /o u tp u ts of each en tity in a control flow m odel, a n d (iii) th e
I
| in te rn al co m p u tatio n al stru c tu re of a seq u en tial p ro g ram m o d el (i.e., a
i
jtask). T extual n o tatio n s are u sed for specifying tim in g constraints, p re-
I
i conditions, and post-conditions. The notations and sem antics of this design
i
! specification m eth o d allow a design to be rep resen ted a t m u ltip le levels of 
abstraction. They are also ideal for m ultiple levels of design valid atio n via 
sim u la tio n .
In addition, I defined a recursive definition for w ell-form ed restricted 
d ata an d activity graphs. The definitions can be the basis for analysis tools to 
check w h e th e r a re stric te d d a ta /a c tiv ity g ra p h is w ell-fo rm ed . T he 
significance of a restricted activity grap h is th at it rep resen ts a sequential 
process an d therefore is naturally associated w ith a task.
A n algorithm for deriving a set of m axim al restricted activity grap h s 
from a g iv en activity g ra p h w as also p re se n te d . N o te th a t th e set of 
m axim al restricted activity g rap h s co rresp o n d s to a m inim al set of tasks 
corresponding to th e given activity graph. T hree theorem s w ere presented 
to p ro v e several im p o rtan t properties of th e p artitio n in g algorithm . First, 
th e com plexity of the algorithm is 0 ( IE I) w here E is th e set of edges in the 
activity graph. Second, th e restricted activity g rap h s p ro d u ced by A lgorithm 
___________________________________________________________ _______________________ 2 2 4 _
1 in C hapter 4 are m axim al restricted activity graph. Finally, the num ber of 
m axim al restricted activity g rap h p ro d u ced is equal to one p lu s th e total 
n u m b er of successors of starting concurrency an d replication vertices in a 
given activity graph.
i
i I, then, presented a set of synthesis rules w hich include an algorithm
{for d eriv in g th e p o rt_ relatio n _ p red icates for all in p u t p o rts an d o u tp u t i 
! j
! p o rts of a task. In addition, I o u tlin ed the steps tak en for d eriv in g a task
g rap h from a given activity graph.
Finally, I presented the requirem ents and design specifications of an 
exam ple avionic rad a r system w hich represents a non-trivial application of 
th e m ethodology in som e detail.
6 .2 . FUTURE W O R K
In the follow ing sections, I briefly discuss topics for fu rth er research
i
w hich are related to m y w ork on the specification an d design of sem i-hard j 
rea l-tim e system s. S everal are concrete, e x p erim en tal projects; o th ers 
req u ire additional theoretical developm ents. J
j
1. Executable Specifications !
j
T his is a n a tu ra l extension to the req u irem en ts specification w o rk j 
began. O ne possible approach is to translate the requirem ents specification | 
into a p ro gram m ing language (such as ADA) since each graphical prim itive 
can be m ap p ed into a p ro gram m ing entity. For exam ple, an atom ic activity 
can be m a p p e d in to a function o r a p rocedure. A ir v ariab les w hich are 
in v o lv e d in th e p re-c o n d itio n fo rm u la an d are n o t sta te v ariab les are
225
considered as the in p u t param eters. All variables w hich are involved in the 
po st-co n d itio n form ula an d are not state variables are considered as the 
o u tp u t p aram eters. T he ty p e stru c tu re of th ese p aram eters can th en be
! deriv ed from th e d ata g rap h associated w ith these variables. F urtherm ore,
!
! since th e activity b o d y w hich describes th e execution b eh av io rs of th e 
j atom ic activity are specified w ith a su b set of th e selected p ro g ram m in g 
language, the activity body becom es the b o d y of th e subprogram unit. As for 
th e n o n -ato m ic activ ities, th ey are m a p p e d to A d a su b p ro g ra m s by 
assig n in g tran sfo rm a tio n ru les to each o p e ra to r p rim itiv e s w ith in th e 
associated activity graph. The successor activity of a sequence operators can 
be in terp reted as a call to a function or a procedures w hich im plem ent this
i
activity. The selection operator is m ap p ed to a case or an if statem ent, an d (
j
th e iteration operator is m ap p ed to a loop construct.
i
The d ata stru ctu res can be deriv ed from th e d ata g rap h since each j 
atom ic d a ta item is alread y defined w ith a ty p e defin itio n of a selected ! 
p ro g ram m in g lan g u ag e an d o p erato r p rim itiv es u sed to co n stru ct non- 
atom ic d ata item s m ay be u sed to m ap the constituent d ata item s in to a 
p a rtic u la r d a ta stru c tu re ex p ressed in to a p ro g ram m in g language. For 
exam ple, a selection p rim itiv e im plies th a t exactly one of the constituent 
d ata item s is available at any particular p o in t in tim e. W hen the d ata item s 
g ro u p ed via th e selection operator rep resen t different states of a device, the 
d a ta item s can be in terp reted as literals of an enum eration type. W hen data 
item s rep resen t alternative form s of data, the v arian t record type construct 
can be an ap p ro p riate A da representation. The inform ation associated w ith 
each d a ta item w o u ld be used to define a field w ith in th e v arian t record.
226
T he n a m e of th e re c o rd d isc rim in a n t w o u ld n e e d to co n fo rm to a 
convention, such as an extension to th e ty p e n am e of the v a ria n t record. 
The discrim inant w o u ld be declared as enum eration type, w ith each literal 
co rresponding to one of th e d ata item s. This w o u ld be p articu larly useful 
because th e d ata item s m ay also a p p ea r as exit co n d itio n s for discrete 
functions an enum eration type.
2. R everse E ngineering
The m aintenance of a com plex real-tim e system is a m ajor problem 
currently. W ith a volum inous am o u n t of code, one can quickly loose sight 
o f th e in te ra c tio n s o f p ro g ra m u n its. A s m e n tio n e d e a rlie r, g ra p h 
p rim itiv e s in m y sp e cifica tio n m e th o d o lo g ie s can b e m a p p e d in to 
p ro gram m ing constructs to generate code. H ow ever, for the large num ber 
of existing system s this is not of direct benefit. It is therefore interesting to 
consider reversing this process by scanning program s a n d constructing the 
task graphs, restricted activity graphs, and data graphs. The g raphs produced 
can th e n be c o m p a re d w ith th e o rig in a l d e sig n to check if th e
im p le m e n ta tio n satisfies th e d e sig n specification a n d /o r b e u se d for
c o n tin u al m ain ten an ce. T his w o u ld also be for p o te n tia lly u se fu l for
reusability of existing designs a n d /o r code.
3. Form al V erification
[Jahanian& M ok86b] u se a d a ta flow m odel for system requirem ents 
specification an d th en tra n sla te th e g rap h m o d el in to R eal-Tim e Logic 
(RTL). T heir ap p ro ach cann ot be directly a p p lied to sem i-h ard real-tim e 
j system d u e to tw o m ajor problem s. First, th e d a ta flow m o d el is n o t
_________________________________ _ 2 2 7 _
sufficient for ex p ressin g req u irem en ts of se m i-h a rd real-tim e softw are. 
Second, real-tim e logic can express the arrival of a n event an d com pletion 
of an activity, b u t it needs to be extended w ith th e n otion of read y tim e, 
s c h e d u lin g d e a d lin e , c o m p le tio n d e a d lin e , im p o rta n c e le v e l, 
preem ptablility, an d variable execution tim e. A ssum ing that the RTL can be 
j e x te n d ed w ith th e n o tio n s afo rem en tio n ed , it is conceivable th a t th e 
! control flow p ro p erties a n d tim ing constraints d efined in a req u irem en ts 
i specification an d a design specification can be tran slated into RTL. If this
; could be accom plished, the form al verification of an activity g rap h a n d a
I
, task graph can be done by using the extended RTL.
I
4. Processors R esource M anagem ent
[M untz& H orow itz] h av e stu d ie d larg e scale sem i-h ard real-tim e !
|
system s w hich req u ire m u ltip le heterogeneous processors to achieve th e j
j
req u ire d p erform ance. In su ch system s, th e h ig h level (m acro) sy stem | 
functions req u ire m ultiple resources and, at a single resource, the w orkload j 
can have a variety of tim ing requirem ents w hich cannot be represented by a J
l
single m odel (i.e. a single ty pe of activity). F urtherm ore, th e load on each 
ty p e of resource m ay be different an d tim e varying. N o single scheduling 
policy perform s w ell for all types of resources (e.g. sensors, processors, and 
m em ory) a n d in all situ atio n s (e.g. lig h t lo a d in g , h eav y lo ad in g , an d 
tran sien t overload).
T h e re fo re , d e sig n in g sc h e d u le rs for su c h a sy stem in v o lv e s 
in te g ratin g m acro- a n d m icro-level w o rk lo ad a n d req u irem en ts. A t th e 
m acro level, th is in v o lv es sc h ed u lin g of activ ities re q u irin g m u ltip le
228— 1
resources, and at the m icro level, it involves scheduling m u ltip le types of 
activities at a single resource. This suggests a m ulti-level decision stru ctu re 
for resource m anagem ent. The issues, w hich m u st be ad d ressed in this type 
jof re s o u rc e m a n a g e m e n t, in c lu d e (i) co n cise a n d c o m p re h e n s iv e 
| rep re se n ta tio n of the w o rk lo ad , (ii) selection of a p p ro p ria te policies for 
i sch ed u lin g w orkload of each type of resource, (iii) in co rp o ratio n of high- 
lev el sy ste m objectives a n d rec o n ciliatio n of th e se o b jectiv es w ith 
contention for lim ited system resources, an d (iv) integration of the use of
i
j m ultiple types of physical resources.
T he p relim in ary results in [M untz& W ang89] sh o w ed th a t th ere are
no op tim al algorithm s for sch ed u lin g a set of in d ep e n d en t a d ap tiv e an d J
!
n o n -p reem p tiv e activities on a single resource. The earliest d ead lin e first | 
(EDF) is th e m ost preferable (the least slack tim e an d th e larg est latency ■
I
factor first algorithm s perform adequately, b u t they incur m ore scheduling ; 
overhead). M uch w o rk is needed to further investigate the schedulability of I 
a set of in d ep en d en t and d ep en d en t adaptive and non-preem ptive activities j 
o n m u lti-reso u rces. O ne altern ativ e su g g ested in [M untz& W ang891 is a 
tw o-level scheduling approach for each type of resource in w hich, at each 
sch ed u lin g p o in t, th e to p level (i.e. level 1) policy is u se d to select the 
'ready' g ro u p w hich currently has the highest priority as com pared to other 
'ready' groups. T hen the low er level (level 2) policy of the selected g ro u p is 
used to select the 'ready' activity in the group. A bove all, it is im perative to 
develop guide-lines for selection of scheduling algorithm s for th e activity
| classes in th e activity taxonom y .
I
I
!
|_________________________________________________________________________________________________229_ _
REFERENCES
Alford85] M. W . A lfo rd . "A G ra p h M o d e l B ased A p p ro a c h to 
Specification." In L ecture N otes in C om puter Science, Vol. 190, D istributed 
System s M ethods and Tools for Specification, C hapter 4, pp.131 - pp.200.
I
[Alford et al. 85] M. W. A lford, J. P. A nsart, G. H om m el, L. L am port, B. 
L iskov, G. P. M ullery, an d F. B. Schneider, "D istributed System ", Vol. 190,
1985.
I
t
[Baer73] J. L. B aer. "A S u rv e y o f S om e T h e o re tic a l A sp e c ts of 
M ultiprocessing." In C om puting Surveys, vol. 5, N o. 1, M arch 1973, 31-80.
I
[Barbacci&W ing86] M. R. Barbacci an d J. M. W ing. "Durra: A Task-level
D escription L anguage." Technical R eport C M U /SE I-86-T R (D T IC -A l78975),
\
S oftw are E n g in eerin g In stitu te , C arnegie M ellon U n iv ersity , D ecem ber,
1986.
Berk et al. 89] J. V. Berk, A. H . M u n tz, a n d P. R. Stevens, "Softw are 
A rchitecture C oncepts for Avionics," IEEE N atio n A erospace and Electronics 
Conference, 23-27 M ay 1989, 88CH2759-9, vol. 4, pp. 1900-1905.
Blackman86] S. S. B lackm an, "M u ltip le-T arg et T racking w ith R ad ar 
A pplications" ARTECH HOUSE, INC., 1986
B usse et al. 81] E. Busse et al., "The d ata acquisition an d m onitoring system 
TOOPSY," IEEE Trans. Nucl. Sri., vol. NS-28, no. 5, pp. 3674-3679, 1981.
Cadre88] C a d re T ec h n o lo g ie s Inc., "T eam w ork: A n In tro d u c tio n " 
V iew graphs, February, 1988
Cerf72] V. G. Cerf. "M ultiprocessors, sem aphores, a n d a g rap h m odel of 
com putation." Ph.D. dissertation, Dep. Eng., U niv. C alifornia, Los A ngeles, 
1972.
2 3 0
[Chen80] P. P. C hen, (ed.) Proc. Intl. C onf. o n th e E n tity-R elationship j 
A p p ro ach to System A nalysis a n d D esign, N o rth H o llan d , A m sterd am , j 
1980.
[C heng& Stankovic88] S. C h e n g a n d J. A. S ta n k o v ic , "S c h e d u lin g 
A lgorithm s for H ard Real-Tim e System s - A Brief Survey," in T utorial H ard
Real-Tim e System s, pp. 150-173, C om puter Society O rder N u m b er 819.
i
i
[DeM arco78] T. D e M arco . " S tru c tu re d A n a ly s is a n d S y ste m 
Specification." Y ourdon Press, N ew York, 1978.
t
i
[Du&Leung88] J. D u an d J.Y.-T. Leung. "M inim izing M ean Flow Tim e w ith 
R elease T im e an d D ead lin e C o n strain ts." In P roceedings of R eal-T im e 
System s Sym posium , pp. 24-32.
E strin et al. 86] G. E strin, R. S. Fenchel, R. R. R azouk, M. K. V ernon.
i
jS A R A (S y ste m A R c h ite cts A p p re n tic s ): M o d e lin g , A n a ly sis, a n d 
S im u la tio n S u p p o rt fo r D esig n o f C o n c u rre n t S ystem s." In IEEE 
T ransactions on Softw are E ngineering, Vol. SE-12, No.2, F ebruary 1986.
[Gane79] C. G ane an d T. Sarson. "S tructured System s A nalysis: Tools an d 
Techniques." Prentice-H all, E nglew ood Cliffs, N . J., 1979.
|Gom aa84] H . G om aa. "A S o ftw a re D esig n M e th o d fo r R eal-T im e 
System s." , In C om m unication of the ACM , Vol. 27, N o. 9, Septem ber 84.
|Hatley84] D. J. H a tle y , "The U se o f S tru c tu re d M e th o d s in th e 
D ev elo p m en t of L arge Softw are-B ased A vionics System s," in A IA A /IE E E 
6th D igital A vionics System s Conference, Baltim ore, MD, D ecem ber, 1984.
Harel86] D. H arel. "Statecharts: A V isual Form alism for C om plex System s."
1 n Science of C om puter Program m ing, 1986.
H arel et al. 87] D. H arel, A. P nueli, J. P. S chm idt, R. Sherm an. "On the 
Form al Sem antics of Statecharts." In Proceedings of LILS 87.
231
[Harel88] D. H arel. "On V isual Form alism s." In C o m m u n icatio n of the 
k c M , Vol. 31, N o.5, M ay 1988.
[Holm et al. 81] A. H o lm e t al., "Real tim e p ro g ra m m in g in a d a ta 
acquisition an d analysis system ," IEEE Trans. N ucl. Sci., vol. NS-28, no. 5, 
pp. 3731-3738,1981.
i
J
[Holt et al. 68] A. W . H olt, H. Saint, R. M. Shapiro, an d S. W arshall, "Final 
re p o rt for the in fo rm atio n system theory project." A p p lied D ata research, 
R om e A ir D evelopm ent C enter, N ew York, 1968.
i
[i-Logix87] "D o c u m e n ta tio n for th e S ta te m a te S ystem " i-L ogix Inc. 
U niversity Place Suite 200, 124 Mt. A u b u rn St., h a rv a rd Square, C am bridge, 
MA. 02138, P rinted June25, 1987.
i
[Jahanian& M ok86a] F. Jah an ian a n d A. K. M ok. "Safety A nalysis of 
T im ing Properties in Real-Tim e system s.", In IEEE T m asactions on Softw are 
Engineering 12(9): 890-904, Septem ber 1986.
Jahanian& M ok86b] F. Jah an ian a n d A. K. M ok. "A G rap h -T h eo retic 
A pproach for T im ing A nalysis in Real Tim e Logic." In IEEE 1986 Real-Tim e 
System s Sym posium , pp.98-108.
i
K arp& M iller66] R. M. K arp an d R. E. M iller. "Properties of a m odel for 
parallel c o m p u ta tio n s: d e te rm in a c y , te rm in a tio n , q u e u in g ." SIAM J. 
A pplied M ath. 14 (Nov. 1966) 1390-1411.
Karp& M iller67] R. M . K arp a n d R. E. M iller. "P arallel p ro g ra m 
sch em ata: a m ath e m a tic a l m o d el for p a ra lle l c o m p u tatio n ." In IEEE 
C o n feren ce R ecord o f th e 8 th A n n u a l S y m p o siu m o n S w itch in g a n d 
k u to m a ta Theory, Oct. 1967, 55-61.
Karp& M iller69] R. M . K a rp a n d R.E. M iller. "P a ra lle l p ro g ra m 
schem ata." J. C om put. Sys. Sci., vol. 3 no. 4., pp. 167-195, M ay 1969.
King et al. 88] D. R. K ing, R. W. Lichota, an d M. F. W ilson, "Executable j 
S p ecificatio n s in R e q u ire m e n ts A nalysis." In te rim R e p o rt, A d v a n ce d |
2 3 2 !
T echnology & R esearch, Softw are E ngineering D ivision, G ro u n d System s 
G roup, H ughes A ircraft Co., N ovem ber 9, 1988.
[Liu&Layland73] C. L. Liu an d J. L ayland, "Scheduling alg o rith m s for 
m u ltip ro g ram m in g in a h ard real-tim e environm ent, " J. ACM , vol.20, no.,
Jan. 1973.
I
l
I
[M arinescu87] D. C. M arinescu, "A p p ro x im ate A nalysis of D istrib u te d 
S em i-H ard R eal-Tim e System s," IEEE T rans, on A utom atic C ontrol, vol. j 
XC-32, no. 12, Decem ber 1987, pp. 1097-1100. I
I M arinescu et e. 84] D. C. M arinescu, F. Busch, H. H ultzsch, J. L ow sky, 
an d M. R ichter, "Extended d ata acquisition support," IEEE Trans. N ucl. Sci., 
vol. NS-31, pp. 914-924,1984.
Mok83] A. K. M ok. "F undam ental D esign P roblem s for th e H a rd Real 
Tim e E nvironm ent." MIT Ph. D. D issertation, C am bridge MA, M ay 1983.
M untz& H orow itz89] A. H. M u n tz an d E. H o ro w itz, "A F ram ew ork for
i
S pecification a n d D esign of S oftw are for A d v a n ce d S ensor System s", 
A ppeared in IEEE 10th Real-Tim e System s Sym posium , D ecem ber 1989.
M untz& W ang89] A. H . M u n tz a n d K. W an g , "W o rk lo a d M o d el :
i i
Specification an d A d ap tiv e S cheduling of S em i-H ard Real-Tim e C ontrols", I 
To A ppear in the 1st International C onference on System s Integration, A pril | 
23-26,1990. j
i
[Myers76] G. J. M yers. "C o m p o site /S tru ctu red D esign." V an N o stra n d ! 
R einhold, 1976. j
j ' i
[Orr77] K. T. O rr. "S tructured System s D evelopm ent." Y ourdon P ress, J 
N ew York, 1977. !
t
Pratt71] T. W. Pratt. "Pair gram m ars, g rap h languages, an d string-to-graph 
tra n sla tio n s." Jo u rn a l of C o m p u te r a n d S ystem Science, p p . 560-595,
] December 1971.
2 3 3
[Pratt83] T. W. P ratt. "Form al specification of so ftw are u sin g H -G rap h 
sem antics." pp314-332, In L ecture N otes in C o m p u ter Science #153: G raph 
G ram m ars an d T heir A pplication to C o m p u ter Science, ed. H. Ehrig, M. 
N agl, and G., Rozenberg, Springer-Verlag(1983).
Schindler87] M ax Schindler, "D esign tools m aster em b e d d ed softw are's 
real-tim e d e m a n d s ," in Electronic Design, Septem ber 17 1987, pp. 65- 66.
[S h a e ta l. 86] Sha, L., Lechoczky, J. P. an d R ajkum ar, R., "Solutions for 
Som e Practical Problem s in P rioritized P reem ptive Scheduling", IEEE Real- 
Tim e System s Sym posium , 1986
S prunt et al. 88] B. S p ru n t, L. Sha, a n d J. P. L ehoczky. "S cheduling 
S poradic an d A p erio d ic E vents in a H a rd Real-Tim e System ." Technical 
Report, SEI, CMU, 1988.
Stim son83] G. W . S tim son. "In tro d u ctio n to A irb o rn e R adar." H u g h es 
A ircraft C om pany El S egundo, California; L ibrary of C ongress catalog card
num ber: 83-83041
!
[Stotts86] P. D. Stotts, Jr. "A H ierarchical G raph M odel of C oncurrent Real- 
Tim e Softw are System s." In TR-1669 of D epartm ent of C o m p u ter Science of 
Jn iv ersity of M aryland, College Park, June 4, 1986.
W ard& M ellor85] P. T. W ard an d S. J. M ellor, "S tructured D evelopm ent 
o r Real-Tim e System s," Vol.1-3, Y ourdon Press, N ew York, 1985
W ard86] P. T. W ard, "The T ransform ation Schema: A n E xtension of the 
D ata Flow D iagram to R epresent C ontrol an d Tim ing," IEEE T ransactions of 
Softw are E ngineering, Vol. SE-12, No. 2, pp. 198-210, Feb. 1986.
Y ourdon& C onstantine78] E. Y ourdon an d L. C onstantine. "Structured 
Design." 2nd. ed. Y ourdon Press, N ew York, 1978.
234