D3.2 Smart City Info Architecture - epic-cities.eu Smart City... · DELIVERABLE)) Project Acronym:...

DELIVERABLE

Project Acronym: EPIC

Grant Agreement number: 270895

Project Title: European Platform for Intelligent Cities

Deliverable 3.2: Smart City Information Architecture and Functional Platform

Version: 1.00

Authors: Margarete Donovang-‐Kuhlisch (IBM) Wilhelm Stoll (IBM)

Martin Schütz (IBM) Keith Osman (BCU)

Leonidas Kallipolitis (ATC) Pavlos Kranas (NTUA) Andreas Menychtas (NTUA) Internal Reviewers: NAV (Philippe Perennez) HIL (Joshua Cooper) IBBT (Wouter Van den Bosche)

Project co-‐funded by the European Commission within the ICT Policy Support Programme

Dissemination Level

P Public X

C Confidential, only for members of the consortium and the Commission Services

EPIC – Deliverable D3.2

© EPIC consortium 2 Version 1.0 -‐ 30/11/2011

Revision History

Revision Date Author Organisation Description

0.01 20/09/2011 MDK IBM Initial Structure

0.03 29/09/2011 MDK IBM First Draft

0.04 13/10/2011 MDK IBM First Revision

0.05 19/10/2011 MDK IBM Final Draft – including chapter 4

0.06 04/11/2011 Andreas Menychtas

NTUA Various Content and format changes


NTUA Internal QA version


NTUA Final Version

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.



Table of Contents 1 Executive Summary ......................................................................................................................................... 6 2 Introduction ........................................................................................................................................................ 7 3 Platform Technical Architecture .............................................................................................................. 10 3.1 System Architecture .......................................................................................................................... 12 3.2 Data Flows ............................................................................................................................................ 14 3.2.1 Common Alerting Protocol (CAP) ............................................................................................................. 15 3.2.2 Event Flows ........................................................................................................................................................ 16 3.2.3 KPI Flows ............................................................................................................................................................. 17 3.2.4 Notification Flow .............................................................................................................................................. 18

3.3 Portal and GIS Architecture ............................................................................................................ 18 3.3.1 Geospatial standards ...................................................................................................................................... 22

3.4 Security Architecture ........................................................................................................................ 22 3.5 User Management .............................................................................................................................. 27 3.5.1 User Profile Management ............................................................................................................................. 27 3.5.2 User and Group Management ..................................................................................................................... 28

4 Smart Relocation Service hosted on the Platform ............................................................................ 30 5 Customization of the Platform .................................................................................................................. 34 5.1 Personalization ................................................................................................................................... 35 5.2 Definition of new Platform Page ................................................................................................... 36 5.3 Define Application Portlets ............................................................................................................ 37 5.4 Portlet Configuration ........................................................................................................................ 39 5.5 MAP Extensions .................................................................................................................................. 40 5.6 Customization of Event Processing .............................................................................................. 40 5.7 KPI Definitions .................................................................................................................................... 42

6 Platform Extensions ...................................................................................................................................... 44 6.1 Federated Enterprise Service Bus ................................................................................................ 44 6.2 Business Process and Case Management ................................................................................... 44 6.3 Business Analytics and Intelligence ............................................................................................. 45

7 Conclusions ....................................................................................................................................................... 48 8 Abbreviations ................................................................................................................................................... 49 9 References ......................................................................................................................................................... 51



List of Figures Figure 1: IBM EPIC platform – Component Overview .............................................................................. 9 Figure 2: Smarter City Component Diagram [1] ....................................................................................... 10 Figure 3: EPIC Platform Component Model ................................................................................................ 11 Figure 4: EPIC Platform System Architecture ............................................................................................ 12 Figure 5: Event Processing System ................................................................................................................. 13 Figure 6: KPI Management System ................................................................................................................. 14 Figure 7: Overview of System Flows .............................................................................................................. 15 Figure 8: Event Flows ........................................................................................................................................... 16 Figure 9: KPI Flows ................................................................................................................................................ 17 Figure 10: Notification Flows ............................................................................................................................ 18 Figure 11: UI Component Architecture ......................................................................................................... 19 Figure 12: MAP Basics within the Platform ................................................................................................ 21 Figure 13: GIS and CURI Integration .............................................................................................................. 21 Figure 14: Basic SSO and Access Control ..................................................................................................... 23 Figure 15: Platform Authentication ............................................................................................................... 24 Figure 16: TAM/Portal Integration ................................................................................................................ 25 Figure 17: TIM/Portal Integration .................................................................................................................. 26 Figure 18: LDAP Integration .............................................................................................................................. 26 Figure 19: Security Service Overview ........................................................................................................... 27 Figure 20: User Management via the EPIC Portal .................................................................................... 28 Figure 21: Portal-‐Based User and Group Management ......................................................................... 28 Figure 22: Phase 1: Planning for Relocation .............................................................................................. 31 Figure 23: Phase 2: Discover Properties ...................................................................................................... 32 Figure 24: Phase 3: Decision (Citizen’s Collaboration with Realtor & Public Authorities) .... 32 Figure 25: Default Frontend scheme ............................................................................................................. 34 Figure 26: Default UI Design .............................................................................................................................. 35 Figure 27: Theme Customization .................................................................................................................... 36 Figure 28: New Portal Page ............................................................................................................................... 37 Figure 29: New Map Portlet ............................................................................................................................... 38 Figure 30: Default Event Portlet Appearance ............................................................................................ 39 Figure 31: Customized Event Portlet ............................................................................................................. 40



Figure 32: Message Flow Definition ............................................................................................................... 42 Figure 33: KPI Ontology Model ........................................................................................................................ 42 Figure 34: New Energy Consumption KPI ................................................................................................... 43 Figure 35: Service Visibility ............................................................................................................................... 44 Figure 36: Case Management Building Blocks ........................................................................................... 45 Figure 37: Power of Analytics in Public Sector ......................................................................................... 47

List of Tables Table 1: Abbreviations ......................................................................................................................................... 50



