RECONFIGURATION OF EMBEDDED SYSTEMS

∗

Mohamed Khalgui, Martin Hirsch, Dirk Missal and Hans-Michael Hanisch

Martin Luther University, Halle, Germany

Keywords:

Industrial Embedded Systems, IEC61499 Function Blocks, Reconﬁguration, Model-checking.

Abstract:

This paper deals with automatic reconﬁguration of embedded systems following the Component-based Stan-

dard IEC61499. First of all, we propose a new reconﬁguration semantic allowing the improvement of the

system performance even if there is no hardware fault. In addition, we characterize all possible reconﬁgura-

tion forms in order to cover all possible execution scenarios and to apply an automatic reconﬁguration, we

deﬁne thereafter an agent-based architecture that we model with nested state machines to control the design

complexity.

1 INTRODUCTION

Nowadays, the new generation of industrial control

systems is addressing new criteria as ﬂexibility and

agility. To reduce their cost, these systems have to

be changed and adapted to their environment with-

out any disturbance. Several academic and industrial

research works have been made to develop reconﬁg-

urable systems. We distinguish in these works two

reconﬁguration policies: the static and dynamic re-

conﬁgurations. The static reconﬁguration is applied

off-line to apply changes before the system cold start

(Angelovet al., 2005), whereas the dynamicreconﬁg-

uration is applied dynamically at run-time. In the last

policy, two cases exist: the manual reconﬁguration

applied by the user (Rooker et al., 2007) and the auto-

matic reconﬁguration applied by an intelligent agent

localized in the system (Al-Saﬁ and Vyatkin, 2007).

In this paper, we are interested in the automatic

reconﬁguration of industrial control systems which

have to satisfy according to user requirements func-

tional and temporal properties but their time to mar-

ket has to be shorter than ever. To satisfy all these

requirements,we use thecomponent-basedmethodol-

ogy supporting the modularity as well as the reusabil-

ity of already developed components. Today, sev-

eral rich technologies have been proposed to develop

component-based manufacturing systems and among

∗

This work is supported by the Humboldt foundation in

Germany under the reference TUN1127196STP.

all these technologies, the standard IEC61499 is pro-

posed by the International Electrotechnical Commis-

sion (IEC) to design the application as well as the cor-

respondingexecutionenvironment. A FunctionBlock

(FB) is a unit of software supporting functionalities

of an application and it is composed of an interface

and an implementation where the interface contains

data/event inputs and outputs supporting interactions

with the environment. Events are responsible for the

activation of the block while data contain valued in-

formation. The implementation contains algorithms

to execute when the corresponding events occur. The

selection of an algorithm to execute is performed by

a state machine called the Execution Control Chart

(ECC). The ECC is also responsible for sending out-

put events at the end of the algorithm execution. A

control application is speciﬁed by a network of FBs

such as each event input (resp. output) of a block

is linked to an event output (resp. input) by a chan-

nel and it corresponds otherwise to a global input

(resp. output). Data inputs and outputs follow the

same rules. Today, several research works on this

standard have been proposed (Khalgui and Thram-

boulidis, 2008), rich tools

and several industrial

platforms

have been developed while following this

standard.

In this paper, we aim to develop reconﬁgurable

IEC61499 control systems. Several research works

http://www.isagraf.com, http://www.holobloc.com

www.itia.cnr.it

157

Khalgui M., Hirsch M., Missal D. and Hanisch H. (2008).

RECONFIGURATION OF EMBEDDED SYSTEMS.

In Proceedings of the Fifth International Conference on Informatics in Control, Automation and Robotics - ICSO, pages 157-162

DOI: 10.5220/0001487001570162

 SciTePress

dealing with the reconﬁgurationof these systems have

been proposed (Angelov et al., 2005; Rooker et al.,

2007; Al-Saﬁ and Vyatkin, 2007) but they are limited

to particular cases (e.g. to resolve hardware faults or

to add new functionalities like the update of an al-

gorithm in a block) and they do not address all the

reconﬁguration reasons that can possibly occur in in-

dustry. We deﬁne a new semantic of the reconﬁgura-

tion to improve th e system performance even if there

is no hardware fault and we characterize all possi-

ble reconﬁguration forms that we can apply on a sys-

