deliverable d2.5 – gap & swot analysis -...

ESPRESSO SystEmic apPRoach to Empower Smart citieS and cOmmunities Co-funded by GA 691720 the Horizon 2020 Framework Programme

of the European Union

D2.5 Gap & SWOT Analysis updated 2017.04.18

File: D2.5 Gap and SWOT Analysis updated 2017.04.18.docx Page: 1 of 63

DELIVERABLE D2.5 – Gap & SWOT Analysis

Project Acronym: ESPRESSO

Grant Agreement number: 691720

Project Title: systEmic Standardization apPRoach to Empower Smart citieS and cOmmunities

Revision: 10

Authors: Juan Bareño (Atos); Peter Parslow (OS); Richard Redweik (virtualcitySYSTEMS GmbH); Claus Nagel (virtualcitySYSTEMS GmbH)

Project co-funded by the Horizon 2020 Framework Programme of the European Union

Dissemination Level P Public X C Confidential, only for members of the consortium and the Commission Services





1. Revision history and statement of originality

1.1. Revision history

Rev Date Author Organization Description

1 8/07/2016 Juan Bareño Atos Initial TOC

2 29/07/2016 Juan Bareño Atos First Draft

3 02/09/2016 Peter Parslow OS Second Draft

4 14/09/2016 Peter Parslow OS Third Draft

5 16/09/2016 Peter Parslow; Richard Redweik, Claus Nagel

OS; VCS Include VCS input, for Consortium QA

6 27/09/2016 Peter Parslow OS Release candidate for deliverable

7 28/09/2016 Irene Facchin TRILOGIS Quality check

8 29/09/2016 Philippe Moretto ETSI STF AIOTI and OneM2M inputs

9 11/04/2017 Peter Parslow; Juan Bareño

OS; Atos Renumber as D2.5; SWOT analysis inserted into section 10; fixed other errors pointed out in review.

10 18/04/2017 Irene Facchin TRILOGIS Quality check

1.2. Statement of originality This deliverable contains original unpublished work except where clearly indicated otherwise. Acknowledgement of previously published material and of the work of others has been made through appropriate citation, quotation or both.





2. List of references

Number Full Reference

[1] ETSI Survey on SmartM2M; IoT LSP use cases and standards gaps.

[2] EIP SCC “UP Initiatives and Standards Mapping on ICT Urban Platforms for Smart Cities, version 3.0, 21st May 2016”.

[3] ESPRESSO D4.2 Definition of Smart city Reference Architecture, first release, 29/07/2016.

[4] ESPRESSO D2.1 The scope of Smart City standardisation, third version (v 3.0), 17/03/2016.

[5] ESPRESSO D2.2 The scope of Smart City use cases, 3.0, 28/05/2016.

[6] ESPRESSO D2.4 Definition of a ConceptuAl StandardS InterOPErability frAmework (CASSIOPEiA) for Smart City, first release, 27/06/2016.

[7] BSI Mapping Smart City Standards, March 2014.

[8] NOUVEL, Romain, et al. Development of the CityGML Application Domain Extension Energy for Urban Energy Simulation. Proceedings of Building Simulation 2015.

[9] CHATURVEDI, Kanishk, et al. Managing versions and history within semantic 3D city models for the next generation of CityGML. Advances in 3D Geoinformation, Lecture Notes in Cartography and Geoinformation, Springer, 2016.

[10] Open Geospatial Consortium. 2015. 3D Portrayal Implementation Standard (OGC 15-001). Candidate standard. V. Coors, B. Hagedorn, and S. Thum, Eds.

[11] CHATURVEDI, Kanishk, KOLBE, Thomas H. Dynamizers: modeling and implementing dynamic properties for semantic 3d city models. In: Proceedings of the Eurographics Workshop on Urban Data Modelling and Visualisation. Eurographics Association, 2015. S. 43-48.

[12] LÖWNER, Marc-O.; BENNER, Joachim; GRÖGER, Gerhard. Aktuelle trends in der Entwicklung von CityGML 3.0. Geoinformationen öffnen das Tor zur Welt, 2015, 34. Jg.

[13] SmartM2M; IoT LSP use cases and standards gaps. ETSI. October 2016.





3. Table of Acronyms

Acronym Description

3D Three dimensional

3DPS (OGC) 3D Portrayal Service

5G “the fifth generation of mobile networks”

ADE (CityGML) Application Domain Extension

AIOTI Alliance for the Internet of Things Innovation

BIM Building Information Model / Modelling

BSI British Standards Institution (the national standards body of the UK)

CASSIOPEiA ConceptuAl StandardS InterOPErability frAmework

CEN European Committee for Standardization

CityGML City Geography Markup Language

DAMA Data Management Association

DKE/DIN German Institute for Standardization

EIP SCC European Innovation Partnership on Smart Cities and Communities

ESPRESSO systEmic Standardization apPRoach to Empower Smart citieS and cOmmunities

eTOM the TM Forum Business Process Framework

ETSI European Telecommunications Standards Institute

EU European Union

FIWARE “The FIWARE Community is an independent open community whose members are committed to materialise the FIWARE mission, that is: “to build an open sustainable ecosystem around public, royalty-free and implementation-driven software platform standards that will ease the development of new Smart Applications in multiple sectors”

GIS Geographic Information System(s)

glTF GL Transmission Format

GPS Global Positioning System, widely known Global Navigation Satellite System

ICT Information and Communications Technology





IEC International Electrotechnical Commission

IFC Industry Foundation Class (ISO 16739)

INSPIRE Infrastructure for Spatial Information in Europe

IoT Internet of Things

ISO International Organization for Standardization

ITRF International Terrestrial Reference Framework

ITU International Telecommunication Union

JTC Joint Technical Committee (e.g. of ISO and IEC)

KM Knowledge Management

M2M Machine to Machine

OASIS Organization for the Advancement of Structured Information Standards

OGC® Open Geospatial Consortium

OS Net The permanent GPS stations which form part of the infrastructure to realise the national coordinate system in Great Britain

PAS Publicly Available Specification (a class of BSI document)

PD Published Document (a class of BSI document)

SAML Security Assertion Markup Language (an OASIS standard)

SDO Standards Development Organizations

SmaCStak ESPRESSO’s Smart City Stakeholder network

SME Small or Medium Enterprise

SOS (OGC) Sensor Observation Service

STEP Standard for the Exchange of Product model data (formalised in ISO 10303)

SWOT Strengths, weaknesses, opportunities, threats

TM Forum A global member association for digital business, formerly “TeleManagement Forum”

TOC Table of Contents

TOGAF The Open Group Architecture Framework

TR Technical Report (a class of ISO or IEC document)





UP Urban Platform (an initiative of the EIP SCC)

WG Working Group (e.g. of ISO/IEC JTC1)

WGS84 World Geodetic System 1984

WMS (OGC) Web Map Service

WP Work Package (e.g. of the ESPRESSO project)





4. Executive Abstract

The ESPRESSO Project (systEmic Standardisation apPRoach to Empower Smart citieS and cOmmunities) which focuses on the development of a conceptual Smart City Information Framework based on open standards, will build this framework by identifying relevant open standards, technologies and information models that are currently in use or in development in various sectors. The project will analyze potential gaps and overlaps among standards developed by the various standardization organizations and will provide guidelines on how to effectively address those shortcomings.

The purpose of this document is to provide recommendations to EC on the requirements for standardization related to the Smart Cities. It is not a purpose of this document to provide a large amount of tutorial/overview material but instead to reference the copious amounts of such material where necessary and to give sufficient context that experts in the various fields can understand what gaps are being identified.

The following list gives a broad view of key areas that require study to effectively determine all the Smart City gaps.

• Platform Architecture: An agreement about the basic platform architecture for Smart City Platforms would be highly beneficial. The D4.2 Definition of Smart city Reference Architecture is the target for the gap analysis. This version of D2.5 uses the first release of D4.2; a further revision of D4.2 is expected in October 2016. This document will need to be revised accordingly.

• Business Data: Most Smart Cities applications and services will need some basic data, related to basic information like geographical data or environmental data.

Version 1.0 of this document was published in September 2016, as per the ESPRESSO project plan. The first version was identified as D2.5, as per the Grant Agreement; however, this caused some confusion, as it is produced by Task 2.4. On the advice of the project officer, this second version is identified as D2.4. This version includes a more complete SWOT analysis, taking account of the design of the pilots. We have also updated it as a result of some external events expected:

• Second meeting of ISO/IEC JTC1/WG11 Smart Cities, late September 2016.

• Meeting of EIP SCC Urban Platforms Industry Group, end of September 2016.

The main objective of this deliverable is to identify strengths and weaknesses of existing and currently developed standards. Task 2.4 used standard analysis activities:

• This process will include activities for quality criteria definition and integration into legislative processes and workflows as well as fast-track standardisation suggestions.

• It will be based upon analysis of standards priorities and will be performed in tight cooperation between standards bodies and Smart Cities





Based on the pilots ‘technical description from D4.2 we should provide an initial SWOT analysis and identify main gaps regarding current standardization, following these two approaches:

• A high level SWOT analysis of the whole standards picture against high level architectural components or knowledge areas.

• Two sectoral SWOT analysis related to particular uses cases • Specific SWOT analysis of Sensor Things, to add to the analysis of CityGML

already present in the first draft.





5. Table of Contents

1. Revision history and statement of originality ............................................................................................... 2

1.1. Revision history .......................................................................................................................................... 2

1.2. Statement of originality .............................................................................................................................. 2

2. List of references ........................................................................................................................................... 3

3. Table of Acronyms ......................................................................................................................................... 4

4. Executive Abstract ......................................................................................................................................... 7

5. Table of Contents .......................................................................................................................................... 9

6. Table of Figures ........................................................................................................................................... 12

7. Table of Tables ............................................................................................................................................ 12

8. Introduction ................................................................................................................................................ 13

9. Settle the basis for the Smart City SDO Gap Analysis .................................................................................. 15

9.1. Use cases on 3D city models extracted from ESPRESSO documents ....................................................... 17

9.2. ESPRESSO Reference Architecture ........................................................................................................... 19

9.2.1. Business Architecture .................................................................................................................... 20

9.2.1.1. Vision, Strategy, and Goals ......................................................................................................... 20

9.2.1.2. Stakeholders, Roles, and Concerns ............................................................................................ 20

9.2.1.3. Business Principles ..................................................................................................................... 20

9.2.1.4. Business requirements ............................................................................................................... 20

9.2.1.5. Business Constraints ................................................................................................................... 21

9.2.2. Business Process Framework ........................................................................................................ 21

9.2.3. Knowledge Management Framework ........................................................................................... 21

9.2.3.1. Privacy ........................................................................................................................................ 22

9.2.3.2. Security ....................................................................................................................................... 22

9.2.3.3. Integrity ...................................................................................................................................... 22

9.2.3.4. Quality ........................................................................................................................................ 22

9.2.3.5. Provenance ................................................................................................................................. 22

9.2.3.6. Data value chain ......................................................................................................................... 23

9.2.3.7. Knowledge management principles ........................................................................................... 23

9.2.3.8. Component catalogue ................................................................................................................ 23

9.2.3.9. Data entity / business function matrix ....................................................................................... 24

9.2.3.10. Data lifecycle ............................................................................................................................ 24

9.2.3.11. Knowledge management process ............................................................................................ 25





9.2.4. Engineering Framework ................................................................................................................ 25

9.2.4.1. Positioning services .................................................................................................................... 26

9.2.4.2. Sensing services .......................................................................................................................... 26

9.2.4.3. Data services .............................................................................................................................. 28

9.2.4.4. Application services .................................................................................................................... 31

9.2.4.5. Business services ........................................................................................................................ 31

9.2.4.6. Consumers .................................................................................................................................. 31

10. High level SWOT analysis ........................................................................................................................... 32

10.1. Overall architecture ................................................................................................................................ 32

10.2. SWOT: Smart City sectoral Use cases: Smart Parking and Water Management .................................... 35

10.2.1. Smart Parking .............................................................................................................................. 35

10.2.2. Water management .................................................................................................................... 36

11. Low level SWOT analysis on key standards ............................................................................................... 38

11.1. CityGML .................................................................................................................................................. 38

