Resilient Supervision System over WSAN

A Distributed Multi-Agent Architecture

abio Janu

ario

1,3

, Am

ancio Santos

2,3

, Catarina Lucena

, Lu

ıs Palma

Alberto Cardoso

and Paulo Gil

1,3

Departmento de Engenharia Electrot

ecnica, Faculdade de Ci

encias e Tecnologia,

Universidade Nova de Lisboa, Lisboa, Portugal

Instituto Superior de Engenharia de Coimbra (ISEC), Coimbra, Portugal

Centre for Informatics and Systems (CISUC), University of Coimbra, Coimbra, Portugal

Keywords:

Wireless Sensor and Actuator Networks, Supervision Systems, Outliers Detection, Resilient Systems,

Multi-Agent Systems, Distributed Computing.

Abstract:

Wireless Sensor and Actuator Networks enable ﬂexibility, low operational and maintenance costs, as well as

scalability in a variety of scenarios. However, in the context of remote control and monitoring applications the

use of Wireless Sensor and Actuator Networks can impact the system’s performance due to several factors,

such as outliers in sampled raw data, communication breakdown or owing to security issues. In order to

improve the overall system’s resilience, this paper proposes a distributed hierarchical multi-agent architecture

where each agent is responsible for a speciﬁc task. Experimental results collected from a laboratory test-bed

show the relevance of incorporating the proposed methodology in the context of monitoring and networked

control systems over Wireless Sensor and Actuator Networks.

1 INTRODUCTION

Wireless Sensor and Actuator Networks (WSANs)

have attracted considerable attention in the last few

years. They are distributed networks of sensors and

actuators nodes, which act together in order to moni-

tor and/or control a diversity of physical environments

or systems (Mendes et al., 2009). Each node is a small

electronic device with wireless communication capa-

bilities, including data storage and processing power.

In addition, they can still be programmed to interact

with the physical environment by means of built in

sensors and actuators (Opina et al., 2009).

In industrial environments WSANs can be used in

supervision applications, which contribute to reduc-

ing installation and operation costs (Cerrada et al.,

2007). However, constraints on resources, in par-

ticular limited processing power, small data storage,

narrow bandwidth and autonomy may lead to inaccu-

rate data being sent to the sink (Tirkawi and Fischer,

2009). Moreover, these systems suffer from two main

types of vulnerabilities. The ﬁrst one refers to the

problem of monitoring the system for faults and fail-

ures, and responding in such a way to prevent and/or

mitigate the problem. A second issue involves the

vulnerability to cyber-intrusion, in which malignant

actors can mask the system’s degradation or provide

“fake” data to higher management levels, concern-

ing the current system’s status (Rieger et al., 2012).

This kind of vulnerabilities can, to some extent be

mitigated by implementing dedicated “coadjutants”,

which contribute to make the overall system more ro-

bust and resilient.

In this work a resilient system is regarded as a con-

trol system that maintains state awareness and an ac-

ceptable level of operational normalcy in response to

disturbances, including threats of an unexpected and

malicious nature (Garcia et al., 2012). In the case of

nodes’ deployment in harsh environments, they may

exhibit malfunction behaviours, which ultimately re-

sult in corrupted raw data that are subsequently sent to

the sink (Zang et al., 2010). These errors in the read-

ings are, as a whole denoted as outliers, and should

be cancelled out or accommodated for the sake of the

supervision systems’ performance.

The implementation of resilient enforcement

mechanisms can be carried out through the implemen-

tation of dedicated algorithms and heuristics, within

an framework based on agents (Cardoso et al., 2012;

Rieger and Villez, 2012). The incorporation of these

119

Januário F., Santos A., Lucena C., Palma L., Cardoso A. and Gil P..

Resilient Supervision System over WSAN - A Distributed Multi-Agent Architecture.

DOI: 10.5220/0004725501190126

In Proceedings of the 3rd International Conference on Sensor Networks (SENSORNETS-2014), pages 119-126

ISBN: 978-989-758-001-7

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

“coadjutants” in the context of faults and failure diag-

nosis, or to make the system less vulnerable, is very

attractive as it makes possible to implement a coop-

