wp2 7-atos · highway addressable remote transducer hdsf . hadoop distributed file system html ....

GA no: 732240

Action full title: SynchroniCity: Delivering an IoT enabled Digital Single Market for Europe and Beyond

Call/Topic: Large Scale Pilots

Type of action: Innovation Action (IA)

Starting date of action: 01.01.2017

Project duration: 36 months

Project end date: 31.12.2019

Deliverable number: D2.8

Deliverable title: Report on Basic Reference Zones platform deployment and operational plan

Document version: 1.0

WP number: WP2

Lead beneficiary: 7-ATOS

Main author(s): Ömer Faruk Özdemir, Said Rahma (ATOS)

Internal reviewers: Thomas Gilbert (AI), Andrea Gaglione (DigiCat), Ignacio Elicegui (SAN), Martin Brynskov (AU)

Type of deliverable: Report

Dissemination level: Public

Delivery date from Annex 1:

M15

Actual delivery date: M20 (30.08.2018)

This deliverable is part of a project that has received funding from the European Union’s Horizon 2020 research and innovation programme under grant agreement no 732240.

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Executive Summary SynchroniCity represents the first attempt to deliver a Digital Single Market for Europe by piloting its foundations at scale in reference zones across 8 European cities, involving also other cities globally. It addresses how to incentivize and build trust for companies and citizens to actively participate, in finding common co-created IoT (Internet of Things) solutions for cities that meet citizen needs and to create an environment of evidence-based solutions that can easily be replicated in other regions.

SynchroniCity aims to synchronize existing IoT-enabled smart city ecosystems in Europe by removing barriers of fragmentation and misalignment that currently sets them apart. It will pilot the necessary building blocks and drivers for change to foster an environment that will contribute towards technical, legal and socio-economic harmonization of the European smart city market.

This Deliverable has been issued by the SynchroniCity Work Package 2 (WP2), which is responsible to define and provide the architecture, components and software, initial interaction model and data model, making up a so-called SynchroniCity platform, by leveraging on existing or new solutions, or integrated system based on context management, IoT device management, data management and market place, among others elements, and related to smart cities eco-system, city service domains and IoT (Internet of Things) infrastructure (software and hardware), by providing the major technological elements allowing a high level of interoperability.

These architectural elements could be deployed by configuring the SynchroniCity platform elements (set of services and components) as a private service network or local cloud services in the scope of an adapted local platform instance to each reference zone or as a global centralized instance which could be offered to the third-party service and application providers and stakeholders involved in the context of the SynchroniCity project, in order to take advantage of the SynchroniCity platform and their service network capabilities from the point of view of interoperability, entities interaction and data model shared, improving their smart cities services.

The report provides a description of the specific reference zone infrastructure and platform elements foreseen to be deployed and operated in each city based on the initial architecture specification and the proposed technologies and components that was documented in Deliverable D2.1 “Reference Architecture for IoT Enabled Smart Cities” [1]. This document reports on the deployment activities establishing the corresponding common and specific deployment plan as well as the initial operational plan for each reference zone. In this context it also provides a basic and initial integration guide and some references oriented to the stakeholders, service and application providers, developer of client applications who could interact with the SynchroniCity platform to integrate their modules, client applications or who interact as a data provider (e.g. data coming from the IoT devices or data already provided by the underlying IT infrastructure of the cities), improving their city services and business activities, providing a new integrated system to their end-user and customers, offering new functionalities related to smart city services.

The proposals or decisions taken during the design of the architecture, methodology, technologies and standards managed during the studies and analysis of the architectural elements ensure the definition of services, interfaces, interactions and data models to be developed and/or integrated during the next steps of the SynchroniCity project. Essentially the design of the architecture was oriented to modules, components and services to guarantee that the evolution of technologies, available tools and standards used in the present document provide advantages during the development, integration, deployment and life-cycle of the SynchroniCity platform.

Significantly, one of the main objectives of the SynchroniCity architecture, platform and theirs associated components and services is to provide a new smart city service platform that is in the scope of SynchroniCity project and where the different scenarios and use cases can be validated, in order to identify improvements and value-added features of this platform.

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

AbbreviationsAAA Authentication,

Authorization and Accounting

ACI Access Control Interface

AE Application Entity AIOT Alliance for the

Internet of Things Innovation

API Application Programming Interface

ASI Application Support Interface

AWS Amazon Web Services

B2B Business-to-Business

BE Business Entities BSI British Standards

Institution CB Context Broker CDB Context Data

Broker CDMI Cloud Data

Management Interface

CEP Complex Event Processing

CKAN Comprehensive Knowledge Archive Network

CSE Common Service Entity

D Deliverable DCAT Data Catalogue

Vocabulary DMG Device

Management DIS Discovery DMR Data

Management and Repository

DoW Description of Work

DoA Description of Action

EC European Commission

e.g. Exempli gratia = for example

ESI Experimental Support Interface

ETSI European Telecommunications Standards Institute

EU European Union FG-SSC

Focus Group on Smart Sustainable Cities

GA Grant Agreement GE Generic Enabler GPS Global Positioning

System GPRS General Packet

Radio Service GMG Group

Management GUI Graphical User

Interface HART Highway

Addressable Remote Transducer

HDSF Hadoop Distributed File System

HTML Hypertext Mark-up Language

HTTP Hypertext Transfer Protocol

IA Innovation Action ICT Information and

communication technology

IDAS Intelligence Data Advanced Solution

IDE Integrated Development Environment

IDM Identity Management

IDS Intrusion Detection System

i.e. id Est = that is to say

IE Integration Environment

IEEE Institute of Electrical and Electronics Engineers

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

IEC International Electrotechnical Commission

IETF Internet Engineering Task Force

IoT Internet of things IoTA Internet of things

Agent IP Intellectual

Property IP (protocol)

Internet Protocol

ISO International Standard Organization

IT Information Technology

ITU International Telecommunication Union

ITU-T ITU Telecommunication Standardization Sector

JSON JavaScript Object Notation

JWT JSON Web Token LTE Long Term

Evolution M2M communication

between CSE and AE

Mcc a reference point for M2M communication between CSE and CSE

Mcn a reference point for M2M communication between CSE and NSE

MQTT Message Queue Telemetry Transport

MVP Minimal Viable Product

NFC Near-field communication

NGSI Next Generation Service Interfaces

NSE Network Service Entity

MSI Management Support Interface

OASC Open & Agile Smart Cities

OASIS Organization for the Advancement of Structured Information Standards

OATH Open Authentication

OAuth Industry-standard protocol for authorization

ODF Open Data Federation

ODMS Open Data Management System

OIDC OpenID Connect OMA Open Mobile

Alliance OMG Object

Management Group

PM Person Month PPM Privacy Policy

Manager PEP Policy

Enforcement Point

PDP Policy Decision Point

QoS Quality of Service RBAC Role-Based

Access Control RDF Resource

Description Framework

REST Representational state transfer

RFC Request for Comments

RFID Radio Frequency Identification

RPS Receive Packet Steering

RTD Research and Technological Development

RZ Reference Zone

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

SAML Security Assertion Mark-up Language

SC SynchroniCity SCADA Supervisory

Control And Data Acquisition

SDO Standards Developing Organizations

SDK Software Development Kit

SLA Service Level Agreement

SNS Simple Notification Service

SOA Service Oriented Architecture

SOA-RM

(OASIS) Reference Model for Service Oriented Architecture

SOAP Simple Object Access Protocol

SQS Simple Queue Service

SR System Requirement

SSH Secure Shell SSL Secure Sockets

Layer SSO Single Sign-On STH Short Time

Historic TCP Transmission

Control Protocol TGP Transports

Publics Genevois TLS Transport Layer

Security UAA User

Management, Authentication and Authorization

UA User Authentication

UC Use Case UDG Universal Device

Gateway UI User Interface UML Unified Modelling

Language

URI Universal Resource Identifier

URL Universal Resource Locator

VM Virtual Machine VPN Virtual Private

Network W3C World Wide Web

Consortium WLAN Wireless Local

Area Network WP Work Package WT Work Task WS Web Service WSDL Web Services

Description Language

WSN Wireless Sensor Network

XACML eXtensible Access Control Mark-up Language

XML eXtensible Mark-up Language

XMPP Extensible Messaging and Presence Protocol

XSD XML Schema Definition

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Contents

1 Introduction ............................................................................................................................ 12

1.1 Document structure and links .......................................................................................... 12

1.2 Links to SynchroniCity project structure .......................................................................... 13

1.3 Link to other SynchroniCity deliverables ......................................................................... 13

2 Scope and background .......................................................................................................... 15

2.1 Intended audience .......................................................................................................... 15

2.2 Background .................................................................................................................... 16

2.3 Reference platform architecture overview ....................................................................... 16

2.4 Reference zones overview .............................................................................................. 17

3 Reference architecture modules and RZ platform elements ................................................... 19

3.1 RZ Antwerp (BE) ............................................................................................................. 20

3.1.1 RZ legacy system overview ........................................................................................ 20

3.1.2 High level theme and service domains ....................................................................... 22

3.1.3 City infrastructure and technical elements .................................................................. 22

3.2 RZ Manchester (UK) ....................................................................................................... 30




3.3 RZ Carouge (CH) ............................................................................................................ 34




3.4 RZ Eindhoven (NL) ......................................................................................................... 41




3.5 RZ Helsinki (FI) ............................................................................................................... 54




3.6 RZ Milano (IT) ................................................................................................................. 62



H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132


3.7 RZ Porto (PT) ................................................................................................................. 73




3.8 RZ Santander (ES) ......................................................................................................... 79




3.9 Non-RZ Seongnam (KR) ................................................................................................. 92

3.9.1 Non-RZ legacy system overview ................................................................................ 92



4 Integration and deployment process ...................................................................................... 94

4.1 RZ Antwerp (BE) ............................................................................................................. 94

4.2 RZ Manchester (UK) ....................................................................................................... 95

4.3 RZ Carouge (CH) ............................................................................................................ 96

4.4 RZ Eindhoven (NL) ......................................................................................................... 96

4.5 RZ Helsinki (FI) ............................................................................................................... 96

4.6 RZ Milano (IT) ................................................................................................................. 97

4.7 RZ Porto (PT) ............................................................................................................... 100

4.8 RZ Santander (ES) ....................................................................................................... 100

4.9 Non-RZ Seongnam (KR) ............................................................................................... 101

5 Operation and maintenance process ................................................................................... 103

5.1 RZ Antwerp (BE) ........................................................................................................... 103

5.2 RZ Manchester (UK) ..................................................................................................... 103

5.3 RZ Carouge (CH) .......................................................................................................... 103

5.4 RZ Eindhoven (NL) ....................................................................................................... 104

5.5 RZ Helsinki (FI) ............................................................................................................. 104

5.6 RZ Milano (IT) ............................................................................................................... 104

5.7 RZ Porto (PT) ............................................................................................................... 104

5.8 RZ Santander (ES) ....................................................................................................... 105

5.9 Non-RZ Seongnam (KR) ............................................................................................... 105

6 Conclusion ........................................................................................................................... 106

7 References .......................................................................................................................... 107

8 Annex - Common infrastructure and platform elements ....................................................... 112

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

8.1 Key common definition related to the SynchroniCity architecture and platform ............. 112

8.1.1 Interoperability.......................................................................................................... 112

8.1.2 Software platform ..................................................................................................... 113

8.1.3 Technology standard ................................................................................................ 113

8.2 Service network infrastructure definition........................................................................ 114

8.2.1 Functional classification of services .......................................................................... 114

8.2.2 Terms and definitions for SynchroniCity service concept .......................................... 115

8.2.3 SynchroniCity Architecture Service (SCA Service) ................................................... 116

8.2.4 SynchroniCity Thematic Service (SCT Service) ........................................................ 119

8.2.5 SynchroniCity classification of services approach .................................................... 121

8.3 System and components .............................................................................................. 123

8.3.1 Technology and standards ....................................................................................... 123

9 Glossary .............................................................................................................................. 124

9.1 Terms and definitions .................................................................................................... 124

List of Figures Figure 1: SynchroniCity Reference Architecture components and interoperability points .............. 17

Figure 2 Antwerp RZ - minimal set of available infrastructures/services (ETA June 2018) ............ 20

Figure 3: Antwerp high level component architecture .................................................................... 22

Figure 4 On-/off-street parking sensor ........................................................................................... 24

Figure 5 Overview status loading zones ........................................................................................ 24

Figure 6 Overview status loading zones cont´d ............................................................................. 25

Figure 7 Example of a Smart traffic sign and the visualization on mobile and desktop device ....... 25

Figure 8 Antwerp city’s bike hiring docking station ........................................................................ 26

Figure 9 ANPR cameras used in the Antwerp RZ ......................................................................... 27

Figure 10 Example of video cameras used in the Antwerp RZ ...................................................... 27

Figure 11 Example of mobile air quality sensors ........................................................................... 28

Figure 12 Antwerp city’s Smart waste sorting litter container (Bigbelly) ......................................... 29

Figure 13 Antwerp city’s Smart waste sorting litter line ................................................................. 29

Figure 14 Simplified Data Architecture for Manchester ................................................................. 31

Figure 15: Carouge high level component architecture ................................................................. 37

Figure 16: Carouge – Parking sensor ............................................................................................ 38

Figure 17: Carouge – Parking sensor on a forbidden parking slot ................................................. 39

Figure 18: Carouge – noise sensor (the white box) placed on a downspout .................................. 39

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Figure 19: Eindhoven RZ - minimal set of available infrastructures/services ................................. 41

Figure 20: Eindhoven overview and locations of IoT devices ........................................................ 42

Figure 21: Eindhoven RZ – MobiMaestro traffic data and flows harvesting and regulation ............ 43

Figure 22: Eindhoven My040Routes analytic/visualization example .............................................. 44

Figure 23: Eindhoven RZ – ViNotion/ViSence pedestrian/bicycle traffic counters ......................... 45

Figure 24 Crossroad in Eindhoven RZ .......................................................................................... 46

Figure 25 Eindhoven RZ – My040Routes (local) traffic tracking app ............................................. 48

Figure 26 Eindhoven RZ – HD Camera, equipped with ViNotion/ViSence .................................... 49

Figure 27 Eindhoven RZ – Hopper bike sharing point at City Hall ................................................. 50

Figure 28 Eindhoven RZ – HD Camera, equipped with ViNotion/ViSence .................................... 51

Figure 29 Eindhoven RZ – Sorama 64 Camera ............................................................................ 52

Figure 30 Eindhoven RZ – Aireas Airbox ...................................................................................... 52

Figure 31 Eindhoven RZ – FIWARE based Framework ................................................................ 54

Figure 32 Helsinki RZ - minimal set of available infrastructures/services ...................................... 55

Figure 33 HRI landing page .......................................................................................................... 56

Figure 34 Helsinki RZ high level component architecture .............................................................. 58

Figure 35 Transport data cycles and app/service development ..................................................... 59

Figure 36 Digitransit micro service architecture ............................................................................. 60

Figure 37 Helsinki City Infrastructure Elements ............................................................................. 61

Figure 38 Helsinki RZ framework .................................................................................................. 62

Figure 39 Milano RZ - Minimal set of available infrastructures/service .......................................... 63

Figure 40 “GiroMilano” (left) and “Muoversi” (right) navigators ...................................................... 64

Figure 41 Mobike and Figure 42 Ofo screenshots ......................................................................... 65

Figure 43 Milano Open Data Portal ............................................................................................... 66

Figure 44 E015 Digital Market ....................................................................................................... 67

Figure 45 Integration between Milan infrastructure and SynchroniCity Platform ............................ 68

Figure 46 The WSO2 platform ...................................................................................................... 68

Figure 47 NGSI Adapter ................................................................................................................ 69

Figure 48 Map of traffic loops ........................................................................................................ 70

Figure 49 Station based bike sharing ............................................................................................ 71

Figure 50 Mobike (orange) and Ofo (yellow) bicycles .................................................................... 72

Figure 51 Bus and Metro ............................................................................................................... 72

Figure 52 CKAN and WSO2 integration ........................................................................................ 73

Figure 53 Porto - minimal set of available infrastructures/services ................................................ 74

Figure 54 Sensing stations: noise (a), meteorological (b) and air pollutants (c) ............................. 77

Figure 55 Proximity Beacons: active, BLE (a) and passive, NFC (b) ............................................. 77

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Figure 56 Vehicle counter ............................................................................................................. 78

Figure 57 Porto Reference Zone Framework ................................................................................ 79

Figure 58 Santander RZ - minimal set of available infrastructures/services................................... 80

Figure 59 Devices deployment within the SmartSantander IoT facility .......................................... 81

Figure 60 Santander high level component architecture ............................................................... 84

Figure 61 Examples of repeaters installation ................................................................................. 88

Figure 62 Mobile environmental monitoring sensors parking sensors (Smart Parking Use Case) . 88

Figure 63 Examples of parking sensors installation ....................................................................... 89

Figure 64 Traffic sensors installation in the main roads of the city ................................................. 89

Figure 65 Mobile node installed on a public bus ............................................................................ 90

Figure 66 Santander city’s bike hiring docking station ................................................................... 90

Figure 67 Santander RZ framework .............................................................................................. 91

Figure 68 Public parking lots near Yatap station in Seongnam...................................................... 93

Figure 69 Off street parking sensor deployment example ............................................................. 93

Figure 70 Deployment process ..................................................................................................... 98

Figure 71 Milano Legacy Data Integration ..................................................................................... 98

Figure 72 SynchroniCity platform on a dedicated virtual machine ................................................. 99

Figure 73 SynchroniCity platform in a physical server ................................................................... 99

Figure 74 Milano advanced deployment model ........................................................................... 100

Figure 75: SynchroniCity Architecture (SCA) Services ................................................................ 117

Figure 76: SynchroniCity Thematic (SCT) Services .................................................................... 120

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

List of Tables Table 1 List of other SynchroniCity deliverables ............................................................................ 14

Table 2: List of service domains by RZ ......................................................................................... 18

Table 3 Carouge RZ themes and services .................................................................................... 35

Table 4: Example of list of architectural services classification .................................................... 119

Table 5: Example of list of thematic services classification .......................................................... 121

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

1 Introduction This deliverable reports on the basic reference zones platform deployment and operational plan as carried out under WP2 (“IoT Enabled Framework for Smart Cities”). It reports on the description concerning the basic elements of the reference architecture and corresponding initial implementation in each reference zone which will be deployed and operated to support the city reference zone services and initial applications that will be developed according to a minimal set of available infrastructures/services and allowing the development and integration of the reference zone element or entities which will interact and exchange data with the SynchroniCity platform.

In this document, each reference zone describes their intrinsic Information Technology (IT) system as part of their legacy system. These IT systems will be integrated with the proposed basic SynchroniCity platform establishing a communication channel (through northbound/southbound) by the interaction of proposed service interface and/or Application Programming Interface (API) and data exchange. This interaction is based on a set of predefined, extended or new data models with the aim of providing a harmonized framework to the application providers. This framework will allow building services and applications related to the themes and services domain designed, selected by the cities and needs of the cities themselves.

1.1 Document structure and links The content of this document is structured into the following chapters:

• We start with the introduction section which includes scope, purpose and the intended audience. The scope description includes a brief description of the main complementary systems and components already studied and analyzed by the T 2.1 in the corresponding outcome - D2.1 “Reference Architecture for IoT Enabled Smart Cities” [1].

• Section 2 provides an overview of the SynchroniCity platform architecture referencing the corresponding deliverable outcome of the T2.1. It includes also a brief description related to RZ structure and activities.

• Section 3 presents the basic reference platform building blocks to implement, integrate and deploy as a minimal set of available infrastructure/services, core components and modules. Infrastructure and platform elements are explained by the common definitions related to the characteristics of the SynchroniCity platform, taking into account of the common service network infrastructure, system and components, and related technologies standard. This section introduces specific reference zone infrastructure and platform elements, providing an overview from the point of view of each cities and corresponding reference zones which includes a description of their legacy system or IT environment involved to interact and exchange data with the SynchroniCity platform.

• Section 4 explains the initial integration and deployment activities as planned by each reference zone.

• Section 5 introduces the initial plans to maintain and operate the SynchroniCity platform among the reference zones.

• Conclusion chapter summarizes the tasks that have been carried out in this deliverable, describing the work performed and the conclusions reached.

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

1.2 Links to SynchroniCity project structure The work package WP2 “IoT Enabled Framework for Smart Cities” is structured in five tasks whose goals are specified as follows:

• Task 2.1 – "IoT Enabled Smart City Reference Architecture"

• Task 2.2 – "Enablement of a DSM for IoT enabled Smart City Applications"

• Task 2.3 – "Advanced data marketplace mechanisms"

• Task 2.4 – "Enablement of a DSM for IoT devices manufacturing for Smart Cities"

• Task 2.5 – "Reference Zone platforms deployment and operation"

WP2 helps RZs to build an environment to integrate and adapt with the existing heterogeneous RZs deployments and underlying IT platforms by providing:

• The deployment of the architectural elements which conforms the basic architecture, framework and components to operate

• Provision of the necessary information to integrate the cities third party services and client application with the SynchroniCity platform

The WP2 “IoT Enabled Framework for Smart Cities” includes the deliverable D2.8 – “Report on Basic RZs platform deployment and operational plan”. This supporting document summarizes the overall deployment and operational plan related to the use of the SynchroniCity platform.

The sources of requirements to define the basic RZs platform deployment and operational plan are:

• The DoA as a basic legal reference to be fulfilled.

• Mainly the results from the deliverables of WP2: D2.1 [1], D2.2 [2], and from the deliverables of WP3: D3.1 [3].

• Information, work done, studies, assets and results of existing platforms, systems, services in the context of the smart city eco-system and descriptions of the RZ technical baseline and SynchroniCity platform requirements.

• The extensive experience of the SynchroniCity consortium partners in Smart City concept and Internet of Things (IoT) domain as well as in the management of systems, cloud and communication infrastructure.

• Expertise in the deployment of the technology related to IoT, as well as in information and communications technology (ICT) systems, service engineering, network and infrastructure.

• The capacities of the SynchroniCity consortium to setting up, planning, developing, deploying and operating systems and software, and performing complex system based on components related to several domains of application, business collaboration (Cities, SME, etc.) and IoT objectives in the context of the SynchroniCity Project activities.

1.3 Link to other SynchroniCity deliverables The SynchroniCity “Basic RZs platform deployment and operational plan” encompasses the results of the SynchroniCity tasks and the related deliverables as listed in Table 1:

Document Name

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

D2.1 “Reference Architecture for IoT Enabled Smart Cities”, where the nature of the dependency is related to the design and elaboration of the high level specifications of the SynchroniCity Reference Architecture for IoT Enabled Smart Cities, describing the high level technical architecture of the SynchroniCity platform based on components, along with the technical description of each of its components.

D2.2 “Guidelines for the definition of OASC Shared Data Models”, where the nature of the dependency is related to specify guidelines and compliance for SynchroniCity Information Models, allowing external stakeholders to understand the necessity of a set of information models in the context of the SynchroniCity Architecture, adopting a well-defined data model which is a key for interoperability requirement.

D3.1 “Documentation of service designs”, where the nature of the dependency is related to specifying the initial applications to be deployed on the SynchroniCity framework, demonstrating the benefits of the SynchroniCity framework to foster and attract others (e.g. SME’s, cities) to join the ecosystem via the open call mechanism.

Table 1 List of other SynchroniCity deliverables

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

2 Scope and background SynchroniCity plans to build a distributed platform that will provide services and functionalities related to smart city eco-systems to the cities. These efforts will particularly be focused on the RZs involved in the Large Scale pilot (LSP) activities, i.e. zones of the cities where the pilot will be performed. The SynchroniCity system provides both third parties and application providers a set of services that are necessary to build applications related to a set of preselected themes and service domains that are in the interest of the cities. To better contextualize the scope of this deliverable inside the overall SynchroniCity project, a brief recap of the preliminary works done as an abstract view of the proposed design of the SynchroniCity platform architecture baseline and core components is provided as a summary in the chapter 2.2 section 2.3.

The detailed SynchroniCity architecture has been already studied, analyzed and designed by the T2.1 activities and described in the corresponding outcome – D2.1 “Reference Architecture for IoT Enabled Smart Cities” [1]. The SynchroniCity reference architecture will serve as a basis to build the SynchroniCity platform that is the fundamental piece to develop a real and practical smart city eco-system to help the cities innovating, creating and developing new services and applications useful for the citizen and the city.

