Skip to content
Open
Changes from 10 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
273 changes: 273 additions & 0 deletions docs/features/communication/dds_gateway/index.rst

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would like to place the same requests as we agreed on with the SOME/IP gateway.

  1. How a translation from intra-ecu to inter-ecu communication is integrated in the system is very much up to the integrator.
  2. The DDS gateway implementation that S-CORE provides is only a showcase on how this problem can be solved. Users must be able to implement/integrate a different DDS translation concept (e.g. one without explicit gateway process).
  3. The DDS logic must be a binding beneath mw::com (e.g. the gateway internally uses mw::com to interact with the DDS stack) This is the foundation of supporting different integration concepts.

@Abhishek2581 Abhishek2581 Jun 25, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed.

We will align the DDS solution with the architectural concept used for the SOME/IP gateway.

The DDS Gateway described in this FR will be positioned as the reference implementation demonstrating one possible translation concept between intra-ECU and inter-ECU communication. Integrators are not required to use this explicit gateway process and may implement alternative translation concepts, including solutions without a dedicated gateway process.

To support this flexibility, the DDS functionality will be provided as a DDS binding beneath mw::com. The reference DDS Gateway will internally use this binding rather than interacting directly with the DDS stack. This establishes a common integration layer that enables different deployment and translation concepts while keeping the gateway as the reference implementation.

The FR will be updated to clarify this architecture.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let me clarify this further to not restrict this in the wrong way:
There are two basic approaches:

  1. Applications know in their deployment that they talk to the DDS daemon (e.g. binding approach)
  2. Applications are completely unaware that they talk to the DDS daemon (e.g. gateway approach)

The gateway approach bases on the binding approach and adds an additional automated translation layer that fully hides any DDS specific information.
There are use cases out for both approaches. Since gatewaying bases on bindings, we must get the binding approach sound.

For the translation logic, we can likely only provide an example, since this is normally very vendor specific.
But showing this example is valuable (hence, why we do this for SOME/IP).

Original file line number Diff line number Diff line change
@@ -0,0 +1,273 @@
..
# *******************************************************************************
# Copyright (c) 2024 Contributors to the Eclipse Foundation
#
# See the NOTICE file(s) distributed with this work for additional
# information regarding copyright ownership.
#
# This program and the accompanying materials are made available under the
# terms of the Apache License Version 2.0 which is available at
# https://www.apache.org/licenses/LICENSE-2.0
#
# SPDX-License-Identifier: Apache-2.0
# *******************************************************************************

DDS Binding and Gateway
=======================

.. document:: DDS-Gateway
:id: doc__dds_gateway
:status: valid
:safety: ASIL_B
:tags: contribution_request, feature_request
:security: YES
:realizes: wp__feat_request


Overview
--------
This feature introduces DDS communication support for ``mw::com`` and a
reference DDS Gateway implementation.

DDS communication is provided as a binding beneath ``mw::com``. This allows
applications to use the ``mw::com`` abstraction while the communication is
transported over a DDS network, based on the service and deployment
configuration selected by the integrator.

In addition, the DDS Gateway provides a reference translation concept between
local ``mw::com (LoLa)`` communication and DDS-based inter-ECU communication.
It enables controlled and configurable data exchange between intra-ECU
``mw::com (LoLa)`` participants and DDS-based systems while preserving
existing application implementations.

Architecture Concept
--------------------

The DDS feature supports two integration concepts:

- Direct DDS binding usage beneath ``mw::com``
- Reference DDS Gateway based translation

Direct DDS Binding Concept
~~~~~~~~~~~~~~~~~~~~~~~~~~
In this concept, an application uses the regular ``mw::com`` API.The integrator selects DDS as
the communication binding through the service/deployment configuration.
The application does not directly use DDS APIs, but its communication is transported over the DDS network.

::

============================== ==============================
ECU 1 ECU 2
============================== ==============================

+-------------------------+ +-------------------------+
| Application A | | Application B |
| (mw::com) | | (mw::com) |
+-----------+-------------+ +-----------+-------------+
| ^
| mw::com API | mw::com API
v |
+---------------------+ +---------------------+
| DDS Binding | | DDS Binding |
+----------+----------+ +----------+----------+
| ^
| DDS | DDS
v |
=================== DDS NETWORK ===================

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Clarification: Will DDS work fully without any daemon that acts as intermediary per host for any DDS traffic?
If no, please add the daemon here and consider that you have essentially two cases:

  1. Daemon interacts with multiple applications (binding usecase)
  2. Daemon interacts with one single application that translates and forwards via LoLa to actual user applications (gateway)


