Real-Time Syst (2007) 37: 139–179DOI 10.1007/s11241-007-9031-4

Cost enforcement in the real-time specification for Java

Osmar Marchi dos Santos · Andy Wellings

Published online: 12 September 2007© Springer Science+Business Media, LLC 2007

Abstract The Real-Time Specification for Java (RTSJ) provides an integrated ap-proach to scheduling periodic real-time threads and monitoring their CPU execu-tion time. It defines a cost enforcement model whereby a periodic real-time threadis suspended when it consumes more CPU time (budget) than it requested in a sin-gle release. However, compliant implementations need not support this model, as theunderlying operating systems mechanisms are not widely available. Consequently,experience with the model is limited (it is generally not provided in most implemen-tations of the RTSJ). In previous work we showed, using model checking techniques,that the current version of the cost enforcement model can, under certain unlikelyscenarios, allow a periodic thread more than its CPU budget in a single period. Sucha behaviour can undermine any schedulability analysis that has been undertaken.In this paper, we present a revised formal model, which corrects this anomalous be-haviour, and evaluate its properties. We also extend the formal model, so it allowssupport for real-time threads with sporadic and aperiodic releases, and show how ourrevised cost enforcement model is valid for all types of threads.

Keywords Fault-tolerance · Java programming language · Real-time specificationfor Java · Model checking

1 Introduction

The distinguishing characteristic of real-time systems is that their correctness de-pends on producing results within timing constraints (deadlines). However, the days

O.M. dos Santos (�) · A. WellingsComputer Science Department, University of York, York YO 105DD, UKe-mail: osantos@cs.york.ac.uk

A. Wellingse-mail: andy@cs.york.ac.uk

140 Real-Time Syst (2007) 37: 139–179

when real-time simply meant real fast have long gone. Nowadays, the goal is to engi-neer systems whose timing properties are analysable and, therefore, can be predictedbefore execution. Of course, we still want systems to be as efficient as possible, butpredictability and analysability are the overriding concerns during design-time trade-offs.

Over the last thirty years, the significant advances in feasibility (schedulability)analysis techniques mean that real-time systems no longer need to be simple sequen-tial systems but can consist of complex interacting concurrent threads. At the heartof all current feasibility analysis techniques is the requirement for the designer tospecify the resources needed by each thread in order to meet its deadlines. These re-sources include: the amount of CPU time, the network bandwidth, and other logicalsoftware (shared objects) and hardware (I/O devices) services needed. For hard real-time systems, the feasibility analysis assumes that these are the worst-case resourceusages. The argument being that if a system can meet its deadlines when all threadsare requesting their maximum resource usages at the same time, then the system willmeet its deadlines under all possible scenarios. Of course, this is predicated on theworst-case resource usages being accurate and the feasibility analysis being correct.Where the worst-case scenarios are sufficiently rare and the system is infeasible un-der those scenarios, designers might choose to allow a system to become operationaland provide recovery mechanism for when those rare events occur. Typically, this in-cludes monitoring the deadlines of threads and informing the application when thosedeadlines have been missed.

Most real-time systems consist of both hard and soft components, and the goal ofthe system designer is to ensure that no hard real-time components miss their dead-lines. In sequential real-time systems implemented using cyclic executive techniques,a single timing interrupt is often used to initiate the start of a new minor cycle. If thelast minor cycle has not finished execution when this interrupt occurs then the sys-tem has overrun, and recovery must be performed. The timing fault, i.e. the overrunexecution of the cycle, is isolated to the overrunning minor cycle. As we have movedaway from cyclic to concurrent systems, it becomes more difficult to isolate timingfaults and consequently a deadline may be missed (the timing error itself, as a con-sequence of a timing fault) in one thread even though it has behaved according to itsworst-case resource needs. In order to provide better fault containment, it is neces-sary for the run-time environments hosting real-time systems to provide mechanismswhich enable resource usage to be monitored and for overruns to be signalled (andperhaps default actions to be taken).

Traditionally, feasibility analysis for real-time systems use some form of worst-case execution time analysis to determine the amount of CPU time needed byeach thread (called its cost in this paper). In order to achieve better fault contain-ment mechanisms with respect to timing faults, modern real-time languages andoperating systems are beginning to introduce support for monitoring the amountof CPU time a thread consumes (cost monitoring). The main examples includePOSIX’s and Ada 2005’s execution time clocks (POSIX.13 1998; Barnes 2005).However, no system in widespread use fully integrates this monitoring with thescheduling facilities, providing enforcement behaviour upon execution overruns.An exception is the Real-Time Specification for Java (RTSJ) (Bollella et al. 2000;

Real-Time Syst (2007) 37: 139–179 141

Belliardi et al. 2006), the first mainstream real-time programming language that at-tempts to integrate its scheduling with the CPU execution time monitoring facility.Specifically, the RTSJ defines a cost enforcement model, whereby a periodic real-timethread is suspended when it consumes more CPU time (budget) than it requested. Theoverall goal of this mechanism is to ensure that the run-time behaviour of the systemcannot undermine the system feasibility analysis without the explicit intervention ofthe program (Wellings et al. 2004). It also attempts to provide an environment inwhich an errant thread can continue to execute and yet not impact the guaranteedexecution time given to other threads in the system.

Nevertheless, the support for the cost enforcement model is optional, as the re-quired underlying operating system mechanisms (CPU budgets) are not widely avail-able. Consequently cost enforcement is generally not provided by most implementa-tions of the RTSJ. For instance, it is not supported in the Reference Implementation(RI) (Timesys Inc. 2007) or other evolving freely available software (OVM/J Consor-tium 2007; JRate 2007). This means that this aspect of the specification has not beenrigorously evaluated during the Java Specification Request (JSR)1. The result was thatin version 1.0 of the specification (Bollella et al. 2000), a call to the waitForNextPe-riod() method could lead a periodic real-time thread to a deadlock situation. This ledto significant changes in the 1.0.2 version (Belliardi et al. 2006), which removed thedeadlock—although, again, no prototype implementation was explored.

Given the lack of experience with the RTSJ cost monitoring and enforcementmodel in Santos and Wellings (2005) we explored the model using formal meth-ods. As a result of the formal analysis we showed that, under certain circumstances,the cost monitoring and enforcement model can give a periodic real-time thread moreCPU budget than it requested in one single period. Depending on the current state ofthe application, such an anomalous behaviour can potentially undermine the feasibil-ity analysis, because the assumed CPU-resource usage has not been enforced.

The main contributions of this paper are:

1. The definition of a new mechanism for cost monitoring and enforcement in theRTSJ that removes the anomalous behaviour;

2. A formal model of the new cost enforcement model and an evaluation of its cor-rectness;

3. An extension of the formal model, which shows that the new cost enforcementmodel correctly interacts with proposed extensions to the RTSJ (support of real-time threads with aperiodic and sporadic releases).

Our new cost enforcement model is currently being considered by the JSR 282 Ex-pert Group (JSR-282 Expert Group 2006)—which is looking at possible extensionsto the RTSJ.

The remainder of this paper is structured as follows. In the next section we givethe background material necessary for presenting our contributions. We describe thecurrent computational model for real-time threads in the RTSJ, discuss its limitations,present the assumptions upon which our work is based, and illustrate the anomalous

1A formalised process which allows interested parties to be involved in the definition of future versionsand features of the Java platform.

142 Real-Time Syst (2007) 37: 139–179

behaviour that can occur (and which undermines the approach to containing timingfaults). Section 3 introduces our proposed cost enforcement model, whose goal is tocorrect the current anomalous behaviour. Moreover, we develop a formal represen-tation of the proposed model using the Timed Automata (TA) formalism (Alur andDill 1994). In Sect. 4 we formally evaluate the model by model checking using theUPPAAL tool (Larsen et al. 1997). The new model is shown to be coherent and toremove the anomalous behaviour found in the current RTSJ. Section 5 extends theapproach to integrate all types of real-time threads. Section 6 discusses related work.We conclude in Sect. 7, presenting our final comments and future work.

2 Background

In Sect. 2.1 we present the computational model for real-time threads supported in theRTSJ. We discuss in Sect. 2.2 the assumptions about this computational model usedin this work. In our previous work (Santos and Wellings 2005), we used a modellingarchitecture to define a TA model for the cost monitoring mechanism of the RTSJ.Using this model we were able to analyse the mechanism and discover the anomalousbehaviour. In Sect. 2.3 we explain the modelling architecture that we use in this workand discuss, for completeness, the main results achieved in our previous work. Ifthe reader is unfamiliar with the model checking approach and the UPPAAL tool,which are used in this work, please refer to (Clarke et al. 2000; Larsen et al. 1997;Behrmann et al. 2004).

2.1 Real-time threads in the RTSJ

Most real-time systems are either thread-based or event-based. The RTSJ introducesthe notion of a Schedulable Object (SO) (Bollella et al. 2000) to generalise these twoapproaches. As the name implies, a schedulable object is an object that has attributesthat allow a run-time scheduler to perform admission control and dispatching. Theseattributes are captured by a Java interface called the Schedulable interface. An SOis any object that implements this interface. Two types of SOs are defined by thespecification: RealtimeThreads and AsynchronousEventHandlers. In this paper, we aremainly concerned with real-time threads.

One of the attributes that can be associated with a real-time thread2 is itsReleaseParameters. Each thread executes in response to release events. Each release(often called a job in the real-time literature) can be identified by a natural number.Hence, the 0th release is the thread’s execution in response to its initial release event;the ith release is the thread’s execution in response to its ith release event. The termcomplete is used to indicate that the thread has finished the execution associated witha particular release. Consequently, the ith completion event is the event that occurswhen the thread indicates that it has completed the execution associated with the ithrelease event.

2From now on, we will use the term thread to mean a real-time thread. Java threads are supported by theRTSJ but they have regular Java semantics and, consequently, are not covered by the model presented here.

Real-Time Syst (2007) 37: 139–179 143

public void run() {while waitForNextPeriod() {// execute code

}}

Fig. 1 The run() method of a periodic real-time thread

public class RealtimeThread implements Schedulable {...

public void deschedulePeriodic();public void run();public void schedulePeriodic();public void start();

}

Fig. 2 An abridged RealtimeThread class specification

The ReleaseParameters attribute provides information about the estimated CPUconsumption cost per release (budget) and any deadline associated with when a re-lease must be completed. It is also possible to specify an interval for the thread if it isreleased periodically (the period of the thread) or sporadically (the Minimum Inter-arrival Time (MIT) of the thread). Currently, the RTSJ only fully supports periodic(time triggered) threads3. The RealtimeThread class both encapsulates the operationsthat can be applied on a thread and provides the infrastructure that the thread needs toexecute. The full details of the class are not required here; those needed for this paperwill be introduced when necessary. One method that is supported by the class is thewaitForNextPeriod() method (wFNP). The thread calls this method when it wishes tocomplete its current release and wait for the next release event. The code to be exe-cuted in response to each release event is usually encapsulated in the run() method ofthe real-time thread. It typically takes the form illustrated in Fig. 1.

A periodic thread can be descheduled by the program by calling the deschedulePeriodic() method in its associated thread object. When this happens, the thread con-tinues its execution until it completes its current release. It receives no further releaseevents (although they are still generated) until the schedulePeriodic() method is in-voked on its thread object. After this has occurred, the thread is able to receive itsrelease events again. It, however, will not be released until the next release event isgenerated. Figure 2 summarises the important characteristics of the real-time threadclass. The start() method is called to start the first release of the thread.

The behaviour of threads in response to cost overruns and deadline misses can bespecified by the programmer via a combination of mechanisms. The ReleaseParame-ters attribute allows asynchronous event handlers to be associated with these failuremodes. The release of a specific event handler can be defined to occur if the currentCPU consumption becomes equal to, or greater than, the cost. Similarly, a specifiedhandler will be released if a call to wFNP does not occur by the time the real-time

3It does, however, support periodic, sporadic and aperiodic event handlers.

144 Real-Time Syst (2007) 37: 139–179

clock reaches the time of the associated release event plus the deadline. If no handleris specified for a deadline miss, the wFNP method will return false immediately whenit is next called.

Currently, the RTSJ only fully supports periodic (time triggered) real-time threads.If a thread has non-periodic release attributes and it calls wFNP, an exception isthrown. Whilst it might seem strange for the RTSJ to allow this behaviour, the API isdefined to allow a real-time thread to change its release attributes. A major limitationof the current approach is, however, that there is no generalised release mechanismfor threads that would allow sporadic or aperiodic real attributes to have meaning-ful semantics. Such a mechanism has been recently proposed, under the auspices ofthe Java Community Process, by the Expert Group of the RTSJ in (JSR-282 ExpertGroup 2006) and will be described in more details in Sect. 5.

