CHAMELEON

New Object Oriented Solution for Adaptive Control Systems

Asma Nafti

2,3

, Mohamed Romdhani

1,3

and Mohamed Khalgui

1,3

University of Carthage, Carthage, Tunisia

FST Faculty, University of Tunis El Manar, Tunis, Tunisia

LISI Laboratory, INSAT Institute, Tunis, Tunisia

Keywords:

Real-time, Reconﬁguration, Adaptive Control System, CHAMELEON System, Memory, Optimization.

Abstract:

The paper deals with a new Object Oriented Solution for Adaptive Control Systems having as name

CHAMELEON. The CHAMELEON system provides more ﬂexibility and a gain in memory compared to

the Classical Oriented Object Approach. Firstly, we give a formalization of the solution. Then, we propose a

CHAMELEON meta-model and a sequence diagram to emphasize the dynamic aspects. Finally, an evaluation

is done in order to highlight the performance of the proposed approach.

1 INTRODUCTION

Embedded systems are playing an increasing role in

our daily life. They also affect different economic

areas such as transport, telecommunications, avion-

ics, etc. These systems are characterized by rigor-

ous functional and performance constraints which are

mainly imposed by their changing operational envi-

ronment. Thanks to the control theory, many ad-

vances have been accomplished yet in the streamline

of the mastery of the speciﬁcation and the implemen-

tation of both functional and reactive aspects of em-

bedded and real-time systems. However, the changing

requirements of the context and the variation of exe-

cution environments invoke the need to develop adap-

tive control systems. An adaptive control system is a

system that is able to reconﬁgure its behavior or its

architecture at runtime in order to meet (or to adapt

to) the context change. Several research studies have

focused on the development of recongurable control

systems (Zhuo and Prasanna, 2008), (O. Lysne and

Skeie, 2008), (W. Jigang and Wang, 2007). These

studies have dealt with many kinds of reconguration

such as static and dynamic conﬁgurations. None of

those works, to our best knowledge, has addressed

the problem of building an adaptive and dynamically

reconﬁgurable architecture framework for real-time

systems at runtime. Our contribution consists of de-

signing CHAMLEON which a new Object Oriented

infrastructure for the design and the implementation

of control systems. CHAMELEON shifts the classi-

cal object oriented paradigm to allow extreme ﬂexible

way of deﬁning objects, their behavior and collabo-

ration, thereby reducing memory consumption. The

paper is structured as follows: Section II deals with

the state of the art. The Case study is mentioned

in section III. Section IV presents our contribution

which consists in modeling the recongurable embed-

ded systems by chameleon system. Section V de-

scribes the meta-model and the sequence diagramme

of CHAMELEON system. We evaluate our proposi-

tion in section VI.

2 STATE OF THE ART

Nowadays, several research approaches have been

studied for the implementation of adaptive control

software: J. Cobleigh and Al. Wise proposes a hierar-

chical self- adaptive software model for robot systems

with fault tolerances (Cobleigh and al, 2002). D. Gar-

lan, B. Schmerl, and P proposes Rainbow that con-

sists of a two layer framework with an external ﬁxed

control loop for architecture based adaptation using

utility theory (Garlan and Steenkiste, 2004). Other

approaches focus on component adaptations such that

K-components (Dowling and Cahill, 2004). Many

works has been done in order to develop extending

middlewares with self-adaptation capabilities. Adap-

tive CORBA Template (Sadjadi and McKinley, 2004)

focuses on CORBA applications transparently weav-

297

Nafti A., Romdhani M. and Khalgui M..

CHAMELEON - New Object Oriented Solution for Adaptive Control Systems.

DOI: 10.5220/0005244902970304

In Proceedings of the 5th International Conference on Pervasive and Embedded Computing and Communication Systems (PECCS-2015), pages

297-304

ISBN: 978-989-758-084-0

 2015 SCITEPRESS (Science and Technology Publications, Lda.)

ing adaptive behavior into object request brokers at

runtime. Zhang and Cheng (Zhang and Cheng, 2006)

