5, september timing requirements for time … transactions onsoftwareengineering, vol. se-9, no. 5,...

14
IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. SE-9, NO. 5, SEPTEMBER 1983 Timing Requirements for Time-Driven Systems Using Augmented Petri Nets JAMES E. COOLAHAN, JR., MEMBER, IEEE, AND NICHOLAS ROUSSOPOULOS Abstract-A methodology for the statement of timing requirements is presented for a class of embedded computer systems. The notion of a "time-driven" system is introduced which is formalized using a Petri net model augmented with timing information. Several subclasses of time-driven systems are defined with increasing levels of complexity. By deriving the conditions under which the Petri net model can be proven to be safe in the presence of time, timing requirements for modules in the system can be obtained. Analytical techniques are developed for proving safeness in the presence of time for the net constructions used in the defined subclasses of time-driven systems. Index Terms-Modeling methodology, performance specifications, Petri nets, real-time systems, timing requirements. I. INTRODUCTION T HE literature dealing with the statement of requirements Ifor computer systems abounds with data-flow-oriented methodologies which permit the statement of functional re- quirements.' Although these are sufficient for many applica- tions in the data processing environment, most embedded systems, which are characterized by' concurrent activities requiring occasional synchronization, demand a statement for the. control aspects of the system. Several techniques have been 'developed to state these control flow properties, but they have generally not addressed the specification of performance requirements such as timing [2], [14]. Recently, however, some more attention has been given to formal meth- ods of specifying timing requirements (3], [4], [161, [18]. The intent of this paper is to outline a methodology for specifying the timing reqiuirements for a class of embedded systems to be called "time-driven" systems. Informally, time- driven systems are here defined as systems wherein the time in which the system and portions of the system execute.their intended functions is critical to "successful" performance, and wherein a master timing mechanism controls the repetitive performance of similar activities at regular intervals. Some types of systems falling into this category are patient-moni- toring systems, process control systems, and scientific data acquisition systems, among others. The approach taken is to use a Petri net, originated in [12] and described in detail by Peterson [10], [11 ], and also by Agerwala [1], to model a time-driven system. The Petri net model is then augmented by attaching an execution time variable to each node in the network representing a process Manuscript received November 2, 1982; revised January 10, 1983. J. E. Coolahan, Jr. is with the Applied Physics Laboratory, Johns Hopkins University, Laurel, MD 20707. N. Roussopoulos is with the Department of Computer Science, University of Maryland, College Park, MD 20742. in the system, a technique originally introduced by Ramchan- dani [15]. Analysis techniques are then used to derive the conditions under which the Petri net model will be safe in the presence of time, from which the timing requirements for the processes in the system are obtained. Several requirements and design methodologies have been developed using modified versions of Petri nets [6]-[9], [17]. Although most of these methodologies indicate that the notion of time may be included as part of a procedure attached to the nodes used to model system processes, the concept is not fully developed. Also, the extensions to Petri nets employed to enhance the general modeling power cause the analytical power to suffer. Analytical work associated with time-extended Petri net models has been,confined to the area of performance evaluation. In [15], Ramchandani 'defined several classes of timed Petri nets and proved their properties analytically. Further work in this area has been done by Ramamoorthy and Ho [13] and by Han [5]. Unfortunately, the restrictions imposed to develop analyzable classes of timed Petri nets make the number of real-world systems which can be modeled relatively small. It is believed that the techniques presented in this paper enable a much larger percentage of embedded systems to be analyzed in order to state their timing requirements. Section II describes the methodology for creating analyzable Petri net models of time-driven systems and defines several subclasses of these systems as a function of increasing analytical complexity. Section III describes proof methods for the net constructions contained in the various subclasses and the sequence of steps required to derive system timing require- ments. Section IV provides some examples of use of the techniques presented. II. METHODOLOGY A. Review of Petri Nets A Petri net is a bipartite directed graph consisting of "place" nodes and "transition" nodes. Places, drawn as circles, are used to represent conditions; transitions, drawn as bars, are used to represent events. The "marking" (m) of a Petri net is a function from the set of places P to the nonnegative inte- gers N, mn: P -*N, that assigns "tokens" to the places of the net. Tokens, drawn as small dots in the circles, are used to define the execution of the Petri net, and their number and position change during execution. Fig. 1 provides a graph representation of a fairly simple Petri net. The marking of a Petri net is changed by the "firing" of 0098-5589/83/0900-0603$01.00 © 1983 IEEE 603

Upload: trankhanh

Post on 13-Mar-2018

216 views

Category:

Documents


2 download

TRANSCRIPT

Page 1: 5, SEPTEMBER Timing Requirements for Time … TRANSACTIONS ONSOFTWAREENGINEERING, VOL. SE-9, NO. 5, SEPTEMBER1983 Timing Requirements for Time-Driven Systems Using Augmented Petri

IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. SE-9, NO. 5, SEPTEMBER 1983

Timing Requirements for Time-Driven SystemsUsing Augmented Petri Nets

JAMES E. COOLAHAN, JR., MEMBER, IEEE, AND NICHOLAS ROUSSOPOULOS

Abstract-A methodology for the statement of timing requirementsis presented for a class of embedded computer systems. The notion ofa "time-driven" system is introduced which is formalized using a Petrinet model augmented with timing information. Several subclasses oftime-driven systems are defined with increasing levels of complexity.By deriving the conditions under which the Petri net model can beproven to be safe in the presence of time, timing requirements formodules in the system can be obtained. Analytical techniques aredeveloped for proving safeness in the presence of time for the netconstructions used in the defined subclasses of time-driven systems.

Index Terms-Modeling methodology, performance specifications,Petri nets, real-time systems, timing requirements.

I. INTRODUCTIONT HE literature dealing with the statement of requirements

Ifor computer systems abounds with data-flow-orientedmethodologies which permit the statement of functional re-quirements.' Although these are sufficient for many applica-tions in the data processing environment, most embeddedsystems, which are characterized by' concurrent activitiesrequiring occasional synchronization, demand a statementfor the. control aspects of the system. Several techniqueshave been 'developed to state these control flow properties,but they have generally not addressed the specification ofperformance requirements such as timing [2], [14]. Recently,however, some more attention has been given to formal meth-ods of specifying timing requirements (3], [4], [161, [18].The intent of this paper is to outline a methodology for

specifying the timing reqiuirements for a class of embeddedsystems to be called "time-driven" systems. Informally, time-driven systems are here defined as systems wherein the timein which the system and portions of the system execute.theirintended functions is critical to "successful" performance, andwherein a master timing mechanism controls the repetitiveperformance of similar activities at regular intervals. Sometypes of systems falling into this category are patient-moni-toring systems, process control systems, and scientific dataacquisition systems, among others.The approach taken is to use a Petri net, originated in [12]

and described in detail by Peterson [10], [11 ], and also byAgerwala [1], to model a time-driven system. The Petri netmodel is then augmented by attaching an execution timevariable to each node in the network representing a process

Manuscript received November 2, 1982; revised January 10, 1983.J. E. Coolahan, Jr. is with the Applied Physics Laboratory, Johns

Hopkins University, Laurel, MD 20707.N. Roussopoulos is with the Department of Computer Science,

University of Maryland, College Park, MD 20742.

in the system, a technique originally introduced by Ramchan-dani [15]. Analysis techniques are then used to derive theconditions under which the Petri net model will be safe in thepresence of time, from which the timing requirements for theprocesses in the system are obtained.

Several requirements and design methodologies have beendeveloped using modified versions of Petri nets [6]-[9],[17]. Although most of these methodologies indicate thatthe notion of time may be included as part of a procedureattached to the nodes used to model system processes, theconcept is not fully developed. Also, the extensions to Petrinets employed to enhance the general modeling power causethe analytical power to suffer. Analytical work associatedwith time-extended Petri net models has been,confined to thearea ofperformance evaluation. In [15], Ramchandani 'definedseveral classes of timed Petri nets and proved their propertiesanalytically. Further work in this area has been done byRamamoorthy and Ho [13] and by Han [5]. Unfortunately,the restrictions imposed to develop analyzable classes of timedPetri nets make the number of real-world systems which canbe modeled relatively small. It is believed that the techniquespresented in this paper enable a much larger percentage ofembedded systems to be analyzed in order to state their timingrequirements.Section II describes the methodology for creating analyzable

Petri net models of time-driven systems and defines severalsubclasses of these systems as a function of increasing analyticalcomplexity. Section III describes proof methods for the netconstructions contained in the various subclasses and thesequence of steps required to derive system timing require-ments. Section IV provides some examples of use of thetechniques presented.

II. METHODOLOGYA. Review ofPetri NetsA Petri net is a bipartite directed graph consisting of "place"

