Recent Changes - Search:



This section include a description of the steps we had to take to run Cityscripts on top of the SmartSantander framework.

Connector to USN

This component integrate SmartSantander sensors into the Cityscripts. It connects a CityScripts instance to USN for retrieving data from sensors. As reported in [UNICA API] the related APIs allow an application (like CityScripts) to subscribe to the system in order to asynchronously receive sensor network events. In order to achieve that, the CityScripts platform must adhere to the API specification also exposing a SOAP-based endpoint for event notifications from the UNICA subscription servers. We will refer in the whole document to UNICA API as Ubiquitous Sensor Network Platform API (USN). The following picture shows a general diagram of an integration/interaction model between CityScripts and USN APIs.

FIGURE 1. General diagram for a CityScripts / USN interaction sequence.

1. Discovery of the SmartSantander deployed sensors/devices: this action is achieved using the SensorData API module. A list of deployed and available sensors/devices is obtained;
2. Retrieve sensors/devices geo-positions: for each sensor/device returned in step 1, retreive the current location. The SensorData API is used;
3. Select a sensor/device: in CityScripts it's be possible to select a particular sensor/device by its ID
4. Subscription for observations: for a selected sensor/device (step 3) a subscription for observations it's registered in the USN service through the Subscription API; the subscription for a particular sensor/device can be performed specifying an XPath expression that points to the sensor/device ID. At the time of develoment we choose to subscribe to all the USN devices and use a local Abstract Sensor Index to store values from observation events notification.
5. Observation events notification: as a consequence of step 3, USN system notifies CityScripts with observation events coming from every sensor/device; events contain measuring data, thus CityScripts will be able to process them as required. Observation notification is performed by Notification API.

Steps 1, 2 & 4 require to design a USN API client, while step 5 requires the implementation of a Notification Interface module in CityScripts. The interface must adhere to the USN Notification API specification.

Finally, each subscription can be deleted from USN servers using the Subscription API. This integration model defines the core of the CityScripts/USN communication.

APIs adhere to Web services standards, described by a WSDL document and exchanged messages are based on SOAP.

Abstract Regions

Briefly, Abstract regions allow users to define geo-bounded areas containing certain types of sensors and, consequently receive produced data aggregated into a single data source, resulting in the creation of sorts of “virtual” sensors.

Abstract Regions in CityScripts, can be summarized in two main requirements:

·       Abstract Region Workspace Widget (ARWW): in their personal workspace, users can define an Abstract region simply selecting a geographical region on a map, generating a geographical query.

·       Abstract Region Index (ARI): data from different sensors belonging to the same Abstract region in the workspace are aggregated in a single data source.

Moreover, Virtual sensors have a key role in the CityScripts experiment. On one hand an abstract region can be regarded as a Virtual Sensor composed by many distributed sensors of the same physical quantity which values are aggregated according to a user defined function (i.e. the average of N values in a region). On the other hand, situation-aware computation may require values from different sensors (e.g. light, noise, and rain) in a given spot to perform an action accordingly.

SmartSantander plans to implement a Virtual Sensor infrastructure [SMARTS D2.2]. What CityScripts expects from such Infrastructure is to expose a clear API capable to handle the lifecycle of a new Virtual Sensor. Waiting for these API, the current version of the CityScripts provides two types of Abstract regions:

Abstract region TypeDescriptionAvailable in Workspace
Abstract Region Virtual Sensor (ARVS)Collects and aggregates data measured by sensors belonging to a specified geographic area and of a specified type. Aggregation is computed according to user-defined functions and it represents the data output.YES
Abstract Region Geographic Selection (ARGS)Collects data measured by sensors of a specified type and belonging to a specified geographic area. No data aggregation is performed, data flows has measured by each sensor contained in the geographic bounding-box defined by users.YES

At the time of development and integration of the current version of CityScripts, SmartSantander doesn’t provide an API to perform geospatial queries to obtain devices and sensors, thus CityScripts implements a local geo-referenced index of SmartSantander devices (Abstract Region Index). The Index is then queried and used by Abstract Regions.

The following picture shows a detailed view for the FIGURE 1 describing all the steps and modules involved in Abstract region implementation. As mentioned before, there is one subscription for all the USN devices and use a local Abstract Sensor Index.

FIGURE 2. Abstract Regions implementation and integration: general overview

Steps numbered from 1 to 4 in FIGURE 2 are related to Abstract Region Index creation which is required component for both Abstract Region types to work properly; in step 4 CityScripts subscribes to receive data from all indexed devices/sensors whereas step 5 represent the Abstract regions, created by users, collecting SmartSantander data thanks to the USN integration. Users can create Abstract Regions in their personal CityScripts workspace through the provided Widgets, differentiated by Abstract Region type: Virtual Sensor or Geographic Selection. Next paragraphs detail these modules and actions.

Abstract Region Index

The Abstract Region Index (ARI) is a CityScripts component which stores all relevant data/metadata about all deployed SmartSantander devices/sensors and it is built thanks to the integration with the USN APIs. APIs adhere to Web services standards, described by a WSDL document and exchanged messages are based on SOAP. The ARI stores data structures like the following:

{ …"status" : 1, "loc" : { "lat" : 43.4629,"lon" : -3.80449 }, "date_modified" : "2012-10-16 17:44:44.221263", "uri" : "/device/M04.37","appID" : "118", "date_created" : "2012-10-09 16:14:26.755457", "data" : {

"concentration" :
{ "unit" : "%","value" : "74" },"luminousFlux" : { "unit" : "lm","value" : "0" },"temperature" : { "unit" : "Cel","value" : "17.67" }


Noteworthy are the following data items:

uri: CityScripts device id composed by the real id of the device/sensor in SmartSantander;
loc: latitude and longitude of the deployed device/sensor location; Location allows CityScripts to geo-spatial index and query the devices as required by Abstract Regions internals;
appID: appID as specified by USN APIs;
data: contains last updated real data measurements from the device/sensor;

ARI is updated/rebuilt with a configurable frequency. By default every 30 minutes. As depicted in FIGURE 1, ARI (re-)building process consists of the following steps:

1.     Discover all deployed sensors/devices querying SmartSantander through the USN SensorData API;
2.     For each device from step 1 obtain additional data/metadata invoking USN SensorData API;
3.     Save each sensor/device metadata in the ARI, also indexing by geo-spatial information;
4.     Subscribe to receive data measurements from all indexed devices/sensor, using the USN Subscription API;

Abstract Region Geographical Selection

SmartSantander does not provide a geographical query engine, thus it is not possible to natively query sensors by latitude, longitude. To work around this limitation CityScripts implemented a local index of (sensorIds, latitude, longitude, altitude) in order to allow such queries.

FIGURE 3. The Abstract Region Geographic Selection Widget

Through the widget shown in FIGURE 3, users can create a new Abstract Region which collects all data coming from the sensor/devices deployed in the geo-spatial bounding-box selected on the map AND measuring data of the selected type. Valid types are: concentration, temperature, sound, luminosity flux, acceleration, power, gas concentration, battery charge, parks.

Abstract Region Virtual sensor

Abstract region can be regarded as a Virtual Sensor composed by many distributed sensors of the same physical quantity which values are aggregated according to a user defined function (i.e. the average of N values in a region). At this time we have the reduction function (e.g average) inside CityScripts without relying on USN.

FIGURE 4. Abstract Region Virtual Sensor Widget

Using the Widget in FIGURE 3, users can create an Abstract Region Virtual Sensor which collects aggregated data of a specified type AND produced by all sensors/devices deployed in a selected geo-spatial area on a map. Allowed data types are (as for ARGS): concentration, temperature, sound, luminosity flux, acceleration, power, gas concentration, battery charge, parks. Data aggregation is performed by the means of a specified function/operation. Supported functions/operations are: data average, minimum and max values.

Abstract Region Data Collection

Steps 5 and 6 in FIGURE 2 are related to data collection from SmartSantander and to convey/adapt them toward defined CityScripts Abstract Regions. SmartSantander notifies CityScripts for all observations data through the dedicated USN Notification API integration, then the system is able to convey the collected data toward the users-defined Abstract region. Data collection strategy is different for the two region types.

For each Abstract Region Geographic Selection type, data is collected in the related sensor only if generated by a sensor/device deployed inside the configured geo-spatial area and it is of the defined data type; an example of collected data is reported in TABLE 1.

For each Abstract Region Virtual Sensor type, at a configurable time t (default is every 3 minutes), recent data coming from SmartSantander is examined by geo-spatial area and type, it is aggregated applying the specified operation/function and finally collected in the related sensor; an example of collected data is reported in

{"loc": {"lat": 43.461109999999998, "lon": -3.81351}, "data": {"type": "temperature", "value": "16", "unit": "Cel"}, "device_id": "M05.554"}{"loc": {"lat": 43.463369999999998, "lon": -3.8055599999999998}, "data": {"type": "temperature", "value": "17.22", "unit": "Cel"}, "device_id": "M14.345"}{"loc": {"lat": 43.461799999999997, "lon": -3.8029299999999999}, "data": {"type": "temperature", "value": "17.54", "unit": "Cel"}, "device_id": "AYTO.48"}

TABLE 1. Example of collected SmartSantander data for an ARGS CityScripts Sensor for temperature value type

{"operations": {"average": 17.942234042553189, "minimum": 15.98, "maximum": 22.37}, "region": , "type": "temperature", "devices_involved": 94, "unit": "Cel"}{"operations": {"average": 18.714571428571425, "minimum": 15.98, "maximum": 22.37}, "region": , "type": "temperature", "devices_involved": 70, "unit": "Cel"}

TABLE 2. Example of collected SmartSantander data for an ARVS CityScripts Sensor for temperature value type and average, minimum and maximum operations


[UNICA API]                             M2M, Functional Specification (Edition 1.02 rev. 00),

[SMARTS D2.2]                       SmartSantander D2.2, Second Cycle Components Design

Edit - History - Print - Recent Changes - Search
Page last modified on November 21, 2012, at 06:01 PM