10.2.1 ARM Mbed

Mbed (Mbed, 2016) IoT platform and operating system (OS) was released by ARM and licensed under Apache 2.0 in 2009. ARM is the company that produces microprocessors for mobile, IoT, wearable systems, automotive, health care, and other markets. Mbed OS is designed for IoT devices and includes the features necessary to develop a connected product based on ARM Cortex‐M microcontroller. Mbed OS is the core of the system and supports sensors and actuators and different communication technologies such as Wi‐Fi and Bluetooth LE. It also has a web‐based development environment. Mbed has its own cloud, named ARM Mbed Cloud. The source code written through web browsers is compiled in the cloud environment. Communication is provided by using CoAP, MQTT, and HTTP/RESTful protocols.

10.2.2 Cumulocity

The term “Cumulocity” is a compound of “Cumulus” (a type of cloud ) and “velocity.” It is Nokia's IoT spin‐off, founded in 2010 in Silicon Valley, California (Cumulocity 2016). Cumulocity GmbH continues development in Düsseldorf, Germany, with the support of Nokia Siemens Networks.

Cumulocity is an application‐centric IoT platform whose functionality is available for public via open APIs. Cumulocity has its own cloud system, and sensor nodes are clients that connect to this system through RESTful, HTTPS, and API. Data collection from devices and their remote management is done through the Cloud Fieldbus application. HTTP(S)/RESTful is the only supported communication protocol in Cumulocity (Derhamy et. al., 2001). It implements OAuth2 protocol for authentication. There is no information about the database system used. On the other hand, it has a system for real‐time data analytics.

10.2.3 DeviceHive

DeviceHive (DeviceHive, 2015) is an open‐source IoT data platform, which was introduced by an IoT research and development company, DataArt, in 2012. It supports the AllJoyn system, which allows devices to communicate with other devices around them. AllJoyn provides cloud connectivity for AllJoyn‐supported devices, and it can be used for as a bridge to connect with third‐party protocols.

DeviceHive is compatible with on‐premise, cloud, hosted, and hybrid systems. It works in public and private clouds: Microsoft Azure, Amazon Web Services, Apache Mesos, and OpenStack. It uses MQTT and HTTP/RESTful protocols for communication. DeviceHive has two authentication protocols: OAuth2 and HTTP basic authentication. It stores data in MongoDB and has support to many data analytics and big data tools such as ElasticSearch, Apache Spark, Cassandra, and Kafka. It supports real‐time and batch processing data analytic solutions.

10.2.4 Digi

Digi Inc. (Digi, 2016), which was founded in 1985, focused on PC boards in the first years. Then the company shifted toward M2M solutions such as satellite communication devices, integrated circuits, and gateways. Digi has started to proceed on its business with Etherios Inc., founded in 2008, and focused on the cloud sector since 2012. Respectively, the iDigi Energy and iDigi Tank platforms were developed for creating smart energy networks and monitoring tank storages. After adding the visualization tools of Thingworx and the cloud capabilities of Etherios, Digi became an advanced IoT platform (Köhler, Wörner, and Wortmann, 2014).

Digi has its own cloud, named Digi Cloud, for device integration and monitoring. It uses the HTTP/RESTful communication protocol and implements HTTP basic authentication protocol. On the other hand, there isn't any information about Digi's database system and data analytic services.

10.2.5 Digital Service Cloud

Digital Service Cloud Open IoT Platform (Digital Service Cloud, 2015) was launched by iYogi, New Delhi, in May 2015. It is built on Microsoft Azure and uses various Azure modules such as Service Bus, Event Hub, DocumentDB, and Machine Learning, for data analytics operations. Digital Service Cloud has more than 12 million connected devices, and it has the highest number of devices among digital service management platforms.

The infrastructure has the HTTP/RESTful communication protocol and OWASP for authentication service. Digital Service Cloud stores collected data in MongoDB and user data in Microsoft SQL Server.

10.2.6 FiWare

FiWare (FIWARE, 2011) is a middleware IoT platform developed by the FiWare community, which is an independent open community that aims to develop smart applications for various areas by constructing sustainable, open, and application‐driven middleware platform standards. It was supported by the European Union Future Internet Public‐Private Partnership (FI‐PPP) project's Framework Programme 7 (FP7) between 2011 and 2014 (COMM 2016). FiWare has its own cloud infrastructure, named FiWare Cloud, which is based on OpenStack. It uses MQTT and HTTP(S)/RESTful protocols for communication and the OAuth2 protocol for authentication. FiWare uses an HDFS‐based system for data storage and has a module named Cosmos for big data analysis. The TrafficHeat project used this module for traffic predictions in FiWare Big Data Hackathon (Santander‐Fiware, 2016).

