Catalogue

This is an umbrella repository which briefly introduces each of the components (also referred as Generic Enablers) which are part of FIWARE and allow users and developers to easily navigate to the relevant source code repositories, documentation and container registry images on Docker Hub or quay.io.

More information about what FIWARE is and how to use it can be found within the FIWARE Tour Guide, the FIWARE Academy and the Step-by-Step Tutorials. Generic questions about FIWARE can be asked on Ask.FIWARE and developer-based questions can be submitted on Stack Overflow using the FIWARE tag.

fiware.org	:books: Tour Guide	:mortar_board: Academy	:capital_abcd: Tutorials	:question: Ask.​FIWARE	Stack Overflow

Contents

Details

• Background
• Installation
• Generic Enablers
  • Core Context Management
  • Interface with IoT, Robots and Third-Party Systems
  • Context Processing, Analysis and Visualization
  • Context Data/API Management, Publication and Monetization
  • Deployment Tools
• Data Spaces
• Management of FIWARE Releases
• Testing
• Contributing
• License

Background

FIWARE brings a curated framework of open source software platform components which can be assembled together and with other third-party components to build platforms that support the development of Smart Solutions faster, easier and cheaper. The main and only mandatory component of any “Powered by FIWARE” platform or solution is a FIWARE Context Broker Generic Enabler, supplying a cornerstone function required in any smart solution: the need to manage context information, enabling to perform updates and bring access to context.

FIWARE NGSI is the API exported by a FIWARE Context Broker, used for the integration of platform components within a "Powered by FIWARE" platform and by applications to update or consume context information. FIWARE NGSI API specifications have evolved over time, initially matching NGSI-v2 specifications, now aligning with the ETSI NGSI-LD standard. The FIWARE Community plays an active role in the evolution of ETSI NGSI-LD specifications which were based on NGSI-v2 and commits to deliver compatible open source implementations of the specs.

Building around the FIWARE Context Broker, a rich suite of complementary open-source FIWARE Generic Enablers are available, dealing with the following:

• Core Context Management manipulates and stores context data so it can be used for further processesing
• Interfacing with the Internet of Things (IoT), Robots and third-party systems, for capturing updates on context information and translating required actuations.
• Processing, analysis and visualization of context information, implementing the expected smart behaviour of applications and/or assisting end users in making smart decisions.
• Context Data/API management, Security, publication and monetization, bringing support to usage control and the opportunity to publish and monetize part of managed context data.
• Deployment Tools such as Docker images and Helm-chart recipes are available for each Generic Enabler

FIWARE is not about take it all or nothing. You are not forced to use these complementary FIWARE Generic Enablers but are free to use other third platform components as well to design the hybrid platform of your choice. As long as it uses the FIWARE Context Broker technology to manage context information, your platform can be labeled as “Powered by FIWARE” and solutions build on top as well. Listings of many FIWARE Ready devices and commercial “Powered by FIWARE” solutions can be found on the FIWARE Marketplace.

To be adopted as a Generic Enabler within FIWARE, each open source component must fulfil a number of contribution requirements. The technical direction of FIWARE is governed by the FIWARE Technical Steering Committee (TSC). Developers can also subscribe to the FIWARE TSC mailing list, join the FIWARE TSC regular confcalls as observer and follow the progress of the discussions through the FIWARE TSC meeting minutes.

:clipboard: Contribution Requirements	:family: Technical Steering Committee	:mega: Mailing list	:open_file_folder: Meeting minutes

Installation

To obtain the latest codebase of all FIWARE Generic Enablers:

git clone https://github.com/FIWARE/catalogue.git
cd catalogue/
git submodule update --init --recursive
git submodule update --recursive --remote

Generic Enablers

The following sections describe the current list of Generic Enablers of the FIWARE platform structured into five architectural chapters.

Core Context Management

Core Context Broker components

A Context Broker component is the core and mandatory component of any “Powered by FIWARE” platform or solution. It enables to manage context information in a highly decentralized and large-scale manner.