erative and decentralized agent-based framework for

such purposes, by making use of agents’ inherent fea-

tures, namely autonomy, reactivity, pro-activity, co-

operation and intelligence.

Several agent-based methodologies and architec-

tures have been proposed to support the design of re-

silient control systems (see e.g. (Rieger and Villez,

2012)). Generally, these methodologies are based on

a combination of intelligent techniques, such as fuzzy

systems, encryption algorithms, Bayesian networks

or neural networks, just to name a few. Given the

limited memory and computation power constraints

of nodes, however, these schemes can hardly be im-

plemented on WSAN based applications.

In the context of WSANs environments, the preva-

lent line of research has been focussed on the use

of mobile agents to tackle particular problems, such

as routing, clustering and localization (Chen et al.,

2007). Jamont and Occelo (Jamont and Occello,

2007) propose an original method for designing em-

bedded multi-agent system, while in Xiong and Bai

(Xiong and Bai, 2010) several generalized frame-

works are proposed to address some critical issues

in Wireless Sensor Networks (WSNs) applications,

namely interoperability, time synchronization, power

management and distributed computation. Worth to

mention is the work of Freitas et al. (Freitas et al.,

2009), which focusses on an agent-based framework,

acting as an integral part of a middleware, to support

autonomous setup and adaptation of sensor networks.

Although these architectures may solve a num-

ber of known problems associated with WSANs, they

do not allow the network to adapt to physical envi-

ronment changes. Regarding monitoring and control

applications, apart from addressing security and dis-

tributed computation issues, it is also crucial to ensure

the integrity of the collected data, and to guarantee the

system is operating safely in case of network commu-

nication faults.

With these premises in mind, the present work

proposes a new resilient enforcement architecture.

It is based on a hierarchical multi-agents paradigm,

where each agent is tailored for executing speciﬁc and

coordinated tasks, namely to outliers detection and

accommodation, as well as to maintain the system in

a safe state operation, in case of communication link

breakdown, and to account for security issues under

the form of manipulation of nodes’ conﬁguration by

a malicious actor. The effectiveness of the proposed

framework and its impact on the supervision system

performance is empirically assessed through experi-

ments conducted on a test-bed.

2 MULTI-AGENT SUPERVISION

SYSTEM

Agents can be regarded as computing entities in a

given environment, presenting a certain degree of au-

tonomy, and possessing the ability to feel and act in

order to accomplish a given mission. Some of their

inherent features include the following (Paolucci and

Sacile, 2005):

• Autonomy. agents are independent entities, able

to accomplish a given task, without any program-

ming or direct intervention;

• Reactivity. capability of perceiving their envi-

ronment and respond quickly and effectively to

changes;

• Pro-activity. ability to take initiative goals and

behave in order to meet them;

• Cooperation. agents have the ability to interact

and communicate with one another for the sake of

their own teleonomy;

• Intelligence. in order to evaluate and take over a

task, in an autonomous way, an agent should in-

corporate intelligent techniques;

• Mobility. agents have the ability to move its code

from a node to another one in a system, offering

mobility properties in distributed computational

devices.

Taking into account these features, it is possible to

devise a cooperative and decentralized multi-agent

framework with a number of advantages for WSANs

applications, namely, for systems’ monitoring and

control, while keeping the system running in a safe

mode, in case of communication loss between the

server and nodes, or in the presence of cyber attacks.

2.1 Architecture Overview

The proposed architecture concerns the implementa-

tion of a resilient supervision system over WSANs,

for which the issues of communication, network

topology and routing protocols have already been

tackled.

The supervision system is composed of three main

components (Fig. 1): a multiple inputs and multi-

ple outputs (MIMO) system being monitored or con-

trolled, a computer (server) running the middleware,

the dispatcher software, which feeds data from the

SENSORNETS2014-InternationalConferenceonSensorNetworks

120

WSAN into the middleware and other top-level appli-

cations, such as the monitoring application and the re-

mote controller, along with the communication infras-

tructure, based on a WSAN. Each node is a process-

ing device that collects information from the environ-

ment through attached sensors or transmitters, sends

sensor reading and reports to the sink, and delivers re-