The full semantics of the cost enforcement applied to periodic real-time threads,and its impact on the scheduling of the thread, are much more complex than thesimple release of an event handler, as implied above. To explain them requires moredetailed consideration. Essentially the model is that a thread, which has overrun itscost, is not allowed to execute again until either a new release event occurs (in whichcase it can steal computation time from the next release), or the program increases itscost value. The argument for allowing the thread to steal CPU time from its next re-lease is that most releases do not consume their worst-case CPU time. Consequently,the system may be able to recover and return to a steady state (without underminingthe feasibility analysis). Of course, the thread’s deadline may be missed, but for a softreal-time thread there may still be some value for continuing the execution.

2.1.1 Scheduling and cost enforcement in detail

The RTSJ uses the term cost monitoring to mean the process of tracking the amount ofCPU consumption for a given periodic real-time thread and, when necessary, takingappropriate actions over its behaviour (an enforcement model) upon cost overruns.A thread can have three different execution states (Belliardi et al. 2006): executing(currently using the CPU); blocked (cannot be selected for execution); and eligible-for-execution (can be selected for execution). Once blocked, the state of the thread canbe further specified as: blocked-for-cost-overrun (the associated CPU consumptionfor the thread has exceeded its cost value); blocked-for-release-event (the thread iswaiting for a new release event to occur and to become eligible-for-execution); orsimply blocked (the thread is waiting for an I/O completion or another operation tocomplete).

A release event is a state change request from blocked-for-release-event toeligible-for-execution. For instance, the release event for a periodic thread is the pas-sage of time. If the thread is not in the blocked-for-release-event state and a releaseevent occurs, a pending release is queued. The next time a change to blocked-for-release-event occurs, the thread immediately becomes eligible-for-execution. Whena thread finishes a specific release, it signals a completion for that release—changingits state from executing to blocked-for-release-event.

The scheduler is responsible for managing the execution of threads: performingadmission control, detecting deadline misses and managing the interaction with the

Real-Time Syst (2007) 37: 139–179 145

cost monitoring mechanism. The default scheduler specified in the RTSJ is based onpriorities, called the base scheduler. The semantics of the base scheduler essentiallyassumes an uni-processor execution environment4, and specifies: (i) the range and us-age of priorities for execution eligibility purposes; (ii) the valid and default parametervalues for threads and when changes to these parameters are acted upon; (iii) the be-haviour of specific threads and their interaction with cost monitoring. Currently, thecost monitoring mechanism of the RTSJ only monitors and enforces behaviour uponthreads with periodic releases.

The cost monitoring mechanism, associated with each thread, monitors in phases.When the thread is executing its ith release, and the ith + N release event (whereN > 0) has not occurred, an ith cost monitoring phase will be associated with thisrelease of the thread. The current CPU consumption is the amount of CPU consumedby the periodic thread in the current cost monitoring phase. In certain specific con-ditions, it is possible for the thread not to finish its current release (make a call towFNP) whilst the ith + N release event has already occurred. In this scenario, thethread is allowed to continue executing (although it exhausts the budget for its cur-rent release), because it can steal computation time from the release events that havealready occurred. Therefore, every time the thread finishes the budget for a givenrelease and uses the budget allocated for the next release, the cost monitoring mech-anism starts considering a new cost monitoring phase. When the budget for a givenrelease is exhausted, i.e. the current CPU consumption of the periodic thread beingmonitored becomes equal to, or greater, than the cost, a cost overrun is triggered,possibly generating a handler to deal with the overrun. Moreover, the current CPUconsumption value is reset whenever the cost monitoring mechanism enters a newmonitoring phase.

In Fig. 3 we present the definitions and requirements for the current cost monitor-ing mechanism of the RTSJ. As soon as the periodic thread starts its initial release, thecost monitoring starts to monitor the CPU consumption (a). If a cost overrun occursfor the ith release (b), any associated cost overrun event handler is released. When acost overrun occurs for the ith release, the cost monitoring mechanism must know ifthe ith+1 release event has already occurred (c). Based on this information, differentactions may be triggered by the cost monitoring (c)(1) or (c)(2). On the occurrenceof the ith release event, the periodic thread may have its consumption value reset:becoming eligible-for-execution (d)(1); or having a pending blocked-by-cost-overruncleared (d)(2)(i). Otherwise, no action from the cost monitoring occurs. When thethread completes the ith current release, the consumption value is reset and the costmonitoring enters its ith + N phase (e). The cost value of the periodic thread beingmonitored can be dynamically changed, triggering different actions by the cost mon-itoring (f). Finally, if the cost monitoring has started the mth phase and the periodicthread is in the nth release, where n > m, the state of the cost monitoring can be resetto consider the nth release (g). This can happen in the RTSJ due to threads beingdescheduled and (re)scheduled by the application.

4Although, implementations of the RTSJ are not precluded from supporting multi-processor executionenvironments (Belliardi et al. 2006), the specification does not explicitly address them.

146 Real-Time Syst (2007) 37: 139–179

(a) On initial release: a new cost monitoring phase is started, the CPU consumption is set to zero(and will increase as the thread executes);(b) Cost overrun occurs when the current CPU consumption becomes equal or greater than cost; theoverrun asynchronous event handler, if any, is released;(c) On the occurrence of a cost overrun:

(1) if the most recent release of the thread is the ith release and ((the ith + 1 release event has notyet occurred) or (the ith + N release event has occurred and the ith + N cost monitoring phasehas been started, where N > 0)):(i) if the thread is executing or eligible-for-execution, then it becomes blocked-by-cost-

overrun;(ii) if the thread is blocked for a reason other than blocked-by-cost-overrun, then a pending

blocked-by-cost-overrun is set;(2) else if the ith + N (where N > 0) release event has occurred and the ith + M (where N > M)

cost monitoring phase has not yet started, then the ith +M cost monitoring phase is started andthe CPU consumption is set to zero, and the thread remains in its current state;

(d) On occurrence of the ith release event for a thread:

(1) if the thread is blocked-by-cost-overrun, then the ith cost monitoring phase is started and theCPU consumption is set to zero, the thread is made eligible-for-execution;

(2) if the thread is blocked for a reason other then blocked-by-cost-overrun:(i) if a pending blocked-by-cost-overrun is set, then the pending is cleared, the ith cost mon-

itoring phase is started, the CPU consumption is set to zero, and the thread remains in itscurrent state;

(ii) otherwise, no cost monitoring actions occurs;(3) otherwise, no cost monitoring actions occurs;

(e) On completion of the ith release for a thread: if the ith+N (where N > 0) cost monitoring phasehas not started, it is started and the CPU consumption is set to zero; otherwise no action is taken;(f) On changes to the cost value:

(1) if the new value is lower or equal to consumption and the old value was greater than consump-tion, then a cost overrun occurs;

(2) if the new value is greater than consumption:(i) if the thread is block-by-cost-overrun, then the thread is made eligible-for-execution;

(ii) if the thread is blocked and a pending for blocked-by-cost-overrun is set, then the pendingis cleared;

(iii) otherwise, no cost monitoring actions occurs;

(g) On reset of the cost monitoring: if the current cost monitoring phase is the mth phase and thethread is in the nth release (n > m), then a reset makes the cost monitoring start the nth phase (reset)and current CPU consumption is set to zero.

Fig. 3 Requirements and definitions for cost monitoring (based on Belliardi et al. 2006)

2.2 Computational model assumptions

Because we are mainly concerned with the analysis of the RTSJ, the assumptionsabout the computational model used in our work follows the assumptions used in thedefinitions of the RTSJ. Initially, the computing system is based on an uni-processorarchitecture. We assume that the implementation is capable of multi-threading, i.e.different threads are competing to gain access to the processor. Threads can commu-nicate with each other via shared-memory and can access other (possibly blockable)resources from the system. Furthermore, the thread can suspend itself (e.g. by issuinga call to the sleep() or wait() methods).

Real-Time Syst (2007) 37: 139–179 147

Although the default eligibility criteria used by the scheduler, to allocate a threadto the CPU, in the RTSJ is based on priorities, we abstract the type of scheduler in ouranalysis. This way, we are not required to specify a run-time system for the model.We make our analysis more general, in such a way that if the scheduling criterionis changed (e.g. Earliest Deadline First (EDF) is used instead of priorities), the be-haviour of our model remains valid. This generalisation is consistent with the RTSJ,which defines the cost monitoring as being independent from the type of schedulingmodel used by the system. However, we shall see (in Sect. 3) that although the costmonitoring infrastructure can be independent of the scheduler, the parameters usedby this infrastructure are feasibility analysis dependent. This is not recognised in thecurrent RTSJ definition.

We consider threads that have periodic release parameters (periodic threads) anddeadline values less than or equal to their period values (D ≤ T ). There are threemain reasons for these choices. Firstly, the cost monitoring model of the RTSJ wasproposed for handling periodic threads and, secondly, the scenarios of interest forour analysis can be shown using periodic threads. Therefore, we focus our attentionon the analysis of periodic threads and their interaction with the cost monitoringand enforcement model. Though, in Sect. 5 we relax this constraint and provide amodel for real-time threads with sporadic and aperiodic release parameters. Thirdly,the restriction of having deadlines less than or equal to periods is imposed by mostimplementations of real-time systems found in the literature, also being assumed bythe RTSJ and, therefore, used in this work. However, in Sect. 3 we also relax thisassumption and show how the cost enforcement mechanism, proposed in this paper,can be used in the context of a priority-based scheduler which allows a thread withdeadline greater than its period (D > T ).

We assume that on the occurrence of deadline misses or execution overruns, han-dlers may be released to deal with the potential faulty behaviour. Nevertheless, whensuch handlers are released we are not concerned with their CPU consumption. Thesehandlers are sporadic or aperiodic by nature, and their behaviour is independent fromthe periodic thread that is our main concern. Whilst it is true that they can interactwith the thread (for example, by calling deschedulePeriodic()), this interaction is cap-tured by the modelling architecture with the non-deterministic generation of methods(see next section).

As discussed before, the cost monitoring mechanism defined in the RTSJ is decou-pled from the scheduler and, instead, works together with it via specific interactions.This way, our analysis abstract away from having several threads executing in thesystem, providing only a general component for representing the behaviour of a pe-riodic thread. Nevertheless, we introduce in our model certain characteristics thatallow us to analyse the possible parameter changes that affect both the behaviour ofthe periodic thread and the cost monitoring for that thread.

2.3 Modelling architecture

In Fig. 4 the architecture to specify the cost monitoring and enforcement approachusing the TA formalism of the UPPAAL tool is defined. The basic idea of the ar-chitecture is to decompose the functionalities of both Periodic Real-Time Threads

148 Real-Time Syst (2007) 37: 139–179

Fig. 4 Modelling architecture

(PRTTs) and the Cost Monitoring (CM) into three different levels (each level can bemodelled with more than one automaton):

• Application level: responsible for modelling the interactions of the application thatcan change the behaviour of the PRTT and CM components at the component level;

• Component level: defines the main behaviour of the PRTT and CM componentsbeing modelled. Also specifies the interaction between these two components, i.e.the monitoring and enforcement features;

• Scheduler level: represents the basic functions and interactions of the scheduler,substituting the need to model a real-time kernel. The portion interacting with thePRTT component deals with the generation of release events and monitoring dead-lines. Differently, the portion interacting with the CM component is used to keeptrack of the release events generated for the PRTT component.

It is important to emphasize that the automata defined at the application levelare used to non-deterministically generate inputs to the component level. By non-deterministic inputs we mean inputs that could be generated at different times for dif-ferent execution runs. In particular, the specification of this application level plays animportant role in the architecture. It is responsible for generating non-deterministicinputs to both the PRTT and CM components (through synchronization channels).They also model the interaction with any released event handlers. Therefore, we canexhaustively check all possible execution combinations for these inputs during veri-fication and take full advantage of using model checking as our analysis method.

The modelling architecture following these ideas is shown in Fig. 4. Both PRTTand CM components have a global variable, called rtt_cs and cm_cs, respectively,used to represent the current state of that component. These variables are utilisedin both components and scheduler levels, but are only set at the component level.

Real-Time Syst (2007) 37: 139–179 149

It is used to correctly synchronize the actions inside components and between archi-tecture levels. The interactions represented by arrows in Fig. 4 are specified throughsynchronization channels, whose names are depicted next to each arrow. The chan-nels that are used to synchronize between the two components of the architecture arenamed with a prefix (rtt for PRTT and cm for CM) that indicates the component re-sponsible for triggering the synchronization. Note that, in the modelling architectureof Fig. 4, we are omitting the automata that compose each level of the architectureand the possible synchronization channels used between them.