In order to build the SynchroniCity platform and make it available to cities, it is necessary to perform technical activities such as development, integration and deployment tasks as well as operations and maintenance activities. This will enable us to provide the SynchroniCity functionalities, services and corresponding environments to the reference city zones.

The interaction model proposed should consider that the southbound and northbound interfaces are the main entry points accessible and available to the external service and applications providers that want to use the services related to smart city eco-system provided through the SynchroniCity platform. The interoperability based on the integration mechanisms are essentially focused on the technologies and standard protocols supporting communication, interaction and data exchange through a set of web services – i.e. interface REST API and data models.

Also, this supporting document intends to provide the basic references about the interface / API specification and the data model specifications making references to the corresponding resources (some of them online) which describe in detail these specifications. It will allow the third parties service and application provider and IT provider together with the city representatives to understand the SynchroniCity platform and overall architecture focusing on the core components and their capabilities to interact and manage data.

2.1 Intended audience This document is relevant to the software engineers, programmers and developers who are the directly involved in the development, participating effectively on the design and implementation of the SynchroniCity platform and the underlying components and sub-systems who want to know more about some technical information and specification intrinsic to the SynchroniCity platform.

At the technical level this document is relevant to: system architects; information systems designers; system developers and application developers; software engineers; integrators; other audiences who provide design services and applications using relevant standards and the recommendations of standards bodies like IETF, ITU, ISO, W3C, etc. General remark

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

2.2 Background This section and Figure 1 represents a brief overview of the logical architecture, the interoperability points of the SynchroniCity platform and the list of the Reference Zones related with their application themes for the base line services.

In order to not repeat the content provided, detailed information about the reference platform architecture and the base line services per Reference Zone can be found in D2.1 and D3.1 respectively.

2.3 Reference platform architecture overview The main aim of this architecture is to define a set of logical components and functionalities that will enable different cities to be actively part of IoT Smart City Digital Single Market by following the OASC principles:

● Standard API for context information management: the context data manager (Context Data Broker) is a key component of the SynchroniCity architecture and the implementation of its API (compliant with NGSI API) is considered an “interoperability point” to enable cities to participate to the Synchronicity platform.

● Information models: semantic interoperability achieved through the adoption of common data models, is introduced in the architecture as a basic requirement to enable re-use of applications in different cities and domains.

● Data publication platforms: the role of data is crucial in SynchroniCity and for this reason the reference architecture includes specific data management components that aim to provide, through standard interfaces, all the functionalities related to data life cycle management.

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Figure 1: SynchroniCity Reference Architecture components and interoperability points

2.4 Reference zones overview The SynchroniCity project has 8 RZs corresponding to 8 highly innovative cities across Europe: Antwerp (ANT) in Belgium, Carouge (CAR) in Switzerland, Eindhoven (EIN) in Netherlands, Helsinki (FVH) in Finland, Manchester (MAN) in UK, Milan (MIL) in Italy, Porto (POR) in Portugal and Santander (SAN) in Spain.

These cities are following the OASC principles to build sustainable IoT ecosystems based on open standards and existing datasets to build integrated services (Table 2: List of service domains by RZ) based on the SynchroniCity reference architecture.

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

SynchroniCity is targeting the development of IoT-based solutions in a total of three different application themes: human-centric traffic management, multi-modal transportation and community policy suite. Each of these application themes addresses relevant urban challenges with a high societal and economic impact. Focusing on city needs that are common to multiple reference zones, IoT services developed within the selected themes can be expected to solicit broad demand that will drive replication across reference zones and stimulate ecosystem enrichment with both private-sector partners and city administrations.

Human-Centric traffic management: The initial application data-driven bicycle mobility aims to improve bicycle mobility in cities by leveraging and combining data from different IoT systems. Also, it aims to improve the overall cycling experience, safety, infrastructure planning and policy making for the future.

Multi-modal transportation: A multimodal assistant application that will inform citizens about their mobility options and will facilitate their use in a multimodal way. Citizens will be able to plan and use public transport, bike, scooter and other sharing services and transport modes, including mobility premises like public escalators, elevators or cables, information about parking areas and parking lots will also be used.

Community policy suite: The aim of the community policy suite is to design the SynchroniCity digital single market. The objective is to enable local authorities implement an approach to develop innovative IoT-based solutions that leverage more agile in their management and policy making processes.

Cities / Reference Zone

Theme Service Domain

ID

ANT CAR EIN FVH MAN MIL POR SAN

HCTM X X X

MT X X X X

CPS X X X

Table 2: List of service domains by RZ

Addition to the RZs in Europe, Seongnam in South Korea is preparing SynchroniCity compliant testbed and services. The key technology used in Seongnam is oneM2M standard that has been transposed to ITU-T Y.4500 Recommendations series.

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

3 Reference architecture modules and RZ platform elements

The SynchroniCity logical reference architecture logical modules are briefly explained below (taken from D2.1 [1]):

The SynchroniCity logical reference architecture, depicted in the Figure 1 is the composition of different logical modules that are summarized below:

● OASC principles: the architecture has been designed following the OASC initiative principles:

o a common standard API for context information management: the context data manager (Context Data Broker) is a key component of the SynchroniCity architecture and the implementation of its API (compliant with NGSI API) is considered an “interoperability point” (see section 3.4) to enable cities to participate to the Synchronicity platform.

o a common set of information models: semantic interoperability achieved through the adoption of common data models is introduced in the architecture as a basic requirement to enable re-use of applications in different cities and domains.

o a set of common standards data publication platforms: the role of data its crucial in Synchronicity for this reason the reference architecture includes specific data management components that aim to provide, through standard interfaces, all the functionalities related to data life cycle management.

● Context Data Management: it manages the context information coming from IoT

devices and other public and private data sources, providing a uniform approach and interface. Context information contains status information about real world entities defined in a structured way. CDM provides functionalities to enable access to different data sources and analyze context information, e.g. for detecting events.

● IoT Management is the module responsible to interact, through specific IoT Agents, with the devices that use different standards or protocols, making them compatible and available to the SynchroniCity platform;

● Data Storage Management provides functionalities related to the data storage and data security and quality in the specific context of IoT systems and smart city platform interacting with heterogeneous sources.

● Marketplace and Asset Management supports business interactions between suppliers of the valuable digital assets (i.e. IoT data or services) that are part of the SynchroniCity ecosystem and consumers. It will implement a hub to enable digital data exchange for urban data and IoT capabilities providing features in order to manage asset catalogues, orders, revenue management. These functions will support the creation of innovative business models.

● Security, Privacy and Governance: this module covers all the security aspects related to three main pillars: data, IoT infrastructure and the platform services, which underpin the applications and services of the cities. Around these pillars, security functionalities provide crucial security properties such as confidentiality, authentication, authorization, integrity, non-repudiation, access control, etc.

● Monitoring and Platform management services: it provides functionalities to manage platform configuration and to monitor activities of the platform services. It supports specific KPI definition to evaluate the status of the platform in relation to different aspects (e.g. performance, usage, reliability, quality of service etc.)

● Southbound uniform interfaces: represents the set of uniform interfaces defined by SynchroniCity used to connect the overall platform to heterogeneous data sources and IoT devices. This represents one of the relevant “interoperability points” that should be implemented by the Reference Zones to be part of the SynchroniCity ecosystem

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

● Northbound uniform interfaces: is the set of uniform APIs that provides all the platform functionalities that will be used by the final Smart city end-users applications. Also this layer can be considered an interoperability point, because it is the main way, for external applications, to interact with the platform and to be part of the digital single market that will be technically enabled by SynchroniCity.

Next sections detail the infrastructure and platform elements for each reference zone by providing the detailed information on the legacy datasets, components and the APIs which are currently deployed and operated.

3.1 RZ Antwerp (BE) This section aims to describe and summarize the reference architecture, system and components, applications and services, data sets and infrastructure related to the Antwerp RZ that will support the SynchroniCity use cases deployment and the Open Call developments.

Figure 2 Antwerp RZ - minimal set of available infrastructures/services (ETA June 2018) shows the Antwerp RZ requirements (minimal set of available infrastructures/services May 2018) related to the application theme “Human Centric Traffic Management” described in the document D3.1 “Documentation of service designs” [3].

Figure 2 Antwerp RZ - minimal set of available infrastructures/services (ETA June 2018)

3.1.1 RZ legacy system overview The Antwerp RZ shown in Figure 3 includes data from different IoT projects, managed by different entities within the reference zone: the City of Antwerp Smart Zone. The Smart Zone is a new and important initiative that has the integration of IoT/IoE in our everyday life as a main goal. The Smart Zone is the pinnacle of the City of Antwerp’s efforts to become a front-running smart city, which leads the city administration to focus its participation in existing IoT projects towards this area. The political decision to focus efforts on the Smart Zone ensures that this area will be much more equipped with technical components and available data than in any other part of the city.

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

The City of Antwerp is expecting a continuous growth in IoT/IoE initiatives in the next months and is aiming to largely improve the visibility, usability and importance of the Smart Zone and its use cases with the cities’ stakeholders, e.g., citizens, merchants, business owners, tourists, decision makers.

One of the most important things that the City of Antwerp is expecting to achieve with these legacy systems and its continuous further development is enlarging and facilitating its social impact on the city and its inhabitants in an easy, cost efficient way.

