1 Introduction

Cloud computing and Internet of Things (IoT) are nowadays two of the most prominent and popular ICT paradigms that are expected to shape the next era of computing.

The IoT paradigm relies on the identification and use of a large number of heterogeneous physical and virtual objects (i.e., both physical and virtual representations), which are connected to the internet [1]. IoT enables the communication between different objects, as well as the in-context invocation of their capabilities (services) towards added-value applications. Early IoT applications are based on radio frequency identification (RFID) and wireless sensor network (WSN) technologies and deliver tangible benefits in several areas including manufacturing, logistics, trade, retail, green/sustainable applications, as well as other sectors. Furthermore, the European Commission has already co-funded a number of FP7 projects (e.g., IOT-A, iCore, BUTLER) [2], which have researched the main building blocks of IoT systems (including reference architectures) and have built innovative added-value applications.

At the same time, the cloud computing paradigm [3] realizes and promotes the delivery of hardware and software resources over the Internet and according to an on-demand utility based model. Depending on the type of computing resources delivered via the cloud, cloud services take different forms such as Network as a Service (NaaS), Infrastructure as a service (IaaS), Platform as a service (PaaS), Software as a service (SaaS), Storage as a service (STaaS) and more. These services hold to promise to deliver increased reliability, security, high availability and improved QoS at an overall lower total cost of ownership (TCO). Similarly to the case of cloud computing, the EC has already co-funded a number of projects (e.g., RESERVOIR, VISION-CLOUD, OPTIMIS, CONTRAIL) [2], which have developed pan-European prototypical cloud infrastructures, while they have also built relevant cloud technologies (e.g., resource management, security) and applications.

Another common aspect of IoT applications is that many of them of practical interest involve control and monitoring functions, where human-in-the-loop actions are not required. As a matter of fact, the only reason for having many of these applications is to remove human intervention for improved efficiency, security, and safety. We focus specifically on these applications, which we call machine-to-machine (M2M), which will create a bridge between the real world (made of sensors, actuators, tags that are pervasive in our lives) and the virtual world (the Internet and its associated services).

In the case of M2M, important research initiatives are proposing new reference models, defining standards and new communication architectures, with different approaches for solving security, reliability and energy-efficiency problems. However, many efforts are focused on largely distributed critical infrastructures and just a few initiatives are dedicated to the definition of platforms for deployment and execution of new M2M applications, based on new generations of WSN and innovative sensor mining methods that can be deployed according to a cloud computing model.

Indeed, M2M applications are envisioned to be hosted within cloud computing systems and contribute to the converge of interactions between the real and virtual world, thus accomplishing improvements in industrial productivity and quality of life for citizens, based on secure and dependable automation of sensing and actuating tasks.

However, we argue that this kind of approach is sub-optimal for M2M because of its inherent paradigms: M2M applications are highly autonomous, implement simple and repetitive interactions in highly constrained environments, with limited scope in time and space, and must respond in a reliable manner to mission critical QoS needs, whereas usual cloud applications require that big volumes of data are redundantly stored and provided through content delivery networks, to be available for very long periods and accessible as ubiquitously as possible for the use by human beings.

The paper is organized as follows. Section 2 presents an overview of the state of the art in Cloud Computing, IoT and M2M, while Sect. 3 presents a cloud computing architecture for telemetry. Section 4 presents Big Data processing involved in the previously mentioned architecture and the results achieved by using it in a real life scenario for hydro-energy telemetry implementation. Finally, Sect. 5 draws the conclusions and presents envisioned future work.

2 State-of-the-Art Review

2.1 Convergence Between Cloud and IoT

Since the early instantiations/implementations of both technologies, it has become apparent that their convergence could lead to a range of multiplicative benefits. Most IoT applications entail a large number of heterogeneous geographically distributed sensors. As a result, they need to handle many hundreds (sometimes thousands) of sensor streams, and could directly benefit from the immense distributed storage capacities of cloud computing infrastructures. Furthermore, cloud infrastructures could boost the computational capacities of IoT applications, given that several multi-sensor applications need to perform complex processing that is subject to timing (and other QoS constraints). Also, several IoT services (e.g., large scale sensing experiments, smart city applications) could benefit from a utility-based delivery paradigm, which emphasizes the on-demand establishment and delivery of IoT applications over a cloud-based infrastructure.