Next we present the TA model for the PRTT subsystem. The PRTT subsystem iscomposed of the PRTT component and the portion of the application and schedulerlevels that interacts with the PRTT component. This subsystem is important in or-der to understand the behaviour of the TA model for the proposed cost monitoringmechanism (shown in Sect. 3). After that we discuss the anomalous behaviour foundin the formal analysis of the cost monitoring model carried out in our previous work(Santos and Wellings 2005).

2.3.1 The PRTT subsystem

A Periodic Real-Time Thread (PRTT) is a Schedulable Object (SO) that has Periodic-Parameters associated with it. The thread executes in a loop and invokes the methodwaitForNextPeriod() within that loop (as illustrated in Fig. 1). In Fig. 5 the requirementsand definitions for the behaviour of PRTTs are presented. The behaviour of a PRTTacts as if the following variables were added to the thread model and manipulatedaccording to the release characteristics defined in paragraph (a) of Fig. 5: booleandescheduled, integer pendingReleases, integer missCount, and boolean lastReturn.

As presented in Fig. 5, releases are affected by the operations defined in (a). Afterthe execution of the initial release, the next releases are due each period (b). The basicbehaviour of a PRTT is explained in (c). In particular, on the invocation of the sched-ulePeriodic() method (c)(3), the cost monitoring can be reset for the current threadbeing monitored. Depending on the current state of the PRTT, different actions canoccur on each release event (c)(6). On the case of deadline misses, miss handlers canbe released (if available), otherwise a variable is used to count the number of deadlinemisses (c)(7). Finally, the behaviour of the PRTT when a call to the waitForNextPe-riod() method is invoked is shown in (c)(8). This part of the definitions is crucial forthe correct behaviour of a PRTT.

In order to specify the PRTT subsystem we define five automata. First we startdescribing the possible values (constants in the UPPAAL tool) for the current state ofthe PRTT component. These values are set through the global variable rtt_cs and areas follows:

• INIT: the PRTT has not been selected for execution, only used to define an initialstate;

• EXEC: the PRTT is eligible-for-execution or executing. We do not differentiatebetween these states since we are not modelling a run-time system where manythreads may be eligible-for-execution;

• BBCO: the PRTT is blocked-by-cost-overrun;• PBBCO: a pending for blocked-by-cost-overrun has been set;

150 Real-Time Syst (2007) 37: 139–179

(a) Release characteristics are defined by the: invocation of the start() method; invocation of thewaitForNextPeriod(), schedulePeriodic(), and deschedulePeriodic() methods; occurrence of deadlinemisses and whether or not a miss handler is available; generation of periodic releases due to the passageof time;(b) Subsequent release events occur as each period falls due (except as described in (c)(5)): if theith release event occurred at a time ti , then the ith + 1 release event occurs at time ti + Ti , where Ti isthe value of the period specified by PeriodicParameters;(c) The behaviour of a real-time thread is defined as below:

(1) initially descheduled is false, pendingReleases is 0, missCount is 0, and lastReturn is true;(2) when the method deschedulePeriodic() is invoked: descheduled is set to true;(3) when the method schedulePeriodic() is invoked: descheduled is set to false. If the thread is

blocked-for-release-event: pendingReleases is set to 0 and cost monitoring is reset for thisthread;

(4) when descheduled is true, the thread is said to be descheduled;(5) if the thread is descheduled and blocked-for-release-event, no release events can be received, i.e.

no deadline misses can occur, until a call to the method schedulePeriodic(). The deschedulingof a thread has no effect on its initial release;

(6) When each period is due:(i) if the thread is blocked-for-release-event and descheduled: no action is taken; else pend-

ingReleases is incremented, cost monitoring is informed that the next release event hasoccurred, and the thread is made eligible for execution;

(ii) otherwise, pendingReleases is incremented, and cost monitoring is informed that the nextrelease event has occurred;

(7) On each deadline miss:(i) if thread has a deadline miss handler: deschedule is set to true, the handler is released with

its fireCount increased by missCount+1, and missCount is set to 0;(ii) otherwise, missCount is incremented;

(8) When the method waitForNextPeriod() is executed:(i) if missCount is greater than 0, missCount is decremented, then if lastReturn is false:

any pending parameter changes are performed, pendingReleases is decremented, cost-monitoring is informed that thread has completed and false is returned; else: lastReturnis set to false and false is returned;

(ii) otherwise, any pending parameter changes are performed, cost-monitoring is informed thatthread has completed and the thread waits while descheduled is false or pendingReleases is0. After that, lastReturn is set to true, pendingReleases is decremented, and true is returned.

Fig. 5 Requirements and definitions for PRTTs (based on Belliardi et al. 2006)

• BFRE: the PRTT is blocked-for-release-event;• BFS: the PRTT is blocked-for-schedule-periodic. This represents a state where

the PRTT is blocked-for-release-event and also descheduled, waiting for a call toschedulePeriodic() to become scheduled again;

• BLK: the PRTT is blocked for some other event.

• Automata for the PRTT subsystem at the application level: Specify the meth-ods that can affect the behaviour of the PRTT. In Fig. 6(a) we present the automatonPRTT_SD (PRTT Schedule/Deschedule) representing calls (channels synchroniza-tions) to schedulePeriodic() (sp!) and deschedulePeriodic() (dp!) methods. Figure 6(b)shows the automaton PRTT_wFNP (PRTT waitForNextPeriod) representing calls tothe waitForNextPeriod() method (wfnp!).

• Automata for the PRTT subsystem at the component level: Specify the in-terface between the schedule/deschedule calls at the application level and the PRTT

Real-Time Syst (2007) 37: 139–179 151

Fig. 6 (a) PRTT_SD and(b) PRTT_wFNP automata

component. Also, it defines the behaviour of the PRTT component. The interfaceis represented by the automaton PRTT_SDI (PRTT Schedule/Deschedule Interface)depicted in Fig. 7(a). This automaton has two main transitions that are activated, re-spectively, by the schedule (sp?) and deschedule (dp?) of the PRTT triggered fromthe application level. Depending on the current state of the PRTT component (vari-able rtt_cs), it may trigger different actions in the PRTT_Main automaton, setting thevariable d to true (when PRTT is descheduled) or false (when PRTT is scheduled).

Figure 7(b) shows the automaton PRTT_Main, describing the main behaviour ofthe PRTT component. The automaton is started by a new release event (execute?).When executing, an overrun can occur (cm_overrun?) or it can non-deterministicallychange to the blocked state, informing the cost monitoring (rtt_block!). Once in theblocked state, a PRTT can have a pending for blocked-by-cost-overrun (cm_pbbco?)or become (non-deterministically) unblocked, informing the cost monitoring about it(rtt_unblock!). If a pending for blocked-by-cost-overrun is set for the PRTT and:(i) it unblocks, it becomes blocked-by-cost-overrun (rtt_unblock!); (ii) a new re-lease occurs, the pending is cleared (cm_clearpbbco?). If the SO is blocked-by-cost-overrun and the cost of the PRTT is increased or a new release occurs, the cost mon-itoring makes the PRTT eligible-for-execution (cm_eligible?).

The main behaviour of a PRTT is defined by the execution of the waitForNextPe-riod() method (wfnp?) that, depending on the current value of its internal variables,triggers different transitions. If the PRTT has not missed a deadline (mc == 0), isexecuting the current ith release (pr == 0) and is descheduled, it becomes blocked-for-schedule-periodic. If it is not descheduled, it becomes blocked-for-release-event.Once blocked-for-schedule-periodic, it can become blocked-for-release-event (sched-ule?), resetting the cost monitoring (rtt_reset!). If blocked-for-release-event, it canchange to the state: (i) blocked-for-schedule-periodic (deschedule?), informing thecost monitoring (rtt_descheduled!); (ii) executing (execute?), decrementing the pend-ing releases (variable pr) and setting the last return (variable lr) to true. Moreover,three other transitions can also happen when a call to the waitForNextPeriod() methodis executed. All these transitions end up in the executing state and they can informthe cost monitoring (rtt_completion!) or not (this means that the PRTT is trying torecover from a deadline miss).

• Automaton for the PRTT subsystem at the scheduler level: Defines the gen-eration of releases and monitors deadlines for the PRTT component. It is modelledusing the automaton PRTT_RD (PRTT Releases/Deadlines) shown in Fig. 8. Thisautomaton keeps track of the deadline and period for the PRTT, generating releaseevents when periods are due. It starts the first release of the PRTT (execute!) and in-forms the cost monitoring (rtt_release!). When the current time equals the deadlinefor the PRTT (time == dl), it can (based on the state of the PRTT component): incre-ment the number of miss counts (variable mc); deschedule the PRTT (d is set to true)

152 Real-Time Syst (2007) 37: 139–179

Fig. 7 (a) PRTT_SDI and (b) PRTT_Main automata

Fig. 8 PRTT_RD automaton

and reset the number of miss counts; or do nothing. Moreover, when a period is due(time == p), it can (also depending on the current state of the PRTT component):increment the pending releases and inform cost monitoring about the new release; in-crement the pending releases, make the PRTT eligible-for-execution and inform thecost monitoring of the new release; or do nothing.

Real-Time Syst (2007) 37: 139–179 153

In order to guarantee that the model is analysable, we need to ensure that variablescannot have their values growing indefinitely. Thus, we impose a guard to control themaximum number of pending releases. When the model reaches a maximum of NRpending releases, the transition S3 → S5 takes place. Whenever this transition oc-curs, the whole model stops and no more transitions (except for S5 → S5) can occur.Using this strategy we bound the number of pending releases and provide a well-defined behaviour once the maximum value for pending releases (NR) is reached.Although we impose this restriction we are still generating all the possible execu-tion combinations (while pending releases is lower than NR) that we are interested inanalysing.

2.3.2 Formal analysis and the anomalous behaviour

The CM subsystem consists of the CM component and the portion of the applicationand scheduler levels that interacts with the CM component (see Fig. 4). In Santosand Wellings (2005) we specified the CM subsystem of the modelling architectureand formally analysed the behaviour of the cost monitoring mechanism of the RTSJ.In this paper, we do not present this previous CM subsystem. Instead, in Sect. 3.2,we present a revised CM subsystem representing the cost monitoring mechanismproposed in this paper. In the formal analysis carried out in Santos and Wellings(2005), we divided the properties to be verified against the defined cost monitoringmodel into two categories. The first category included seven properties and was usedto guarantee that the TA model was consistent with the definitions for PRTT and costmonitoring found in the RTSJ. When verified with the UPPAAL tool, all propertiesof the first category ended up being valid (or had a true result) in the formal analysis.That allowed us to get confidence in the consistency of the model and start analysingthe behaviour of the cost enforcement approach.

The second category was used to explore the main characteristics of the cost en-forcement approach defined in the RTSJ. It consisted of four properties. In the firstproperty we verified that a deadlock situation was not possible in the model, thisreached a true result during verification. Then, we verified a property (with a falseresult, i.e. the property ended up not being valid) that presented a counter-examplewhere a PRTT could execute the CPU for more than its cost in a release. Nevertheless,as a consequence of this counter-example, we defined a new property that was used toguarantee that, whenever a PRTT executed for more than its cost in a release, a costoverrun handler would be released. This property had a true result during verification.

Finally, the last property verified was that a PRTT cannot execute the CPU formore than its cost per period. This property had a false result and revealed the pos-sible anomalous behaviour found in the current definition of the cost monitoring ap-proach of the RTSJ, defined in Belliardi et al. (2006). An execution example thatshows the anomalous behaviour is depicted in Fig. 9. The scenario used during veri-fication to generate the counter-example consists of a PRTT executing with a periodof 10 time units, a deadline of 5 time units, and a cost of 4 time units.

As shown in Fig. 9, the PRTT starts executing and becomes blocked at time one(say, as a result of an I/O operation), unblocking and restarting execution at time 11(in the second period). It continues executing and an overrun occurs at time 14 (gen-erating a handler) when the budget of the first release finishes. Because the current

154 Real-Time Syst (2007) 37: 139–179

Fig. 9 Possible anomalous inthe cost enforcement model ofthe RTSJ

cost monitoring and enforcement model of the RTSJ supports a full replenishment ofcost when the ith + 1 release event already occurred, as in this case, at time 14 theith + 1 cost monitoring phase starts and the PRTT can continue executing for more4 time units. Indeed, it can exceed the allowed budget in the period and execute fromtime 15 up to time 18. At time 18 it stops because an overrun for the second releaseoccurs and the PRTT becomes blocked-by-cost-overrun. This way, in this particularrun, the PRTT is allowed to execute up to seven time units in the second period (70%of the CPU in an uni-processor architecture because the period is of 10 time units).