nodes and "transition" nodes. Places, drawn as circles, areused to represent conditions; transitions, drawn as bars, areused to represent events. The "marking" (m) of a Petri netis a function from the set of places P to the nonnegative inte-gers N, mn: P -*N, that assigns "tokens" to the places of thenet. Tokens, drawn as small dots in the circles, are used todefine the execution of the Petri net, and their number andposition change during execution. Fig. 1 provides a graphrepresentation of a fairly simple Petri net.The marking of a Petri net is changed by the "firing" of

0098-5589/83/0900-0603$01.00 © 1983 IEEE

603

Page 2: 5, SEPTEMBER Timing Requirements for Time … TRANSACTIONS ONSOFTWAREENGINEERING, VOL. SE-9, NO. 5, SEPTEMBER1983 Timing Requirements for Time-Driven Systems Using Augmented Petri

IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. SE-9, NO. 5, SEPTEMBER 1983

Fig. 1. A simple marked Petri net.

p5

Fig. 2. The marking after t, fires in Fig. 1.

1t t3Fig. 3. The marking after t3 fires in Fig. 2.

transitions. A transition is "enabled" to fire if and only ifthere is at least one token in each of its input places (i.e.,places from which a directed arc to the transition exists).In the classic definition of Petri nets, the time from the en-

abling of a transition to its firing is indeterminate. Likewiseindeterminate is the order of firing of two or more currentlyenabled transitions. The firing of a transition is an instantane-ous event during which one token is removed from each of

the transition's input places and one token is deposited in eachof its output places. Fig. 2 illustrates the marking resultingfrom the firing of transition t1 in Fig. 1.The removal of tokens from input places as a result of transi-

tion firing has the effect that, if two or more transitions are

currently enabled by the presence of a token at the same inputplace, the firing of any one of those transitions removes thattoken and disables the remaining transitions. These transitionsare said to be "in conflict" and the place causing the conflictrequires a "decision" to be made between multiple outputpaths. Fig. 3 illustrates the disabling of transition t2 by thefiring of transition t3 in Fig. 2.

If, from the initial marking of the Petri net, it can be shownthat any sequence of firings of transitions never results in morethan some finite number k of tokens residing in any place,the net is "k-bounded." If k is equal to one, the net is called"safe."

The foregoing is a brief introduction to the Petri net conceptspertinent to this paper. For a more complete discussion, see

Peterson [11].

B. Time AugmentationBecause of the power of Petri nets in the modeling of con-

trol flow in asynchronous concurrent systems, it seems naturalto use them as a basis for modeling embedded real-time systems.What is needed, however, is an extension to the classic Petrinet definition to incorporate the notion of time."Extended timed Petri nets" have been defined by Ram-

chandani [15] and used by Ramamoorthy and Ho [13] andHan [5] to investigate the performance of computer systems.In this extended model, transitions are used to model pro-cesses, and the firing of a transition becomes an event with aduration equal to the execution time of the process.A similar method is used here, with the exception that places

are used to represent processes. The execution of a process(as well as a simple condition) is modeled by a transition repre-senting the instantaneous start of execution with a directed arcto a place representing the condition of that process being inexecution. A nonnegative execution time Ti is assigned to eachplace pi. A token becomes "ready" to aid in enabling an out-put transition of place Pi only after Ti time units have expiredsince Pi first received the token. This modeling approach hasbeen chosen for two reasons:

1) it preserves the classic Petri net notion of transitions asinstantaneous events, and2) it does not obscure the state of the system (as represented

by the net marking) during the time that a process is in exe-cution.One additional assumption is also used here with respect to

the time of transition firings. If only one transition becomesenabled when a token becomes ready at a place, then thattransition fires immediately. If multiple transitions becomeenabled when the token becomes ready, then one transitionfires immediately and the rest become disabled, with the selec-tion of the transition to fire being indeterminate.

C. The Time-Driven System Model

As stated earlier, a time-driven system is, informally, a sys-tem wherein the time in which the system and portions of thesystem execute their intended functions is critical to successfulperformance, and wherein a master timing mechanism controlsthe repetitive performance of similar activities at regular inter-vals. A formal model of such a system may be constructedusing Petri nets augmented with timing information.The net constructions to be used are best defined in terms of

input and output functions of their transitions and places. LetIt be 'a set-valued transition input function mapping a transitionti to the set of places from which arcs exist to ti. That is,It: T -e P°, where T is the set of net transitions and P is the setof net places. Similarly, let Ot be a set-valued transition outputfunction mapping ti to the set of places to which arcs existfrom ti, Ot: T -+ P'. The input/output functions may be ex-tended to include a similar place input function, Ip: P-* T°,and a place output function, Op: P -+ T'. The cardinality ofthe sets produced by these functions will be denoted by ...The master timing mechanism is modeled by a net construc-

tion that includes a cycle, called the "driving cycle" becauseits execution time drives the execution time of the remainderof the Petri net model. The master timing mechanism consists

604

Page 3: 5, SEPTEMBER Timing Requirements for Time … TRANSACTIONS ONSOFTWAREENGINEERING, VOL. SE-9, NO. 5, SEPTEMBER1983 Timing Requirements for Time-Driven Systems Using Augmented Petri

COOLAHAN AND ROUSSOPOULOS: TIME-DRIVEN SYSTEMS USING PETRI NETS

T1

(a)

T1 T2

~~~t2P1 l )2 t2

(b)Fig. 4. (a) A driving cycle of a time-driven system. (b) The simplest

time-driven system.

of a place p1 (the master timing process) connected by an

elementary loop to a transition t, such that1) the initial marking of P, (ml = 1) reproduces itself with

a fixed execution time (driving cycle time) T1;2) It (t1 ) = {P}1 (i.e., t1 's only input place is p1 );

3) Pti Ot (ti) and lOt (tI)I > I (i.e., P1 is one, but notthe- only, output place of t1 ); and4) Ip (P l ) = Op (P 1 ) = {t1 } (i.e., t1 is pt 's only input and

only output transition).Fig. 4(a) gives a graph representation of a driving cycle

whose timing process has an execution time of T1 time units.Note that the above restrictions placed on the number of inputsand outputs of the place and the transition in the driving cyclehave insured that the execution of this cycle is not affected bythe execution of any other parts of the Petri net model. Notealso that the dynamic result of the driving cycle constructionis the firing of the transition precisely once every T1 timeunits, and that the place Pi in the cycle is obviously safesince it receives a token only by the firing of the transition t1,which removes the token previously present in pBy using the net constructions presented later, the remainder

of the Petri net model of a time-driven system may be formedby adding places and transitions such that:

1) each place has a -fixed positive finite execution time (tomodel a process) or a zero execution time (to model a condi-tion);2) the bipartite nature of the Petri net is preserved (i.e., arcs

from places always go to transitions and arcs from transitionsalways go to places);3) to every place and transition added there exists a directed

path from the transition t1 in the driving cycle; and4) eventually, all paths terminate in transitions representing

outputs from the system.This procedure essentially "roots" the Petri net model in

the driving cycle and thus ensures that the execution frequencyof each process modeled by the Petri net is somehow depen-dent on the firing frequency of the transition in the drivingcycle.A point of interest here is that even the simplest model con-

structed using the previous procedure violates the classic Petrinet notion of safeness. Consider Fig. 4(b), which has beenconstructed by adding a single place and a single system outputtransition to the driving cycle of Fig. 4(a). In the absence oftiming information, the first firing of t, removes a token from

Pt but immediately replaces it and also deposits a token in P2 .Now both t1 and t2 are. enabled simultaneously. Since thefiring order is indeterminate, selecting t1 to fire again placesa second token in P2, thus violating its safeness. However, ifit were known that T1 = 2 and T2 = 1 then t1 could not fireagain for two time units whereas the token at P2 would beready and would fire t2 after only one time unit. This timinginformation permits us to say that p2 is "safe in the presenceof time." It is the derivation of the conditions under whichsafeness under time is achieved (in this case, T2 < T1) whichyields the timing requirements for the system.

D. Relative Firing Frequency ConceptsThe determination of the frequency at which a transition in

the net fires relative to the firing of the transition in the drivingcycle plays an important role in the analysis of the net con-structions. This is so because restrictions imposed by the netconstruction methodology ensure that the relative firing fre-quency is directly related to the interarrival time of consecutivetokens at a place.The two key concepts are the "maximum relative firing

frequency" (MRFF) of the input transition of a place and the"minimum token interarrival time" (MTIAT) of the place itself.These are defined as follows.

1) The MRFF of a transition is the number of times thetransition fires for each firing of the driving cycle transition,assuming that all decisions lying between the driving cycleand the transition are made in favor of the path to the transi-tion. Thus the MRFF is really just a ratio, without units oftime.

2) The MTIAT of a place is the shortest possible time be-tween the arrivals of any two consecutive tokens at the place.The net construction methodology employed herein ensures

that, for each place pi for which conditions for safeness in thepresence of time need to be derived, the following relationshipholds:

MTIAT(pi) = T1 / MRFF(ti)where T1 is the driving cycle execution time and t1 is the inputtransition of pi.

