Feature Request for DDS Gateway by Abhishek2581 · Pull Request #2997 · eclipse-score/score

Abhishek2581 · 2026-06-18T10:45:21Z

DDS Gateway: Recreated PR following accidental merge/closure of the previous PR. No functional changes beyond the requested modifications.

github-actions · 2026-06-18T10:50:29Z

The created documentation from the pull request is available at: docu-html

LittleHuba

Blocking this PR formally until agreement is achieved in Communication FT.

LittleHuba · 2026-06-22T11:16:40Z

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

How a translation from intra-ecu to inter-ecu communication is integrated in the system is very much up to the integrator.

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).

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.

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.

LittleHuba · 2026-06-22T11:18:19Z

+- End-to-End (E2E) protection:
+
+  - Centralized handling of Counter, CRC, and DataID
+  - Validation and protection configurable per route


E2E protection handling might be impossible to achieve in a centralized handling. In some of our supported operating systems the network stack is not qualified.
The SOME/IP gateway works around this with a split of the "gateway process" into a QM and an ASIL-B part.

I'm not aware that a DDS-library with a split which enables the E2E-protection running in one process and the network handling running in another process exists. AFAIK CycloneDDS does not have that split.

But I agree that we want something like that in order to enable a usage of DDS in ASIL-scenarios.

I'm not aware that a DDS-library with a split which enables the E2E-protection running in one process and the network handling running in another process exists. AFAIK CycloneDDS does not have that split.

But I agree that we want something like that in order to enable a usage of DDS in ASIL-scenarios.

Good point.

The intention is not to require the DDS stack itself to implement or be aware of E2E protection.

Our current direction is that the DDS stack remains responsible only for transporting the payload, while the Gateway (or another ASIL component built on top of the DDS binding) performs the E2E protection and validation. Since the gateway uses runtime type information, it can insert and validate the E2E information within the payload before handing it to the DDS stack and after receiving it.

We will update the FR to clarify that E2E handling is performed by the translation layer rather than implying it is part of the DDS stack or a centralized network component.

I'm not aware that a DDS-library with a split which enables the E2E-protection running in one process and the network handling running in another process exists. AFAIK CycloneDDS does not have that split.

But I agree that we want something like that in order to enable a usage of DDS in ASIL-scenarios.

Agreed.

The intention is not to rely on a DDS implementation providing a QM/ASIL split internally. Instead, the DDS stack is considered the transport layer, while E2E handling is performed by the translation layer built on top of the DDS binding.

This keeps the E2E logic independent of the underlying DDS implementation and avoids requiring a specific DDS stack architecture.

We'll clarify this in the FR so it does not imply that such a split already exists within current DDS implementations.

LittleHuba · 2026-06-22T11:21:45Z

+
+- Configurable routing:
+
+  - Mapping between ``mw::com`` events(TBD for fields and methods) and DDS topics


I'd be interested in more detail on this mapping.
What are the supported mapping cases? What are the corner cases where support is not provided?
It is hard to judge feasibility without further details.

Maybe one of the first decisions is whether we want to provide the service-grouping also to DDS and which kind of service discovery we want to do in this case. Or more specific do we want to communicate with AUTOSAR-stacks over DDS?

Good point.

The initial scope is intentionally focused on configuration-driven event communication.

The supported mapping cases are:

One mw::com event is mapped to one DDS Topic.

DDS Topic data is mapped back to the corresponding mw::com event.

The DDS binding creates the corresponding DDS Topic, DataReader and DataWriter from deployment configuration.

Runtime type information is referenced from the deployment configuration through an external JSON type description.

DDS-specific attributes such as QoS policies and DDS Domain IDs are provided through DDS deployment configuration.

Standard DDS endpoint discovery is used to determine availability of configured communication endpoints and map this to the mw::com availability model.

Communication with native DDS applications is supported when the DDS topic, type, QoS and domain configuration match.

The corner cases / limitations for the initial scope are:

mw::com fields are not supported initially.

mw::com methods are not supported initially.

Automatic mapping without deployment configuration is not supported.

DDS deployment extensions for QoS, Domain IDs and type-description references still need detailed definition.

DDS Domain ID allocation strategy still needs detailed definition. For example, different DDS domains may be used to separate QM and ASIL communication routes.

I'll update the FR to clarify the supported event-to-topic mapping, the use of DDS discovery, and the current limitations/open architectural points.

LittleHuba · 2026-06-22T11:22:41Z

+- Configurable routing:
+
+  - Mapping between ``mw::com`` events(TBD for fields and methods) and DDS topics
+  - Support for DDS domain-based routing


Same here, please add more details / link to references.
I'm not a DDS expert so I need some more background to judge.

Good point. I've updated the FR to provide more details on the mapping and added a short architectural overview of DDS concepts (Topics, DataReaders/DataWriters, and Domains) so that the proposed integration can be understood without requiring detailed DDS knowledge.

LittleHuba · 2026-06-22T11:25:10Z

+
+- Dynamic Type handling:
+
+  - Runtime type definition via configuration or via dynamic library