But the problem could be worst if, for instance, we consider that (for whateverreason) the PRTT gets blocked for a number of R release events. In this case, wecould have the possibility of the PRTT executing uninterrupted for: R release eventsmultiplied by the PRTTs cost. Depending on the current state of the application, thisbehaviour could have a major impact on lower priority threads and potentially un-dermine the feasibility analysis of the application. Of course, if the application hasspecified a deadline miss handler and an overrun handler, these will be released ateach missed deadline and overrun. However, there is no automatic recovery actionin such a handler that can immediately stop the execution of the PRTT, and conse-quently isolation of the timing fault cannot be guaranteed. In the next section wepropose a solution to this problem and provide a formal model representing this so-lution, including the definition of its behaviour in terms of the notation used in theRTSJ.

3 A revised cost monitoring and enforcement model

In general there are two goals for any cost enforcement approach:

1. Notify the program about any overrun execution state (faulty behaviour), so thatmeasures can be taken by the program;

2. To ensure that the run-time behaviour of the program does not undermine anyperformed feasibility (schedulability) analysis without the explicit intervention ofthe program.

We have seen that there are some scenarios in which the RTSJ does not guaranteethe second property. In order to solve the anomalous behaviour discussed previouslyand enforce that a PRTT cannot exceed its budget in a period, the first solution soughtwas for the cost monitoring mechanism to not allow stealing of execution time from

Real-Time Syst (2007) 37: 139–179 155

Fig. 10 Problems with onlyconsidering a cost per periodmechanism for enforcement

outstanding releases. This leads to a cost per period mechanism used to enforce thebehaviour upon the PRTT. Specifically, on each new ith + 1 release occurrence, thecost monitoring system would reset the current consumption of the PRTT to zeroand consider this ith + 1 release to be the new ith cost monitoring phase. Therefore,whenever the current consumption exceeds the cost in the current period, an overrunoccurs and the PRTT becomes blocked-for-release-event. Unfortunately, as a conse-quence of not considering outstanding releases, this model can no longer guaranteethat an overrun handler will be fired when the PRTT exceeds the budget per release(a property that is guaranteed by the current model in the RTSJ, defined in Belliardiet al. (2006)). This fails to ensure the first property listed before, where the programshould be informed that an overrun has occurred.

For instance, one possible situation that can happen using this model is shown inFig. 10. The scenario consists of a PRTT executing with a period of 10 time units, adeadline of 5 time units, and a cost of 4 time units. In the example, the PRTT enters ina cycle (executing for 3 time units, blocking and unblocking) and can execute in eachperiod without exceeding its budget per period. Though, the thread presents an errantbehaviour by not making a call to the wFNP method and, therefore, not finishingits first release. Because we are considering the current release in this run (whichexceeds its cost at time 12), the system is not able to inform the (faulty) behaviour tothe application since a cost overrun never occurs at time 12 (for the release) and nooverrun handler is ever released (although a deadline miss handler, if present, will bereleased).

So far we can identify two main enforcement attributes, based on per release orper period mechanism, which can be used to enforce the CPU budget for a PRTT. Onone hand, using the per release mechanism, we can guarantee that overruns are no-tified to the application—first property previously described. On the other hand, theper period mechanism enforces that errant threads cannot impact on other threads ex-ecution, maintaining the feasibility analysis—second property previously presented.Four possible combinations of these two attributes are possible. In the first approachno cost enforcement model is introduced during execution and the PRTT can exe-cute freely. The second approach is the one found in the current version of the RTSJ.The approach discussed before is the third approach, where only per period basedenforcement is added to the system. In the fourth approach we can find a combina-tion of both per release and period enforcements. This solution is consistent in thesense that it combines strengths found in both approaches 2 and 3. Indeed, this is thesolution proposed in this paper.

156 Real-Time Syst (2007) 37: 139–179

Fig. 11 Example of theproposed solution

The idea is to guarantee that an overrun handler will be released when the con-sumption exceeds the cost per release and that a PRTT becomes blocked-by-cost-overrun whenever it exceeds the budget per period (possibly releasing a handler aswell). We extend the current model of cost monitoring system of the RTSJ by addinganother consumption value, which is used to monitor the CPU consumption duringthe current period of the PRTT. When this consumption exceeds the cost in a givenperiod, a cost overrun (due to the period) occurs and the PRTT becomes blocked-by-cost-overrun. In Fig. 11 we present an example of the solution. This shows the samerun of Fig. 9, where the anomaly was depicted. The difference is that, instead ofcontinuing the execution up to time 18, the PRTT becomes blocked-by-cost-overrunat time 15 due to an overrun for the period. This guarantees that the behaviour iscorrectly enforced upon the PRTT.

Note about enforcing cost per period: Although, enforcing a worst-case cost(budget) per thread’s release is independent of the feasibility analysis, the actualcost to be enforced in a thread’s period is dependent on the assumptions used inthe analysis. For example, with a thread’s deadline being less than or equal to its pe-riod (as is the case with the RTSJ base priority scheduler used in our assumptions),this value is again equal to the thread’s worst-case cost. However, the RTSJ allowsdifferent schedulers to be added. If we relax the assumptions of this work, describedin Sect. 2.2, and assume the use of a scheduler (and its associated feasibility analysis)which allows a thread’s deadline to be greater than its period (D > T ), then enforcingcost per period is not a valid constraint.

In the cost monitoring and enforcement model proposed in this paper, our mainobjective is to enforce the maximum possible budget for a thread in a given interval,which is in accordance with the feasibility analysis. It follows that, from a cost mon-itoring and enforcement point-of-view, we have two main attributes: (i) the intervalfor the budget replenishment; (ii) the maximum budget per interval. Using the as-sumptions defined in Sect. 2.2 for (D ≤ T ), irrespective of the scheduler used, theseattributes are set as: (i) the period (or MIT in the case of sporadic threads, see Sect. 5)of the thread; (ii) the cost per release of the thread. Indeed, by relaxing the assump-tions and considering (D > T ), we should be able to maintain these two attributes todefine the cost monitoring and enforcement mechanism. Although the relation of costper period should be adapted, following the values used in the feasibility analysis forsystems with (D > T ).

For example, in the specific case of using a priority-based scheduler, the feasi-bility analysis itself needs to be changed when (D > T ), as described in Lehoczky

Real-Time Syst (2007) 37: 139–179 157

(1990). In this scheduling model, the longest response time of a thread’s release oc-curs during a level-i busy period—a time interval where only threads of priority i orhigher execute in the system. Therefore, in order to check if the system is feasiblefor a thread with (D > T ), the analysis has to consider a finite number of N releases,where the last release of the level-i busy period finishes before the start of the nextN + 1 period.

This way, we can adapt the two attributes described for the cost monitoring andenforcement mechanism as follows. The first attribute (interval for budget replen-ishment) corresponds to the level-i busy period of the thread. Meaning that, insteadof looking to a single period, the mechanism has to expand its interval to considerN periods according to the feasibility analysis. Moreover, because we expanded thereplenishment interval, the second attribute (maximum budget) has to be set accord-ingly. Indeed, we set the cost (budget) to be (N × cost_per_release), where N isthe number of releases that can occur in the level-i busy period of the thread (theenforcement interval).

We show how it is possible to use the cost monitoring and enforcement mecha-nism proposed in this paper in the context of priority-based scheduling which allowsthread’s with deadline greater than their period (D > T ). It must be noted that whenusing (D > T ), the complexity of the feasibility analysis is increased. For example,when using a necessary and sufficient analysis for priority-based systems like the Re-sponse Time Analysis (Tindell et al. 1994), the complexity becomes exponential in-stead of pseudo-polynomial as in the case of (D ≤ T ). Therefore, for the remainder ofthis section, we assume the RTSJ priority scheduler. However, by parameterising thecost enforcement mechanism with values from the feasibility analysis as explained,the model presented in this paper is a general model for the RTSJ.

3.1 A revised monitoring and enforcement mechanism for the RTSJ

Based on the previously discussed approach for solving the anomalous behaviour,Fig. 12 presents a modified definition of the cost monitoring system defined in theRTSJ. The main modification is the addition of another counter to keep track of theCPU consumption value per period (for the PRTT), which we call consumption-period. Moreover, the current consumption value used in the release is calledconsumption-release. Due to this addition we need to: (i) change some of the rules al-ready defined by the RTSJ to cope with the consumption counter; (ii) add other rulesto deal with this new counter. We give an explanation of the proposed definition.

As presented in Fig. 12, as soon as the PRTT starts its initial release the cost mon-itoring starts to monitor the CPU consumption (per release and per period) (a). If acost overrun occurs (b), any associated cost overrun handler is released. When a costoverrun in a release occurs, different actions may be triggered by the cost monitor-ing (c1). The semantics of the behaviour for a cost overrun in a period are shown in(c2). On the occurrence of a new ith release event, the PRTT has its consumption-release and consumption-period values reset: becoming eligible-for-execution (d)(1);or having a pending for blocked-by-cost-overrun cleared (d)(2)(i). Otherwise, onlythe consumption-period is reset. When the thread completes the ith (current) re-lease and the ith + N cost monitoring phase has not started, it is started and the

158 Real-Time Syst (2007) 37: 139–179

(a) Initial release: consumption-release and consumption-period are set to zero and will increase asthe thread executes;(b) Cost overrun: if consumption-release or consumption-period becomes equal or greater than cost—due to execution of the thread or change in the cost value—the overrun asynchronous event handler,if any, is released;(c1) On the occurrence of a cost overrun (due to a release overrun):

(1) if the most recent release of the thread is the ith release and ((the ith + 1 release event hasnot yet occurred) or (the ith + N release event has occurred and the ith + N cost monitoringphase has been started, where N > 0)):(i) if the thread is executing or eligible-for-execution, then it becomes blocked-by-cost-

overrun;(ii) if the thread is blocked for a reason other than blocked-by-cost-overrun, then a pending

for blocked-by-cost-overrun is set;(2) else if the ith + N (where N > 0) release has occurred and the ith + M (where N > M) cost

monitoring phase has not yet started, then the cost monitoring system starts its ith +M phase,CPU consumption-release is set to zero and the thread remains in its current state;

(c2) On the occurrence of a cost overrun (due to a period overrun):

(1) if the thread is executing or eligible-for-execution, then it becomes blocked-by-cost-overrun;(2) if the thread is blocked for a reason other than blocked-by-cost-overrun, then a pending for

blocked-by-cost-overrun is set;

(d) Occurrence of the ith release event for a thread:

(1) if the thread is blocked-by-cost-overrun, then the ith cost monitoring phase is started, theCPU consumption-release and the CPU consumption-period are set to zero, the thread is madeeligible-for-execution;

(2) if the thread is blocked for a reason other then blocked-by-cost-overrun:(i) if a pending for blocked-by-cost-overrun is set, then the pending is cleared, the ith cost

monitoring phase is started, consumption-release and consumption-period are set to zero,the thread remains in its current state;

(ii) otherwise, the CPU consumption-period is set to zero;(3) otherwise, consumption-period is set to zero;

(e) Completion of the ith release for a thread: and if the ith + N (where N > 0) cost monitoringphase has not started, it is started and the CPU consumption-release is set to zero; otherwise no actionis taken;(f) Changes to the cost value:

(1) if the old value was greater than consumption-release and consumption-period and if the:(i) new value is lower or equal to consumption-release and greater than consumption-period:

a cost overrun due to a release overrun occurs;(ii) new value is lower or equal to consumption-release and consumption-period: a cost over-

run due to a release and a period overrun occurs;(iii) new value is lower or equal to consumption-period and greater than consumption-release:

a cost overrun due to a period overrun occurs;(2) if the new value is greater than consumption-period:

(i) if the thread is block-by-cost-overrun, then the thread is made eligible-for-execution;(ii) if the thread is blocked and a pending for blocked-by-cost-overrun is set, then the pending

is cleared;(iii) otherwise, no cost monitoring actions occurs;

(g) Reset the cost monitoring: if the most recent release being considered is the mth release and thethread is in the nth release (n > m), then a reset makes the cost monitoring start its nth phase (reset)and consumption-release and consumption-period are set to zero.

Fig. 12 Requirements and definitions for the revised cost monitoring and enforcement model

Real-Time Syst (2007) 37: 139–179 159

