d1.3 final requirements and reference...

FP7-ICT-2013-EU-Japan

ClouT: Cloud of Things for empowering the citizen clout in smart cities

FP7 contract number: 608641

NICT management number: 167 ア

Project Deliverable

D1.3 – Final Requirements and Reference Architecture

ABS TR AC T

This deliverable provides the final version of the ClouT Reference Architecture for the CIaaS (City Infrastructure as a Service) and CPaaS (City Platform as a Service) layers, along with final proposals for reusable components. The document is a complete report about the creation of the ClouT Architecture, starting from the description of use cases and user/service requirements (based on those defined in the Deliverable 1.1 - Use Cases and User Requirements – and reviewed according to stakeholders’ meetings and customer’s survey) and the finalization of the initial work included in the D1.2 - First version of Reference Architecture and Reusable Components (revised and improved following first project technical review recommendations). The Reference Architecture is described following a top-down approach, explain the overall architecture first and then the individual functional blocks, with all details about their integration between each other.

D1.3 - Final Requirements and Reference Architecture

ClouT – 30/09/2014

Disclaimer

This document has been produced in the context of the ClouT Project which is jointly funded by the European Commission (grant agreement n° 608641) and NICT from Japan (management number 167ア). All information provided in this document is provided "as is" and no guarantee or warranty is given that the information is fit for any particular purpose. The user thereof uses the information at its sole risk and liability. This document contains material, which is the copyright of certain ClouT partners, and may not be reproduced or copied without permission. All ClouT consortium partners have agreed to the full publication of this document. The commercial use of any information contained in this document may require a license from the owner of that information. For the avoidance of all doubts, the European Commission and NICT have no liability in respect of this document, which is merely representing the view of the project consortium. This document is subject to change without notice.

The ClouT consortium is composed of the following institutions:

No. Participant organization name Short name Country

1 Commissariat à l’énergie atomique et aux énergies alternatives

CEA (coordinator)

France

2 Engineering Ingegneria Informatica SpA ENG Italy

3 University of Cantabria UC Spain

4 STMicroelectronics S.r.l. ST Italy

5 Santander City Municipality SAN Spain

6 Genova Municipality GEN Italy

7 Nippon telegraph and telephone East Corporation (NTT East)

NTTE (coordinator)

Japan

8 Nippon Telegraph and telephone corporation (NTT R&D)

NTTRD Japan

9 Keio University KEIO Japan

10 Panasonic System Solution PANA Japan

11 National Institute of Informatics NII Japan


ClouT – 30/09/2014

EU Editor Bartolomeo Turco, ENG

JP Editor Takuro Yonezawa, KEIO

Authors Bartolomeo Turco, Daniele Pavia, Philip Wright, Cosimo Greco, Martino Maggio, Ciro Formisano ENG; Levent Gürgen, Christophe Munilla CEA; Marco Grella, ST; Jose Antonio Galache, UC; Vittorio Saettone, GEN; Takuro Yonezawa, KEIO; Hiroyuki Maeomichi, NTT ; Kenji Tei, NII

Internal reviewer Levent Gürgen, CEA

Deliverable type R

Dissemination level

(Confidentiality)

PU

Contractual Delivery Date 31/07/2014

Actual Delivery Date 30/09/2014

Keywords ClouT, Cloud Computing, IoT, Smart Cities, CSaaS, CPaaS, CIaaS, System Requirements, Reusable Components, Reference Architecture, Functional Models, Field Trials

Revision history

Revision Date Description Contributors

v0.1 09/06/2014 Table of Contents created ENG

v0.2 12/06/2014 Table of Contents revised All partners

v1.0 19/06/2014 Table of Contents finalized ENG

v1.1 03/07/2014 First contributions for user/service requirements and use cases (revision from D1.1).

ENG, KEIO

v1.2 10/07/2014 Second contributions for user/service requirements and use cases (new items).

ENG, KEIO

v1.3 30/07/2014 - Final version of user/service requirements and use cases.

- First contributions for functional components (Reference Architecture).

ENG, KEIO, ST, UC

v1.3.4 11/09/2014 - Updated with Final Reference Arch overview - Partially updated System Requirements - Updated Domain Model - Updated Use Cases and User Requirements

All partners

V1.4 30/09/2014 Reviewed version CEA

V1.5 15/10/2014 Revised version after the review ENG


ClouT – 30/09/2014

TABLE OF CONTENTS

TABLE OF CONTENTS ........................................................................................................................................ 5

LIST OF FIGURES ............................................................................................................................................... 7

LIST OF TABLES ................................................................................................................................................. 9

LIST OF ABBREVIATIONS ................................................................................................................................. 10

TERMINOLOGY USED IN CLOUT ...................................................................................................................... 11

EXECUTIVE SUMMARY ................................................................................................................................... 16

1. INTRODUCTION .................................................................................................................................... 18

1.1. SCOPE OF THE DOCUMENT ....................................................................................................................... 18 1.2. TARGET AUDIENCE .................................................................................................................................. 18 1.3. STRUCTURE OF THE DOCUMENT ................................................................................................................ 18

2. FINAL USER SCENARIOS & REQUIREMENTS ........................................................................................ 20

2.1. INTRODUCTION ....................................................................................................................................... 20 2.2. SMART CITIES APPLICATIONS AND HIGH LEVEL USER SCENARIOS .................................................................. 20 2.2.1. INVOLVED ACTORS .............................................................................................................................. 21 2.2.2. SMART CITY RESOURCE MANAGEMENT ................................................................................................. 23 2.2.2.1. TRAFFIC MOBILITY MANAGEMENT ........................................................................................................ 24 2.2.2.2. IOT DEVICE SHARING AND COMPOSING ................................................................................................. 28 2.2.3. SAFETY AND EMERGENCY MANAGEMENT .............................................................................................. 33 2.2.3.1. CITY SAFETY AND ACCIDENT MANAGEMENT .......................................................................................... 33 2.2.3.2. WEATHER RISK AND ALERT MANAGEMENT ............................................................................................ 37 2.2.4. CITIZEN HEALTH AND PLEASANT ENHANCEMENT .................................................................................... 42 2.2.4.1. CITY EVENT FINDER ............................................................................................................................. 42 2.2.4.2. CITIZEN ACTIVITY ENHANCER ............................................................................................................... 46 2.3. USER/SERVICE REQUIREMENTS ................................................................................................................. 51 2.4. SYSTEM REQUIREMENTS .......................................................................................................................... 55

3. PRELIMINARY ANALYSIS OF SURVEY RESULTS .................................................................................... 63

3.1. STAKEHOLDERS’ SURVEY ........................................................................................................................... 63 3.2. CITIZENS SURVEYS ................................................................................................................................... 66 3.1.1. CITIZEN SURVEY - GENOA..................................................................................................................... 67 3.1.2. CITIZEN SURVEY – MITAKA AND FUJISAWA ............................................................................................ 68 3.1.3. CITIZENS SURVEY – SANTANDER ........................................................................................................... 70

4. CLOUT REFERENCE ARCHITECTURE ...................................................................................................... 75

4.1. INTRODUCTION ....................................................................................................................................... 75 4.2. FINAL VERSION FOR A CLOUT REFERENCE ARCHITECTURE ............................................................................ 83 4.3. CIAAS FUNCTIONAL MODELS AND COMPONENTS ......................................................................................... 84 4.3.1. CITY INFRASTRUCTURE MANAGEMENT .................................................................................................. 85 4.3.2. COMPUTING AND STORAGE .................................................................................................................. 89 4.3.3. INTEROPERABILITY & CITY RESOURCE VIRTUALISATION ........................................................................... 92 4.3.4. SENSORISATION AND ACTUATORISATION ............................................................................................... 95 4.3.5. INTERNET OF THINGS KERNEL ............................................................................................................... 98 4.4. CPAAS FUNCTIONAL MODELS AND COMPONENTS ...................................................................................... 103


ClouT – 30/09/2014

4.4.1. CITY SERVICE COMPOSITION .............................................................................................................. 104 4.4.2. CITY DATA PROCESSING ..................................................................................................................... 109 4.4.3. CITY RESOURCE ACCESS ..................................................................................................................... 112 4.5. SECURITY & DEPENDABILITY ................................................................................................................... 115

5. MAPPING THE ARCHITECTURE ........................................................................................................... 119

5.1. INTRODUCTION ..................................................................................................................................... 119 5.2. MAPPING THE ARCHITECTURE TO A REAL WORLD SCENARIO ...................................................................... 119

6. CONCLUSIONS..................................................................................................................................... 122

REFERENCES ................................................................................................................................................. 124

APPENDIX..................................................................................................................................................... 125

APPENDIX A – FULL SYSTEM REQUIREMENTS SPECIFICATIONS ...................................................................................... 125 APPENDIX B – CITIZENS AND STAKEHOLDERS’ SURVEYS ................................................................................................ 159 STAKEHOLDERS’ SURVEY ..................................................................................................................................... 159 GENOA CITIZENS’ SURVEY ................................................................................................................................... 163 SANTANDER CITIZENS’ SURVEY ............................................................................................................................ 169

LIST OF FIGURES

Figure 1: Relationship actors/ClouT Layers ........................................................................................................ 22 Figure 2: Sequence Diagram about interactions between actors, ClouT and Devices ....................... 23 Figure 3: Simplified Use Case Diagram of Traffic Mobility Management ................................................ 25 Figure 4: Sequence Diagram of Traffic Mobility Management ..................................................................... 26 Figure 5: IoT Device Sharing and Composing ..................................................................................................... 29 Figure 6: Sequence Diagram of IoT Device Sharing and Composing ......................................................... 31 Figure 7: City Safety and Accident Management ................................................................................................ 34 Figure 8: Sequence Diagram of City Safety and Accident Management ................................................... 35 Figure 9: Weather Risks and Alert Management ............................................................................................... 38 Figure 10:Sequence Diagram of Weather Risk and Alert Management ................................................... 39 Figure 11: City Event Finder ....................................................................................................................................... 43 Figure 12: Sequnce Diagram of City Event Finder ............................................................................................ 44 Figure 13: Citizen Activity Enhancer ...................................................................................................................... 47 Figure 14: Sequence Diagram of Citizen Activity Enhancer .......................................................................... 48 Figure 15: Stakeholders' survey, gender breakdown ...................................................................................... 64 Figure 16: Stakeholders' survey, Technologies familiarity ........................................................................... 64 Figure 17: Aims of Smart Cities, Ranking .............................................................................................................. 65 Figure 18: TECHNOLOGIES AND IOT SOLUTIONS – RANKING ................................................................... 66 Figure 19: APPLICATIONS OF IOT – PREFERENCES FROM GENOVA CITIZENS .................................. 67 Figure 20: Citizen Survey, Participants Demographic ..................................................................................... 68 Figure 21: Citizen Survey, Cloud Technology Familiarity .............................................................................. 69 Figure 22: Citizen Survey, Cloud Service Models Interest ............................................................................. 69 Figure 23: CITIZEN SURVEY, Internet of Things TECHNOLOGIES FAMILIARITY ................................ 69 Figure 24: CITIZEN SURVEY, Dataset Availability Interest ........................................................................... 70 Figure 25: CITIZEN SURVEY, Field Trials Interest ............................................................................................ 70 Figure 26: CITIZEN SURVEY, Smartphone Technologies FAMILIARITY .................................................. 70 Figure 27: Interest in Internet of Things Applications .................................................................................... 71 Figure 28: Pace of City Events.................................................................................................................................... 72 Figure 29: Pace of City First Experience ................................................................................................................ 73 Figure 30: Pace of City Service Evaluation ........................................................................................................... 74 Figure 31: ClouT domain model ................................................................................................................................ 76 Figure 32: ClouT domain model: CIaaS .................................................................................................................. 77 Figure 33: Example of City Infratructure Service .............................................................................................. 78 Figure 34: Example of Virtualized City Infrastructure Entity ....................................................................... 79 Figure 35: ClouT domain model: CPaaS ................................................................................................................. 80 Figure 36: ClouT domain model: CSaaS ................................................................................................................. 82 FIGURE 37: CLOUT REFERENCE ARCHITECTURE OVERVIEW ......................................................... 83 FIGURE 38: Main Functional blocks for City Infrastructure layer .............................................................. 84 FIGURE 39: City Infrastructure Management Interaction with Other Blocks........................................ 86 FIGURE 40: Functional components for City Infrastructure Management ............................................. 86 Figure 41: City Infrastructure Management, Detailed Interaction with Other Functional Blocks 87 Figure 42: Detailed view of City infrastructure Management Module ..................................................... 87


ClouT – 30/09/2014

Figure 43: Computing and storage Interactions with other blocks. .......................................................... 89 Figure 44: FUNCTIONAL COMPONENTS FOR COMPUTING AND STORAGE .......................................... 90 Figure 45: Computing and Storage Architecture ............................................................................................... 91 Figure 46: Interoperability & City Resource Virtualisation .......................................................................... 93 Figure 47: Interoperability Architecture............................................................................................................... 93 Figure 48: City Resource Vitrualisation Architecture ...................................................................................... 94 Figure 49: Interoperability & City Resource Virtualisation, Interactions with other blocks .......... 96 FIGURE 50: FUNCTIONAL COMPONENTS FOR SENSORISER AND ACTUATORISER............ 97 Figure 52: IoT Kernel Interactions with Other Blocks ..................................................................................... 99 Figure 53: Functional Components for IoT Kernel ........................................................................................... 99 Figure 54: IoT Kernel Block ..................................................................................................................................... 100 Figure 55: Iot Device Wrapping Block ................................................................................................................. 102 Figure 56. Main Functional blocks for City Platform layer ......................................................................... 104 Figure 57: City Service Composition Interactions with Other Blocks .................................................... 105 Figure 58: Functional Components of the City Service Composition ..................................................... 105 Figure 59: Development and Deployment Platform Scalability ............................................................... 107 Figure 60 - Service Composition components ................................................................................................. 108 Figure 61 - Service Composition Interactions .................................................................................................. 108 Figure 62: City Data Processing Interactions with other blocks .............................................................. 110 Figure 63: City Data Processing Architecture .................................................................................................. 111 Figure 64: City Resource Access Interactions with Other Blocks ............................................................ 113 Figure 65: Functional Components for City Resource Access ................................................................... 113 Figure 66: City Resource Access Platform Interactions ............................................................................... 114 Figure 67: Security and Dependability Interactions with Other Blocks ................................................ 115 Figure 68: Functional Components for Security & Dependability ........................................................... 116 Figure 69: Security & Dependability Platform Interactions ....................................................................... 116 Figure 70: Encrypting Facility Platform interactions ................................................................................... 117 Figure 71: Dependability monitoring Interaction with Other Blocks .................................................... 118 Figure 72: Interaction with ClouT reference architecture in Traffic Mobility Management Use Case .................................................................................................................................................................................... 121

LIST OF TABLES

Table 1. List of abbreviations ..................................................................................................................................... 10 Table 2. Services Terminology .................................................................................................................................. 11 Table 3. Entities Terminology .................................................................................................................................... 11 Table 4. Transform/Function/Properties Terminology ................................................................................. 14 Table 5: ClouT User Scenarios ................................................................................................................................... 21 Table 6: User/Service Requirements ...................................................................................................................... 54 Table 7: System Requirements .................................................................................................................................. 62

LIST OF ABBREVIATIONS

TABLE 1. LIST OF ABBREVIATIONS

API Application programming interface CIaaS City Infrastructure as a Service CPaaS City Platform as a Service CSaaS City Software as a Service DoW Description of Work, Annex II to the Grant Agreement ID Identifier IoT Internet of Things IoT-A Internet of Things – Architecture LDAP Lightweight Directory Access Protocol CDMI Cloud Data Management Interface NIST National Institute of Standards & Technology's


ClouT – 30/09/2014

TERMINOLOGY USED IN CLOUT

TABLE 2. SERVICES TERMINOLOGY

Terminology Definition Examples

CIaaS A model that provides virtualized city resources (sensors, actuators, storage, etc.) as a service.

Open city data as a service

CPaaS A model that provides city computing platform (event processing, mash-up tools, etc.) as a service.

City application development tools

CSaaS A model that provides city application software (city event analyser, public space management, etc.) as a service.

Participatory sensing, context-aware city applications

IaaS A model that provides virtualized computer resources (CPU, network, storage, etc.) as a service.

Amazon EC2, Amazon S3

PaaS A model that provides computing platforms (OS, Executable runtime, databases) as a service.

Google App Engine, Windows Azure

SaaS A model that provides application software (CRM, Email, communication) as a service.

Salesforce.com, Gmail, Google docs

Service A functionality offered by a computing entity via well-defined access interfaces to perform a given task

Web services, J2EE services, OSGi services

TABLE 3. ENTITIES TERMINOLOGY


Action Resource A City Resource which can be used as actuator in the city.

Virtual City Light

Actuator An electronic hardware that acts on a physical property. The term actuator is used interchangeably as an IoT device with actuating capabilities.

Light, Display, Speaker, Shutter, heating devices

Actuatorised Web Application

A web application which is able to be used as a concrete actuator.

Dynamic update of a web page

Big Data It identifies data, typically a large amount of data that needs “ad hoc” software to be managed.

Steaming data from sensors, web transactions, uploaded pictures


ClouT – 30/09/2014


City Action An action which controls action resource in the city.

Turn-on, display

City Data A generic term for representing data which is generated by sensors and web related to the city.

Presence information, city events, data captured by citizens

City Infrastructure Entity (CIE)

Representation of any physical or virtual entity providing data streams or actions.

IoT devices, web applications

City Infrastructure Service

A service that virtually represents a City Infrastructure Entity and exports means to access to Virtualized City Resources exposed by the service.

Light Service, Temperature Service, Presence Service

City Resource A resource of city which is represented by city infrastructure service. It is classified to Data Resource and Action Resource.

Virtual City Temperature, Virtual City Light

Cloud Storage It is a service of data storage, typically file based, where the data is distributed into virtualized servers.

OpenStack Swift, Ceph, GlusterFS

Data Resource A City Resource which can be used as city data generator.

Temperature, presence information, luminosity, humidity

Device Any computing equipment with possible communicating and storage capabilities.

Computer device, IoT device, legacy device

IoT Device A device that incorporates new generation, mostly wireless, communication capabilities, and possibly sensors and actuators.

Zigbee, 6LoWPAN devices, communicating home appliances, networked cameras, etc.

Legacy Device A device that belongs to an “old” pre-existing infrastructure that is already deployed and will be reused after adaptation by the ClouT system. It can provide sensing or actuating capabilities

Traffic light system, SCADA systems, street light regulators

Legacy Web Application

A pre-existing web application that will be reused after adaptation by the ClouT system.

City web services

Metadata A metadata is a collection of attributes that describes more in detail the data that it is associated with.

Timestamp, unit, owner, location


ClouT – 30/09/2014


Networked Legacy Device

A legacy device which turned into being connected to the Internet.

City information displays, weather stations,

noSQL Database It identifies a database that is not SQL based. It identifies a no relational database (NRDBMS).

Apache HBASE, Cassandra, MongoDB

Open Data Data which is freely accessible through the Internet via well defined interfaces.

Government public data, municipality public data

Sensor An electronic hardware that detects or measures a physical property. Here the term is used interchangeably as an IoT device with sensing capabilities.

Temperature, humidity, presence sensor

Sensor Data Data stream which is generated by any city infrastructure entity (Sensors, sensorised web applications, sensorised legacy devices, etc.).

Temperature data, humidity, presence information flow, city events flow

Sensorised Web Application

A web application which is able to be used as a sensor.

Twitter, Facebook likes, etc.

Social Network Application

A web application which purpose is to connect people in consideration with their social relationship.

Facebook, Twitter, Foursquare

Virtualized Actuator An entity which provides actuation function according to defined actuator capabilities. It is mapped to a concrete actuator at runtime.

Byproduct of ClouT virtualisation Functionalities

Virtualized City Resource

A virtualized resource in terms of either sensor data, computing capabilities or an action exposed by City Infrastructure Service.


Virtualized Sensor An entity which provides sensor data stream according to defined sensor capabilities. It is mapped to concrete sensor at runtime.


Virtualized Storage An entity which provide sensor data history according to defined storage capabilities. It is mapped to concrete storage at runtime.



ClouT – 30/09/2014

TABLE 4. TRANSFORM/FUNCTION/PROPERTIES TERMINOLOGY

Terminology Definition Input Output

Abstraction A method to abstract sensor node platform to provide programming capability by various languages.

Specific sensor node hardware resources

Abstracted sensor node

Actuatorisation A transform method to change legacy web application to actuatorised web application (or actual transformation using the method).

Legacy web application

Actuatorised web application

Data Processing A method to compute data. Raw data High level data

Decision Making Decision making can be regarded as the cognitive process resulting in the selection of a course of action among several alternative scenarios.

Events, conditions and rules

Action or a choice

Dependability Capability for monitoring, fault and error detecting and recovering mechanism.

Dependability requirements

Dependability insurance

Event Processing A method to process data/events to detect higher level event.

Raw events Complex events

Hosting A method to provide accessibility to sensor data stream and history.

Query Sensor data streaming /history

Mapping A method to map virtual resources. Virtual resources

Physical resources

Mash-up Creating a high level service by co-operating several services.

Different services

High level service

Self-binding The process by the way of which the system ensures automatic connections of inter-dependent services in the system.

Required and exposed services

Bound services

Self-discovery The process by the way of which the system ensures that all reachable and recognizable physical resources are discovered and integrated to the system.

Service needs, service repository

Discovered services

http://en.wikipedia.org/wiki/Cognition


ClouT – 30/09/2014

Terminology Definition Input Output

Self-healing A method to auto-repair an IoT error or failure.

Abnormal situation of sensors

Normal situation of sensors

Self-identification The process by the way of which the system ensures the suitable virtual representation of a physical resource in the system (i.e. the features of the physical resource are accessible through its virtual counterpart) and provides a formalized description of those features allowing functionalities discovering.

Information on resources

Formalized descriptions

Semantic Interoperability

Interoperable capability on function among different formats of sensor data by utilizing meta data.

Different format of sensor data

Interoperable sensor data

Sensorisation A transform method to change legacy web application to sensorised web application.

Legacy web application

Sensorised web application

Service Composition A method to combine different services as one service.

Different services

Composite service

Syntactic Interoperability

Interoperable capability on communication among different operations of sensor nodes.

Different syntactic

Interoperable syntactic

Virtualisation A method to create virtual resources corresponding to physical resources.

Physical resources

Virtual resources


ClouT – 30/09/2014

EXECUTIVE SUMMARY

This document describes the consolidated and final version of ClouT Reference Architecture. It starts from a set of User Scenarios derived from the Use Cases described in the Deliverable 1.1 and categorized in order to point out the various application contexts. The defined categories are:

Smart City Resource Management (SCRM): in which it is shown how to manage several heterogeneous resources (sensors, actuators, smartphones, cars, bus etc.) in an unified manner to share information and to improve the efficiency of a Smart City

Safety and Emergency Management (SEM): in which ClouT approach is used to minimize the risks due to natural events (weather, earthquakes etc.) or accidents (due by traffic, crime etc.) by combining data coming from sensors and people (acting as human sensors)

Citizen Health and Pleasant Enhancement (CHPE): with the purpose to inform and motivate citizens to take part in public events (cultural, sports etc.) in the city, by collecting and classifying information coming from citizens and municipality.

A set of User/Service Requirements and System Requirements has been obtained from the analysis of these User Scenarios and the experience of the partner involved in the project, including the pilot cities (Genova, Santander, Fujisawa and Mitaka). User/Service Requirements have been explicitly associated to the User Scenarios demonstrating that ClouT approach meets them and have been classified according to the impacted architectural component. In particular:

ClouT Service Layer must provide service availability and simple interface, in particular for elderly people

ClouT Platform Layer must enable users to access and share several kinds of data: these data should be related to city context, location aware and should be used by citizen and municipalities

ClouT Infrastructure Layer must enable to store data in a way compliant with Privacy and Security laws of different countries, support quasi-real time and location independent access to heterogeneous city resources (e.g., support different kinds of sensors and actuators).

The overall system must guarantee scalability, availability and capability to react to load peaks. The sensors, including legacy devices, must communicate in a common data format regardless to the actual kind of data (from images to temperature). Data replication and backup must be available and security and good performances must be guaranteed.

According to these requirements ClouT Reference Architecture is described. The model is Cloud centric, i.e. IoT features are supported by modules based on cloud layers: IaaS, PaaS and SaaS,

City Infrastructure As A Service layer (CIaaS) provides features such as infrastructure management, computing and storage as a service, virtualisation for city resources such


ClouT – 30/09/2014

as IoT devices, legacy devices and web applications (such as social networks), which are considered as particular IoT devices

City Platform As A Service layer (CPaaS) provides APIs to access city infrastructure and city resources and offers tools for city service creation. Moreover, at this level the city behavior is managed (e.g., how actuators react to certain contextual conditions).

City Software As A Service layer (CSaaS) enables users to build their city applications by using CPaaS APIs and to consume services built upon ClouT’s infrastructure.

The architecture defined is finally mapped in real world scenarios that have been conceived to involve all the modules and to show their functionalities.

Finally some considerations are presented to demonstrate how ClouT approach, that combines IoT, Social Networks, Open Data and Cloud is an efficient and cost-effective answer that enables even small cities to become Smart.


ClouT – 30/09/2014

1. Introduction

1.1. Scope of the Document

This document presents the final version of the use cases, user/system requirements and the ClouT reference architecture. This deliverable contains a revised version of the deliverable 1.2 that has been improved based upon several internal and external feedbacks. This deliverable will provide an input for the WP2 and WP3 technical work and a blueprint for the implementation of the technical components. It will also guide the WP4 deployments and trials with the use cases and user requirements herein identified.

1.2. Target Audience

The document is addressed to the following groups:

Municipalities can check the use cases presented in this deliverable and apply the scenarios in their respective cities

City ICT system architects can build a smart city architecture based on the system requirements and ClouT architecture presented in this deliverable.

Smart City Ecosystem integrators leverage ClouT Reference Architecture and reuse the proposed reusable components from IoT and Cloud technologies presented in this deliverable

ClouT project members will employ this document which provides the definitive requirements, the final Reference Architecture and all proposed reusable components that present the basic concepts and tools to complete the other technical work packages, including the field trials within pilot cities.

1.3. Structure of the Document

Aside from the Introduction Chapter 2 contains the revision of use cases and user/service requirements – described in the Deliverable 1.1 – Use Cases and User Requirements - and the consequent review and finalization of system requirements, of which a first draft was already presented in the Deliverable 1.2 - First version of Reference Architecture and Reusable Components.

Chapter 0 contains the preliminary results and analysis of the stakeholders’ and citizens’ surveys aimed at weighting the perception of usefulness and priorities concerning ClouT scope and applications.

Chapter 4 is focused on the final ClouT Reference Architecture description, in particular:

an overall architecture overview

a finer grained overview of the City Infrastructure as a Service and City Platform as a

Service models


ClouT – 30/09/2014

a description of each functional block, its interaction with other blocks and details about

its functional components.

a definitive list of reusable components, based on the results of Deliverables 2.2 and 3.2.

Chapter 5 describes an example of how the reference architecture components maps and acts relatively to a real world scenario derived from field trials.

Finally, Chapter 6 highlights the results of the analysis and the main features of the final ClouT Reference Architecture.


ClouT – 30/09/2014

2. Final User Scenarios & Requirements

2.1. Introduction

This chapter contains all user scenarios and requirements (user/service and system) derived from D1.1 and D1.2, revised and extended according to internal and external feedbacks from stakeholder meetings and surveys performed during last year.

The objective of this revision work is to highlight those aspects of the Cloud Computing model and technologies that can takle many challenges that the IoT paradigm brings and improve the effectiveness of a Smart City architecture: all results are based on real needs extracted directly from scenarios within pilot cities.

2.2. Smart Cities Applications and High Level User Scenarios

This section will describe some high level user scenarios and smart city applications which can be efficiently developed by using ClouT platform. First, the actors mainly involved in all scenarios will be presented: every actor interacts with some specific components of ClouT architecture. Then, the proposed scenarios will be detailed: each scenario is associated to a Smart City application to provide a concrete demonstration of the suitability of the ClouT approach. Some of them are based on already existing and used applications. The introduction of the ClouT approach in these cases will dramatically improve their quality by solving several technological limitations and issues. The proposed scenarios will identify these issues and show how the ClouT approach covers the gaps.

The proposed scenarios have been defined starting from the work done in the first part of the project. They represent the evolution of those scenarios presented in D1.1 and give emphasis to the importance of the Cloud in the ClouT approach. A categorization based on the context has been introduced and the relationship with the user scenarios presented in D1.1 has been preserved and made explicit.

Table 5 shows the list of categorized user scenarios, in particular the six scenarios are classified into three categories: Smart City Resource Management (SCRM), Safety and Emergency Management (SEM), and Citizen Health and Pleasant Enhancement (CHPE). Each user scenario defines an associated application which is described by detailing the building blocks and the involved actors. Finally, the objectives and challenges, which are the reasons for considering these applications as pilots for ClouT, are highlighted.


ClouT – 30/09/2014

Category User Scenario ID User Scenario Name Related Scenario ID in D1.1

Smart City Resource Management

SCRM_1 Traffic Mobility Management

UCA1/UCA5

SCRM_2 IoT Device Sharing and Composing

UCA4

Safety and Emergency

Management

SEM_1 City Safety and Accident Management

UCA3

SEM_2 Weather Risk and Alert Management

SEHM1

Citizen Health and Pleasant

Enhancement

CHPE_1 City Event Finder PS1/UCA2/SEHM2

CHPE_2 Citizen Activity Enhancer

PS2/SEHM3

TABLE 5: CLOUT USER SCENARIOS

2.2.1. Involved Actors

In order to better define the scope of the interactions between the city actors and ClouT architecture, the users that play a role in the smart city scenarios detailed in this document have been identified and categorized. Three main categories have been identified:

Citizens and Municipality Users – main actors in every smart city scenario, especially in ClouT’s user centric approach, citizens and municipality users are both consumers of all the applications and services built upon ClouT platform and data providers through ClouT’s sensorisation capabilities, collaborating with their portable devices, interacting with smart city apps or simply sharing information via social networks

Muncipality and Third Party Developers – building on ClouT’s infrastructure and platform layers, municipality and third party developers are the actors that actively develop the applications and the services that are going to be consumed by end-users. ClouT includes PaaS solutions that offer Cloud scalable development & runtime environments, meeting specifically smart city developers’ needs.

System Administrators/Infrastructure Providers – Infrastructure Providers and their System Administrators represent the foundation on which a smart city is built. Municipalities may be customers to Cloud and IoT service providers, may own the required infrastructures themselves or may employ a mix of both private and public/third party infrastructures. All required functionalities to adapt protocols, manage computing and IoT infrastructures, discover new devices and services are described in ClouT’s Reference Architecture.


ClouT – 30/09/2014

The simplified use case diagram in Figure 1 shows the associations between the actors described and the functionalities provided by the three main architectural elements of ClouT (described as use cases). Citizen and Municipality Users are mainly interested in applications for making easier the life in the city, at CSaaS layer. Developers can create their original application by using virtualized city resources/data which are provided in CIaaS layer and leverage the CPaaS layer. System Administrators (SysAdmin) can register IoT devices and platforms to take advantages of ClouT platform such as virtualisation, Sensorisation or secure access functions. Thus, SysAdmins can setup their system based on virtualized IoT on Cloud computing environment efficiently: they leverage the features of the whole cloud stack.

FIGURE 1: RELATIONSHIP ACTORS/CLOUT LAYERS

The sequence diagram in Figure 2 shows how applications, ClouT Platform and IoT devices interact with the actors presented above. It represents the starting point for the user scenarios that will be described in the following sections.


ClouT – 30/09/2014

FIGURE 2: SEQUENCE DIAGRAM ABOUT INTERACTIONS BETWEEN ACTORS, CLOUT AND DEVICES

2.2.2. Smart City Resource Management

This section describes the first category of smart city applications, called smart city resource management. Many city resources are currently not managed efficiently: each system is separated and isolated, so that users and developers have to care about specific system usage or APIs. Smart city resource management use cases enable Users/Developer/Sysadmin to use city resource easily and efficiently by integrating and abstracting access to those available resources. For resources, it is not intended only sensors or actuators deployed at specific places, but also mobile resources such as smartphones, moving connected objects like cars, bus and trains. To manage these resources in unified manner and to share them with various users/cities is critical for the future of smart cities, in order to avoid more fragmentation and increase the power and quality of the offered services. In the following sections, we introduce two particular scenarios: Traffic Mobility Management (SCRM_1) and IoT Device Sharing and Composing (SCRM_2).


ClouT – 30/09/2014

2.2.2.1. Traffic Mobility Management

ID: SCRM_1

Title: Traffic Mobility Management

User Scenario Description

Smart traffic mobility management concept is considered as one of the solutions that would

enable citizens and visitors to get access to enhanced urban mobility experience and to leverage

city transportation resources efficiently. The availability of a great amount of information

associated to the use of public transportation currently fosters the improvement of this concept.

Information about public buses fleet, buses schedule, position, speed, estimated time to stop,

occupancy, expected travel time, will be leveraged and combined on a single application. This

application will also contain information on available taxis, available public cycles or specific

friends’ routes. All this data can be also combined with information regarding traffic parameters,

such as speed, occupancy degree, as well as with environmental indicators such as CO2, NO2, O3,

noise; all of them provided by the static deployed devices at main places of the city or

streetlamps all over the streets or on mobile devices such as the public vehicles or the citizen

smart phones. Additionally, traffic sensors (measuring speed, occupancy degree, number of

vehicles) located under the asphalt in the main entrances of the city, as well as the street

webcams installed in different zones of the city offer useful information.

All the aforementioned data, suitably processed, allows offering the users (according also to

their preferences) recommendations on the best route towards their destinations at each

moment, providing also an enhanced public transportation experience, dynamically adapting to

user requirements according to current urban conditions.

Additionally, with the gathered information, it is possible to generate alerts about urban traffic in

the city and the availability of places in public car parks, as well as providing a set of services

related to available car park locations and information services, based on traffic density

supervision provided by traffic sensors located under the ground on the main traffic backbone of

the town that permits to collect and communicate data, as well as services related with street.

Additionally, the traffic management will also provide real-time traffic information (Webcam, Video

Message System, Alarms and Events) to the citizens. Any event will be highlighted by colored icons on

a map and it will appear inside a list. SysAdmin can also publish alarms and events and trigger email

to interested stakeholders including public transport operators, local authorities, etc.

The aforementioned capabilities will be offered in two different applications: multimodal

transportation service providing optimal route according to a user request, and augmented

mobility point showing all urban traffic related events in a friendly way to the user

The simplified use case diagram in Figure 3 shows how the relationships between the actors

defined above and the use cases included in the user scenario. Citizens can request optimized


ClouT – 30/09/2014

route for traveling in city, and the application sends results of the selected route. SysAdmins or

Developers such as Traffic Company can check traffic condition in the city, so that they can

understand the dynamicity of the city in real-time. In addition, they can control traffic level by

controlling various actuators in city such as traffic lights. If it is difficult to reduce traffic level

only by controlling such devices, Municipality or Traffic Company can make a decision to

increase or decrease the offered transportation service (e.g., sending off additional buses in

crowded zone). Through this scenario, city can enhance manageability of transportation city

resources, and citizen can use the traffic resource efficiently.

FIGURE 3: SIMPLIFIED USE CASE DIAGRAM OF TRAFFIC MOBILITY MANAGEMENT

Main Actors

The main stakeholders to be considered within this scenario are the following ones:

- User (Citizen): Citizens and visitors are provided with efficient routes according to traffic

and environmental parameters, as well as to the suitability of the mean of transport to be

used. For citizens, parameters like their scheduled routines and their friends’ routes can be

also considered in order to calculate the most convenient route for a determined user. For

visitors, preferences according to visiting more important points of interest of the city can be

also taken into consideration to get efficient routes. It is clear that shortening and optimizing

the transportation time has a clear impact on improving the city perception of the users.

Furthermore, users could monitor different events that occur in the city in a graphical way.

- Developer (Third party service provider): For third party service developers, several

applications can be developed offering different alternative routes to the users according to

the specific conditions indicated by them, such as the traffic circumstances, environmental

care policies or the user preferences.,.


ClouT – 30/09/2014

- SysAdmin (Traffic Company/Municipality): Logically, the efficiency of transportation

companies will be increased, as an application could be designed for balancing (in real time)

the necessities in terms of vehicles, staff, considering user requirements and preferences to

user requirements (i.e. good weather implies more people going to the beach),specific city

events (spectacles, sport events) as well as traffic/parking conditions, thus allowing a

dynamic resource allocation and avoiding inefficient performance peaks and valleys. On the

other hand, Municipality can offer a real time map of the status of transportation within the

city, including coloured alarms and events, thus allowing a dynamic reaction to the changing

situations that can be occurred along the day. Additionally, these applications could

contribute to envisage future direction of city planning.

Detailed scenario and main supporting blocks

Figure 4 shows the sequence diagram of traffic mobility managerment scenario. To understand

context of traffic level in city, various IoT devices send environmental information to ClouT

platform. Then, by analysing several sensor data, Traffic Management Service can recognize

traffic level. Based on the recognized information, the service can recommend optimized

traveling route for citizens. The users can request the route information by using their

smartphones or public display with intuitive interfaces. Also, SysAdmin and Developer can check

current traffic level by using full-functional application in computer and also can request IoT

control operation through ClouT platform. All this information can be clearly visualized in

coloured icons, differentiating among the type of information offered to users, SysAdmin and

Developer.

FIGURE 4: SEQUENCE DIAGRAM OF TRAFFIC MOBILITY MANAGEMENT


ClouT – 30/09/2014

Objective and Challenges for ClouT

The purpose of the above mentioned use cases is to use contextual information to generate a

visual exploration of the city for mobility purposes while providing users with best estimated

route towards a destination taking into account traffic conditions, vehicles location and

environmental parameters. These use cases will highlight the challenge of integrating various

sources of information (from the citizen perspective), as well as the need to have an always

updated context of the city mobility to instantaneously evaluate optimal path throughout the city

with multiple vehicles. Some security related challenges arise such as:

Authentication - Rigorously protect information from unauthorized use

Data Encryption – Data stored locally and data in transit should be encrypted

Persistent Data – Apps can be designed to maintain some data on the device itself

Besides, ClouT Platform should be designed to minimize impact on local ICT sub-systems and

networks and provision the enterprises accordingly with an easy deployment scheme

Assumptions

Users have Smartphone with a mid-level GPU or better.

The user devices have are connected (both Wi-Fi or 2G/3G/LTE are suitable)

Users can interact with the Service both with a Smartphone and a web interface.

The interface is compliant to the notion of NUI1

End users devices should have integrated sensors such as GPS and accelerometers,

Users are allowed to send their own specific requirements and contextual data to the

Service.

The Service manages received contextual data as per existing security and privacy laws

and regulations in order to notify the users with the calculated route when it is available.

User/Service Requirements for the Reference Architecture

Taking into consideration the particularities of the aforementioned use cases, they can be

identified the following user/service requirements:

UR1SCRM_1: User shall be provided with visual similarity-based services.

UR2SCRM_1: Interface for the Smartphone end-user: the user shall be able to intuitively and

1 http://en.wikipedia.org/wiki/Natural_user_interface


ClouT – 30/09/2014

easily shared his device and create applications via application creation tools.

UR3SCRM_1: The user's ability to control the level of contextual information sent to the service

shall be assured/guaranteed in order to allow the required accuracy in the service

provisioning.

UR4SCRM_1: Location based services and mobility data shall be automatically integrated and

available to the Municipalities

UR5SCRM_1: The user shall be able to create personalised mobility routes based on his

personal requirements.

UR6SCRM_1: User and Municipality data stored within the ClouT platform shall be compliant

with Security and Privacy laws and regulations of their country.

UR7SCRM_1: The Municipalities shall be provided with IoT devices which are secure against

physical access, interference and altering.

UR8SCRM_1: The user shall be able to access to an heterogeneous set of Sensors over a wide

geographical area, hybrid localisation (gps, gprs, wi-fi, webcam) services (multi-sensors

integration and outdoor/indoor), communication and networking capability for Street

equipment actuation.

UR9SCRM_1: The Municipality shall be provided with access to an heterogeneous set of sensors

(statics and on-board of mobile vehicles), in order to define the corresponding routes.

UR10SCRM_1: The Municipality shall be enabled to use additional non-IoT data sources from the

city environment and the citizens (legacy devices and Social Networks).

2.2.2.2. IoT Device Sharing and Composing

ID: SCRM_2

Title: IoT Device Sharing and Composing


By sharing IoT devices owned by end-users, we can easily increase the sensing and actuation

scope in a city. This can allow collaborative detection of important city events or provision of

more precise information by exploiting the multi-source information coming from various

devices. This user scenario provides sharing function of IoT through cloud computing platform.

As shown in Figure 5, Users, SysAdmins and Developers can freely share their devices and use

shared devices by protecting their security and privacy. They can get sensor data from shared

devices, or control actuators such as street light with appropriate accessibility rules. In addition,

composing functions for using data coming from multiple shared IoT devices are provided:

SysAdmins and Developers can define set of shared devices as virtual and composite IoT devices.

Thus, it will be easy to manage and create their original smart city applications with this use

case.

Besides end users, the municipalities can also monitor the physical devices (sensors, actuators,


ClouT – 30/09/2014

gateways, but also infrastructure components) by using this functionality. In particular the

SysAdmin can watch and map all the sensors and actuators in order to have a complete view of

the current status of the IoT devices.

An overview of what it is happening inside the devices can also prevent potential failures: in this

way it is possible to avoid physical gateways overcomitting that could disrupt data gathering and

communication between the connected devices and all the related services.

Such monitoring capabilities can be extended to virtual and composite IoT devices via custom

monitoring scripts that are capable of sending alerts if errors occur.. This kind of tools are

necessary in order to manage a complex system with many devices connected.

FIGURE 5: IOT DEVICE SHARING AND COMPOSING

Main Actors

The main stakeholders to be considered within this use case are the following:

- User (Citizen): Citizens can share their equipment in home for public usage. For example,

environmental monitoring sensors in their garden can provide air condition or temperature

in fine-grained granularity in city.

- SysAdmin (Municipality): SysAdmins can also provide public sensors information for

citizen and developers. For example, if garbage collection car, which moves around in city, is

equipped with sensors and share the sensor information with everyone, citizen can

understand details of environmental status in city. Not only sensors, but also actuators such

as public light/electric fan can be target of sharing devices. SysAdmin has a complete view of


ClouT – 30/09/2014

the current status and to map all the CIaaS components with a simple web interface.

- Developer (Third Party): Developers take advantages of sharing devices/data in order to

obtain information for creating applications. They can, not only reuse sensor data gathered

from those devices, but also reuse actuating functions in the city such as public displays.


Figure 6 shows the sequence diagram of this scenario. As explained in the use case diagram,

Users (Citizen) and Sysadmins (Municipality) can share their IoT devices in the ClouT platform.

Then, IoT devices can send sensor data to the ClouT platform where the data can be stored.

Scalability and reliability are important aspects for this scenario: in particular ClouT platform

must manage an increasing number of devices in an efficient way. Cloud elasticity provides an

efficient and cost-effective way to manage these aspects: this will allow also citizen of small

municipalities, with limited budget, to take advantage of the services provided by Smart Cities. In

addition SysAdmin and Developer can compose IoT devices hy using composition function at

both CIaaS and CPaaS layer. At CIaaS layer, virtualisation-based composition should be

supported, and at CPaaS layer, service-level composition should be supported. By using these

functions, Developers can create applications covering wide areas of the city easily and

efficiently without paying heavy cost. This must boost up the city’s usability more and more.


ClouT – 30/09/2014

FIGURE 6: SEQUENCE DIAGRAM OF IOT DEVICE SHARING AND COMPOSING


This user scenario will provide new business properties for application developers that can

reuse contextual information shared by the users and build applications on top of them. This is

also an opportunity for platform providers to host those applications and provide data as a

service. Even citizens could get involved in the revenue sharing if adequate business models can

be built. Following challenges arise for ClouT:

City resource management

IoT device virtualisation in cloud computing environment

Resources allocation

Intuitive Interface

City data management


ClouT – 30/09/2014

Interoperability

Scalability (Millions of device and data from city)

Data composition(Different types of data should be composed easily for various

applications)

Assumptions

Users wish to share access to his/her devices with others based on various policies and

contextual information

Either devices are configured to be ClouT compatible or a gateway makes the device

accessible by the ClouT system

User has a valid account on the ClouT’s sharing platform.


Taking into consideration the particularities of the aforementioned use case, they can be

identified the following user/service requirements:

UR1SCRM_2: Interface for the Smartphone end-user: the user shall be able to intuitively and


UR2SCRM_2: The user shall have the complete control on who he/she wants to share

his/her devices with and on which conditions.

UR3SCRM_2: The service owner (Municipality) shall be able to propose some kind of

incentive to the user that shares his data through a certain app.

UR4SCRM_2: The user shall be able to take adantage of the ClouT platform services without

any noticeable lag, indipendently to the number of concurrent users that are consuming

the same services (e.g. due to particular events in the municipality).

UR5SCRM_2: The user's security and privacy should be protected and be of high

importance to the device sharing platform.

UR6SCRM_2: The user should be able to get responses to his/her requests in quasi real-

time

UR7SCRM_2: The Municipality shall be able to easily identify, discover and manage

resources within the city.

UR8SCRM_2: The Municipality shall be able to deploy ClouT platform to reduce/minimize

costs and avoiding vendor lock-in, possibly employing open source software and

hardware

UR9SCRM_2: The Municipality/citizen shall be able to constantly monitor the status of the

Smart City's resources.


ClouT – 30/09/2014

2.2.3. Safety and Emergency Management

This section describes the second category of smart city applications in ClouT, called Safety and

Emergency Management. Risks in the city can be mainly classified into two categories: artificial

risk and natural risks. The former, artificial risks, are caused by humans such as car accidents

and criminal acts; the latter, natural risks, contain events like weather disasters or earthquakes.

Managing those risks and providing safety is one of the most important goals for smart city

applications. Thus, this user scenarios category provides those safety and emergency

management services based on IoT and cloud computing technology.

2.2.3.1. City Safety and Accident Management

ID: SEM_1

Title: City Safety and Accident Management


This user scenario provides management services for non-natural risks. Figure 7 shows that the

Citizen can search for safety information such as criminal information in the city. In addition, the

Citizen can act as human sensor (participatory sensor) which reports actual accident or self-

feeling about risks in the city. Another important risk factor is traffic accidents such as car

accidents (both car-car accident and car-human accident): it is a very big risk factor, for example

in narrow roads where both people and car can pass, that are very common in Japan, but also in

some European cities. This user scenario takes care of such situations by including use cases in

which alerts to pedestrians are sent in order to take care of passing cars detected by the system.