tem. To apply an automatic reconﬁguration at run-

time, we propose thereafter an agent-based architec-

ture to handle reconﬁguration scenarios bringing the

system into safe states. We model the agent accord-

ing to well suited formal formalism: the Net Con -

dition/Event Systems (denoted NCES) proposed by

Rausch and Hanisch in (Rausch and Hanisch, 1995).

We present in the next section the NCES formal-

ism and in Section3 the EnAS production system to

be used as an example in the paper. We deﬁne in Sec-

tion4 a new semantic of the reconﬁguration before

we detail in Section5 all reconﬁguration forms. Fi-

nally before conclusions, we present in Section6 the

Agent-based architecture to handle automatic recon-

ﬁgurations.

2 NCES FORMALISM

The formalism of Net Condition/Event Systems

(NCES) is an extension of the well k nown Petri net

formalism. It was introduced by Rausch and Hanisch

in (Rausch and Hanisch, 1995) and further developed

through the last years according to which a NCES is

a place-transition net formally represented by a tuple:

NCES =(P,T,F,CN ,EN,C

out

) where,

(1) P (resp, T) is a non-empty ﬁnite set of places

(resp, transitions), (2) F is the set of ﬂow arcs, F :

(PXT)



(TXP),(3)CN (resp, EN) is the set of con-

dition (resp, event) arcs, CN ⊆ (PXT) (resp, EN ⊆

(TXT)), (4) C

(resp, E

) is the set of condition

(resp, event) inputs, (5) C

out

(resp, E

out

)isthesetof

condition (resp, event) outputs, (6) B

(resp, B

)isthe

set of condition (resp, event) input arcs in a NCES

module, (7) B

⊆ (C

XT) (resp, B

⊆ (E

XT)), (8)

Cs (resp, Dt) is the set of condition (resp, event) out-

put arcs, (9) Cs ⊆ (PXE

out

) (resp, Dt ⊆ (TXE

out

)),

(10) m

: P → 0,1 is the initial marking.

The semantics of NCES are deﬁned by the ﬁring

rules of transitions. There are several conditions to be

fulﬁlled to enable a transition to ﬁre. First, as it is in

ordinary Petri nets, an enabled transition has to have a

token concession. That means that all pre-places have

to be marked with at least one token . In addition to the

ﬂow arcs from places, a transition in NCES may have

incoming condition arcs from places and event arcs

from other transitions. A transition is enabled by con-

dition signals if all source places of the condition sig-

nals are marked by at least one token. The other type

of inﬂuence on the ﬁring can be described by event

signals which come to the transition from some other

transitions. Transitionshaving no incoming eventarcs

are called spontaneous,otherwiseforced. A forced

transition is enabled if it has token concession and it

is enabled by condition and event signals (Rausch and

Hanisch, 1995).

We note ﬁn ally that the model-checker SESA is a

useful tool to verify functional and temporal proper-

ties on NCES (Rausch and Hanisch, 1995). We apply

it in our work to verify reconﬁgurablecontrol systems

following the standard IEC 61499.

3 INDUSTRIAL CASE STUDY

In this paper, we are interested in the manufactur-

ing system EnAS used as a demonstrator at the Mar-

tin Luther University of Halle (in Germany). This

system is implemented while f ollowing the standard

IEC61499 and it allows the transportation of pieces

from the production into storing units. The pieces

shall be placed inside tins to close with caps after-

wards

. Two different production strategies can be

applied : we place in each tin one or two pieces ac-

cording to production rates of pieces, tins and caps.

In this paper, we denote respectively by nb

pieces

tins+caps

the production number of pieces, tins (as

well as caps) per hour. In the following, we denote

by Threshold a variable ( deﬁned in speciﬁcations) al-

lowing to choose the adequate production strategy.

The EnAS system is mainly composed of a belt,

two Jack stations (J

and J

) and two Gripper stations

and G

) (Figure 1). The Jack stations place new

produced pieces and to close tins with caps, whereas

the Gripper stations remove charged tins from the belt

into the storing units.

Initially, the be lt m oves a particular pallet contain-

ing a tin and a cap into the ﬁrst Jack station J

.Ac-

cording to the production parameters, we distinguish

two cases,

For d etailed information on the EnAS system, we re-