This sounds like we have a huge overlap with the SOME/IP efforts. The format might differ, but the general task is the same. I'd like to see an investigation on how much we can reuse from the upcoming SOME/IP infrastructure.

We'll discuss this with the SOME/IP team to identify common infrastructure and reusable components. The goal is to align the DDS and SOME/IP approaches where possible while keeping middleware-specific functionality isolated behind their respective bindings.

LittleHuba · 2026-06-22T11:26:23Z

+
+- DDS stack abstraction:
+
+  - Pluggable DDS implementations via defined interfaces


Ideally this stack abstraction is mw::com (as highlighted in a previous comment)

Agreed. The architecture has been updated accordingly. The primary abstraction is now the DDS communication binding beneath mw::com, while the DDS Gateway is positioned as a reference implementation built on top of this binding. This enables alternative integration concepts to reuse the same mw::com binding without requiring an explicit gateway process.

JochenSatETAS · 2026-06-22T19:52:36Z

+- Dynamic Type handling:
+
+  - Runtime type definition via configuration or via dynamic library
+  - No dependency on DDS IDL generation


Typically a DDS-stack provides a type-safe API (for C++). This API is generated. I'm not aware that DDS-stacks maintain a stable API between the generated and non-generated parts. Maybe I missed something here, but we need to discuss this.

Good point. The intention is not to depend on vendor-specific DynamicData APIs provided by individual DDS implementations.

The DDS binding owns the runtime type handling as well as runtime serialization/deserialization based on the configured runtime type definitions. The underlying DDS stack is accessed through an abstract interface responsible for DDS communication, allowing different DDS implementations to provide their own adapter without exposing vendor-specific runtime type APIs to the binding.

I've updated the FR to reflect this architecture by moving runtime type handling and serialization/deserialization into the DDS binding and defining the DDS stack interaction through abstract interfaces.

Update PR gainst eclipse-score#2997 (comment) Signed-off-by: Abhishek GOYAL <abhishek.goyal@valeo.com>

Signed-off-by: Abhishek GOYAL <abhishek.goyal@valeo.com>

Enhanced the description of the DDS binding and its features, including runtime serialization, mapping, and QoS configuration. Updated the reference DDS Gateway implementation details and clarified the support for DDS domain-based routing and type handling. Signed-off-by: Abhishek GOYAL <abhishek.goyal@valeo.com>

Add explanation of DDS Topics and their role in communication. Signed-off-by: Abhishek GOYAL <abhishek.goyal@valeo.com>

Clarified the description of pluggable DDS stack implementations. Signed-off-by: Abhishek GOYAL <abhishek.goyal@valeo.com>

Feature Request for DDS Gateway

57bb4a5

Abhishek2581 requested review from arsibo and qor-lb as code owners June 18, 2026 10:45

github-project-automation Bot added this to TLC - Technical Lead Circle and S-CORE Roadmap Jun 18, 2026

github-project-automation Bot moved this to Backlog in S-CORE Roadmap Jun 18, 2026

Abhishek2581 mentioned this pull request Jun 18, 2026

DDS Gateway communication feature #2817

Merged

qor-lb added community:architecture feature_request ft:communication Feature Team Communication labels Jun 21, 2026

LittleHuba requested changes Jun 22, 2026

View reviewed changes

LittleHuba reviewed Jun 22, 2026

View reviewed changes

JochenSatETAS reviewed Jun 22, 2026

View reviewed changes

Abhishek2581 added 5 commits June 25, 2026 17:58

Revise DDS Gateway documentation for clarity and detail

b23b405

Update PR gainst eclipse-score#2997 (comment) Signed-off-by: Abhishek GOYAL <abhishek.goyal@valeo.com>

Clarify End-to-End (E2E) protection details

5c9e3f4

Signed-off-by: Abhishek GOYAL <abhishek.goyal@valeo.com>

Enhance DDS Gateway documentation with Topic details

eac818d

Add explanation of DDS Topics and their role in communication. Signed-off-by: Abhishek GOYAL <abhishek.goyal@valeo.com>

Update DDS stack implementation description

c2e63f6

Clarified the description of pluggable DDS stack implementations. Signed-off-by: Abhishek GOYAL <abhishek.goyal@valeo.com>


		- Configurable routing:

		- Mapping between ``mw::com`` events(TBD for fields and methods) and DDS topics


		- Dynamic Type handling:

		- Runtime type definition via configuration or via dynamic library


		- DDS stack abstraction:

		- Pluggable DDS implementations via defined interfaces

Uh oh!

Conversation

Abhishek2581 commented Jun 18, 2026

Uh oh!

github-actions Bot commented Jun 18, 2026

Uh oh!

LittleHuba left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Abhishek2581 Jun 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

JochenSatETAS Jun 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

JochenSatETAS Jun 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Abhishek2581 Jun 25, 2026 •

edited

Loading

JochenSatETAS Jun 22, 2026 •

edited

Loading

JochenSatETAS Jun 22, 2026 •

edited

Loading