http://www.fiware.orghttp://connectedsmartcities.eu/open-and-agile-smart-cities/Follow @FIWARE on Twitter!

The OASC (Open and Agile Smart Cities) initiative: from vision to executionJuanjo HierroOASC TF Board member. FIWARE Coordinator and Chief Architectjuanjose.hierro@telefonica.com, @JuanjoHierro (twitter)

2

Open and Agile Smart Cities (OASC) initiative

3

We cannot remain blocked in the chicken & egg dilema

Cities & Communitie

s

Developers &

integrators

De facto standards (platform)

4

The Open and Agile Smart Cities (OASC) initiative

Common APIs FIWARE NGSI to start with Standard Data Models CitySDK and more Platform for Open Data/API publication Driven by implementation approach

More info:http://connectedsmartcities.eu/open-and-agile-smart-cities/

5

Open and Agile Smart Cities (OASC) initiative

31 cities from 7 countries launched the OASC initiative

Other countries and cities joining since then. Currently:• Denmark: Copenhagen, Aarhus, Aalborg, Vejle

• Finland: Helsinki, Espoo, Tampere, Vantaa, Oulu, Turku

• Spain: Valencia, Santander, Sevilla, Málaga, Sabadell

• Portugal: Lisbon, Porto, Fundão, Palmela, Penela and Águeda

• Belgium: Brussels, Ghent, Antwerp

• Italy: Milan, Palermo, Lecce, Ancona

• Brazil: Olinda (Recife), Anapólis (Goiás), Porto Alegre (Rio Grande do Sul), Vitória (Espírito Santo), Colinas de Tocantins (Tocantins) and Taquaritinga (São Paulo), Rio das Ostras (Rio de Janeiro)

• Netherlands: Amsterdam, Rotterdam, Utrecht, Eindhoven, Amersfoort, Enschede

• Ireland: Dublin, Galway, Cork

Over 50 cities already lined up for 2nd wave (Mindtrek Openmind 2015, Tampere) 100 cities by November 2015 (SCWC in Barcelona)

6

Open & Agile Smart Cities initiative principles

API: Adoption of a lightweight, open-licene standard API to gather, publish, query and subscribe-to in-time context information describing the state of the city. Specifically, the FIWARE NGSI API will serve as a first common API which the supporters will implement.

Data model: Adoption of a simple initial standard data model required for effective interoperability when exchanging context information. Specifically, CitySDK, which is available through the FIWARE NGSI API, functions as a basis

Open Data Platform: Adoption of a flexible, easily-distributable open data publication platform which any organisation can set up at a low cost if it is not already being used. Specifically, CKAN will serve as the initial standard platform for publication of datasets or NGSI API resources. CKAN is already integrated and extended as part of the FIWARE Reference Architecture

7

Open & Agile Smart Cities initiative principles

Approach: Adoption of a “driven by implementation” approach towards experimental consolidation of initial standard data models as well as specification of new standard data models. The goal is that communities and developers can (1) co-create their services based on basic but commonly-defined data models, (2) influence the definition of new models by implementing and experimenting, and (3) help “curate” existing data models. Specifically, this will mean engaging organisations and communities, leveraging relevant initiatives, e.g. startups/SMEs selected through the FIWARE Accelerator Programme (projects focused on Smart Cities), the OrganiCity Experimentation-as-a-Service facility and open calls, Code for Europe and/or other relevant programmes, including national networks, that may help to engage wider communities of stakeholders and developers. It will also mean leveraging the FIWARE Lab, OrganiCity facility etc. as joint, major hubs for experimentation with the proposed APIs, data models and platforms

8

It’s time to execute!

OASC cities

App 1

App 3

App i

City 1

City 2

City 3

City k

City n

City 1

City k

City 2

City 3

City n

App 3

App 2 App i

App r

App 1

Showcase 1

Showcase 1

Showcase m

Transference to Market

FIWARE Accelerator Programme

Other Prototypes or ServiceReady solutions

9

Zoom into OASC principles

10

Being “Smart” requires first being “Aware”

Implementing a Smart Application requires gathering and managing context information

Context information refers to the values of attributes characterizing entities relevant to the application

Bus• Location• No. passengers• Driver• Licence plate

Citizen• Name-Surname• Birthday• Preferences• Location• ToDo list

Shop• Location• Business name• Franchise• offerings

Context Information

Application

11

Different sources of context need to be handle

Context information may come from many sources:• Existing systems

• Users, through mobile apps

• Sensor networks (Internet of Things)

Source of info for a given entity.attribute may vary over time

Place = “X”, temperature = 30º

What’s the current temperature in place

“X”? Standard API

A sensor in a pedestrian street

The Public Bus Transport

Management systemA person from his

smartphone

It’s too hot!

Notify me the changes of temperature in place

“X”

12

A non-intrusive approach is required

Capable to integrate with existing or future systems dealing with management of municipal services without impact in their architectures

Info about attributes of one entity may come from different systems, which work either as Context Producers or Context Providers

Applications rely on a single model adapting to systems of each city

Application/Service

Standard API

System A System B

attribute “location” attribute “driver”

Context Producer Context Provider

13

Connecting to the Internet of Things

Capturing data from, or Acting upon, IoT devices should be as easy as to read/change the value of attributes linked to context entities

Context Broker

Standard APIStandard API

GET <Oauth token>/V1/contextEntities/lamp1/attributes/presenceSensor

