New Multi-Token based Protocol for Flexible Networked

Microcontrollers

Imen Khemaissia

1,2

, Olfa Mosbahi

and Mohamed Khalgui

Cynapsys Company, France-Germany

Faculty of Sciences, Tunis El-Manar University, Tunis, Tunisia

National Institute of Applied Sciences and Technology, INSAT, University of Carthage, Tunis, Tunisia

Keywords:

Microcontroller, Networked STM32F4, Token Ring, Reconﬁguration, Multi-agent Architecture, Communi-

cation Protocol.

Abstract: This research

paper deals with reconﬁgurable networked microcontrollers following the STM32F4 technol-

ogy. These controllers based on the token ring architecture, are planned to be reconﬁgurable according to

user requirements, and should be automatically adapted at run-time to their environment. A reconﬁguration

scenario is assumed to be any run-time automatic addition/removal/update of OS periodic tasks to/from dif-

ferent STM32F4 microcontrollers. Nevertheless, if simultaneous and concurrent scenarios appear in different

controllers, then we can get unpredictable critical behaviors of the whole distributed system. A multi-agent

architecture is deﬁned where Request and Coordination Agents are assigned to each microcontroller to handle

local reconﬁguration scenarios after coordination with remote controllers. A tool is developed to simulate

a real-case study. We discuss the paper’s contribution by analyzing the experimental results that we did on

Networked STM32F4 microcontrollers.

This research work is a collaboration between LISI Lab at INSAT and Cynapsys Company. We thank

Ing. Souhail KCHAOU R&D Manager and Ing. Haythem TEBOURBI Technical Manager who supported the

implementation of the current paper’s contribution. We thank also Mohamed Aymen Jouini for a collaboration

in the implementation part.

1 INTRODUCTION

The networked microcontrollers are widely used to-

day for the new generations of embedded systems

(J. Garc´ıa, ) especially for the modern vehicles in

order to offer more functionalities in these automo-

biles. Due to possible external or also internal distur-

bances, the system can be automatically adapted by

adding/removing/updatingOS periodic to/from/in the

microcontrollers. Nevertheless, some real-time con-

straints may be violated and the system becomes un-

feasible. Today rich related works have been ded-

icated to develop reconﬁgurable real-time embed-

ded control systems (M. Khalgui and Hanisch, 2011)

(C. Angelov and Marian, 2005) (K. Thramboulidis

and Frantzis, 2004) (George and Courbin, ) (Z. Gu,

2008). Several algorithms are proposed to schedule

their changeable OS tasks at run-time (S. Baruah and

Rosier, 1990) (Pellizzoni and Lipari, 2004) (Liu and

Layland, 1973) (Spuri and Buttazzo, 1996). A recon-

ﬁguration can be any operation adapting the hardware

or software components. A software reconﬁguration

is deﬁned by the run-time addition/removal/update of

OS tasks to be assumed periodic. A hardware recon-

ﬁguration means the activation/deactivation of con-

trollers in order to optimize the energy consumption

which is a major problem for embedded systems. We

are interested in our work in dynamic software recon-

ﬁgurations that we assume automatic to be performed

at run-time. The goal is to establish a coordination

between the different microcontrollers after any re-

conﬁguration. This paper assumes that if a microcon-

troller mic

applies a reconﬁguration scenario to adapt

its execution according to user requirements for ex-

ample, the rest should perform also coherent behav-

iors to be adaptive to this execution. Otherwise, the

whole system will be oriented to unpredictableand in-

coherent behaviors on different microcontrollers. The

solution is to allow of course the required reconﬁg-

urations at run-time but we should also guarantee a

coherent distributed behavior. We aim in this paper to

allow ﬂexible networked microcontrollers that should

464

Khemaissia I., Mosbahi O. and Khalgui M..

New Multi-Token based Protocol for Flexible Networked Microcontrollers.

DOI: 10.5220/0005014304640469

In Proceedings of the 9th International Conference on Software Engineering and Applications (ICSOFT-EA-2014), pages 464-469