• The Orion Context Broker Generic Enabler currently provides the FIWARE NGSI v2 API which is a simple yet powerful Restful API enabling to perform updates, queries or subscribe to changes on context information.

The following Context Broker implementations, supporting the ETSI NGSI-LD 1.3.1. API specification or higher are available:

• The Orion-LD Context Broker Generic Enabler is a NGSI-LD Broker, which supports both NGSI-LD and the NGSI-v2 APIs.
• The Scorpio Broker Generic Enabler is an alternative NGSI-LD Broker which can also be used in federated environments
• The Stellio Context Broker Generic Enabler is another alternative NGSI-LD Broker

NGSI-LD Context Broker Feature Comparison

The NGSI-LD Specification is regularly updated published by ETSI. The latest specification is version 1.8.1 which was published in March 2024.

• A spreadsheet detailing the current compatibility of the bleeding edge development version of each context broker (Orion-LD, Scorpio, Stellio) against the features of the 1.6.1 specification can be viewed and downloaded here

• An Excel file detailing the compatibility of the latest FIWARE Release of each context broker (Orion-LD, Scorpio, Stellio) against the features of the 1.6.1 specification can be downloaded here

Core Data Connectors

Accompanying a Context Broker component as part of Core Context Management, a number of Data Connectors are available:

• The Cygnus Generic Enabler is enables a means of managing the history of context which is created as a stream of data and can be injected into multiple data sinks, including many popular databases such as PostgreSQL, MySQL, MongoDB or AWS DynamoDB or as Big Data platforms such as Hadoop, Storm or Spark. The component is based on Apache Flume
• The Draco Generic Enabler is an alternative data persistence mechanism for managing the history of context. It is based on Apache NiFi and is a dataflow system based on the concepts of flow-based programming. It supports powerful and scalable directed graphs of data routing, transformation, and system mediation logic and also offers an intuitive graphical interface
• The Cosmos Generic Enabler enables simpler Big Data analysis over context integrated with popular Big Data platforms (Spark and Flink).
• The QuantumLeap Generic Enabler supports the storage of context data into a time series database (CrateDB and Timescale)
• The STH Comet Generic Enabler brings the means for storing a short-term history of context data (typically months) on MongoDB

The following is a list of Generic Enablers under incubation within the area of Core Data Connectors systems:

• Mintaka is an add-on to the Orion-LD Context Broker providing an implementation of the NGSI-LD temporal retrieval API.
• The Canis Major Generic Enabler is a blockchain adaptor that supports various DLTs, the adaptor aims to submit the data to DLT using FIWARE Technologies
• The NGSI.js Library provides a series of JavaScript functions allowing developers to connect and push context data to any NGSI compliant context broker
• The PySpark Connector Generic Enabler creates a data bridge between context brokers and PySpark
• The O2K Connector Generic Enabler that enables context data sharing from any NGSI Context Broker towards Apache Kafka
• The Apollo Generic Enabler creates entities based on notifications

Further information can be found on dedicated pages linked to Core Context Management

Interface with IoT, Robots and Third-Party Systems

A number of Generic Enablers are available making it easier to interface with the Internet of Things (IoT), Robots and Third-party systems for the purpose of gathering valuable context information or trigger actuations in response to context updates:

• The IDAS Generic Enabler offers you a wide range of IoT Agents making it easier to interface with devices using the most widely used IoT protocols (LWM2M over CoaP, JSON or UltraLight over HTTP/MQTT, OPC-UA, Sigfox or LoRaWAN)

  • IoT Agent for JSON - a bridge between HTTP/MQTT messaging (with a JSON payload) and NGSI
  • IoT Agent for LWM2M - a bridge between the Lightweight M2M protocol and NGSI
  • IoT Agent for Ultralight - a bridge between HTTP/MQTT messaging (with an UltraLight2.0 payload) and NGSI
  • IoT Agent for LoRaWAN - a bridge between the LoRaWAN protocol and NGSI
  • IoT Agent for OPC-UA - a bridge between the OPC Unified Architecture protocol and NGSI
  • IoT Agent for Sigfox - a bridge between the Sigfox protocol and NGSI
  • IoT Agent for ISOXML - a bridge between the ISOXML/ADAPT protocol for agricultural machinery and NGSI
  • IoT Agent library - library for developing your own IoT Agent.

