SensiNact

Introduction

SensiNact aims at helping coders working with data streams from deployed “IoT” devices without the need to complex API configuration.

Using SensiNact, experimenters can find Internet of Things devices which are deployed in the city, and understand the data streams that they provide. The SensiNact IDE allows the creation of applications using a scripting tool (with Code Assist functionality). These applications might set up alerts for when variables in the data streams reach certain levels, or can aggregate data from many devices, creating virtual devices which provide coarse data that might be more useful to an experiment.

The following schema summaries the way SensiNact integrates with the OrganiCity Experimentation as a Service facility.

SensiNact architecture

The Organicity EaaS facility collects and stores data from the federated sites (Santander, Aarhus and London, on this schema). SensiNact Gateway is connected to this platform, and is notifed when IoT devices is added, removed, or when sensed data is updated. SensiNact studio provides a graphical UI to the gateway. It ease discovering devices, and provides an editor to write applications using IoT devices.

Installation

To use sensiNact, you need a gateway, and the studio.

SensiNact gateway will be provided as a service, in the cloud. To get the url and your credentials, please contact Etienne Gandrille.

SensiNact studio is based on the well known Eclipse IDE. To recieve a download link, please contact Etienne Gandrille.

Studio

SensiNact Studio allows an easy interaction with the OrganiCity devices and the creation of applications. The Studio is based on the Eclipse platform [Eclipse] and built as a rich client platform application. The Graphical User Interface (GUI) is developed using the views mechanism from Eclipse. Thus, it propose s views for browsing devices, locating devices on a map and interacting with them, i.e., getting value from sensors or performing actions on actuators. The Studio is also targeted to ease the creation of IoT application following the Event-Condition-Action (ECA) pattern [Den89].

SensiNact Studio GUI

The GUI includes different views: navigator, deployment, properties views, as well as a Domain Specific Language (DSL) editor.

Browsing devices

Before users can use the studio for managing devices and applications, they need to connect a SensiNact gateway (see paragraph 4.3). This action is performed by clicking on the plus sign icon on the device navigator. Then, gateway information have to be provided.

SensiNact Studio gateway config

Once the information have been provided and the dialog validated, the Gateway is added to the Navigator View. To display and browse the available devices imported by this gateway, connecting to it is needed. This action is performed using the connect button.

SensiNact Studio gateway connection

The device Navigator View is then populated, and pin points are displayed on the map. By clicking on attributes names, it is possible to get the current value for the considered attribute. It is also possible to see attributes values on the map, clicking on the pin points.

Application management

Application creation

SensiNact application creation

The SensiNact Studio allows the creation of applications to be executed on the gateway. Creating an application is performed by writing a script using a dedicated syntax, and deploying this script to the gateway.

On the figure above, a project has been created on the project explorer view (on the left). In this project, a script named speed-limit.sna has been created, and is being edited. As the figures shows, the editor provides code highlighting (some keywords are displayed in a special font), code completion (with popups) and a syntax validator which displays red crosses on the script margin in case of error.

The dedicated syntax, a Domain Specific Language, is composed by the following blocks:

The following table shows the basic structure for writing a script.

[resource ]+ Shortcut block, which must contains at least one statement.
on + The event block, lists the events triggering the script. At least one event must be provided.
[if do]+
[]+
[else do]?
[]?+
end if;
The conditional block, which lists actions to be performed based on conditions.

Once the script has been written, it can be deployed to the gateway where it will be executed. This is performed using a right click on the script file.

SensiNact application deployment

Application monitoring

After the application has been deployed, a new set of resources is automatically created under the AppManager device. You can browse those resources into the Device Navigator View.

SensiNact application resources

First of all, a new service is created with the name of the sna file (without the extension). In our example, it is speed-limit. This service representing the application always contains a standard set of resources.

Resource Type Description
autorestart property In case of failure, decides if the application should be automatically started again
content property Script file content
EXCEPTION action Deprecated
location property GPS location which can be used if it makes sense
maxinstances property Number of parallel instances which should be started
resetOnStop property On Stop, decides if the generated resources by the application should be destroyed or kept
START action Starts the application
status state variable Current status of the application: START/STOP/...
STOP action Stops the application
UNINSTALL action Removes the application

To start the application, simply double click on the START resource. This will launch the start action, which will run the script.

SensiNact application startup

The figure shows that the application is up and running on the server. The studio can be used to check if the application has the expected behavior, by querying the resources. The studio can also be shutted down, since the applications are executed on the gateway, which will be presented in paragraph 4.3 (sensiNact Gateway).

Conclusion

In this section, we have presented the way sensiNact Studio can gives an overview of the available devices in the OrganiCity context. We have also shown the creation process of IoT application following the Event-Condition-Action (ECA) pattern.

Gateway

Introduction