11.1.1. Add new objects (i.e. for urban insertion analysis) ..................................................................... 39

11.1.2. Integration of sensor and dynamic data ..................................................................................... 40

11.1.3. Enable Interoperability ................................................................................................................ 40

11.1.4. Urban Simulations/Scenarios and Decision Support ................................................................... 41

11.1.5. Work in a web browser and on low-‐end mobile devices ............................................................ 42

11.1.6. Integration with user interaction / participation services ........................................................... 42

11.1.7. Management of versions and history of the city ......................................................................... 42

11.1.8. Summary and classification of gaps ............................................................................................ 42

11.1.9. How can we solve the identified gaps? ....................................................................................... 43

11.1.9.1. Solving the lack of integration of planned buildings ................................................................ 43

11.1.9.2. Solving the lack of harmonization and interoperability, the lack of expert information ......... 44

11.1.9.3. Solving the lack of representing time-‐dependent properties and integration of sensor data . 45

11.1.9.4. Solving the lack of support for low-‐end mobile devices ........................................................... 46

11.1.9.5. Solving the lack of managing versions and history of the city .................................................. 46

11.1.9.6. Solving the lack of user interaction and participation services ................................................ 46

11.1.10. Conclusions concerning CityGML .............................................................................................. 47

11.2. Sensor Things ......................................................................................................................................... 47

11.3. LORA ....................................................................................................................................................... 48

12. Conclusions and main recommendations ................................................................................................. 50

12.1. Future of this document ......................................................................................................................... 51





13. Annex 1 GAP Analysis Methodology ......................................................................................................... 52

13.1. Action 1: Investigate Smart City Standards gap analysis. ....................................................................... 52

13.2. First set of Standards extracted from the SD Reports and Survey, “Prioritization” report. ................... 53

14. Annex 2: Results from the ETSI survey on IoT for Smart Cities ................................................................. 54

14.1. Survey results for the Smart Cities vertical domain – Technical ............................................................ 54

14.2. Survey results for the Smart Cities vertical domain – Societal ............................................................... 54

14.3. Survey results for the Smart Cities vertical domain – Business .............................................................. 55

14.4. Currently, the main gaps are the following: ........................................................................................... 55

14.5. Related Areas regarding potential gaps identified by ETSI .................................................................... 55

14.5.1. Communication and Connectivity ............................................................................................... 55

14.5.2. Integration/Interoperability ........................................................................................................ 56

14.5.3. Applications ................................................................................................................................. 56

14.5.4. Infrastructure .............................................................................................................................. 56

14.5.5. Reference Architecture ............................................................................................................... 57

14.5.6. Devices and sensor technology ................................................................................................... 57

14.5.7. Security and Privacy .................................................................................................................... 57

15. Annex 3: Mapping of requirements and related standard coverage ........................................................ 58

15.1. Communication and Connectivity .......................................................................................................... 58

15.1.1. Connectivity at Physical and Link layer ........................................................................................ 58

15.1.2. Connectivity at Network layer ..................................................................................................... 58

15.1.3. Service level and application enablers ........................................................................................ 58

15.1.4. Application Layer level, APIs, Data models and ontologies ......................................................... 58

15.1.5. Integration/Interoperability ........................................................................................................ 58

15.1.6. Applications management ........................................................................................................... 59

15.1.7. Infrastructure .............................................................................................................................. 59

15.1.8. IoT Architecture ........................................................................................................................... 59

15.1.9. Devices and sensor technology ................................................................................................... 59

15.1.10. Security and Privacy .................................................................................................................. 60

16. Annex 4: EU IoT Standardization Strategy ................................................................................................. 61





6. Table of Figures

Figure 1. Smart Cities Reference Architecture (ESPRESSO D4.2). ................................................................... 25 Figure 2. ISO 42010 architectural models ....................................................................................................... 27 Figure 3. IOT service interactions. ................................................................................................................... 28 Figure 4. AIOT HLA functional model. ............................................................................................................. 29 Figure 5 AIOTI oneM2M mapping ................................................................................................................... 30 Figure 6. ITU AIOTI mapping. .......................................................................................................................... 31 Figure 7. Result of an urban flood vulnerability assessment. Visualized are relative losses of inundated buildings at a simulated water level. ............................................................................................................... 39 Figure 8. Result of an urban wind field simulation. ......................................................................................... 40 Figure 9. Example of an urban 3D scene rendered on the client. Accessible via: http://demo.virtualcitymap.de/. ..................................................................................................................... 44 Figure 10. Example of an urban 3D scene rendered on the server. Accessible via: http://www.3dcontentlogistics.com/loesungen/demos/berliner-‐3d-‐stadtmodell-‐smartmap-‐web/. ............ 45

7. Table of Tables





8. Introduction

A Smart City integrates physical, digital and human systems to deliver a sustainable, prosperous and inclusive future for its citizens. Many of these innovative solutions will be based on sophisticated information and communication technologies having both infrastructure (hard) and organizational (soft) components. However, technological complexity as well as the sophisticated articulation of the various sectorial services involved within a Smart City, requires a system approach to standardisation. Such an approach must promote the greatest possible reuse of existing open standards to accelerate Smart City deployment and exploit the enormous potential deriving from use of disparate interoperable technologies and from re-use of interoperable applications and services among cities. Standardization forms a critical part of the evolution that Europe’s cities need to make over the coming years. While technologies such as IoT, 5G or cloud technologies are opportunities for increased sustainability and effectiveness, they also present a challenge to societies as they face the digital transition. Cities are one of the EU's essential assets, but in order to leverage their potential as drivers of sustainable growth in the digital transition, the more traditional, sectorial approach to technological development must be increasingly complemented and directed with a holistic view on Smart Cities. Through the processes of standardizing Smart Cities, citizens will be guaranteed the protection of citizen rights in the use of data within cities. This will guarantee the protection of end-user rights, but also provide security for European companies in the development of information value chains.

We will see continued rapid buildout of communications infrastructure and data-capture devices like cameras and sensors, especially in emerging economies. Cities with higher adoption and penetration of these technologies will start to take inventory of assets and think of how they can be leveraged across multiple projects and/or departments. Architecture discussions will be in the theoretical stage, and progress will stall if standards don't emerge.

Standards help founding a common ground on interfaces between human beings (e.g. terminology) between human beings and technology (e.g. ergonomics and human-system-interaction, usability) and between technological devices (e.g. hardware interfaces). Following this, standards prevent vendor locks by ensuring interoperability between interfaced devices. They support each stakeholder by transparent information. Especially they support procurement by creating comparability and commensurability on each standardized entity

This document uses reports on the sectorial systems and uses cases identified, respectively D2.1 and D.2.2 in WP2, and D 4.2 Definition of Smart city Reference Architecture as a technical baseline. The case study-based approach to define key requirements for Smart Cities is the baseline for further standards analysis activities, and development of the conceptual Smart City information framework. The D4.2 is the target for the gap analysis.

Version 1.0 of this report (identified as D2.5) was intended as a live document. Its initial findings have been updated with feedback from other tasks of ESPRESSO project and from cities in frame of SmaCStak network. Results from Tasks 2.3. CASSIOPEiA – a Conceptual Standards Interoperability Framework for Smart City





and Task 2.4 Cross-SDOs Gap and SWOT analysis have extended this document to include technical standards, to identify strengths and weaknesses in the standards as well as existing gaps

The ESPRESSO reports D2.1 and D2.2 in WP2 and D4.2 list some use cases and requirements for smart cities. These requirements match with requirements originating from cities and research projects such as using 3D city models in order to enable smart urban planning, to do urban simulations, to integrate sensor data into the model, and the use of 3D city models on end-user devices such as smartphones or tablets. An additional use case is the management of versions and the history of the city within the 3D city model in order to represent the city’s evolution [9]. However, there are some gaps in order to fulfil the mentioned requirements.

The following sections describe the use cases and requirements extracted from the mentioned ESPRESSO documents with gaps and solutions on how to close these gaps. As CityGML is the OGC standard for the representation, storage and exchange of virtual 3D city models, the following analysis will be based on this standard.





9. Settle the basis for the Smart City SDO Gap Analysis

The purpose of Smart City is to increase the quality of life of its citizens through the use of intelligent technology (Big Data, IoT and M2M, sensors, mobile technologies, visualization, 3D, cloud platforms, open data platforms), improving the quality and efficiency of services provided by both public bodies and companies, in order to produce sustainable city development.

• From sensors and hardware technology that allows data capture from the city; M2M technologies for the transmission of information, data repositories, or Big Data technology that enables storing, analysing and visualization of large volumes of data, we find open source solutions, that in some cases, like in the field of Big Data, are leading the way to the rest of the solutions.

• Smart technologies are part of a new and emerging market where many of the products and services are still in their pre-commercial stage of development. The smart technologies market suffers from a number of technical barriers that need to be overcome if the market is to grow and mature.

• Additionally, augmented reality, cloud computing, e-health, the Internet of Things (IoT), smart grid and other innovative capabilities are foundational technology areas. Such standards are being created and refined through globally open collaboration across traditional geographic, industrial and technological boundaries

Therefore, Cities are complex ecosystems1. Cities need to be able to assess their current situation and determine critical capabilities needed to enable a Smart City.

• The plethora of technology choices and range of technologies;

• Key elements include interoperability of data between devices and subsystems;

• Standards for Smart Cities can support cities, (local) governments and industrial partners alike in removing some of these obstacles and lowering barriers.

Accordingly, the proposed next step towards Smart City standardization is the definition of the standards which are part of the Smart City Platform. These standards should be based on a minimum set of to-be-defined requirements in terms of interoperability potential, openness, reference implementation validation, and possibly open source implementation. Existing initiatives from standardization bodies should be leveraged (probably through the Multi Stakeholders Platform). Gaps may be identified, where standards need to be developed, but development of additional standards is outside the remit of ESPRESSO. In a way, ESPRESSO sets out to answer the challenge expressed by FIWARE2.

• Platform Architecture: An agreement about the basic platform architecture for Smart City Platforms would be highly beneficial.

1 BSI Mapping Smart City Standards. 2 Smart City Interoperability Essentials by FIWARE.





o City Platforms will require building the relevant Generic Enablers for Internet of Things Service Enablement, in order for things to become citizens of the Internet – available, searchable, accessible, and usable – and for the City Platforms services to create value from real-world interaction enabled by the ubiquity of heterogeneous and resource-constrained devices. To-date several researchers have described the benefits of a pervasive (sensor-based) distributed computing infrastructure without however providing a systematic and structured solution to the formulation and management of utility based IoT environments.

o ESPRESSO D4.2 proposes a standard architectural framework, which is being developed in conjunction with the European Innovation Partnership on Smart Cities and Communities. This ESPRESSO deliverable shows how the framework can be implemented with open standards based solutions.

• Business Data: Most Smart Cities applications and services will need some basic data, related to basic information like geographical data or environmental data.

o City GML: CityGML is a common information model for the representation of sets of 3D urban objects. It defines the classes and relations for the most relevant topographic objects in cities and regional models with respect to their geometrical, topological, semantic and appearance properties. Included are generalization hierarchies between thematic classes, aggregations, relations between objects, and spatial properties. This thematic information goes beyond graphic exchange formats and makes it possible to employ virtual 3D city models for sophisticated analysis tasks in different application domains like simulations, urban data mining, facility management, and thematic inquiries. City BIM systems use CityGML.

o Spatial and Environmental Data: The INSPIRE directive has enabled the creation of a European Union (EU) spatial data infrastructure. This enables the sharing of environmental spatial information among public sector organisations and better facilitates public access to spatial information across Europe.

o ESPRESSO seeks to identify other common data requirements.

According to the ETSI3 Survey, the realization of a Smart City is subject to many challenges in order to monitor and integrate all of the city infrastructure and services. From the technical infrastructure to be put in place to the adoption and acceptability of the offered services by the citizens as well as the business actors involved.

Regardless of the different challenges, a critical requirement for the success of a Smart City deployment remains in making the relevant data available to the relevant applications in order to achieve the idea of a Smart City. The Smart City faces the integration of different and autonomous systems that are often vendor specific (waste collection and management, parking management systems, building management, etc.). Moreover, various technologies have been employed for each application. The 3 ETSI Survey on SmartM2M;IoT LSP use cases and standards gaps