• The Kurento Generic Enabler enables real-time processing of media streams supporting the transformation of video cameras into sensors as well as the incorporation of advanced application functions (integrated audiovisual communications, augmented reality, flexible media playing and recording, etc)

The following is a list of Generic Enablers under incubation within the area of IoT, Robotics and third-party systems:

• The OpenVidu Generic Enabler is an abstraction layer for Kurento, making media processing easier to program.
• The OpenMTC Incubated Generic Enabler brings an open source implementation of the OneM2M standard. A northbound interface with the Orion Context Broker is implemented as part of the product.
• The Fast DDS Incubated Generic Enabler has been adopted as default middleware in ROS2, the widely known Robot Operating System, therefore it helps to interface with ROS2-based robotics systems.
• The Micro XRCE-DDS Incubated Generic Enabler is a lite version of the DDS middleware, adapted to run in extremely constrained resource devices (e.g. micro-controllers).
• The FIROS Incubated Generic Enabler works as a translator between the robotics domain and the cloud, transforming ROS messages into NGSI v2 and vice versa.
• The Domibus Incubated Generic Enabler helps users to exchange electronic data and documents with one another in a reliable and trusted way.
• The Oliot Incubated Generic Enabler is a mediation gateway which translates information from NGSI based platforms to EPCIS based IoT platforms.

Further information can be found on dedicated pages linked to IoT Agents and Robotics and Third-Party Systems

Context Processing, Analysis and Visualization

A number of Generic Enablers are available making it easier to process, analyze or visualize context information for the purpose of implementing the “smart behaviour” expected in any application:

• The Wirecloud Generic Enabler brings a powerful web mashup platform making it easier to develop operational dashboards which are highly customizable by end users.
• The FogFlow Generic Enabler is a distributed execution framework to support dynamic processing flows over cloud and edges.

The following is a list of Generic Enablers under incubation within the chapter:

• The Perseo Generic Enabler introduces Complex Event Processing (CEP) defined using a rules-based system, enabling you to fire events which send HTTP requests, emails, tweets, SMS messages etc.

Further information can be found on dedicated pages linked to Context Processing, Analysis and Visualization

Context Data/API Management, Publication and Monetization

You can implement secured access to components in the architecture of any “Powered by FIWARE” solution using Generic Enablers of the security chapter:

• The Keyrock Identity Management Generic Enabler brings support to secure and private OAuth2-based authentication of users and devices, user profile management, privacy-preserving disposition of personal data, Single Sign-On (SSO) and Identity Federation across multiple administration domains.
• The Wilma PEP Proxy Generic Enabler brings support of proxy functions within OAuth2-based authentication schemas. It also implements PEP functions within an XACML-based access control schema.
• The AuthZForce PDP/PAP Generic Enabler brings support to PDP/PAP functions within an access control schema based on the XACML standard.

The incorporation of components and features to support Advanced Data Usage Control have been introduced as part of FIWARE Release 7.7. For a summary of vision and current status of work in this area, please visit the usage control pages found at: https://github.com/ging/fiware-usage-control

This area also contains a chapter for the publication and monetization of context data resources, available through the core Orion Context Broker component of your platform:

• The CKAN extensions Generic Enabler brings a number of add-ons enabling to extend current capabilities of the world-leading CKAN Open Data publication platform to allow publication of datasets matching right-time context data, the assignment of access terms and policies to those datasets and the assignment of pricing and pay-per-use schemas to datasets.
• The Biz Framework Generic Enabler brings backend support to Context API/Data monetization based on open TM Forum Business APIs.
• Idra is able to federate existing Open Data Management Systems based on heterogeneous technologies (e.g. CKAN, SOCRATA, DKAN etc.) providing a single API and a standard metadata format (DCAT-AP) to discover open datasets.

