DELIVERABLE - ESPRESSO...

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

of the European Union

D4.2 – Definition of Smart City reference architecture

File: D4.2 - Definition of Smart City reference architecture.docx Page: 1 of 49

DELIVERABLE

D4.2 – Definition of Smart City Reference Architecture

Project Acronym: ESPRESSO

Grant Agreement number: 691720

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

Revision: 4

Authors: Andy Cox, Peter Parslow, Bart De Lathouwer, Eva Klien, Bernhart Kempen, Joachim Lonien

Project co-funded by the 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

Ref. Ares(2016)4019068 - 31/07/2016





1. Revision history and statement of originality

1.1. Revision history

Rev Date Author Organization Description

1 15.06.2016 Bart De Lathouwer OGCE First Draft

2 14.07.2016 Bart De Lathouwer, Andy

Cox, Peter Parslow

OGCE, OS Second draft

3 27.07.2016 Bart De Lathouwer, Andy

Cox, Peter Parslow, Eva Klien,

Bernhard Kempen,

Joachim Lonien

OGCE, OS, DIN, Fraunhofer

First release

4 29.07.2016 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

TOGAF Copyright © 2003 - 2011, The Open Group. All Rights Reserved. TOGAF® is a

registered trademark of The Open Group

EIP SCC http://ec.europa.eu/

https://eu-smartcities.eu/content/urban-platforms





3. Table of Acronyms

Acronym Description

TOGAF The Open Group Architecture Framework

EIP European Innovation Partnership

SCC Smart Cities and Communities

WSx Work Stream x

ESO European Standardisation Organizations

NSB National Standardisation Bodies

SDO Standards Development Organizations

ADM Architecture Development Method

ISO International Organization for Standardization

IEC International Electrotechnical Commission

JTC1 Joint Technical Committee 1

WGx Working Group x

KPI Key Performance Indicators

ITS Intelligent Transport Systems

ITU International Telecommunication Union

CRUD Create Read Update Delete

BSI Publicly Available Specification

PAS Publicly Available Specification

OGC Open Geospatial Consortium

W3C World Wide Web Consortium

API Application Programming Interface

ADM Architecture Development Method





4. Executive Abstract

This document (D2.4) is part of a trilogy: D2.3 (Definition of a Conceptual Standards Interoperability Framework), D4.2 (Definition of a smart city reference architecture) and D2.4 (Cross-SDOs GAP and SWOT analysis, delivery in September 2016) – and describes a reference architecture that is mission and vendor agnostic. It therefore may not contain any form of technicalities nor solution elements, nor may it be prescriptive or excluding certain solutions. It must be able to act as a real reference for cities and communities that have the wish to realize a comprehensive solution, or only part of it. This reference architecture will remain valid, even if technology and standards change – making the reference architecture future proof.

ESPRESSO’s deliverables D2.4 (cross SDO GAP and SWOP analysis) will bring together the standards described in D2.3 with this document and make the reference architecture specific – meaning that standards will be assigned to the various layers of the architecture.

ESPRESSO aligns as much as possible with the output of the first and second element (Standards & Standardisation and Reference Architecture & Design Principles) – WS1 and WS2 respectively. This document aligns with the output of WS2 (this version of the document is initially based on the draft WS2 document created by Jeroen Scheer and Lutz Heuser), and will continue to support one another – keeping into account the different in scope (see Figure 3: Scope of EIP SCC Urban Platforms.). The output of WS1 (Standards & Standardisation) is aligned with ESPRESSO’s D2.3 (Definition of a ConceptuAl StandardS InterOPErability frAmework (CASSIOPEiA) for Smart City).

The next version of this document (to be published in August 2016 and again in October 2016) will further align with WS2 (and WS1) to maximally support EIP SCC.

The trilogy (documents D2.3, D4.2 and D2.4) can be used by both demand and supply side for procurement and solution development, to increase the level of interoperability between city services and between cities.

These documents will also be submitted to the members NSB, ESO, SDO as well as ISO IEC JTC1 WS11 s input into the standards process – and serve as input for papers and dissimination material.





5. Table of Content

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 .............................................................................................................................. 5

5. Table of Content ................................................................................................................................. 6

6. Table of Figures .................................................................................................................................. 8

7. Table of Tables.................................................................................................................................... 9

8. Introduction ......................................................................................................................................10

8.1. Target audience ..............................................................................................................................10

8.2. Purpose ..........................................................................................................................................10

9. Context and Background ....................................................................................................................12

9.1. EIP SCC Urban Platforms ..................................................................................................................12

9.1.1. Scope of the EIP SCC .....................................................................................................................13

9.2. SCC03 - ESPRESSO ...........................................................................................................................13

9.3. One Common Framework for Architecture .......................................................................................15

9.4. TOGAF Architecture Framework .....................................................................................................16

9.4.1. Why do we need an Architecture Framework? ...............................................................................16

9.4.2. TOGAF Architecture Domains ........................................................................................................16

9.4.3. The TOGAF Architecture Development Method .............................................................................17

10. ESPRESSO Architecture framework....................................................................................................17

10.1. Phase A: Architecture Vision ..........................................................................................................18

10.1.1. Scope.........................................................................................................................................18

10.1.2. Foundation, Principles and Assumptions ......................................................................................18

10.1.2.1. Principles ................................................................................................................................18

10.1.2.2. Assumptions............................................................................................................................19

10.1.3. Reference to EIP SCC Urban Platforms WS1 and ESPRESSO D2.3....................................................19

10.1.4. Urban Platform Concept View .....................................................................................................20

10.2. Phase B: Business Architecture.......................................................................................................20

10.2.1. Vision, Strategy & Goals ..............................................................................................................20

10.2.2. Stakeholders, Roles & Concerns ..................................................................................................22





10.2.3. Business Principles......................................................................................................................23

10.2.4. Business Requirements ...............................................................................................................23

10.2.5. Business Constraints ...................................................................................................................26

10.3. Phase C: Information Systems Architecture.....................................................................................26

10.3.1. Business Process Framework .......................................................................................................27

10.3.2. Knowledge Management Framework ..........................................................................................28

10.3.2.1. Knowledge / Data Value Chain..................................................................................................32

10.3.2.2. Knowledge Management Principles ..........................................................................................33

10.3.2.3. Knowledge / Information / Data Entity – Component Catalogue .................................................33

10.3.2.4. Data Entity/Business Function matrix........................................................................................34

10.3.2.5. Data Lifecycle diagram .............................................................................................................35

10.3.2.6. Knowledge management process .............................................................................................36

10.3.3. Engineering Framework ..............................................................................................................36

10.3.3.1. Positioning Services .................................................................................................................42

10.3.3.2. Sensing Services ......................................................................................................................42

10.3.3.3. Data Services ...........................................................................................................................43

10.3.3.4. Application Services .................................................................................................................43

10.3.3.5. Business Services .....................................................................................................................43

10.3.3.6. Consumers ..............................................................................................................................43

10.3.3.7. Cross-Cutting Services ..............................................................................................................43