ISBN: 978-989-758-036-9

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

be adapted to their environment at run-time, neverthe-

less, this ﬂexibility should guarantee the perfect co-

herence between microcontrollers. We assume that

any possible reconﬁguration scenario can only be re-

sumed in one of the following levels: 1) Architecture

level: we add-remove OS periodic tasks in a micro-

controller, 2) Composition Level: we keep the same

architecture of tasks but we change their scheduling

in a controller, 3) Data Level: we change the values

of data according to user requirements. To allow a re-

quired coherent distributed behavior after any recon-

ﬁguration scenario, we propose a multi-agent archi-

tecture where Request and Coordination Agents (RA

and CA

) are deﬁned for each microcontroller. RA

deﬁnes local reconﬁguration scenarios in the micro-

controller and CA

coordinates with the remote con-

trollers to apply this scenario. We propose a Multi-

Token based protocol (L. Gauthier and Jerraya, 2001)

(Henzinger and Sifakis, 2006) for the coordination

between microcontrollers at run-time. This protocol

is based on the architecture, composition and data lev-

els. Three types of tokens are proposed: Architecture,

Composition and Data Tokens. First of all, if RA

wants to apply a reconﬁguration scenario that mod-

iﬁes the software architecture, the scheduling and the

values of some data; the related CA

is requested to

perform this modiﬁcation. The latter sends an Archi-

tecture Token to all the remote controllers. This to-

ken will be accepted if it has a highest priority among

all tokens which are sent on the network. If CA

re-

ceive the acceptance of this token, then it sends the

scheduling one in order to get the acceptance of re-

mote controllers. Then it sends the last data token and

waits the acceptance of the remote controllers too. We

have used three different types of tokens in order to

get an optimal step-by-step adaptation of the system.

Indeed, it is not signiﬁcant to negotiate the schedul-

ing with remote microcontrollers when the new ar-

chitectures are not yet ﬁxed. We assume in the cur-

rent paper a distributed embedded system following

the STM32F4 technology. This new technology of

microcontrollers is well-used today in industry since

they are cheaper than other controllers. We developed

at the company Cynapsys a tool for the simulation of

this protocol on real STM32F4 and we show the ben-

eﬁts of the paper’s contribution. The rest of the paper

is organized as follows: In Section 2 the case study to

be followed as a running example. We present in Sec-

tion 3 the proposed Multi-Agent Architecture. The

multi-microcontroller protocol is proposed in Section

4, before we implement, simulate and analyze the

whole architecture in Section 5. Section 6 concludes

ﬁnally this research work.

2 CASE STUDY

We assume as a running example a reconﬁgurable

distributed system to be composed of two microcon-

trollers. In this work, the different LEDs will be used

to differentiate the different reconﬁguration steps that

will be detailed in the next sections. We assume that

each micro-controller contains several periodic OS

tasks such that each one produces periodic jobs ac-

cording to (Liu and Layland, 1973). It is character-

ized by: (1) A release time R, (2) A period T, (3) A

deadline D, (4) A WCET C and (5) A static priority S.

We assume that these tasks are periodic, synchronous,

i.e, R = 0 and with precedence constraints. Table 1

represents the initial tasks of mic

and mic

. Table 2

represents the added tasks of mic

and mic

, respec-

tively.

Table 1: The characteristic of the initial tasks of mic

and

mic

Tasks C

mic

2 10 mic

4 15 mic

7 30 mic

3 20 mic

5 20 mic

6 20 mic

Table 2: The characteristic of the added tasks of mic

Tasks C

mic

1 15 mic

2 30 mic

1 30 mic

6 20 mic

3 30 mic

9 30 mic

We assume the following precedence constraints

between the tasks to be uploaded on both mic

and

mic

in order to offer the global service of the dis-

tributed system. We assume that τ

must be executed

after τ

and τ

must be executed before τ

. We as-

sume that the latters are reconﬁgurable. For each con-

troller, we deﬁne two different implementations of