Always keeping in mind that a solution for end users has to be easily accessible from different devices and via multiple channels (e.g., smartphone, public pc, organization service desks like frontend desks of the public social welfare organization, user-friendly and cost efficient. These services will need to be announced at a daily basis via multiple channels and devices and the interested party will have to be able to stake his or her claim on these services. More examples can be found below.

The current IoT services are focused on multiple domains:

● Smart Logistics: e.g. parking slots with sensors and smart parking signs.

● Smart Mobility & Traffic: e.g. Cycling Push Sensors, Bike sharing stations and Camera feed - traffic info.

● Smart Environmental monitoring: e.g. fixed and mobile air quality sensors and weather stations.

● Smart Waste: e.g. smart waste sorting litter bins and containers on the street for recycling

Antwerp RZ offers its data catalogue mainly through two ways:

● API Marketplace

The responsibility of the API Marketplace in our IoT infrastructure is twofold:

1. To abstract the communication bridges and other data sources from the microservices that uses the data (for storage, analytics, in stream processing). In this way other services can work with the data without the connection complexity. Therefore the gateway must support patterns like telemetry (if not raw or data dump) and inquiries.

2. Exposure of the data to third parties

To be able to expose data to third parties, the marketplace(s) need(s) to support multiple types of protocols, like: Request response messaging, Fire and forget, Event messaging, Streaming and File.

● Static Open Data1

Since November 2012, the city of Antwerp has made a number of lists of data or datasets freely available to everyone.

Multiple data sets are available for the following domains (+300 datasets): Management and policy, population, culture - sports – leisure, geography, infrastructure, environment and nature, mobility, education and upbringing, tourism, safety, well-being and health, work and economy, living.

Everyone may use and publish this information as desired, without restrictions on, for example, copyright and patents.

1 http://opendata.antwerpen.be/

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Other relevant datasets that are not necessarily open data. For instance Datasets/integrations with public transport, alternative transport (bikes), current traffic (jams, lights), public/private parking, route planners, etc.

Figure 3: Antwerp high level component architecture

3.1.2 High level theme and service domains Antwerp will be participating in the “Human Centric Traffic Management” theme. For this, the following datasets will be made available through the Synchronicity platform:

● Traffic intensity ○ Bike sharing data ○ Bike GPS data

The datasets will be expanded as the SynchroniCity project progresses, while the RZ adapts the existing and incoming data sources to the agreed Synchronicity data models and implements the corresponding adaptors. Most of the data models will follow the FIWARE data model specification2.

3.1.3 City infrastructure and technical elements The IoT architecture of the platform in Antwerp is based on microservices architecture. Every component stands on itself and communicates with the other components through APIs. Communication with UI and data stores also happen trough adapter and open APIs hence realizing a flexible architecture based on top of or across the City Infrastructure components

Some numbers of the Antwerp RZ infrastructure (March 2018):

Some numbers of the Antwerp RZ infrastructure (March 2018):

2 http://fiware-datamodels.readthedocs.io/en/latest

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

● Devices

o 1.550 devices

o 58.169 messages per day

● Type and Volume

o 938 waste observations per day

o 7.231 parking observations per day

50.000 environment observations per day

The biggest infrastructural capacity of the RZ relies on a set of gateways, which are specifically developed for City of Things (testbed) architecture and are scattered throughout the city. Each gateway is connected to the city’s fiber-optic network, which acts as a control network to provide experimentation management. These gateways have a wide range of wireless technologies available as dedicated Systems on Chip: IEEE 802.1ac on 2.4 and 5 GHz, DASH7 on 433 and 868 MHz, Bluetooth (Low Energy), IEEE 802.15.4, IEEE 802.15.4g and LoRa. This enables connecting both high bitrate sensors at close range and long range low power sensors. Other wireless technologies (e.g., cellular) will be integrated in the future. Additionally, each gateway is equipped with a small-form-factor computer, which acts as a controller of the different radios and has ample storage and processing power available for deploying large smart city applications directly on top of the gateways.

City of Antwerp also features a separate LoRaWAN-based network, mainly intended for ensuring a continuous real-time stream of sensor data and a citywide coverage. This robust LoRa network will support data capturing for ACPaaS and City of Things core platforms. Besides that, sensors can use the existing commercial networks available in the city, such as commercial LoRa-networks, a commercial Sigfox-network, several mobile data networks (e.g. GPRS, LTE, LTE-M). When used in city projects, the data collected by these sensors will typically be collected through RESTful APIs provided by the network providers.

Antwerp has a growing number of sensors installed throughout the city, for both experimentation and operational purposes. This allows external parties to install their own sensors and connect them to the IoT infrastructure. To allow experimentation at the network and data level, the majority of the experimentation sensors have two radios attached: one LoRaWAN radio and one additional radio, supported by the City of Things gateways.

Smart Parking Lots (FastPRK): About 100 parking sensors have been deployed in the downtown city to measure usage of parking spots on loading zones. Several loading zones have been equipped with parking sensors (Figure 4 On-/off-street parking sensor) every 2 meter. Once a vehicle is stationed above the magnetic sensor - the status becomes occupied. After 15 minutes occupancy off the same sensors (every car is longer than 2 meters) a message is sent to the traffic wardens within a 500 meter radius. The traffic workers within this radius receive a notification on their handheld - one of them picks up the notification and goes to the long occupied sensors. If people are still loading the vehicle - no fine is written - otherwise a fine is written.

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Figure 4 On-/off-street parking sensor

Figure 5 Overview status loading zones

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Figure 6 Overview status loading zones cont´d

Smart Traffic Signs (A*Sign): The A*Sign digital traffic signs are equipped with Sigfox, NFC, GPS and E-ink screens. They are an IoT add-on for the Romcore3 platform that handles every city user request:

• Citizens complete their digital request in 2 minutes.

• Civil servants manage requests in a user-friendly interface.

• 2 supporting Romcore components handle asset management and planning.

Figure 7 Example of a Smart traffic sign and the visualization on mobile and desktop device

3 Romcore combines two architectural paradigms, a data processing pipeline to handle real time data streams (for example sensor data from Internet of Things applications) and supporting microservices that serve as a set of software components, https://www.iotone.com/software/romcore/s300

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Cycling GPS Sensors A project is being prepared to track bikes in the municipality. In an initial phase the target group is the pool bikes used by the employees of the municipality in order to monitor and share data regarding bike usage, location, speed and paths. The intention of the Municipality is to exploit these data in order to improve bicycle paths, route planners, planning of roadworks, events, etc.

Bike Sharing Stations The numerous Velo stations are located in walking distance from each other (max 400 m). The Velo stations can be found throughout the city center and in the surrounding districts. New bike stations are added on a regular basis4.

Figure 8 Antwerp city’s bike hiring docking station

Antwerp RZ provides real time information of bike renting (Velo) stations. Bike hiring docking stations information is offered to the Antwerp Open Data Portal5 by the company managing these infrastructures and is used in the operational processes.

Camera Feed- Traffic Information Antwerp is deploying 14 AXIS Q6000-E PTZ Network cameras. Each camera consists of 1 PTZ camera for police use case scenarios, and 4 additional 2MP camera for smart city use case scenarios. Machine learning components will be working on the 48 camera feeds to detect relevant information (e.g. citizen flows) in real-time.

In the context of the smart city use case scenario the Municipality is looking at smart lighting and smart crossing projects with an ETA of June 2018 for the thermal images and December 2018 for other images to track direction, speed, vehicle type and amount.

4 https://www.velo-antwerpen.be/en 5 http://opendata.antwerpen.be/datasets/velo-stations

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Figure 9 ANPR cameras used in the Antwerp RZ

● Video camera feeds with video analytics software for smart city use case scenarios

Figure 10 Example of video cameras used in the Antwerp RZ

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Fixed and Mobile Air Quality Sensors There are 20 mobile air quality nodes deployed on top of mobile post vans that drive around the city of Antwerp. These air quality nodes measure PM1, PM10, PM25, CO2, NO2, VoC6 and are continuously sending the air quality data over LORAWAN. Currently we also have 1 static sensor box and will extend this to 4 additional static sensor boxes.

Figure 11 Example of mobile air quality sensors

Smart Waste At the moment, 695 waste containers7 in sorting lines have been rolled out in Antwerp. A waste sorting line is a series of underground waste containers in which the waste can be deposited per fraction. Only the pillars can be observed above ground. In the districts where the “waste sorting lines” have been rolled out, the door-to-door 6 https://en.wikipedia.org/wiki/Volatile_organic_compound 7 https://www.antwerpen.be/nl/overzicht/sorteerstraatjes-en-glascontainers/sorteerstraatjes

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

collection of waste ends. City streets are then no longer filled with waste trucks doing weekly trash pick-up rounds. Waste from the “sorting streets” is being collected per fraction when needed and “on demand”. Only waste containers that are almost full (~95%) are being emptied. By use of these sensors and the analytic, the city of Antwerp could go from 3 to 2 waste deposit trucks for underground waste containers. In addition to the “sorting streets” the city of Antwerp has about 130 Bigbelly's (smart waste bins). All these smart waste collection infrastructures have sensors; the collected data is readily available and can be used for optimizations and predictions on emptying only the waste systems that are actually just below full filling.

Figure 12 Antwerp city’s Smart waste sorting litter container (Bigbelly)

The sensors in the underground sorting columns, paper baskets (a pilot project in 100 paper baskets and Bigbelly) have plenty of information. The acquired knowledge and information contains data on different domains: use of the column (tonnage of the fraction, valve movements), the user (who is the citizen identification) and infrastructure info for maintenance and collection, container blockage. With this info the organization can optimize their services, reduce CO2 emission because of optimized collection routes, and work more tailor-made.

Figure 13 Antwerp city’s Smart waste sorting litter line

“Consumers” and citizens obtain access to a sorting column (modern waste containers) via a personal badge. The city of Antwerp aims to provide citizens access via the A-card and/or via mobile phone in the near future. The citizen can manage his waste budget in a virtual portfolio.

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Reference zone framework The data funneled through to the IMEC part of the Antwerp RZ platform is actual live data coming from the Antwerp Smart City project, City-of-Things. The heterogeneous set of active sensors currently monitors a wide variety of environmental measurements and KPIs relevant to the mobility use-cases of the smart city area. Via IMEC developed platform, Dyamand, sensor data is ingested into the platform and normalized in our Kafka Message Broker. Different sets of microservices, deployed on Kubernetes, then act as Kafka consumers and drive specialized data flows processing, aggregating and storing the data in different data stores, e.g. MongoDB, InfluxDB and of course the Orion Context Broker. Other microservices, representing the API Gateway, are used to present the data to the user in different formats, both proprietary and standardized formats.

3.2 RZ Manchester (UK) This section aims to describe and summarize the reference architecture, system and components, application and services, data sets and infrastructure related to the Manchester RZ that will support the SynchroniCity use cases deployment and the Open Call developments.

Manchester RZ is (minimal set of available infrastructures/services) related to the application theme the “Community Policy Suite” described in the document D3.1 “Documentation of service designs” [3].

3.2.1 RZ legacy system overview Manchester City Council (MCC) is the coordinating partner for the Manchester RZ. Although the city is the public sector partner on Synchronicity, the RZ will access assets and services that are provided by a range of public and private sector partners. In particular, the assets from two major projects, Triangulum 8 (2015-20), funded by the EU’s Horizon 2020 Programme, and CityVerve (2016-18), funded by the UK innovation agency Innovate UK.

The management of these programs is discreet from Synchronicity, but the coordination across all three projects is managed by the Resources and Programmes team within City Policy, Partnerships and Research within Manchester City Council.

The reporting structure of CityVerve9 in particular – featuring as it does, only Manchester – partners is key to understanding the city’s IoT infrastructure. Project management is undertaken by Cisco Create, and by MCC reporting into a project board consisting of theme and work package leads, and chaired by Rowena Burns, Chief Executive of Health Innovation Manchester. This project board in turn reports into the Corridor board, a not-for-profit organization consisting of the city council, two universities, Manchester Science Partnerships and other partners based on the Oxford Road Corridor which forms our “smart city district.”

Links with the internal ICT systems and technology services are indirect, so our “Smart city” architecture sits outside of the remit of our technology services, and is a partnership between public and private sector partners.

Because of this Manchester RZ has developed a model where a range of different services and applications are discreetly managed, but data is then made available via a range of platforms, with integration and interoperability taking place at the data level, rather than the device level.

8 http://www.triangulum-project.eu/ 9 https://cityverve.org.uk/

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

In addition, many of the existing IoT services and data sources within the city are not held by the city council. Where these are made available (e.g. Defra’s Air Quality data10) they are integrated into the city’s platforms. In other cases, where data is not open, the partnership model we have enables us to coordinate sharing of closed data between industrial partners and public bodies. (e.g. integration between air quality data and traffic light control).

Figure 14 Simplified Data Architecture for Manchester

The Figure 14 above shows how this works using a sample of 6 services/datasets. We have a federated model with a wide range of data owners and providers, and a number of different data hubs/catalogues/platforms.

Each of these is maintained by different organizations, and hosted locally by the service.

Where this data is open it can be shared amongst several platforms, which will either make a call to an API or upload a static dataset on a regular basis.

The city’s own data catalogue provides a single entry point to find out what data is available but doesn’t provide the functionality required by the smart city platforms.

The 2 CityVerve platforms work together – BT data hub began as primarily a transport hub, but has expanded to include other data and this also is part of the “platform of platforms” available through Cisco’s programmable city API. Triangulum’s data platform, maintained by the University of Manchester, has some unique data which can then also be accessed via BT data hub.

In order to provide some standardization, the Hypercat11 standard is applied to data on the BT data hub.

10 https://uk-air.defra.gov.uk/ 11 http://www.hypercat.io/

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

The above diagram indicates how the city, as a non-FI-WARE installation will interact with the Synchronicity architecture. There will be a single point of integration via data that is on the BT hub which will then be converted from Hypercat format into NGSI format.

Access to the city data from SynchroniCity partners, open call applicants and the Synchronicity data store will therefore be available in a single place. A local install of Orion Context Broker will be required to enable this, and we are currently assessing the options for installing and maintaining this. Conversion of datasets to NGSI format will be undertaken by the Digital Catapult, and we perceive this will be an ongoing process as we onboard more services to the city’s IoT infrastructure.

The strengths of the model above see a “loosely coupled” system that does not proscribe particular technologies for new sensors and services, but provides an incentive to make data from those available via a shared city platform which can then provide easy access to other data. From a Synchronicity point of view, this provides a single point of entry (BT hub) into Manchester data. Where datasets are required but not currently on the hub, we will be looking to ensure onboarding in line with demand.

3.2.2 High level theme and service domains Manchester will be participating in the Community Policy Suite theme. As this theme does not require the installation of new sensors, and the theme is about developing agile governance across different services we are not limited to a single data set or data type. However, during the development of the baseline service, in order to prove the concept (as detailed in D3.1), we are working to identify challenges that utilize a range of existing data sets.

Real Time data

• Air quality monitoring

• People tracking

• Cycle & car counting

• Cycle journeys

• Building energy usage

• Parking data

Static data

• Bus, tram and train routes

• Points of Interest

• Events

• INSPIRE data

• Transparency data (e.g. spend by local authority)

• Population and Demographic Data (ONS)

• Street side asset data (Ordnance Survey)

The subset of data that we will be utilizing will be via the BT data hub, and these datasets will, where appropriate use Hypercat as a standard.

• Air quality monitoring - Live Air Quality readings from sensors at key sites around the city:

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

o Noise

o PM1

o PM10

o PM2p5

o Humidity

o Heat • People tracking

o People Counting – Oxford Road and Portland Street (Camera) o People Counting – Albert Square (Camera) o People Counting – Railway Stations (Wi-Fi)

• Cycle & car counting

o Cycle counting – Oxford Road

o Cycle counting – Albert Square

o Vehicle Counting – Oxford Road

o Vehicle Counting – Albert Square

• Cycle journeys

o Seesense12 data

o Cargo bike data

• Building energy usage

o Half-hourly electricity consumption (kWh) • Parking data

o Car park occupancy data

• Bus, tram and train routes

• Points of Interest

• Events

• INSPIRE data

o Compulsory Purchase Orders

o Planning Obligations

o Smoke control orders

• Transparency data (e.g. spend by local authority)

• Population and Demographic Data (ONS)

• Street side asset data

o Ordnance Survey data on wide range of street side assets.

3.2.3 City infrastructure and technical elements Manchester has a high level of connectivity.

12 https://seesense.cc/pages/manchester

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

• 3G & 4G Networks

o Maintained and managed by the national mobile operators (e.g. Vodafone, 3, EE)

• Public Wi-Fi

o FreeBeeMcr13 – public Wi-Fi managed by Virgin Mobile on behalf of Arqiva14, who have the concession for providing this service

o Wi-Fi on trams – public Wi-Fi provided for free by TfGM15

• 5G

o None currently available

• Low Frequency Networks

o Sigfox – concession managed by Arqiva

o LORA – network installed by Cisco for use with CityVerve

o Things Network (LORA) – Open LORA network

• FTTP

o Superfast fiber is readily available in Manchester via BT and Virgin (Cable) to residents and businesses.

• Localized networks

o Bluetooth and ZigBee are easily deployable within Manchester

• Geospatial information

o Manchester is working closely with Ordnance Survey, the UK’s mapping agency, to develop next generation geospatial tools, including 3D models of our reference zone and point clouds, with a high level of granularity.

Manchester is not currently looking to install new sensors through the Synchronicity Community Policy Suite theme, however our “loose coupling” approach to city architecture makes it very easy for new sensors to be installed, and for data from them to be shared via the above platforms e.g. via the open call.

A range of public assets are owned by the city or other partners, and our smart city district also includes a major property developer, Bruntwood16 (major shareholder in Manchester Science Partnerships), the hospital and two universities all of which have considerable estates they are responsible for.

The city and TfGM have access to lamp posts, bus stops and other assets for install of sensors. There is usually a cost associated, but the city can act as a coordinator to enable new sensors via the open call, or as a result of changes highlighted via the community policy suite.

3.3 RZ Carouge (CH) This section aims to describe and summarize the reference architecture, system and components, application and services, data sets and infrastructure related to the Carouge

13 http://www.manchester.gov.uk/info/100003/people_and_communities/6886/free_wifi_in_manchester/1 14 https://www.arqiva.com/ 15 https://www.tfgm.com/ 16 https://bruntwood.co.uk/

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

RZ that will support the SynchroniCity use cases deployment and the Open Call developments.

Service Service provider Infrastructure

Smart parking IEM Parking slots with sensors

Noise monitoring OrbiWise Sound level sensors

Online schedule for the public transports

TPG Bus stops

Off street parking SITG Public parking entrances and exits

Traffic flow observed SITG Road sections

Air quality observed SABRA (Canton of Geneva)

Air quality for PM10, NO2 and O3

Table 3 Carouge RZ themes and services

3.3.1 RZ legacy system overview The city of Carouge provides several services through the Smart City infrastructure in Carouge:

The first one is a smart parking service. The different parking slots in Carouge are equipped with sensors which are able to determine the occupancy of a vehicle. The manufacturer of these sensors (IEM [74]) collects the data from the sensors to a server, and the server is connected to an intermediate platform named Universal Device Gateway (UDG). UDG retrieves the data using HTTPS and make it available for the city of Carouge to enable further services.

The second available service is a noise monitoring in all the streets of Carouge. OrbiWise [75], the manufacturer of the sound level sensors, collects the measurements data from each sensor every 15 minutes. Then, a server installed by OrbiWise provides these measurements to UDG using HTTPS and UDG makes it available for the city of Carouge.

The third service is providing online and live schedule on the public transports in Carouge. The TPG (Transports Publics Genevois [76]) offers an API to access the open data concerning the next departures of each bus stop in the city of Carouge. The schedule is used for the different kinds of vehicles, like the buses, the trolleybuses and the tramways. An online Web service managed by the TPG can be accessed to retrieve the data for all the bus stops through a HTTP connection. UDG integrates the data into the Carouge platform.

The fourth and fifth services are on integration process. The service data are provided by the canton of Geneva through two offices: the SITG and the SABRA. As mentioned in the introduction of this section, the fourth service is the monitoring of the off street parking and the traffic flow in the entire canton in Geneva. The fifth service is the measurements of the air quality across all the canton of Geneva.

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

The SITG (Système d’Information du Territoire à Genève) gives an open access to the data owned by the canton of Geneva. Two kinds of live and open data are available: the public parking and the mobility. The data concerning the public parking are mapped to the FIWARE OffStreetParking data model. On the same time the data for the mobility are mapped to the FIWARE data model for the traffic flow observed. HTTPS requests are made regularly to the SITG server to retrieve the latest measurements.

The SABRA (Service de l'air, du bruit et des rayonnements non ionisants) is a service of the canton of Geneva, which takes care of the air quality, the noise and the non-ionizing radiation. In this context, the SABRA is responsible for the ROPAG (Réseau d’Observation de la Pollution Atmosphérique à Genève); the ROPAG is a network of four measuring stations to monitor the air quality. Three types of measurements are made periodically: particulate matter of a size of 10 micrometers (PM10), nitrogen dioxide (NO2) and ozone (O3). The data generated by these four stations built in different locations in Geneva is accessible freely from a Web server managed by the SABRA. This kind of data is mapped to the FIWARE AirQualityObserved data model that is selected to be used in SynchroniCity.

Universal Device Gateway (UDG [77]) is an Internet of Things platform permitting the seamless integration and the interoperability of the heterogeneous data provided by the different services installed in Carouge. The different kinds of data mentioned in this document are pushed by UDG to a FIWARE Orion context broker, followed by SynchroniCity reference implementation. Then, another FIWARE component named Cygnus dispatches the data to Comet STH (Short Time Historic) and to CKAN. Comet STH is responsible to store the data into a MongoDB database and CKAN is a server used to publish open data.

The data models used by the reference zone of Carouge are already described in the Task 2.2. Other useful information is also available in the Task 2.4.

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Figure 15: Carouge high level component architecture

3.3.2 High level theme and service domains UDG provides the data under a format compatible with the NGSI version 2. So it is possible to retrieve the data from the Orion context broker dedicated for the city of Carouge using the standardized NGSI API.

The data models used in the implementation for Carouge are aligned with the SynchroniCity data models [8], which are based on FIWARE data models.

So, the principle of entity identifier and type of NGSI is taken into account in the full process of the data collected in Carouge. Each field of the data coming from the different servers linked to the city of Carouge is considered as an attribute having a name, a type and a value.

The complete datasets available in Carouge are described in the T2.2 and corresponding deliverable D2.2 [2]).

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

3.3.3 City infrastructure and technical elements The infrastructure is composed by different sorts of wireless sensors currently installed in Carouge. The usage of the sensors is to measure mainly the presence of a vehicle on each parking slot and to monitor the sound level across the streets of Carouge. To achieve these goals, different web servers have been installed and are currently maintained and managed by the service providers, like IEM and OrbiWise. The Web servers offer APIs to retrieve the data provided by the different kinds of sensors. These APIs are used by Universal Device Gateway (UDG) and the data are automatically transformed into the corresponding FIWARE data model.

The different types of sensors already deployed into the city of Carouge are presented below in Figure 16, Figure 17 and Figure 18:

Figure 16: Carouge – Parking sensor

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Figure 17: Carouge – Parking sensor on a forbidden parking slot

Figure 18: Carouge – noise sensor (the white box) placed on a downspout

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Reference zone framework As a reference, the detailed study and description of the technical elements, particularly the IoT devices in OASC compliant platforms, is presented and described in the T2.4 – “Enablement of a DSM for IoT devices manufacturing for Smart Cities” and corresponding deliverable D2.6 “Guidelines for the integration of IoT devices in OASC compliant platforms” [4], which include a description of the IoT devices and solutions that will be deployed, including the elements of the Carouge reference zone platform, presenting; a collections of IoT products in city applications, a description of southbound interfaces of OASC compliant platforms, and the Integration models and guidelines, as well as presenting solutions easily deployable and fully interoperable with SynchroniCity architecture and deployment.

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

3.4 RZ Eindhoven (NL) This section aims to describe and summarize the reference architecture, system and components, application and services, data sets and infrastructure related to the Eindhoven RZ that will support the SynchroniCity use cases deployment and the Open Call developments.

Figure 19 shows the Eindhoven RZ requirements (minimal set of available infrastructures/services for the initial application ‘data-driven bicycle mobility’) related to the application theme “Human-centric traffic management” described in the D3.1 “Documentation of service designs” [3].

Figure 19: Eindhoven RZ - minimal set of available infrastructures/services

3.4.1 RZ legacy system overview • The Eindhoven legacy system includes data from different IoT projects and/or living

labs, managed by different entities within the city ecosystem. Figure 24 provides a

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

screenshot of an overview in Google Maps of the Eindhoven reference zone area with the different available types IoT sensors, devices and/or dataset POIs and their locations

Figure 20: Eindhoven overview and locations of IoT devices

Technolution Traffic Data Technolution provides amongst others the MobiMeastro Traffic Management System, controlling the intelligent Traffic Light Controllers. The Eindhoven RZ will use the following modules:

• C-ITS module for providing motorized traffic data from roadside and integrated counting systems and smart connected vehicles, including routes/trajectories.

o Floating Car Data from the C-ITS roadside stations and vehicles.

o Open Data services or External system interfaces modules? as real-time and historic traffic data from the (Dutch) National Data Warehouse for Traffic Information17

• DVM-Exchange18 module to ‘process’ an iTLC ‘switching’ advice, as defined in Interface Design Description DVM Exchange 2.5 19

• Traffic Light module for

17 http://www.ndw.nu/en/ 18 http://www.dvm-exchange.nl/ 19 http://www.dvm-exchange.nl/uploads/2014/02/idd-v2-5-4-dvm-exchange-v2-5.pdf

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

o The ‘real’ actuation of the iTLC’s, according to the regulating traffic flows, as defined in (paragraph 4.6 of) the IveraTLC-FI, Traffic Light Controller Facilities Interface20.

o Retrieving VLOG3 status message (contains the actual state of a specific item, i.e. phase state or detection state) from the iTLC’s, as defined in (paragraph 4.1.2 of) the Ivera IRSIDD VLOG Interface21

• It is possible to divide the road into trajectories between two crossings. For each trajectory travel times can be exposed, using the DATEX-2 NL-profile - format:

• From the traffic light installations in the RZ traffic counts (traffic intensity) can be exposed as shown in Figure 21;

Figure 21: Eindhoven RZ – MobiMaestro traffic data and flows harvesting and regulation

My040Routes Local Traffic Tracking Data In the Eindhoven RZ a pilot is conducted to get insight into the transport behavior of road users in the city. With the Sesamo app installed by pilot users the following data is captured and analyzed.

• Transport modes

20 https://www.ivera.nl/wp-content/uploads/2016/01/Deliverable-G3-IRSIDD-iTLC-Ivera4.00-v1.2.pdf 21 https://www.ivera.nl/wp-content/uploads/2016/01/Deliverable-G4-IRSIDD-VLOG31.pdf

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

• Routes used

• Times

• Front and after transport

• Travel duration

• Distribution over the day/week

Visualization of infra-use modal split and intensity (green = pedestrian, orange = bike, light blue = bus, grey = car, dark blue = train)

Figure 22: Eindhoven My040Routes analytic/visualization example

ViSence Pedestrian/Bicycle Counters This pedestrian/bicycle countering functionality is currently operational at the Strijp-S and Stratumseind living labs in Eindhoven. Figure 23 provides a screen shot of a test to recognize abnormal behavior (a lot of running people) at the Stratumseind living lab, more focused on de-escalation and/or prevention of unsecure circumstances and in this way increase well-being of visitors and inhabitants of the largest pub street during night/going-out hours.

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Figure 23: Eindhoven RZ – ViNotion/ViSence pedestrian/bicycle traffic counters

• ViNotion provides amongst others traffic analysis and classification software solutions. On YouTube22 is the ViSense Traffic Analysis Kleine Berg Eindhoven available, explaining how people, bicycle and/or car recognition and counting works (in a pilot environment). ViNotion traffic flow analysis is performed in software located in the video cameras on the edge, personal data/images are never stored at any location; only the counters are made available to higher context broker/(open) data platforms. The Eindhoven RZ will use aggregated/delayed people and bicycle count (for the last hour) which are available on the Open Data Portal23 - as available from living lab Stratumseind - and/or directly the (relevant) data API packets. Available data API packages:

• Scene

• Rule

• Density description packet

• Count

• Object description

• Object classification description

• Object real-world description

• Object GPS description packet

• Object speed

• Object GPS location

• Throughput

• Density

22 https://www.youtube.com/watch?v=7pNm-WjFfUk 23 https://data.eindhoven.nl/api/records/1.0/search/?dataset=livinglab-stratumseind-last-hour-peoples-count

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

3.4.2 High level theme and service domains • Using non-motorized traffic metrics for optimizing traffic flow

o The City of Eindhoven promotes non-motorized traffic over motorized traffic.

o Benefits:

Health of commuters

Environment (Paris Climate Agreement)

Less congestion

Less space for storing unused cars

o The goal is to give preference to non-motorized traffic by optimizing for speed and safety without causing further congestion.

Figure 24 Crossroad in Eindhoven RZ

• Traffic Management Systems can optimize traffic throughput based on data

• Motorized traffic data is available:

o Roadside and integrated counting systems

o Smart connected vehicles

o Data from adjacent traffic light installations

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

• Non-motorized traffic is invisible

• Using Smart Camera's to count non-motorized traffic at intersections

o Counting movement patterns and type of traffic

o Images are deleted on camera after analysis, no personal data is retrieved

Traffic Monitoring The traffic information to be provided within this use case will be gathered from the following sources deployed in the Eindhoven Reference Zone:

• Technolution traffic (times and counts) data

• My040Routes local traffic tracking data

• ViSence pedestrian/bicycle counters, and (optionally)

• Hopper point bike sharing (usage/tracking) data

This information will (where feasible) be modelled following the FIWARE Transportation Harmonized Data Models [59], using the following entity types

• Road

• Road segment:

• TrafficFlowObserved [60]. This modelling offers the description of a set of attributes related to traffic flow in a city. From this set of attributes some of them have been selected to describe the deployed traffic sensors in Eindhoven: identifier, type, location, dateModified, dateObserved, intensity and occupancy

• The BikeHireDockingStation [61] entity type. This modelling offers the description of a set of attributes related to its location and current status, e.g. the number of available bikes for hiring or the number of free docks to return the bikes.

Environmental Monitoring The traffic information to be provided within this use case will be gathered from the following sources deployed in the Eindhoven Reference Zone.

• Munisence noise level microphones

• Sorama noise analysis and classification

• Aireas air quality

This information will (where feasible) be modelled following the FIWARE Environment [50] and Weather [53] data models.

• NoiseLevelObserved [52] represents an observation of those parameters that estimate noise pressure levels at a certain place and time.

• AirQualityObserved [51] represents an observation of air quality conditions at a certain place and time.

• WeatherObserved [54] represents an observation of weather conditions at a certain place and time.

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

3.4.3 City infrastructure and technical elements

My040Routes local traffic sensors With the Sesamo app24 installed on their smart phone by pilot users, these GPS equipped smart phone are the (human-based) sensors, providing the data as described in paragraph 3.3.1.2. Figure 25 shows how a pilot user can rate a trip, connect a date/time to a trip and see the estimated time of arrival of the destination.

Figure 25 Eindhoven RZ – My040Routes (local) traffic tracking app

ViSence pedestrian/bicycle counters At the living lab there are 5 high definition cameras in place, with the ViNotion/ViSence pedestrian/bicycle countering functionality installed. The video stream is processed directly on the edge; no video data is streamed (northbound) or stored in higher level IoT agent, context broker or open/history data stores. In Figure 26 below a picture is shown with an example of these cameras in the middle. On top is a MAC address tracker, which is disabled; below is a police surveillance camera.

24 https://play.google.com/store/apps/details?id=nl.mobidot.sesamo&hl=en

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Figure 26 Eindhoven RZ – HD Camera, equipped with ViNotion/ViSence

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Hopper points There are 5 bike sharing stations available in Eindhoven at different locations at Strijp-S (and –T), municipality building locations (STH + NRE) and Park Plaza (shown in Figure 27).

Figure 27 Eindhoven RZ – Hopper bike sharing point at City Hall

With the Hopperpoint app25 installed on their smart phone of the users, these GPS equipped smart phone are the (human-based) sensors, providing bike sharing (usage/tracking) data.

Munisence noise level microphones At the living lab Stratumseind there are 5 Munisence26 directional microphones in place (shown in Figure 28), which monitors sound levels.

25 https://play.google.com/store/apps/details?id=nl.hopperpoint.api&hl=en 26 https://munisense.com/measuring-noise

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Figure 28 Eindhoven RZ – HD Camera, equipped with ViNotion/ViSence

Sorama sound cams At the living lab Stratumseind there are 5 Sorama Soundcams 6427 in place as shown in Figure 29, with the Sorama noise analysis and classification functionality installed. The audio stream will be processed directly on the edge, with only relevant/abnormal sound data is streamed (northbound) and stored in higher level IoT agent, context broker or open/history data stores.

27 https://www.sorama.eu/?q=CAM64

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Figure 29 Eindhoven RZ – Sorama 64 Camera

Aireas air quality boxes There are 33 Aireas air quality measurement boxes. Figure 30 shows a screenshot of an installed Aireas Airbox.

Figure 30 Eindhoven RZ – Aireas Airbox

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Reference Zone Framework The Eindhoven RZ framework will consist of the following components as depicted in the following Figure 31 and described bottom-up, from sensor to end-user:

• The IoT devices and sensors as described in the paragraphs above.

• Using cellular (2G up to 4G), broadband (copper and fiber), Wi-Fi and LPWAN (Lora and Zigbee) connections and southbound SynchroniCity APIs

• Providing ‘translate’, process and store data using a number of FIWARE Generic enablers as well as the existing Eindhoven Open Data Portal.

Eindhoven will use an own instance with stable and integrated versions of the IDAS IoT/Device Manager and Agents (on MongoDB), the Orion Context Broker, the Proton Complex Event Processing and the Cygnus Connector to PostgreSQL CKAN-based data storage with (linking and/or harvesting to/from) the Eindhoven Open Data Portal based on OpenDataSoft28 tooling and DCAT-AP Data Catalog Vocabulary. Eindhoven will also use the (to be developed, as part of the northbound SynchroniCity APIs) uniform historic data API to store historic traffic data (from My040Routes and/or the MobiMeastro Traffic Management Platform) in the CKAN data store

• The (standardized) data will use northbound SynchroniCity APIs to the (to be selected and/or developed) services and market place components,

• To provide data, service and applications for data-driven bicycle mobility for the end-users.

• One off the foreseen application will support optimizing traffic light scenario’s based on the combined use of all (pedestrian, bicycle, cars, emergency and public transport) traffic modes, intensities and classifications. Since to actuation of the traffic lights must be performed by the iTLCs, we will anticipate the use a southbound SynchroniCity APIs to provide an advice to the MobiMeastro Traffic Management Platform.

28 https://www.opendatasoft.com/

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Figure 31 Eindhoven RZ – FIWARE based Framework

3.5 RZ Helsinki (FI) This section aims to describe and summarize the reference architecture, system and components, application and services, data sets and infrastructure related to the Helsinki RZ that will support the SynchroniCity use cases deployment and the Open Call developments.

Figure 32 shows the Helsinki RZ requirements (minimal set of available infrastructures/services) related to the application theme “Multimodal transportation” described in the document D3.1 “Documentation of service designs” [3].

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Figure 32 Helsinki RZ - minimal set of available infrastructures/services

3.5.1 RZ legacy system overview Helsinki has been one of the open data pioneers in Europe and opened data since 2011.

The Helsinki Region Info share (HRI - shown in Figure 33) service aims to make regional information quickly and easily accessible to all. Essentially, HRI is a web service for fast and easy access to open data sources between the cities of Helsinki, Espoo, Vantaa and Kauniainen. The data published is mainly statistical, giving a comprehensive and diverse outlook on different urban phenomena, such as living conditions, economics and well-being, employment and transport. A good proportion of the data material offered by the service is GIS based. 600 data sets have been published in HRI so far.

The data can be used in research and development activities, decision-making, visualization, data journalism and in the development of apps. The data may be used by citizens, businesses, universities, academies, research facilities or municipal administration. The data on offer is ready to be used freely at no cost. There are no limitations on users; anyone interested in open data can participate.

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

There are four operational areas in which the HRI service mainly operates in:

• Producing data

• Opening data

• Sharing data

• Utilizing data

The main operational activity is to support the producers of information in opening their data and to increase its utilization by multi-channel communication.

Figure 33 HRI landing page

Legacy data (e.g. public transport fleet locations, bike sharing stations, etc.) is generally available through third party APIs provided by the operator of the device fleet or service. Helsinki area transport operator HSL has lots of open data which can be discovered via its web page29.

Digitraffic APIs (traffic flows, camera streams etc.) English documentation link can be found here30.

Swagger documentation can be found here31 .

29 http://dev.hsl.fi 30 https://github.com/finnishtransportagency/digitraffic/wiki/Digitraffic-in-English 31 https://tie.digitraffic.fi/api/v1/metadata/documentation/swagger-ui.html#/

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Noise Sensors Noise sensors provide data in “Sentilo JSON” [78] format, which they push to our endpoint via HTTP requests, connected via 3G.

OpenAhjo API This dataset provides link to OpenAhjo32, which is an API and a UI for accessing the decision-making material of the City of Helsinki.

City of Helsinki Procurements This dataset provides data on the City of Helsinki’s procurements beginning from 2012. The data33 includes all municipal departments and unincorporated business entities.

Open311 Open311 API34 is used for reporting issues and giving feedback.

City IT System Interaction with Synchronicity Platform Data streams provided by existing deployments managed by operative organizations of the city are accessed through the open APIs provided by those organizations. The plan is to write software agents that subscribe to the original source updates, transform the data into a relevant FIWARE data model, and publish the data to the SynchroniCity platform. It is not planned to be able to send messages back (e.g., for reconfiguration or actuation) to the legacy IoT deployments.

32 http://www.hri.fi/en/dataset?q=openahjo&sort=metadata_created+desc 33 http://www.hri.fi/en/dataset/helsingin-kaupungin-ostot 34 https://dev.hel.fi/apis/open311/

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

3.5.2 High level theme and service domains

Figure 34 Helsinki RZ high level component architecture

Helsinki has evaluated standards created in other EU projects and follows Smart City Reference Architecture from Espresso project35 as shown in Figure 34.

The Helsinki RZ will implement a pilot that belongs to the Multimodal Transportation theme. Helsinki has long been supporting Open Data and Open APIs. The aim is to move out from closed silos, and enable innovative services. In this view, authorities provide basic data, services and tools, on top of which third parties and cities can create their novel services and applications (Figure 35).

35 http://espresso-project.eu/

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Figure 35 Transport data cycles and app/service development36

The Digitransit platform shown in Figure 36 is the most significant outcome of these efforts. This platform is the result of several years of development in order to move out from a full service silo provided by an external company. The platform is 100% based on Open Source code and Open Data. It takes in open map and public transport data, and provides a full-fledged journey planner for citizens for free. Some of the main design principles of the platform include Open API First, Mobile First, HTML5 First and Regular Customers First. The Digitransit platform replaced the legacy system in 2017, with the legacy service closed on 30.11.2017.

The service and application layer of Helsinki RZ is based on the Digitransit platform. The platform provides both offline and online processes. Digitransit’s architecture is based on micro services. Figure 2 illustrates this architecture. Data sources, such as road maps and public transport schedules are read in and conversed into an internal representation, and distributed to the four main services – routing, geocoding, map and real-time services. A user interface then utilizes these services via separate connections to compose an integrated app. Operators oversee the updates, running map and schedule updates at regular intervals, and monitoring real time feeds.

Digitransit service components are available as Docker images.

Routing is the main Digitransit service, with OpenTripPlanner (OTP) as the core. A typical routing request includes the origin, destination and various preferences. This request is handled by Routing Core module, which rerates a separate Routing Context for each routing request. This context includes the user input and other parameters, as well as the graph and transit feeds. If requested, the real-time feeds for transit and historical data on traffic speeds is included in the Routing Context as well. The Context is then given to PathFinder. The PathFinder is responsible for actually searching possible routes from origin to destination. The found paths are returned to the user.

Digitransit uses Pelias as Geocoding and Reverse Geocoding service. Pelias is a modular, open-source geocoder built on top of Elasticsearch37 for fast and accurate global search. Pelias is completely open source and MIT licensed software. The importers filter, normalize, and ingest geographic datasets into the Pelias database. Currently there are five 36 Open Data at HSL. Tuukka Hastrup, 7.5.2015, presentation at Data Science seminar 37 https://www.elastic.co/

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

officially supported importers: OpenStreetMap, OpenAddresses, Who’s on First, Geonames and Polylines. Pelias uses Elasticsearch 2.4 for data storage.

The Map service provides background maps in HSL style. OpenStreetMap data is transformed into vector tiles, with HSL Style and HSL font visualizations, and available via the Map API.

The Real-time Service provides service alerts, trip updates and vehicle positions. It is based on available legacy real time data, which depends on current deployment status and combines both old and new technologies.

Digitransit App is a React based web application integrating all four Digitransit services into a fluid user experience. The front-end is written using JavaScript (ES2015) with three types of components: Views, RelayConnector and Containers.

Figure 36 Digitransit micro service architecture38

3.5.3 City infrastructure and technical elements IoT infrastructure (shown in Figure 37) in Helsinki is taking form as devices are being deployed in the city. Devices are generally operated by the organizations using the data in their operations. The data is planned to be imported into the Synchronicity platform via

38 https://github.com/HSLdevcom/digitransit/blob/master/Architecture.md, Samuli Heljo, 12.11.2015.

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

custom software agents that subscribe to the data sources. This presupposes that all data that we wish to import to the Synchronicity platform must be provided openly by the respective organizations.

Figure 37 Helsinki City Infrastructure Elements

Reference zone framework The Helsinki RZ framework is based on the integration of the RZ data sources with the Digitransit platform via the NGSIv2 API in pursue of a large scale piloting facility. Figure 38 presents the overall schema. On the left, available data sources provide measurements via sensors’ own proprietary protocols, typically over HTTP or MQTT on 3G networks. These sources are read in via Sensor agents, parsing the formats and storing the data both in a fast memory cache for real time use, and to a database for historical searches. Then, Northbound APIs provide this data via NGSIv2 API, both for the RZ Pilot use case and as general Open Data. The data will be provided also in the standard O-MI/O-DF format39.

Details of the Digitransit platform are provided in section 86, Service and Application Layer.

The implementation of this Service Manager may be based on either the Synchronicity platform with selected FIWARE components such as Orion and Cygnus, or the O-MI Reference Implementation, extended to support the NGSIv2 API40.

• The Digitransit platform currently supports only GTFS-RT as an online update format, intended for public vehicle tracking, arrival estimates etc. In order to utilize environmental sensor data via NGSIv2, there are two main options:

• To create a new NGSIv2 compliant networking module into the OpenTripPlanner along with a new dynamic OTP graph updater, followed by extensions to application networking and UI.

To create a new map overlay module that supports NGSIv2 and creates environmental map overlays to the Digitransit Navigation App, with related extensions to networking and app UI.

39 http://www.opengroup.org/iot/odf/p3.htm 40 https://github.com/AaltoAsia/O-MI

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Figure 38 Helsinki RZ framework

This section aims to present a summary describing the technical environment, related technologies and technical characteristics establishing a kind of technical data sheet of the fundamental pieces of the framework and the platform elements to deploy, install and configure, which will be compliant to the platform instance corresponding to the reference zone foreseen to be deployed and operated.

In the following sections a list of tables are proposed to summarize the technological environment of the main components of each layer or modules of the corresponding framework. This information will help to know and foreseen the element to deploy and to operate related to the associated technical context.

3.6 RZ Milano (IT) This section aims to describe and summarize the reference architecture, system and components, application and services, data sets, infrastructure related to the Milano RZ that will support the SynchroniCity use cases deployment and the Open Call developments.

Figure 39 shows the Milano RZ requirements (minimal set of available infrastructures/services) related to the application themes “Human-Centric traffic management “and “Multimodal transportation”.

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Figure 39 Milano RZ - Minimal set of available infrastructures/service

3.6.1 RZ legacy system overview The Milano RZ provides numerous services related to IoT sensors spread around the city. There are weather sensors for pressure, humidity and temperature, traffic sensors such as traffic loops and cameras for counting vehicles and access control to restricted areas. There is also a plan of the Municipality to install parking sensors, especially dedicated to parking lots for disabled, by March/April 2018.

The public transport system is managed by a company (ATM) controlled by the Municipality and it is composed by buses, trams, 4 metro lines and a station-based bike sharing service. Every mean of transportation is equipped with GPS sensors so that is it possible to verify their position in real-time. There is also a urban train system managed by a regional operator (TRENORD) that has an agreement with ATM to integrate all the public transport means into a single ticketing system. Exploiting all these data, ATM developed its own multimodal navigator named “GiroMilano”41 as

shown in

Figure 40.

41 http://giromilano.atm.it/#/home/

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Some of the data are made accessible to the Municipality itself in order to develop an alternative

multimodal navigator named “Muoversi”42 as shown in

Figure 40. Since “Muoversi” is not having a great success among the citizens, there is a talk inside the Municipality about either dismissing or keep investing on it.

Figure 40 “GiroMilano” (left) and “Muoversi” (right) navigators

From October 2017 the Municipality authorized two different operators (Figure 41 and Figure 41 Mobike and Figure 42) to start a free-floating bike sharing service to allow citizen to use, by means of a mobile app, bicycles spread all around the city. The agreement with the municipality involves that the companies must share their data about bike usage and paths with the Municipality. The intention of the Municipality is to exploit these data in order to improve bicycle paths.

42 http://www.muoversi.milano.it/web/portale-mobilita/geomobilita

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Figure 41 Mobike and Figure 42 Ofo screenshots

The Municipality of Milano has its own interoperability platform, based on WSO2, with its own digital market store (API-Store) in order to offer to internal and external user’s access to Municipality’s data. The API Store is accessible from the Municipality web portal43 and offers API to access data in SOAP or REST format.

The Municipality of Milano started as well a long assessment process, yet to be finished, to identify all the data coming from the city and collect them into a large data-lake to be accessed by the interoperability WSO2 platform and made accessible by means of APIs exposed on the API-store.

The Municipality of Milano provides also to the end user a large set of data that can be accessed through the data portal as shown in Figure 4344. Data catalogue consists of several dataset (in March 2018 they were more than 330) that allow any companies, people or organizations to develop new ideas and build upon them new applications that can generate new data, knowledge, process improvement, added value to existing data or to create new services. The data catalogue of Milano RZ is managed by a CKAN system instance, and for most of the data set there is the chance to access them also via API REST. All the documentation of the CKAN REST API is available.

43 https://apisp.comune.milano.it/store/ 44 https://dati.comune.milano.it/

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Figure 43 Milano Open Data Portal

In occasion of the recent EXPO held in Milan in 2015, the Region Lombardia established a consortium (sponsored moreover by the Chamber of Trade of Milan and by the local associations of Industry and Commerce) in order to create a web Digital Market as shown in Figure 44, named E01545 to gather data coming from the different data providers to be exposed to third parties via API (via SOAP or REST format) in order to develop applications. The services offered by the E015 platform are of wide variety including some of the already mentioned transportation data such as bike sharing service, bus and metro system status, parking status in the exchange parking areas in connection with metro stops, but also bus connections with airports (Linate, Malpensa and Orio-al-Serio) and related flight schedules, traffic information and weather conditions just to name the most interesting related to SynchroniCity project perspective.

45 http://www.e015.regione.lombardia.it/PE015/

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Figure 44 E015 Digital Market

The original intention of the E015 platform was to offer to Italian SMEs a platform to access data via API and develop new services, thus all the documentation, policies of use and agreement documents are in Italian. There is then a possible risk that the data could not be available for all European SME that will participate to the open-call, but in the worst case it would be possible to use these data for Milan-RZ technical partner (Engineering) in order to develop the internal services.

Therefore, the biggest issue, toward the SynchroniCity goal, is to gather all these data into a single point because most of them are not held and managed directly by the Municipality.

The Municipality of Milano has its own interoperability platform based on the WSO2 framework that should be integrated with the Synchronicity platform as shown in Figure 45. At the moment the WSO2 platform in Milan is not provided with an IoT Agent module since the only IoT devices owned by the Municipality are connected to a specific platform managed by an external operator that is not integrated with the WSO2 platform. Deeper

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

details about integration between Milan infrastructure and SynchroniCity Platform are discussed in Chapter 4.5.

Figure 45 Integration between Milan infrastructure and SynchroniCity Platform

The WSO2 platform shown in Figure 46 will be integrated with the SynchroniCity platform with the help of the technical partner (Engineering). Present IoT deployments in the Milan RZ include ad hoc vertical solutions to collect data and manage devices that direct link the corresponding IoT set to its specific component in the core architecture. Merging current and incoming IoT deployments, the reference zone will experiment a SynchroniCity powered architecture leveraging components in order to capture and manage context data and adapt it to standard NGSI data models.

Figure 46 The WSO2 platform

Data from existing sources will be adapted to fit SynchroniCity harmonized data models. Context information will be collected in the Context Broker that makes them available to the application through the SynchroniCity API.

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

In Figure 47 you can see the adaptation the NGSI adapter perform starting from legacy data in order to obtain a JSON object compliant with the NGSI information model and the air quality observation harmonized data model.

Figure 47 NGSI Adapter

3.6.2 High level theme and service domains Milano RZ IoT services, from the point of view of SynchroniCity project, are oriented to provide consumers with data captured by its IoT edge in the Smart City domains and deployed in the city and from third party providers. In this sense, Milano IoT Deployment needs to align its capturing data with current SynchroniCity data models, based on NGSI meta-model, and so, according to the described architecture, these datasets will be offered through an NGSIv2 RESTful API, implemented by its owned instance of the WSO2 Message Broker component. The final Milano’s RZ dataset will be expanded as the SynchroniCity project progresses, while the RZ adapts the existing and incoming data sources to the agreed Synchronicity data models and implements the corresponding adaptors. Currently, the already available datasets include:

● Open Data portal

● E015 platform data (for internal use involved into “Human-Centric traffic management” and “Multimodal transportation” application themes)

● Parking lots status (from May 2018)

● Free floating Bike sharing System

● Station based bike sharing

● Environmental Monitoring

● Metro and bus system availability and status (for internal use involved into “Multimodal transportation” application theme)

3.6.3 City infrastructure and technical elements The Municipality of Milano is involved into several European projects beyond SynchroniCity (SharingCities, Eugugle, OrganiCity, etc.). The most advanced one is Sharing Cities which

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

aims to demonstrate the significant benefits of smart city concepts and solutions by focusing on the needs of low-energy neighborhoods: retrofitting buildings, installing integrated energy management systems and smart lamp posts, and introducing shared-use electric vehicle.

Sharing Cities project is focused on a specific area of Milano’s territory that coincides with the same RZ of SynchroniCity. Among of the benefit given by Sharing Cities that can be exploited by SynchroniCity there are the installation in the RZ of weather sensors and the integration of Message Broker inside the WSO2 interoperability platform of the Municipality of Milano.

Parking Sensor The Municipality of Milan has a plan to install a within May 2018 a set of parking sensors especially dedicated to disabled people. Each sensor will report information about its position and status (free/occupied).

Traffic Loops During the years the Municipality installed more than 900 traffic loops, immersed in the asphalt, spread all around the city. Each sensor is able to register vehicle speed and length.

Figure 48 Map of traffic loops

Due to continuous works on roads, some of sensors are inadvertently removed or partially damaged, thus not always all the 900 sensors are properly working. Furthermore, data coming from traffic loops sensors are gather into an parallel close platform that do not communicate with the Interoperability WSO2 platform of the Municipality so that data will not be available for the SynchroniCity Open Call.

Notice Figure 48 Map of traffic loops highlighting how Milano RZ is a portion of Milano whole territory.

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Station Based Bike Sharing The local transport company (ATM) provides the citizens of Milan RZ with 3650 traditional bikes and 1000 pedal assisted bikes. Bikes can be rented through a mobile app from a number of stations (Figure 49) spread all around the city. To finish the rental the citizen must leave the bike in one of the station in the city.

Figure 49 Station based bike sharing

The information provided is about the number of bikes available in each station and their type (traditional or pedal assisted), and the maximum capacity of each station.

Free Floating Bike Sharing Mobike provides 8000 bicycles to the citizens of Milan RZ while instead Ofo provides 4000 bicycles to the citizens of Milan (bicycles shown in Figure 50). Both the companies started their service from October 2017.

Citizens can pick an available bike in any point of the city by means of a mobile app and can leave the bike everywhere in the city when they decide to finish the rental.

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Figure 50 Mobike (orange) and Ofo (yellow) bicycles

The agreement between Mobike and Ofo with the Municipality is to provide 2 different sets of information thru API in JSON format:

● Offline data: ○ Rentals: number, starting and ending time, starting and ending position,

rental duration, rental path length; ● Real-time data:

○ Bikes availability and position

Metro-bus Information Nodes Bus and metro information, including station information, are provided by the local transport company ATM. Figure 51 shows pictures from the lines.

Figure 51 Bus and Metro

Since the data model provided thru the API on the E015 platform are given in non-compliant NGSI data model they must be converted by the NGSI adaptors. In any case in order to provide valuable information for the use case in which Milan RZ is involved, the data provided

● metroLine entity: a metro line in which there are metro stops (mandatory) and metro-train (optional). Line status information are also provided;

● metroStop entity: a metro stop which belongs to a metro line and in which buses can run. Facilities for disabled people information are also provided;

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

● metroEstimation entity: estimation of arrivals of metro train in relation to a combination of metroStop-metroLine.

● busLine entity: a bus line in which there are bus stops (mandatory) and buses (optional).

● busStop entity: a bus stop which belongs to a bus line and in which buses can run. Facilities for disabled people information are also provided;

● busEstimation entity: estimation of arrivals of buses in relation to a combination of busStop-busLine.

Environmental Monitoring Devices The local energy company A2A installed 8 environmental sensors connected to the Sharing Cities EU project providing in JSON format information about humidity, pressure and temperature every 5 minutes.

Reference Zone Framework Milano RZ is based on a WSO2 platform integrated with a CKAN Open Data Portal as depicted in Figure 52.

Figure 52 CKAN and WSO2 integration

3.7 RZ Porto (PT) This section aims to describe and summarize the reference architecture, system and components, application and services, data sets and infrastructure related to the Porto RZ that will support the SynchroniCity use cases deployment and the Open Call developments.

Figure 53 represents the Porto RZ requirements (minimal set of available infrastructures/services) related to the application themes “Multimodal Transportation” and the “Community Policy Suite” described in the deliverable D3.1 – Documentation of service designs [3].

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Figure 53 Porto - minimal set of available infrastructures/services

3.7.1 RZ legacy system overview The Porto legacy system includes data from different IoT projects, managed by different entities within the municipality. Some of the data is directly fed to the platform using the southbound interfaces made available. In other cases, custom connectors were built in order to fetch this data and send it to the platform, after standardizing it.

The data made available corresponds to different city verticals, namely traffic management, environmental monitoring, public transportation, touristic events and Points of Interest data.

Through an environmental sensor network (ESN) made of sensing stations easily installable in the current urban infrastructure, it is possible to draw indicators on meteorological parameters (solar radiation, UV radiation, wind direction, wind speed, rainfall, air pressure,

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

air temperature, air relative humidity), air pollutants (PM2.5 and PM10 particles, ozone, nitrogen dioxide and carbon monoxide) and noise.

The system can therefore respond more effectively to the problems of its citizens, improve urban planning and obtain objective data on the quality of life provided. In conjunction with other city indicators, the ESN is a decision support tool to improve the city’s communication with citizens and to better inform the policy making in the areas of environment, mobility and urbanism.

Regarding traffic monitoring devices and data, there are more than 100 inductive loops spread throughout the city of Porto, placed in road intersections. These inductive loops are installed in the pavement and are able to detect passing vehicles. This allows for the proprietary system to collect traffic intensity data (vehicle counts). A custom application was built to extract data from this system and share it to the Porto’s FIWARE infrastructure (Urban Platform). Furthermore, data from some of the municipality’s vehicles, such as waste collectors and service vehicles is being collected from a proprietary API, which is being pulled in regular time intervals, and sent to the existing Urban Platform.

Regarding the public transportation data, Porto’s public transport companies (buses, metro/tram and trains) will be integrated in the platform, including information about schedules and real-time vehicle’s position. Furthermore, it is expected that there will be bicycles available through a bike-sharing solution with a GPS location based locking device. The bicycles can be unlocked by card or by a mobile device, upon registration; and only allows locking or unlocking a bicycle in defined areas. Data related to the bicycles, their docking stations locations and occupancy status will be shared to the platform.

As described in the next section, the data referenced above is made available through the FIWARE Orion Context Broker and the Comet Short Time Historic API, using the standard data models made available by FIWARE (where applicable).

3.7.2 High level theme and service domains Porto will be participating in the Multimodal Transportation and the Community Policy Suite application themes. For these, the following datasets will be made available through the Synchronicity platform:

• Environmental monitoring;

• Traffic intensity;

• Vehicle monitoring;

• Public transportation;

• Bike sharing;

• Points of Interest and events.

Below, we detail the data models used for each of the above datasets. Most of the data models follow the FIWARE data model specification. However, in some particular cases, there were no available data models in the FIWARE catalogue that matched the requirements. In these cases, other data models were proposed, conforming to the FIWARE data models specification guidelines. Environmental monitoring

• AirQualityObserved (FIWARE), for air pollutants;

• WeatherObserved (FIWARE) for meteorological parameters;

• NoiseLevelObserved (FIWARE) for noise.

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Bike Sharing • BikeHireDockingStation FIWARE), for data regarding the docking stations where a

