Design of Material-integrated Distributed Data Processing Platforms

with Mobile Multi-agent Systems in Heterogeneous Networks

Stefan Bosse

University of Bremen, Department of Mathematics and Computer Science, ISIS Sensorial Materials Scientiﬁc Centre,

Bremen, Germany

Keywords:

Multi-agent Platform, Sensor Network, Mobile Agent, Heterogeneous Networks, Embedded Systems.

Abstract:

An agent processing platform suitable for distributed computing in sensor networks consisting of low-resource

(e.g., material-integrated) nodes is presented, providing a unique distributed programming model and en-

hanced robustness of the entire heterogeneous environment in the presence of node, sensor, link, data pro-

cessing, and communication failures. In this work multi-agent systems with mobile activity-based agents are

used for sensor data processing in unreliable mesh-like networks of nodes, consisting of a single microchip

with limited low computational resources. The agent behaviour, interaction, and mobility (between nodes)

can be efﬁciently integrated on the microchip using a conﬁgurable pipelined multi-process architecture based

on Petri-Nets. Additionally, software implementations and simulation models with equal functional behaviour

can be derived from the same source model. Hardware and software platforms can be directly connected in

heterogeneous networks. Agent interaction and communication is provided by a simple tuple-space database

and signals providing remote inter-node level communication and interaction. A reconﬁguration mechanism

of the agent processing system offers activity graph changes at run-time.

1 INTRODUCTION

Trends are recently emerging in engineering and

micro-system applications such as the development of

sensorial materials (Lang, 2011) show a growing de-

mand for distributed autonomous sensor networks of

miniaturized low-power smart sensors embedded in

technical structures (Pantke, 2011). These sensor net-

works are used for sensorial perception or structural

health monitoring, employed, for example in Cyber-

Physical-Systems (CPS), and perform the monitoring

and control of complex physical processes using ap-

plications running on dedicated execution platforms

in a resource-constrained manner under real-time pro-

cessing and technical failure constraints.

To reduce the impact of such embedded senso-

rial systems on mechanical structure properties, sin-

gle microchip sensor nodes (in mm

range) are pre-

ferred. Real-time constraints require parallel data pro-

cessing inadequately provided by software based sys-

tems.

Multi-agent systems can be used for a decentral-

ized and self-organizing approach of data processing

in a distributed system like a sensor network (Gui-

jarro, 2008), enabling information extraction, for ex-

ample based on pattern recognition (Zhao, 2008), and

by decomposing complextasks in simpler cooperative

agents.

Hardware (microchip level) designs have advan-

tages compared with microcontroller approaches con-

cerning power consumption, performance, and chip

resources by exploiting parallel data processing (cov-

ered by the agent model) and enhanced resource shar-

ing (Bosse, 2011), which will be applied in this work.

Usually sensor networks are a part of and con-

nected to a larger heterogeneous computational net-

work (Guijarro, 2008). Employing of agents can over-

come interface barriers arising between platforms dif-

fering considerably in computational and communi-

cation capabilities. That’s why agent speciﬁcation

models and languages must be independent of the un-

derlying run-time platform. On the other hand, some

level of resource and processing control must be avail-

able to support the efﬁcient design of hardware plat-

forms.

Hardware implementations of multi-agent sys-

tems are still limited to single or a few and im-

mobile agents (Meng, 2005, Naji, 2004), and were

originally proposed for low level tasks, for example

in (Ebrahimi, 2011) using agents to negotiate net-

Bosse S..

Design of Material-integrated Distributed Data Processing Platforms with Mobile Multi-agent Systems in Heterogeneous Networks.

DOI: 10.5220/0004817500690080

In Proceedings of the 6th International Conference on Agents and Artiﬁcial Intelligence (ICAART-2014), pages 69-80

ISBN: 978-989-758-016-1

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

work resources. Coarse grained reconﬁguration is

enabled by using FPGA technologies (Meng, 2005).

Most current work uses hardware-software co-design

methodologies and code generators, like in (Jamont,

2008). This work provides more ﬁne-grained agent

reconﬁguration and true agent mobility without rely-

ing on a speciﬁc technology and employs high-level

synthesis to create standalone hardware and software

platforms delivering the same functional and reactive

behaviour.

There is related work concerning agent program-

ming languages and processing architectures, like

APRIL (McCabe, 1995) providing tuple-space like

agent communication, and widely used FIPA ACL,

and KQGML (Kone, 2000) focusing on high-level

knowledge representations and exchange by speech

acts, or model-driven engineering (e.g. INGENIAS,

Sansores, 2008). But the above required resource and

processing control is missing, which is addressed in

this work.

There are actually four major issues related to

the scaling of traditional software-based multi-agents

systems to the hardware level and their design:

• limited static processing, storage,and communica-

tion resources, real-time processing,

• unreliable communication,

• suitable simpliﬁed agent-oriented programming

models and processing architectures qualiﬁed

for hardware designs with ﬁnite state machines

(FSM) and resource sharing for parallel agent ex-

ecution,

• and appropriate high-level design tools.

Traditionally agent programs are interpreted, leading

to a signiﬁcant decrease in performance. In the ap-

proach presented here, the agent processing is directly

implemented in standalone hardware nodes without

intermediate processing levels and without the neces-

sity of an operating system.

This work introduces some novelties compared to

other data processing and agent platform approaches:

• One common agent behaviour model, which is

implementable on different processing platforms

(hardware, software, simulation).

• Agent mobility crossing different platforms in

mesh-like networks and agent interaction by us-

