SensLog in both versions was designed from the very beginning as a modular solution. It consists of several modules and it has been extended by additional modules.
- SensLog v2
- SensLog v1
Structure of SensLog v2 is shown on following diagram.
The Processing module provides methods for receiving observations and storing received data to the central data storage. This module was designed as standalone receiver module with object corresponding to the data model.
The Provider module provides methods for publishing stored data and result of analyses to clients and other applications. This module was designed as standalone receiver module with object corresponding to the data model. Provided webservices allow clients various method for data requesting.
The Model module provides to clients information about structure of objects that are provided by Processing and Provider modules. It allows clients to prepare corresponding structure of objects in applications utilizing SensLog web services.
Database part of SensLog v2 consists of data model and stored functions, procedures and triggers. Database model is implemented in PostgreSQL 9+ with PostGIS 2+ spatial extension.
Database model v2
The data model of SensLog v2 was redesigned according to experience from previous development and use cases.
- unit – table storing info about measuring unit (node, gateway, smartphone …)
- observation – main table storing received data from sensor, results of analyses etc.
- position – main table storing position of unit in particular timestamp
- sensor – table storing info about physical device producing observations
- sensor_type – table storing info about types of sensors that can be deployed in the sensor network
- phenomenon – table storing info about phenomenon measured by sensor deployed in the network
- event – table storing info about event occured in the network (alert, warning, exception, threshold etc.)
- event_status – code list of possible status of events
- privilege – table storing list of privilege for different objects
- unit_group – table storing group of units that are somehow related together (same campaign, same locality, …)
- user – table storing info about user that can access to the system
Structure of SensLog is shown on following diagram.
The core module contains methods responsible for objects modelling, number of utility classes for querying and storing and methods for database connection.
The Feeder module is responsible for receiving measured data from sensor units or gateways but also management data from any client applications. The Feeder module has sepparate services for sensor data and for management and administrative data.
The Provider module is responsible for publication of all stored data. It contains web services for publishing of stored raw data, results of analyses, management data etc.
Additional modules are focused on special types of data.
The VGI module is oriented on a specific type of thematic data with spatio-temporal localization. Current version of the module is focused on collecting Points Of Interest (POI). This module for collecting VGI is the newest part of SensLog. The VGI module is able to store features that are containing point geometry, standard simple attributes and additional connected multimedia files. Web services for handling VGI are described in separate chapter. VGI can be published both in JSON or GeoJSON format.
Database part of SensLog consists of data model and stored functions, procedures and triggers. Database model is implemented in PostgreSQL 9+ with PostGIS 2+ spatial extension.
Core database model
The core data model is shown on following diagram.
Data models of additional modules
Additional tables were added to the core data model for implementing the VGI module. VGI data model is shown on following diagram.
SensLog runs in Tomcat as web application and needs PostgreSQL in version 9.0 and higher with PostGIS version 2.0 and higher installed on server.