tasks. Note also that these controllers apply each time

a unique distributed reconﬁguration scenario.

Running example 1 At a particular time t1, if mic

decides to apply a reconﬁguration scenario by removing

and mic

wants to keep τ

. It is one of the incoherence

that can be happen if there is no coordination between the

microcontrollers. For that, a protocol should be proposed

in the current paper to coordinate between the different

microcontrollers and avoid the incoherence in a network

of microcontrollers.

NewMulti-TokenbasedProtocolforFlexibleNetworkedMicrocontrollers

465

3 MULTI-AGENT BASED

ARCHITECTURE

We formalize in this section the networked real-time

microcontrollers that we assume adaptive to their en-

vironment. The distributed system is composed of n

STM32F4 controllers to be linked with a token ring

topology and serial ports. After applying a reconﬁgu-

ration scenario, the coherence between the microcon-

trollers can not be guaranteed. We propose a multi-

agent architecture where we propose for each micro-

controller a Request Agent RA that deﬁnes the recon-

ﬁgurations to be applied locally, and a Coordination

Agent CA which manages any coordination with re-

mote controllers after any reconﬁguration scenario.

3.1 Request Agent Modeling

The request agent RA is responsible of the local soft-

ware reconﬁgurations in the microcontroller. We con-

sider three forms of reconﬁgurations to be locally ap-

plied at run-time: (i) Architectural Reconﬁguration

allowing the addition-removal of OS tasks at run-

time to-from the controller, (ii) Scheduling Recon-

ﬁguration allowing the modiﬁcation of the compo-

sition of tasks without modifying their architecture,

(iii) Data Reconﬁguration allowing the modiﬁcation

of values of data while keeping the same architecture

and scheduling. The idea of our paper is as follows:

suppose that a Request Agent of a controller wants

to apply a deep reconﬁguration that changes the ar-

chitecture (adds-removes tasks), the scheduling (the

composition of some tasks) and the values of some

data. This reconﬁguration should be applied with

the agreement of remote controllers in order to ap-

ply a coherent and correct distributed behavior of the

whole system. We model the agent RA by nested state

machines which are studied in several researches be-

fore(Rausch and Hanisch, 1995) (Hanisch and Luder,

). We assume that the architecture level is speciﬁed by

an architecture state machine SAm for each microcon-

troller m ∈ [1, n] where each state represents a partic-

ular proposed architecture. We deﬁne for each state

SAm

of SAm a composition state machine to be de-

noted by SCm. It represents the different schedules

that can be applied if this particular architecture SAm

is applied. The data level is speciﬁed by data state ma-

chine state machines such that each one SDm

corre-

sponds to a particular state SCM

i, j

of SCM

. The agent

automatically applies at run-time different reconﬁg-

uration scenarios where each scenario is denoted by

i, j,k,h

and corresponds to (i) an architecture state in

the top level, (ii) scheduling state in the second level,

(iii) data state in the bottom level as follows:

• The architecture State SAm

: a state of SAm that

corresponds to a particular set of tasks to be lo-

cally executed in the microcontroler,

• The Composition State SCm

i, j

: a state describing

a possible scheduling of these tasks according to

user requirements. This state belongs to a state

machine that corresponds (in the second level) to

SAm

• The Data State SDm

k,h

: a state that corresponds in

the third level to particular values of data that we

attach to the tasks of SAm

3.2 Coordinator Agent

The coordination agent CA of a microcontroller co-

ordinates with remote controllers to look for the ap-

plication of the desired reconﬁgurations from RA

. In

a particular controller i (i = 1...n), the controller CA

sends a request to the remote coordinatoragents of the

rest of controllers. These coordinators analyze this

request with their RA agents to possibly decide if the

request of CA

is acceptable or not. If all the coordi-

nators of the different remote microcontrollers agree

the request ofCA

, then this reconﬁguration is applied

since the coherence is guaranteed.

3.3 Token

To apply this protocol, we propose three types of to-

kens: (i) Architecture Token, (ii) Scheduling Token,