fer the reader to our group website: http://at.informatik.uni-

halle.de

ICINCO 2008 - International Conference on Informatics in Control, Automation and Robotics

158

Figure 1: Distribution of the EnAS stations.

• The First Production Policy

(nb

pieces

/nb

tins+caps

≤ Threshold): the Jack

station J

places from the production station a

new piece and closes the tin with the cap. In this

case, the Gripper station G

removes the tin from

the belt into the storing station St

• The Second Production Policy

(nb

pieces

/nb

tins+caps

> Threshold): the Jack

station J

places just a piece in the tin which is

moved thereafter into the second Jack station to

place a second new piece. Once J

closes the

tin with a cap, the belt moves the pallet into the

Gripper station G

to remove the tin (with two

pieces) into the second storing station St

.Ifwe

follow this policy, the productivity as well as the

factory receipt is improved.

4 NEW RECONFIGURATION

SEMANTIC

We deﬁne in this paper the reconﬁguration semantic

as follows.

Deﬁnition. A dynamic reconﬁguration is any

change according to well-deﬁned conditions in the

software as well as in the hardware components to

lead the system into a better safe state at run-time.

According to the standard IEC61499, we mean in this

deﬁnition by a change in the software components

any operation allowing to add, to remove or to update

Function Blocks to improve the behavior of all the

system. On the other hand, we mean by a change in

the hardware components any operation allowing to

add, remove or update devices used in the execution

environment.

Running Example. In the EnAS system, we

apply the reconﬁguration for two reasons: (i) to

save the system when hardware p roblems occur at

run-time. For example, when the Gripper G2 is

broken, then we have only to follow the ﬁrst pro-

duction policy by placing only one piece in each

tin. (ii) to improve the production gain when

(nb

pieces

/nb

tins+caps

> Threshold). In this case, we

have to apply the second policy to improve the factory

receipt. Therefore, we have to apply changes in the

systemarchitecture and blocks to followthispolicy. In

this example, the reconﬁguration is not only applied

to resolve hardware problems as proposed in (Al-Saﬁ

and Vyatkin, 2007)but alsoto improve the system per-

formance by increasingthe production gain. This new

semantic of the reconﬁguration concept will be a fu-

ture issue in the manufacturing industry.

5 RECONFIGURATION CASES

We classify in this section all reconﬁguration forms to

possibly apply on a control system in order to cover

all possible reasons described above. We distinguish

the following forms:

• First Form. It deals with the change of the

application architecture that we consider as a

composition of Function Blocks. In this case,

we have possibly to add, to remove or also to

change the localization of Function Blocks (from

one to another device). This reconﬁguration form

requires to load new (or to unload old, resp)

blocks in (from, resp) the memory.

Running Example. We distinguish in EnAS two

architectures: (i) We implement the system with

the ﬁrst architecture when we follow the ﬁrst

production policy. In this case, we load in the

memory the Function Blocks J1

CTL, Belt CTL

and G1

CTL. (ii) We implement the system

with the second architecture when we follow

the second production policy. In this case, we

load in the memory the Function Blocks J1

CTL,

CTL, Belt CTL and G2 CTL. If we follow

the ﬁrst production policy and nb

pieces

/nb

tins+caps

becomes higher than Threshold, then we have to

load the function block G2

CTL in the memory to

follow the second production policy.

• Second Form. it deals with the reconﬁguration of

the application without changing its architecture

(e.g. without loading or unloading Function

Blocks). In this case, we apply changes on the

internal structure o f blocks or on their composi-

tion as follows: (a) we change the ECC structure,

(b) we add, update or remove data/events in-

puts/outputs, (c) we update algorithms, (d) we

RECONFIGURATION OF EMBEDDED SYSTEMS

159

change the conﬁguration of connections between

blocks.

Running Example. In the EnAS system, if we

follow the second policy and the Jack station J2

is broken, then we have to change the internal

behavior (e.g. the ECC structure) of the block

CTL to close the tin with a cap once it places

only one piece. The tin will be moved directly

thereafter to the Gripper G2 .Inthisexample,we

do not change the application architecture (e.g.

loading or unloading blocks) but we just change

the b ehavior of particular blocks.

• Third Form. it simply deals with the recon-