1 Executive Summary As Europe develops towards a politically and economically integrated body, agencies, organisations and enterprises from various nations face the challenge of having to collaborate and provide and share information and services to achieve common goals and to implement the reality of the EU Single Market. European and national legislations need to set the context and rules for such business conduct in multi-‐national service-‐oriented ecosystems, as agile business process management needs more than a technical interoperability foundation. The European Interoperability Strategy and Framework requires also semantic, procedural and organizational interoperability on-‐top of a hosted interoperability platform in the future internet of people, things and services. The smart city CIP project EPIC addresses as a pilot the requirement of cross country collaborative relocation services for citizens moving from one city to another across the EU Member States. The Relocation Service facilitates the mobility of people in the single market of Europe. The goal is to enable increased jobs, competitiveness, innovation and growth in a globalized world while ensuring compliance to security and privacy policies. This document is a technical white paper describing the “Smart City Information Architecture and Functional Platform” implemented for the participating living labs to pilot and validate of the selected smart services to support the cross-‐border relocation of a family. To really make these services citizen-‐centric, integration, interaction and collaboration between governmental and non-‐governmental organizations across multiple countries has to be enabled. In addition, information about employment, social security, healthcare insurance etc. has to be interchanged between public authorities and private organizations. To this direction, the proposed platform addresses the aforementioned issues following the extensive requirements analysis outcomes as described in D2.3 -‐ Online Service Delivery Baseline & technical requirements report [7] and the architecture design analyzed in D3.1 -‐ Technical Integration and architecture plan report [9] of EPIC Project. The structure of this document is as follows: in the introduction of chapter 2, we briefly define the concept of a smart city and connect to the high-‐level architecture of the EPIC Platform. Chapter 3 describes the EPIC platform in technical detail. Whereas the platform is purely built upon open standards and protocols, the implemented service management components make the platform unique in the market. Chapter 4 depicts how the major functional building blocks of the platform are being used to support the relocation scenario leveraging all the pilot applications developed in EPIC. Chapter 5 briefly touches on the deployment tasks to deliver a new application service from the platform. Finally, chapter 6 addresses the issues of functional scalability of the platform. In chapter 7, we conclude with a brief outlook.



2 Introduction This document describes the Smart City Information Architecture and Functional Platform delivered by EPIC. The design of the EPIC smart city platform is based the analysis of the requirements of EPIC project that took place in WP2 and the project vision on ‘smart city’ concept [8]. As presented in project vision report a truly ‘Smart City’ is one that is able to:

• Benefit from the innovative developments of citizens, SMES and other actors from across Europe rather than just within their own cities.

• Leverage a service infrastructure that is capable of delivering ‘one stop government’ through the integration of services, interoperability of systems and use of actionable intelligence in service delivery.

• Contribute to a multi-‐national service-‐oriented ecosystem by providing and sharing open business processes as services with other cities.

Another important aspect that was taken into consideration is the IBM understanding of the capabilities that make a city smart [1] as the key technology and infrastructure provider for intelligent cloud-‐based services:

• A well-‐managed city works to create an optimal urban environment for citizens, visitors, and industries by focusing on urban design, energy and water management, and an efficient and easy-‐to-‐use transportation system. These cities provide better performing and reliable city services that enable simplified and integrated access to services.

• A healthy and safe city addresses the health and safety of residents and visitors through innovations in local healthcare networks, disease management and prevention, social services, food safety, public safety, and individual information privacy.

• A sustainable city implements concrete measures toward sustainability through, for example, reduced consumption of energy and water and reduced emissions of CO2. Possible measures that can make a city sustainable include urban planning principles for mixed land use, architecture and construction principles for buildings, and methods to use rainwater instead of treated water.

• A city with good governance strives to improve the quality and efficiency of city services. It mandates transparency and accountability at all levels of the government. It provides the means to listen, understand, and respond to the needs of its citizens and businesses.

• A city that incorporates culture and events attracts visitors and keeping citizens interested in the city through investments in arts, culture, and tourism. These investments are a great way to draw attention to the city and a way to establish the city as a world-‐class location to live in.



• A city focused on its citizens looks to address their needs by providing information and access to city services in a convenient and easy-‐to-‐use manner. When done right, both the citizens and city government can benefit. This mechanism gives the citizens access to the information and services when needed and gives the city a means to share important information and obtain input from their citizens in a timely manner.

• A city of digital innovation focuses on using strategic investments in connectivity and communications (for example wireless broadband either broadcast or through hotspots). It attracts cutting edge businesses in the industrial and high-‐tech fields and builds human and intellectual capital.

• A city of commerce establishes itself as local, regional, or national center of commerce and economic development. It builds local expertise in a specific industry and the infrastructure and services to support continued growth and to remain competitive.

• A city attracting and keeping skilled workers promotes itself as being a desirable place to locate to or to grow up and stay in. This ability to maintain skilled workers is accomplished by anticipating and accommodating shifts in business needs, skills, local population, and demographics to offer economic opportunities.

• A city with free flowing traffic identifies and manages congestion actively. This demand is accomplished by making various forms of transport (such as road, air, rail, and bus) cost effective and efficient.

The platform in this manner is also fulfilling the requirements of the smart pilot applications deployed and evaluated in the EPIC project: the relocation, the urban planning and the smart energy service. To achieve this, the platform is built on top of three fundamental architecture principles:

• Modularization of architectural components – build multi-‐purpose components that can be extended as necessary.

• Normalization of system data – the platform is designed around standardizing and normalizing data from participating services and sub-‐systems and provides a standard format and interfaces that allow administrators of smart city participants to define their end of the interfaces.

• Standardization of common functions – doing similar things in a unified fashion. The purpose of the platform is to present a high-‐level view within a specific stakeholder’s environment or set of domains. This is a different goal from that of specific service providers which are more focused on environmental details. Through its integration capability, the platform supports the transition of a city from “intelligent” to “smart”: it supports the management of significant events, alerts and change of circumstance from a high-‐level, city-‐wide perspective. It monitors pre-‐set key performance indicators on behalf of the city officials, provides actionable intelligence via the smart city portal and triggers measures and actions in near real time.



In our “Technical Integration Architecture Plan” the architecture for the EPIC platform was outlined as shown in Figure 1.

Figure 1: IBM EPIC platform – Component Overview

In the following chapter this rather rough architecture figure will be refined and discussed from different perspectives (e.g. functionality, data flow, communication etc.). After that discussion the usage and possible extension of the platform will be described.

IBM EPIC Platform iLOGRules Execution

WebSphereProcess Server

WebSphereESB

WebSphere ServicesRegristry & Repository

TFIM

WebSpherePortal Server +

Forms

B2B Adaptors

IBM EPIC Platform iLOGRules Execution

WebSphereProcess Server

WebSphereESB

WebSphere ServicesRegristry & Repository

TFIM