10.2.7 Global Sensor Networks (GSN)

The Global Sensor Network (GSN, 2016) project is one of the initial projects that have been started in 2004 by Distributed Information Systems Laboratory LSIR at École Polytechnique Fédérale de Lausanne. It's an open‐source platform and is written in the Java programming language (Petrolo, Loscri, and Mitton, 2015). The main aim was to develop a middleware platform for sensor data integration and query processing. Later GSN is supported by other projects and institutions such as the OpenIoT project, the HYDROSYS project, and others. As it is one of the premise projects, it doesn't have any special cloud support and runs the on‐premise principle. While its first version uses HTTP/SOAP and RESTful communication protocols, MQTT and CoAP communication protocols were added in the second version. GSN implements HTTP basic authentication for authentication of users and uses a MySQL database for data storage. Although GSN has a Weka library that enables data analysis and mining operations, no application that predicts sensor observations by using this library was identified.

10.2.8 IoTgo

IoTgo (IoTgo, 2014) is an open‐source IoT platform founded by ITEAD Intelligent Systems Co. Ltd, which is headquartered in Shenzhen, China.

IoTgo is compatible with on‐premise, cloud, hosted, and hybrid systems. WebSocket and HTTP/RESTful are two communication protocols supported by IoTgo. IoTgo implements HTTP basic authentication method for authentication, and MongoDB is used for data storage. No information about data analytics has been found.

10.2.9 Kaa

Kaa (Kaa, 2014) is a middleware open‐source IoT platform that aims to collect information from various sources, and it is licensed under Apache 2.0. Since 2014, the Kaa project is an enterprise of CyberVision, a software company. Kaa has on‐premise, hosted, hybrid, and cloud deployments. It supports MQTT, HTTP(S)/RESTful, CoAP, and XMPP communication protocols and implements the OAuth authentication protocol. MongoDB and Cassandra databases are used for data storage. Collected data could be analyzed employing the Apache Spark extension of the platform. The Kaa project has endpoint SDKs for Java, C, C++, and Objective‐C.

10.2.10 Nimbits

Nimbits (Nimbits, n.d.) is an open‐source PaaS for IoT licensed under Apache 2.0. The Nimbits platform is compatible with Raspberry Pi, J2EE Web Application Servers, Amazon EC2, and the Google App Engine. It supports MQTT, XMPP, and HTTP/RESTful communication protocols and provides authentication by implementing HTTP basic authentication protocol. MySQL database is used to store the data. It provides Java libraries and SDK for development (Mazhelis and Tyrvainen, 2014). There is no information about data analytics and prediction systems in Nimbits.

10.2.11 RealTime.io

RealTime.io (RealTime.io, 2016) is a PaaS of ioBridge for IoT systems. The purpose of ioBridge RealTime.io is easy and cheap connection of products to the Internet and building a bridge between embedded systems and user applications.

RealTime.io has its own cloud system for storage and management. It uses UDP‐based ioDP (Mazhelis and Tyrvainen, 2014) and HTTP/RESTful protocol for communication and HTTP basic authentication for user and device authentication. There is no information about the database system employed and the data analytic tools of RealTime.io.

10.2.12 SensorCloud

SensorCloud (SensorCloud, 2016) is an IoT platform of US‐based LORD MicroStrain corporation. It was introduced by MicroStrain, founded in 1987. In the first years, the company focused on sensors used in biomedical research. MicroStrain released their first inertial product, the 3DM, in 1999. While it was initially thought of as a biomedical product, it was later made compatible with navigation systems, civil engineering projects, and industrial equipment monitoring. In 2001, MicroStrain released the first wireless sensor of the company. Owing to such a background, the company launched SensorCloud that enables to store, fast monitor, and analyze data in 2011. One year later, MicroStrain was acquired by LORD Corporation.

Sensor Cloud provides a cloud platform hosted by Amazon Web Services (AWS). It communicates via the HTTP/RESTful protocol and authenticates users via custom API key and HTTP basic authentication. It stores data in SQL Azure database. SensorCloud provides support to Python, Java, C#, and C++ (Mazhelis and Tyrvainen, 2014). It has also MathEngine, IPython, and Scipy support for data analysis and machine learning operations.

10.2.13 SiteWhere