ing tuple-space databases and global signal prop-

agation aid solving data distribution and synchro-

nization issues in the design of distributed sensor

networks.

• Support for heterogeneous networks and plat-

forms covered by one design and synthesis ﬂow

including functional behavioural simulation.

• A token-based pipelined multi-process agent pro-

cessing architecture suitable for hardware plat-

forms with Register-Transfer Level Logic offering

optimized computational resources and speed.

• A Petri-Net representation is used to derive a

speciﬁcation of the hardware process and commu-

nication network, and performing advanced anal-

ysis like deadlock detection. Timed Petri-Nets can

be used to calculate computational time bounds to

support real-time processing.

The next sections introduce the activity based agent

processing model, available mobility and interaction,

and the proposed agent platform architecture related

to the programming model. Finally, a case study

shows the suitability of the proposed design approach.

2 STATE-BASED MOBILE

AGENTS

The implementation of mobile multi-agent systems

for resource constrained embedded systems with a

particular focus on microchip level is a complex

design challenge. High-level agent programming

and behaviour modelling languages can aid to solve

this design issue. To carry out multi-agent sys-

tems on hardware platforms, the activity-based agent-

orientated programming language AAPL was de-

signed. Though the imperative programming model

is quite simple and closer to a traditional PL it can

be used as a common source and intermediate repre-

sentation for different agent processing platform im-

plementations (hardware,software, simulation) by us-

ing a high-level synthesis approach, shown in Figure

1. Commonly used agent behaviour models based on

PRS/ BDI architectures with a declarative paradigm

(2APL, AgentSpeak/Jason), communication models

(e.g. FIPA ACL, KQML), and adaptive agent models

can be implemented with AAPL providing primitives

for the representation of beliefs or plans (discussed

later). Agent mobility, interaction, and replication in-

cluding inheritance are central multi-agent-orientated

behaviours provided by AAPL.

Deﬁnition: There is a multi-agent system (MAS) con-

sisting of a set of individual agents {A

,..}. There

is a set of different agent behaviours, called classes

C={AC

,AC

,..}. An agent belongs to one class.In

a speciﬁc situation an agent A

is bound to and pro-

cessed on a network node N

m,n

(e.g. microchip, com-

puter, virtual simulation node) at a unique spatial lo-

cation (m,n). There is a set of different nodes N={N

,..} arranged in a mesh-like network with peer-to-

