26
Annals of Software Engineering 7 (1999) 257–282 257 Towards reusable real-time objects Brian Nielsen a and Gul Agha b a Department of Computer Science, Aalborg University, Fredrik Bajersvej 7E, DK-9220 Aalborg, Denmark E-mail: [email protected] b Open Systems Laboratory, University of Illinois at Urbana-Champaign, Department of Computer Science, 1304 W. Springfield Avenue, Urbana, IL 61801, USA E-mail: [email protected] Large and complex real-time systems can benefit significantly from a component-based development approach where new systems are constructed by composing reusable, docu- mented and previously tested concurrent objects. However, reusing objects which execute under real-time constraints is problematic because application specific time and synchroniza- tion constraints are often embedded in the internals of these objects. The tight coupling of functionality and real-time constraints makes objects interdependent, and as a result difficult to reuse in another system. We propose a model which facilitates separate and modular specification of real-time constraints, and show how separation of real-time constraints and functional behavior is possible. We present our ideas using the Actor model to represent untimed objects, and the Real-time Synchronizers language to express real-time and synchro- nization constraints. We discuss specific mechanisms by which Real-time Synchronizers can govern the interaction and execution of untimed objects. We treat our model formally, and succinctly define what effect real-time constraints have on a set of concurrent objects. We briefly discuss how a middleware scheduling and event-dispatching service can use the synchronizers to execute the system. 1. Motivation Real-time systems remain among the most challenging systems to build, and often projects are late and products faulty. Developers are faced with ever more strin- gent requirements for building larger, more complex systems at a faster pace and without proportional resources. However, because current tools and techniques to deal with complexity do not scale linearly with the size of programs, development problems worsen. We believe that real-time systems can benefit significantly from a development approach based on components where new systems are constructed by composing reusable, documented and previously tested components. Unfortunately, current software development methods and tools do not properly support such con- struction. Because real-time systems are safety critical and often unattended, they must operate under strict end-to-end time constraints and be dependable. Dependability requirements entail both correctness and tolerance to faults. Real-time systems can J.C. Baltzer AG, Science Publishers

Towards reusable real-time objects

Embed Size (px)

Citation preview

Page 1: Towards reusable real-time objects

Annals of Software Engineering 7 (1999) 257–282 257

Towards reusable real-time objects

Brian Nielsen a and Gul Agha b

a Department of Computer Science, Aalborg University, Fredrik Bajersvej 7E,DK-9220 Aalborg, DenmarkE-mail: [email protected]

b Open Systems Laboratory, University of Illinois at Urbana-Champaign, Department of ComputerScience, 1304 W. Springfield Avenue, Urbana, IL 61801, USA

E-mail: [email protected]

Large and complex real-time systems can benefit significantly from a component-baseddevelopment approach where new systems are constructed by composing reusable, docu-mented and previously tested concurrent objects. However, reusing objects which executeunder real-time constraints is problematic because application specific time and synchroniza-tion constraints are often embedded in the internals of these objects. The tight coupling offunctionality and real-time constraints makes objects interdependent, and as a result difficultto reuse in another system. We propose a model which facilitates separate and modularspecification of real-time constraints, and show how separation of real-time constraints andfunctional behavior is possible. We present our ideas using the Actor model to representuntimed objects, and the Real-time Synchronizers language to express real-time and synchro-nization constraints. We discuss specific mechanisms by which Real-time Synchronizers cangovern the interaction and execution of untimed objects. We treat our model formally,and succinctly define what effect real-time constraints have on a set of concurrent objects.We briefly discuss how a middleware scheduling and event-dispatching service can use thesynchronizers to execute the system.

1. Motivation

Real-time systems remain among the most challenging systems to build, andoften projects are late and products faulty. Developers are faced with ever more strin-gent requirements for building larger, more complex systems at a faster pace andwithout proportional resources. However, because current tools and techniques todeal with complexity do not scale linearly with the size of programs, developmentproblems worsen. We believe that real-time systems can benefit significantly from adevelopment approach based on components where new systems are constructed bycomposing reusable, documented and previously tested components. Unfortunately,current software development methods and tools do not properly support such con-struction.

Because real-time systems are safety critical and often unattended, they mustoperate under strict end-to-end time constraints and be dependable. Dependabilityrequirements entail both correctness and tolerance to faults. Real-time systems can

J.C. Baltzer AG, Science Publishers

Page 2: Towards reusable real-time objects

258 B. Nielsen, G. Agha / Towards reusable real-time objects

be loosely defined as systems where timely response is equally important as cor-rect response. Real-time systems typically monitor and regulate physical equipment.Some well-known examples include: manufacturing plant automatization, where theproduction steps must be supervised and coordinated; chemical processes which areautomatically monitored and regulated through sensors and actuators; safety systemsaboard trains and cars; financial applications where stock rates must be guaranteedup-to-date and where transactions must be completed within specific time bounds.

Historically, real-time systems were built using low level programming languagesand executed on dedicated hardware and specialized operating systems: efficiency, highresource utilization, and integration with hardware were the primary concerns, softwaremodularity and reuse were only secondary. In the light of more stringent developmentrequirements, we believe the emphasis should now be on building modular and reusablecomponents, which can be used in many applications. Middleware services (i.e.,general purpose services located between platforms and applications [Bernstein 1996])can then be used to help integrate the components.

However, reusing real-time components is often problematic because applicationspecific time and synchronization constraints are embedded in the internals of thesecomponents. This kind of tight coupling makes components interdependent, and conse-quently unlikely to be reusable in other systems. Properly supported component-basedsoftware development will allow components to be developed individually and later becomposed with other individually developed or existing components, making it possi-ble to reuse components in different applications. Thus component-based software hasemerged as an active area of research. Our work makes a contribution to this area.

2. Separation and reuse

In what follows we use collections of concurrent objects to represent componentsin a distributed real-time system. Typically these objects model real-world entitiesor act as proxies for them. The objects execute concurrently and communicate byexchanging messages containing computation results or information about their localstates. Objects may be larger entities than data structures such as lists or trees, theyneed not be heavyweight processes.

Designing reusable objects is difficult and requires skilled engineers. Buildingreusable concurrent real-time objects is even more difficult, and necessitates particularrestrictions:

1. Objects should not schedule themselves by setting their priorities or by spec-ifying deadlines and delays on method invocations, e.g., use expressions suchas object.method(args) deadline 10, or contain any other type ofscheduling related information.

2. Objects should not manipulate timers for programming delays or timeouts. Timermanipulation includes requesting, cancelling, and handling timer signals.

Page 3: Towards reusable real-time objects

B. Nielsen, G. Agha / Towards reusable real-time objects 259

3. Objects should not have hardwired synchronization constraints. In a concurrentsystem, certain restrictions on order of events must be enfored in order to ensuresafety and liveness. This concerns both the order of invocations of a single object,and the interaction between invocations on a set of objects.

Priorities, real-time constraints, timer values, and synchronization constraints areall properties that are likely to differ between applications, and therefore objects thatembed such behavior cannot be readily reused. In addition, most of these properties areglobal properties, not properties belonging internally to a single object. For example,a priority level only makes sense when compared to the priorities of other objects.Similarly, an object is usually part of a sequence of objects chained by method callswhich together must obey an end-to-end deadline. A deadline on a method invocationonly represents a single object’s time budget along the call chain. New applicationsusing the object will usually have different end-to-end deadlines and different callsequences. Therefore the objects would have to be modified, and consequently re-tested, to accommodate a new time budget.