In many cases, the MRFF is found directly from net consis-tency computations as shown in Section III-A. It is only whena decision (multiple-output) place is encountered that additionalinformation or assumptions are required. Decisions may bedivided into two classes: predetermined and data-dependent.For predetermined decisions, it is known during the modelingprocess how often each output path is to be taken, and thedecision as to which path is taken during execution is not basedon data or another uncontrollable parameter. For data-depen-dent decisions, the modeler does not know precisely how ofteneach path will be taken since this decision is dependent on dataor some other dynamic parameter.Predetermined decisions in time-driven systems may be used

to permit a single driving cycle to be the timing basis for severalprocesses operating at different basic timing rates. This isdone by creating for each of the processes an output place ofthe driving cycle transition which is itself a decision placehaving two output transitions. The two output arcs of theplace are labeled with fractions of the form 1/n and (n - 1)/n,

605

Page 4: 5, SEPTEMBER Timing Requirements for Time … TRANSACTIONS ONSOFTWAREENGINEERING, VOL. SE-9, NO. 5, SEPTEMBER1983 Timing Requirements for Time-Driven Systems Using Augmented Petri

IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. SE-9, NO. 5, SEPTEMBER 1983

2 0 (5-sps process)

T 1= °. 1 0

3=0 (2-sps process)

(a)T =0

(Site 1: 4 sps)

(Site 2: 2 sps,.delayed by 0.1 sec)

(b)Fig. 5. (a) A timing mechanism for two processors with different rates.

(b) A two-site system with time offset.

respectively, where n is a positive integer. The intended mean-ing of this construction is that the path labeled 1/n is takenprecisely once out of every n consecutive decisions in a stronglyperiodic fashion. Fig. 5(a) illustrates a 10 sample/s drivingcycle used to time both a 2 sample/s and a 5 sample/s process.It is readily shown that any number of processes with differentbasic rates may be timed using a driving cycle with a firingfrequency equal to the least common multiple of the rates.A similar approach may be used to model distributed time-

driven systems (assuming that an implementation mechanismexists to synchronize their locally maintained time bases).Timing offsets may be modeled by the inclusion of a nonzeroexecution time at one or all of the decision places. Fig. 5(b)illustrates a two-site system with a built-in timing offset.The inclusion of predetermined decisions, of course, affects

the MRFF's of all transitions to which a -path exists from thedecision places. However, it does not require any assumptionsto be made. On the other hand, data-dependent decisionsrequire that some assumption be made as to the frequencywith which each path will be taken. For most time-drivensystems, it will generally be desired to evaluate the systemunder the "worst case" assumption. This requires consideringthe effect on transition firing frequencies when each outputtransition of the data-dependent decision place is assumed tofire at the same frequency as the place's input transition, andgives rise to the MRFF definition. A procedure for determiningthe MRFF's of all transitions in the net is given in Section III-A.

E. Subclasses of Time-Driven Systems1) Overview: The analysis (as opposed to simulation) of

time-driven Petri net models in order to prove safeness in thepresence of time is the major thrust of the remainder of thispaper. The degree of difficulty of this analysis is dependenton the types of net constructions used in the model, andanalysis may not be possible for the most general net con-structions. During the progress of the work on formal proofmethods presented in Section III, four analyzable subclassesof time-dirven systems have been defined thus far. The foursubclasses are of increasing complexity, with each new class

T2 r4

t4 P6 t7Fig. 6. An asynchronous time-driven system.

adding new constructions to the last, and thus increasing boththe number of proof techniques required and the number ofreal systems which may be modeled. The following sectionsdefine the four subclasses and indicate the differences betweeneach. A methodology for forming Petri nets falling into thesesubclasses is also outlined.2) Asynchronous Systems: Asynchronous time-driven sys-

tems may be, defined in terms of the cardinality of the sets ofinputs and outputs of their places and transitions. For eachplace Pi and for each transition t1 (excluding the driving cycletransition t, ) in an asynchronous system,

1) lIp (pi)I = 1Ot(tj)I = 1 and2) 10p(pi).I .

Fig. 6 is an example of an asynchronous system. Note fromthe definition that, except for the driving cycle, it is notpossible to have cycles. This severely limits the modelingpower as does the fact that synchronization cannot be modeled,but it does at least permit the modeling of data-dependentdecisions since places may have multiple output transitions.By virtue of the construction of the net, the MTIAT of eachplace is equal to the execution time of the master timingprocess divided by the MRFF of the place's input transition.Only two types of timing requirements can be generated for

asynchronous systems.1) The execution time of any process represented by a

place cannot exceed the place's MTIAT.2) The cumulative sequential processing time ofany specified

path cannot exceed any separately stated path execution timerequirements. For example, in Fig. 6, the user might simplystate that from the time of any "interrupt" at t1, the resultingsystem output must be received at ts in not more than threetime units. These requirements have been addressed as "pathlatency" requirements in [16]. Their generation requires onlythe summation of the execution times (and, in all but asyn-chronous systems, the delay times) of all places along thepaths between the two transitions. Although they are applicableto all classes of systems and can be incorporated in the meth-odology, they are excluded from the remainder of thisdiscussion.3) Synchronized Systems: Synchronized time-driven sys-

tems permit all of the constructions used in asynchronoussystems, but also permit the use of "synchronized parallelpath constructions" not containing cycles. A synchronizedparallel path construction consists of a set T of transitions anda set P of path places pp. T consists of one initial transitionti, one final transition tf, and a set Tp of zero or more pathtransitions tp. P and Tp each consist of n (2 or more) disjoint

606

Page 5: 5, SEPTEMBER Timing Requirements for Time … TRANSACTIONS ONSOFTWAREENGINEERING, VOL. SE-9, NO. 5, SEPTEMBER1983 Timing Requirements for Time-Driven Systems Using Augmented Petri

COOLAHAN AND ROUSSOPOULOS: TIME-DRIVEN SYSTEMS USING PETRI NETS

p5 t4

Fig. 7. A synchronized time-driven system.

subsets such that Pi U Tpi represents a path from ti to tf. Forthe initial transition ti,

1) It(ti)fnP=q5 and

2) lot(t,) n Pi = n-For the final transition tf,

1) It(tf) C P and 1t[(tf)I= n, and2) Ot(tf) nP=0.

For each of the path transitions tp (if any),1) LJt(tp)fnPil>and2) lOt(t)nlPi> I.

Finally, for each of the path places pp,1) Vp(pp)I = 1 and Ip(pp) C T, and2) 1Op(pp)I = 1 and Op(pp) C T.Fig. 7 is an example of a synchronized system. As the figure

shows, the definition of a synchronized parallel path construc-tion does not prohibit the overlap ofseveral such constructions.Synchronized systems require more analysis to determine con-

ditions for safeness in the presence of time because at a transi-tion with multiple input places, a token will generally have towait at one or more of the places for the last required token tobe ready to enable the transition to fire. For example, in Fig.7, it can be shown that place p4 will not be safe in the presenceof time if the sum of the execution times of places ps and P6exceeds the execution time of the master timing processdivided by the MRFF of transition t3As shown in Section III, the following timing requirement

is derivable for synchronized systems in addition to those forasynchronous systems.For any set of parallel paths emanating from a transition t1

and ending at a transition tf, the sum of the execution timeand the waiting time of a token at the fmal place in any ofthe paths must not exceed the MTIAT of that place. Onceagain, by virtue of the net construction methodology, theMTIAT is the driving cycle execution time divided by theMRFF of the place's input transition.The waiting time at the final place of a path is the difference

between the total path time of that path and the greatest totalpath time. The total path time is the sum of the executiontimes and the waiting times of all places on a path (excludingthe waiting time at the final place). The need to include thewaiting time is made evident by the situation in Fig. 7 shownby the paths beginning at t4 and ending at t7. If the pathfrom t3 to t6 through place p4 takes longer to execute thanthe path through place P6, then the waiting time of a token atP6 must be considered in developing the timing requirementfor the path through that place from t4 to t7

4)' Independent Cycle Systems: Independent cycle systemspermit all of the constructions in synchronized systems, but

also permit cycles to be formed by multiple inputs to transi-tions, provided that all cycles so formed are "independent."The place outside the cycle with one input and one outputwhich provides an input to the cycle will be called the "entryplace."An independent cycle consists of a set T of transitions and

a set P of cyclic path places pp. T consists of a cycle inputtransition ti and a set Tp of zero or more cyclic path transi-tions tp. The union of T and P represents a cyclic path begin-ning and ending at t . For the initial transition ti,

1) JIt(tj)j = 2 and lIt(t,) nPi = 1, and2) IOt(t1)nPj=l.

For each of the cyclic path transitions tp (if any),1) IIt(tp)I = 1 and It(tp) C P, and2) iOt(tp)nPi=l.

For each of the cyclic path places pp,1) lIpI(pp)I= 1 andIp(pp) C T, and2) IOp(pp) = 1 and Op(pp) C T.