introduced an approach to create formal models of

adaptive programs behavior for analysis and imple-

mentation synthesis. Their approach separates spec-

iﬁcations of adaptive and non-adaptive behavior by

simplifying their use. Using models as formal spec-

iﬁcations of self-adaptive software systems has been

also proposed.Genie (N. Bencomo and Blair, 2008)

uses architectural models to support generation and

execution of adaptive systems for component-based

middlewares.

Although these contributions are interesting, we

believe they are limited when real-time conﬁguration

becomes a requirement for the adaptation of the sys-

tem to its environment. The current paper proposes an

original CHAMELEON-based solution for a required

ﬂexibility of the software as well as the optimal man-

agement of the used memory.

3 CASE STUDY: FESTO MPS

We present in this section the Benchmark Produc-

tion System FESTO (J.F. Zhang and Mosbahi, 2012)

(Khalgui, 2010) developed at Martin Luther Univer-

sity in Germany . Festo MPS is a platform used

by different universities for research and education

goals. Its platform is composed of three units (Fig-

ure 1): (i) Distribution Unit: composed of Pneumatic

Feeder and Converter to forward Cylindrical Work-

pieces from Stack to Testing Unit. (ii) Testing Unit:

composed of Detector, Elevator and Shift-Out Cylin-

der. It performs the checking of Workpieces for their

Height, Material Type, and Color. (iii) Processing

Unit: Workpieces that pass Testing Unit successfully

are forwarded to Rotating Disk of this unit for drilling.

We assume in this research work two drilling ma-

chines Drill1 and Drill2. Drill1 performs a simple

piercing whereas Drill2 performs a tapped piercing

of workpieces. Depending on the workpieces type,

the rotation of the Wick is equal to 15 rotations/s

for aluminum one and 20 rotations/s for bronze and

steel one. The result of the drilling operation is next

checked by a checker and ﬁnally the ﬁnished product

is removed from the system by an evacuator. To im-

plement actions performed by the drilling machines

Drill1 and Drill2, we propose the following set of

action methods: (i) On: to activate Drill1 or Drill2,

(ii) DownDo: to pierce a simple hole using the Drill1

Wick, (iii) Downt: to pierce a tapped hole using the

Drill2 Wick, (iv) Up: to elevate the Drill1 Wick or

Drill2 Wick after piercing, (v) Trans: to translate the

workpiece in order to drill a second hole, (vi) Of:

Figure 1: Operation of system FESTO. (M. Khalgui, 2010).

to deactivate Drill1 or Drill2. We use the attributes:

(i) Nbtour to indicates the number of Wick tour per

second which depends on Type of the workpiece,(ii)

Depth to indicate the depth of the hole pierced.

In our case study, 27 production modes of FESTO

MPS are considered according to Color c, Height h

and Types t of pieces. We cite the following cases:

• Case1: If c= ”red”, 10 =< h <= 20 and t= ”steel”

then, the drilling machine Drill2 is used with a

rotation equal to 20 rotations/s to do a tapped hole

having a depth of 5 cm in a single pass,

• Case2: If c= ”blue”, h > 30 and t= ”aluminum”

then, Drill1 and Drill2 are used with a rotation

equal to 15 rotations/s to do the piercing. In the

ﬁrst time, Drill1 does a simple hole having a depth

of 10 cm in two passes.

The trivial implementation of the 27 production

modes requires logically 27 software classes with a

valuable number of attributes and constants. Since we

are dealing with embedded systems with limited fre-

quency of processor and size of memory, the imple-

mentation of these 27 classes is not an easy solution to

deploy: this is the real-time problem that the current

paper deals with. All these problems lead us to pro-

pose an optimal solution that reduces the complexity

of the system by representing it with a one reconﬁg-

urable class that will cover all system conﬁgurations

and minimize the memory consumption besides the

number of context switching: It is the CHAMELEON

class that will be presented in the next section. Note

that the CHAMELEON class is an original concept

for reconﬁgurable software systems which is not pro-

