Challenge & Context
One of the biggest challenges in Smart Cities projects is bringing, in one single place, relevant context, which is gathered and managed by different actors and in many different ways. Too often, such data is compiled in a non-interoperable and non-harmonized manner. Context information may come from many sources such as legacy systems, individual users (e.g. mobile apps), sensor networks (e.g. IoT devices), static datasets (e.g. CSV, spreadsheet) and APIs without any standardization approach.
Processing miscellaneous context into harmonised data models and meaningful information can take over a month, give or take, and that’s just the estimated time for the engineering team to map all data models and try to understand the value of each context provided by the suppliers. The effort is far more complex. For instance, a non-intrusive approach is required to integrate context data with existing systems as well as upcoming future systems, with few or even none special adaptations. This way, data providers reduce the impact in their architectures and generate savings when creating, maintaining and operating context information models.
Modelling data is a time-consuming effort and often results in a significant loss of information, creating the most diverse challenges, such as how to deal with data that is already generated and is mutating every second and how to carry out an “agnosticism” capable of starting the data collection without any special adaptations for every new context provider? In order to find answers to those questions, one must find a possible entity that is common to most context providers and that have similar characteristics and contains valuable information.
Solution
To address such challenges, the smartdata.wien platform uses FIWARE Orion Context Broker, currently promoted as a Connecting Europe Facility Building Block (CEF building block), providing a global standard NGSI-based API for large scale contextual information management. FIWARE Orion Context Broker also works as a hub of contexts, by sending data to several services, such as notifications, that can be used to automatically send every change to a historical database – in this particular case, the so-called “Data Lake”.
The Smart City Project Smarter Together, financed by the European Commission, promotes the innovation and improvement of urban mobility through the implementation of innovative technical solutions for Smart Cities. Some of the most significant results include openly shared city data, enhanced citizen participation, better knowledge management and increased data/impact monitoring.
Thanks to the initiative, three use cases have so far come to life: Facility Management, Monitoring Mobility, and Harmonisation of Facility and Energy Information. The data providers collect their sensors and other data in their feeder systems and send them to the FIWARE platform via https and predefined APIs. A security layer ensures that only whoever is authorised to do so can see and access the data.
Use Case 1: Facility Management
- Goal: Collection of energy, heating and water consumption data from a school before and after the renovation programme (Smarter Together)
- Data source: energy, heating and water meters
- Visualization: consumption over time
Use Case 2: Monitoring Mobility
- Goal: Analysis regarding changes in the choice of transportation modes
- Data source: Bike & Car sharing apps, e-vehicles (e.g. e-forklift, e-cars of postal service)
- Visualization: KPI´s, energy consumption
Use Case 3: Harmonization of Facility and Energy Information
- Goal: Harmonization of different data sources regarding facility and energy information with unique identifiers
- Data source: Addresses -, building and housing register (AGWR), “lächen” multi-purpose card (FMZK)
- Visualization: Consolidated information from different sources in the Geo information system
In addition, FIWARE platform retrieves Viennese Open Government Data from two open data portals: data.gv.at and opendataportal.at and displays them.
Figure 1 . Visualization car sharing and bike sharing in smartdata.wien
The rich capabilities of the actual deployment of FIWARE on smartdata.wien feeds multiple stakeholders and provides a single, yet, comfortable user experience for developers and non-technical stakeholders alike. The platform handles all data requests and provides innovative visualization capabilities, based on recent FIWARE component KnowAge and data models.
How it works
The API Response entities can be associated with other entities that were generated from it. According to the FIWARE Data Modelling Guidelines on linked data, it should be named with the prefix ref, plus the name of the target (linked) entity type, when an entity’s attribute is used as a link to other entities. The final data model can be composed by several API responses, depending on the context provider and how the data is published.
Figure 2 . FIWARE Data Model
The proposed method consists of the use of a given consumer, a service that makes HTTP requests to the API endpoints and records data into the API response data models. On every request with the same properties, parameters, and query string, filter conditions represent a singular request and will have a unique identification. This request is then formatted into an NGSI data model to create an entity object, subsequently used to create or update an entity into the Orion Context Broker. This same consumer can then provide such information to other entities depending on the project goals.
Figure 3 . Information flows in smartdata.wien
This model can take advantage of all the other benefits offered by the Orion Context Broker, such as NGSI v2 notifications, to create a historical database or consume the NGSI v2 API creating real-time applications, such as dashboards and monitoring panels. This way, smartdata.wien stands out as a future-proof solution and provides all the recently recommended topology and design features.
Benefits & Impact
Both citizens and city officials can benefit from the platform’s web services that facilitate daily activities, ranging from urban mobility to environmental monitoring. The platform gives access to readily organised and visualised information, without the need to go through raw data. This provides the city with unparalleled transparency across policy areas for monitoring and benchmarking, while promoting citizen participation in shaping the future of the city.
From a software developers perspective, the Orion Context Broker’s available solutions indeed save time and money. The APIs make it easy to integrate the Orion Context Broker with existing and future systems, they enable cross-sector data interchanges, and facilitate the creation and maintenance of context data models. The Orion Context Broker is an Open Source solution, eliminating the risk of vendor lock-in. Its open data and open interfaces provide opportunities for third party developers to innovate and get started with creating Smart cities solutions. A complete suite of complementary solutions is provided by FIWARE for data modelling, data visualisation, security, user management and much more.
Added value through FIWARE
The Orion Context Broker is the reference implementation. Orion is an Open Source software designed to take into account all specifications and save developers’ time and money. The Orion Context Broker also provides an open standard API to communicate with all other applications in the ecosystem, such as an open government database or a dashboard application. The API also enables sending data to a historical database, called the Data Lake, to monitor developments across a timeline. Both the Context Broker and the API have been developed by FIWARE, based on the global NGSI specifications. FIWARE’s version of the NGSI interface is a RESTful API that uses HTTP to transfer context data between applications. The API allows data to be retrieved for both one-time queries and subscriptions. The illustration below depicts the solution, with the arrows representing data flows.
Within a FIWARE compliant platform, the context of an entity represents the state of a physical or conceptual object, which exists in the real world. However, to deal with this problem, it is necessary to go to the lowest level possible of the context information available, the elemental data of the context provider, the APIs. Each API. request is a basic HTTP request and can be used as a context entity, its attributes are the URL itself, the connection time, the total time, HTTP Response Code and the data itself: the response body, the raw material that can be used to create new and harmonized data models.
The response of the API is the basic abstraction possible to consume the context data, without knowing the real value of this context information, yet, designing it into the API Response entities, a heterogeneous information system.
Figure 4 . Data exchanges in smartdata.wien
Vienna has chosen relevant data models from FIWARE when defining how entities and attributes relate to each other. This helps the Orion Context Broker to understand how data can be aggregated from the various different sources, including:
- Open Government Data from the following two open data portals
- www.data.gv.at
- www.opendataportal.at
- Other public sources, such as maps and real-time traffic cameras for geospatial data and live camera feed
- Other local data providers
For the API, Vienna has chosen to use the latest NGSI v2 data model with enhanced support for linked data. This makes it easier to create associations between entities, which facilitates establishing meaningful context for data. A security layer ensures that each stakeholder only sees the data for which they are authorized to do so. After adapting and customising the solution for over one year, Vienna now handles a wide range of data requests with innovative visualisation capabilities, based on FIWARE’s complementary business intelligence component called KnowAge.
References
Authors & Contributors