WebSpherePortal Server +

Forms

B2B Adaptors



3 Platform Technical Architecture The ability to communicate, share information, and collaborate in real time with city officials and citizens is an essential element to making cities smarter. City officials, enterprises and citizens working together in different service domains can communicate with each other by using an integrated collaborative environment that includes email and calendar sharing. Real-‐time collaboration can be achieved through sharing data, videoconferencing, online meetings, telephony, and instant messaging. Through situational awareness, stakeholders can see who is online and their current location, enabling better utilization of resources and reaction to events. Important documents can be shared across teams and viewed online, through the use of wikis, blogs, team spaces, and communities. Citizens and city officials can be notified of events and issues happening within the city and enable immediate situational feedback, creating a closed loop process. By using these capabilities the city can provide for more optimized and interactive services. Within the Smarter Cities Initiative, IBM has defined a component business model as depicted in Figure 2. For the purpose of EPIC, IBM has extracted and implemented the core components needed in any smart city application/service.

Figure 2: Smarter City Component Diagram [1]



The instrumented layer (lowest layer in Figure 2) has various data sources including sensors, meters, cameras, and unstructured data. These data sources measure and feed data back to systems, such as Supervisory Control and Data Acquisition (SCADA), which in return monitor and control particular functions. The devices and products at this layer are provided by various companies that specialize in this area. The activities found at this level can measure water quality, collect electrical meter readings for a grid, or provide building measurements to determine its energy usage. Aspects of this data can be sensed and used to generate events and alerts, which in turn, can be published by using an enterprise service bus (ESB). The interconnected layer (middle layer in Figure 2) adds event services that map various inputs (as identified in the instrumented layer) into events of interest. This data can be combined with other event-‐related information occurring throughout the city or domains to create a rich source of data that can be used to enhance decision making. The intelligent layer (upper layer in Figure 2) processes relevant city data in a broader context to identify city-‐relevant events that need to be analyzed or acted upon. A service-‐oriented architecture (SOA)-‐based model, along with existing applications and management systems, is used to transform data and perform analysis. Analytics along with additional related data (such as weather) can be applied to provide further insight. This layer includes user or role-‐oriented capabilities, where data and information are displayed by using various types of user interfaces, such as dashboards. Accessing this data and information with intelligence applied to it can ensure that the users can take action and make informed decisions. Figure 3 illustrates which components make out the foundational core of the EPIC platform.

Figure 3: EPIC Platform Component Model

Intelligent Operations CenterIntelligent Operations CenterPredictive Systems

Predictive Systems

Modeling & SimulationModeling & Simulation

City ArchivesCity Archives

City Governance

Policy

City Governance

Policy

DashboardsDashboards

AlertsAlerts

Directives

DirectivesKPI’sKPI’sAlertsAlerts

Event Rules Workflows

Standards Based Interfaces

Domain Specific Interfaces

GatewayGateway

WaterWater

GatewayGateway

TrafficTraffic

GatewayGateway

Public SafetyPublic Safety

GatewayGateway

ElectricElectric

Reports/AnalysisReports/Analysis

Advanced Visual Features

Advanced Visual Features

Semantic Models

Service BusService Bus

Analytics

Visualization

DataIntegration

GatewayGateway

BuildingsBuildings

Other Feeds:

WeatherCitizensHealth

Financials…

Other Feeds:

WeatherCitizensHealth

Financials…