Smart City vertical sector is thus a domain where several technological solutions are used for solving similar problems.

The Smart City concept has the following specificities:

• Integration of a large number of heterogeneous equipment (sensors, actuators, edge devices, end user devices, enterprise and cloud systems, etc.)

• High data heterogeneity in terms of model, representation format, volume, precision, importance, etc.

• Use of various network and communications technologies (access network technologies and communication protocols)

• Interconnection of the newly deployed IoT systems with the legacy ones.

Moreover, target applications for the Smart City require access to data flows and actuation mechanisms. For example, a smart lightning application will require access to data provided by luminosity sensors, weather information, and a way to control connected city lights.

Smart Cities also rely on the principle of open data to foster local democracy/governance and allow the local economy to thrive. Therefore, the huge amounts of data collected and processed by the different applications are to be put on open platforms and accessible through open interfaces (APIs). Based on these new data, business models are to be developed in order to monetize the collected data and to support the service delivery.

Since Smart Cities put the citizen at the centre and thus deal with data provided by end-user or collected by monitoring systems, privacy and data security need to be solved. Open data principle may be seen as conflicting with data security and privacy. Therefore, Smart City data need to define mechanisms for data access with the appropriate access rights and protection mechanisms in order to allow the appropriate access/processing to the appropriate entity (end-user, municipality, application, third-party operators, etc.)

Finally, Smart Cities seek enhancing the efficiency of resource use and city operations services. This is achieved through the use of ICT technologies. In this context, innovative applications should have access to high level services provided by the city and its platforms. Service platforms are thus a key for the Smart City success. Such services platforms must integrate data sources, devices, systems to a large extent.

9.1. Use cases on 3D city models extracted from ESPRESSO documents This section extracts and lists the use cases and requirements on 3D city models extracted from the ESPRESSO deliverables D2.1 The scope of Smart City standardization, D2.2 The scope of Smart City use cases, and D4.2 Definition of Smart City Reference Architecture.

The deliverable D2.1 The scope of Smart City standardization presents different technological and non-technological domains that relate to the concept of Smart City. In addition, it uses a case study based approach to define key requirements for Smart Cities in order to elaborate some general technological challenges. Amongst others,





these are the storing, analysis and visualization of sensor data and the use of GIS to provide location based services in an interoperable way that is able to connect to other data sources. As an additional requirement, D2.1 provides the monitoring and integration of all critical infrastructures of the city for the complex interaction of systems. Furthermore, the deliverable states that there is a lack of on overall interoperability framework standard that works across sectorial systems.

The deliverable D2.2 The scope of Smart City use cases builds up on D2.1 to define use cases and requirements for ESPRESSO together with the pilot cities Rotterdam and Tartu. In Rotterdam one main use case is 3D Rotterdam for assisted decision making. The scope of the use case is analysis and visualization that is open and accessible to the public. This includes the integration of different data sources and the use of the model for environmental simulations, running scenarios, decision support, people and assets tracking and communication with stakeholders. The requirements for the use case are that a 3D city model (CityGML) is used as a base. The model should be extendable, replicable and scalable. In addition, the model should allow adding new objects (e.g. for urban insertion analysis) and there should be a possibility to connect sensor data using open standards. Moreover, the data should be accessible online for e-government purposes, it should support the integration with user interaction services for participation and communication purposes, and there should be export capabilities to native/vendor specific applications.

The use cases in Tartu are nearly the same. However, Tartu focuses more on participation of the citizens in order to bridge the gap between planning visualization tools and web-based open innovation and direct user interaction. It is required that the 3D city model supports the integration of proposals, works in a web browser and low-end mobile devices, and that the citizens are able to give feedback and leave comments on proposals.

The deliverable D4.2 Definition of Smart City Reference Architecture provides reference architecture for Smart Cities. The document lists business requirements, which summarize the requirements of D2.2 very well. Here the requirements are that the virtual city model is freely accessible for all, it is based on CityGML and that it is extendable, replicable, and scalable. In addition, the model should allow the connection to sensor data using open standards and the integration with user interaction services as well as the export to native applications. The deliverable proposes to use a semantic mapping by means of ontologies as knowledge management principles for the information system architecture in order to bring together information from sectoral systems.

[9] gives an additional use case not mentioned in the ESPRESSO deliverable, namely the management of the history and different versions of the city in the 3D city model in order to represent the city’s evolution or different planning alternatives.

To summarize, the use cases are:

• Using an extendable, replicable and scalable city model.

• Allow to add new objects (i.e. for urban insertion analysis).

• Allow the integration of sensor data using open standards.

• Enable interoperability in order to integrate data from different sources or from different sectoral systems.





• Allow to use the city model for simulations, scenarios and decision support.

• Integration with user interaction / participation services.

• Able to work in a web browser and on low-end mobile devices.

• Management of versions and history of the city.

9.2. ESPRESSO Reference Architecture D 4.2 Definition of Smart city Reference Architecture provides the target for the gap analysis. This version of D2.5 uses the first version of D4.2.

The intent of the Reference Architecture, and the Design Principles which form part of it, is to provide cities and communities that wish to implement Smart City initiatives with a mission and vendor agnostic approach that will result in an enhanced interoperable, standards-based architecture and implementation which is specific to a mission when their specific city context is applied. In addition, the Reference Architecture can be used with existing architectures to plan for improving interoperability, maturity, and functioning of an expanding technology solution for smart city initiatives. This mission and vendor agnostic approach is meant to provide key elements and concepts needed in order to make these resulting solution architectures interoperable.

A common theme among the definitions within the world regarding the term Reference Architecture is that the primary purpose of such a Reference Architecture is to guide and constrain the instantiations of solution architectures. In addition, a Reference Architecture should:

• Provide common language for the various stakeholders;

• Provide consistency of technology implementation to solve problems;

• Support the validation of solutions against a proven Reference Architecture; and

• Encourage adherence to common standards, specifications, and patterns.

In general, a Reference Architecture is an authoritative source of information about a specific subject or mission area that guides and constrains the instantiations of multiple architectures and solutions. The Reference Architecture provides the key elements, aligned to several other EU initiatives, and worldwide standards regarding Reference Architectures. It contains a generic yet integral approach including Business, Infrastructure, Data, Applications/Services, Security, and Performance domains, to which the concepts of interoperability and standards are applied.

ESPESSSO has adopted the Open Group TOGAF standard as the architectural framework for the definition of this Smart City Reference Architecture. The Open Group is a global consortium that leads the development of open, vendor neutral IT standards and certifications.

The use of the TOGAF architectural framework results in architectures that are consistent, respond to stakeholders needs, adopt and employ best practice, and give appropriate consideration to the current and future requirements of a given enterprise. Therefore, TOGAF provides both tools and methods for the “acceptance, production, use, and maintenance of enterprise architecture” (TOGAF 9.1).





9.2.1. Business Architecture Smartening a city benefits from a leadership guide, covering questions such as citizen engagement, vision setting, smart management, establishing goals, integrated planning, encouraging innovation.

The main standard in this area is ISO 37101 Management system for sustainable development.

Other relevant standards include:

• ISO 37120 Sustainable development of communities - Indicators for city services and quality of life

• ISO 37152 Smart community infrastructures - Common framework for development and operation

• OASIS Transformational Government Framework

• British Standards Institution’s:

o PAS 181 Smart city framework -- Guide to establishing strategies for smart cities and communities

o BS 8001 Framework for implementing the principles of the circular economy in organizations – Guide

o PD 8100 Smart Cities overview – Guide

o PD 8101 Smart cities – Guide to the role of the planning and development process

• City Protocol Society’s CPA-I_001-v2 City Anatomy: A Framework to support City Governance, Evaluation and Transformation

9.2.1.1. Vision, Strategy, and Goals

ISO 37101 “sets out to establish a coherent framework to enable the community to develop its purposes and vision”. PAS 181 includes a short section on establishing a city vision.

9.2.1.2. Stakeholders, Roles, and Concerns

ISO 37101 discusses “identifying and engaging interested parties” (its preferred term for stakeholders), and organisational roles & responsibilities

PAS 181 includes a section on stakeholder collaboration.

9.2.1.3. Business Principles

PAS 181 proposes a few “guiding principles”.

9.2.1.4. Business requirements

Although cities vary widely, there is work going on within communities of cities, such as the European Innovation Partnership Smart Cities, to find common expression for certain requirements, e.g. in lighting, running a data marketplace, asset management.





9.2.1.5. Business Constraints

No standards found: does this indicate a significant gap?

9.2.2. Business Process Framework

Work has just begun on ISO/IEC 30145-1 Smart City ICT Reference Framework – Business Process Framework, which seeks to establish a common business process framework for cities. It is initially working from the TM Forum Business Process Framework (“eTOM”), and the TM Forum Smart City Maturity Model, which is itself still under development.


• ISO 37152 Smart community infrastructures - Common framework for development and operation, which appears to be specifically relevant to those aspects of a city concerned with operating infrastructure (e.g. water, electricity, rail): it “outlines the basic concept of a common framework for the development and operation of smart community infrastructures. The framework describes the planning, development, operation and maintenance methodology to facilitate the harmonization of each infrastructure as a part of a smart community and ensures that the interactions between multiple infrastructures are well orchestrated.”

• PAS 181 Smart city framework - Guide to establishing strategies for smart cities and communities includes a short section on “key cross-city governance and delivery processes”

The various Smart City measurement frameworks implicitly indicate the business processes involved in a city, as they enumerate things to measure.

9.2.3. Knowledge Management Framework

The European Innovation Project Smart City’s “demand side” survey found that the main services running on a smart city platform are for data collection, analysis, and processing. This indicates the need for data or knowledge management.

Work has just begun on ISO/IEC 30145-2 Smart City ICT Reference Framework – Knowledge Management Framework. The initial working draft draws together existing work from British Standards Institution (PAS 182), the Chinese national standards body, the City Protocol Society, and the Global City Indicator Foundation.

Knowledge Management in general works through a number of professional societies and networks, rather than any specific formal standardisation body.

ESPRESSO D2.4 identifies knowledge management standards common to any organisation, in particular the knowledge management clauses of ISO 9001:2005.


• BSI PAS 182 Smart city concept model – Guide to establishing a model for data interoperability provides a way to connect together data held in various sectoral systems

• BSI PAS 183 Smart cities - Guide to establishing a decision-making framework for sharing data and information services (in preparation)





And on knowledge management in general, that is, not specifically to do with smart cities:

• European CEN Workshop Agreements CWA 14924 European Guide to good Practice in Knowledge Management, in five parts:

o Knowledge management framework

o Organizational culture

o SME implementation

o Guidelines for measuring KM

o KM terminology

• BSI PAS 2001:2001 Knowledge management. A guide to good practice

• BSI PD 7501 to 7505 also cover various aspects of generic knowledge management

The information architecture of a city needs to address five types of barrier: privacy, security, integrity, quality, and provenance4. Each of these areas has a number of well-established standards.

9.2.3.1. Privacy

ISO 29100 Information technology - Security techniques – Privacy framework, and related standards

9.2.3.2. Security

ISO/IEC 27000 Information technology - Security techniques – Information security management systems – Overview and vocabulary, and related standards

Note: the EIP SCC includes a “technology area” for security and privacy, mentioning many standards from public key protocols, to SAML.

9.2.3.3. Integrity

Generally considered as part of ‘security’.

9.2.3.4. Quality

ISO/TS 8000 Data quality, in a number of parts.

ISO 19157 Geographic information – Data quality.

9.2.3.5. Provenance

There are a number of ISO standards that include the notion of ‘provenance’, as applied to different domains. None seem generally applicable to smart cities:

• ISO 5127 – libraires, documentation and information centres, etc.

ISO 19115 (19153, 19160) – Geographic information

4 PAS 182, but draft PAS 183 has a completely different list of seven “additional barriers” to “interoperability and effective data sharing”





• ISO/IEC 23000 – multi-media

• ISO 13527 – space data

More general work about tracking the provenance of data has been done within the World Wide Web Consortium, under the label “PROV”, and this may prove a more fruitful approach; see http://www.w3.org/TR/prov-overview/.