Parameterizing objects with timing and scheduling information would solve theseproblems only to a very limited extent. This is partly because it is difficult to knowwhich attributes should be parameterized, and partly because concurrency constraintsamong objects are difficult to capture through parameters. We argue that it is better tohandle the composition by a composition software agent, and use design methods andprogramming languages/environments that explicitly provide notations and abstractionsfor this decoupling.

Another source of reuse is the constraints themselves. We expect that manyinstantiations of the same constraints will recur in different applications. It wouldtherefore be advantageous to reuse them. However, a more important reason for reuseis that real-time and synchronization constraints can be extremely tricky to specifycorrectly. Constraints that work as desired should be reused rather than be replaced bynew similar ones. An effective and modular language should enable the programmerto factor out common constraint instances as constraint patterns and support theircomposition.

We propose a model in which both real-time and synchronization constraintscan be specified in an integrated manner, enabling a fairly general set of constraintsto be specified. For example, a time constraint could specify that a controller objectmust receive sensor data from a sensor object every 20 milliseconds. A synchronizationconstraint temporarily disables some actions until others have taken place, for example,to prevent a producer from inserting in a full buffer. We refer to combined real-time andsynchronization constraints as interaction constraints. Both types constrain dynamicinteractions among objects.

Our interaction constraints are conceptually installed “above” ordinary objects,and they actively enforce the developers’ constraints, see figure 1. The enforcing agentis the scheduler (or schedulers) which bases its decisions on the supplied constraints.

Interaction constraints are expressed in terms of enabling conditions on com-munication events occurring on the interface of objects. These events constitute the

Page 4: Towards reusable real-time objects

260 B. Nielsen, G. Agha / Towards reusable real-time objects

Figure 1. Separation of constraints and objects.

observable behavior of a system. What goes on inside an object is encapsulated,and cannot be constrained. Specifically, a collection of synchronizer entities constrainby delaying or accelerating message invocations. Each synchronizer implements aconstraint pattern. We use the object-oriented Actor model to describe objects.

Section 3 introduces and exemplifies our model. Since we are interested inproviding a clean and sound model, it is accompanied by a description of its seman-tics. Our goal is to succinctly define constraints and their effects on the objects theyconstrain. Section 4 provides formal definitions. Finally, in section 5 we discussimplementation.

3. Specification of interaction constraints

We use the object-oriented Actor model [Agha 1986,1990; Agha et al. 1997] todescribe distributed computing entities (hardware or software). An actor encapsulatesa state, provides a set of public methods, and potentially invokes public methods inother objects by means of message passing. Unlike many object-oriented languages,message passing is non-blocking and buffered. This means that when an actor sends amessage, it continues its computation without waiting for, or getting a reply from, thereceiver. Further, messages sent but not yet processed by the receiver are conceptuallybuffered in a mailbox at the receiver. The receiver receives and processes messagesone at a time. In addition, actors execute concurrently with other actors. An actorsystem is illustrated in figure 2.

Each actor is identified by a unique name, called its mail address. A mail addresscan be bound to state variables of type actor reference. To send a message an actorexecutes the send a.m(pv) primitive, where a is an actor reference variable containingthe mail address of the target actor (possibly the actor itself), m is the method to beinvoked, and pv is the value(s) passed. It is possible to communicate mail-addressesthrough messages thus allowing dynamic configuration of the communication topology.

Page 5: Towards reusable real-time objects

B. Nielsen, G. Agha / Towards reusable real-time objects 261

Figure 2. Illustration of an actor system.

actor pressureSensor ( ) {real value;method read(actorRef customer) {

send customer.reading(value);}}actor steamValve ( ) { . . . } // unspecifiedactor controller (actorRef sensor,valve) {

method loop( ) {send self.loop( );send sensor.read(self);}method reading(real pressure) {newValvePos=computeValvePos(pressure);send valve.move(newValvePos);}}

Figure 3. Steam boiler.

The example actor program in figure 3 describes part of a simple boiler controlsystem consisting of a pressure sensor, a controller, and a valve actuator. These entitiesare modelled as actors. The goal is to maintain a pre-specified pressure level in theboiler. The controller is the heart of the system. It repeatedly executes a method whichsends a request to the pressure sensor for the current boiler pressure. The iterationis implemented by having the controller send itself a loop message which causesrequests to be sent to the pressure sensor. The parameter of this message specifies

Page 6: Towards reusable real-time objects

262 B. Nielsen, G. Agha / Towards reusable real-time objects

which actor the result must be sent to, in this case the controller itself. Upon request,the pressure sensor sends a reply containing its current pressure reading back to theinitiator of the request (i.e., the controller). Based on that value, the controller computesan updated steam valve position, and sends a message to invoke the move method onthe valve.

The RT-Synchronizers− language that we define in this paper to express con-straints is purposely distilled: it does not include syntactic sugar for convenient de-scription of common constraint patterns. This allows us to focus on the central ideas,and makes it easier to define a complete semantics. A synchronizer is an object thatenforces user specified constraints on messages sent by actors. Such constraints ex-press real-time or ordering constraints on pairs of message invocations. The messagesof interest are captured by means of patterns that represent predicates over messagecontents and synchronizer state. The structure of an RT-Synchronizers− declaration isgiven in figure 4. It consists of 4 parts: a set of instantiation parameters, declarationsof local variables, a set of constraints, and a set of triggers.

A constraint has one of the following forms:

p1 ⇒ p2 ≺ y: Here p1 and p2 are message patterns and y is a variable or constant withpositive real value. Let a1(cv1) and a2(cv2) be message invocations matching p1

and p2, respectively. This constraint then states that after an a1(cv1) has occurred,an a2(cv2) must follow before y time units elapse. We say that event a1(cv1) firesthe constraint, and causes a demand for a2(cv2).

p1 ⇒ p2 � y: After a1(cv1) occurs, at least y time units must pass before a2(cv2) ispermitted.

In both cases there are no constraints on a2(cv2) until after a1(cv1) fires. A patternhas the form x1(x2) when b, where b is a boolean predicate (guard) over the messageparameter x2 and the state of the synchronizer. x1 is a state variable containing anactor address. Intuitively, a message satisfies a pattern if it is targeted at x1 and theboolean predicate evaluates to true. If a message satisfies a pattern, the invocation is

synchronizer (a1, . . . , an){State Declaration

p11 ⇒ p21 ∼ y1...p1n ⇒ p2n ∼ yn

p1 : x := exp...pk : x := exp}

Figure 4. Structure of RT-Synchronizers−. ∼∈ {�,≺}.

Page 7: Towards reusable real-time objects

B. Nielsen, G. Agha / Towards reusable real-time objects 263

affected by a constraint which must then be satisfied before the invocation can takeplace. When a constraint forbids the invocation of a message, it is buffered until alater time when the constraint enables it. A disabled message may become enabledwhen a delay has expired, or when the synchronizer changes state through a triggeroperation, thus invalidating the constraint.

A trigger command specifies how the synchronizer’s state variables change whena message invocation satisfies a given pattern. Specifically, assignment of the triggerp : x := exp is executed when a message satisfying p is invoked. Synchronizers canthus adapt to the system’s current state.

To promote modularity of interaction constraints, the constraints can be specifiedas a collection of synchronizer objects executing concurrently.

3.1. Example 1: Steam boiler constraints

The synchronizer in figure 5 describes the real-time constraints for the simpleboiler control system from figure 3. The controller should read the pressure periodically(every 20 time units plus or minus some tolerance). The controller must receive sensordata from the pressure sensor within 10 time units measured from the start of the period,and it must update the steam valve position no later than 5 time units after receivingsensor data. A message sequence chart illustrating the communication among theboiler objects and the associated timing constraints is shown in figure 6.