ﬁguration of the application data (e.g. internal

data of blocks or global data of the system). The

reconﬁguration in this case is easy to apply.

Running Example. In theEnAS system, if a hard-

ware problem occurs at run-time, we propose to

change the value of Threshold to a great number

max

value. In this case we will not be interested

in the performance improvement but in the rescue

of the system to guarantee a minimal level of pro-

ductivity.

Finally, this classiﬁcation covers all possible recon-

ﬁguration forms to dynamically bring a manufactur-

ing system into a safe and better state while satisfying

the user requirements and the environment changes.

6 AUTOMATIC

RECONFIGURATION OF

MANUFACTURING SYSTEMS

To apply an automatic reconﬁguration, we deﬁne in

this section an agent-based architecture of a control

system where the Agent checks the environment evo-

lution and takes also into account the user require-

ments to apply reconﬁguration scenarios on the sys-

tem. To control the design complexity, we specify

this agent with nested NCES supporting the different

reconﬁguration forms presented above. We specify

also the possible behaviors of the system with NCES

in order to verify with SESA functional and temporal

properties described in user requirements.

6.1 Architecture of the Reconﬁguration

Agent

According to the reconﬁguration forms proposed

above, we deﬁne the agent behavior with the follow-

ing units belonging to three levels:

• First Level: (Architecture Unit) this unit checks

the system behavior and changes its architecture

(add/remove Function Blocks) if particular con-

ditions are satisﬁed. We note that Standardized

Manager Function Blocks are used in this unit to

load or unload such blocks in the memory.

• Second Level: (Control Unit), for a particular

loaded architecture, this unit checks the sys-

tem behavior and : (i) reconﬁgu res the blocks

composition (e.g. changes the conﬁguration

of connections), (ii) adds/removes data/events

inputs/outputs, (iii) reconﬁgures the internal

behavior of blocks (e.g. modiﬁcation of the ECC

structure or the update of algorithms),

• Third Level:(Data Unit), this unit updatesdata if

particular conditions are satisﬁed.

To control its complexity, we design the agent with

nested state machines. In this case, the Architecture

unit is speciﬁed by a n Architecture State Machine

(denoted by ASM) where each state corresponds to a

particular architecture of the application. Therefore,

each transition of the ASM corresponds to the load

(resp, or unload) of Function Blocks in (resp, or from)

the memory. We construct for each state S of the

ASM a particular Control State Machine (denoted by

CSM) in the Control unit. This state machine spec-

iﬁes all the reconﬁguration forms to possibly apply

when the system architecture corresponding to the

state S is loaded (e.g. modiﬁcation of the blocks com-

position or of th eir internal behavior). Each transition

of any ASM has to be ﬁred if particular conditions

are satisﬁed. Finally, the Data unit is speciﬁed also

by Data State Machines (denoted by DSMs) where

each one corresponds to a state of a CSM or the ASM.

Running Example. In the EnAS system, we de-

sign the agent with nested state machines as depicted

in Figure 2. The ﬁrst level is speciﬁed with the ASM

where each state deﬁnes a particular architecture of

the system ( e.g. a particular FB composition to load

in the memory). The state S

(resp, S

) correspondsto

the second (resp, ﬁrst) policy where the stations J

and G

(resp, only J

and G

) are loaded in the mem-

ory. We associate for each one of these states a CSM

in the Control unit. Finally, the data unit is speciﬁed

with a DSM deﬁning the values that Threshold takes

under well deﬁned conditions. Note that if we follow

the second production policy (state S

) and the grip-

per G

is broken, then we have to change the policy

and also the system architecture by loading the block

ICINCO 2008 - International Conference on Informatics in Control, Automation and Robotics

160

G1 CTL to remove pieces into Belt1. On the other

hand, we associate in the second level for the state S

the CSM CSM

deﬁning the different reconﬁguration

forms to apply when the ﬁrst architecture is loaded in

the memory. In particular, when the state S

is active

and the Jack station J

is broken, then we activate the

state S

in which the Jac k station J

is alone run-

ning to place only one piece in the tin. In this case,

the internal behavior of the block Belt

CTL has to be

changed (e.g. the tin has to be transported directly to

the station J

). Finally, we specify in the data unit a

DSM where we change the value of Threshold if the

Gripper G

