DETERMINISTIC RUNTIME ADAPTATION FOR HARD

REAL-TIME EMBEDDED SYSTEMS WITH PROCESSING

CONSTRAINTS

Fahad Bin Tariq

Design of Distributed Embedded Systems, University of Paderborn, Fuerstenallee 11, Paderborn, Germany

Keywords:

Runtime Adaptation, Determinism, Hard Real-time, Processing Constraints, Middleware, Embedded Systems.

Abstract:

Increasing the connectivity of systems at various levels gives rise to potential beneﬁts that is addressed by

trends such as the Internet of Things, Cyber-Physical Systems and Cyber-Biosphere. It is inevitable that the

vast global network will consist of computationally constrained units. The ability of such systems to adapt

while being connected to a global network presents new opportunities. Qualities such as fault tolerance and

load sharing may be extended to nodes in the network that initially were devoid of them. On the other hand,

an open adaptable system that does not limit its adaptation to pre-deﬁned and pre-containing states needs to be

connected to one or more sources that may provide the necessary behavioral units to switch to the new state.

Extending computationally constrained nodes with the ability to adapt is in itself challenging, which increases

when timely behavior is required due to real-time requirements. The system must then guarantee all deadlines

implying the need for deterministic adaptation. The question of when to adapt becomes an important one with

real-time deadlines involved. We present our work on a framework that aims to achieve deterministic runtime

adaptation on single processor systems thereby enabling such computationally constrained systems to extend

their functionality and non-functional qualities.

1 INTRODUCTION

Embedded systems are typically designed to have

long life cycles. Consider the systems found in

modern vehicles such as airplanes and cars, or

those running industrial systems. Unmanned de-

vices such as autonomous submarines or mobile

robots(Herbrechtsmeier et al., 2009) fully rely on the

embedded systems within them to achieve their tasks.

Once deployed, the system will be expected to run for

periods ranging from months to decades (Koopman,

1996). It is inevitable that such systems come across

changes in their context. This may include changes

to other components working with the embedded sys-

tem such as hardware replacement due to a failure.

System objectives and requirements may evolve over

time with changes in the environment. QoS require-

ments may vary over time as well as resource con-

sumption. To cater to these changes, the system needs

to adapt while maintaining a safe level of operation.

The idea of runtime adaptation in general is not

new as can be seen by work done in (Fabry, 1976) as

early as 1976. Its application to embedded real-time

systems was only a matter of time and recent years

have shown an increased interest by the embedded

systems community in harnessing the beneﬁts asso-

ciated with it. Runtime adaptation is the ability of a

system to change its behavior and/or structure while

remaining in a desirable state of operation. A desir-

able state of operation implies the system remains on

course to meet certain functional and/or QoS objec-

tives.

There exist various reasons for having runtime

adaptation as a characteristic property of the sys-

tem. As the complexity of systems and their devel-

opment process has increased over time, so have the

costs and efforts to maintain them. An architecture

enabling adaptation inherently supports change dur-

ing the runtime phase of the system lifecycle making

maintenance less costly. Resource requirements may

change overtime depending on various factors such as

computational load and communication requirements.

The occurrence of failure on one node in a distributed

environment may force topological restructuring such

as the sharing of processing load or the creation of

new connections. Hence the ability to adapt enables

systems to acquire other properties, for example, fault

tolerance.

469

Bin Tariq F. (2012).

DETERMINISTIC RUNTIME ADAPTATION FOR HARD REAL-TIME EMBEDDED SYSTEMS WITH PROCESSING CONSTRAINTS.

In Proceedings of the 2nd International Conference on Pervasive Embedded Computing and Communication Systems, pages 469-477

DOI: 10.5220/0003943504690477

 SciTePress

The increasing complexity of embedded systems

is due, but not limited, to the increasing quality and

quantity of the resources involved (e.g. Multi-core

processing units). It is interesting to note that such

resources are there in the ﬁrst place to tackle the in-

creasing complexity brought onto the system by ever-

increasing requirements and functionality (realized by

software). Another approach to handle such complex-

ity and, as a result give rise to different complexity, is

to distribute the system or to increase its connectivity.

Increasing the connectivity of systems at various lev-

els gives rise to potential beneﬁts that is addressed by

trends such as the Internet of Things, Cyber-Physical