user can rent a bike.

Traffic • TrafficFlowObserved (FIWARE), for intensity (vehicle counts) data.

Vehicle • Vehicle (FIWARE), used to represent specific vehicles belonging to the municipality.

POIs and events • PointOfInterest (FIWARE), representing any relevant point in the city which might

be of interest to inhabitants, visitants or tourists;

• Event, as specified in link46.

3.7.3 City infrastructure and technical elements The city of Porto pioneered the idea of a living lab, fostering a wide range of projects emerged from the University and R&D institutions, not only the ones on the municipality, but also from the surrounding cities. Porto has also been focusing on the development of a consistent infrastructure to promote data driven decision making and effective governance support. This is supported by the city’s IoT infrastructure, which includes the following:

• Environmental sensor network (ESN): noise, meteorological parameters and air quality sensing stations (±30 units);

• Beacons: active (BLE, ±1.000 units) and passive (NFC, ±1.000 units);

• Traffic monitoring: vehicle counters (±120 units)

Air Quality, Weather and Noise Sensors Among the different air quality indicators, measured by the sensors embedded in each sensing station(shown in Figure 54) that can be possible targets for data collection and creation of metrics associated through client-oriented reports, information related to atmospheric pressure, air humidity and temperature, UV and solar radiation, rainfall and wind (speed and direction) and noise pollution. Additionally, indicators focused on air pollution such as the levels of CO, NO2, O3 and particles (PM2.5 and PM10) can be collected. Furthermore, dedicated sensors are used for collecting data regarding noise levels.

46 http://schema.org/Event

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

(a) (b) (c)

Figure 54 Sensing stations: noise (a), meteorological (b) and air pollutants (c)

Beacons Proximity Beacons shown in Figure 55 have a built-in NFC tag, which enables apps to trigger beacon events not only on proximity, but also on the very explicit gesture of touching a beacon. These will be attached to fixed points in urban furniture, to provide apps with location context (nearby points of interest).

(a) BLE (b) NFC

Figure 55 Proximity Beacons: active, BLE (a) and passive, NFC (b)

These will be enclosed on a shell case to be better suited both physically and visually with the urban furniture.

Traffic Monitoring A vehicle counter (shown in Figure 56) based on induction loops comprises a square of wire embedded into or under the road, connected to a device at the roadside. The loop utilizes the principle that a magnetic field introduced near an electrical conductor causes an electrical current to be induced. When a vehicle passes over, it acts as the magnetic field, and the inductive loop as the electrical conductor. The roadside device picks the variation and records it.

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Figure 56 Vehicle counter

The FIWARE instances receive update every 5 minutes, allowing us to detect sudden traffic change (representing a possible traffic event like a car crash), which streets have more traffic, the flow through the day, etc.

Reference zone framework Although Porto has long been used as a living lab for IoT related projects, it is currently reworking its platform, having SynchroniCity not only as a booster for the process, but also as a reference. The Figure 57 depicts the overall approach to the architecture framework. Reading from bottom up, supporting the architecture are the data sources (in yellow): the sensing infrastructure and data gathering/harvesting from existing data sources (city databases from its departments, public data, etc.). These will feed what we call the “City Urban Platform”(in blue) which comprises the Data Management and Security layers and, of course the bounding to the south and north systems. Regarding the Data Management layer, note that data reaching the Context Broker will be used not only for the above layers, but also (via Cygnus connectors) to feed systems focused on monitoring and data processing. These can later feedback the City Data Sources (to be used by the city managing departments). The information extracted from the data processing systems, will also be available to the above components. Because these systems hold undisclosed information, they will connect to such components via the security layer (in this case via an application firewall). On top, we have the applications, and services supporting those (in green). Rounded boxes refer to software components, trans lucid/dotted boxes make no change to the transacting data, other are hardware our abstract components.

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Figure 57 Porto Reference Zone Framework

3.8 RZ Santander (ES) This section aims to describe and summarize the reference architecture, system and components, application and services, data sets and infrastructure related to the Santander RZ that will support the SynchroniCity use cases deployment and the Open Call developments.

Figure 58 Represents the Santander RZ requirements (minimal set of available infrastructures/services) related to the application theme “Multimodal Transportation” described in the document D3.1 “Documentation of service designs” [3].

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Figure 58 Santander RZ - minimal set of available infrastructures/services

3.8.1 RZ legacy system overview Santander RZ IoT (Internet of Things) facility is based on a real IoT deployment in an urban setting. The core of the facility is located in the city of Santander and surroundings, encompassing IoT deployments in different key areas of the city infrastructure, ranging from public transport, key logistics facilities, public places and buildings, work places and residential areas, thus creating the basis for development of a Smart City. This deployment exhibits the diversity, dynamics and scale that are essential for the evaluation of advanced protocol solutions.

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Figure 59 Devices deployment within the SmartSantander IoT facility

Considering the current Santander city deployments shown in Figure 59 and open IoT innovative initiatives and in parallel with Synchronicity, the Reference Zone ambitions, in terms of IoT services include:

• Environmental monitoring: The current solutions for environment monitoring in urban settings usually rely on a small number of measurements stations placed at fixed locations. Although the accuracy of the measurement equipment in these units is high, their cost effectively excludes large-scale deployment to obtain measurements at finer granularity. With the introduction of IoT technology, it is now possible to deploy a large number of low cost sensors for a fraction of cost of the current technology. These IoT sensors do not provide the same degree of accuracy but using a large number of measurement points and intelligent processing of the measurements it is possible to obtain sufficiently accurate measurements. In the environmental monitoring use case, readings gathered from fixed and mobile sensors are used as the initial indicator of the severity of the environment pollution (air quality, noise levels and luminosity levels) covering large areas. In case where conditions are observed, special alarms are generated by the system. If these observations last for long periods of time in some specific geographical region, then more accurate environment monitoring equipment is deployed. Moreover, in order to comply fully with environmental-monitoring legislation, devices offering a high degree of accuracy are deployed temporarily at the identified pollution hotspots, thereby resulting in the coverage of a broad area at the fraction of the cost.

