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 on industrial 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,

including configuration of alarms, sending rates, closed-loop control and actions We uding actions. present our system architecture and show a user interface called GWeb.

2. GinConf System Architecture ystem
As devices of WSN have limited computation capabilities and may connect with different sensors and actuators, manual configuration/reconfiguration (by /reconfiguration programming) is infeasible if a large number of sensor nodes are used. Based on web services, we introduce a plug-and-play plug approach, that allows allow configuring/reconfigur /reconfiguring any mote in the WSN. We designed the Gin inConf to offer the configuration and execution interface for the wireless sensor network Our approach also allows connecting multiple concurrent network. applications to share sensing resources in a flexible way. Figure 1 show the system architecture.

Figure 1: System Architecture

As shown on Figure 1, we propose to use the GinConf as an interface that allows configuring and execut executing controllers in wireless sensor networks. GinConf abstracts the proprietary communication protocols of motes and offers their functionalities accessible via an Application Programming Interface (API) It is (API). based on a web service interface that allows connecting any applications to the WSN WSN. For instance, if we consider a action coming from the closed-loop software via API an loop to a sensor node, the G GinConf maps this request to a specific request of the mote and transmits it to the WSN The API provides a set of resources that can be identified WSN. using a request of web service service. The architecture’s key components of GinConf are the I/O Adapter, wsnDB and the Rule Processor. The I/O Adapter is a module that allows establishing the connection between G GinConf and dispatcher to obtain sensor data streams, submit data queries to the sensors or access sensor characteristics. The dispatcher sensors, implements sensor-specific methods to communicate with the sensor. specific The wsnDB is an internal memory database used to store information about the network. This module is subdivided in two sub modules: catalog, and senseData. The sub-modules: catalog is responsible for indexing the sensor characteristics and other shared

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-todate 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 space–time 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.

Figure 3: Layout of deployment

Figure 2: GWeb Interface Figure 4: Temperature’s 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 notification to 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 the GINSENG Project and based on the architecture presented above, we aim to demonstrate how to configure the network to operate in critical scenarios. We will deploy 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.

Sign up to vote on this title
UsefulNot useful