Feature Request for DDS Gateway #2997
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,178 @@ | ||
| .. | ||
| # ******************************************************************************* | ||
| # 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 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 | ||
| -------- | ||
|
|
||
| The DDS Gateway introduces a communication bridge within the S-CORE communication stack. | ||
| It enables controlled and configurable data exchange between ``mw::com (LoLa)`` (intra-ECU | ||
| communication via IPC binding) and DDS-based systems (inter-ECU | ||
| communication), allowing integration with distributed DDS environments | ||
| while preserving existing application implementations. | ||
|
|
||
| Architecture Concept | ||
| -------------------- | ||
| The DDS Gateway acts as a centralized communication bridge between local | ||
| ``mw::com (LoLa)`` communication and DDS domains, enabling inter-ECU | ||
| communication between ``mw::com`` participants via DDS transport. | ||
|
|
||
| :: | ||
|
|
||
| ============================== ============================== | ||
| 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) | | ||
| +---------------------+ | ||
|
|
||
| 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 data in both directions between ``mw::com`` and DDS representations | ||
| - Routing data across DDS domains | ||
| - configure QOS on DDS for each route | ||
| - Applying E2E protection | ||
|
|
||
|
|
||
| Scope | ||
| ----- | ||
| The DDS Gateway provides: | ||
|
|
||
| - Bridging between ``mw::com (LoLa)`` and DDS via the gateway: | ||
| - ``mw::com (LoLa)`` → DDS GW → ``mw::com (LoLa)`` (inter-ECU communication via DDS) | ||
| - ``mw::com (LoLa)`` → DDS GW → DDS applications | ||
| - DDS applications → DDS GW → ``mw::com (LoLa)`` | ||
|
|
||
| - Configurable routing: | ||
|
|
||
| - Mapping between ``mw::com`` events(TBD for fields and methods) and DDS topics | ||
|
Contributor
There was a problem hiding this comment. I'd be interested in more detail on this mapping. There was a problem hiding this comment. 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?
Contributor
Author
There was a problem hiding this comment. Good point. The initial scope is intentionally focused on configuration-driven event communication. The supported mapping cases are:
The corner cases / limitations for the initial scope are:
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. |
||
| - Support for DDS domain-based routing | ||
|
Contributor
There was a problem hiding this comment. Same here, please add more details / link to references.
Contributor
Author
There was a problem hiding this comment. 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. |
||
|
|
||
|
There was a problem hiding this comment. How is the ServiceDiscovery done on the service-level?
Contributor
Author
There was a problem hiding this comment. DDS discovery operates at the Topic and endpoint level, whereas The gateway configuration defines the mapping between DDS Topics and the The DDS Communication Component monitors the discovery state of the configured Once the required DDS Topics become available, the Gateway Component offers To make this explicit, I added a service availability propagation section and |
||
| - Dynamic Type handling: | ||
|
|
||
| - Runtime type definition via configuration or via dynamic library | ||
|
Contributor
There was a problem hiding this comment. 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.
Contributor
Author
There was a problem hiding this comment. 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. |
||
| - No dependency on DDS IDL generation | ||
|
There was a problem hiding this comment. 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.
Contributor
Author
There was a problem hiding this comment. 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. |
||
| - Enables data translation and consistent serialization across middleware boundaries | ||
| - Supports DDS standard encodings (e.g., XCDR1 and XCDR2) for interoperability | ||
|
|
||
| - End-to-End (E2E) protection: | ||
|
|
||
| - Centralized handling of Counter, CRC, and DataID | ||
| - Validation and protection configurable per route | ||
|
Contributor
There was a problem hiding this comment. 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. There was a problem hiding this comment. 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.
Contributor
Author
There was a problem hiding this comment.
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.
Contributor
Author
There was a problem hiding this comment.
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. |
||
|
|
||
| - DDS stack abstraction: | ||
|
|
||
| - Pluggable DDS implementations via defined interfaces | ||
|
Contributor
There was a problem hiding this comment. Ideally this stack abstraction is mw::com (as highlighted in a previous comment)
Contributor
Author
There was a problem hiding this comment. Agreed. The architecture has been updated accordingly. The primary abstraction is now the DDS communication binding beneath |
||
|
|
||
| - 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 to achieve low-latency data delivery | ||
| - Normal-priority routes are handled via standard processing queues | ||
| - Priority configuration is defined per route | ||
|
|
||
| - DDS QoS configurability: | ||
|
|
||
| - Ability to configure DDS Quality of Service (QoS) policies per route | ||
| - Enables tuning of reliability, durability, and latency behavior based on use case | ||
|
|
||
| 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: | ||
|
|
||
| - Integration with DDS requires custom adapters | ||
| - Applications may need to embed DDS 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 setups are difficult to manage consistently | ||
|
|
||
|
|
||
| The DDS Gateway addresses these challenges by introducing a centralized, | ||
| configurable component responsible for bridging and routing communication | ||
| across middleware boundaries. | ||
|
|
||
| Key Value | ||
| --------- | ||
|
|
||
| - Standardized integration with DDS systems | ||
| - Direct interoperability with native DDS applications via the gateway | ||
| - Standardized inter-ECU communication between ``mw::com`` participants via DDS | ||
| - Clean separation between ``mw::com (LoLa)`` and DDS | ||
| - Reduced integration effort | ||
| - Support for distributed and multi-domain systems | ||
|
|
||
| - 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 | ||
|
|
||
| - Centralized handling of safety (E2E) and type management | ||
|
|
||
| Reference | ||
| --------- | ||
|
|
||
| The detailed Feature Request is available here: | ||
|
|
||
| - DDS Gateway Feature Request:https://github.com/eclipse-score/score/issues/2726 | ||
There was a problem hiding this comment.
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.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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:
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).