consumption-release value is reset (e). Furthermore, the cost value of the PRTT be-ing monitored can be dynamically changed, triggering different actions by the costmonitoring (f), affecting both consumption-release and consumption-period valuesand triggering the respective overruns. Finally, if the cost monitoring is in the mthphase and the thread is in the nth release, where n > m, the state of the cost monitor-ing is reset to consider the nth release (g)—resetting both consumption-release andconsumption-period counters.

From an implementation point of view, we consider that only one type of handleris generated when an overrun occurs. By doing so we are able to maintain the currentinterface proposed by the RTSJ. Nevertheless, it is necessary for the developer to beable to distinguish what type of overrun triggered the handler in order to take appro-priated measures. In this sense, the idea is to reflect in a special variable (representingthe state of the thread) the last overrun state of the thread. According to the modelshown in Fig. 12, we have three different states: (i) overrun in a release; (ii) overrun ina period; (ii) overrun in a release and period. Using this state the developer is able totake the correct measures in the system. Moreover, this approach introduces a loweroverhead in the system because only one type of handler is released.

3.2 The CM subsystem

Based on the modified version of the cost monitoring mechanism shown in Fig. 12,we present details for the TA model that reflects the incorporated changes. The overallstructure shown in Fig. 4 is unchanged. The model for the Cost Monitoring (CM)subsystem is composed of five automata. As discussed before, the current state ofthe CM component is set through the global variable cm_cs. Because the idea ofthis model is to monitor the execution of the PRTT, it reflects on its behaviour thecurrent state of the PRTT being monitored. The interaction between both PRTT andCM needs to be correct otherwise the model may become inconsistent. The possiblevalues for the state of the PRTT were described in Sect. 2.3: INIT, EXEC, BBCO,PBBCO, BFRE, BFS and BLK.

• Automaton for the CM subsystem at the application level: Specifies themethod that can affect the behaviour of the CM. In Fig. 13 we present the automatonCM_Cost representing calls (channels synchronizations) from the application thatcan change the current cost value (budget) of the PRTT being monitored (change-cost!).

• Automata for the CM subsystem at the component level: Specify the interfacebetween the change of cost calls at the application level and the CM component. Italso defines the main behaviour of the CM component. The interface is representedby the automaton CM_CI (CM Cost Interface) depicted in Fig. 14(a). This automatonhas three main transitions that are activated by the change of cost (changecost?) from

Fig. 13 CM_Cost automaton

160 Real-Time Syst (2007) 37: 139–179

Fig. 14 (a) CM_CI, (b) CM_Main and (c) CM_Counter automata

the application level. Depending on the current state of the CM component (vari-able cm_cs), it may trigger different actions in the CM_Main automaton (includingoverruns, see actions changeoverrun! and changeoverrunpp!). Also, it swaps valuesbetween the current cost (variable cost) and the new cost (variable ncost). Usingthis technique of swapping values we can verify all possible interleaving executionswhere the old and new cost values are different from each other.

Figure 14(b) shows the automaton CM_Main, describing the main behaviour ofthe CM component. It specifies the actions triggered by the cost monitoring in

Real-Time Syst (2007) 37: 139–179 161

the occurrence of cost overruns and also resets the CPU consumption-release andconsumption-period to zero. We insert two integer variables to keep track of thecurrent CPU consumption-release (variable cpr) and consumption-period (variablecpp) in order to detect the overruns. Since it is not possible to store the value of aclock using the TA formalism, we also define the automaton CM_Counter shownin Fig. 14(c). This automatons counts, every one time unit (this suffices to capturethe PRTT execution profile), the CPU consumption-release/period (cpr and cpp) andgenerates overruns (overrun! and overrunpp!) when the current CPU consumptionequals the current cost set for the PRTT.

The CM_Main automaton starts by monitoring the thread that was initially re-leased (monitor?) whilst counting the CPU consumption (start!). During execution,when the thread becomes blocked (rtt_block?), the cost monitoring stops countingthe CPU consumption value of the thread. If the thread changes from a blocked stateto executing (rtt_unblock?), the cost monitoring starts counting the CPU consump-tion again. If a cost overrun in a release or period occurs and the thread is blocked(changeoverrun? or changeoverrunpp?), a blocked-by-cost-overrun is left pending.Either when a new release event (monitor?) or a change to the cost value (if the newcost is greater than the current CPU consumption) occurs (clearpbbco?), the threadhas the blocked-by-cost-overrun pending cleared (cm_clearpbbco!) and considers thethread to be in the blocked state. Otherwise, if the thread changes from executingstraight away, it becomes blocked-by-cost-overrun (rtt_unblock?).

When the thread is executing and a cost overrun in a release occurs (due eitherto consumption-release (overrun?) or change in the cost value (changeoverrun?))and the release being monitored is the ith release (cor == 1), the thread becomesblocked-by-cost-overrun. The same transitions can be triggered during a cost overrunin a period (channels overrunpp? and changeoverrunpp?). Otherwise, the cost mon-itoring enters its ith + 1 phase (cor > 1), resetting the consumption-release valueand not changing the state of the thread. If a thread is blocked-by-cost-overrun, itcan become executing when its cost changes to a value greater than the current CPUconsumption-release (makeefe?) or a new release occurs for the thread (monitor?).Note that, whenever a new release occurs (monitor?), the CPU consumption-period isreset (cpp := 0). When a thread completes a release, if the release being monitored isthe ith release and the current release for the thread is the ith release (rtt_completed?),the thread becomes blocked-for-release-event. Otherwise (rtt_completion?), the num-ber of outstanding releases is decremented (variable cor), the consumption-releasevalue is reset, and the thread continues its execution. If the thread is descheduled(rtt_descheduled?), it can eventually become scheduled again, where the cost moni-toring is reset (rtt_reset?).

• Automaton for the CM subsystem at the scheduler level: This is used to keeptrack of the release events generated for the PRTT component. It is modelled usingthe automaton CM_MR (CM Monitor Releases) shown in Fig. 15. This automatoncounts the number of outstanding releases (variable cor, meaning count outstandingreleases) that represents the ith monitoring phase for the mechanism. When a newrelease occurs (rtt_release?) the number of outstanding releases is increased and thecost monitoring is informed to start monitoring (monitor!). If the current state of

162 Real-Time Syst (2007) 37: 139–179

Fig. 15 CM_MR automaton

the thread is blocked-for-release-event, the number of outstanding releases is reset(cor := 1). This means that the ith cost monitoring phase is related to the ith releaseof the PRTT.

• Variables for verification purposes: In the automata shown in Fig. 14 we intro-duced three variables used for verification purposes in the next section. The variabletpr (time per release) is used to count the current CPU consumption-release valuefor a given release of the PRTT until its completion. The variable oh (overrun han-dler) is set to true when a cost overrun occurs (either due to a release or a periodoverrun), and set to false when the PRTT completes a release. Similarly, the variableohpp (overrun handler per period) is set to true on the occurrence of a cost overrunin a period, being set to false when a new period starts or the cost for the period isincreased.

4 Formal evaluation of the revised model

In order to guarantee that the proposed revised cost monitoring and enforcementmodel does correctly solve the encountered anomalous behaviour, in this section wepresent the formal evaluation of the model. Since we use model checking as the analy-sis method, we start defining in the next section the scenario used during the verifica-tion process. Then, in Sect. 4.2, we specify and verify an initial set of properties usedto guarantee that our model is in accordance with both the RTSJ (the PRTT compo-nent) and our proposed cost monitoring model. Having those properties verified, wespecify another set of properties in Sect. 4.3 that are used to evaluate the behaviourof the proposed model and show its correctness, specially guaranteeing that no PRTTcan receive more than its budget per period. All properties are specified using therestricted version of the Timed Computation Tree-Logic (TCTL) found in the UP-PAAL tool, the reader is referred to (Behrmann et al. 2004) for more information.In Sect. 4.4 we present details of the verification results for the properties described,respectively, in Sects. 4.2 and 4.3.

4.1 Verification scenario

In our model we have attributes related to the PRTT that need to have their values ini-tialised. These attributes comprise: start time (variable s); period value (variable p);deadline time (variable d); initial cost (variable cost); possible new cost (variable

Real-Time Syst (2007) 37: 139–179 163

ncost). Moreover, in order to make the model finite and analysable, we have to re-strict the maximum allowed number of pending releases (constant NR) for the PRTT.

In order to define the scenario we provide different values for the variables de-scribed before. In particular, during the verification process we observed that boththe start time and the period value do not impact on the complexity of the verifica-tion process. This happens because during the start time no interactions that changethe state of the system occur and the tool can efficiently abstract this time, reducingstate space. The same is true for increasing the period value, after the PRTT stopsexecuting in a given period. Also, both these variables do not change the validity ofthe results for the verifications. Therefore we set a fixed value for the start time tozero (0) and period to ten (10) in our verification scenario.

We vary the scenario by increasing the maximum allowed number of pending re-leases. Since we are analysing a system based on an uni-processor architecture, wedo not want to have a cost equal to the period. This would model a system whereonly one thread would be executing without stopping—if the thread has the highestpriority. Therefore, we set the initial cost value to four (4) time units and it can dy-namically change to two (2) time units. This way, due to the period value of ten (10),we have the PRTT initially executing up to 40% of the CPU, but once a new cost isdetermined, it can execute up to 20 % of the processor. Moreover, we specify anothervariation of the scenario, where the cost value remains constant with four (4) timeunits. This is used for the analysis of Property 12. The deadline time is set to a fixedvalue of five (5) time units. In Sect. 4.4 we discuss the verification results for thescenario and its variations against the properties defined in the next sections.

4.2 Model consistency

The idea of this section is to provide a sequence of properties that enable us to checkthe consistency of the defined model. Because we model the behaviour of a PRTT,in the first two properties we check that no inconsistency behaviours from a PRTTpoint of view occurs. We focus our attention in two key variables of the behaviour forPRTTs: mc, used to count the number of deadline misses; and pr , which counts thenumber of pending releases.

Property one looks at the mc variable (deadline misses).

Property 1 The number of deadline misses is always equal or greater than zero andless than or equal to the maximum allowed number of releases in the model plus one.

This property specifies that the variable mc must never have a negative value,such condition would indicate a faulty behaviour in the model. Since we restrict thepossible number of releases of our model to the value contained in the constant NR(see the formal model presented in Sect. 2.3), the number of missed deadlines shouldnever become greater than the number of releases which are pending plus one (1).We add one to NR because, when the model reaches NR, it is possible for the modelto miss one further deadline before stopping its execution. We specify the followingsafety property A[] (mc >= 0) && (mc <= NR + 1)—meaning that in all statesof possible executions, the value of mc is always greater than or equal to zero and lessthan or equal to the maximum number of releases in the model plus one (NR + 1).

164 Real-Time Syst (2007) 37: 139–179

In the second property we look at the pr variable (pending releases).

Property 2 The number of pending releases is always equal or greater than zero andalso equal or lower than the maximum allowed value of pending releases.

In this property we want to make sure that the value of the pr variable isgreater than zero. We also want to make sure that it is bounded by the possi-ble number of pending releases (constant NR). We define another safety property:A[] (pr >= 0) && (pr <= NR)—meaning that in all states of possible execu-tions the value of pr is always between zero and NR.

All properties for the scenario ended up being valid (they had a true result) in theverification process. After checking that PRTTs present the expected behaviour, wefocus our attention on guaranteeing that the interaction between the CM and PRTTcomponents is consistent with the expected behaviour. For the rest of the consistencyproperties we specify liveness properties using the pattern (� � φ) found in theUPPAAL tool. In this pattern, when the left-side of the implication (�) is valid, theright-side must become valid as well. This way, we can force certain computations tooccur (using the left-side) and check that the side effects of reaching that computationare correct (specified in the right-side). In the next three properties we analyse thepossible behaviours for a thread when a cost overrun occurs and the thread is in theexecuting state.

We start checking that in the occurrence of cost overrun (per release) and the threadis executing the current ith release, its behaviour is enforced (the thread becomesblocked-by-cost-overrun).

Property 3 If a thread is in the executing state and the cost monitoring is in its ithphase (and the ith + N5 release event has not occurred), on the occurrence of a costoverrun (where the consumption-release value is greater or equal to the cost) thecost monitoring always puts the thread in the blocked-by-cost-overrun state.

For this property we want to make sure that the thread is currently in the executingstate (CM_Main.exec), the cost monitoring is in its ith phase (cor == 1) and thata cost overrun per release occurs (cpr ≥ cost)—this specifies the left-side. Havingall those conditions true, we want to make sure that the thread is changed to theblocked-by-cost-overrun state (PRTT_Main.bbco)—this defines the right-side. Thisleads to the liveness formula ((CM_Main.exec) && (cor == 1) && (cpr ≥ cost))� (PRTT_Main.bbco).

