1 Introduction

Today, wireless sensor networks have become a discipline that plays a very important role in the acquisition, use, and manipulation of information [1]. They are a less costly technique for observing the earth’s surface that provides a wealth of data for different domains of environment [2], telecommunications [3] and transportation (followed by a road network) [4]. The majority of work based on wireless sensor networks is concerned with physical and network level study (routing, energy consumption, communication technique) and other solutions aiming at manipulating and analyzing the data recorded by sensor networks. Several works have been realized around architecture of monitoring application based on network sensors, in [5]. The authors proposed an approach for integrating wireless sensor nodes into a service-oriented architecture using a gateway to access the WSN. They suggested the use of service-oriented architecture (SOA) for integration into different systems such as home automation. However, their work lacks the most important part, namely the interception and use of data in real time. The reference [6] is interested in the use of SOA architecture via a REST API on each sensor node in the WSN. Similarly in [7], a study devoted to the implementation of a system based on the SOA architecture with Web services interoperable via the simple object access protocol (SOAP) directly on the nodes and not on the gateways. A major challenge in the deployment of Web service technology on resource-limited sensor nodes leads to unacceptable overheads in terms of RAM, CPU, bandwidth load, and energy [8]. However, a gateway device is required to support the scalability of management operations, as well as reliability and survivability of the WSN with a minimum of complexity and low maintenance cost. In our scheme, we implemented a climate monitoring system based on SOA [9], which allows to intercept sensor data in real time via MQTT and to index them, analyzes them in memory database [10], and transmits in real time a Web application [11] via Web Socket. The spatial and temporal conceptual modeling methodology in GeoUML [12] makes it possible to design a database for structuring and archiving spatial, temporal, and spatiotemporal data coming from the sensor network. The archived data are exposed via a Web services API (REST, GWS) allowing exploitation and analysis according to several spatial and temporal criteria in different graphic and table formats. Thus, the exploitation of spatial and temporal data makes it possible to generate various layers enabling to represent a phenomenon variation over time in various geographic areas (e.g., variation of the temperature during one year in the Saharan zones). This paper is structured as follows: Sect. 2 is devoted to the presentation of climate monitoring systems, as well as the techniques for data collection, data storage, conceptual modeling of spatial temporal data, and query processing. Section 3 discusses the architecture implemented in our system. The client interfaces of our application are represented in Sect. 4. Finally, Sect. 5 concludes the paper.

2 Climate Monitoring System

The climate network sensors based on monitoring systems are mainly composed of a set of sensor nodes (agile or fixed or mobile). This type of network has usually many sensor nodes distributed over an area defined to measure a physical quantity or track events that communicate with each other. Each node in the network is considered intelligent. It is equipped with an acquisition module which provides a measurement of climate data (such as temperature, humidity, pressure, and sunshine.), a processing capacity, a storage volume, a communication system, and energy. Sensors can be used and placed wherever one needs to collect useful information. These systems are responsible of technical collection and information saving. There are two types of sensor data:

  • Static data that are related to sensor characteristics (such as its type, storage capacity, and its transmission power.).

  • Dynamic data that are collected in relation to the physical features of the environment (such as temperature, humidity, and light.). Their values depend on the variation of the observed phenomenon [13]. Thus, the data collection position varies in case of agile or mobile sensors.

Collected data from the sensors can be spatial, temporal, or spatiotemporal. Indeed a spatiotemporal conceptual modeling is necessary to structure the various data in a central database.

2.1 Collecting Data

Data collection is a basic operation in the WSN. It consists of transmitting the data collected by sensors to a base station. Generally, data collection can be triggered by requests (at the request of the user) for information on the network. It can also be periodically triggered to monitor a geographic area, as it can be triggered by the occurrence of an event. The data collected at the base station can be processed immediately to meet the needs of the user. They can also be stored in a database for analysis by the following [14]. There are two types of data collection: (i) the data collected and transmitted individually to the base station when the measures are important and (ii) the data aggregation, defined as the data fusion process from several sensors at intermediate nodes in order to eliminate redundant transmissions and to reduce the amount of data transmitted across the network [15]. The data aggregation seeks to collect the most critical sensors and transmit them to the base station in effective way with a minimal latency and a low power consumption [16].

2.2 Data Storage

There are also two data storage approaches in WSN [17]. (i) Storage approach which is based on a centralized system. The data are collected from a sensor array and sent to a centralized database. Data processing is performed at the base to respond to user requests. In this approach, the processing of applications and the access to the sensors network are separated [18]. The storage approach is well suited to meet predefined queries on historical data. (ii) Distributed approach, where the data is stored in a database server and the sensors themselves, which will be then considered as databases. Generally, the database system builds an implementation plan for the treatment of requests [19]. The sensors storage capacity is limited and as the database system they form must maintain a history, it is necessary to clean the sensors database simultaneously with measurement acquisition. Indeed, the storage of sensors data in the central database is the adopted solution to climate monitoring system.