PUT <Oauth token>/V1/contextEntities/lamp1/attributes/status“light on”

Setting up the value of attribute “status” to “light on” triggers execution of a function in the IoT device that switches the lamp on

Issuing a get operation on the “presenceSensor” attribute enables the application to get info about presence of people near the lamp

14

Integration with sensor networks

The FIWARE backend IoT Device Management GE enables creation and configuration of NGSI IoT Agents that connect to sensor networks

Each NGSI IoT Agent can behave as Context Consumers or Context Providers, or both

FIWARE Context Broker

IoT Agent-1

IoT Agent-2

IoT Agent-n

IoT Agent

Manager

create/monitor

FIWARE Backend IoT

Device Management

OMA NGSI API (northbound interface)

(southbound interfaces)

MQTTETSI M2M

IETF CoAP

15

Context Management in FIWARE

The FIWARE Context Broker GE implements the OMA NGSI-9/10 API: a simple yet powerful standard API for managing Context information complying with the requirements of a smart city (OASC 1st principle)

The FIWARE NGSI API is Restful: any web/backend programmer gets quickly used to it

Bus• Location• No. passengers• Driver• Licence plate

Citizen• Name-Surname• Birthday• Preferences• Location• ToDo list

Shop• Location• Business name• Franchise• offerings

Context Information

Application

Standard API

16

FIWARE NGSI: Basic interaction

Context Producers publish context information by invoking the updateContext operation on a Context Broker.

Context Consumers can retrieve context information by invoking the queryContext operation on a Context Broker

Bus = “X”, location = (x, y)updateContext

Context Broker

Context Producer

Context Consumer

queryContext

FIWARE NGSI: Subscription to notifications

Context Consumers can be subscribed to reception of context information complying with certain conditions, using the subscribeContext operation a ContextBroker exports. Such subscriptions may have a duration.

The Context Broker notifies updates on context information to subscribed Context Consumers by invoking the notifyContext operation they export

17

Bus = “X”, next_stop = “A”, arrived = “Yes”

updateContext (context_info)

Context Broker

Context Producer

Context Consumer(consumer1)

notifyContext (id, context_info)

Id = subscribeContext (consumer1, condition, duration)

FIWARE NGSI: Context Providers

Context Providers can be registered to the Context Broker as “holders” of certain context information.

A Context Broker will invoke the queryContext or updateContext operations exported by Context Providers whenever they are queried for, or asked to update, context information they hold

18

Bus = “X”, location = (x, y)queryContext / updateContext

Context Broker

Context Provider(provider-x)

Context Consumer

queryContext / updateContext

registerContext (provider-x, registration_data, duration, id))

19

Integration with existing systems

Context adapters will be developed to interface with existing systems (e.g., municipal services management systems in a smart city) acting as Context Providers, Context Producers, or both

Some attributes from a given entity may be linked to a Context Provider while other attributes may be linked to Context Producers

queryContext (e1, attr1, attr2)

Context Provider

queryContext (e1, attr1)

Context Consumer

updateContext (e1, attr2)

Application

Context Broker

System B (e.g.

Transport system)

System A (e.g. GIS, POIs)

20

Open data publication

Once context information is gathered, a lot of useful complementary tools/enablers can be used

FIWARE NGSI API

Advanced Web-based UI (AR, 3D)

Data/Apps visualization

Big Data AnalysisComplex Event Processing

Multimedia processing

21

Open Data publication

Context Broker

NGSI

Context

Sources

Traditional “static” historic data

22

NGSI resources in CKAN

23

How can standard Smart City data models easing common solutions be defined? The problem

Smart City apps can be ported from one Smart City to another once their platforms provide the same set of APIs, that’s why FIWARE brings a rather high value

Without standard data models, Smart City apps would need to come with adapters that transform data made available by the city so that it complies with the data model handled by the app but that has proven to be easy with FIWARE NGSI (overall if NGSI is at both ends)

Creation of standard Smart City data models would allow to avoid performing this kind of adaptation and make portability of Smart City apps across Smart City platforms a pretty straightforward task

How creation of these standard Smart City data models can be fostered?

24

How can standard Smart City data models easing common solutions be defined? The solution

A “design by committee” approach would not be the best approach:• Such kind of approach has proven to be wrong in many

other standardization efforts in the past

• Who grants that the defined model is suitable for what apps need and developers want to have?

We need a “driven by implementation” approach:• Identify real applications that solve a real problem and cities

would like to see running in their cities

• Check what data models they have been designed to work with and take them as input

• Carry out a “data curation” process where input data models converge into a single common model

You will end with a set of standard data models and soon a portfolio of killer Smart City apps working!

25

How can standard Smart City data models easing common solutions be defined?

Leverage on existing work: CitySDK

Leverage on initiatives like the FIWARE Accelerator programme to identify killer Smart City apps• These applications can serve as basis for definition of new

Smart City data models

• Involvement in this process becomes also an incentive for the entrepreneurs to join identified initiatives (“I want to influence the standard so that my app can easily align with it”, “I want to provide one of the first example applications”)

• There are 80 M€ for entrepreneurs in the FIWARE Accelerator programme that can be put at work!

Cities would play a key role:• Their data models will be contrasted/analyzed against those

coming from the apps and other cities

• They would get involved in the data curation process

http://fiware.org

http://connectedsmartcities.eu/open-and-agile-smart-cities/

Follow @Fiware on Twitter !

Check latest videos at www.youtube.com/user/FIWARE

Thanks!

26