In the next property we check that in the occurrence of a cost overrun per releasewhen the thread is in the executing state, but the ith + N release event has alreadyoccurred, its behaviour is not enforced, because the replenishment policy allows it tocontinue executing.

Property 4 If a thread is in the executing state and the cost monitoring is in its ithphase (and the ith + N release event has already occurred), on the occurrence of a

5We assume that N > 0 for the properties defined in this section.

Real-Time Syst (2007) 37: 139–179 165

cost overrun (where the consumption-release value is greater or equal to the cost)the cost monitoring does not change the current state of the thread.

For this property we make sure that the thread is currently in the executing state(CM_Main.exec), the cost monitoring is in its ith + N phase (cor > 1) and that acost overrun per release occurs (cpr ≥ cost)—this defines the left-side. Having allthose conditions true, we specify that the thread continues in the same executing state(PRTT_Main.exec) because its cost must have been replenished—this specifies theright-side. This leads to the liveness formula ((CM_Main.exec) && (cor > 1) &&(cpr ≥ cost)) � (PRTT_Main.exec).

In the next property we specify that in the occurrence of a cost overrun per periodwhen the thread is in the executing state, its behaviour is enforced (the thread becomesblocked-by-cost-overrun).

Property 5 If a thread is in the executing state, on the occurrence of a cost overrun(where the consumption-period value is greater or equal to the cost) the cost mon-itoring always puts the thread in the blocked-by-cost-overrun state, irrespective ofwhether the ith + N release event has already occurred or not.

First, for this property we have in the left-side of the liveness formula the threadbeing in the executing state (CM_Main.exec). Also, we need to characterise the oc-currence of a cost overrun per period at the left-side of the formula. According tothe behaviour of our model we define two more propositions. The first concerns theconsumption-period exceeding the cost (cpp ≥ cost) and the second is the releaseof an overrun handler due to a cost overrun per period (ohpp == true). We needto use the generation of an overrun handler per period because it may be possible, incertain executions, that consumption-period becomes greater than cost but as soon asthis happens, the thread may increase its cost and continue the execution. Using thegeneration of an overrun enables the exact characterisation of an overrun per period inthe model. At the right-side of the formula we define the thread behaviour being en-forced to blocked-by-cost-overrun (PRTT_Main.bbco). Putting the propositions to-gether yields the following liveness formula ((CM_Main.exec) && (cpp ≥ cost) &&(ohpp == true)) � (PRTT_Main.bbco).

In the previous three properties we analysed the behaviour upon cost overrunswhen the thread is in the executing state. In the next three properties the idea isto analyse the behaviour of cost overruns when the thread is in the blocked state.It should be noted that, even if a thread is not using the CPU, an overrun can happensince the application may change the cost to a lower value and, therefore, trigger anoverrun.

For the next property we start checking that in the occurrence of a cost overrun(per release) when the thread is blocked, but in the current ith release, a pending forblocked-by-cost-overrun is set for the thread.

Property 6 If a thread is in the blocked state and the cost monitoring is in its ithphase (and the ith + N release event has not occurred), on the occurrence of a costoverrun (where the consumption-release value is greater or equal to the cost) thecost monitoring sets a pending for blocked-by-cost-overrun in the thread.

166 Real-Time Syst (2007) 37: 139–179

In this property we make sure that the thread is currently in the blocked state(CM_Main.blk), the cost monitoring is in its ith phase (cor == 1) and that a costoverrun per release occurs (cpr ≥ cost)—this specifies the left-side. Having all thoseconditions true, we specify that a pending for blocked-by-cost-overrun is set for thethread, changing its state to (PRTT_Main.pbbco)—this defines the right-side. Thisleads to the liveness formula ((CM_Main.blk) && (cor == 1) && (cpr ≥ cost))� (PRTT_Main.pbbco).

For the next property we define that in the occurrence of a cost overrun per releasewhen the thread is in the blocked state, but the ith + N release event has alreadyoccurred, the pending for blocked-by-cost-overrun is not set since the replenishmentpolicy allows it.

Property 7 If a thread is in the blocked state and the cost monitoring is in its ithphase (and the ith + N release event has already occurred), on the occurrence of acost overrun (where the consumption-release value is greater or equal to the cost)the cost monitoring does not change the current state of the thread.

For this property we make sure that the thread is currently in the blocked state(CM_Main.blk), the cost monitoring is in its ith + N phase (cor > 1) and thata cost overrun per release occurs (cpr ≥ cost)—this defines the left-side. Havingall those conditions true, we ensure that the thread continues in the same blockedstate (PRTT_Main.blk), because its cost must have been replenished and a pend-ing for blocked-by-cost-overrun is not set—this specifies the right-side. This leadsto the liveness formula ((CM_Main.blk) && (cor > 1) && (cpr ≥ cost)) �(PRTT_Main.blk).

Finally, we focus on the behaviour enforced in a cost overrun per period. Here wewant to check that in the occurrence of a cost overrun per period when the thread isin the blocked state, its behaviour is enforced (a pending for blocked-by cost-overrunis set).

Property 8 If a thread is in the blocked state, on the occurrence of a cost over-run (where the consumption-period value is greater or equal to the cost) the costmonitoring sets a pending-by-cost-overrun in the thread, irrespective of whether theith + N release event has already occurred or not.

First, for this property we have in the left-side of the liveness formula thethread being in the blocked state (CM_Main.blk). Just like for Property 5, we char-acterise the occurrence of a cost overrun per period at the left-side of the for-mula using ((cpp ≥ cost) && (ohpp == true)). Then, at the right-side of theformula we have a pending for blocked-by-cost-overrun being set for the thread(PRTT_Main.pbbco). Putting the propositions together yields the following live-ness formula ((CM_Main.blk) && (cpp ≥ cost) && (ohpp == true)) �(PRTT_Main.pbbco).

In summary, in Properties 1 and 2 we guarantee that no deviations occur in themodel of a PRTT. We specified two safety properties about its key variables usedto count the number of deadline misses (variable mc) and pending releases (variable

Real-Time Syst (2007) 37: 139–179 167

pr). With respect to the proposed cost monitoring and enforcement, in Properties 3to 8 we have addressed the behaviour triggered by cost overruns due to release andperiod overruns using liveness formulas. Since all those properties had a true resulton the verification runs, we can state that our model is coherent and consistent withthe definitions found in the RTSJ and our proposal.

4.3 Model evaluation

In this section we specify certain properties used to explore different behaviours of themodel and evaluate the correctness of the proposed cost monitoring and enforcementapproach. The main idea is to show that the previously encountered anomaly doesnot occur in this model.

In the first property we use the model checking tool to generate all possible exe-cutions for the scenario and check that no deadlock situations can occur.

Property 9 The use of cost monitoring with a thread must never leads to a deadlocksituation.

In order to specify this property we make use of the deadlock keyword availablein the UPPAAL tool. This keyword is used to identify a state in the system whereno transitions can occur (deadlocked state). Using this keyword we specify the safetyformula A[] (not deadlock). When verified, this property ended up being valid forthe scenarios.

We focus on analysing the enforcement of behaviour imposed by the cost moni-toring when a PRTT exceeds its cost (budget) in a given release.

Property 10 A PRTT cannot execute on the CPU for more than its cost per release.

For the specification of this property we monitor the CPU execution time for thePRTT during a release. We use the variable tpr that is used to count the consump-tion of a PRTT until it makes a completion for the current release. Then we definethe proposition (tpr ≤ cost) asserting that the value of the tpr variable is alwayslower than or equal to the current maximum possible cost value of the scenario beingverified. The following safety formula is specified A[] (tpr ≤ cost). This propertywas not valid during the verification process and a counter-example, using one of theverification scenarios, is shown in Fig. 16.

Fig. 16 Counter-examplegenerated for Property 10

168 Real-Time Syst (2007) 37: 139–179

In the counter-example, the PRTT starts executing with a budget of 4. Then, itexecutes its entire budget in the first period, generating a cost overrun and becom-ing blocked-by-cost-overrun (enforced behaviour). Because it did not complete thefirst release in the first period (calling the waitForNextPeriod() method), it resumedexecution in the second period (using the budget of the second release). Therefore,it exceeded its execution budget in a given release. Nevertheless, it is important tonote that, when the PRTT exceeded its cost in the first period, a cost overrun handlerwas fired for that release (guaranteeing that actions may be taken by the program tocorrect the behaviour) and also the PRTT was suspended (because of the enforcedbehaviour). Consequenly, there is no impact on lower priority threads.

Since the behaviour of the cost monitoring mechanism seems to be working fine,according to the counter-example, we specify another property about the behaviourof the mechanism when a PRTT exceeds the cost in a given release.

This property is used to ensure that if the cost is exceeded in a release, specificmeasures (generation of an overrun handler) are taken by the cost monitoring mech-anism.

Property 11 If a PRTT executes the CPU for more than its cost per release a costoverrun handler is released.

In order to specify this property we utilize the pattern (� � φ) used for the spec-ification of previous liveness properties. We want to make sure that during execu-tion the PRTT exceeds its budget per release (tpr ≥ cost)—defines the left-side ofthe formula. Making sure that this proposition holds, we have as its consequence thegeneration of an overrun handler (oh == true)—specifying the right-side of the for-mula. The following liveness property is specified (tpr ≥ cost) � (oh == true).This property ended up being valid for the scenarios in the verification process, guar-anteeing that an overrun handler is always released whenever the PRTT exceed itsbudget per release.

The last property aims to check that the previously found anomaly is not presentin the proposed cost monitoring model. We focus on guaranteeing that during a givenperiod only one budget is permitted.

Property 12 A PRTT cannot execute the CPU for more than its maximum allowedcost per period.

For the specification of this property we monitor the CPU execution time for thePRTT during a period. We use the variable cpp, which counts the consumption of aPRTT per period. Then we define the proposition (cpp ≤ cost), asserting that thevalue of the cpp variable is always lower than or equal to the possible cost value.Note that, for the verification of this property, we used the scenario with a fixedcost value. If we used the scenario with dynamic change of costs, we could havea situation where the PRTT has the current cost of 4 time units and executed for 3time units in a period. Because of the dynamic changes of cost, it could change to acost of 2 time units, a situation where cpp is greater than the current cost, but not anerror condition from the cost monitoring mechanism. We define the safety formula

Real-Time Syst (2007) 37: 139–179 169

A[] (cpp ≤ cost). This property ended up being valid for the scenario, guaranteeingthat the previous encountered anomaly in the cost monitoring of the RTSJ does nothappen in the proposed model of this paper.

In summary, in Property 9 we analysed that no deadlock situations could occurin the model, reaching a true result in the verification process. Then we considered,in Property 10, that it was not possible for a PRTT to execute for more than its costin a given release. This property ended up being false in the verification, leading tothe specification of Property 11 which stated that if the PRTT executes for more thanits cost in a release, it will always release a handler to correct the situation. Havingreached a true result with this property, we defined Property 12 where we specifiedthat it is not possible for a PRTT to execute for more than its maximum cost valuein a period. This property was true and solved the previous anomaly by guaranteeingthat the behaviour upon the errant thread is enforced (the thread becomes blocked-by-cost-overrun).

4.4 Verification results

In this section we present the verification results for both consistency and evalua-tion properties defined in the last sections. For the verification of the properties weused an Intel Pentium 4 1.9 GHz machine running the Slackware Linux 8 OperatingSystem with 1 Gb of RAM. The UPPAAL tool version 3.4.11 was used with the ag-gressive state space reduction option set. As presented in the definition of the scenario(Sect. 4.1), during the verification of the properties we used variations of the scenarioby increasing the maximum allowed number of pending releases, until memory ranout for the verification of the properties.

In Table 1 we show the verification results for the properties. Besides presentingthe validity result of the property (true or false), we also show the time taken toevaluate the property, the memory consumption incurred and the variation of scenario(allowed number of pending releases) for which the results are related to. We do

Table 1 Verification results forspecified properties Property Result Time Generated Allowed number of

(sec.:msec.) state space pending releases

1 true ≈152:89 759 Mb five

2 true ≈155:98 759 Mb five

3 true ≈154:66 785 Mb five

4 true ≈154:94 791 Mb five

5 true ≈155:35 759 Mb five

6 true ≈152:31 767 Mb five

7 true ≈152:50 770 Mb five

8 true ≈148:50 760 Mb five

9 true ≈286:00 760 Mb five

10 false ≈00:10 1 Mb –

11 true ≈58:58 819 Mb four

12 true ≈208:60 942 Mb eight