ceived control actions or actuation signals, stemming

from the remote controller through the WSAN, to the

plant.

Server

WSAN

DispatcherMiddleware

Monitoring Configuration Control

Sink

TCP/IP

Plant (MIMO)

Input

Output

Figure 1: System Architecture.

2.2 Local Multi-Agent System

The architecture is based on the multi-agent

paradigm, where each agent is responsible for a spe-

ciﬁc task. As shown in Fig. 2, each local node in-

cludes a set of agents for monitoring, safety control,

as well as for management and supervision purposes.

The following sections describe each local agents’

main features.

2.2.1 Master Agent

The main goal for this agent is to carry out exten-

sive management routines related to other subordinate

local agents, and to coordinate the communications

between the node and the sink. When this agent is

activated, it automatically launches dependent lower-

level agents (actuator node or sensor node agents, see

Fig. 2). This agent is also responsible for monitoring

the status of all local dependent agents and, in case

of an agent crash, the master will relaunch the corre-

sponding “thread”.

Master

Agent

#2 #3

Monitoring

Agent

Emergent

Control

Agent

Security

Agent

Control

Agent

Sensor Node

Actuator Node

Figure 2: Local Multi-Agent System Architecture.

2.2.2 Monitoring Agent

This agent is responsible for collecting data from the

environment and for accommodating possible outliers

in raw data. The detection and accommodation of out-

liers is based on the approach proposed in (Cardoso

et al., 2012).

2.2.3 Security Agent

This agent is responsible for periodically check all

important variables in the system, as well as messages

structure. If any anomaly is detected, an alarm is trig-

gered and sent by the master agent to the user inter-

face. In addition, the system is switched to safe mode

operation.

2.2.4 Control Agent

The purpose of this agent is to send to the digital-to-

analog converter (DAC) control actions received from

the sink. This agent is also responsible for testing the

periodicity of control actions, through which a com-

munication breakdown is detected.

2.2.5 Safety Agent

The function of this agent is to maintain the system in

a safe operation mode, in case of communication link

breakdown, and controller’s malfunction or user er-

rors. This goal is achieved by deﬁning a threshold for

normal operation in terms of system’s outputs. When

the safety agent detects that collected data are outside

the pre-speciﬁed bounds or no control actions have

been received from the sink in the corresponding sam-

pling interval, the system is switch to safe mode op-

eration, and a local control action computed based on

an on-off heuristic, while considering the most recent

reference signal received from the middleware.

ResilientSupervisionSystemoverWSAN-ADistributedMulti-AgentArchitecture

121

2.3 Multi-Agent Framework

The multi-agent framework relies on a collaborative

and sharing proﬁle/approach, which is a necessary

condition to any distributed system. Each node incor-

porates a set of agents (see Fig. 2), including a mas-

ter agent responsible for communicating with the user

interface and with local agents, or even with other

WSAN nodes.

Each message comprises a header and a payload.

The header is composed of the sender and destination

addresses in the WSAN, message sequence number,

hops, and a control identiﬁer. The message payload

(see Table 1) contains the Message Type: the mes-

sage can stem from the system’s application or from

a local agent; Node ID: denoting the node address;

Control ID: the command ﬂag for local agents; Data

ID: data collected in the node ID; Agent ID: agent’s

identiﬁer that will be launched, stopped or resumed;

Agent MSG: data provided by an agent.

Table 1: Messages Payload.

Type

Node

Control

Data

Agent

MSG

2.3.1 Master Agent Framework

Table 2 shows the messages’ parameters received by

the master agent and sent by sink. When launching a

master agent, it is required the sampling time T

and

the sigma factor for outliers detection in monitoring

agents (σ f ). In order to start an actuator agent, it

is necessary to send the sampling time T

, the max-

imum level ϒ

and minimum level ϒ

to be used by

the safety agent. These values, excluding the sample

time, can be changed later on by sending new “Upload

Limits” and “Upload Sigma Factor”, through dedi-

cated messages.

The security agent parameters are deﬁned inter-

nally in the master agent during the programming

node, and are not accessible by the user, for the sake

of the system’s security.

Table 2: Messages received by the Master Agent.