System (Lee, 2008) and Cyber Biosphere (Rammig,

2008). Hence, simple computational and communi-

cation units connected with similar units give rise to

complex behavior which is also the basic concept of

swarms (Dorigo and Birattari, 2007). An example

where units (or nodes) that are relatively simple at

the individual level but combine to create more com-

plex behavior, is a group of communicating mobile

robots called bebots (Herbrechtsmeier et al., 2009).

The Bebots consist of a relatively simple architecture

and communicate via an ad-hoc network. Another

more common example is a sensor network, which

relies on very simple but large number of stationary

sensing nodes, possibly distributed over a vast area to

gather information. Thus it is inevitable that the vast

global network mentioned above will consist of com-

putationally constrained units.

The ability of systems to adapt while being con-

nected to a global network presents new opportuni-

ties. Qualities such as fault tolerance and load sharing

may be extended to nodes in the network that initially

were devoid of them. Conversely, an open adaptable

system that does not limit its adaptation to pre-deﬁned

and pre-containing states needs to be connected to

one or more sources that may provide the necessary

components to switch to the new state. Extending

computationally constrained nodes with the ability to

adapt is in itself challenging, which increases when

timely behavior is required due to real-time require-

ments. The system must then guarantee all dead-

lines implying the need for deterministic adaptation.

The question when to adapt becomes an important

one with real-time deadlines involved. In literature

we ﬁnd two common techniques namely (a) adapt at

once and (b) adapt on demand. In the former, all

the required adaptation steps are scheduled in a sin-

gle block. The duration of this block is not ﬁxed and

depends on the amount of adaptation. In the latter,

adaptation takes place only when the functionality, to

be directly effected by the adaptation, is accessed. In

the ﬁrst case, the duration of the adaptation is unpre-

dictable, whereas in the second case, access times be-

come unpredictable since an access may trigger adap-

tation.

In this paper we present an approach to tackle the

issue of runtime adaptation on computationally con-

strained systems with real-time constraints. Our focus

is on systems with only a single general purpose pro-

cessor, with the responsibility to run the system and

application software. In section 2, we introduce our

Framework followed by the architecture and evalua-

tion in sections 3 and 4 respectively. Related work is

then found in section 5 followed by the conclusion in

section 6.

2 FRAMEWORK

The inevitable presence of computationally con-

strained systems in emerging paradigms such as the

Internet of Things, has already been emphasized

above. This section introduces a framework that en-

ables such systems to adapt during runtime and par-

take in the dynamics of the global network thus cre-

ated. To achieve this the framework, viewed from the

bottom up, provides a supporting mechanism to (a)

enable the behavior to execute and (b) enable the sys-

tem to deterministically adapt. Adaptation may in-

clude changes to the current behavior of the system,

as well as addition of new behavior. These tasks are

the responsibility of the Middleware. To facilitate the

work of the Middleware and pave way for efﬁcient

behavioral reconﬁguration, a behavioral model is pro-

vided. The model lays forth the anatomy of the appli-

cation designed for the embedded system enabling the

behavior to be captured in a desired structure. Further,

the model lays down rules of communication that al-

low for efﬁcient connection reconﬁguration between

the behavioral units. The idea is to support the adapta-

tion process with applications having features making

them inherently adaptive. Hence in order to under-

stand the tasks of the Middleware, a brief description

of the behavioral model is ﬁrst provided.

2.1 Behavioral Model

Embedded systems tend to be application speciﬁc, the

question how an application should be implemented,

instead of what it implements, is addressed by the be-

havioral model. The result is an application behaving

desirably from a structural point of view, and commu-

nicating between its constituent components without

any explicit connections. This is achieved without the

need to dictate or even know its functional behavior.

In our model, the behavior is seen as a composition of

PECCS 2012 - International Conference on Pervasive and Embedded Computing and Communication Systems

470

Figure 1: Behavioral unit with entry points and exit indices.

behavioral units, as is done in programming-in-the-

large. This is in contrast to programming-in-the-small

where granularity of models is at the level of classes,

objects and methods. The behavioral units are de-

veloped independently and appear to each other and

the underlying system as black boxes. If the behavior

consists of k behavioral units, then the composition

of behavioral units C

, ∀i : 1 ≤ i ≤ k making up the

behavior is denoted by

Typically, a behavioral unit has a required and pro-

vided interface, where the former speciﬁes the pre-