The proclaimed benefits of the IoT/cloud convergence have (early on) given rise to research efforts that attempted to integrate multi-sensory services into cloud computing infrastructures [4]. The most prominent of these efforts are the so-called sensor-clouds, which blend sensors into the data centre of the cloud and accordingly provide service oriented access to sensor data and resources [5]. Several recent research initiatives are focusing on real-life implementation of sensor clouds, including open source implementations [6]. Note that such initiatives are in progress both in the US [7] and in the EU [8], aiming at developing middleware infrastructures for sensor-clouds, which will enable the on-demand delivery of IoT services.

In addition to research efforts towards open source sensor-clouds, there are also a large number of commercial on-line cloud-like infrastructures, which enable end-users to attach their devices on the cloud, while also enabling the development of applications that use those devices and the relevant sensor streams. Such commercial systems include COSM [9], ThingsSpeak [10], and Sensor-Cloud [11]. These systems provide tools for application development, but they offer very poor semantics and no readily available capabilities for utility based delivery. There is also a number of other projects which have been using cloud infrastructures as a medium for M2M interactions (e.g., [12]), without however adapting the cloud infrastructure to the needs of the IoT delivery.

In the area of IoT applications (e.g., for smart cities), we are also witnessing cases of IoT/cloud convergence. For example, in the scope of ICT-PSP project RADICAL [13], the partners will be deploying sensor streams over the BONFIRE cloud infrastructure, as means to benefitting from the cloud’s storage capacity and applications hosting capabilities. A similar approach is followed in the scope of the FP7 SmartSantander project [14]. Note that smart cities is a privileged domain for exploring and realizing the IoT/cloud convergence, given that such applications need to manage and exploit a large number of distributed heterogeneous sensor streams and actuating devices.

Regarding the area of Cloud M2M concept for renewable energy, there is ongoing standardisation work in M2M communications followed by the application of M2M communications especially to smart grids [15, 16]. Also, a middleware perspective for telemetry is proposed by unifying M2M, SCADA, WSN and RFID technologies into IoT in the cloud [17]. An approach for data analytics for M2M and smart energy grid is discussed based on smart meter data mining and machine learning [18]. Even though cloud computing is considered efficient for smart energy grids, there are some drawbacks, such as security and reliability needed for critical infrastructures [19]. Furthermore, sensor-based M2M agriculture monitoring systems are being adapted for developing countries for monitoring renewable energy sources and smart green buildings [20, 21].

2.2 Big Data

The European Union has declared Big Data as a priority for Horizon 2020, the EU’s next European research framework. This is confirmed by the theme and budget of the last FP7 ICT call for projects to be started in 2014 [22, 23].

The plethora of data types and formats (structured, unstructured, semistructured or multistructured) as well as the diversity of generating sources (sensors, devices, social networks, web content, mobile phones, etc.) generates a large variety of data. According to Tech Target [24], multistructured data already represents 80 % of the volume of data that is available in an organization.

The economic potential of Big Data represents the greatest challenge and it consists of finding value in the large volume of unstructured data in (near) real time. The tendency to use this information for business analytics is becoming a worldwide management practice.

Fruitful sources of data, recently come to attention (IoT, sensor networks, social networks) have given an unprecedented growth rate of the volume of available microeconomic and macroeconomic data. It is estimated that in the year 2012 alone, 2.5 ExaBytes of data have been generated daily [25].

Big Data and their management (generating, storing, indexing, and searching) is a worldwide challenge because multiple factors, of which we mention:

  • The need for highly skilled labourers A Gartner study [26] from 2012 estimates the creation of 4.4 million new jobs globally in relation to Big Data.

  • Environment problem monitoring warping dams, proactive maintenance and repair, using satellite imaging to monitor changes in the Earth’s crust (earthquakes, erosion, floods, and landslides).

  • Smart City management this is based on gathering, managing and analysing large volumes of data regarding car and passenger traffic, the evolution of environmental factors, energy consumption dynamics, high risk situation monitoring etc. [2].