SiteWhere (SiteWhere, 2009) is an IoT platform launched by SiteWhere LLC in 2009. The platform was initially aimed to be a telecommunications‐processing platform. Then real‐time location data has been integrated. And finally it became a more generalized IoT platform, and it is open‐sourced since June 2013.

SiteWhere is compatible with on‐premise, cloud, hosted, and hybrid systems. It communicates via the MQTT, AMQP, Stomp, and HTTP/RESTful protocols and implements HTTP basic authentication protocol. MongoDB, Apache HBase, and InfluxDB technologies are used for data storage. There isn't any information about predictive analytics usage by the SiteWhere platform.

10.2.14 TempoIQ

TempoIQ (TempoIQ, 2016), is an IoT platform developed with the purpose of providing fast, flexible, and agile device data collection, storage, and monitoring. TempoIQ uses the CODA cloud system for monitoring and controlling devices and data. Its communication protocols are MQTT and HTTP/RESTful. It provides support for C, Java, Python, Ruby and .NET (Mazhelis and Tyrvainen, 2014). TempoIQ stores data in the DataIQ module and has the Analytic Composer for data analysis in the AnalyticIQ module.

10.2.15 Thinger.io

Thinger.io (Thinger.io, 2016) is an IoT platform that has its own cloud infrastructure to connect and manage devices. It uses MQTT and HTTP/RESTful communication protocols. Users/customers can integrate it to their business logic by using REST API. Thinger.io authenticates users and devices by implementing the OAuth2 protocol, and collected data are stored in MongoDB. No information about prediction of device data has been found.

10.2.16 Thingsquare

The development of the Contiki Operating System, which is compatible with low‐power and less memory and suitable for connected devices, led to the foundation of ThingSquare (Thingsquare n.d.). Contiki and its commercial type ThingSquare Mist are released under the BSD license and open source (Köhler, Wörner, and Wortmann, 2014). ThingSquare focuses on mostly the automation, controlling, and monitoring of things via the Internet than integrating applications and analyzing collected data (Derhamy et. al., 2001). ThingSquare has its own cloud for deployment. It uses the HTTP/RESTful communication protocol and HTTP basic authentication method for authentication. ThingSquare has an IDE named “ThingSquare Code,” which enables development of applications for ThingSquare Mist. There isn't any information about its database and data analytics capabilities.

10.2.17 ThingWorx

ThingWorx (ThingWorx, 2016) is an IoT platform that reduces complexity for non‐technical people (Köhler, Wörner, and Wortmann, 2014). It focuses on integration, transformation, and presentation of collected data instead of communication between nodes and collection of data. Four main blocks of ThingWorx were built in 2011. The first block, SQUEAL, enables to search data and devices. The second one, Mashup Builder block, enables application development by “drag and drop.” The third block, Composer, was developed for composition of different data visualizations, storages. and business logics. Finally, the social networks block is used for crowdsourcing (Köhler, Wörner, and Wortmann, 2014). ThingWorx enables on‐premise, hosted, and hybrid deployments (Mazhelis and Tyrvainen, 2014). Besides, it is also compatible with third‐party clouds such as Amazon Web Services and Microsoft Azure. Thingworx uses CoAP, WebSockets, MQTT, and HTTP/RESTful communication protocols (Derhamy et. al., 2001) and implements HTTP basic authentication as authentication protocol. It stores model data in Apache Casandra, supports Neo4j graph database, and has a module named ThingWorx Analytics for data analytics.

10.2.18 VITAL

The VITAL (Virtualized programmable InTerfAces for smart, secure, and cost‐effective IoT depLoyments in smart cities; VITAL, 2016) platform aims to integrate inter‐connected objects (ICOs) among multiple IoT platforms. The detailed description of the platform will be given in the following sections.

10.2.19 Xively

Xively (Xively, 2016) is another a PaaS platform that enables real‐time communication, device monitoring, and data storage and distribution (Mazhelis and Tyrvainen, 2014). It was initially developed in 2007 to connect things to things and was named Pachube. In 2011 it was widely used in Japan to monitor radioactive fallout across the country after the nuclear accident in Fukushima. Then in the same year it was acquired by LogMeln and renamed Cosm. Later on in 2013, it was renamed Xively (Köhler, Wörner and Wortmann, 2014). Xively supports MQTT, HTTP(S)/RESTful, and WebSocket communication protocols, and it has its own public cloud. HTTP basic authentication protocol and OAuth2 are the two supported protocols to authenticate users. Xively uses Blueprint database and has libraries for Python, Ruby, and Java. It doesn't have any sensor data prediction support.

