Native DDS

[kzangeli]

Native DDS in Orion-LD

As a part of the ARISE European project, Orion-LD is equipped with native FastDDS, as a "joint venture" between eProsima and the FIWARE Foundation.

The idea is that the context broker translates the data published in the DDS topics into NGSI-LD entities and attributes.
Not to make a full binding for NGSI-LD to use FastDDS as just another transport layer as FastDDS is way too sophisticated for that. It's more like a convention on how to connect an NGSI-LD context broker to a FastDDS system and open up HTTP access to the FastDDS sustem via the context broker.

Phase I - Legacy Mode

Phase I or "Legacy Mode" is for the broker to be able to connect to already running DDS systems, without any modification whatsoever to the already running DDS system.

Basically, the broker listens to the DDS communication, receiving every DDS sample and translates those samples into NGSI-LD entities/attributes, adding that to its current state.
Applications can then access those entities/attributes coming from DDS via normal HTTP NGSi-LD queries/subscriptions.

That's about the "read only" mode, which is already working as of release 1.7.0 of Orion-LD.

For the "Write mode" that is to be supported by the end of 2024, any update of an NGSI-LD entity/attribute will be pushed onto DDS.

As earlier stated, every pushed DDS sample is (by convention) seen as an NGSI-LD attribute, so the NGSI-LD broker needs a translation table from DDS topic to NGSI-LD entity id, entity type, and attribute name.
In the Legacy mode, as we need it to be 100% non-intrusive on the already running DDS system, a configuration file of the broker supplies this information

Configuration File

The recently introduced configuration file of Orion-LD contains, apart from pure DDS information (such as QoS), a translation table from DDS topics to NGSI-LD entity id/type and attribute names.
Right now there's only DDS related options in the configuration file but, the idea is to include all CLI options in the config file, some day ...
By default the config file $HOME/.orionld is used, but there is a CLI option -configFile <path to configuration file> to override that. If you do override and the config file does not exist, Orion-LD refuses to start.
It's OK to run Orion-LD without a config file, there are default values in place. It is not OK though to tell the broker to use a specific config file that does not exist.

Sample config file:

{
  "dds": {
    "ddsmodule": {
      "dds": {
        "domain": 0,
        "allowlist": [
          {
            "name": "*"
          }
        ],
        "blocklist": [
          {
            "name": "add_blocked_topics_list_here"
          }
        ]
      },
      "topics": {
        "name": "*",
        "qos": {
          "durability": "TRANSIENT_LOCAL",
          "history-depth": 10
        }
      },
      "ddsenabler": null,
      "specs": {
        "threads": 12,
        "logging": {
          "stdout": false,
          "verbosity": "info"
        }
      }
    },
    "ngsild": {
      "topics": {
        "P1": {
          "entityType": "Camera",
          "entityId": "urn:ngsi-ld:camera:cam1",
          "attribute": "shutterSpeed"
        },
        "P2": {
          "entityType": "Arm",
          "entityId": "urn:ngsi-ld:arm:arm1",
          "attribute": "armReach"
        }
      }
    }
  }
}

The field "dds:ngsild:topics" is a JSON object containing the DDS topics ("P1", "P2" in the example), with the three NGSI-LD "identifiers" hanging under them.
Any DDS sample (notification) with a topic name not covewred in the config file is assumed to belong to a default NGSI-LD entity. The ID and Type of this default entity are { "id": "urn:ngsi-ld:dds:default", "type": "DDS" }.
[ Remember the value of the entity type ("DDS") is expanded usinf the @context. ]

NGSI-LD shortnames are used in the configuration file, but, these are expanded by the broker using the @context.
Still not 100% decided on what to do with the context but for now, a default user context will be used. Default user contexts are already standardized in ETSI ISG CIM and the feature has recently been added to Orion-LD.

Phase II - NGSI-LD Aware Mode

Phase II of the "Native DDS in NGSI-LD brokers" is meant for DDS systems created with NGSI-LD in mind from scratch.
The definition of phase II is still a work in progress but the idea is that the topic name is the NGSI-LD longname of an attribute
and the entity id and optionally the entity type are part of the sample.
Thus, no config file is needed. Well, the part "dds:ngsild:topics" is not needed.

This phase II should be implemented and fully working in Orion-LD before the end of 2025.

How to enable native DDS in Orion-LD

Orion-LD already has a CLI option -wip used to turn on features that are "work in progress".
To turn on native DDS support, start the broker like this:

% orionld -wip dds