(iii) Data Token. The Coordination Agent sends ﬁrst

a Token Agent in order to have an authorization from

remote controllers. This token has a priority and can

be rejected from the network if another Architecture

Token with a higher priority is sent. The Coordination

Agent waits the authorization from all remote con-

trollers before applying effectively this reconﬁgura-

tion. The architecture of the different distributed tasks

is ﬁxed at this level in the different controllers. CA

sends now a new Scheduling Token in order to deﬁne

the scheduling of the local tasks and also in the rest

of controllers. When an agreement is received, CA

sends then a Data Token in order to ask the applica-

tion of reconﬁgurations allowing the modiﬁcation of

data. This step-by-step reconﬁguration is useful since

it is not important to apply architectural, scheduling

and data reconﬁgurations at the same time. We note

ﬁnally that these tokens are described in the transi-

tions of the nested state machines of each RA.

3.3.1 Token Architecture

The architecture token is deﬁned by a Matrix where

the lines represent the microcontrollers of the system

ICSOFT-EA2014-9thInternationalConferenceonSoftwareEngineeringandApplications

466

and the columns are as follows (Three columns):

• Column 1: Architecture ”added/removed tasks”,

• Column 2: Priority of the architecture,

• Column 3: Decision of CA

(1 or 0). After a re-

conﬁguration request, CA

will answer by 1 or 0

where:

– 1, if the reconﬁguration is authorized,

– 0, if the reconﬁguration is not authorized.

3.3.2 Token Composition

For a particular architecture, a token composition is

deﬁned. The columns are as follows:

• Column1: The given schedule,

• Column2: The priority.

Note that the priority of each schedule is modiﬁed ac-

cording to user requirement.

3.3.3 Token Data

When an agreement is received after the composition

level, CA

sends then a Data Token in order to ask the

application of reconﬁgurations allowing the modiﬁca-

tion of data. A Data Token is composed two columns

that represent the new values of data and its prior-

ity that will be applied for a given architecture after

scheduling.

3.4 Running Example

We deﬁne a nested state machine for RA

and RA

The architecture level of mic

is characterized by two

different architectures:

• SA1

: composed of τ

, τ

and τ

• SA1

: composed of τ

, τ

and τ

For SA1

, we have 2 possibilities of schedules:

• SC1

: τ

, τ

and τ

• SC1

: τ

, τ

and τ

For SA1

, we have 3 possibilities of schedules:

• SC1

: τ

, τ

and τ

• SC1

: τ

, τ

and τ

• SC1

: τ

, τ

and τ

For SD1

, the periods must be equal to 20 but for

SDA2

, they will be equal to 30 Time Units. For a

given SC1

, SC1

and SC1

the periods will be equal

to 20, 30 and 40, respectively.

The architecture level of mic

is characterized by two dif-

ferent architectures:

• SA2

: composed of τ

, τ

and τ

• SA2

: composed of τ

, τ

and τ

Since τ

is executed after τ

and τ

is only in SA1

. Then

will be in SA2

and not SA2

. Similar for τ

, it will be

in SA2

since it has a precedence constraint with τ

which

is in SA1

. For SA

, we have 2 possibilities of schedules:

• SC2

: τ

, τ

and τ

• SC2

: τ

, τ

and τ

For SA

, we have 2 possibilities of schedules:

• SC2

: τ

, τ

and τ

• SC2

:τ

, τ

and τ

The composition states SC2

and SC2

, the periods are

modiﬁed to be equal to 30 and 40, respectively. For a given

SC2

, the period is equal to 30 Time Units.

At a particular time t1, RA

chooses to apply SA1

and

chooses to apply SA2

. We assume that SA1

has

the highest priority. A token architecture is represented by

table 3. If CA

receive the acceptance of this token from

, then it sends the composition one which is deﬁned by

table 5 in order to get the acceptance of CA

. If the latter

give its authorization, then CA

sends the last data token

shown by table and waits for the answer of CA

Table 3: Architectural Matrix.

MiC