• Outdoor parking & Management and driver guidance: The outdoor parking management use case implies the development and deployment of a parking space management service in the city of Santander. Essentially, this smart-city service enables monitoring the occupancy of outdoor parking spaces on the streets of the Santander city center for parking-bay usage and accounting. To implement this service, ferromagnetic wireless sensors are buried under the asphalt at each bay. Peer equipment such as repeaters are deployed in an area to guarantee connectivity with the Internet such that parking occupancy information can be disseminated instantaneously to drivers, the relevant traffic control management organizations in the city or local authorities. Further, sensor data from parking bays is aggregated

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

and used to feed parking status information to display panels located at street intersections. These data streams can be subscribed to by mobile phone applications providing, for example, navigation help to free parking spaces. Similarly, historical parking occupancy data can be analyzed by municipal authorities to determine the level of parking provisioning in the city.

• Parks and gardens precision irrigation: The Precision Irrigation use case is aimed at augmenting the automated irrigation systems currently deployed along parks and gardens to evaluate plants’ requirements in water and provide for more precise on-demand irrigation. Automatic irrigation systems in use in city parks and gardens are schedule-based i.e. run preconfigured programs based on timetables irrespective of weather conditions or the water requirements of the vegetation at particular areas. Different species of shrubbery and trees have varying requirements in terms of water consumption, which is also influenced by other factors such as soil humidity. The development of Wireless Sensor Network (WSN) precision irrigation and park monitoring applications makes it easier to increase efficiency and cut down costs. IoT devices spread around the park and gardens enable agricultural data such as air temperature and humidity, soil temperature and moisture, leaf wetness and rainfall to be collected. The real-time information from the sites provides a solid base for park technicians to adjust strategies at any time. Instead of taking decisions based on some uncertain average condition, which may not be even close to reality, or having to be physically present on-site constantly, a precision park irrigation approach recognizes differences and automates management actions accordingly.

• Augmented reality: The augmented reality use case aims at augmenting the city scape or locations in the city with IoT endpoints to provide context-sensitive information and services at these locations. This initially involves augmenting Points Of Interest (POI) in the city, for example touristic sites, shops and public spaces with Near-field communication (NFC) tags. These tags are used to expose services or information relevant to the location/context to site-visitors. As an example of this service usage, the site-visitor’s mobile-phone display can be overlaid with relevant services or tourist-targeted information, depending on their location or direction of vision. For instance, the augmented reality use case provides tourists with a ‘‘stroll in the city’’ experience by supplying them with location-sensitive information such as description of monuments in their preferred language. Whilst NFC tags have been deployed at the various POIs in the city, we are currently envisaging a commercial exploitation of this platform capability that involves augmenting shops with NFC tags as a means for advertising sales opportunities to customers. This will provide shops with new opportunities to build and strengthen customer relationships. There are several potential windfall applications that can exploit the data collected from this platform capability. Location information and visitor frequency can be used to gauge the popularity of sites and to adjust visitor-management strategies accordingly. Tags can be coupled with more advanced services such as ‘‘feedback’’ from the citizens to the city council.

• Participatory sensing: In this scenario, mobile phones are used as sensors, feeding sensed physical data such as GPS (Global Positioning System) coordinates, direction (compass) and environmental data such as noise or temperature to the SmartSantander platform. Users can also subscribe to services such as ‘‘the pace of the city’’, where they can get alerts for specific types of events currently occurring in the city. Users also can report the occurrence of such events, which will subsequently be propagated to other users that are subscribed to the respective type of events.

• Resilient IoT: Most of the IoT infrastructure so far deployed in the cities it does not guarantee that information reaches destination entities with the requirements imposed by some critical services. As such it is important to conceive a second

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

generation IoT infrastructure and supported services aiming at guaranteeing specific quality of service attributes such latency, resilience against failures, etc.

Santander RZ offers its data catalogue mainly through two ways:

• FIWARE: The SmartSantander testbed offers a fully-fledged integration with the FIWARE platform. The way to achieve this compatibility is done by means of the injection of all the data gathered from the IoT sensors into the FIWARE servers (i.e. an instance of the ORION Context Broker). To do so, several NGSI adaptors plus customizations of IoT Agents (e.g. UL2.0 IoT Agent) have been designed and integrated within the SmartSantander testbed. This way, Santander offers real-time data from IoT nodes via NGSI-9/10 interfaces. Adopting these that are going to facilitate other cities in federation is a valid approach given that the technology solutions meet the most basic interoperability requirements. As a result of this exercise of integration, data generated by SmartSantander IoT resources are directly sent to an instance of the FIWARE platform, providing external users (either hardware/software experimenters or service developers) standardized access to manage the information generated by the SmartSantander facility, which includes both sensor deployment and applications used by the citizens.

• Open Data: Santander City Council provides, to the end user, a set of data that can be accessed through the Santander Open Data portal. Its data catalogue consists of several data types that allow any con person or organization to build upon them a new idea that generates new data, knowledge, process improvement, added value to existing data or to create new services, and includes data coming from SmartSantander IoT infrastructures plus additional datasets coming from external providers and managed by the municipality. The portal also offers tools to facilitate the search for information and make a rating of each data set based on its quality. Another interesting aspect of this website is the “Demonstrator data”, which presents graphically some of the most interesting resources available in the Data Catalogue. This can be used as a model or a suggestion of use to potential users for applications development. The data catalogue of Santander Open Data is managed by a CKAN system instance. Even all the documentation of the CKAN API REST is available, Santander City council provides a basic guide to facilitate the data access to the developers.

Santander RZ will use NGSI specifications as Northbound and southbound API interfaces to manage context information, according SynchroniCity reference framework implementation. Santander RZ will provide its own instance of the FIWARE Orion CB, to be later federated with SynchroniCity platform.

Security Framework will be also based on Oauth2.0 protocol. Santander gets its own instance of the classic FIWARE security set, including KeyRock IdM, Wilma PEP proxy and AuthZForce PDP, and these are planned to be integrated with SynchroniCity platform in the way the project indicates.

Santander SynchroniCity Instance will also support FIWARE Cygnus connector for long term historical data plus short term historical Comet FIWARE component. This way, Santander RZ plans to be aligned with the SynchroniCity historical data management.

Santander RZ IoT infrastructure relies on SmartSantander experimentation facility [47] that supports most of the IoT experiments, deployments and IoT EU initiatives, whilst puts together all the Santander IoT nodes sets, creating our IoT edge.

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Figure 60 Santander high level component architecture

As depicted Figure 60, in SmartSantander is realized by a three-tiered network architecture, which consists of an loT device tier, a gateway (GW) tier and server tier.

The loT node tier provides the necessary experimentation substrate consisting of loT devices. As loT experimentation is the primary focus for SmartSantander, the loT node tier accounts for the majority of the devices utilized in the testbed infrastructure. In order to satisfy the expected heterogeneity the loT node tier consists of a variety of loT device types, such as diverse mote platforms, RFID readers and tags as well as more powerful platforms such as mobile phones with short range communication capabilities.

The gateway node tier links the loT devices at the edges of the network to a core network infrastructure. The nodes of the GW tier are also part of the programmable experimentation substrate, in order to allow experimentation for different interworking and integration solutions of loT devices with the network elements of a current or FI.

The server tier provides more powerful server devices, with high availability, which is directly connected to the core network infrastructure. External users access the platform through these servers.

The architecture distinguished between four subsystems:

• Authentication, Authorization and Accounting (AAA)

• Testbed Management

• Experimental Support and

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

• Application Support.

The Authentication, Authorization and Accounting (AAA) subsystem is common for all user groups and controls the access to the testbed functions. Its services are exposed via the Access Control Interface (ACI). Depending on user privileges the other subsystem functions can be invoked. The management support interface (MSI) exposes the service functions of the management subsystem and is typically used by the system administrators of a testbed deployment. It provides access to functions such as user accounts, testbed resource discovery and configuration as well monitoring and fault management. The experimental support interface (ESI) is mainly used by the experimental researcher and provides access to the service functions of the Experimentation Support Subsystem which assist the user in the entire experimentation life-cycle. This includes functions for testbed resource selection, specification of experiments including resource configurations, reservation of testbed resources, scheduling of experiments as well as functions for the deployment and execution control of experiments and data collection and data analysis. The application support interface (ASI) offers a wide range of data management functions that can operate on information retrieved from the deployed sensors of the loT node tier including citizen provided information through participatory sensing on mobile phones.

3.8.2 High level theme and service domains Santander RZ IoT services, from the point of view of SynchroniCity project, are oriented to provide consumers with data captured by its IoT edge in the Smart City domains deployed in the city. In this sense, Santander IoT Deployment is aligning its capturing data with current FIWARE data models [8], based on OMA [28] NGSI meta-model, and so, according to the described architecture, these datasets will be offered through an NGSIv2 RESTful API [48], implemented by its owned instance of the Orion Context Broker component. The final Santander’s RZ dataset will be expanded as the SynchroniCity project progresses, while the RZ adapts the existing and incoming data sources to the agreed Synchronicity data models and implements the corresponding adaptors. Currently, the already available datasets include:

• Environmental monitoring

• Smart Parking

• Traffic monitoring

• Santander Bus Information System (TUS)

• Santander Bike Hiring System (TUSBIC)

Environmental monitoring Data captured is available according FIWARE Environment [49] and Weather [52] data models. Currently, three entities are managed within Santander SynchroniCity infrastructure:

• AirQualityObserved [50]. It represents an observation of air quality conditions at a certain place and time.

• NoiseLevelObserved [51]. It represents an observation of those parameters that estimate noise pressure levels at a certain place and time.

• WeatherObserved [53]. It represents an observation of weather conditions at a certain place and time.

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Smart Parking Data captured related to smart parking use case is available according FIWARE Parking Harmonized Data Models [54]. Currently, three entities are managed within Santander SynchroniCity infrastructure:

• OffStreetParking [55]. An off street parking site with explicit entries and exits.

• OnStreetParking [56]. An on street, free entry (but might be metered) parking zone which contains at least one more adjacent parking spots.

• ParkingSpot [57]. An individual, usually monitored, parking spot.

Traffic monitoring The traffic information to be provided within this use case will be gathered from the traffic sensors deployed in the city of Santander. This information will be modelled following the FIWARE Transportation Harmonized Data Models [58], using the TrafficFlowObserved [59] entity type. This modelling offers the description of a set of attributes related to traffic flow in a city. From this set of attributes some of them have been selected to describe the deployed traffic sensors in Santander: identifier, type, location, dateModified, dateObserved, intensity and occupancy.

Santander Bus Information System (TUS) Since FIWARE does NOT provide a specific data model [8] for this purpose, this use case information is modelled according a general Semantic Modelling for the bus system, based on 3 main entities with their corresponding set of properties/attributes:

• busLine entity: a bus line in which there are bus stops (mandatory) and buses (optional)

• busStop entity: a bus stop which belongs to a bus line and in which buses can run

• Estimation entity: estimation of arrivals of buses in relation to a combination of busStop-busLine.

Notice that the associated Bus data model will be described and specified in a document data model specification in the context of the WP2 - Task 2.2 activities.

Santander Bike Hiring System (TUSBIC) The current status of each Bike hiring docking station is provided by a set of devices installed on each of the 15 docking stations deployed within the city. This information is modelled following the FIWARE Transportation Harmonized Data Models [58], using the BikeHireDockingStation [60] entity type. This modelling offers the description of a set of attributes related to its location and current status, e.g. the number of available bikes for hiring or the number of free docks to return the bikes.

3.8.3 City infrastructure and technical elements EU SmartSantander project enabled a wide variety of research lines, thus making the city an urban laboratory and fostering the continuous evolution of its Smart City dimension towards the improvement of the quality of municipality services and the realignment of the productive model around technology and knowledge. In this sense, Santander RZ, starting from its SmartSantander IoT project, provides a twofold exploitation opportunity. On the one hand, the research community gets benefit from deploying such a unique infrastructure which allows true field experiments. Researchers will be allowed to reserve the required

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

resources within the whole network and for a determined time period in order to run their experiments. On the other hand, different services fitting citizens’ requirements will be deployed. In numbers, the Santander RZ infrastructure is composed by:

• Capillary network (802.15.4 based plus LoRa technology in deployment) covering wide area of the city:

o 12,000 IoT diverse and heterogeneous devices

o About 3,000 IEEE 802.15.4 devices.

o 200 GPRS modules.

o 2,000 RFID tags/QR codes deployed.

• Type and Volume of Data:

o 139,370 environmental monitoring observations per day

o 8,365 irrigation monitoring observations per day

o 82,726 mobile environmental monitoring observations per day

o 13,489 parking occupancy observations per day

o 54,720 traffic management observations per day

o 6,352 participatory sensing observations per day

• Number of Researchers:

o 30+ experiments

o 100+ experimenters

Santander Reference Zone integrates assets deployed as part of the SmartSantander and also datasets published in “Santander Open Portal” (“Datos Abiertos Santander” [61]) under CKAN (Comprehensive Knowledge Archive Network) catalogue system. To this end, according OASC (Open & Agile Smart Cities) principles and SynchroniCity objectives, information of the different data assets will be integrated within a single local IoT core based on FIWARE architecture. This FIWARE core will be part of the SynchroniCity Santander framework implementation.

At the bottom level, the IoT edge will inject data into the Santander FIWARE core using NGSI interfaces. Sensors deployed within the SmartSantander IoT facility send the information to the SmartSantander platform, where specific connectors link to the FIWARE UltraLight 2.0 IoT Agent to feed data to the FIWARE core. For other data sources (e.g. Municipality CKAN data) designed procedures consume and convert data sets into NGSI context data and integrate those using NGSI primitives, therefore achieving a unified format.

Within the Santander RZ’s IoT platform, context information is managed according NGSI standards and FIWARE NGSIv2 data models. Publish/Subscribe, assets and context discovery or query/update data functionalities are supported by the core platform. To create historical data, the FIWARE Cygnus and STH (Short Term Historic) components are used. This way, Santander RZ will use NGSIv2 as Northbound and southbound API interfaces, provided by the SAN instance of FIWARE Orion CB. NGSI9 and NGSI10 will be also supported.

Environmental monitoring devices The city of Santander is trying to carry out an effective policy for environmental management through the signing of agreements that aid improvements in air quality and quality of life for its citizens. Key elements in undertaking this task are:

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

• Monitoring of pollutants

• Noise and temperature measurement

With the aim to develop this environmental monitoring policy, temperature, CO index, noise and luminosity sensors have been installed in street lamps and facades. All these devices send their information, in a multi-hop fashion (if needed), to the corresponding gateway that gathers all the received information making it available to the Santander backbone. Figure 61 and Figure 62 shows several examples of the installation of these devices, at different streetlamps and facades of the city:

Figure 61 Examples of repeaters installation

More than 1,000 of these fixed nodes have been installed at the Santander city center. To extend this Environmental Monitoring service based on fixed infrastructure to other areas of the city is costly. Hence, instead of continuing with fixed deployment all over the city, the hardware was installed on municipal public buses, parks and gardens vehicles and taxis. This way a much wider area is covered on a much more efficient way. Mobile nodes send the collected information to the internet/intranet and interact with the corresponding static nodes placed at streetlamps and facades.

Figure 62 Mobile environmental monitoring sensors parking sensors (Smart Parking Use Case)

Numerous parking sensors(shown in Figure 63) have been deployed in the downtown city to indicate the parking spots that are available or occupied. To detect the occupancy state of a determined parking spot, ferromagnetic sensors buried under the asphalt have been installed, thus sending the corresponding information (free or occupied) associated to a determined parking space. This information is forwarded to the central device (gateway), through the corresponding repeaters (a set of the repeaters installed for environmental

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

monitoring).

Figure 63 Examples of parking sensors installation

To be more precise, 350 parking sensors those have been installed within the “30 Zone”, to inform the occupancy degree of determined parking lots. Currently, new parking sensors are being deployed as part of the new LoRa network infrastructure, which will complement the existing service.

Traffic Intensity sensors Nowadays, the measure and classification of vehicles in road traffic is accomplished by inductive loops(shown in Figure 64) placed under the pavement. These inductive loops allow monitoring vehicle flows, providing several parameters of the traffic, e.g. vehicle speed, traffic congestion and traffic accidents.

Figure 64 Traffic sensors installation in the main roads of the city

However, these systems have several problems and disadvantages like their deployment, maintenance, high cost, and put into gear, among others. In this sense, within the SmartSantander project a solution based on Wireless Sensor Network was deployed, monitoring parameters such as cars speed, occupancy and count in the road lanes in the two main entrances of the city.

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Bus Information nodes The Bus Information System aims to provide bus information data to end users in real-time. This includes information about buses, bus stops, bus lines, and real-time data on current bus locations and arrival estimations to bus stops. Information is captured and provided by mobile nodes (shown in Figure 65) installed in Santander public buses.

Figure 65 Mobile node installed on a public bus

Bike Hiring docking stations Santander RZ provides with real time information of bike renting (TUSBIC) stations (shown in Figure 66). Every time a resource is previewed, a query of that station is sent to the Santander IoT platform in order to get the last updated information. It will retrieve real time information about the station, for instance the number of available bicycles which there are at the station in that moment. Bike hiring docking stations information is offered to the Santander Open Data Portal by the company managing these infrastructures.

Figure 66 Santander city’s bike hiring docking station

Reference zone framework Santander’s city IoT framework is evolving according IoT technologies and architectures do. Its first IoT network and sensors deployments were based on IEEE 802.15.4 [62] mesh network (SmartSantander [63]), setting the basis for a growing heterogeneous FIWARE

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

aligned architecture. In this sense, Santander RZ manages its own instances of the FIWARE enablers required to expose IoT data according NGSI interfaces which Figure 67 provides overall approach to the Santander’s RZ architecture.

Figure 67 Santander RZ framework

The IoT Edge comprises all the heterogeneous sensors deployed in Santander, plus the IoT communication protocols and networks. Santander’s IoT edge comes directly from the SmartSantander IoT project and provides the city with a wide WSN based in 802.15.4 that covers the main part of the city, complemented by Wi-Fi, Ethernet and 3G gateways, and 2G/2G3G nodes. This infrastructure provides access to the Santander’s backbone network and introduces mobile sensing nodes that considerably expand its sensing capabilities. A new LoRa network [64] it’s being currently deployed, managed by the University of Cantabria, to support new IoT devices deployments. This Santander’s IoT Edge directly feeds data to the Santander Open Data Portal and the SmartSantander City Services, as well as to the Santander’s FIWARE based backbone to be used as its SynchroniCity reference framework implementation.

The Data Management core corresponds to an own-managed instance of the Orion Context Broker [66]. This component will distribute (Publish/Subscribe messaging system) and manage the context information uploaded by the SmartSantander IoT Edge. The Orion CB implements and NGSIv2 [67] interface, both, to gather context (southbound) and to provide context (northbound), according the agreed Synchronicity NGSI-based data models, defined and adapted following FIWARE Foundation guidelines. Specific NGSI adaptors, designed and developed by the University of Cantabria, to import the SmartSantander IoT

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

edge data (plus other external info sources managed by the municipality and third parties) and an instance of the FIWARE Backend Device Management IDAS (Intelligence Data Advanced Solution) [68] (currently, only UltraLight2.0 IoT Agent has been used in some SmartSantander pilots) compose the southbound layer.

The Context Broker is complemented by two FIWARE components to manage historical data. The Short Term Historic Comet [69] and the Cygnus Connector [70], both included in the SynchroniCity reference framework implementation. These two components are currently being tested within Santander IoT architecture, as part of pilots, but not in production environment yet. Anyhow, they will be linked to SynchroniCity architecture implementation, according the project’s guidelines.

Santander’s RZ FIWARE security framework instantiates the classical FIWARE approach: PEP Wilma proxy [71], its Identity Manager KeyRock [72] and the Authorization PDP AuthZForce [73]. These three components together identify the data consumer and protect the data access University of Cantabria manages its customized instance of this enablers set, as part of other EU initiatives and is ready to integrate a specific security framework aligned with Synchronicity requirements as soon as these are provided by the Synchronicity’s security workgroup.

The Santander’s RZ current Services & Applications layer contains a wide set of citizen-centered applications to update end users with latest info about public transport, city events or traffic status (apps can be found in google play and apple store). It also contains small scale pilots and proof of concepts running within several IoT projects and EU initiatives. Information gathered from environmental sensors, waste containers, waste trucks or public vehicles feed also municipality tools to manage park and gardens or waste collection services. The Santander Open Data portal [61] offers third parties an access to different data sets to exploit or develop new apps based on city collected data.

3.9 Non-RZ Seongnam (KR) In Korea, there are other cities (e.g. Busan, Goyang) which have involved in open standard solutions based on the pilot projects with large scale testbeds. In case of Seongnam, SynchroniCity Korean partners based in the city are deploying new IoT standard (i.e. oneM2M) enabled testbed since 2018. Therefore, compared with other RZs in the project, existing smart city infrastructure and services are small at the moment. However, it is expected to be getting larger and richer in terms of testbed and services until 2020.

3.9.1 Non-RZ legacy system overview Not as the city-scale or in city area yet, the legacy system in Seongnam is KETI headquarter premises as a testbed. OneM2M platform is up and running, gathering parking occupancy data and building environment sensor data.

3.9.2 High level theme and service domains Seongnam will offer the services to the citizens in the theme of multimodal transportation. The smart parking service for commuters is being prepared. One of the scenarios is to recommend a parking lot for transit when the parking availability gets lower quickly in the morning. The following data sets will be used:

• Parking occupancy from 3 off street parking lots (real-time)

• Long-distance bus schedule (static)

• City bus schedule (static) and bus location (real-time)

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

• Metro line (static) and estimated arrival at the station (real-time)

3.9.3 City infrastructure and technical elements Commuters parking service will be offered by covering three public off street parking lots (shown in Figure 68 Public parking lots near Yatap station in Seongnam) near Yatap metro station. Seongnam is located next to Seoul, the capital city of South Korea, there are lots of commuters who park their car near the station and transfer into metro or buses. In the area, there is one metro line, many city bus lines passing by and even the long-distance bus terminal that connects to major cities in entire country. Two parking lots and transfer parking lots, KETI will deploy sensors per spot (estimated to be completed in July 2018) and the other one already has parking sensors.

Figure 68 Public parking lots near Yatap station in Seongnam

In the off street parking lots (shown in Figure 69), parking sensors are attached on rails from ceiling and they emit indicator lights showing parking availability in green and red.

Figure 69 Off Street parking sensor deployment example

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

4 Integration and deployment process This integration guide is for the cities’ party integrators and developers who want to interact and exchange data with the SynchroniCity platform and the application providers who will develop client application in the context of the SynchroniCity project based on the selected services. This is also to give a reference guideline on how to integrate external applications using the SynchroniCity platform interfaces associated to the Southbound and Northbound layer and the corresponding interfaces based essentially on web services REST API.

This guide does not cover the installation or configuration of any client application or client components (at city and application provider side) eventually required by the application providers to interact with the SynchroniCity platform.

An interface is a specification which defines essentially operations and data, implemented by software that sends and receives properly formatted information from one application to another.

SynchroniCity exposes a set of services as separate interfaces that process different types of operations and data related to the corresponding set of services (context management, data management). For example, the interface related to context management services supports the registry of entities, publish and subscribe, and CRUD services related to these entities and corresponding data.

In order to integrate client applications there is no need to include or import libraries or modules as the interaction is based on the intercommunication and exchange of data using the standard network protocol following the TLS/SSL protocols and NGSI specification

The integration process from a point of view of an application provider is to develop a client application or client service which is able to call the SynchroniCity services securely using the standard HTTPS protocol.

Loosely coupled intermediate layer at city legacy system side, to adapt / transform legacy data model to SynchroniCity data model based on NSGI protocol.

Full description and detailed specification for the NGSI protocol can be found via the link to the online specification47.

Generally, the developers of the client side must use a module, library or framework which allows building and sending HTTP request and receiving the responses. At application development level this framework depends on the languages and development environment used to program the client application.

Next chapters describe the integration and the adaptation activities needed to be carried out by each RZ in order to have a functioning SynchroniCity platform which is built on top of reference architecture components defined in D2.1 [2].

4.1 RZ Antwerp (BE) The IoT Gateway is a component that provides the connection and the data inflow of different types of sensors. The data from different sensors enters this platform where it is then processed into structured data by the adapters. The structured data is then stored in a central location and forwarded to users who have created a subscription.

The transformation process from raw data into the final NGSI data model is done in 2 steps:

● Step 1 - Transform raw data into IoT Gateway data model

47 http://www.openmobilealliance.org/release/NGSI/V1_0-20120529-A/OMA-RD-NGSI-V1_0-20120529-A.pdf

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