At the same time, car drivers can also know existence of pedestrian in the same street. The

status of the street is detected by various sensors and street lights and smartphones can be used

to control the traffic and send alerts.


ClouT – 30/09/2014

FIGURE 7: CITY SAFETY AND ACCIDENT MANAGEMENT

Main Actors

The main stakeholders to be considered within this use case are the following ones:

- User (Citizen): Pedestrian is one of main targets of the use case. Especially, the system has

to care for blind people or elder people to prevent various accidents.

- User (Municipality): Municipality officer in criminal section or traffic section can report

important risk to the service through ClouT platform.


Figure 8 shows the details of the interaction between system components and actors. Safety

Management Service calculates risk information by using two data sources – human

participatory sensors and physical IoT sensors. The combination of each sensing source enables

the service to understand risks from diverse point of view. Users (Citizens and Municipality) can

report risks by using participatory sensing functions of the ClouT Platform. Those qualitative

data are collected from IoT sensors, and stored into cloud storage. Based on historical and real-

time analysis performed in ClouT platform, safety management services recognize the risk and

alert the users in appropriate timing. ClouT platform provides appropriate way of alerting users

such as flashing street light or displaying information on the personal smartphones/public

displays. In more details, the functions of controlling various kinds of city resources are provided

based on above use case (SCRM_2). The features of such a user scenario may lead to sudden


ClouT – 30/09/2014

increases of information in the city in certain periods of the year or hour of the day: cloud

scalability and elasticity are the best cost-effective solution to manage these aspects.

FIGURE 8: SEQUENCE DIAGRAM OF CITY SAFETY AND ACCIDENT MANAGEMENT


This user scenario will provide more safety and secure city life which will be necessary

according to increasing population in city area. For safety and accident management, we have to

analyse city risks from various points of view - not only data from environmental sensors but

also data from human sensors or SNS. Therefore, the objective of ClouT in this scenario is

effective integration of various sensing system in city by removing noises in human-based

sensors. In addition, according to the sensing orchestration, ClouT system should control various

actuators to prevent accidents in the city rife. More specifically, following challenges arise for

ClouT:


ClouT – 30/09/2014

Data orchestration

Integrated sensing (IoT and participatory sensing can be combined for recognizing city

context in terms of quantitive and qualified points of view)

Noise removing (various noises in sensor data should be removed for efficient data

analysis)

City actuation

Data visualization (various city data should be visualized intuitively to enable users to

understand city context)

Public actuator controlling (various city actuators such as public display, street lights or

speaker should be controlled appropriately according to city contexts)

Real-time understanding of streets’ context by analysing various public infrastructure

devices

Controlling public infrastructure devices such as street lights and camera according to

street situation

Balancing security, safety, privacy and efficiency of public infrastructure devices

Assumptions

Various public infrastructure devices are networked

Various public infrastructure devices can be controlled remotely


Taking into consideration the particularities of the aforementioned use case, the following

user/service requirements can be identified:

UR1SEM_1: The user shall be able to take adantage of the ClouT platform services without



UR2SEM_1: User and Municipality data stored within the ClouT platform shall be compliant

with Security and Privacy laws and regulations of their country.

UR3SEM_1: The user should be able to get responses to his/her requests in quasi real-time.

UR4SEM_1: The user shall be able to access to an heterogeneous set of Sensors over a wide





ClouT – 30/09/2014

UR5SEM_1: The Municipality shall be enabled to use additional non-IoT data sources from

the city environment and the citizens (legacy devices and Social Networks).

UR6SEM_1: The Municipalities shall be provided with a common repository (on Cloud

storage infrastructure) to collect different kind of data (e.g. environment measurements,

transportation information, social data) allocated in different databases – with different

access and management features.

UR7SEM_1: The Municipality shall be able to easily identify, discover and manage resources

within the city.

UR8SEM_1: The Municipality shall be able to deploy ClouT platform to reduce/minimize


hardware.

2.2.3.2. Weather Risk and Alert Management

ID: SEM_2

Title: Weather Risk and Alert Management


This user scenario concerns risk management for natural accidents such as typhoon,

earthquake, heavy spot-raining and so on. As for SEM_1, risks are calculated basing on two kinds

of data source – participatory sensing and IoT devices. Thus, as shown in Figure 9, citizen can

report weather condition by using their smartphones (text and photo/video media). In addition,

users can both search weather risks information and receive “push” warnings from the service.

In addition to these basic functions, the scenario enables municipality to set original

participatory sensing tasks which can ask citizens to report current situation by using

questionnaire format. Thus, the system can alert risk information in real-time.


ClouT – 30/09/2014

FIGURE 9: WEATHER RISKS AND ALERT MANAGEMENT

Main Actors

The main stakeholders to be considered within this use case are the following ones:

- User (Citizen): Citizen can act as participatory sensor for reporting weather information.

Also citizen can understand current information by searching it or receiving weather risk

notification. At last Citizen can always be informed on environmental disaster condition

around city area, and can also provide further feedbacks as participatory sensors during

actual environmental disaster such as flooding, earthquakes and typhoon

- User (Municipality): Municipality can ask people for more details about weather conditions

by deploying participatory sensing tasks. The tasks can be deployed as location-aware

virtual sensors in the city. The municipality can create and edit contents of participatory

sensing tasks, such as “please report how heavy of the raining” or “please take a photo of

building damage by earthquake” in unified format.


Figure 10 shows the sequence diagram of the weather risk and alert management scenario. As

for SEM_1, Citizens can act as human sensors by using participatory sensing functions in the

ClouT platform. Municipalities can set and distribute various kinds of participatory sensing tasks

to know more details on weather conditions. IoT devices for weather monitoring send


ClouT – 30/09/2014

environmental data periodically to ClouT platform. In addition, by using open data and social

networks, ClouT platform can collect various big data from the Internet. By integrating and

analyzing these sensor data from various city resources, weather risk monitoring service can

recognize the weather conditions of the city, and send warning to user’s devices or public

devices if necessary.

FIGURE 10:SEQUENCE DIAGRAM OF WEATHER RISK AND ALERT MANAGEMENT


Many people go online immediately after a noteworthy event such as a natural disaster, a traffic jam,

etc. to get news and information about a particular event. This can cause a rapid increase in traffic to

information systems (website, back-end, API, sensors) that provide relevant and useful information,

and may even cause platforms to crash at the moment they are more useful and are increasing their

popularity. Even if it’s not always possible to anticipate such events, it's possible to take advantage of

ClouT cloud based platform in order to handle a sudden surge in traffic if one of them occurs.

The main goal is to obtain scalability in order to meet the changing demands for IT resources.


ClouT – 30/09/2014

Besides following challenges arise:

Legacy data as sensors

Open data Sensorisation (there are many weather information existing as open data, such open data should be used as sensor data)

SNS Sensorisation (weather information can be also reported in SNS: this information should

be used as sensor data)

Data composition (various data from environmental sensors, camera or citizen report should

be composite in an easy way)

Dependability

Scalability (weather sometimes changes dynamically, so user requests also dynamically

change: the system should manage such situation for keeping it’s accesibility)

Error correction (IoT sensors may encounter some troubles such as hardware/software error:

it is necessary to detect such errors quickly and provide a way to recover them)

Assumptions

Municipalities can interact with the Platform through a simple interface

The application requires a working data connection

End users devices should be integrated with sensors such as GPS, accelerometers and

gyroscope

To localize the user, it is necessary to enable GPS function after the start-up

User may need to to share some sensible and private information during emergency

situations and the system acts (and can be audited) on the basis of the current legal

framework


Taking into consideration the particularities of the aforementioned use case, the following


UR1SEM_2: Access of urban and citizen context shall be allowed to the Municipalities in

order to push/pull urban event notifications. Provision and access to personal data shall

be enabled from anywhere, at anytime only by authorised people.

UR2SEM_2: The user shall be able to take adantage of the ClouT platform services without



UR3SEM_2: Both citizens and Municipality users shall be able to access and consume open

data generated from the ClouT Platform

UR4SEM_2: The user should be able to get responses to his/her requests in quasi real-time


ClouT – 30/09/2014

UR5SEM_2: The user shall be able to access to an heterogeneous set of Sensors over a wide




UR6SEM_2: The user should be provided with all the required software necessary to

interact with the platform in a package with automatic updates

UR7SEM_2: The user shall be able to use the platform services even in adverse conditions

UR8SEM_2: The user data should be backed up automatically and recovery options should

be available

UR9SEM_2: The Municipality shall be able to deploy ClouT platform to reduce/minimize


hardware.

UR10SEM_2: The Municipality shall be enabled to use additional non-IoT data sources from

the city environment and the citizens (legacy devices and Social Networks).

UR11SEM_2: The Municipalities shall be provided with a common repository (on Cloud

storage infrastructure) to collect different kind of data (e.g. environment measurements,

transportation information, social data) allocated in different databases – with different

access and management features.


ClouT – 30/09/2014

2.2.4. Citizen Health and Pleasant Enhancement

This section describes the third category of smart city scenarios called Citizen Health and Pleasant Enhancement. The purpose of this domain is to motivate citizens to participate in various public or private activities in cities such as cultural and sportive events. This enhances not only citizen’s pleasant for their city life, but also citizen’s health condition through their body exercises. On the one hand this scenario is focused on finding, classifying and recommending various city events; on the other hand it also includes use cases in which citizens can register their personal activities in order to allow other citizens to participate in them.

2.2.4.1. City Event Finder

ID: CHPE_1

Title: City Event Finder


As shown in Figure 11, in this user scenario citizens can report event information through

participatory sensing functions of the ClouT platform. In addition, similar to SEM_2 scenario,

Municipalities can set original participatory sensing tasks by defining report forms. Users (both

Citizens and Municipalities) can get city event information by search functions. In addition, by

using event classification function of ClouT platform, Users can receive recommended events

according to their profile. Developers can use those events information to build their original

applications.


ClouT – 30/09/2014

FIGURE 11: CITY EVENT FINDER

Main Actors

The main stakeholders to be considered within this user scenario are the following:

- User (Citizen): He/she can report any event in the city associated to a determined topic,

such as public areas, culture and sports as well as subscribe to different alarms or feedbacks

associated to one of the aforementioned topics. This service incentives citizens or visitors to

report incidents or events that require the attention of municipalities: in addition the service

provides them with enough capacity to track the resolution of the problem. In order to

promote users’ participation and involvement in reporting events, some kind of incentives,

for instance in terms of discounts in some parking of the city center or free tickets for

cultural spectacles, can be offered to the end-users.

- User (Municipality): In addition to the role of user (in the same way as citizen does),

Municipality can define and deploy additional sensing tasks for citizen, thus recognizing

more details of the event. This, in turn, contributes to enhance the quality and the

completeness of the services provided by ClouT for the citizens and the municipality.

- Developer (Third Party): Developer can use event information to build their application.

The application can be based on real-world event information – not only existence of the

event but also various properties of the events. By using this information, high-level event

recommendation service or context-aware coupon distribution service can be developed.

Event organizer also leverages event information to understand the popularity of the

organized event.


Figure 12 represents the sequence diagram of the city event finder. ClouT platform collects a big

amount of sensor information in order to recognize events data, such as environmental features

and details collected from the participants (citizens and/or the municipality). It also collects

related information from SNS services such as Twitter, Foursquare, etc. According to collected

information, the system detects existence of the events, and classifies it according to its type, size

or popularity. Detected event information is automatically sent to the citizens and the

Municipality. If the municipality wants to obtain more detailed information on the event, it can

set additional participatory sensing task to citizens. This process can be operated periodically,

and developers can freely leverage event information for developing their applications.


ClouT – 30/09/2014

FIGURE 12: SEQUNCE DIAGRAM OF CITY EVENT FINDER


This scenario shows how the ClouT approach can be used to improve the awareness of events in the

city by leveraging contextual information, either related to the municipality or to the citizen. For

providing information about not only past city events but also current real-time events and future

events, the objective of ClouT is to provide enough data resource from entire city, and also provide

method to analyse the events in real-time. More specifically, following challenges arise for this

scenario.

Understanding the city

City context recognition (it is necessary to provide analysing tool for recognising various city

event including both scheduled or accidental events)

Intuitive interface (easy and intuitive interface on both PC and smartphone should be

developed to enable citizen to use the application easily)

Heterogeneity of data collected and stored in quasi-real-time

Clustering, matchmaking and in general mining of large amount of privacy-concerned data

SNS data has noisy data that may negatively finding urban events


ClouT – 30/09/2014

Physical sensor data and SNS don’t share a common integration platform

Citizen involvement

Smart event recommendation (to provide users with appropriate event recommendations, it

is necessary not only to detect city events but also to classify them in terms of various

indicators)

Evaluation of citizen behaviors’ change (not only just developing applications, but it is also

necessary to evaluate how proposed ClouT application can actually change citizen behavior)

Conflicting security and privacy assurance requirements among municipalities and citizens in

the reporting and dispatching process through multiple – potentially independent – systems

Assumptions

Sensor information on weather and traffic offered on open network

Analysed information of Twitter available to citizens

Digital Divide, Elderly people are technically un-savvy

Citizens have digital devices such as smartphones or tablets

User can report the occurrence of different events in the city: this information will be

treated in accordance with the privacy laws of the city

The Municipality receives the events and process them according to internal business

process, rules and legislation

A transparent legislation applies to the municipality services that empower the users to

access any information associated to the state of the reported incidences/events

Social Network security policies entrust users to share events information, based on

some kind of subscribe mechanism associated to a determined topic/event

Users will use a smartphone/tablet with embedded sensors (at least geo-localisation and

camera) to report events in real time


Taking into consideration the particularities of the aforementioned user scenario, the following


UR1CHPE_1: The proper operation of the user's Smartphone shall be ensured during the