posed in related works, and presents today a new

PECCS2015-5thInternationalConferenceonPervasiveandEmbeddedComputingandCommunicationSystems

298

challenge for the optimal implementation of reconﬁg-

urable systems.

4 CHAMELEON META MODEL

4.1 A Paradigm Shift in Modeling

Run-time Reconﬁguration

Among the criteria that we must ensure for a reconﬁg-

urable embedded system is the ﬂexibility and also the

reduction of the memory consumption since embed-

ded systems have a reduced memory size. To solve

these problems, we propose to present reconﬁgurable

embedded real-time systems by a new type of class

to be named CHAMELEON class. CHAMELEON is

a class that changes automatically its behavior from

a mode to another. It contains all the common meth-

ods for different execution modes and a set of spe-

ciﬁc methods for each conﬁguration. Instead of load-

ing the system by many objects representing the dif-

ferent conﬁgurations, we create one object related to

the CHAMELEON class which reduces certainly the

memory consumption compared to the oriented ob-

jected approach. When we switch from a conﬁgura-

tion to another one, we just activate the speciﬁc meth-

ods of the new conﬁguration and deactivate those of

the previous one. This reduces the number of con-

text switching and gives more ﬂexibility for the sys-

tem. A CHAMELEON class inherits from the Thread

class. To handle all possible reconﬁguration forms,

the CHAMELEON class has three tables allowing the

run-time reconﬁgurations of its methods as well as at-

tributes for a ﬂexible adaptation to changes in the en-

vironment according to user requirements.

4.2 Formalization of CHAMELEON

Class

CHAMELEON is a new type of Object Oriented

Classes for ﬂexible systems that should be recon-

ﬁgured at run-time. Three possible reconﬁguration

forms can be applied on CHAMELEON: (i) Method

reconﬁguration: activation or deactivation of methods

at run-time, (ii) Scheduling reconﬁguration: modiﬁ-

cation of the execution orders of methods inside the

CHAMELEON object, (iii) Attribute-Constant recon-

ﬁguration: the modiﬁcation of values according to

user requirements.

4.2.1 Method Reconﬁguration

The different possible reconﬁgurations of methods

can be represented in the speciﬁcation level by a ﬁnite

state machine FSM

meth

. A FSM

meth

is composed of n

states such that each one represents a subset of meth-

ods to be active for the implementation of the class at

a particular time t. Each transition in this state ma-

chine represents a reconﬁguration scenario allowing

the addition-removal of methods. We implement this

ﬁnite state machine FSM

meth

by an architecture Table

to be denoted by AT. AT is a matrix (n,p) of integers

where n is the number of system conﬁgurations and p

is the number of all its methods ( active and deactive).

AT is formed from the ﬁnite state machine FSM

meth

such that each state represents a row in the table AT.

The method reconﬁguration is applied according to

the table AT, which is given by:

AT[i][ j] =



1, if M

∈ A

0, i f M

/∈ A

(1)

Where:

• M

: the j

method of the system, j=1..p,

• Ai: the i

conﬁguration of the system (e.g. a set

of active methods), i=1..n.

Note that an object is attached to each method M

(j=1..p). When a method is activated by a given con-

ﬁguration A

(i=1..n), the corresponding cell in the ta-

ble AT takes 1 and its corresponding object is instan-

tiated. When a method is deactivated, the correspond-

ing cell in the table AT takes the value 0 and the cor-

responding object is deleted. Finally, we denote by

(t) the i

implementation of the system at a partic-

ular time t.

Running Example 1. To simplify, We assume that

the Festo MPS system does three types of piercing

(e.g. three conﬁgurations). We suppose that the sys-

tem runs at a particular time t1 with the conﬁguration

(t1) such that :

(t1) = {On, Downt,U p,Of}

when a new reconﬁguration scenario is applied at

time t2, the system changes to a new conﬁguration

(t2) such that:

(t2) = {On, Down,U p, Trans,Of}

The corresponding state machine is composed of

three states as follows (Figure 2):

Since FSM

Meth