ESPRESSO D4.2 expects the knowledge management framework to have at least the parts covered in the following sub-sections.

9.2.3.6. Data value chain

ISO 9001 introduces the basic data value chain, of data, information, and knowledge. PAS 183 will have a short section on the data value chain in the context of a smart city.

The concept of ‘data value chain’ is central to European work on the “Digital Single Market”, but does not appear to have been explicitly standardised – discussion is in the realm of policy and strategy: to extract maximum value from the data, by recognising the existence of a value chain. The idea of ‘value chain’ originates from business management, in industrial production and distribution; a number of organisations have applied some of the concepts to data processing and management.

9.2.3.7. Knowledge management principles

A major concern for people confronted with the idea of a smart city is their privacy. Technologies of ubiquitous computing can provide the means for total monitoring of an individual’s behaviour. In order to overcome these concerns, potential users have to gain trust in the systems.

There are a number of publicly available sets if knowledge management principles, of various lengths (5, 7, 10, 12, 14!), but no consensus standard.

ESPRESSO D4.2 suggests a principle: “To be “smart”, the information available for all these kinds5 of decisions should be consistent, and coordinated across sectors.”

9.2.3.8. Component catalogue

Based on TOGAF, D4.2 states that a city will need to establish a (data) component catalogue. There are a number of sector specific standards that provide component catalogues, and PAS 182 (ISO/IEC 30182 working draft) proposes a way to integrate across them. However, a complete component catalogue depends on the full set of business requirements – the more you want to do, the more kinds of data you need to manage.

In several cases, the component catalogue is defined in the context of a data model.

• PAS 180 and the City Protocol Society ontology attempt to provide a common vocabulary across a city.

• OGC® CityGML – a reasonably detailed model concentrating on the built infrastructure in the city. Although at first sight CityGML standardises an exchange model, in practice many cities base their digital model of the city on

5 Strategic, analytical, operational, critical – as per PAS 182





it. Section 0 below examines the gaps of CityGML in order to fulfil the requirements of the extracted use cases.

• INSPIRE – the European Commission INSPIRE initiative has established a large catalogue of ‘spatial objects’ (more often called ‘features’), initially concentrating on environmental information, but in practice covering much of the physical and social geography of Europe.

• ISO 37120 Sustainable development of communities - Indicators for city services and quality of life – by establishing a set of indicators, this standard also establishes a set of data components that may be of use in monitoring city services and quality of life.

• ISO/TR 37102 Sustainable development and resilience of communities – Vocabulary provides a vocabulary, which could be a starting point for a component catalogue

• ISO 19152 Geographic information – Land Administration Domain Model

• ISO 29461 Building Information Models – various parts, providing detailed models for construction and facilities management, not only of buildings but of the built environment in general.

• OGC 15-111 Land and Infrastructure Conceptual Model – detailed model for construction and facility management, concentrating on things other than buildings

• To include smart procurement in the scope of a smart city, the component catalogue would include a lot of e-Commerce, such as invoicing and payment.

ISO 19110 Geographic information – Methodology for feature cataloguing describes an approach to describing the physical and social geography of the world which may be useful if an existing catalogue doesn’t provide what is wanted.

9.2.3.9. Data entity / business function matrix

TOGAF recommends that in a given architecture, the data entities defined in the component catalogue are cross referenced to the business functions defined in the business architecture and framework. This is probably not an area which needs a standard of its own.

9.2.3.10. Data lifecycle

ISO 15926 Industrial automation systems and integration - Integration of life-cycle data for process plants including oil and gas production facilities is generally recognised as being of wider application, potentially covering data integration, sharing, exchange, and hand-over between computer systems. In achieving this, it includes a generic data lifecycle, often known as “STEP” (from ISO 10303 Industrial automation systems and integration - Product data representation and exchange). However, this was designed to represent the lifecycle of technical installations and their components, and may not fit well to ‘data’.

The Data Management Association (DAMA) has a standard data lifecycle with seven phases, as part of their Data Management Body of Knowledge. But this is not an open consensus based standard.





9.2.3.11. Knowledge management process

ISO 9001:2015 includes some idea of a knowledge management process.

9.2.4. Engineering Framework

Work has just begun on ISO/IEC 30145-3 Smart City ICT Reference Framework – Engineering Framework. The initial working draft draws on the TOGAF Technical Reference Model, work done by the ITU Focus Group on Smart Cities, and Chinese work on smart city pilots. ESPRESSO D4.2 suggests adding an explicit “positioning layer” to the proposed model, to ensure that the sensors and all other layers have a common understanding of their position in relation to the physical city and to each other.

On a technical level, the smart city architecture includes the following layers:

Figure 1. Smart Cities Reference Architecture (ESPRESSO D4.2).

• A perception layer, where the components of the city (roads, vehicles, and end-users) are instrumented with sensors, actuators, tags, and readers.

o The perception layer technologies consist of these smart sensors, machine to machine (M2M) communications, and the Internet of Things (IoT).





o More advanced sensors could also be used to collect information, such as LIDARs (Laser Illuminated Detection And Ranging) for building 3D city models and so on

• A network layer, which enables data transmission between sensors and actuators and the application support layer, using either wired or increasingly often wireless connections.

o Some applications require real-time connections, others are suited for delay tolerant networks (DTN).

• An application support layer, which provides massive data processing capabilities using cloud computing.

o Cloud computing is expected to provide the support needed to address the dynamic, exponentially growing demands for real-time, reliable data processing peculiar to smart city applications

o A cloud service maintains the collected sensor data, enables its processing to produce services, and distributes the result for either human or machine use.

• An application layer, which analyses and processes data related, for example, to environmental monitoring and intelligent transportation

9.2.4.1. Positioning services

Geodetic, coordinate reference and global positioning related capabilities; but also mechanisms for precise positioning using e.g. fixed arrays of Wifi hotspots.

ISO 19161 Geographic information – Geodetic references – Part 1: The international terrestrial reference system will apply an ISO consensus approach to the long established International Terrestrial Reference System (ITRF) and systems based on it, such as GPS.

ISO 19111 Geographic information – Spatial referencing by coordinates defines the conceptual schema for the description of spatial referencing by coordinates – generally a city would not need these, simply choosing an existing coordinate reference system, e.g. WGS84, or a national grid. However, to accurately position things to any grid system requires a positioning service, and that service will make use of these underlying standards. Example: in Great Britain, OS Net.

9.2.4.2. Sensing services

Including sensor webs, crowd sourcing, and even “traditional” surveying of land, assets, construction – all the mechanisms by which data gets into the system of systems.

• OneM2M

• OGC SensorML and SensorThings

• ISO/IEC 29182

• ISO/IEC 20005

• ISO/IEC 30101





• ISO/IEC 30128

The AIOTI HLA puts the “thing” (in the IoT) at the center of value creation. While consistent with ISO/IEC/IEEE 42010, AIOTI WG3 does not provide a complete architecture description for IoT which conforms to the standard. An overview of architectural models is described in ISO/IEC/IEEE 42010 in Figure 2 below.

Figure 2. ISO 42010 architectural models

In the domain model, a User (human or otherwise) interacts with a physical entity, a Thing. The interaction is mediated by an IoT Service which is associated with a Virtual Entity, a digital representation of the physical entity. The IoT Service then interacts with the Thing via an IoT Device which exposes the capabilities of the actual physical entity. This is depicted in Figure 3 below.





Figure 3. IOT service interactions.

9.2.4.3. Data services

The AIOTI functional model describes functions and interfaces between functions of the IoT system. Functions do not mandate any specific implementation or deployment; therefore it should not be assumed that a function must correspond to a physical entity in an operational deployment. Grouping of multiple functions in physical equipment remains possible in the instantiations of the functional model. Figure 4 below provides a high level AIOTI functional model, referred to as the “AIOTI HLA functional model”.





Figure 4. AIOT HLA functional model.

Figure 5 below provides the mapping between oneM2M and the AIOTI HLA functional model. OneM2M specifies a Common Services Entities (CSE) which provide IoT functions to oneM2M AEs (Applications Entities) via APIs. The CSEs also allows leveraging underlying network services (beyond data transport) which are explicitly specified in oneM2M and referred to as Network Services Entity (NSE).





Figure 5 AIOTI oneM2M mapping

EIP SCC separate “Data Management” & “Data Access”; their section focuses on cloud technology and data storage standards. Their data access section includes SOAP, JSON, HTTP, etc. They also have a “Smart Data” section, mentioning the Open Knowledge Foundation and a number of EC directives.

EIP SCC list a number of IETF, ISO/IEC, ITU, ETSI, IEEE, and OASIS standards under “IoT”, alongside oneM2M.

Hypercat, published as BSI PAS 282, “Hypercat is an open, lightweight JSON-based hypermedia catalogue format (open specification) for exposing collections of uniform resource identifiers (URLs) for exposing information about IoT assets over the web. It is extremely simple, described by one participant as "the most that 40 companies could agree on" with a strong security model. Using HTTPS, REST and JSON, each Hypercat catalogue may expose any number of URIs, each with any number of resource description framework-like (RDF-like) triple statements about it. Hypercat allows a server to provide a set of resources to a client, each with a set of semantic annotations. Implementers are free to choose or invent any set of annotations to suit their needs. A set of best practices and tools is currently being developed.”

OGC: SOS and SPS, built over OGC SWE Common.





9.2.4.4. Application services

ITU-T has developed an IoT Reference Model which provides a high level capability view of an IoT infrastructure. The Figure 6 below provides an initial high level mapping of the ITU-T Y.2060 IoT Reference model to AIOTI HLA functional model.

Figure 6. ITU AIOTI mapping.

Note: for EIP SCC, this is generic services for the management of applications, allowing applications to message between themselves & users. In ESPRESSO D4.2, it seems more to be the applications themselves?

9.2.4.5. Business services

EIP SCC Applications: Business logic technology area.

9.2.4.6. Consumers

ESPRESSO D4.2 describes this layer “The Consumers Layer would include any smart city stakeholder who wishes to interact with and consume smart city services. These consumers could either be humans or other smart city systems (e.g. machine 2 machine, system 2 system).”





10. High level SWOT analysis

10.1. Overall architecture This section includes analysis of the whole standards picture against high level architectural components or knowledge areas.

Regardless of the different challenges, a critical requirement for the success of a Smart City deployment remains in making the relevant data available to the relevant applications in order to achieve the idea of a Smart City. The Smart City faces the integration of different and autonomous systems that are often vendor specific (waste collection and management, parking management systems, building management, etc.). Moreover, various technologies have been employed for each application. The Smart City vertical sector is thus a domain where several technological solutions are used for solving similar problems.

The Smart City concept has the following specificities6:

• Integration of a large number of heterogeneous equipment (sensors, actuators, edge devices, end user devices, enterprise and cloud systems, etc.).

• High data heterogeneity in terms of model, representation format, volume, precision, importance, etc.

• Use of various network and communications technologies (access network technologies and communication protocols).

• Interconnection of the newly deployed IoT systems with the legacy ones

As a first step, an initial SWOT analysis and identify main gaps of the Smart City high level architectural regarding current standardization together with a list of the existing standards and recommendations that are used on a European/Global level is provided as a guidance for the European cities.

Strengths Weakness

- CityGML increasingly use - Several ongoing European

initiatives on harmonization of the use of open data (City SDK, OASC, CKAN..)

- Initial advances on Context Management Information standardization (ETSI+FIWARE)

- Lack of harmonisation and consensus on the right technology.

- Overlap of standards, each pertaining to one specific vertical application

- Integration of different existent data assets is expensive.