requisites of the behavioral unit before it can fulﬁll

its functionality. The provided interface then, mani-

fests the different results the behavioral unit produces

on completing its function. In this model, the required

interface consists of many entry points, as can be seen

in Fig. 1. Each entry point s

can be seen as provid-

ing an access point to the functionality a behavioral

unit has to offer. Hence, different entry points allow

for access to different functionality of the behavioral

unit. The set of entry points of a behavioral unit C is

denoted by EP

A behavioral unit may, for example, offer two

compression techniques. A client wishing to access

one of these must then provide the data to be com-

pressed along with the associated entry state. Fur-

ther, a behavioral unit may combine two or more in-

ternal functionalities to fulﬁll a composite function.

For example, a third compression technique may be

provided by combining the ﬁrst two. This compos-

ite function will again have only one associated en-

try point instead of requiring the client to provide an

entry point for every function involved. Thus from

the client perspective, access to a simple or composite

functionality of the behavioral unit is transparent. An

entry point triggers an atomic run that, upon comple-

tion, releases an exit index. An exit index x

denotes

the state that the behavioral unit is in, from a set of

possible and predeﬁned states. Further, an exit index

may be accompanied by data generated by the behav-

ioral unit during execution. The underlying system

(section 2.2) notiﬁes other behavioral units about the

received exit index based on behavioral unit connec-

tions registered in the connection list.

A connection is simply the association of an exit

index of a behavioral unit to an entry point of another

behavioral unit. In other words, the generation of an

exit index by a behavioral unit may trigger the entry

point of another behavioral unit. One exit index may

be associated with one or more entry points and vice

versa. Thus the connection list is a mathematical re-

lation between all the exit indices and their triggered

entry points, as given below:

CL = {(x

, s

, o)|x

∈ XI

, (s

∈ EP

∨ s

∈ EP

∀C

, C

∈

C, ∀o ∈ N}

C is the set of behavioral units in the system, and

and C

are two such behavioral units. XI

are the

exit indices belonging to behavioral unit C

, whereas

are the entry points of behavioral unit C

. EP

speciﬁes the possibility of an exit index not being as-

sociated with the entry point of any behavioral unit.

An exit index may be associated with more than one

entry point of the same behavioral unit, hence a turn

based approach is used to disambiguate between the

entry points. The ordering o speciﬁes which entry

point to choose at a given instance.

A behavioral unit has certain platform indepen-

dent and platform speciﬁc properties associated with

it. These properties are packaged along with the be-

havioral unit and called the meta-data. The meta-

data consists of, for every behavioral unit, the plat-

form independent relative deadline, the platform spe-

ciﬁc worst case execution time and worst case mem-

ory usage. Besides these, pointers to the starting point

of behavioral unit code execution and communication

interface are also provided. These are used by the

underlying system to transfer execution control and

send/receieve data to/from the behavioral unit via the

Middleware-Application Interface.

2.2 Middleware

The mechanism to enable the behavior to execute

and the system to adapt, is provided by the middle-

ware. From the application behavioral units perspec-

tive(section 2.1), the middleware acts as a execution

engine on top of which the behavioral units execute

and communicate. From a node perspective, in a

networked environment with different nodes running

their own instances of the execution engine, the en-

gine is the middleware through which nodes commu-

nicate. Even on a single node, the execution engine is

the middleware that separates the application behav-

DETERMINISTIC RUNTIME ADAPTATION FOR HARD REAL-TIME EMBEDDED SYSTEMS WITH

PROCESSING CONSTRAINTS

471

Figure 2: Timed phases.

ioral units from the underlying operating system and

other behavioral units.

The middleware consists of two modes namely,

the initialization mode and the running mode. In the

initialization mode, all the behavioral units that cur-

rently makeup the application are plugged in. Plug-

ging in the behavioral units consists of allocating re-

sources such as memory space, registering the meta-

data and linking the execution and communication in-

terface pointers with the middleware. The initial con-

nection list is then used to register the connections

between the behavioral units.

The drawbacks of two approaches to adaptation

namely adapt at once and adapt on demand were

mentioned in section 1. The middleware employs a

highly deterministic approach called timed phases to

achieve the intended objectives of behavioral execu-

tion and runtime adaptation. As already mentioned,

the target embedded systems have processing con-

straints with only one processing unit, therefore the

timed phases approach divides the processing time-

line of the single processor into phases for compu-

tation, communication and adaptation, as shown in

Fig. 2. Effectively, processing time is allocated for

the three separate concerns. Adaptation is not treated

by the system as a low priority, optional activity but

as a main concern. The approach not only aims to

guarantee deterministic behavior from the functional-

ity perspective but also guarantees processing time for

adaptation activities.

After the behavioral units have been plugged in

and connections registered, the middleware initializes

the timed phases with the help of services offered by

the underlying real-time operating system (section 3),

such as the timer and interrupt services. The lengths

of the computation, communication and adaptation

phases, denoted by T

, T

and T

respectively, may

differ from one another and are predetermined based

on the current application. Once set, the three phase

lengths remain constant throughout the system life-

time.

The commencement of the timed phases signals

the switch of the middleware to the running mode.

In the running mode, the three phases are executed

one after the other. The end of the adaptation phase

triggers the start of another computation phase and the

phases are repeated in cyclic manner, as is shown in

Fig. 2.

2.2.1 Computation Phase

The behavioral units are scheduled for execution dur-

ing the computation phase. Every behavioral unit

ﬂagged for release is given the processor based on the

scheduling policy being used. The scheduling pol-

icy, for instance the Earliest Deadline First (EDF) or

Fixed Priority (FP), is chosen at design time and re-

mains constant throughout the system lifetime. Upon

release, a behavioral unit receives an entry point and

a block of data (mail) registered under it in the mid-

dleware. This mail contains the data required by the

behavioral unit to proceed with the functionality. As

mentioned earlier in section 2.1, upon completion the

behavioral unit releases an exit index and data. Fur-

ther, a behavioral unit may have data that it uses over

a period of time, for example the average tempera-

ture of a device over a given duration. Such data is

classiﬁed as the state of the behavioral unit and is

recorded by the middleware at the end of the com-

putation phase.

2.2.2 Communication Phase

In the communication phase the middleware executes

the communication protocol. The connection list is

used to map the exit indices to entry points. This pro-

cess employs the publish-subscribe pattern by mak-

ing a behavioral unit have the task of only publishing

an exit index without having any knowledge of sub-

scriptions to the exit index. The subscribing behav-

ioral unit(s) receive an entry point from the middle-

ware based on the connection list. Data is transferred

by providing a buffer to the publisher where standard

size packets are created. This buffer along with the

packets, is then routed to the subscribing behavioral

units. The data is consumed during the computation

phase. All inter-behavioral unit communication in-

cluding data transfer is done indirectly via the middle-

ware. Due to this, communication between geograph-

ically distant nodes connected via a network appears

transparent to all behavioral units on these nodes.

2.2.3 Adaptation Phase

The adaptation phase runs in two modes namely the

normal mode and the adapt mode. The middleware

checks at the beginning of the phase for an adaptation

request. If none is found, the normal mode is executed

where soft real-time messages are exchanged for sys-

tem diagnostics and the system is monitored to check

PECCS 2012 - International Conference on Pervasive and Embedded Computing and Communication Systems

472

Figure 3: Hierarchial adaptation.

if adaptation is required. An adaptation request may

be triggered locally or remotely. A local request is

sent from a reﬂection monitor responsible to reﬂect

upon the system and ensure certain constraints are

met. These constraints vary depending on the adapta-

tion policy. For example, the system may have a pol-

icy of executing a certain load during the computation

phase, which may decrease depending on the energy

utilization of the system. It is possible that at a certain

energy level, the monitor decides to decrease the load

and hence send an adaptation request. Terminology

introduced by (Ibm, 2006) and commonly used for

adaptive systems namely the Monitor, Analyze, Plan

and Execute cycle (MAPE) may be applied to the ac-

tivities of the reﬂection monitor. The MAPE activi-

ties of the reﬂection monitor are limited to the ones

present within the monitor resulting in a restricted-

MAPE. Since the monitor itself is a behavioral unit, it

may be replaced during runtime in effect making the

local adaptation policy replaceable, as can be seen

in Figure 3. A separate system (e.g. a server), au-

tomated or human controlled, and connected via net-

work, monitors the adaptable node (current system)

as well as for the presence of new adaptation poli-

cies and node objectives. New node objectives and/or

adaptation policies may require new reﬂection mon-

itors not present with the server. These reﬂection

monitors are then acquired from third-parties via the

global network. Since there is no restriction to the

change of objectives or adaptation policies that can

be created locally or acquired by the server, the activ-

ities can be termed as unrestricted-MAPE. A request

to replace the reﬂection monitor can be sent to the

adaptive node.

Having dealt with local adaption requests trig-

gered by the reﬂection monitor, remote requests may

also be received from an external source, such as a hu-

man controller or a monitor in another node, in a net-

worked system. If an adaptation request is found, the

middleware enters the adapt mode and executes the

adaptation protocol. A Standard Adaptation Request

(SAR) speciﬁes the type of adaptation required which

can either be the addition/removal of behavioral units

and/or a reconﬁguration of behavioral unit connec-

tions. Reconﬁguring connections during adaptation

is the simple task of changing the connection list, in-

stead of needing to go through every behavioral unit

and changing the connections, since no direct con-

nections exist and all inter-behavioral unit communi-

cation is handled by the middleware. The new con-

nection conﬁguration is read from the SAR. In case

where whole behavioral units need to be added, the

SAR contains the quantity of the behavioral units and

their meta-data, mentioned in section 2.1. This meta-

data is used for admission control where, based on

the scheduling strategy used, the middleware checks

the processor utilization to conclude whether the tim-

ing and memory requirements of existing and new be-

havioral units can be met. In case they are met, an

approval is sent to the source of the request to start

transfer of the behavioral unit binaries.

The length of the adaptation phase T

is not ﬁxed

since no optimal value, applicable to all scenarios,

exists. This follows from the work done by Gupta

which proves that ”determining appropriate con-

straints for the timing of an update is undecidable in

general”(Gupta, 1994). An appropriate value for T

can be determined case by case, considering certain

parameters such as the expected adaptation frequency

and application performance requirements.

2.3 Performance in Highly Adaptive

Environment

The presence of multiple processing units gives rise to

the possibility of delegating adaptation to a dedicated

processor or one with less computation load. When

only a single processing unit is available, computation

time must be allocated to adaptation while guarantee-

ing deadlines of existing hard real-time computation

load. Any guarantee depends on the system remain-

ing deterministic while accommodating adaptation.

Having already outlined the beneﬁts of adapta-

tion made possible in an open and networked envi-

ronment, the assumption that systems will be working

in highly adaptive environments is realistic. Efforts in

areas such as Cloud Computing outline a path towards

DETERMINISTIC RUNTIME ADAPTATION FOR HARD REAL-TIME EMBEDDED SYSTEMS WITH

PROCESSING CONSTRAINTS

473

leaner systems that acquire functionality on demand.

This results in many design time decisions to be for-

warded to system runtime enabling an increase in de-

cision accuracy.

We assume an adaptive system deployed in such

a scenario with a high frequency of adaptation. In

resource constrained embedded systems, besides hav-

ing timed phases, other possibilities are to have adapt-

at-once or adapt-on-demand approaches, mentioned

in section 1. We compare the adapt at once approach

with the timed phases one. Without loss of gener-

alization, let cp denote the time allotted for compu-

tation, cm for communication, ac the time needed to

only check if an adaptation request has arrived and ap

the time allotted for adaptation in a single phase. Let

denote the cycle of a system Sys

using the timed

phases approach and T

the cycle of a system Sys

us-

ing the adapt-at-once approach. We assume a cycle to

have ﬁnished in in Sys

once cp,cm and ac have been

allotted once. Hence:

= cp + cm + ac + ap

= cp + cm + ac

To get a comparable term, we acquire a common

multiple (c.m.) of T

and T

T = T

× T

T implies that in Sys

, there are T

cycles of T

and similarly in Sys

there are T

cycles of T

. Let

cp + cm + ac be denoted by t

cca

, which is also equal

to T

. So,

= t

cca

+ ap

T there are T

cycles of t

cca

T = T

cca

) + T