The cyclic path place which is an input to ti is marked initiallywith a single "ready" token so that ti will fire immediatelywhen the first token is ready at the entry place.An extended defmition of an independent cycle may be

formed which does not severely complicate the analysis, butwhich permits the intersection of independent cycles to allowtwo independent cycles to have a common input transition orto allow a parallel path construction or another independentcycle to be "embedded" in an independent cycle. To permitthis extension, the above definition is modified to permitIIt(td)j > 2 and JIt(tp)j > 1, provided each additional inputplace is a member of the setP for an intersecting independentcycle and, among all the cycles, there is only one entry placewhich is a member of no cycle's set P.

Fig. 8 is an example of an independent cycle system. Onemotivation for this subclass is to permit the modeling ofcomputations done repetitively with a database which isaltered by each execution. For example, the cycle in Fig. 8which includes places p3, p4, and ps could be used to modela running computation of the standard deviation of the last ninput data values, where p3 cumulates the statistics of the newdata poimt with those of the last (n V 1) data points, p4 com-putes the new standard deviation outputting the results to P6,and p5 removes the nth oldest point's statistics from thecumulation enabling t2 to accept a new input value.In addition to the timing requirements for synchronized

systems, independent cycle systems add the following require-ment, as shown in Section III, to ensure that the entry placeis safe in the presence of time.For any independent cycle, the total cycle execution time

must not exceed the MTIAT of the entry place of the inde-pendent cycle.As before, the net construction methodology will ensure

that the MTIAT is equal to the driving cycle execution timedivided by the MRFF of the entry place's input transition.5) Shared Resource Systems: Shared resource time-driven

systems provide a significant extension to independent cyclesystems, since they allow cycles to overlap in such a way so asto permit the modeling of competition for a shared resource.This is done by the addition of a shared resource construction.A shared resource construction is a set of n (two or more)

607

Page 6: 5, SEPTEMBER Timing Requirements for Time … TRANSACTIONS ONSOFTWAREENGINEERING, VOL. SE-9, NO. 5, SEPTEMBER1983 Timing Requirements for Time-Driven Systems Using Augmented Petri

IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. SE-9, NO. 5, SEPTEMBER 1983

Fig. 8. A time-driven system with an independent cycle.

Fig. 9. A generalized shared resource construction.

otherwise nonintersecting independent cycles (as defined pre-

viously), each of whose input transitions have a common

firing frequency under all conditions, but which have beenmodified by replacing their final places with a common

"shared resource." A shared resource consists of a set T ofzero or more resource path transitions tp and a set P of places.P consists of an initial place Pi, a final place pf (possibly thesame as pi), and zero or more resource path places pp. Forthe initial place Pi,

1) 1IP(Pd)j=n, with one input transition from each ofthe n cycles, and

2) ifpi Pf, IOp(pi)I = 1 and Op(pi) C T.For the final place pf,

1) 1Op(pf)I=n, with each output transition being theinput transition ti of one of the cycles,

2) the initial marking is with one ready token, and3) if pi = pf, IIP (pf)I = 1 and Ip (pf) C T.

For the resource path places pp (if any),1) Ip (pp)1 = 1 and Ip (pp) C T and2) IOOp (pp)I = 1 and Op (pp) C T.

For the resource path transitions tp,1) It(tp)CP, and

2) Ot(tp))CP.A shared resource construction is shown graphically in Fig. 9.As shown in Section III, the net construction itself guarantees

that each place in the shared resource construction is safe even

in the absence of any time information. However, for theplaces which provide entry into the shared resource construc-tion (Pi * ,Pn in Fig. 9), safeness must be guaranteed bythe net timing. A restriction must be imposed on the use ofthe shared resource construction in that the net constructionmethodology must first ensure that the firing frequencies ofthe input transisiton to the entry places (Pej) must all havethe same value under all conditions. Similarly, the methodol-ogy will ensure that the MTIAT (designated Td) is equal tothe driving cycle execution time T, divided by the MRFF

(Feq) for these places. It can then be proven (Section III)that the following additional timing requirement guaranteessafeness in the presence of time for these places.

Let Tej be the execution time of entry place Pej. DefineTck (Tj1) as the sum of the execution times of all places inthe cycle of the shared resource construction which willexecute when place Pek (Pej) provides an input. If Td is theMTIAT of each of the n entry places, then for each place Pejto be safe in the presence of time, we must have

nTej+ ZTCkl< Td-

k=1k # j

The derivation of this formula results from the proof given inSection III-E.

F. Net Construction MethodologyThe construction of an analyzable timed Petri net model of

a time-driven system consists merely of integrating the buildingblocks described in the preceding sections. As a means ofsummarizing the results of these sections, the following pro-cedure for constructing the model is provided.

1) Construct the driving cycle, as described in Section II-C.2) As required by the system being modeled, add output

places to the transition such that each place hasa) a single input arc andb) either zero execution time (for a condition) or a finite

positive execution time (for a process).3) As required, to each place as yet having no outputs, add

one or more of the following net constructions as outputs:a) a single transition with exactly one input arc;b) a complete synchronized parallel path construction

[Section II-E3];c) a transition with multiple inputs which will complete

a synchronized parallel path construction;d) an independent cycle [Section II-E4]; ore) a cycle which forms part of a shared resource con-

struction [Section II-ES], guaranteeing that all entry placeshave input transitions which will fire at the same frequency.4) As required, to each transition as yet having no outputs

(which is not an output transition of the net), add one or moreoutput places, as in step 2).5) Repeat steps 3) and 4) until the system has been com-

pletely modeled.

III. PROOF TECHNIQUES

A. Derivation of the Maximum Relative Firing FrequenciesIn order to derive conditions for the safeness of places in

the presence of time, it is necessary to know the maximumrelative firing frequencies (MRFF's) of all input transitionsto those places. As defined in the previous section, the MRFFof a transition is the number of times that transition fires foreach firing of the transition in the driving cycle, assuming alldecisions at the intervening places are resolved in favor of thepath leading to that transition.Every system modeled by a Petri net is either a consistent

system or an inconsistent system. As defined in [13], a sys-tem is consistent if and only if there exists a nonzero integerassignment to the transitions in its Petri net model such thatat every place, the sum of integers assigned to its input transi-

608

Page 7: 5, SEPTEMBER Timing Requirements for Time … TRANSACTIONS ONSOFTWAREENGINEERING, VOL. SE-9, NO. 5, SEPTEMBER1983 Timing Requirements for Time-Driven Systems Using Augmented Petri

COOLAHAN AND ROUSSOPOULOS: TIME-DRIVEN SYSTEMS USING PETRI NETS

tions equals the sum of integers assigned to its output transi-tions. An inconsistent system either produces an infinitenumber of tokens or consumes tokens and stops. For pur-poses of this analysis, it is desired that all real-world embeddedsystems of interest be able to execute indefinitely, and thusthey are required to be consistent. In practice, the integer as-signed to a transition in a consistent assignment gives a possiblerelative firing frequency for that transition.As shown in [131, the consistency of a system may be in-

vestigated by assigning a variable to each transition and writingan equation for the input-output balance at each place requiredfor a consistent system. If a contradiction is derived whilesolving the set of simultaneous equations, then the system isinconsistent. For the Petri net model of a time-driven system,since the net is rooted in the driving cycle, the firing frequencyof each transition relative to the driving cycle transition caneither be computed exactly or can be bounded. It cannot becomputed exactly for a transition which has a data-dependentdecision place on a path from the driving cycle to the transi-tion, since the percentage of time that each output path willbe taken during execution of the system is not known.For most embedded systems, it is desired that the system

meet its timing requirements in the worst case. For thisreason, the MRFF of each transition is needed. The procedurefor computing the MRFF of all transitions in the net is asfollows.

1) Assign a variable Fi to each transition ti, including thedriving cycle transition.2) For each place Pk in the net, write an equation which

sets the sum of the variables assigned the input transitionsequal to the sum of the variables assigned the output transi-tions. That is,

n m

LFi =EFi

where tieIp(Pk),tjEOp(pk), IIP(pk)I=n,and IOP(Pk)I= m.3) Starting with the places which are outputs of the driving

cycle transition, perform the following.a) If the place has a single output transition, the MRFF

may be found directly by solving that place's equation for theoutput transition's F1 as a function of F1, the driving cyclefiring frequency. This multiple of F1 may be substituted forFj in all succeeding solutions.

b) If the place has multiple outputs, then we have thefollowing.

i) If the place represents a predetermined decision (Sec-tion II-D), then the MRFF of each output transition is foundby multiplying the sum of the MRFF's of the input transitionsby the fraction (R1) labeling the arc to that transition whichgives the percentage of time that the, decision will be made infavor of the transition. That is,

n

F =R1 E Fi.i=l

ii) If the place represents a data-dependent decision, thenthe MRFF of each output transition is just the sum of the

MRFF's of the input transitions:

n

i=1

This procedure results in all net constructions following adata-dependent decision being evaluated in terms of "worstcase" timing requirements.4) As each place is evaluated in steps 2) and 3), its output