10.3.3.7.1. Security Services................................................................................................................44

10.3.3.7.2. Technology Services...........................................................................................................44

10.3.3.7.3. Supporting Services ...........................................................................................................44

11. Annex ..............................................................................................................................................45

11.1. Rotterdam ....................................................................................................................................45





6. Table of Figures

Figure 1: Authoritative source of information. .........................................................................................11 Figure 2: Standards supporting both Demand and Supply Side. ................................................................12

Figure 3: Scope of EIP SCC Urban Platforms. ............................................................................................13 Figure 4: TOGAF Architectural Domains. .................................................................................................17 Figure 5: TOGAF Architecture Development Method (ADM). ....................................................................17 Figure 6: Urban Platform Concept...........................................................................................................20 Figure 7: From high-level goals to Use Cases to Requirements..................................................................21 Figure 8: Knowledge Management Context. ............................................................................................28

Figure 9: Categories of Knowledge Demand (BSI PAS 182 Figure 5.2). .......................................................29 Figure 10: City Knowledge. .....................................................................................................................30 Figure 11: Data to Knowledge ISO 9001 KM)............................................................................................32 Figure 12: An Example Data Value Chain Using Analytics. .........................................................................32 Figure 13: 30145-3 from OGC 14-115. .....................................................................................................33 Figure 14: OGC 14-155 from FG-SCC TR & JTC1/SC1 report.......................................................................33

Figure 15: TOGAF Enterprise Continuum. ................................................................................................37 Figure 16: TOGAF Architecture Continuum. .............................................................................................38 Figure 17: TOGAF Technical Reference Model (showing service categories). .............................................38 Figure 18: Smart Cities Solution Concept Diagram- SOURCE ISO/IEC JTC 1/WG 11 (Originated from OGC). ..39 Figure 19: ITU-T IOT Reference Model.....................................................................................................40 Figure 20: Smart Cities Solution Concept Diagram....................................................................................41

Figure 21: Smart Cities Reference Architecture. .......................................................................................42 Figure 22: Rotterdam Design on headlines. .............................................................................................45 Figure 23: Rotterdam specific architecture. .............................................................................................46 Figure 24: Eindhoven discourse. .............................................................................................................47 Figure 25: Societal Needs are prime. .......................................................................................................48 Figure 26: Layers by Spanish national standard UNE 178104. ...................................................................49





7. Table of Tables

N.A.





8. Introduction

The intent of the Reference Architecture and the Design Principles which form part of it, is to provide cities and communities a mission and vendor agnostic approach for implementing enhanced interoperable, standards-based architectures for their specific city context. In addition, this 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 to be addressed to make these resulting solution architectures interoperable – so that we achieve interoperability between the various services within a city and also to increase interoperability between different cities.

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 as presented here provides the key elements, aligned to several other EU initiatives and worldwide standards regarding Reference Architectures. It will at least contain 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.

8.1. Target audience

This document has various target groups that will use it. It is not by definition that all chapters and elements are deeply understood by all readers and users. The target audience vary from the mayor of a city, the city manager and its policy makers (C-level, budget holder) all the way to solution architects that need to implement parts of an urban platform and the purchasing department that want to tender solutions.

Also vendors (hardware, software and service providers) can use the document to understand if their solutions will fit to the Reference Architecture.

8.2. Purpose

The purpose of this work is to provide guidance and direction to stakeholders (including the Smart City and Communities initiatives) on the better use of Reference Architectures for guiding and constraining architecture descriptions, developments, and usages for current and future capabilities. The approach taken was to research and leverage Reference Architecture information and best practices to develop a common definition for Reference Architecture and describe the elements that compose a solid mission and vendor agnostic Reference Architecture.





The key points made in this document are:

Reference Architecture is defined as an authoritative source of information about a specific subject area that guides and constrains the instantiations of multiple architectures and solutions. This definition is applicable to all of Smart City and Communities initiatives.

Project-specific Architectures may be developed by various organizations for their own purposes and intended uses.

The goals and objectives of Reference Architecture are numerous. They solve a specific (recurring) problem in a problem space; explain context, goals, purpose, and problem being solved including when and how Reference Architecture should be used; and provide concepts, elements and their relationships that are used to direct/guide and constrain the instantiation of repeated concrete solutions and architectures.

Figure 1: Authoritative source of information.

Reference Architectures may address different levels of abstraction (from the specific to the generalized) and at different levels of coverage (from patterns to full end‐to‐end

coverage).

It must be clear that the provided Reference Architecture is not logical nor solution architecture. However, we will provide the Reference Architecture in such a manner that based on this an implementation or tender can be executed. Every user can derive project-specific architectures from this Reference Architecture. For ESPRESSO this will be expressed in deliverable D2.4 (GAP and SWOP analysis). The reference architecture is technology agnostic and future proof.





9. Context and Background

9.1. EIP SCC Urban Platforms

By 2025 300 million EU citizens are served by platforms within their cities and in short-term accelerate the adoption of Urban Platforms through an easy-to-implement template approach, and cross-sector collaboration.1

Urban Platforms form a core building block by which cities better manage the current explosion in volumes of city data and more easily share this data between city services in order to improve outcomes for society.

The Urban Platform Initiative comprises three core elements:

1. Demand-Side – to define common requirements, and speed adoption. Common and aligned set of requirements, and more innovative business models and acquisition processes to acquire urban platforms. Typically, the demand-side is underexposed; the challenges of cities/communities are the basis on which the solutions have to be modelled after. Also, the demand-side needs ways to get and stay involved in the standard-setting process

2. Supply-Side – to bring together EU Industry to adopt open solutions and to mobilise industry on a pan-EU basis to commit to an open reference architecture for urban platforms that services demand side needs. Maximises template component-based solutions that enable affordable standards based solutions to be put in place in cities, thereby avoiding vendor lock-in and promote interoperability between the various city services and services between cities. Solutions have to be developed based on city’s challenges (demand side), instead of forcing a fit between an existing industry solution (that’s ready for market) and a city’s infrastructural/IT problems.

3. Standardisation – raise awareness for interoperability and to formalise the capture of the core content as international standards. To establish a robust basis to develop and prove a more common open and sustainable basis by which the urban platform market is developed – this should include stakeholder participation during development and review cycles.

Figure 2: Standards supporting both Demand and Supply Side.

1 https://eu-smartcities.eu/content/urban-platforms.

https://eu-smartcities.eu/content/urban-platforms





9.1.1. Scope of the EIP SCC

Figure 3: Scope of EIP SCC Urban Platforms.

When looking at a Smart City, we consider this as a vision of a city where key components of infrastructure and services – environmental, emergency response, traffic and energy management to name a few – are integrated in such a way that features and applications can easily be combined with whatever capability existed before. Achieving that vision requires moving beyond many current implementations in which the degree of integration of core subsystems within smart cities is often limited by patchworks of legacy and fixed solutions connected by custom integrations, if any. Therefore, we have the wish to create an open, referenceable and composable Smart City (Urban) Framework. Specifically, we do not aim to create a so-called Urban Platform, since by name that would suggest that one platform could be the solution. We do not believe in that; we believe that many platforms will arise and be implemented, based on a standard way of working with components that adhere to open standards, patterns and references. By composable, we imply that continuous integration and improvement will be achieved through easy addition of function as opposed to wholesale replacement or retrofitting. Cities integrating each new capability should be able to simply acquire and add it to the existing infrastructure with a minimum of tailoring and rework of existing component interfaces. The whole will be greater than the sum of its parts.

