PaperlayerView exact revision on arXiv

Source-linked AI summary

A Standard-based Open Source IoT Platform: FIWARE

Flavio Cirillo, Gürkan Solmaz, Everton Luís Berz, Martin Bauer, Bin Cheng, Ernoe Kovacs

arXiv:2005.02788v1cs.NI

TL;DR

FIWARE addresses the challenge of deploying interoperable IoT systems across fragmented platforms and demanding application settings. The paper analyzes three real-world use cases and their requirements, finding support for federation, data analytics, and IoT-augmented automated driving while highlighting semantics and privacy as areas of continued innovation.

  • Problem

    IoT deployments face fragmented platforms, heterogeneous data sources, and requirements for interoperability, analytics, security, privacy, and low latency.

  • Method

    The paper analyzes three real-world use cases and maps their requirements to FIWARE components and standard-based interworking approaches.

  • Results

    FIWARE-based approaches support harmonized smart-city platforms, federated analytics, and interworking among heterogeneous IoT platforms for automated driving.

  • Takeaways & Limitations

    FIWARE combines standards, community-driven components, and real-world deployments while remaining open to semantic and privacy innovations.

Abstract

from arXiv · show

The ever-increasing acceleration of technology evolution in all fields is rapidly changing the architectures of data-driven systems towards the Internet-of-Things concept. Many general and specific-purpose IoT platforms are already available. This article introduces the capabilities of the FIWARE framework that is transitioning from a research to a commercial level. We base our exposition on the analysis of three real-world use cases (global IoT market, analytics in smart cities, and IoT augmented autonomous driving) and their requirements that are addressed with the usage of FIWARE. We highlight the lessons learnt during the design, implementation and deployment phases for each of the use cases and their critical issues. Finally we give two examples showing that FIWARE still maintains openness to innovation: semantics and privacy.

I. INTRODUCTION

FIWARE is presented as an open-source IoT framework addressing the fragmented platform landscape and transitioning from research toward commercial readiness. Its real-world validation includes global smart-city interoperability through SynchroniCity.

  • I. INTRODUCTION: IoT platform offerings span commercial and open-source solutions, with FIWARE transitioning from research to commercial readiness.Commercial platforms emphasize provider support, while open-source platforms implement standards and evolve through community-driven, use-case-oriented innovation.
  • I. INTRODUCTION: FIWARE development and deployment have been supported by European Commission-funded projects covering smart cities, autonomous driving, agriculture, food, and e-health.Large-scale pilots such as SynchroniCity and AUTOPILOT demonstrate the framework’s movement toward business readiness.
  • I. INTRODUCTION: Closed commercial APIs and implementations create vendor lock-in, while successful city solutions can remain regionally isolated and produce city lock-in.Both forms of lock-in discourage small and medium-sized enterprises.
  • I. INTRODUCTION: SynchroniCity addresses these barriers by targeting five Minimal Interoperability Mechanisms: context management, data models, marketplace, security, and storage.The first three mechanisms were officially adopted by the OASC consortium in 2019.
  • I. INTRODUCTION: SynchroniCity demonstrates feasibility by harmonizing eight cities and pursuing co-designed IoT services, applications, and a shared market.The cities are Antwerp, Carouge, Eindhoven, Helsinki, Manchester, Milan, Porto, and Santander.

A. Legacy IoT platforms are not neglected

SynchroniCity overlays existing city infrastructures rather than replacing legacy platforms, using FIWARE components to integrate and standardize heterogeneous data. The resulting architecture exposes sensor streams, open data, and historical time series through common interfaces.

  • A. Legacy IoT platforms are not neglected: Figure 1 depicts the federation of pilot sites through the FIWARE IoT platform.The figure accompanies the overlay architecture for connecting existing city resources.
  • A. Legacy IoT platforms are not neglected: SynchroniCity preserves legacy city platforms by deploying a generic overlay instead of redesigning or replacing operational systems.The overlay uses FIWARE building blocks to implement the five Minimal Interoperability Mechanisms.
  • A. Legacy IoT platforms are not neglected: Ad-hoc integration modules translate data from running platforms into the NGSI standard format, while MQTT and HTTP expose sensor data in some cities.FIWARE IoT Agents support native device interfaces.
  • A. Legacy IoT platforms are not neglected: FIWARE/OASC data models harmonize context descriptions across application areas including parking, transportation, waste management, and weather.Adapters and IoT Agents generate context data using these shared models.
  • A. Legacy IoT platforms are not neglected: The Orion Context Broker exposes NGSI query and subscription methods while holding the latest attribute values for each entity.NGSI combines an HTTP-bound context-management interface with a JSON context-data format.

