Dynamic Sensor Control

Main Released Functionalities and Services

In the context of Resource Sharing & Management functionalities, a Dynamic Sensor Control module has been developed that extends the X-GSN module. The functionality of this module periodically queries the LSM-Light for the active sensors and activates/deactivates the relevant virtual sensors on the X-GSN module. In order to implement the module it was necessary to provide an extension to the API of X-GSN that would perform these queries that identify the currently active sensors.

##Download, Deploy and Run The current module is embedded in the X-GSN module, therefore the process to download, install and run this module is already handled when performing the same process with X-GSN. Refer to the X-GSN section for specific details.

Source Code Analysis

This section describes the architecture of the Dynamic Sensor Control code. Figure 30 represents the UML class diagram that facilitates the Sensor Use Identification functionality (identify the X-GSN sensors that are used in the queries, and activate/deactivate virtual-sensors accordingly).

UML Diagram

The following UML diagram depicts the classes that comprise the Dynamic Sensor Control Module. The Parser interface and the SensorParser implementation class are in charge of parsing the RDF metadata in LSM-Light, and extract the identifiers of the virtual sensors. The DynamicControlTask class encapsulates the operations of activation and de-activation of virtual sensors. It has a SparqlClient attached to be able to pose SPARQL queries, get results (which can be later parsed) and get the virtual sensor identifiers to activate or de-activate.

[](Documentation/images/dynamic-sensor-control/dsc-uml.png)

###Class Components The following section contains tables that analyse various class methods of the module’s components.

**Parser**

Service Name	Input	Output	Info
parse	TupleQueryResult	Collection<T>	This method should be implemented by any class implementing the Parser Interface

The Parser interface is part of the Strategy Design Pattern that is used to manage various Parser subclasses that are used from the SparqlClient. Each class implementing this interface returns a Collection of the type defined at runtime.

**ParserFactory**

Service Name	Input	Output	Info
SENSOR_PARSER	void	SensorParser	Sensor parser implements the Parser interface meaning that the parse method returns a Collection of Strings

ParserFactory implements a Static Factory Design pattern that creates objects that implement the Parser<T> interface.

**SensorParser**

Service Name	Input	Output	Info
parse	TupleQueryResult	Collection<String>	Simply calls the parseTQR method
parseTQR	TupleQueryResult	Collection<String>	Implementation of the actual parsing functionality

SensorParser implements a Parser<String> interface and is the only concrete implementation at the moment. Sensor parser parses TupleQueryResults and returns Strings that represent a sensor ID. The parser is executed over the SPARQL query results from LSM-Light.

**DynamicControlTask (Singleton)**

Service Name	Input	Output	Info
run	void	void	This is the main method of the class that is executed once a timer starts it
activateSensor	File	void	Copies active sensors from the LSM-Light directory to the virtual-sensors directory
deactivateSensor	File	void	Deletes inactive sensors from the virtual-sensors directory
getGSNSensors	String	Map<String, File>	Retrieves GSN sensors from the specified path
loadSparqlClient	void	SparqlClient	Initializes the sparql client
getInstance	void	void	Retrieves the singleton instance

DynamicControlTask is the class providing the main dynamic sensor control functionality. Since it is desirable that only a single task of that type is running at a given time, it is implemented as a singleton. Other than that its’ main responsibilities are using the SparqlClient class to query the LSM-Light for active sensors and activate/deactivate the corresponding virtual sensors. The activateSensor and deactivateSensor method implements the copy and activation of sensors, if they are announced in LSM-Light. Conversely, the deactivate Sensor service deletes inactive sensors in X-GSN, thus optimizing the use of resources in the system.

**DynamicControlTaskTimer (Singleton)**

Service Name	Input	Output	Info
getInstance	void	Timer	Retrieves the singleton instance
startTimer	void	void	Initiates the timer

The DynamicControlTaskTimer class simply starts/cancels the timed schedule for the DynamicControlTask class. Similarly to the DynamicControlTask, we only want a single Timer to be active. Therefore, this class is also implemented as a singleton.

**SparqlClient**

Service Name	Input	Output	Info
getQueryResults	String, Parser<T>	Collection<T>	This method receives a string query and a Parser with which the query results are parsed. It retrieves the results from the LSM-Light, inserts them into the parser and returns a Collection of objects specified by the parser algorithm that is selected.
sparqlToQResult	String	TupleQueryResult	This method receives a Sparql query in String form and returns a TupleQueryResult which can then be inserted into a parser

The SparqlClient class is responsible for establishing a connection with the LSM-Light database, in order to perform queries and return results.

Configuration

Concerning the Dynamic Sensor Module itself, there is a limited set of functionalities that can be configured in the conf/lsm_config.properties file. The file contains the following lines that concern the specific module.

#DynamicControl
functionalGraph = http://lsm.deri.ie/OpenIoT/guest/functionaldata#
endPoint = http://lsm.deri.ie/sparql
virtualSensorsDir = virtual-sensors
availableSensorsDir = virtual-sensors/LSM
dynamicControl = true

#enter frequency of dynamic sensor control in minutes
dynamicControlPeriod = 5

The properties that can be configured are explained as follows:

Property	Explanation
functionalGraph	The link to the RDF Graph that is to be queried
endPoint	An LSM-light endpoint that is used to establish the connection for the SparqlClient class
virtualSensorsDir	This is the folder where active virtual sensors (xml files) are expected to be found
availableSensorsDir	This is the folder where available virtual sensors (xml files) are expected to be found
dynamicControl	This property states if the Dynamic Control actives (True) or inactive (False). The default value is true
dynamicControlPeriod	This property states the time interval, which the LSM-Light query for active sensors (in minutes)