An IoT service ecosystem for Smart Cities: The #SmartME project

Accepted Manuscript

An IoT service ecosystem for Smart Cities: the #SmartME project Dario Bruneo, Salvatore Distefano, Maurizio Giacobbe, Antonino Longo Minnolo, Francesco Longo, Giovanni Merlino, Davide Mulfari, Alfonso Panarello, Giuseppe Patane, ` Antonio Puliafito, Carlo Puliafito, Nachiket Tapas PII: DOI: Reference:

S2542-6605(18)30100-8 https://doi.org/10.1016/j.iot.2018.11.004 IOT 29

To appear in:

Internet of Things

Received date: Revised date: Accepted date:

10 October 2018 22 November 2018 23 November 2018

Please cite this article as: Dario Bruneo, Salvatore Distefano, Maurizio Giacobbe, Antonino Longo Minnolo, Francesco Longo, Giovanni Merlino, Davide Mulfari, Alfonso Panarello, Giuseppe Patane, Antonio Puliafito, Carlo Puliafito, Nachiket Tapas, An IoT service ` ecosystem for Smart Cities: the #SmartME project, Internet of Things (2018), doi: https://doi.org/10.1016/j.iot.2018.11.004

This is a PDF file of an unedited manuscript that has been accepted for publication. As a service to our customers we are providing this early version of the manuscript. The manuscript will undergo copyediting, typesetting, and review of the resulting proof before it is published in its final form. Please note that during the production process errors may be discovered which could affect the content, and all legal disclaimers that apply to the journal pertain.

ACCEPTED MANUSCRIPT

An IoT service ecosystem for Smart Cities: the #SmartME project

a Universit` a

CR IP T

Dario Bruneoa , Salvatore Distefanoa,b , Maurizio Giacobbea , Antonino Longo Minnoloa , Francesco Longoa , Giovanni Merlinoa , Davide Mulfarid,a , Alfonso Panarelloa , Giuseppe Patan`ec , Antonio Puliafitoa , Carlo Puliafitoe,d , Nachiket Tapasa degli Studi di Messina, 98166 Messina, Italy Federal University, Russia c Park Smart Srl, Italy d University of Pisa, Italy e University of Florence, Italy

AN US

b Kazan

Abstract

#SmartME has been one of the first initiatives in Italy to realize a Smart City through the use of open technologies. Thanks to the use of low cost sensor-

M

powered devices scattered over the city area, different “smart” services have been deployed having the Stack4Things framework as the common underlying middleware. In this paper, we present the results obtained after 2 years of project

ED

highlighting the vertical solutions that have been proposed in different areas ranging from environmental monitoring to parking management. Keywords: IoT; Cloud computing; Smart City; Blockchain; OpenStack;

PT

Arduino.

CE

1. Introduction and Motivation The urbanization process is aggregating large populations of people into ever-

AC

growing metropolitan areas, raising up the scale of problems such as traffic and

Email addresses: [email protected] (Dario Bruneo), [email protected], [email protected] (Salvatore Distefano), [email protected] (Maurizio Giacobbe), [email protected] (Antonino Longo Minnolo), [email protected] (Francesco Longo ), [email protected] (Giovanni Merlino), [email protected], [email protected] (Davide Mulfari), [email protected] (Alfonso Panarello), [email protected] (Giuseppe Patan` e), [email protected] (Antonio Puliafito), [email protected] (Carlo Puliafito), [email protected] (Nachiket Tapas)

Preprint submitted to Internet of Things Journal

November 29, 2018

ACCEPTED MANUSCRIPT

mobility, pollution, utility, waste and safety management, among others. To deal 5

with these issues, new information and communication technologies (ICT) and solutions coming from the Internet of Things (IoT), Edge and Cloud computing,

CR IP T

Big Data, to name a few, are brought together to fulfill the vision of Smart Cities. This way, modern cities are becoming mixes, jumbles of more or less technological

objects, mostly Internet connected and sometimes even smart, but not yet enough 10

to establish an interoperable infrastructure. Indeed, a Smart City is something

more than just a bunch of Internet-connected objects, as it “brings together technology, government and society to enable the following characteristics: a

AN US

smart economy, smart mobility, a smart environment, smart people, smart living,

smart governance”1 . Projecting this definition in the technological context, 15

a Smart City can be thus considered as an ecosystem of infrastructure and services aiming at implementing the aforementioned characteristics. This holistic view calls for an all-encompassing approach able to embrace the aforementioned heterogeneous technologies and services, thus providing a wider (or even a

20

M

global) solution to (Smart) city problems. In this light, there is the need for a scalable architecture aiming at reusing, multiplexing, and sharing technologies

ED

and services on the urban scale.

The goal of this paper is therefore to establish an homogeneous ecosystem where multiple applications can scale out to a metropolitan range, thus under-

25

PT

pinning an open shared ICT infrastructure made of sensing, actuation, network, processing, and storage resources. As above discussed, this requires to deal with

CE

different technologies and solutions, such as IoT, Cloud, Fog, Edge computing, Big Data, intelligent systems and machine learning, to name a few, thus calling for specific mechanisms, tools and framework able to manage the Smart City

AC

ecosystem.

30

Following a learning-by-example approach, we discuss the proposed solution

by a case study we are implementing in Messina through the #SmartME project2 . 1 http://smartcities.ieee.org/about.html 2 http://smartme.unime.it/

2

ACCEPTED MANUSCRIPT

This was born from a joint idea between a team of researchers in the University of Messina and the municipality of Messina in order to spur the creation of a novel, virtual ecosystem in its urban area, also involving several companies in the nearby area, among which SmartME.io, a University of Messina spin-off active in

CR IP T

35

the development of IoT and Cloud-based solutions that now is mainly driving this project. The main goal of the #SmartME project is to establish an infrastructure

and an ecosystem of services also exploiting the already-in-place devices, sensors, and actuators available in the area of Messina. This way, we shifted the burden 40

to the software side, adopting a specific framework, Stack4Things, able to

AN US

solve interoperability, networking, security, and other issues. One of the main

benefits of the proposed framework is programmability: anyone, if authorized, can inject and run own applications and services, exploiting the same Smart City infrastructure, which is therefore shared by several applications and services, 45

even at the same time running in parallel. Based on this middleware, the solution we propose comes with a 4-layer stack from infrastructure to application. The

M

main advantage of this approach is that it can be replicated into any Smart City context, thus paving the way to low-cost, reusable and flexible Smart Cities.

50

ED

The rest of the paper is organized as follows: in Section 2 our view of the Smart City ecosystem is explained in details, including the reference stacked architecture driving next sections descriptions. Thus, Section 3 deals with

PT

the Smart City ecosystem infrastructure and middleware, Section 4 with the management platform, and Section 5 describes some applications and services

CE

implemented in Messina by the #SmartME project. Some final remarks and 55

considerations in Section 6 close the paper.

AC

2. The Smart City Ecosystem A Smart City can be considered as an ecosystem or, more precisely, as a

Cyber-Physical Social System [1] including sensors, actuators, devices, related data and information, applications and services, as well as policies, rules, laws,

60

and citizens. Figure 1 summarizes this system view into a well known and widely

3

ACCEPTED MANUSCRIPT

adopted 4-layer model [2]. At the bottom, the foundation of a Smart City is

Application Management

AN US

Infrastructure

CR IP T

Smart City

Stakeholder

Figure 1: A 4-layer model for Smart Cities.

the Infrastructure composed of the sensors and actuators in the urban area, including both private and public devices such as: smart cameras, air pollution and weather stations, traffic lights, lamp posts, bus GPS, and citizens’ mobile devices. Furthermore, network resources and related issues have to be considered

M

65

in the infrastructure layer, as well as storage and processing facilities able to

ED

collect, manage and process data. This complex infrastructure has to be properly managed, and this layer has to provide basic, core mechanisms for enabling the Smart City infrastructure, granting access to all the available resources to an as wide as possible population of users/citizens. Therefore, a software framework, a

PT

70

middleware able to establish such an ecosystem of IoT devices, dealing with the heterogeneity of nodes, networking and similar “low level” issues, is mandatory

CE

to implement a urban scale infrastructure. On top of this, the Management layer provides platform-advanced features

based on and extending the infrastructure core mechanisms. These may include