- The use of multiple communication infrastructures is here to stay due to the characteristics of each communication technology (LoRa, GPRS/3G/4G, Satellite,

6 SmartM2M; IoT LSP use cases and standards gaps. ETSI. October 2016





etc. - Lack of Real Time/Context

information management standards and Cross-domain Context Information Models

- For the smart cities ISO 37120 is a good start, but not sufficient for the industrial implementation

Opportunities Threats

- Provide more technical guidance of compatibility with other standards this will help going beyond on-site infrastructure

- Define standards to integrate different data types.

- Provide a clear scenario with standardized protocols and applications, with a focus on interoperability

- Open source should be developed alongside the standards

- Need of a common ontology, but most importantly - to introduce incentives/business models that make it attractive for sensor developers and service providers to adhere to the specifications defined in the framework and ontology

- Today's focus is on proprietary and fast-to-market solutions. There is a gap in thinking about longer term technology, operational and business models.

- There is a missing consensus on privacy

- Lack of interoperable standards and ecosystem that make the development of M2M/IoT solutions affordable for many more applications than just a few major verticals (ITS, smart grids).

- Lack of offer of standard API in the devices/terminal offer for M2M/IoT application.

Following this analysis we found the following major Gaps:

- Lack of harmonisation and consensus on the right technology. - Standards fragmentation. - Integration of different existent data assets is expensive. - Interoperability of the platforms for IoT - Lack of Real Time information management standards

A practical approach is to use, as much as possible, existing standards and recommendations that are used on a European/Global level.

● Identify European initiatives about Smart City Standards harmonization (EIP SCC, AIOTA, FIWARE, OASC, CitySDK, )





o EIP SCC: EIP-SCC also emphasises the importance of creating interoperable solutions across cities in Europe. Several organisations have signed a memorandum of understanding with the goal of moving towards more interoperable urban platforms. The aim is to speed up the smart cities market by focusing on interoperable platforms, enabling cities to freely mix products from different suppliers, and leaving the traditional approach of custom-built and proprietary solutions behind.

o CitySDK: CitySDK was developed in an EU-funded project to allow cities to release their data sets so that developers are able to re-use it. The project was focused on the areas of smart participation, smart mobility and smart tourism. (CitySDK 2014). The CitySDK has defined a harmonised approach between several European cities to creating open data and programming interfaces for urban data.

o CityGML: There are potential ways to exchange city data, as CityGML, which is used increasingly in France, Belgium, Holland, Nordics. However, there is no single format to handle all the required content and use cases. Software vendors are developing Hybrid solutions combining with open standards (CityGML, KuntaGML in planning, LandXML (inframodel) in infrastructures, InfraGML (standard in the making to replace LandXML) and IFC in buildings.

o FIWARE: This platform was developed in the FIWARE project to come up with a core platform for the future internet. It should provide a sustainable ecosystem for innovative service providers developing new applications and end-users/consumers actively participating in content/service consumption and creation. The platform consists of cloud hosting, data management, application framework, interfaces, security mechanisms and others. The standard FIWARE proposes to describe how to collect, manage, publish, and notify about changes of context information is called FIWARE NGSI.). FIWARE has became cornerstone in frontrunner Smart Cities standardization initiatives FIWARE collaborate with TMForum in the adoption and extension of the TMF Business Ecosystem APIs to build a true data market ecosystem and to contribute to the evolution of those standards, as well as the adoption by TMF of the NGSI API for smart application environments

o The Open and Agile Smart Cities (OASC) initiative: This initiative, kicked off in 2015, when a group of cities agreed which technologies would be used as common de facto standards. Their goal is develop together a digital single market for Smart Cities where any solution that is developed will be valid for several cities without requiring any adaptation whatsoever. This initiative tries to adopt a very basic set of standards. Basically cities joining the OASC initiative commit to adopt three mechanisms:

• One single API for managing and access to context data describing what is happening in the city at any moment. The standard of choice was FIWARE NGSI.

• Commonly defined Data models, ensuring that data and its meaning is equivalent across cities.

• Mechanisms for publishing and sharing not only historic but real-time datasets as Open Data.





o FIWARE, OASC and TM Forum have built the components to make an economy of data possible. Using the FIWARE platform and common data models, cities can also share best practices and speed up the development of a Global Digital Single Market for Smart Cities.

o AIOTA: The Alliance for Internet of Things Innovation (AIOTI) was launched in 2015 by the European Commission and several relevant stakeholders (mainly industry) in the IoT domain to create a dynamic European ecosystem that can boost the market in its multiple application domains. The alliance has also a Smart Cities Working Group which aims to create a city centric ecosystem of state-of-the-art, viable, technologies which apply the IoT technologies and integrate it with the concepts of Internet of Energy (IoE), Internet of Vehicles (IoV), and Internet of Buildings (IoB)

o Spatial and Environmental Data: In some specific application areas, there are regulations in place that oblige cities and other municipalities to follow particular European standards. The most influential is location-based services, which must follow the scheme laid down in European law (INSPIRE Directive).

10.2. SWOT: Smart City sectoral Use cases: Smart Parking and Water Management Following the main Sectors identified by the use cases defined in ESPRESSO, D 2.6. We provide an initial SWOT analysis regarding each standardization sectoral issues.

10.2.1. Smart Parking

Smart parking involves using low-cost sensors, real-time data collection, and mobile-phone-enabled automated payment systems that allow people to reserve parking in advance or very accurately predict where they will likely find a spot. When deployed as a system, smart parking thus reduces car emissions in urban centers by reducing the need for people to needlessly circle city blocks searching for parking. It also permits cities to carefully manage their parking supply. The major challenges are associated with multiple data owners and lack of standardization, there are no citywide solutions across fragmented public and private parking providers. Data tends to have many owners and is not standardized or accessible in a way that would allow software developers to turn it into user-friendly applications. Developing smart parking solutions within a city requires data standardization and management; mobile phone integration; hardware and software innovation; and coordination among various stakeholders (on and off street parking facility owners, business owners, municipalities, transportation authorities, customers, and software developers).





Strengths Weakness

- Availability of traffic data standards (Datex II, SIRI)

- Traffic data handling and analysis (fusion, cleaning, processing, mining, etc.)

- Early stage of development of real time traffic information systems

- Very different network technologies and communications protocols are used.


- Look for open protocols to send the data

- Harmonization of regional standards

- Securing high network availability, with certified performance figures, is necessary

10.2.2. Water management Water observations data are a key element of water resources information systems. The need to accurately monitor, assess and forecast the availability, condition and use of water resources is now more vital than ever. There is a need to define standards for information about climate and environmental data so that data can be easily exchanged among water authorities, meteorological bureaus and other environmental stakeholders. Heterogeneous connectivity is only one part of the challenge7. Even more importantly is the interoperability at the data layer as a diverse set of sensors from different manufacturers produce heterogeneous data flows with different representations. A similar heterogeneity is inherent in the controllers and actuators in a water network. Analytics and control processes are only able to make effective decisions if the heterogeneous sensor readings can be interpreted adequately and translated into appropriate control signals. To handle this complexity at in a machine-process able way, increased semantic interoperability is needed. The World Wide Web Consortium (W3C) is an important standardization body to be considered. Recent efforts such as the Semantic Sensor Network (SSN) ontology provide important foundations that target more broadly the Internet of Things scenario. More specific efforts for the water domain are also starting to emerge such as the Semantic Water interoperability Model (SWIM).

7 Intercity Report Phase 2





Strengths Weakness

- Water ML 2.0 will provide a standard encoding for data transfer to support the input and update of data into databases, standard data delivery interfaces from databases and applications and the development of applications with a standard data import/export mechanism

- The lack of integration of current solutions

- The inexistent common ICT reference model for water management processes.

- Heterogeneous connectivity - Diverse set of sensors from

different manufacturers produce heterogeneous data flows with different representations


- Cooperation between the IoT community and energy community.

- Increased semantic interoperability is needed.

- No clear winner among all existing IoT architectures.

- Lot of standards are from the sensor network and the energy/water communities.

-‐ Smart environment data, especially those from utilities (energy/water) can be very sensitive. Security and data privacy standards are necessary. The lack of these standards prevents large scale deployments.





11. Low level SWOT analysis on key standards

This section includes more detailed SWOT analysis on the key standards identified for the pilots.

11.1. CityGML Starting from the development of a conceptual Smart City Information Framework to be built around CityGML as a reference data model and encoding with data services to integrate and process data efficiently in Smart City enterprise applications. On top of this conceptual framework, the project will map current standards, in line with potential actions from other European plans and guideline documents. Particular emphasis will be on the development of framework components that allow the integration of geo-located data, as location information is a major enabler of Smart City technology benefits.

Large countries, such as Germany and the Netherlands, are digitising their cities into CityGML format. They have described a national application domain environment (ADE) that explain how the format will be used (CityGML.org, 2015).

Strengths Weakness

- Data model supported in both commercial & open source software, both at the back end (database) and for web visualisation

- Possibility to extent standard and integrate domain information

- Via Application Domain Extension, or via generic city objects and attributes

- It is possible to create simple ADEs very quickly.

- ADEs may get complex; the development of bigger ADEs (e.g. Energy ADE) may take several years.

- No software known which can handle ADEs in a generic way

- Many existing models were created purely for visualisation, and are not good enough for simulation

- Not optimised for direct visualisation

- No support for user interaction/participation - putting ‘comments’ into models

- Doesn’t support versioning/history (although the underlying database technology may)






- CityGML is one of the specification options in the EC INSPIRE Directive, which requires public authorities to provide data about Buildings

- CityGML has strongly influenced development of the INSPIRE Building model, thus they share common concepts

- Integration of BIM view (of the world ‘as planned’) with CityGML view (of the world ‘as observed’)

- Developers moving away from XML encodings

Following this analysis, the following Gaps have been found:

11.1.1. Add new objects (i.e. for urban insertion analysis)

In order to evaluate or communicate urban planning scenarios to stakeholders or citizens the creation of planning scenarios is important (e.g. adding or removing buildings from the city model). In addition, this would allow citizens or stakeholders to give feedback on the proposals. However, planned objects often exist as BIM (Industry Foundation Classes - IFC) models. The problem here is that there are modelling differences between BIM and CityGML. The fundamental difference is that BIM sees the world as planned while CityGML sees the world as observed. This leads to differences in modelling paradigms, in the geometry representation, in the spatial reference, etc. Thus, in order to integrate planned objects into the 3D city model the BIM models need to be transformed to CityGML. However, this is not an easy task and subject of intense research. Thus, there is a gap on how to integrate planning scenarios into the city model. Since several years, OGC and buildingSMART as standardization bodies for CityGML and openBIM/IFC respectively are joining forces to tackle the interoperability across the building life cycle and complementary infrastructure systems.

Figure 7. Result of an urban flood vulnerability assessment. Visualized are relative losses of inundated buildings at a simulated water level.





11.1.2. Integration of sensor and dynamic data Another topic of current interest is the integration of sensor or time-dependent and dynamic data into 3D city models (cf. OGC Future City Pilot Phase 1). As there are more and more sensors out there (e.g. sensing air pollution), there is a need to integrate the different sensors deployed in the city in one 3D city model. This would enable to get an overview of the current situation in the city and to relate the measurements of different sensors. At present, 3D city models maintained by municipalities typically provide a static view of the topographic city objects at a given point in time with little or no dynamic or time-dependent thematic information. The integration of sensor information is not foreseen by CityGML (v2.0), which is clearly a gap.

Moreover, to represent the evolution of the city (e.g. changing owner of a building, or changing energy demands) time-dependent properties are important. In addition, time-varying properties may be useful for simulations (e.g. changes in solar irradiation levels or location). Currently CityGML (v2.0) is not able to represent time-dependent and dynamic properties. It only allows to store properties as static values [11]. The time-varying properties may be variations of spatial properties (e.g. change of a feature’s geometry) or the variation of thematic attributes (e.g. change of the building’s mean temperature), or variations with respect to sensor or real time-time data. This lack is a technological gap when it comes to represent changing properties of the city or city objects.

11.1.3. Enable Interoperability

In order to integrate data from different sources or sectorial systems into the 3D city model, interoperability between the data models needs to be ensured. CityGML provides two concepts to integrate information from different sources with concepts/objects that are not explicitly modelled in CityGML: 1) generic objects and attributes, and 2) Application Domain Extensions (ADE).

Figure 8. Result of an urban wind field simulation.

Generic attributes allow augmenting any city object by additional attributes without changing the CityGML schema in order to model and exchange features and thematic information not represented in CityGML. This option enables an easy integration of





sector information. However, extensions using this generic mechanism are not formally specified.

An Application Domain Extension (ADE) creates a formally specified extension to the CityGML model. An ADE may introduce new object types or new properties to existing CityGML classes. Usually, information communities interested in a specific application field define an ADE. An ADE can even be standardized (e.g. by the OGC). Hence, there is a potential gap when there is no ADE available for the sector information that needs to be integrated into the city model (cf. urban energy modelling).

