a configuration and execution interface for

8/2/2019 A Configuration and Execution Interface For

1/4

GinConf: A configuration and execution interface for

Wireless Sensor Network in industrial context

Abstract. Wireless sensor networks (WSNs) are deployed to sense, monitor

and act on the environment. Some applications of these networks, especially in

industrial sense and react scenarios, require high performance and guaranties.

Our work is focused on building a system that allows configuring/reconfiguring

alarms, actions or closed-loop techniques in the context of GINSENG project wireless sensor networks with performance control guarantees. We propose an

approach for interaction with real-world devices through a web services

interface, allowing users to configure and apply various operations, including

complex closed-loop techniques that monitor and act over any actuator in the

WSN. To allow the interaction between a client application and the motes we

implemented an API to access services of the motes.

Keywords: WSN, Configuration/Reconfiguration, Industrial application.

1. Introduction

Sensor Networks are used nowadays in many application contexts, with quite

different characteristics. One application scenario of these networks consists onindustrial environments. In an industrial setting for monitoring-and-control

applications, easy configuration and reconfiguration capabilities become important

during deployment and tests, where issues such as latencies may dictate modification.

During the lifetime of the network, a deployment may not meet all requirements. It

is important to check if all requirements are guaranteed, if not, it is needed to change

something in the network.

Closed-loop control is an important issue in industrial settings. Since sensor motes

have limited computation capability and control computations may require operation

on values coming from multiple sensors, immediate sensor-triggered control will

typically be only for emergency actuation (e.g. opening a valve if pressure goes

beyond an emergency level). More complex closed-loop control computations can be

done in a control workstation, subject to larger latencies and more data (e.g. multiple

samples, inputs from multiple sensors).In this paper, we present an approach to connect wireless sensor or actuator nodes

to a web services interface for configuring and applying various operations, including

complex closed-loop control techniques. This work is done in the context of a

European GINSENG project wireless sensor networks with performance control

guarantees. Sensors and actuators are represented as resources of the corresponding

node and are made accessible using a web service interface that establishes the

communication with the nodes. Our main goal is to enable a flexible architecture

where sensor networks data can be accessed by users to configure the system,


2/4

including configuratio

present our system arc

2. GinConf Syste

As devices of WS

different sensors a

programming) is infea

services, we int

configuring/reconfigur

We designed the Gi

wireless sensor netwo

applications to share sarchitecture.

As shown on Figur

configuring and execu

GinConf abstractstheir functionalities ac

based on a web servic

For instance, if we co

to a sensor node, the

transmits it to the WS

using a request of webThe architectures

the Rule Processor.

connection between

data queries to the

implements sensor-speThe wsnDB is an i

network. This module

catalog is responsibl

n of alarms, sending rates, closed-loop control and ac

hitecture and show a user interface called GWeb.

Architecture

have limited computation capabilities and may co

nd actuators, manual configuration/reconfigura

sible if a large number of sensor nodes are used. Bas

roduce a plug-and-play approach, that

ing any mote in the WSN.

nConf to offer the configuration and execution interf

rk. Our approach also allows connecting multiple

ensing resources in a flexible way. Figure 1 show t

Figure 1: System Architecture

1, we propose to use the GinConf as an interface t

ing controllers in wireless sensor networks.

he proprietary communication protocols of motescessible via an Application Programming Interface (

interface that allows connecting any applications to

sider an action coming from the closed-loop softwa

inConf maps this request to a specific request of the

N. The API provides a set of resources that can be

service.ey components of GinConf are the I/O Adapter, w

he I/O Adapter is a module that allows establi

inConf and dispatcher to obtain sensor data strea

sensors, or access sensor characteristics. The

cific methods to communicate with the sensor.nternal memory database used to store information

is subdivided in two sub-modules: catalog, and sense

for indexing the sensor characteristics and oth

tions. We

nect with

tion (by

d on web

allows

ce for the

oncurrent

he system

at allows

nd offersAPI). It is

the WSN.

e via API

mote and

identified

snDB and

shing the

s, submit

ispatcher

about the

Data. The

er shared


3/4

resources in the system to enable applications to discover what is available for use.

The catalog information is maintained up-to-date by the Monitoring module that

collects status information from the network. To guarantee that the catalog has up-to-

date information, the sensor node may periodically send status messages to the

monitoring module. The senseData is responsible for storing data messages during a

time window. When an application needs data from overlapping spacetime windows,

senseData uses stored messages to get the data. This allows a client to request data

from any past instant. For instance, if a client requests all values in the last 10 minutes

to compute an appropriate action, the GinConf extracts data from the memory,

streams it and sends it to the application.

Lastly, the Rule Processor is a module that allows establishing the interaction

between different clients over the network in order to exchange data or to trigger

certain actions. The Rule Processor is composed by a web service interface that

allows using the resources of remote devices. In addition, GinConf provides, through

the API, a push-based mechanism to subscribe the data received from the WSN. This

functionality allows any client to receive periodically a data stream with the reading

transmitted by each sensor.

3. Application Programming Interface

GinConf offers an API that includes a set of functionalities required by

applications that need to interact with wireless sensor networks for industrial

environments. The API offers functionalities for:

Activate / deactivate nodes; Activate / deactivate sensors and actuators connected to each node; Gather sensed value data at different frequencies; Change the sampling rate; Request node status; Reset a node; Change node configuration parameters; Send controller code to nodes; Start a controller; Stop a controller; Set parameters, allow changing parameters of a controller; Define actions, conditions and rules.

4. User Interface

In this section, we describe the implementation of GWeb an interactive application

built on top of GinConf. GWeb (Figure 2) demonstrates how to create and send

queries to the WSN.


4/4

Figure 2: GWeb Interface

Figure 3: Layout of deployment

Figure 4: Temperatures chart

This application allows users to, for example, define a set of rules which trigger

certain actions based on a specified event. A typical rule may have the format if the

pressure lever in sensor A is greater than 5 bar, open valve X and send a notificationto server.

GWeb is an application that combines configuration and display of sensor streams

obtained using GinConf. Figure 3 shows the layout of an example of deployment and

Figure 4 shows the chart of temperature for mote 3. This application can be used by

all deployers to configure or reconfigure the network.

5. Demo Roadmap

In this demo we aim to present a tool that allows configuring and execute

controllers in a WSN specifically designed for industrial scenarios. In the scope of theGINSENG Project and based on the architecture presented above, we aim to

demonstrate how to configure the network to operate in critical scenarios. We willdeploy some nodes in a tree hierarchy topology, where all nodes are sense the

temperature and we will demonstrate how to change the sampling rates, create alarms

in motes and/or in PC, how to trigger actions based on events and how to change a

threshold level.

a configuration and execution interface for

Documents