AC

75

security, privacy, Authentication Authorization Accounting (AAA), data management, monitoring, profiling, Service Level Agreement (SLA) and Quality of Service (QoS) mechanisms and policies, placement and orchestration strategies, incentive mechanisms, credit-reward systems, and so on.

80

The Application layer provides Smart City applications and services in 4

ACCEPTED MANUSCRIPT

contexts such as: energy, e-health, mobility, waste, public safety, water, and mobility building management, to name a few. Finally, the Stakeholder layer includes all the possible entities involved in a Smart city (e.g., the municipality,

85

CR IP T

citizens, enterprises, telecommunication operators, medical doctors, officers, and vehicles).

The above 4-layer model is adopted within several Smart City projects that integrate the IoT and Cloud computing. One of these solutions is the

ALMANAC Smart City Platform [3], which was developed in the context of the ALMANAC FP7 EU project. This platform employs technologies such

as: Node.js, Java, OSGi, and C#. Another Smart City solution is iSapiens

AN US

90

[4]. This integrates IoT and Cloud computing, but it also introduces a further computational layer, i.e., the Edge computing layer. As such, besides the Cloud, it employes computing nodes deployed at the network edge (i.e., generally onehop away from data producers and consumers) in order to enable a set of 95

advantages that are not possible when relying only on the distant Cloud. For

M

instance, proximity of edge nodes allows reduced latencies, a better utilization of network resources, and improved privacy and security. Last but not least,

ED

PortoLivingLab [5] is a Smart City solution deployed in the city of Porto, Portugal. It is specifically aimed at monitoring weather conditions, environmental 100

parameters (i.e., air quality and noise), and mobility of people and public

PT

transports. An interesting survey on IoT-based Smart Cities can be found in [6]. All the above Smart City projects and solutions aspire to data and device

CE

interoperability, which is a fundamental feature for Smart Cities. Indeed, Smart Cities are complex ecosystems that, by nature, integrate diverse vertical domains

105

(e.g., transportation, industrial automation, healthcare, education, tourism) with

AC

one another in a unique environment. Therefore, ”knowledge silos” are to be avoided, and, on the contrary, data need to be exchanged in an open fashion among different services and stakeholders and jointly analysed in order to extract

value-added information and trigger smarter actions [7]. Verticality is instead

110

still present in all the above solutions in terms of resource utilization. More precisely, each of those projects plans to leverage dedicated IoT devices for each 5

ACCEPTED MANUSCRIPT

service so that a sensor/actuator node that is used e.g., for waste management cannot be also used e.g., for environmental monitoring. This is the main aspect for which the #SmartME project [8] distinguishes itself from the existing solutions. As such, it enables both data and device

CR IP T

115

interoperability but also allows to use the same IoT resources for the most diverse Smart City services and applications. Going into detail, #SmartME is a

crowd-funded initiative aiming at transforming the city of Messina, Italy, into a Smart City [9]. The main goal of the project is to disseminate IoT resources 120

throughout the territory of the Messina municipality, thus creating an ubiquitous

AN US

sensing and actuation infrastructure and a virtual laboratory to which multiple

stakeholders can contribute with their own resources and on top of which they can develop applications and services for research, business, and administrative activities.

As a result, one of the main contributions and novelties of the #SmartME

125

project is to establish a new, crowd-sourced and shared/contributed form of

M

Smart City where anybody, from citizens to public administrations, from shops and businesses to private buildings, can share their hardware facilities to build

130

ED

up the contributed infrastructure. All this should be properly managed by a specific framework which allows contributors to share their resources, and application developers and users to use them. Within the #SmartME project,

PT

such a framework is Stack4Things 3 , which allows to remotely enroll and manage IoT resources altogether, as a whole, also providing customization facilities and

CE

fruition modes for their actual exploitation, on a Cloud provisioning model. 135

This way, several services have been developed exploiting this crowd-sourced Smart City involving several stakeholders into the #SmartME project as better

AC

described in the following sections. Moreover, thanks to the middleware-based, service-oriented approach the au-

thors envisioned with Stack4Things, which provides homogeneous, API-based ac-

140

cess to physical resources, and virtualized ones as well, interoperability is ensured 3 http://stack4things.unime.it

6

ACCEPTED MANUSCRIPT

at the IoT device level. Most verticals can thus be approached with a devicecentric perspective, thus enabling a more natural, horizontal, infrastructure-level integration.

145

CR IP T

Indeed, even legacy distributed applications may run on top of IoT infrastructure managed by Stack4Things, as the latter can establish transparent (e.g., overlay) private networks among nodes across Wide-Area Networks, and orchestrate their deployment and execution at any time.

3. Infrastructure

M

AN US

3.1. Devices

ED

Figure 2: A typical #SmartME node.

The #SmartME infrastructure is composed of a set of devices that provide

150

PT

sensor and/or actuator facilities. Figure 2 reports the composition of a typical #SmartME node. The Arduino YUN is a Single-Board Computer powered by an

CE

Atmel ATmega32u4 micro-controller and the Atheros AR9331 System-on-a-Chip. The Atheros MIPS processor runs Linino OS, a Linux distribution based on

155

an Arduino-enabled “flavor” of OpenWrt supporting microcontroller-exposed

AC

interfaces to General Purpose I/O (GPIO) pins. The board has built-in Ethernet and WiFi support, a USB-A port, micro-SD card slot, 20 digital I/O pins (of

which 7 can be used as PWM outputs and 12 as analog inputs), a 16 MHz crystal oscillator, a micro USB connection, an ICSP header, and 3 reset buttons. This

160

way existing legacy systems and devices can be connected to the #SmartME infrastructure through a Yun board exploiting GPIO pins. 7

ACCEPTED MANUSCRIPT

Method

URL

Semantics

Parameters

Return Type

1

GET

/v0.1/nodes

List nodes

-

Nodes

2

POST

/v0.1/nodes

Add a node

Node

DetailedNode

3

PUT

/v0.1/nodes/{node uuid}

Update a node

Node

DetailedNode

4

DELETE

/v0.1/nodes/{node uuid}

Delete a node

-

-

5

GET

/v0.1/nodes/{node uuid}

Show node details

-

DetailedNode

CR IP T

#

Table 1: Stack4Things IoTronic node management RESTful APIs.

The #SmartME YUN board has been equipped with a Tinkerkit Shield hosting a set of low-cost sensors. Specifically, a Tinkerkit thermistore, Ldr, and

Mpl3115 have been installed as temperature, brightness, and pressure sensor, respectively. A Groove MQ9 is used as gas sensor to obtain information about

AN US

165

air quality. In particular, CO levels are captured as an indication of air pollution. A Honeywell HIH-4030 has been chosen as humidity sensor, while an Arduino KY38 captures the environmental noise level.

3.2. The smart city infrastructure middleware: Stack4Things

The heart and soul of the #SmartME project is the Stack4Things frame-

M

170

work [10]. Stack4Things enables Cloud-mediated interactions with droves of sensor- and actuator-hosting nodes regardless of their geographical position or

ED

their networking configuration, implementing the Software-Defined City (SDC) vision [11]. The framework is based on a mixture of relevant technologies, frame175

works, and protocols. On the node side, the Stack4Things lightning-rod interacts

PT

with sensing and actuation resources representing the point of contact with the Cloud infrastructure and allowing end users to manage the board resources even

CE

if they are behind a NAT or a strict firewall. This is ensured by a WAMP and WebSocket-based communication between the Stack4Things lightning-rod

180

and its Cloud counterpart, namely the Stack4Things IoTronic service. The

AC

Stack4Things IoTronic service is implemented as an OpenStack service providing end users with the possibility to manage one or more nodes, remotely. This can happen both via a command-line based client, namely Stack4Things command

line client, and a Web browser though a set of REST APIs provided by the

185

Stack4Things IoTronic service. The Stack4Things IoTronic service comprises a

8

ACCEPTED MANUSCRIPT

set of agents. Among others, the IoTronic registration agent deals with node registration to the Cloud while the IoTronic command agent deals with node management and command delivering.

190

CR IP T

The I/Ocloud [12] approach and the OpenStack-based implementation naturally lend themselves to support IoT infrastructure to integrate with Cloudprovided resources (e.g., VMs), as both IoT and server-class infrastructure are