This component model is a one-‐level-‐further drill-‐down of the high-‐level architecture presented in Figure 1. It shows how the different sensor information (e.g. the smart meter information, the list of available properties (in the relocation process) or the reported street damage (in the urban planning application) can be integrated and presented in the city’s dashboard. Workflows, semantic models and event rules (key performance indicators) are being used to take effect-‐oriented measures to optimize city operations.

3.1 System Architecture Figure 4 illustrates that the platform is not only a set of context agnostic middleware components, but also includes the implementation of a set of horizontal application services. Furthermore, it shows the modularity of the system.

Figure 4: EPIC Platform System Architecture

This architecture diagram gives deep insight into the platform’s layered structure build on an open-‐standard-‐based SOA foundation, WebSphere Application Server (WAS). Several more IBM middleware products are deployed on top of the application server:

• WebSphere Portal Server

• Lotus Sametime

• WebSphere Business Monitor and Tivoli Service Request Manager (to function as process server)

© 2011 IBM Corporation



• WebSphere Message Broker (to function as enterprise service bus) and

• DB2 as database for harmonized system data. This runtime environment is complemented with a security layer described in detail later on in this document.

Figure 5: Event Processing System

The platforms event processing system (Figure 5) is composed of several key components working together to provide effective message processing in the platform and within the hosted applications. Events can be either notifications or alerts entering the system through standardized interface. In a first processing step, these messages are formally validated and de-‐duplication measures are taken to assure authenticity. Afterwards, the messages are recorded as formal events and undergo an event analysis: rules and key performance indicators are used to determine the application and semantic relevance of the event e.g. whether energy consumption in a neighbourhood goes beyond a healthy threshold. If necessary, the event processing system creates incidents and triggers pre-‐defined workflows to handle the situation, whether it is an emergency response (e.g. fire) or the application for a citizen service (e.g. granting a resident permit). Needless to say, key performance indicators (KPI) vary from service domain to service domain and are specific to business applications. As the purpose of the platform is to present a high level governance view within a set of domains, it encompasses means for the business administrator to model and define application-‐specific KPI. The inherent Model Manager (IBM©) supports this activity. The KPI are then deployed within WebSphere Business Monitor which applies them together with the overall business rules in the event processing task. Figure 6 illustrates the KPI management system.




Figure 6: KPI Management System

3.2 Data Flows The mandate for the platform is to enable intelligent governance of smart city operations. This capability will be demonstrated within the end-‐to-‐end relocation service (being offered by the city of Brussels to a new resident) serving as a show case for the three pilot applications. In such a complex use case, the platforms ability to manage complex application and system data flows is of crucial importance. Figure 7 illustrates the systems flow for the different data types: events, KPI, sensors and external data sources.




Figure 7: Overview of System Flows

The following chapters describe in more detail the flows for the different data categories.

3.2.1 Common Alerting Protocol (CAP)

The Common Alerting Protocol (CAP) is one of the EDXL initiatives [2]. EDXL is a set of incident and emergency-‐related standards for data interoperability from OASIS. EDXL is a broad initiative to create an integrated framework for a wide range of emergency data exchange standards to support operations, logistics, planning, and finance. CAP standardizes the content of alerts and notifications across all hazards, including law enforcement and public safety as well as natural hazards such as severe weather, fires, earthquakes, and tsunamis. CAP can be used to define and model the core concept of an alert, including key attributes such as category, status, scope, certainty, severity, urgency, onset time, expiration time, response type, instructions, etc. Although CAP was created in the context of EDXL to address the specific needs of the emergency management domain, it is being adopted in the industry as a general-‐purpose alert protocol. As such, CAP qualifies as a core standard for smarter city solutions, which explains its inclusion in this article. EDXL, as a whole, is emergency management specific and will be discussed in a follow-‐up article specific to the emergency management domain.




3.2.2 Event Flows

Figure 8 shows the process for the case of events:

• A CAP event message is sent into the system

• The message flows through Message Broker: input queue CAP_IN, output queue CAP_OUT

• Rules are processed by Omnibus and placed in internal data store

• The message is picked up by the event reader. Policies are triggered and process the message as necessary:

• Message is placed into the database

• Update is sent to the presentation layer

• The event update servlet notifies data provider that updates are available for users

• The event data provider retrieves latest updates’ presentation.

Figure 8: Event Flows




3.2.3 KPI Flows

Figure 9 shows the KPI processing in detail:

• A CAP event message with CAP Code = KPI is sent into the system

• The message flows through Message Broker: input queue CAP_IN, output queue CAP_OUT

• Rules are processed by Omnibus and placed in internal data store

• The message is picked up by the event reader. Policies are triggered and process the message as necessary:

• The message is placed into the database

• The message is placed into the KPI_IN queue

• Message Broker transfers to KPI_OUT queue

• The WBI event emitter consumes the message from KPI_OUT queue

• A KPI update message is sent to portal server

• The KPI data provider pulls KPI change and updates the GUI.

Figure 9: KPI Flows




3.2.4 Notification Flow

Finally, Figure 10 gives the details for notifications:

• A notification event is sent from WebSphere Business Monitor or from any third party application

• The message is placed into the notification queue

• Rules are processed by Omnibus and placed into the internal data store

• The impact notification policy sends message to the presentation layer.

Figure 10: Notification Flows

3.3 Portal and GIS Architecture Visualization of the city and service status and the important application information is essential to making predictions and reacting to events and changes. The platform supports the design of the user interface to be flexible with regards to layout of information, while providing a standard look and feel. Effective UI layouts are governed by the following factors:

• Presenting easily consumable critical information to decision makers such as the mayor and domain managers

• Bringing different data sources together to provide comprehensive information about service status, operations, domain business, and infrastructure




• Displaying summarized data that can be expanded giving access to detailed information

• Providing alerts driven from real-‐time information, allowing immediate analysis and action

• Showing relevant information across dynamically linked views, e.g. by selecting a point on a geospatial map, the associated views show related detailed information

• Providing a consistent look and feel to minimize the learning curve and confusion such that the user interface is uncomplicated and self explanatory.

Each type of user requires the right and appropriate level of detail as in the following examples:

• Executive users want high-‐level information (scorecards and charts) to see the big picture of the city (e.g. the decision maker in the environmental department of the city)

• Detail users need more in depth information and sometimes raw data to be used in their purpose-‐driven applications (e.g. the resident looking for a place to live in)

• Analytic users might need access to the data so that they can run further analysis on it (e.g. the urban planner needing trend prediction).

Figure 11: UI Component Architecture

In the top layer, all widgets share a common client side data and connection framework. The Tivoli Common Topology (TCT™) and the Common UI REST Interface (CURI™) are a result of a cross-‐divisional effort to help enable greater re-‐use of UI components within IBM solutions. While they have taken the name of “topology”, the broader aim is to provide:




• Common Navigation Widgets with functionality that extends well beyond topology rendering. It is a composite widget that uses the Common UI Abstraction Layer to visualize and interact with dataset contents.

• A single Common UI Abstraction Layer. This layer can feed common client-‐side UI widgets that are generic and not restricted to topology. Common widgets such as tables, charting, scorecards, custom gauges can also use this abstraction layer to consume information for visualization in a standardized way regardless of back-‐end application.

• The CURI layer consists of client side and server side components: o Client

§ Dojo Data Stores § Client Nav Model to isolate UI code from any knowledge on the server

side. It brokers all communication with the Common UI REST service. o Server

§ CURI that implements a set of REST URIs designed and agreed to as part of a joint effort between TCP, TIP and SAPM. The REST service can be extended with implementations of the Java Navigational Data Model or proxy requests to other instances of the Common UI REST Service running on other servers.

§ Product-‐specific providers (e.g. ESRI) can extend the Common UI REST Service. They implement a thin set of Java interface (called the Navigational Data Model) and register themselves with the service.

Dojo 1.5 [4] is made available through the custom portal scheme providing a powerful development toolkit for UI enhancements. To do so, the platform encompasses a pluggable data provider interface to feed the presentation layer UI widgets. There also is a common API for creating and modifying events and incidents and to define and maintain role and group based security concepts featuring grained data access. Figure 12 summarizes the basics of the included map services. It illustrates the integration within the portal and its collaboration environment. In addition, external data providers can hook into the platform; initial strategic teaming agreements have been finalized already, e.g. between IBM and ESRI for basic mapping data. Special effort has been put into the integration of the GIS and CURI, as is described in Figure 13. The creation of a custom adapter provides a single approach to the UI. This includes common security and performance concerns.



Figure 12: MAP Basics within the Platform

Figure 13: GIS and CURI Integration





3.3.1 Geospatial standards

The Open Geospatial Consortium (OGC, [3]) is an international organization of over four hundred organizations offering an array of standards for geospatial and location-‐based services. These standards are freely available at no cost and cover data models, encodings, interfaces, and best practices. They are also incorporated in the platform.

3.3.1.1 OGC Abstract Specification

The OGC Abstract Specification provides the conceptual foundation on which the OGC Standards Baseline, the core OGC standards, is built. The OGC Reference Model describes these standards and how they relate to one another. Geospatial information encompasses both location and time. Locations can be described either as civic locations, such as a postal address, or as numeric coordinates in a coordinate reference system. The OGC Abstract Specification defines coordinate reference systems that have a reference to the Earth. It includes datum that define the origin, orientation, and scale of the coordinate system tied to the Earth.

3.3.1.2 OpenGIS Geography Markup Language (GML)

OGC's most prominent standard, GML, defines an XML grammar for the exchange of geospatial information on the Internet. The standard is available as an XML Schema and has become the reference for the transport and storage of geographic information in the industry. Because GML only covers geographic features, locations in GML can only be expressed based on geometric points. In particular, GML does not support civic locations. For this reason, GML is sub-‐optimal for the development of a core reference data model for smarter city solutions. Using one of the richer, higher-‐level standards that builds on GML, such as OpenGIS Location Services (OpenLS), appears to be a better approach. OpenLS is designed for enabling location-‐based applications and defines several data types that are not part of GML such as location. OpenLS's location encompasses several types of locations, including an address defined in such a way that it can accommodate international addresses, a point of interest identified by name such as the name of a restaurant, or a geographic position defined by its coordinates. All of these types of locations can be of use in smarter city scenarios including the previously described planned roadwork. OpenLS is defined as an XML Schema, based on GML's XML schema.

3.4 Security Architecture As already illustrated in Figure 4, the functional architecture of the platform is sided by a comprehensive security architecture.



Figure 14: Basic SSO and Access Control

Figure 14 describes the components for the basic single-‐sign-‐on (SSO) and access control. The WebSeal component of Tivoli Access Manager h(running on an HTTP server in the demilitarized zone, DMZ) functions as forward and reverse proxy between the user coming from the internet and the services and applications hosted on the platform. It uses the Lightweight Third Party Authentication method during the portal login phase and manages the tokens used therefore. In particular, single-‐sign-‐on towards the web application server (WAS) and the collaboration foundation (Sametime) is initially performed. Each application/web server running on the application server or within a hosted process management solution is enabled to perform its own permission and access control management. Figure 15 shows in more detail the steps being performed throughout authentication.




Figure 15: Platform Authentication

WebSeal has the responsibility to implement coarse grained web resource access: it controls who may access portal, application server, web service etc. Within the EPIC platform, we have solely allowed portal access for registered users; fine-‐grained access control is maintained on security level 2 and 3. Within the portal’s access control list (ACL) fine-‐grained portal access is achieved: who may access what pages and/or portlets with the portal server. Like the user definitions themselves, the ACL are stored in and drawn from the LDAP directory. Finally, on the information layer data access can be controlled: who may access which content within each portlet.




Figure 16: TAM/Portal Integration

The integration of Tivoli Access Manager within the Portal Server environment implements the core access control paradigm that roles (not individuals) are given permissions to use resources. These permissions are being created, retrieved, updated, destroyed/deleted (CRUD) during their lifecycle. Figure 16 summarizes the alternatives with respect to the externalization of security policies from portal or application web service to TAM. Similarly, exploiting Tivoli Identity Manager allows for the implementation of the identity paradigm that individuals are assigned to roles which map into LDAP groups. It is important to note that any individual user can have more than one role within that concept thus authorizing him/her to use different back office services and applications. Figure 17 shows how the integration of TIM and portal can be exploited to aggregate personalized portal UIs based on a harmonized identity profile.




Figure 17: TIM/Portal Integration

As most of the organizations and service providers using the platform already will have one or more user repositories in place, several options exist for the integration with these existing systems in regards to directory and identity management. Figure 18 illustrates those.

Figure 18: LDAP Integration

Finally, the platform’s security service introduces the concept of “category” to limit the content presentation to specific data categories re-‐using existing portlets. The implemented





paradigm here is the one that users get access to a category of data based on membership in LDAP groups. Figure 19 summarizes this function of the composite security service.

Figure 19: Security Service Overview

3.5 User Management

3.5.1 User Profile Management

Once defined, each portal user can edit the own profile and customize the personal look and feel within the limits set by the page and portlet providers. Figure 20 shows an example for the “edit my profile” option.




Figure 20: User Management via the EPIC Portal

3.5.2 User and Group Management

WebSphere Portal Server provides the administrators to create new groups and users and assign them to each other. It includes an intuitive interface to manage group membership and allows for delegated administration, thus enabling each service provider to manage their respective community and permissions set. Figure 21 is a sample screenshot.

Figure 21: Portal-‐Based User and Group Management





For reporting purposes extracts about the number of users and their permissions by group and category can be produced.



4 Smart Relocation Service hosted on the Platform In EPIC, we have chosen a relocation scenario to demonstrate the platforms capability to increase the mobility of European citizens. The scenario highlights relevant advantages:

• providing smart e-‐government which means streamlining the often tiresome practical government-‐related duties in relation with relocation

• overcoming language barriers

• making implicit knowledge visible

• offering an augmented layer of government and non-‐government data concerning cities, including general information newcomers in a city need to know or strongly benefit from knowing (smart city guide)

• smart housing which means making finding a temporal or a more permanent place to stay much less cumbersome.

Obviously, the listed advantages hold for situations other than relocating as well. For example, the solutions that we will develop and present for streamlining government-‐related duties in relation to relocation can easily be generalized to streamlining other government-‐related duties from renewing a passport to the registration of an enterprise. Thus, the scenario will not only highlight the advantages of the relocation service application, in particular, but will also underline the strength of the EPIC platform more generally. In this chapter, we showcase the inherent capabilities of the platform to support the citizen during the three principle phases of the process:

• plan for relocation

• discover housing options according to personal preferences (KPI)

• execute the decision. The first phase is about data gathering and information presentation in a filtered and contextual format. This smart information service is offered by the city to attract new – tax-‐paying – residents, service providers and enterprises to come to the city. Figure 22 is an example of how the informational dashboard of Brussels could look like. The dashboard could provide an inter-‐disciplinary portal to the different flavours of city life and work. In addition, geo-‐referenced points-‐of-‐interest (POI) and events can be shown on-‐top of a map, complimented with live video feeds (in this example from the soccer stadium). Top news, contacts and tourist information can complete the picture and present information in a filtered and contextual format.



Figure 22: Phase 1: Planning for Relocation

The services presented in Figure 23 relate to the discovery phase in the relocation process. The interested resident has registered with a realtor services and is now exploring a neighbourhood in Brussels to find a house fulfilling his personal preferences. This particular relocation services provided via the platform shows the set of available properties in the suburb on-‐top of the map and enables the drill-‐down for more information by clicking on the objects. In addition, further personalized information about e.g. the level of preference matching or the timeliness of availability of the properties is displayed. Real-‐time information is fed into the dashboard to allow an optimized exploration route. Events that might have an impact are shown for information and planning purposes. Online feedback or incident reporting is enabled through links and contact information.

Brussels

TaxSocial SecurityEntrepeneurEconomy-Centricity

SportsCultureFamilyCitizen-Centricity

HospitalsAmbulant CareWell-beingHealthcare

HousesFlatsSocial HousingProperties

TertiarySecondaryPrimaryEducation

Train SystemBus / MetroPrivate carsTransportation

TaxSocial SecurityEntrepeneurEconomy-Centricity

SportsCultureFamilyCitizen-Centricity

HospitalsAmbulant CareWell-beingHealthcare

HousesFlatsSocial HousingProperties

TertiarySecondaryPrimaryEducation

Train SystemBus / MetroPrivate carsTransportation

SoccerChampionship

Key Events Stadium Weather



Figure 23: Phase 2: Discover Properties

Finally, Figure 24 addresses the time after decision making – the relocation has to be executed through different tasks.

Figure 24: Phase 3: Decision (Citizen’s Collaboration with Realtor & Public Authorities)

Brussels

Profile Match

Availability

PerfectHighMediumLow

ImmediateDaysWeeksMonths

Notifications

Traffic Jam RO West 5 km use A201 insteadTrain Breakdown at Metro A11 Shuttle Busses in operation

Contacts and Information

Citizen BureauTourist InformationPublic TransportService ProvidersHousing and Properties

Events and Incidents

Open House at Kennedy-Laan 11 Today 10:00 – 14:00Open House at Kaanalstraat 24 Today 09:00 – 12:00Information Day of International Business School May 12 09:00 – 17:00Fotographer Workshop at Haaren City Hall May 18 13:00 – 18:00….….

Property Heat Map

Contacts and Information

Citizen BureauTourist InformationPublic TransportService ProvidersHousing and Properties

Brussels

CriticalHigh PrioMedium PrioLow PrioNice to have

Task Importance

Task Completion

DoneDecision PendingSubmittedPerparedNot started

Moving into Rue de Verdun

My Assignments

- Contact Insurance for Policy Copy- Call Principle at University- Send Application to Soccer Club- Cancel Membership of Church Choir- …

Close House ContractRegister at City HallProfessional Licensing as FotographerEnroll Children at Schools….….

Notifications

Road Construction on M40 expect 30min delaysStrike at Airport contact your airline for cancellations

Tasks in Relocation



In this example, the family has decided to buy and move into a house in the “Rue de Verdun”. This POI now links to the personalized task list depicted on the service portal. Each task relates to a predefined collaboration workflow involving different city and private organizations, business objects and documents. The “My Assignment” frame points to “personal to-‐do’s” supported by a planning calendar and allows for step-‐by-‐step visualization of workflow and status tracking. Contacts and further information can be accessed and engaged through various online collaboration means, thus providing a near real-‐time environment for context-‐based identification and coordination of actions and responses in the various relocation tasks.



5 Customization of the Platform This chapter describes the basic tasks for a freshly on-‐boarded service provider (e.g. city department) to customize the platform for usage within his specific mandate. The Platform presents itself with a standard frontend scheme as shown exemplary in Figure 25.

Figure 25: Default Frontend scheme



Figure 26: Default UI Design

First steps of customization include the branding for a specific application or city function by changing the look and feel of the portal page e.g. colours, text, logo. Then the tasks include creation of new portal pages for user communities, the addition and configuration of portlets, assignment to user groups and implementation of page and data level security. In this whitepaper, we describe these tasks using well-‐proven examples not from smart city services, within EPIC the intent-‐driven process of cross-‐border relocation of a family in Europe, but from the mature domain of emergency response.

5.1 Personalization The portal administrator can use the “theme customizer” tool to perform a number of tasks:

• Create and configure a new style.

• Design the page: customize text colour, page background such as image or colour, breadcrumb navigation, page content etc.

• Design the banner: update the banner style information and customize the site title that appears on the browser, banner logo image, banner menu text, background, border etc.

• Design the navigation: update the navigation style information and customize the page navigator layout, background colour, text, border etc.

• Design the portlet area: update the portlet area style information and customize the portlet header and area text, background, borders etc.



• Design the footer: update the footer style information and customize the footer background, text, border, links etc.

Such a newly configure style can be applied in the administration settings tab of the portal. Under portal user interface, the option “manage pages” is selected and the new style is entered into the platform’s page properties. Figure 27 shows an example for basic customization.

Figure 27: Theme Customization

5.2 Definition of new Platform Page Within the administration settings, the “manage pages” tab supports the definition of new pages within the platform’s page hierarchy tree starting with “root”. The new page’s details are entered within properties and the theme is inherited from the parent. The new page is then displayed as a new tab in the portal as depicted in Figure 28.



Figure 28: New Portal Page

After defining the new page, configuration tasks include:

• Page’s functionality o Installing portlets to portal (see 5.3) o Adding portlets to the page o Configure the portlets

• Security Settings (done within the “users and groups” tab within access management)

o Creating new groups o Assigning groups to pages o Creating new users o Assigning users to groups.

5.3 Define Application Portlets New portlets can be installed on the portal using the “web modules” tab within the portlet management section of portal administration. The installation completes after the selection of a WAR file to be uploaded. Figure 29 is an example screenshot illustrating how a pre-‐installed map portlet can be added to the page:

1. Navigate to the page 2. Select “Edit Page Layout” from page dropdown



3. Click “Add Portlets” 4. Select Portlet 5. Click “OK” 6. Click “Done”

Figure 29: New Map Portlet

Portlet configuration can take place on three different levels:

• Personalized: o Change settings only for the single user o Can be done by any privileged user of the system

• Shared settings: o Change default settings for all users o Needs at least editor permissions

• Configuration: o Change default setting for all occurrences o Needs at least manager role permissions.

2

4

5



5.4 Portlet Configuration Portlets can be duplicated and provisioned with different provisioned properties to allow for flexible re-‐use. One example for sensible doing this is providing natural language support within the help portlets of the platform. Portlets can also be configured regarding the appearance of their output. For example, the events portlet displays the CAP events stored in the database. Without customization, it appears like shown in Figure 30.

Figure 30: Default Event Portlet Appearance

Figure 31 shows one way of custom fitting of the event portlet. It includes not only the hiding of toolbar, tabs and add event button, but also the exclusion of entire columns in the presentation layer. Furthermore, the portlet title, column order and date format have been changed. Finally, filters regarding the event severity have been set to show only the events of moderate, severe or extreme classification. All of this can be configured without changing the core functionality of the portlet itself.



Figure 31: Customized Event Portlet

Similar changes can be applied to the platform inherent alerts portlet that displays notifications saved in the database about event correlation and KPI value change.

5.5 MAP Extensions In the out-‐of-‐the-‐box configuration, the basic map is integrated with the events list and provides the described UI filter capabilities. By simple reconfiguration of the MAP portlet the geography can be changed and zoom levels can be customized to specific user and application needs. In the presence of a GIS server, additional geo-‐information from the server side can be integrated into the presentation layer to enrich the presented information in the portal. This involves only very little client side processing, different to the case of including external Keyhole Markup Language (KML, [5]) layers managing 3D geo-‐spatial data in the portal presentation.

5.6 Customization of Event Processing This task is about information handling for the case that a new sensor is been integrated into the system e.g. a smart meter in a property that sends data at regular intervals. The instrumented layer as shown in Figure 2 is made up of sensors, actuators, programmable logic controllers (PLCs), and distributed intelligent sensors. This technology is based around control engineering and has a large amount of physical infrastructure. Currently, communication between the controller and the sensor and actuators is achieved by using field buses and other interfaces. The technology has evolved to allow for wireless connection to the sensors and actuators from the controller. Wireless communication means that sensors and actuators can be placed in an environment without the need of physical wiring. Data that is captured from these sensors is numeric and is used in a logical manner. Sensor data is becoming more sophisticated with video and digital signal processing.



Instrumented layers can be designed for a specific purpose such as controlling the environment of a building or performing their predefined task through a logical sequence. The ability to source reliable and accurate data is the key to building effective business intelligence (BI) and business analytics (BA)-‐based systems. Because of the complexity of this layer, consult further resources in the field of industrial control systems for more information. This layer includes the following key capabilities:

• Data capture and control o Integrate a wide range of sensors and devices o Provide the ability to collect and move data o Execute local commands to take action o Run distributed operational logic

• Manage distributed device infrastructure o Provides the ability to manage devices and sensors o Offers remote configuration and management of devices o Provides the ability to monitor and provide security of these devices and

their data The instrumented layer in the EPIC platform is exploited by the generic sensor monitoring and control framework developed in context of the smart energy pilot. The format of the data needs to be transformed into something the platform can consume to track KPI monitoring energy consumption. Message Broker is used to transform the messages into CAP events that can easily be consumed. In addition, new impact policies need to be implemented for example to alert people via email if necessary. Figure 32 shows the new message flow for the new sensor: A new input queue and transformation schema are defined.



Figure 32: Message Flow Definition

A new policy is then set to send an email to an operator once the sender value is above threshold. The “send email” service is being configured within the impact server of the platform.

5.7 KPI Definitions The Model Manager Server is part of the IBM Integrated Information Core and provides a standard-‐based repository for ontology data and relationships with both EJB and web service interfaces. Within the platform, it is used to store the KPI hierarchical tree including the KPI identifiers and the child-‐parent relationships. It is preloaded with sample KPI which can be used for customization. It is accessible both via a command line interface and through the portal. The KPI ontology model defines data and relationships for the KPI model definition; Figure 33 shows the preconfigured classes.

Figure 33: KPI Ontology Model

Customization is done following 4 steps: Step1: Use a text editor to edit the KPI.rdf file to include the new “Energy Service” KPI, Figure 34)