/Rec

Architecture Priority DecisionofCA

mic

SA1

1 1

mic

SA2

0 1

Table 4: Data Matrix.

CA data Priority

SD1

Table 5: Composition Matrix.

CA Schedule Priority

SC1

4 COMMUNICATION

PROTOCOL

We propose a protocol for coherent distributed recon-

ﬁgurations of networked microcontrollers. Let we as-

sume that this protocol is based on the following three

parts::

• Part 1: RA of a particular microcontroller detects

a reconﬁguration request.

NewMulti-TokenbasedProtocolforFlexibleNetworkedMicrocontrollers

467

• Part 2: relation RA−CA: CA receives this request

and veriﬁes according to its conditions if RA can

apply this reconﬁguration or not. CA will check

if this applied reconﬁguration lead it to apply an-

other corresponding reconﬁguration. If it is the

case, it will inform the correspond RA to request

the new reconﬁguration.

• Part 3: communication between CA and the re-

mote microcontrollers: every CA asks the rest of

the CA if it has the authorization to apply a recon-

ﬁguration or not.

The reconﬁguration can be halted when architecture

or composition or data tokens are not authorized. The

goal of this protocol is to have useful and optimal dis-

tributed reconﬁgurations: if the microcontrollers do

not agree a suggested new architecture, then it is not

important to go to scheduling and so on. Algorithm

1 is developed to show the behavior of an RA when it

sends a request to CA

. Algorithm 2 shows the behav-

ior of the remote CA when they receive this request.

This algorithm is applied in all the different level of

reconﬁguration.

Algorithm 1: Communication Protocol.

Variables:

int CA

;// Coordination agent for each mic

int RA

; // Request agent for each mic

1. 1.

if (RA

sends an architecture request) then

if (answer(CA

)==1) then

Invoke algorithm 2;

end if

else

break;

end if

if (RA

sends a composition request) then

if (answer(CA

)==1) then

Invoke algorithm 2;

end if

else

break;

end if

if (RA

sends a data request) then

if (answer(CA

)==1) then

Invoke algorithm 2;

end if

else

break;

end if