leveraged, abstracted, virtualized and ultimately exposed in a homogeneous

fashion through standardized APIs. At the same time, the Stack4Things-unique

IoTronic subsystem is meant to specifically tackling Fog-unique challenges for IoT/Cloud integration, i.e., WAN coverage.

AN US

195

Details of the Stack4Things architecture have been presented in [10, 13]. Here, we describe the Stack4Things features that are mostly exploited in the context of the #SmartME project, namely node presence and management and node contextualization through plugins injection. 3.2.1. Node management and presence

M

200

Table 1 illustrates the main Stack4Things IoTronic RESTful API calls related

ED

to node management. When the SDC administrator needs to add a node to the system, he/she has to issue the call identified as #2, providing a Node object in the body of the request. An example of such a type of object is reported in Listing 1.

PT

205

Specifically, it contains a human-readable name for the node, a code provided by the manufacturer which is used for the first registration of the node to

CE

the Cloud, the kind of device, a flag identifying the node as mobile or not, a location, and some extra parameters if required. If the procedure is successful, a DetailedNode object is returned as a response containing, among other fields,

AC

210

a universally unique identifier (uuid) specifically generated for the node. An example of such a type of object is reported in Listing 2. As soon as the node has been added to the system, it can be configured for

the registration to the Cloud. On the node side, the first configuration is minimal: 215

the only information that needs to be specified in the lightining-rod configuration 9

ACCEPTED MANUSCRIPT

Listing 1: Example of Node JSON object. {

CR IP T

”name” : ” my node ” , ” code ” : ”00112233” , ” d e v i c e ” : ” a r d u i n o −yun ” , ” mobile ” :

False ,

” location ” : { ” l a t i t u d e ” : ”38.19642” , ” longitude ” : ”15.56287” , ” a l t i t u d e ” : ”19” , ” extra ” :

AN US

}, []

}

{ ”name” : ” my node ” ,

M

Listing 2: Example of DetailedNode JSON object.

ED

” code ” : ”00112233” ,

” d e v i c e ” : ” a r d u i n o −yun ” ,

” c r e a t e d a t ” : ”2016−03−08T10 : 04 : 32+00 : 00” , ” s t a t u s ” : ”DISCONNECTED” , null ,

PT

” updated at ” :

” u u i d ” : ” ecc0dddd −7687−415c−b0c8−f 9 a 4 5 e 4 2 3 7 a 8 ” , ” s e s s i o n ” : ”” , ” mobile ” :

False ,

CE

” location ” :

{

” l a t i t u d e ” : ”38.19642” ,

AC

” longitude ” : ”15.56287” , ” a l t i t u d e ” : ”19” , ” updated at ” :

null ,

}, ” extra ” :

[]

}

10

ACCEPTED MANUSCRIPT

file is the WAMP endpoint of the IoTronic registration agent and the registration code. At the very first registration, the lightining-rod issues a specific WAMP RPC call exposed by the IoTronic registration agent providing the code as an

220

CR IP T

identifier. The agent is then able to verify if the node has been previously added to the system. If not, the node is rejected and the lightining-rod keeps trying to register following an exponential backoff algorithm. If the node has been

previously added to the system, the IoTronic registration agent accepts the node, updating its status as connected and storing the corresponding WAMP session

identifier. Moreover, it provides the node with a configuration file including, among other information, the endpoint of the IoTronic command agent, to which

AN US

225

the lightining-rod needs to connect to receive future commands from the Cloud, and the node uuid that the lightining-rod will use in future registration. Indeed, nodes can disconnect from the infrastructure for multiple reasons, e.g., temporary lack of network connectivity or power. However, node presence is 230

an important prerequisite for a reliable management. For such a reason, as soon

M

as a node disconnects, the corresponding IoTronic command agent is able to detect the situation updating the node status and identifying it as disconnected.

ED

In order to obtain a list of the nodes currently registered to the system, the SDC infrastructure administrator can issue the call identified as #1 in Table 1. The 235

call provides as a response a Nodes object, i.e., a JSON array containing a Node

PT

object for each node. The other API calls can be used to update or delete a node and to show detailed information about it, including connection status and

CE

location.

More in general, with regard to the aforementioned API, as well as those

240

discussed in the next sections, the IoTronic API is expected to grow in the

AC

direction of higher compliance with OpenStack guidelines and best practices going forward, including trimming down the interfaces related to functionalities

which are planned to be fully delegated to their natural OpenStack subsystem, as integration with other OpenStack projects (i.e., Zun, Qinling, Barbican,

245

Placement API, etc.) becomes deeper.

11

ACCEPTED MANUSCRIPT

3.2.2. Node Contextualization Method

URL

Semantics

Parameters

Return Type

1

GET

/v0.1/plugins

List plugins

-

Plugins

2

POST

/v0.1/plugins

Register a plugin

Plugin

DetailedPlugin

3

PUT

/v0.1/plugins/{p uuid}

Update a plugin

Plugin

DetailedPlugin

4

DELETE

/v0.1/plugins/{p uuid}

Unregister a plugin

-

-

5

GET

/v0.1/plugins/{p uuid}

Show plugin details

-

DetailedPlugin

6

GET

/v0.1/nodes/{n uuid}/plugins/

List plugins in a node

-

Plugins

7

POST

/v0.1/nodes/{n uuid}/plugins/{p uuid}

Inject a plugin in a node

-

-

8

DELETE

/v0.1/nodes/{n uuid}/plugins/{p uuid}

Delete a plugin

-

-

9

PUT

/v0.1/nodes/{n uuid}/plugins/{p uuid}/st/

Run or stop a plugin

PluginParams

PluginStatus

10

GET

/v0.1/nodes/{n uuid}/plugins/{p uuid}/st/

Get the status of a plugin

-

PluginStatus

11

GET

/v0.1/nodes/{n uuid}/plugins/{p uuid}

Invoke a plugin in a node

PluginParams

PluginResponse

CR IP T

#

AN US

Table 2: Stack4Things IoTronic plugin management RESTful APIs.

Here we define contextualization the Cloud-enabled injection of custom code on any node at runtime under the guise of independent pluggable modules. In other words, contextualization represents a way to adapt the behavior of the 250

node under consideration to the task at hand. We chose Node.js4 as the reference runtime environment.

M

Plugins are managed by the lightining-rod through a default wrapper that allows them to be isolated (as separated processes) and to control their lifecycle.

255

ED

A plugin management library allows the developer to write his/her own plugins in the form of Node.js modules. At the time being, two main kinds of plugins are available in the system: synchronous and asynchronous ones. Synchronous

PT

plugins are characterized by a short execution time and can provide a result to the user (in the form of a JSON object). Asynchronous plugins are long-running

CE

pieces of code that can be executed on a node and do not provide any result. 260

Both the kinds of plugins can take as input a JSON object. Contextualization and plugin management are also exploited to enrich the lightining-rod with

AC

system-wide functionalities. For example, the node-side virtual networking subsystem described in [13] is implemented through a set of plugins.

265

Table 2 reports the main Stack4Things IoTronic RESTful API calls related

to plugin management. First of all, the developer needs to register a plugin 4 See

https://nodejs.org/

12

ACCEPTED MANUSCRIPT

Listing 3: Example of Plugin JSON object. { ”name” : ” h e l l o p l u g i n ” , e x p o r t s . main = f u n c t i o n ( p a r a m e t e r s ,

callback ){

( p a r a m e t e r s . name == u n d e f i n e d ) {

if

CR IP T

” code ” : {

v a r e r r o r = { ” e r r o r ” : ”You need t o p r o v i d e a name ! ” } ; callback ( error ,

null ) ;

}

else{

v a r r e s u l t = { ” message ” : ” H e l l o ” + p a r a m e t e r s . name + ”!” } ;

},

}

}

” parameters ” : { ”name” : ””

M

}

}

result ) ;

AN US

