the open and agile smart cities (oasc) initiative: from vision to execution
TRANSCRIPT
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 [email protected], @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