The raw message is stored in the Message table. The system reads the messages and searches for the corresponding device based on the Device ID and the Connection or Device type. Some message types transmit the data in an encrypted way.

This data is translated by an external decoder that can be set per Device Subtype. The system then processes the raw messages into readable data and divides them into 4 groups:

• Alarm: alarms and errors • Config: configuration of the device • Status: metadata • Parameter: actual measured values

● Step 2 - Transform IoT Gateway data model into NGSI data model

Specific NGSI adapters convert the converted data coming from the IoT Gateway into the NGSI format required by the SynchroniCity platform.

In order to provide NGSI support, as Synchronicity requirement, Antwerp RZ will implement its own instance of the FIWARE Orion Context Broker. This instance is currently under construction

Antwerp RZ publishes its datasets according the agreed FIWARE data models.

The Security Framework of the Antwerp RZ will be integrated within SynchroniCity Security Framework according Synchronicity security workgroup guidelines.

For Historical data management, Antwerp RZ will precede according Synchronicity architecture requirements, in order to integrate with Synchronicity Historical Data approach.

Antwerp RZ tends to use the best technology for a specific need. This leads to a complex integration of different type of technologies, each with their own specific method of deployment, e.g. a Kafka cluster, Kubernetes for our microservices, NGINX and Kong-based gateways and several different types of Data Storage technologies. To manage this from an overall perspective we use the Tengu automation platform for IMEC site. This platform is developed at IMEC and is designed to automate deployment, configuration and integration from the ground up. It also abstracts the infrastructural requirements, i.e. it can use public cloud resources (GCE, AWS, Azure) or private clouds (OpenStack, VMware) as easily as bare metal servers. The deployment of Antwerp’s RZ platform uses VMware instance. Within VMware, and on top of Kubernetes, our microservices are then running within Docker containers.

4.2 RZ Manchester (UK) In order to provide NGSI support, as Synchronicity requirement, Manchester RZ will implement its own instance of the FIWARE Orion Context Broker. We are currently testing this using the generic Synchronicity framework but are in the process of hosting our version within Manchester.

As Manchester data is not currently in FIWARE standards we will identify a list of core datasets from the Manchester platforms including all live data; Digital catapult will provide the conversion scripting from the Manchester BT data hub to FIWARE data models. Where these aren’t available, we will follow common practice around common data fields.

Security and historical data will be in line with the Synchronicity framework once the Manchester local install is in place.

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

4.3 RZ Carouge (CH) In order to provide the required NGSIv2 support, the reference zone of Carouge has deployed its own instance of the FIWARE Orion Context Broker. This instance is currently up and running, offering the complete NGSIv2 interface defined by FIWARE.

For the historical data, the smart city of Carouge will follow the API defined by the SynchroniCity architecture requirements. STH Comet with a MongoDB database is actually used in conjunction with the Orion Context Broker and the Cygnus component.

The reference zone of Carouge has one server per provider (IEM, OrbiWise, TPG, etc.). A server with several virtual machines is used to retrieve the data and to push it to the FIWARE components. So there is one virtual machine for UDG, one for Orion context broker and Cygnus, one for MongoDB and Comet STH and finally, one for the CKAN server. More information is available in the D2.6.

4.4 RZ Eindhoven (NL) In order to provide NGSI support, as Synchronicity requirement, Eindhoven RZ will implement its own instance of the FIWARE Orion Context Broker. This instance will be up and running, offering the complete NGSIv2 interface published by FIWARE in a short period of time.

Eindhoven RZ publishes its datasets according agreed FIWARE data models.

To be compliant with OAuth protocol, Eindhoven RZ will make use of the FIWARE classic security approach, based on instances of KeyRock Identity Manager, Wilma PEP proxy and AuthZForce FIWARE Enablers. These will be integrated within SynchroniCity Security Framework according Synchronicity security workgroup guidelines

For Historical data management, Eindhoven RZ will precede according Synchronicity architecture requirements, in order to integrate with Synchronicity Historical Data approach.

ATOS NL is working on an OpenStack environment for the Eindhoven reference zone which will act as the main cloud container for the whole platform and VMs that will serve the nodes of the reference architecture. The initial plan is to have 2 VMs to install the SynchroniCity components. Docker is the primary virtualization technology that is supporting the deployment activities in Eindhoven RZ.

4.5 RZ Helsinki (FI) Synchronicity platform is currently running and accepting requests48. Orion is found at the URL49, where it offers NGSIv2 interface. Making HTTP requests is accurately described above.

In order to provide NGSI support, as Synchronicity requirement, Helsinki RZ deploys its own instance of the FIWARE Orion Context Broker. This instance is currently up and running, offering the complete NGSIv2 interface published by FIWARE.

Helsinki RZ publishes its datasets according agreed FIWARE data models.

To be compliant with OAuth protocol, Helsinki RZ will make use of the FIWARE classic security approach, based on instances of KeyRock Identity Manager, Wilma PEP proxy and AuthZForce FIWARE Enablers, provided that the architecture or deployment files are provided by ENG. Helsinki RZ has a legacy OAuth service which could be used. These will

48 http://Docker.fvh.fi/ 49 http://Docker.fvh.fi/v2/

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

be integrated within SynchroniCity Security Framework according to Synchronicity security workgroup guidelines.

For Historical data management, Helsinki RZ will precede according Synchronicity architecture requirements, in order to integrate with Synchronicity Historical Data approach. STH Comet and Cygnus are used.

Deployment of the Synchronicity platform in Helsinki is done using Docker Community Edition. Specifically, Docker Compose and the architecture specification provided by ENG are used to instantiate containers for the components and to define their relationships and connections. Physically platform is installed in a dedicated root server at Hetzner (32 GB RAM, 4 CPU cores).

The process to deploy software agents used to consume, transform and publish legacy data is to be developed with the technical subcontractor. These ostensibly should also be deployed as Docker containers.

Currently data is delivered to the broker using custom proof-of-concept level gateway (Django web application), which receives data from sensors via HTTP. Application converts custom data formats to NGSI API v2 format and then sends it to the broker. The Nginx proxy in the front of broker handles basic authentication and allows only POST and PATCH HTTP verbs without correct credentials. In the next stage gateway will be re-implemented with the technical subcontractor and then Dockerized.

4.6 RZ Milano (IT) In order to provide NGSI support, as Synchronicity requirement, Milano RZ needs to re-expose on its APIStore the already existing APIs involved in Synchronicity project into the NGSI format according the agreed Synchronicity data models.

Newly APIs developed following the Synchronicity project will publish datasets according the agreed NGSI data models.

Milano RZ implements the OAuth2 protocol for Authorization based on an instance of the KeyManager module of the WSO2 platform. The Authentication layer will be implemented in the very next future by a WSO2 Identity Manager module.

For Historical data management, since changing data-models already in use for storage could severely impact Municipality processes, on the first step Milano RZ need to create connectors to access to already existing data in order to expose them into NGSI protocols. A data-model changing process can be evaluated after the success of SynchroniCity project and a costs and benefits evaluation.

For newly generated data-models as result of the SynchroniCity project, Milano RZ will proceed to historicize according to SynchroniCity NGSI data model.

In 2017 the Municipality of Milano RZ started a process to define a standard to deploy applications on its legacy systems and platforms that should be completed by the end of 2018.

The deploying process shown in Figure 70 will rely on a technological stack based on Redmine - GitLab - Jenkins - Selenium - SonarQube - JFrog Artifactory products, assisted by WSO2 Enterprise Integrator - Data Service Server and WSO2 Eclipse Studio to create a continuous improvement process in delivering new software as depicted in Figure 70 Deployment process, harmonized with Milano RZ interoperability platform based on WSO2.

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Figure 70 Deployment process

Since the contingency of SynchroniCity project to deploy its platform on RZs legacy system before the start of the Open Call, and the issue represented by the above uncompleted standardization deployment process, Milano RZ according with its technological partner Engineering (ENG) defined a two steps plan of deployment as shown in Figure 71.

The first step, in order to be ready for the Open Call, is to connect Milan RZ legacy system to the Cloud instance of SynchroniCity platform provided by ENG. The RESTful API, carrying out SynchroniCity related data, exposed on Milan RZ WSO2 API Market Store will be addressed via HTTP protocol to the NGSI Adapters of SynchroniCity platform cloud instance to convert data into the proper NGSI format.

Figure 71 Milano Legacy Data Integration

In this scenario the main task is to develop the proper NGSI adapters in order to convert data coming from the Municipality of Milano into the NGSI format required by the SynchroniCity platform.

The second step depicted in Figure 72 is to include the Synchronicity Platform within the boundaries of the Municipality of Milano and integrate it with its WSO2 platform. ENG proposed different hypothesis:

• An instance of the Synchronicity Platform on a dedicated virtual machine provided by ENG. This model is very similar to the interaction with the Cloud SynchroniCity Platform. The virtual machine will not be physically present within the Municipality Servers, and will be maintained by ENG, but it will be fully dedicated to the Municipality of Milano and federated with the SynchroniCity Platforms of the other cities. The RESTful API exposed on Milan RZ WSO2 API Market Store, carrying out SynchroniCity related data, will be addressed via HTTP protocol to the NGSI

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Adapters of SynchroniCity platform cloud instance to convert data into the proper NGSI format. This solution has the advantage not to require extra resources for the Municipality of Milan and no effort in maintenance, though all the Synchronicity generated data will not be inside the city storage.

Figure 72 SynchroniCity platform on a dedicated virtual machine

• A second hypothesis is to deploy a whole package of the SynchroniCity platform on a physical server inside (shown in Figure 73). This case is formally equivalent to the previous one with the difference that the Municipality of Milan must provide the physical resources to install the SynchroniCity platform, considering also a possible duplication of data since most of the current applications running on Municipality’s legacy systems needs their data not in NGSI format.

Figure 73 SynchroniCity platform in a physical server

• A most advanced model is to deploy the platform inside the perimeter of Milano RZ infrastructure federating the WSO2 API Market Store with the SynchroniCity API Market Place, and federating also the Security layer performed by the WSO2 Identity Server component, OAuth2 compliant, of the Milano RZ with the security layer of the SynchroniCity platform (Figure 74). This solution goes toward a more advanced integration between different platforms inside the SynchroniCity project, but requires a deep analysis and a feasibility study about the effort needed to integrate WSO2 modules into the analogous FIWARE modules on which relies the SynchroniCity platform.

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Figure 74 Milano advanced deployment model

4.7 RZ Porto (PT) In order to provide NGSI support, as Synchronicity requirement, Porto implements its own instance of the FIWARE Orion Context Broker. This instance is currently up and running, offering the complete NGSIv2 interface published by FIWARE.

Porto publishes its datasets according to agreed FIWARE data models.

To be compliant with OAuth protocol, Porto will make use of the FIWARE classic security approach, based on instances of KeyCloak Identity Manager, Wilma PEP Proxy and AuthZForce FIWARE Enablers. These will be integrated within SynchroniCity Security Framework according to SynchroniCity’s security workgroup guidelines.

For Historical data management, Porto will precede according to SynchroniCity’s architecture requirements, in order to integrate with SynchroniCity’s Historical Data approach.

Porto decided to install the FIWARE components as containers, using Docker Community Edition.

Once the hosts are delivered by the infrastructure team, a set of Ansible Playbook are executed in order to get a fully configured system to receive and run the containers.

Docker-compose files are used for the installation of the components.

Ansible Playbooks, Docker files, and Docker-compose files are versioned on a GitLab instance.

4.8 RZ Santander (ES) In order to provide NGSI support, as Synchronicity requirement, Santander RZ implements its own instance of the FIWARE Orion Context Broker. This instance is currently up and running, offering the complete NGSIv2 interface published by FIWARE.

Santander RZ publishes its datasets according agreed FIWARE data models.

To be compliant with OAuth protocol, Santander RZ will make use of the FIWARE classic security approach, based on instances of KeyRock Identity Manager, Wilma PEP proxy and AuthZForce FIWARE Enablers. These will be integrated within SynchroniCity Security Framework according Synchronicity security workgroup guidelines

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

For Historical data management, Santander RZ will precede according Synchronicity architecture requirements, in order to integrate with Synchronicity Historical Data approach.

Santander RZ deployment plans converge towards a whole instance, managed by the City, of the SynchroniCity platform, according the reference implementation proposed within WP2 and based on FIWARE components. In this sense:

• Data management. Santander City already deployed an instance of the FIWARE Orion Context Broker that provides NGSI support for both, northbound and southbound interfaces. Santander RZ technical partners are migrating all original SmartSantander datasets on this Orion instance following the data and information models defined within the project and required to support SynchroniCity application areas (mainly Multimodal transportation). Other information sources will be added, as soon as the NGSI injectors will be adapted to SynchroniCity data models. Santander RZ will also support the Historical Data API, based on FIWARE Short Time Historical data access and adapted according new ETSI NGSI-LD specifications. This API will rely, in SAN scenario, on a Cygnus + MongoDB instance. This instance is ready to be integrated with our instance of Orion CB.

• Security Framework. This will rely on our KeyRock + Wilma instances. By the end of March 2018, SAN set a KeyRock 5.4.0 instance ready to be integrated with SynchroniCity IdM approach. This instance was updated to KeyRock v6.0 in April 2018 and will be updated to version 7 and integrated to Synchronicity platform. It is also intended to include the Wilma add-on designed within WP2 to support SynchroniCity Marketplace.

4.9 Non-RZ Seongnam (KR) Having KETI as technical partner, Seongnam will demonstrate SynchroniCity platform and services based on oneM2M standard. Korean partners (KETI, ULIKE and SNIP) plans two phase approach to support the SynchroniCity in Seongnam.

• Phase 1: Provide SynchroniCity northbound APIs and services over oneM2M platform to Orion Context Broker interworking.

• Phase 2: Provide SynchroniCity northbound APIs as an extension to oneM2M platform.

In phase 1, in order to provide NGSI support, KETI runs a local instantiation of SynchroniCity platform. Then the implemented northbound APIs over FIWARE NGSI will be re-used. In the south, the parking occupancy data is collected in Mobius, which is oneM2M certified open source implementation, platform. Then the data get stored via oneM2M to Orion Broker agent. KETI had an experience to provide parking services over oneM2M to NGSI interface interworking50 based on semantics before. It can be re-used or another generic interworking framework51 can be implemented as non-semantic interworking scheme.

In the next phase, Mobius will implement SynchroniCity northbound APIs. Then data from the parking sensors in Seongnam and other oneM2M will be enabled and interwork-able (e.g. OCF, OMA LwM2M) devices can be accessed by SynchroniCity APIs directly from Mobius not via interworking proxies. In high-level, data marketplace APIs in SynchroniCity is the gap missing in oneM2M specifications. Other API sets like historical data or authorization are not exactly the same but it is natively supported by oneM2M so SynchroniCity enabler over oneM2M will be designed and implemented as open source by KETI.

50 Wise-IoT, http://www.wise-iot.eu 51 oneM2M TS-0030, Generic Interworking

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

5 Operation and maintenance process The main purpose of this chapter is to explain the day by day activities carried out by each SynchroniCity project partners to keep their platform stable and operational.

This process is crucial for the sanity of the overall platform; we list some of the important actions to be followed by the partners:

● Following an operation and maintenance plan

● Daily system checks

● Error handling

● Detection of discarded features

● Performance improvements

● Making necessary modifications to the platform components

● Keeping platform stable and steady In next sections, we describe the operation and maintenance processes followed by each RZ.

5.1 RZ Antwerp (BE) Maintenance is done by IMEC and Digipolis on their respective components and contains server health monitoring, critical security updates, automatic resource monitoring with alerts and external watchdog processes, which check periodically that services are up and running.

● Check_MK for health monitoring

● ELK-stack

● TICK stack

5.2 RZ Manchester (UK) Digital Catapult will provide the resource for synchronizing data and onboarding to the Manchester RZ in NGSI format.

There are a number of options in terms of operations and maintenance that Manchester is looking at. As there is not a local technical partner for Manchester running the data architecture based within the project this will likely be a 3rd party.

Either:

• Working with BT (our partner on CityVerve) to provide close links between the Manchester data platform and the Synchronicity one.

• Bringing in 3rd party hosting and operational maintenance support

5.3 RZ Carouge (CH) The maintenance process is realized by the Swiss partners and concerns the monitoring of the server and the software components. Of course, the server and its virtual machines are constantly updated.

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

5.4 RZ Eindhoven (NL) Maintenance is done by ATOS NL staff members and contains server health monitoring, critical security updates, automatic resource monitoring with alerts and external watchdog processes, which check periodically that services are up and running.

5.5 RZ Helsinki (FI) Maintenance is done by Aalto and contains server health monitoring, critical security updates, automatic resource monitoring with alerts and external watchdog processes, which check periodically that services are up and running.

5.6 RZ Milano (IT) According to Italian Regulation, all maintenance activities, if not internal, must be run by contractors companies selected by AGID (Digital Italian Agency whose duties is to furnish best practices in ICT in Italian Public Administration). The Municipality of Milano has its own contractors companies that collaborate with Data Centre Department in order to guarantee the proper operation of all the hardware systems.

The maintenance of software systems is demanded instead to the software solution provider. In the case of the WSO2 platform, all maintenance activity is demanded to ProfesiaS.r.l52.

Currently (March 2018), the Municipality of Milano still has to decide the deployment model of the SynchroniCity Platform inside its legacy system, thus there is no definite specific plan about the maintenance of its instance of the SynchroniCity Platform. In any case, the plan will include the following characteristics:

● Hardware and software will be kept up to date with particular attention to security patches.

● it will be necessary to monitor the uptime / downtime of the services and establish priority levels for the recovery interventions.

● Standard services: In this case, following a request sent by mail, the assignee must intervene remotely or by sending a technician within the time implied by the SLA after the date of receipt of the request during normal working hours.

● Critical services: In this case, following a request sent by mail, the assignee must intervene remotely or by sending a technician within the time implied by the SLA after the date of receipt of the request during normal working hours.

5.7 RZ Porto (PT) Primarily, Porto will make an effort to automate all the recurrent maintenance tasks.

All the other tasks will be executed by both Porto and its technical partner (Ubiwhere) in the project.

A monitoring stack is also installed to retrieve/store/display operation status and performance of each component.

This will not only help tracking issues and finding root cause for them, but also provide alert management around issue/incidents.

Porto will create an on-call rota in order to mitigate issues on non-office hours.

52 https://www.profesia.it/

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

5.8 RZ Santander (ES) During Synchronicity project life plus any possible extensions, University of Cantabria and TST, the Santander Reference Zone technical partners, will maintain, upgrade and monitor the Santander SynchroniCity framework instance, guaranteeing the required integration and interoperability between instances. In the same way, these partners will provide support for third parties involved in the Open Call.

5.9 Non-RZ Seongnam (KR) Maintenance is done by KETI. To minimize the downtime of oneM2M platform and interworking components, KETI will deploy automated heartbeat check API for the platform and other components which sends reports (e.g. email, SNS) on not-responding component(s) to admin person(s).

The Mobius, open source oneM2M server implementation, server machine performance monitoring will be done by the web dashboard application provided by KETI.

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

6 Conclusion This deliverable defines the first version of the deployment and operation activities through RZs by following the architectural guidelines offered in D2.1. Each RZ and their respective technical partners are responsible to carry out these heterogeneous activities in their cities. Even though they have different needs in terms of implementation and scenario, the idea is to ensure all the pilot zones are following the same standards and interoperability points.

We have summed up the activities in 4 main sections:

• Specific reference zone infrastructure and platform elements: We asked RZs to detail as-is and legacy systems in their environments to have an in detail understanding of the systems and platforms.

• Integration guide: This section details the transformation and adaptation activities of the legacy systems (datasets, sensors, DBs, APIs, etc.) with the reference architecture based on the components and standards defined in the previous deliverables.

• Deployment process: Each RZ is asked to provide the very first approach to deploy the customized reference architecture based on the pilot needs.

• Operation and maintenance process: Day to day operations to keep the SynchroniCity platform operable and functional.

This deliverable is a living document which will be updated on a time span by having more details from the RZs. There will be another (advanced) version of this document in the next months that will aim to cover the sections that are not written or mentioned shortly in the previous sections.

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

7 References The following references are used as background documents for the preparation of this document. References are categorized standards (i.e. standards and specifications from the consortium working groups or alliances and specifications or drafts standardization bodies) and other documents, publications and technical or scientific books.

1. SynchroniCity project. Deliverable D2.1 “Reference Architecture for IoT Enabled Smart Cities”, 2017

2. SynchroniCity project. Deliverable D2.2 “Guidelines for the definition of OASC Shared Data Models”, 2018

3. SynchroniCity project. Deliverable D3.1 “Documentation of service designs”, 2018

4. SynchroniCity project. Deliverable D2.6 “Guidelines for the integration of IoT devices in OASC compliant platforms”, 2018

5. FIWARE Publish/Subscribe Context Broker - Orion Context Broker. https://catalogue.fiware.org/enablers/publishsubscribe-context-broker-orion-context-broker , http://cattelefonica.webs.upv.es/Fiware/fiwareoverview-141006190614.pdf, https://ngsi9.docs.apiary.io/

6. FIWARE Publish/Subscribe Context Broker - Orion Context Broker Documentation, reference guide, manuals. https://catalogue.fiware.org/enablers/publishsubscribe-context-broker-orion-context-broker/documentation

7. FIWARE Orion Context Broker, specification and documentation. https://fiware-orion.readthedocs.io/en/develop/index.html , https://fiware-orion.readthedocs.io/en/master/user/walkthrough_apiv1/index.html , https://fiware-orion.readthedocs.io/en/develop/user/walkthrough_apiv2/index.html

8. FIWARE Data Models. https://www.fiware.org/data-models/ , https://www.fiware.org/developers/data-models/ , http://fiware-datamodels.readthedocs.io/en/latest/index.html#fiware-data-models

9. W3C (1999). Hypertext Transfer Protocol - HTTP/1.1. https://www.w3.org/Protocols/rfc2616/rfc2616.html

Chapter 10 “Status Code Definitions” https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

10. JSON specification Introduction. https://www.json.org/

11. The JavaScript Object Notation (JSON) Data Interchange Format. https://tools.ietf.org/html/rfc7159

12. JSON Schema specification. http://json-schema.org/ . http://json-schema.org/specification.html

13. JSON API specification. http://jsonapi.org/

14. Extensible Markup Language (XML), https://www.w3.org/TR/xml/

15. Fielding, Roy Thomas. Architectural Styles and the Design of Network-based Software Architectures. Doctoral dissertation, University of California, Irvine, 2000

https://catalogue.fiware.org/enablers/publishsubscribe-context-broker-orion-context-broker

https://catalogue.fiware.org/enablers/publishsubscribe-context-broker-orion-context-broker

http://cattelefonica.webs.upv.es/Fiware/fiwareoverview-141006190614.pdf

http://cattelefonica.webs.upv.es/Fiware/fiwareoverview-141006190614.pdf

https://ngsi9.docs.apiary.io/

https://catalogue.fiware.org/enablers/publishsubscribe-context-broker-orion-context-broker/documentation


https://fiware-orion.readthedocs.io/en/develop/index.html

https://fiware-orion.readthedocs.io/en/develop/index.html

https://fiware-orion.readthedocs.io/en/master/user/walkthrough_apiv1/index.html

https://fiware-orion.readthedocs.io/en/master/user/walkthrough_apiv1/index.html

https://www.fiware.org/data-models/

https://www.fiware.org/developers/data-models/

http://fiware-datamodels.readthedocs.io/en/latest/index.html#fiware-data-models

http://fiware-datamodels.readthedocs.io/en/latest/index.html#fiware-data-models

https://www.w3.org/Protocols/rfc2616/rfc2616.html

https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

https://www.json.org/

https://tools.ietf.org/html/rfc7159

http://json-schema.org/

http://json-schema.org/specification.html

http://json-schema.org/specification.html

http://jsonapi.org/

https://www.w3.org/TR/xml/

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

16. Representational State Transfer (REST), https://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#relwwwrest , https://en.wikipedia.org/wiki/Representational_state_transfer , https://www.service-architecture.com/articles/web-services/representational_state_transfer_rest.html

17. IBM, "RESTful Web services: The basics", http://www.ibm.com/developerworks/webservices/library/ws-restful/index.html

18. International Organization for Standardization (ISO), https://www.iso.org/home.html

19. International Organization for Standardization (Information Technology Vocabulary, Fundamental Terms)

http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=7229

20. International Electrotechnical Commission (IEC), http://www.iec.ch/

21. International Telecommunication Union (ITU), https://www.itu.int/en/Pages/default.aspx