Variable prices and rising costs of production are forcing energy producers to optimize production costs. Therefore “precision energy production”, the optimized use of natural energy resources such as water, sun or wind is now indispensable. The growing environmental awareness of consumers further accelerates this process and promotes the usage of remote automatic monitoring system for field information such as the one we propose. By running the M2M software over virtual machines it is possible to optimize the network performance and improve the energy consumption for the devices that are powered by batteries [27].

In previous approaches remote telemetry units (RTUs) were implemented in most cases on a local server and no company could aggregate enough sensor data to consider automating the production process and providing the required resilience [28]. Furthermore, by using low power sensors and data aggregation the energy consumption of the M2M network can be optimized [29].

Some studies show that Cloud computing can actually make traditional datacentres more energy efficient by using technologies such as resource virtualization and workload consolidation [30]. Contrary to the above opinion, other studies, for example Greenpeace [31], observe that the Cloud phenomenon may aggravate the problem of carbon emissions and global warming.

3 Components of the Cloud Telemetry Architecture

To illustrate the need for interconnecting extremely heterogeneous sensors and gateways we consider the following example scenarios, which show short-term realistic applications of smart things enabled by M2M communication:

  • Continuous care Citizens affected by chronic diseases can be provided with sensors continuously monitoring relevant health parameters, which produce data that are conveyed through a smart phone to a remote centre for real-time analysis. In case a potentially dangerous situation is detected an alarm can be fed back to the smart phone.

  • Ambient assisted living Activity detection sensors installed in houses where senior or disabled citizens live send data to a remote centre, so as to generate alarms in case anomalies are detected with respect to a typical pattern (e.g., prolonged lack of movement during daytime).

  • Smart grid The distribution system operator (DSO) provides the smart meter of a house with information on the next-house cost of electricity. Based on this piece of information, possibly combined with other sources (e.g., power currently generated by solar panels), a remote control system can switch on/off smart electric appliances.

  • Traffic management Road-side units (RSU) are placed along roadways to monitor the flow of vehicles. Based on the information collected from a given area, a remote centre can identify congestions and provider drivers with real-time feedback to reduce travel times, hence CO2 emissions.

  • Fleet management Vehicles provide the intelligent transportation infrastructures with information on their location and health status, by allowing a remote control system to optimize logistics or track dangerous goods, for commercial vehicles only, and provide all drivers with improved safety or advanced services (e.g., pay-as-you-go insurance).

3.1 Cloud Architecture

SlapOS is based on a Master and Slave design, as shown in Fig. 1. In this paper we are going to provide an overview of SlapOS architecture and are going in particular to explain the role of Master node and Slave nodes, as well as the software components which they rely on to operate a distributed cloud for telemetry applications. Slave nodes request to Master nodes which software they should install, which software they show run and report to Master node how much resources each running software has been using for a certain period of time. Master nodes keep track of available slave node capacity and available software. Master node also act as Web portals and Web service so that end users and software bots can request software instances which are instantiated and run on Slave nodes.

Fig. 1
figure 1

SlapOS master—slave cloud architecture

Full size image

Master nodes are stateful. Slave nodes are stateless. More precisely, all information required to rebuild a Slave node is stored in the Master node. This may include the URL of a backup service which keeps an online copy of data so that in case of failure of a Slave node, a replacement Slave node can be rebuilt with the same data.

It is thus very important to make sure that the state data present in Master node is well protected. This could be implemented by hosting Master node on a trusted IaaS infrastructure with redundant resource. Or—better—by hosting multiple Master nodes on many Slave nodes located in different regions of the world thanks to appropriate data redundancy heuristic. We are touching here the first reflexive nature of SlapOS. A SlapOS master is normally a running instance of SlapOS Master software instantiated on a collection of Slave nodes which, together, form a trusted hosting infrastructure. In other terms, SlapOS is self-hosted.

SlapOS Slave nodes are relatively simple compared to the Master node. Every slave node needs to run software requested by the Master node. It is thus on the Slave nodes that software is installed. To save disk space, Slave nodes only install the software which they really need.

Each slave node is divided into a certain number of so-called computer partitions. One may view a computer partition as a lightweight secure container, based on UNIX users and directories rather than on virtualization. A typical barebone PC can easily provide 100 computer partitions and can thus run 100 RTU web portals or 100 sensors monitoring sites, each of which with its own independent database. A larger server can contain 200–500 computer partitions.