Algorithms 1 and 2 are with complexity O(n

Algorithm 2: Communication CA-CA.

Variables:

int l=0; // counter for microcontrollers

boolean RR; // reconﬁguration request for each level Matrix

of integers:

Mat

decision

// Matrix containing the decision of the other mi-

crocontrollers for each level,

for each CA

, i! = j do

gives its answer;

Put this value in Mat

decision1

;

end for

for (l = 1; l ≤ size(Mat

decision1

); i+ + ) do

if l! = j then

if Mat

decision1

[l] == 1 then

Message=”Reconﬁguration is authorized”;

RR =1; //

else

RR =0;

break;

end if

end for

5 EXPERIMENTATION

The contribution of this paper is applied to a ring that

will be composed of 2 STM32F4 as said in the sec-

tions below. A tool is developed to apply this new

simple strategy in order to manage the coordination

between the different devices of the system at run-

time. We expose in this section our case study.

5.1 Architectural Level 1

The microcontroller mic

asks mic

to apply a recon-

ﬁguration scenario. It implements the architecture

SA1

. The microcontroller mic

activates the yellow

led when it asks the reconﬁguration. Two cases may

happen.

5.1.1 Case 1: Reconﬁguration is Authorized

According to table 6 the reconﬁguration is authorized

sinceCA

gives its authorization. Then, mic

activates

the yellow led.

Table 6: Architectural Decision.

MiC

/Rec

- 0

1 -

5.1.2 Case 2: Reconﬁguration is not Authorized

Table. 7 shows that the reconﬁguration SA1

is not

authorized. In this case, mic

will be light in red.

ICSOFT-EA2014-9thInternationalConferenceonSoftwareEngineeringandApplications

468

Table 7: Architectural Decision.

MiC

/Rec

- 0

0 -

5.2 Composition Level

The microcontroller mic

will ask to apply SD1

. The

microcontroller mic

will give the authorization to ap-

ply this schedule. In this level mic

will be light in

orange after the task addition. Table 8 shows the de-

cision of CA

Table 8: Composition Decision.

MiC

/Rec

- 0

1 -

5.3 Data Level

The microcontroller mic

must update the periods of

the tasks for a given architecture SA1

and a schedule

. mic

must gives its authorization as shown in

table 9. If it accepts this reconﬁguration. Then, it will

be light in blue. In our example, mic

will update the

relative periods to be equal to 20. The microcontroller

Table 9: Data Decision.

MiC

/Rec

- 0

1 -

mic

informs the microcontroller mic

that a particu-

lar reconﬁguration is applied. As a consequence, the

microcontroller mic

will react and apply a forced re-

conﬁguration. mic

reacts by lighting in blue like the

other microcontrollers.

6 CONCLUSION

This paper presents a new solution for feasible co-

ordination between STM32F4 microcontrollers of a

reconﬁgurable distributed system. A protocol is ap-

plied in step-by-step for optimal distributed reconﬁg-

urations or the system. We plan in future works to

deal with low-power and low-memory reconﬁgura-

tions of the same architecture by assuming heuristics-

based strategies since the problem is NP-Hard.

REFERENCES

C. Angelov, K. S. and Marian, N. (2005). Design models

for reusable and reconﬁgurable state machines. Proc.

of Embedded Ubiquitous Comput.

George, L. and Courbin, P. Reconﬁguration of unipro-

cessor sporadic real-time systems: the sensitivity ap-

proach. In chapter in IGI-Global Knowledge on Re-

conﬁgurable Embedded.

Hanisch, H.-M. and Luder, A. modular modelling of closed-

loop.

Henzinger, T. A. and Sifakis, J. (2006). The embedded

systems design challenge. Canada. 14th International

Symposium on Formal Methods.

J. Garc´ıa, F.R. Palomo, A. L. C. A. J. Q. D. C. F. G. P. R. J. P.

Reconﬁgurable distributed network control system for

industrial plant automation.

K. Thramboulidis, G. D. and Frantzis, A. (2004). Towards

an implementation model for fb-based reconﬁgurable

distributed control applications. Vienna. Proc. IEEE

7th Int. Symp. Object-Oriented Real-Time Dist. Com-

put.

L. Gauthier, S. Y. and Jerraya, A. A. (2001). Automatic gen-

eration and targeting of application-speciﬁc operating

systems and embedded systems software. In IEEE

Transactions on Computer-Aided Design of Integrated

Circuits and Systems.

Liu, C. L. and Layland, J. W. (1973). Scheduling algo-

rithms for multiprogramming in a hard real time envi-

ronment. J. Assoc. Comput. Mach.

M. Khalgui, O. Mosbahi, Z. W. L. and Hanisch, H.-M.

(2011). Reconﬁguration of distributed embedded-

control systems. IEEE/ASME Trans. Mechatronics.

Pellizzoni, R. and Lipari, G. (2004). A new sufﬁcient fea-

sibility test for asynchronous real-time periodic task

sets. in Proc. on 16th Euro. Conf.

Rausch, M. and Hanisch, H.-M. (1995). net condition/event

systems with multiple condition outputs. in Sympo-

sium on Emerging Technologies and Factory Automa-

tion.

S. Baruah, R. H. and Rosier, L. (1990). Algorithms and

complexity concerning the preemptive scheduling of

periodic real-time tasks on one processor. Real-Time

Syst.

Spuri, M. and Buttazzo, G. (1996). Scheduling aperiodic

tasks in dynamic priority systems. Real-Time Sys-

tems.

Z. Gu, M. Lv, Q. D. a. G. (2008). Schedulability analysis of

global ﬁxed-priority or edf multiprocessor scheduling

with symbolic model-checking. 11th IEEE Sympo-

sium on Object Oriented Real-Time Distributed Com-

puting.

NewMulti-TokenbasedProtocolforFlexibleNetworkedMicrocontrollers

469