contains three states, AT is com-

posed also of three rows (Table 1).

Table 1: Architecture table for FESTO MPS.

M on down downt up trans of

A1 1 0 1 1 0 1

A2 1 1 1 1 1 1

A3 1 1 0 1 1 1

CHAMELEON-NewObjectOrientedSolutionforAdaptiveControlSystems

299

Figure 2: FSM of method reconﬁguration for FESTO MPS.

Each state in the FSM

meth

and its corresponding

row in AT, is a conﬁguration of the system FESTO

MPS. At a time t, if the system is in architecture A

only the methods On, Down, Up and Case1 are acti-

vated and its corresponding cells in the table AT takes

the value 1 whereas the other cells takes 0. When the

system changes from the architecture A

to A

, the

method Downt is activated and its corresponding cell

in AT takes the value 1 whereas the method Down and

Trans are deactivated and their corresponding cells in

AT take 0.

4.2.2 Scheduling Reconﬁguration

The scheduling reconﬁguration is a reconﬁguration

allowing the modiﬁcation of the methods schedul-

ing according to conﬁguration requirements. For

each state of FSM

meth

in the method reconﬁguration

level. We deﬁne down a new nested state machine

NSM

sched

, (h=1..n) in the scheduling reconﬁguration

level to show all possible scheduling of active meth-

ods in the upper level. We supposethat each NSM

sched

is composed of k

states. Each state of NSM

sched

is a ﬁnite state machine FSM

sched

,i = 1..k

that is

composed of q

states such that each one is rela-

tive to an active method. FSM

sched

represents a pos-

sible scheduling of the active methods relative to a

conﬁguration in FSM

meth

(Figure 3). We implement

NSM

sched

by a scheduling table to be denoted by ST

such as a state in the ﬁrst is a row in the second. ST

a matrix (k

, q

) of integers such that q

is the number

of activated methods and k

is the number of all pos-

sible scheduling for q

activated methods. The values

in the table ST

indicate the execution order of meth-

ods. Indeed, each box in ST

indicates the order of

each call for an activated method. For each conﬁgu-

ration, we have a set of methods to be executed. The

scheduling table shows all the possible execution or-

ders of these methods. If a method is called more than

one time, then ST

indicates the order of each call. The

scheduling reconﬁguration is applied according to the

table ST

given by:

∀ 1 =< i <= k

,1 =< j <= q

,1 =< h <= n :

[i][ j] = {a

..a

}

(2)

where:

• a

..a

: the set of the execution order of the

method M

, j = 1..q

for the i

scheduling of

FSM

sched

We denote by S

(t) the i

scheduling of the active

methods relative to the h

architecture A

(t) at a par-

ticular time t.

Running Example 2. At time t1, if the conﬁgura-

tion A1(t1) is loaded, then the activated methods are

On, Downt, Up, Of. The scheduling in this case is

assumed to be:

) = {{1},{2},{3}, {4}}

Indeed, 1, 2, 3 and 4 indicates respectively the

execution order of On, Downt, Up and Of. At time

t2, if the conﬁguration A

(t2) is loaded, then the

activated methods are On, Down, Downt, Up, Trans,

Of. For this conﬁguration, there are two scheduling

for FESTO MPS which are:

) = {{1, 7},{2,4},{8,10},{3,5, 9,11},{6},

{12, 13}}

) = {{1, 5},{2}, {6}, {3, 7}, {4},{8,9}}8, 9}}

For example, the method Up is called 4 times to do

two holes having a depth equal to 10 cm in two passes.

The values 3, 5 indicate the execution order of Up to

do the ﬁrst hole for the ﬁrst pass and the second one.

The values 9, 11 are the execution orders of Up to

do the second hole for the ﬁrst pass and the second

one. The table ST

is formed from the NSM

sched

. It

is composed of 6 columns which are the number of

active method and two rows that indicate the possible

schedulings for the architecture A

(Table 2).

Table 2: Scheduling table ST2 for FESTO MPS.

on down downt up trans of