The following is a list of Generic Enablers under incubation within the area of API management, publication and monetization:

• APInf API Management Framework is a tool for API owners to manage their APIs. It provides all the necessary features to run business with APIs and makes it easy for API consumers to find and start using the standard APIs.
• CoatRack is a third-party backend-to-backend communications framework facilitating API access, monitoring and monetization.
• Endpoint-Auth-Service transparently adds authentication/authorization information to outgoing http-requests
• Kong Plugins extends the functionality of the Kong API Gateway to cover additional PEP scenarios applicable to context data sharing

The following is a list of Generic Enablers under incubation within the area of Security:

• Keystone SPASSWORD is an OpenStack Keystone extension that enables extra security checks over user passwords
• FIWARE TRUE Connector enables trusted data exchange in order for context brokers to be able to become an active part of an International Data Spaces (IDS) Ecosystem
• Steelskin PEP is a PEP proxy meant to secure independent FIWARE components, by intercepting every request sent to the component, validating it against an Access Control component such as Keypass
• Keypass is multi-tenant XACML server with PAP and PDP capabilities.
• Keystone SCIM is an OpenStack Keystone extension that enables the management of User, Groups and Roles using the SCIM v1.1 standard
• Keystone SPASSWORD is an OpenStack Keystone extension that enables extra security checks over user passwords
• Anubis is an RBAC Policy Execution Point that makes easier to reuse security policies across different services
• Trusted Issuers List Service provides an EBSI Trusted Issuers Registry implementation to act as the Trusted-List-Service in the DSBA Trust and IAM Framework.
• DSBA PDP is a Policy-Desicion Point, evaluating Json-Web-Tokens containing VerifiableCredentials in an DSBA-compliant way. It also supports the evaluation in the context of i4Trust.
• VC-Verifier provides the necessary endpoints to offer SIOP-2/OIDC4VP compliant authentication flows. It exchanges VerfiableCredentials for JWT, that can be used for authorization and authentication
• Keycloak VC-Issuer is a plugin for Keycloak to support SIOP-2/ OIDC4VP clients and issue VerifiableCredentials through the OIDC4VCI-Protocol to compliant wallets.
• Credentials Config Service manages and provides information about services and the credentials they are using. It returns the scope to be requested from the wallet per service and the credentials and issuers that are considered to be trusted for a certain service.
• Trusted Issuers Registry provides both an EBSI Trusted Issuers Registry implementation and an iShare implementation.

Further information can be found on dedicated pages linked to Context Data/API Management, Publication and Monetization and Security

Deployment Tools

Most FIWARE components are available as Docker Images, direct links can be found within the descriptions of each generic enabler. A docker-compose.yml may also be available within the GitHub repository, but these should only be used in development environments. For fully scalable production-ready instances of FIWARE Generic Enablers please refer to the repository holding the FIWARE Helm Chart recipes or find FIWARE Helm Chart receipes directly on ArtifactoryHub

Data Spaces

FIWARE brings the essential building blocks helping to create Data Spaces enabling access and share of data in an effective and trustworthy manner. The open source nature of FIWARE technologies foster creation of these data spaces as federated infrastructures where multiple providers can be involved and not just a few players. FIWARE is bringing today mature technologies, compatible with IDS and CEF Building Blocks, that may accelerate the delivery of data spaces to the market and the materialization of initiatives like GAIA-X in Europe.

The concrete selection of FIWARE components proposed as building blocks for the creation of Data Spaces can be found on dedicated pages linked to FIWARE for Data Spaces.

Management of FIWARE Releases

The individual components within the FIWARE catalogue are free to make semantic versioned releases at any time. Additionally, a labelling of the whole FIWARE catalogue takes place at regular intervals where all components are collected together and a FIWARE label added according to a set of well-defined rules. The FIWARE catalogue release schedule follows a strict timetable. Versions of components with the same FIWARE release label should be completely interoperable and work nicely with each other.