Sensor

Start Agent T

σ f

Upload Sigma Factor σ f -

Actuator

Start Agent T

Upload Limits ϒ

Control Action k u(k) r(k)

In order to implement the control action on the

plant, the sink sends a message to each actuator nodes,

comprising the input voltage, along with the current

reference for each of the tanks under control, namely

and T

. These references will be used by the safety

control agent in case of communication breakdown.

When the master agent receives a “Start Agent”

#ID message, the corresponding local agent is

launched, which sends periodically messages to the

master agent reporting its operation state. If the mas-

ter agent does not receive periodically reports from a

running agent this agent is assumed to be “off” and

launched once again.

The messages sent by the master agent to the user

application interface via the sink node are presented

in Table 3. They include the security state ψ(k) of the

node and the accommodated reading y(k) in the case

of a sensor node, or the safe control action u

(k) in

case of an actuator node.

Table 3: Messages sent by the Master Agent.

Sensor

Send State k y(k) ψ(k)

Actuator

Send State k u

(k) ψ(k)

2.3.2 Monitoring Agent Framework

Monitoring agents collect the level of each tank

through the analog-to-digital converter (ADC) port to

which the level sensor is connected, and based on an

outlier detection and accommodation algorithm, pro-

posed in (Cardoso et al., 2012) each sample is accord-

ingly tested (see Algorithm 1). If a sample is tested

positive, it is replaced by the mean value of the over-

sampled time series, excluding those samples that are

outside the threshold limits (σ f providing a way to

control threshold size).

2.3.3 Security Agent Framework

The security agent is responsible for checking the val-

ues of T

, σ f , ϒ

, ϒ

, y(k), u(k) and u

(k). This agent

has internally deﬁned maximum and minimum val-

ues that these variables can take. Whenever they are

outside the admissible threshold an alarm message is

triggered and sent to the user interface. In addition,

the variable is adjusted to be within the pre-deﬁned

limits. The structure of the messages sent and re-

ceived by the node and between agents is quite strin-

gent. If the security agent detects a different structure

a message error is triggered and sent to the user inter-

face, while the current message will be ignored (see

Table 4).

SENSORNETS2014-InternationalConferenceonSensorNetworks

122

Algorithm 1: Monitoring Agent.

Input: f s − Sampling Frequency

f os − Oversampling Frequency

σ f − Sigma Factor

1 T s ← 1 / f s; // sampling period

2 Tos ← 1 / f os; // oversampling period

3 while true do

4 ti ← GetTime; // initial time

5 i ← 0; // initial iteration

6 repeat // oversampling until next sample time

7 i ← i + 1; // iteration

8 z[i] ← GetSample; // oversample

9 Sleep(Tos) // node sleep for Tos seconds

until GetTime ≥ ti + Tos;

10 y ← GetSample; // sample

11 z[i + 1] ← Mean(z); // expected value

12 ∆u ← z[i + 1] + σ f × STD(z); // upper

threshold

13 ∆l ← z[i + 1] − σ f × STD(z); // lower

threshold

14 if y /∈ [∆l, ∆u] then SendToMaster(y);

// the sample is not an outlier

15 else SendToMaster(z[i + 1]); // outlier:

accommodated

end

Table 4: Security Agent Send Messages.

Variable Error code (ψ(k))

σ f 2

y(k) 5

u(k) 6

(k) 7

Message structure 8

2.3.4 Control Agent Framework

The control agent is started by the master agent, from

which receives as conﬁguration parameters the sam-

pling time and the initial control action. This agent

uses the sampling time to test the network for commu-

nication breakdown. If in a given sampling interval

the agent does not receive any control action the mas-

ter agent is “warned” and the safety agent will take

over the control of the system (see Algorithm 2).

Algorithm 2: Control Agent.

Input: T s − Timeout

u − Initial Control Action

1 SetADC (u) ; // dispatch to ADC the initial control

action

2 Time.timeout ← T s; // deﬁne timeout

3 Time.init ← 0; // deﬁne initial time

4 Time.start; // launch the Time counter

5 while true do

6 ev ← Event; // wait for new event