1,7 2,4 8,10 3,5,9,11 6 12,13

1,5 2 6 3,7 4 8,9

4.2.3 Data Reconﬁguration

The data reconﬁguration is a reconﬁguration allow-

ing the modiﬁcation of values of attributes according

to conﬁguration requirements. The data conﬁguration

represents all the data values related to active meth-

ods for a given conﬁguration. It is given by the ta-

ble named Data table DT

, h=1..n and 1 =< i <= k

corresponds to a particular architecture table AT

and scheduling table ST

. It is a matrix (l

) of inte-

gers such that l

is the number of elements in a subset

PECCS2015-5thInternationalConferenceonPervasiveandEmbeddedComputingandCommunicationSystems

300

Figure 3: states machines for CHAMELEON system.

of the active methods, l

= 1..q

, t

is the number of

active attribute related to these methods. This table

contains the set of values of each active attributes for

a given scheduling. The data reconﬁguration is ap-

plied according to the table DT

, which is given by:

∀ 1 =< i <= q

,1 =< j <= t

,h = 1..n,

1 =< l <= k

[i][ j] = {v

..v

}

(3)

Where:

• y: the executions number of each activated

method,

• v

..v

: indicate the different value of the attribute

j for the different executions of the method i in

the same ﬁxed scheduling (e.g. the method i is

executed y times in this scheduling).

Note that an object is attached to each variable.

When a variable is activated by a given conﬁguration

and a scheduling S

, it will be mentioned in the

table DT

with its values for each activated method

according to the ﬁxed scheduling. In fact, when the

system changes from a conﬁguration to another, we

activate a set of variables and deactivate others. we

denote by D

(t) the data conﬁguration relative to the

scheduling S

(t) of the h

architecture A

(t) at a

particular time t.

Running Example 3: When the Festo MPS is run-

ning in the architecture A

and in the ﬁrst corre-

sponding scheduling S

, the corresponding Data Ta-

ble DT

is as follow ( Table 3):

Table 3: Scheduling table ST2 for FESTO MPS.

Method

variable

depth nb tour

down 5, 10 15, 15

downt 5, 10 15, 15

This table gives the values of variables depth and

nbtour when calling the method Down and Downt.

In this conﬁguration, the drilling machine makes the

piercing of two holes for aluminum workpieces, the

ﬁrst is a simple hole and the second is tapped.Firstly,

the method Down is called to do the ﬁrst pass of the

simple hole with a depth equals to 5 and a number

of wick rotation equals to 20. In the second time,

the method Down is called for the second pass with a

depth of 10 and a number of rotation equal to 20. The

same is repeated for the second drill hole by calling

Downt.

The data conﬁguration in this case is as follows:

)={{{5,10},{ 15,15}},{{5,10},{15,15}}}

Note that this classiﬁcation covers all pos-

sible reconﬁgurations form that we can apply

to adapt a chameleon class to its environment:

(i):additionel/remove and modiﬁcation of execution

order of methods,(ii) update of attributes. So, the i

conﬁguration (i=1..n) of the CHAMELEON class CH

at time t is given by:

CH(t) = {A

(t),S

(t),D

(t),AT,ST

,DT

} (4)

• j: the number of the schedulings relative to the

conﬁguration i, j = 1..k

5 UML BASED DESIGN

5.1 Meta-model Caracterisation

Based on the formalization done in the previous sec-

tion, we elaborate the CHAMELEON meta-model

given by Figure 4.

The CHAMELEON is composed of one architec-

ture table AT which is composed of n architecture

conﬁguration (.e.g a set of active methods). For each

CHAMELEON-NewObjectOrientedSolutionforAdaptiveControlSystems

301

Figure 4: Meta-model of CHAMELEON system.

Figure 5: Sequence diagram for initialisation of system ta-

bles.

architecture conﬁguration, there is n scheduling tables

ST. Each table ST contains all possible scheduling for

the active methods. For each scheduling is related one

data table DT that represents a data conﬁguration(.e.g

a set of active data).

5.2 Sequence Diagram