IOC_Energy.IN Q



Step2: clear the old .rdf file from Model Manager Step3: Load the new .rdf to the Model Manager Step4: Restart Portal Server.

Figure 34: New Energy Consumption KPI

Even this trivial example illustrates the parent-‐client KPI relationships between the single meters (sensors) and the overall consumption level within the energy service. KPI are typically retrieval at system start-‐up time, at configurable intervals and when the KPI subsystem determines a value change. The KPI engine is provided by WebSphere Business Monitor; applications containing KPI definitions also are installed on this server. KPI values are calculated from metrics obtained or derived from CAP messages.

Energy Service

Consumption



6 Platform Extensions The platform described so far focuses mainly on the near real-‐time information gathering and complex event processing to achieve and maintain situational awareness through semantic interoperability in a specific domain while complying with the security and privacy mandates. Out of the box easy measures and actions can be triggered e.g. collaborations started, workflows initiated, emails sent. For the EPIC pilots, this functionality is sufficient to host all three pilot applications. To really implement the envisioned interoperability within a Pan-‐European e-‐Government Service (PEGS) “Relocation”, more core enterprise management services are needed; they are briefly described in the following paragraphs.

6.1 Federated Enterprise Service Bus Smart cities and smart city networks are looking increasingly to service oriented architecture (SOA) for better align business processes and IT systems, to improve agility; maximise reuse of SOA assets and reduce maintenance costs. An enterprise service bus (ESB) and a service registry, as shown in Figure 35, are essential components in any successful SOA, to connect to the right information at the right time and to reuse existing SOA assets.

