d1.3 final requirements and reference...
TRANSCRIPT
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 Page 2
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 3
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 4
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 6
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 8
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 11
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
Terminology Definition Examples
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 12
Terminology Definition Examples
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 13
Terminology Definition Examples
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.
Byproduct of ClouT virtualisation Functionalities
Virtualized Sensor An entity which provides sensor data stream according to defined sensor capabilities. It is mapped to concrete sensor at runtime.
Byproduct of ClouT virtualisation Functionalities
Virtualized Storage An entity which provide sensor data history according to defined storage capabilities. It is mapped to concrete storage at runtime.
Byproduct of ClouT virtualisation Functionalities
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 14
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 15
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 16
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 17
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.
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 18
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 19
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.
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 20
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.
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 21
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.
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 22
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.
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 23
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).
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 24
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 25
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.,.
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 26
- 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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 27
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 28
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
User Scenario Description
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,
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 29
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 30
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.
Detailed scenario and main supporting blocks
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.
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 31
FIGURE 6: SEQUENCE DIAGRAM OF IOT DEVICE SHARING AND COMPOSING
Objective and Challenges for ClouT
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 32
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.
User/Service Requirements for the Reference Architecture
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
easily shared his device and create applications via application creation tools.
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.
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 33
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
User Scenario Description
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.
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 34
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.
Detailed scenario and main supporting blocks
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 35
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
Objective and Challenges for ClouT
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:
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 36
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
User/Service Requirements for the Reference Architecture
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
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).
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
geographical area, hybrid localisation (gps, gprs, wi-fi, webcam) services (multi-sensors
integration and outdoor/indoor), communication and networking capability for Street
equipment actuation.
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 37
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
costs and avoiding vendor lock-in, possibly employing open source software and
hardware.
2.2.3.2. Weather Risk and Alert Management
ID: SEM_2
Title: Weather Risk and Alert Management
User Scenario Description
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.
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 38
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.
Detailed scenario and main supporting blocks
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 39
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
Objective and Challenges for ClouT
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.
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 40
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
User/Service Requirements for the Reference Architecture
Taking into consideration the particularities of the aforementioned use case, the following
user/service requirements can be identified:
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
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).
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 41
UR5SEM_2: 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.
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
costs and avoiding vendor lock-in, possibly employing open source software and
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.
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 42
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
User Scenario Description
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.
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 43
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.
Detailed scenario and main supporting blocks
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.
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 44
FIGURE 12: SEQUNCE DIAGRAM OF CITY EVENT FINDER
Objective and Challenges for ClouT
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 45
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
User/Service Requirements for the Reference Architecture
Taking into consideration the particularities of the aforementioned user scenario, the following
user/service requirements can be identified:
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 46
easily shared his device and create applications via application creation tools.
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
order to push/pull urban event notifications. Provision and access to personal data shall
be enabled from anywhere, at anytime only by authorised people.
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
User Scenario Description
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.
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 47
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.
Detailed scenario and main supporting blocks
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.
.
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 48
FIGURE 14: SEQUENCE DIAGRAM OF CITIZEN ACTIVITY ENHANCER
Objective and Challenges for ClouT
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 49
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
User/Service Requirements for the Reference Architecture
Taking into consideration the particularities of the aforementioned user scenario, the following
user/service requirements can be identified:
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
easily shared his device and create applications via application creation tools.
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 50
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
order to push/pull urban event notifications. Provision and access to personal data shall
be enabled from anywhere, at anytime only by authorised people.
UR7CHPE_2: User and Municipality data stored within the ClouT platform shall be
compliant with Security and Privacy laws and regulations of their country.
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 51
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 52
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 53
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 54
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 55
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 56
REQ_CIAAS_15 Application Description (Interoperability)
FR28 Interoperability & City Resource Virtualisation
REQ_CIAAS_16 Conversion Function (Interoperability)
FR28 Interoperability & City Resource Virtualisation
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
FR21 Interoperability & City Resource Virtualisation
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 57
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
FR29 City Infrastructure Management
REQ_CIAAS_32 Plug & Play integration of city resources
FR27 City Infrastructure Management
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)
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 58
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
FR27 Sensorisation and Actuatorisation
REQ_CIAAS_7 Turning legacy actuators into IoT actuators
FR27 Sensorisation and Actuatorisation
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 59
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)
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 60
REQ_CPAAS_22
Collecting evidence FR31 Security & Dependability (Platform and Infrastructure Dependability Monitoring)
REQ_CPAAS_23
Configurable data collection
City Data Processing
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
City Data Processing (Data/Event Processing)
REQ_CPAAS_27
Open Data support Interoperability & City Resource Virtualisation
REQ_CPAAS_28
Cloud Development Platform
FR23 City Service Composition (Development & Deployment Platform)
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 61
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 62
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 63
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:
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 64
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 65
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 66
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 67
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 68
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?
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 69
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:
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 70
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.
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 71
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 72
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 73
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 74
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 75
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.
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 76
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 77
FIGURE 32: CLOUT DOMAIN MODEL: CIAAS
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 78
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.
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 79
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.
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 80
FIGURE 35: CLOUT DOMAIN MODEL: CPAAS
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 81
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.
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 82
FIGURE 36: CLOUT DOMAIN MODEL: CSAAS
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 83
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.
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 84
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.
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 85
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).
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 86
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 87
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).
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 88
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 89
- 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
Layer: City Infrastructure as a Service
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.
Functional components
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 90
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:
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 91
FIGURE 45: COMPUTING AND STORAGE ARCHITECTURE
Proposed Reusable Component(s)
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)
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 92
4.3.3. Interoperability & City Resource Virtualisation
Name: Interoperability & City Resource Virtualisation
Layer: City Infrastructure as a Service
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.
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 93
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 94
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.
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 95
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).
Proposed Reusable Component(s)
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
Layer: City Infrastructure as a Service
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 96
(application profiles, protocols, wiring, …).
FIGURE 49: INTEROPERABILITY & CITY RESOURCE VIRTUALISATION, INTERACTIONS WITH OTHER BLOCKS
Functional components
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 97
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 98
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.
Proposed Reusable Component(s)
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
List of requirements related to this block:
- 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
- REQ_CIAAS_26 - Integration of any data source
4.3.5. Internet of Things Kernel
Name: IoT Kernel
Layer: City Infrastructure as a Service
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 99
different natures (application profiles, protocols, wiring, …).
FIGURE 51: IOT KERNEL INTERACTIONS WITH OTHER BLOCKS
Functional components
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 100
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 101
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.
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 102
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.
Proposed Reusable Component(s)
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 …
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 103
from ST, or NTT R&D’s virtual machine
Requirements
List of requirements related to this block:
- 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_26 - Integration of any data source
- 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.
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 104
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 105
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
Functional components
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 106
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.
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 107
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 108
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.
Proposed Reusable Component(s)
Openstack Heat: Development & Deployment Platform
Enterprise Mash-up Markup Language: Service Composition
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 109
Open Social Specification: Service Composition
Apache Shindig: Service Composition
BPMN: Service Composition
IFTTT: Service Composition
Xively: Service Composition
Requirements
List of requirements related to this block:
- 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
Layer: City Platform as a Service
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.
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 110
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.
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 111
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 112
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.)
Proposed Reusable Component(s)
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
Layer: City Platform as a Service
Description:
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 113
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
Functional components
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.
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 114
FIGURE 65: CITY RESOURCE ACCESS PLATFORM INTERACTIONS
Proposed Reusable Component(s)
CDMI for Swift: City Data Access, City Action Access
Apache Tomcat: City Data Access, City Action Access
Requirements
List of requirements related to this block:
- 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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 115
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
Functional components
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 116
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:
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 117
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.
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 118
FIGURE 70: DEPENDABILITY MONITORING INTERACTION WITH OTHER BLOCKS
Proposed Reusable Component(s)
- SOA3: Authentication, Authorization, Accounting
- Zabbix: Monitoring
- SSL, TLS, Others: Encrypting Facilities
Requirements
List of requirements related to this block:
- 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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 119
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 120
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.
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 121
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 122
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 123
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.
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 124
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.
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 125
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
Related Architectural Components
Computing and Storage (Computation as a Service)
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 126
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.
History 10/2013: creation of requirement. 09/2014: requirement updated
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
Related Architectural Components
Computing and Storage (Computation as a Service)
Rationale Open standards for virtual assets guarantee ease of asset migration and avoid vendor lock-in
History 10/2013: creation of requirement. 09/2014: requirement updated
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 127
Field Description
new sensing capabilities associated to a resource.
Priority Mandatory
User Requirement ID FR29
Related Architectural Components
IoT Kernel, City Infrastructure Management
Rationale It is needed to manage the resources in order to maintain network resources updated.
History 10/2013: creation of requirement. 09/2014: requirement updated
Field Description
ID REQ_CIAAS_5
Title Turning social network into sensor
Requirement Type Non-Functional
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
User Requirement ID FR27
Related Architectural Components
Sensorisation and Actuatorisation
Rationale It is necessary to remove noisy data from social network
History 10/2013: creation of requirement. 09/2014: requirement updated
Field Description
ID REQ_CIAAS_6
Title Making legacy sensors to IoT sensors
Requirement Type Non-Functional
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 128
Field Description
necessary to export legacy sensors/actuators as virtual IoT devices.
Priority Mandatory
User Requirement ID FR27
Related Architectural Components
Sensorisation and Actuatorisation
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 Type Non-Functional
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
User Requirement ID FR27
Related Architectural Components
Sensorisation and Actuatorisation
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 129
Field Description
Requirement Type Non-Functional
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
User Requirement ID FR26
Related Architectural Components
Computing and Storage (Computation as a Service)
Rationale Easy deploying means less time to market and no need to change available hardware resources
History 10/2013: creation of requirement. 09/2014: requirement updated
Field Description
ID REQ_CIAAS_9
Title Cloud: Network Virtualisation
Requirement Type Non-Functional
Requirement Description The system shall be capable of isolating network traffic in multi-tenancy environments for security and privacy reasons
Priority Recommended
User Requirement ID FR18,FR16
Related Architectural Components
Computing and Storage (Computation as a Service)
Rationale Network virtualisation means easier network management and network isolation between different tenancies
History 10/2013: creation of requirement. 09/2014: requirement updated
Field Description
ID REQ_CIAAS_10
Title Data Storage encryption security
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 130
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
Related Architectural Components
Security & Dependability (Encrypting Facilities), Computing and Storage (Storage as a Service)
Rationale To safely keep encrypted data from tampering
History 10/2013: creation of requirement. 08/2014: requirement updated
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.
Priority Recommended
User Requirement ID FR9,FR10,FR21,FR27
Related Architectural Components
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
History 10/2013: creation of requirement. 08/2014: requirement updated
Field Description
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 131
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.
Priority Recommended
User Requirement ID FR14,FR20
Related Architectural Components
Computing and Storage
Rationale Huge amounts of data coming in and out of the cloud require an agile infrastructure
History 10/2013: creation of requirement. 08/2014: requirement updated
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
Priority Recommended
User Requirement ID FR20,FR24
Related Architectural Components
Computing and Storage
Rationale The system should be available even in adverse conditions
History 10/2013: creation of requirement. 08/2014: requirement updated
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 132
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.
Priority Recommended
User Requirement ID FR28
Related Architectural Components
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 Type Functional
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.
Priority Recommended
User Requirement ID FR28
Related Architectural Components
Interoperability & City Resource Virtualisation
Rationale To know the type of information which the application need for interoperability
History 10/2013: Creation of requirement.
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 133
Field Description
ID REQ_CIAAS_16
Title Conversion Function
Requirement Type Functional
Requirement Description Interoperability function must provide conversion function that converts the structured of data and unit of the data
Priority Recommended
User Requirement ID FR28
Related Architectural Components
Interoperability & City Resource Virtualisation
Rationale To provide interoperability capability
History 10/2013: Creation of requirement.
Field Description
ID REQ_CIAAS_17
Title Virtualisation (Abstracting)
Requirement Type Functional
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.
Priority Recommended
User Requirement ID FR21, FR22
Related Architectural Components
IoT Kernel, Interoperability & City Resource Virtualisation
Rationale To make it easy to access many types of sensors and CPUs.
History 10/2013: Creation of requirement.
Field Description
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 134
Field Description
ID REQ_CIAAS_18
Title Scalable User Infrastructure
Requirement Type Non Functional - Performance
Requirement Description The system should scale to thousands of users and hundred thousand of access requests per month.
Priority Recommended
User Requirement ID FR20, FR25, FR26
Related Architectural Components
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.
History 10/2013: Creation of requirement.
Field Description
ID REQ_CIAAS_19
Title Scalable Device Infrastructure
Requirement Type Non Functional - Performance
Requirement Description The system should scale to hundreds of thousands of devices, producing several MB of data per day.
Priority Recommended
User Requirement ID FR20, FR24, FR25, FR26, FR27, FR30, FR31
Related Architectural Components
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.
History 10/2013: Creation of requirement.
Field Description
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 135
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
User Requirement ID FR27, FR28, FR29
Related Architectural Components
City Infrastructure Management (Service Management)
Rationale Social Web Of Things scenario in which the devices participate in the Social Network life of the users.
History 10/2013: Creation of requirement.
Field Description
ID REQ_CIAAS_21
Title Interoperable sensing infrastructure
Requirement Type Non Functional - Interoperability
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
User Requirement ID FR21
Related Architectural Components
Interoperability & City Resource Virtualisation
Rationale In order to take into account the existing heterogeneity in city infrastructures.
History 10/2013: Creation of requirement.
09/2014 Update of the requirement
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 136
Field Description
ID REQ_CIAAS_22
Title Commands to IoT devices
Requirement Type Non Functional - Interoperability
Requirement Description IoT devices shall embed necessary functions to provide data gathering and/or to perform actions.
Priority Mandatory
User Requirement ID FR15
Related Architectural Components
IoT Kernel
Rationale In order to perform remote data gathering and action execution on the devices.
History 10/2013: Creation of requirement.
09/2014 Update of the requirement
Field Description
ID REQ_CIAAS_23
Title Device and service descriptions
Requirement Type Non Functional - Interoperability
Requirement Description The system shall provide expressive, flexible and easy to extend device and service descriptions.
Priority Mandatory
User Requirement ID FR21
Related Architectural Components
Interoperability & City Resource Virtualisation, IoT Kernel
Rationale To be able to describe many functionalities of services and personalise them when necessary
History 10/2013: Creation of requirement.
09/2014 Update of the requirement
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 137
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
User Requirement ID FR29, FR21
Related Architectural Components
Interoperability & City Resource Virtualisation, IoT Kernel
Rationale To be able to ensure the device data interoperability
History 10/2013: Creation of requirement.
09/2014 Update of the requirement
Field Description
ID REQ_CIAAS_25
Title Common APIs
Requirement Type Non Functional – Interoperability
Requirement Description The system shall provide agreed service access interfaces gathering data and performing actions
Priority Mandatory
User Requirement ID FR29, FR21
Related Architectural Components
Interoperability & City Resource Virtualisation, IoT Kernel
Rationale To be able to ensure the interoperability of accessing to device resources
History 10/2013: Creation of requirement.
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 138
Field Description
09/2014 Update of the requirement
Field Description
ID REQ_CIAAS_26
Title Integration of any data source
Requirement Type Non Functional – Interoperability
Requirement Description The system shall support seamless integration of any entity providing city data (IoT device, legacy device, web application,etc.)
Priority Recommended
User Requirement ID FR27
Related Architectural Components
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.
History 10/2013: Creation of requirement.
09/2014 Update of the requirement
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
User Requirement ID FR29, FR31
Related Architectural City Infrastructure Management
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 139
Field Description
Components
Rationale To be able to customize the means of access to resources (e.g., synchronous, vs asynchronous)
History 10/2013: Creation of requirement.
09/2014 Update of the requirement
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
User Requirement ID FR29, FR31
Related Architectural Components
City Infrastructure Management
Rationale To be able to discover the resource that applications really need.
History 10/2013: Creation of requirement.
09/2014 Update of the requirement
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.
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 140
Field Description
Priority Mandatory
User Requirement ID FR28, FR31
Related Architectural Components
City Infrastructure Management
Rationale To be able to maintain the list of available resources in the system.
History 10/2013: Creation of requirement.
09/2014 Update of the requirement
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
User Requirement ID FR28, FR31
Related Architectural Components
City Infrastructure Management
Rationale To avoid any name conflicts for resources.
History 10/2013: Creation of requirement.
09/2014 Update of the requirement
Field Description
ID REQ_CIAAS_31
Title Autonomic discovery
Requirement Type Functional – Resource Discovery
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 141
Field Description
Requirement Description The system should support autonomic discovery and binding of devices/services/resources based on requirements of the clients
Priority Recommended
User Requirement ID FR29
Related Architectural Components
City Infrastructure Management
Rationale To avoid manual binding of resources to services/applications
History 10/2013: Creation of requirement.
09/2014 Update of the requirement
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
User Requirement ID FR27
Related Architectural Components
City Infrastructure Management
Rationale To avoid manual integration of resources.
History 10/2013: Creation of requirement.
09/2014 Update of the requirement
Field Description
ID REQ_CIAAS_33
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 142
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.
Priority Recommended
User Requirement ID FR24,FR31
Related Architectural Components
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
Related Architectural Components
Security & Dependability (A.A.A.)
Rationale Direct access to the infrastructure resources should be allowed only to system administrators
History 08/2014: creation of requirement.
Field Description
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 143
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.
Priority Recommended
User Requirement ID FR20,FR24,FR25,FR30
Related Architectural Components
Computing and Storage (Storage as a Service)
Rationale A high performing, reliable and scalable storage backend is needed to store, retrieve and safely keep huge amounts of data
History 08/2014: creation of requirement.
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
Related Architectural Components
Security & Dependability (Encrypting Facilities), Computing and Storage (Storage as a Service)
Rationale Employing security and access control to the data stored in distributed environments.
History 08/2014: creation of requirement.
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 144
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
User Requirement ID FR15,FR21
Related Architectural Components
City Resource Access (City Data Access)
Rationale To provide a common and standard layer to access (store and retrieve) data.
History 08/2014: creation of requirement.
Field Description
ID REQ_CPAAS_2
Title Cloud Storage Authentication and Authorization security facilities
Requirement Type Non Functional – Security
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
User Requirement ID FR16, FR18
Related Architectural Components
Security & Dependability (A.A.A.)
Rationale To provide a common and standard layer to provide authentication
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 145
Field Description
and authorization facilities.
History 08/2014: creation of requirement.
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
User Requirement ID FR16, FR18
Related Architectural Components
Security & Dependability (Crypting Facilities)
Rationale To provide a security access to the data stored in the cloud storage.
History 08/2014: creation of requirement.
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.
Priority Recommended
User Requirement ID FR21
Related Architectural Components
Ciy Resource Access
Rationale To reuse devices as services for different applications.
History 10/2013: Creation of requirement.
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 146
Field Description
09/2014 Update of the requirement
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.
Priority Recommended
User Requirement ID FR3, FR13
Related Architectural Components
City Service Composition
Rationale To enable service/application creation by end-users/developpers
History 10/2013: Creation of requirement.
09/2014 Update of the requirement
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.
Priority Recommended
User Requirement ID FR3
Related Architectural Components
City Service Composition
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 147
Field Description
Rationale To enable dependable service/application creation that conforms to specifications defined.
History 10/2013: Creation of requirement.
09/2014 Update of the requirement
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
User Requirement ID FR20, FR15
Related Architectural Components
City Data Processing
Rationale To be able to get informed in real-time by the events occurring in the city captured by sensors.
History 10/2013: Creation of requirement.
09/2014 Update of the requirement
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
Priority Recommended
User Requirement ID FR15, FR21
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 148
Field Description
Related Architectural Components
City Data Processing
Rationale to exploit data processing capabilities of devices, thus avoid unnecessary transfer of raw information from devices.
History 10/2013: Creation of requirement.
09/2014 Update of the requirement
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
User Requirement ID FR20
Related Architectural Components
City Data Processing
Rationale to extract useful information for the smart city applications
History 10/2013: Creation of requirement.
09/2014 Update of the requirement
Field Description
ID REQ_CPAAS_11
Title Context prediction
Requirement Type Functional – Context data
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 149
Field Description
Requirement Description The system shall be able to predict future context of the citizens and the city environment.
Priority Recommended
User Requirement ID FR9, FR10
Related Architectural Components
City Data Processing
Rationale Use contextual information for smart city applications
History 10/2013: Creation of requirement.
09/2014 Update of the requirement
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
User Requirement ID FR9, FR10, FR21
Related Architectural Components
City Data Processing
Rationale Use contextual information for smart city applications
History 10/2013: Creation of requirement.
09/2014 Update of the requirement
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 150
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
User Requirement ID FR21
Rationale to take necessary actions based on the contextual information in order to optimize resource usage in the city
Related Architectural Components
City Data Processing
History 10/2013: Creation of requirement.
09/2014 Update of the requirement
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
User Requirement ID FR9, FR15
Related Architectural Components
City Resource Access (City Data Access)
Rationale To provide access to the data stored in the cloud storage.
History 08/2014: creation of requirement.
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 151
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
User Requirement ID FR28
Related Architectural Components
Computing and Storage (Storage as a Service)
Rationale To provide high availability to the data access.
History 08/2014: creation of requirement.
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
User Requirement ID FR9, FR25
Related Architectural Components
Computing and Storage (Storage as a Service)
Rationale To provide large amounts of data to processes that need to create statistics or business analysis
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 152
Field Description
History 08/2014: creation of requirement.
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.
Priority Recommended
User Requirement ID FR3
Related Architectural Components
City Service Composition
Rationale Show in a friendly way the corresponding information, as well as provide a good manageability experience to the user.
History 10/2013: creation of requirement.
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
User Requirement ID FR7,FR8
Related Architectural Components
City Data Processing
Rationale Event-driven behaviour that deals with multiple users and multiple applications tends to be very complex and involves unexpected
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 153
Field Description
features interactions, which may have a large undesirable impact on human users.
History 08/2014: creation of requirement.
Field Description
ID REQ_CPAAS_20
Title Assurance of Accurate Sensory Data
Requirement Type Non Functional – Reliability
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
User Requirement ID FR7
Related Architectural Components
City Data Processing (Data/Event Processing)
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
History 08/2014: creation of requirement.
Field Description
ID REQ_CPAAS_21
Title Systems strategy description and evidence
Requirement Type Non Functional – Reliability
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
User Requirement ID FR31
Related Architectural Security & Dependability (Platform and Infrastructure
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 154
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
History 08/2014: creation of requirement.
Field Description
ID REQ_CPAAS_22
Title Collecting evidence
Requirement Type Non Functional – Reliability
Requirement Description The system need to collect evidences from the system itself that are required to prove it is actually running.
Priority Optional
User Requirement ID FR31
Related Architectural Components
Security & Dependability (Platform and Infrastructure Dependability Monitoring)
Rationale The system must collect evidence from its components to check that they are actually running
History 08/2014: creation of requirement.
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
User Requirement ID FR21
Related Architectural City Data Processing
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 155
Field Description
Components
Rationale Data acquisition should be configurable to easily wrap different data harvesting needs
History 08/2014: creation of requirement.
Field Description
ID REQ_CPAAS_24
Title Standard service API provision
Requirement Type Non Functional
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
Related Architectural Components
Interoperability & City Resource Virtualisation, City Resource Access
Rationale Standard APIs helps exploiting the available resources while guaranteeing compatibility
History 08/2014: creation of requirement.
Field Description
ID REQ_CPAAS_25
Title Primitive city context detection
Requirement Type Non Functional
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.
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 156
Field Description
Priority Mandatory
User Requirement ID FR31
Related Architectural Components
City Data Processing (Data/Event Processing)
Rationale To create true smart applications the system has to be capable of understanding and providing applications with data context.
History 08/2014: creation of requirement.
Field Description
ID REQ_CPAAS_26
Title High-level city context recognition
Requirement Type Non Functional
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
User Requirement ID FR31
Related Architectural Components
City Data Processing (Data/Event Processing)
Rationale To create true smart applications the system has to be capable of understanding and providing applications with data context.
History 08/2014: creation of requirement.
Field Description
ID REQ_CPAAS_27
Title Open Data support
Requirement Type Non Functional
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 157
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
User Requirement ID FR1
Related Architectural Components
Interoperability & City Resource Virtualisation
Rationale Open data is crucial to municipalities willing to share their data with citizens and organizations
History 08/2014: creation of requirement.
Field Description
ID REQ_CPAAS_28
Title Cloud Development Platform
Requirement Type Non Functional
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
User Requirement ID FR23
Related Architectural Components
City Service Composition (Development & Deployment Platform)
Rationale Eases the development of new smart city services
History 08/2014: creation of requirement.
Field Description
ID REQ_CPAAS_29
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 158
Field Description
Title Cloud Storage Authentication security facilities
Requirement Type Non Functional – Security
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
User Requirement ID FR9, FR16, FR18
Related Architectural Components
Security & Dependability (Crypting Facilities, A.A.A.)
Rationale Employing security and access control to the CSaaS and CPaaS applications.
History 08/2014: creation of requirement.
Field Description
ID REQ_CPAAS_30
Title Dynamic computational resource scaling
Requirement Type Non Functional - Performance
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
Related Architectural Components
City Service Composition (Development & Deployment Platform)
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 159
Field Description
Rationale Deployed services should consume available resources according to actual workload
History 08/2014: creation of requirement.
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?
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 160
(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?
(1) Not at all Familiar
(2) Not so much Familiar
(3) Moderately Familiar
(4) Quite Familiar
(5) Very much 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.
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 161
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 162
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)?
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 163
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
(1) Not at all Familiar
(2) Not so much Familiar
(3) Moderately Familiar
(4) Quite Familiar
(5) Very much Familiar
3. What Mobile Operating Systems do you use?
iOS (iPhone) Android
(Samsung, LG…) Microsoft Windows Phone Blackberry OS OS Palm
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 164
4. How familiar are you with Internet of things ?
Not at all Familiar
(1) Not at all Familiar
(2) Not so much Familiar
(3) Moderately Familiar
(4) Quite Familiar
(5) Very much 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, …)
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 165
□ 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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 166
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 □ □ □ □ □
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 167
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 168
□ 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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 169
□ 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
(1) Not at all Familiar
(2) Not so much Familiar
(3) Moderately Familiar
(4) Quite Familiar
(5) Very much Familiar
3. What Mobile Operating Systems do you use?
iOS (iPhone)
Android (Samsung, LG…)
Microsoft Windows Phone
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 170
Blackberry OS OS Palm
4. How familiar are you with Internet of things ?
(1) Not at all Familiar
(2) Not so much Familiar
(3) Moderately Familiar
(4) Quite Familiar
(5) Very much 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…)
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 171
□ 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 □ □ □ □ □
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 172
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 □ □ □ □ □
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 173
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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 174
□ 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
D1.3 - Final Requirements and Reference Architecture
ClouT – 30/09/2014 Page 175
□ Telecommunications
□ Foreign Language
□ Law
□ Other