An Architecture to Support Dynamic Service Composition in Distributed

Real-Time Systems

Iria Estévez-Ayres Luı́s Almeida Marisol Garcı́a-Valls, Pablo Basanta-Val

Dpto. Ing. Telemática DET / IEETA-LSE Dpto. Ing. Telemática
Univ. Carlos III de Madrid Universidade de Aveiro Universidad Carlos III de Madrid
Leganés, Madrid, Spain Aveiro, Portugal Leganés, Madrid, Spain
[email protected] [email protected] {mvalls, pbasanta}@it.uc3m.es

Abstract applications dynamically from existing services, possibly

remote, enhancing the reuse of code and decreasing the de-
Recently, new trends in application development for dis- velopment time.
tributed platforms, such as the composable services model, The composable service model can also be advanta-
attempt to provide more flexibility in system design, deploy- geously used in the development of distributed real–time
ment and execution. Such trends, and particularly the re- embedded systems, identifying services with clear inter-
ferred composable services model, can also be beneficial faces that are executed according to a specific sequence.
in real–time distributed embedded systems, also providing The services available, possibly with multiple versions, can
a means to support more adaptive behaviors, reacting to be shared among different applications and can change on-
the execution environment or coping with system reconfig- line providing a high level of adaptability to varying op-
uration. This paper explores a relatively new direction, erational conditions, enhancing the efficiency in the use of
which is the extension of the service-based model to dy- system resources [19]. Examples include networked control
namic, i.e. at run–time, composition in real-time distributed systems, where different controllers and filters can be seen
environments, in order to support the level of flexibility and as services that can be shared and updated on-line, and also
adaptibility referred above. The paper proposes an archi- distributed multimedia systems, in which the different ser-
tecture to support such dynamic service composition that vices correspond to filters and encoders/decoders possibly
is based on the Flexible Time Triggered communication with different levels of Quality of Service(QoS).
paradigm (FTT).To achieve the desired goal, we also re- The dynamic composition of services in this kind of ap-
define the concepts of service and service–based applica- plications can be interesting not only from the applications
tion in the concept of the FTT paradigm. Finally, we show development point of view, by means of automatic composi-
experimental results obtained with a prototype implementa- tion of software components, but mainly as a way to support
tion of the proposed architecture that confirm its feasibility on–line updating and reconfiguration of services, for exam-
and good temporal behavior. ple to provide dynamic QoS management, load balancing
and fault tolerance as explained next:

• Dynamic software and hardware updating. Whenever

1 Introduction
a new version of a service appears in the system, it
will be analyzed to check whether the performance of
In the last few years, distributed software systems have the respective application using this new version can
become more dynamic allowing transparent distribution, be improved, according to a pre-specified metric. De-
self-reconfiguration, portability and migration of applica- pending on such analysis, the system might switch ser-
tions, etc. As a consequence, new application development vice versions and recompose the applications that use
paradigms emerged such as those based on the usage of them.
multiple services dispersed in the environment [22]. These
new paradigms, used in conjunction with the composable • Fault Tolerance: Different service implementations
service model, provide more flexibility in the aplication de- are used as backups to assure the survival of the system
velopment and execution. Instead of monolithic applica- if one of the nodes involved falls down. In this situa-
tions resident in one single node, it is possible to create tion, upon a service failure, a failure detector requests

Proceedings of the 10th IEEE International Symposium on

