Event-Driven Support of Real-Time Sentient Objects

Paulo Verıssimo and Antonio Casimiro{pjv,casim}@di.fc.ul.pt

Univ. of Lisboa, Portugal∗

Abstract

The emergence of applications operating indepen-dently of direct human control is inevitable. Researchon high-level models for this class of applications—e.g. on autonomous agents and distributed AI— hasrevealed the shortcomings of current architectures andmiddleware interaction paradigms. If we focus on com-plex real-time systems made of embedded components,that evidence is even more striking. Event models haveshown to be quite promising in this arena, but theyoften lack one or several of the following key points:seamless integration with a programming model; ade-quate layer structure; and the provision of support fornon-functional attributes, such as timeliness or qualityof service, or security. This paper discusses infrastruc-tural support to construct large-scale proactive applica-tions based on the use of real-time sentient objects, andis specially devoted to the latter two points.

1 Introduction

The emergence of applications operating indepen-dently of direct human control is inevitable. In fact,with the increasing availability of technologies to sup-port accurate and trustworthy visual, auditory, and lo-cation sensing [11] as well as the availability of conve-nient paradigms for the acquisition of sensor data andfor the actuation on the environment [1], a new classof large-scale decentralized and proactive applicationscan be envisaged.

However, research on high-level models for this classof applications— e.g. on autonomous agents and dis-tributed AI— has revealed the shortcomings of currentarchitectures and middleware interaction paradigms.Dealing with highly dynamic interactions and con-tinuously changing environments and, at the sametime, with needs for predictable operation, is still an∗Navigators Home Page: http://www.navigators.di.fc.ul.pt.

This work was partially supported by the EC, through projectIST-FET-2000-26031 (CORTEX), and by the FCT, though theLarge-Scale Informatic Systems Laboratory (LaSIGE).

open challenge. If we focus on complex real-time sys-tems made of embedded components, then even morestringent requirements have to be taken into account,namely to achieve distributed, safe and timely processcontrol. In this context, the provision of adequate in-teraction paradigms is a fundamental aspect [2]. Typ-ical characteristics of this class of applications, such asautonomy or mobility must be accommodated, whileallowing the possibility to handle non-functional re-quirements like reliability, timeliness or security.