Figure 35: Service Visibility

6.2 Business Process and Case Management A city is a smarter place than it was ten years ago, with systems and processes that are more intelligent, instrumented and interconnected than ever before. The convergence of physical and digital infrastructures is changing what is possible in the worlds of work and leisure, allowing global collaboration; prediction of events and control of complex systems. The fast interconnected nature of the digital world is changing the way we live and do business in the physical world, presenting a myriad of opportunities with their attendant challenges.



Business networks are changing as relationships become more dynamic between citizens, administrations, service providers, consumers, partners and suppliers—all of whom are constantly shifting and being re-‐evaluated. The same technologies that are creating a smarter planet are driving the need for a more dynamic business network. Citizens and enterprises demand lightning-‐fast responsiveness and increasing levels of personalization of service. Regulations and compliance demands shape and reshape the way business is conducted. More agile, interconnected business processes are required to enable organizations to establish dynamic business networks and fully take advantage of a smarter planet. Business processes must be explicit, documented, understood and agreed upon. They must also be visible, making process performance data available, measurable and actionable in real-‐time. Increased personalization of service delivery needs agility combined with process information contextualized by role and current usage paradigm of each stakeholder, with robust governance to ensure compliance with business rules and regulatory requirements relevant to the stakeholder’s location. Rule-‐based case management tools address that challenge as shown in Figure 36.