To illustrate the dynamic aspect and all the possible

reconﬁguration, we detail in this section the sequence

diagrams. At the ﬁrst time, the user calls initmethod-

table(), initschedulingtable(), initdatatable() and to

initialize respectively AT, ST, DT (Figure 5). when an

event happens, the system will pass from an architec-

ture i to a another j. The CHAMELEON method calls

the method architecture(i,j). Architecture(i,j) consults

the table AT and points to the next row to determine

which methods should be activated (Figure 6).

The CHAMELEON method calls data(j) that will

do the data reconﬁguration. Data(j) points to the data

table DT and activates the attributes related to acti-

vated methods.(Figure 7). Then the CHAMELEON

Figure 6: sequence diagram of architecture conﬁguration

for CHAMELEON system.

Figure 7: sequence diagram of data conﬁguration for

CHAMELEON system.

methods call the method scheduling(j) which consults

the scheduling table ST relative to the current archi-

tecture conﬁguration and calls the action methods in

the execution order mentioned in ST (Figure 8).

Once the conﬁguration is done, the method ar-

chitecture(i,j) deactivates the action methods previ-

ously activated, the method data(j) deactivates the at-

tributes.(Figure 9).

PECCS2015-5thInternationalConferenceonPervasiveandEmbeddedComputingandCommunicationSystems

302

Figure 8: sequence diagram of scheduling for

CHAMELEON system.

Figure 9: sequence diagram of method and data deactiva-

tion in the CHAMELEON system.

6 EVALUATION

The goal of this evaluation is to get early performance

measurements of the CHAMELEON implementation

impact when used in modeling a real-time applica-

tion. We considered the Festo MPS benchmark pro-

duction system which has been presented earlier in

section III as a running example. We also chosen

the Java programming language and its related perfor-

mance tool-set mainly JConsole and Java VisualVM

as a technical infrastructure for this evaluation.

6.1 Preparing the Testbench

In order to assess the impact of the CHAMELEON

approach of FESTO MPS production system, we have

produced two alternative models for the FESTO MPS

system:

6.1.1 A First ”CHAMELEON less” Model

This model implements the FESTO system using a

classical Object Oriented approach. In this model, an

abstract Java class called Drilling encapsulates the set

of the methods that correspond the basic behaviors of

FESTO and this class is reﬁned in terms of more spe-

ciﬁc classes in order to enrich the basic behavior or

redeﬁne some of the polymorphic methods.

6.1.2 A Second CHAMELEON Based Model

This model implements the FESTO system using the

CHAMELEON meta-model concepts presented in IV.

In this model, the Drilling objects are Java objects

that do not have any known methods at compile-time

but those are ”injected” dynamically at run-time. The

dynamic conﬁguration and reconﬁguration of the ob-

jects at run-time according to the actual context is the

key feature of CHAMELEON. In terms of OO pro-

gramming, this feature should promote an extreme

degree of behavior reuse and ensures that objects

are lightweight. The CHAMELEON based model of

FESTO MPS system has been written in Java.

6.2 Results

We highlight ﬁrst that both the polymorphism and the

CHAMELEON model of FESTO MPS system do the

same functionality. Performance analysis results ob-

tained using Java Visual VM of the two models are

shown in the ﬁgures below. We focus mainly on mem-

ory consumption since CPU performance shows that

there is no remarkable differences between the two

models.

Figure 10: Consumption by FESTO MPS in the polymor-

phism model.

We notice that the CHAMELEON model of

FESTO optimizes the memory (heap) consumption.

The required heap size is only of 1202 KB (ﬁgure 10).

In the case of the CHAMELEON less model the re-

quired heap size is 1341 KB (Figure 11).

The CHAMELEON model provides a minimiza-

tion of memory consumption equal to 10 percent

compared to the polymorphism model.

6.3 Explanation

The CHAMELEON approach optimizes the memory

consumption since, unlike the OO approach, the ob-

jects does not have a set of known methods at com-

pile time. In the OO approach, each object that is