It could be summarized that most of the IoT middleware platforms only provide monitoring, controlling and planning of sources/sensors for the moment. However, it should be kept in mind that the services/applications supporting prediction are becoming very important in order to manage, plan, and prepare cities to the future.

10.3.1 The VITAL IoT Platform

The VITAL (Virtualized programmable InTerfAces for smart, secure, and cost‐effective IoT depLoyments in smart cities) platform aims to integrate inter‐connected objects (ICOs) among multiple IoT platforms (Petrolo, Loscri and Mitton, 2015), as previously explained. The management and access of heterogeneous objects are achieved with virtualization of interfaces. The VITAL architecture is given in Figure 10.1. As shown in the figure, the data and service access to VITAL are implemented using VUIAs (virtualized universal access interfaces), which makes VITAL platform‐agnostic. The VUIA layer has several connectors enabled to communicate different IoT platforms and clouds. VITAL integrates heterogeneous data and functionalities of different sensors in a platform‐agnostic way with the help of linked data standards. Different sensor clouds are deployed to the VITAL platform via the platform provider interface (PPI). In order to model different IoT systems, the VITAL consortium selected four platforms, namely, X‐GSN, Xively, Hi Reply, andFIT IoT Lab. On the top of the VITAL core platform there is a security module to authenticate all users. Sensor observations are stored and managed via the data management services (DMS) module, and MongoDB is used as database. Detailed description about the VITAL platform can be found in Petrolo, Loscri and Mitton (2015) and VITAL (2016).

10.3.2 VITAL Prediction Module

Generally, most of the collected data in city data repositories can be considered as time series; hence, time series analysis (Gulacar, Yaslan and Oktug, 2016) or interpolation techniques are used (Dobre and Xhafa, 2014) for analysing them. On the other hand, one can also obtain feature vectors from sensor observations, and depending to the application domain, successful machine learning algorithms can be applied for classification, clustering, and regression applications. In order to predict sensor observations, regression algorithms can be used, where the aim is to find a continuous function between a dependent variable and one or more independent variables (Pan et al., 2013). Besides, regression relies on a loss function, which is generally the difference between the predicted value and the actual value to learn the best function, the one with least error. In this subsection, we will use the most common and successful regression models, such as support vector regression, regression trees, etc., for traffic sensor data prediction in Istanbul (Gulacar, Yaslan, and Oktug, 2016). We consider various representations of the feature vectors and their effects on performance as well.

The prediction module explained is an extension to the VITAL platform architecture given in Figure 10.1. The VITAL platform easily enables to extend services when the security issues are implemented. The extended prediction module and its VITAL integration are shown in Figure 10.2. As shown in the figure, the prediction module communicates with the VITAL security module and observes data via DMS and has core components that are listed below:

Prediction module components:

1. VITAL security module: Determines whether an access token is valid or not.
2. VITAL DMS: Stores sensor observations, lists, etc.
3. Service.war: Gets, controls, and responds to client requests.
4. Database: Stores prediction results in MongoDB.
5. Train.jar: Trains data in order to produce regression models and saves models. It is scheduled as working once every week.
6. Models: Folder that includes all models created after training.
7. Predict.jar: Gets data and makes prediction by using pickle. It is scheduled as working once every 15 minutes.

Communication between components (edges):

1. Training data request: Send request DMS in order to get sensor observations for training.
2. Training data response: Get sensor observations from DMS.
3. Save model: Regression models created in training phase are saved into Models folder in order to reuse by Predict.jar.
4. Weekly prediction results: Train.jar creates regression models. Additionally, it predicts weekly (long‐term) data and inserts into database.
5. Observation request: Send request to DMS in order to get sensor observations.
6. Observation response: DMS response that includes sensor observations.
7. Get Model: Gets regression models for prediction.
8. Insert prediction results: Insert prediction results to database.
9. Client Request: Client must send request whose header includes vitalAccessToken and body includes the following item(s):
   1. city: Shows which PPI's prediction results are requested.
   2. sensor^*: List of sensors' id.
   3. property^*: List of observation property or properties.
   4. gt^*: Lower bound of time interval.
   5. lt^*: Upper bound of time interval.