C. IoT Marketplace

The IoT marketplace addresses the need to compensate data providers and give consumers access to cataloged public and private datasets. SynchroniCity implements this function through a standardized marketplace exposing data endpoints, licensing, and prices.

  • C. IoT Marketplace: Private providers may withhold IoT data without payback, while service companies may pay for otherwise inaccessible datasets.This creates a need to treat private data as valuable assets and public datasets as open data.
  • C. IoT Marketplace: SynchroniCity works with the FIWARE community to implement the TM Forum business API standard for its IoT Data Marketplace.The marketplace catalogs available data from Orion or STH Comet.
  • C. IoT Marketplace: The SynchroniCity IoT Data Marketplace describes access endpoints, licenses, and prices, allowing users to buy data items.The marketplace also sets access rules for purchased data.
  • C. IoT Marketplace: The Open Data Federation Platform IDRA addresses the difficulty of discovering government datasets scattered across city-specific platforms and websites.The problem is especially pronounced when open-data sites are available only in local languages.

D. Security

The paper frames interoperable IoT analytics as difficult when data remain fragmented across private infrastructures and analytics routines depend on one another. FIWARE-based approaches combine federation, access control, and data-handling components, while exposing technical constraints in high-frequency streams.

  • D. Security: OAuth2 and XACML 3.0 provide authorization and access control, with FIWARE components KeyRock and AuthZForce integrated into the framework.These requirements are treated as common IoT needs rather than smart-city-specific requirements.
  • D. Security: SynchroniCity addresses global-market interoperability through standardized service interfaces, data models, and an IoT marketplace.These mechanisms support data access across existing city infrastructures.
  • D. Security: Very frequent sensor observations can overwhelm Orion Context Broker notifications or cause data loss.SynchroniCity uses a time-series database as a data sink, while Aeron IoT Broker offers an alternative approach.
  • D. Security: SynchroniCity contributes a free-to-use IoT marketplace, addressing an identified gap in FIWARE.The paper attributes practical usefulness to FIWARE’s community-driven development.
  • D. Security: Fragmented private IoT infrastructures make provider discovery, heterogeneous-data integration, and analytics orchestration difficult for service providers.Porting services to another environment adds further effort in these areas.

A. City Platform as a Service

CPaaS.io defines requirements for integrating, federating, scaling, orchestrating, securing, and transferring smart-city services across Europe and Japan. It addresses them through a heterogeneous FIWARE- and u2-based platform federation.

  • CPaaS.io requires easy data-source integration, federation among IoT platforms, multi-city flexibility, analytics orchestration, security, and transferability across cities.
  • The project tests feasibility across water management, public event management, and public transportation use cases in Amsterdam, Sapporo, Yokosuka, and Tokyo.
  • The platform combines FIWARE on the European side with Japan’s u2 platform to address federation, access control, privacy, security, and analytics orchestration.
  • The European implementation deploys and enhances FIWARE components as the foundation for a smart-city data infrastructure.

B. Urban water management scenario

The Waterproof Amsterdam scenario uses CPaaS.io and FIWARE to manage urban water buffers under drought and heavy rainfall. Its architecture combines layered sensing, data handling, virtual representations, and flexible analytics orchestration.

  • Waterproof addresses drought and intense rainfall by using weather, sewerage, and environmental data to calculate each buffer’s optimal filling degree.
  • The application comprises IoT resources, data ingestion, virtual entities, and analytics-routine management layers for operating smart devices.
  • The implementation uses a customized LoRaWAN IoT Agent, Aeron IoT Broker, STH historical storage, and IoT Discovery for resource registration and contextual queries.
  • FogFlow links atomic analytics tasks flexibly by discovering physical or generated resources and automatically connecting suitable streams to task inputs.
  • FogFlow supports smooth topology portability because it operates at the virtual-world abstraction level; deployment elsewhere requires describing available computing nodes.
  • FogFlow is designed to orchestrate tasks across cloud and edge resources, identified as a future feature for exploiting deployed-device computing.

C. Lessons learned from smart city services

The smart-city services reveal both the value and the engineering gaps of FIWARE-based federation. Open-source components enabled targeted extensions for performance and historical metadata requirements.

  • NGSI and FIWARE components support federation of private and heterogeneous IoT systems toward a global Internet of Things.
  • The water-management deployment exposed unanticipated technical gaps during practical implementation.
  • A lightweight LoRaWAN-to-NGSI bridge was developed for high throughput and low latency, while STH was extended to persist metadata with time-series values.
  • FIWARE’s open-source nature enabled both new-agent implementation from an existing library and direct extension of component source code.