transitions are marked as solved. When all output places ofthe driving cycle have been evaluated, the next place to beevaluated is chosen from the set of all places all of whose inputtransitions are marked as solved, but for which at least oneoutput transition is not marked as solved. This process con-tinues until no such places remain.An example of the use of the above procedure may be found

in Section IV.

B. Safeness for Simple PlacesIn an asynchronous system, places may have only one input.

Although they may have multiple output transitions, each ofthese transitions may have only a single input place (the placein question). This implies that a token's becoming ready toenable a transition always causes a transition to fire immediatelywithout any waiting time, thus simplifying analysis. Thesetypes of places are found in all subclasses of time-driven sys-tems. It is desired to be able to derive conditions which insuresafeness in the presence of time for such places which are notinherently safe. A place is inherently safe if it is safe by virtueof the net construction, even in the absence of timing informa-tion, such as places inside the shared resource of Fig. 9. Thisleads to the following definition and theorem.Definition 3.2: A simple place is a place pi, which is not

inherently safe, with JIp(pi)I = 1 and 1Op(pi)l > 1, such thatfor each transition tk O°p (Pi), [It(tk)I = 1.Theorem 3.2: Given a time-driven system with driving cycle

execution time T1, then any simple-place in the Petri net modelof the system with execution time Ti, whose input transitionhas an MRFF of F1, will be safe in the presence of time in theworst case if and only if Ti < T1lFj.

Proof: For reference, consult Fig. 10. In the worst case,by virtue of the net construction methodology, t1 will fireregularly Fi times for each firing ofthe driving cycle transition.Therefore, the time between any two consecutive firings of tiis TllF1. Let m and (m + 1) be any two consecutive tokensarriving at pi by the firing of t1. Place pi will be safe if andonly if token m is removed prior to (or concurrent with) thearrival of token (m + 1). But m will be removed precisely Titime units after its arrival because there can be no waiting ata simple place. If m arrives at some absolute reference timeRm, then (m + 1) will not arrive until Rm + T I/F>. Then piwill be safe if and only if

Rm +TRTiRm + TI/F2or

Ti <TTlF/.

A point to note here is that if the input transition fires atregular intervals (Tj1Fj), then for a single-output place, the

609

Page 8: 5, SEPTEMBER Timing Requirements for Time … TRANSACTIONS ONSOFTWAREENGINEERING, VOL. SE-9, NO. 5, SEPTEMBER1983 Timing Requirements for Time-Driven Systems Using Augmented Petri

IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. SE-9, NO. 5, SEPTEMBER 1983

r ~~~F T.

P1 t, p.

Fig. 10. A simple place.

output transition will fire at the same regular interval. Formultiple-output places, each output transition may fire atirregular intervals, but the intervals are always a multiple ofT1l/F. The worst case (for timing) will be achieved when atransition fires at its MRFF, when it will fire at a regular inter-val of Tl/Fj. Thus, a simple place preserves transition firingregularity in the worst timing (MRFF) case.

C. Safeness for Final Places in Synchronized Parallel PathsFor the final places in synchronized parallel paths, the ques-

tion of safeness in the presence of time becomes more difficultbecause of the potential waiting time of a token at each ofthese places due to slower execution of the other parallel paths.The following definitions and theorem apply to the analysisof these places.Definition 3.3.1: The waiting time (Wi) of a token at place

pi is the elapsed time from the token's becoming ready (Titime units after arrival) and its removal by the firing of an out-put transition.Definition 3.3.2: Given a synchronized parallel path con-

struction beginning at transition ti and ending at transitiontf, the total path time (Pj) for any path j from ti to tf is thesum of Tk and Wk for all places Pk on the path (Pk not thefinal place) and Tf for place pf (the final place on the path).

It is clear from the above definitions that for any two pathsi and / with PJ > Pi, the waiting time at the final place Pif inpath i is just Pi - Pi. In a synchronized parallel path construc-tion, the waiting time at any final place is just the maximumof\these path difference times (or zero for the longest path).To maintain safeness, the sum of Tif and Wif must not begreater than the MTIAT of Pif. The net construction method-ology guarantees that, in the worst case, the initial transition tifires regularly at intervals of T1 /F1. This leads to the statementof the following theorem.Theorem 3.3: For a synchronized parallel path construction

of n paths, the final place pif in each path Pi is safe in the pre-sence of time in the worst case, if and only if, for all pathsj(j=, n),

Pi - Pi < (T, /F,if) - Tifwhere T1 is the driving cycle execution time and Fif is theMRFF of the input transition of Pif.

Proof: For reference, consult Fig. 1 1. From the definitionof a synchronized parallel path construction given in SectionII-D3, each place on a parallel path between the boundingtransitions has only one output. Therefore, there will beexactly one firing of the final transition tf for each firing ofthe initial transition ti. From the construction, it is apparentthat this will occur' only when each of the parallel paths pro-duces a token at its final place which is ready to enable tf.Thus, tokens must wait at each of the final places for a tokento be ready at the final place of the last path to completeexecution.

T ~~~ ~ ~ ~~~~If If

p1 :1flf .

etnE Pnf

Fig. 11. Synchronized parallel paths.

For any path i, since Fif is the MRFF of the input transitionto pif, the time between consecutive firings is, in the worstcase, T1 /Fif. Let m and (m + 1) be any two consecutive tokensarriving at Pif. Place Pif will be safe if and only ifm is removedby the firing of tf prior to (or concurrent with) the arrival of(m + 1). Assume ti fires at some absolute reference time Ri.Then m will arrive at Pif at time

Rm =R + (Pi- Tif)In order to maintain safeness, tf must fire by time

Ri + (Pi - Tif) + T I/Fif.But tf can fire only when each path j has a token ready at itsfinal place, which will occur at time

R1=Ri +Pi.Therefore, for each path j, we must have

Ri +Pi < Ri + (Pi - Tif) + Th/F,f or

Pi - Pi < T1 /Fif - TifNote that for i =j, this reduces to Tif< T, IFif, which is thesame condition derived for simple places.The effect of the above theorem is to require at least n con-

ditions to hold in order to ensure safeness for each final placein a synchronized parallel path construction of n paths. Thisminimum number of conditions is required only when thepath time Pi has a single possible value for each path, whichwill be true only when no transition in the paths is itself thefinal transition of another synchronized parallel path construc-tion. For any such transition terminating m parallel paths, itsinput place on one of the original n paths will have m possiblewaiting time (W1) values. Each of these possible We's must beincluded in a separate safeness condition for Pif since each willresult in a different value of P1.

It should also be noted that the synchronized parallel pathconstruction preserves the regularity of transition firings.Since all place execution and waiting times are constant, thefiring of the final transition (and of all transitions in the con-struction) will always occur at a constant time interval afterthe firing of the initial transition ti. Thus, when ti fires regularlyat intervals of T, /Fi, all other transitions will fire at the sameregular interval.

D. SafenessforEntry Places ofIndependent Cycles

Consider Fig. 12, which shows a generalized independentcycle and the place external to the cycle which provides forentry into it. The entry place and the final place in the cycledeserve particular consideration because tokens at these placesappear able to incur waiting time prior to the firing of ti.

610

Page 9: 5, SEPTEMBER Timing Requirements for Time … TRANSACTIONS ONSOFTWAREENGINEERING, VOL. SE-9, NO. 5, SEPTEMBER1983 Timing Requirements for Time-Driven Systems Using Augmented Petri

COOLAHAN AND ROUSSOPOULOS: TIME-DRIVEN SYSTEMS USING PETRI NETS

T1 F T

C 1 t p te I

Fig. 12. An independent cycle with entry place.

The initial state of the cycle requires that only pf be marked.By the definition of an independent cycle, a token may enterthe cycle only by the firing of ti. But each firing of ti removesa token from pf. Since each place in the cycle that receives atoken as an immediate or subsequent result of the firing of t1must release the token before ti can fire again, all places in thecycle, including pf, are safe even in the absence of timing in-formation. Before stating and proving the conditions underwhich Pe will be safe in the presence of time, the followingpreliminary result is needed.Theorem 3.4.1: The first token to become ready at Pe does

not wait. For all other tokens, in the worst case, the waitingtime is zero if and only if Tc (the time interval from the firingof ti until a token is ready at pf) is less than or equal to T /Fe,where Fe is the MRFF of the input transition of Pe (Note:

Given this, a token wil be ready at pf at Ri, + T,. Also,token (n + 1) will be ready at Pe at R1 + (n)Td + Te. Fromthe above,

if Tc < Td, then RI + (n)Td + Te = Rin + Td

and so R, +((n)Td+Te>Rin+TceThus token (n + 1) will not wait at Pe. However,

if Tc > Td, thenRl + (n)Td + Te <Rin + Td

and so Rl +(n)Td +Te <Rin +Tc.Thus token (n + 1) must wait at Pe. By induction, the theoremholds.Theorem 3.4.2: The entry place Pe to an independent cycle

is safe in the presence of time, in the worst case, if and only if

1) Te< TI/Fe and

2) Tc < Ti /Fe.

Proof. Once again, let Td = T, IFe. In order for ti to fire,a token must be ready at both place Pe and place pf. ByTheorem 3.4.1, ti will fire when Pe becomes ready if Tc < Td,but will fire when pf becomes ready if Tc > Td. This leads tothe following table of firing times:

Arrives PeR1R1 +TdR, +2Td

R1 +(m- l)TdR1 + (m)TdR1 +(m+l)Td

Ready at PeR1 + TeR, + Td + TeR1 + 2Td + Te

RI + (m - 1)Td + TeR1 +(m)Td+TeR1 + (m + l)Td + Te

Results in TokenIf Tc < TdR1 + Te + TcRI +Td+Te+TcR + 2Td +Te+TC

R1 + (m - l)Td + Te + TcR1 + (m)Td + Te + TcR1 + (m + 1)Td + Te + Tc

Ready at pfIf Tc > TdR1 + Te + TcR1 + Te + 2TcR1 + Te + 3Tc

RI +Te+(m)TcR1 + Te + (m + l)TcRI + Te + (m + 2)Tc

Again, in this and the following theorem, the net constructionmethodology ensures that the MTIAT of Pe is Ti /Fe.)