7 if ev = Timeout then // timeout event

8 Enabled Safety Agent;

end

9 if ev = NewControlAction then // control

action received event

10 u ← GetControlAction;

11 SetADC (u); // dispatch to ADC the control

action

12 Time.reset; // reset the counter

end

Sleep(T s)

end

2.3.5 Safety Agent Framework

This agent receives the level of the tank provided by

the corresponding sensor node and implements a re-

lay controller (on/off). Furthermore, if the liquid level

in the controlled tanks exceeds the prescribed bounds

this agent also takes over the control system (see Al-

gorithm 3).

3 CASE STUDY

3.1 Test-bed Description

The test-bed consists of a three-tank system (Fig. 3),

a remote desktop computer, where the user interface

and controller is running, six Crossbow TelosB nodes

(ﬁve for tanks and one sink). The main goal is to mon-

itor and control the liquid level in the tanks T

and T

while maintaining the system under safety operation

mode, in case of faults events.

The AMIRA



DTS 200 benchmark three-tank

system (Fig. 3) comprises three plexiglas cylindrical

tanks with identical cross-section supplied with dis-

tilled water. Liquid levels, namely h

, h

and h

are

measured by piezoresistive transducers. The middle

tank T

is connected to the other two tanks by means

of circular cross section pipes provided with manu-

ResilientSupervisionSystemoverWSAN-ADistributedMulti-AgentArchitecture

123

Algorithm 3: Safety Agent.

Input: ϒ

− Maximum Level

− Minimum Level

T s − Waiting time

f lag − Flag that indicates

communication breakdown

1 ∆

; // level threshold

2 ∆

; // control action increment

3 while true do

4 y ← GetLevel; // get level

u ← GetControlAction; // get last control

action

r ← GetRefrence; // get last reference

5 if y > ϒ

− ∆

then SetADC (u − ∆

);

// decrease pump

6 else if y < ϒ

+ ∆

then SetADC (u + ∆

);

// increase pump

7 else if f lag = 1 then // communication

breakdown

if y > r + ∆

then SetADC (u − ∆

);

// decrease pump

if y < r − ∆

then SetADC (u + ∆

);

// increase pump

end

8 else disable emergent control; // normal state

end

Figure 3: Three-tank system.

ally adjustable ball valves. In the tank T

it is located

the main outlet of the system, which is directly con-

nected to the collecting reservoir by means of a cir-

cular cross-section pipe provided with an outﬂow ball

valve. This system has two pumps to circulate water

from the bottom reservoir to tanks T

and T

In what the WSAN is concerned, it is built in with

Crossbow TelosB (TPR2400) sensor nodes, which are

ultra-low power wireless devices. These nodes lever-

age industry standards like USB and IEEE 802.15.4

to interoperate seamlessly with other devices. Each

TelosB node has available analogue and digital ports,

to which sensors and actuators are attached. The op-

erating system used in WSAN programming is based

on de Contiki OS. This operating system has been

written in C language with support for dynamic load-

ing and replacement of individual programs and ser-

vices. Additionally, it was built around an event-

driven kernel, but provides optional preemptive multi-

threading, which can be applied to individual pro-

cesses (Dunkels et al., 2004).

In the case of the present setup, three nodes are

conﬁgured as sensors, in order to collect tanks’ lev-

els (h

and h

), while two other nodes are used as

actuators, associated with pumps P

and P

. In ad-

dition a sixth node is used as a sink/gateway. This

node is attached via USB port to the remote desktop

computer, thus allowing its communication with the

WSAN nodes. As can be seen in Fig. 4 these nodes

are hierarchically arranged in a N-5 topology, but al-

lowing peer-to-peer communication between sensor

and actuator nodes associated with tank T

and T

Actator

Sensor

Actuator

Sink

Figure 4: Logical topology.

Finally, the remote controllers were implemented

based on a PID-Fuzzy controller (see (Janu

ario et al.,

2013)), being the control actions and readings deliv-

ered through the WSAN.

3.2 Experimental Results

This section is devoted to assess the proposed

methodology in dealing with vulnerabilities on the su-

pervision systems over WSANs, as mentioned in Sec-

tion 1.