In contrast with the client/server or RPC basedparadigms supported by current state-of-the-artobject-oriented middleware [13, 8], event models haveshown to be quite promising in this arena [9, 15],but they often lack one or several of the followingkey points: seamless integration with a programmingmodel; architectures with an adequate layer structure;and the provision of support for non-functional at-tributes. This paper is specially devoted to the lattertwo points, in the context of the IST CORTEX project(http://cortex.di.fc.ul.pt), which is concerned with theinfrastructural support to construct large-scale proac-tive applications based on the use of real-time sen-tient objects. CORTEX proposes an object-orientedprogramming model based on anonymous event-basedcommunication [16]. In broad terms, the system modelis composed of the environment and a set of sentientobjects, which are capable of sensing the former andact on it, and cooperate with each other.

Now, how to architect such a system, namely howto define placement and composition rules for softwarecomponents, when our objects are often embedded sys-tems, or collections thereof, where the differences be-tween hardware and software are sometimes subtle?That is, we no longer have the acquired principle thathas guided modular and distributed systems design foryears [10]: there are hosts, which we put where we wantin the system, and there are software components, e.g.objects, which we put in some host, and which we canmove, migrate, replicate, etc, with a desired propertycalled transparency. The solution we propose is basedon a component-based object model [7]. This breakswith the traditional separation between the software

1

and hardware perspectives, pointing to seeing objectsas mixed hardware/software components, although it isobviously possible to conceive an object as a software-only component.

Another problem in the context of architecture isthe handling of the information flow in the system.Here, we wish to break with the traditional real-timesystems view, which makes a neat separation betweenthe physical flow of information through the environ-ment and the message-based flow inside the computersystem— the input/output subsystem being the barrierbetween the two. We propose that the event modeltreats physical and computer event propagation in auniform way, and discuss the resulting advantages. Forthat, we define an adequate event middleware architec-ture based on the notion of generic events, which wecall the Generic Events ARchitecture (GEAR).

This addresses the functional part of event han-dling, but is not enough. Non-functional properties areparamount in systems dealing with the environment,and in the paper we briefly discuss two questions whichare particularly relevant in the context of sentient ob-jects: temporal consistency as the key criterion for con-sistency of operations on time-value entities; and thedependable management of end-to-end QoS.

The paper is structured as follows. Next sectiondescribes a component-based object model that buildson some of the ideas proposed in the CORTEX project.Then, Section 3 introduces the GEAR architecture tosupport the described object model. In Section 4 wefocus on an example application scenario, in which weexercise some of the concepts and solutions proposedin the paper, and discuss the temporal consistency andQoS issues.

2 A Component-based Object Model

The approach proposed in this paper to architec-turally structure applications composed of sentient ob-jects is based on a component-based object model thatincorporates some of the ideas developed in the contextof the CORTEX project.

CORTEX assumes that a new class of applicationscan be envisaged, which is composed of a (possiblylarge) number of smart components that are able tosense their surrounding environment and interact withit. These components are referred to as sentient ob-jects. The basic CORTEX object metaphore was pre-sented in [6] (see Figure 1). Sentient computing es-tablished the generic concept, presented in [12], elabo-rated in CORTEX in the context of object components.Generically speaking, sentient objects are objects thataccept input events from a variety of different sources(including sensors, but not constrained to that), pro-cess them, and produce output events, whereby they

actuate on the environment and/or interact with otherobjects.

� � � � � � � �� � � � � �

� ���

����������

� ���

���������

Figure 1. The sentient object metaphor.

Sentient objects can take several different forms:they can simply be software-based components, butthey can also comprise mechanical and/or hardwareparts, amongst which the very sensorial apparatus thatsubstantiates “sentience”, mixed with software compo-nents to accomplish their task. We refine this notion byconsidering a sentient object as an encapsulating entity,a component with internal logic and active processingelements to transform sensorial information received asinput events, and output events in the course of it. Thisinterface hides the internal hardware/software struc-ture of the object, which may be complex, and shieldsthe system from the low-level functional and temporaldetails of controlling a specific sensor or actuator.

Furthermore, given the inherent complexity of theenvisaged applications, the number of simultaneous in-put events and the internal size of sentient objects maybecome too large and difficult to handle. Therefore, itshould be possible to consider the hierarchical compo-sition of sentient objects so that the application logiccan be separated across as few or as many of theseobjects as necessary. On the other hand, compositionof sentient objects should normally be constrained bythe actual hardware component’s structure, prevent-ing the possibility of arbitrarily composing sentient ob-jects. This is illustrated in Figure 2, where a sentientobject is internally composed of a few other sentientobject, each of them consuming and producing events,some of which only internally propagated.

To provide an example of such component-awareobject composition, we take a robot having as com-ponents the several axes and manipulator controllers:each of these controllers together with the control soft-ware may be a sentient object. The robot itself maythen be a (composite) sentient object, composed of theobjects materialized by the controllers, and the envi-ronment internal to its own structure, or body. Thesame reasoning can be applied to a car, with its inter-nal components. The car body (together with its em-bedded software) may be a sentient object, composedof several simpler objects, like: WLAN receiver andtransmitter card and driver; velocity sensor processor;cruise speed control processor and actuator; dopplerradar control; GPS CCD camera input treatment mod-

2

Figure 2. Component-aware sentient objectcomposition.

ules; control elements such as cruise speed, platoon,ambient, visual display, etc. Note that in this systemit makes no sense migrating the cruise control softwareto the ambient control hardware module— it shouldobviously be attached to the relevant control hardware.Distribution and location transparency/independencymay still be desirable to a certain extent, but they mustbe addressed in the context of well-formed sentient ob-jects that obey the component-aware structuring andcomposition approach.

� � � �

� � � �

� � � �

� � � � � � �

� � � �

� � � � � �

� � � � �

� � � � � � � � � � � � � � � � �� � � � � � � � � � �

� � � � � � � � � � � � � � � � �� � � � � � � � � � �

� � � � � � � � �

� � � � � � � �� � � � � � � � � � � � ! �

� � � � � � � � �

" � # $ � � � � � � � � � � % � � $ � & � & � � �

� � � � � � � � �" � # $� � � � � � & � � � # � % � � � � �

� � � � � � � � �

� � � � � � � �� � � � � � � � � � � � � ' � � � �

Figure 3. Information flow through a sentientobject (C.E- control element).

Figure 3 shows the perspective of a fully-fledged sen-tient object, for example a car, receiving events fromvarious different sources, namely operational networks(e.g., WLAN receiver), remote sources (e.g., GPS re-ceiver) or local sources (e.g. velocity sensor). Likewise,the object produces events to be consumed by differ-ent sinks, for instance events transmitted through net-works (e.g., WLAN transmitter) to the environmentor other objects, events to remote sinks (e.g., dopplerradar actuator) or events to local sinks (e.g., speed con-trol actuator). Note that interactions within the localscope are referred to as interactions with the body ofthe object. This concept will be developed in the nextsection.

Although literature has classically studied the net-working and sensing/actuating problems in isolation,we propose the innovative concept of generic event, beit derived from the boolean indication of a door openingsensor, from the electrical signal embodying a networkpacket (at the WLAN aerial) or from the arrival of atemperature event message.

In fact, what happens with classical event/objectmodels is that they are software oriented. As such,when transported to a real-time, embedded systemssetting, their harmony is cluttered by the conflict be-tween, on the one side, send/receive of “software”events (message-based), and on the other side, in-put/output of “hardware” or “real-world” events,register-based. In fact, very often, the only “event”characteristic in “software” events is the arrival ofthe event-message itself (e.g., when it merely car-ries the state of a variable or an information to an-other object). If such classical desiderata of dis-tributed systems such as distribution and locationtransparency/independency are to be realized to a cer-tain degree, this conflict must be solved.

Furthermore, sentient objects deal with real-time as-pects involving the environment. It has been shownthat the hidden channels developing through the lat-ter (e.g., feedback loops) may hinder software-basedalgorithms ignoring them. Likewise, the programs run-ning in sentient objects have very often consistency re-quirements that derive, even if remotely, from whatare called real-time entities, in fact representations ofstate variables of the surrounding environment. Someof these, referred to as time-value entities, have consis-tency conditions based on the timeliness of the opera-tions controlled by the computer, vis-a-vis their evolu-tion in the environment (e.g., for the cooling system toconsistently use the temperature of the engine it mustobey some timeliness constraints) [18].

To fulfil this vision, we require an event model thatsatisfies these two sets of requirements, respectively offunctional and non-functional nature. That is, a modelthat treats the information flow through the wholecomputer system and environment in a seamless way,handling “software” and “hardware” events uniformly.On the other hand, one that allows defining global,end-to-end, non-functional criteria in the time domain,such as temporal consistency, or QoS guarantees. Weaddress these issues in the forthcoming sections.

3 Architecture

Given the component-based object model presentedabove, we should seek the right architecture to sup-port it. This architecture must be sufficiently genericto encompass all the possible flows of information inthe system and support the compositional approach

3

described earlier but, at the same time, one with suf-ficient expressiveness to allow the identification of theseveral entities that make up the system, including theenvironment, the hardware and the software compo-nents.

We propose the Generic-Events Architecture(GEAR), depicted in Figure 4, which we describe inwhat follows. The L-shaped structure is crucial to en-sure some of the properties described.

� � � � � �� � � � � �� � � � � �

� � � � � � � �

� � � �

� � � � � � � �

� � � �

� � � �

� � � � � � � �

� � � �

� � � � � � � �

� � � �

� � � � � � � �� � � � � � � � � � � � � � � � � � � � � � � �

� � � � � � � � � � � � � � � � � � �

� � � � � � � �

� � � �

� � � �

� � � �

� � � �

� � � �

� � � � � � � �

� � � �

� � � �

� � � � � �

� � � � � �

� � � � � �

� � � � � �

� � � � � �

� � � � � �

� � � � � �

� � � � � �� � � � � � � � � � � � � � � � � �� � � � �

Figure 4. Generic-Events architecture.

Environment The physical surroundings, remote andclose, solid and etherial, of sentient objects.

Body The physical embodiment of a sentient object(e.g., the hardware where a mechatronic controllerresides, the physical structure of a car). Note thatdue to the compositional approach taken in ourmodel, part of what is ’environment’ to a smallerobject seen individually, becomes ’body’ for alarger, containing object. In fact, the body is the‘internal environment’ of the object. This archi-tecture layering allows composition to take placeseamlessly, in what concerns information flow.

Translation Layer The layer responsible for physi-cal event transformation from/to their native formto Event Channel (EC) dialect, between Environ-ment/Body and Event Channel. Essentially onedoing observation and actuation operations on thelower side, and doing transactions of event descrip-tions on the other.

Event Channel The layer responsible for event prop-agation in the whole system. This layer is a

kind of middleware that provides important event-processing services which are crucial for any real-istic event-based system. For example, some ofthe services that imply the processing of eventsmay include publishing, subscribing, discrimina-tion, zoning, filtering, fusion and queuing.

Communication Layer The layer responsible for’wrapping’ events (as a matter of fact, eventdescriptions in EC dialect) into ’carrier’ event-messages, to be transported to remote places. Forexample, a sensing event generated by a smart sen-sor is wrapped in an event-message and dissemi-nated, to be caught by whoever is concerned. Thesame with an actuation event produced by a sen-tient object, to be delivered to a remote smartactuator. Likewise, this may apply to an event-message from one sentient object to another.

Regular Network This is represented in the hori-zontal axis of the block diagram by the Com-munication Layer, which encompasses the usualLAN, TCP/IP, and real-time protocols, desirablyaugmented with reliable and/or ordered broadcastand other protocols.

The Generic-Events Architecture (GEAR) intro-duces some innovative ideas in distributed systems ar-chitecture, which we discuss in what follows:

• It serves an object model based on production andconsumption of generic events.• Events are produced by several sources— environ-

ment, body, objects— which are all treated in ahomogeneous way.• There is a basic dialect for talking about events,

used in all transactions by the Event Channel.• The Translation Layer performs the transforma-

tion between the physical representation of a real-time entity and the EC compliant format, in eitherdirection.• The Event Channel propagates events through

Regular Network infrastructures, via regularmessage-passing protocols.• The flow of information (external environment and

computational part) is seamlessly supported bythe L-shaped architecture.

The GEAR architecture serves an object modelbased on production and consumption of genericevents. A generic event in our model is a happeningthat requires the attention of objects which showed aninterest on (subscribed) this class of happenings. Anevent is then consumed by the object when it hap-pens. Events are presented to objects through an EventChannel, which is in charge of propagating them to therelevant objects (those having subscribed to that eventclass). However, not only objects produce or consume

4

events, but this is transparent, since it is dealt withby ensuring all these entities (objects and other) speakthe EC dialect.

Events are produced by several sources which aretreated in a homogeneous way. Event sources include:

• the environment where physical events take place,such as the detection of the opening of a gate, orof the change of a semaphore light, the samplingof a temperature at a given time.• the body of the object (or object compound),

taken as that part of the environment which isaggregated to the object or object compound andwould not make sense otherwise (e.g., the body ofa robot, the hardware of a car, the embodiment ofa mechatronic device), and where similar kinds ofphysical events take place, for example, the sam-pling of a car’s velocity. Note that part of what is’environment’ for an isolated object, may become’body’ of a compound object of which that objectis part.• the objects themselves may generate an event,

when they invoke produce, which manifests itselfas: a piece of information or a command they wishto make available to other objects; a notificationthey produce “to whom it may concern”; an ac-tuation command on the body or on the environ-ment, for example, controlling the speed of a car,or telling a gate to close.

There is a basic dialect for talking about events,used in transactions by the Event Channel. Any entityspeaking this dialect is capable of producing events tobe propagated by the Event Channel to the relevantparts of the system, and of consuming events whichare propagated by the EC. Some of these entities aresentient objects, which are capable of perceiving theseevents and perform processing on them. Other enti-ties are simpler: smart transducers, sensors and actu-ators. They deserve the ’smart’ adjective because theyspeak the EC dialect. However, they are limited intheir ability: sensors can only generate EC compliantevents which report what they sensed; actuators canonly consume EC compliant events requesting an actu-ation, and perform the requested action.

The Translation Layer performs the transformationbetween the physical representation of a real-time en-tity and the EC compliant format, in either direction.Note that a special kind of device, represented in Fig-ure 4 by an antenna, was introduced to denote that,unlike what happens in many models, it is necessaryto englobe the operational network transmission andreception in the translation layer activity, and not inthe regular network activity. By operational network-ing we mean network activity further to the regularpacket passing network of a distributed system. Thisis very typical of real-time systems, namely those con-

taining embedded components, and materializes in theform of I/O fieldbuses, IR beaming to control remoteactuators, or radio beam reception from remote sen-sors.

The propagation mission assigned to the EventChannel is performed by Regular Network infrastruc-tures (Ethernet, Internet, WLAN, RTLAN), throughregular message-passing protocols. However, they mustensure whatever real-time, reliability and consistencyproperties are required of the relevant implementa-tion [14]. The Communication Layer features proto-cols capable of enforcing the consistency properties ofthe information flow across the event channel platform,as suggested by the shade uniting local EC modules.The distributed EC is in fact a middleware platform,and its functionality may be completed by functionssuch as: routing, filtering, enforcement of delivery se-mantics. For example, filtering requires event channelsto be identified by a subject, over which filtering canbe performed. There exist approaches using content-based addressing over single channels [3], but this re-quires filtering every message. More appropriate in sen-tient environments is to use subject-based filtering, inwhich every event channel is identified by a particularsubject. To improve performance, at the expenses ofextensibility and anonymity, it is possible to bind eventchannels to the addressing mechanisms of the underly-ing network infrastructure.

The proposed architecture supports the flow of in-formation in a number of different ways, as illustratedin Figure 5, which demonstrates the expressiveness ofthe model with regard to the necessary forms of infor-mation encountered in real-time cooperative and em-bedded systems. Smart sensors produce events whichreport on the environment. Body sensors produceevents which report on the body. They are dissemi-nated by the local EC module, through the RegularNetwork, to any relevant remote EC modules whereentities showed an interest on them, normally, sentientobjects attached to the respective local EC modules.Sentient objects consume events they are interested in,process them, and produce other events. Some of theseevents are destined to other sentient objects. They arepublished on the EC using the same EC dialect thatserves, e.g., sensor events. However, these events aresemantically of a kind such that they are to be sub-scribed by the relevant sentient objects, for example,the sentient objects composing a car computer system.Smart actuators, on the other hand, merely consumeevents produced by sentient objects, whereby they ac-cept and execute actuation commands. Alternativelyto “talking” to other sentient objects, sentient objectscan produce events of a lower level, for example, ac-tuation commands on the body or environment. Theypublish these exactly the same way: through the lo-cal EC representative. Now, if these commands are of

5

concern to local actuator units (e.g., body, includinginternal operational networks), they are passed on tothe local Translation Layer. If they are of concern to aremote smart actuator, they are disseminated throughthe distributed EC, to reach the former. In any case,if they are of interest to other entities, such as othersentient objects that wish to be informed of the actua-tion command, then they are disseminated on the ECto these sentient objects. A key advantage of this ar-chitecture is that messages and events can be globallyordered since they all pass through the event channel.

� � � � �� � � � �

� � � � � � � � � � �

� � � � � � � �

� �� � � � �

� � � �� � �

� � � �� � �

� � � �� � �

� � � �� � �

� �� � � � �

� � � � � � � �

� � � � �

� � � � � �

� � � � �� � � � �

� � � � � � � � � � �

� � � � � � � � �

� � � �� �

� � � � � � � � � � �

� � � �� � � � � � � � � �

� �

� �

� � � �

Figure 5. Information flow in the whole sys-tem.

One of the fundamental challenges we address in thispaper is the provision of support for non-functional re-quirements. Our focus is on the aspect of timeliness. Inorder to deal with real-time sentient objects we need tounderstand the implications of timeliness requirementsin the context of the proposed generic-events architec-ture. This can be done by establishing fundamentalcorrectness criteria for the operation of the system.The system architecture, including the protocols andmechanisms lying in the middleware (which, in fact,can be part of the Event Channel), must be built sothat the strict observation of the established criteriais ensured. Given the distributed nature of the prob-lem, the correctness of the operation does not dependsolely on the observation of timeliness constraints, butalso on the consistency and coordination among thedistributed actors in the system. In this respect, notethat the information flow is defined in terms of events,and it is controlled at the Event Channel, where ev-erything passes. As such, and very importantly, all

consistency criteria that we define as to be secured bythe EC, apply as well to regular messages, messagesthrough other, operational network channels, and in-put/output feedback paths through the environment.In this architecture, no hidden channel problems affectthe operation of the system [18].

Before proceeding, we need to define events moreprecisely. A generic event is a happening that takesplace in the event channel at a given instant of thetimeline, 〈 E,T 〉. The happening is internal to the sys-tem, has an event-channel-compliant representation,and is not necessarily related with physical events tak-ing place in the environment. That is, the ’event’ isthe happening as seen by the event channel, at a giveninstant of the timeline.

In the following section we present a small exampleto illustrate how an event channel aware of timelinessrequirements can be used in a concrete scenario.

4 A Cooperating Cars Scenario

An interesting scenario to exercise some of the ideaspresented in this paper, is one involving several sentientobjects operating and interacting with their environ-ment, and where the correct operation of the whole sys-tem requires some timeliness requirements to be met.A cooperating cars scenario provides all these ingredi-ents [5].

Modern cars make an increasing use of sensor tech-nology and advanced mechatronic systems. It is ex-pected that in a near future they will be equipped withall kinds of sensors, for the diagnosis of internal com-ponents, to let them know their exact position, for thedetection of obstacles, for the evaluation of weather androad conditions, etc. Based on all this information itwill be possible to automate several controls and func-tionalities, specially all those not involving any safetyissues. However, the automatic control of critical func-tions is a more challenging objective. The fundamentalproblem is that it is not possible to construct an exact’image’ of the surrounding environment, and thereforethere is a risk of making wrong decisions based on in-complete or inaccurate information. Moreover, the en-vironment is continuously changing, which introducesan additional time dimension that must also be takeninto account. In fact, the intrinsic problem is that ofunpredictability, which must be addressed in the con-text of adequate models and solutions.

In the scenario we consider, there may exist severalcars (sentient objects) with the ability to ’consume’events from the environment and ’produce’ events toit, trying to perform some function inside a restrictedarea, call it a zone, requiring the ability to perceivethe environment and control their operation. We obvi-ously model our system using the GEAR architecture,

6

which implies that there exist Event Channels throughwhich events are disseminated and received. Becausethere are several cars, the fundamental safety rule con-sists in ensuring that no car crashes occur (to focus ourdiscussion, we do not consider other, static, obstacles).To satisfy this safety rule, each car must obviously beaware of each other car position. Therefore, we assumethat each car periodically disseminates its position tothe environment, which will be used by the interestedcars (namely those lying in its proximity).

One possible way to achieve this would be by provid-ing to all of them a temporally consistent image of theexternal environment, and one that would be consis-tent with each one’s internal environment (what theirbody tells them), e.g., the coordinates and attitude ofa car, and the state of internal variables. Smart sensorspublish events about the relevant real-time entities ofthe environment. Body sensors do the same with re-spect to the body. These events define the state ofthe zone (the part of the environment circumscribed toa given zone). Now, suppose all sentient objects fea-ture a module, call it constructor, in charge of buildinga real-time image of the zone. The constructor sub-scribes to the environment and body events, as well asto any relevant events produced by the other objects.The external environment events contribute to form apublic RT Image of the zone. That image is enrichedwith inputs from other objects, and from the object’sown body, part of which may or not be made public.What is important is that all these events obey globalconsistency rules.

�

� � � � � � � � � � � � � � � � � �� � � � � � � � � � � � � � � �

�

�

Figure 6. Safety rules in the cooperating carsscenario.

The safety rule is illustrated on the left of Figure 6.At every instant, each car must know the position of allother cars with a bounded error (ε). This error dependson how much time has passed since the position of acar was disseminated and on the maximum speed ofthat car. Therefore, both of them must be bounded.The control safety rule that must be satisfied is thatthe grey car cannot ’enter’ inside the dashed circles.

The problem would be easily solvable if we could

assume a reliable and timely propagation of eventsthrough EC modules. In such a traditional hard real-time approach, the system would be configured so thatat every P time units the grey car would receive infor-mation from the black car (see Figure 6 on the right).Every car would be able to construct a real-time im-age of the environment (of the surrounding cars) witha bounded accuracy (related with the propagation la-tency, ∆, and the period P), and all the images wouldbe consistent among them. Then, every car wouldconsistently decide what to do. However, because weare assuming a distributed environment, possibly withmany cars disseminating events to a shared event chan-nel, we have to consider the uncertainty of the environ-ment. Hence, we also have to solve the conflict betweenthis uncertainty and the requirements for timeliness(that is, ensuring bound ∆).

The problem of operating in uncertain environmentsis that timing bounds (e.g., like those resulting fromtemporal consistency constraints) may be violated be-cause of timing failures. Therefore, when executing inuncertain environments, applications with timelinessrequirements must be able to deal with timing fail-ures. We assume our architecture, despite uncertaintyof communication, is endowed with perfect timing fail-ure detection, such as supported by a timely computingbase (TCB) [17]. Fail-safe applications deal with tim-ing failures simply by switching to a fail-safe state assoon as a timing failure occurs. In that way, they avoidany misbehavior and they preserve safety. This is onlypossible, however, if the failure is timely detected, be-fore there is time to do anything wrong. The timelytiming failure detection and timely execution of safetyprocedures can be done with the help of the TCB ser-vices.

Considering our cooperating cars scenario, it is quiteeasy to see that there exists a fail-safe state to whicha car can switch if anything goes wrong: it just has tostop. Hence, it would be possible to construct an ECmodule with associated timeliness requirements (trans-lated into timing bounds) and, simultaneously, use theadequate constructs to ensure that, would the real-timeview of the environment at that car become temporallyinconsistent, it would immediately stop. In this exam-ple, it is also clear that the car would be able to startmoving again, as soon as its view of the environmentwould become consistent again.

Note that it would be possible to relax the timingbounds assumed for the propagation of events throughthe event channel, in order to reduce the probability ofthe occurrence of timing failures (and hence the prob-ability of a car stopping). However, unless the positionwere disseminated more frequently, this would increasethe error bound (ε) associated to the local image ofthe environment (which is also not good). To keep theerror while increasing the assumed timing bounds, it

7

would be necessary to reduce the allowed maximumspeed. As a matter of fact, the possibility of adjust-ing the maximum car speed along with the assumedtiming bound would be allowed for applications of thetime-elastic class, that is, applications where boundsare automatically adjusted with the QoS of the sup-porting runtime environment [4].

But the relevant question has to do with knowingwhen and how to make the adjustments in order tohave better results (i.e., for a car to keep moving, pos-sibly slower, but never stopping because of a timingfailure). Note that if the environment does not change,then it is not necessary to make any adjustments (as-suming that the operational state is already the best).On the other hand, when the environment changes,the system should adapt to the new conditions. Oncemore, this problem may be solved by dependably esti-mating the state of the environment and deciding howto adapt. That is, by measuring the timeliness of theevent channel, and making these measurements avail-able to all EC modules: this would allow all relevantcars to adapt consistently.

5 Conclusion

We discussed an innovative model and architectureto support event-based object-oriented programmingon real-time cooperative and embedded systems. Thecomponent-based approach to object definition is veryimportant, as it reflects well the nature of the targetsystems. The body-environment duality is key to re-cursive composition in the model. The L-shaped blockdiagram allows the harmonious confluence of physicaland computerized information flows. To our knowl-edge, it is the first architecture to provide hidden chan-nel avoidance in the model, that is, a seamless integra-tion of physical and computer information flows. Thismay have important implications on the way to ar-chitect embedded systems, which we intend to explorein future papers. The generic event concept provides acommon representation inside the system for what usedto be “state” and “event” messages, and this opens anavenue for the integration of event-triggered and time-triggered operation, a subject of current importance inembedded systems.

References

[1] M. Addlesee, R. Curwen, S. Hodges, J. Newman,P. Steggles, A. Ward, and A. Hopper. Implementing asentient computing system. IEEE Computer, 34(8):50–56, aug 2001.

[2] J. Bacon, K. Moody, J. Bates, R. Hayton, C. Ma,A. McNeil, O. Seidel, and M. Spiteri. Generic sup-port for distributed applications. IEEE Computer,33(3):68–76, 2000.

[3] N. Carriero and D. Gelernter. Linda in context. Com-munications of the ACM, 32(4):444–458, apr 1989.

[4] A. Casimiro and P. Verıssimo. Using the timely com-puting base for dependable qos adaptation. In Pro-ceedings of the 20th IEEE Symposium on Reliable Dis-tributed Systems, pages 208–217, New Orleans, USA,Oct. 2001. IEEE Computer Society Press.

[5] Definition of application scenarios. CORTEX project,IST-2000-26031, Deliverable D1, Oct. 2001.

[6] Preliminary definition of cortex programming model.CORTEX project, IST-2000-26031, Deliverable D2,Mar. 2002.

[7] I. Crnkovic and M. Larsson, editors. Building ReliableComponent-Based Software Systems. Artech HousePublishers, 2002.

[8] O. M. Group. The common object request broker: Ar-chitecture and specification. Technical Report OMGDocument 96-03-04, July 1995.

[9] T. Harrison, D. Levine, and D. Schmidt. The de-sign and performance of a real-time corba event ser-vice. In Proceedings of the 1997 Conference on ObjectOriented Programming Systems, Languages and Appli-cations (OOPSLA), pages 184–200, Atlanta, Georgia,USA, 1997. ACM Press.

[10] A. J. Herbert, J. Monk, and R. van der Linden.The ANSA Reference Manual, Release 1.1. Architec-ture Projects Management, Ltd, Cambridge, UK, July1989.

[11] J. Hightower and G. Borriello. Location systems forubiquitous computing. IEEE Computer, 34(8):57–66,aug 2001.

[12] A. Hopper. The clifford paterson lecture, 1999 sentientcomputing. Philosophical Transactions of the RoyalSociety London, 358(1773):2349–2358, Aug. 2000.

[13] M. Horstmann and M. Kirtland. Dcom architecture.http://www.microsoft.com/jini/specs/.

[14] J. Kaiser and M. Mock. Implementing the real-timepublisher/subscriber model on the controller area net-work (CAN). In Proceedings of the 2nd InternationalSymposium on Object-oriented Real-time distributedComputing (ISORC99), Saint-Malo, France, May 1999.

[15] R. Meier and V. Cahill. Steam: Event-based mid-dleware for wireless ad hoc networks. In Proceedingsof the International Workshop on Distributed Event-Based Systems (ICDCS/DEBS’02), pages 639–644, Vi-enna, Austria, 2002.

[16] P. Verıssimo, V. Cahill, A. Casimiro, K. Cheverst,A. Friday, and J. Kaiser. Cortex: Towards support-ing autonomous and cooperating sentient entities. InProceedings of European Wireless 2002, Florence, Italy,Feb. 2002.

[17] P. Verıssimo and A. Casimiro. The Timely ComputingBase model and architecture. Transaction on Comput-ers - Special Issue on Asynchronous Real-Time Sys-tems, 51(8), Aug. 2002. A preliminary version of thisdocument appeared as Technical Report DI/FCUL TR99-2, Department of Computer Science, University ofLisboa, Apr 1999.

[18] P. Verıssimo and L. Rodrigues. Distributed Systems forSystem Architects. Kluwer Academic Publishers, 2001.

8