The DDS binding provides the DDS communication layer beneath ``mw::com``.
It is responsible for runtime type handling, runtime serialization and
deserialization, creation of DDS communication entities, conversion between
``mw::com`` samples and DDS runtime data representation, DDS communication
routing, QoS configuration, and interaction with the underlying DDS stack.

Communication is established by mapping mw::com events to DDS Topics.
In DDS, a Topic represents a named communication channel associated with a
specific data type.Based on the deployment configuration, the DDS binding
creates the required DDS Topics, DataReaders and DataWriters. DDS Domains
provide communication isolation and may be used to separate communication
routes (for example, QM and ASIL communication).

Applications continue to use the standard ``mw::com`` programming model,
while the selected binding transports the data over DDS.
The application programming model remains unchanged. Publishers and subscribers
continue to allocate and populate typed ``mw::com`` samples, while the DDS
binding performs the conversion to the DDS data representation and interacts
with the underlying DDS stack.

Reference DDS Gateway Concept
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The DDS Gateway is a reference implementation that demonstrates one possible
translation concept between local ``mw::com (LoLa)`` communication and DDS
domains. In this concept, the applications continue to use ``mw::com (LoLa)``
locally, while the gateway performs the translation and routing to DDS.

::

============================== ==============================
ECU 1 ECU 2
============================== ==============================

+-------------------------+ +-------------------------+
| Application A | | Application B |
| (mw::com LoLa) | | (mw::com LoLa) |
+-----------+-------------+ +-----------+-------------+
| ^
| mw::com (LoLa - IPC) | mw::com (LoLa - IPC)
v |
+---------------------+ +---------------------+
| DDS Gateway | | DDS Gateway |
| (ECU 1) | | (ECU 2) |
+----------+----------+ +----------+----------+
| ^
| |
v |
=================== DDS NETWORK ===================
| ^
============================== |
ECU 3 |
============================== |
| |
v |
+---------------------+ |
| DDS Application |--------------------------+
| (optional) |
+---------------------+

The reference DDS Gateway is one such implementation built on top of the
DDS communication binding. The binding architecture also supports deployment
solutions without an explicit gateway process.

Each DDS Gateway instance connects to:

- Local ``mw::com (LoLa)`` participants (IPC binding)
- A DDS domain for inter-ECU communication

The gateway is responsible for:

- Translating between ``mw::com (LoLa)`` and DDS communication
- Managing configurable translation routes
- Applying End-to-End (E2E) protection
- Scheduling translation through configurable worker queues (e.g., Mailbox and Queue policies)

Scope
-----

This feature provides:

DDS Communication Binding
~~~~~~~~~~~~~~~~~~~~~~~~~

The DDS communication binding provides DDS communication beneath ``mw::com``.

It provides:

- Communication between ``mw::com`` applications over DDS using the standard
``mw::com`` programming model

- Configuration-driven mapping between ``mw::com`` and DDS:

- Each ``mw::com`` event is mapped to one DDS Topic
- DDS Topic data is mapped back to the corresponding ``mw::com`` event
- DDS deployment configuration extends the ``mw::com`` deployment
configuration with DDS-specific attributes such as runtime type references,
QoS policies and DDS Domain IDs
- Standard DDS endpoint discovery is used to determine the availability of
configured DDS endpoints and map this to the ``mw::com`` availability model

This comment was marked as resolved.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

DDS discovery operates at the Topic and endpoint level, whereas mw::com
availability is exposed at the service level.

The gateway configuration defines the mapping between DDS Topics and the
events of a corresponding mw::com service instance.

The DDS Communication Component monitors the discovery state of the configured
DDS Topics and derives service availability from the required Topics of the
configured service instance.

Once the required DDS Topics become available, the Gateway Component offers
the corresponding local mw::com service. Loss of the required DDS Topics
results in withdrawal of the local service availability.

To make this explicit, I added a service availability propagation section and
a high-level diagram to the Feature Request.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the answer, I will continue this discussion in the newly added section.