9.2. SCC03 - ESPRESSO

ESPRESSO is the implementation of the SCC03 call, and host of this document.

Over the next decade, the way we live, work and use energy, transportation and other city resources and services will change significantly thanks to a range of innovative ‘Smart City’ solutions. 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. However, technological complexity, as well as the complexity of the various sectorial services involved within a Smart City, require 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.

In an effort to leverage the promise of a system approach, ESPRESSO will focus on the development of a conceptual Smart City Information Framework (of which this document forms a part) based on open standards. This framework will consist of a Smart City platform (the “Smart City enterprise application”) and a number of data provision and processing services to integrate relevant data, workflows, and processes. The project 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 analyse potential gaps and overlaps among standards developed by the various standardisation organizations and will provide guidelines on how to effectively address those shortcomings.

Although “horizontal” interoperability is outside the scope of ESPRESSO, preferences will be given to “common denominator” solutions that can facilitate horizontal interoperability between the various sectors of a Smart City. In fact, emphasizing integration of reference models as a common denominator (e.g. in the form of multi-dimensional city models) will lay essential parts of the foundation for future levels of interoperability.

Based on a detailed requirements-engineering campaign executed in close cooperation with cities, standardisation organizations, administrative bodies, and private industry, the project will identify open standards matching the elicited requirements and will establish a baseline for interoperability between the various sectorial data sources and the Smart City enterprise application platform. In a comprehensive set of coordination, support and networking activities, the project will engage a very large number of stakeholders, such as Smart Cities (both existing and those with aspirations), European Standardisation Organizations (ESOs), National Standardisation Bodies (NSBs), Standards Development Organizations (SDOs), public administrations, industries, SMEs, and other institutions.

An Open Standard:

Is created in an open, international, participatory industry process, as described above. The standard is thus non-proprietary, that is, owned in common. It will continue to be revised in that open process, in which any company, agency or organization can participate.

Has free rights of distribution: An "open" license shall not restrict any party from selling or giving away the specification as part of a software distribution. The "open" license shall not require a royalty or other fee.

Has open specification access: An "open" environment must include free, public, and open access to all interface specifications. Developers are allowed to distribute the specifications.

Does not discriminate against persons or groups: "Open" specification licenses must not discriminate against any person or group of persons.

Ensures that the specification and the license must be technology neutral: No provision of the license may be predicated on any individual technology or style





of interface. By this definition, a de facto standard established by one company or an exclusive group of companies or by a government is not an open standard, even if it is published and available for use by anyone at no charge. The Web, and the Spatial Web, cannot depend on proprietary standards.

ESPRESSO’s approach emphasizes cost reduction and will foster an open market for many actors, avoiding lock-in to proprietary solutions. European Smart City solutions that adopt these prescripts will be raised to the forefront worldwide.

9.3. One Common Framework for Architecture

The EIP SCC (Integrated Infrastructures and Processes Action Cluster) Urban Planning2 contains three core elements: Demand Side, Supply Side and Standardisation. The Supply Side element has 3 Work Streams (WS): Standards & Standardisation, Reference Architecture & Design Principles and Scale.

ESPRESSO aligns as much as possible with the output of the second element (Reference Architecture & Design Principles), called WS2 (Work Stream 2). Future versions of this document and WS2 will continue to support one another – keeping into account the different in scope (see Figure 3: Scope of EIP SCC Urban Platforms.).

Both WS2 and ESPRESSO pursue consensus on a smart city framework that meets the demand-side needs – and both teams collaborate jointly on this document – to maximize consistency in support of the EIP SCC Urban Platforms.

Cities and entrepreneurs worldwide and within Europe seek to enable incrementally added “smarts” to various aspects of city life regardless of which community of interest the components come from. And they do not want to wait to deploy these capabilities in anticipation of the arrival of some kind of “grand scheme” or “total solution”. A desirable (reference) architecture would draw on the existing work to minimize the barriers to integrating critical as well as new and novel applications to the benefit of citizens and city managers.

The recent significantly increasing interest and progress in Smart Cities and Urban programs will give us many insights and lessons learned. However, we are only at the beginning, and sometimes even before the real beginning. Many teams of implementers and cities pioneering applications within Europe. There are also many consortia and standards organizations developing architectures of various scopes appropriate for Smart City integrations or equivalents. All of these groups would benefit from the ability to work together through a common language and shared architectural principles.

As well as industry interest, governments have a keen desire to benefit from the efficient integration of “Smart” into their cities. A recent report predicts that by 2017, twenty of the world’s largest countries will have in place prioritized national smart city policies and one third of medium and large cities worldwide will have developed a smart city roadmap. A shared smart cities framework can support informed policy and decision-making and promote the emergence of a vibrant global market for smart city technologies.

2 https://eu-smartcities.eu/content/urban-platforms





To meet the needs of all stakeholders, the working group is a technology- and business-model-neutral forum for capturing a minimum set of commonality that can be adopted to achieve the composable vision of a Smart City/Urban platforms. The goal is to find a common intersection of consensus among the stakeholders around which all participants can rally.

9.4. TOGAF Architecture Framework

ESPESSSO has adopted The Open Group Architecture Framework (TOGAF®3) 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.

9.4.1. Why do we need an Architecture Framework?

The use of the TOGAF architectural framework results in architectures that are consistent, respond to stakeholders needs, adopts and employs best practice, and gives the 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 an enterprise architecture” (TOGAF 9.1).

9.4.2. TOGAF Architecture Domains

TOGAF includes four different architectural domains, which are accepted as sub-sets of an overarching enterprise architecture. These are:

3 Copyright © 2003 - 2011, The Open Group. All Rights Reserved. TOGAF® is a registered trademark of The Open Group.





Figure 4: TOGAF Architectural Domains.

9.4.3. The TOGAF Architecture Development Method

TOGAF uses the Architecture Development Method (ADM) as a step-by-step approached to developing enterprise architecture. It describes how to create an organisation or context specific enterprise architecture that address a set of business requirements and responds to stakeholder concerns.

Figure 5: TOGAF Architecture Development Method (ADM)4.

10. ESPRESSO Architecture framework

As TOGAF is itself a framework it can be adapted and customised according to need. Therefore, for the purposes of the ESPRESSO reference architecture this document will only cover Phases A: Architecture Vision, B: Business Architecture and C:

4 http://pubs.opengroup.org/architecture/togaf9-doc/arch/Figures/adm.png.

http://pubs.opengroup.org/architecture/togaf9-doc/arch/Figures/adm.png





Information Systems Architecture (Application & Data) as these are sufficient to describe the reference architecture (reference 10.1.1).