3.2.1 Outliers Accommodation

The ﬁrst experiment was designed to assess the ben-

eﬁts of outliers accommodation for the supervision

system resilience. In this context, readings have been

taken from sensor nodes’ ADCs, at the frequency of

1 Hz, and using also a USB data acquisition board

in parallel, namely a NI6008, from National Instru-

ments, through which samples have been taken at

the same discrete times. A root mean square of er-

ror (RMSE) metric (1) was subsequently compute to

compare three different σ f against the raw data. Ta-

SENSORNETS2014-InternationalConferenceonSensorNetworks

124

ble 5 shows the corresponding results.

RMSE =

∑

k=1

(k) − y

(k)]

(k) − y

(k)]

∑

k=1

(k)

(1)

with y

the sensor reading sent through the WSAN

and y

the reading sampled via the USB data acquisi-

tion board.

As can be observed in Table 5, the RMSE mea-

sure drops with the decrease of the underlying sigma

factor, which is in line with what was expected as the

thresholds depends on the sigma factors.

Table 5: Performance metric for the tree-tank system.

σ f - null σ f − 2 σ f − 1.5 σ f − 1

Tank 1 0.0241 0.0237 0.0223 0.0182

Tank 2 0.0398 0.0396 0.0386 0.0379

Tank 3 0.0321 0.0310 0.0302 0.0297

3.2.2 Safety Agent Operation

Figure 5 and Figure 6 show the liquid levels in tanks

and T

when a safety control agent is in operation.

In this case it was conﬁgured to a minimum level of

0.15 % and a maximum level of 0.45 %. As can be ob-

served, the local safety agent does not allow the liquid

level outside the [0.15, 0.45] % even if the reference

signal for the control system is set outside. Inside the

admissible system’s outputs the safety agent is in idle

operation mode.

0 50 100 150 200 250 300 350 400

0.2

0.4

0.6

0.8

Time [s]

Water level [%]

Output WSN

Reference

0 50 100 150 200 250 300 350 400

0.5

1.5

Time [s]

Water flow [%]

Emergent Control Signal

Control Signal

Figure 5: MIMO system working out of limits Tank 1.

0 50 100 150 200 250 300 350 400

0.2

0.4

0.6

Time [s]

Water level [%]

Output WSN

Reference

0 50 100 150 200 250 300 350 400

0.5

1.5

Time [s]

Water flow [%]

Emergent Control Signal

Control Signal

Figure 6: MIMO system working out of limits Tank 2.

0 100 200 300 400 500 600

0.2

0.4

0.6

0.8

Time [s]

Water level [%]

Fail Zone

Output WSN

Reference

0 100 200 300 400 500 600

0.5

1.5

Time [s]

Water flow [%]

Emergent Control Signal

Control Signal

Figure 7: Communication faults: Tank 1.

In the event of a communication link breakdown,

from the sink to the actuator node, the safety agent is

able to deal transparently with this situation, by main-

taining the tank level in the vicinity of the last refer-

ence received. Figure 7 refers to the case of commu-

nication loss (fail zone) between 150 and 250 second

and from 350 to 450 second. As can be observed, the

safety agent maintains the tank level around the last

reference signal received from the sink node by means

of an on/off control approach, and without exceeding

the prescribed admissible level limits.

ResilientSupervisionSystemoverWSAN-ADistributedMulti-AgentArchitecture

125

4 CONCLUSIONS

This paper addressed the problem of supervision over

Wireless Sensor and Actuator Networks from the re-

silience point of view, namely, focusing on outliers

detection and accommodation, safety operation and

breakdown communication links. The proposed ap-

proach was based on a hierarchical multi-agent sys-

tem framework deployed in wireless nodes. Out-

liers are detected using statistical based techniques,

along with an oversampling technique prior to peri-

odic sensor reading, while the Wireless Sensor and

Actuator Networks security is achieved by periodi-

cally “scanning” the control variables and messages

structure. Breakdown communication faults and con-

troller malfunction have also been considered. Re-

sults from experiments on a test-bed comprising a

benchmark three-tank system and a WSAN built with

Crossbow TelosB nodes reveal the feasibility and rel-