10. Security request: Server.war sends request to VITAL/securitywrapper in order to determine whether vitalAccessToken is valid or not.
11. Security response: VITAL/securitywrapper response whether vitalAccessToken is valid or not.
12. Related prediction results: Asks prediction results from database according to user query.
13. Prediction response: Prediction response is a list of nodes including the following items:
    1. city: PPI name
    2. sensor: sensor ID
    3. property: observation property
    4. value: predicted observation value
    5. prediction_time: shows when the module predicted that value
    6. minute_later: shows which prediction time mode (15 min., 30 min. ahead, or long‐term(999))
    7. predicted_time: shows for which time the module predicted that value.

In order to observe prediction results from the VITAL platform, one needs to implement the post method given in Table 10.2.

10.4.1 Prediction Techniques Employed

In our previous work (Gulacar, Yaslan, and Oktug, 2016), we studied in detail the effects of using different feature vectors and clustering and regression methods on traffic speed prediction results. We determined that while the weather feature does not increase the prediction performance beyond our expectations, binary record time vectors increased the accuracy. Therefore, in this work we applied prediction methods on feature space that include previous speed observations and binary record time vectors. We also did extensive analysis on the data set employed. We showed that the observations of sensors at time t are strongly correlated with the observations of their neighbor sensors at time t – 30, as shown in Figure 10.4. In this experiment we aimed to find whether there is a relationship between the average values of sensor observations. Mostly, neighbouring sensors have relationship with the next sensor after 30 min. Thus this speed information is added as an extra feature in our predictions. Additionally, we analyzed the effect of adding neighbor sensor observation(s) to the feature vectors.

In this work, the clustering step is neglected since the module is compatible with a real IoT platform VITAL. While new sensors and/or PPIs can be added to the platform, determining a cluster is an extra burden for the platform. Besides, there is no significant differences between success of using clustering methods.

In the rest of this section, firstly, we describe data preprocessing operations. Then, constructions of feature vectors and normalization steps are described. Later, we describe training and test partitioning, and evaluation metrics are given. Finally, we give the applied regression methods and experimental results.

10.4.1.2 Feature Vectors

Let represent the speed of i‐th sensor at time .; in order to predict we construct the following feature vector for regression:

where:

• +: vector concatenation operator,
• : speed of i‐th sensor at time x,
• : returns vector that includes speeds of sensor(s) that is/are neighbour(s) of at time t. For example,
• returns
• ,
• : returns 7‐bit binary vector that represents day‐of‐week value of time x. For example, returns ,
• : returns 24‐bit binary vector that represents hour‐of‐day value of time x. For example, returns a 24‐bit binary vector containing zeros except the leftmost 14‐th bit,
• : returns 4‐bit binary vector that represents 15 min. time slice of hour value of time x. For example, returns .

After constructing the feature vectors, non‐binary features are normalized by using z‐score normalization. These feature extraction and model training and testing phases are given in Figure 10.5.

10.4.2 Results

Our experimental prediction results are obtained using various regression algorithms, namely: AdaBoost.R2 regressor (ADA; Solomatine and Shrestha, 2004), decision tree regressor (DTR; Breiman, Friedman, and Stone, 1984), Gradient boosting regressor (GBR; Friedman, 2002), K‐nearest neighbors regressor (KNN; Altman, 1992), kernel ridge regressor (KRR; Schölkopf, Luo, and Vovk, 2013), random forest regressor (RFR; Breiman, 2001) and support vector regressor with RBF kernel (SVR; Vapnik, 1995).

Adaboost regressor is an ensemble model and starts with fitting a model on the initial data set. Then, based on the error on the data set, it updates the selection probability of the samples and trains new prediction models on difficult examples.

Decision tree regressor is a hierarchical model that partitions the features based on a split measure such as mean square error. Decision trees are simple to interpret and handle both numerical and categorical variables.

Gradient boosting regressor is an ensemble model where several weak learners are learned on the residual of the previous models.

K‐nearest neighbors regressor estimates the target value of a data sample by calculating the average target values of the K nearest neighbors.

Kernel ridge regressor uses the least squares regression algorithm with regularization and applies Kernels functions.

Random forest regressor trains a number of decision tree regressors on various subsamples of the data set and combines their outputs to find the final result.

Support vector regressor is the generalization of support vector machines for regression problems. It aims to minimize the ɛ‐sensitive errors on the training set. Generally, a nonlinear kernel function is used to project initial data into a higher‐dimensional space.

Each regression algorithm is trained on a two‐month training set and evaluated on the upcoming test month using the aforementioned feature vectors. The training sets and test sets that are obtained using a sliding window is given in Figure 10.6.

Experimental results are evaluated using root mean square error (RMSE):

(10.1)