10.1. Phase A: Architecture Vision

Phase A: Architecture Vision is the initial phase of the TOGAF ADM cycle. This phase establishes the architecture project and initiates an iteration of the TOGAF ADM. Therefore, it includes:

Definition of the expectations and scope of the architecture initiative, including any constraints

Identification of key stakeholders including their concerns and objectives

Creating the architecture vision itself

Validating the business context e.g. business principles, goals, drivers and Key Performance Indicators (KPIs)

10.1.1. Scope

The intent of this Reference Architecture is to provide cities and communities that wish to implement Smart City & Communities initiatives, a mission, implementation 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. The reference architecture does however aim to provide common semantics that can be used unambiguously across and between different implementations.

10.1.2. Foundation, Principles and Assumptions

Our vision is to have a Reference Architecture that is mission and vendor agnostic. It therefore may not contain any form of technicalities nor solution elements, nor may it be prescriptive or excluding certain solutions. It must be able to act as a real reference for cities and communities that have the wish to realize a comprehensive solution, or only part of it. Therefore, we have adopted several overall foundational assumptions that form the basis for the Reference Architecture presented in this document.

When analysing several other Reference Architectures and taking inputs from the Demand-Side into consideration, we come to the conclusion that several common denominators are present among those architectures. These are represented as a set of related principles and assumptions below.

10.1.2.1. Principles

A layered approach towards architecture

Capabilities are the centre element of the architectures to ensure that a common ground is easy to be found

Delivering smart services are the ultimate delivery for users

Iterative, evolutionary approach starting from various pain points

Not aimed at a single ‘target customer’, but at a ‘community of customers’





Promoting Open Standards, based on large-scale deployments. Between the various layers, standards are promoted

Technologically and implementation agnostic

No vendor lock in

Able to enable various urban platforms

Aiming at certification and compliancy (not part of the reference architecture, but of solution architecture)

Modularity: cities can use and deploy various (combinations) of the reference architecture and its deployments

Market structure agnostic

Re-use of existing proven architectures

Customers need to be able to migrate thru EU without having a completely new set up of its active participation of an urban platform (no-barrier approach)

‘Collaboration’ and ‘sharing’ vs. “single entity processes’ (modular approach)

10.1.2.2. Assumptions

Pace-layered approach (i.e. various characteristics for different capability groups) (some layers change faster than other layers)

Any-Infrastructure approach (OnPremise, SaaS, PaaS, IaaS) with the same reference architecture(?)

Focus on harmonization of data and its logistics, promoting Open Data

Adopting public infrastructures has to be considered

IoT-based use cases provide high demands

Independent for integration with new and existing system; both are mandatory (‘no green field’)

Data modelling is an integral part of the logical and solution architecture, and therefore not part of the reference architecture

10.1.3. Reference to EIP SCC Urban Platforms WS1 and ESPRESSO D2.3

As indicated in chapter One Common Framework for Architecture, ESPRESSO tries to align with the output of the EIP SCC Urban Platforms. WS2 aligns with this document.

The output of WS1 (Standards & Standardisation) is aligned with ESPRESSO’s D2.3 (Definition of a ConceptuAl StandardS InterOPErability frAmework (CASSIOPEiA) for Smart City).

ESPRESSO’s deliverables D2.4 (cross SDO GAP and SWOP analysis) will bring together the standards described in D2.3 with this document and make the reference architecture specific – meaning that standards will be assigned to the various layers of the architecture.

The reference architecture described in this document will remain valid, even if technology and standards change – making the reference architecture future proof.





10.1.4. Urban Platform Concept View

Urban Platforms form a core building block by which cities better manage the current explosion in volumes of city data and more easily share this data between city services in order to improve outcomes for society. When looking at a Smart City, we consider this as a vision of a city where key components of infrastructure and services – environmental, emergency response, traffic and energy management to name a few – are integrated in such a way that features and applications can easily be combined with whatever capability existed before. Achieving that vision requires moving beyond many current implementations in which the degree of integration of core subsystems within smart cities is often limited by patchworks of legacy and fixed solutions connected by custom integrations, if any. Therefore, we have the wish to create an open, referenceable and composable Smart City (Urban) Framework. An example of an Urban Platform concept is show below.

Content

Portal & Marketplace

Applications

Services

Urban Platform

Figure 6: Urban Platform Concept.

10.2. Phase B: Business Architecture

Phase B: Business Architecture is the second phase of the TOGAF ADM cycle. This phase describes a business from the perspective of:

An enterprise’s mission, vision, strategy, and goals

How an enterprise will meet its business goals e.g. via business functions, capabilities and services

The people within the enterprise

The key business processes

10.2.1. Vision, Strategy & Goals

Leadership Guide - Key issue guides that seek to inform city leaders on their urban platforms’ strategy, roadmap, and decision-making [Source: Align Roadmap Template Slide]

ESPRESSO workshop output:

o Smart citizens and smart management

o Threshold of performance in sectorial systems; best practices





o Integrated urban planning approach - integration of databases, completion of land register, paperless planning, transborder integration

o Public authorities should be drivers

o Involving the community: crowdsourced information, if properly validated, can lay foundations for real-time planning

o Smart systems technology and cloud computing solutions are easy to use and do not require local resources

Eindhoven discourse:

o Demand-led, city-needs-led, approach

o “Exploiting the value of city data through urban platforms”

o 1 co-enable the realisation of the Urban Platform High Level Goals

o From High Level Goals to Use Cases to Requirements Specification

Figure 7: From high-level goals to Use Cases to Requirements.

o Requirements to deliver new digital services that will address the societal needs of cities in a positive manner that relates to political narratives

o Requirements to new profitable business models and the development of an increase range of new and engaging services in the smart cities





o Requirements to provide all city data stakeholders ready access and delivery of all city data that unpins the decision making process in smart cities

o Requirements to create an open urban platform that will be recognized as being better and as outperforming competitions with regards to city, human and business needs

o Requirements to deliver the backbone infrastructure which will be used to capture the opportunities of digital technology and data to enable transformation

10.2.2. Stakeholders, Roles & Concerns

Management Framework - Organising frameworks that help decision makers to improve the quality of ‘smart’ cross-domain integrated city management, and to understand key issues and means of resolution [Source: Align Roadmap Template Slide]

ESPRESSO Workshop output:

o Maximize viability and awareness: make the community understand and react;

o Expand and promote the Smart City Stakeholder Network;

o Better understand drivers for smart cities, opportunities and barriers;

o Collect potential use cases and input for ESPRESSO future work and deliverables;

o In case of Rotterdam, open the pilot subject and define first priorities for the D4.5;

o Issue of trust;

o Pitfall of hyper-technologization is the loss of community sense, identity, culture and tradition.


o Identify the priority service outcomes that the city seeks to achieve to steer the overall prioritisation of urban platform development – what are your specific goals?

o Perform a city data mapping exercise to develop a picture of the data landscape, including: sources, volume, variety, temporal factors and sensitivity, data licensing and ownership policies;