This example shows how real-time constraints can be expressed and imposed sep-arately from the functionality. It also shows how periodic constraints can be expressedby combining deadlines and delays. To make the language easier to use, commonconstraint patterns such as those enforcing periodicity can be specified as macros.

3.2. Example 2: New boiler

In a new boiler application, the pressure sensor must be polled approximatelyevery 100 time units for pressure readings, and the pressure valve must be movedaccordingly no later than 20 time units after the appropriate reading. However, in

actor pressureSensor ( ) { . . . };actor steamValve ( ) { . . . };actor controller (actorRef sensor,valve) { . . . };

synchronizer boilerConstraints (actorRef: controller,valve) {//periodic loop:controller.loop ⇒ controller.loop ≺ 20+εcontroller.loop ⇒ controller.loop � 20-ε//deadline on reading:controller.loop ⇒ controller.reading ≺ 10//deadline on move:controller.reading ⇒ valve.move ≺ 5}

Figure 5. Steam boiler constraints.

Page 8: Towards reusable real-time objects

264 B. Nielsen, G. Agha / Towards reusable real-time objects

Figure 6. Message sequence chart with annotated timing constraints for the steam boiler example.

synchronizer newBoilerConstraints (actorRef: sensor, controller, valve){enum Mode {Normal,High} mode = Normal;//normal pressure periodic:sensor.read when mode==Normal ⇒ sensor.read ≺ 100+εsensor.read when mode==Normal ⇒ sensor.read � 100-ε//high pressure periodic:sensor.read when mode==High ⇒ sensor.read ≺ 50+εsensor.read when mode==High ⇒ sensor.read � 50-ε//deadline on move:sensor.read ⇒ valve.move ≺ 20//Trigger mode changecontroller.reading(pressure) when pressure > NormToHighThr: mode=High;controller.reading(pressure) when pressure 6 HighToNormThr: mode=Normal;}

Figure 7. New steam boiler.

situations where the pressure in the boiler is high, the system must operate with ahigher frequency. The pressure sensor must then be polled every 50 time units. Twothreshold values, NormToHighThr and HighToNormThr, define which pressurevalues cause mode change.

The functional part is reused from example 1, i.e., the actors and their respectivebehaviors are unmodified, but they are now composed by the “newBoilerConstraints”synchronizer given in figure 7. The synchronizer maintains a mode state variable whichtracks whether the system operates in high or normal pressure mode. The examplealso illustrates RT-Synchronizers−’s ability to capture the dynamic changes that arecommon to many real-time systems through the use of a state variable, and to changetime constraints accordingly.

3.3. Example 3: Time bounded buffer

This and the next example show two common real-time constraint patterns:a real-time producer-consumer relation, and rate control. These examples also

Page 9: Towards reusable real-time objects

B. Nielsen, G. Agha / Towards reusable real-time objects 265

actor q {method put(Item item) { //store item };method get(actorRef customer) { send customer.processItem(item);}}actor consumer( ) { actor producer( ) {

method consume( ) { method produce ( ) {send q.get(self); send q.put(item);send self.consume( ); send self.produce( );} }method processItem(Item item) { . . . } }}synchronizer bbConstraints (actorRef: producer, consumer, q) {int n=0; // no of elements in queueq.put ⇒ q.get ≺ 20; // time bound on getdisable consumer.consume when n 6 0; //buf empty?disable producer.produce when n > maxBufSz; //buf full?producer.produce: n++;consumer.consume: n−−;}

Figure 8. Bounded buffer with time constraints.

show how RT-Synchronizers− can express synchronization (event ordering) con-straints.

Figure 8 shows a time bounded buffer where each element must be removed 20time units after it has been inserted. In addition, the usual restrictions of not putting ona full buffer and not getting from an empty buffer are enforced. Note that the code usesa shorthand, disable p, to temporarily prevent messages matching the pattern p frombeing invoked. disable p can be written as e0 ⇒ p � ∞, where e0 is a pattern assumedto be fired at system startup time. This synchronizer could be used, for example, in amultimedia system where the queue is an actor capable of decompressing a compressedvideo stream: the actor has a fixed storage capacity for (uncompressed) frames anduntil a compressed frame is decompressed, it occupies a buffer slot. The actor acceptsmessages containing a compressed frame and messages removing an uncompressedframe. The frames may only stay in the actor for a bounded amount of time. Thebuffer space must then be freed up for processing of new, fresh frames.

3.4. Example 4: Rate control

The example shown in figure 9 illustrates how rate control can be described. Atmost 20 move operations can safely be performed on an actuator in any time windowof 30 time units.

We use an event generator actor to produce message invocations so that thesynchronizer changes state at certain time-points. An event generator actor does not addany functionality per se, but is necessary for the proper functioning of the synchronizer.This programming technique obviates the need for a special internal event concept inRT-Synchronizers− .

Page 10: Towards reusable real-time objects

266 B. Nielsen, G. Agha / Towards reusable real-time objects

actor actuator { method move( ) { . . . }}actor eventGenerator {

method timeOut( ) { send self.timeOut( ); }}synchronizer rateControll (actorRef: actuator, eventGen) {int credit=20; // max no of events in window//timeOut 30 tu’s after move:actuator.move ⇒ eventGen.timeOut ≺ 30;actuator.move ⇒ eventGen.timeOut � 30;//event permitted?disable actuator.move when credit 6 0;//timeOut must be after move!disable eventGen.timeOut when credit > 20;actuator.move: credit−−;eventGen.timeOut: credit++;}

Figure 9. Rate control.

Figure 10. Dependencies of the transition systems to be defined.

4. Formal definition

In this section we provide a formal definition of our model. The formal modeldefines the permissible behavior of a constrained actor program, which is crucial fordetermining which executions on a physical machine will be considered correct.

The separation of functionality and constraints is maintained in the formal defi-nition, and this enables the semantics for Actors and RT-Synchronizers− to be givenas independent transition systems. The meaning of a program composed of actorsand synchronizers is then given by putting the two transition systems in “parallel.”Figure 10 gives an overview of the the transition systems to be defined. A numeratordenominator-pair should be read as Premise

Conclusion , where the premise is the condition thatmust hold in order for the conclusion to hold. The κ transitions define semantics forActors, the γ transitions for individual constraints, and the σ transitions for synchro-nizer objects. Finally, κσ transitions define the behavior of a constrained actor-system.

4.1. Semantics of actors

We first define a transition system κ for an actor language. This defines how thestate of an actor system changes when a primitive operation is performed, thus givingan abstract interpretation. The actor semantics presented here is inspired by the workof [Agha et al. 1997], where a well-developed theory of actors can be found. However,note that we present actor semantics in imperative style rather than the applicative styleused in previous work. Our semantic model abstracts away the notion of methods.

Page 11: Towards reusable real-time objects

B. Nielsen, G. Agha / Towards reusable real-time objects 267

〈fun : a〉E ` b −→λ E′ ` b′⟨

α , [E ` b]a | µ⟩−→κ

⟨α , [E′ ` b′]a | µ

⟩〈snd : a, 〈a′ ⇐ cv〉〉⟨α , [E ` send(a′, cv); b]a | µ

⟩−→κ

⟨α , [E ` b]a | µ , 〈a′ ⇐ cv〉

⟩〈rcv : a, 〈a⇐ cv〉〉⟨α , [E ` ready(x); b]a | µ , 〈a⇐ cv〉

⟩−→κ

⟨α , [E[x 7→ cv] ` b]a | µ

⟩Figure 11. Configuration transitions −→κ.

Instead, each actor has a single behavior – a sequence of statements – which it appliesto every incoming message.

When an actor has completed processing a message it executes the ready com-mand to indicate its readiness to accept a new message. As an aside, readers familiarwith the classic Actor literature will note that the original become primitive has beenreplaced with ready. When an actor executed a become it created a new anonymousactor to carry out the rest of its computation, and prepared itself to receive a newmessage. Thus, in the classic model, actors were multi-threaded, and tended to beextremely fine-grained. In recent literature [Agha 1996], the simpler ready has re-placed become, with essentially no loss of expressiveness. In addition we have, dueto brevity, omitted the semantic definition of dynamic actor creation.

The state of an actor system is represented by a configuration which can bethought of as an instantaneous snapshot of the system state made by a conceptualobserver. It is modeled as a pair 〈α | µ〉, where α represents actor states and µ isthe set of pending messages. The α mapping maintains the state of all actors in thesystem. An actor state holds the execution state of an actor: the values of its statevariables and the commands that remain to be executed. An actor state is written as[E ` b]a, where a is the actor’s address, E is an environment (mapping from identifiersto their values) tracking the values of the state variables, and b is the remainder ofthe actor’s behavior. In each computation step the actor reduces the behavior untilit reaches a ready(x) statement. This juncture signifies that the actor a is waitingfor an incoming message whose contents should be bound to x. When a messagearrives, the actor continues its execution. A message is a pair 〈a⇐ cv〉 consisting of adestination actor address a and a value to be communicated cv. In general cv encodesinformation about which method to invoke along with the values of the method’sparameters.

The semantics of actors is given in figure 11. The fun transition defines the effecton system state when an actor performs an internal computation step, i.e., a reductionof an expression. The transition system −→λ defines the semantics of the sequentiallanguage used to express actor behaviors. Since we do not rely on a specific language,we have omitted its definition.

Page 12: Towards reusable real-time objects

268 B. Nielsen, G. Agha / Towards reusable real-time objects

The interpretation of send is given by the snd-rule. The newly sent messageis added to µ. Message reception is described by the rcv transition. When an actorexecutes a ready(x) command, it becomes ready to accept a new message in anenvironment with the updated state variables left by the previous processing. Also,the actual value carried by the message is bound to the formal argument x. Finally,the message is removed from µ. It is exactly these receive transitions that will beconstrained by RT-Synchronizers− . Other transitions are only affected indirectly.

From this semantics one can make no assertions about the execution time of anactor program; how, then, can we meet real-time requirements? To make this pointclear, we temporarily introduce time into the Actor semantics.

Time can be added to transition systems by introducing a special set of delayactions written as ε(d), where d is a finite positive real-valued number representing thepassage of d time units. The idea is that system execution can be observed by alter-nately observing a set of instantaneous transitions and observing a delay. In [Nicollinet al. 1992] this idea was termed the two-phase functioning principle: system stateevolves alternately by performing a sequence of instantaneous actions and by lettingtime pass.

By adding the rule: 〈α | µ〉 ε(d)−→κ 〈α | µ〉, we extend the −→κ transition relationwith the ability to let time pass. The rule states that any actor configuration is alwaysable to delay transitions for some (finite) amount of time. The consequence is thatone cannot tell how long a time an actor program takes to finish; indeed the intervalbetween any pair of actions is indeterminate. This is a reasonable model for untimedconcurrent programs, where no assumptions on the relative order or timing of eventsshould be made. However, a language with this semantics is unsuitable for real-timesystems: from the code one can only make assertions about eventuality properties,not about bounded timing. A real-time programming language should make assertionsabout time bounds possible, and its semantics should define when and by how muchcan time advance.

4.2. RT-Synchronizers− semantics

We start by defining semantics for single constraints (−→γ transition system),and thereafter proceed to a synchronizer object (−→σ transition system); the latter isessentially a state plus a collection of constraints and triggers. The state variables ofa synchronizer will be represented by an environment V mapping identifiers to theirvalues. Constraints and patterns are evaluated in this environment.

Recall that a constraint has the form p1 ⇒ p2 ∼ y. Whenever an invocationmatches p1 the constraint fires thereby creating a new demand instance for an invoca-tion matching p2. Such a demand will semantically be represented by the triple p2 ∼ d,where d is a real number denoting the deadline or release time of p2, depending on ∼.d is initialized with the value of state variable y, V (y), when fired. Since a constraintcan fire many times successively, a constraint may induce many outstanding demandinstances. The state of a single constraint is therefore represented as a constraint con-

Page 13: Towards reusable real-time objects

B. Nielsen, G. Agha / Towards reusable real-time objects 269

〈Sat≺ : a(cv)〉cs =

{∅ if a(cv) |= p2

p2 ≺ d′ otherwisecf =

{p2 ≺ V (y) if a(cv) |= p1

∅ otherwise

〈|ξ≺ | χ ] p2 ≺ d′|〉 a(cv)−→γ 〈|ξ≺ | χ ] cf ] cs|〉

〈Sat� : a(cv)〉

cs =

{∅ if a(cv) |= p2 ∧ d′ 6 0p2 ≺ d′ otherwise

cf =

{p2 � V (y) if a(cv) |= p1

∅ otherwise

〈|ξ� | χ ] p2 � d′|〉 a(cv)−→γ 〈|ξ� | χ ] cf ] cs|〉

〈Sat∅ : a(cv)〉cf =

{p2 ∼ V (y) if a(cv) |= p1

∅ otherwise

〈|ξ∼ | ∅|〉 a(cv)−→γ 〈|ξ∼ | ∅ ] cf |〉

〈Delay∼ : e〉∀p2 ≺ di ∈ (χ� e).di > 0

〈|ξ∼ | χ|〉 ε(e)−→γ 〈|ξ∼ | χ� e|〉

a(cv) |= x1(x2) when b =def a = V (x1) ∧ b(V [x2 7→ cv])

Figure 12. Semantics for single constraints −→γ where ∼∈ {�,≺}.

figuration 〈|ξ∼ | χ|〉, where ξ∼ stands for the (static description of a) constraint ofthe form p1 ⇒ p2 ∼ y, and χ is a multi-set of demands instantiated from the staticdescription ξ∼ . The semantic rules are shown in figure 12.

The function cs determines whether the pattern of a demand instance is satisfied,and if so, removes it from the demand instance set. If the pattern is not satisfied,the demand is maintained. Similarly, the function cf determines whether or not theconstraint fires and therefore whether or not to add a new demand instance. Thus theSat-rules ensure that whenever a constraint fires, a demand (cf ) is added to χ. Also,whenever a demand (cs) is satisfied, it is removed from χ. Due to the possibility of asingle message matching both p1 and p2 the Sat-rules are prepared to both satisfy andfire a demand. The demand instance to be removed is chosen non-deterministically,giving the implementation maximal freedom to choose the demand it finds the mostappropriate, e.g., the one with the tightest deadline.

Passage of time is controlled by the Delay-rule such that the elapsed amount oftime (e) is subtracted from di in each demand pi ∼ di. This is written as χ � e.Thus for p � d, d is the amount of time that must pass before p is enabled. Inparticular, p will be enabled when d is less than 0. This requirement is enforcedby the cs function of the 〈Sat� : a(cv)〉 rule. For p ≺ d, d is the amount of time

Page 14: Towards reusable real-time objects

270 B. Nielsen, G. Agha / Towards reusable real-time objects

that may pass before p will be disabled. p would be disabled if d is less than 0.However the 〈Delay≺ : e〉 rule prevents time from progressing that much. In effect,the delay rule ensures that deadline constraints are always satisfied in the semantics.This corresponds to the declarative meaning one would expect from a constraint:something that must be enforced. Without this strict definition, our constraints woulddegenerate to mere assertions and not convey their intended meaning. Note that anactual language implementation may not always be able to give this guarantee – eitherstatically or dynamically – for two reasons. First, because physical resources maynot exist to realize them, and second, because finding feasible schedules for generalconstraints is computationally very complex.

Conflicting constraints that have no solutions should be detected as part of thecompiler’s static program check. Ren has shown how RT-Synchronizers− constraintscan be mapped to linear inequality systems for which polynomial time algorithms existfor detecting solvability [Ren and Agha 1998; Ren 1997].

The following transition sequence illustrates application of the transition rules fora constraint:

〈|p1 ⇒ p2 ≺ 7 | ∅|〉 a1(cv)−→ γ

〈|p1 ⇒ p2 ≺ 7 | p2 ≺ 7|〉 ε(3)−→γ

〈|p1 ⇒ p2 ≺ 7 | p2 ≺ 4|〉 a1(cv)−→ γ

〈|p1 ⇒ p2 ≺ 7 | p2 ≺ 4, p2 ≺ 7|〉 ε(4)−→γ

〈|p1 ⇒ p2 ≺ 7 | p2 ≺ 0, p2 ≺ 3|〉 a2(cv)−→ γ

〈|p1 → p2 ≺ 7 | p2 ≺ 3|〉 a2(cv)−→ γ

〈|p1 → p2 ≺ 7 | ∅|〉Given that the behavior of each individual constraint is well defined, it is easy

to define the behavior of a collection of constraints as found within a synchronizer.Essentially the individual constraints are conjoined, i.e., we require that all con-straints agree on a given invocation. Similarly, they must all agree on letting timepass.

A synchronizer is represented by a synchronizer configuration [γ|V ], where γ is aset of constraint configurations (ranged over by γ). As previously stated, V representsthe state variables of a synchronizer and is a mapping from identifiers to their values.The necessary definition is shown in figure 13. A synchronizer can engage in messagereception a(cv) or delay ε(e) only when it is permitted by every constraint.

We have omitted the rather simple definition of the effect of triggers: V ′ is Vsimultaneously updated with the specified assignments in the matched triggers.

4.3. Combining Actors and RT-Synchronizers−

Preceding sections defined Actor and RT-Synchronizers− languages indepen-dently. The effect of constraining an actor program can now be defined here as aspecial form of parallel composition (denoted by ‖) that preserves the meaning of

Page 15: Towards reusable real-time objects

B. Nielsen, G. Agha / Towards reusable real-time objects 271

〈Action : `〉∀i ∈ [1..n].γi

`−→γ γ′i

[γ1, . . . , γn|V ] `−→σ [γ′1, . . . , γ′n|V ′], ` ∈ {a(cv), ε(e)}

Figure 13. Semantics for a synchronizer −→σ.

Unaffected Actions

〈α | µ〉 `−→κ 〈α′ | µ′〉 ` ∈ {〈fun : a〉, 〈snd : a,m〉, 〈ready : a〉}〈α | µ〉 ‖ (σ1, . . . ,σn) `−→κσ 〈α′ | µ′〉 ‖ (σ1, . . . ,σn)

Receive

〈α | µ〉 `−→κ 〈α′ | µ′〉∧

i∈[1..n]σi

a(cv)−→σ σ′i ` = 〈rcv : a, 〈a⇐ cv〉〉

〈α | µ〉 ‖ (σ1, . . . ,σn) `−→κσ 〈α′ | µ′〉 ‖ (σ′1, . . . ,σ′n)

Delay ∧i∈[1..n]

σiε(d)−→σ σ

′i

〈α | µ〉 ‖ (σ1, . . . ,σn)ε(d)−→κσ 〈α | µ〉 ‖ (σ′1, . . . ,σ′n)

Figure 14. Combined behavior −→κσ .

constraints. We call a collection of synchronizers an interaction constraint systemconfiguration which is written as (σ1, . . . ,σn) where σ ranges over synchronizer con-figurations. The composition ‖ of an actor configuration and an interaction constraintsystem configuration is defined in figure 14.

Transitions unaffected by interaction constraints altogether are message sendsand local computations. These only have effect on the actor configuration. Messageinvocations 〈rcv : a,m〉 are the interesting events affected by constraints. Note thatthe same invocation may be constrained by several synchronizers, and all must certifythe invocation, i.e., synchronizers, like constraints, are composed conjunctively. Theidea is that adding more synchronizers should further restrict the behavior of objects.A consequence of this idea is that the synchronizers also must agree on letting timepass.

The combined semantics define all correct transition sequences (−→∗κσ). A transi-tion sequence corresponds to one possible schedule of the implemented system (consist-ing of actors, constraints, operating system, runtime system, and hardware resources),and thus a primary task of the language implementation is to schedule events in thesystem such that the resulting schedule can be found in the program’s semantics. Thus,

Page 16: Towards reusable real-time objects

272 B. Nielsen, G. Agha / Towards reusable real-time objects

a program consisting of actors and RT-Synchronizers− can be viewed as a specificationfor the set of possible systems.

Observe that not all transition sequences defined by −→∗κσ are realizable on aphysical machine. The problem is related to the progress of time and our intuition aboutcausal ordering. Suppose event e1 is a method invocation resulting in the sending of amessage which eventually causes a method invocation, event e2, then we surely wouldexpect that time has progressed between these events. That is, in terms of a fictitiousglobal clock C, it should hold that C(e1) < C(e2). However, in our semantics, timeis not required to pass between causally related events, but only permitted to.

There are two related problems, time locks and cluster points. A time lockoccurs when no time progress is possible, i.e., the delay transition is eternally disabled.In our model this occurs as a consequence of an unsatisfiable deadline constraint.A cluster point is a bounded interval of time in which an infinite number of eventsoccur. It is possible to write such a specification in RT-Synchronizers−. However, itwill not be implementable on a (finitely fast) computer! Since our goal is to definethe permissible implementations, and since time locks and cluster points are onlyrequired when explicitly specified, we have taken no measure to prohibit such behavior.A compiler should, however, warn developers about such unsatisfiable constraints.

5. Middleware scheduling of RT-Synchronizers−

The examples in figures 5–9 illustrated how our language can be used as a spec-ification or modeling language that defines the structure and permissible behavior of acomputer system consisting of hardware and system software executing an application.

An attractive approach to implementing a language that supports separation ofobjects and time constraints is to use a middleware scheduling/event dispatching ser-vice. Such a service is depicted in figure 15. An application consists of two parts,objects and time constraints. A set of potentially reusable objects are composed bymiddleware services for communication and scheduling. Communication typicallyincludes request-reply communication, point-to-point real-time communication, andgroup communication. The scheduler(s) are responsible for event dispatching and re-source (typically processor) allocation, based on information that is specified by theapplication separately from the objects. Thus, objects are being controlled by themiddleware, rather than controlling themselves or each other.

Specifically, given a set of synchronizers as input, this service should, preferablywithout further programmer involvement, schedule message invocations in accordancewith the specified real-time and synchronization constraints. The remainder of this sec-tion is devoted to uncovering what such a service must do to execute the specificationdirectly.

Implementing our full model is not an easy task, but the difficulty is mostlyrelated to the generality of the constraints that can be expressed, rather than to theseparation of functionality and time constraints. We have identified three main tasksa compiler and scheduling service should address:

Page 17: Towards reusable real-time objects

B. Nielsen, G. Agha / Towards reusable real-time objects 273

Figure 15. Middleware integrates pre-built objects.

Figure 16. End-to-end deadlines require computation intermediate deadlines along the call chain.

Scheduling: One challenge is to find a scheduling strategy that satisfies the deadlineconstraints when the RT-Synchronizers− program is executed on a physical machinewith limited resources. In addition, hard and firm real-time systems require an apriori guarantee (or at least a solid argument) that timing constraints will be satisfiedon the chosen platform during runtime.

Constraint propagation: In RT-Synchronizers− the programmer need only specifyend-to-end timing relations, not intermediate constraints on all events along the callchain. Assume that actor a receives a message m1; a then responds with a messagem2 to actor b which in turn sends a message m3 to actor c. Let am1, bm2 and cm3

denote the reception events of these messages. Then a typical interaction constraintwould be am1 ⇒ cm3 ≺ 10. This scenario is depicted in figure 16. Consequently,there is an implicit constraint on event bm2 which is to happen (well) before cm3.Ideally, the compiler/runtime system should be able to perform constraint propaga-tion along the call chain, and derive the intermediate deadlines.

Synchronizer distribution: If the synchronizer entities are maintained as runtime ob-jects, how should their state be distributed? Here there is a classic compromisebetween a centralized solution where consistent updates are easy versus a distrib-uted solution that potentially reduces bottlenecks and increases fault tolerance, butby increasing the cost of maintaining consistency.

Our implementation idea seems practical for soft real-time systems only: weprovide no procedure, whether automatic or manual, for establishing the guaranteesof satisfaction of time constraints as required by hard real-time systems, and for theunrestricted type of real-time and synchronization constraints that we permit in our

Page 18: Towards reusable real-time objects

274 B. Nielsen, G. Agha / Towards reusable real-time objects

Figure 17. Implementation architecture with constraint directed scheduling.

language. Additionally, a full verification of the implemented system is rarely practical.To make schedulability analysis practical, one often restricts the types of constraintsto periodic constraints. Similar restrictions can be made to RT-Synchronizers− . Withsimple dependencies between periodic tasks, generalized rate-monotonic analysis canbe utilized [Sha et al. 1994].

Constraint directed scheduling is an implementation technique that dynamicallyuses the information of the fired constraints in the synchronizers to assign deadlinesand release times to messages (see figure 17). Synchronizer objects are thus maintainedat run time as data objects, whose state can be inspected by the scheduler.

Time-based scheduling such as Earliest-Deadline-First (EDF) can then be usedto dispatch messages based on their deadlines. We propose to use EDF-schedulingbecause it is dynamic and optimal: if a feasible schedule exists EDF will produceone. Obviously, EDF does not in itself guarantee that a feasible schedule exists andconstraint violations may therefore occur. An advantage of our strategy is that it doesmore than simply monitor the time constraints; it constructively applies informationfrom the synchronizers to its scheduling decisions.

We propose to let the compiler compute a conservative version of the call graphannotated with worst case execution time and message propagation delays, and includea copy of it at runtime [Ren 1997]. The runtime system then has the informationnecessary to propagate constraints automatically when this cannot be done staticallyby the compiler. Moreover, we expect that in many cases the compiler would beable to compile away synchronizers entirely. It can generate code (similar to remote-procedure-call stubs) which can be linked with the objects. This code implementsthe time constraints by manipulating timers, setting priorities and/or instructing thescheduler about method call deadlines, etc.

It is interesting to note that the operational semantics can assist in the implemen-tation of a constraint directed scheduling system. An operational semantics can oftenbe constructed such that it constitutes an abstract algorithm for the language imple-mentation. However, because our semantics abstracts away any notion of resourcesand execution time, in our case, this algorithm can only be partial. In particular, itdoes not solve the constraint propagation problem mentioned earlier.

The following example demonstrates two potential benefits of the semantics.First, it shows how the semantics manipulates the synchronizer data structure by adding

Page 19: Towards reusable real-time objects

B. Nielsen, G. Agha / Towards reusable real-time objects 275

and removing constraints, and second it indicates how release times and deadlines formessages can be deduced. Recall the boiler example in section 3.1. We show howthe runtime system may execute that specification. We maintain two important datastructures, the set of fired demands, and the pool of unprocessed messages. We reusethe notation for demands from the semantics: 〈|ξ∼ | χ|〉, where ξ∼ stands for the staticdescription of a constraint and χ is the multi-set of instantiated demands. A messageis written as o.m[R,D], where o is the target object, m the method to be invoked, andR and D respectively the release time and deadline of the message. In the following,we measure time relative to a global clock t, and not using individual timers as wasconvenient in the semantics. Each row in figure 18 shows the global time at which agiven event (i.e., message invocation) occurs, the resulting synchronizer state, and theset of unprocessed messages (including those produced by the event).

At time 0, the system is shown in the initial state in which the message pool con-tains an initialization message (controller.loop) and in which no synchronizer demandshave been fired. Suppose the scheduler invokes the controller.loop message at time 1.This invocation matches three constraints and consequently causes the synchronizer toissue three new demands. The first two constitute the periodic constraint on a futureloop message and the last one determines the deadline on the sensor reading. Duringprocessing of the loop message the controller sends out two new messages, the loopmessage to itself, and a read request to the pressure sensor.

The new loop message matches two demands, and according to the semanticsthese are applied conjunctively. The runtime system can therefore deduce the releasetime and the deadline (an ε interval around time 21) for the loop message from thedemands. Deducing a deadline for sensor.read constitutes a more difficult case (la-beled with a ‡ symbol in figure 18). There is no immediate matching demand onwhich to base the deadline. But it can be noted that there is a demand for which nomatching message exists in the message pool. It is therefore likely that invocation ofthe unmatched sensor.read message will cause sending of the demanded message (asit indeed turns out to be the case in this example). Therefore the sensor.read mes-sage should be assigned a deadline before the demanded deadline (at time 11). Thespecific choice of deadline is in general a heuristic function of slack time and methodcomputation time. Here time 6 is chosen.

The approach of assigning where unmatched messages are assigned deadlinesbased on the most urgent unmatched demand will generally constrain the system un-necessarily, but selecting precisely the right message to constrain is generally im-possible without extra information about potential causal relations between messages.This information is exactly what needs to be generated by the compiler. Less ideally,the missing constraints could be resolved explicitly by the programmer by providingadditional synchronizers. In less expressive real-time programming languages whereend-to-end constraints cannot be expressed, the programmer would always be forcedto do this.

Resuming the example at time 4 where sensor.read is invoked, the sensor respondswith a controller.reading. Since this message matches a demand, it inherits the deadline

Page 20: Towards reusable real-time objects

276 B. Nielsen, G. Agha / Towards reusable real-time objects

Figure 18. Sample execution of the boiler specification.

Page 21: Towards reusable real-time objects

B. Nielsen, G. Agha / Towards reusable real-time objects 277

from that (time 11). The result of invoking the reading message (at time 9) is the firingof a new demand on the valve movement and the sending of a valve.move message.Again, the runtime system is able to deduce the deadline on the move message fromthe move demand. Finally, at time 21, the loop message is invoked. This satisfies theremaining two demands, but at the same time fires two new demands, starting the nextperiod.

6. Related work

Real-time CORBA (Common Object Request Broker Architecture) [Group 1996]is a highly visible research effort where practitioners are shifting towards component-based real-time systems. An object request broker can be viewed as middleware facil-itating transparent client-server communication in a heterogeneous distributed system.It also contains other communication services to facilitate building distributed appli-cations. However, according to [Schmidt et al. 1997], current ORBs are ill-suited forreal-time systems for at least four reasons. They lack interfaces for specifying qual-ity of service, quality of service enforcement, real-time programming facilities, andperformance optimizations.

Current proposals for real-time CORBA [Cooper et al. 1997; Feng et al. 1997;Kalogeraki et al. 1997; Schmidt et al. 1997] use a quality of service metaphor for spec-ifying real-time constraints. Typically, the interface definition language is extendedwith QoS-datatypes. In TAO ORB [Schmidt et al. 1997], these parameters, whichare necessary for guaranteeing schedulability according to rate monotonic scheduling,include worst case execution time, period, and importance. In the NRad/URI’s pro-posal [Cooper et al. 1997] for a dynamic CORBA, time constraints are specified in astructure containing importance, deadline and period, and the constraints specify timebounds on a client’s method invocations on a server. The proposed runtime systemuses this information to compute dynamic scheduling and queuing priorities. The Re-alize proposal [Kalogeraki et al. 1997] associates deadline, reliability, and importanceattributes to application tasks, where a task is defined as a sequence of method invo-cations between an external input and the generation of an external result. That is,deadlines in Realize are true end-to-end deadlines.

We see a clear trend in specifying real-time requirements through interface defi-nitions and letting middleware enforce them. Clients and servers are largely unawareof the imposed real-time requirements. However, we think that these approaches –although an improvement – are imperfect:

• The quality of service attributes seem to be derived from what current run-timesystems can manage rather than forming a coherent set. We have opted for a cleanlanguage instead of a more or less arbitrary collection of attributes.

• The types of constraints that can be specified are restrictive, e.g., only periodsor deadlines between request and reply events. In addition, the constraints arestatic; once assigned they cannot be modified to respond to dynamic changes in

Page 22: Towards reusable real-time objects

278 B. Nielsen, G. Agha / Towards reusable real-time objects

the system’s state of affairs. We allow for a fairly general set of constraints to bespecified.

• Synchronization constraints are not considered. In our proposal, synchronizationconstraints are specified using the same mechanism as time constraints.

The concept of separating functional behavior and interaction policies for Actorswas first proposed in [Frølund and Agha 1993] and a detailed description, operationalsemantics and implementation can be found in [Frølund 1996]. That work only con-sidered constraints on the order of operations. Our work is a continuation of this lineof research where we have extended it to apply to real-time systems and provided aformal treatment of the extended model. However, to what extent real-time and syn-chronization constraints can always be cleanly separated from functionality remains anopen issue, and one which we think can be best resolved through larger case studies.

Another approach which permits separate specification of real-time and syn-chronization constraints for an object oriented language is the composition filtermodel [Aksit et al. 1994; Bergmans and Aksit 1995]. Real-time input and output filtersdeclared in an extended interface enable the specification of time bounds on methodexecutions. Among the differences between composition filters and RT-Synchronizers−

is that RT-Synchronizers− takes a global view of a collection of objects whereas thecomposition filter model takes a single object view. No formal treatment of composi-tion filters appears to be available in the literature.

The Real-time Object-Oriented Modeling method (ROOM) [Selic et al. 1994],which has many notions in common with the Actor model, has recently been ex-tended with notions for specifying real-time properties [Saksena et al. 1997]: messagesequence charts with annotated timing information can now be used to express activa-tion periods of methods or end-to-end deadlines on sequences of message invocations.With these two kinds of constraints and a few design guidelines, the authors show howscheduling theory can be applied to ROOM-models.

Our approach to defining the semantics is inspired by recent research in formalspecification languages for real-time systems, and the use of timed transition systems isborrowed from these languages. Languages often take the form of extended automata(Timed Automata [Alur et al. 1990], Timed Graphs [Alur et al. 1990; Nicollin etal. 1992]), or process algebras such as Timed CSP [Schneider 1995]. A differentapproach is to include a model of the underlying execution resources. This approachis taken in [Satoh and Tokoro 1994] and [Zhou and Hooman 1992]. The resultingsemantics includes an abstract model of the execution environment (number of CPU’s,scheduler, execution time of assignments, etc.). The process algebra CommunicatingShared Resources (CSR) has been designed with the explicit purpose of modelingresources [Gerber and Lee 1989,1992]. A process always runs on some, possiblyshared, resource. A set of processes can be mapped to different sets of resources,hence describing different implementations. Thus, these approaches model relativelyconcrete systems, rather than being specifications for a set of possible systems, as wasour goal.

Page 23: Towards reusable real-time objects

B. Nielsen, G. Agha / Towards reusable real-time objects 279

A recent implementation result is [Kirk et al. 1997], where certain aspects of RT-Synchronizers− are implemented in their DART framework where constraints are usedto dynamically instruct the scheduler about delays and deadlines of messages. How-ever the paper gives no systematic (automatic) translation of constraints to schedulinginformation. We expect that our semantics can help in filling up this gap.

7. Discussion

Developers of modern real-time systems are required to construct increasinglylarge and complex systems, preferably at no extra cost. To satisfy this requirement, itis essential that developers can build real-time systems from existing components, andthat newly developed components can be reused in several applications. We arguedthat in order to facilitate reuse of real-time objects, the real-time and synchronizationconstraints governing the object’s interaction should be specified separately from theobjects themselves. However, current development methods do not adequately supportsuch separation.

We formulated our ideas in the context of Actors, and an associated specificationlanguage, RT-Synchronizers− . Combined, they enable separate and modular speci-fication of real-time systems: computing objects are glued together by synchronizerentities that express real-time and synchronization constraints. However, we believethat these ideas are applicable beyond these specific languages.

Our model is explained both conceptually and formally. Through a series of ex-amples we indicated how separate specification is possible. Our operational semanticsdefines exactly what constraints are and what their effect on a given set of objectsshould be.

Our work on semantic modeling has clarified our understanding of the behaviorof our model, and provides a succinct and detailed definition of synchronizers andconstrained actor programs. In particular, we have gained new insight into three areas,which made the effort worthwhile:

• We defined the semantics in a modular fashion by composing a transition systemfor the untimed object-model with a transition system which interprets the timeconstraints. This composition explicitly points out which object transitions areaffected and how: reception of messages and time-progress may only occur whenpermitted by the constraints. Other object transitions are only indirectly affected.The modularity opens the possibility of plugging in a different constraint specifi-cation language, i.e., the −→σ transition could be replaced with the semantics forthe new language. The composition will work when affected transitions remainas above, and when the semantics of the new language can be given as a timedtransition system. Thus, our constraining concept is captured by the composition.

• Our semantics helped uncover some of the semantic subtleties of our constraintlanguage, such as what happens when patterns and constraints overlap. For exam-ple, the same message may both fire a new demand as well as satisfy an existing

Page 24: Towards reusable real-time objects

280 B. Nielsen, G. Agha / Towards reusable real-time objects

one. Moreover, we decided that overlapping constraints should be interpreted con-junctively, i.e., both must be satisfied. Finally, we decided that adding more syn-chronizers should further restrict the behavior of objects; i.e., synchronizers mustbe satisfied conjunctively.It should also be noted that the rules defining the semantics of individual constraintsappear complicated. This should give food for thought when revising the languageor the semantics.

• The last major benefit is that our semantics suggests an implementation strategysuitable for soft real-time systems. The synchronizer entities can be maintained atruntime and can be used to extract information about release times and deadlinesof messages. The semantics gives an abstract interpretation of the synchronizerobjects and specifies how demands should be added or removed.

Building real-time components and architectures for integrating them is an areaof active research. We believe that with additional research, component-based de-velopment will allow more complex real-time systems to be developed on schedule.However, additional work is needed, both on the models used for separate specificationand on the middleware services necessary to implement them.

Acknowledgements

This work was made possible in part by support from the US National ScienceFoundation under contracts NSF CCR-9523253 and NSF CCR-9619522; by supportfrom the US Air Force Office of Scientific Research, under contract AF DC 5-36128.The authors would like to thank other members of the Open Systems Laboratory fortheir comments and critical insights into the work related in this paper. In particu-lar, we would like to thank Shangping Ren for her contribution to the definition ofRTSynchronizers, and to Nadeem Jamali for his comments on a draft of this paper.A part of this research was done while the first author was a visitor to the Universityof Illinois Open Systems Laboratory under a fellowship from the Danish TechnicalResearch Foundation and the Danish Research Academy.

References

Agha, G. (1986), Actors: A Model of Concurrent Computation in Distributed Systems, MIT Press, LosAlamitos, CA.

Agha, G. (1990), “Concurrent Object-Oriented Programming,” Communications of the ACM 33, 9, 125–141.

Agha, G. (1996), “Modeling Concurrent Systems: Actors, Nets, and the Problem of Abstraction andComposition,” In 17th International Conference on Application and Theory of Petri Nets, Osaka,Japan.

Agha, G., I.A. Mason, S.F. Smith, and C.L. Talcott (1997), “A Foundation for Actor Computation,”Journal of Functional Programming 7, 1–72.

Page 25: Towards reusable real-time objects

B. Nielsen, G. Agha / Towards reusable real-time objects 281

Aksit, M., J. Bosch, W. van der Sterren, and L. Bergmans (1994), “Real-Time Specification InheritanceAnomalies and Real-Time Filters,” In Proceedings ECOOP, pp. 386–407.

Alur, R., C. Courcoubetis, and D. Dill (1990), “Model-Checking for Real-Time Systems,” In Proceedingsof the 5th IEEE Symposium on Logic in Computer Science, pp. 414–425.

Bergmans, L. and M. Aksit (1995) “Composing Synchronization and Real-Time Constraints,” In Proceed-ings of the Object Oriented Real-Time Systems (OORTS) Workshop, San Antonio, TX. In conjunctionwith 7th IEEE Symposium on Parallel and Distributed Computing Systems.

Bernstein, P.A. (1996), “Middleware – A Model for Distributed System Services,” Communications ofthe ACM 39, 2, 86–98.

Cooper, G., L.C. DiPippo, L. Esibov, R. Ginis, R. Johnston, P. Kortman, P. Krupp, J. Mauer, M. Squadrito,B. Thuraisingham, S. Wohlever, and V.F. Wolfe (1997), “Real-Time CORBA Development at MITRE,NRaD, Tri-Pacific and URI,” In Proceedings of IEEE Workshop on Middleware for Distributed Real-Time Systems and Services, IEEE, San Francisco, CA, pp. 69–74.

Feng, W., U. Syyid, and J.W.-S. Liu (1997) “Providing for an Open, Real-Time CORBA,” In Proceed-ings of IEEE Workshop on Middleware for Distributed Real-Time Systems and Services, IEEE, SanFrancisco, CA, pp. 75–80.

Frølund, S. (1996), Coordinating Distributed Objects: An Actor-Based Approach to Synchronization,MIT Press.

Frølund, S. and G. Agha (1993), “A Language Framework for Multi-Object Coordination,” In Proceedingsof the European Conference on Object Oriented Programming (ECOOP) ’93, O. Nierstrasz, Ed.,Lecture Notes in Computer Science, Vol. 707, Springer-Verlag, Kaiserslautern, Germany, pp. 346–360.

Gerber, R. and I. Lee (1989) “Communicating Shared Resources: A Model for Distributed Real-TimeSystems,” In Proc. Real-Time Systems Symposium, IEEE, Santa Monica, CA, pp. 68–78.

Gerber, R. and I. Lee (1992) “A Layered Approach to Automating the Verification of Real-Time Systems,”IEEE Transactions on Software Engineering 18, 9, 768–784.

Group, O.M. (1996), “Realtime CORBA – A White Paper – Issue 1.0,” Technical Report ORBOS/96-09-01, Object Management Group.

Kalogeraki V., P. Melliar-Smith, and L. Moser (1997), “Soft Real-Time Resource Management in CORBADistributed Systems,” In Proceedings of IEEE Workshop on Middleware for Distributed Real-TimeSystems and Services, IEEE, San Francisco, CA, pp. 46–51.

Kiely, D. (1998), “Are Components the Future of Software,” IEEE Computer 32, 2, 10–11.Kirk, B., L. Nigro, and F. Pupo (1997), “Using Real Time Constraints for Modularisation,” In Joint

Modular Language Conference, Linz.Nicollin, X., J. Sifakis, and S. Yovine (1992), “Compiling Real-Time Specifications into Extended Au-

tomata,” IEEE Transactions on Software Engineering 18, 9, 805–816.Ren, S. (1997), “An Actor-Based Framework for Real-Time Coordination,” Ph.D. thesis, Department

Computer Science, University of Illinois at Urbana-Champaign.Ren, S. and G. Agha (1995), “RT-Synchronizer: Language Support for Real-Time Specifications in

Distributed Systems,” ACM Sigplan Notices 30, 11. Also in Proceedings of the ACM Sigplan 1995Workshop on Languages, Compilers, and Tools for Real-Time Systems.

Ren, S. and G. Agha (1998), “A Modular Approach for Programming Embedded System,” In Lectures onEmbedded Systems, Lecture Notes in Computer Science, Vol. 1494, F. Vaandrager and G. Rozenberg,Eds., Springer-Verlag, pp. 170–207.

Ren, S., G. Agha, and M. Saito (1996), “A Modular Approach for Programming Distributed Real-TimeSystems,” Journal of Parallel and Distributed Computing 36, 1, 4–42.

Saksena, M., P. Freedman, and P. Rodziewicz (1997), “Guidelines for Automated Implementation ofExecutable Object Oriented Models for Real-Time Embedded Control Software,” In 18th IEEE Real-Time Systems Symposium, IEEE, pp. 240–251.

Page 26: Towards reusable real-time objects

282 B. Nielsen, G. Agha / Towards reusable real-time objects

Satoh, I. and M. Tokoro (1994), “Semantics for a Real-Time Object-Oriented Programming Language,”In Int. Conf. on Computer Languages, IEEE, Toulouse, France, pp. 159–170.

Schmidt, D.C., R. Bector, and D.L. Levine (1997), “An ORB Endsystem Architecture for StaticallyScheduled Real-Time Applications,” In Proceedings of IEEE Workshop on Middleware for DistributedReal-Time Systems and Services, IEEE, San Francisco, CA, pp. 52–60.

Schmidt, D.C. and M.E. Fayad (1997a), “Lessons Learned Building Reusable OO Frameworks for Dis-tributed Software” Communications of the ACM 40, 10, 85–87.

Schmidt, D.C. and M.E. Fayad (1997b), “Object-Oriented Application Frameworks,” Communications ofthe ACM 40, 10, 32–38.

Schneider, S. “An Operational Semantics for Timed CSP,” Information and Computation 116, 193–213.Selic, B., G. Gullekson, and P.T. Ward (1994), Real-Time Object-Oriented Modeling, Wiley Professional

Computing, Wiley, New York.Sha, L., R. Rajkumar, and S.S. Sathaye (1994), “Generalized Rate-Monotonic Scheduling Theory:

A Framework for Developing Real-Time Systems,” Proceedings of the IEEE 82, 1 68–82.Zhou, P. and J. Hooman (1992), “A Proof Theory for Asynchronously Communicating Real-Time Sys-

tems,” In Proc. Real-Time Systems Symposium, IEEE, Phoenix, AZ, pp. 177–186.