(ap) (1)

From Sys

perspective in

T , T

(ap) time was

given for adaptation. We assume an adaptation re-

quest took that much time to successfully complete

up till time

T . From Sys

perspective there exist T

cycles of computation and communication up till time

T :

T = T

cca

)

As already mentioned, we need T

(ap) amount of

time to adapt, hence in Sys

adaptation needs to start

at T

start

T − T

(ap)

start

= T

cca

+ ap) − T

(ap) (from (1))

start

= T

cca

)

Thus Sys

also provides T

computation and com-

munication cycles as Sys

, after which adaptation will

need to start to be successfully completed. Hence

having an adaptation phase in every cycle will not de-

crease system performance in a highly adaptive envi-

ronment. On the contrary, Sys

performs better when

it comes to managing adaptation with hard real-time

tasks already scheduled. Assume there is a high pri-

ority periodic task with a period P

task

, with P

task

≈ T

In Sys

, a stretch of T

(ap) after T

start

for adaptation

will either not start an instance of the periodic task or

not complete adaptation till

T . Hence another feature

of the approach employed by the middleware, is be-

sides guaranteeing determinism for the hard real-time

behavior, a guarantee that adaptation will take place

and not denied processing time by a high priority ac-

tivity, is also provided.

3 ARCHITECTURE