callback ( null ,

on the Stack4Things Cloud providing a Plugin JSON object containing the

ED

plugin name, the plugin code, and a schema describing the structure of the PluginParams JSON object that can be passed to the plugin when it is activated. An example of Plugin JSON object is reported in Listing 3. It implements a synchronous plugin taking a name as input and providing an hello message

PT

270

as output. Also in this case, if the procedure is successful, a DetailedPlugin

CE

object is returned as a response containing, among other fields, a universally unique identifier (uuid) specifically generated for the plugin. Once the plugin has been registered on the Cloud, it can be deployed (in-

jected) in one or more nodes of interest. The corresponding call is the one

AC

275

identified in Table 2 as #7. When this call is issued, the lightining-rod of the involved node is invoked and the Plugin JSON object is serialized and sent through a specific WAMP RPC. Then, the plugin is loaded and ready to be invoked by using either call #9 or call #11, depending on the kind of plugin

13

ACCEPTED MANUSCRIPT

Listing 4: Example of PluginResponse JSON object. {

” p l u g i n ” : ”5730 a 2 f d−f 8 3 2 −42 f 6 −9795− e c e e 3 f 7 b 8 e e 1 ” , ” node ” : ” ecc0dddd −7687−415c−b0c8−f 9 a 4 5 e 4 2 3 7 a 8 ” , ” invocation parameters ” : { ”name” : ” F r a n c e s c o ” },

” result ”: { ” message ” : ” H e l l o F r a n c e s c o ! ”

280

AN US

}

}

CR IP T

” i n v o c a t e d a t ” : ”2016−03−08T11 : 05 : 45+00 : 00” ,

(asynchronous or synchronous, respectively). When such calls are issued, the input PluginParams JSON object is compared with the parameters field in the Plugin JSON object of the involved plugin and if there is a mismatch an error is reported. Otherwise, the PluginParams JSON object is passed to the lightining-rod through a specific WAMP RPC call and the plugin is launched. Call #11 returns the PluginResponse JSON object containing the result of

M

285

the plugin invocation, while call #9 only returns a PluginStatus indicating if

ED

the plugin has been correctly launched or not. An example of PluginResponse JSON object related to the hello plugin reported above is reported in Listing 4.

PT

3.2.3. Providing Stack4Things Services in Wide Area Networks Smart City applications need to wireless connect battery operated things

290

CE

to the Internet through regional, national or global networks. Moreover, an IoT-oriented infrastructure has to take into account the IoT requirements, for example in terms of bi-directional communication, end-to-end security, tracking

AC

and localization services, etc. To this end, Stack4Things has been enabled to

295

follow the LoRa specification for Wide Area Network (LoRaWAN) by the LoRa

Alliance5 A part the above-mentioned necessities, our choice is motivated because the LoRaWAN specification defines the device-to-infrastructure physical layer 5 https://lora-alliance.org,

last accessed 25/09/2018.

14

ACCEPTED MANUSCRIPT

parameters and the technical implementation without to bind the platform to the type of deployment (i.e., if it is public, private, shared, or enterprise/business). 300

The result is the freedom in to innovate the platform and it can be used as

CR IP T

ecosystem where to grow heterogeneous apps allowing to differentiate how the platform can be used.

Typical LoRaWAN network architecture is deployed in a star-of-stars configuration in which “gateway” nodes relay messages between the IoT end-nodes and 305

a central network server via standard IP connections. The LoRaWAN baud rates

range from 0.3 kbps to 50 kbps. Security is provided by using AES algorithms for

AN US

authentication and integrity of packets to the network server and the end-to-end encryption to the application server.

4. Management

A Smart City management platform has to provide services and mechanisms

310

M

that can support and facilitate application development. In #SmartME three main management platform services have been implemented as detailed in the

ED

following. 4.1. Incentive mechanisms

In a crowdsourcing-based system as a Smart City, according to our vision,

315

PT

one of the most important facilities to provide is the incentive mechanism for motivating contributors. To this purpose, in #SmartME we designed and

CE

implemented a virtual complementary currency called UniMeCoin. This currency is implemented through an Android-based mobile application that leverages the Ethereum blockchain technology6 . Currently, we have implemented a proof-ofconcept version of UniMeCoin as follows:

AC

320

• 1 UniMeCoin corresponds to 1 ETH in a private Ethereum blockchain; 6 https://www.ethereum.org

15

ACCEPTED MANUSCRIPT

• one single miner is involved in the blockchain under the control of the University of Messina (i.e., a fully centralized version of the blockchain implementing proof of authority consensus mechanism has been put in

325

CR IP T

place); • the Android-based mobile application implements an Ethereum light node; thus, the mobile phones are involved in the blockchain in the sense that transactions are fully managed by the application itself, but they neither download the blockchain nor participate in the mining process.

330

AN US

This way, we are currently exploiting only few advantages of the blockchain

technology, namely the built-in functionalities of Ethereum for currency management and public auditability. However, we are in the process of migrating to a consortium-chain network in which more partners are involved in the man335

agement of UniMeCoin by hosting additional miners (e.g., we will include the Municipality of Messina as UniMeCoin partner shortly), thus implementing a

M

decentralized approach in which the consensus process is distributed. Also in this case, a proof of authority consensus mechanism will be imple-

340

ED

mented, i.e., only authorized miners will be allowed to join the system. The peer to peer network will be formed statically by configuring each miner to connect to all the authorized miners in the network. Of course, user trustiness with

PT

respect to the entire system is critical to the efficacy of our incentive mechanisms. However, even if few miners will be involved, the decentralization of the network

CE

will be guaranteed by the presence of different administrative domains so that a 345

51% attach will be virtually impossible or easily detectable. Moreover, we plan to migrate to a version of UniMeCoin in which the

AC

complementary currency is implemented as token on top of the blockchain currency by means of a specific smart contract. Figure 3 shows some screenshots of the UniMeCoin Android-based application. Specifically, the activities that

350

allow users to check the balance of their account and to send a certain amount of UniMeCoin to another user are reported. Though, UniMeCoin is planned to be the official currency for access and pay16

CR IP T

ACCEPTED MANUSCRIPT

Figure 3: The UniMeCoin Android-based application.

AN US

ment of services belonging to the #SmartME ecosystem, the general architecture

of UniMeCoin make it suitable for incentive mechanism services. In order for 355

UniMeCoin to represent an incentive for any service, it will be exploited for: • making purchases at discount prices in shops that join the initiative; • paying for parking in the city center thanks to an agreement with the

M

Municipality;

• access to the university canteen and other university services at special prices.

ED

360

These are some of the common use cases that can be addressed by UniMeCoin. Being same as the digital currency, the UniMeCoin can be used in all the

PT

cases possible using any cryptocurrency. Thus, it can be used as an incentive

CE

mechanism with any kind of application. 365

4.2. Data Management One of the earliest verticals that has been implemented in the #SmartME

AC

project is the collection of city environmental monitoring data in a standard open data format. We exploited CKAN, an open source data portal software, to store and visualize the collected data. The Comprehensive Knowledge Archive

370

Network (CKAN)

7

is a Web-based open source Content Management System

7 http://ckan.org

17

ACCEPTED MANUSCRIPT

(CMS) for the storage and distribution of datasets. Data delivery is performed through the CKAN REST API interface. Data is consumed by the Public portal, which provides a user-friendly showcase through which citizens can browse the

375

CR IP T

#SmartME nodes and have a sneak peek at collected data. Moreover, the CKAN datastores offer the possibility for both citizens and third party services to perform complex queries and retrieve historical series.

#SmartME nodes are programmed to periodically send samples to a set of

CKAN datastores, but it is very important to highlight that this is just a choice,

e.g., due to technical convenience, or otherwise policy, and that data management is by design fully decoupled from device management in the #SmartME

AN US

380

architecture. Indeed, the #SmartME dataplane can be fully reconfigured, even at runtime, according to whichever requirements are in place, and the #SmartME control plane, based on Stack4Things, as interface for device repurposing, is key in enabling this degree of freedom. Indeed, asynchronous plugins, i.e., long-running 385

self-contained business logic units, are used for sampling environmental data and

M

sending it to datastore(s) defined at (plugin) injection time, or even at runtime. The plugins run on top of Arduino YUN boards deployed in the Messina urban

ED

area. Using the ideino-linino library, plugins periodically sample the voltage levels of the pins to which sensors are connected. Such voltage samples are then 390

elaborated to obtain the environmental data and finally sent to CKAN together

PT

with a timestamp and the geographical position of the node. Other use cases in #SmartME can theoretically be, and in a few cases have been, empowered by

CE

this approach in decoupling data management from device control. In the production system, no specific semantics enrichment is currently

395

exploited in the procedures of business logic, data filtering and analysis. However,

AC

we are currently in the phase of actively researching mechanisms and technologies that can be used to reach such a goal. In particular, in [14], we leveraged on the Semantic Sensor Network (SSN), the DateTime, and the WGS8pos geographical ontologies to semantically enrich the data produced by the #SmartME nodes. In

400

this way, it is easily possible to find correlations between the data produced by different nodes and implement mechanisms for data interpolation and predicition. 18

ACCEPTED MANUSCRIPT

This could be interesting, for example, for implementing real-time weather forecasting systems in the area of Messina (see for example [15]).

AN US

CR IP T

4.3. Image Processing and Scene Interpretation: SmartMECam

Figure 4: Graphical representation of the workflow of the SmartMECam solution for image processing and scene interpretation.

SmartMECam is a combined hardware / software solution that can recognize

405

and analyze objects in a generic video stream, even in real time, and may

M

also interface with an existing network of cams. A scheme is reported in Figure 4. Even in standalone mode, SmartMeCam lends itself to applications

410

ED

in challenging environments, such as airports, stations, or large public places, when it is necessary to collect statistical information about the number of people and other mobile objects, as well as their mobility patterns. We can

PT

think SmartMECam as enabler for the development of complex apps mainly for Business-to-Business (B2B) and Business-to-Government (B2G) scenarios. The solution is capable of making accurate assessments about the most crowded areas, the most attractive showcases, or the status of queues. SmartMECam,

CE 415

in fact, can be used in complex environments where non-identification of the

AC

person is required, in the industrial and agrifood sector for monitoring internal company processes, or in general to build new applications based on advanced algorithms for image processing and scene interpretation (for example combining

420

Computer Vision (CV) and Artificial Intelligence (AI)). It offers the possible interface with an already existing network of cameras allowing their reuse and integration for more sustainable vertical apps (e.g., reducing cost of hardware). 19

ACCEPTED MANUSCRIPT

Moreover, SmartMECam can use the LoRaWAN8 specifications with advantages in terms of coverage range and dynamism of data flows.

5. Applications and Services

CR IP T

425

One of the main advantage of the proposed approach is the flexibility and

adaptability to application domains. The Smart City ecosystem managed by the stack above described allow to reuse and repurpose the same infrastructure

by multiplexing resources and nodes thus able to run different applications 430

in parallel. Examples of applications from #SmartME are described in the

AN US

following. 5.1. #SmartME Parking

#SmartME Parking is a service implemented in collaboration with Park Smart, a startup that aims to solve parking problems with an innovative solution 435

based on computer vision algorithms executed close to the cameras on the AISee

M

box, an IoT device capable to run complex AI algorithms. This way, Park Smart proposes a solution that exploits the Edge Computing paradigm, with sensors

ED

distributed on the city and computational units that process the data and send only the parking occupancy information to the Cloud. As reported in [16, 17], the Computer Vision system is based on a classification

440

PT

model that is able to discriminate between patches depicting free parking lots and the ones where the slot is occupied by a car. The underlying model is a

CE

deep convolutional neural network, designed for classification, which has been fine-tuned using a dataset containing over 270.000 patches. In order to ensure different variabilities, the dataset - shown in Figure 5

445

AC

has been acquired over several months, to include seasonal weather and light conditions (e.g. sunny, rainy, day/night, etc.). By being a full-stack company, Park Smart develops its software from the

IoT operating system up to the services running on the Cloud. 8 https://lora-alliance.org/about-lorawan,

last accessed 25/09/2018.

20

AN US

free

CR IP T

occupied

ACCEPTED MANUSCRIPT

Figure 5: A sample from the Park Smart dataset.

The software framework is designed to be easily expandable, so that in

M

450

the future more functionalities can be developed. In particular, a multi-cloud approach is implemented by using different IoT gateways, such as AWS, vanilla

ED

Openstack, and Stack4Things, to be compliant with #SmartME. Through the IoT gateway, an operator is able to interact with the AISee box, sending 455

requests, receiving response messages and logs. Specifically, the integration

PT

with Stack4Things allows not only to remotely control the AISee box but also to access the streaming flow of the camera through a set of Websocket-based

CE

tunnels. An example of such a feature is represented in Figure 6 where an overlay on top of the streaming flow of the camera visually represents the occupancy status of a specific parking area.

AC

460

5.2. #SmartME Lighting The #SmartME platform integrates a low-cost solution for data collection

and remote control of public, private, and industrial areas lighting systems

21

Figure 6:

CR IP T

ACCEPTED MANUSCRIPT

The #SmartME Parking solution integrating Park Smart framework with

AN US

Stack4Things.

developed by Meridionale Impianti Spa9 . The #SmartME Lighting system uses 465

conveyed waves (PLM) as the main mean of communication. Each lamp is equipped with an electronic device (called End Device in the following) that activates/deactivates the lamp (lamps can be either SAP or LED) and monitors the main consumption parameters such as voltage, current, and absorbed power.

470

M

The End Device is equipped with an STM32L151RBT6 MCU, a PLM modem, a 0-10 VDC output for external dimming of the lamp, and a power output

ED

consisting of a relay with integrated current and voltage sensors. Every single End Device is periodically queried by a Gateway located in the plant electrical panel. The Gateway is equipped with an STM32F4 MCU, a

475

PT

PLM modem, and a set of physical interfaces, i.e., two mini USB 2.0 connectors, a GSM/GPRS modem, a RS-485 serial interface, an Ethernet interface, and Bluetooth connectivity. The Gateway checks the status of the lamps and stores

CE

the data in its internal memory (i.e., a micro SD card). The system comes

with a proprietary software that allows the manual management of the lighting

AC

system by letting operators run the main diagnostic and maintenance functions,

480

e.g., manual on/off of lamp, lamp dimming, reading of each single parameter, programming of time slots. 9 Meridionale

Impianti Spa has a sister company in Singapore called Meridionale Impianti

Singapore Pte Ltd

22

ACCEPTED MANUSCRIPT

However, in the context of the #SmartME project, the Gateway has been also equipped with an Arduino YUN board, connected through the serial interface, that acts as a bridge with the external world allowing all the information to be sent to the #SmartME portal and actuation commands to be received and

CR IP T

485

AN US

forwarded to the Gateway for remote control of the whole lighting network.

Figure 7: The integration of #SmartME Ligting in the #SmartME portal.

5.3. #SmartME Energy

Getting cities smarter means to transform their “metabolism” to offer sus-

490

M

tainable services to citizens. To this end, balancing sustainability and comfort objectives with energy efficiency and cost-saving requirements is a challenge. #SmartME Energy is the solution that allows both Public Administrations

ED

and businesses to optimize the use of all the electrical equipments inside their buildings. The goal is to reduce energy consumptions and costs also improving

PT

sustainability and comfort inside offices, getting them smarter. The system is currently in operation at the University of Messina: it collects,

495

stores and analyzes the data from grid-connected electrical devices and appliances,

CE

the accesses, the brightness and the temperature inside offices (both rooms and hallways). About the electrical workload, in particular, when the monitoring detects an idle state of the device, after a programmable time it removes the unnecessary power consumption.

AC 500

The architecture of #SmartME Energy mainly consists of two levels: (i) the

edge of the IoT network, involving the end-nodes with sensors and actuators,

(ii) the Stack4Things connection through “in the middle” gateway nodes. At the edge (i), the end-nodes can be configured to be used in a (i.1) star network

23

ACCEPTED MANUSCRIPT

505

(having the gateway as star center) or in a (i.2) mesh network (each end-node can communicate directly with the remote Cloud). Currently, the (i.1) configuration is running. Each device is equipped with the Bluetooth technology or with the

CR IP T

433/868 MHz transceiver in order to allow the user to access the device in its proximity, thus resulting in a piconet. The choice of the communication standard 510

is the result of a cost-benefit analysis at the IoT device level. The trade-off takes

into account basic transmission rate (class 2), limited (proximity) coverage rate, full compatibility transceiver-IoT device, low-cost incidence on the entire cost of the IoT device (less than 8%), ease of integration, small dimensions, power

515

AN US

supply via cable. Moreover, thanks to the probability of interfering with another Bluetooth system that is less than 1.5%, several Bluetooth piconets can operate at the same time in the same area with minimal interference. By using the above-mentioned technology in a Proximity Area Network (PAN) involving the monitored offices, the gateway periodically executes a polling loop to test each

connected node (having its MAC address as ID stored at gateway). Therefore it sends (via Ethernet or WiFi) data in a programmable manner to CKAN to be

M

520

managed as referenced datasets. The (i.1) configuration is preferable to the (i.2)

ED

for low-performance data transmission (for example when it is not necessary to have low latency), or to connect low-cost and/or not smart objectives when the quantitative approach is preferable to the qualitative one. A study phase is underway related to data accuracy in order to assure value

PT

525

representation consistency, valid values, to avoid change-induced inconsistencies

CE

and to minimize missing values. The exact correspondence between the values automatically stored by the system and the values measured by calibrated instrumentation was tested with a systematic procedure over a proportionate period (one sample every 3-10-15 minutes) at the time of data acquisition at the

AC

530

gateway. The last concept of #SmartME Energy is based on the use of Arancino.cc

(a SmartMe.IO 10 project). Coming from the experience in the Arduino world 10 http://smartme.io

24

CR IP T

ACCEPTED MANUSCRIPT

ED

M

AN US

Figure 8: A screen-shot of the #SmartME Energy application.

PT

Figure 9: Example of data-view about the power consumption monitoring.

combined with the University experience, it is highly customizable and feature535

rich, also designed to be easily used and managed in the (i.2) configuration

CE

instead of the current (i.1). Figure 8 shows a screen-shot of the #SmartME Energy application (front-

end). In this example, the front-end provides information about the position of