o Map out existing ICT system resources across the city in order to identify those resources with the greatest potential for reuse, identify gaps and provide the foundation for a data strategy and technology plan to fill them;

o Identify the requirements within this document that best suit city needs - alongside any other emerging requirements – and refine and prioritise them in accordance to their data strategy defined in step 1 and 2;





o Primarily city leaders, both political and professional. Notably those that guide a city (Mayor, Advisers; ‘Smart’ portfolio holder; Finance). And those that manage the city (CEX, Finance, Policy, ‘Smart’ Director);

o Principally City Officials: Heads of Department and Services; Senior cross-cutting roles (policy, finance, commissioning, ICT etc.).

10.2.3. Business Principles

ESPRESSO Workshop output:

o Development of a smart city should be community-centric, not technology-centric;

o Data marketplace: capitalizing on the economy of scale of putting out data which is open.


o Common approaches, and common shared platforms.

10.2.4. Business Requirements

Validated Requirements Specification for Urban Platforms - Common core set of validated and tested city-needs-led requirements to support and accelerate the acquisition of “Urban Platforms” by EU cities [Source: Align Roadmap Template Slide]

ESPRESSO workshop output:

o Pre-existing initiatives: water flow management in the city, automatic parking control, light pool control with single backend system, etc.

o Key sectorial systems:

Safe City concept (Rotterdam has a mixed population and aims at enhancing the intra-urban safety);

Water and waste management (crucial);

Mobility (integrated territorial planning);

Education and youth, communication and participation;

Energy transition, housing, liveable city;

Facilitation and support of cooperation and trade economy.

o Energy, ICT and mobility in a Lighthouse proposal, potential use cases for standardization. Focus: redevelopment of Stadium area.

o Data marketplace: capitalizing on the economy of scale of putting out data that is open. Challenges: usability, usefulness, quality, potential monetization, impact assessment (quantification of advantages). Data should be user friendly, and user trust needs to be sought (catalyst organization).

o Asset management is key: information-driven municipal work, capitalizing on building-level microdata.

o Information and communication platform embedding virtual interactions between organizations and people via 3D CityGML.





o Dynamic energy and transport info from sensors and spatial planning (phase 1).

o Main idea: maintenance of real and virtual city, with a free access for all (public affair).

o Requirements:

City GML Format model, extendable, replicable, scalable;

Allowing urban insertion analysis;

Allowing connection to sensor data using open standards;

Integration with user interaction services;

Capable of export via CityGML to native applications.

o D2.2 – Scope of Smart City use cases, together with results from ESPRESSO Questionnaires.

o Priority areas / sectorial systems of interest in ESPRESSO can be narrowed to: Smart Governance and participation, Smart mobility and ITS, Quality of Life cases, Energy Transition, Smart Infrastructures.

o City-centric analysis still work-in-progress: Time is required to communicate, involve, and understand.


o City-Needs Spec.

o Leadership Guide – politics and city management.

o Management Framework – toolkit for action.

o From High Level Goals to Use Cases to Requirements Specification.

o Societal needs and wants must be recognised as the starting point for city data service offering. To achieve a large-scale adoption and impact we need to:

Take Human behaviour and needs as seriously as technology;

Understand which services and data are needed to solve social problems and drive innovation;

Identify what makes data and services more accessible to users;

Gain understanding of what influences user’s experience while interacting with services provided (e.g. usability, feeling of security and trust).

o Providing tailor-made data services requires careful targeting and needs assessment of users. To achieve a large-scale dissemination and impact of services we need to:

Create new partnerships that could allow the creation of new potential and cost-effective beneficial services that could be rolled out across cities of different sizes;





Understand under which context users may use or request a service;

Provide tailor-made data services which careful targeting and needs of users and businesses;

Explore use cases where data is used to deliver different forms of value.

o The urban platform is the foundation for widespread exploitation of data. To achieve a large-scale dissemination and impact of services we need to:

Perform a city data mapping exercise to develop a picture of the data landscape, including: sources, volume, variety, temporal factors and sensitivity;

Define data licensing and ownership policies;

Define Terms and conditions to exploit data to full effect;

Understand the architectural features of city data;

Set city data and metadata quality requirements;

Explore the vulnerability aspects of city data (e.g. volunteered citizen’s data);

Identify data usability and reusability requirements for humans and machines.

o Urban platform is the foundation for widespread exploitation of data. To create it we must:

Use city data and open platforms to mobilise collective knowledge and innovation in smart cities;

Build partnerships to deliver holistic and interoperable solutions;

Identify integrated approaches to design and service delivery which ensures that services fit together and that synergies can be exploited;

Manage the data in a way that ensures its integrity and compliance with data protection regulations;

Ensure the platform is able to accommodate additional functionality at later stage at a fair and transparent cost.

o Urban platform is the foundation for widespread exploitation of data. To enable it we must:

Identify what ICT infrastructure is needed citywide to support the urban platform

Map out existing ICT system resources across cities in order to identify those resources with the greatest potential for reuse, identify gaps and provide the foundation for a strategy to fill them;

Set up governance processes and usage policies for ICT infrastructure in order to maximize asset reuse by city partners;





Define reasonable service level agreements to guarantee scalability requirements.

10.2.5. Business Constraints

ESPRESSO workshop output

o Usefulness and results of workshops is beyond initial scope: SmaCStak strengthening and development, dissemination, input for Gap and SWOT analysis, Piloting preparation, SC Business framework.

o Small-scale, stakeholder-focused workshops should be further developed (Tartu, but also external).

o Early Adopters: not easy to involve. Clarification of role and expectations should be done.


o SDOs are not presently legitimate to this audience; and several of these topics may well be covered by other information sources (City Associations; Institutions; Investors; Industry etc) so the brand of SDOs (typically “trusted, slow, detailed”) combined with these other parties must be best exploited.

o Target delivery – 3-6 months. SDOs typically have lengthy (and Industry-resourced) processes for delivery. Some have developed rapid processes, and a few are starting to link their (smart city) actions tighter to national legislation, policy, and support of market development. Swift agile delivery will be important to gain the attention and legitimacy of city leaders. (Without which technical standards, and common approaches to common solutions may well not result).

o Internal SDO alignment will be important – ie how energy and transport documents align. Given the limited existence of formal SDO documents external alignment amongst SDOs is less of an issue. Alignment with Institutional / Association documents will however be important (for example: City Protocol City Anatomy; 100RC Resilience Framework).

o Target 6-9 months for working papers that can be used to prove and improve. Formal delivery could be around 9-18mos. It would be anticipated that these documents could be developed in a more agile or component based manner to get them to the market swiftly and augment with use.

10.3. Phase C: Information Systems Architecture

Phase C: Information Systems Architecture is the third phase of the TOGAF ADM cycle. This phase covers both the application and data domains and the major types of information and applications/services that process them. Therefore the objectives of this phase are to:

Data Architecture - define the types and sources of data that are required to support the business requirements. Key considerations for the data architecture are data management, data migration, data integration and data governance.