The behavioral model and middleware described in

section 2 gave an idea of the architecture of a sys-

tem following the frameowork. The application be-

havior is vertically partitioned into a set of loosely

coupled behavioral units that interact indirectly via

the middleware below. Hence taking a horizontally

partitioned view, the top layer consists of the appli-

cation layer followed by the middleware layer, as can

be seen in Fig. 4. To achieve low level functional-

ity such as allocating storage space to incoming be-

havioral units, garbage collection after behavioral unit

removal, scheduling behavioral units for execution on

the single processor, timer interrupt handling etc., the

middleware uses the services of a Real-Time Oper-

ating System (RTOS). The RTOS is also responsible

to act as an interface between the processing unit and

software layers running above. To make the middle-

ware independent of any speciﬁc RTOS, an Operating

System Adaptor Layer (OSAL) is present between the

middleware and the RTOS. The middleware does not

make any direct calls to any speciﬁc RTOS services

but to generic services provided by the OSAL. The

middleware can be ported to any RTOS by porting the

OSAL to the desired RTOS. The scope of the frame-

work concepts encapsulates the top three layers and is

called Framework for Deterministic Runtime Adapta-

tion of Real-time Embedded systems (F-DRARE).

The system is a node in a network with each node

having the same software architecture with the pos-

sibility of heterogeneous hardware platforms, or may

even be a standalone system such as a single robot. A

node may even have many application speciﬁc pro-

cessing units (e.g. DSP) with the assumption that

only a single processing unit is provided for the sys-

tem software. In the networked case (Fig.4), each

node runs its own independent copy of the middle-

PECCS 2012 - International Conference on Pervasive and Embedded Computing and Communication Systems

474

Figure 4: Architecture of system on a node in a network.

ware. The application running at the top layer may

be distributed into many behavioral units running on

different nodes. Keeping with the idea of Cyber Phys-

ical Systems, these nodes may be connected to exter-

nal networks with or without the same architecture.

A server used for external monitoring, as mentioned

in section 2.2, is connected and also acts a behavioral

unit repository.

A node may send/receive an SAR and behavioral

units to/from either the repository, other nodes in the

local network or an external network. The nodes in

the local network synchronize by using any bounded

delay network protocol. This enables behavioral units

of a distributed application present on different nodes

to synchronize via the middleware and also fulﬁll

adaptation timing requirements.

4 EVALUATION

The concepts presented earlier have been imple-

mented and an evaluation is shown in this section.

The middleware or execution/adaptation engine of F-

DRARE has been implemented in C++, as well as the

OSAL. Following the behavioral model enabled the

creation of different behavioral units loosely coupled

by mapping exit indices to entry points in the connec-

tion list. The resulting composition became the ap-

plication. Similar to the middleware, the behavioral

units were also implemented in C++. The TrueTime

Kernel(Cervin et al., 2003) has been used as the un-

derlying RTOS, which runs on Matlab/Simulink.

The example used consists of two categories of

uni-processor Bebots. The ﬁrst category consists of

lighter and cheaper worker-bots with a small camera,

Figure 5: Normal mode execution.

a general purpose processor, wireless communication

device, a motor for movement and a limited power

supply. The second category consists of server-bots

equipped with an additional dedicated visual process-

ing unit (Digital Signal Processor). All the worker-

bots have a server-bot within communication range at

all times. The Bebots move around an area in search

of a chemical found in plants growing in the desig-

nated area. The presence of the chemical is identiﬁed

by analyzing the shade of the leaves of the plant in