2.3 Spatiotemporal Conceptual Model

Spatiotemporal conceptual models aim to answer the users who need to answer their needs and to enable them to describe a diagram of readable and easy data to apprehend. The installation of an information system requires data modeling. If it is not contestable to make a traditional modeling of data in unified modeling language (UML) [20], it is more difficult to find a standard modeling for spatial data, and even for spatiotemporal data that are geometrically different. The spatiotemporal conceptual model must capture the essential semantics of the information change over time. It should be compatible with the traditional model in order to allow the modeling of data that are neither spatial nor temporal [21]. In a spatiotemporal conceptual model, we should know the various types of links (conventional, spatial, and temporal) between entities in the real world. However, there are various spatial conceptual models of data (CMD) among which we state two different approaches: Perceptory [22] and modeling of application data with spatiotemporal (MADS) [23]. They are based on CMD that originates from the databases, respectively, UML and ER (Entity/Association). They are extended to the spatial concepts. Considering the limitations related to MADS [24], we chose to use the Perceptory tool. This tool, which is able to be integrated into the Engineering Software Workshop (ESW) Visio, offers effectiveness in the visual modeling of spatial databases (DBS) and the basic of spatiotemporal data [22]. Perceptory was developed starting from a standard directed-object formalism. Later, it was undergone and was enriched to support the spatial reference and to take into account the norms ISO-TC211. In this paper, we applied spatial modeling GeoUML with the Perceptory tool using as a model real-time spatiotemporal data model [12]. The model mainly describes the aspects of environment monitoring. In this real-time spatiotemporal data (RTSTD) model, we define a GeoUML representation of the spatiotemporal data in a real time and their relationship with other static entities. The data collected by a sensor node are called according to their locations and their dates of acquisition. The sensors are located in the same area of observation to allow collection of various types of data (temperature, pressure, humidity, etc.) [25].

2.4 Queries Processing in WSN

The data acquired by the sensors are localized and dated. They are used in real time and deferred time managing a variety of large masses of spatiotemporal data. Several types of queries can be applied to these data, to spatial, temporal, and spatiotemporal queries. We can mention examples of requests processed by our system:

  • Spatial Queries: they seek the value of a product attribute in one location. For example, the query “SELECT temperature FROM sensors WHERE sensors-location \(=\) (50, 60)” seeks the temperature of a sensors located in a point in the coordinate plane (50, 60).

  • Time Queries: they seek the value of a product attribute at a certain date. For example, the query “SELECT temperature FROM sensors WHERE mesure\(_{-}\)date = ‘10 / 10 / 2016”’ searches the temperature of each sensor on the mesure date of ‘10 / 10 / 2016’.

  • Spatiotemporal Queries: they seek the value of a product attribute at a time and in a given location. For example, the query “SELECT temperature FROM sensors WHERE mesure\(_{-}\)date \(=\) ‘10 / 09 / 2016’ and sensors\(_{-}\)location \(=(50, 60)\)”. Researches localized temperature sensor (50, 60) at the mesure date of ‘10 / 9 / 2016’.

3 System Architecture

In this work, we adopted a solution based on a SOA architecture interconnected with MQTT which allows the integration of the real physical peripherals data in other information systems. This architecture is based on the use of Web services technologies (REST, GWS) and the Web sockets with the components of customer RIA. The emergence and the consolidation of service-oriented architecture (SOA), MQTT, and of the wireless sensor network (WSN) increase the advantages (such as flexibility, evolutionarily, the security, interworking, and the adaptability) of this kind of applications. The following architecture in Fig. 5 summarizes the relations between all technologies we have cited. This architecture is made up of the three following modules.

Fig. 1
figure 1

Mechanism of transferring data between the gateway and the application server

Full size image

3.1 Module 1

A wireless sensor network (WSN) composed of a large number of nodes where each is equipped with an Xbee module and a set of sensors to detect various physical phenomena such as the sunning, the temperature, and the pressure. The data collected by the various sensors are sent toward a gateway via Wifi connection. The Wifi connection is configured between the nodes and the gateway by using a Zigbee protocol. The communication of information between the gateway and the application server is based on the use of MQTT protocol which consists of a communication channel publish/subscribe Fig. 1.

3.1.1 Real-time Data Exchange