3.2 M2M Telemetry Architecture

In Fig. 2 we present the general structure of the system that we propose for the tele-monitoring of installation sites in hydro power stations.

Fig. 2
figure 2

General structure of the tele-monitoring system

Full size image

At each of the monitored installation sites a system is set up composed mainly from distant RTUs, sensors and actuators. RTUs capable to communicate with the Gateway through GSM-GPRS and Internet will be used in standard configurations. For the installation sites which are situated in no GSM coverage areas, RTUs in the UHF band of 430–440 MHz will be used. These will communicate with the date concentrator through a bridge station (bridge) which will ensure the UHF-GPRS and GPRS-UHF conversion.

In the relatively few instances when this will be possible, the RTU-Gateway communication will be held by radio exclusively in the UHF band of 430–440 MHz. The system’s key elements are:

  • Gateway, which ensures the communication with the RTUs and available resource management;

  • Presentation Server (PS) which is hosted on a computer with server features (for example, unattended operation 24/7), equipped with a software package focused mainly on data presentation in various forms, entirely available to users;

  • Application Server (AS), focused on special tasks, which PS cannot perform.

Practically, all system communication is done through the Internet and this gives the system investment and mostly operational advantages. It is mentioned that the users can access the processed data, offered by the PS and AS anywhere and anytime, from any terminal with Internet access (PC, tablet, mobile phone etc.) [32].

The system’s central elements are configured and scaled so that they would allow a system takeover of 100 RTUs.

4 Implementation of Hydro-Energy Telemetry System and Obtained Results

4.1 Installation Structure

In this chapter we present the particularities of the implementation for hydro-energy telemetry with respect to general implementations for aeolian or photovoltaic tele-monitoring. Similar applications could be identified for photovoltaic panels where voltage and current information is periodically sampled and transferred by M2M protocols. What is usually being used in measurement of energy potential and monitoring performances of photovoltaic parks is as follows: a remote telemetry unit, total radiation sensor pyranometer, sunshine duration sensor, albedometer, wind speed and wind direction sensor, air temperature and relative humidity sensor, barometric pressure sensor, solar panel for powering the M2M devices and sensors.

When the hydro power installation site to be monitored is a water intake installation, the structure of the installation that will be mounted at the site is shown in Fig. 3.

Fig. 3
figure 3

General structure of the water take telemetry solution

Full size image

Components of this structure are:

  • Remote Telemetry Unit (RTU), with GSM/GPRS communication in UHF band of 430–440 MHz;

  • Solar panel which ensures power supply to RTU’s and most of the sensor;

  • Rain gauge;

  • Interface boards PI and PI2;

  • Sensors connected to RTU through PI and PI2;

  • Electrovalve controlling the water intake in the segment-valve;

  • Auxiliary battery of 24 V for the power supply of the electrovalve to control the water intake and some of the sensors.

Comparing the proposed implementation with existing ones, there are similarities regarding the use of RTUs and solar panel and obviously differences regarding the sensors connected to the RTU for specific energy monitoring. For Adcon A753 (GSM/GPRS) or Adcon A733 (UHF) RTUs [9], for example, the interface board PI2 is connected through cables to I/O A, I/O C and I/O D ports. The rain gauge is connected to the RTU’s I/O B port. Also, some of the sensors are connected to the PI2 board.

The interface board PI2 will be placed, usually in the mast base. The interface board PI connects the rest of the sensors through cables, the electrovalve which ensures the water intake control in the segment-valve, and also the auxiliary battery of 24 V.

The interface boards PI and PI2 are interconnected through a multicore cable, pulled through a protection tube. The tube and the cable inside must pass through the concrete wall of the segment-valve room and finally to reach the metallic mast.

The parameters that can be monitored and specific sensors at a water intake are presented in Table 1.

Table 1 Monitored parameters and sensors used for water intakes
Full size table

The monitored parameters at the water intake are represented by the flow captured in summer and winter period. For the flow captured in the summer period a probe of water level is used with a range of 0–150 cm, mounted in the tank inside a protection metal tube; in winter period a water level probe with a range of 0–10 m is used, mounted at the dam’s base, with probe reference level under the lower threshold of the winter intake. Other parameters that need to be measured are the water level in the lake at the dam (to measure this parameter, the water level probes mentioned are used), the air temperature (this parameter is reported to the temperature sensor integrated in RTU A723, placed in the dam), rainfall level (to measure this parameter, the standard aluminium rain gauge is used, with a resolution of 0.2 mm, connected to RTU A723).