question. The application on a worker-bot consists of

behavioral units B1, the main controller also responsi-

ble for the direction of movement; B2, responsible to

acquire the image using the on-board camera; and B3,

responsible to compress the image and send it to the

server-bot which in-turn analyzes it and returns the

boolean result (chemical present or not). B2 and B3

are registered to listen to the exit index of B1 result-

ing in respective entry points. The entry point for B2

instructs it acquire an image whereas the entry point

for B3 instructs it to compress and send the last image

to the server-bot. In turn, B1 is registered to listen for

the exit indices of both B2 and B3, which effectively

delivers the results to B1.

A normal mode simulation with the granularity of

time in milliseconds, is shown in Fig 5. The end of

the computation phase is triggered by the start of the

communication phase. Similarly the end of the com-

munication phase is triggered by the start of the adap-

tation phase. The phase durations T

, T

and T

, cor-

respond to current simulation values of 0.6 ms, 0.4

ms and 0.4 ms respectively . The small duration of

the phase switch triggering the start of a phase spec-

iﬁes the handover activity carried out by the middle-

ware when switching from one phase to the next. The

behavioral units are released for execution during the

computation phase. The communication and adapta-

tion protocols described in section 2.2, and denoted

here by Comm protocol and Adpt protocol are exe-

cuted in their respective phases. A reﬂection monitor

reﬂects upon the system during the adaptation phase.

In this example, the reﬂection monitor tracks the en-

DETERMINISTIC RUNTIME ADAPTATION FOR HARD REAL-TIME EMBEDDED SYSTEMS WITH

PROCESSING CONSTRAINTS

475

Figure 6: Reconﬁguration of behavioral units and connec-

tions.

ergy consumption of the robot to check that enough

samples are analyzed before the battery runs out. Dur-

ing the course of the search it is realized that enough

samples will not be analyzed with the current energy

consumption. A local adaptation request is triggered

and according to the current adaptation policy, the be-

havioral unit B3, responsible to compress and com-

municate with the server-bot, is replaced with a new

behavioral unit B4, with a software image processing

algorithm. This results in the worker-bot saving en-

ergy by not communicating with the server-bot and

instead relying on a less accurate software analysis.

Simulation results in Fig. 6 depict the handling

of the adaptation request. At time 53 ms an SAR is

processed resulting in the replacement of behavioral

unit B3 with the new behavioral unit B4. Connection

reconﬁguration also occurs with B4 registering to the

exit index of B2, resulting in the image taken by B2 to

be sent to B4 for analysis. Connection entries related

to B3 are removed. The following computation phase

executes the already scheduled B2 followed by execu-

tion of the new behavioral unit B4 in the computation

phases starting at time 70 ms.

5 RELATED WORK

The introduction of this paper already stated that the

concept of runtime adaptation has been present with

some variation as far back as the pioneering work

done by Fabry in 1976 (Fabry, 1976). A great vari-

ation exists from naming (e.g. online update, run-

time reconﬁguration etc.), as well as the target system

characteristics, to approaches for achieving it. For in-

stance, Fabry in his work strives to change Abstract

Data Types with the scope of the change already pro-

vided by the programmer and realized by using priv-

ileged instructions. A good survey on these varia-

tions can be found by Vandewoude et. al. in (Vande-

woude, 2002). The same authors present their work

on a Java-based component system SEESCOA (Van-

dewoude and Berbers, 2004) that employs the adapt

at once technique, mentioned in section 1. Ritzau

et.al. also present a Java based approach where the

Java Virtual machine (JVM) is extended (Ritzau and

Andersson, 2000). This work is notable since it uses

the other approach mentioned in section 1, namely

adapt on demand. We differ from these and similar

approaches with respect to the timing of the adapta-

tion by employing the timed phases to achieve de-

terminism, a top priority in hard real-time systems.

Another difference is the special focus on processing

constrained systems.

The Flexible Resource Manager tries to optimize

system behavior using a heuristic based on latest re-

quirements (Hojenski and Oberth

ur, 2006). This is

achieved by toggling between a set of pre-deﬁned pro-

ﬁles to reach the goal of resource optimization. Be-

sides resource optimization, our work enables the ac-

quisition of new behavior un-deﬁned at system design

time. Heavier adaptive platforms such as the Simplex

Architecture (Sha et al., 1995), besides having other