peer neighbour connectivity (e.g. two-dimensional

ICAART2014-InternationalConferenceonAgentsandArtificialIntelligence

Figure 1: From AAPL level to heterogeneous distributed

networks (RTL: Register-Transfer Level, MT: Multi-

Threading, CSP: Communicating Sequential Processes.

grid). Each node is capable to process a number of

agents n

(AC

) belonging to one agent behaviour class

, and supporting at least a subset of C’⊆ C. An

agent (or at least its state) can migrate to a neighbour

node where it continues working.

2.1 AAPL Programming Model

The agent behaviour is partitioned and modelled with

an activity graph, with activities representing the con-

trol state of the agent reasoning engine, and con-

ditional transitions connecting and enabling activi-

ties,. Activities provide a procedural agent process-

ing by sequential execution of imperative data pro-

cessing and control statements. The activity-graph

based agent model is attractive due to the proxim-

ity to the ﬁnite-state machine model, which simpliﬁes

the hardware implementation.An activity is activated

by a transition depending on the evaluation of (pri-

vate) agent data (conditional transition) related to a

part of the agents belief in terms of BDI architectures,

or using unconditional transitions (providing sequen-

tial composition), shown in Figure 2. An agent be-

longs to a speciﬁc parameterizable agent class AC ,

specifying local agent data (only visible for the agent

itself), types, signals, activities, signal handlers, and

transitions.

Plans are related to AAPL activities and transitions

close to conditional triggering of plans. Deﬁnition

1 summarizes the available language statements.

Instantiation. New agents of a speciﬁc class can

be created at runtime by agents using the

new

Agent Class Deﬁnition

agent

class

(

arguments

deﬁnitions

end;

Activity Deﬁnition

activity

name =

statements

end;

Data Statements

var x,y,z:

type

; var* a,b,c:

type

;

x :=

(

variable

value

constant

);

Conditional Statements

cond

then

statements

else

statements

end;

case

| v1

> statements |

.. end;

Loop Statements

for i :=

range

statements

end;

while

cond

statements

end;

Transition Network Deﬁnition

transitions =

transitions

end;

> a2

cond

;

Tuple Database Statements

out(

,..); .. exist?(

,..)..

in(

?,..); rd(

?,..);

try in(

timeout

,..); try rd(

timeout

,..);

mark(

timeout

,..); rm(

,?,..);

Signals

signal

datatype

;

handler

(

) =

statements

end;

send(ID,

,v); reply(S,v);

broadcast(AC,DX,DY,S,v);

timer+(

timeout

);timer-(

); sleep; wakeup;

Exceptions

exception

; raise E;

try

statements

except

> statements

end;

Mobility, Creation, and Replication

moveto(

direction

);

.. link?(

direction

) ..

:= new

class

(

arguments

);

:= fork(

arguments

);

kill(

);

Transitional Reconﬁguration

transition+(

cond

);

transition*(

cond

);

transition-(

);

Deﬁnition 1: Summary of the AAPL Language (..x.. means

x is part of an expression ε, and ; terminates procedural

statements).

AC(v1,v2,..)

statement returning a node unique

agent identiﬁer. An agent can create multiple liv-

ing copies of itself with a fork mechanism, creat-

ing child agents of the same class with inherited data

and control state but with different parameter initial-

ization,done by using the

fork(v1,v2,..)

state-

ment.Agents can be destroyed by using the

kill(ID)

statement.

Each agent has private data (body vari-

ables),deﬁned by the

var

and

var*

state-

ments.Variables in the latter statement will not

be inherited or migrated! Agent body variables in

conjunction with transition conditions represent the

mobile data part of the agents beliefs database.

DesignofMaterial-integratedDistributedDataProcessingPlatformswithMobileMulti-agentSystemsinHeterogeneous

Networks

Figure 2: Agent behaviour programming level with activities and transitions (AAPL, left); agent class model and activity-

transition graphs (middle); agent instantiation, processing, and agent interaction on the network node level (right).

Statements inside an activity are processed se-

quentially and consist of data assignments (

x:=

ε) op-

erating on agent’s private data, control ﬂow state-

ments (conditional branches and loops), and special

agent control and interaction statements.

Agent interaction and synchronization is pro-

vided by a tuple-space database server available on

each node (based on McCabe, 1995). An agent

can store an n-dimensional data tuple (v1,v2,..) in

the database by using the

out(v1,v2,..)

state-

ment(commonly the ﬁrst value is treated as a key).

A data tuple can be removed or read from the

database by using the

in(v1,p2?,v3,..)

rd(v1,p2?,v3,..)

statements with a pattern tem-

plate based on a set of formal (variable,

) and ac-

tual (constant) parameters. These operations block

the agent processing until a matching tuple was

found/stored in the database. These simple operations

solve the mutual exclusion problem in concurrent sys-

tems easily. Only agents processed on the same net-

work node can exchange data in this way. Simpliﬁed

the expression of beliefs of agents is strongly based

on AAPL tuple database model. Tuple values have

their origin in environmental perception and process-

ing bound to a speciﬁc node location.

The existence of a tuple can be checked by using

the

exist?

function or with atomic test-and-read be-

haviour using the

try in/rd

functions. A tuple with

a limited lifetime (a marking) can be stored in the

database by using the

mark

statement. Tuples with

exhausted lifetime are removed automatically (by a

garbage collector). Tuples matching a speciﬁc pattern

can be removed with the

statement.

Remote interaction between agents is provided

by signals carrying optional parameters (they can be

used locally, too). A signal can be raised by an agent

using the

send(ID,S,V)

statement specifying the ID

of the target agent, the signal name S, and an optional

argument value V propagated with the signal. The re-

ceiving agent must provide a signal handler (like an

activity) to handle signals asynchronously. Alterna-

tively, a signal can be sent to a group of agents belong-

ing to the same class AC within a bounded region us-

ing the

broadcast(AC,DX,DY,S,V)

statement. Sig-

nals implement remote procedure calls. Within a sig-

nal handler a reply can be sent back to the initial

sender by using the

reply(S,V)

statement.

Timers can be installed for temporal agent control

using (private) signal handlers, too. Agent processing

can be suspended with the

sleep

and resumed with

the

wakeup

statements.

Migration of agents (preserving the local data and

processing state) to a neighbour node is performed

by using the

moveto(DIR)

statement, assuming the

arrangement of network nodes in a mesh- or cube-

like network. To test if a neighbour node is reachable

(testing connection liveliness), the

link?(DIR)

state-

ment returning a Boolean result can be used.

Reconﬁguration. Agents are capable to change

their transitional network (initially speciﬁed in

the transition section) by changing, deleting,

or adding (conditional) transitions using the

transition

⊲⊳

(S1,S2,cond)

statements (with

⊲⊳=’+’: add, ’-’: remove, and ’*’: change transition).

This behaviour allows the modiﬁcation of the activity

graph, i. e., based on learning or environmental

changes, which can be inherited by child agents.

2.2 Agent Communication

Agent communication can be achieved basically by

three different methods: 1. signal propagation (sim-

ilar to commitment messages in AGENT0, Shoham,

1991), 2. tuple database exchange, and 3. by us-

ing agents with a composition of methods 1 & 2.

These basic methods can be used to realize com-

mon higher-level agent communication languages

like ACL or KQML (tuple patterns correspond to

message content entries). Signal propagation im-

plements light-weighted asynchronous peer-to-peer

ICAART2014-InternationalConferenceonAgentsandArtificialIntelligence

remote-procedure calls, executed on target agents

with appropriate signal handlers, which must not nec-

essarily belong to the same agent class, whereas pat-

tern matching based tuple database access can be per-

formed by any group of agents having a common un-

derstanding of the meaning of data and which are ac-

tually processed on the same platform node.

For example, a simple FIPA ACL based request

from agent A (initiator) to B (participant), which ask

for a database tuple on B can be created with the

following AAPL code pattern using signals:

FIPA ACL: (request :sender IDA

:receiver IDB :content (p ?) :ontology TS2)

AAPL:

signal REQ1,REQ2,INFR,FAIL;

-- Agent A --

var pv,ps;

handler INFR(v) = pv:=v; ps:=true; wakeup ..

handler FAIL = ps:=false; wakeup ..

function request(AID,p) =

send(AID,REQ1,p); timer+(100,FAIL);

sleep;

if ps then return pv else raise FAILED ..

-- Agent B --

handler REQ1(arg) =

var v;

if exist?(p,?) then

in(p,?v); reply(INFR,v)

else reply(FAIL) ...

3 AGENT PLATFORM

SYNTHESIS

The AAPL model is a common source for the imple-

mentation of agent processing on hardware, software,

and simulation processing platforms. A database

driven high-level synthesis approach (Bosse, 2013)

is used to map the agent behaviour to these different

platforms. The agent processing architecture required

on each network node must implement different agent

classes and must be scalable to the microchip level to

enable material-integrated embedded system design,

which represents a central design issue, further fo-

cussing on parallel agent processing and optimized

resource sharing.

3.1 Hardware Platform

This microchip-levelprocessing platform implements

the agent behaviour with reconﬁgurable pipelined

communicating processes (PCSP) related to the Com-

municating SequentialProcess model (CSP) proposed

by Hoare (1985). The activities and transitions of the

AAPL programming model are merged in a ﬁrst inter-

mediate representation by using state-transition Petri

Nets (PN), shown in Figure 3. This PN representation

allows the following CSP derivation specifying the

process and communication network, and advanced

analysis like deadlock detection. Timed Petri-Nets

can be used to calculate computational time bounds

to support real-time processing.

Keeping the PN representation in mind,the set of

activities {A

} is mapped on a set of sequential pro-

cesses {P

} executed concurrently. Each subset of

transitions {T

i, j

} activating one common activity pro-

cess P

is mapped on a synchronous N:1 queue Q

providing inter-activity-process communication, and

the computational part for transitions embedded in

all contributing processes {P

}, shown in Fig. 3.

Changes (reconﬁguration) of the transition network at

run-time are supported by transition path selectors.

Each sequential process is mapped (by synthe-

sis) on a ﬁnite-state machine and a datapath using

a register-transfer architecture (RTL) with mutual ex-

clusive guarded access of shared objects, all imple-

mented in hardware.

Agents are represented by tokens (natural num-

bers equal to the agent identiﬁer, unique at node

level), which are transferred by the queues between

activity processes depending on the speciﬁed tran-

sition conditions. This multi-process model is di-

rectly mappable to register-transfer level RTL hard-

ware. Each process P

is mapped on a ﬁnite state

machine FSM

controlling process execution and a

in a region of a memory module assigned to each in-

dividual agent. There is only one incoming transition

queue for each process consuming tokens, perform-

ing processing, and ﬁnally passing tokens to outgoing

queues, which can depend on conditional expressions.

There are computational and IO/event-based activity

statements. The latter ones can block the agent pro-

cessing until an event occurs (for example, the avail-

ability of a data tuple in the database). Blocking state-

ments {s

j,i

} of an activity A

are assigned to sepa-

rate intermediate IO processes {P

i, j

} handling only

IO events or additional post computations, as shown

on the bottom of Fig. 3. Agents in different activ-

ity states can be processed concurrently. Thus, activ-

ity processes that are shared by several agents may

not block. To prevent blocking of IO processes, not-

ready processes pass the agent token back to the input

queue. An IO process either processes unprocessed

agent tokens or waits for the happening of events,

controlled by the agent manager.

This pipeline architecture offers advanced re-

source sharing and parallelized agent processing with

DesignofMaterial-integratedDistributedDataProcessingPlatformswithMobileMulti-agentSystemsinHeterogeneous

Networks

Figure 3: Pipelined Communicating Sequential Process Architecture derived from a Petri-Net speciﬁcation and relationship

to the activity graph. Signals ar handled asynchronously.

only one activity process chain implementation re-

quired for each agent class. The hardware resource

requirement (digital logic) is divided into a control

and a data part. The control part is proportional to

the number of supported different agent classes. The

data part depends on the maximal number of agents

executed by the platform and the storage requirement

for each agent.

3.2 Software Platform

There are two different architectures for the imple-

mentation of the agent processing on programmable

platforms: 1. by using the already introduced PCSP

architecture, or 2. by using a direct procedural com-

position of the activity graph and its transitions. In the

ﬁrst case, the activity processes are implemented with

light weighted processes (threads) and queues, pro-

viding token based agent processing. In the second

case, each agent is assigned to and processed by one

thread created at run-time. Activities are one-to-one

mapped on procedures called by a transition sched-

uler (as in the simulation platform case). Blocking

of agent processing is handled by the thread imple-

mentation itself. In any case further software modules

implement the agent manager, tuple space databases,

and networking. A software platform can be directly

connected to hardware nodes and vice versa.

3.3 Simulation Platform

In addition to real hardware and software imple-

mented agent processing platforms there is the capa-

bility of the simulation of the agent behaviour, mobil-

ity, and interaction on a functional level.The SeSAm

simulation framework (Kl¨ugel, 2009) offers a plat-

form for the modelling, simulation, and visualization

of mobile multi-agent systems employed in a two-

dimensional world. The behaviours of agents are

modelled with activity graphs (specifying the agent

reasoning machine) close to the AAPL model. Ac-

tivity transitions depend on the evaluation of condi-

tional expressions using agent variables. Agent vari-

ables can have a private or global (shared) scope.

Basically SeSAm agent interaction is performed by

modiﬁcation and access of shared variables and re-

sources (static agents). In addition to the agent rea-

soning speciﬁcation there are global visible feature

packages that deﬁne variables and function operat-

ing on these variables. Features can be added to each

agent class. Agents can change their position in the

two-dimensional world map enabling mobility, and

new agents can be created at run-time by other agents.

The SeSAm framework was chosen due to the activity-

based agent behaviour and the data model which can

be immediately synthesized from the common AAPL

source and can be imported by the simulator from a

text based ﬁle stored in XML format. This model ex-

change feature allows the tight coupling of the simu-

lator to the synthesis framework.

In principle, AAPL activity graphs can be directly

mapped on the SeSAm agent reasoning model. But

there are limitations which inhibit the direct map-

ping. First of all, AAPL activities (IO/event-based)

ICAART2014-InternationalConferenceonAgentsandArtificialIntelligence

Figure 4: Simulation Model used in the SeSAm MAS Simulator.

can block (suspend) the agent processing until an

event occurs. Blocking agent behaviour is not pro-

vided directly by SeSAm. Secondly, the transition

network can change during run-time. Finally, the

handling of concurrent asynchronous signals used in

AAPL for inter-agent communication cannot be estab-

lished with the generic activity processing in SeSAm

(the provided exception handling is only used for ex-

ceptional termination of agents).

For this reason, the agent activity transitions in-

cluding the dynamic transition network capability are

managed by a special transition scheduler, shown in

Figure 4. This transition scheduler handles signals

and timers, too, which are processed prioritized and

passed to the signal scheduler. Each agent activity

is activated by the transition scheduler. After a spe-

ciﬁc activity was processed, the transition scheduler

is activated and entered again. An AAPL activity

can be split in computational and IO/event-based sub-

activities in the presence of blocking statements (e.g.

and

tuple space interaction).

There is a special node agent implementing the tu-

ple database with lists (partitioned to different spaces

for each dimension), and managing agents and sig-

nals actually bound to this particular node. Concur-

rent manipulation of lists is non-atomic operations in

SeSAm, and hence requires mutual exclusion.

The AAPL mobility, interaction, conﬁguration,

and replication statements are implemented by feature

packages.

3.4 Synthesis

The database driven synthesis ﬂow (details in Bosse,

2013) consists of an AAPL front end, the core com-

piler, and several backends targeting different plat-

forms. The AAPL program is parsed and mapped on

an abstract syntax tree (AST). The ﬁrst compiler stage

analyzes, checks, and optimizes the agent speciﬁca-

tion AST. The second stage is split in three parts: an

activity to process mapper, a transition to queue map-

per, a transition (pipelined processing architecture)

network builder, and a message generator supporting

agent and signal migration. Different outputs can be

produced: a hardware description enabling SoC syn-

thesis using the ConPro high-level synthesis frame-

work (details in Bosse, 2011), a software description

and the SeSAm simulation model (XML). The ConPro

programming model reﬂects an extended CSP with

atomic guarded actions for the access of shared re-

sources. Each process is implemented with an FSM

and an RT datapath.

All implementation models (HW/SW/SIM) pro-

vide equal functional behaviour, and only differ in

their timing, resource requirements, and execution en-

vironments. Some more implementation and synthe-

sis details follow.

Agent Manager

The agent manager provides a node level interface

for agents, and it is responsible for the creation, con-

trol (including signals, events, and transition network

conﬁguration), and migration of agents with network

connectivity, implementing a main part of an operat-

ing system. The agent manager controls the tuple-

space database server and signals events required for

IO/event-based activity processes.

The agent manager uses agent tables and caches to

store information about created, migrated, and passed

through agents (req., for ex., for signal propagation).

DesignofMaterial-integratedDistributedDataProcessingPlatformswithMobileMulti-agentSystemsinHeterogeneous

Networks

Migration

Migration of agents requires the transfer of the agent

data and the control state of the agent together with a

unique global agent identiﬁer (extending the local ID

with the agent class and the relative displacement of

its root node)encapsulated in messages.

Transition Network

A switched transition network offers support for

agent activity graph reconﬁguration at run-time.

Though the possible reconﬁguration and the condi-

tional expressions must be known at compile time

(static resource constraints), a reconﬁguration can re-

lease the use of some activity processes and enhances

the utilization for parallel processing of other agents.

The transition network is implemented with selector

tables in case of the HW implementation, and with

dynamic transition lists in case of the SW and SIM

implementations.

Tuple-space Database

Each n-dimensional tuple-space TS

(storing n-ary tu-

ples) is implemented with ﬁxed size tables in case of

the hardware implementation, and with dynamic lists

in the case of the software and simulation model im-

plementations. The access of each tuple-space is han-

dled independently. Concurrent access of agents is

mutually exclusive. The HW implementation impli-

cates further type constraints, which must be known

at design time (e.g. limitation to integer values).

Signals

Signals must be processed asynchronously. There-

fore, agent signal handlers are implemented with a

separate activity process pipeline, one for each sig-

nal handler. For each pending agent signal, the agent

manager injects an agent token in the respective han-

dler process pipeline independent of the processing

state of the agent. Remote signals are processed by

the agent manager, which encapsulate signals in mes-

sages sent to the appropriate target node and agent.

4 CASE STUDY

A small example implementing a distributed feature

detection in an incompletely connected and unreliable

mesh-like sensor network using mobile agents should

demonstrate the suitability of the proposed agent pro-

cessing and design approach. The sensor network

consists of nodes with each node attached to a sen-

sor used, for example, in a structural health monitor-

ing system (e.g. strain-gauge sensors). The nodes can

be embedded in a mechanical structure, for example,

used in a robot arm. The goal of the MAS is to ﬁnd

extended correlated regions of increased sensor inten-

sity (compared to the neighbourhood) due to mechan-

ical distortion resulting from externally applied load

forces. A distributed directed diffusion behaviour and

self-organization (see Figure 5) is used, derived from

the image feature extraction approach (proposed by

Liu, 2001). A single sporadic sensor activity not cor-

related with the surrounding neighbourhood should

be distinguished from an extended correlated region,

which is the feature to be detected. There are three

different agent classes: an exploration, a deliver, and

a node agent. A node agent is immobile and is primar-

ily responsible for sensor measurement, observation,

and creating of exploration agents. The feature de-

tection is performed by the mobile exploration agent,

which supports two main different behaviours: dif-

fusion and reproduction. The diffusion behaviour is

used to move into a region, mainly limited by the

lifetime of the agent, and to detect the feature, here

the region with increased mechanical distortion (more

precisely the edge of such an area). The detection of

the feature enables the reproduction behaviour, which

induces the agent to stay at the current node, setting

a feature marking and sending out more exploration

agents in the neighbourhood. The local stimuli H(i, j)

for an exploration agent to stay at a speciﬁc node with

coordinate (i, j) is given by eq. 1.

H(i, j) =

∑

s=−R

∑

t=−R

{kS(i+ s, j + t) − S(i, j)k ≤ δ}

S : Sensor Signal Strength

R : Square Region around (i, j)

(1)

The calculation of H at the current location (i, j) of the

agent requires the sensor values within the square area

(the region of interest ROI) R around this location. If

a sensor value S(i+s, j+t) with i, j∈ {-R,..,R} is similar

to the value S at the current position (diff. is smaller

than the parameter δ), H is incremented by one.

If the H value is within a parameterized interval

∆ = [ε

, ε

], the exploration agent has detected the

feature and will stay at the current node to reproduce

new exploration agents sent to the neighbourhood. If

H is outside this interval,the agent will migrate to a

neighbour different node and restarts exploration (dif-

fusion).

The calculation of H is performed by a distributed

calculation of partial sum terms by sending out child

explorer agents to the neighbourhood, which itself

can send out more agents until the boundary of the

region R is reached. Each child agent returns to its

origin node and hands over the partial sum term to his

parent agent, shown in Figure 5. Because a node in

the region R can be visited by more than one child

agent, the ﬁrst agent reaching a node sets a marking

MARK

. If another agent ﬁnds this marking, it will im-

ICAART2014-InternationalConferenceonAgentsandArtificialIntelligence

Figure 5: Distributed feature extraction in an unreliable and incomplete network by using distributed agents with migration

and self-organization behaviour (right: AAPL activity graph of the explorer agent).

ROW

COLUMN

Expl. Agents

Figure 6: Simulation results for two different sensor network situations (left: start, middle: exploration, right: ﬁnal result

situation). Top row: sensor activity within clusters, bottom row: sensor activity scattered over the network.

Figure 7: High-level and gate-level synthesis results for one sensor node (FPGA: Xilinx XC3S100, ASIC: LSI10K standard

cell library, 180nm technology).

DesignofMaterial-integratedDistributedDataProcessingPlatformswithMobileMulti-agentSystemsinHeterogeneous

Networks

mediately return to the parent. This multi-path visit-

ing has the advantage of an increased probability of

reaching nodes with missing (non operating) commu-

nication links (see Fig. 5). A deliver agent, created

by the node agent, ﬁnally delivers exploration results

to interested nodes by using directed diffusion ap-

proaches, not discussed here.

AAPL Speciﬁcation

Example 1 shows the AAPL behaviour speciﬁcation

for the exploration agent. The agent behaviour is par-

titioned in nine activities and two signal handlers. If a

sensor node agent observes an increased sensor value,

it creates a new explorer agent that enters the start

activity (lines 8-19). Each explorer agent is initial-

ized on creation with two parameter arguments: a di-

rection and a radius value. The ﬁrst agent created

by the sensor node has no speciﬁc direction. Child

agents with a speciﬁc direction are moved to the re-

spective node (line 11). In line 18, the transition

move

→

percept neighbour

is created (all existing tran-

sitions starting from activity

move

are deleted ﬁrst).

The start activity transitions to the perceptive activ-

ity, which creates child agents (lines 44-46). Forked

agents inherit all parent data and the current transition

network conﬁguration. Thus, in line 43 the transi-

tion

percept

→

move

is established (and inherited),

but after forking reset in lines 47-50 for the parent

agent behaviour, which await the return of all child

agents and a decision for behaviour selection (repro-

duce/diffuse). The child agents enter the

move

(lines

20-25) activity after forking and will be migrated in

the speciﬁc direction to the neighbour node.

Finally, the

percept neighbour

activity is

reached, which performs the local calculation (line

52) if there was no marking found, and stores the par-

tial result in the tuple database. Further child agents

are sent out if the boundary of the ROI is still not

reached.

Otherwise the agent goes back to his origin (par-

ent) by entering the

goback

activity performing the

migration (lines 66-68), previously updating its

value of the tuple database. If the returning agent

has arrived, it will deliver its

value by adding it

to the local

value stored in the database (lines 69-

72) and raising the

WAKEUP

signal to notify the parent,

which causes the entering of the parent’s signal han-

dler (lines 77-79).

If there is enough input and all child agents had

returned (or a time-out has occurred handled by the

signal handler

TIMEOUT

, lines 80-81), the exploration

agent either enters the

diffuse

reproduce

activ-

ity.

Diffusion and reproduction is limited by a lifetime

(decreased each time an explorer agent is replicated or

on migration, lines 27 & 36).

The agent behaviour speciﬁcation was synthesized

to a digital logic hardware implementation (single

SoC) and a simulation model with equal functional

behaviour suitable for the MAS simulator environ-

ment SeSAm (Kl¨ugel, 2009).

Simulation Results

Simulation results are shown in Figure 6 for two dif-

ferent sensor network situations, each consisting of a

network with autonomous sensor nodes arranged in

10 rows and 10 columns. One situation creates sig-

niﬁcant sensor values arranged in a bounded cluster

region, for example, caused by mechanical forces ap-

plied to the structure, and the other situation creates

signiﬁcant sensor values scattered around the network

without any correlation, for example, caused by noisy

or damaged sensors.

In the ﬁrst clustered situation, the explorer agents

are capable to detect the bounded region feature for

the two separated regions (indicated by the change

of the agent colour to black). Due to the reproduc-

tion behaviour there are several agents at one loca-

tion, shown in the right agent density contour plot. In

the second not clustered situation, the explorer agents

did not ﬁnd the feature and vanish due to their limited

lifetime behaviour.

The feature search is controlled by a set of param-

eters: {δ,ε

, ε

,lifetime,search radius R}.

Synthesis Results

The synthesis results of the hardware implementation

for one sensor node are shown in Fig. 7. The AAPL

speciﬁcation was compiled to the ConPro program-

ming model and synthesized to an RTL implementa-

tion on VHDL level. Two different target technolo-

gies were synthesized using gate-level synthesis: 1.

FPGA, Xilinx XC3S1000 device target using Xilinx

ISE 9.2 software, 2. ASIC standard cell LIS10K li-

brary using the Synopsys Design Compiler software.

The agent processing architecture consisted of the ac-

tivity process chain for the explorer and node agent,

the agent manager, the tuple-space database (support-

ing two- and three-dimensional tuples with integer

type values), and the communication unit. The pro-

cessing time of an activity is in the order of 10 µs.

This case study showed 1. the suitability of agent-

based approaches for large scale sensor networks, for

example used for real-time structural health monitor-

ing, and 2. the suitability of the proposed agent mod-

elling and synthesis approach for single System-on-

Chip microchip-level implementations.

ICAART2014-InternationalConferenceonAgentsandArtificialIntelligence

Example 1: Shortened and simpliﬁed excerpt of the AAPL

speciﬁcation for agent class

Explore

type keys=

{

ADC,FEATURE,H,MARK

}

;direction=

{

}

signal WAKEUP,TIMEOUT; val RADIUS := 4; ...

agent explore

(dir:direction,

radius:integer[1..16]) =

var dx,dy:integer[-100..100];

live:integer[0..15]; ......

var* s: integer[0..1023]; ......

activity start

dx := 0; dy := 0; h:= 0;

if dir

ORIGIN then

moveto

(dir);

case dir of

NORTH -

backdir := SOUTH

SOUTH -

......

else

live := MAXLIVE; backdir := ORIGIN

group := random(integer[0..1023]);

transition*

(move,percept neighbour);

out

(H,id(self),0);

(ADC,s0?)

activity move

case dir of

NORTH -

backdir := SOUTH; incr(dy)

SOUTH -

backdir := NORTH; decr(dy)

WEST -

....

moveto

(dir)

activity diffuse

decr(live);

(H,id(self),?);

if live

0 then

case backdir of

NORTH -

dir :=

random(

{

SOUTH,EAST,WEST

}

)

SOUTH -

....

else

kill

(ME)

activity reproduce

var n:integer;

decr(live);

if live

0 then

for nextdir in direction do

if nextdir

backdir

and

link?

(nextdir) then

fork

(nextdir,radius)

transition*

(reproduce,stay)

activity percept

= -- Master perception --

enoughinput := 0;

transition*

(percept,move);

for nextdir in direction do

if nextdir

backdir

and

link?

(nextdir)then

incr(enoughinput);

fork

(nextdir,radius)

transition*

(percept,diffuse,(h

ETAMIN

or h

ETAMAX) and enoughinput

1);

transition+

(percept,reproduce,h

= ETAMIN

and h

= ETAMAX and enoughinput

1);

timer+(TMO,TIMEOUT)

activity percept neighbour

if not

exist?

(MARK,group) then

mark

(TMO,MARK,group);

enoughinput:= 0;

(ADC,s?);

out

(H,id(self),calc());

transition*

(percept neighbour,move);

for nextdir in direction do

if nextdir

backdir

and inbound(nextdir) and

link?

(nextdir) then

incr(enoughinput);

fork

(nextdir,radius)

transition

*(percept neighbour,goback,

enoughinput

1);

timer+

(TMO,TIMEOUT)

else

transition*

(percept neighbour,goback)

activity goback

h := 0;

try in

(0,H,id(self),h?);

moveto

(backdir);

activity deliver

var v:integer;

(H,id(parent),v?);

out

(H,id(parent),h+v);

send

(id(parent),WAKEUP);

kill

(ME)

activity stay

rm(H,id(self),?)

;

n :=0;

try in

(0,FEATURE,n?);

out

(FEATURE,n+1)

handler WAKEUP

decr(enoughinput);

try rd

(0,H,id(self),h?);

if enoughinput

1 then

timer-

(TIMEOUT)

handler TIMEOUT

enoughinput := 0; again := true

function calc

():integer=

if abs(s-s0)

= DELTA then return 1

else return 0

function inbound

(nextdir:direction):bool=

case nextdir of

NORTH -

return (dy

RADIUS)

SOUTH -

......

transitions

start -

percept; percept -

move;

move -

percept neighbour;

.....

5 CONCLUSIONS

A novel design approach using mobile agents for

reliable distributed and parallel data processing in

large scale networks of low-resource nodes was intro-

duced. An agent-orientated programming language

AAPL provides computational statements and state-

ments for agent creation, inheritance, mobility, in-

teraction, reconﬁguration, and information exchange,

based on agent behaviour partitioning in an activ-

ity graph, which can be directly synthesized to the

microchip level by using a high-level synthesis ap-

proach. The high-level synthesis tool also enables

the synthesis of different processing platforms from a

common program source, including standalone hard-

ware and software platforms, as well as simulation

models offering functional and behavioural testing.

Agents of the same class share one virtual ma-

chine consisting of a reconﬁgurable pipelined multi-

process chain based on the CSP model implement-

ing the activities and transitions, offering parallelized

agent processing with optimized resource sharing.

Unique identiﬁcation of agents does not require

unique absolute node identiﬁers or network addresses,

a prerequisite for loosely coupled and dynamic net-

works (due to failures, reconﬁguration, or expansion).

DesignofMaterial-integratedDistributedDataProcessingPlatformswithMobileMulti-agentSystemsinHeterogeneous

Networks

The migration of an agent to a neighbour node takes

place by migrating the data and control state of an

agent using message transfers. Two different agent

interaction primitives are available: signals carry-

ing data and tuple-space database access with pattern

templates.

Reconﬁguration of the activity transition network

offers agent behaviour adaptation (which can be in-

herited by child agents) at runtime and improved

resource sharing for parallel agent processing. A

case study demonstrated the suitability of the pro-

posed programming model, processing architecture,

and synthesis approach. Migration of agents requires

only the transfer of the control and data space of an

agent using messages.

REFERENCES

Bosse, S. (2013). Intelligent Microchip Networks: An

Agent-on-Chip Synthesis Framework for the Design

of Smart and Robust Sensor Networks. Proceedings

of the SPIE 2013 Microtechnologies Conference

Guijarro, M., Fuentes-fernandez, R., Pajares, G. (2008).

A Multi-Agent System Architecture for Sensor Net-

works. Multi-Agent Systems - Modeling, Control, Pro-

gramming, Simulations and Applications.

Zhao, X., Yuan, S., Yu, Z., Ye, W., Cao., J.

(2008). Designing strategy for multi-agent sys-

tem based large structural health monitoring. Ex-

pert Systems with Applications, 34(2), 1154 - 1168.

doi:10.1016/j.eswa.2006.12.022

Pantke, F., Bosse, S., Lehmhus, D., Lawo, M. (2011).

An Artiﬁcial Intelligence Approach Towards Senso-

rial Materials. Future Computing Conference

Kl¨ugel, F. (2009). SeSAm: Visual Programming and Par-

ticipatory Simulation for Agent-Based Models. In:

Multi-Agent Systems - Simulation and Applications,

A. M. Uhrmacher, D. Weyns (ed.), CRC Press

Bosse, S. (2011). Hardware-Software-Co-Design of Par-

allel and Distributed Systems Using a unique Be-

havioural Programming and Multi-Process Model

with High-Level Synthesis. Proceedings of the SPIE

Microtechnologies 2011 Conference, Session EMT

102

Kone, M. T., Shimazu, A., Nakajima, T. (2000). The

State of the Art in Agent Communication Languages.

Knowledge and Information Systems, 2(3), 259 - 284.

doi:10.1007/PL00013712

Ebrahimi, M., Daneshtalab, M., Liljeberg, P., Plosila, J.,

Tenhunen, H. (2011). Agent-based on-chip network

using efﬁcient selection method. IEEEIFIP 19th In-

ternational Conference on VLSI and SystemonChip

(pp. 284-289)

Sansores, C., Pavon, J. (2008). An Adaptive Agent Model

for Self-Organizing MAS. In Proc. of 7th Int. Conf. on

Autonomous Agents and Multiagent Systems (AAMAS

2008), May, 12-16., 2008, Estoril, Portugal, pp. 1639

- 1642.

McCabe, F. G., Clark, K. L. (1995). APRIL - Agent Process

Interaction Language, (M. Wooldridge & N. R. Jen-

nings, Eds.). Intelligent Agents Theories Architectures

and Languages LNAI volume 890. Springer-Verlag.

Lang, W. Jakobs, F., Tolstosheeva, E., Sturm, H., Ibragimov,

A., Kesel, A., Lehmhus, D., Dicke, U. (2011). From

embedded sensors to sensorial materials - The road to

function scale integration. Sensors and Actuators A:

Physical, Volume 171, Issue 1

Liu, J. (2001). Autonomous Agents and Multi-Agent Sys-

tems. World Scientiﬁc Publishing, (ISBN 981-02-

4282-4)

Meng, Y. (2005). An Agent-based Reconﬁgurable System-

on-Chip Architecture for Real-time Systems. In Pro-

ceeding ICESS ’05 Proceedings of the Second Inter-

national Conference on Embedded Software and Sys-

tems, pp. 166 - 173.

Jamont, J. P., Occello, M. (2008). A multiagent method

to design hardware/software collaborative systems,

2008. 12th International Conference on Computer

Supported Cooperative Work in Design

Naji, H. (2004). Creating an adaptive embedded system

by applying multi-agent techniques to reconﬁgurable

hardware. Future Generation Computer Systems, vol.

20, no. 6, pp. 1055 - 1081

ICAART2014-InternationalConferenceonAgentsandArtificialIntelligence