CHAMELEON-NewObjectOrientedSolutionforAdaptiveControlSystems

303

Figure 11: Memory (Heap) Consumption by FESTO MPS

in the CHAMELEON model.

an instance of the Drilling class has its self copy of

attributes and methods. This duplication of contexts

causes extra memory consumption that may be aggra-

vated when the application involves a large number

of collaborating objects. The memory performance

may also be negatively impacted by applications that

involve a large number of methods or heavy process-

ing methods. However, in the CHAMELEON sys-

tem there is an additional memory footprint required

for the dynamic management of object contexts (data,

methods, conﬁgurations). But the memory cost of

these meta data structures are insigniﬁcant when com-

pared with the memory cost of application objects.

7 CONCLUSION

In this paper, we present a new approach for mod-

eling reconﬁgurable embedded systems which is

CHAMELEON meta-model. This concept covers all

possible reconﬁguration forms that can be applied

at run-time to adapt the system to its environment

and the user requirement. CHAMELEON classes

can add/remove at run-time, modify their execution

orders, update attributes and constants. We have

proven that this approach minimizes greatly the mem-

ory consumption compared to the polymorphism ap-

proach especially when the system has many conﬁgu-

rations. We plan in the future work to enrich this con-

cept with several features such as real-time, memory,

power, quality. We plan also to study the collabora-

tive CHAMELEON classes that should synchronize

their run-time behavior in order to prevent any inco-

herent conﬁgurations. Finally, we plane to new solu-

tion for optimal teste of CHAMELEON classes since

this kind of veriﬁcation is not exhaustive.

REFERENCES

Cobleigh, J. and al (Nov 2002). Containement units: a hi-

erarchically composable architecture for adaptive sys-

tems. ACM SIGSOFT Software Engineering Notes.

Dowling, J. and Cahill, V. (2004). Self-managed decen-

tralised systems using k-components and collabora-

tive reinforcement learning. CM SIGSOFT workshop

on Self-managed systems.

Garlan, B. S. and Steenkiste, P. (2004). Rainbow:

architecture-based self-adaptation with reusable in-

frastructure. International Conference on Autonomic

Computing.

J.F. Zhang, M. Khalgui, Z. L. and Mosbahi, O. (2012). R-

tnces: a novel formalism for reconﬁgurable discrete

event control systems. IEEE Transactions on Systems,

Man and Cybernetics, Part A: Systems and Humans.

Khalgui, M. (2010). Nces-based modelling and ctl-based

veriﬁcation of reconﬁgurable embedded control sys-

tems. Computers in Industry 61, pp.198212.

M. Khalgui, O. Mosbahi, Z. L. H. M. H. (2010). Reconﬁg-

urable multi-agent embedded control systems: From

modelling to implementation. IEEE Transactions on

Computers.

N. Bencomo, P. Grace, C. F. D. H. and Blair, G. (2008).

Genie: supporting the model driven development of

reﬂective, component-based adaptive systems. Inter-

national conference on Software engineering.

O. Lysne, J.-M. Montanana, J. F. J. D. T.-M. P. and Skeie, T.

(2008). An efﬁcient and deadlock-free network recon-

ﬁgurable protocol. IEEE Transactions on Computers.

Sadjadi, S. and McKinley, P. (2004). Sact: an adap-

tive corba template to support unanticipated adapta-

tion. International conference on Distributed Comput-

ing Systems.

W. Jigang, T. S. and Wang, X. (2007). Integrated row

and column rerouting for reconﬁguration of vlsi ar-

rays with four-port switches. IEEE Transactions on

Computers.

Zhang, J. and Cheng, B. H. C. (2006). Model-based devel-

opment of dynamically adaptive software. 28th inter-

national conference on Software engineering.

Zhuo, L. and Prasanna, V.-K. (2008). High-performance

designs for linear algebra operations on reconﬁgurable

hardware. IEEE Transactions on Computers, vol.57,

no.8.

PECCS2015-5thInternationalConferenceonPervasiveandEmbeddedComputingandCommunicationSystems

304