Figure 36: Case Management Building Blocks

6.3 Business Analytics and Intelligence When asked about what factors will significantly affect their organizations, once again strong public sector themes emerge. The IBM 2010 Global CEO Study ([6]) shows them to be:

• Information explosion affects public sector organizations to a much greater extent than the private sector.

• Talent shortages are similar to the people issues discussed in private sector – the public sector tends to suffer more from an ageing population, has difficulty attracting and retaining the skilled staff they will increasingly need.

Integration

WorkflowContent

Rules

Collaboration & Social

EventsMonitoring

Analytics

Case Management



• Shorter cycle times are a result of the growth in capability to deliver information quickly (in near real time) and so make decisions quicker – leading to rising expectations from citizens.

• In many countries there have been significant shifts in the boundaries between the public and the private sector. Largely in response to demands for greater public sector efficiency, governments are reassessing whether activities are part of their core competencies or could more efficiently be delivered by a specialist external partner, thereby lowering cost, reducing risk and potentially increase flexibility. There is a questioning of what roles government and other public sector organizations have been playing and what roles they should be playing moving forward. Increasingly government and other public sector organizations are concluding that it is to deliver the best public outcomes to citizens the most efficiently, regardless of whether the public sector carries out all aspects of the delivery. The ever present challenge is what and how public outcomes are defined, measured and how organizational – given the roles they play relative to those outcomes – results (measures of performance) meaningfully contribute to (indicators of progress) those public outcomes.

