From 57bb4a55720a2f7150035c55a2d5216d984f28b4 Mon Sep 17 00:00:00 2001 From: Abhishek GOYAL Date: Thu, 18 Jun 2026 12:41:50 +0200 Subject: [PATCH 01/12] Feature Request for DDS Gateway --- .../communication/dds_gateway/index.rst | 178 ++++++++++++++++++ 1 file changed, 178 insertions(+) create mode 100644 docs/features/communication/dds_gateway/index.rst diff --git a/docs/features/communication/dds_gateway/index.rst b/docs/features/communication/dds_gateway/index.rst new file mode 100644 index 00000000000..a47b4f77743 --- /dev/null +++ b/docs/features/communication/dds_gateway/index.rst @@ -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 + - Support for DDS domain-based routing + +- Dynamic Type handling: + + - Runtime type definition via configuration or via dynamic library + - No dependency on DDS IDL generation + - 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 + +- DDS stack abstraction: + + - Pluggable DDS implementations via defined interfaces + +- 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 From b23b40596db9989bf708d30aae0609177c04cb3a Mon Sep 17 00:00:00 2001 From: Abhishek GOYAL Date: Thu, 25 Jun 2026 17:58:38 +0200 Subject: [PATCH 02/12] Revise DDS Gateway documentation for clarity and detail Update PR gainst https://github.com/eclipse-score/score/pull/2997#discussion_r3451771277 Signed-off-by: Abhishek GOYAL --- .../communication/dds_gateway/index.rst | 179 +++++++++++++----- 1 file changed, 128 insertions(+), 51 deletions(-) diff --git a/docs/features/communication/dds_gateway/index.rst b/docs/features/communication/dds_gateway/index.rst index a47b4f77743..4a1ff3d9506 100644 --- a/docs/features/communication/dds_gateway/index.rst +++ b/docs/features/communication/dds_gateway/index.rst @@ -12,8 +12,8 @@ # SPDX-License-Identifier: Apache-2.0 # ******************************************************************************* -DDS Gateway -=========== +DDS Binding and Gateway +======================= .. document:: DDS-Gateway :id: doc__dds_gateway @@ -26,18 +26,75 @@ DDS Gateway Overview -------- +This feature introduces DDS communication support for ``mw::com`` and a +reference DDS Gateway implementation. -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. +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 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. + +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 and service +definition. 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 | + | beneath mw::com | | beneath mw::com | + +----------+----------+ +----------+----------+ + | ^ + | DDS | DDS + v | + =================== DDS NETWORK =================== + +The DDS binding provides the DDS communication layer beneath ``mw::com``. +It is responsible for runtime type handling, creation of DDS communication +entities, conversion between ``mw::com`` samples and DDS data representation, +DDS routing, QoS configuration, and interaction with the underlying DDS stack. + +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. :: @@ -71,60 +128,74 @@ communication between ``mw::com`` participants via DDS transport. | (optional) | +---------------------+ +The reference DDS Gateway is implemented using the DDS communication binding +beneath ``mw::com``. The gateway focuses on translation between local +``mw::com (LoLa)`` communication and DDS communication while reusing the +common DDS communication layer. + +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 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 - +- 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 ----- -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)`` +This feature provides: + +DDS Communication Binding +~~~~~~~~~~~~~~~~~~~~~~~~~ -- Configurable routing: +The DDS communication binding provides DDS communication beneath ``mw::com``. - - Mapping between ``mw::com`` events(TBD for fields and methods) and DDS topics - - Support for DDS domain-based routing +It provides: -- Dynamic Type handling: +- Communication between ``mw::com`` applications over DDS using the standard + ``mw::com`` programming model +- Mapping between ``mw::com`` events (TBD for fields and methods) and DDS topics +- Support for DDS domain-based routing +- Runtime type definition via configuration (e.g. JSON) or dynamic library +- Runtime creation of DDS entities (Topics, DataReaders, and DataWriters) +- True Zero-generation workflow with no dependency on DDS IDL generation +- Conversion between ``mw::com`` raw memory samples and the DDS runtime data representation +- Serialization and deserialization using the underlying DDS stack +- Support for DDS standard encodings (e.g., XCDR1 and XCDR2) +- Per-route DDS Quality of Service (QoS) configuration +- Pluggable DDS stack implementations via defined abstract interfaces - - Runtime type definition via configuration or via dynamic library - - No dependency on DDS IDL generation - - Enables data translation and consistent serialization across middleware boundaries - - Supports DDS standard encodings (e.g., XCDR1 and XCDR2) for interoperability +Reference DDS Gateway +~~~~~~~~~~~~~~~~~~~~~ -- End-to-End (E2E) protection: +The DDS Gateway is the reference implementation for translating between +``mw::com (LoLa)`` and DDS. - - Centralized handling of Counter, CRC, and DataID - - Validation and protection configurable per route +It provides: -- DDS stack abstraction: +- 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)`` - - Pluggable DDS implementations via defined interfaces +- Centralized End-to-End (E2E) protection - 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 + - High-priority routes can be processed with dedicated queues and worker pools - 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 ---------- @@ -135,26 +206,32 @@ systems. In mixed middleware environments: -- Integration with DDS requires custom adapters -- Applications may need to embed DDS logic, reducing abstraction +- ``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 setups are difficult to manage consistently +- 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 Gateway addresses these challenges by introducing a centralized, -configurable component responsible for bridging and routing communication -across middleware boundaries. +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 integration with DDS systems -- Direct interoperability with native DDS applications via the gateway +- 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 +- Direct interoperability with native DDS applications - 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: @@ -175,4 +252,4 @@ Reference The detailed Feature Request is available here: -- DDS Gateway Feature Request:https://github.com/eclipse-score/score/issues/2726 +- DDS Gateway Feature Request: https://github.com/eclipse-score/score/issues/2726 From 5c9e3f4d62d907194c4f56bd6cc6e57dcc4d05b5 Mon Sep 17 00:00:00 2001 From: Abhishek GOYAL Date: Thu, 25 Jun 2026 18:33:55 +0200 Subject: [PATCH 03/12] Clarify End-to-End (E2E) protection details Signed-off-by: Abhishek GOYAL --- docs/features/communication/dds_gateway/index.rst | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/docs/features/communication/dds_gateway/index.rst b/docs/features/communication/dds_gateway/index.rst index 4a1ff3d9506..81b228ca74a 100644 --- a/docs/features/communication/dds_gateway/index.rst +++ b/docs/features/communication/dds_gateway/index.rst @@ -187,7 +187,10 @@ It provides: - ``mw::com (LoLa)`` → DDS GW → DDS applications - DDS applications → DDS GW → ``mw::com (LoLa)`` -- Centralized End-to-End (E2E) protection +- 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 - Execution and performance model: @@ -245,7 +248,10 @@ Key Value (e.g., 32-bit / 64-bit, different endianness) - Ensures consistent data representation via Dynamic Type handling -- Centralized handling of safety (E2E) and type management +- 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 --------- From 988cef5e0f1a23c61169b20c8a78bc65d9df9004 Mon Sep 17 00:00:00 2001 From: Abhishek GOYAL Date: Fri, 26 Jun 2026 10:11:43 +0200 Subject: [PATCH 04/12] Improve DDS binding and reference gateway documentation 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 --- .../communication/dds_gateway/index.rst | 39 ++++++++++++------- 1 file changed, 24 insertions(+), 15 deletions(-) diff --git a/docs/features/communication/dds_gateway/index.rst b/docs/features/communication/dds_gateway/index.rst index 81b228ca74a..9e06be7abad 100644 --- a/docs/features/communication/dds_gateway/index.rst +++ b/docs/features/communication/dds_gateway/index.rst @@ -78,9 +78,10 @@ DDS APIs, but its communication is transported over the DDS network. =================== DDS NETWORK =================== The DDS binding provides the DDS communication layer beneath ``mw::com``. -It is responsible for runtime type handling, creation of DDS communication -entities, conversion between ``mw::com`` samples and DDS data representation, -DDS routing, QoS configuration, and interaction with the underlying DDS stack. +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. Applications continue to use the standard ``mw::com`` programming model, while the selected binding transports the data over DDS. @@ -128,11 +129,6 @@ locally, while the gateway performs the translation and routing to DDS. | (optional) | +---------------------+ -The reference DDS Gateway is implemented using the DDS communication binding -beneath ``mw::com``. The gateway focuses on translation between local -``mw::com (LoLa)`` communication and DDS communication while reusing the -common DDS communication layer. - 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. @@ -163,14 +159,26 @@ It provides: - Communication between ``mw::com`` applications over DDS using the standard ``mw::com`` programming model -- Mapping between ``mw::com`` events (TBD for fields and methods) and DDS topics -- Support for DDS domain-based routing + +- 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 + +- 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) -- True Zero-generation workflow with no dependency on DDS IDL generation -- Conversion between ``mw::com`` raw memory samples and the DDS runtime data representation -- Serialization and deserialization using the underlying DDS stack -- Support for DDS standard encodings (e.g., XCDR1 and XCDR2) +- 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 using +configured 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 @@ -233,6 +241,7 @@ 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 From eac818d3fa14355e4ee18b21deebcdd33774381b Mon Sep 17 00:00:00 2001 From: Abhishek GOYAL Date: Fri, 26 Jun 2026 10:19:08 +0200 Subject: [PATCH 05/12] Enhance DDS Gateway documentation with Topic details Add explanation of DDS Topics and their role in communication. Signed-off-by: Abhishek GOYAL --- docs/features/communication/dds_gateway/index.rst | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/docs/features/communication/dds_gateway/index.rst b/docs/features/communication/dds_gateway/index.rst index 9e06be7abad..3a6098867e5 100644 --- a/docs/features/communication/dds_gateway/index.rst +++ b/docs/features/communication/dds_gateway/index.rst @@ -83,6 +83,12 @@ 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. +In DDS, a Topic represents a named communication channel associated with a +specific data type.The DDS binding maps ``mw::com`` events to DDS Topics and creates the +required DDS Topics, DataReaders and DataWriters from the deployment +configuration. 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 From c2e63f6339070fbd0bc03332095e3a0bf4d94b80 Mon Sep 17 00:00:00 2001 From: Abhishek GOYAL Date: Fri, 26 Jun 2026 10:23:54 +0200 Subject: [PATCH 06/12] Update DDS stack implementation description Clarified the description of pluggable DDS stack implementations. Signed-off-by: Abhishek GOYAL --- docs/features/communication/dds_gateway/index.rst | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/features/communication/dds_gateway/index.rst b/docs/features/communication/dds_gateway/index.rst index 3a6098867e5..b0f56b66824 100644 --- a/docs/features/communication/dds_gateway/index.rst +++ b/docs/features/communication/dds_gateway/index.rst @@ -186,7 +186,8 @@ configured 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 +- Pluggable DDS stack implementations via defined abstract interfaces, + isolating DDS-stack-specific APIs from the DDS communication binding Reference DDS Gateway ~~~~~~~~~~~~~~~~~~~~~ From 8d27006ba01fa45d11c28e742c03789959462e67 Mon Sep 17 00:00:00 2001 From: Abhishek GOYAL Date: Fri, 26 Jun 2026 11:06:18 +0200 Subject: [PATCH 07/12] Refactor DDS Binding section in documentation Removed redundant text in DDS Binding section. Signed-off-by: Abhishek GOYAL --- docs/features/communication/dds_gateway/index.rst | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/docs/features/communication/dds_gateway/index.rst b/docs/features/communication/dds_gateway/index.rst index b0f56b66824..61e8ae81591 100644 --- a/docs/features/communication/dds_gateway/index.rst +++ b/docs/features/communication/dds_gateway/index.rst @@ -70,8 +70,7 @@ DDS APIs, but its communication is transported over the DDS network. v | +---------------------+ +---------------------+ | DDS Binding | | DDS Binding | - | beneath mw::com | | beneath mw::com | - +----------+----------+ +----------+----------+ + +----------+----------+ +----------+----------+ | ^ | DDS | DDS v | From a66e598a0375c9255683762d7140cf0af4d39183 Mon Sep 17 00:00:00 2001 From: Abhishek GOYAL Date: Fri, 26 Jun 2026 11:12:50 +0200 Subject: [PATCH 08/12] Improve clarity in DDS Gateway documentation Refactor text for clarity and formatting consistency in DDS Gateway documentation. Signed-off-by: Abhishek GOYAL --- .../features/communication/dds_gateway/index.rst | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/docs/features/communication/dds_gateway/index.rst b/docs/features/communication/dds_gateway/index.rst index 61e8ae81591..c7379df5c25 100644 --- a/docs/features/communication/dds_gateway/index.rst +++ b/docs/features/communication/dds_gateway/index.rst @@ -50,10 +50,9 @@ The DDS feature supports two integration concepts: Direct DDS Binding Concept ~~~~~~~~~~~~~~~~~~~~~~~~~~ -In this concept, an application uses the regular ``mw::com`` API and service -definition. 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. +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. :: @@ -82,11 +81,12 @@ 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.The DDS binding maps ``mw::com`` events to DDS Topics and creates the -required DDS Topics, DataReaders and DataWriters from the deployment -configuration. DDS Domains provide communication isolation and may be used to separate -communication routes (for example, QM and ASIL communication). +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. From dfe286cd68df50f5a287fdb5da65ee4b40688ef9 Mon Sep 17 00:00:00 2001 From: Abhishek GOYAL Date: Fri, 26 Jun 2026 11:32:54 +0200 Subject: [PATCH 09/12] Fix formatting in DDS Gateway index.rst Removed extra line break in DDS Gateway documentation. Signed-off-by: Abhishek GOYAL --- docs/features/communication/dds_gateway/index.rst | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/docs/features/communication/dds_gateway/index.rst b/docs/features/communication/dds_gateway/index.rst index c7379df5c25..2e5a780de39 100644 --- a/docs/features/communication/dds_gateway/index.rst +++ b/docs/features/communication/dds_gateway/index.rst @@ -185,8 +185,7 @@ configured 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 +- Pluggable DDS stack implementations via defined abstract interfaces,isolating DDS-stack-specific APIs from the DDS communication binding Reference DDS Gateway ~~~~~~~~~~~~~~~~~~~~~ From 13fe00a9b6e13411c3ce8b9996ca1bc10b11c972 Mon Sep 17 00:00:00 2001 From: Abhishek GOYAL Date: Fri, 26 Jun 2026 11:34:59 +0200 Subject: [PATCH 10/12] Fix formatting issue Signed-off-by: Abhishek GOYAL --- docs/features/communication/dds_gateway/index.rst | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/docs/features/communication/dds_gateway/index.rst b/docs/features/communication/dds_gateway/index.rst index 2e5a780de39..5a1ea559d64 100644 --- a/docs/features/communication/dds_gateway/index.rst +++ b/docs/features/communication/dds_gateway/index.rst @@ -178,10 +178,8 @@ It provides: - 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 using -configured runtime type definitions +- 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 From 128b24aad85bec4ed84bc8c05f8e5a3548379d1e Mon Sep 17 00:00:00 2001 From: Abhishek GOYAL Date: Wed, 15 Jul 2026 17:40:41 +0200 Subject: [PATCH 11/12] Enhance DDS Gateway documentation with detailed explanations Expanded the explanation of the DDS Gateway's functionality, including its role in translating between local mw::com communication and DDS-based communication, and detailed the service availability propagation process. Signed-off-by: Abhishek GOYAL --- .../communication/dds_gateway/index.rst | 285 ++++++++++++++++-- 1 file changed, 262 insertions(+), 23 deletions(-) diff --git a/docs/features/communication/dds_gateway/index.rst b/docs/features/communication/dds_gateway/index.rst index 5a1ea559d64..3c639e9bdf2 100644 --- a/docs/features/communication/dds_gateway/index.rst +++ b/docs/features/communication/dds_gateway/index.rst @@ -134,21 +134,55 @@ locally, while the gateway performs the translation and routing to DDS. | (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. +The DDS Gateway is a reference deployment concept for translating between +local ``mw::com (LoLa)`` communication and DDS-based communication. -Each DDS Gateway instance connects to: +A gateway deployment may separate the functionality responsible for local +``mw::com`` interaction from the functionality responsible for DDS stack +interaction. -- 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) + +-------------------------+ + | Local mw::com | + | Applications | + +------------+------------+ + | + | mw::com (LoLa) + v + +--------------------------------------------+ + | Gateway Component | + | | + | - Local service model | + | - Runtime type handling | + | - Runtime Serialization / Deserialization | + | - E2E processing | + +------------+-------------------------------+ + | + | IPC + v + +--------------------------------+ + | DDS Communication | + | Component | + | | + | - DDS discovery | + | - DDS Topics | + | - DDS QoS | + | - DDS Stack interaction | + | - DDS publication and | + | subscription of serialized | + | payloads | + +------------+-------------------+ + | + | DDS + v + ================== + DDS NETWORK + ================== + +This separation allows deployments where DDS stack interaction is isolated +from local application interaction while preserving the standard +``mw::com (LoLa)`` programming model for local applications. Scope ----- @@ -172,16 +206,24 @@ It provides: - 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 - +- DDS endpoint and service discovery: + - Standard DDS discovery mechanisms are used to discover matching + DDS endpoints. + - Service availability is derived from the DDS endpoints associated + with a configured service instance. + - DDS endpoint availability is mapped to the corresponding + ``mw::com`` availability model. + - Availability changes resulting from DDS participant join, leave, + restart, or recovery are propagated through the ``mw::com`` availability model. - 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 +- No dependency on DDS-stack-specific IDL-generated application interfaces +- Runtime type definitions and E2E-related configuration may be generated + or manually maintained as part of the deployment configuration - 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 @@ -198,10 +240,211 @@ It provides: - ``mw::com (LoLa)`` → DDS GW → DDS applications - DDS applications → DDS GW → ``mw::com (LoLa)`` +- Service availability propagation: + + - DDS endpoint discovery is performed by ``DDS Communication Component`` for the DDS Topics + associated with a configured service route. + + - The gateway configuration maps the discovered DDS Topics and endpoints to + the events of the corresponding ``mw::com`` service instance. + + - Service availability is derived from the configured DDS Topics associated + with the service instance. + + - Once the endpoints required for all configured DDS Topics are available, + ``DDS Communication Component`` exposes the corresponding inter-daemon route to ``Gateway Component``. + + - ``Gateway Component`` offers the corresponding local ``mw::com`` service only after + the inter-daemon route and the required DDS communication path are + available. + + - Loss of a required DDS endpoint causes ``DDS Communication Component`` to withdraw the + inter-daemon route. ``Gateway Component`` then withdraws the corresponding local + ``mw::com`` service availability. + + - Availability is restored automatically when the required DDS endpoints + and the inter-daemon communication route become available again. + +:: + + +------------------------------------------------------------+ + | DDS NETWORK | + +------------------------------------------------------------+ + | | | + | Topic A | Topic B | Topic C + | discovered | discovered | discovered + v v v + + +------------------------------------------------------------+ + | DDS Communication Component | + | | + | DDS endpoint discovery | + | Topic-to-service mapping | + | | + | All configured service events available? | + +--------------------------+---------------------------------+ + | + | Yes + | + | Offer inter-daemon route + v + + ==================== mw::com (LoLa IPC) ===================== + + +------------------------------------------------------------+ + | Gateway Component | + | | + | Discover inter-daemon route | + | Establish event subscriptions | + | | + | Offer local mw::com service | + +--------------------------+---------------------------------+ + | + | + v + + +------------------------------------------------------------+ + | Local mw::com Application | + +------------------------------------------------------------+ + + Availability loss propagates in the reverse direction: + + DDS endpoint lost + -> DDS Communication Component withdraws route + -> Gateway Component StopOfferService() + -> local service unavailable - 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 + + - E2E protection is implemented by the gateway translation layer and is + independent of the selected DDS stack implementation. + + - E2E generation and validation are performed by ``Gateway Component``. + ``DDS Communication Component`` and the DDS stack transport the resulting payload without + interpreting the E2E protection information. + + - E2E protection is configurable per communication route. + + - Routes may be configured with or without E2E protection according to + deployment requirements. + + - E2E protection information, including Counter, CRC, and DataID related + information, is associated with the application payload representation used for translation and is independent of DDS or RTPS transport headers. + + - The E2E representation is defined through configuration associated with + the runtime type description of the mapped ``mw::com`` event and DDS Topic. + + - Runtime type information may be provided through configuration or a + dynamically loaded type description. + + - No DDS-stack-specific IDL generated application interfaces are required + for E2E processing. + +- For outgoing communication: + + - ``Gateway Component`` reads the sample using the configured runtime type. + + - ``Gateway Component`` updates Counter, CRC, DataID and other configured + E2E elements. + + - ``Gateway Component`` serializes the payload using the configured runtime + type representation. + + - The serialized payload is forwarded to the + ``DDS Communication Component``. + + - The ``DDS Communication Component`` publishes the serialized payload + through the DDS stack. + +- For incoming communication: + + - The ``DDS Communication Component`` receives the serialized DDS payload. + + - The serialized payload is forwarded to the + ``Gateway Component``. + + - ``Gateway Component`` performs deserialization using the configured + runtime type representation. + + - ``Gateway Component`` validates the configured E2E information before + delivering the sample to the local application. + + - Samples failing E2E validation are handled according to the configured + route policy. + +:: + + Outgoing direction + + +----------------------------+ + | Local mw::com Sample | + +-------------+--------------+ + | + v + +----------------------------+ + | Gateway Component | + | | + | Runtime type handling | + | Update Counter | + | Update CRC | + | Update DataID | + | Serialize payload | + +-------------+--------------+ + | + | Serialized payload + v + + ================= LoLa IPC ================= + + | + v + + +-------------------------------+ + | DDS Communication Component | + | | + | DDS discovery | + | DDS Topics | + | DDS write_cdr() | + +-------------+-----------------+ + | + v + + DDS NETWORK + + + Incoming direction + + DDS NETWORK + | + v + + +-------------------------------+ + | DDS Communication Component | + | | + | DDS read_cdr() | + +-------------+-----------------+ + | + | Serialized payload + v + + ================= LoLa IPC ================= + + | + v + + +----------------------------+ + | Gateway Component | + | | + | Deserialize payload | + | Validate Counter | + | Validate CRC | + | Validate DataID | + +-------------+--------------+ + | + v + + +----------------------------+ + | Local mw::com Sample | + +----------------------------+ - Execution and performance model: @@ -260,10 +503,6 @@ Key Value (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 --------- From 67f446355e67507b4b73e8c6e32378be0b2785bb Mon Sep 17 00:00:00 2001 From: Abhishek GOYAL Date: Wed, 15 Jul 2026 19:37:11 +0200 Subject: [PATCH 12/12] Update DDS communication component terminology Signed-off-by: Abhishek GOYAL --- docs/features/communication/dds_gateway/index.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/features/communication/dds_gateway/index.rst b/docs/features/communication/dds_gateway/index.rst index 3c639e9bdf2..5231c519522 100644 --- a/docs/features/communication/dds_gateway/index.rst +++ b/docs/features/communication/dds_gateway/index.rst @@ -403,7 +403,7 @@ It provides: | | | DDS discovery | | DDS Topics | - | DDS write_cdr() | + | DDS serialized data sending | +-------------+-----------------+ | v @@ -420,7 +420,7 @@ It provides: +-------------------------------+ | DDS Communication Component | | | - | DDS read_cdr() | + | DDS serialized Data receiving | +-------------+-----------------+ | | Serialized payload