One city is not a market. The vision of the Open & Agile Smart Cities (OASC) initiative is to create an open smart city market based on the needs of cities and communities. Cities need interoperability and standards to boost competitiveness by avoiding vendor lock-in, comparability to benchmark performance, and easy sharing of best practices. They also need solutions that can be implemented with respect for local practices and job creation. The OASC initiative achieve this vision by advocating cities to adopt four simple mechanisms as de facto standards. The first mechanism is a driven-by-implementation attitude. The other three mechanisms are technical (an API, a set of data models, and an open data platform, described in the Background Document). Since it was launched in March 2015, more and more cities have joined the initiative. More info at: http://connectedsmartcities.eu/open-and-agile-smart-cities/

1. http://www.fiware.org
http://connectedsmartcities.eu/open-and-agile-smart-cities/
Follow @FIWARE on Twitter!
The OASC (Open and Agile Smart Cities) initiative:
from vision to execution
Juanjo Hierro
OASC TF Board member. FIWARE Coordinator and Chief Architect
juanjose.hierro@telefonica.com, @JuanjoHierro (twitter)

2. Open and Agile Smart Cities
(OASC) initiative
1

3. We cannot remain blocked in the chicken & egg
dilema
2
Cities &
Communities
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
3
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)
4

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
5

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
6

8. It’s time to execute!
7
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
Showcase 1
Showcase 1
Showcase m
Transference to Market
FIWARE Accelerator
Programme
Other Prototypes or
ServiceReady solutions

9. Zoom into OASC principles
8

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
9
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
10
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
11
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
12
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
13
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
14
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
15
Bus = “X”, location = (x, y)
updateContext
Context Broker
Context Producer
Context Consumer
queryContext

17. 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
16
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
)

18. 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
17
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
18
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
19
FIWARE NGSI API
Advanced Web-based UI (AR,
3D)
Data/Apps visualization
Big Data AnalysisComplex Event
Processing
Multimedia processing

21. Open Data publication
20
Context
Broker
NGSI
Context
Source
s
Traditional “static”
historic data

22. NGSI resources in CKAN
21

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?
22

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!
23

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
24

26. 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!
25