AC

the #SmartME Energy node through OpenStreet Map, and the measurement of

540

the power consumption at the electrical lines identified as L3 and L4 and of the brightness labeled as L2 (i.e., the electrical line for the lighting). A screen-shot of the 48-hours data-view about the power consumption (Watt)

at the electrical line L3 is shown in Figure 9.

25

CR IP T

ACCEPTED MANUSCRIPT

AN US

Figure 10: Example of data-view about the brightness monitoring.

A screen-shot of the 3-days data-view about the brightness (microWatt/cm2) 545

at the electrical line L2 is shown in Figure 10. 5.4. #SmartME TrashCan

#SmartME Trashcan is the waste management solution conceived by the

M

University of Messina within the #SmartME project [18]. The IoT nodes in #SmartME Trashcan are the Trashcan smart dumpsters (see Figure 11), which integrate easy-to-use, open-source, and low-cost hardware and software. They

ED

550

present an external case with an anchoring system able to host the removable internal container. Such dumpsters are conceived to serve two different typologies

PT

of waste collection: (i) community service, for public open spaces; (ii) residential service, for household waste. The first one has a capacity of 50 gal/190 l or 150 gal/570 l, while the second one of 31.7 gal/120 l or 63.4 gal/240 l. All the smart

CE

555

dumpsters are powered by a solar photovoltaic panel and an energy storage unit.