The information explosion, combined with other information trends particular to the public sector – particularly government – also presents very different dynamics than that of the private sector … and significant challenges when it comes to getting the most out of the massive data stores that these organizations collect, store, manage:

• Uses and users, diversity and scale: The variety and volume of uses and users of public sector information is skyrocketing. There is growing recognition of the prominent role and potential of PSI in driving all sorts of public – and commercial – outcomes, even as tensions between access v. use, visibility and transparency v. security and privacy remain and often heighten (see table above).

• “Open”: In several countries there have been recent moves to make more information available to the public and to increase transparency of government through making information available online. A recent study showed that 68 % of private sector organizations were unwilling to share data with their customers but 83% believe they should be entitled to greater access to government data (in survey of 1000 UK businesses, Informatic corp, reported in the guardian http://www.guardian.co.uk/technology/2010/jun/29/business-‐data-‐sharing-‐unwilling). It is important also to think of the possibilities of combining “internal” and “external” data. More open initiatives are underway – the next wave in transparency, accountability and, when combined with external data, citizen engagements. One example it the Digital Agenda for Europe (DAE).

• Citizen-‐centricity: At the same time, public sector organizations, due to the nature of their work, must interact with citizens and other constituents in a more open and to a broader extent. Leading practices on knowing and understand customers and their behavior, collaboration and information, speed all touch PSI remain important. Though this may sound obvious, many are a long way off.



Figure 37: Power of Analytics in Public Sector

Figure 37 shows the capability areas of advanced analytics discipline, methods and tooling.

AnalyticsTalent

AnalyticsCapability

AnalyticsLeadership

AnalyticsTalent

AnalyticsCapability

AnalyticsLeadership



7 Conclusions In this document, we have described a technical smart city governance and management platform enabling the EPIC pilots and underpinning the EPIC roadmap for platform adaptation in a city striving to become smart. We have further briefly elaborated on the different platform extensions that support the comprehensive implementation of the Digital Agenda Europe and the European e-‐Government Strategy 2020. As the platform and the extension support the European Interoperability Strategy and implement the EIF, the platform cannot not only be of value in any smart city transformation, but also underpin the sustainability of all the European Large Scale Actions.



8 Abbreviations ACL Access Control List API Application Programming Interface B2B Business – to – Business BI Business Intelligence CAP Common Alerting Protocol CEI CRUD Creation, Retrieval, Update, Destruction/Deletion CURI Common UI REST Interface DAE Digital Agenda Europe EDXL Emergency Data Exchange Language EIF European Interoperability Framework EIS European Interoperability Strategy ERP Enterprise Resource Planning ESB Enterprise Service Bus GIS Geographical Information Systeme GML Geography Markup Language GUI Graphical User Interface IOC Intelligent Operations Center KML Keyhole Markup Language KPI Key Performance Indicators LDAP Lightweight Directory Access Protocol LPTA Lightweight Third Party Authentication MDB Message Driven Bean MM Model Manager MQ Message Queuing NCOMS NetCool Common Object Management Server OASIS Organization for the Advancement of Structured Information Standards OGC Open Geospatial Consortium OpenLS OpenGIS Location Services PEGS Pan-‐European e-‐Government Services POI Point of Interest REST Representational State Transfer SAPM Service Availability and Performance Management SCADA Supervisory Control and Data Acquisition SOA Service Oriented Architecture SSO Single Sign-‐On TAM Tivoli Access Manager TCP Transmission Control Protocol TCT Tivoli Common Topology TFIM Tivoli Federated Identity Manager TIM Tivoli Identity Manager



TIP Transaction Internet Protocol TSRM Tivoli Service Request Manager UI User Interface WAS WebSphere Application Server WBI WebSphere Business Integration WBM WebSphere Business Monitor XML eXtensible Markup Language

Table 1: Abbreviations



9 References [1] Kehoe, Mike et al.: Smarter Cities Series: A Foundation for Understanding IBM Smarter

Cities, IBM Redbook, March 2011 [2] www.oasis-open.org/committees/tc_home.php?wg-abbrev=emergency#technical, last xxxx

access: September 2011 [3] http://www.opengeospatial.org/, last access: September 2011 [4] http://dojotoolkit.org/, last access: September 2011 [5] http://www.gdal.org/ogr/drv_kml.html, last access: September 2011 [6] IBM CEO Study, 2010 [7] Menychtas A., Kranas P., Donovang-Kuhlisch M. et al; (October 2011). D2.3 Online

Service Delivery Baseline and Technical Requirements Report. European Platform for Intelligent Cities. No: 270895.

[8] Ruston S., Glidden J., Menychtas M. and Kranas P.; (October 2011). D2.1 Project Vision. European Platform for Intelligent Cities. No: 270895.

[9] Donovang-Kuhlisch M. et al; (October 2011). D3.1 Technical Integration Architecture Plan. European Platform for Intelligent Cities. No: 270895.

D3.2 Smart City Info Architecture - epic-cities.eu Smart City... · DELIVERABLE)) Project Acronym:...

Documents

Transcript of D3.2 Smart City Info Architecture - epic-cities.eu Smart City... · DELIVERABLE)) Project Acronym:...