is broken (we suppose as an example that

we are not interested in the system performance when

the Gripper G

is broken).

Figure 2: Behavior of the reconﬁguration agent.

6.2 System Behaviors

The different reconﬁguration scenarios applied by the

agent deﬁne all the possible conﬁgurable behaviors

to follow by the system blocks when conditions are

satisﬁed. We specify in this paper these behaviors

with a unique System State Machine (denoted by

SSM) where each state corresponds to a particular

behavior of a block when a corresponding input event

occurs.

Running Example. In the EnAS system, we spec-

ify in Figure 3 the different system behaviors that

we can follow to resolve hardware problems or to

improve the system performance. In this example,

we distinguish 4 traces encoding 4 different behav-

iors. The trace trace1 implements the system behavior

when the Jack station J

is broken. The trace trace2

implements the system behavior to apply the second

production policy. The trace trace3 implemen ts the

system behavior when the Jack station J

is broken.

Finally the last scenario implements the system be-

havior when the Gripper G

is broken or when we

have to apply the ﬁrst production policy. Note ﬁnally

that each state corresponds to a particular behavior

of a system block when the corresponding input event

occurs.

Figure 3: The system state machine: SSM.

6.3 Speciﬁcation with Net

Condition/event Systems

To specify the synchronisation between the agent

and the system models, we apply the formalism

NCES which provides useful facilities allowing such

speciﬁcation. We use in particular event/condition

signals from the agent to ﬁx the behavioral trace to

follow in the SSM (e.g. a reconﬁguration)and we use

event signals to synchronize the agent state machines:

ASM, CSM and DSM. Once the system is speciﬁed,

we apply the SESA model-checker available at our

laboratory to verify functional (like the attainability

of states or the deadlock) and temporal properties.

Running Example. We show in the Figure 4 the

agent and system models according to the NCES for-

malism. When the Jack station J

is broken, the agent

activates the place P

and sends a condition signal

to activate the trace trace1 in the system. Note that

the a rchitecture and control state machines are com-

municating by event signals to synchronize the agent

behavior. Finally, the state ”Well ” represents a dead-

lock in the system when the Jack stations J

and J

are

broken.

7 CONCLUSIONS AND FUTURE

WORKS

We propose in this paper a new reconﬁguration se-

mantic of embedded systems and a classiﬁcation of

all reconﬁgurationforms before we propose an agent-

based architecture to take into account all r easons as

RECONFIGURATION OF EMBEDDED SYSTEMS

161

Figure 4: Design of the reconﬁgurable system with the NCES formalism.

well as reconﬁguration forms. The agent applies au-

tomatic reconﬁgurations under ﬁxed conditions, it is

speciﬁed with nested NCES to reduce the design com-

plexity and it is checked by the model checker SESA

to verify functional and temporal properties. In our

future works, we plan to propose an approach ana-

lyzing the schedulability of a system in the diff erent

reconﬁguration scenarios in order to meet real-time

constraints.

REFERENCES

Al-Saﬁ, Y. and Vyatkin, V. (2007). An ontology-based

reconﬁguration agent for intelligent mechatronic sys-

tems. In Third International Conference on Industrial

Applications of Holonic and Multi-Agent Systems.

Angelov, C., Sierszecki, K., and Marian, N. (2005). De-

sign models for reusable and reconﬁgurable state ma-

chines. In L.T. Yang and All (Eds): EUC 2005, LNCS

3824, pp:152-163. International Federation for Infor-

mation Processing.

Khalgui, M. and Thramboulidis, K. (2008). An iec61499-

based development approach with focus on the de-

ployment of industrial control applications. In Ac-

cepted in International J ournal of Modelling, Identiﬁ-

cation and Control.

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

systems with multiple condition outputs. In Sympo-

sium on Emerging Technolo gies and Factory Automa-

tion. Vol.1, pp.592-600.

Rooker, M. N., Sunder, C., Strasser, T., Zoitl, A., Hum-

mer, O., and Ebenhofer, G. (2007). Zero downtime re-

conﬁguration of distributed automation systems : The

εcedac approach. In Third International Conference

on Industrial Applications of Holonic and Multi-Agent

Systems.

ICINCO 2008 - International Conference on Informatics in Control, Automation and Robotics

162