The framework is based on a service-oriented architecture (SOA) and a CloudMQTT allowing a transparent integration of various data collected toward a server (broker). The MQTT is responsible for making the connection between the gateway and the application server or different customers registered in the topic. The models of communication publish/subscribe provide a form of interaction which performs less dependency between the entities on the systems. The basic idea is that the application server fits in an object (topic) or a set of events, when the gateway generates events or publishes data on the broker [26], and the latters will be propagated in real time in the server.

3.1.2 REST Architectural Style

The configuration of the sensor network through the clients is done by consuming a service between the gateway and the application server Fig. 2. It allows client applications to reconfigure and maintain the network during its lifetime. So we defined a representational state transfer (REST) style SOA to allow integration of the WSN with the application services REST-WS [27]. REST is an architectural model that triggers a good extension of Web services by presenting various Hypertext Transfer Protocol (HTTP) methods and operations to transfer representations of resources between clients and servers. REST is less complex than SOAP-WS [28], and its consumption is minimal, which provides an open and flexible framework, allowing evolutionary and dynamic monitoring of resources [29, 30]. The format used for data transfer in our work is JSON. Unlike XML, JSON provides a more readable and easy-to-implement structure involving less use of application and network resources.

Fig. 2
figure 2

Mechanism of the sensor network configuration

Full size image

3.2 Module 2

The application server (which complies with the industry standard) enables the reception of data sent by the gateway and the distribution of users and information loads while ensuring high availability. The module is also based on the use of a database in “In Memory Database”. This allows data to be saved and indexed in real time to optimize the backup time and speed up access to recent data. Then, this data will be archived in a PostgreSQL/PostGIS geographic database server which allows the storage, archiving, and management of spatiotemporal data according to well-defined periods. A cartographic server certified by the Open Geospatial Consortium (OGC) complying with ISO/TC 211 standards [31] is thus used for manipulating the display and distribution of geographic data in a Web environment via GWS Web services, WMS). The data received by the application server is transmitted to the clients in real time via Web sockets Fig. 3. The notifications are sent in “Push” mode to the client without execution of the requests when the server receives the new data.

Fig. 3
figure 3

Communication between client and application server

Full size image
Fig. 4
figure 4

Query operations to application server

Full size image

The manipulation and consultation of the data stored in memory database and the spatiotemporal database are done by consuming a service between the clients and the application server via HTTP Fig. 4.

3.3 Module 3

The Web client module allows secure access to the different data. It enables thin clients to query the spatiotemporal or the memory database and then to view the network data of the sensors in a Web environment. This module is based on the use of RIA Web client available through Web browsers and mobile devices such as smartphones and desktops. Thus, the data stored in the spatiotemporal database can be interrogated and manipulated by heavy clients, such as open source software (Qgis, Gvsig, Quantum GIS) as well as Arcgis, which allows to organize, manage, analyze, communicate, and disseminate geographic information.

Fig. 5
figure 5

Architecture patterns of the system

Full size image
Fig. 6
figure 6

Proposed system dashboard

Full size image
Fig. 7
figure 7

Interface consulting real-time information sent by the sensor

Full size image
Fig. 8
figure 8

Chart of temperature measurement

Full size image

4 System Implementation

The implemented system can intercept the data of WSN. The received data are immediately processed by a filter and treatment modules. Thus, interesting data (critical value or abnormal phenomenon) triggers an alert or a notification that will be sent to users in real time. Filtering and processing modules allow the backup of data in the memory database to ensure high availability system. A dashboard was made available to the user for monitoring various collected data and phenomena Fig. 6. Other interfaces detail the observations of each phenomenon.

The interface illustrated in Fig. 7 allows visualizing in a Web environment the data of sensors network. It enables the users to consult the different observations sent by the sensors nodes. This interactive interface permits users to directly select one of the sensors on a map. One node sensor can be accessed by pan and zoom or by browser to visualize the real-time data distribution of the different sensors in an attributed table. The sensors are located in the same observed environment. The sensors nodes offer the possibility to measure different variables such as air temperature, rainfall, humidity, and solar radiation. Indeed, several measurements can be performed by a single sensor node.

The interactive interface presented in Fig. 8 allows users to view the collected data in the form of a graphical representation. By clicking on the graphic button, graphics display the data variation in a selected period. The data can be displayed in a data-grid representation mode if the tab button has been clicked.

5 Conclusion

Our application is intended to provide a tool enabling risk specialists to carry out expertise on events, sometimes on recent data in real time or very old data which affected the territory by confronting various sources. These expertises, called summary, will be used by risk managers to refine and improve their decision making, referring not only on the size of the harvested measures but also on the geographic location of events. Finally, the sensor data are used to supply a decision support system. Our application is a platform based on Web services (WFS, WMS, and REST) dedicated to the exchange and sharing of data and cartographic information in the field of natural risks.