Application Architecture – define the kind of application services that are needed to process the data in order to support the business requirements.

ISO/IEC Joint Technical Committee (JTC) 1 has created Working Group 11 to work on standards for the ICT aspects of smart cities. Amongst their first projects is creation of a Smart City ICT Reference Framework, the purpose of which is to assist city Chief Information Officer (CIO) and other stakeholders in planning and implementing a smart city. It comprises of the following three parts:

Part 1: Smart City Business Process Framework

Part 2: Smart City Knowledge Management Framework

Part 3: Smart City Engineering Framework

These three views are each aimed at a different role or viewpoint within the city and thus separate focus needs to be maintained. The "separation of concerns" is a principle for development of reference and system architecture as a set of views. The value of using the separation of concerns is to simplify development and maintenance of the architecture.

The remainder of this section of this document adopts the same set of views. The ESPRESSO project has established contact with the WG11 editors.

10.3.1. Business Process Framework

ISO/IEC JTC1 WG11 are considering using the TM Forum’s Business Process Framework approach in their ISO 30145-1 project. They note5 that the TM Forum Smart City Maturity Model (TR 259; still under development) identifies a number of business processes, which would have a specific “smart city” flavour:

Integrated IT Governance

Energy Management

Water Management

Waste Management

Transport Management

Infrastructure and Building Management

Sustainability and Environment Management

ESPRESSO has established a similar set of key sectors, which are used throughout the ESPRESSO document set (see ESPRESSO D2.1):

Education

Energy

Environment

Governance

Health

5 Initial Working Draft of 30145 Part 1 v0.1, dated 2016-06-08, quoting TM Forum’s TR 259 TM Forum Smart City Maturity Model (currently only available to members of TM Forum to review).





Safety

Building

Transportation

Water supply

Waste water

Each of these sectors has associated business processes; to be a smart city, these process should interact, and rely on a common set of services and knowledge/information.

10.3.2. Knowledge Management Framework

Sources/standards: ISO 9001:2005 Knowledge Management clause, via various websites. BSI PAS 2001:2001 Knowledge Management, and PD 750x series. European CWA 14924:2004 European guide to good practice in knowledge management. (EC website http://www.knowledgeboard.com/ - abandoned) – all these cost, & so far I’ve used other people’s notes & summaries of them.

Business Process

Knowledge Management

Engineering

Kn

ow

led

geIn

form

atio

nD

ata

Figure 8: Knowledge Management Context.

A smart city needs information on which to base various kinds of decisions. PAS 182 / ISO WD 30145-2 expresses these different perspectives as strategic, analytical, operational, and critical:





Figure 9: Categories of Knowledge Demand (BSI PAS 182 Figure 5.2).

(The bottom layers – “crosses” in yellow & green – are at least examples of the kinds of information that are needed; not sure they help at this point in the document!)

PRINCIPLE To be “smart”, the information available for all these kinds of decisions should be consistent, and coordinated across sectors.





Common operating picture

Data marketplace

knowledge

data

City model

Sectoral data

Semantic mapping

Social media

mining

Secu

rity: con

fiden

tiality, integrity, ava

ilability

Me

tadata: accu

racy, co

mp

lete

ne

ss, pro

vena

nce

/ reliab

ility, ...

Val

ue

Val

ue

information

Actuators

Critical Operational

Analytical

Strategic

Sensors

energy transport Social care ...

Traffic light

Flood gate

Fire response call

Figure 10: City Knowledge.

Taking a top down perspective, the city (i.e., all its stakeholders) needs a constantly evolving, constantly updated digital (common operating) picture of the real world city, including not just the physical aspects, but also the social aspects ranging from administration and ownership to people’s sense of place and sense of well-being. However, the picture will always be incomplete, inaccurate, and out of date. That aspect is represented by metadata, which must be taken into account when using the data for any of the kinds of decision, listed above. To support the strategic and analytical views requires a sense of how the picture has changed over time.

Taking a bottom up perspective, there are many sources of data available: relatively static data from authoritative sources and surveys, “exhaust” (operational) data from existing business processes around the city, sensors for physical aspects of the environment, pro-active use of social media, and harvesting / mining social media for event notifications and even mood indicators. Making all this data available in a data warehouse, supported by an innovation culture, can enable a range of stakeholders to add value to the data, producing information & knowledge to support the decisions that each stakeholder is interested in.

For example:

Private parking space providers could be encouraged to provide real time data about parking spaces into the data market place, with a free to use mobile app, which locates the nearest parking space. The data value would be released back to the provider by the parking place charges.

In certain areas (depending on the citizen demographics) it may be possible to mine social media for information about traffic incidents. This information could be available to emergency services, highway authorities, and navigation apps – with appropriate anonymization.

In practice, most cities will take a melded approach, combining aspects of the top down and bottom up approaches. For example, a city could establish a data market





place, and provide data into it about public assets and business established in the city. Sectoral providers, such as utilities, could be encouraged to provide data into the market place. The city would then build a core common operating picture on that data market place, enhancing it as more data becomes available.

There are five types of barriers to data sharing: privacy, security, integrity, quality, and provenance. These all need to be properly managed in the information architecture of a city.

Privacy – data about identifiable individuals needs to be treated with care; in particular, people providing data need to be confident that it can only be used in ways which they have approved. Considered this way, that is true of all data – data sourced from commercial organisations may only be available to be used in specific circumstances. This traceability needs to be demonstrable and evident in a system, in order for potential data providers to trust it.

Security - similarly, data should only be available to authorised parties. It may be possible that some or most data can be available to everyone, but if this assumption is built into the system, by design or by neglect, then the data that can be processed will be more limited.

Integrity – in order to trust decisions made on the data, the systems must process the data reliably.

Quality – different kinds of data will have different quality profiles, and therefore be suitable for different purposes. For example, sensor data may generally have a high accuracy, but only be valid for a specific place and time. In contrast, data mined from social media may have a larger probability of error, but may be indicative of a more widely dispersed change in the environment.

Provenance – sometimes in lieu of specific quality measures, it is sufficient to know the source of the data. This is particularly true for authoritative data (e.g. ownership records, or street names) and forecast data.

Managing these aspects to maximise participation in a data market place, and value of the common operating picture, requires attention at the design stages, as well as instance metadata being preserved and enhanced as data moves through the systems.





10.3.2.1. Knowledge / Data Value Chain

Figure 11: Data to Knowledge ISO 9001 KM).

Figure 12: An Example Data Value Chain Using Analytics.





Figure 13: 30145-3 from OGC 14-115.

Figure 14: OGC 14-155 from FG-SCC TR & JTC1/SC1 report.

10.3.2.2. Knowledge Management Principles

Identifier strategy / management – data describing the physical and social environment of the city is mostly in the form of identifiable data objects that relate to specific real world things. Except for the most volatile data, each data item requires an identifier, which can be used to track the data object through its lifecycle, as it changes to represent changes to the real world.

In the geographic information domain, these are called feature instances, reflecting the tendency of geographers to consider the world as made up of features.