Object and Component-Oriented Real-Time Distributed Computing (ISORC'07)
0-7695-2765-5/07
Authorized$20.00
licensed © 2007
use limited to: ISMAI - Instituto Universitario da Maia. Downloaded on January 13,2024 at 10:31:10 UTC from IEEE Xplore. Restrictions apply.
 the removal of the failed service, causing the applica- flexibility and the timeliness required to support dynamic
tions recomposition with another available version of composition of real-time systems based on services allo-
that service. cated in nodes connected to a real-time network.
The rest of the paper is organised as follows: Section 2
• Load balancing: Whenever the performance of an ap- briefly introduces the background of this work; Section 3
plication degrades because excessive load in a given presents the underlying application model; Section 4 de-
node is causing poor performance to one of its ser- scribes the proposed approach; Section 5 presents prelim-
vices, then the system can look for other versions of inary experimental results; and, finally, Section 6 outlines
that service residing in different nodes and currently the main conclusions.
exhibiting better performance and invoke the recom-
position of the application to exploit those alternatives.
This allows maximizing application performance at 2 Related Work
each moment. Worst-case response time analysis can
be used to deduce the current performance level of a The component service model has been recently applied
given service as a function of the load in the respective to distributed environments such as Ubiquitous Computing
node. and Peer-to-Peer, to develop generic frameworks that allow
providing end–to–end application QoS via QoS–aware mid-
As a practical example consider a vision system for tex- dleware systems [16, 10, 11, 13]. However, these systems
tile inspection based in a parallel computer cluster[3]. Each are not suitable for composing real–time applications since
acquisition node delivers camera frames to one among n the specified QoS does not take into account the underly-
computing nodes. However, acquisition nodes are some- ing hardware and the scheduling requirements of the whole
times idle, for example when the fabric roll is changed, and system.
thus, the load of the computing nodes varies. Using a com- Integration of QoS characteristics into component tech-
positional framework as referred above we can consider the nology has also been studied in [5]. However, these ap-
processing of each vision data stream as an application and proaches aim at a rather static composition environment
distribute the load of the computing nodes on–line to en- and enterprise applications based on components and not
hance the performance of the whole system. Another ex- strictly on services.
ample concerns high availability systems, such as those in- In the real–time world, component–based software de-
volved in energy transportation [6]. A fault tolerance solu- velopment (CBSD) [4, 12] is an emerging development
tion using the dynamic service composition referred above paradigm that enables the transition from monolithic to
can provide the required flexibility, reusability and porta- open and flexible systems. This allows systems to be as-
bility, at a reasonable cost, instead of an ad hoc solution sembled from a pre–defined set of components explicitly
at application level that lacks such attributes and would be developed for multiple usages. However, none of these ap-
more expensive. Also, solutions at hardware and OS–level, proaches can be directly applied to dynamic composition
only, do not solve all dependability problems of those ap- of real–time components (or more generally, applications)
plications as indicated by the end-to-end argument [21]. in a distributed environment because they are focused on
However, in order to be effective for distributed real-time the design phase rather than on the execution phase. Within
embedded systems, the proposed compositional framework the context of reconfigurable real–time systems Tesanovic’s
must allow for on–line addition/removal of services and work [23] on reusable software using aspects and compo-
nodes, transparent code mobility, scalability and continued nents defines a WCET–based composition model for sys-
timeliness. This combination of attributes is not trivial to tems that execute in a single node, thus not being suit-
achieve and requires an adequate arquitectural support. able for distributed applications. Wang’s work [24], on the
Previous work [7, 9] focused on the definition of a frame- other hand, studies the use of aspects and components in
work that allowed performing the off-line composition of a COTS solution, CIAO, the Component–Integrated ACE
static real-time applications from existing downloadable ORB. This solution is too heavy to be applied to distributed
services but this framework did not deal with dynamic dis- embedded systems based on simple microcontrollers.
tributed real-time systems or with the possibility of using Another line of work that bears some relationship with
remote services. In this paper we define a model and pro- the scope of this paper is the use of multiple modes. In a
pose an architecture that integrate techniques inspired by way, multiple modes also correspond to dynamic reconfig-
emerging models of distributed computing for on-line com- urations. Traditionally, real–time systems are assumed to
position of real-time services, offering the possibility of dy- be formed by a fixed set of tasks that are scheduled to fulfil
namic reconfiguration of software and hardware. To build the application requirements and exhibit a desired behavior.
this architecture we use the Flexible Time Triggered (FTT) Applications needing to exhibit more than one behaviour
communication paradigm [17] that provides the operational are known as multi–moded applications [20]. These appli-

Proceedings of the 10th IEEE International Symposium on

Object and Component-Oriented Real-Time Distributed Computing (ISORC'07)
0-7695-2765-5/07
Authorized$20.00
licensed © 2007
use limited to: ISMAI - Instituto Universitario da Maia. Downloaded on January 13,2024 at 10:31:10 UTC from IEEE Xplore. Restrictions apply.
 cations consist in a fixed number of operating modes, each tion, nor the means for service composition. This extension
one producing a different behaviour, implemented by differ- is the main contribution of this paper.
ent task sets. The set of modes is established off–line and
thus, despite the dynamism introduced by allowing on–line 3 Application model
mode changes, the overall run–time flexibility is still lim-
ited, particularly with respect to the level targeted by the ar-
We consider a distributed system executing recurrent ap-
chitecture that we propose in this paper. In fact, we focus on
plications that span over several nodes. Each application is
run–time flexible systems in which the composition of the
composed of a set of services possibly residing in different
applications is not established a priori and can change dur-
nodes and invoked in a given sequence. Services are ma-
ing the system lifetime due to the arrival/departure of new
terialized in tasks, each with worst case computation time
versions of the services that compose the applications, and
Cit and relative deadline Dit . Given the recurrent nature of
due to the possible composition of new applications with
the applications, tasks will also be recurrent with period Tit .
the existing services.
Global synchronization is available thus supporting use of a
More related work can be found in the field of Fault Tol- release offset Oit .
erance, where active, passive and hybrid replication mech- Tasks communicate with each other across the system
anisms have been developed [15]. The architecture pro- exchanging messages which are read in the beginning of
posed in this paper supports a passive replication approach their execution and generated at the end, in every periodic
in which backup services are activated upon the failure of instance. We classify tasks in four groups according to the
active ones. A particular aspect is that previous approaches way they interact with one another. A task needing data
seem to have focused on using similar service or compo- from other tasks is a consumer; a task that generates data
nent instances, replicas, for backup elements. However, in for other tasks is a producer; a task can also be both si-
our case the backups do not need to be similar and can, in- multaneously, i.e., a consumer/producer; tasks that do not
clusively, present different levels of performance or QoS. interact with others are called stand–alone. The tasks in the
When necessary, the system should use the best backup first three groups are generically called interactive and their
service available to compose each application. This may interactions are supported by message–passing with multi-
support more efficient and thus less expensive fault-tolerant cast, i.e. several consumers may receive a message sent by
replication mechanisms. N-version software [1] is a partic- one producer.
ular approach that targets high coverage of software faults. There is no control flow between tasks and mes-
This approach also uses several different versions of each sages. Their interface is based on data buffers which are
software entity but it is normally associated to active repli- read/written by the tasks. Messages are then considered in-
cation and voting mechanisms that are capable of handling dependent entities, triggered autonomously by the network,
broader fault models but are substantially more expensive each with worst-case transmission time Cim , relative dead-
and less flexible than the approach proposed in this paper. line Dim , period Tim and release offset Oim .
In the remainder of the paper we propose and describe Hence, an application corresponds to an ordered graph of
an architecture that explores the FTT paradigm [17] to sup- services (tasks) and the respective interactions (messages)
port dynamic service composition in distributed environ- such as represented in fig. 1(a), which is executed periodi-
ments. The composition is driven by specific performance cally. A corresponding transaction (or data stream as in [2])
(QoS) metrics defined a priori thus being QoS–aware. The is then defined as the sequence of task executions and mes-
FTT paradigm is particularly suited to support this model sage transmissions between the triggering of the first pro-
because it concentrates in a single node, known as FTT– ducer and termination of the last consumer involved in an
master, the temporal properties of all message streams and application. Typically, all tasks and messages in a transac-
tasks currently running in the system, and distributes sched- tion share the same period but not necessarily, such as in
ules for the remaining nodes generated at run–time. Thus, multirate control systems in which inner loops execute at
changes in the system configuration are readily and syn- rates that are integer multiples of a lower rate at which an
chronously applied to the whole system. Moreover, most outer loop executes.
of the system management overhead is concentrated on one If we have multiple implementations (versions) of a task
node, only, i.e., the FTT–master, which can be replicated for on different nodes, e.g. tasks 2A and 2B in fig. 1(b), the
fault tolerance porposes [8], while the remaining nodes can system must decide, according to an appropriate parameter,
be relatively simple. This paradigm has been implemented e.g., the worst–case execution time (WCET), worst–case re-
over Controller Area Network (CAN) [8] using simple 8- sponse time (WCRT) or another QoS metric, which service
bit microcontrollers and over Etheernet, both in shared [18] version will be used to compose the application, using a
and switched [14] modes. However, the FTT paradigm by composer engine. However, for transparent composition we
itself does not provide the notions of service and applica- need a mechanism to hide the existence of different imple-

Proceedings of the 10th IEEE International Symposium on

Object and Component-Oriented Real-Time Distributed Computing (ISORC'07)
0-7695-2765-5/07
Authorized$20.00
licensed © 2007
use limited to: ISMAI - Instituto Universitario da Maia. Downloaded on January 13,2024 at 10:31:10 UTC from IEEE Xplore. Restrictions apply.
 msg1
msg3

4
msg5 msg1 2B msg2B carried out by data buffers, as considered in the application
2

1
msg2 msg4
5
msg1 model above, without explicit control signals.
1 3
3 2A msg2A Beyond the tasks and messages scheduled by the mas-
(a) Distributed application ab- (b) Different versions of service 2 ter, the FTT paradigm also considers the existence of a
straction specific window inside each EC to support the transfer of
non-periodic messages, called asynchronous, e.g., related
2B 3C
msg1 msg2
3B
msg3 to management actions, signalling and logging (CM and
1
2A
3A
4
NRTM). These, however, to do not interfere with the sched-
2
3 uled, i.e., synchronous, messages (SM).
(c) Hidding the different versions EC(i) EC(i+1)

synchronous asynch
window window
Figure 1. Application model abstraction
TM SM2 SM5 SM8 SM9 CM3 NRTM4 TM SM4 SM11 SM9 CM1 NRTM2 NRTM7

mentations of the same service and make it transparent to Figure 2. FTT Elementary Cycle
the other tasks that interact with that service (fig. 1(c)).
Such mechanism is basically a system manager that con- Some important features of the FTT paradigm are: Slave
trols the execution of tasks and transmission of messages nodes are not aware of the particular scheduling policy and
across the distributed system, including the respective mul- the master can change it on–the–fly autonomously or on de-
tiple versions, thus inherently playing the role of composer. mand; Slave nodes are synchronized upon the reception of
To implement this mechanism we use the FTT–paradigm the TM; All dispatching information per EC is conveyed in
that already includes a system manager to control task ex- the TM; The master holds all current timing requirements
ecutions and message transmissions by means of specific of the system; Any changes to such requirements are sub-
trigger messages, and we add the necessary structures to ject to on–line admission control to filter out changes that
support the composition, namely to describe the applica- could jeopardize the system schedulability; The activation
tions and their associated services as well as all the service periods, the deadlines and the offsets are integer multiples
versions available and their properties. of the EC duration.

4.2 Temporal model of an application

4 Applying the model to FTT
In the FTT–paradigm the transmission of messages and
4.1 FTT–paradigm principles the execution of tasks can be triggered independently of
each other by the central scheduler. Alternatively, the
The FTT paradigm [17] uses an asymmetric architecture, scheduler may trigger just the message transmissions while
with one master node controlling multiple slave nodes. The the associated tasks are triggered by the reception of these,
master holds the system requirements (communications and using callback functions. In any case, the application trans-
computations) and executes the scheduling policies and on– actions are triggered by the central scheduler, which resides
line admission control. Since the requirements and opera- in a network component, and thus we call this a network–
tional data and mechanisms are located in just one node, this centric approach [2, 14].
architecture supports fast and atomic changes to the system The network–centric approach requires the definition of
configuration. Master redundancy is used to tolerate master appropriate message offsets to achieve low transaction end-
crashes. to-end delay. In the example shown in fig. 3, messages m1
The scheduling of the tasks and messages is carried out and m2 are scheduled by the central scheduler and trigger
on–line in the master, for a time window called Elementary tasks τ2 and τ3 respectively. Task τ1 is triggered by the cen-
Cycle (EC). At the begining of each EC, the master dis- tral scheduler with offset 0 and represents the start of the
tributes across the system the schedule for that EC, called respective transaction. The offset O2m must be larger but
the EC-schedule, using trigger messages (TMs), fig. 2. The as close as possible to O1m + W1m + W2t where W1m and
TM (see structure in table 1) is the only control message W2t are the worst-case response times of message m1 and
sent per EC and it may trigger the transmission of several task τ2 , respectively, considering all possible interferences.
slave messages, called synchronous messages, and tasks ex- If a new implementation of task τ2 becomes available with
ecutions. These messages use indirect source addressing a shorter C2t , thus shorter W2t , the central manager can re-
with unique identifiers assigned to all sources. Moreover, duce O2m accordingly, thus decreasing the transaction end-
the interface between tasks and synchronous messages is to-end delay. The worst-case response time analysis must

Proceedings of the 10th IEEE International Symposium on

Object and Component-Oriented Real-Time Distributed Computing (ISORC'07)
0-7695-2765-5/07
Authorized$20.00
licensed © 2007
use limited to: ISMAI - Instituto Universitario da Maia. Downloaded on January 13,2024 at 10:31:10 UTC from IEEE Xplore. Restrictions apply.
 Type TM Flags Num. synch. ID Time ...
TM type Master ID Reserv. Num Sec. msgs Tx
2 Bytes 2 Bytes 2 Bytes 2 Bytes 1 Byte ...
[b15 , b12 ] [b11 , b0 ] No def [b7 , b0 ] [b15 , b0 ] [b15 , b0 ] [b7 , b0 ] ...
TM MESG ID [0, 4096) No def [0, 256) [0, 65536) [0, 65536) [0, 256) ...

Table 1. Original structure of the Trigger Message

Producer Producer Consumer

Consumer Lookup service
τ1
msg1 msg2
τ2 τ3 Application
Service−Nodes
DB
App Admission Control
end−to−end delay

produce message 1
t t Composer
Producer ( τ 1) W W
1111 0
0000 1 1111 0
0000 1
1 1

t=0 O
m addMessage(id)
1 t
T delMessage(id)
1

produce message 2
App Interface
Producer− ( τ ) W
t
Consumer 2
111 0
000 1
2

t=0 O
m
2 Application Admission Control FTT−
Service−Nodes Ethernet
DB
t
Consumer ( τ 3)
W
111
000
3

t=0
EC Scheduler
m Scheduler Dispatcher
Network W W
m Register

1111
0000 111
000
1 2

t=0
Ethernet

Figure 3. A transaction and its timeline

Figure 4. Proposed architecture

be executed on–line whenever a service is added/removed

from a node. The application composer must then deduce parameters and the messages involved. All such informa-
the appropriate offsets, for example, using the techniques tion is stored in the Application-Service-Nodes Database.
proposed in [2]. Notice, however, that either the response When a new service implementation arrives at the sys-
time analysis and the generation of the required offsets are tem it notifies the master using an asynchronous message
beyond the scope of this work. (Lookup service), the master analyzes the respective worst-
case response time as well as the performance and schedu-
4.3 Proposed architecture lability of the target application and of the whole system
(Application Admission Control). If a given QoS parame-
The proposed system architecture is an extension to the ter is improved, e.g., application end-to-end delay, and the
FTT architecture, which simplifies substantially the over- schedulability of the system is not jeopardized, the master
all design task by reusing and exploiting the operational (Composer) makes the necessary changes at the application
flexibility features of the FTT paradigm. Moreover, it also level to replace the old with the new service implementa-
allows an easy porting to different hardware platforms for tion within the respective application transaction. These
which FTT protocol implementations are available. Fig. 4 changes are then passed down to the FTT layer as new mes-
shows an implementation over FTT-Ethernet. Using other sages/tasks to be added or replaced in the FTT System Re-
communication platforms, e.g., CAN, just requires replac- quirements Database.
ing the FTT-Ethernet block by an FTT-CAN block, which In order to achieve the transparency referred in Section 3,
interface is nevertheless similar. the unique identifier of each message is broken into two
Basically, the internal architecture of the FTT–master is parts, a service level identifier and an application level iden-
complemented with an extra layer that handles applications tifier. The former separates different versions of the same
and services. At the application level, the new layer keeps service while the latter identifies the service within an ap-
track of the applications being executed and the services plication. The consumers of a message will only check the
that compose them while, at the service level, it manages application-level identifier, i.e., they listen to any service
the several versions of the available services, their location, version indistinctively. On the other hand, the master and
worst-case execution/response times, possibly other QoS the producers will look at the whole identifier, which al-

Proceedings of the 10th IEEE International Symposium on

Object and Component-Oriented Real-Time Distributed Computing (ISORC'07)
0-7695-2765-5/07
Authorized$20.00
licensed © 2007
use limited to: ISMAI - Instituto Universitario da Maia. Downloaded on January 13,2024 at 10:31:10 UTC from IEEE Xplore. Restrictions apply.
 Master Intel Celeron Producer
lows scheduling one given service implementation among 735MHz
128MB RAM
Intel Celeron
735MHz

several available. Ethernet Switch

10Mb/s
128MB RAM

1
{ QoS1
OUT:msg 01
2a
{ QoS2a
IN:msg X1
OUT:msg 12
3
{ QoS3
IN:msg X2

TM(async,msg01,msg12) Consumer Intermediate 1 Intermediate 2

2b
Master
EPIC 266MHz EPIC 266MHz EPIC 266MHz
Intel Mobile Pentium MMX Intel Mobile Pentium MMX
Intel Mobile Pentium MMX
128MB RAM
(a) Configuration of nodes 128MB RAM 128MB RAM

1
{ QoS1
OUT:msg 01
2a
{ QoS2a
IN:msg X1
OUT:msg 12
3
{ QoS3
IN:msg X2 Figure 6. Configuration of nodes

async msgs
async msgs

Master
2b
{ QoS2b
IN:msg X1
OUT:msg 22
uses Switched Ethernet [14]. Then we defined an exper-
imental setup (fig. 6) using computers running RT-Linux.
The FTT EC is set to 1 millisecond. The system executes
(b) New node attach one synthetic application composed of three services simi-
1
{ QoS1
OUT:msg 01
2a
{ QoS2a
IN:msg X1
OUT:msg 12
3
{ QoS3
IN:msg X2
larly to what is shown in fig. 1(b).

5.1 Two similar implementations of a con-

TM(async,msg01,msg22)

Master
2b
{ QoS2b
IN:msg X1
OUT:msg 22
sumer/producer task

(c) Reconfiguration Producer

Intermediate Consumer 1
1.4 Intermediate Consumer 2

Figure 5. Example of reconfiguration 1.2

1
Fig. 5(a) depicts an illustrative simplified scenario in
which all nodes implement only one service and the appli-
Packets/t

0.8

cation spans over three nodes. The message identifiers have

two digits, the first one referring to the service-level iden- 0.6

tifier and the second one referring to the application-level 0.4

identifier. At run–time, the Trigger Message triggers the

transmission of the synchronous messages 01 (version 0, 0.2

service 1) and 12 (version 1, service 2). So, the nodes 1 and 0

2a that hold the scheduled service versions transmit their

3e+08 3.05e+08 3.1e+08 3.15e+08 3.2e+08
Time

messages over the network in a broadcast fashion. These

messages are received by nodes 2a and 3 respectively. The Figure 7. Experiment 1: Message arrivals at
X in the service-level identifier means a don’t care. When the consumer node
a new node joins to the network, it uses an asynchronous
reserved message to notify all its information to the mas- This experiment verifies the switching between two ver-
ter 5(b). The master assigns an identifier to each new ser- sions of a service that corresponds to a consumer/producer
vice version (2b in this case) and decides to replace the other task. The versions reside in the nodes intermediate 1 and
version 2a. Thus, it starts scheduling message 22 (version 2 and exhibit similar temporal parameters, namely O =
2, service 2) instead of 12, Fig. 5(c). The following service 200EC, T = 1000EC, D = T . The master switches be-
in the application, i.e., 3, continues receiving any message tween those implementations every 10 seconds. The con-
that has application identifier 2, either 12 or 22 and thus it sumer node is actually receiving both the producer message
will not be aware of the change. and the consumer/producer messages and logging their re-
ception instants (fig. 7). We can see that the switching be-
5 Experimental Results tween both service versions does not cause any significant
extra delay. The end–to–end delay experimented by the
To verify the practical feasibility of the proposed archi- whole application stays around 25.3 microseconds with a
tecture, we implemented it over the FTT-SE protocol, which jitter of ±30 nanoseconds and rare peaks of 100 nanosec-

Proceedings of the 10th IEEE International Symposium on

Object and Component-Oriented Real-Time Distributed Computing (ISORC'07)
0-7695-2765-5/07
Authorized$20.00
licensed © 2007
use limited to: ISMAI - Instituto Universitario da Maia. Downloaded on January 13,2024 at 10:31:10 UTC from IEEE Xplore. Restrictions apply.
 onds caused by the run–time system, despite the switching
between versions. Similarly, the interactivation delay of the
consumer task stays steadily near 1 second, as expected,
with again a jitter of ±30 nanoseconds. This experiment
shows that the proposed architecture is able to switch be-
tween service implementations in different nodes, on-line,
maintaining the same QoS, and with the remaining tasks not
being aware of the switching.

5.2 Two implementations of a con-

sumer/producer task with different
QoS
Figure 9. Experiment 2: End–to–end delay

Producer
Intermediate Consumer 1
1.4 Intermediate Consumer 2

1.2

1
Packets/t

0.8

0.6

0.4

0.2

0
3e+08 3.05e+08 3.1e+08 3.15e+08 3.2e+08
Tiempo
Figure 10. Experiment 2: Interactivation delay
Figure 8. Experiment 2: Message arrivals at
the consumer node
6 Conclusions and Future Work
In this experiment we change a temporal parameter of
one of the consumer/producer tasks. One has an offset of Next generation distributed real–time systems will re-
m
O2A = 100EC for producing the second message, and the quire more flexibility, and the ability of reacting and chang-
m
other has O2B = 200EC for the same. This offset impacts ing their behaviour at run–time, i.e. adaptability. Service–
directly on the QoS of the application, leading to different based approaches can be used in the development of such
end–to–end delays. We can see (figures 8 and 9) how the systems, in order to provide this desired flexibility by means
end–to–end delay is modified from 150 to 250 microsec- of the definition of a model and an architecture that support-
onds every time the service implementation is switched, as dynamic service composition, allowing the applications to
expected. The interactivation delay (fig. 10) shows peaks change dynamically the set of services that compose them,
of ±100 milliseconds when the switching occurs due to the supporting for each service the definition of different ver-
difference between the two different offsets of the transmis- sions or profiles.These aproaches also offer the possibility
sions carried out by the different versions of the intermedi- of providing dynamic QoS management, load balancing and
ate service. fault tolerance.
This experiment shows that when we switch between This paper proposed an architecture to support dynamic
two different profiles, i.e., implementations, of a service, service composition in a distributed embedded real–time
the consumer of the messages produced by such service will environment. This architecture allows an application to be
not notice such switching, except for an anticipation or de- composedof existing services dispersed in the network, and
lay of its activation, caused by the different timing parame- to dynamically switch between different versions of any
ters of the different profiles, which lead to a corresponding given service in a transparent way with respect to service
end–to–end delay modification. This result shows that the location, timing features or set of consumers of its mes-
proposed architecture can support on–line updating of code, sages. The architecture is built as an extension to the FTT
even when its timing characteristics are changed. paradigm. This extension required the introduction of the

Proceedings of the 10th IEEE International Symposium on

Object and Component-Oriented Real-Time Distributed Computing (ISORC'07)
0-7695-2765-5/07
Authorized$20.00
licensed © 2007
use limited to: ISMAI - Instituto Universitario da Maia. Downloaded on January 13,2024 at 10:31:10 UTC from IEEE Xplore. Restrictions apply.
 notion of service and service–based application in the FTT [10] X. Gu and K. Nahrstedt. Distributed Multimedia Service
scope.Also, a prototype of the proposed architecture was Composition with Statistical QoS Assurances. IEEE Trans-
implemented as proof of concept, and the experimental re- actions on Multimedia, 8(1):141–151, February 2006.
sults show that the architecture is able to switch between [11] X. Gu and K. Nahrstedt. On Composing Stream Applica-
tions in Peer-to-Peer Environments. IEEE Transactions on
service implementations in different nodes, without affect-
Parallel and Distributed Systems, 17(8):824–837, August
ing the remaining services in the application, and that it
2006.
can support on–line updating of code, even when its timing [12] D. Isovic and C. . Norström. Components in Real–time Sys-
characteristics are changed. Future work will consider the tems. In Proc. of the 8th Conf. on Real–Time Computing
integration of offset configuration tools and schedulability Systems and Applications, Tokyo, 2002.
analysis that can be applied on-line. [13] J. Jin and K. Nahrstedt. A Distributed Approach for
QoS Service Multicast with Geometric Location Awareness.
Acknowledgements IEEE Distributed Systems Online, 4(6), June 2003.
[14] R. Marau, L. Almeida, and P. Pedreiras. Enhancing Real–
This work has been partially funded by e-MAGERIT (S- Time Communication over COTS Ethernet switches. In
WFCS 2006, IEEE 6th Workshop on Factory Communica-
0505/TIC/0251), project funded by the Education Council of the
tion Systems, Turin, Italy, June 2006.
Goverment of the Region of Madrid, the European Social Fund,
[15] S. Mullender, editor. Distributed systems. Addison Wesley,
and the European Regional Development Fund; also by a grant 2nd edition, 1993. Chapters 7 and 8.
from IEETA, Universidade de Aveiro, Portugal; and by the Euro- [16] K. . Nahrstedt, D. Xu, D. Wichadakul, and B. Li. QoS–
pean Commission (ARTIST2 NoE, IST-2004-004527). Aware Middleware for Ubiquitous and Heterogeneous En-
vironments. IEEE Communications Magazine, 39(2):140–
References 148, Nov. 2001.
[17] P. Pedreiras and L. Almeida. The Flexible Time-Triggered
(FTT) Paradigm: An Approach to QoS Management in Dis-
[1] A. A. Avizienis. The Methodology of N-Version Program-
tributed Real-Time Systems. In IPDPS ’03: Proc. of the
ming. In C. Lyu, editor, Software Fault Tolerance, pages
17th International Symposium on Parallel and Distributed
25–46. John Wiley & Sons Ltd, 1995.
Processing, April 2003.
[2] M. Calha and J. Fonseca. Data streams – an analysis of the
[18] P. Pedreiras, P. Gai, L. Almeida, and G. Buttazzo. FTT-
interactions between real–time tasks. In ETFA 2005, 10th
ethernet: a flexible real-time communication protocol that
IEEE Conference on Emerging Technologies for Factory Au-
supports dynamic QoS management on Ethernet-based
tomation, pages 375– 380, Catania, Italy, September 2005.
[3] J. Cano, J. Perez-Cortes, J. Valiente, R. Paredes, and J. Ar- systems. IEEE Transactions on Industrial Informatics,
landis. Textile Inspection with a Parallel Computer Cluster. 1(3):162–172, August 2005.
[19] D. Prasad, A. Burns, and M. Atkin. The Measurement and
In 5th International Conference on Quality Control By Arti-
Usage of Utility in Adaptive Real–Time Systems. Journal
ficial Vision. QCAV-2001, Le Creusot (France), 2001.
[4] I. Crnkovic and M. Larsson. A case study: Demands on of Real–Time Systems, 25(2/3):277–296, 2003.
Component–based Development. In Proc. of 22nd Int. Conf. [20] J. Real and A. Crespo. Mode Change Protocols for Real-
of Software Engineering, Limerick (Ireland), June 2000. Time Systems: A Survey and a New Proposal. Real Time
[5] M. A. de Miguel, J. Ruiz, and M. Garcı́a-Valls. QoS–Aware Systems Journal, 26(2):161–197, March 2004.
Component Frameworks. In Proc. of the International Work- [21] J. Saltzer, D. Reed, and D. Clark. End-to-end arguments in
shop on Quality of Service, May 2002. system design. ACM Transactions on Computer Systems,
[6] G. Deconinck, T. A. V. Vincenzo De Florio, and E. Ver- 2(4):277–288, 1984.
entziotis. The EFTOS Approach to Dependability in Em- [22] M. Satyanarayanan. Pervasive computing: vision and chal-
bedded Supercomputing. IEEE Transactions on reliability, lenges. IEEE Personal Communications, 8(4):10–17, Au-
51(1):76, March 2002. gust 2001.
[7] I. Estevez-Ayres, M. Garcia-Valls, and P. Basanta-Val. En- [23] A. Tes̆anovic, D. Nyström, J. Hansson, and C. Norström.
abling WCET–based Composition of Service–based Real– Aspects and components in real–time system development:
Time Applications. ACM SIGBED Review, 2(3):25–29, July Towards reconfigurable and reusable software. Journal of
2005. Embedded Computing, Feb. 2004.
[8] J. Ferreira, L. Almeida, J. A. Fonseca, P. Pedreiras, E. Mar- [24] N. Wang, C. D. Gill, D. C. Schmidt, and V. Subramonian.
tins, G. Rodriguez-Navas, J. Rigo, and J. Proenza. Combin- Configuring Real–Time Aspects in Component Middleware.
ing operational flexibility and dependability in FTT-CAN. In R. Meersman and Z. Tari, editors, CoopIS/DOA/ODBASE
IEEE Transactions on Industrial Informatics, 2(2):95–102, (2), volume LNCS 3291, pages 1520–1537. Springer, 2004.
May 2006.
[9] M. Garcı́a-Valls, I. Estévez-Ayres, P. Basanta-Val, and
C. Delgado-Kloos. CoSeRT: A Framework for Compos-
ing Service–Based Real–Time Applications. In C. Bussler
and A. Haller, editors, Business Process Management Work-
shops, volume LNCS 3812, pages 329–341. Springer, 2005.

Proceedings of the 10th IEEE International Symposium on

Object and Component-Oriented Real-Time Distributed Computing (ISORC'07)
0-7695-2765-5/07
Authorized$20.00
licensed © 2007
use limited to: ISMAI - Instituto Universitario da Maia. Downloaded on January 13,2024 at 10:31:10 UTC from IEEE Xplore. Restrictions apply.