170 Real-Time Syst (2007) 37: 139–179

not present the variation of scenario for Property 10 (that had a false result duringverification), because all variations had that same time and memory requirements.As discussed previously, in the verification of Property 12, we used the variation ofscenario with a constant cost value. By not having a scenario with dynamic changeof cost, we were able to verify the property in a scenario with up to eight (8) pendingreleases.

5 Supporting periodic, sporadic and aperiodic real-time threads

The current version of the RTSJ supports a range of release parameters that can beassociated to real-time threads. Asynchronous event handlers support the full range.However, currently there is no appropriate mechanism to support associating aperi-odic and sporadic parameters. This is because there is no notion of a real-time threadwaiting for a next release. It can only call the waitForNextPeriod() method (see Fig. 2),which throws an exception if the real-time thread does not have periodic parameters.This also means that it is impossible to support the deadline miss and cost overrundetection mechanisms. Also aperiodic and sporadic threads cannot be descheduled ofthe same way as periodic threads.

In this section we first present recently proposed extensions to the RTSJ to allowthe full set of release parameter types to be supported by real-time threads. Moreover,we show using model checking that the revised cost monitoring and enforcementmodel presented in Sect. 3 is valid for all release types.

5.1 Real-time thread support for aperiodic and sporadic release parameters

The basic idea of the proposal in (JSR-282 Expert Group 2006) to enable the use ofreal-time threads with aperiodic/sporadic release parameters consists in the additionof the following methods to the RealtimeThread class:

• waitForNextRelease(): signals the completion of the current release of the real-timethread and (in the absence of any missed deadline) blocks the real-time threaduntil a release event occurs. The waitForNextRelease() method has comparable se-mantics to waitForNextPeriod(). In the normal case, it returns true when the real-timethread has finished the current release and has not missed its deadline. It returnsfalse immediately if the real-time thread has missed its deadline and no deadlinemiss handler has been released. Real-time threads are automatically descheduled(at the end of the current release) when a deadline has been missed and a han-dler has been released. Alternatively, they can be descheduled explicitly by callingthe deschedule() method. The waitForNextRelease() method is defined to have thesame semantics as the waitForNextPeriod() method, if the thread has periodic releaseparameters;

• release(): signals that the associated real-time thread should be released. Themethod throws an exception if the thread has periodic release parameters;

• deschedule(): indicates that the associated real-time thread should be removed fromthe list of threads eligible for scheduling at the end of its current release. Themethod is defined to have the same semantics as the deschedulePeriodic() method,if the thread has periodic release parameters;

Real-Time Syst (2007) 37: 139–179 171

• schedule(): indicates that the associate thread can be added to the list of threadseligible for scheduling when the next release event for that thread occurs (subject toany MIT constraints if it has sporadic release parameters). The schedule() methodis defined to have the same semantics as the schedulePeriodic() method, if the threadhas periodic release parameters.

The full semantics of this proposal can be found in Santos and Wellings (2006),along with TA models for the semantics. The analysis in that paper focused on thepossible changes of behaviour from aperiodic or sporadic to periodic release para-meters and vice-versa. Differently, here we focus on presenting the integration of theaperiodic and sporadic TA models with the revised cost monitoring model and itsanalysis.

5.1.1 Timed automata model

Different from the periodic model, the aperiodic and sporadic models of the systemhave to cope with arrivals—which have an associated time-stamp (the arrival time).Since we cannot obtain and store the current time from a clock using the TA for-malism, we add the automaton TIME (Fig. 17(a)) to the modelling architecture of

Fig. 17 (a) TIME, (b) RTT_GA, (c) RTT_AI and (d) RTT_Main automata

172 Real-Time Syst (2007) 37: 139–179

Fig. 4. This automaton is responsible for maintaining a global time for the modeland stopping it (transition S1 → S2) once this maximum time (constant MAXT) isreached.

We define the aperiodic/sporadic Real-Time Thread (RTT) subsystem by modify-ing the scheduler level of the PRTT subsystem shown in Sect. 2.3. First we add theautomaton RTT_GA (RTT Generate Arrivals), see Fig. 17(b), to represent the gen-eration of arrivals (arrival!) from the environment that the application is interactingwith. In Fig. 17(c) we depict the automaton RTT_AI (RTT Arrivals Interface), re-sponsible for keeping track of the arrivals (arrival?) and generating release eventswhen arrivals are accepted by the scheduler (accepted!). The arrival is only acceptedif the MIT constraint (variable next holds the MIT constraint for the next arrival)is maintained and the queue of arrivals has not reached its maximum size (constantAQS). Once accepted the arrival is put in the arrival queue with its corresponding ar-rival time (array aq). Moreover, the automaton also signals the CM subsystem aboutthe new release (rtt_release!). In particular, we model aperiodic threads by setting theMIT constraint to zero. It is possible for arrivals to occur in a burst, possibly over-flowing the arrival queue or violating the MIT constraints for sporadic threads. Todeal with these cases, the RTSJ defines four different policies: IGNORE, EXCEPT,REPLACE and SAVE. For the purposes of this paper, which is to analyse the interac-tion of aperiodic/sporadic RTTs with the cost monitoring mechanism being proposed,we only model the IGNORE policy, where arrivals generating overflow of the queueor violating the MIT are ignored.

Figure 17(d) shows the automaton RTT_Main, responsible for monitoring thedeadline of the current release. It receives the accepted arrival (accepted?) and calcu-lates the relative deadline for this release (variable ndl). Then, it starts the executionof the thread (execute!) or not, if the current state of the thread is different fromblocked-for-release-event or initial. After that, it atomically removes the entry for thecurrent release from the arrival queue. If the thread has already missed its deadline,it changes to state S5, otherwise it goes to state S4 and waits for the next deadlineto be reached (t ≤ ndl). A deadline is not missed if the thread completes a release(channels completion? and completed?) or becomes descheduled (descheduled?). Ifthe deadline for the current release is reached, it can (based on the state of the RTTcomponent): increment the number of miss counts (variable mc); deschedule the RTT(d is set to true) and reset the number of miss counts; or do nothing. Once in stateS6, the next transition depends on the current size of the arrival queue (variable aqs).If the arrival queue is empty, the automaton returns to the initial state and waits foranother arrival. Otherwise, it restarts the described behaviour. Moreover, if the max-imum time (MAXT) for the model has been reached, the automaton stops executingand goes to state S7.

It should be noted that the budget for an aperiodic/sporadic RTT is given in everynew release, i.e. via the acceptance of an arrival. Therefore, in the case of a costoverrun, once blocked, the thread can only execute again if a new release occurs, i.e.a new arrival happens and is accepted. Due to the uncertainty of aperiodic/sporadicevents, it is not possible to guarantee that the cost will be replenished once the MITconstraints are satisfied by the thread (or not in the case of aperiodic threads), be-cause we cannot be sure that a new arrival will happen. This way, if the program-mer wants to give more cost for the thread to finish its execution, it is necessary to

Real-Time Syst (2007) 37: 139–179 173

change the associated cost parameter (increasing the thread’s budget). For sporadicthreads, the reason for not automatically providing a new budget once the MIT con-straints have passed comes from the fact that we would not provide a proper sporadicthread, but an execution server instead. In this sense, the RTSJ already provides theprocessing group parameters class to run several threads with a budget replenishmentcapability.

5.1.2 Model evaluation and results

Similar to the evaluation of the cost monitoring model using periodic threads, wespecify a scenario for analysing certain properties over the model. We use the con-sistency and evaluation properties defined in Sect. 4 for the formal analysis. In theanalysis we focus our attention to sporadic threads (with MIT greater than zero), anddo not analyse aperiodic threads. We do so because in the aperiodic model there is noenforcement of MIT (which acts as the period in the enforcement rules) and, by defin-ition, the system could become full of arrivals, possibly only executing this aperiodicthread (depending on its priority level)6.

In order to define a scenario for the sporadic model we have to initialise attributesrelated to the MIT value (constant MIT), deadline time (variable d), initial cost (vari-able cost), possible new cost (variable ncost), the maximum size of the arrival queue(constant AQS), and the maximum time the model can run up to (constant MAXT).Since we use a mechanism to count the time, the value of MAXT directly influ-ences the complexity of the model. Therefore, we define the scenario with differ-ent variations, by increasing the MAXT constant value. The other values are de-fined accordingly (in time units): MIT is four (4), deadline is three (3), initial cost istwo (2), the possible new cost is set to one (1), and the arrival queue size is two (2).Like in the previous analysis, we also specify a variation of scenario where the costvalue of two (2) remains constant. This is particularly important for analysing Prop-erty 12.

The properties defined in Sect. 4 are analysed against this model. Specifically, wemodified the formulas specified for Properties 1 and 2 by not using the NR constantin the specification, since the sporadic model does not use it. In Table 2 we show theverification results for the properties, including the validity result of the property (trueor false), the time taken to evaluate the property, the memory consumption incurredand the variation of scenario (maximum time in the model) for which the shownresults are related to. We do not present the variation of scenario for Property 10,because it had a false result during verification and all variations had equivalent timeand memory requirements. This false result is not depicted, but occurred in the sameconditions of the false result shown for the previous model in Fig. 16. Moreover, bynot having a scenario with dynamic change of cost in the verification of Property 12,we were able to verify the property in a scenario with the maximum time of eigh-teen (18). The results for the analysis using sporadic threads are very similar to theprevious one, using periodic threads.

6The RTSJ supports a form of deferrable server called ProcessingGroup that allows the impact of aperiodicSO to be contained.

174 Real-Time Syst (2007) 37: 139–179

Table 2 Verification results forspecified properties Property Result Time Generated Maximum time

(sec.:msec.) state space in the model

1 true ≈95:38 651 Mb fourteen

2 true ≈95:64 651 Mb fourteen

3 true ≈96:88 673 Mb fourteen

4 true ≈96:20 667 Mb fourteen

5 true ≈95:27 651 Mb fourteen

6 true ≈97:25 662 Mb fourteen

7 true ≈95:79 659 Mb fourteen

8 true ≈96:10 651 Mb fourteen

9 true ≈201:50 651 Mb fourteen

10 false ≈00:11 1 Mb –

11 true ≈43:81 692 Mb twelve

12 true ≈128:34 793 Mb eighteen

6 Related work

We can identify two groups of related work in the literature. The first comprises theuse of formal methods to analyse real-time kernels. In the second group we discussthe increasing support for cost monitoring given by the main real-time languages andoperating systems.

The usage of formal methods to analyse real-time kernels includes simple mod-elling (Spivey 1990), rigorous implementation (Fowler and Wellings 1997), andanalysis using model checking (Lundqvist and Asplund 2003; Penix et al. 2005).Spivey (1990) modelled a real-time kernel of an embedded system using the Z no-tation (Spivey 1992). The goal was to provide a precise specification, which couldbe used as the basis for the implementation of a portable kernel. During specifi-cation, a flaw that could lead to a deadlock situation was discovered, and this wasdirectly reflected in a mathematical property of the system’s specification. Withrespect to rigorous implementation, Fowler and Wellings presented a formal de-velopment approach for a small real-time kernel in (Fowler and Wellings 1997).In their approach, an abstract model of the kernel was specified and propertiesverified. For modelling, they used the logic of the Prototype Verification System(PVS) theorem prover (Owre et al. 1992) and, for the specification of properties,the Real-Time Logic (RTL) (Jahanian and Mok 1986). The kernel size was rela-tive small, and very similar to the Ravenscar Tasking Profile for Ada 95 (Burns1999). After proving the correctness of the abstract model, the development processconsisted of proving a set of verification conditions for each stage in the devel-opment process, which related the kernel specification at one level of abstractionto the next highest level. Although both works did not used model checking asthe analysis method, in common to our work is the use of formal methods to in-crease the understanding of the system. Nevertheless, none of the kernels analysedin (Spivey 1990; Fowler and Wellings 1997) included a cost monitoring and enforce-ment model.

Real-Time Syst (2007) 37: 139–179 175