The control unit is positioned between the case and the removable container, thus

AC

to avoid damage during waste collection operations. Each #SmartME Trashcan smart dumpster embeds Arduino YUN as the main sensing-and-actuation board.

560

This is equipped with fill-level sensors (either ultrasonic or laser) and with other sensors for monitoring environmental parameters such as temperature, humidity, air quality, light, and noise. Moreover, Stack4Things lightning-rod runs on each

Arduino YUN board and interacts on the one side with the sensors, actuators, 26

CR IP T

ACCEPTED MANUSCRIPT

AN US

Figure 11: The Trashcan smart dumpster design.

and OS tools available on the board and, on the other side, communicates with 565

Stack4Things IoTronic service.

Hereafter, we describe theClosestBin, a mobile application implemented as part of the #SmartME Trashcan solution. This application is targeted at the

M

citizens for the detection of the closest and still fillable smart dumpster containing a specific type of waste. theClosestBin shows the route to follow and provides 570

information on the distance and time required to reach the dumpster. We used

ED

Intel XDK as development kit. This is built on top of the Apache Cordova framework, which allows to develop multi-platform (e.g., Android, iOS, Windows

PT

Phone) applications. Apache Cordova applications are implemented as Web applications and thus are written in the standard Web languages, such as: (i) 575

HTML; (ii) CSS; and (iii) JavaScript. In order to build maps, we exploited the

CE

Mapbox Streets tiles, which are based on data from OpenStreetMap. Moreover,

we employed the Leaflet JavaScript library to handle the elements of the map such as buttons, pop-ups, and markers. Finally, we leverged the Leafelt KNN

AC

plugin to calculate distances as the crow flies and return the closest element, while

580

Leaflet Routing Machine was adopted for the computation and representation on the map of the best route to follow in order to reach the closest dumpster. Figure 12 reports a screenshot of the application in which the user is provided

with the information necessary to reach the closest paper dumpster.

27

CR IP T

ACCEPTED MANUSCRIPT

AN US

Figure 12: A screenshot of theClosestBin.

5.5. #SmartME Pothole

#SmartME Pothole is an example of mobile application, coupled with a Web

585

service as backend for, e.g., mapping and other visualization tasks, following the mobile crowdsourcing (crowdsensing) paradigm. The purpose of the system

M

lies in detecting potholes and other distress elements on the surface of public roads. Users of the app are free to choose whether and under which conditions to 590

share the resources (computing and sensing) of their own mobile device, where

ED

volunteering means providing useful data to potentially novel high value-added services for the community at large. The detection system is based on two

PT

components:

• i) an Apache Cordova-based multi-platform mobile app (tested under Android) running on volunteer-owned mobiles, ii) a backend system, developed

CE

595

as an Apache Tomcat servlet, to collect, filter, analyze, and mine data.

The system works by exploiting mobile-carrying volunteering commuters to

AC

detect and classify automatically road surface conditions. A combined sampling takes place of acceleration data from on-board motion detection sensors and

600

geospatial coordinates, as provided by the GPS. The system then generates a quality map of traversed roads, pinpointing any distress condition and potential presence of potholes. The mobile app performs uninterrupted sampling of linear

28

ACCEPTED MANUSCRIPT

acceleration, i.e., the three-dimensional vector representing acceleration along each device axis, once gravity has been filtered out. As such, this is actually the 605

output of a virtual sensor, typically out of multi-sensors fusion (accelerometer,

CR IP T

magnetometer, gyro, etc.). The app computes changes in the sampled values for the norm of the acceleration vector: intuitively, when bumping into a pothole on

the way, or more generally going down a distressed road surface, these changes

may turn out to be significant. The app then marks the presence of a potentially 610

critical condition at the corresponding geospatial coordinates.

To avoid submission of inconsistent data to the DB, a simple and device-local

AN US

data filtering strategy has been applied: an experimentally determined threshold

for cruising speed, set as limiting value such that detected abrupt displacements, plausibly considered a sign of distress condition for the road surface, would 615

be discarded if cruising at sampling time keeps below the threshold, avoiding situations where i.e. the volunteering mobile owner is not commuting yet leaving sensing activities running by mistake. The flagging mechanism is based on

M

the provider of geo-data: at all times, its value reflects the currently active geo-positioning method; therefore, data will be saved only when “GPS” is the value.

ED

620

Datapoints thus acquired, together with extra data (difference values of the components of the acceleration vector along the three axes), get stored

PT

in a NoSQL DB (MongoDB) as data source for a Web application to enable monitoring and visualization of roads condition. Extra data collection has been deemed a useful extension in order to enable the extraction of additional

CE

625

intelligence from collected data when needed. The same information base may be perused by the local government and competent authorities to carefully plan

AC

targeted maintenance actions and aptly arrange those according to priority levels. Repaired sites may be marked as such on the Web UI by authorized operators.

630

Most business logic, data filtering and analysis routines reside inside the

Web application, in order to keep computational duties for involved mobiles at a minimum, e.g. just essential mechanisms and filtering rules to drop false positives. One of the most useful post-processing phases consists in snapping the pothole 29

ACCEPTED MANUSCRIPT

sites to actual road segments, by consuming Google Roads APIs, in particular the 635

snapToRoads primitive: a requirements for cleaning up data, considering that often the precision of GPS measurements may be on the order of a few meters,

