We use proprietary and third party´s cookies to improve your experience and our services, identifying your Internet Browsing preferences on our website; develop analytic activities and display advertising based on your preferences. If you keep browsing, you accept its use. You can get more information on our Cookie Policy
Cookies Policy
Ask Your Question

Revision history [back]

click to hide/show revision 1
initial version

Which are the main logical layers of the architecture and what are their main functionalities?

Infrastructure layer. Provides all the computational resources needed to run a smart city platform instance. It is based on Docker and OpenStack technologies. So, cities can deploy their own infrastructures on premise.

Data acquisition & actuation layer. It allows acquiring and ingesting smart city data from different sources including diverse IoT devices and protocols, existing IT systems, or extra private or public data sources. In addition, it exposes mechanisms to actuate over devices or systems, so that a more efficient and smart behaviour is exhibited by a city.

Context brokering layer. The main component of this layer is a data hub (performing the functional role of a context broker) which integrates all the data coming from different sources. In fact, it offers developers an open API (FIWARE NGSI) intended to publish, consume and subscribe to context information. Context information is modelled using entities and properties which represent what is happening in real (or right) time in a city, integrating and aggregating information from multiple sources as described above. Context information is usually harmonised as per the rules dictated by the FIWARE schemas (FIWARE Data Models). The Context brokering layer enables the creation of multiple and related vertical applications portable at data level and easily replicable in multiple cities. The context brokering layer typically exposes the last value of each data item. However, there is also a short term historical database which allows applications to make use of historical time series for the different properties. This layer also provide plugins which offer the capability to automatically generate long term historical data and populate it to big data stores.

Data processing, Analytics & Visualization layer. It allows processing all the city data so that new information can be derived or useful insights can be obtained. As a result processes can be optimized or better decisions can be taken. Data processing can be performed in real time (using a Complex Event Processing component) or deferred by using long term historical data stored in Big Data systems. Once data has been processed, the platform offers plugins and components for its visualization in a dashboard. Besides, there are graphical tools intended to perform advanced data analyses such as those related to location or business intelligence. Last but not least, some advanced interaction components are offered to deal with 3D representations or augmented reality.

Economy of data layer. This layer incorporates all the components needed to run an economy of data, so that context information from a city is properly published, secured and accounted. It allows data providers to publish, expose and charge for their data, data consumers to acquire data sets and pay for their consumption. As a result a data marketplace is enabled, moving forward from the concept of open data to the economy of data. This layer is powered by the corresponding TM Forum APIs.

How does the reference architecture handle southbound integration? How is integration with legacy systems managed? What kind of protocols are supported?

Southbound integration is managed through a library of connectors named IoT Agents. Each IoT Agent is specialized in one IoT protocol or connectivity mechanism. There is a programming library which simplifies the creation of new IoT Agents. Integration with legacy systems is managed through context providers which are adaptors that enable the integration of legacy systems with the rest of smart city data present in a context broker instance. For instance, a context provider can be used to obtain the current position of a bus, being this position exposed by an existing bus fleet management system.

Multiple protocols are supported, particularly HTTP, MQTT, LWM2M or Sigfox. Different representation formats for IoT data are supported, including Ultralight 2.0 or plain JSON. The developed of new adaptors for other protocols is fast and easy thanks to the programming library mentioned above.

How are authentication, authorization and accounting managed? Authentication is managed through an Identity Manager component (IdM) based on an extended version of OpenStack Keystone. Authorization is controlled by a policy decision point (PDP) implemented using XACML 3.0 and controlled by an HTTP proxy, which acts as a Policy Enforcement Point (PEP). Such proxy secures access to the data so that only authenticated and authorized users can get access to it. Currently a new architecture is being developed which includes a more robust API management component (named APinf) and accompanying proxy (API Umbrella). Accounting is managed as follows: Every transaction made by an application is logged by the PEP proxy. Such PEP proxy is capable to propagate a usage log record to the system in charge of performing the accounting, the Business Framework. In fact, the Business API Ecosystem supports pay-per-use pricing models.

How is privacy and data protection handled? Although the original FIWARE Projects worked on different privacy components, for the time being there are no, production ready, off-the-shelf platform components for dealing with privacy. As a result, applications have to implement their own custom mechanisms for data protection and privacy.

Are there reference implementations of the architecture or suggested technologies to implement specific components? All the components of the architecture are open source and offered through friendly open source licenses. Source code is available through Github repositories https://github.com/fiware.

How is managed the data collection/publication process? Is there a specific component dedicated to open data management? FIWARE uses CKAN as the main platform for managing open data, including data publication and its exposure to developers, consumers or businesses. The data collection and ingestion to CKAN is managed through specific platform components which allow connecting a context broker instance to CKAN. As a result, new CKAN datasets can be generated on the fly, including all the historical data series generated along the time by real time datasets.
In addition, there are extra plugins offered by FIWARE which allow publishing real time datasets associated to dynamic NGSI queries. Last but not least, FIWARE is offering innovative CKAN plugins which allow visualizing harmonized entities in advanced and composable dashboards.

In essence, FIWARE provides connectors between the traditional open data publication world and the real (right) time data world, incarnated by context broker architectures and the NGSI API.

How is managed the data/semantic interoperability inside the platform? Are defined specific data models? The FIWARE Data Models site http://schema.fiware.org provides a catalogue of different common information models useful in the smart city domain. Multiple smart city verticals are addressed (parking, lighting, transport, waste management, etc.). Some of these data models have already been adopted by GSMA and other smart city platforms. Such data models have been formalized using JSON Schema, so that developers can easily adopt them. Last but not least, the development of the data models follows a community-driven collaborative approach, ensuring that the interests of different stakeholders are covered.

How is the northbound layer managed? Does the architecture define logical API? As it was mentioned before, the architecture mandates the northbound exposure of all data using the FIWARE NGSI API. The FIWARE NGSI API, supported by GSMA and TMForum, is specified at http://fiware.github.io/specifications/ngsiv2/latest/ and it is in process of being formally standardised by the ETSI CIM ISG.