The parameters resulted by integration (summing) allow the possibility of calculating the water amount (in mc) captured in a given time period. Also, it is possible to find the rainfall amount (in mm = l/mp) captured in a given time period.

Each of the parameters from 1 to 11 in Table 1 is measured by RTU once every 3 min. Every 15 min, RTU will calculate a mean value of the five measurements performed in that interval. Every hour, RTU will send through the bridge RA440 to the Presentation Server the four mean values calculated for each parameter.

RTU will be able to keep the measured parameters for 10 days, in case the communication with the AS is unavailable.

The PS will keep available to users the primary and processed data during 2 years. In case it’s considered useful, the period this data is kept could be longer than 2 years.

4.2 Measurement Results

Figures 4, 5 and 6 present measurement results for the evolution of two of the monitored parameters, considering the water level in a lake in the summer period and the flow captured in the summer period.

Fig. 4
figure 4

Summer operating switchover

Full size image
Fig. 5
figure 5

Deviation of parameters during intense rain

Full size image
Fig. 6
figure 6

Deviation of parameters during water capture interruption

Full size image

PS presents the measured data as a table or in the diagram form. There are multiple possibilities for visualizing the dates in different past periods (from a day to a year), showing the values at a specific date, hour, minute and second. Also, there is the possibility of highlighting the average, the amount, the maximum and minimum registered value for each parameter for periods of time, on user’s demand.

Figure 4 presents the measured parameters on the 15th March 2012, as the water intake was switched to the summer operating system. The water level in the reservoir, at the dam was 1.51 m, and the captured flow had small values, about 2400 m3/h [33].

At the end of May 2012, the level in the reservoir and the captured flow stabled around 1.80 m and 21,000 m3/h. Important deviations were noticed only during intense rain, like the one in 31.05.2012, as seen in Fig. 5.

Because of the extended drought, in September 2012, both the level in lake and the captured flow are stable, unfortunately at low levels (captured flow 2860 m3/h). On 11.09.2012, the water capture process was interrupted for about 8 h, as presented in Fig. 6.

The main challenge posed by the presented application to a M2M cloud implementation was the energy efficiency of the sensors and RTUs, especially during periods when the battery was not charged due to the lack of solar radiation. Consequently, in order to have near-real time relevant results, we improved the system by optimizing the data sampling rate and sending average values as presented in Sect. 4.1. Finally, the results were compared with on-site manual measurements and small adjustments were done so that the measurement results could be compared with similar results [34] existing in the literature. The implementation demonstrated that it performs better than using other sensors such as radars, sonar or infrared and the cloud platform provided elastic resources for storing and processing of the big data volumes, offering advantages such as live migrations compared to traditional approaches.

5 Conclusions and Future Directions

The present paper discussed a number of popular ICT paradigms, including Cloud computing, IoT and Big Data. It provided an extensive state-of-the-art review of them and the convergence between them. Next, the paper analyzed a proposed M2M telemetry system based on a decentralized cloud architecture, general systems and Remote Telemetry Units (RTUs), for renewable energy objectives tele-monitoring. The system was built for Big Data processing of sensors information in the way that data can be aggregated to generate “virtual” sensors, and some measurement results were presented.

With the advent of smart mobile devices, the Internet access has become ubiquitous, and has opened the way for new applications that use M2M communications. Indeed, the Internet of Things paradigm is an evolution of the traditional Internet for seamlessly integrating most things around us and collecting big data from sensors that track everything happening in our environment. IoT is already a reality and is growing, while the way we apply this new concept will drive new applications and may revolutionize life. Future research includes concepts such as flexible, open, and standardized service interfaces—Internet of Services (IoS), people becoming part of ubiquitous intelligent networks having the potential to seamlessly exchange information—Internet of People (IoP), and, finally, the ability to interconnect any web enabled device and provide natural Human-2-Machine (H2M) interaction interfaces—Internet of Everything (IoE).