Proof: Because pf is marked initially, it is ready to enableti when the first token becomes ready at Pe, and thus thefirst token need not wait. Now consider the second token tobecome ready at Pe. If the first token arrived at Pe at absolutereference time R1, then ti fired atR + Te and a token is readyat pf at RI + Te + T,. Let Td = Ti /Fe. The second token be-comes ready at Pe at R I + Td + Te. If Tc < Td, then

R1 + Te + Tc SR + Te + Td

and the token will not have to wait. However, if Tc > Td,

R, + Te + Tc >R1 + Te + Td

and the token must wait.Now assume the theorem holds for some token n. That is,

letting Rin be the firing time of ti which removes token n

from Pe, and given that n arrives at Pe at R1 + (n - 1) Td, then

if Tc < Td, thenRl + (n l)Td + Te =Rin

and

if TC> Td, thenR1 + (n - 1)Td + Te <Rin.

Place Pe will be safe in the presence of time for any two con-

secutive tokens (m + 1) and (m + 2) if and only if (m + 1) is

removed before (m + 2) arrives, or from the table,1) Ri + (m)Td + Te <RI + (m + l)Td and

2a) if Tc< Td,R I + (m - I)Td + Te+ TcAR 1 + (m + I )Td or

2b) if Tc > Td,Ri + Te + (m)Tc .Ri + (m + l)Td.

Condition 1) above reduces to

Te < Td

which is precisely condition 1) of the theorem. Condition 2a)above reduces to

Te + Tc<= 2Td

which is directly implied by condition 1) and the preconditionfor 2a). Condition 2b) above reduces to

Te + (m)Tc < (m + l)Td

or

Te 6 (m + l)Td - (m)TT.

Now since Tc > Td, let Td = (a) Tc, where a < 1. Then

Te<(m + l)(a)TC - (m)TC

Token123

mm+ Im + 2

611

Page 10: 5, SEPTEMBER Timing Requirements for Time … TRANSACTIONS ONSOFTWAREENGINEERING, VOL. SE-9, NO. 5, SEPTEMBER1983 Timing Requirements for Time-Driven Systems Using Augmented Petri

IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. SE-9, NO. 5, SEPTEMBER 1983

or

Te<(a-m(l - a))Tc.

Since, for the system to run indefinitely, m can get infinitelylarge, choose

m > a/(l - a).

The right side of the preceding condition thus becomes negative,requiring that the execution time of Pe become negative, whichis clearly impossible. Therefore, if Tc > Td, safeness cannotbe guaranteed for Pe and we must have Tc S Td.Theorems 3.4.1 and 3.4.2 now can be used to prove the fol-

lowing useful result.Theorem 3.4.3: If an entry placepe to an independent cycle

is safe in the presence of time, then the waiting time for alltokens arriving at that place is zero.

Proof. Theorem 3.4.2 guarantees that if Pe is safe thenTc < Td. The first token arriving at Pe does not wait, byTheorem 3.4.1. Since Tc < Td, all subsequent tokens havezero waiting time by that same theorem.The effect of this result is to permit the introduction of

independent cycles along synchronized parallel paths withoutunduly complicating the analysis. The waiting time for aplace on one of these paths which is the entry place to theindependent cycle can be assumed to be zero in the path timecomputation as long as the conditions for safeness given inTheorem 3.4.2 are also stated.As with simple places and synchronized parallel paths, inde-

pendent cycles preserve the regularity of the net timing.Theorem 3.4.3 guarantees that ti will fire exactly Te time unitsafter Pe's input transition. Since all net constructions withinthe cycle itself also preserve the net timing, all transitionswhich provide outputs from the cycle must fire regularly, inthe worst case, at intervals given by T1 divided by theirrespective MRFF's.

E. Safeness for Places in Shared Resource ConstructionsConsider Fig. 13, which shows a generalized shared resource

construction along with the places which provide entry to it.All tokens entering the shared resource construction must doso by means of the firing of one of the transitions til, , tin.Since only pf is marked initially and since all of the transitionstil, * *, tin are in conflict, needing a token at pf to enablethem to fire, every time one of the transitions fires, a token isremoved from pf and a token arrives at one of the placesPil,X Pin - Each place in the construction which receivesa token as an immediate or subsequent result of this firingmust release it before another input transition to the construc-tion can fire. Therefore, all places are safe, even in the absenceof timing information.The safeness for entry places requires more analysis. The

following definition and theorem are required.Definition 3.5: The shared cycle time Tck for the cycle

containing the transition tik in a shared resource constructionis the time interval between the firing of tik and a token be-coming ready at pf.Theorem 3.5: Given that the net construction methodology

guarantees that all entry places have identical MRFF's and

Fig. 13. A shared resource construction with entry places.

that the MTIAT of the entry places is the driving cycle execu-tion time divided by this MRFF, then each entry place Pej to ashared resource construction is safe in the presence of time, inthe worst case, if and only if

n

Tej + E (Tck) TlIlFe + Tcjk=1

where T1 is the driving cycle execution time and Fe is theMRFF of the input transition of all entry places, including Pej.

Proof: Let Td = T, IFe. Now order the n entry places inascending order of the ready times of their tokens and assumea first-ready, first-fired scheduling method. Assume also thatwhenever several tokens become ready simultaneously thatthe scheduler orders transition firings in an arbitrary manner,but that the order is consistent from one set of firings to thenext. The table on page 613 gives times for various tokens atthe entry places and at the final place in the shared resource.With the table as a reference, a place Pej will be safe in the

presence oftime for two consecutive tokens (m + 1) and (m + 2)if and only if

j-l; j-l \ ~n nmax mTd + max (Rq + E Tck), max Rq + E Tck)

q= 1 k=q ,q= 1 k=q

n j-1

+(m- l)max (d ZTck) + Tck)<R -Tejk=i k=1

+ (m + l)Td.

There are several cases to consider. First, Td can be either lessthan, or greater than or equal to, the sum of the n shared cycletimes. The first of these may be shown to be infeasible byarguments similar to those in the previous section, but thesewill not be presented here. There are still two cases to con-sider, depending on whether the flrst or second argument ofthe outermost maximum function of the left side of the in-equality has the greater value.Assume that the first is greater and let q,, be the value of

q which maximizes the maximum function in that argument.Then

j-l

Rq + E Tck <Rp- Tej + Tdk=q

or

i-ITej + E Tck S (Ri - Rq) + Td.

k=q

612

Page 11: 5, SEPTEMBER Timing Requirements for Time … TRANSACTIONS ONSOFTWAREENGINEERING, VOL. SE-9, NO. 5, SEPTEMBER1983 Timing Requirements for Time-Driven Systems Using Augmented Petri

COOLAHAN AND ROUSSOPOULOS: TIME-DRIVEN SYSTEMS USING PETRI NETS

Results in Token Ready at pfat time

1 | 1 | RI - Tel RI RI + TCi

2 R2 -Te2 R2 max(R2 +Tc2, RI + Tcl + TC2)

l/j Rp-Tei max(Rq + £ Tk) Rmn forjnq= 1 k=q

2 1 Rl Tel +Td RI +Td max(Rl + Td + Tcl,Rmn + Tcl)

/ RR - Tej + Td R1+ Td max + max q +k Tck Rmn + l ck)

iln Rn - Ten + Td Rn + Td Rmn + max(Td, Tce =Rmn + Tm

3 1 RI Tel + 2Td Rl + 2Td max(R 1 + 2Td + Tcl, Rmn + Tm)

n Rn Ten + 2Td Rn + 2Td Rmn + 2Tm

maxmTd +Maxq + XTck)Rmn + (M- l)Tm+ Tck)q=1 k=q k=1