11.1.4. Urban Simulations/Scenarios and Decision Support

Currently, urban simulations are a subject undergoing intense study [8]8,9,10. The simulations are utilized in decision-making processes regarding questions concerning scales from a single district to the whole city. The simulations shall answer questions regarding the city’s development (e.g. environmental simulations such as energy or CO2 modelling) as well as for decision support in emergency cases (e.g. disaster management such as floods or blast simulations). In order to represent the real world objects in the most realistic way, the calculations make use of semantic 3D city models. Thus, the spatial resolution and geo-location of the objects in interest can be utilized.

The main challenge here is to bring together 3D city models with their application beyond visualization. This issue bears some gaps, which will be explained in the following.

Environmental simulations or scenario calculations regarding the city’s future development may be the simulation of CO2 emissions or energy efficient retrofitting scenarios of buildings as well as the simulation of flood vulnerability assessment. For instance, the location of development areas may be chosen based on flood vulnerability assessment simulations for different inundation and construction scenarios, such that the overall vulnerability will be less (see Figure 1). Another example is urban energy modelling at the city scale level. However, at present BIM models at the building scalre are used as the exchange support between different energy modelling tools. Currently, there is no standard for urban energy modelling at the city scale as CityGML does not contain energy related objects and attributes [8]. Thus, there is a gap when using CityGML in order to do citywide energy modelling: the lack of expert information in order to answer professional questions.

When doing numerical simulations, e.g. blast, flood or wind-field simulations (Figure 2), a high degree of geometric, topologic, and semantic consistency is needed. In addition, numerical simulation engines do not support exchange formats of 3D city models (e.g. due to different geometrical representations). This leads to another technological gap between CityGML and the simulation platforms, namely that simulation platforms usually cannot handle CityGML models, which is a lack of interoperability. The reasons for this gap may be different data capturing and modelling practices and methods.

8 http://local.climate-‐kic.org/ 9 http://ssd-‐moabit.org/?lang=en 10 http://www.gfz-‐potsdam.de/en/media-‐communication/news/details/article/urbanes-‐hochwasserrisiko-‐3d-‐stadtmodelle-‐als-‐analysewerkzeug/





11.1.5. Work in a web browser and on low-end mobile devices In order to allow easy access for the general public the 3D city model needs to be accessible via a web browser and mobile devices. However, as CityGML is intended as 3D geospatial information model but not as a 3D graphics format, it is not optimized for direct visualization. The 3D visualization is the result of a portraying process applied to the city model. There are several tools available in order to execute this portraying process. The Importer/Exporter of the 3D City Database11, which is a free geo database to store, represent, and manage virtual 3D city models, is able to export a GL Transmission Format (glTF) representation of the city model, which can be visualized by the open-source WebGL virtual globe Cesium12. Modern web browsers can access these visualizations without the need for any plug-in, even on mobile devices.

Nevertheless, the performance is not sufficient on low-end mobile devices, which is another technological gap.

11.1.6. Integration with user interaction / participation services

A prerequisite for the integration of user interaction and participation services is the performant visualisation of the city model in a web browser. Based on this it is possible to construct participation services. That means, the user can browse through the visualization of the 3D city model, give feedback and leave comments (e.g. as tickets) on the current situation in the city or on proposals.

The visualization of CityGML based 3D city models on web browsers can be done easily. However, the existing visualization solutions lack in support of user interaction and participation services.

11.1.7. Management of versions and history of the city

Urban planning, architecture and business development often address planning alternatives of buildings or other structures. These alternatives may be presented to the general public or a reviewing body (cf. Section 10.1). In addition, it may be important to answer question such as “How did the city look like at a specific point in time?” and “How did it change between different points in time?” in order to represent the evolution of the city. This requires mechanisms to manage different versions and the history of the city model. However, CityGML (version 2.0) does currently not enable the management of versions and the history of the city, which is a technological gap.

11.1.8. Summary and classification of gaps

The following table summarizes and classifies the elaborated gaps:

Nature of the gap

Area Criticality

How can standardization or regulation improve this?

Lack of integrating planning

Integration/Interoperability 5 Focus on semantic interoperability between different modelling paradigms

11 http://www.3dcitydb.org 12 http://cesiumjs.org/





scenarios and enable versioning Lack of harmonization and lack of interoperability

Communication and Connectivity (application level); Integration/Interoperability

5 Focus on semantic interoperability and extent the common ontology

Lack of expert information in the common city wide ontology

Integration/Interoperability 4 Extent the common ontology in order to enable the modelling of the expert information

Lack of representing time-dependent properties

Integration/Interoperability 4 Extent the common ontology in order to enable the modelling of dynamic properties

Lack of sensor integration

Integration/Interoperability 4 Extent the common ontology in order to enable the integration of sensor data

Lack of support for low-end mobile devices

Communication and Connectivity (application level); Applications

4 Focus on standard service interfaces for 3D geodata portrayal

Lack of user interaction and participation services

Communication and Connectivity (application level); Applications

4 Currently unclear

Lack of managing versions and history of the city

Integration/Interoperability 4 Extent the common ontology in order to enable the management of versions and history

11.1.9. How can we solve the identified gaps?

Standardization efforts may solve many of the gaps identified above. Thereby, the city models stay replicable and scalable to other cities. In the following possible solutions to the most important gaps are proposed.

11.1.9.1. Solving the lack of integration of planned buildings

In order to communicate different planning scenarios, which are often created as BIM/IFC models, to stakeholders or the public, the models need to be integrated into the city model (GIS). Currently, the topic of integrating BIM models into GIS models and vice versa, is a subject undergoing intense study (cf. OGC Future City Pilot Phase 1). Löwner et al. [12] propose a harmonization between CityGML and IFC for the next version of CityGML (version 3.0). They constrain the transformation in a way that parts of a building, which can already be represented in CityGML (e.g. rooms, walls, roofs, floors), can be transformed easily from IFC to CityGML. Their proposal includes the extension of CityGML with a volumetric representation of certain structural elements (e.g. walls, roofs), similar to IFC. However, as GML and thus CityGML allow to represent volumes only by boundary surfaces and IFC mostly use parameterization





or Constructive Solid Geometry (CSG) the transformation from CityGML to IFC may be problematic.

Hence, if the proposal is accepted, the gap of integrating IFC models into CityGML will become smaller with CityGML version 3.0. When combined with the possibility to manage version of the city model (cf. Section 11.5) it is possible to manage and present parallel scenario versions. However, the transformation from CityGML to IFC is still an open issue.

Instead of converting data between CityGML and BIM, and hence between two domains with different scopes and applications, linking CityGML objects with their BIM counterparts using sematic web technologies offers an alternative approach for data integration. This, however, would require a common upper-level ontology that would allow queries to be answered from either model. With the development of the InfraGML standard for infrastructure modelling, OGC and buildingSMART have proven that this approach can be successfully realized. This could be used as a blueprint to close the gaps between CityGML and BIM.

Figure 9. Example of an urban 3D scene rendered on the client. Accessible via:

http://demo.virtualcitymap.de/.

11.1.9.2. Solving the lack of harmonization and interoperability, the lack of expert information

CityGML already provides a mechanism to overcome the gaps of harmonization and interoperability as well as the lack of expert information in the common citywide ontology, namely by the definition of ADEs.

One example of an ADE that is currently developed is the CityGML Energy ADE13. This ADE defines a standardized data model based on CityGML for energy analysis on the

13 https://github.com/cstb/citygml-‐energy/





city scale. It aims to be a reference exchange data format between urban modelling tools and expert databases. The ADE has been developed since 2014 by an international consortium of urban energy simulation developers and users. The Energy ADE extends CityGML (v2.0) with energy related entities and attributes which are needed to perform energy analyses at urban scale. These analyses may be energy demand or solar potential analysis, or the simulation of low-carbon energy strategies.

In order to overcome the gap of harmonization and interoperability the “Energy ADE considers the existing international building and energy data specifications, like the INSPIRE Directive of the European Parliament, as well as the recent US Building Energy Data Exchange Specification (BEDES), and integrates their relevant energy-related attributes” [8]. This example shows that an ADE helps to solve the gap of harmonization and interoperability between CityGML and different data specifications (e.g. BEDES).

Additionally, the ADE provides information required by different urban energy models and simulation tools. These are for example standard energy balance methods based on ISO 13790 and software programs such as CitySim or EnergyPlus [8]. Thus, an ADE solves the lack of expert information in order to use the city model as an input for urban simulations.

Figure 10. Example of an urban 3D scene rendered on the server. Accessible via: http://www.3dcontentlogistics.com/loesungen/demos/berliner-3d-stadtmodell-

smartmap-web/.

11.1.9.3. Solving the lack of representing time-dependent properties and integration of sensor data

Work is already underway to solve the gap of integrating time-dependent properties and sensor data into CityGML based 3D city models. So called ‘dynamizers’ [11] will close this gap. Dynamizers enable feature properties and associations to be variant over time. The variants may affect spatial properties as well as thematic attributes. Thus, properties of the city model or city objects can become dynamic. In addition, dynamizers can be linked to sensors (e.g. via the Sensor Observation Service (SOS)





interface). That means, real-time dynamic data from sensor observations (e.g. air pollution data) can be integrated into the city model as well. Thus, the concept of dynamizers, which is intended to be introduced into CityGML 3.0, will help to solve the gaps of representing time-dependent properties and integrating sensor data.

11.1.9.4. Solving the lack of support for low-end mobile devices

There is a new OGC standard defining service interfaces for 3D geodata portrayal, namely 3DPortrayalService (3DPS). The standard defines interfaces in order to visualize 3D geospatial data in a web browser or on mobile devices. It is sometimes compared to a WebMapService (WMS) for 3D models. The service defines interfaces to request either geometric 3D scene data or a 3D view of a scene represented as images. If the 3D scene is delivered, it is rendered on the client. This has the advantage that the user can interact with the visualization, for instance changing the perspective or interacting with objects. If the 3D view is delivered as images, the rendering is done on the server, which means that only the rendered images are transmitted to the client. This allows the high quality 3D visualization on any device including low-end mobile devices [10].

Hence, the 3DPS closes the gap to a standardized access to 3D portrayal tasks as well as the gap of support for low-end mobile devices.

11.1.9.5. Solving the lack of managing versions and history of the city

[9] Proposes a concept solving the issue of managing versions and the history of the city as an official extension of the next version of CityGML (v3.0). The approach proposes an extension to the CityGML data model which supports different versions and version transitions in a city model. This allows the identification and organization of multiple states of the city model. Therefore, the maintenance of the city model’s history and evolution is supported which allows to answer the questions raised above: “How did the city look like at a specific point in time?” and “How did it change between different points in time?”. Additionally, the proposed approach supports the management of parallel alternative planned versions of objects at the same time. As the different versions of the city model can be used in an interoperable exchange format in one dataset, software systems can use these datasets to visualize the city’s evolution or to work with all the versions. In addition, this concept supports the management of buildings in planning scenarios. Thus, the proposed concept may close the gap of managing versions and the history of the city.

11.1.9.6. Solving the lack of user interaction and participation services

In order to solve the gap of user interaction and participation services some other gaps need to be closed first. One of these gaps is the management of different versions of the city in order to manage different planning scenarios. One more gap that needs to be closed is the standardized access to 3D portrayal tasks in order to visualize the different scenarios. After these gaps are solved an additional service for user interaction and participation needs to be added.

There is no standardization effort known solving this issue. However, adding simple services, which allow a user to comment on objects in a 3D web-visualization of a 3D city model, is a technically feasible task.





11.1.10. Conclusions concerning CityGML The use cases together with their requirements defined by the two ESPRESSO pilot cities Rotterdam and Tartu reveal some gaps in the use of CityGML based virtual 3D city models. These gaps range from the integration of planning scenarios with user interaction and participation services and the management of versions and the history of the city to the representation of time-dependent properties and the integration of sensor data as well as solving the lack of harmonization and interoperability between different sectors. As the previous sections have shown, standardization efforts are undertaken in order to close most of these gaps, such that CityGML based 3D city models will fulfil the requirements.