differences, are not suited to the target embedded sys-

tem in our focus.

In (Andersson et al., 2009), we ﬁnd a reference

model for adaptive systems which enables a qualita-

tive evaluation of systems with the ability to reﬂect

upon themselves, a necessary quality for self-adaptive

systems. This is done by analyzing a system via the

given reﬂection prism.

6 CONCLUSIONS

In this paper we have presented a framework that pro-

vides a behavioral model and an underlying support

mechanism to achieve deterministic runtime adapta-

tion for processing constrained embedded systems.

With the concepts of Cyber Physical Systems and the

Internet of Things changing the stance from closed to

open and connected embedded systems, the potential

to harness new abilities such as the acquisition of sys-

tem qualities as well as functionality not present at

design time, becomes a possibility. To achieve this,

systems must have the ability to adapt while simul-

taneously fulﬁlling their timing guarantees. It is in-

evitable that the vast global network will consist of

nodes with processing constraints, making adaptation

a problem. The work in this paper moves towards

solving this problem. A realization of the concepts

and evaluation was done by presenting F-DRARE.

PECCS 2012 - International Conference on Pervasive and Embedded Computing and Communication Systems

476

REFERENCES

Andersson, J., de Lemos, R., Malek, S., and Weyns, D.

(2009). Reﬂecting on self-adaptive software systems.

In SEAMS, pages 38–47.

Cervin, A., Henriksson, D., Lincoln, B., Eker, J., and rzn,

K.-E. (2003). How does control timing affect perfor-

mance? analysis and simulation of timing using jitter-

bug and truetime. In IEEE Control Systems Magazine.

Dorigo, M. and Birattari, M. (2007). Swarm intelligence.

Scholarpedia, 2(9):1462.

Fabry, R. S. (1976). How to design systems in which mod-

ules can be changed on the ﬂy. In Intl. Conf. on Soft-

ware Engineering.

Gupta, D. (1994). On-line software version change.

Herbrechtsmeier, S., Witkowski, U., and R

uckert, U.

(2009). Bebot: A modular mobile miniature

robot platform supporting hardware reconﬁguration

and multi-standard communication. In Progress in

Robotics, Communications in Computer and Infor-

mation Science. Proceedings of the FIRA RoboWorld

Congress 2009, volume 44, pages 346–356, Incheon,

Korea. Springer.

Hojenski, K. and Oberth

ur, S. (2006). Towards self-

optimizing distributed resource management. In Selb-

storganisierende, Adaptive, Kontextsensitive verteilte

Systeme (SAKS 06), Kassel, Germany.

Ibm (2006). An architectural blueprint for autonomic com-

puting. Quality, 36(June):34.

Koopman, P. (1996). Embedded system design issues (the

rest of the story). In Proceedings of the 1996 Interna-

tional Conference on Computer Design, VLSI in Com-

puters and Processors, ICCD ’96, pages 310–, Wash-

ington, DC, USA. IEEE Computer Society.

Lee, E. A. (2008). Cyber physical systems: De-

sign challenges. In International Symposium on

Object/Component/Service-Oriented Real-Time Dis-

tributed Computing (ISORC). Invited Paper.

Rammig, F. J. (2008). Cyber biosphere for future embed-

ded systems. In Proceedings of the 6th IFIP WG 10.2

international workshop on Software Technologies for

Embedded and Ubiquitous Systems, SEUS ’08, pages

245–255, Berlin, Heidelberg. Springer-Verlag.

Ritzau, T. and Andersson, J. (2000). Dynamic deployment

of java applications. In IN JAVA FOR EMBEDDED

SYSTEMS WORKSHOP.

Sha, L., Rajkumar, R., and Gagliardi, M. (1995). Evolv-

ing dependable real-time systems. In IEEE Aerospace

Applications Conference, pages 335–346.

Vandewoude, Y. (2002). Run-time evolution for embed-

ded component-oriented systems. In in Proceedings

of the International Conference on Software Mainte-

nance, pages 242–245. IEEE Computer Society.

Vandewoude, Y. and Berbers, Y. (2004). Supporting run-

time evolution in seescoa. J. Integr. Des. Process Sci.,

8:77–89.

DETERMINISTIC RUNTIME ADAPTATION FOR HARD REAL-TIME EMBEDDED SYSTEMS WITH

PROCESSING CONSTRAINTS

477