:dart:   Roadmap	:rocket:   Release Notes

As well as source-code repositories and binaries, relevant components are available as container registry images and Helm-chart recipes for Kubernetes. Smart Data Models for NGSI-v2 and NGSI-LD help to define harmonised representation formats and semantics that will be used by applications both to consume and to publish data.

Docker Hub	quay.io	Artifact Hub	:globe_with_meridians: Helm Charts	Smart Data Models

Testing

FIWARE is ready to work in industrial environments. A continuous quality assurance process is running to warranty the level of reliability in FIWARE Generic Enablers. Following the energy labelling system applied by European Union for devices, each Generic Enabler is assigned with an overall label in the Catalogue (A+++, A++, A+, A, B, C) according to the obtained results in testing different aspects.

A testing method has been defined to conduct documentation verification, functional tests (verification of Generic Enablers specifications and APIs testing) and non-functional tests such as performance, stability and scalability. The tests are executed for every new version of the Generic Enablers, providing valuable insights to the Generic Enabler owners for improving the next Generic Enabler release.

All the tests can be conducted by anyone since the files for defining and running the tests have been published in an open source repository.

Full details of the test results can be found on the FIWARE site - a summary of the test results is presented for each enabler within the submodules below.

Mature Generic Enablers have been thoroughly tested and have already demonstrated useful role accepted within the FIWARE framework. Incubated Generic enablers (annotated with :seedling:) have also been tested, but are still in the process of maturing to full acceptance with the FIWARE system. Recent applicants to FIWARE (annotated with :new:) are new to FIWARE and will undergo testing in the forthcoming release.

Willing to contribute your technology to FIWARE?

The application process for joining the FIWARE Initiative is described in the links below. To be adopted as a Generic Enabler within FIWARE, each open source component must fulfill a number of contribution requirements, follow common Open Source Best Practice and sign-up to the harmonized FIWARE Entity Contributor License Agreement. The technical direction of FIWARE is governed by the FIWARE Technical Steering Committee (TSC).

You can contribute to FIWARE technically by different means: contributing code for a given FIWARE component, helping to develop tutorials/training material which are made freely available to developers, supporting QA activities or supporting the operations of the FIWARE Lab.

:inbox_tray: Application Form	:clipboard: Contribution Requirements	:heavy_plus_sign: :computer: Entity CLA	:wrench: Active Contributors	:heavy_plus_sign: :bust_in_silhouette: Individual CLA

License

License: AGPL-3.0 © 2018-2023 FIWARE Foundation e.V.

The FIWARE Catalogue includes additional submodules which have been obtained under license - check the README of each submodule for more details. Some of these elements are available under a more permissive license than Affero General Public License.

Additional permission is given to reproduce the texts found within the root project under the Creative Commons CC-BY-4.0 License.

Further information on the use of the GPL or AGPL open source license

Some FIWARE Components are distributed under GPL or AGPL open source licenses … Is it safe for me to use?

Absolutely. Issues with GPL (or AGPL) licenses are mostly related with the fact that different people assign different interpretations on the meaning of the term “derivate work” used in these licenses. Due to this, some people understand that there is a risk in just using software under GPL or AGPL licenses (even without modifying it).

In order to avoid any issue, FIWARE Generic Enabler owners who have decided to release their software using a GPL or AGPL license are required to make a public statement that states:

Please note that software derived as a result of modifying the source code of this software in order to fix a bug or incorporate enhancements is considered a derivative work of the product. Software that merely uses or aggregates (i.e. links to) an otherwise unmodified version of existing software is not considered a derivative work.

The public statement above is aimed at giving users confidence they can use FIWARE components even if they have been licensed under a copyleft license without this requiring that their applications have to be released as open source. The FIWARE Foundation has sought legal advice regarding this statement and has been told that incorporation of this paragraph is valid for this purpose as per the report produced by Across Legal/ID law partners (see summary report).

This means that there is absolute no risk that you are forced to release the software that you may have developed using FIWARE Generic Enablers under a GPL, AGPL or any other open source license.