11.2. Sensor Things SensorThings API[1] is an Open Geospatial Consortium (OGC) standard providing an open and unified framework to interconnect IoT sensing devices, data, and applications over the Web. It is an open standard addressing the syntactic interoperability and semantic interoperability of the Internet of Things. It complements the existing IoT networking protocols such CoAP, MQTT, HTTP, LowPAN. While the above-mentioned IoT networking protocols are addressing the ability for different IoT systems to exchange information, OGC SensorThings API is addressing the ability for different IoT systems to use and understand the exchanged information. As an OGC standard, SensorThings API also allows easy integration into existing Spatial Data Infrastructures or Geographic Information Systems.

The OGC SensorThings API14 simplifies and accelerates the development of IoT applications. Application developers can connect to various IoT devices and create innovative applications without worrying the daunting heterogeneous protocols of the different IoT devices, gateways and services. IoT device and system manufacturers can also use OGC SensorThings API as it be embedded within various IoT hardware and software platforms, so that the various IoT devices can effortlessly connect with the OGC standard-compliant servers around the world. In summary, the OGC SensorThings API is transforming the numerous disjointed IoT systems into a fully connected platform where complex tasks can be synchronized and performed.

The OGC SensorThings API is developed based on the existing OGC Sensor Web Enablement (SWE) standards. The OGC SWE standards enable all types of sensors and actuators discoverable, accessible and re-usable via the Web. These standards have been widely implemented around the world. SWE standards, however, are as complex as necessary to support tasks such as controlling Earth imaging satellites and archiving national libraries of geological observation data, and thus are, too "heavyweight" for the resource-constrained IoT applications. The OGC SensorThings API can be considered as a lightweight SWE profile suited particularly for IoT applications. As a result, the OGC SensorThings API is a new and efficient API based on the proven and widely implemented SWE standard framework.

14 http://www.opengeospatial.org/projects/groups/sweiotswg.





Strengths Weakness

- A new and efficient API based on the proven and widely implemented SWE standard framework.

- Simplify the connections between devices-to-devices and devices-to-application

- Permits the proliferation of new high value services with lower overhead of development and wider reach

- Lowers the risks, time and cost across a full IoT product cycle

- The problem with an API-led approach is that the design may be too complex for device manufacturers


- The OGC SensorThings API can also be embedded within various IoT hardware and software platforms

- Security and control concerns - Upcoming new open-source

lightweight IoT integration solutions

11.3. LORA The LoRa Alliance and its members, amongst which include many industry leaders and Mobile Network Operators, see this as a major step towards international standardization in LPWAN, catalysing network deployments and certified sensor manufacturing around the world. The Alliance members have collaborated; sharing knowledge and experience and intensively tested the LoRaWAN R1.0 specification to ensure readiness for the entire ecosystem. This will drive the global success of the LoRaWAN Low Power Wide Area Networks (LPWANs) and guarantee interoperability in one open carrier grade global network. Communication between end-devices and gateways is distributed via different frequency channels and data rates. The selection of channel and data rate is a trade-off between communication range and message payload. LoRaWAN data rates range from 0.3 kbps to 50 kbps. To maximize both the battery life of the end-devices, network capacity and ease of deployment, and to easily scale, the LoRaWAN network server manages the data rate for each connected sensor via an Adaptive Data Rate algorithm (ADR). This unique optimization is based on advanced information such as SNR, RSSI, PER and channels to ensure optimal performance under the local radio conditions.





National LPWAN's for the Internet of Things (IoT) have strict requirements in terms of security for the each individual user and typically require local, or in country, hosting. To ensure this for the user, the application or the network owner LoRaWAN includes:

• Unique Network key (EUI64) and ensure security on network level

• Unique Application key (EUI64) ensure end-to-end security on application level

• Device specific key (EUI128)

Strengths Weakness

- Standard that uses a different technique to maximize range while minimizing transmission power

- Guaranteeing interoperability and standardization of Low Power Wide Area Networks internationally

- Proprietary standard - No ISM (industrial, scientific and

medical) band standard published yet for far some Asian countries such as; Korea and Japan


- LPWANs have momentum and are proliferating. LoRa alliance membership tripled last year

- Applications like Smart meters, environmental monitoring, Smart Grid

- LPWAN capabilities will eventually be integrated into 5G service base stations

- LoRaWAN is being deployed for nationwide networks by major European Telcos

- New open standards as NB-IoT technology standardized by 3GPP standards body





12. Conclusions and main recommendations

At this stage in ESPRESSO, these remain preliminary conclusions. This gap analysis depends on both the standards framework (D2.4) and the architecture framework (D4.2). Both of which depend on evolving requirements from the use cases and cities, as they operate their pilots. As yet, the standards framework only covers non-technical (management and information) standards. The EIP SCC will be considering whether the architecture framework suits its requirements. Most likely, both documents will evolve.

At this stage, it seems that:

• The business architecture for a smart city is reasonably well defined, but the standards have not been used much yet

o The exception in this area is that TOGAF expects business architecture to contain “business constraints”, and we have not found any standard approach to understanding or documenting the constraints which smart cities face.

• Similarly, there are standards for a business process framework, but the only fully international one is specific to the development and operation of infrastructure. ISO/IEC JTC1/WG11 has a project for this: 30145-1.

• There are a number of national standards towards a knowledge management framework, and it is likely that common ICT standards will be appropriate in areas like privacy, security, and quality. ISO/IEC JTC1/WG11 has a project for this: 30145-2.

o The gaps which we have noted are for knowledge management principles - there are a lot of publications available, but perhaps not a formal standard.

o Similarly, there are commonly used data life cycle models, but we have not found a formal standard.

o There are a lot of possibilities for a component catalogue; or to put it another way, a lot of competing data models. This is probably a weakness. The ESPRESSO and EIP SCC pilots should go some way to exploring which standards work well together.

o Several cities have successfully used a CityGML based model to improve their city management. This has highlighted a number of areas for improvement, which are described in section 0 above.

• A lot of groups have been working on aspects of an engineering framework. ISO/IEC JTC1/WG11 has a project for this: 30145-3; it remains to be seen whether this can draw together other work, such as that at ITU.

o Within the engineering framework, there are a bewildering variety of standards for sensing services, and for network communications. It is probably important that there are choices at the network level, to suit different environments, but it can be hard for a city to choose the right mix of wired and wireless, internet and telecommunications, let alone the





plethora of “standard” protocols operating at higher levels. Both ETSI and EIP SCC list six or seven standards bodies working in this area.

o In theory, a layered approach to communications (whether the OSI seven layer model15, or the internet TCP/IP four layer model16) could result in interoperability independently of the underlying layers. But this does not seem to be the case in practice.

So the most important area for further work at present is not where there is a lack of standards, but where there are so many standards bodies working separately: network communications, and protocols running over those.

12.1. Future of this document In July 2016, IEC organised the World Smart Cities Forum, specifically to explore “the most important factors that hinder the broad roll out of Smart Cities today”, and consider how the standards development bodies (ISO, IEC, ITU, and others) can satisfy this. The report was due in November 2016, and was expected provide significant insight into planned work. Instead, ISO plans to host a similar meeting in late 2017.

Earlier this year, ISO/IEC JTC1 set up a working group to develop standards for the ICT aspects of smart cities. It held its second meeting in September 2016, and will continue to develop a standard for Smart City ICT reference architecture throughout 2017.

15 ISO/IEC 7498-‐1 or ITU-‐T X.200 16 Internet Protocol Suite, IETF RFC 1122, 1123 and so on.





13. Annex 1 GAP Analysis Methodology

In Standardization needs, the general suitability of various standardisation efforts in various SDOs is evaluated in terms of stable standards which can be used. In the sections below, the Smart City requirements are analysed to determine which standard is most relevant and what are the gaps in functionality between the existing status and what is needed within ESPRESSO. Based on that analysis, a number of action items will be created within each technical area, defined to fill those standardization gaps.

13.1. Action 1: Investigate Smart City Standards gap analysis. In the Smart City context understanding the demands of the cities towards standardisation is an absolute need. Based on possible actions as follow-this, understanding how these demands are met – or not yet met - by the current status of standards; and how coordination within the Smart City standards landscape could take place is essential.

First, what we do consider as gaps?

• Gaps and missing standards or regulations, missing APIs, technical interoperability profiles that would clarify the use cases, duplications that would require harmonization

• These "gaps" are the main point of interest of the present report. Three categories of gaps will be addressed:

o Technology gaps. Some examples in this category are communications paradigms, data models or ontologies, software availability.

o Societal gaps. Some examples in this category are privacy, energy consumption, ease of use.

o Business gaps. Some examples in this category are siloed applications, value chain, investment

To achieve such harmonisation, we will carry out a gap analysis that will leverage on the following sources of information:

• First selection of Gaps:

o Identifying the most important gaps in the several reports from different SDOs bodies of potential interworking frameworks (D 2.1 and D2.4).

o Identifying any remaining gaps to be addressed in standards to achieve the Smart city vision

• The identification of gaps additionally will be completed with a survey whose results will help us identify missing functionalities in the Smart City standards landscape. The identification and recognition of these “gaps” may help their resolution by the Smart City community, thus fostering the development of future solutions and expanding the Smart City ecosystem.

o The survey considers technical as well as other characteristics of Smart Cities in specific “vertical” application domains, e.g. home automation, smart mobility and wearable medical devices, etc. as well as ”horizontal”





ones, not specific to any particular vertical domain but aiming at common standards, protocols and solutions applicable to as many vertical domains as possible

• Maintains contacts at the highest level with ETSI, key European and international SDOs that could be shaped in organising roundtables or other high-level events with participation of SDO key figures, policymakers EU and global industry and the Commission

13.2. First set of Standards extracted from the SD Reports and Survey, “Prioritization” report. The current Smart City Set of Standard is the first attempt in building the framework of standards which can support Smart City deployment in Europe, however also stating in the clearest way what is available and what is coming. Generally and in accordance with several SDO report findings, it is expected that a majority of standards to help implement Smart Cities in Europe is already available and mature.

A prioritisation of standards gaps and related standardisation work:

• Identifying the most important gaps in the several reports from different SDOs bodies of potential interworking frameworks (D 2.1 and D2.4).

• ESPRESSO will convey a survey to all members of the SmaCStak n in order to evaluate in a balanced way what are the most important standardisation areas to consider. This survey will show a quite good alignment of stakeholders on the highest standardisation priorities needed to achieve in order to in order to ensure the most seamless deployment of Smart Cities in Europe and to provide a frame from interoperability between all Smart Cities components. The most important gaps expressed through the survey will be mainly focused on (but not restricted to):

o Data model harmonisation. This concerns mostly the integration of field level, with remote monitoring and control levels, as well as integration of smart metering into smart grid systems;

o Protocols (including data-models and communication services) for connecting smart producers and consumers, including the associated aggregations levels;

o Connecting new types of generators, while ensuring the expected level of quality and grid stability, as well as enabling new types of operating distribution networks;

o Deploying cyber-security. It is also important to consider that this list of gaps will be reassessed all along the mandate duration, in order to take into account the outputs of the security, architecture and processes-related works.





14. Annex 2: Results from the ETSI survey on IoT for Smart Cities

14.1. Survey results for the Smart Cities vertical domain – Technical Nature of the gap

Area Criticality


Lack of harmonization and consensus on the right technology

Communication and Connectivity (network up to application level); IoT Architecture ; Security and Privacy

4 Agree on very few common standards

Lack of harmonization and lack of interoperability

Communication and Connectivity (application level); Integration/Interoperability

5 Focus on semantic interoperability and a drive to use new technologies to push the market forward.

Integration of different existent data assets is expensive

Communication and Connectivity (network and service levels)

3 Define standards to integrate different data types

14.2. Survey results for the Smart Cities vertical domain – Societal Nature of the gap Area Critical

ity How can standardization or regulation improve this?

Privacy and security aspects not sufficiently covered, developed and not real, mature models/solutions seem to be available. This could limit IoT adoption Another social gap is that many decision makers does not have a real understanding of practical potentialities IoT can provide and a dissemination campaign would be useful addressing mainly Public admins

Communication and Connectivity (network and service levels); Integration/Interoperability; IoT Architecture ; Security and Privacy

