Skip to main content
European Commission logo
Smart Cities Marketplace
Scalable cities

Inspiration

Changing roles of stakeholders during implementation

In the networks where stakeholders in smart city projects are engaged, these stakeholders play specific roles. However, it appears that once the local ecosystem has been formed, it is often quite dynamic, not only by the entrance of newcomers, but also in terms of changing roles. A study by Nijman (2014) analysed envisaged and observed roles of actors during the implementation of the Smart Citizen Kit project, which enabled citizens to measure local air quality in Amsterdam. She concluded that distinctions between design and use of smart solutions and the roles of government and citizen had become blurred. New roles emerged, such as citizens as data producer and co-designer or even co-creator of solutions. But roles changed as well: participating citizens who tested, gave feedback, shared information about their behaviour and had little knowledge on the topic before, became data interpreters, knowledge contributors, helpdesk and guides of the process. The project team became testers as well, helped to smoothen technology and to redevelop the Smart Citizen Kit. 

Development of indicators

(Brita Fladvad Nielsen, NTNU, Institute of Architecture and Planning) 

It is recommended to use KPIs relevant for each of these categories and subcategories in order to feed benchmarking database in a consistent manner and help in replication/scaling-up.

An indicator should be developed through a logical process. A good way to decide which indicator in each case is relevant and useful, is to use the MADM method. Multiple attribute decision making (MADM) methods described in (Yoon and Hwang, 1995). MADM problems are diverse, but share some common attributes (Yoon and Hwang, 1995):

  • Alternatives: Each problem consists of a finite number of alternatives that are screened, prioritized, selected and/or ranked.
  • Multiple attributes: Each alternative is characterised by a set of attributes. The decision maker (DM) must generate the relevant attributes.
  • Incommensurable Units: Each attribute has different units of measure (if any).
  • Attribute Weight: Almost all MADM methods require information regarding the relative importance of each attribute.
  • Decision Matrix: A MADM problem can be concisely expressed in a matrix format, where columns indicate attributes and rows list competing alternatives.

The MADM process can be split into three steps:

  1. Generating attributes and defining the data: To establish a foundation for the decision making, the relevant attributes needs to be identified. The term "attributes" can be referred to as "goals" or "criteria". The set of attributes should represent all the important parameters relevant for the decision. Preferably, the attributes should be broken down to "sub-attributes" until they reach a measurable level. For most MADM methods, it is also necessary to rank or weigh the attributes, as they seldom are considered equally important. 
  2. Attribute rating: All the alternatives must be rated against all attributes. For quantitative attributes, this could be a relatively simple process. For qualitative attributes, this is more complex and requires a more subjective assessment. Many MADM methods require quantitative data for the attribute evaluation, and the qualitative evaluation then has to be quantified.
  3. Applying the MADM methods: The MADM methods are classified based on the available information. In some MADM problems, it is reasonable to apply more than one method, e.g. apply one method to eliminate the alternatives with unacceptable performance at important attributes, and then rank the rest using a secondary method.

FI-WARE Platform for smart cities

(José Javier Astrain, Institute of Smart Cities (ISC) Public University of Navarre)

Its developers describe FIWARE as “a curated framework of open source platform components which can be assembled together with other third-party platform components to accelerate the development of Smart Solutions” (FIWARE, 2019b). FIWARE aims to be a standard an open platform for smart cities.

The FI-WARE Project (May 2011-December 2014) was funded (~41M€) by the European Union under the programme FP7-ICT. The project consortium (Telefónica, Orange, Engineering and Atos) was led by Telefónica. FIWARE currently has its own foundation, in charge of providing shared resources to help to achieve the FIWARE mission by promoting, augmenting, protecting, and validating the FIWARE technologies as well as the activities of the FIWARE community. Nowadays the community of FIWARE includes more than 1,000 startups, 11 innovation hubs, 2 acceleration programmes and more than 100 cities (FIWARE, 2019c).

ORION context broker generic enabler

The main and mandatory component of a FIWARE platform is Orion. Orion Context Broker Generic Enabler manages the context information and brings access to context. Orion allows interacting with IoT (IoT) devices, robots and third-party systems, for capturing updates on context information and translating required actuations (see figure below). 

Figure 4-8 ORION context broker generic enabler. Source: FIWARE

Generic Enablers (GEs)

GEs are components that offer, through APIs, a great number of general-purpose functions, easing the development of smart applications in multiple sectors and also the interconnection with other GEs.

FIWARE assembles a set of building blocks (GEs) in order to provide reusable and common shared functionalities to ease the creation of smart applications. Generic enablers concern data/context management, security, IoT, application/services and data delivery, cloud computing, interfaces to network and devices and advanced web-based user interfaces. Figure 4-7 depicts some of the available GEs.

Figure 4-9 FIWARE catalogue. Source: FIWARE, https://catalogue-server.fiware.org/enablers.

 

 

FIWARE, by means of GEs, allows the quick implementation of smart solutions by just interconnecting GEs. Results are easily replicable and scalable, and FIWARE allows the development of powerful Apps and data fed in real-time.

Figure 4-8 shows a case study of FIWARE, where we can appreciate the interaction among applications, FIWARE NGSI-10 and the backend. An interesting overview can be found in Salhofer (2018).

 

Figure 4-10 FIWARE case study (Source: FIWARE)

 

Docker images

FIWARE community provides Docker images for every component (FIWARE, 2019e). Docker is a container technology, which allows to different components isolated into their respective environments.