Since it is desired not to be required to compute the differencebetween a number of "token-ready" times at all of the entryplaces, consider the conditions which will maximize the valueof the left side while minimizing the value of the right side.Since it is known that Rq < R1 by the case assumption, letRq =R,. It is still possible to have q = 1 and] = n, which willmaximize the left side, yielding

n

Tej + L TCk < Td + Tc,k=1

Although this was derived using j = n, it is applicable to allplaces pej, since the order in which tokens become ready isnot determined beforehand.Now assume that the second argument of the maximum

function is greater than the first, and let qm be the value of qwhich maximizes the maximum function in that argument.Then

n /-i

Rq+ Y3 Tck +(m- l)Td+ T3Tck< R,- Tei+(m+ l)Tdk=q k=1

or

n j-lTei + , Tck + ETC S (Ri Rq+ T.ck q)+2Td.

k=q k=1

st is known that R, + Td > Rq since Fe is the same for all

input transitions to entry places. Then choose Rq = R1 + Td,

which minimizes the right side, and requires j< q. But thisallows1 = 1 and q = 2, which will maximize the left side, yielding

n

Tei + E Tck < Td + Tck=1

Once again, since there is no knowledge of the relative "token-ready" times, the above is applicable to all places Pej. Thetheorem is thus shown to hold in both cases under the worst

case assumptions.Since no outputs are allowed from the shared resource itself

(the common path to all cycles in the construction), theshared resource construction preserves the regularity of thenet timing. Although the firings of net construction inputtransitions may be delayed from the time that tokens becomeready at their entry places, the delays are constant from one

token to the next, so that the interarrival times of tokens atthe first place inside the construction are constant. The con-

struction of the paths prior to the shared resource itself alsopreserves the net timing so that all output transitions fireregularly at an interval given by the driving cycle executiontime divided by the common MRFF of the input transitionsto the entry places.

IV. A COMPREHENSIVE EXAMPLE

In order to illustrate the use ofeach ofthe four net construc-tions and proof techniques, a small process control systemexample will be used. Consider a system whose job it is to

Token iArrivesPei

ReadyPei

m+lI j R - Tel +mTd R,+ mTd

613

Page 12: 5, SEPTEMBER Timing Requirements for Time … TRANSACTIONS ONSOFTWAREENGINEERING, VOL. SE-9, NO. 5, SEPTEMBER1983 Timing Requirements for Time-Driven Systems Using Augmented Petri

IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. SE-9, NO. 5, SEPTEMBER 1983

maintain a laboratory salt water bath for testing oceanographicinstruments at a constant operator-selectable salinity. At aregular interval, the system must sample a temperature sensorand a conductivity sensor using two similar A/D converters.A common sample validity checker is then used which logs thereliability of the two A/D converters and checks for limitingvalues to detect failed sensors. The A/D bit values are thenconverted to temperature and conductivity units, and the twoare combined mathematically to produce a salinity value.' Thisvalue is then averaged over several samples to determine themean and standard deviation. While old data points are removedfrom the cumulation, the new mean and standard deviationare recorded. The mean is then compared to the desired valuejust sampled from the operator's console. If it is within ac-ceptable limits, nothing is done. If the salinity is too low, asmall amount of water is drained from the tank while a salinesolution is injected. If it is too high, a small amount is drainedand fresh water is added.

Fig. 14 is a Petri net model of this time-driven system. Thefunction of the process represented by each place in the Petrinet model is given by the annotation in the figure.The maximum relative firing frequencies are computed as

follows (letting F1 = 1):

at P2: F9 = 1atp3: F2 = 1atp4: F3 = 1

atps: F4=F2=lat P6: Fs =F3 = 1atp7: F5 +F4=F3 +F2 (i.e.,2=2)atp8: F6 =F4 =1atp9: F6 =F5 (i.e., 1 1)atplo: F7 =F6 = 1atp11: F8 =F7 = 1atp12: F8 =F7 (i.e., 1= 1)at P13: F9 = F8 = 1atp14: Flo +F1l +F12 =F9 = 1;

choose F10'= 1, F1 1 = O, F12 = 0 and obtainat p15: F13 =F1o = 1;choose Fl0 0,F11 = 0, Fl2 = 1 and obtainatP16: F14 =F12 =1.

Thus, all transitions have an MRFF of 1.Now apply Theorem 3.5 to all entry places of shared resource

constructions:

T3 +(Ts +T7)+(T6 +T7).T1 +(T5 +T7)orT3 +T6 +T7.T (1)

and

T4 + (T6 + T7) + (T5 + T7) 6 T1 + (T6 + T7)or T4 + T5 + T7 < T1. (2)

Now apply Theorem 3.4.2 to all entry places of independentcycles:

T,o S T,

Til + Tl2 < TI.

P1 Master timing process (p9

7~<1 A/D samplers

Temperature (p)

p4 Y}Conductivity (p4

t2 t3Common validity checker

and reliability monitor

'½ 7 )P6 (P5,p61p7)

4 I5Unit converters

p p Temperature (p8)9_4 8 Conductivity (p9)

to

Salinity comnputation (p1)

10 ! < 2Operator console sampler (p2)

sit7 ,Mean and standard deviationcomputation (p11)

p11 *p12Old data point removal (p12)

\ / > New mean and standard13 deviation recorder (p13)

t9P14 Comparison of mean to

operator selection ( 14)

Xto tli Il10 11 t12Saline solution injector (p15)

P15 P16Fresh water injector (P16)

t t13 ~~~14

Fig. 14. A time-driven system model of a simple process control system.

Now apply Theorem 3.3 to the final places in all synchro-nized parallel paths. 'The following sets of paths must be con-sidered:

a) p3 - t2 - p5 -4 - p8 withp4 - t3 - P6 - t5 - P9b) P2 withp3 - - p- 4- P8 - -Po -P1 - PI l

- - P13c) P2 withp4 - -P6 -S - P9 -t6 - Pio - llP

- - P13-

For a path set a), first consider P8. Ifp3 has a token readybefore p4, then t2 will fire immediately, and the token at p4must wait if it becomes ready before -a new token is ready atp7. Therefore, if T3 < T4 and T4 < T3 + Ts + T7, then

T4 + (T3 + Ts + T7 - T4) + T6 + T9 - (T3 + TS + T8)S'T1 - T8or T6 + T7 + Tg < T1. (5)

However, it is still possible that neither a token at p3 nor atoken atp4 will have to wait. If T3 < T4 and T4 > T3 + Ts +T7, then

T4 + T6 + T9 - (T3 +T5 + T8) < T1 - T8or T4 + T6 +T, - T3 - Ts < T1.

If p4 has a token ready before p3, then t3 will fire immedi-ately, and the token at p3 must wait if it becomes ready beforea new token becomes ready at p7. Therefore, if T4 < T3 andT3 <T4 + T6 + T7,then

(3) T4 + T6 + Tg - (T3 + (T4 + T6 +T1 - T3) + TS + T8)< T, - T8(4) or Tg - T7 - Ts < TI .

614

(6)

Page 13: 5, SEPTEMBER Timing Requirements for Time … TRANSACTIONS ONSOFTWAREENGINEERING, VOL. SE-9, NO. 5, SEPTEMBER1983 Timing Requirements for Time-Driven Systems Using Augmented Petri

COOLAHAN AND ROUSSOPOULOS: TIME-DRIVEN SYSTEMS USING PETRI NEWS

From inequality (5), since all execution times are at leastzero, Tg < T1. Thus the above inequality is implied by (5)and provides no new information. The inequality for the caseT4 S T3 and T3 > T4 + To + T7 is identical to (6).The inequalities for final place pq in path set a) are derived

similarly to those for p8. They are as follows:

Ts +T7 + T8 <T1

T3 + T + T8 T4 T6 a Tl.

(7)(8)

Now consider final place P2 in path set b). If the token atplace P8 does not have to wait, then the total path time isdependent only on whether the token at p3 has to wait. Ifthe token at p3 does not wait, we have

T3 + Ts + T8 + T1o + Til + TI3 < Ti. (9)

Since all execution times are at least zero, we know T3 + T5 +T8 < T1 and inequality (9) implies (8).If the token at p3 waits (T4 S T3 and T3 < T4 + T6 + T7),

we have

T3 +(T4 + T6 + T7 -T3)+ Ts + T8 + Tjo + TI, + TI 3 < T,or T4 +Ts + T6 +T7 +T8 +T10 + TI1 +iT'3 T-1.

(10)

Note that inequality (10) implies (7) and (2).If the token at place P8 waits, there are two cases to consider

depending on whether a token at p4 must wait. Let the pathtime from p3 through P8 (regardless of whether p3 waits) beP38. If a token at p4 does not have to wait,

P38 + (T4 + T6 + To - P38) + T10 + T11 + T13 < T1orT4 + T6 +Tg +T1o + TI1 + T13 .T1. (11)