CR IP T

and thus capturing some samples outside of the road grid (e.g., on a building). Other post-processing duties lie in reverse geocoding (e.g., finding the nearest

address), by engaging Google Geocoding APIs, and datapoints aggregation (e.g., 640

clustering of nearby samples). 5.6. Carpooling@UniMe

AN US

Within the #SmartME project, the Centro Informatico di Ateneo (CIAM) and SmartMe.io startup11 designed and developed Carpooling@UniMe, a software platform that implements a carpooling social network. The Platform plays 645

an important role in enabling the matching of supply and demand among the members of the University of Messina such as students, technicians and researchers.

M

A user friendly Android-based mobile application has been prototyped in order simplify the search for a private transportation vehicle belonging to another member of the university who is going to take the same route to the workplace.

ED

650

In fact, the app allows the users to contact each other to share private means of transportation (cars, motorbikes). Thus, such a new service faces the problem

PT

of urban mobility and environmental sustainability with the aim of reducing traffic and pollution, allowing the sharing of private means of transportation to 655

and from some of the hotter spots in the city from the mobility point of view,

CE

i.e., the university campuses. Carpooling systems usually need incentives mechanisms.

AC

In this direction, we designed and implemented a virtual complementary

currency called UniMeCoin. The currency is implemented through a second

660

Android-based mobile application that leverage the Ethereum blockchain technology. Android-based mobile application that leverage the Ethereum blockchain 11 http://smartme.io

30

ACCEPTED MANUSCRIPT

technology. The sharing of means of transportation implemented through Carpooling@UniMe can be for free or can require small refunds (mostly, fuel refunds). This implements a form of micro economy within the ecosystem. In particular, the complementary currency UniMeCoin ensures a form of economic sustain-

CR IP T

665

ability in the ecosystem. In this manner UniMeCoin represents an incentive in

the use of the carpooling application but at the same time the crypto-currency could be exploited for: (i) making purchases at discount prices in shops that join

the initiative; (ii) paying for parking in the city center thanks to an agreement 670

with the Municipality; (iii) access to the university canteen and other university

AN US

services at special prices. The use of UniMeCoin also involves the creation

of a small fund that is created and enriched when users convert their money in UniMeCoins. The fund is managed by the University of Messina that contributes with 50% of money. Such a fund is exploited for charitable projects or to 675

improve university services for students. The way the fund is exploited is decided annually by the students by mean of an electronic distributed voting system

M

based on blockchain technology. This mechanisms implements a form of social sustainability. CarPooling@UniMe and UniMeCoin are original solutions for

680

ED

mobility that combine technology innovation with environmental, economic and social sustainability.

In the following figures, some screenshots of the developed mobile app are

PT

shown. Especially in Figure 5.6 is showed the main men´ u of the application. The user, once logged in, has the possibility to (i) look for a trip; (ii) check the

CE

reserved trips; (iii) publish a trip to other university members and finally (iv) 685

set the preference of the application. In Figure 14, instead is shown the searching functionality. The user can use

AC

this feature to look for some trip which he is interested to. By choosing the date searchDate and the arrival point the application will show a list of possible trips.

690

The Figure 15 depicts filling out of the offering. A user can create a trip by

inserting details about it. Specifically he has to insert: (i) both starting and destination points; (ii) Date and starting hour; (iii) the hour for the return trip

(optional); (iv) the used vehicle (registered on the platform previously); (v) the 31

AN US

CR IP T

ACCEPTED MANUSCRIPT

Figure 13: Carpooling mobile application

M

number total available sits and finally the payment (optional). The payment can

695

ED

be done by the UnimeCoin currency. 5.7. #SmartME Art

#SmartME Art is an Android-based mobile application that has been de-

PT

veloped with the aim to support tourism in a smart city. The service provides tourists with a tool that allows them to better explore artistic heritage within a

CE

urban environment by using just their smartphones camera, as shown in Figure 700

16. The software solution is based on Google TensorFlow, an open source machine learning framework. We employ it in the field of image classification: in

AC

particular, this technology is exploited to build personalized image classifiers.

These pieces of software exploit TensorFlow to create personalized deep neural networks able to recognize specific assets, depicted in own pictures. This is a

705

critical feature for our research activities and we introduced a method to tag a given environment or space (for example, a museum) and to adjust the embedded software according to personalized user’s preferences. In order to investigate 32

AN US

CR IP T

ACCEPTED MANUSCRIPT

(a) Date Selection

(b) Destination Selection

M

Figure 14: Carpooling mobile application searching feature

these functionalities, we choose to retrain the Inception’s final layer in order

710

ED

to recognize single objects, such as artworks, monuments and paintings. These assets are convenient to classify because their essence (including the shape and the color) is unique, while in general the Inception model works with an abstrac-

PT

tion process to relate a visual data to a given class. In artworks recognition (classification process), the task seems to operate in a better way because there

CE

is a single object for each class, i.e., a specific artwork. Therefore the single

715

object (for example, a panting) represents the unique instance of a given class. In our mobile app, this classification approach allows us to recognize art objects

AC

(i.e., historical buildings, statues, monuments, paintings) belonging to a pre-built visual database that tourists frame with their camera.

720

After the recognition phase, the application serves its user with videos and

other engaging content in a mobile optimized format. Figure 17 graphically depicts the workflow of the application.

33

AN US

CR IP T

ACCEPTED MANUSCRIPT

.png

(b) Filled out Form

(a) Offering Form

M

Figure 15: Carpooling mobile application offering feature

The app accesses to the camera by using the Android Camera2 package,

ED

while it support JNI (Java Native Interface) procedures to interact with TensorFlow’s core engine, which has been implemented (by Google developers) in C++ 725

programming language. By looking at our software architecture (Figure 18), we

PT

currently work with TensorFlow C++ interface in the following manner: • On startup, the app launches an Android activity (CameraActivity. java)

CE

which then starts a fragment (Camera-ConnectionFragment.java)

• The fragment does some setup to basically start the camera and feed the

AC

730

incoming stream of images to an object it instantiates (TensorflowImageListener.java)

• The listener consults the classifier (TensorflowClassifier.java) about each image it gets, and receives the classification and confidence score for each image.

34

AN US

CR IP T

ACCEPTED MANUSCRIPT

735

5.8. #SmartME Taxi

M

Figure 16: #SmartME Art application.

ED

#SmartMe Taxi represents the integration of a fleet management application developed by Arkimede Srl12 into the #SmartME portal. The goal is twofold: first, to give the Taxi company a smart tool for the internal fleet management,

740

PT

additionally to equip the taxi’s fleet with sensors such as PM10 or PM2.5 (connected to a Arduino board) that, together with the parameters provided

CE

by the taxi electronic control unit, can retrieve environmental data. The basic idea is to retrieve temperature and atmospheric pressure data by the taxi’s electronic control unit and in order to reduce the equipping costs (purchase and

AC

calibration) of PM10 or PM2.5 that could be very high, to equip each taxi with

745

low price sensors, calibrated one-off at the year 0 with a PM10 or PM2.5, and then to use normalization alghoritms to understand and reduce the error on measurements. In this way, we have a number of sensors that, roaming around 12 http://www.arkimedenet.it

35

CR IP T

ACCEPTED MANUSCRIPT

ED

M

AN US

Figure 17: Graphical representation of the workflow of the #SmartME Art application.

PT

Figure 18: Mobile app code structure.

the city, can sample any environmental data such as temperature, atmospheric pressure or even the radio coverage signal of mobile operators. The first goal is simply achieved by an Android or iOS application, running on a tablet aboard,

CE

750

that sends the taxi’s position and speed for further processing. The sampling is done every 10 meters when the taxi is in transit, every 5 minutes at rest. In this

AC

way it is possible to monitor effectively the fleet movements during the working hours and, at the same time, by inferring a real-time view of the city traffic, the

755

mobility as well. This way it is possible to have a birds-eye view of the traffic in real-time. In fact, if going from a point A to a point B a driver needs in average 3 minutes, but the measured time now turns out to be 20 minutes, it

36

ACCEPTED MANUSCRIPT

means that there is currently an issue (e.g., traffic jam) with that road, and an alert could be triggered on the #SmartMe platform. Moreover the data about 760