The sensiNact Gateway allows the interconnection of heterogeneous devices and services into a consistent model. This one is presented to the sensiNact Studio which can monitor the devices ecosystem and design application to be executed on the gateway.

SensiNact gateway integration

More precisely, the sensiNact Gateway integrates with the OC Platform using the Asset Discovery Service. Thereby, the gateway is aware of the assets provided by the OC Platform. On the other hand, the gateway has dedicated interfaces to directly connect to third parties devices and API. As a result, the gateway can interact with a lot of resources, which can be local or remote.

The gateway architecture

The interactions between the gateway and other entities are performed through a set of northbound and southbound bridges. The goal of the bridges is to manage the communication with devices and services, which can be local or remote. On one hand, southbound bridges are in charge of collecting data from sensors and services, and to send orders which will be performed by actuators. On the other hand, northbound bridges are specialized in interacting with remote systems. Thanks to those bridges, it is possible to make third party systems aware of devices & virtual resources known by the gateway.

SensiNact gateway architecture

In terms of connectivity, on the southbound side the sensiNact gateway allows to cope both with “physical device” protocols and “virtual device” ones, allowing a uniform and transparent access to an XBee network, or an HTTP Restful web service for example. Here's a non-exhaustive list of supported protocols:

On the northbound side the sensiNact gateway provides both client/server and publish/subscribe access protocols: MQTT [MQTT], JSON-RPC (1.0 and 2.0) [JSON-RPC], HTTP RESTful, CDMI [CDMI].

All the communications of sensiNact gateway are converging to a central piece: the core. This element is in charge of the overall coordination of information, involving two managers: the device manager and the application manager.

The device manager, with its associated database (the OSGi registry) stores all the information regarding devices. This include devices availability, and also devices properties, location, etc.

The application manager is a bit more complex. It manages the applications, following devices availability and updating applications life cycle. It offers a plug-in facility, to extend its behaviour. The two main plugins are the Event Condition Action plugin, and the Complex Event Processor plugin. The Event Condition Action plugin provides the basic structure for creating applications. It allows the triggering of rules, based on event. Then, a condition can be evaluated, and actions performed accordingly. Of course, events, conditions and actions are related to devices, using the device manager. Using the Esper Engine, the Complex Event Processor plugin is able to generate high level events based on low level ones. For example, it is possible to know that two events occur in a given time interval, with a given order. The events generated by the CEP plug-in can be used in the ECA plugin.

SensiNact resource model

It is important to understand the internal model of the sensiNact Gateway , since it is used everywhere in the sensiNact ecosystem. That is why, a clear understanding of the concepts and relationships between them can even help using the Studio introduced previously.

All the devices and their related informations are represented using a standard resource model. It is structured around three main concepts: Service Provider, Service and Resource. A Service Provider représents an entity, which can be a device or something more abstract such as an API endpoint. This Service Provider can have several Services, which are a meaningful aggregate of resources based on a common purpose. A resource is the place where information is stored. For example, on a weather station, a temperature sensor will be a resource providing the temperature.

SensiNact gateway resource model

Based on its purpose, a resource can be a Property, a Sensor Data, a State Variable, or an Action. The differences among them is detailed in the following table.

Type Description
Property Property exposed by a service. This is information which is likely to be static (owner, model, vendor, static location, etc.). In some cases, this property can be allowed to be modified.
Sensor Data Sensory data provided by a service. This is real-time information provided, for example, by the SmartObject that measures physical quantities.
State Variable Information representing a SmartObject state variable of the service. This variable is most likely to be modified by an action (turn on light modifies the light state, opening door changes the door state, etc.) but also to intrinsic conditions associated to the working procedure of the service.
Action Functionality provided by a service. This is mostly an actuation on the physical environment via an actuator SmartObject supporting this functionality (turn on light, open door, etc.) but can also be a request to do a virtual action (play a multimedia on a TV, make a parking space reservation, etc.)

Since it is not possible to directly interact with resources, sensiNact provides access methods. The access methods that can be associated to a resource depend on the resource type, for example, a GET method can only be associated to resources of type Property, State Variable and SensorData. A SET method can only be associated to State Variable and modifiable Property resources. An ACT method can only be associated to an Action resource. SUBSCRIBE and UNSUBSCRIBE methods can be associated to any resources.

Type Description
GET Gets the value attribute of the resource.
SET Sets a given new value as the data value of the resource.
ACT Invokes the resource (method execution) with a set of defined parameters.
SUBSCRIBE Subscribes to the resource with optional condition and periodicity.
UNSUBSCRIBE Remove an existing subscription.

Conclusion

We have presented the architecture of the sensiNact Gateway, and the way it is integrated into the OC Platform. We also have introduced its resource model, since it is used in the studio as well.

To help experimenters start easily using the Studio, we are providing “Gateways as a Service” for the OrganiCity project. They are Gateways available in the cloud, and configured for interacting with OrganiCity devices.