22. Internet Engineering Task Force (IETF), https://www.ietf.org/

23. World Wide Web Consortium (W3C), https://www.w3.org/ , https://www.w3.org/standards/

24. W3C (2004). Web Services Architecture. W3C Working Group Note 11 February 2004. http://www.w3.org/TR/ws-arch/

25. Institute of Electrical and Electronics Engineers (IEEE), https://www.ieee.org/index.html , http://standards.ieee.org/

26. Institute of Electrical and Electronics Engineers. IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries. New York, NY: 1990.

27. European Telecommunications Standards Institute (ETSI), http://www.etsi.org/ , http://www.etsi.org/standards

28. Open Mobile Alliance (OMA), http://openmobilealliance.org/ , http://openmobilealliance.org/wp/index.html , http://openmobilealliance.org/wp-content/uploads/2012/11/OMA-Service-API-standardization-Open-Access-to-Context-aware-Service-Enablers.pdf , http://openmobilealliance.org/release/NGSI/V1_0-20120529-A/OMA-TS-NGSI_Context_Management-V1_0-20120529-A.pdf

29. Devices Profile for Web Services (DPWS), http://ws4d.org/technology/dpws/ , http://docs.oasis-open.org/ws-dd/ns/dpws/2009/01

30. RFC 7252 Constrained Application Protocol, http://coap.technology/

31. OGC http://www.opengeospatial.org/ , Glossary of Terms, http://www.opengeospatial.org/ogc/glossary/

32. MQTT – machine-to-machine (M2M) / "Internet of Things" connectivity protocol. http://mqtt.org/ ,

https://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#relwwwrest

https://www.w3.org/TR/2004/NOTE-ws-arch-20040211/#relwwwrest

https://en.wikipedia.org/wiki/Representational_state_transfer

https://www.service-architecture.com/articles/web-services/representational_state_transfer_rest.html

https://www.service-architecture.com/articles/web-services/representational_state_transfer_rest.html

http://www.ibm.com/developerworks/webservices/library/ws-restful/index.html

https://www.iso.org/home.html



http://www.iec.ch/

https://www.itu.int/en/Pages/default.aspx

https://www.ietf.org/

https://www.w3.org/

https://www.w3.org/standards/

http://www.w3.org/TR/ws-arch/

https://www.ieee.org/index.html

http://standards.ieee.org/

http://www.etsi.org/

http://www.etsi.org/standards

http://openmobilealliance.org/

http://openmobilealliance.org/wp/index.html

http://openmobilealliance.org/wp-content/uploads/2012/11/OMA-Service-API-standardization-Open-Access-to-Context-aware-Service-Enablers.pdf



http://openmobilealliance.org/release/NGSI/V1_0-20120529-A/OMA-TS-NGSI_Context_Management-V1_0-20120529-A.pdf

http://openmobilealliance.org/release/NGSI/V1_0-20120529-A/OMA-TS-NGSI_Context_Management-V1_0-20120529-A.pdf

http://ws4d.org/technology/dpws/

http://docs.oasis-open.org/ws-dd/ns/dpws/2009/01

http://coap.technology/

http://www.opengeospatial.org/

http://www.opengeospatial.org/ogc/glossary/

http://mqtt.org/

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Wikipedia, MQTT protocol. https://en.wikipedia.org/wiki/MQTT

OASIS Standard: OASIS Message Queuing Telemetry Transport (MQTT). https://www.oasis-open.org/news/announcements/mqtt-version-3-1-1-becomes-an-oasis-standard

http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html

33. SOA-RM (2006). OASIS Reference Model for Service Oriented Architecture 1.0. Committee Specification 1, 2 August 2006. http://www.oasis-open.org/committees/download.php/19679/soa-rm-cs.pdf, http://docs.oasis-open.org/soa-rm/v1.0/soa-rm.pdf

34. ISO 19100 – Standards catalogue – ISO/TC211 - Geographic information/Geomatics. https://www.iso.org/committee/54904/x/catalogue/

35. ISO 19119 – Geographic information Services. https://www.iso.org/standard/59221.html

36. OAuth 2.0 authorization framework enables third-party applications to obtain limited access to a web service. https://oauth.net/ , https://oauth.net/2/

37. OAuth 2.0 Authorization Framework – rfc6749. https://tools.ietf.org/html/rfc6749

38. The OpenID Foundation (OIDF) promotes, protects and nurtures the OpenID community and technologies. http://openid.net/

39. OpenID Connect. http://openid.net/connect/, http://openid.net/developers/specs/

40. Wikipedia, Computer software, http://en.wikipedia.org/wiki/Software

41. Wikipedia, Software Framework, http://en.wikipedia.org/wiki/Software_framework

42. Wikipedia, ”Standard” http://en.wikipedia.org/wiki/Standard

43. Wikipedia, ”Metadata” https://en.wikipedia.org/wiki/Metadata

44. Marine Metadata Interoperability. Definition of Metadata. http://uop.whoi.edu/techdocs/presentations/MMI_Guides.pdf

45. Powell, D. (Ed.) (1991). Delta-4: A Generic Architecture for Dependable Distributed Computing. Re-search Reports ESPRIT. Project 818/2252 Delta-4 Vol.1. ISBN 3-540-54985-4 Springer-Verlag 1991.

46. Jacobson, I., Bylund, S., Jonsson, P., and Ehneboom, S. (1995), “Modeling with Use Cases: Using contracts and use cases to build plugable architectures”. Journal of Object Oriented Programming, Vol. 8, No. 2, pp. 18-24.

47. SmartSantander: Experimentation and service provision in the smart city - IEEE Conference Publication. https://ieeexplore.ieee.org/document/6618633/

48. FIWARE NGSI version 2 Release Candidate. https://www.fiware.org/2016/06/08/fiware-ngsi-version-2-release-candidate/ , http://fiware.github.io/specifications/ngsiv2/stable/

49. FIWARE Environment Harmonized Data Models. http://fiware-datamodels.readthedocs.io/en/latest/Environment/doc/introduction/index.html

https://en.wikipedia.org/wiki/MQTT

https://www.oasis-open.org/news/announcements/mqtt-version-3-1-1-becomes-an-oasis-standard

https://www.oasis-open.org/news/announcements/mqtt-version-3-1-1-becomes-an-oasis-standard

http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html

http://www.oasis-open.org/committees/download.php/19679/soa-rm-cs.pdf

http://www.oasis-open.org/committees/download.php/19679/soa-rm-cs.pdf

http://docs.oasis-open.org/soa-rm/v1.0/soa-rm.pdf

http://docs.oasis-open.org/soa-rm/v1.0/soa-rm.pdf

https://www.iso.org/committee/54904/x/catalogue/

https://www.iso.org/standard/59221.html

https://oauth.net/

https://oauth.net/2/

https://tools.ietf.org/html/rfc6749

http://openid.net/

http://openid.net/connect/

http://openid.net/developers/specs/

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

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

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

https://en.wikipedia.org/wiki/Metadata

http://uop.whoi.edu/techdocs/presentations/MMI_Guides.pdf

https://ieeexplore.ieee.org/document/6618633/

https://www.fiware.org/2016/06/08/fiware-ngsi-version-2-release-candidate/

http://fiware.github.io/specifications/ngsiv2/stable/

http://fiware-datamodels.readthedocs.io/en/latest/Environment/doc/introduction/index.html

http://fiware-datamodels.readthedocs.io/en/latest/Environment/doc/introduction/index.html

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

50. FIWARE Air Quality Observed. http://fiware-datamodels.readthedocs.io/en/latest/Environment/AirQualityObserved/doc/spec/index.html

51. FIWARE Noise Level Observed. http://fiware-datamodels.readthedocs.io/en/latest/Environment/NoiseLevelObserved/doc/spec/index.html

52. FIWARE Weather Harmonized Data Models. http://fiware-datamodels.readthedocs.io/en/latest/Weather/doc/introduction/index.html

53. FIWARE Weather Observed. http://fiware-datamodels.readthedocs.io/en/latest/Weather/WeatherObserved/doc/spec/index.html

54. Parking Harmonized Data Models. http://fiware-datamodels.readthedocs.io/en/latest/Parking/doc/introduction/index.html

55. FIWARE Off Street Parking. http://fiware-datamodels.readthedocs.io/en/latest/Parking/OffStreetParking/doc/spec/index.html

56. FIWARE On Street Parking. http://fiware-datamodels.readthedocs.io/en/latest/Parking/OnStreetParking/doc/spec/index.html

57. FIWARE Parking Spot. http://fiware-datamodels.readthedocs.io/en/latest/Parking/ParkingSpot/doc/spec/index.html

58. FIWARE Transportation Harmonized Data Models. http://fiware-datamodels.readthedocs.io/en/latest/Transportation/doc/introduction/index.html

59. FIWARE Traffic Flow Observed. http://fiware-datamodels.readthedocs.io/en/latest/Transportation/TrafficFlowObserved/doc/spec/index.html

60. FIWARE Bike Hire Docking Station. http://fiware-datamodels.readthedocs.io/en/latest/Transportation/Bike/BikeHireDockingStation/doc/spec/index.html

61. Santander Open Portal (“Datos Abiertos Santander”). http://datos.santander.es/

62. IEEE Std 802.15.4-2011 (Revision of IEEE Std 802.15.4-2006) - IEEE Standard for Local and metropolitan area networks--Part 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs). http://standards.ieee.org/findstds/standard/802.15.4-2011.html

63. SmartSantander Web site. http://www.smartsantander.eu/

64. LoRa Alliance Technology – Wide Area Networks for IoT. https://www.lora-alliance.org/technology

What is LoRa. https://www.semtech.com/technology/lora/what-is-lora

65. Wikipedia LPWAN. https://en.wikipedia.org/wiki/LPWAN

http://fiware-datamodels.readthedocs.io/en/latest/Environment/AirQualityObserved/doc/spec/index.html



http://fiware-datamodels.readthedocs.io/en/latest/Environment/NoiseLevelObserved/doc/spec/index.html



http://fiware-datamodels.readthedocs.io/en/latest/Weather/doc/introduction/index.html

http://fiware-datamodels.readthedocs.io/en/latest/Weather/doc/introduction/index.html

http://fiware-datamodels.readthedocs.io/en/latest/Weather/WeatherObserved/doc/spec/index.html



http://fiware-datamodels.readthedocs.io/en/latest/Parking/doc/introduction/index.html

http://fiware-datamodels.readthedocs.io/en/latest/Parking/doc/introduction/index.html

http://fiware-datamodels.readthedocs.io/en/latest/Parking/OffStreetParking/doc/spec/index.html



http://fiware-datamodels.readthedocs.io/en/latest/Parking/OnStreetParking/doc/spec/index.html



http://fiware-datamodels.readthedocs.io/en/latest/Parking/ParkingSpot/doc/spec/index.html

http://fiware-datamodels.readthedocs.io/en/latest/Parking/ParkingSpot/doc/spec/index.html

http://fiware-datamodels.readthedocs.io/en/latest/Transportation/doc/introduction/index.html

http://fiware-datamodels.readthedocs.io/en/latest/Transportation/doc/introduction/index.html

http://fiware-datamodels.readthedocs.io/en/latest/Transportation/TrafficFlowObserved/doc/spec/index.html



http://fiware-datamodels.readthedocs.io/en/latest/Transportation/Bike/BikeHireDockingStation/doc/spec/index.html



http://datos.santander.es/

http://standards.ieee.org/findstds/standard/802.15.4-2011.html

http://www.smartsantander.eu/

https://www.lora-alliance.org/technology

https://www.lora-alliance.org/technology

https://en.wikipedia.org/wiki/LPWAN

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

66. FIWARE Catalogue – Publish/Subscribe Context Broker - Orion Context Broker documentation. https://catalogue.fiware.org/enablers/publishsubscribe-context-broker-orion-context-broker/documentation

67. FIWARE-NGSI v2 Specification. http://telefonicaid.github.io/fiware-orion/api/v2/stable/

68. FIWARE Catalogue – Backend Device Management – IDAS. https://catalogue.fiware.org/enablers/backend-device-management-idas

69. FIWARE Catalogue – STH-Comet. https://catalogue.fiware.org/enablers/sth-comet

70. FIWARE Catalogue – Cygnus. https://catalogue.fiware.org/enablers/cygnus

71. FIWARE Catalogue – PEP Proxy – Wilma. https://catalogue.fiware.org/enablers/pep-proxy-wilma

72. FIWARE Catalogue – Identity Management – KeyRock. https://catalogue. fiware.org/enablers/identity-management-keyrock

73. FIWARE Catalogue – Authorization PDP – AuthZForce. https://catalogue. fiware.org/enablers/authorization-pdp-authzforce

74. Ingénierie Électronique et Monétique (IEM). www.iemgroup.com/

75. Orbiwise, a Swiss company that develops advanced technologies for the Internet of Things industry. https://www.orbiwise.com/home

76. Transports Publics Genevois (TPG). https://www.tpg.ch/en/web/site-international

77. Universal Device Gateway (UDG). https://www.devicegateway.com/

78. Sentilo web site, open source API and general model, http://www.sentilo.io/xwiki/bin/view/APIDocs/Overview , http://www.sentilo.io/wordpress/



http://telefonicaid.github.io/fiware-orion/api/v2/stable/

http://telefonicaid.github.io/fiware-orion/api/v2/stable/

https://catalogue.fiware.org/enablers/backend-device-management-idas

https://catalogue.fiware.org/enablers/sth-comet

https://catalogue.fiware.org/enablers/sth-comet

https://catalogue.fiware.org/enablers/cygnus

https://catalogue.fiware.org/enablers/pep-proxy-wilma

https://catalogue.fiware.org/enablers/identity-management-keyrock

https://catalogue.fiware.org/enablers/identity-management-keyrock

https://catalogue.fiware.org/enablers/authorization-pdp-authzforce

https://catalogue.fiware.org/enablers/authorization-pdp-authzforce

http://www.iemgroup.com/

https://www.orbiwise.com/home

https://www.tpg.ch/en/web/site-international

https://www.devicegateway.com/

http://www.sentilo.io/xwiki/bin/view/APIDocs/Overview

http://www.sentilo.io/wordpress/

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

8 Annex - Common infrastructure and platform elements

The SynchroniCity platform, services and components, will deal with network communication capability addressing integration of various types of services, legacy systems and a wide range of heterogeneous devices, sensors and different kinds of machines.

In this context, one of the main activities is to define an infrastructure and the environment of the SynchroniCity platform taking into consideration the flexibility and the interoperability as key system requirements.

8.1 Key common definition related to the SynchroniCity architecture and platform

8.1.1 Interoperability The main technical challenges of the SynchroniCity project are related to the interoperable of the city and reference zone architectures. The idea is to choose the correct and adaptable platform architecture elements (sub-systems, components, interfaces, data model))) where each use case or scenario and their requirements should be developed taking advantage of an architecture always focusing on the integration, compatibility and interoperability with all the elements or entities which are involved in this architecture.

One key requirement is the interoperability of the SynchroniCity general activities but also in the scope of SynchroniCity platform and network communications domain. With respect to software, the term interoperability is used to describe the capability of different programs to exchange data via a common set of exchange formats, to read and write the same file formats, and to use the same protocols (the ability to execute the same binary code on different processor platforms is 'not' contemplated by the definition of interoperability). The lack of interoperability can be a consequence of a lack of attention to standardization during the design of the architecture, services, components, and applications. Indeed, interoperability is not taken for granted in the non-standards-based portion of the computing world.

There are different levels of interoperability:

• The technical level needed to guarantee physical interoperability: The goal is to achieve compatibility between systems being "plugged" together.

• Level where it is necessary to abide by/implement to the same protocols (interface, API, etc.) as a prerequisite for further interoperability.

• Level focused on the Data/Object model interoperability to enforce exchangeability of information.

Below some interoperability definitions are provided:

ISO/IEC 2382-01 (Information Technology Vocabulary, Fundamental Terms) [19]

According to ISO/IEC 2382-01, Information Technology Vocabulary, Fundamental Terms, interoperability is defined as follows: "The capability to communicate, execute programs, or transfer data among various functional units in a manner that requires the user to have little or no knowledge of the unique characteristics of those units".

The IEEE Glossary [26]:

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

The IEEE Glossary defines interoperability as: “The ability of two or more systems or components to exchange information and to use the information that has been exchanged”

There are also many other definitions related to interoperability related to specific domains of applications, where one of them is as follows:

OGC interoperability definition [31]

The OGC defines interoperability as capability to communicate, execute programs, or transfer data among various functional units in a manner that requires the user to have little or no knowledge of the unique characteristics of those units (ISO 2382-1).

“The ability for a system or components of a system to provide information portability and inter-application, cooperative process control. Interoperability, in the context of the OpenGIS Specification, is software components operating reciprocally (working with each other) to overcome tedious batch conversion tasks, import/export obstacles, and distributed resource access barriers imposed by heterogeneous processing environments and heterogeneous data".

The OGC definition applies to metadata interoperability, when one replaces the word “data” in the definition with the word “metadata”. An important aspect is that interoperable metadata can be used by computer systems, in contrast to metadata that is designed to be read and understood by a person.

8.1.2 Software platform Typical platforms include a computer architecture, operating system, programming languages and related user interface (run-time system libraries or graphical user interface), network services and communication systems.

A platform is a crucial element in software development. A platform might be simply defined as a place to launch software. The platform provider offers to the software developer an undertaking that logic code will run consistently as long as the platform is running on top of other platforms.

In computer programming [40][41], a framework (or software framework) is an abstraction in which common code providing generic functionality can be selectively overridden or specialized by user code providing specific functionality. Frameworks are a special case of software libraries in that they are reusable abstractions of code wrapped in a well-defined Application programming interface (API), yet they contain some key distinguishing features that separate them from normal libraries.

The software platform should focus allowing the incorporation of recognized standards and reliable technologies. These technologies involved in the underlying architecture and software platform should provide a clear trend towards integration and interoperability. These technologies should be considered as references already consolidated where the exchange of information with external systems should be based on certified standards for interoperability, at level of communications, transport protocols, data exchange protocols and service engineering.

8.1.3 Technology standard This section enumerates some existing standards and service-oriented solutions. These existing solutions include standards for service description, semantic service descriptions and service frameworks. These systems are essential to fulfil the SynchroniCity platform related requirements in the context of a smart city and service platform.

According to [42], "a technical standard is an established norm or requirement. It is usually a formal document that establishes uniform engineering or technical criteria, methods,

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

processes and practices. In contrast, a custom, convention, company product, corporate standard, etc. which becomes generally accepted and dominant is often called a de facto standard."

The development of technical standards can be done privately or unilaterally, for example by a corporation or regulatory body. In particular, standards organizations have great impact on local, national, regional and global standardization activities. International standard organizations, such as the International Organization for Standardization (ISO) [18], the International Electrotechnical Commission (IEC) [20], the International Telecommunication Union (ITU) [21] have established thousands of standards covering almost every conceivable topic, while others, such as the Internet Engineering Task Force (IETF) [22], the World Wide Web Consortium (W3C) [23], Institute of Electrical and Electronics Engineers (IEEE) [23], and particularly European Telecommunications Standards Institute (ETSI) [27], Open Mobile Alliance (OMA) [28] have worked on more specialized topics.

In the context of SynchroniCity, international standards serve as the base for all different technologies involved in the overall framework. For example, this will affect services and components, user interface design, security mechanisms and communication technologies. By using and relying on international standards, the SynchroniCity platform will try to ensure interoperability with other services, components and other city legacy system. For example: W3C Web services [24], Representational State Transfer (REST) [16], Web Services Standards for Publish/Subscribe Systems, Devices Profile for Web Services (DPWS) [29], Constrained Application Protocol CoAP [30], MQTT [32], XML [14], JSON [10].

8.2 Service network infrastructure definition The objective of this section is to introduce and describe the state of the art of service architecture based on service engineering approach and service platform concepts that can be included in the scope of the SynchroniCity project and particularly in the SynchroniCity platform / system.

A good approximation of engineering services for the architecture of SynchroniCity may be references to specifications, guideline, recommendations and frameworks related to SOA (Service Oriented Architecture) in particular, those described by the working group OASIS and called SOA-RM [33] (SOA Reference Model) and references from W3C that describe the Web Services Architecture [24], references under the standard ISO 19100 [34], ISO 19119 Geographic information Services [35], service taxonomy, service modelling standard and best practices.

8.2.1 Functional classification of services The aim is to give the concepts to classify the cluster of generic services or basic service that can be members of the architecture. These concepts are valid for any service-based system that can be on the server side or other kind of platform e.g. client side, embedded system, etc.