IV. RESEARCH AND INNOVATION: AN AUTOMATED

AUTOPILOT extends FIWARE-based IoT concepts to automated driving, where low latency, high computation, ubiquitous computing, and multiple administrative domains create demanding interoperability requirements.

  • AUTOPILOT targets extreme smart-mobility conditions requiring very low latency, high computation power, ubiquitous computing, and multiple administrative IoT domains.
  • Its use cases include car sharing, car re-balancing, autonomous platooning, and automated valet parking.
  • The project seeks interoperability among vehicles, roadside units, cloud systems, and network infrastructures, including operation across city and road-administration boundaries.

A. Federation of large scale pilots

FIWARE-based federation connects heterogeneous IoT actors, platforms, and pilot sites through transparent brokering, semantic mediation, and standardized data models. The approach supports information flow across vehicles, roadside units, cloud services, and administrative domains.

  • Federation architecture: A decentralized architecture enables vehicles to use local city information while sending key measurements back to their home city during cross-border travel.The example preserves vehicle measurements such as braking distance in the home pilot site while the vehicle operates abroad.
  • Federation architecture: FIWARE Aeron IoT Broker and NEConfMan transparently route datasets and streams between providers and consumers based on declared data availability and interests.Actors may serve as both providers and consumers, allowing flexible IoT data exchange.
  • Edge federation: Roadside units act as edge nodes with processing and storage capabilities, hosting Level 2 federation components for connected autonomous vehicles.Vehicles can communicate directly with one another or connect through roadside units.
  • Semantic interoperability: Semantic Mediation Gateway provides bidirectional context translation between oneM2M’s Mca reference point and the NGSI interface.Interoperability relies on shared semantics that map homologous underlying concepts despite different syntactic representations.
  • Pilot deployment: A real-time Dutch pilot tested data from vehicle and roadside-unit WiFi scanners to estimate regional crowdedness and deliver standardized NGSI context to automated-driving applications.The contextualized information is shared with the automated-driving application as part of the deployed system.

C. The experience of IoT-augmented automated driving

AUTOPILOT demonstrates that standard-based interworking can harmonize heterogeneous IoT platforms for European-scale automated driving. The approach reduces adaptation effort while requiring common information models to handle heterogeneous services.

  • Key benefits: Standard-based interworking allows different IoT platforms to operate in harmony without significant extra costs or overhead.The result is presented as the central benefit of the AUTOPILOT approach.
  • Key benefits: Automated driving can operate across European pilot sites and support long-distance travel despite site-specific solutions.The conclusion concerns European-scale travel across many different local deployments.
  • Key benefits: Pilot sites need not adapt their specific devices or software separately for connection to different IoT platforms.Interworking avoids requiring each site to replace or customize its existing components for every platform.
  • Key benefits: Autonomous vehicles can use services from multiple IoT platforms with limited adaptation effort, including FIWARE crowd estimation and Huawei OceanConnect geofencing.The cited examples show complementary services supplied by different platforms.
  • Critical issue: Heterogeneous data from many possible services remains a drawback, making common standardized information models necessary to avoid service-specific format conversion.AUTOPILOT addresses this through a stakeholder group developing common data models.

A. Semantics: NGSI-LD

NGSI-LD extends FIWARE’s context interfaces with semantic grounding and linked-data representations. It supports ontology-based interoperability, semantic tooling, and direct access to historical time series through advanced queries.

  • Specification: NGSI-LD evolves the OMA-standardized NGSI Context Interfaces and is standardized by ETSI’s ISG CIM for Context Information Management.The specification was published in early 2019 and was expected to become FIWARE’s core interface for Generic Enablers.
  • Semantic grounding: JSON-LD gives NGSI-LD semantic grounding by representing elements as URIs and explicitly defining concepts such as entity types in ontologies.Applications and sources can agree at the level of explicitly specified semantics.
  • Semantic interoperability: Ontology-based modeling adds semantic interoperability on top of heterogeneous IoT systems, especially for cross-cutting and large-scale smart-city applications.Existing ontology and rule-based reasoning tools can operate on information retrieved through NGSI-LD requests.
  • Historical data: NGSI-LD provides native historical-data support, allowing applications to request complete time series directly from context management.It also supports complex IoT data query capabilities.
  • Open challenges: Secure global IoT data sharing still requires distributed privacy and data-usage control, including continued control after sensitive data are shared.FIWARE’s collaboration with IDSA reports feasibility and compatibility of their respective visions, while identifying these capabilities as important for broader deployment.
Loading 2005.02788v1…