Lundqvist and Asplund in (Lundqvist and Asplund 2003) modelled the RavenscarTasking Profile for Ada 95 using the UPPAAL tool. Because the Ravenscar Task-ing Profile imposes a series of restrictions over Ada 95, eliminating all tasking con-structs that contain implementation dependencies and non-deterministic behaviour,the model of the analysed kernel was quite small in size and complexity. Indeed,due to the limited complexity it was possible to use model checking to verify theconsistency of the Ravenscar Tasking Profile. Similar to our work, in Lundqvist andAsplund (2003) the UPPAAL tool was used to analyse the kernel. But again, nocost monitoring and enforcement model was analysed. A different approach on theuse of model checking to analyse a real-time kernel was presented by Penix et al.(2005). In their work, a core slice of the scheduling kernel of the Honeywell’s Dy-namic Enforcement Operating System (DEOS) was translated to the input languageof the SPIN model checker (Holzmann 1997). The work was very similar to ours, inthe sense that the portion of the kernel verified was the enforcement model (calledtime partitioning) of the DEOS. Due to the size of the kernel, several abstractiontechniques were applied to make the verification process feasible. In contrast, in thiswork we focused on modelling the system from its specification, rather than its im-plementation, tailoring a specific modelling architecture for the requirements of theRTSJ.

Another group of related work comprises the increasing support for cost monitor-ing and enforcement given by real-time languages and operating systems. Examplesinclude the real-time extensions to POSIX (POSIX.13 1998) and the new Ada 2005language (Barnes 2005). In POSIX it is possible to support execution time moni-toring by extending the clock and timer facilities to include CPU-time clocks forthreads. Then, using the standard POSIX timers, one can create timers that generatesignals when the execution time has expired, specifying a pre-defined behaviour forthe thread. In a similar way, Ada 2005 introduces timers for monitoring the executionof a task, a group of tasks, and another for triggering events at specific real times(Burns and Wellings 2007). POSIX and Ada 2005 do not include a more specificmodel for tackling task overruns, as in the RTSJ. Instead, they allow the programmerto respond to an overrun event. Furthermore, they do not distinguish between execu-tion time per release and execution time per period (or MIT in the case of sporadicthreads). They provide a more primitive mechanism to monitor the time consumedby a thread. The programmer must build on these mechanisms to obtain the requiredhigher-level model, as provided in the RTSJ.

7 Conclusions and future work

Typically, real-time systems must be fault tolerant to timing failures. In order to pro-vide fault containment, it is necessary for the run-time environments hosting real-timesystems to provide mechanisms which enable CPU execution time (cost) to be mon-itored and for overruns to be at least signalled. The Real-Time Specification for Java(RTSJ) goes one stage further, and tries to provide an environment whereby a peri-odic real-time thread is only allowed to execute after a cost overrun if the system canguarantee that the thread will not cause lower priority threads to miss their deadlines.

176 Real-Time Syst (2007) 37: 139–179

The mechanisms provided by the RTSJ are designed to be independent of the sched-uler and its feasibility analysis. Nevertheless, this paper has demonstrated that theparameters used by the mechanisms are feasibility analysis dependent.

In Santos and Wellings (2005), we analysed the current cost monitoring and en-forcement model of the RTSJ and showed that it allows a periodic real-time thread toexecute more than its budget in a given period under certain scenarios (albeit perhapsrare). Depending on the current state of the application, this form of behaviour canpotentially undermine the system’s feasibility analysis. Such a situation is generallyan error condition. By not enforcing the cost, the error has not been confined to theerrant thread but has been allowed to impact on lower priority threads through addedinterference.

To counteract this problem, in this paper we have presented a revised model. Theapproach is to combine the enforcement per release, currently found in the RTSJ,with an enforcement based on periods. We have used a Timed Automata formalismto verify and evaluate the revised model, and have shown that the current anomalyfound in the RTSJ does not occur. However, having the combination of both releaseand period enforcements does require a more complex formal model (and this wouldbe reflected by more complex implementation support). Furthermore, we note that thebase scheduler of the RTSJ supports a deadline less than or equal to period (D ≤ T )model in its feasibility analysis. It does not support scheduling of periodic threadswhose deadlines are greater than period (D > T ). When using (D > T ), the modelproposed in this paper needs to be parameterised to indicate (as discussed in Sect. 3in the context of a priority-based scheduler): (i) the interval for the budget replen-ishment; (ii) the maximum allowed budget per interval. Hence, the cost enforcementmodel cannot be totally independent of the scheduler. This paper has also shown thatif the RTSJ real-time thread model is generalised to allow sporadic and aperiodicthreads, then the revised model remains valid.

A generalised real-time thread model means that a uniform policy could be alsoapplied to Asynchronous Event Handlers (AEHs). The current version of the RTSJviews asynchronous events as dataless occurrences that are either fired (by the pro-gram) or associated to the triggering of interrupts (or signals) in the environment. Oneor more handlers can be associated to (attached to) a single event, and a single handlercan be associated to one or more events. Each handler has a count (called fireCount) ofthe number of outstanding occurrences. When an event occurs (is fired by the applica-tion or is triggered by an interrupt), the count is atomically incremented. The attachedhandlers are then released for execution (once any Minimum Inter-arrival Time con-straint has been obeyed). Hence an event handler can be released even though it hasnot completed the execution associated to its previous releases. The fire count catersfor this situation, allowing the implementation to start the execution associated to thenew release as soon as the old releases have finished.

From a cost monitoring perspective, the following points need to be considered.(1) As with threads, AEHs have release parameters and, therefore, a cost associatedto each release. Periodic, aperiodic and sporadic releases are supported. (2) The RTSJrequires that no more than the cost be given in each release. (3) Any program manipu-lation of the fire count (which represent the occurrence of outstanding release events)is considered to be an optimisation. It does not alter the current release (which has

Real-Time Syst (2007) 37: 139–179 177

its specified deadline and cost constraints). However, it does result in pending re-leases being cleared. (4) The revised cost enforcement model presented in this paperapplies to all time triggered periodic releases, aperiodic and sporadic releases. Thisis because it focuses on release rather than the details of the objects that implementthe code associated to the releases. However, the RTSJ provides no guarantee that anevent handler that is specified as being periodic is actually released periodically. Theassumption is that these handlers are tied to periodic timer events. Other handlersshould have sporadic or aperiodic parameters. This way, the model proposed in thispaper could be potentially applied to both types of schedulable objects provided inthe RTSJ.

Although the RTSJ has pioneered the use of run-time monitoring of resource us-age, within the context of an overall approach to scheduling and feasibility analysis,it is limited to CPU time. In order to ensure that the feasibility analysis is not un-dermined by the run-time execution of the program, all resource accesses need to bemonitored. The impact of resource usage on feasibility analysis is usually manifestedin terms of a blocking factor. This is the maximum time that a high priority thread canbe blocked from executing by a low priority thread holding a resource. One approachis to monitor this blocking time at run-time to ensure that it is less than the maximumused by the analysis.

It should be noted that currently the RTSJ requires a thread to be suspended (enter-ing in the blocked for cost overrun state) if the CPU consumption is equal to its cost.POSIX and Ada adopt a softer approach to asynchronous suspensions (which can beprogrammed when a cost overrun occurs) and require the thread to be suspended assoon as possible. This is implemented by lowering the priority of the thread to a pri-ority below that of all the real-time threads. This means that if a thread is suspendedwhilst holding resources, priority inheritance algorithms allow the thread to continueuntil all resources are released. This approach could be adopted by the RTSJ to sus-pend threads on cost overruns. The immediate suspension issue is orthogonal to themain issue addressed in this paper, that is, ensuring that the thread does not executefor more than the analysis has assumed.

Finally, whilst the current state of the art in model checking does mean that wehave been limited in the size of the scenarios we have been able to analyse, we wereable to exercise all relevant aspects of the current RTSJ and our revised cost enforce-ment models.

Acknowledgements We are grateful for the input from members of the RTSJ Expert Group, in particularPeter Dibble and David Holmes, to some of the ideas expressed in this paper. We also acknowledge thehelp of Alan Burns with his insights into schedulability analysis where the deadline of a thread is greaterthan its period. We would also like to thank the reviewers for their time and effort.

References

Alur R, Dill DL (1994) A theory of timed automata. Theor Comput Sci 126(2):183–235Barnes J (2005) Rationale for Ada 2005: 4 tasking and real-time. Ada User J 26(3):1–17Behrmann G, David A, Larsen KG (2004) A tutorial on UPPAAL. In: 4th international school on for-

mal methods for the design of computer, communication, and software systems. LNCS, vol 3185.Springer, Italy, pp 200–236

178 Real-Time Syst (2007) 37: 139–179

Belliardi R et al. (2006) The real-time specification for Java – Version 1.0.2. http://www.rtsj.org/specjavadoc/book_index.html

Bollella G et al (2000) The real-time specification for Java – Version 1.0. Addison-Wesley, USA

Burns A (1999) The Ravenscar profile. ACM SIGAda Ada Lett XIX(4):49–52

Burns A, Wellings A (2007) Concurrent and real-time programming in ada. Cambridge University Press,UK

Clarke EM, Grumberg O, Peled DA (2000) Model checking. MIT, USA

Fowler S, Wellings AJ (1997) Formal development of a real-time kernel. In: 18th IEEE real-time systemssymposium. IEEE CS Press, USA, pp 220–229

Holzmann GJ (1997) The model checker SPIN. IEEE Trans Softw Eng 23(5):279–295

Jahanian F, Mok AK (1986) Safety analysis of timing properties in real-time systems. IEEE Trans SoftwEng 12(9):890–904

JRate (March 2007) Java real-time extension. http://jrate.sourceforge.net/

JSR-282 Expert Group (2006) SI 1.4: supporting sporadic and aperiodic releases in real-time threads.http://jcp.org/en/jsr/detail?id=282

Larsen KG, Pettersson P, Yi W (1997) UPPAAL in a nutshell. Int J Softw Tools Technol Trans 1(12):134–152

Lehoczky JP (1990) Fixed priority scheduling of periodic task sets with arbitrary deadlines. In 11th real-time systems symposium, IEEE CS Press, USA, pp 201–209

Lundqvist K, Asplund L (2003) A Ravenscar-compliant run-time kernel for safety-critical systems. Real-Time Systems 24(1):29–54

OVM/J Consortium (March 2007) OVM Project. http://www.ovmj.org/

Owre S, Rushby JM, Shankar N (1992) PVS: A prototype verification system. In: 11th international con-ference on automated deduction. LNCS, vol 607. Springer, USA, pp 748–752

Penix J et al (2005) Verifying time partitioning in the DEOS scheduling kernel. Formal Methods Syst Des26(2):103–135

POSIX. 13 (1998) IEEE standard for information technology – Standardized application environmentprofile – POSIX(R) realtime application support (AEP). IEEE Std. 1003.13-1998

Santos OM, Wellings A (2005) Cost monitoring and enforcement in the real-time specification for Java –A formal evaluation. In: 18th IEEE real-time systems symposium. IEEE CS Press, USA, pp 177–186

Santos OM, Wellings A (2006) Formal analysis of aperiodic and sporadic real-time threads in the RTSJ. In:4th international workshop on Java technologies for real-time and embedded systems. ACM Press,France, pp 10–19

Spivey JM (1990) Specifying a real-time kernel. IEEE Softw 7(5):21–28

Spivey JM (1992) The Z notation: A reference manual. Prentice Hall, UK

Timesys Inc. (March 2007) The Java reference implementation. http://www.timesys.com/java/

Tindell K, Burns A, Wellings A (1994) An extendible approach for analyzing fixed priority hard real-timetasks. Real-Time Syst 6(2):133–151

Wellings AJ et al (2004) Cost enforcement and deadline monitoring in the real-time specification for Java.In: 7th IEEE international symposium on object-oriented real-time distributed computing. IEEE CSPress, Austria, pp 78–85

Osmar Marchi dos Santos is currently a PhD student in the Real-Time SystemsGroup at the Computer Science Department in the University of York, UK. Heis sponsored by the Brazilian Ministry of Education, CAPES. He holds a masterdegree in Computer Science from Pontifícia Universidade Católica do Rio Grandedo Sul (PUCRS), Brazil in 2002. His research activities are mainly concernedwith fault-tolerance in real-time systems, but his research interests also include theuse of formal methods for the analysis of real-time, distributed and fault-tolerantsystems.

Real-Time Syst (2007) 37: 139–179 179

Andy Wellings is Professor of Real-Time Systems at the University of York, UKin the Computer Science Department. He is interested in most aspects of the designand implementation of real-time dependable computer systems and, in particular,real-time programming languages and operating systems. He is European Editor-in-Chief for the Computer Science journal “Software-Practice and Experience”and a member of the International Expert Groups currently developing extensionsto the Java platform for real-time, safety critical and distributed programming.Professor Wellings has authored/co-authored over 170 papers/reports. He is alsothe author/co-author of several books including “Hard Real-Time HOOD: A Struc-tured Design Method for Hard Real-Time Ada Systems”, “Concurrent and Real-Time Programming in Ada”, “Real-Time Systems and Programming Languages

(3rd Edition)” and “Concurrent and Real-Time Programming in Java”.