execution of a determined application (no battery drain, no memory drain, no erase

user's files ).

UR2CHPE_1: Interface for the Smartphone end-user: the user shall be able to intuitively and


ClouT – 30/09/2014


UR3CHPE_1: The ederly or impaired user shall be able to access the services through

natural user interfaces.

UR4CHPE_1: The user shall be able to register and cluster any event through a natural

interface.

UR5CHPE_1: The user's ability to control the level of contextual information sent to the

service shall be assured/guaranteed in order to allow the required accuracy in the

service provisioning.

UR6CHPE_1: Provision and access to historical event data and features shall be provided to

the Municipalities in order to be used for trend analysis.

UR7CHPE_1: Access of urban and citizen context shall be allowed to the Municipalities in



UR8CHPE_1: User and Municipality data stored within the ClouT platform shall be

compliant with Security and Privacy laws and regulations of their country.

UR10CHPE_1: The user's security and privacy should be protected and be of high

importance to the device sharing platform.

UR11CHPE_1: The Municipality shall be enabled to use additional non-IoT data sources

from the city environment and the citizens (legacy devices and Social Networks).

2.2.4.2. Citizen Activity Enhancer

ID: CHPE_2

Title: Citizen Activity Enhancer


This user scenario enables users to share their personal activity with other citizens. Users

(citizens or municipalities) can register their activity such as private sports activity or shopping

activities (Figure 13). Developers can also register more complex activities by using several

sensors. Users can then search and participate in activities around them and can receive

certification of participation. The number of certifications can be used as achievement, so that

users can be motivated to participate in more events by gamification effects, and developers can

also use the certification for further application development.


ClouT – 30/09/2014

FIGURE 13: CITIZEN ACTIVITY ENHANCER

Main Actors

The main stakeholders to be considered within this user scenario are the following:

- User (Citizen&Municipality): Citizens are the actors in all the use cases, however, in terms

of health enhancement, elderly people should be the most important actors. Users can

register their activities freely improving the quality of their city life.

- Developer (Third Party): Developers and event organizers can register special activities

which promotes citizen to participate in their organized events. According to the certification

of participation, they also can provide amenity or coupon to the users.


Figure 14 shows the sequence diagram of citizen activity enhancer. Users including citizens,

municipalities and developers can register their activities to the service. ClouT platform

manages the activities by relating corresponding sensor data. The service provides users with

the list of available activities. Users can select and participate in the activities, and the

information on their activities is sent to the service. The service can analyse their activities with

sensor data whether they fulfill definition of registered activities. If the service recognizes that

the activities were done correctly, the service provides certification of the activity to the users.

The service is working as an SNS service, so that users can also communicate on the service.

.


ClouT – 30/09/2014

FIGURE 14: SEQUENCE DIAGRAM OF CITIZEN ACTIVITY ENHANCER


The user scenario provides a good example of the lifecycle of a participatory sensing application,

including the phases of proposition, deployment, evaluation, selection, registration, execution

and completion/disposal. In this sense, citizens role may vary over time, while computing and

storage needs cannot be evaluated in advance (successful sensing tasks in big cities may be

followed by millions of citizens sending thousands of say, 1MB images) by the municipality. In

addition access to tasks and their data can overwhelm any system due to picks of use. In order to

manage these aspects, Cloud based approach of ClouT seems to be the best solution. Cities, as

social body, need to motivate elderly people to do walking activity combined with going out

support for their healthy and enjoyable life. As a result, they go out every day, which helps their

life enhancement especially for elderly people living alone. This puts a series of interesting

challenges in term of personal data to be managed, always geo-referenced, and to be stored in a

secure way by CIaaS. Similarly the analysis of these data needs to be performed in a way that is

secure and compliant to legislations by the CPaaS. The CPaaS is also in charge to ensure the right

distribution of these data other than to the user owner, balancing among the privacy aspects and

the safety risks. The following challenges arise for the use cases in this category:

Personal Activity Understanding


ClouT – 30/09/2014

Recognize various activities which are not only pre-defined but also user-defined

Certification of activity participation and its certification level, obtained by enabling the

interoperability between sensors and smartphones

Personal Activity Sharing

Designing and developing a new kind of Social Network Services providing functions of

activity sharing and participating

Evaluation of activity involvement

Assumptions

User have Smartphone with embedded sensors suitable for the selected tasks and

enabled to deploy and execute sensing tasks

Legislations and Municipality rules allow users to register the required sensors data and

access any information associated to state of sensing tasks

Security Privacy policies applied to user sensing tasks and way of using the Smartphone

are known by the users and explicitly approved by him/her

Pedometers or Smartphone with pedometer function are connected to different

networks in most cases

The instruments to measure health condition (blood pressure, the weight) are connected

to different networks in most cases

Health information (blood pressure, the weight) is in different database in most cases

People need to have not only a pedometer but also a Smartphone or a tablet PC to get all

the services including activity continuation support or health maintenance support


Taking into consideration the particularities of the aforementioned user scenario, the following


UR1CHPE_2: The proper operation of the user's Smartphone shall be ensured during the

execution of a determined application (no battery drain, no memory drain, no erase

user's files ).

UR2CHPE_2: Interface for the Smartphone end-user: the user shall be able to intuitively and


UR3CHPE_2: The ederly or impaired user shall be able to access the services through

natural user interfaces

UR4CHPE_2: The user shall be able to register his personal data through a personal


ClouT – 30/09/2014

information registration interface.

UR5CHPE_2: The user's ability to control the level of contextual information sent to the

service shall be assured/guaranteed in order to allow the required accuracy in the

service provisioning.

UR6CHPE_2: Access of urban and citizen context shall be allowed to the Municipalities in



UR7CHPE_2: User and Municipality data stored within the ClouT platform shall be

compliant with Security and Privacy laws and regulations of their country.


ClouT – 30/09/2014

2.3. User/Service Requirements

Here a summary table of all user/service requirements and their mapping with use cases:

Assignee Final Req. code

Req. Code

Requirement Description CHPE_1 CHPE_2 SCRM_1 SCRM_2 SEM_1 SEM_2

CS

aaS

FR1 UR1SCRM_1 User shall be provided with visual similarity-based services.

x

FR2

UR1CHPE_1 The proper operation of the user's Smartphone shall be ensured during the execution of a determined application (no battery drain, no memory drain, no erase user's files ).

x

UR1CHPE_2 x

FR3

UR2CHPE_1 Interface for the Smartphone end-user: the user shall be able to intuitively and easily shared his device and create applications via application creation tools.

x

UR2CHPE_2 x

UR2SCRM_1 x

UR1SCRM_2 x

FR4 UR3CHPE_1 The elderly or impaired user shall be able to

access the services through natural user interfaces

x

UR3CHPE_2 x

FR5 UR4CHPE_1 The user shall be able to register and cluster any event through a natural interface.

x

FR6 UR4CHPE_2 The user shall be able to register his personal data through a personal information registration interface.

x

CP

aaS

FR7

UR5CHPE_1 The user's ability to control the level of contextual information sent to the service shall be assured/guaranteed in order to allow the required accuracy in the service provisioning.

x

UR5CHPE_2 x

UR3SCRM_1 x


ClouT – 30/09/2014

FR8 UR2SCRM_2 The user shall have the complete control on who he/she wants to share his/her devices with and on which conditions.

x

FR9 UR6CHPE_1

Provision and access to historical event data and features shall be provided to the Municipalities in order to be used for trend analysis.

x

FR10

UR7CHPE_1 Access of urban and citizen context shall be allowed to the Municipalities in order to push/pull urban event notifications. Provision and access to personal data shall be enabled from anywhere, at anytime only by authorised people.

x

UR1SEM_2 x

UR6CHPE_2 x

FR11 UR3SCRM_2 The service owner (Municipality) shall be able to propose some kind of incentive to the user that shares his data through a certain app.

x

FR12 UR4SCRM_1 Location based services and mobility data shall be automatically integrated and available to the Municipalities

x

FR13 UR5SCRM_1 The user shall be able to create personalised mobility routes based on his personal requirements.

x

FR14

UR4SCRM_2 The user shall be able to take advantage of the ClouT platform services without any noticeable lag, independently to the number of concurrent users that are consuming the same services (e.g. due to particular events in the municipality).

x

UR1SEM_1 x

UR2SEM_2 x

FR15 UR3SEM_2 Both citizens and municipality users shall be able to access and consume open data generated from the ClouT Platform

x

CIa

aS

FR16

UR8CHPE_1 User and municipality data stored within the ClouT platform shall be compliant with security and privacy laws and regulations of their country.

x

UR7CHPE_2 x

UR6SCRM_1 x


ClouT – 30/09/2014

UR2SEM_1 x

FR17 UR9CHPE_1 Capacity to hold Personal information in a secure

way, in compliance to laws and regulations.

x

UR2SEM_1 x

FR18

UR5SCRM_2 The user's security and privacy should be protected and be of high importance to the device sharing platform.

x

UR10CHPE_1 x UR9CHPE_1

UR2SEM_1

FR19 UR7SCRM_1 The Municipalities shall be provided with IoT devices which are secure against physical access, interference and altering.

x

FR20

UR3SEM_1

The user should be able to get responses to his/her requests in quasi real-time

x

UR4SEM_2 x

UR6SCRM_2 x

FR21

UR4SEM_1 The user shall be able to access to a heterogeneous set of Sensors over a wide geographical area, hybrid localisation (gps, gprs, wi-fi, webcam) services (multi-sensors integration and outdoor/indoor), communication and networking capability for Street equipment actuation.

x

UR5SEM_2 x

UR8SCRM_1 x

FR22 UR9SCRM_1

The Municipality shall be provided with access to a heterogeneous set of sensors (static ones and on-board of mobile vehicles), in order to define the corresponding routes.

x

FR23 UR6SEM_2 The user should be provided with all the required software necessary to interact with the platform in a package with automatic updates

x

FR24 UR7SEM_2 The user shall be able to use the platform services even in adverse conditions

x

FR25 UR8SEM_2 The user data should be backed up automatically and recovery options should be available

x


ClouT – 30/09/2014

FR26

UR9SEM_2 The Municipality shall be able to deploy ClouT platform to reduce/minimize costs and avoiding vendor lock-in, possibly employing open source software and hardware.

x UR8SCRM_2

UR8SEM_1

FR27

UR11CHPE_1

The Municipality shall be enabled to use additional non-IoT data sources from the city environment and the citizens (legacy devices and Social Networks).

x

UR10SCRM_1 x

UR5SEM_1 x

UR10SEM_2 x

FR28

UR12CHPE_1 The Municipalities shall be provided with a common repository (on Cloud storage infrastructure) to collect different kind of data (e.g. environment measurements, transportation information, social data) allocated in different databases – with different access and management features.

x

UR6SEM_1 x

UR11SEM_2 x

FR29 UR7SCRM_2

The Municipality shall be able to easily identify, discover and manage resources within the city.

x

UR7SEM_1 x

FR31 UR9SCRM_2 The Municipality/citizen shall be able to constantly monitor the status of the Smart City's resources.

x

TABLE 6: USER/SERVICE REQUIREMENTS


ClouT – 30/09/2014

2.4. System Requirements

Here is a summary table of all the identified system requirements.

City Service Model (CIaaS/CPaaS)

Requirement Code

Requirement Title

Related User

Requirements

Related Architectural Components

CIa

aS

REQ_CIAAS_1 Cloud: Infrastructure Scalability

FR14, FR20,FR24

Computing and Storage (Computation as a Service)

REQ_CIAAS_10 Data Storage encryption security

FR16,FR18, FR19

Security & Dependability (Crypting Facilities), Computing and Storage (Storage as a Service)

REQ_CIAAS_11 Cloud: Common sensor data format

FR9,FR10,FR21,FR27

Interoperability & City Resource Virtualisation (Semantic & Syntactic Interoperability), City Resource Access, Sensorisation and Actuatorisation, IoT Kernel

REQ_CIAAS_12 Cloud: High throughput

FR14,FR20 Computing and Storage

REQ_CIAAS_13 Cloud: High availability

FR20,FR24 Computing and Storage

REQ_CIAAS_14 Sensor Description (Interoperability)

FR28 Interoperability & City Resource Virtualisation, Sensorisation and Actuatorisation, IoT Kernel


ClouT – 30/09/2014

REQ_CIAAS_15 Application Description (Interoperability)

FR28 Interoperability & City Resource Virtualisation

REQ_CIAAS_16 Conversion Function (Interoperability)


REQ_CIAAS_17 Virtualisation (Abstracting)

FR21,FR22 IoT Kernel, Interoperability & City Resource Virtualisation

REQ_CIAAS_18 Scalable User Infrastructure

FR20, FR25, FR26

City Infrastructure Management (City Entity Management, City Resource Access), Security and Dependability (A.A.A.)

REQ_CIAAS_19 Scalable Device Infrastructure

FR20, FR24, FR25, FR26, FR27, FR30, FR31

IoT Kernel (Uniform Access…), Sensorisation and Actuatorisation (Uniform Access…)

REQ_CIAAS_2

Standardized data formats between mobile user devices and servers

FR5, FR10, FR13

City Infrastructure Mangement, Interoperability & City Resource Virtualisation

REQ_CIAAS_20 Device sharing FR27, FR28, FR29

City Infrastructure Management (Service Management)

REQ_CIAAS_21 Interoperable sensing infrastructure


REQ_CIAAS_22 Commands to IoT devices

FR15 IoT Kernel

REQ_CIAAS_23 Device and service descriptions

FR21 Interoperability & City Resource Virtualisation, IoT Kernel

REQ_CIAAS_24 Common Data format

FR29, FR21 Interoperability & City Resource Virtualisation, IoT Kernel


ClouT – 30/09/2014

REQ_CIAAS_25 Common APIs FR29, FR21 Interoperability & City Resource Virtualisation, IoT Kernel

REQ_CIAAS_26 Integration of any data source

FR27

Interoperability & City Resource Virtualisation, IoT Kernel, Sensorisation and Actuatorisation

REQ_CIAAS_27 Access to city resources

FR29, FR31 City Infrastructure Management

REQ_CIAAS_28 Resource discovery FR29, FR31 City Infrastructure Management

REQ_CIAAS_29 Resource repository

FR28, FR31 City Infrastructure Management

REQ_CIAAS_3 Cloud: Open Infrastructure

FR26 Computing and Storage (Computation as a Service)

REQ_CIAAS_30 Resource identification

FR29 City Infrastructure Management

REQ_CIAAS_31 Autonomic discovery


REQ_CIAAS_32 Plug & Play integration of city resources


REQ_CIAAS_33 System Infrastructure Monitoring

FR24,FR31 Security & Dependability (Platform and Infrastructure Dependability Monitoring)

REQ_CIAAS_34 Cloud: Infrastructure Security

FR16,FR18,FR19

Security & Dependability (A.A.A.)

REQ_CIAAS_35 Cloud: Scalable Storage Architecture

FR20,FR24,FR25,FR30

Computing and Storage (Storage as a Service)

REQ_CIAAS_36 Data Storage encryption

FR16,FR18, FR19

Security & Dependability (Encrypting Facilities), Computing and Storage (Storage as a Service)


ClouT – 30/09/2014

REQ_CIAAS_4 Manage available resources

FR29 IoT Kernel, City Infrastructure Management

REQ_CIAAS_5 Turning social network into sensor

FR27 Sensorisation and Actuatorisation

REQ_CIAAS_6 Making legacy sensors to IoT sensors


REQ_CIAAS_7 Turning legacy actuators into IoT actuators


REQ_CIAAS_8 Cloud: Infrastructure Deployment

FR26 Computing and Storage (Computation as a Service)

REQ_CIAAS_9 Cloud: Network Virtualisation

FR18,FR16 Computing and Storage (Computation as a Service)

CP

aa

S

REQ_CPAAS_1

Cloud Storage - Store and Retrieve objects/data facilities

FR15,FR21 City Resource Access (City Data Access)

REQ_CPAAS_10

Near real-time data processing

FR20 City Data Processing

REQ_CPAAS_11

Context prediction FR9, FR10 City Data Processing

REQ_CPAAS_12

City Context information

FR9, FR10, FR21

City Data Processing


ClouT – 30/09/2014

REQ_CPAAS_14

Context-aware actions on the city

FR21 City Data Processing

REQ_CPAAS_15

Retrieve data from Cloud Storage

FR9, FR15 City Resource Access (City Data Access)

REQ_CPAAS_16

Data Replication FR28,FR25 Computing and Storage (Storage as a Service)

REQ_CPAAS_17

Backup data on Cloud Storage

FR9, FR25 Computing and Storage (Storage as a Service)

REQ_CPAAS_18

Development of mashups/widgets

FR3 City Service Composition

REQ_CPAAS_19

Verification of Event-Driven Behaviour

FR7,FR8 City Data Processing

REQ_CPAAS_2

Cloud Storage Authentication and Authorization security facilities

FR16,FR18 Security & Dependability (A.A.A.)

REQ_CPAAS_20

Assurance of Accurate Sensory Data

FR7 City Data Processing (Data/Event Processing)

REQ_CPAAS_21

Systems strategy description and evidence

FR31 Security & Dependability (Platform and Infrastructure Dependability Monitoring)


ClouT – 30/09/2014

REQ_CPAAS_22

Collecting evidence FR31 Security & Dependability (Platform and Infrastructure Dependability Monitoring)

REQ_CPAAS_23

Configurable data collection


REQ_CPAAS_24

Standard service API provision

Interoperability & City Resource Virtualisation, City Resource Access

REQ_CPAAS_25

Primitive city context detection

FR9, FR10, FR21

City Data Processing (Data/Event Processing)

REQ_CPAAS_26

High-level city context recognition

FR9, FR10, FR21


REQ_CPAAS_27

Open Data support Interoperability & City Resource Virtualisation

REQ_CPAAS_28

Cloud Development Platform

FR23 City Service Composition (Development & Deployment Platform)


ClouT – 30/09/2014

REQ_CPAAS_29

Cloud Storage Authentication security facilities

FR9, FR16, FR18

Security & Dependability (Crypting Facilities, A.A.A.)

REQ_CPAAS_3 Communication encryption

FR16,FR18 Security & Dependability (Crypting Facilities)

REQ_CPAAS_30

Dynamic computational resource scaling

FR20,FR23,FR24

City Service Composition (Development & Deployment Platform)

REQ_CPAAS_4 Reusable device services

FR21 Ciy Resource Access

REQ_CPAAS_5 Service composition tools

FR3, FR13 City Service Composition

REQ_CPAAS_6 Dependable service creation

FR3 City Service Composition


ClouT – 30/09/2014

REQ_CPAAS_8 Sensor data collection

FR20, FR15 City Data Processing

REQ_CPAAS_9 data pre-processing

FR15, FR21 City Data Processing

TABLE 7: SYSTEM REQUIREMENTS


ClouT – 30/09/2014

3. Preliminary analysis of survey results

In the month of September ClouT launched a set of surveys to collect feedback both from citizens and stakeholders on IoT + Cloud related concepts. The project team prepared three different surveys:

Citizens survey – to collect information from the citizens of the partner cities both in

Europe and Japan. The surveys had a set of general question and a group of questions

specific for each city to collect information regarding ClouT city applications

Stakeholder survey – to collect information from a set of stakeholders identified by

ClouT partners, mainly municipalities and IT specialists.

General citizen survey – a general citizen survey was also prepared and launched in

order to collect information also from citizens different from the cities involved in the

project.

In the following sections we report about the preliminary analysis performed on the replies received up to 3rd October on the Citizens Survey and the Stakeholders Survey. The replies collected on the General Citizens survey at the date of writing this report where not considered an adequate number to perform the analysis and for this reason its results will be reported, if relevant, at a later stage. A more in depth analysis of all surveys will be performed after the submission of this deliverable and, where relevant, the results will be presented in deliverable D4.2 (M24).

3.1. Stakeholders’ survey

ClouT stakeholders’ survey targeted mainly municipalities and IT specialists both in the area of Cloud computing and IoT. At the date of writing this contribution the survey received a total of 65 replies. The survey was made up of 12 questions, the complete version of it can be viewed in Appendix B – Citizens and stakeholders’ surveys.

In the pictures below is a quick view of the people who responded to the survey:


ClouT – 30/09/2014

FIGURE 15: STAKEHOLDERS' SURVEY, GENDER BREAKDOWN

The average age of respondents is 45. The majority of respondents had a good familiarity with the concepts analysed in the survey: IoT and Cloud as it can be seen in the following graphs.

FIGURE 16: STAKEHOLDERS' SURVEY, TECHNOLOGIES FAMILIARITY

Gender

Female

Male

Field IT Company

City

Research Centre

Education Centre

Application Developer

Service Provider

7%

2%

15%

29%

47%

Familiarity with IoT Not at all Familiar

Not so muchFamiliarModeratelyFamiliarQuite Familiar

Very much Familiar

0%

9%

13%

29%

49%

Familiarity with Cloud

Not at all Familiar

Not so muchFamiliarModeratelyFamiliarQuite Familiar

Very much Familiar


ClouT – 30/09/2014

The first particularly interesting result that we would like to report about, refers to question 4. In this question we asked participants to rate (from “very important” to “indifferent”) what in their opinion are the main aims of the Smart City applications. The list of aims was chosen according to a set of objectives smart cities have and that ClouT supports in their fulfilment. It was interesting to see that the great majority of respondents considered the aims proposed in the list as “important” or “very important” - from a minimum of 81% to a maximum 93 %. In the graph below we show the ranking we obtained by weighing the replies given to question 4, i.e. points were given from 4 to 1 according to the grade of importance (from “very important” =4 to “indifferent” =1) that was given to each item by respondents.

FIGURE 17: AIMS OF SMART CITIES, RANKING

As we can see “help save costs” comes out to be considered, by survey participants, as the first aim for a smart city application. This is a very interesting result for ClouT as it perfectly fits its objectives. In fact, one of the concepts that lies behind the use of cloud technologies in the ClouT project in combination with IoT, is to enable cities to offer smart services with lower costs. In some cases, this can be translated into costs savings for those municipalities which have already adopted other technologies (different from cloud and which prove to be more expensive) or into the opportunity, for small municipalities, to offer smart services with lower costs. This result is also depicted in the user requirements identified.

Another interesting result comes out from the analysis of question 8 where we asked participants to rate how certain technologies and IT solutions would, in their opinion, support the future IoT.. It was positively welcomed by the project team that interest was shown towards all the items identified with a percentage of “very useful” and “useful” which ranges from 72%, obtained by “sensorisation of social networks”, to a maximum of 96 % of respondents, obtained by “big data management”. In the following chart we show the ranking we obtained by weighing each reply given by respondents. At a first sight we can see how all the items are very close in the ranking, this makes us conclude that not much difference was perceived by respondents regarding the usefulness of each item proposed. This is a positive result for ClouT as the

Support citizens’ concerns

Make city more attractive

Help save costs

Increase citizen participation

Reduce/Prevent risks

Monitor environmental

parameters

Improve the quality of life

Make cities safer

Ease the city economic and social

growth

135,00 140,00 145,00 150,00 155,00 160,00 165,00 170,00

1

2

3

4

5

6

7

8

9


ClouT – 30/09/2014

question was formulated taking into consideration the technologies and solutions ClouT aims to provide for smarter cities.

If we have a look at the ranking obtained in first place we find “big data management” as we can see in the following graph. This result follows the actual trend of interest towards big data management technologies but it also in line with ClouT objective to use cloud technologies to meet the increasing needs of processing large amounts of data in quasi real time. “composition and aggregation of IoT sensors” is ranked in second place together with “easier access to city resources” two items which are again considered crucial also by ClouT project partners.

FIGURE 18: TECHNOLOGIES AND IOT SOLUTIONS – RANKING

3.2. Citizens Surveys

The citizens surveys where tailored to collect feedback on ClouT related topics from citizens of the cities partners of the project. The survey was divided into 3 sections : Introduction, ClouT field trials and Demographic information. The middle section – ClouT field trials - was specific for each city and aimed at collecting information regarding the city applications being developed in ClouT (you can view the complete version of the questionnaires in Appendix B – Citizens and stakeholders’ surveys). At the time of writing this deliverable we collected 113 replies for the survey run in Genova, 54 for the survey run in Santander and 70 for the one run in Mitaka and Fugisawa. All online surveys are still open and will be further analysed in the following weeks.

In the following sections we provide a preliminary analysis of the surveys.

Big

Dat

a M

anag

emen

t

Sen

sori

sati

on

of

soci

al n

etw

ork

s

Co

mp

osi

tio

n a

nd

agg

rega

tio

n o

f Io

T se

nso

rs

Lon

g-te

rm n

eed

of

com

pu

tin

g re

sou

rces

Sud

den

incr

ease

of

com

pu

tin

g re

sou

rces

Op

en a

cces

s to

IoT

dat

a

Ease

dis

cove

ry,

iden

tifi

cati

on

an

d

man

agem

ent

of

IoT

reso

urc

es

IoT

dat

a se

nso

r m

on

ito

rin

g

secu

rity

asp

ects

Acc

ess

to d

ata

sto

rage

bas

ed o

n

com

mo

n s

tan

dar

ds

Easi

er a

cces

s to

cit

y re

sou

rces

pla

tfo

rm t

o e

asily

plu

g an

d p

lay

IoT

dev

ices

un

der

a c

lou

d a

pp

roac

h

leav

e p

eop

le t

he

op

po

rtu

nit

y to

cr

eate

ser

vice

s b

y th

emse

lves

0

20

40

60

80

100

120

1 2 3 4 5 6 7 8 9 10 11 12 13


ClouT – 30/09/2014

3.1.1. Citizen survey - Genoa

The largest group of citizens who completed the survey refused to provide the demographic information for this reason this information was not considered during the survey analysis.

According to replies to question 1, over 80% of respondents have a smartphone, this result shows the market penetration rates of smartphone is very high and for the Municipality of Genoa it is a very good starting point because in the last two years it has started experimenting mobile applications. Survey results also show that, among the survey participants, digital divide is lower than what reported in previous statistics, with a percentage of 32,8% of respondents who are “quite familiar” with the use of smart phones and 39% who are “very familiar”. This is a very good indicator because the municipality was the promoter of several actions in this direction. Regarding the mobile operative system there is a prevalence of iOS and Android.

In question 5 citizens were asked to check the application or applications of IoT they were more interested in. In the graph below we depict the results. Very good inputs came from this question for the Municipality of Genoa. We see how the city still needs to work on certain IoT fields which collected high consensus, but at the same time it is already very active on other fields which are also considered interesting by respondents. For example the Municipality is already very active on IoT, and in particular weather sensors and hydrometers, with the Civil Protection API (developed during and thanks to ClouT Project) and Public Transport Projects (Projects: 3iPlus, Movues SIMON with Google GTFS).

FIGURE 19: APPLICATIONS OF IOT – PREFERENCES FROM GENOVA CITIZENS

Through question 6 respondents were asked to rate (from 1 - not interested - to 5 - very interested) the five field trials developed in ClouT. The results showed how IoNonRischio is

Infant Monitoring; 24

Track performance in sports; 16

Monitor an aging family member; 37

Smart thremostats; 35

Multi-functional lights; 21

Consumption sensors (light, water, ...); 46

Smart bins (to reduce the number

of pick-ups); 31 Parking space availability; 21

Weather sensors; 41

Air quality sensors; 37

Hydrometers (track water level); 33

Protect wildlife; 16

Traffic monitoring; 31

Public transport measurings; 50

Social Sensors (Trends, Events); 19

Presence sensors; 17


ClouT – 30/09/2014

considered to be an important system for the common citizen collecting 78,8% of “interested” and “very interested” rating. It is interesting to see that also the classification of Social Events provided by Fujisawa is positively evaluated by Genoa citizens.

Regarding the section dedicated to IoNonRischio, the results collected are really very important both to improve the application and the local IOT systems and datasets. Citizens provided positive feedback from the experience in using the first release of the IoNonRischio powered by ClouT. Through question 7 we see that among the features offered by IoNonRischio citizens consider very important: Areas of risk (Geospatial database), Infomobility Webcam, Weather Sensors. The most popular is the Civil Protection Alarm Systems. As a result during the next months the municipality of Genova will integrate in the app also the Facebook Channel and improve the Twitter module using Oauth.

Finally, open questions provided very useful inputs about: datasets, GIS functionalities, ways of behavior, usability, social network services.

3.1.2. Citizen Survey – Mitaka and Fujisawa

Citizen survey results provide a current view of citizens’ attitude towards cloud computing and IoT in Japan. Citizens in Mitaka or Fujisawa which are the field trial cities in Japan for this project responded to the questions mainly. This online survey is still opened to the public and we got 70 answers at this moment. Characteristics of people who responded to the survey are as follows.

FIGURE 20: CITIZEN SURVEY, PARTICIPANTS DEMOGRAPHIC

Overall, citizens are keenly interested in cloud computing and IoT and expect to get benefits of the services utilizing those technology. Over 90% citizens responded “Very much Familiar” or “Moderately Familiar” to the question about smartphone usage, this result shows the market penetration rates of smartphone is very high. Another remarkable point is that many people are interested in “Risk management for natural disaster” and “Real time tourism information” as field trials.

1. How familiar are you with Cloud technology?


ClouT – 30/09/2014

FIGURE 21: CITIZEN SURVEY, CLOUD TECHNOLOGY FAMILIARITY

2. In which fundamental models of Cloud are you interested?

FIGURE 22: CITIZEN SURVEY, CLOUD SERVICE MODELS INTEREST

3. How familiar are you with IoT devices?

FIGURE 23: CITIZEN SURVEY, INTERNET OF THINGS TECHNOLOGIES FAMILIARITY

4. The following list illustrates a set of dataset (IoT devices, geo spatial database) that can potentially be provided by our Local Authority. Please indicate your level of interest for their provision:


ClouT – 30/09/2014

FIGURE 24: CITIZEN SURVEY, DATASET AVAILABILITY INTEREST

5. The following list illustrates the four field trials in the four cities within the consortium have been developed during the first year of the project. Please indicate your level of interest for their provision

FIGURE 25: CITIZEN SURVEY, FIELD TRIALS INTEREST

6. How familiar are you with the usage of smartphone in general?

FIGURE 26: CITIZEN SURVEY, SMARTPHONE TECHNOLOGIES FAMILIARITY

3.1.3. Citizens survey – Santander

In the introductory section of the survey, issues such as degree of smartphone usage, familiarity with IoT and interest in IoT applications were evaluated. More than seventy-five percent (75%) of surveyed citizens use his/her smartphone as his/her primary mobile phone and more than sixty percent (60%) are at least moderately familiar with IoT.


ClouT – 30/09/2014

The following graph shows the ranking of all the IoT applications. The top five (applications with more than forty percent (40%) in green colour) consists of consumption sensors (77%), presence sensors (46%), public transport measuring (44%), traffic monitoring (43%) and Monitor an aging family member (41%). Whereas the least interesting IoT applications resulted to be hydrometers (11%) and infant monitor (9%), respectively.

FIGURE 27: INTEREST IN INTERNET OF THINGS APPLICATIONS

Going into the analysis of the section ClouT field trials of the survey we ca see how all of the developed field trials have resulted at least moderately interesting for more than fifty percent (50%) of the surveyed citizens. The ranking of the field trials is: Genova field trial (65%), Fujisawa field trials (60% in both), Santander field trial (55%) and Mitaka field trial (almost 50%).

One point to be remarked in relation with this question is the percentage of no answers, not completed or not displayed cathegories, around thirty percent (30%). It may be due to several factors in relation with surveyed citizens, such as, lack of awareness in the field trial, an incomplete or non attractive description of the field trial, lack of time to complete the survey.

As previosly mentioned, a more detailed analysis of the replyes related to the Pace of the City application was made. The first point of this analysis is in relation with the different kinds of events included in the Pace of the City (PoC). The following graph shows the ranking of these events. The blue colour represents positive answers gathering “moderately”, “quite” and “very much” answers. The red colour represents negative answers, gathering “not at all” and “not so much” answers. As can be seen, the top five (events with more than 90%) consists of: Culture (100%), Traffic (95%), Transport (91%), Health (91%) and Water (90%). The least interesting event is Sport, althought its interest percentage is higher than sixty percent (60%).

0% 10% 20% 30% 40% 50% 60%

Consumption sensors

Public transport measurings

Monitor an aging family member

Social Sensors

Protect wildlife

Air quality sensors

Track performance in sports

Hydrometers

Infant Monitor

Q5. Interest in IoT applications


ClouT – 30/09/2014

FIGURE 28: PACE OF CITY EVENTS

As it happened in the case of level of interest for the provision of the five field trials, about thirty percent of surveyed citizens did not answer/complete these questions.

The second evaluation point was the first experience using the Pace of the City (PoC), which results are shown in the next Figure 29: Pace of City First Experience. As in the PoC events case, blue colour represents positive answers, while red colour represents negative answers. As it can be seen, more than sixty seven percent (67%) of surveyed citizens reported a good first experience: happy, exciting, wide-awake and satisfying experience, while less than thirty percent (30%) of surveyed citizens reported bad experience. It is important to remark that in this case, no answered/completed/displayed cathegory shows a high value, more than fifty-seven percent (57%) of citizens did not answer, nor complete this question.

0%10%20%30%40%50%60%70%80%90%

100%

Pace of the City: Events Positive Negative


ClouT – 30/09/2014

FIGURE 29: PACE OF CITY FIRST EXPERIENCE

Finally, the last evaluated issue is PoC service, where parameters such as flexibility, compatibility, usefulness have been taken into account. The following graph shows the obtained results.

0%

10%

20%

30%

40%

50%

60%

70%

80%

Pace of the City: First Experience Positive Negative


ClouT – 30/09/2014

FIGURE 30: PACE OF CITY SERVICE EVALUATION

As it can be seen, the top five (issues with more than seventy-seven percent (77%)) are IT Experimentation (96%), Recommendation (91%), Future Use (87%), Flexibility (85%) and compatibility (77%). The worst evaluation is for Easy service (33%) and Usefulness (32%). As in the previous case, no answered/completed/displayed cathegory shows a high value, more than fifty-seven percent (57%) of citizens did not answer, nor complete this question.

Demografic information such as gender, age, studies level and interest field of citizens were included in the last section of the survey. As in the previous case, no answered/completed/displayed cathegory shows a high value, almost forty percent (40%) of citizens did not answer, nor complete this set of questions.

The percentage of male and female citizens who have participated in the survey is around fifty percent, being slightly higher male contribution (55% male and 45% female). The interest in this kind of services/applications does not depend on the gender.

The range of age with a more active participation has been from thirty-five to forty-four years old (54%), followed by the range between forty-five to fifty-four (15%) and older than fifty-five (15%). Citizens with higher educational level have participated more actively (about 80%) than those with lower studies level (about 18%).

In relation with field of study, citizens related to computer science have been the most participative (about 16%), followed by business (10%) and economics (10%). Others graduates such as architects, physicist and telecommunication engineer have also answered the survey (6%per each).

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

Pace of the City: Service Evaluation Positive Negative


ClouT – 30/09/2014

4. ClouT Reference Architecture

4.1. Introduction

Before starting the functional analysis of ClouT Reference Architecture, a brief overview of ClouT domain - with the domain model approach – will be shown, in order to clarify the used vocabulary and key concepts. We have already shown preliminary reduced domain model in the Deliverable 1.2: it included only a part of the vocabularies and some concepts mainly of the CIaaS layer. Herein, we show a complete and refined ClouT domain model.


ClouT – 30/09/2014

FIGURE 31: CLOUT DOMAIN MODEL

Figure 31 illustrates an overview of the ClouT domain model. ClouT’s overall concept is leveraging the Cloud Computing as an enabler to bridge the Internet of Things with Internet of People via Internet of Services. Therefore, ClouT provides three layer concepts inspired by cloud domain: CIaaS, CPaaS, and CSaaS. ClouT adopts representational state transfer (REST) style concept. A service provides a uniform interface to an entity, by exposing resources for accessing states of the entities.

CSaaS

CitySoftwareService

CIaaS

CityApplication

CityInfrastructureEntity

CitySoftwareResource

user

WebApplication

CityApplicationSoftware

citizen

VirtualizedCityInfrastructureEntity

municipality

ConcreteCityInfrastructureEntity

service provider

Processor

application integrater

Storage

local business

CityInfrastructureService

IoTDevice

LegacyDevice

Sensorized/ActuatorizedWebApplication

*1..*virtualize

CityResource

ActionResource

DataResource

ActionResource

1..*1expose

CPaaS

CityData

CityAction

CityBehaviorCityContext

CityEvent

CityPlatformServiceCityBehaviorService

CityContextSerice

CityResourceAccessService

DependabilityProperty

CityPlatformControlOrMonitoringResource

*

1..*

*

1..*fire*

*

0..1

*sensorize/actuatorize

1..* *

virtualize

0..1

*sensorize/actuatorize

*1

execute

*

1

maintain

*

*

estimatedBy

*

*

execute

1..*

*

getFrom

1..*

*

actOn

*

1

use

*

*

assure

*

*

definedOver

*

*

definedOver

*1explose

*

*

use

*

*

relyOn

*

*awareOf

*

*

consistsOf

**use

**

create

*

*

use

*

*

use

*

*

use

*1expose

*

*

realize

*

1

use


ClouT – 30/09/2014

FIGURE 32: CLOUT DOMAIN MODEL: CIAAS


ClouT – 30/09/2014

The CIaaS layer provides CityInfrastructureService for accessing entities managed in city infrastructure. CIaaS deals with entities relevant to IoT (such as IoTDevices) and Cloud (such as Processors and Storages). CIaaS also manages WebApplications (such as Twitter or Facebook) and LegacyDevices as CityInfrastuructureEntity by Sensorisation or Actuatorisation. The CityInfrastructureService provides a uniform interface to CityInfrastructureEntity by exposing CityResources, in accordance with REST concept. CityResource can be either an ActionResource, that manipulates devices, or a DataResource, that represents data provided by devices.

FIGURE 33: EXAMPLE OF CITY INFRATRUCTURE SERVICE

For example, Figure 33 shows a Light Service, managing a Light Device deployed in a city. The Light Device is a CityInfrastructureEntity and exports the Light Service, which is a CityInfrastructureService. The light service exposes “On”, “Alert”, and “Brightness” resources. “On” and “Alert” resources (ActionResource) represent state of actions provided by the light devices, and “Brightness” resource (DataResource) represents current brightness of the light devices. Besides, ClouT introduces virtualisation concepts used in the cloud domain. IaaS in the cloud domain enables a service to use a virtualized entity (e.g. virtual machine) instead of a concrete entity (e.g. physical machine) in order to manage resources in a flexible way by mapping virtualized resources to concrete resources at runtime. CIaaS in the ClouT domain supports virtualisation of sensors and actuators to improve flexibility and portability. CIaaS introduces VirtualizedCityInfrastructureEntities, representing virtualisation of ConcreteCityInfrastructureEntity. CIaaS enables CityInfrastructureServices to use VistualizedCityInfrastructureEntity instead of CityInfrastructureEntity.


ClouT – 30/09/2014

FIGURE 34: EXAMPLE OF VIRTUALIZED CITY INFRASTRUCTURE ENTITY

VirtualizedCityInfrastructureEntity is mapped to ConcreteCityInfrastructureEntity at runtime. Figure 34 illustrates an example of VirtualizedCityInftastructureEntity. The CityLightService provides an abstract interface to control and monitor some adequate lights in the street. It manages LightsInStreet (VirtualizedCityInstrastructureEnitity), which does not correspond to a certain light device but is mapped to ConcreteCityInfrastructureEntity, like Light1 or Light2 at runtime.


ClouT – 30/09/2014

FIGURE 35: CLOUT DOMAIN MODEL: CPAAS


ClouT – 30/09/2014

CPaaS layer provides CityPlatformServices, which can be either CityResourceAccessService, CityContextService or CityBehaviorService. CityResouceAccessService provides rich APIs for accessing CityInfrastructureService, which provides primitive APIs for accessing city resource. CityContextService generates and manages CityContext. CityContext represents the current context of city and it is derived from CityData. CityContextService provides not only APIs for managing CityContext but also event processing APIs to generate CityContext from CityData. CPaaS also supports CityBehaviorServices. CityBehaviorService supports one or more CityBehaviors. CityBehavior can change or can be ruled by CityContext, and consists of CityActions and CityEvents. For example, “the street is bright” or “the street is dark” (CityContext) are estimated from brightness data (CityData) provided from CIaaS. A “sunset” event (CityEvent) is fired by changes in the CityContext (from “the street is bright” to “the street is dark”). The service executes CityActions acting on some CityInfrastructureEntity corresponding to lights in the street on. In addition, CPaaS supports assurance of DependabilityProperties related to CityBehavior and CityContext. DependabilityProperties includes a variety of properties to satisfy non-functional requirements, such as secure accessibility to CityContext that includes some personal information, safety of CityBehavior that controls traffic.


ClouT – 30/09/2014

FIGURE 36: CLOUT DOMAIN MODEL: CSAAS


ClouT – 30/09/2014

CSaaS enables users to build their CityApplications by using CPaaS. Each CSaaS may be constructed and operated by using specific part of the CPaaS functionalities, depending on the application characteristics. For example, data-centric CSaaS should make intensive use of CityContextService to realize data processing (analysis, mining, learning, etc.). Other CSaaS may require more support on the control behaviour to orchestrate multiple services by following interaction protocols

4.2. Final version for a ClouT Reference Architecture

FIGURE 37: CLOUT REFERENCE ARCHITECTURE OVERVIEW

FIGURE 37 shows a high level view of ClouT Reference Architecture, the composing layers, functional blocks and models.

The Reference Architecture has been conceived starting from the challenges proposed by four pilot cities. The vision is cloud-centric, i.e. cloud service models (IaaS, PaaS and IaaS) represent the core supporting the modules which bind together Internet of Things, Cloud Computing and Internet of People, rendering municipalities capable of deploying scalable infrastructures that allow the gathering, processing and exploitation of huge amounts of data harvested from physical devices and web & participatory sensing. ClouT’s architecture includes both-easy-to-use and full-fledged scalable development platforms that cater to citizens and developers alike, enabling the development of cloud-enabled Smart City services.


ClouT – 30/09/2014

4.3. CIaaS functional models and components

FIGURE 38: MAIN FUNCTIONAL BLOCKS FOR CITY INFRASTRUCTURE LAYER

FIGURE 38 shows the logical representation of the main functional blocks within the City Infrastructure layer. City Infrastructure as a Service Layer provides all the required facilities to exploit the computing and sensing resources available to the City, while making it easier to extend such infrastructures through the adoption of cloud technologies, standard protocols and interoperability facilities. Here is a brief breakdown of its main subcomponents:

City Infrastructure Management offers centralized search capabilities and event management on the discovered city resources. It keeps track of all the available city resources, detecting changes in state and offering information on the availability of devices and services.

Computing and Storage offers all the physical and virtualized computing, networking and storage resources that are required to store, retrieve and elaborate city data. It has load balancing, high availability and scalability qualities that are typical of the Cloud. It’s the foundation on which the other city service models lay.

The Interoperability & City Resource Virtualisation component is in charge of validating and converting data gathered from both IoT and sensorised devices. Its duty is to transform raw, unstructured city data into meaningful context data. It offers both syntactic and semantic interoperability capabilities. Moreover it includes the sensor/actuator virtualisation capabilities, offering extended sensor/actuator abstraction functionalities.


ClouT – 30/09/2014

The Sensorisation and Actuatorisation component is responsible for the “sensorisation” of legacy devices, rendering such resources IoT-compliant sensors and/or actuators. This sensorisation/actuatorisation process applies to both physical legacy devices and Internet of People’s selected sources such as social networks. This component includes the facilities required to transform legacy resources into smart objects, the noise reduction functionalities required to extract meaningful data from external web data sources and it offers access to the sensorised resources via APIs.

The IoT Kernel comprises all the IoT resources available to the City. It includes a multiprotocol IoT Gateway that is in charge of gathering heterogeneous IoT devices data streams. On one hand it offers a multiprotocol compatibility layer that complies with all IoT transmission protocol standards, on the other hand it offers a uniform access to the connected resources. It has discovery and management functionalities that enable the remote management of the bound IoT sensors/actuators.

In the following section a detailed explanation of every block is provided.

4.3.1. City Infrastructure Management

Name: City Infrastructure Management

Layer: City Infrastructure as a Service

Description:

This functional block gives access to City Services and Resources. Basically, it maintains the bindings between entities and physical, sensorised and virtualised devices (interaction with logically lower layer blocks) and makes their capabilities searchable in the form of Services exported by the City Infrastructure to logically upper layers components (CPaaS in principle).


ClouT – 30/09/2014

FIGURE 39: CITY INFRASTRUCTURE MANAGEMENT INTERACTION WITH OTHER BLOCKS

Functional components

FIGURE 40: FUNCTIONAL COMPONENTS FOR CITY INFRASTRUCTURE MANAGEMENT

The City Infrastructure Management block is, in turn, divided into three main functional

components:

Service Management: in charge of the abstraction of City Resources as Services.

Resource Access Management: in charge of the communication with the physical,

virtualised or sensorised devices.

City Entity Management: this block is in charge of keeping track of the mapping among

Resource Access

Management

Service

Management

City Entity

Management


ClouT – 30/09/2014

Entities and the IoT and Sensorised/Actuatorised Devices, while actual sensor data is stored

in the Storage as a Service block.

The roles and interactions at functional components level are highlighted in the next diagram.

FIGURE 41: CITY INFRASTRUCTURE MANAGEMENT, DETAILED INTERACTION WITH OTHER FUNCTIONAL BLOCKS

FIGURE 42: DETAILED VIEW OF CITY INFRASTRUCTURE MANAGEMENT MODULE

The Resource Access Management functional block is composed of three sub-blocks:

Historical access: it is the block in charge of providing historical access facilities to the

upper layers (i.e. it provides the capability of asking data for a given period of time).


ClouT – 30/09/2014

On-Demand Access: it is the block in charge of the Request/Response interaction with a City

Entity. This kind of interaction is typically synchronous as the client/requestor waits for the

response carrying the latest value or status of the City Entity.

Event Based Access: it is the block in charge the Push (or “Observe”) type of interaction with

a City Entity. In this type of interaction (typically asynchronous) the client/consumer is

notified about the value/status of an entity on event basis: this can be a change on the

value/status (optionally above a certain percentage or absolute value) or a periodic

timeout.

The Service Management functional block is composed of three sub-blocks:

Service search: This block is in charge of providing mechanisms for searching and reusing

the available services provided by the CIaaS and offered to the CPaaS layer through the City

Resource Access block. In this sense, the service registry will contain the description of the

available services according to certain standard(s), thus contributing to improve the

efficiency of the searching mechanism.

Service description: this block is in charge of providing the representation of available

services the representation of the Services, exposed by the City Entities, by means of widely

adopted standards.

Service auto-discovery and auto-binding: this block is in charge of discovering the services

exposed by the City Entities and bind them if necessary to other services. The Discovery

phase can leverage different protocols and tools depending on the nature of the Entity that

is involved.

Proposed Reusable Component(s)

SmartSantander, Butler GW: Resource Access, Service Management

UDDI/WSDL/JSDL/Visual Web Search: Service Description, Service Search

USDL: Service Description

Requirements

List of requirements related to this block:

- REQ_CIAAS_4: Manage available resources

- REQ_CIAAS_18: Scalable User Infrastructure

- REQ_CIAAS_20: Device sharing

- REQ_CIAAS_27: Access to city resources

- REQ_CIAAS_28: Resource discovery

- REQ_CIAAS_29: Resource repository


ClouT – 30/09/2014

- REQ_CIAAS_30: Resource identification

- REQ_CIAAS_31: Autonomic discovery

- REQ_CIAAS_32: Plug & Play integration of city resources

4.3.2. Computing and Storage

Name: Computing and Storage


Description:

Computing and Storage includes all the physical and virtualized computing city resources. It offers a virtualisation infrastructure, with its high availability, scalability and resource exploitation properties. Storage resources required to safely store and access all the data retrieved from the city, offering scalability and performance, are available at this level. Computing and Storage includes all the software and hardware needed to offer a scalable and dependable cloud computing infrastructure on which the other city service models lay their foundations.

FIGURE 43: COMPUTING AND STORAGE INTERACTIONS WITH OTHER BLOCKS.



ClouT – 30/09/2014

FIGURE 44: FUNCTIONAL COMPONENTS FOR COMPUTING AND STORAGE

Computing as a Service offers virtualised computational resources as virtual machines running on

multiple infrastructure nodes. Such infrastructure is typically composed of one or more

supervisor/management node and multiple computational nodes. Management/supervisor nodes

are responsible for offering both supervisor functionalities, e.g. checking on the availability of

computational and storage nodes, showing running virtual machines status, keeping track of the

virtualisation user/roles, etc., and exposing a centralised management interface that enables

various management and operational actions to system administrators. Each virtual machine

represents a slice of the available computational resources. Each virtual machine can be migrated

on the available computing nodes in quasi real-time. If a computing node fails or becomes

unavailable or unresponsive, the supervisor/management engine can move the virtual machines

that were running from the failed node to one or more available computing nodes, while taking into

account shared workload between remaining nodes, thus maintaining hosted services intact while

employing a load balancing mechanism at the same time.

Storage as a service is actually part of the virtualisation infrastructure itself, where available

storage space can be split in different quotas that are assigned to different tenants. In a typical

virtualisation infrastructure, storage is usually provided both in block storage form – logical units

shared by storage devices that appear as local disks to the server – and in network attached storage

form – shared filesystems that can be accessed simultaneously by multiple clients. Due to the huge

quantity of data amassed from a vast array of different data sources, ClouT’s approach to cloud

storage is to use a scalable filesystem technology that enables rapid scaling by adding more storage

nodes as the need arises, coupled with cloud storage standard APIs that guarantee data

interoperability and portability.

Data collection:


ClouT – 30/09/2014

FIGURE 45: COMPUTING AND STORAGE ARCHITECTURE


Openstack Cloud Computing Platform: Computing as a Service

Openstack Swift, Hypertable: Storage as a Service

GlusterFS: Scalable Filesystem: Storage as a Service

IDAS platform Sensor data storage: Storage as a Service

Requirements

- REQ_CIAAS_1: Cloud: Infrastructure Scalability

- REQ_CIAAS_3: Cloud: Open Infrastructure

- REQ_CIAAS_8: Cloud: Infrastructure Deployment

- REQ_CIAAS_9: Cloud: Network Virtualisation

- REQ_CIAAS_10: Data Storage encryption security

- REQ_CIAAS_11: Cloud: Common sensor data format

- REQ_CIAAS_12: Cloud: High throughput

- REQ_CIAAS_13: Cloud: High availability

- REQ_CIAAS_35: Scalable Filesystem

- REQ_CIAAS_36: Data Storage encryption

- REQ_CPAAS_16: Data Replication

- REQ_CPAAS_17: Computing and Storage (Storage as a Service)


ClouT – 30/09/2014

4.3.3. Interoperability & City Resource Virtualisation

Name: Interoperability & City Resource Virtualisation


Description: This functional block gathers two concerns; The first one is the harvested data conversion into a system-usable format by adapting both content and format; the second one is the reification of various city resources in terms of virtualized homogenous resources.

Interoperability :

Components implied in the interoperability aim to provide a cross-application domain interoperability that will make the system capable of cooperating with the solutions of different device vendors, service providers or application integrators.

Virtualisation:

It can be considered as an extension (mainly at gateway level), of the basic capabilities offered by subjacent resources, both IoT and legacy devices and other data sources (like SNS), extending the available resources accessible from the CPaaS layer. In this sense, different capabilities can be highlighted as follows:

Resource combination: It consists of inserting in the resource directory, the information description of a virtualized resource, composed of the sensing and processing capabilities of a set of devices that are managed by one or more gateways, as well as of information provided by other data sources (like SNS), thus contributing to extend the available city resources.

Resource abstraction: The user from the upper layer will be able to ask for an abstract sensor (i.e. average temperature in certain geographical area), thus being translated this request by the virtualisation block in to a virtual sensor, which gathers all the information from the single nodes responding to the rules established by the user (temperature sensors within the selected geographical area), and offering the aggregated values to the upper layer in a transparent way, as if it was another city resource. Additionally, these new virtual nodes can be added to the registry, as new combined sensors that could be offered to other users.

Mobile sensor: Mobile phones or tablets can be virtualized thus loading on them applications that allow data retrieval (raw or processed) from them such as, for instance, data from sensors with which the mobile phones are provided. In this sense, the citizens/users will behave as virtual sensors.

Sensor history: Information retrieved by both real and virtual resources, can be also used to generate new virtualized sensors based on the combination, correlation, mining or aggregation over the historical data already stored.

By employing Cloud technologies with the aforementioned sensor virtualisation functionalities it is

possible to elaborate huge amounts of data while preventing, for example, a system overload of a

gateway device due to “trillions” of operations.


ClouT – 30/09/2014

FIGURE 46: INTEROPERABILITY & CITY RESOURCE VIRTUALISATION

Functional components :

The interoperability block is in charge of transforming raw unstructured city-data into to well-structured machine readable data, and finally into meaningful city context data for human comprehension :

The Syntax verifier component is responsible for verifying if the received data conform to the expected syntax. This component will be in interaction with the City Resource Virtualisation components to gather data in the format provided by those components and check their syntax.

The Syntax interpreter component is responsible for interpreting the received data and

Interoperability

Semantic

Syntactic

Metadata Repository

Components Repository

Data Converter

Data Transformer

Syntax Interpreter

Syntax Verifier Data Model

Resource Model

Service Model

Figure 47: Interoperability Architecture


ClouT – 30/09/2014

extracting the useful information from the content. This component gets the data verified by the syntax verifier and sends it to the data transformer.

The Data transformer component is responsible for transforming information from one format to another. This component will get the data from the syntax interpreter and transform it into the desired data representation format and provide it to the Data Converter in charge of semantic interoperability concern, to include semantic information into the data.

The Data converter function can transform sensor data from one format to another. It searches metadata for sensor on Metadata Repository. It may utilize components on Component Repository, to enable conversion function

FIGURE 48: CITY RESOURCE VITRUALISATION ARCHITECTURE

The city resource virtualisation block is in charge of access to city resources (i.e., sensorized/actuatorized devices and IoT), abstraction of the city resources, mapping between virtual and physical city resources, and management virtual city resources:

The Sensorized/Actuatorized Device Accessor component is responsible for accessing sensorized/actuatorized devices according to requests from city resource abstractor. It directly communicates with Sensorisation & Actuatorisation layer.

The IoT Accessor component is responsible for accessing IoT according to requests from city resource abstractor. It directly communicates with IoT Kernel layer.

The City Resource Abstractor component is responsible for abstracting physical city resource as virtual city resources. The abstraction is achieved based on each city resources’ property such as type, capability, location, etc.

The Virtual-Physical Resource Mapper component is responsible for mapping between virtual city resources and city physical resources. Upper layer’s applications which use virtual city resources do not have to care about actual physical resources for their application. This component provides appropriate physical city resources according to virtual city resources which are used in upper layer’s applications.


ClouT – 30/09/2014

The Virtual Resource Manager component is responsible for managing virtual city resources. It manages both one-to-one mapped virtual resources which are abstracted through city resource abstractor, and user-defined virtual resources which are possible to be mapped to both single physical city resources and multiple physical city resources (device combination).


Syntactic interoperability : XML, JSON or any other standard format

Semantic interoperability: Sesame, Neo4J, JSON-LD

City resource virtualisation: XMPP, PIAX, DNS

Requirements

- REQ_CIAAS_2 – Standardized data formats between mobile user devices and servers

- REQ_CIAAS_11 - Cloud: Common sensor data format

- REQ_CIAAS_14 – Sensor Description (Interoperability)

- REQ_CIAAS_15 - Application Description (Interoperability)

- REQ_CIAAS_16 – Conversion Function (Interoperability)

- REQ_CIAAS_17 - Virtualisation (Abstracting)

- REQ_CIAAS_21 - Interoperable sensing infrastructure

- REQ_CIAAS_23 - Device and service descriptions

- REQ_CIAAS_24 - Common Data format

- REQ_CIAAS_25 - Common APIs

- REQ_CIAAS_26 - Integration of any data source

- REQ_CPAAS_24 - Standard service API provision

- REQ_CPAAS_27 - Open Data support

4.3.4. Sensorisation and Actuatorisation

Name: Sensorisation and Actuatorisation


Description:

This functional block is in charge of the actual interface with the Web information, which relates to legacy sensors information and social network services. This block is also in charge of offering to the upper layers a uniform interface to the underlying devices, hiding their different natures


ClouT – 30/09/2014

(application profiles, protocols, wiring, …).

FIGURE 49: INTEROPERABILITY & CITY RESOURCE VIRTUALISATION, INTERACTIONS WITH OTHER BLOCKS



ClouT – 30/09/2014

FIGURE 50: FUNCTIONAL COMPONENTS FOR SENSORISER AND ACTUATORISER

The Sensorizer and Actuatorizer block is, in turn, divided into three main functional components:

Networked Sensor/Actuator Enabler: this function can transform legacy

sensors/actuator and social network sensors, especially immersed web data from the

devices, into IoT sensors/actuators.

Noise Reduction: this function can remove noises in social network/web data to use them as

sensors.

Uniform access to Sensorized/Actuatorized web/SNS: this block provides uniform APIs

to access virtualized sensorised/actuatorised devices/web.

The Sensorisation and Actuatorisation block is accessed, through the Uniform Access functional

component, by the City Entity Virtualisation component of the Interoperability and City Resource

Virtualisation block: this completes the process of wrapping and presenting the underlying


ClouT – 30/09/2014

network-enabled devices in a common abstract representation.

The Sensorized/Actuatorized Device Server block is used for managing the network-enabled devices

with their repository, and providing publish/subscribe uniform access method to upper layer

components.

The Agent Software blocks perform as bridge between lower layer of devices/SNSs and

sensorized/actuatorized device server. For retrieving data from legacy sensors, it can work as the

combination of browser plug-in and server-based monitoring software.


XMPP/Sensor Andrew (Uniform Access to Sensorized/Actuatorized web/SNS)

Google Chrome Extension (Networked Sensor/Actuator Enabler)

Network enabler such as Arduino and Raspberry Pi for hardware components (Networked

Sensor/Actuator Enabler)

Place-triggered geo-tagged tweets method (Noise Reduction)

Requirements


- REQ_CIAAS_5 - Turning social network into sensor

- REQ_CIAAS_6 – Making legacy sensors to IoT sensors

- REQ_CIAAS_7 – Turning legacy actuators into IoT actuators

- REQ_CIAAS_11 - Common sensor data format

- REQ_CIAAS_14 - Sensor Description (Interoperability)

- REQ_CIAAS_19 - Scalable Device Infrastructure


4.3.5. Internet of Things Kernel

Name: IoT Kernel


Description:

This functional block is in charge of the actual interface with the IoT compliant devices, implementing the protocols needed to access their resources (get sensor data, operate on actuators) and to manage them (change of settings, firmware update,…). This block is also in charge of offering to the upper layers a uniform interface to the underlying devices, hiding their


ClouT – 30/09/2014

different natures (application profiles, protocols, wiring, …).

FIGURE 51: IOT KERNEL INTERACTIONS WITH OTHER BLOCKS


FIGURE 52: FUNCTIONAL COMPONENTS FOR IOT KERNEL

The IoT Kernel block is, in turn, divided into three main functional components:

Uniform access to IoT Devices: this functional component is charge of the device

abstraction, i.e. it implements the uniform Device Access API to let the upper layers


ClouT – 30/09/2014

interface with the actual devices regardless the actual protocol or profiles they use;

IoT Device Management: this functional component is in charge of the managements tasks,

i.e. tracking the relevant parameters that can be used to configure the operation of the

devices (i.e. frequency of the data reporting, …), the status of their firmware, its update, …;

IoT Device Wrapping: this is the lowest level block that is in charge of the actual

communication with a specific device, i.e. for each device type it interacts with the specific

physical medium, it addresses the specific communication protocol, it understands the

specific application profile. All the different IoT Devices are wrapped in a uniform way, in

order to properly interact with the other two functional components of this block.

The roles and interactions at functional components level are highlighted in the next diagram.

FIGURE 53: IOT KERNEL BLOCK

The IoT Kernel block is accessed, through the Uniform Access functional component, by the City

Entity Virtualisation component of the Interoperability and City Resource Virtualisation block: this

completes the process of wrapping and presenting the underlying IoT devices (along with other

legacy devices and sensorised resources) in a common abstract representation.

The IoT Device Management block is used only for specific management operations, while a direct

IoT Kernel

IoT Device Wrapping

Uniform Access to IoT

Devices

IoT Device Management

Interoperability & City Resource VirtualisationCity

Infrastructure Management Semantic & Syntactic

Interoperability City Entity Virtualisation

IoT Devices

Discovery Directory


ClouT – 30/09/2014

connection between upper layers and IoT Device wrapping is used, via the Uniform APIs, for normal

operations like data retrieval or to operate on actuators.

As illustrated in FIGURE 53, IoT Device Management block performs also the Device Discovery

function. This is done in a specific way for the different supported devices, depending on the

standards they support, their capability, resources and physical bindings. As examples, standard

IPv6 neighbour discovery approaches, or higher level protocols like mDNS/DNS-SD or techniques

involving RDNSS and standard CoAP/Resource directory bindings can be used. Discovered devices

are stored in a local database (or Device Directory) along with all their available information and

capabilities.

In Figure 54 the two layers (logical) architecture of the IoT Device Wrapping block is highlighted. At

this level, usually one instance of the so called “Protocol Adapter” exists for each IoT Device family

that we are addressing. These different families are identified by the physical media and protocols

they are using to communicate (i.e. IEEE 802.15.4, Bluetooth, WiFi, Ethernet, …) and by the upper

layer network, transport and application protocols they are using to describe resources and make

them reachable.

The actual (if any) partitioning depends on the specific protocol adapter, but we can generally

divide this layer in a Link Handler (lhx) in charge of the physical connectivity (i.e. it can be

responsible of the serial communication with a USB dongle in case of a specific adapter for ZigBee

or Z-Wave devices) and a Protocol Handler (phx) in charge of the upper layers management

(transport protocol termination, if this applies, and profile support).

The profile is the specific representation of the resources according to a common set of rules and

naming convention.


ClouT – 30/09/2014

FIGURE 54: IOT DEVICE WRAPPING BLOCK

The behavior of an IoT device itself can be implemented by various programming languages by

using the virtualisation (abstraction) mechanism. The virtual machine (VM) for IoT devices

enables portability by abstracting each device and operating system, and it also provides a

standard programming interface across a range of target platforms. As an example, the virtual

machine based on Common Intermediate Language (CIL) developed by NTT can execute

programs built with various programming languages of J++, C#, Visual Basic, and C++/CLI, F#.

This reduces the cost to develop a program that works on various sensor devices with deferent

platforms.


Butler GW, SmartSantander: Uniform access to IoT devices, IoT management, discovery,

directory and wrapper.

Standards and protocols like CoRE CoAP (and suitable libraries like Californium),

6LoWPAN (uIP6 stack), IPSO Application Framework/Smart Objects (OMA LWM2M

based objects representation): for the profiles/firmware on devices and the

communication between them and the gateway (involving the Discovery phase).

Standard based and Virtualised Devices such as the ones based on SPIRIT1 transceiver

IoT Kernel

Uniform Access to IoT

Devices IoT Device Management

IoT Devices

lh1

ph1

lh2

ph2

lh3

ph3

…

lhN

phN

…

IoT Device Wrapping

Protocol Adapter N

1

2 3 N …


ClouT – 30/09/2014

from ST, or NTT R&D’s virtual machine

Requirements


- REQ_CIAAS_4 - Manage available resources

- REQ_CIAAS_11 - Common sensor data format

- REQ_CIAAS_14 - Sensor Description (Interoperability)

- REQ_CIAAS_17 - Virtualisation(Abstracting)

- REQ_CIAAS_19 - Scalable Device Infrastructure

- REQ_CIAAS_21 - Interoperable sensing infrastructure

- REQ_CIAAS_22 - Commands to IoT devices

- REQ_CIAAS_23 - Device and service descriptions

- REQ_CIAAS_24 - Common Data format

- REQ_CIAAS_25 - Common APIs


- REQ_CIAAS_27 - Access to city resources

- REQ_CIAAS_28 - Resource discovery

- REQ_CIAAS_29 - Resource repository

- REQ_CIAAS_30 - Resource identification

- REQ_CIAAS_31 - Autonomic discovery

- REQ_CIAAS_32 - Plug&play integration of city resources

- REQ_CIAAS_33 - System Infrastructure Monitoring

4.4. CPaaS functional models and components

The City Platform as a Service layer includes the development and processing tools offered by the ClouT platform. It lays the foundations on which the end-user services are built upon.

City Service Composition aims at both technically oriented and un-experienced users to mash-up and aggregate data and services offered by deployed applications. It has a graphical user interface to enable an accessible interaction with the composition services. It also caters to the experienced developer with Platform as a Service Cloud capabilities via the Development and Deployment Platform, enabling the swift instancing of customized development environments and the shipping of the developed applications on auto-scalable, self-balancing virtualised instances.


ClouT – 30/09/2014

The City Data Processing component enables the analysis and extraction of the data

archived inside the cloud storage. It offers querying interfaces that are exposed to the overlaying services. Moreover it includes an event/decision making engine that analyses requested queries and takes actions based on a configurable rules directory. Finally it has a data fault corrector that analyses and rectifies faulty sensor data.

City Resource Access offers the middleware software that enables the storing and retrieval of the collected city data, together with the associated metadata, from and into the backend storage via a uniform data access layer. It’s a gateway to the City Infrastructure as a Service layer.

Here follows the logical representation of main functional blocks within the City Platform layer:

FIGURE 55. MAIN FUNCTIONAL BLOCKS FOR CITY PLATFORM LAYER

For each single block shown in the above Figure 55, a detailed explanation follows.

4.4.1. City Service Composition

Name: City Service Composition

Layer: City Platform as a Service

Description:

City Resource Access

City Data Processing City Service Composition

CPa

aS

Service

Composition

Development

&

Deployment

Platform

Context Management

Data/Event Processing

City Data Access City Action Access


ClouT – 30/09/2014

City Service Composition brings all the required functionalities needed to develop and deploy applications on top of the City Infrastructure as a Service layer. Its two main functional blocks are Service Composition and Development & Deployment Platform. The City Service Composition caters to both the experienced municipality/third party developer, via the Development & Deployment Platform, and the non-technical users such as citizens that wish to create services via the Service Composition mash-up capabilities.

FIGURE 56: CITY SERVICE COMPOSITION INTERACTIONS WITH OTHER BLOCKS


FIGURE 57: FUNCTIONAL COMPONENTS OF THE CITY SERVICE COMPOSITION

Development & Deployment Platform: this block offers Platform as a Service capability to

Municipality/Third Party developers that enables the creation, testing and deployment of City

applications, running them on top of the Cloud infrastructure.

The Development & Deployment Platform has scalability mechanisms that enable the dynamic


ClouT – 30/09/2014

allocation of virtualised resources to the deployed City Applications, both fully automated and

manual. The scalability mechanism consists in system-instanced virtual machines which host the

deployed application; as the number of requests, therefore workload, increases, new instances of the

hosted application are deployed and a load balancer in instanced to distribute such requests among

application instances. This characteristic enables the creation of City services which are capable of

reacting to sudden spikes in workload due to specific City events.

The Development & Deployment Platform supports most development languages and server

applications on which both simple and complex software architectures are built upon, such as web

servers, SQL/NOSQL databases, middleware and connectors. Management interfaces for both

System Administrators and Developers - which ease the task of instancing and managing

development, testing and runtime environments - are offered.

Developers can build applications that take advantage of the underlying City Infrastructure as a

Service via City Resource Access, requesting collected sensor data via queries or subscription to an

exposed brokering service. City services built upon the Development & Deployment Platform range

from the simple mobile application backend (e.g. a city weather forecasting service that is

consumed via a specific mobile application) to more much more complex web services that include

participatory sensing (e.g. a web platform which enable citizens to document and share concerns

regarding risks in their neighbourhood), effectively furthering data collection capabilities of a

ClouT deployment.


ClouT – 30/09/2014

Service Composition: this block contains all providing tools to allow users (experienced developers, non-technical users, etc.) to build their own services, therefore making them actively part of the city ecosystem: in particular the Service Composition component will allow to perform data mash-up, but also to compose services provided by the CIaaS layer in order to create, in a simple way, rich end user applications. The Service Composition component is composed by eight components:

Application Deployer: This component is responsible of deploying the application/service

that composes several services at the underlying layer

Composition/Mash-up Engine: This component is responsible for the composition/mash-up

execution. It is an engine that allows to read and decode specific composition/mash-up

description languages and to perform the service composition/mash-up execution.

Considering that from the technical point of view service composition and service mash-up

follow different approaches; this component could have two different implementations.

Service Connector: This component is responsible for providing direct access to existing

services to be used in the composition process

Security Manager: This component is responsible for securing access to the services to be

composed.

DSL: Domain specific Language responsible for describing the model and existing services

synchronously with the GDL component

GDL: Graphic Description Language responsible for the application being created or

existing services representation synchronously with the DSL component

GUI: Graphical User Interface for interaction with end-users.

Application Behaviour Verifier: Responsible for verifying the behaviour specified in the DSL

model

Figure 58: Development and Deployment Platform Scalability


ClouT – 30/09/2014

FIGURE 59 - SERVICE COMPOSITION COMPONENTS

FIGURE 60 - SERVICE COMPOSITION INTERACTIONS

Figure 60 shows the interaction among some service composition components: the service Composition/Mash-up Engine performs the service composition exposing the composed services that will be used by the final city applications. The Engine can access to the low level services, provided by the City Resources component, through the Service Connector that contains the adapters for different services technologies. The general composition process is monitored by the Application Behaviour Verifier that verifies the DSL model.


Openstack Heat: Development & Deployment Platform

Enterprise Mash-up Markup Language: Service Composition


ClouT – 30/09/2014

Open Social Specification: Service Composition

Apache Shindig: Service Composition

BPMN: Service Composition

IFTTT: Service Composition

Xively: Service Composition

Requirements


- REQ_CPAAS_5: Service composition tools

- REQ_CPAAS_18: Development of mashups/widgets

- REQ_CPAAS_28: Cloud Development Platform

- REQ_CPAAS_30: Dynamic computational resource scaling

4.4.2. City Data Processing

Name: City Data Processing


Description:

The main function of this block is to build the data processing layer of the ClouT platform. It gathers city data from the City Resource Access component, and provides processed data/events, as well add high level contextual information to the applications or to the service composition environment.


ClouT – 30/09/2014

FIGURE 61: CITY DATA PROCESSING INTERACTIONS WITH OTHER BLOCKS

The city data processing component is composed of 2 main functional blocks, which are :

- Data/event processing is in charge of handling (storing and processing) data collected

by various city data and event sources

- Context management is in charge of storing and delivering high level context information obtained from the processed data and events.

Functional components :

Each functional block is composed of several components having specific tasks.


ClouT – 30/09/2014

FIGURE 62: CITY DATA PROCESSING ARCHITECTURE

Stored Data Processing component manages all persistent data (historical data, meta-data storage, video/photo files, GIS information, etc.) including storing, querying and updating. It gathers data from the City Resource Access component.

Data Stream Processing component is in charge of managing transient data that are captured from the various data sources in the city (sensors, legacy devices, social networks, etc.) and evaluating dynamic continuous queries on those data streams. It gathers data from the City Resource Access component.

Data Healing component is responsible of identifying and correcting faulty data in stored data or data streams. The Data Healing component is optional and provides corrected data to the Stored Data Processing or the Data Stream Processing.

Event Engine takes as input both stored and streaming data and detects the occurrence of predefined events. The engine can also detect complex events composed of low-level basic events. The engine can notify the subscribers when their interested events occur.

Event Repository stores descriptions of different types of events that are defined by applications or end-users. The Event Engine uses this repository to match the captured events and notify the entities subscribed for those events.

Context Broker is the entry point to the citizen/city context information directly accessible by applications that show interest to a given context information. The broker can respond to both synchronous (get) or asynchronous requests (subscribe).

Context Resolution and Management component is responsible of maintaining the context information, storing it in the context repository, and responding any queries related to a context


ClouT – 30/09/2014

of a given user, or physical environment.

Context Repository manages both User Context information (profile, preferences, localization, etc.) and City Context information (temperature, sport/cultural events, pollution, etc.)


Orion Context Broker: Context Broker

MongoDB, MySQL: Stored Data Proecssing

ESPER CEP Engine: Stream Data Processing

MongoDB: Context/Event repository

Requirements

REQ_CPAAS_8 Sensor data collection

REQ_CPAAS_9 data pre-processing

REQ_CPAAS_10 Near real-time data processing

REQ_CPAAS_11 Context prediction

REQ_CPAAS_12 City Context information

REQ_CPAAS_14 Context-aware actions on the city

REQ_CPAAS_19 Verification of Event-Driven Behaviour

REQ_CPAAS_20 Assurance of Accurate Sensory Data

REQ_CPAAS_23 Configurable data collection

REQ_CPAAS_25 Primitive city context detection

REQ_CPAAS_26 High-level city context recognition

4.4.3. City Resource Access

Name: City Resource Access


Description:


ClouT – 30/09/2014

City Resource Access brings all the required functionalities needed to access the modules developed and deployed in the City Infrastructure as a Service layer. Its two main functional blocks are City Data Access & City Action Access Platforms.

FIGURE 63: CITY RESOURCE ACCESS INTERACTIONS WITH OTHER BLOCKS


FIGURE 64: FUNCTIONAL COMPONENTS FOR CITY RESOURCE ACCESS

City Data Access Platform: this block offers Platform as a Service capabilities to City Data

Processing and City Service Composition to orchestrate the access to the Service Management

services.

The City Data Access Platform has scalability mechanisms that enable the city data processing of

virtualised resources to the deployed City Applications, allowing them to access the stored City data

through the Service Management platform.

The City Data Access Platform exposes standard access APIs to City Data Processing and City

Service Composition. It also manages, and orchestrates, the access to the Service Management

framework for data services and to the Security & Dependability framework to check the

credentials of the users that asking to access the resources.


ClouT – 30/09/2014

FIGURE 65: CITY RESOURCE ACCESS PLATFORM INTERACTIONS


CDMI for Swift: City Data Access, City Action Access

Apache Tomcat: City Data Access, City Action Access

Requirements


- REQ_CIAAS_11: Cloud: Common sensor data format

- REQ_CIAAS_18: Scalable User Infrastructure

- REQ_CPAAS_1 - Cloud Storage - Store and Retrieve objects/data facilities

- REQ_CPAAS_4 - Reusable device services

- REQ_CPAAS_15 - Retrieve data from Cloud Storage

- REQ_CPAAS_24 - Standard service API provision


ClouT – 30/09/2014

4.5. Security & Dependability

Name: Security and Dependability

Layer: City Infrastructure as a Service, City Platform as a Service

Description:

Security and Dependability brings all the required security functionalities, included the protocols used, needed to check and authorize the access to the all the modules modules developed and deployed, including CSaaS. In particular CSaaS applications can leverage Security and Dependability Module or use their own A.A.A. system. Security and Dependability Module is composed by three main functional blocks: “Platform & Infrastructure Dependability Monitoring”, “Encrypting Facilities” and “Authentication, Authorization and Accounting”

.

FIGURE 66: SECURITY AND DEPENDABILITY INTERACTIONS WITH OTHER BLOCKS



ClouT – 30/09/2014

FIGURE 67: FUNCTIONAL COMPONENTS FOR SECURITY & DEPENDABILITY

Authentication, Authorization and Accounting (A.A.A) Platform: this block offers Authentication and

Authorization facilities to the City Infrastructure as a Service and City Platform as a Service layers.

The A.A.A Platform has scalability mechanisms to manage a great number of account and

authorization rules.

The A.A.A Platform exposes standard API based access to the City Infrastructure as a Service and

City Platform as a Service layers.

By ClouT architecture design choice, City Applications (within CSaaS) can leverage ClouT security

framework or use their own internal security modules; in order to do so, such Applications must be

trusted by the ClouT infrastructure.

FIGURE 68: SECURITY & DEPENDABILITY PLATFORM INTERACTIONS

Encrypting facilities:


ClouT – 30/09/2014

FIGURE 69: ENCRYPTING FACILITY PLATFORM INTERACTIONS

This block encompasses all the technologies and protocols used to encrypt stored data and communications between the applications and the other components running in the platform on each layer of the architecture (CSaaS, CPaaS and CIaaS). Typically this includes technologies such as SSL, TLS with various encryption algorithms.

Dependability Monitoring

This block monitors all the resources, hardware and software, running on CIaaS and CPaaS layers. In order to monitor the available resources, both a passive - remote probing of status - and/or active - an agent that’s local to each device/service - may be appropriate depending on circumstances. The monitoring facility is capable of checking the status of the monitored devices/service with minimal footprint and transmission overhead, while being highly customizable.


ClouT – 30/09/2014

FIGURE 70: DEPENDABILITY MONITORING INTERACTION WITH OTHER BLOCKS


- SOA3: Authentication, Authorization, Accounting

- Zabbix: Monitoring

- SSL, TLS, Others: Encrypting Facilities

Requirements


- REQ_CIAAS_33 Cloud Storage Authentication and Authorization security facilities

- REQ_CIAAS_34 Cloud: Infrastructure Security

- REQ_CIAAS_36 Data Storage encryption

- REQ_CIAAS_10 Data Storage encryption security

- REQ_CPAAS_2 Cloud Storage Authentication and Authorization security facilities

- REQ_CPAAS_3 Communication encryption

- REQ_CPAAS_21 Systems strategy description and evidence

- REQ_CPAAS_22 Collecting evidence

- REQ_CPAAS_29 Cloud Storage Authentication security facilities


ClouT – 30/09/2014

5. Mapping the Architecture

5.1. Introduction

Considering the ClouT global architecture and the final use cases defined within this document, this section focuses on the mapping of the architecture into a real world scenario. For this purpose, this section shows the applying the architecture to a generic scenario (involving the actors defined in the section 2.2.1 “Involved Actors”, being particularized (within D4.2 and D4.3) each of the use cases into the corresponding applications and field trials developed in the 4 pilot cities Genova, Santander, Mitaka and Fujisawa.

5.2. Mapping the Architecture to a Real World Scenario

Starting from the actors and the action sequence defined in section 2.2.1 “Involved Actors”. A generic real world scenario is composed of different types of actors that interact with the architecture in order to generate and offer a service (Municipality and Third Party developers), consume a service (citizens and Municipality users) and manage the infrastructure/platform (system administrators and infrastructure providers). For each of these actors, the interaction with the architecture is carried out in the following way:

First of all and in a transversal way to CIaaS, CPaaS and CSaaS layers, it lays the Security and Dependability module, in charge of the authentication and authorization of the users accessing to the platform. This translates into the assignment of different access policies and permissions according to the user role. In this sense, as detailed in Security and Dependability module, some applications in the CSaaS layer will use the authorization and authentication capabilities provided by the ClouT architecture, whilst the other ones will use their own mechanisms trusted by ClouT architecture.

Citizens and Municipality users: These actors access to the city applications provided by the CSaaS layer, applications that have been created using the corresponding tools provided by the CPaaS, using the resources and the data stored and processed at the CIaaS platform. These are users that only consume information from the platform by using the corresponding applications, but they are neither qualified nor authorized users for accessing to the CPaaS and CIaaS layers. In principle, these applications, created by third party service provider and application developers, could be part of other architecture using another security mechanism trusted by ClouT architecture.

Municipality and Third Party developers: These users want to access to the architecture in order to use the resources and services offered by the deployed platform, as well as to create and develop new applications mainly at the CSaaS layer. For this purpose, as a first step, the users access to the architecture through the security and dependability module located in the CPaaS layer, being assigned the corresponding permissions according to the user role. Once within the platform, the user can access to the City Service Composition block that provides the corresponding mechanisms to create and develop services as a composition of services from the city. Additionally, ,data from the CIaaS can be accessed and processed through the City Resource Access and City Data Processing modules, respectively. The communication between CPaaS and CIaaS will be carried out through the communication between City Resource Access module in CPaaS and City Infrastructure Management block in CIaaS. This module provides the


ClouT – 30/09/2014

corresponding mechanisms for accessing and managing the sensors, actuators, IoT devices, SNS and other information sources, including both physical and virtual resources, which compose the city platform, thus offering this data in a standardized way to the CPaaS layer.

System administrators and infrastructure providers: These actors will mainly access to the CSaaS and the CIaaS layers. Regarding to the CSaaS layer, applications for managing and monitoring the infrastructure as well as handling events and actuating over the deployed platform will be accessed by this type of users. In this sense, as these applications will be tightly related with the ClouT platform could integrate within the Clout architecture, using the security mechanisms provided by it. With respect to the access to CIaaS layer, it will be carried out through the security and dependability module, being assigned the corresponding credentials for accessing the CIaaS modules. In this sense, unlike to Municipality and Third Party developers, these users will directly access to the different resources provide by the platform by IoT Kernel and Sensorization and Actuatorization modules, thus modifying capabilities, adding or removing the resources that compose the platform. In addition to this, the Interoperability & City Resource Virtualization, formatting and homogenizing data coming from the platform resources. All the information retrieved by these resources will be processed and stored by the Computing & Storage module, offering a scalable and dependable cloud computing infrastructure for exploiting resources and city services properties, as well as storing the data provided by these resources. Finally, as previously indicated for Municipality and Third Party developers, the City Infrastructure Management module will act as bridge between CIaaS and CPaaS, thus managing and offering data from infrastructure resources to the upper layers.

Once defined the interaction of each type of users with the ClouT Reference Architecture and in order to clarify these interaction, Traffic Mobility Management use case is taken as an example of interaction among these three types of users and the three layers composing the ClouT Reference Architecture.


ClouT – 30/09/2014

FIGURE 71: INTERACTION WITH CLOUT REFERENCE ARCHITECTURE IN TRAFFIC MOBILITY MANAGEMENT USE CASE

In Figure 71, it can be seen that the interaction among the different users with the ClouT Reference Architecture:

The citizens access to different applications (within the CSaaS) that provide route planning according to certain user requirements and necessities, and also to the monitoring of the urban events that occurred in the city. As it can be observed in the figure, these types of applications could be developed by external third party users using their own security mechanism and accessing to the Security and Dependability block, as a trusted application.

The traffic company and the Municipality will use the traffic management application (in the CSaaS layer) for monitoring and managing the available resources that provide data to the upper layers. In this sense, considering that this application is tightly dependent from the ClouT architecture, then access will be carried out through the Security and Dependability block. Apart from that, they access to the CIaaS in order to add new IoT devices, sensors and actuators for providing the corresponding data for the traffic mobility use case. All this data will be processed and stored in the Computing & Storage block, formatting this data accordingly in the Interoperability & City Resource Virtualization module, which make them available to the City Infrastructure Management block.

Computing & Storage

Sensorization & Actuatorization

Interoperability & City Resource Virtualization

IoT Kernel

City Infrastructure Management

CIa

aS

City Resource Access

City Data ProcessingCity Service Composition

CP

aaS

Security an

d D

epen

dab

ility

CSa

aS

Route planning Urban eventsTraffic

Management

Citizen

Third

Party Se

rvice

Pro

vide

rTraffic C

om

pan

y/M

un

icipality


ClouT – 30/09/2014

Third Party service providers will enter to the platform through the Security and Dependability block, thus accessing to the Service Composition in order to generate the different applications of the CSaaS layer. In this sense, the City Service Composition will be fed by the data and events processed by the City Data Processing block and will be able to access and manage the different city and services/resources using the City Resource Access.

As it can be derived from this Traffic Mobility Management use case, the different users interact with the different layers of the platform producing and/or consuming the information provided by the subjacent platform. This interaction will be further detailed in coming WP4 deliverables (D4.2 and D4.3), as the rest of real implementations and deployments of the corresponding applications to be deployed in the four field trial cities of the project.

6. Conclusions

ClouT approach defines how Cloud and IoT can cooperate to obtain significant benefits in offering services for Smart Cities.

The proposed user scenarios shows how ClouT approach can be applied in different contexts, such as resources, emergency and pleasant management. The common aspect of all the contexts is the management of a relatively high amount of data in quasi-real time. As relatively high is intended both an high quantity of data and a burst of data concentrated in a limited time slot. In general modern cities, especially if willing to offer several high quality services, must face the issues related to the described aspects: for example a simple traffic jam can produce a sudden access of great number of involved drivers to smartphones applications to know the reason and potential alternative ways. Moreover special public events such as exhibitions or sporting events or natural disasters can increase this amount of data processed and used for a certain period of time that can be longer than a simple burst. These events are not so unusual in cities, regardless their dimension: they can occur in big cities as well as in small cities.

The issues raised by these aspects are not the only ones to be considered. The efficiency of public services for young and old people, emergency or healthcare is strictly related to the quantity and the quality of information shared between municipalities an citizens and among the citizens.

For all the use scenarios considered the data must be collected as finer-grained as possible: sensors managed by gateways and virtualized provide a continuous information flow that should be stored, processed together with other data and produce other information that, in turn, should be stored. Moreover time limited data burst lasting from few seconds to few days should be processed in quasi-real time and implementation of reactions to either simple or very complex alerts must always be supported by the infrastructures of the city.

The simplest solution is to provide the hardware needed to store the required data for an appropriate amount of time and to face the load peaks in the worst case. The costs are enormous, totally unaffordable for small municipalities, but also very difficult to sustain for big cities, especially if a good quality of service is requested.

Cloud technology is the real answer: ClouT approach demonstrates that it can be specialized for SmartCities applications. In particular the infrastructure layer (CIaaS) enables the


ClouT – 30/09/2014

abstraction of the concept of sensor, taking into account also social networks which are a very precious data source and provides an unlimited and secure storage capability. The platform layer (CPaaS) enables the composition of services and data processing, enabling the developers of the software layer (CSaaS) to offer services more and more innovative. Cloud technology provides these features with elasticity and cost effectiveness, enabling small (but also big) municipality to provide services always dimensioned as required and to pay only for the resources used.

For these reasons ClouT approach has the potentiality to make small municipalities willing to make a first step into the Smart City way easy and cheap, while making already smart cities even smarter.


ClouT – 30/09/2014

REFERENCES

[DoW] FP7 EU Research Project “Cloud of Things for empowering the citizen clout in smart cities ", Grant agreement no: 608641, Version date: 2013-03-26 - Annex I - "Description of Work".

[NIST] Fang Liu, Jin Tong, Jian Mao, Robert Bohn, John Messina, Lee Badger and Dawn Leaf “NIST Cloud Computing Reference Architecture” - September 2011.

Peter H. Deussen (Fraunhofer), Toshihiro Suzuki (IPA) “Open Cloud Interoperability Framework” – 28/10/2013.

An Oracle White Paper “Cloud Reference Architecture” - November 2012.

Atif Alamri, Wasai Shadab Ansari, Mohammad Mehedi Hassan, M. Shamim Hossain, Abdulhameed Alelaiwi, and M. Anwar Hossain “A Survey on Sensor-Cloud: Architecture, Applications, and Approaches” - November 2012.


ClouT – 30/09/2014

APPENDIX

APPENDIX A – FULL SYSTEM REQUIREMENTS SPECIFICATIONS

Field Description

ID REQ_CIAAS_1

Title Cloud: Infrastructure Scalability

Requirement Type Non-Functional - Performance

Requirement Description The system shall guarantee infrastructural scalability to respond to increasing workloads. Adding more computational/storage nodes should be easy and non-disruptive.

Priority Mandatory

User Requirement ID FR14, FR20,FR24



Rationale Huge workloads are expected, especially in case of city events or disasters

History 10/2013: creation of requirement. 09/2014: requirement updated

Field Description

ID REQ_CIAAS_2

Title Standardized data formats between mobile user devices and servers

Requirement Type Non Functional - Interoperability

Requirement Description The system shall provide the mechanisms to enable the data transmission between the application installed in the mobile phone and the server, providing different standardized formats for transmitting the information.

Priority Mandatory

User Requirement ID FR5, FR10, FR13

Related Architectural City Infrastructure Mangement, Interoperability & City Resource


ClouT – 30/09/2014

Field Description

Components Virtualisation

Rationale It is needed to send standardized information from deployed IoT devices and mobile applications to the corresponding server and vice versa, as well as to interact with external users.


Field Description

ID REQ_CIAAS_3

Title Cloud: Open Infrastructure

Requirement Type Non-Functional

Requirement Description The system shall adopt open formats for its virtual assets to avoid vendor lock-in and ease migration from and to other software platforms.

Priority Mandatory

User Requirement ID FR26



Rationale Open standards for virtual assets guarantee ease of asset migration and avoid vendor lock-in


Field Description

ID REQ_CIAAS_4

Title Manage available resources

Requirement Type Functional - Management

Requirement Description In order to manage the resources offered by the infrastructure, the system shall provide the corresponding description associated to the available resources, as well as enable the maintenance policies to control the status of the aforementioned resources. These policies include the addition of new resources as well as the removal of resources working in a wrong way, or the inclusion of


ClouT – 30/09/2014

Field Description

new sensing capabilities associated to a resource.

Priority Mandatory



IoT Kernel, City Infrastructure Management

Rationale It is needed to manage the resources in order to maintain network resources updated.


Field Description

ID REQ_CIAAS_5

Title Turning social network into sensor


Requirement Description A social network can be seen and used as a sensor, but it provides many noisy data. To turn social network data into useful sensor data, it is necessary to remove noisy data from social network.

Priority Mandatory



Sensorisation and Actuatorisation

Rationale It is necessary to remove noisy data from social network


Field Description

ID REQ_CIAAS_6

Title Making legacy sensors to IoT sensors


Requirement Description There are many legacy sensors which already deployed in city, but many of them are not connected the Internet or not accessible. It is


ClouT – 30/09/2014

Field Description

necessary to export legacy sensors/actuators as virtual IoT devices.

Priority Mandatory




Rationale It is necessary to export legacy sensors as virtual IoT devices to exploit existing resources.

History 10/2013: creation of requirement 09/2014: requirement updated

Field Description

ID REQ_CIAAS_7

Title Turning legacy actuators into IoT actuators


Requirement Description There are many legacy actuators which already deployed in the city, but many of them are not connected the Internet or not accessible. It is necessary to export legacy sensors/actuators as virtual IoT devices.

Priority Mandatory




Rationale It is necessary to export legacy actuators as virtual IoT devices to exploit existing resources.

History 10/2013: creation of requirement 09/2014: requirement updated

Field Description

ID REQ_CIAAS_8

Title Cloud: Infrastructure Deployment


ClouT – 30/09/2014

Field Description


Requirement Description The system shall be easily deployable on existing hardware infrastructures with minimal disruption in order to fully exploit hardware assets that are already at Municipality disposal

Priority Recommended




Rationale Easy deploying means less time to market and no need to change available hardware resources


Field Description

ID REQ_CIAAS_9

Title Cloud: Network Virtualisation


Requirement Description The system shall be capable of isolating network traffic in multi-tenancy environments for security and privacy reasons


User Requirement ID FR18,FR16



Rationale Network virtualisation means easier network management and network isolation between different tenancies


Field Description

ID REQ_CIAAS_10

Title Data Storage encryption security


ClouT – 30/09/2014

Field Description

Requirement Type Non-Functional - Security

Requirement Description The encrypted data, if not properly protected, may be subject to analysis and tampering. As to prevent tampering and illegal analysis of the data, the system must not store private keys, used for encryption, in the servers containing the encrypted files.

Priority Mandatory

User Requirement ID FR16,FR18, FR19



Rationale To safely keep encrypted data from tampering


Field Description

ID REQ_CIAAS_11

Title Cloud: Common sensor data format

Requirement Type Non-Functional - Interoperability

Requirement Description All the sensors, including legacy and sensorised devices, must communicate in a common data format to the cloud storage back-end. This requires the adoption of a cloud storage standard protocol and a translation layer.


User Requirement ID FR9,FR10,FR21,FR27


Interoperability & City Resource Virtualisation (Semantic & Syntactic Interoperability), City Resource Access, Sensorisation and Actuatorisation, IoT Kernel

Rationale Employing one standard language to communicate with the cloud storage


Field Description


ClouT – 30/09/2014

Field Description

ID REQ_CIAAS_12

Title Cloud: High throughput

Requirement Type Non Functional - Performance

Requirement Description In order to guarantee the high throughput required to receive and retrieve sensor and application data the system shall be capable of handling a huge amount of inbound/outbound data employing high performing networking technologies and load balancing solutions.




Computing and Storage

Rationale Huge amounts of data coming in and out of the cloud require an agile infrastructure


Field Description

ID REQ_CIAAS_13

Title Cloud: High availability

Requirement Type Non Functional - Dependability

Requirement Description The system shall guarantee high availability for both reliable data collection & elaboration and to keep the developed software up and running




Computing and Storage

Rationale The system should be available even in adverse conditions



ClouT – 30/09/2014

Field Description

ID REQ_CIAAS_14

Title Sensor Description

Requirement Type Functional

Requirement Description Sensor Description must be provided by the system for realizing interoperability of data. Sensor Description includes structure of produced data, unit of the data, sampling rate, resolution of data.




Interoperability & City Resource Virtualisation, Sensorisation and Actuatorisation, IoT Kernel

Rationale To know the type of information of sensor data for interoperability

History 10/2013: Creation of requirement.

Field Description

ID REQ_CIAAS_15

Title Application Description


Requirement Description Application Description must be provided by the system for realizing interoperability of data. Application description includes acceptable structure of data, unit of the data. For demanding application it may require sampling rate and resolution of data.




Interoperability & City Resource Virtualisation

Rationale To know the type of information which the application need for interoperability



ClouT – 30/09/2014

Field Description

ID REQ_CIAAS_16

Title Conversion Function


Requirement Description Interoperability function must provide conversion function that converts the structured of data and unit of the data





Rationale To provide interoperability capability


Field Description

ID REQ_CIAAS_17

Title Virtualisation (Abstracting)


Requirement Description Because there are many type of sensors and CPUs for sensor nodes, it is difficult to access to sensors on the nodes. To access them easily, it is necessary to virtualize them.


User Requirement ID FR21, FR22


IoT Kernel, Interoperability & City Resource Virtualisation

Rationale To make it easy to access many types of sensors and CPUs.


Field Description


ClouT – 30/09/2014

Field Description

ID REQ_CIAAS_18

Title Scalable User Infrastructure


Requirement Description The system should scale to thousands of users and hundred thousand of access requests per month.




City Infrastructure Management (City Entity Management, City Resource Access), Security and Dependability (A.A.A.)

Rationale To guarantee service for a lot of users and requests per user.


Field Description

ID REQ_CIAAS_19

Title Scalable Device Infrastructure


Requirement Description The system should scale to hundreds of thousands of devices, producing several MB of data per day.


User Requirement ID FR20, FR24, FR25, FR26, FR27, FR30, FR31


IoT Kernel (Uniform Access…), Sensorisation and Actuatorisation (Uniform Access…)

Rationale It is needed to support an increasing number of devices because of new deployments in already covered areas or new areas covered by the service.


Field Description


ClouT – 30/09/2014

Field Description

ID REQ_CIAAS_20

Title Device sharing

Requirement Type Functional - Control

Requirement Description The user should be able to easily share his devices in the Cloud with other users, and to control them (make them shared/unshared, get information on who is accessing them).

Priority Mandatory



City Infrastructure Management (Service Management)

Rationale Social Web Of Things scenario in which the devices participate in the Social Network life of the users.


Field Description

ID REQ_CIAAS_21

Title Interoperable sensing infrastructure


Requirement Description Given the strong heterogeneity in the city infrastructure in terms of IoT protocols, legacy devices, etc. the ClouT’s sensing backbone shall support different protocols and standards using different data formats, implementation paradigms...etc

Priority Mandatory




Rationale In order to take into account the existing heterogeneity in city infrastructures.


09/2014 Update of the requirement


ClouT – 30/09/2014

Field Description

ID REQ_CIAAS_22

Title Commands to IoT devices


Requirement Description IoT devices shall embed necessary functions to provide data gathering and/or to perform actions.

Priority Mandatory



IoT Kernel

Rationale In order to perform remote data gathering and action execution on the devices.



Field Description

ID REQ_CIAAS_23

Title Device and service descriptions


Requirement Description The system shall provide expressive, flexible and easy to extend device and service descriptions.

Priority Mandatory



Interoperability & City Resource Virtualisation, IoT Kernel

Rationale To be able to describe many functionalities of services and personalise them when necessary




ClouT – 30/09/2014

Field Description

ID REQ_CIAAS_24

Title Common Data format

Requirement Type Non Functional – Interoperability

Requirement Description The system shall provide agreed common format for IoT device data exchange (sensor data, events, etc.)

Priority Mandatory




Rationale To be able to ensure the device data interoperability



Field Description

ID REQ_CIAAS_25

Title Common APIs


Requirement Description The system shall provide agreed service access interfaces gathering data and performing actions

Priority Mandatory




Rationale To be able to ensure the interoperability of accessing to device resources



ClouT – 30/09/2014

Field Description


Field Description

ID REQ_CIAAS_26

Title Integration of any data source


Requirement Description The system shall support seamless integration of any entity providing city data (IoT device, legacy device, web application,etc.)




Interoperability & City Resource Virtualisation, IoT Kernel, Sensorisation and Actuatorisation

Rationale To be able to include as many data sources as possible to the city infrastructure.



Field Description

ID REQ_CIAAS_27

Title Access to city resources

Requirement Type Functional – Resource Access Configuration

Requirement Description The system shall provide access to any given city resource in a configurable manner

Priority Mandatory


Related Architectural City Infrastructure Management


ClouT – 30/09/2014

Field Description

Components

Rationale To be able to customize the means of access to resources (e.g., synchronous, vs asynchronous)



Field Description

ID REQ_CIAAS_28

Title Resource discovery

Requirement Type Functional – Resource Discovery

Requirement Description The system shall provide discovery and lookup of city resources

Priority Mandatory




Rationale To be able to discover the resource that applications really need.



Field Description

ID REQ_CIAAS_29

Title Resource repository

Requirement Type Functional – Resource Repository

Requirement Description The system shall provide a repository where the descriptions of resources (physical, sensorised a virtualised sensors) and their respective properties are stored for lookup. The repository shall expose an API to ease remote querying from different services.


ClouT – 30/09/2014

Field Description

Priority Mandatory




Rationale To be able to maintain the list of available resources in the system.



Field Description

ID REQ_CIAAS_30

Title Resource identification

Requirement Type Functional – Resource Identification

Requirement Description The system shall provide mechanisms to uniquely identify city resources

Priority Mandatory




Rationale To avoid any name conflicts for resources.



Field Description

ID REQ_CIAAS_31

Title Autonomic discovery

Requirement Type Functional – Resource Discovery


ClouT – 30/09/2014

Field Description

Requirement Description The system should support autonomic discovery and binding of devices/services/resources based on requirements of the clients





Rationale To avoid manual binding of resources to services/applications



Field Description

ID REQ_CIAAS_32

Title Plug&play integration of city resources

Requirement Type Functional – Resource integration

Requirement Description The system shall provide means for seamless and automatic integration of city devices/services/resources into the existing infrastructure

Priority Mandatory




Rationale To avoid manual integration of resources.



Field Description

ID REQ_CIAAS_33


ClouT – 30/09/2014

Field Description

Title System Monitoring

Requirement Type Non Functional – Dependability & Availability

Requirement Description The system shall enable the users (municipalities) to monitor the state of the physical resources available. Physical resources include both IoT Devices and servers. As an optional requirement, the system should provide software monitoring capabilities.




Security & Dependability (Platform and Infrastructure Dependability Monitoring)

Rationale The Municipality should be constantly aware of the status of all the systems and devices and be capable to swiftly respond to abnormal system behaviours

History 08/2014: creation of requirement.

Field Description

ID REQ_CIAAS_34

Title Cloud: Infrastucture Security

Requirement Type Functional – Security

Requirement Description The system shall provide A.A.A. at infrastructure level for administrative purposes.

Priority Mandatory

User Requirement ID FR16,FR18,FR19



Rationale Direct access to the infrastructure resources should be allowed only to system administrators


Field Description


ClouT – 30/09/2014

Field Description

ID REQ_CIAAS_35

Title Cloud: Scalable Storage Architecture

Requirement Type Non Functional – Dependability & Availability, Performance

Requirement Description The system shall guarantee storage performance, resilience and scalability. Adding more nodes to extend available storage space should be fast and non-disruptive.


User Requirement ID FR20,FR24,FR25,FR30



Rationale A high performing, reliable and scalable storage backend is needed to store, retrieve and safely keep huge amounts of data


Field Description

ID REQ_CIAAS_36

Title Data Storage encryption

Requirement Type Non Functional – Security

Requirement Description The system data must guarantee encryption facilities to prevent unauthorized accesses to the data. The encryption of the data must be transparent to the applications.

Priority Mandatory

User Requirement ID FR16,FR18, FR19



Rationale Employing security and access control to the data stored in distributed environments.



ClouT – 30/09/2014

Field Description

ID REQ_CPAAS_1

Title Cloud Storage - Store and Retrieve objects/data facilities

Requirement Type Functional – Access cloud storage data

Requirement Description The system shall provide a service that enables the store of data, related to a wide range of time (e. g. week), coming from IoT devices, mobile phones, social networks, applications, etc., into the Cloud Storage. This service must allow storing small data or big/large data (files).

Priority Mandatory



City Resource Access (City Data Access)

Rationale To provide a common and standard layer to access (store and retrieve) data.


Field Description

ID REQ_CPAAS_2

Title Cloud Storage Authentication and Authorization security facilities


Requirement Description The system shall control access to data via authentication and authorization functionalities. Role based access policies should be available to check if users are authorized to perform the action (e.g. PUT Object) on the object or to store the sensors data. The role and the authorization to access an object (sensor data or object data) should be checked on user/password credentials and/or on the certificate used by the client.

Priority Mandatory




Rationale To provide a common and standard layer to provide authentication


ClouT – 30/09/2014

Field Description

and authorization facilities.


Field Description

ID REQ_CPAAS_3

Title Communication encryption

Requirement Type Non Functional – Security access

Requirement Description The system shall expose Cloud Storage APIs primitives based on encryption protocols. The communication must to be provide standard encryption protocols (e.g. HTTPS protocol).

Priority Mandatory



Security & Dependability (Crypting Facilities)

Rationale To provide a security access to the data stored in the cloud storage.


Field Description

ID REQ_CPAAS_4

Title Reusable device services

Requirement Type Non-Functional – Service oriented approach

Requirement Description The system shall provide devices as reusable services.




Ciy Resource Access

Rationale To reuse devices as services for different applications.



ClouT – 30/09/2014

Field Description


Field Description

ID REQ_CPAAS_5

Title Service composition tools

Requirement Type Functional – Service creation

Requirement Description The system shall provide easy-to-use application creation tools (textual language, graphical tool) to mash-up different data sources such as IoT and sensorised devices together.




City Service Composition

Rationale To enable service/application creation by end-users/developpers



Field Description

ID REQ_CPAAS_6

Title Dependable service creation

Requirement Type Non-functional – Dependability

Requirement Description The system shall provide mechanisms to assure the correctness of the composed services.






ClouT – 30/09/2014

Field Description

Rationale To enable dependable service/application creation that conforms to specifications defined.



Field Description

ID REQ_CPAAS_8

Title Sensor data collection

Requirement Type Functional – Data collection

Requirement Description The system shall provide support for real-time sensor data gathering

Priority Mandatory




Rationale To be able to get informed in real-time by the events occurring in the city captured by sensors.



Field Description

ID REQ_CPAAS_9

Title Data pre-processing

Requirement Type Functional – Data processing

Requirement Description The system shall allow pre-processing of data on devices




ClouT – 30/09/2014

Field Description



Rationale to exploit data processing capabilities of devices, thus avoid unnecessary transfer of raw information from devices.



Field Description

ID REQ_CPAAS_10

Title Near real-time data processing

Requirement Type Functional – Data processing

Requirement Description The system shall provide near real-time processing of high amounts of data coming from the city infrastructure.

Priority Mandatory




Rationale to extract useful information for the smart city applications



Field Description

ID REQ_CPAAS_11

Title Context prediction

Requirement Type Functional – Context data


ClouT – 30/09/2014

Field Description

Requirement Description The system shall be able to predict future context of the citizens and the city environment.





Rationale Use contextual information for smart city applications



Field Description

ID REQ_CPAAS_12

Title City Context information

Requirement Type Functional – Context data

Requirement Description The system shall provide high level contextual information on the citizens and the city

Priority Mandatory




Rationale Use contextual information for smart city applications




ClouT – 30/09/2014

Field Description

ID REQ_CPAAS_14

Title Context-aware actions on the city

Requirement Type Functional – Contextual actions

Requirement Description The system shall perform actions on the city infrastructure on a given device based on the contextual information.

Priority Mandatory


Rationale to take necessary actions based on the contextual information in order to optimize resource usage in the city





Field Description

ID REQ_CPAAS_15

Title Retrieve data from Cloud Storage

Requirement Type Functional – Data access

Requirement Description The system shall provide a service to be that enables the retrieval of data from Cloud Storage. This service must allow the retrieval of both small (for example temperature coming from sensors stored) and big/large data (images, documents) stored into Cloud Storage environment.

Priority Mandatory



City Resource Access (City Data Access)

Rationale To provide access to the data stored in the cloud storage.



ClouT – 30/09/2014

Field Description

ID REQ_CPAAS_16

Title Data Replication

Requirement Type Non Functional – Data availability

Requirement Description The system shall provide data replication functionalities. The data must be replicated to guarantee a high availability of service also in case of fail over.

Priority Mandatory




Rationale To provide high availability to the data access.


Field Description

ID REQ_CPAAS_17

Title Backup data on Cloud Storage

Requirement Type Non Functional – Backup data

Requirement Description The system must backup online data, stored in the cloud storage, in external storage systems. The backup must be periodical and configurable. The backup could be full, e.g. snapshot of the database, or incremental. The objects (files) and data stored in the noSQL database are object of the backup. The backups must be transparent to the applications and without blackout of the service. These data can be useful to perform other analysis (e.g. business analysis).

Priority Mandatory




Rationale To provide large amounts of data to processes that need to create statistics or business analysis


ClouT – 30/09/2014

Field Description


Field Description

ID REQ_CPAAS_18

Title Development of mashups/widgets

Requirement Type Functional - Application Creation

Requirement Description Creation and development of different mashups/widgets associated to the services to be deployed.





Rationale Show in a friendly way the corresponding information, as well as provide a good manageability experience to the user.


09/2014: requirement updated

Field Description

ID REQ_CPAAS_19

Title Verification of Event-Driven Behaviour

Requirement Type Non Functional – Reliability

Requirement Description The system shall verify its complex event-driven behaviour that affects shared spaces for multiple users and multiple applications.

Priority Optional




Rationale Event-driven behaviour that deals with multiple users and multiple applications tends to be very complex and involves unexpected


ClouT – 30/09/2014

Field Description

features interactions, which may have a large undesirable impact on human users.


Field Description

ID REQ_CPAAS_20

Title Assurance of Accurate Sensory Data


Requirement Description The system shall correct data faults included in city data. Usually, different kinds of faults appear in the city data. The system shall deal with multiple faults simultaneously.

Priority Optional




Rationale Sensor output often includes erroneous values of different kinds, such as continuous errors or temporary errors, while the output should be reliable to proper support context-aware behaviour of the application


Field Description

ID REQ_CPAAS_21

Title Systems strategy description and evidence


Requirement Description The system needs to provide the means to describe the strategy and evidence to meet non-functional requirements in a structured way.

Priority Optional


Related Architectural Security & Dependability (Platform and Infrastructure


ClouT – 30/09/2014

Field Description

Components Dependability Monitoring)

Rationale The system needs to provide the means to describe the strategy and evidence to meet non-functional requirements in a structured way


Field Description

ID REQ_CPAAS_22

Title Collecting evidence


Requirement Description The system need to collect evidences from the system itself that are required to prove it is actually running.

Priority Optional



Security & Dependability (Platform and Infrastructure Dependability Monitoring)

Rationale The system must collect evidence from its components to check that they are actually running


Field Description

ID REQ_CPAAS_23

Title Configurable data collection

Requirement Type Non Functional

Requirement Description The data acquisition should be configurable through a set of basic parameters chosen by the local admin.

Priority Optional


Related Architectural City Data Processing


ClouT – 30/09/2014

Field Description

Components

Rationale Data acquisition should be configurable to easily wrap different data harvesting needs


Field Description

ID REQ_CPAAS_24

Title Standard service API provision


Requirement Description The system should provide access to services, available in CPaaS, through API based on standard (official or de-facto) description languages.

Priority Optional

User Requirement ID


Interoperability & City Resource Virtualisation, City Resource Access

Rationale Standard APIs helps exploiting the available resources while guaranteeing compatibility


Field Description

ID REQ_CPAAS_25

Title Primitive city context detection


Requirement Description For creating smart city application, it is necessary to detect primitive city context through temporal-spatial analysis of city data. It should firstly analyse simple city context such as "context changed", "usual context" or "unusual/emergency context". Then provide to applications or further analysis for high-level city context recognition.


ClouT – 30/09/2014

Field Description

Priority Mandatory




Rationale To create true smart applications the system has to be capable of understanding and providing applications with data context.


Field Description

ID REQ_CPAAS_26

Title High-level city context recognition


Requirement Description For creating smart city application, it is necessary to detect primitive city context through temporal-spatial analysis of city data. It should firstly analyse simple city context such as "context changed", "usual context" or "unusual/emergency context". Then provide to applications or further analysis for high-level city context recognition.

Priority Mandatory




Rationale To create true smart applications the system has to be capable of understanding and providing applications with data context.


Field Description

ID REQ_CPAAS_27

Title Open Data support



ClouT – 30/09/2014

Field Description

Requirement Description The system should provide support for open data provision by adopting open file formats compliant with open data European specifications.

Priority Optional




Rationale Open data is crucial to municipalities willing to share their data with citizens and organizations


Field Description

ID REQ_CPAAS_28

Title Cloud Development Platform


Requirement Description In order to ease the development of ClouT-enabled applications, the system shall provide an easy-to-operate mechanism that allows the instantiation of customizable development environments at platform level

Priority Optional




Rationale Eases the development of new smart city services


Field Description

ID REQ_CPAAS_29


ClouT – 30/09/2014

Field Description

Title Cloud Storage Authentication security facilities


Requirement Description The system must provide security facilities to CPaaS and CSaaS cloud layers, based on certificates and/or user/password credentials, to store (IoT, physical devices, virtual devices, etc.) data and retrieve (CSaaS applications) data (objects or sensor historical data) from Cloud Storage.

Priority Mandatory



Security & Dependability (Crypting Facilities, A.A.A.)

Rationale Employing security and access control to the CSaaS and CPaaS applications.


Field Description

ID REQ_CPAAS_30

Title Dynamic computational resource scaling


Requirement Description In order to fully exploit virtualised computational resources and optimize their consumption, the system shall provide a dynamic scale-up/scale-down resource allocation mechanism at platform level. Such vertical scaling approach guarantees a quick response from software deployed at platform level (e.g.: big data analysis, middleware) while maintaining a continual optimization of the allocated resources. The system should be able to dynamically scale resources allocated within specific constraints specified by the users (municipalities). This approach would introduce an effective load-balancing mechanism at platform level.

Priority Optional

User Requirement ID FR20,FR23,FR24




ClouT – 30/09/2014

Field Description

Rationale Deployed services should consume available resources according to actual workload


APPENDIX B – CITIZENS AND STAKEHOLDERS’ SURVEYS

Stakeholders’ Survey

This is a text-only version of the stakeholders’ survey form, it includes all the questions that are submitted to the surveyed in the original document.

Survey Introduction

This is a Survey from the ClouT Project (http://clout-project.eu), a Research Project co-funded by the European Community's Seventh Framework Programme and the National Institute of Information and Communications Technology of Japan. The project aims at identifying, prototyping and validating the ClouT Reference Architecture which extends the cloud paradigm to the Internet of Things (IoT) and Internet of People (IoP) in order to enable a smarter city ecosystem

This survey is aimed to collect insights from a group of stakeholders on IoT/Cloud related topics. The data provided through this survey will be used to support ClouT project in defining concrete functionalities that will be covered by the ClouT Reference Architecture.

Surveyed Profile

Age: Gender:

Male: Female:

1. To which of the following groups do you belong?

IT Company

City

Research centre

Education centre

Application developer

Service provider

Other

2. Does the IoT (Internet of things) concept sound familiar to you?


ClouT – 30/09/2014

(1) Not at all Familiar

(2) Not so much Familiar

(3) Moderately Familiar

(4) Quite Familiar

(5) Very much Familiar

3. Does the Cloud computing concept sound familiar to you?




(4) Quite Familiar


General purpose questions

4. Could you please rate the following according to your point of view? What are the main aims of the Smart City applications?

Very Important Important Not Important Indifferent

Support citizens’ concerns (security, city cleanliness)

Make city more attractive for citizens and visitors

Help save costs

Increase citizen participation to the city life

Reduce/Prevent risks (incidents, environments disasters, …)

Monitor environmental parameters (air quality, energy consumption, …)

Improve the quality of life

Make cities safer

Ease the city economic and social growth

5. What would a Smart City of the future look like? Please, provide the major trends in terms of the smart city concept based on your own experience and knowledge.


ClouT – 30/09/2014

6. What do you think are the top three applications of Smart City (according to your expertise) and which are their limitations (if present)?

7. In your opinion, what are the main barriers (if any) that prevent Smart City Applications to take off?

Cloud and IoT related questions

8. Could you please rate the following according to how, in your opinion, they may support the future IoT? You can add a short explanation of why you consider it useful, very useful or not useful in the boxes below each item:

Very Useful Useful Not Useful Indifferent

Big Data Management

(volume i.e data size; variety i.e data types, velocity; i.e. data generation frequency)

Transform social network feeds as valuable data sources (sensorisation of social network concept)

Composition and aggregation of different IoT sensors to produce new (not otherwise) available data source

Support to long-term need of computing resources

Support to sudden increase of computing resources

Open access to IoT data from different cities

Ease discovery, identification and management of IoT resources

IoT Data/Sensor monitoring

Security aspects (communication, authentication, authorization, …)

Access to data storage facilities based on common standards

Easier access to city resources (sensors, actuators, social networks, media, participatory sensing facilities)

A platform to easily plug and play city resources or legacy devices under a cloud based approach

Leave people the opportunity to create new services by themselves


ClouT – 30/09/2014

9. In your opinion, what are the fields where IoT technology is mature enough to respond (environmental monitoring, decision making, service creation tools, virtualized computing and storage resources, etc.)?

10. What are, in your opinion, the pros and cons (if any) of leveraging Cloud computing in the Internet of Things?

a. From the Perspective of the Citizen

b. From the Perspective of the City Authority

c. From the Perspective of an IT Company

d. From the Perspective of a Research Centre

e. From the Perspective of an Educational Centre

f. From the Perspective of a Service Provider

g. From the Perspective of an Application Developer

h. From other perspective not listed before

Perspective: ___________________________________

11. Do you think ClouT can become a “product” to support any city?

yes no

If you think so, may you provide several approaches related to the sustainability of Cloud Computing in the Internet of Things domain after the funding from EU runs out (potential business cases)? In particular:

a. Who are the customers (e.g. research, industry and end consumers of services) and who will pay for what?

b. Should we form a company to control ClouT (developed SW, replicability of deployed applications …)?

c. When should we make decisions (a business model should be implemented during the project for exploiting ClouT outcomes)?


ClouT – 30/09/2014

12. Do you have any other comments or suggestions related to leveraging Cloud computing in the Internet of Things in order to enable a smarter city ecosystem?

Genoa Citizens’ Survey

This is a text-only version of Genoa citizens’ survey form, it includes all the questions that are submitted to the surveyed in the original document.

This is a Survey from the ClouT Project (http://clout-project.eu), a Research Project co-funded by the European Community's Seventh Framework Programme and the National Institute of Information and Communications Technology of Japan. This survey aims at identifying the key aspects of the IoT (Internet of Things) and IoP (Internet of People) world in combination with the cloud paradigm to create the future internet.

1. Do you use or own a smartphone as your primary mobile phone?

□ Yes

□ No ( if No skip question n.2, n.3)

2. How familiar are you with the usage of smartphones in general?

Not at all Familiar




(4) Quite Familiar


3. What Mobile Operating Systems do you use?

iOS (iPhone) Android

(Samsung, LG…) Microsoft Windows Phone Blackberry OS OS Palm


ClouT – 30/09/2014

4. How familiar are you with Internet of things ?

Not at all Familiar




(4) Quite Familiar


5. In which application of Internet of things are you more interested ? ( you can check more than one item)

□ Infant Monitor (provides information about baby’s temperature, position, breathing ,…

□ Track performance in sport (

□ Monitor an aging family member

□ Smart thermostats

□ Multi-Functional Lights

□ Consumption Sensors (Light, Water, …)

□ Smart Bin to reduce the number of pick-ups

□ Parking Space Availability

□ Weather Sensors

□ Air Quality Sensors

□ Hydrometers (track water level)

□ Protect WildLife

□ Traffic monitoring

□ Public Transport measuring

□ Social Sensors (Trends, Events, etc…)

□ Presence sensors (adapt lighting according to presence, security, …)


ClouT – 30/09/2014

□ Other

2 ClouT – Field Trials

Answer all questions by ticking the box marking an x in the answer box. Please feel free to express your sincere opinion.

6. The following list illustrates the five field trials developed in the four cities within the ClouT consortium during the first year of the project. Please indicate your level of interest for their provision. (1: Not interested at all, 5: Very interested)

1 2 3 4 5

Fujisawa - Detect various city information related to safely, emergency and healthy contexts. City infrastructure can be controlled (street lights, traffic, alerts, information displays, etc).

□ □ □ □ □

Fujisawa - Detect and classify social events that occur inside the city, and visualize them into map-based visualizer

□ □ □ □ □

Genova – ‘IoNonRischio' risk alert management including information from weather stations and urban mobility, thus processing it accordingly and developing service to access data from sensors and to get improved graphics, better features and accessibility.

(www.iononrischioclout.comune.genova.it)

□ □ □ □ □

Mitaka - Motivate citizens to act something new and notice city events by delivering customized local information based on information registered by citizens. Associated to services such as, healthy walking program, community creating and shopping support.

□ □ □ □ □

Santander - Allow users to send enriched content events and incidences in the city while following the actuation on these incidences accordingly.

□ □ □ □ □

7. The following list illustrates a set of dataset (Internet of Things, geo spatial database) that are provided by IoNonRischio. Please indicate your level of interest towards their provision:

1 2 3 4 5


ClouT – 30/09/2014

Civil Protection Alarm □ □ □ □ □

Hydrometers □ □ □ □ □

Infomobility Webcam □ □ □ □ □

Risk Areas □ □ □ □ □

Tourism Webcam □ □ □ □ □

Video Message System (VMS) □ □ □ □ □

Weather Sensors □ □ □ □ □

8. Please, describe what your experience with the first release of IoNonRischio (powered by ClouT) was.

Place an X in the box closer to the feeling you experienced

1 2 3 4 5

Unhappy □ □ □ □ □ Happy

Calm □ □ □ □ □ Excited

Sleepy □ □ □ □ □ Wide-awake

Unsatisfied □ □ □ □ □ Satisfied

9. Based on your experience using the service, please indicate your level of agreement (1: Totally Disagree, 5: Totally Agree) with the following statemens.

1 2 3 4 5

I found the service easy to use □ □ □ □ □

I intend to use the service in the future □ □ □ □ □

In general, the Local Authority has supported the use of the system. □ □ □ □

□

I found it easy to get the service to do what I want it to do □ □ □ □ □

Using the system makes me more flexible □ □ □ □ □


ClouT – 30/09/2014

The system is compatible with other systems I use. □ □ □ □ □

People who are important to me think that I should use the system. □ □ □ □

□

I like to experiment with new information technologies. □ □ □ □ □

10. Please provide, based on your experience of the Application, a new user we can interact with that could help us improve the final version of IoNonRischio

11. Please describe the most important requirements that the final version of the app must have (i.e. 24x7 support, highly automated, reliability, scalability, quality of data, etc…)

12. Do you have a particular idea for an application to enhance your daily life? Please describe it.

3 Demographic Information

Answer all questions by ticking the box marking an x in the answer box.

13. What is your gender?

□ Male

□ Female

14. What is your age?

<18 18-24 25-34 35-44 45-54 >55

□ □ □ □ □ □

15. What is the highest educational level you have completed?

□ Less than primary school

□ Primary school

□ Less than junior high school

□ Junior High school


ClouT – 30/09/2014

□ Less than senior high school

□ Senior High School

□ Some college or associate degree

□ Bachelor’s degree

□ Master degree

□ PhD Degree

□ Other____

16. What is your major interest or field of study?

□ Journalism

□ Business

□ Psychology

□ Advertising

□ Physiology

□ Architecture

□ Art/Film/Dance

□ Biology

□ Computer Science

□ Political Science

□ Economics

□ Chemistry

□ International Affairs

□ Physics

□ Telecommunications

□ Foreign Language


ClouT – 30/09/2014

□ Law

□ Other

Santander Citizens’ Survey

This is a text-only version of Santander citizens’ survey form, it includes all the questions that are submitted to the surveyed in the original document.

This is a Survey from the ClouT Project (http://clout-project.eu), a Research Project co-funded by the European Community's Seventh Framework Programme and the National Institute of Information and Communications Technology of Japan. This survey aims at identifying the key aspects of the IoT (Internet of Things) and IoP (Internet of People) world in combination with the cloud paradigm to create the future internet.

1. Do you use or own a smartphone as your primary mobile phone?

□ Yes

□ No ( if No skip question n.2, n.3)

2. How familiar are you with the usage of smartphones in general?

Not at all Familiar




(4) Quite Familiar


3. What Mobile Operating Systems do you use?

iOS (iPhone)

Android (Samsung, LG…)

Microsoft Windows Phone


ClouT – 30/09/2014

Blackberry OS OS Palm

4. How familiar are you with Internet of things ?




(4) Quite Familiar


5. In which application of Internet of things are you more interested ? ( you can check more than one item)

□ Infant Monitor (provides information about baby’s temperature, position, breathing ,…

□ Track performance in sport (

□ Monitor an aging family member

□ Smart thermostats

□ Multi-Functional Lights

□ Consumption Sensors (Light, Water, …)

□ Smart Bin to reduce the number of pick-ups

□ Parking Space Availability

□ Weather Sensors

□ Air Quality Sensors

□ Hydrometers (track water level)

□ Protect WildLife

□ Traffic monitoring

□ Public Transport measuring

□ Social Sensors (Trends, Events, etc…)


ClouT – 30/09/2014

□ Presence sensors (adapt lighting according to presence, security, …)

□ Other

2 ClouT – Field Trials

Answer all questions by ticking the box marking an x in the answer box. Please feel free to express your sincere opinion.

6. The following list illustrates the five field trials developed in the four cities within the ClouT consortium during the first year of the project. Please indicate your level of interest for their provision. (1: Not interested at all, 5: Very interested)

1 2 3 4 5

Fujisawa - Detect various city information related to safely, emergency and healthy contexts. City

infrastructure can be controlled (street lights, traffic, alerts, information displays, etc). □

□ □ □ □

Fujisawa - Detect and classify social events that occur inside the city, and visualize them into

map- based visualizer □ □ □ □ □

Genova – ‘IoNonRischio' risk alert management including information from weather stations and urban mobility, thus processing it accordingly and developing service to access data from sensors and to get improved graphics, better features and accessibility.

(www.iononrischioclout.comune.genova.it)

□ □ □ □ □

Mitaka - Motivate citizens to act something new and notice city events by delivering customized local information based on information registered by citizens. Associated to services such as,

healthy walking program, community creating and shopping support. □ □ □

□ □

Santander - Allow users to send enriched content events and incidences in the city while

following the actuation on these incidences accordingly. □ □ □ □ □

7. The following list illustrates a set of event types that can be submitted in Pace of the City App. Please indicate your level of interest for their provision:

1 2 3 4 5

Cimatology □ □ □ □ □

Culture □ □ □ □ □


ClouT – 30/09/2014

Sports □ □ □ □ □

Beaches □ □ □ □ □

Park And Gardens □ □ □ □ □

Traffic □ □ □ □ □

Transport □ □ □ □ □

Tourism □ □ □ □ □

Health □ □ □ □ □

Urban Furniture □ □ □ □ □

Water □ □ □ □ □

8. Please, describe what your experience with the first release of Pace of the City was.

Place an X in the box closer to the feeling you experienced

1 2 3 4 5

Unhappy □ □ □ □ □ Happy

Calm □ □ □ □ □ Excited

Sleepy □ □ □ □ □ Wide-awake

Unsatisfied □ □ □ □ □ Satisfied

9. Based on your experience using the service, please indicate your level of agreement (1: Totally Disagree, 5: Totally Agree) with the following statemens.

1 2 3 4 5

I found the service easy to use □ □ □ □ □

I intend to use the service in the future □ □ □ □ □

In general, the Local Authority has supported the use of the system. □ □ □ □

□

I found it easy to get the service to do what I want it to do □ □ □ □ □


ClouT – 30/09/2014

Using the application makes the communication between citizens and local authorities more

flexible □ □ □ □ □

The system is compatible with other systems I use. □ □ □ □ □

People who are important to me think that I should use the system. □ □ □ □

□

I like to experiment with new information technologies. □ □ □ □ □

10. Please provide, based on your experience of the Application, a new user's interaction with the system that could us help to improve the final version of Pace of the City

11. Please describe the most important requirements that the final version of the app Pace of the City must have (i.e. 24x7 support, highly automated, reliability, scalability, quality of data, etc…)

12. Do you have a particular idea for an application to enhance your daily life? Please describe it.

3 Demographic Information

Answer all questions by ticking the box marking an x in the answer box.

13. What is your gender?

□ Male

□ Female

14. What is your age?

<18 18-24 25-34 35-44 45-54 >55

□ □ □ □ □ □

15. What is the highest educational level you have completed?

□ Less than primary school


ClouT – 30/09/2014

□ Primary school

□ Less than junior high school

□ Junior High school

□ Less than senior high school

□ Senior High School

□ Some college or associate degree

□ Bachelor’s degree

□ Master degree

□ PhD Degree

□ Other____

16. What is your major interest or field of study?

□ Journalism

□ Business

□ Psychology

□ Advertising

□ Physiology

□ Architecture

□ Art/Film/Dance

□ Biology

□ Computer Science

□ Political Science

□ Economics

□ Chemistry

□ International Affairs

□ Physics


ClouT – 30/09/2014

□ Telecommunications

□ Foreign Language

□ Law

□ Other

d1.3 final requirements and reference...

Documents