- Support for configurable DDS domain-based routing
- Runtime type definition via configuration (e.g. JSON) or dynamic library
- Runtime creation of DDS entities (Topics, DataReaders and DataWriters)
- Runtime conversion between ``mw::com`` raw memory samples and the DDS runtime data representation using runtime type definitions
- Runtime serialization and deserialization performed by the DDS binding usingconfigured runtime type definitions
- Support for standard DDS serialization encodings (e.g. XCDR1 and XCDR2)
- True zero-generation workflow with no dependency on DDS IDL generation
- Per-route DDS Quality of Service (QoS) configuration
- Pluggable DDS stack implementations via defined abstract interfaces,isolating DDS-stack-specific APIs from the DDS communication binding

Reference DDS Gateway
~~~~~~~~~~~~~~~~~~~~~

The DDS Gateway is the reference implementation for translating between
``mw::com (LoLa)`` and DDS.

It provides:

- Bridging between ``mw::com (LoLa)`` and DDS:
- ``mw::com (LoLa)`` → DDS GW → ``mw::com (LoLa)``
- ``mw::com (LoLa)`` → DDS GW → DDS applications
- DDS applications → DDS GW → ``mw::com (LoLa)``

- End-to-End (E2E) protection:
- The translation layer performs generation and validation of Counter, CRC, and DataID
- Independent of the underlying DDS stack implementation

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we detail more the intention about E2E/Code-Generation/Overlay-Protocol? For me it looks like here are some implicit assumptions made, but I'd like them to be explicit so I can check for consistency.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed. The previous text left some assumptions implicit.

The intended model is that E2E processing is owned by the Gateway Component
and remains independent of the selected DDS stack implementation.

Runtime type information associated with the configured communication route is
used for serialization, deserialization, and E2E generation/validation.

The DDS Communication Component is responsible for DDS communication and
transports serialized payloads, while interpretation and validation of E2E
information remain within the Gateway Component.

I updated the Feature Request to make these responsibilities explicit and
added a high-level data-flow diagram showing the interaction between runtime
type handling, E2E processing, serialization, and DDS communication.

- Validation and protection configurable per route

- Execution and performance model:

- Asynchronous processing using internal worker queues
- Support for configurable priority-based routing
- High-priority routes can be processed with dedicated queues and worker pools
- Normal-priority routes are handled via standard processing queues


Motivation
----------

S-CORE currently focuses on local communication via ``mw::com (LoLa)`` but does
not provide a standardized mechanism for inter-ECU communication using DDS-based
systems.

In mixed middleware environments:

- ``mw::com`` does not provide a standardized DDS communication binding
- Different projects implement DDS integration using project-specific solutions
- Integration with DDS requires project-specific bindings or adapters
- Applications may need to embed DDS-specific logic, reducing abstraction
- Communication with native DDS applications is not standardized
- Inter-ECU communication between ``mw::com`` participants via DDS is not standardized
- Multi-domain DDS deployments are difficult to configure consistently


This feature addresses these challenges by introducing a reusable DDS
communication binding beneath ``mw::com`` together with a reference DDS
Gateway implementation.

The DDS binding provides standardized DDS communication for ``mw::com``
applications, while the reference gateway demonstrates one possible approach
for translating between local ``mw::com (LoLa)`` communication and DDS-based
communication.

Key Value
---------

- Standardized DDS communication support through an ``mw::com`` binding
- Reference DDS Gateway implementation for ``mw::com (LoLa)`` to DDS translation
- Supports multiple integration concepts through a common DDS communication layer
- DDS-stack-independent runtime type handling through a common abstraction layer
- Direct interoperability with native DDS applications
- Standardized inter-ECU communication between ``mw::com`` participants via DDS

- Performance and determinism:

- Low-latency processing for high-priority data flows
- Controlled execution via configurable worker queues
- Predictable behavior for mixed criticality communication

- Interoperability across heterogeneous systems:

- Enables communication between systems with different architectures
(e.g., 32-bit / 64-bit, different endianness)
- Ensures consistent data representation via Dynamic Type handling

- End-to-End (E2E) protection:
- The translation layer performs generation and validation of Counter, CRC, and DataID
- Independent of the underlying DDS stack implementation
- Validation and protection configurable per route

Reference
---------

The detailed Feature Request is available here:

- DDS Gateway Feature Request: https://github.com/eclipse-score/score/issues/2726
Loading