10.3.2.3. Knowledge / Information / Data Entity – Component Catalogue

The city’s data market place will contain various kinds of data, which taken together provide a common operating picture.

Master data registers (catalogues). This is a class of data entities: those that need to exist once in some authoritative sense. Good examples are:

register of businesses operating in the city

register of addresses

register of citizens

cadastre – who owns what

Each of these master data registers will have governance, stewardship, and a maintenance process. Some will be owned and managed outside the city, for example by a national authority.

There are other registers / catalogues which are more volatile (change more often), but where the overall system of systems would benefit from a single source of truth:





sensors

actuators

datasets and/or APIs available in the data market place

These system level registers may well be provided by the standard approach within that architectural component, e.g. internet domain name resolution, media access control (MAC) addressing.

Metrics – where a city knows what it wants to measure, this will provide additional information entities to manage. In many cases this may be set by external reporting requirements e.g. cleanliness of beaches, air quality, urban noise.

Examples of things to measure include the UN Sustainable Development Goals; the ISO, IEC, ITU, and other ‘smart city metrics’ standards; various European Commission Environmental Directives, for many of which INSPIRE provides the information model. Work is currently on-going in various SDOs to map from the goals, via the metrics to the data entities required to measure them. Examples of data items to support measurement include:

social sustainability: response time for emergency services: calculated from incident reports

environmental sustainability: noise levels: observations voluntarily collected from citizen’s mobile phones; city-owned sensor measurements

economic sustainability: number of empty shop units, calculated from business and address registers; supplemented with citizen observations (active reports, and indirect through mining social media)

Semantic mapping, by means of ontologies – a mechanism to bring together information from sectoral systems (rather than re-engineering them). The sectorial systems continue to report on e.g. crime, health incidents, school truancy; city ontology allows these to be collated into a common picture of people, places, and events.

City model – digital representation of the physical and social characteristics of the city. At least a collation of “digital built environment” (BIM), cadastre, business index, address, “greenspace”, ITS infrastructure, and utility infrastructure. This needs to bring together the indoor, outdoor, above & below ground spaces – and increasingly, “places” which exist in a purely digital sense.

From this discussion it is clear that each city will establish and evolve its own data component catalogue. The common thread is that it is likely to involve most of the types of information described here.

10.3.2.4. Data Entity/Business Function matrix

The purpose of the Data Entity/Business Function matrix is to depict the relationship between data entities and business functions within the enterprise.

The mapping of the Data Entity-Business Function relationship enables the following to take place:

Assignment of ownership of data entities to organizations

Understand the data and information exchange requirements business services





Support the gap analysis and determine whether any data entities are missing and need to be created

Define system of origin, system of record, and system of reference for data entities

Enable development of data governance programs across the enterprise (establish data steward, develop data standards pertinent to the business function, etc.)6

With a bottom up, data market place approach, this has to be largely self-managing with than market place. When data is supplied to the market place, ownership, provenance and so on are part of registering the data. This includes situations where an API is registered to give access to data. Even where the data is more static and could be managed more traditionally, such as an authoritative register, it makes sense to register it in the same way.

Similarly, systems that wish to use the data or APIs should register, in order that the pattern of demand can be monitored.

That in turn implies that the data market place is what needs governance, including identifying gaps where data would be useful but is not currently available.

As an alternative in TOGAF, this can be represented as a Data Dissemination diagram. It should be possible to generate this from a properly functioning data market place.

10.3.2.5. Data Lifecycle diagram

The Data Lifecycle diagram is an essential part of managing business data throughout its lifecycle from conception until disposal within the constraints of the business process.7

Potentially, each data entity can have a different lifecycle. However, it is likely that many entities will have similar lifecycles. It may be possible to create a set of data lifecycles, and for data entities to be attached to particular lifecycles when they are registered in the data market place.

Examples of data lifecycles include:

“standard” data lifecycle endorsed by DAMA: http://www.information-management.com/news/data-management/Data-Life-Cycle-Defined-10027232-1.html

Data capture; data maintenance; data synthesis; data usage; data publication; data archival; data purging.

Critique – in a smart city / data market place context, data “publication” generally occurs alongside usage, rather than afterwards.

ISO 15926 / STEP, originally for industrial process facilities, but recognised as having wider application

6 TOGAF notes 7 TOGAF notes

http://www.information-management.com/news/data-management/Data-Life-Cycle-Defined-10027232-1.html







W3C has collated various data life cycle descriptions at https://www.w3.org/2011/gld/wiki/GLD_Life_cycle, as part of its work to standardise the data life cycle applicable to ‘government linked data’.

CRUD

10.3.2.6. Knowledge management process

Knowledge management requires a business process; ISO 9001:2015 provides a generic process for this. Although aimed at businesses providing products and services, this approach could be adopted by a smart city.