3 IoT and big data pose new challenges to an acceptable model of privacy and security management and rules (in terms of civil rights and "industrial privacy/security" guarantees: it is necessary to find out new models /approaches





14.3. Survey results for the Smart Cities vertical domain – Business Nature of the gap

Area Criticality


Standards fragmentation

Integration/Interoperability 4 Consolidation and/or better

interworking

Too many standards to follow. Even customers don't know which Standards to follow, demand or expect to be applied.

Integration/Interoperability; Applications life-cycle support; IoT Architecture ; Devices and sensor technology; Security and Privacy

4 First, to set up clear standards framework, using also existing standards, second, implement these standards. Only written is not enough. For the smart cities ISO 37120 is a good start, but not sufficient for the industrial implementation.

14.4. Currently, the main gaps are the following: • Service platform: no clear winner among all existing IoT architectures. Each

service platform is currently positioning among the other one through the proposition of underlying interworking plugins.

• Communication infrastructure: the use of multiple communication infrastructures is here to stay due to the characteristics of each communication technology (LoRa, GPRS/3G/4G, Satellite, etc.). IP is likely the best candidate as a convergence layer.

• Data interoperability: A lack of global data model and/or translation mechanisms between different specific models is clearly a big issue.

14.5. Related Areas regarding potential gaps identified by ETSI

14.5.1. Communication and Connectivity

Examples of Mapping to Standardised Communication Protocols to Applications The IoT applications in the Smart Cities are recommended to use open standards based on independent, international governance body/organization (e.g. ETSI, IEEE, IETF, W3C, OASIS, OMG, OneM2M, ITU-T; ISI, IEC, etc.). Many of these standards are horizontal and neutral and are applicable across vertical domains. The IoT applications will use standard-defined gateways to connect the applications to other core protocols

Mainly specification of communication protocols at all layers, e.g., physical, access, network, Transport, Service, and Application layers

• Connectivity at physical and link layer

• Network layer





• Service level and application enablers

• Application level API, data models and ontologies

• Management of the protocols

14.5.2. Integration/Interoperability • Profiles

• Certification

14.5.3. Applications The support of the applications lifecycle. This includes development tools, application models, deployment, monitoring and management of the applications

• Flexible remote management

• Support methods for installing, starting, updating applications

14.5.4. Infrastructure

It covers the design, deployment, and management of computational platforms and infrastructures (e.g. network elements, servers, etc.)

• Virtualization

• Mobile-Edge Computing

• Network Management

• Network Dimensioning, Network Planning





14.5.5. Reference Architecture

14.5.6. Devices and sensor technology

• Device Monitoring

• Sensor/actuators virtualization

• Configuration management

14.5.7. Security and Privacy • Communications security and integrity

• Access Control

• Authorization, Authentication, Identity Management

• PII (Personally Identifiable Information) Management





15. Annex 3: Mapping of requirements and related standard coverage

Note: this section documents standards bodies at work in the various domains identified by ETSI; it does not yet contain specific technical standards. This will be consolidated with input from the EIP SCC, in a second version of the document.

15.1. Communication and Connectivity

15.1.1. Connectivity at Physical and Link layer

Requirements Organizations providing related standards

Support of heterogeneous communications : wireless/wired, short/long range,

3GPP, ETSI TETRA, IEEE , LoRa alliance, ITU EnOcean Alliance, DASH7 Alliance,Zigbee, IETF, OMG

15.1.2. Connectivity at Network layer


Support of local and remote access to infrastructure services,

3GPP, ETSI TETRA, IEEE 802.x, LoRa alliance, ITU,IETF,

15.1.3. Service level and application enablers


General services and Interoperability between different applications

oneM2M, OCF, AllSeen

15.1.4. Application Layer level, APIs, Data models and ontologies


Unified data model W3C, oneM2M

15.1.5. Integration/Interoperability


Certification of devices Wi-Fi, WiMAX,

For some technologies, there is a





potential gap

Interoperability between heterogeneous devices at the data level

ITU-T, W3C, oneM2M

15.1.6. Applications management


Application specification This is a potential gap

Local and remote application management (configuration, Installation, start/stop, update, etc.)

OMA LWM2M,OSGi

Application performance’ monitoring (computing resources)

This is a potential gap

15.1.7. Infrastructure


Integration of new and legacy systems oneM2M, OCF, AllSeen

Deployment and management OSGi

15.1.8. IoT Architecture


Device discovery; capability to include new devices, sensors, actuators when they join the system It covers integrated/complete IoT specification solutions, including architecture descriptions for Smart Cities.

oneM2M-; ITU-T; IIC;

IEEE, IERC, IoT.A, ISO/IEC JTC1; AIOTI

15.1.9. Devices and sensor technology


Interoperability of sensor networks, and make sensor networks plug-and-play, so that it becomes fairly easy to

ISO/IEC, M2.COM, Zigbee





Add/remove sensor nodes to/from an existing sensor network.

Sensors to provide robustness, accuracy, reliability

ISO / IEC JTC1

15.1.10. Security and Privacy


End-to-end security 3GPP, Hypercat, IEEE, IETF

Confidentiality and privacy, protection of personal data; encryption

OASIS





16. Annex 4: EU IoT Standardization Strategy

Ongoing standards activities Standards Developments Organisation Short description and Web links

ETSI ETSI TCs are active in the developing of radio technologies specific for M2M/Internet of Things such as DECT ULE, a wireless technology with ultra-low power consumption for Home Automation and Industry Automation applications. DECT ULE provides audio and data transmission with reliable radio links, superior indoor range, very low power consumption, strong security features and remote software downloading capabilities. Activities are also being carried out in the highly active ETSI ISG (NFV – Network Function Virtualization) along with ETSI TC NTECH/WG AFI (Autonomic Future Internet) and TC INT (Core Network and Interoperability Testing). A need has been identified to achieve standardized interoperability testing via a common methodology.

IEEE The IEEE Standards Association (IEEE-SA) has created a working group to develop its Standard for an Architectural Framework for the Internet of Things (IoT) (P2413). In addition, IEEE has a number of existing standards, projects in development, activities, and events that are directly related to creating the environment needed for a vibrant IoT, recognizing the value of IoT to industry and the benefits this technology innovation brings to the public http://standards.ieee.org/develop/msp/iot.pdf.

IETF The IETF has a number of working groups chartered to develop standards Rolling Plan 2015 for ICT Standardisation Page 3 of 7 http://ec.europa.eu/growth/single-market/european-standards/policy/benefits/index_en.htm Organisation Short description and Web links to support the Internet of Things. The 6lowpan working group is developing standards to ensure interoperability between smart object networks and defining the necessary security and management protocols and constructs for building such networks. The roll working group is developing standards to support the routing of communications within low-power and lossy networks. The core working group is specifying protocols that allow applications running in resource-constrained environments to interoperate with each other and the rest of the Internet. For more information see http://trac.tools.ietf.org/group/iab/trac/wiki/Multi-Stake-Holder-Platform#IOT Within the IETF, kick off in March 2015 the "thing to thing research group" (T2TRG). See https://github.com/t2trg

ISO/IEC JTC 1 The Internet of Things Special Working Group (SWG) is working in the following areas:

- IoT Terms and Definition, Mind map

- Market requirements of IoT

- Analysis of standardization gaps

- Reference architectures/frameworks ITU The IoT - Global Standards Initiative (IoT-GSI) advances IoT standardisation work in the fields of definition, overview, requirements, functional frameworks, architectures, identification, applications and services http://itu.int/en/ITU-T/gsi/iot. Definition of IoT in Recommendations





ITU-T Y.2060 “Overview of the IoT” http://itu.int/itu-t/Y.2060 IoT relevant Recommendations have been developed in Study Groups 13 (Future Networks), SG16 (Multimedia) and SG11 (Protocol and test specifications). http://itu.int/ITU-T/studygroups. To promote international coordination among SDOs a Joint Coordination Activity on Internet of Things (JCA-IoT) has been set up. http://itu.int/en/ITU-T/jca/iot . JCA-IoT maintains the global online IoT standards roadmap http://itu.int/en/ITU-T/jca/iot/Documents/deliverables/Free-download-IoT-roadmap.doc

OASIS OASIS runs a Technical Committee on Message Queuing Telemetry Transport (MQTT) https://www.oasis-open.org/committees/mqtt. It is producing a standard for the Message Queuing Telemetry Transport Protocol compatible with MQTT V3.1, together with requirements for enhancements, documented usage examples, best practices, and guidance for Met opmaak: Lettertype: 12 pt Rolling Plan 2015 for ICT Standardisation Page 4 of 7 http://ec.europa.eu/growth/single-market/european-standards/policy/benefits/index_en.htm Organisation Short description and Web links use of MQTT topics with commonly available registry and discovery mechanisms. As an M2M/Internet of Things (IoT) connectivity protocol, MQTT is designed to support messaging transport from remote locations/devices involving small code footprints (e.g., 8-bit, 256KB ram controllers), low power, low bandwidth, high-cost connections, high latency, variable availability, and negotiated delivery guarantees. https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=mqtt OASIS also runs Advanced Message Queuing Protocol (AMQP) Description: Ubiquitous, secure, reliable internet protocol for high speed transactional messaging https://www.oasis-open.org/committees/amqp.

Others (including stakeholder groups, technology platforms, research projects Title Short description and Web links AIOTI The Alliance for Internet of Things Innovation (AIOTI) created under the Commission's auspices has the goal to promote interoperability and convergence between standards, facilitate policy debates and prepare a Commission's initiative for large scale testing and experimentation, tabled for 2016. Forging new alliances between IoT sectors, stakeholders, large companies, SMEs and start-ups help Europe get a global lead in this field and will foster a Digital Single Market for IoT. The Commission published a 51M€ call (H2020 ICT-30). The initiative cuts across several technological areas (smart systems integration, cyber-physical systems, smart networks, big data), and targets SME and IoT innovators for to create an open IoT environment. Amongst AIOTI's European largest technical and digital companies are:

- Alcatel, Bosch, Cisco, Hildebrand, IBM, Intel, Landis+Gyr, Nokia, ON Semiconductor , Orange , OSRAM, Philips, Samsung , Schneider Electric, Siemens, NXP Semiconductors, STMicroelectronics, Telecom Italia, Telefonica, Telit, Vodafone, Volvo, start-ups (SIGFOX)…

- Representatives of different industries: nanoelectronics/semiconductor companies, Telecom companies, Network operators, Platform Providers (IoT/Cloud), Security, Service providers, sectors: energy, utilities, automotive, mobility, lighting, buildings, manufacturing, healthcare, supply chains, cities etc. https://ec.europa.eu/digital-agenda/en/news/launch-alliance-internet-things-innovation Rolling Plan 2015 for ICT Standardisation Page 5 of 7 http://ec.europa.eu/growth/single-market/european-standards/policy/benefits/index_en.htm Title Short description and Web links





EC There are several projects funded by the European Commission, which are integrated in the Internet of Things Research in Europe Cluster (IERC) that are dealing with aspects of the standardisation in IoT: CALIPSO, GAMBAS, IOT.EST, OPENIOT, UIOT6, SPRINT and PROBE-IT. In particular, OPENIOT deals with standardisation of open source solution for creating utility/cloud based environments of internet-connected objects, SPRINT has an active contribution to W3C (web services), OMG (e.g., on exchange formats, APIs) and OASIS (data exchange formats), PROBE-IT validates standards or pre-standards on European and International Level and perform pre-normative research work on standardisation requirements. Also, the Future Internet PPP (FI-PPP) deals with some issues connected to the standardization of the IoT. IVA Internet of Things (IoT) is a sub-project within ICT for Sweden with the objective of supporting the entire value chain, from business benefits to sensors. http://www.iva.se/IVA-seminarier/Internet-of-Things-IoT---fran-affarsnytta-till-sensorer/ W3C AW3C kick off in April 2015, after having organised a workshop on “Web of Things” was organised by W3C in June 2014. http://www.w3.org/2014/02/wot/ UK the KTN (Knowledge Transfer Network) IoT interest group https://connect.innovateuk.org/web/internet-of-things Finland IoT Cluster supporting investments in IoT http://www.investinfinland.fi/industries/rd-and-innovation/internet-of-things-in-finland/12