What is called "core services" would be the “fundamental/elemental services” and the "basic and common services" would be support service and info-structure service. The "thematic" services groups are services that provide functionalities oriented to a type of thematic or specific high level service (service domains or application domains as human-centric traffic management (bicycle mobility), multi-modal transportation (Multimodal Assistant), and community policy suite (Agile Governance).

Example of description: “SynchroniCity service consists of…”, “and uses services core/basic/commons such as...”, “with interfaces such....”, “incoming/outgoing communications, persistence data and/or messages, algorithms or engines, statistical calculations,...”.

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

As part of the architecture used in SynchroniCity, SynchroniCity (SC) service types are defined by the collection of the interface types that they support. As an interface type defines the externally visible behavior, an SC service type is in fact defined by the functionality that it provides to the external world. The proposed SynchroniCity Reference Model Architecture classifies service types into service categories by discussing their functionality.

The main service categories are SC Architecture Services (SCA Services) and SC Thematic Services (SCT Services):

• SCA Service provides a generic, platform-neutral and application-domain independent functionality.

• SCT Service provides an application domain-specific functionality built on top and by usage of SCA Services and/or other SCT Services.

Hereafter, the term “usage” means that a service may call operations of another service in order to provide the desired functionality. In this sense, the calling service depends on the other service. In the service specification it is stated if such a usage is mandatory or just recommended.

The list of SCA Services and SCT Services as presented in the following section is the result of an intense analysis of the existing functional user or actor and system requirements (some based on the technical requirements enumerated in the document D2.1 “Reference Architecture for IoT Enabled Smart Cities” [1] and some other based on the selected service requirements enumerated in the document D3.1 “Documentation of service designs” [2] related to smart cities eco-system issues but focused within the SynchroniCity project.

The granularity for the services is oriented at the functional coherency of the service operations and the type of information (e.g. feature types, meta-information) that is managed by the service.

8.2.2 Terms and definitions for SynchroniCity service concept SynchroniCity Service Network (SSN)

Set of networked hardware components and SynchroniCity Service Instances (SSI) that interact in order to serve the objectives of SynchroniCity Applications. The basic unit, within an SSN for the provision of functions, is the SynchroniCity Service Instance (SSI).

SynchroniCity Service Instance (SSI)

The SynchroniCity Service Instance is executing manifestation of a SynchroniCity Service Component (SSC).

SynchroniCity Service Component (SSC)

SynchroniCity Service Component is a component that provides an external interface of a SynchroniCity Service according to a SynchroniCity Implementation Specification (SIS).

SynchroniCity Implementation Specification (SIS)

SynchroniCity Implementation Specification is a combined platform-specific specification of the engineering and technology viewpoints as a result of the mapping of the SynchroniCity Architecture to a specific platform.

SynchroniCity Application

SynchroniCity Application is a set of software components that together comprise an application based on the usage of SynchroniCity Services.

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

8.2.3 SynchroniCity Architecture Service (SCA Service) SynchroniCity Architecture Services (SCA) is further classified into two sub-categories:

• SCA Info-Structure Service: These are services that are required to operate an SSN (SynchroniCity Service Network) in the sense that these services play an indispensable role in the operation of a SSN depending on its required characteristics. An example of such a role may be that at least one service instance of such a service must exist in one service network environment (e.g. for the concurrency of process or thread, communication service, context or data service).

• SCA Support Service: These are SCA Services that support the provision of SCA Info-Structure Service functionality (as an implementation option) or facilitate the operation of a SSN, e.g. providing an added value by combining them with the usage of SCA Info-Structure Services.

These two categories together comprise the generic information infrastructure (info-structure) of the RM-SCA (Reference Model for SynchroniCity Architecture).

The RM-SCA term has to be understood in the context of the SynchroniCity project as an attempt to model the SynchroniCity architecture. The RM-SCA comprises the generic aspects of service-oriented architectures, i.e., those aspects that are independent of the smart city eco-system, context and service management domain and thus applicable to other application domains.

The SCA Services thus provide the functional basis for application domain-specific functionality. SCA Services themselves do not address any specific thematic application domain, nor do they impose any structure on the SynchroniCity Thematic (SCT) Services.

Note that SCA Services may themselves use other SCA Services. Furthermore, SCT Services may use both SCA Info-Structure Services and SCA Support Services in order to fulfil a given functionality.

This functional classification is illustrated in the Figure 75:

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Figure 75: SynchroniCity Architecture (SCA) Services

Basic functionality that may, or even shall, be offered by all SCA and SCT Services with well-defined interfaces is collected in an “abstract service type” called “SCA Basic Service”. This service type is abstract as there is no meaningful instance of such a service type. However, it is kept in the table as the same description and specification techniques are used in order to describe its functionality.

For instance, based on the ISO 19100 Service Taxonomy which identifies and defines the architecture patterns for service interfaces and particularly the ISO 19119 which is used for geographic information, the following Table 4 represents a list of example geographic services placed in the services taxonomy. This list of service types is categorized as info-structure services and support service in alphabetic order within the sub-categories.

Note that GeoModel/InfoManagement here stands for Geographic Model/Information Management Services.

Obviously, as it is an example to illustrate this topic, the SCA Services type should be specific for the SynchroniCity issues. This will be done in other chapters and next deliverables which will describe the definition and specification of the SynchroniCity service types with more details.

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Service Type Name Service Category

ISO 19119 Service Taxonomy

SCA Basic Service Info-Structure none

Authentication Service Info-Structure GeoModel/InfoManagement

Authorization Service Info-Structure GeoModel/InfoManagement

Catalogue Service Info-Structure GeoModel/InfoManagement

Document Access Service

Info-Structure GeoModel/InfoManagement

Feature Access Service Info-Structure GeoModel/InfoManagement

Map and Diagram Service


Name Service Info-Structure GeoModel/InfoManagement

Sensor Access Service Info-Structure GeoModel/InfoManagement

Service Monitoring Service


User Management Service


Annotation Service Support GeoModel/InfoManagement

Coordinate Operation Service

Support Geographic Processing Services

Document Indexing Service

Support GeoModel/InfoManagement

Format Conversion Service


Gazetteer Service Support GeoModel/InfoManagement

Knowledge Base Service


Ontology Access Service


Query Mediation Service


Schema Mapping Service


Service Chain Access Service

Support Workflow/Task Management Services

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Service Type Name Service Category


Thesaurus Access Service


Table 4: Example of list of architectural services classification

8.2.4 SynchroniCity Thematic Service (SCT Service) SynchroniCity Thematic Services (SCT) provides application domain-specific functionality. However, both within and between different application domains, high level functions that have a generic nature may be identified. These services are inside the scope of the RM-SCA as a generic architecture and area defined as follows:

• SCT Support Service: generic service that facilitates the development or interactive composition of a thematic functionality.

The application domain of the components of the underlying platform of the SynchroniCity system is taken as an informative example of further sub-categories of SCT Services, although outside the scope of the RM-SCA. Here, the SynchroniCity platform could provide dedicated SCT Services according to the following structure:

• SCT Neutral Service: service specific to the SynchroniCity extensions and its associated platform management domain that facilitates the development or interactive composition of SynchroniCity interface and service extension based on the reference platform functionality.

• SCT Specific Service: service specific to a specific service domain (e.g. specific traffic services, parking services, marketplace service extensions, multimodal services, bicycle services) that facilitates the development or interactive composition of a specific SynchroniCity platform functionality and interfaces.

All SCT Services may use and combine the SCA Services in order to fulfil their thematic function.

This functional classification is illustrated in Figure 76:

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Figure 76: SynchroniCity Thematic (SCT) Services

As an example, also related to the ISO 19100 Service Taxonomy, the following Table 5 shows a list of thematic support services for some application domain.

Obviously, as it is an example to illustrate this topic, the SCT Services type should be specific for the SynchroniCity issues. This will be done in other chapters and next deliverables which will describe the definition and specification of the SynchroniCity service types with more details.

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Service Name Service Category


Processing Service Support Geographic Processing Services

Simulation Management Services

Support Geographic Processing Services

Calendar Service Support Workflow/Task Management Services

Communication Service Support Workflow/Task Management Services

Project Management Support Service

Support Workflow/Task Management Services

Reporting Service Support Workflow/Task Management Services

Sensor Planning Service Support Workflow/Task Management Services

Table 5: Example of list of thematic services classification

8.2.5 SynchroniCity classification of services approach In order to describe and specify the services(T3.1) for the SynchroniCity platform it is necessary to identify and analyze the possible SynchroniCity functionalities and interfaces with other entities or actors. This kind of work will allow grouping these functionalities in functional blocks and clustering theses blocks in service domain to establish a classification of SynchroniCity services that will be specified and implemented.

During the identification and classification of SynchroniCity services, it can be necessary to take into account some principle, steps or rules related to service dependency, service API specification, service implementation, and relevant use cases.

For example, identifying the basic data type and relevant functionalities, rules for building a core SynchroniCity services and associated schema, following a methodological approach, thinking in a service framework in order to assure basic interoperability of data and service and especially to promote the interoperability between SSN developed separately (e.g. interface between different kind of service and application backend and its own underlying system or legacy system).

A methodological approach for identification of services and data can be based on the analysis of the use cases (with the focus that they are relevant to the SynchroniCity project goal, the SynchroniCity tasks and the interaction with entities involved in an SSN, i.e. the platform itself, cities and reference zones, service and application providers).

In the chapter dedicated to each reference zone (related to legacy system and High level theme and service domains) a list of services related to the scenario and use cases, foreseen to be specified, are presented and shall be understood as a recommended approach for analyzing and modelling of service and information in relationship to several selected purposes in the scope of the SynchroniCity tasks. Their purpose is to clarify possible uses and information necessary to provide the respective functionality through a use cases categorization.

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

8.3 System and components In this section we describe the baseline components and the technology stack that has been used system wide in order to build and run the overall platform. SynchroniCity architecture depends on the open source components and standards defined in the next section.

8.3.1 Technology and standards This section covers the deployment methods, tools and open standards that are used for building the SynchroniCity architecture.

• Virtualization: Creating a virtual version of computer hardware platforms, storage devices, and computer network resources. Virtualization allows running multiple operating systems on a single physical machine. Virtualization software acts as a layer between the primary OS and the virtual OS.

• OpenStack: OpenStack is a free and open-source software platform for cloud computing, mostly deployed as infrastructure-as-a-service (IaaS), whereby virtual servers and other resources are made available to customers] The software platform consists of interrelated components that control diverse, multi-vendor hardware pools of processing, storage, and networking resources throughout a data center. Users either manage it through a web-based dashboard, through command-line tools, or through RESTful web services53.

• Docker: Docker is a computer program that performs operating-system-level virtualization also known as containerization. It is primarily developed for Linux, where it uses the resource isolation features of the Linux kernel such as cgroups54 and kernel namespaces, and a union-capable file system such as OverlayFS55 to allow independent "containers" to run within a single Linux instance, avoiding the overhead of starting and maintaining virtual machines (VMs)56.

• FIWARE: The FIWARE platform provides a powerful set of APIs that ease the development of Smart Applications in multiple vertical sectors. The specifications of these APIs are public and royalty-free. Besides, an open source reference implementation of each of the FIWARE components is publicly available so that multiple FIWARE providers can emerge faster in the market with a low-cost proposition57.

• NGSI: Today’s telecommunications service providers face strong competition to deliver new revenue-generating services. Creating value in future service domains is strongly linked to the convergence of new services across various domains. The objective of Next Generation Service Interface (NGSI) enabler is to define a set of new service APIs in order to stimulate the usage of various service enablers to foster the development of new services and applications. NGSI will both define extensions beyond today’s Parlay X APIs (latest version: 3GPP Release 8 Parlay/Parlay X APIs) and define several new APIs as needed. Considering the evolution of the network in the day-to-day life, shaping the future of the digital life is driven by information sources, social communities, e-commerce, as well as network access and network infrastructure variety up to integrated services58.

53 https://en.wikipedia.org/wiki/OpenStack 54 https://en.wikipedia.org/wiki/Cgroups 55 https://en.wikipedia.org/wiki/OverlayFS 56 https://en.wikipedia.org/wiki/Docker_(software) 57 https://www.fiware.org/about-us/ 58 http://www.openmobilealliance.org/release/NGSI/V1_0-20120529-A/OMA-RD-NGSI-V1_0-20120529-A.pdf

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

9 Glossary The glossary provides the coherent terminological framework used in this document.

9.1 Terms and definitions This section provides definitions of any terms that may be needed in order for the reader to understand the terminology used in the document. The author should define any definition/acronym or technical term used in the document that may be unfamiliar to the reader, and it is best to err on the side of too many rather than too few definitions. This also allows the author to frame a word within a specific context, which provides the reader with a common understanding of the author’s definition.

Access control Authorization (or denegation) for performing a certain action (based on privileges management). The access control is carried out once the Identification and Authentication procedures have been performed.

Accounting

Process of gathering information about the usage of resources by subjects.

Acceptance and trust

Acceptability indicates the degree of approval of a technology by the users. It depends on whether the technology can satisfy the needs and expectations of its users and potential stakeholders. Within the framework of introducing new technologies, acceptability relates to social and individual aspects as well.

Application

Use of capabilities, including hardware, software and data, provided by an information system specific to the satisfaction of a set of user requirements in a given application domain.

Application Domain

Integrated set of problems, terms, information and tasks of a specific thematic domain that an application (e.g. an information system or a set of information systems) has to cope with.

Application Schema [ISO/FDIS 19109:2003]

Conceptual schema for data required by one or more applications.

Architecture (of a system) [ISO/IEC 10746-2:1996]

Set of rules to define the structure of a system and the interrelationships between its parts.

Authentication

Process of verifying the identity of a certain subject. In other words, authentication indicates whether a subject is who/what it seems to be.

Generally speaking, this proof can depend on a secret that can be, e.g. what somebody has (key, smart card, …), what somebody knows (password, …), what somebody is (biometrical data, …).

Authorization Process of determining whether a subject is allowed to have the specified types of access to a particular resource. This is done by evaluating applicable access control information contained in a so called authorization context. Usually, authorization is carried out after the

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

identification and authentication. Once a subject is identified and authenticated, it may be authorized (or not) to perform different types of access.

Availability Availability refers to the degree to which a system, subsystem, or equipment is in a specified operable and committable state at the start of a mission, when the mission is called for at an unknown, i.e., a random time. So, availability is the proportion of time that a system is in operating condition.

Capability

Capabilities are a set of functionalities, through a combination of software and hardware, used to provide services and data. They can reside in a system or for example in a terminal itself as embedded capabilities or they can be available through the network services and infrastructure and others communication technologies as external capabilities.

Catalogue59

Collection of entries, each of which describes and points to a feature collection. Catalogues include indexed listings of feature collections, their contents, their coverages, and of meta-information. A catalogue registers the existence, location, and description of feature collections held by an Information Community. Catalogues provide the capability to add and delete entries. A minimum Catalogue will include the name for the feature collection and the locational handle that specifies where these data may be found. Each catalogue is unique to its Information Community.

Certificate Authority A Trusted Third Party, responsible for ensuring the binding between the public keys and the personal data of their respective owners.

Component

Hardware component (device) or Software Component.

Conceptual model [ISO/FDIS 19109:2003(E); ISO 19101]

Model that defines concepts of a universe of discourse.

Conceptual schema [ISO/FDIS 19109:2003(E); ISO 19101]

Formal description of a conceptual model.

Coverage [ISO 19123]

Function from a spatial, temporal or spatiotemporal domain to an attribute range. Coverage associates a position within its domain to a record of values of defined data types. Thus, coverage is a feature with multiple values for each attribute type, where each direct position within the geometric representation of the feature has a single value for each attribute type.

Data acquisition

Methods of data acquisition include methods to collect background data, digitally acquire data from sensors, and subjective data (such as data acquired from questionnaires). In addition, data in the form of manually or automatically transcribed data and reductions of collected data is also considered sensor acquired data (but with a manual sensor – the analyst).

Description Logics

59 http://www.opengeospatial.org/resources/?page=glossary

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Family of logic based knowledge representation languages that are a decidable subset of first order logic with well-defined semantics and inferencing (problem decision procedures). In Description Logics, a distinction is made between the terminological knowledge and the assertional knowledge. This distinction is useful for knowledge base modelling and engineering: for modelling it is just natural to distinguish between concepts and individuals; for engineering it helps by separating key inference problems.

Digital Certificate

A kind of digital document that contains structured information about the identity of its owner along with her/his public key, signed all together with a Certificate Authority’s private key.

Digital Signature

The encrypted form of a message with the private key of the owner, indicating in a secure way the creator of the message, as well as the identity of a signed data.

Encryption

The act of modifying the contents of a message in an algorithmic and secure way, so that it cannot be observed or altered in while in transit.

End-User All users that are involved in an application domain and that use the applications, the services built by the system users according to the system and service Architecture.

Feature [derived from ISO 19101]

Abstraction of a real world phenomenon [ISO 19101] perceived in the context of an Application. In this general sense, a feature corresponds to an “object” in analysis and design models.

Framework60

An information architecture that comprises, in terms of software design, a reusable software template, or skeleton, from which key enabling and supporting services can be selected, configured and integrated with application code.

Generic

A service is generic, if it is independent of the application domain. A service infrastructure is generic, if it is independent of the application domain and if it can adapt to different organizational structures at different sites, without programming (ideally).

Identification The identification process allows relating a person/device with the service environment. The “electronic identity” is something like a credential or a “business card”, suitable to be verified throughout the authentication process.

Implementation61

Software package that conforms to a standard or specification. A specific instance of a more generally defined system.

Info-structure Service Service that is required to operate a system oriented service in the sense that it plays an indispensable role in the operation of architecture or system oriented service.

60 http://www.opengeospatial.org/resources/?page=glossary 61 http://www.opengeospatial.org/resources/?page=glossary

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Interface 62 [ISO 19119:2005]

Named set of operations that characterize the behavior of an entity.

The aggregation of operations in an interface, and the definition of interface, shall be for the purpose of software reusability. The specification of an interface shall include a static portion that includes definition of the operations. The specification of an interface shall include a dynamic portion that includes any restrictions on the order of invoking the operations.

Interoperability63 [ISO 19119:2005 or OGC]

Capability to communicate, execute programs, or transfer data among various functional units in a manner that require the user to have little or no knowledge of the unique characteristics of those units [ISO 2382-1]. (http://www.opengeospatial.org/ogc/glossary/i)

JSON

JavaScript Object Notation, used as well for textual data which is both human and machine readable. Is designed from the start for browser -based applications and is supported natively in browsers. Is replacing XML, especially for data transmission purposes. Used in OpenID Connect federation.

Loose coupling64 [W3C]

Coupling is the dependency between interacting systems. This dependency can be decomposed into real dependency and artificial dependency: Real dependency is the set of features or services that a system consumes from other systems. The real dependency always exists and cannot be reduced. Artificial dependency is the set of factors that a system has to comply with in order to consume the features or services provided by other systems. Typical artificial dependency factors are language dependency, platform dependency, API dependency, etc. Artificial dependency always exists, but it or its cost can be reduced. Loose coupling describes the configuration in which artificial dependency has been reduced to the minimum.

Metadata [43][44]

Metadata are used to describe data or information. In environmental sciences like oceanography, metadata describe the information that scientists collect and informs users about the characteristics and history of a data set or data item—including methodological, temporal and spatial information. The word metadata is sometimes used in a singular form (metadata is). We use the plural (metadata are). Both are in common usage, though in the sciences it’s typically used in the plural.

The National Information Standards Organization (NISO) defines metadata as "structured information that describes, explains, locates, or otherwise makes it easier to retrieve, use, or manage an information resource." The World Wide Web Consortium (W3C) defines metadata as "machine understandable information for the web." The Federal Geographic Data Committee (FGDC) defines metadata as describing, "the content, quality, condition, and other characteristics of data." Put simply, metadata are data about data. They provide context for research findings, ideally in a machine-readable format. Once published, metadata can enable discovery of data via electronic interfaces and enable correct use and attribution of your findings.

Meta-information

Descriptive information about resources in the universe of discourse. Its structure is given by a meta-information model depending on a particular purpose.

62 http://www.opengeospatial.org/docs/as 63 http://www.opengeospatial.org/resources/?page=glossary 64 http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/#loosecoupling

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Note: A resource by itself does not necessarily need meta-information. The need for meta-information arises from additional tasks or a purpose (like catalogue organization), where many different resources (services and data objects) must be handled by common methods and therefore have to have/get common attributes and descriptions (like a location or the classification of a book in a library).

Meta-information model Implementation of a conceptual model for meta-information. It is represented by an Application Schema for Meta-information.

Middleware65

Software in a distributed computing environment that mediates between clients and servers.

Open Architecture [based on (Powell 1991)] [45]

Architecture whose specifications are published and made freely available to interested vendors and users with a view of widespread adoption of the architecture. An open architecture makes use of existing standards where appropriate and possible and otherwise contributes to the evolution of relevant new standards.

Operation66 [ISO 19119:2005]

Specification of a transformation or query that an object may be called to execute. An operation has a name and a list of parameters.

OTP

One Time Passcode is a password which wears out at first use.

TOTP Time-based One-time Password Algorithm is based on shared secret and timestamp.

HOTP HMAC-based One-time Password Algorithm is based on a shared secret and continuously incrementing counter.

Performance indicators definition (PI)

PIs are quantitative or qualitative measurements, agreed on beforehand, expressed as a percentage, index, rate or other value, which is monitored at regular or irregular intervals and can be compared with one or more criteria.

PKI Public Key Infrastructure. Uses asymmetric private – public key pairs, where the private is kept safely at one place at owner’s possession and public is available to anybody.

Public key has two functions. It can encrypt a data structure so that only the holder of private key can decrypt it. It can also verify the data or document signature, whether it is signed by the holder of private key as well as the consistency of the data item, whether it has not been tampered during data transfer.

Both public and private keys are represented by structured files which are called certificates.

Private Key certificate can be issued by Certificate Authority (CA) or by a model called Trust-On-First (TOFU).

Platform (Service)

Set of infrastructural means and rules that describe how to specify service interfaces and related information and how to invoke services in a distributed system.

65 http://www.opengeospatial.org/resources/?page=glossary 66 http://www.opengeospatial.org/docs/as

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Principal

A principal represents the identity of a subject in a Service Network. A subject may have several identities, and thus several principals. The association between a principal and a subject is established in an authentication process.

Privacy Privacy is a fundamental right, essential to autonomy and the protection of human dignity; serving as the foundation upon which many other human rights are built. Privacy is the right to be let alone, or freedom from interference or intrusion. Privacy is the ability of an individual or group to seclude themselves, or information about themselves.

Purpose (of meta-information)

A purpose of meta-information describes the goal of the usage of the resources.

Reference Model [ISO Archiving Standards67

A reference model is a framework for understanding significant relationships among the entities of some environment, and for the development of consistent standards or specifications supporting that environment. A reference model is based on a small number of unifying concepts and may be used as a basis for education and explaining standards to a non-specialist.

Reliability

Reliability is the ability of a system or component to perform its required functions in routine circumstances, as well as hostile or unexpected circumstances, under stated conditions for a specified period of time.

Resource

Functions (possibly provided through services) or data objects.

REST [15][16][17]

Representational state transfer (REST) is an abstraction of the architecture of the World Wide Web68; more precisely, REST is an architectural style consisting of a coordinated set of architectural constraints applied to components, connectors, and data elements, within a distributed hypermedia69 system. REST ignores the details of component implementation and protocol syntax in order to focus on the roles of components, the constraints upon their interaction with other components, and their interpretation of significant data elements.

RESTful

Refers to web services which implement REST rules.

Service70 [ISO 19119:2005; ISO/IEC TR 14252]

Distinct part of the functionality that is provided by an entity through interfaces.

Session

Temporary association between a subject and a principal as a result of an authentication process initiated by the subject. Information about a session is stored in authentication session information.

67 http://ssdoo.gsfc.nasa.gov/nost/isoas/us04/defn.html] 68 http://en.wikipedia.org/wiki/World_Wide_Web 69 http://en.wikipedia.org/wiki/Hypermedia 70 http://www.opengeospatial.org/docs/as

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

SOAP

Simple Object Access protocol is a protocol 71 specification for exchanging structured information in the implementation of web services72 in computer networks73. It uses XML74 Information Set for its message format, and relies on other application layer75 protocols, most notably Hypertext Transfer Protocol 76 (HTTP) or Simple Mail Transfer Protocol 77 (SMTP), for message negotiation and transmission.

Software Component [http://www.opengeospatial.org/resources/?page=glossary]

Software program unit that performs one or more functions and that communicates and interoperates with other components through common interfaces.

Source System Container of unstructured, semi-structured or structured data and/or a provider of functions in terms of services. The source systems are of very heterogeneous nature and contain information in a variety of types and formats.

Stateless Communication protocol where each call from an agent (browser) must send all information a web server application needs to perform the requested task. The server does not preserve the state which the web application was left during preceding browser interactions.

Subject

Abstract representation of a user or a software component in an Application.

Support Service Service that facilitates the operation of an architecture or system oriented service, e.g. providing an added value by combining the usage of Info-Structure Services.

System [ISO/IEC 10746-2:1996]

Something of interest as a whole or as comprised of parts. Therefore, a system may be referred to as an entity. A component of a system may itself be a system, in which case it may be called a sub-system.

Note: For modelling purposes, the concept of system is understood in its general, system theoretic sense. The term "system" can refer to an information processing system but can also be applied more generally.

System User

Provider of services that are used for an application domain as well as IT architects, system developers, integrators and administrators that conceive, develop, deploy and run applications for an application domain.

Terminal Terminal is a mobile device capable of running mobile services and/or mobile applications.

Transaction78 [W3C]

71 http://en.wikipedia.org/wiki/Protocol_(computing) 72 http://en.wikipedia.org/wiki/Web_service 73 http://en.wikipedia.org/wiki/Computer_network 74 http://en.wikipedia.org/wiki/XML_Information_Set 75 http://en.wikipedia.org/wiki/Application_layer 76 http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol 77 http://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol 78 http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/#transaction

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

Transaction is a feature of the architecture that supports the coordination of results or operations on state in a multi-step interaction. The fundamental characteristic of a transaction is the ability to join multiple actions into the same unit of work, such that the actions either succeed or fail as a unit.

Universe of discourse [ISO 19101]

View of the real or hypothetical world that includes everything of interest.

Use case A common definition of use cases is the one described by Jacobson (Jacobson et al (1995) [46]): “When a user uses the system, she or he will perform a behaviorally related sequence of transactions in a dialogue with the system. We call such a special sequence a use case”. In Other words, a use case is a textual presentation or a story about the usage of the system told from an end-user’s perspective.

The use cases provide some tools for people, with different skills (e.g. software developers and non-technology oriented people), to communicate with each other. The use cases are general descriptions of needs or situations that often are related to basic scenarios and that are independent of the technologies and implementations of the underlying system.

User

A human acting in the role of a system user or end-user of the service and system.

WADL The Web Application Description Language is a machine-readable XML79 description of HTTP80-based web81 applications (typically REST82web services83) WADL models the resources provided by a service and the relationships between them. WADL intends to simplify reuse of web services that are based on the existing HTTP architecture of the Web. It is platform and language independent and aims to promote reuse of applications beyond basic use in a web browser.

Web Service

Self-contained, self-describing, modular service that can be published, located, and invoked across the Web. A Web service performs functions, which can be anything from simple requests to complicated business processes. Once a Web service is deployed, other applications (and other Web services) can discover and invoke the deployed service.

W3C Web Service84 [W3C]

Software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP-messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards.

XML Extensible Mark-up Language, used for textual data which has to be both human-readable and machine-readable. Can be used for both for data exchange between hosts as well as for storing static data in SQL databases. Since most SQL databases have Native SQL/XML extension, XML documents can be integrated with existing SQL databases and applications 79 http://en.wikipedia.org/wiki/XML 80 http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol 81 http://en.wikipedia.org/wiki/World_Wide_Web 82 http://en.wikipedia.org/wiki/Representational_State_Transfer 83 http://en.wikipedia.org/wiki/Web_service 84 http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/#webservice

H2020-IOT-2016-2017/H2020-IOT-2016 D2.8

of 132

in very flexible way. Because of XML’s descriptive notation, it is quite bulky format for data transmission.

wp2 7-atos · highway addressable remote transducer hdsf . hadoop distributed file system html ....

Documents