“In ISO 9001:2015, clause 7.1.5, the organization is asked to identify, manage and make available all knowledge necessary to ensure process results which are in line with quality and conformity requirements.” (http://iso9001revision.com/knowledge-management). Clause 7.1.6 “defines requirements for the handling of organizational knowledge in the following four phases:

1. Determine the knowledge necessary for the operation of processes and for achieving conformity of products and services;

2. Maintain knowledge and make it available to the extent necessary;

3. Consider the current organizational knowledge and compare it to changing needs and trends;

4. Acquire the necessary additional knowledge (http://isoconsultantpune.com/iso-90012015-organizational-knowledge/).

10.3.3. Engineering Framework

TOGAF includes the concept of an “Enterprise Continuum”. The Enterprise Continuum is a view of the “Architecture Repository” that classifies architecture artefacts as they evolve from generic reference architectures to organisation-specific architectures. The Architecture Repository can be used to store different classes of architectural output at different levels of abstraction, created by the ADM.

https://www.w3.org/2011/gld/wiki/GLD_Life_cycle

http://isoconsultantpune.com/iso-90012015-organizational-knowledge/

http://isoconsultantpune.com/iso-90012015-organizational-knowledge/





Figure 15: TOGAF Enterprise Continuum8.

The Enterprise Continuum consists of three main parts: The Enterprise Continuum, the Architecture Continuum and the Solution Continuum. The Architecture Continuum is part of the Enterprise Continuum and is supported by the Solution Continuum. The Architecture Continuum represents Architecture Building Blocks that evolve through their development from abstract and generic entities to organisation-specific entities.

The Architecture Continuum shows how architectures are developed and evolved from Foundation Architectures through to Organisation-Specific architectures.

8http://pubs.opengroup.org/architecture/togaf9-doc/arch/Figures/39_entcon_oview.png

http://pubs.opengroup.org/architecture/togaf9-doc/arch/Figures/39_entcon_oview.png





Figure 16: TOGAF Architecture Continuum9.

TOGAF includes the Technical Reference Model as Foundation Architecture from which more specific architectures are based.

Figure 17: TOGAF Technical Reference Model (showing service categories)10.

9 http://pubs.opengroup.org/architecture/togaf9-doc/arch/Figures/39_archcon.png.

10 http://pubs.opengroup.org/architecture/togaf9-doc/arch/Figures/43_trm_detail.png.

http://pubs.opengroup.org/architecture/togaf9-doc/arch/Figures/39_archcon.png

http://pubs.opengroup.org/architecture/togaf9-doc/arch/Figures/43_trm_detail.png





A Smart City Engineering View can be developed using Industry Architecture. Industry Architectures guide the integration of common systems components with industry-specific components, and guide the creation of industry solutions for targeted customer problems within a particular industry.

This Smart City Engineering View would respond to the business process needs identified in Section 10.3.1 and implement the technology to exchange the knowledge elements identified in Section 10.3.2.

A key element of the Engineering View is a Solution Concept Diagram or similar overview of the engineering architecture. As identified in TOGAF, a Solution Concept Diagram provides a high-level orientation of the solution that is envisaged in order to meet the objectives of the architecture engagement. In contrast to the more formal and detailed architecture artefacts developed in the subsequent TOGAF phases, the solution concept represents a "pencil sketch" of the expected solution at the outset of the engagement.

Figure 18 provides an initial Smart Cities Solution Concept Diagram. This high-level engineering view of Smart City is organised in layers typical of an information system deployment. The layers in this diagram are based on the approach defined by the ITU Focus Group on Smart Sustainable Cities. The layers are consistent with the approach used in China’s Smart City Pilots.

Some elements of the diagram are more mature and have existing standards. Other elements are new and are under active development, e.g. IoT.

Figure 18: Smart Cities Solution Concept Diagram- SOURCE ISO/IEC JTC 1/WG 11

(Originated from OGC).





Figure 19 shows the latest ITU-T recommendation, Y.2060 (ITU-T 2013), which provides an overview of the IoT space with respect to ITU-T. This recommendation describes a high-level overview of the IoT domain model and the IoT functional model as a set of Service Capabilities.

Figure 19: ITU-T IOT Reference Model.

Figure 20 provides a Smart Cities Solution Concept Diagram, which aims to combine the three different viewpoints above into a single viewpoint. The figure is similar to the solution concept diagrams above but with the important addition of a positioning layer at the bottom. Some of the ‘horizontal’ components have also been moved to ‘vertical’ layers as they cut across various layers within the overall architecture e.g. networks and transport.

The layers in the Smart City Concept Diagram are discussed in the Annex. Some elements of the diagram are mature and have existing standards. Other elements are new and are under active development, e.g., IoT.

https://www.google.co.uk/url?sa=i&rct=j&q=&esrc=s&source=images&cd=&cad=rja&uact=8&ved=0ahUKEwi-27-RlPXNAhVqB8AKHV98CFkQjRwIBw&url=https://www.linkedin.com/pulse/m2m-iot-survey-various-standards-raja&bvm=bv.127178174,d.ZGg&psig=AFQjCNHFjyiOzCQ_na45xT0rwze_59nGEQ&ust=1468661305451863





Figure 20: Smart Cities Solution Concept Diagram.





Figure 21: Smart Cities Reference Architecture.

10.3.3.1. Positioning Services

The Positioning Services Layer would include geodetic, co-ordinate reference and global positioning related capabilities. Location related positioning services could be fulfilled via a range of methods e.g. satellite or 4G depending on the level of positional accuracy required. The location positioning services should be capable of recording position on all scales necessary for effective decision-making. For example, meter in rural areas, cm for city level, mm for buildings and sub-0.1 mm for building components and plant.

10.3.3.2. Sensing Services

The Sensing Services Layer would include ‘sensor’ related capabilities whether these are Internet of Things (IoT) related devices, formal surveying (land, asset management, construction) methods or citizen based crowd sourcing from consumer devices. The data capture services should be capable of capturing all significant features in the built and natural environment that are required to support onward business processes and effective decision making.

The Sensing Services Layer would form an important building block within any Urban Platforms and be the source of various sectorial data, which would subsequently be used within the Data Services, Application Services and Business Services Layers.





10.3.3.3. Data Services

The Data Services Layer would include core data management and data lifecycle (e.g. ingest, assure, integrate etc.) related capabilities. The data services should be capable of providing all the data management, processing, exploitation and dissemination capabilities required to support the onward application centric and business process centric uses of the data via the Application Services and Business Services Layers.

Within TOGAF this would equate to the Data Architecture layer.

10.3.3.4. Application Services

The Application Services Layer would include all the software applications that act upon the data components provided via the Data Services Layer in order to support the onward Business Services Layer. Application related services should provide all the functional capabilities (e.g. analytics, reporting, data visualisations etc.) required to support onward business process and services (e.g. waste management, asset management, urban mobility etc.). This layer should encapsulate, decouple and abstract business logic and data access. The idea behind such a layer is to have an architecture, which can support multiple business services.

Within TOGAF this would equate to the Application Architecture layer.

10.3.3.5. Business Services

The Business Services Layer would include smart city sectorial specific business services which would be consumed by a variety of consumers and stakeholders (e.g. city leaders, citizens, operations, and commerce etc.).

A ‘business service’ can be thought of as any service that is delivered to ‘customers’ by ‘business units’. A more traditional example would be, delivery of financial services to customers of a bank, or goods to the customers of a retail store. Successful delivery of business services often depends on one or more ‘IT services’ provided by the Application Services Layer. A business service can consist almost entirely of an IT service (e.g. an online banking service) or can be much more business services centric (e.g. a professional or managed service).

The business services layer should be capable of providing all the operational and governance capabilities required to support a smart city sectorial system.

Within TOGAF this would equate to the Business Architecture layer.

10.3.3.6. Consumers

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.3.3.7. Cross-Cutting Services

The Smart City Reference Architecture includes four “vertical” or crosscutting layers – namely – Security Services, Technology Services and Supporting Services, which are not bound to or specific to a given “horizontal” layer. They would include various capabilities that could be required for any of the horizontal layers.





10.3.3.7.1. Security Services

The Security Services Layer would include a set of standard security capabilities such as Identify Management, Authentication, Authorisation, Encryption, and Auditing etc.

10.3.3.7.2. Technology Services

The Technology Services Layer would include a set of standard technology capabilities such as Integration, Networks & Communications, Transaction Management & Orchestration and Computing Infrastructure (e.g. cloud, on-premise or hybrid)

10.3.3.7.3. Supporting Services

The Technology Services Layer would include a set of standard enterprise support capabilities such as Collaboration, Document and Knowledge Management and Business Intelligence.





11. Annex

11.1. Rotterdam

Figure 22: Rotterdam Design on headlines.





Figure 23: Rotterdam specific architecture.





Figure 24: Eindhoven discourse.





Figure 25: Societal Needs are prime.





Figure 26: Layers by Spanish national standard UNE 178104.

This figure has been proposed to ITU for consideration and recommendation

http://www.itu.int/itu-t/workprog/wp_item.aspx?isn=10815

http://www.itu.int/itu-t/workprog/wp_item.aspx?isn=10815

DELIVERABLE - ESPRESSO...

Documents

Transcript of DELIVERABLE - ESPRESSO...