Note that inequality (11) implies (6).If a token at p4 must wait, then

P38 + (T4 + MT + TS +-T7 - T4) + T6 + Ts P38) + Tjo + T, l+ T13 S T,

or T3 + Ts + T6 + T7 + T + 7T70 + T11 + T13 Tl.(12)

Note that inequality (12) implies (5) and (1).Now consider final place P13 in path set b). The same four

cases apply as for P2. If there is no wait both at P8 and at p3,

T2 - (T3 + T5 + T8 + T1o + T,1 + T13). T, - T13or T2 - T3 - T5 - T8 - T10 - T11 T1 .

Note that the above inequality would be implied by T2 < T1.Since T2 also qualifies as a "simple place," Theorem 3.2 can

be applied to yield

T < T1. (13)

This implies not only the previous inequality, but also theother three which would be generated for P13 using Theorem3.3.For path set c), the analysis proceeds similarly as for path

set b). A cursory review of the net construction and theparallelsim between inequalities (9) and (11) and between(10) and (12) reveals that these will be regenerated.

It now remains to apply Theorem 3.2 to all remaining simpleplaces. Review of the inequalities generated previously shows

that application of the theorem to simple places p3, p4, p5,P6, P8,PoI PI 1 ,P1 2, and P13 will yield no new information.However, the theorem should be applied to P14,IPs, and P16-The following is a summary of the ten timing requirements

for the system:

Ti0 .T1

T3 + Ts + T8 + To + TI + T13 . T1T4 + T6 + T9 + Tio + Tll + T13 . T'

l'4 + T5 + l 6 + T7 + T8 + T10 + T11 + T13 < T,T3 + Ts + T6 + T7 + T9 + Tio + T1l + T13 . Ti

7'2 ._ T1

T15. T1T16 T1 1

V. CONCLUSIONS AND FURTHER WORKThe results presented herein are the product of the early

phases of research on the topic. Although of benefit in itscurrent form, the work could profit from several extensions.First of all, the ability to rejoin paths at the input to a placewhich are a result of a decision at a previous place needs tobe added. This will permit the complete analysis ofalternationconstructions. Secondly, the shared resource constructionneeds to be extended to accept inputs from places whose inputtransitions have different firing frequencies.The inclusion of each of the above extensions will require

reconsideration of the notion of maximum relative firing fre-quency. The assumptions made in this paper of constantdriving cycle execution time and constant process executiontimes have permitted the MRFF and driving cycle time to beused to compute a static token interarrival time at each place.It is this time which was used in performing the proofs inSection III.Permitting process or path execution times to vary will

cause frequent shorter-than-nominal interarrival times. Thissame effect would be experienced downstream of both alter-nation constructions and shared resource constructions withdifferent input firing frequencies. What is needed is a modifiedeffective MRFF representing the shortest interarrival time,which can be merely substituted for the statically derivedMRFF in the expressions resulting from the proofs.

Finally, attempts need to be made to lift some of the restric-tions on the current allowed constructions, and perhaps addnew constructions if attempts at modeling more real systemsreveal this need. In this respect, it is not really desirable toattempt to analyze any general Petri net, since not every netwill model a good, well-designed system.The benefits of using the methodology outlined herein during

the requirements specification phase are twofold.I) Timing requirements may be stated formally and specif-

ically, without the need to assign a time to each processindividually.2) Since the net constructions are well-defined, automated

methods may be used to locate each and generate the timingrequirements.

615

Page 14: 5, SEPTEMBER Timing Requirements for Time … TRANSACTIONS ONSOFTWAREENGINEERING, VOL. SE-9, NO. 5, SEPTEMBER1983 Timing Requirements for Time-Driven Systems Using Augmented Petri

IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. SE-9, NO. 5, SEPTEMBER 1983

In the early system design phase, the methodology is of usein assigning execution time goals for each module since a set ofgoals can be readily tested for feasibility in meeting the systemtiming requirements. Finally, throughout the implementationphase, the methodology can be used to monitor the achieve-ment of the timing requirements. As the actual executiontimes of modules become known, they may be substituted forthe variables in the inequalities to determine that the timingrequirements can still be met and to refine the requirementsfor other uncompleted modules.

REFERENCES[1] T. Agerwala, "Putting Petri nets to work," IEEE Computer, vol.

12, pp. 85-94, Dec. 1979.[2] M. W. Alford, "Software requirements engineering methodology

(SREM) at the age of four," in Proc. COMPSAC 80, IEEE, Oct.1980, pp. 866-873.

[3] T. L. Booth and C. A. Wiecek, "Performance abstract data typesas a tool in software performance analysis and design," IEEETrans. Software Eng., vol. SE-6, pp. 138-151, Mar. 1980.

[4] B. Dasarathy, "Timing constraints for real-time systems: con-structs for expressing them, methods of validating them," inProc. IEEE Real- Time Systems Symp., Dec. 1982.

[5] Y. W. Han, "Performance evaluation of a digital system using aPetri net-like approach," in Proc. Nat. Electron. Conf., vol. 32.Nat. Eng. Consortium, Oct. 1978, pp. 166-172.

[6] L. J. Mekly and S. S. Yau, "Software design representation usingabstract process networks," IEEE Trans. SoftwareEng., vol. SE-6,pp. 420-435, Sept. 1980.

[7] J. D. Noe, "Hierarchical modeling with pro-nets," in Proc. Nat.Electron. Conf, vol. 32. Nat. Eng. Consortium, Oct. 1978,pp. 155-160.

[8] J. D. Noe and G. J. Nutt, "Macro E-nets for representation ofparallel systems," IEEE Trans. Comput., vol. C-22, pp. 718-727,Aug. 1973.

[9] G. J. Nutt, "Evaluation nets for computer systems performanceanalysis," inProc. Fall Joint Comput. Conf., Dec. 1972, pp. 279-286.

[10] J. L. Peterson, "Petri nets," ACM Comput. Surveys, vol. 9, pp.223-252, Sept. 1977.

[11] J. L. Peterson, Peti Net Theory and the Modeling of Systems.Englewood Cliffs, NJ: Prentice-Hall, 1981.

[12] C. A. Petri, "Kommunikation mit Automaten," Ph.D. disserta-tion, Univ. Bonn, Bonn, W. Germany, 1962; translation: C. F.Greene, "Communication with automata," Supplement 1 toTech. Rep. RADC-TR-65-337, vol. 1, Rome Air DevelopmentCenter, Griffiss Air Force Base, NY, 1966.

[13] C. V. Ramamoorthy and G. S. Ho, "Performance evaluation ofasynchronous concurrent systems using Petri nets," IEEE Trans.Software Eng., vol. SE-6, pp. 440-449, Sept. 1980.

[14] C. V. Ramamoorthy and H. H. So, "Software requirements andspecifications: Status and perspectives," in Tutorial: SoftwareMethodology. New York: IEEE Press, 1978, pp. 43-164.

[15] C. Ramchandani, "Analysis of asynchronous concurrent systemsby Petri nets," M.I.T., Cambridge, MA, Project MAC, TR-120,1974.

[16] B. J. Taylor, "Introducing real time constraimts into requirementsand high level design of operating systems," inIEEE Conf. Rec.,Nat. Telecommun. Conf., Dec. 1980, pp. 18.5.1-18.5.5.

[17] W. Trattnig and H. Kerner, "EDDA-A very-high-level program-ming and specification language in the style of SADT," in Proc.COMPSAC 80, IEEE, Oct. 1980, pp. 436-443.

[18] P. Zave, "An operational approach to requirements specificationfor embedded systems," IEEE Trans. Software Eng., vol. SE-8,pp. 250-269, May 1982.

James E. Coolahan, Jr. (M'83) received theB.S. degree in aerospace engineering from theUniversity of Notre Dame, Notre Dame, IN,in. 1971, the M.S. degree in aerospace engi-neering from the Catholic University ofAmerica,Washington, DC, in 1975, and the M.S. degreein computer science from The Johns HopkinsUniversity Evening College, Baltimore, MD, in1980.He is currently a Ph.D. candidate in computer

science at the University of Maryland, CollegePark. Since 1972, he has worked as an Engineer for The Johns HopkinsUniversity Applied Physics Laboratory, Laurel, MD, where he is nowProgram Manager of the Ocean Data Acquisition Program. His researchinterests include real-time computer systems and requirements anddesign specification techniques.Mr. Coolahan is a member of the IEEE Computer Society.

Nicholas Roussopoulos was born in Argos,Greece. He received the B.S. degree in mathe-matics from the University of Athens, Athens,Greece, and the M.Sc. degree and the Ph.D.degree in computer science from the Universityof Toronto, Toronto, Ont., Canada.He worked for IBM Research, San Jose, CA,

and the University of Texas at Austin beforejoining the University of Maryland, CollegePark, where. he is now. His research interestsinclude database design, distributed databases,

software engineering, and artificial intelligence.Dr. Roussopoulos is a member of the Association for Computing

Machinery.

616