the taxi’s position and speed, acquire by gps sensor, are periodically sent to a

CR IP T

CKAN datastore. Thus the citizen is able to get information about the status of the taxis by means of the #SmartMe portal that shows corresponding markers for each vehicle in real-time on a map. Thus by means of a smart analysis of the

collected data it is possible to improve both the taxi service and the city quality 765

of life for the citizens.

AN US

6. Conclusions and future work

In this paper we presented an overview of solutions and services developed in the context of the #SmartME project. Based on the Stack4Things framework, which provides an abstract and uniform environment on top of heterogeneous 770

devices laying at the intersection between IoT and Cloud , concepts such as

M

reuse, resource virtualization and multiplexing, and software defined cities have been implemented on a real testbed, demonstrating their effectiveness. This way, a wide bouquet of services have been implemented on the same #SmartME

775

ED

testbed infrastructure, ranging from smart mobility (smart parking, fleet/taxi management, carpooling, pothole detection) to smart art, smart environment

PT

(environmental monitoring, trash management), smart energy and lighting. These demonstrate the flexibility and adaptability of the approach adopted by the #SmartME project to small and medium cities that can easily turn, with very

CE

few effort and low costs, into smart cities, by possibly exploiting, reconverting

780

and reusing existing infrastructure. As ongoing and future work we are planning, indeed, to replicate this ex-

AC

periments into other cities around the world , thus exploiting the #SmartME experience worldwide. Furthermore, the scalability of the proposed solution is under evaluation. The general approach is in theory highly scalable and

785

replicable, but underlying technologies have to be tested in real setups where thousands, or even million of devices have to be interconnected and cooperate.

37

ACCEPTED MANUSCRIPT

This is also a challenge to address in future work, aiming at further exploiting the #SmartME experience at larger scale, in big cities and urban areas.

790

CR IP T

References [1] C. G. Cassandras, Smart Cities as cyber-physical social systems, Engi-

neering 2 (2) (2016) 156 – 158. doi:http://dx.doi.org/10.1016/J.ENG. 2016.02.012. URL

http://www.sciencedirect.com/science/article/pii/

795

AN US

S2095809916309420

[2] N. Z. Bawany, J. A. Shamsi, Smart city architecture: Vision and challenges, International Journal of Advanced Computer Science and Applications(IJACSA) 6 (11).

[3] D. Bonino, M. T. D. Alizo, A. Alapetite, T. Gilbert, M. Axling, H. Udsen,

M

J. A. C. Soto, M. Spirito, Almanac: Internet of Things for Smart Cities, in: 2015 3rd International Conference on Future Internet of Things and Cloud,

800

ED

2015, pp. 309–316. doi:10.1109/FiCloud.2015.32. [4] F. Cicirelli, A. Guerrieri, G. Spezzano, A. Vinci, An edge-based platform

for

dynamic

smart

city

applications,

Gener-

doi:https:

PT

ation Computer Systems 76 (2017) 106 – 118.

Future

//doi.org/10.1016/j.future.2017.05.034.

805

URL

http://www.sciencedirect.com/science/article/pii/

CE

S0167739X16308342

AC

[5] P. M. Santos, J. G. P. Rodrigues, S. B. Cruz, T. Loureno, P. M. dOrey,

810

Y. Luis, C. Rocha, S. Sousa, S. Crisstomo, C. Queirs, S. Sargento, A. Aguiar, J. Barros, Portolivinglab: An IoT-based sensing platform for Smart Cities, IEEE Internet of Things Journal 5 (2) (2018) 523–532. doi:10.1109/JIOT. 2018.2791522.

38

ACCEPTED MANUSCRIPT

[6] H. Arasteh, V. Hosseinnezhad, V. Loia, A. Tommasetti, O. Troisi, M. Shafiekhah, P. Siano, IoT-based Smart Cities: a survey, in: 2016 IEEE 16th International Conference on Environment and Electrical Engineering (EEEIC),

815

CR IP T

2016, pp. 1–6. doi:10.1109/EEEIC.2016.7555867. [7] B. Ahlgren, M. Hidell, E. C. . Ngai, Internet of Things for Smart Cities: Interoperability and open data, IEEE Internet Computing 20 (6) (2016) 52–56. doi:10.1109/MIC.2016.124. 820

[8] D. Bruneo, S. Distefano, F. Longo, G. Merlino, An IoT testbed for the

AN US

Software Defined City vision: The #SmartMe project, in: 2016 IEEE Int. Conf. on Smart Computing (SMARTCOMP), 2016, pp. 1–6. [9] G. Merlino, D. Bruneo, F. Longo, A. Puliafito, S. Distefano, Software Defined Cities: A novel paradigm for smart cities through IoT clouds, in: 2015 IEEE 12th Intl Conf on Ubiquitous Intelligence and

825

doi:10.1109/

M

Computing (UIC-ATC-ScalCom), 2015, pp. 909–916. UIC-ATC-ScalCom-CBDCom-IoP.2015.174.

ED

[10] G. Merlino, D. Bruneo, S. Distefano, F. Longo, A. Puliafito, Stack4things: Integrating IoT with OpenStack in a Smart City context, in: Proceedings of the IEEE First International Workshop on Sensors and Smart Cities, 2014.

830

PT

[11] G. Merlino, D. Bruneo, F. Longo, A. Puliafito, S. Distefano, Software Defined Cities: a novel paradigm for Smart Cities through IoT clouds, in:

CE

Proceedings of the 2015 IEEE Intl Conf on Cloud and Big Data Computing (CBDCom), UIC-ATC-SCALCOM-CBDCOM ’15, 2015, pp. –.

[12] D. Bruneo, S. Distefano, F. Longo, G. Merlino, A. Puliafito, I/Ocloud:

AC

835

Adding an IoT dimension to Cloud infrastructures, Computer 51 (1) (2018) 57–65. doi:10.1109/MC.2018.1151016.

[13] G. Merlino, D. Bruneo, S. Distefano, F. Longo, A. Puliafito, Enabling mechanisms for cloud-based network virtualization in IoT, in: Internet of

39

ACCEPTED MANUSCRIPT

Things (WF-IoT), 2015 IEEE 2nd World Forum on, 2015, pp. 268–273.

840

doi:10.1109/WF-IoT.2015.7389064. [14] D. Bruneo, F. Longo, G. Merlino, A. Puliafito, N. Kushwaha, Integrating iot

CR IP T

and cloud in a smart city context: The #smartme case study, International

Journal of Computer Applications in Technology 57 (4) (2018) 267–280, cited By 0. doi:10.1504/IJCAT.2018.093528.

845

URL

https://www.scopus.com/inward/record.uri?eid=2-s2.

0-85050816820&doi=10.1504%2fIJCAT.2018.093528&partnerID=40&

AN US

md5=2a625990009cbd28073e018e196de63f

[15] T. Fowdur, Y. Beeharry, V. Hurbungs, V. Bassoo, V. Ramnarain-Seetohul, E. C. M. Lun, Performance analysis and implementation of an adaptive

850

real-time weather forecasting system, Internet of Things 3-4 (2018) 12 – 33. doi:https://doi.org/10.1016/j.iot.2018.09.002. URL

S2542660518300519 855

M

http://www.sciencedirect.com/science/article/pii/

[16] D. Di Mauro, S. Battiato, G. Patan`e, M. Leotta, D. Maio, G. M. Farinella,

ED

Learning approaches for parking lots classification, in: J. Blanc-Talon, C. Distante, W. Philips, D. Popescu, P. Scheunders (Eds.), Advanced Concepts for Intelligent Vision Systems, Springer International Publishing,

860

PT

Cham, 2016, pp. 410–418.

[17] D. D. Mauro, M. Moltisanti, G. Patan, S. Battiato, G. M. Farinella, Park

CE

smart, in: 2017 14th IEEE International Conference on Advanced Video and Signal Based Surveillanc e (AVSS), 2017, pp. 1–5. doi:10.1109/AVSS.

AC

2017.8078502.

[18] M. Giacobbe, C. Puliafito, M. Scarpa, The big bucket: An IoT cloud solution

865

for smart waste management in Smart Cities, in: The 4th International Workshop on CLoud for IoT (CLIoT 2016), Vienna, Austria, 2016.

40