evance of the proposed framework. Finally, it should

be mentioned that this work is still under progress.

Further developments will include security policies

against malicious attacks and other features, such as

self awareness in heterogeneous environments.

ACKNOWLEDGEMENTS

Janu

ario, F. acknowledge Fundac¸

ao para a Ci

encia

e Tecnologia (FCT), Portugal for the Ph.D. Grant

SFRH/BD/85586/2012. This work has been partially

supported by iCIS-Intelligent Computing in the Inter-

net of Services, Project CENTRO-07-ST24-FEDER-

002003.

REFERENCES

Cardoso, A., Santos, A., Nunes, G. B., and Gil, P. (2012).

A multi-agent approach for outlier accommodation in

wireless sensor and actuator networks. Controlo2012

- 10th Portuguese Conference on Automatic Control.

Cerrada, M., Cardilho, J., Aguilar, J., and Faneite, R.

(2007). Agents-based design for fault management

systems in industrial processes. In Computers in In-

dustry.

Chen, M., Gonzalez, S., and Leung, V. C. M. (2007). Appli-

cations and design issues for mobile agents in wireless

sensor networks. Wireless Communications, 14:20–

26.

Dunkels, A., Gr

onvall, B., and Voigt, T. (2004). Contiki

- a lightweight and ﬂexible operating system for tiny

networked sensors. In Proceedings of the First IEEE

Workshop on Embedded Networked Sensors, Tampa,

Florida, USA.

Freitas, E. P., Heimfarth, T., Ferreira, A. M., Wagner, F. R.,

Pereira, C. E., and Larsson, T. (2009). An agent

framework to support sensor networks setup and ad-

aptation. Computer Science and Information Technol-

ogy, pages 619–626.

Garcia, H. E., Lin, W., and Meerkov, S. M. (2012). A re-

silient condition assessment monitoring system. In

5th International Symposium on Resilient Control Sys-

tems (ISRCS).

Jamont, J. P. and Occello, M. (2007). Designing embedded

collective systems: The diamond multiagent method.

Proceedings of the 19th IEEE International Confer-

ence on Tools with Artiﬁcial Intelligence, 2:91–94.

Janu

ario, F., Santos, A., Lucena, C., Palma, L., Cardoso,

A., and Gil, P. (June 2013). Outliers accommodation

in fuzzy control systems over wsan. In 5th Interna-

tional Conference on Intelligent Decision Technolo-

gies (KES-IDT), Portugal.

Mendes, M. J. G. C., Santos, B. M. S., and Costa, J. S.

(2009). Multi-agent platform and toolbox for fault tol-

erant networked control systems. Journal of Comput-

ers, pages 303–310.

Opina, A. P., Canola, A. M., and Carranza, D. O. (2009).

Integration model of mobile intelligent agents within

wireless sensor networks. In IEEE Latin-American

Conference on Communications.

Paolucci, M. and Sacile, R. (2005). Agent-based Manufac-

turing and Control System: New Agile Manufactur-

ing Solutions for Achieving Peak Performance. CRC

Press.

Rieger, C., Zhu, Q., and Basar, T. (2012). Agent-based cy-

ber control strategy design for resilient control sys-

tems: Concepts, architecture and methodologies. In

5th International Symposium on Resilient Control Sys-

tems (ISRCS), pages 40–47.

Rieger, C. G. and Villez, K. (2012). Resilient control sys-

tem execution agent (recosea). In 5th International

Symposium on Resilient Control Systems (ISRCS).

Tirkawi, F. and Fischer, S. (2009). Generality challenges

and approaches in wsns. In I. J. Communications, Net-

works and System Sciences.

Xiong, F. Y. and Bai, L. (2010). Interoperable wireless sen-

sor network model using multi-agent-based middle-

ware. International Symposium on Intelligent Signal

Processing and Communication Systems,, pages 1–4.

Zang, Y., Meratnia, N., and Havinga, P. (2010). Outlier

detection techniques for wireless sensor networks: A

survey. IEEE Communnications Surveys & Tutorials,

pages 159–170.

SENSORNETS2014-InternationalConferenceonSensorNetworks

126