DDS gateway

[Abhishek2581]

Change Request Type

Feature Request

Description of the Change Request

Summary
We propose introducing a DDS Gateway as a new feature in the S-CORE communication stack.
The DDS Gateway enables seamless and configurable routing between mw::com-based communication (MWCom) and DDS domains, supporting both:

• MWCom <-> MWCom communication over DDS (via the gateway)
• MWCom <-> Native DDS applications

The DDS Gateway acts as a protocol bridge and routing layer that connects mw::com events, fields and Method to DDS topics and vice versa, enabling interoperability, scalability, and multi-domain communication without modifying existing applications.
The gateway introduces full Dynamic Type support, allowing DDS topic types to be created and handled at runtime without requiring static DDS IDL generation or compilation. This removes the need to maintain DDS IDL files for gateway-routed data and enables fully configuration-driven type handling.

The gateway also provides optional End-to-End (E2E) protection at the gateway boundary, allowing the GW to append and/or validate E2E metadata (e.g., Counter, CRC, DataID) on routed samples. This enables consistent integrity and sequence protection across MWCom <-> DDS and MWCom <-> MWCom-over-DDS routes without requiring every application to implement E2E logic.

Motivation
In modern distributed automotive systems, different communication technologies may coexist depending on system architecture, legacy components, or integration requirements. While S-CORE applications primarily interact through the mw::com API, certain system deployments may also rely on DDS-based communication infrastructures.
In such mixed communication environments, there is currently no standardized mechanism within S-CORE to bridge mw::com communication with DDS domains. As a result, integrating systems that rely on different middleware technologies requires custom integration approaches.
Without a dedicated gateway:

• Applications or integration components that need to interact with DDS systems may need to directly integrate DDS logic, which reduces the abstraction provided by the mw::com API.
• Multi-domain DDS deployments become harder to manage when the same logical data must be distributed across multiple DDS domains.
• Integration with DDS-native systems or external components requires custom adapters or modifications to existing communication components.
• System integrators may need to implement project-specific bridging solutions, which leads to duplicated effort and inconsistent implementations.
• Implementing End-to-End (E2E) protection across communication boundaries becomes complex if it must be handled independently by each communication component.

To address these challenges, a standardized bridging mechanism is required to enable controlled data exchange between mw::com communication and DDS domains while preserving the abstraction provided by the mw::com API.
The DDS Gateway addresses these needs by providing a centralized and configurable component responsible for routing data between mw::com and DDS, managing domain mappings, and applying optional mechanisms such as Dynamic Type handling and End-to-End (E2E) protection.

Proposed Solution

The DDS Gateway introduces a configurable routing engine between mw::com and DDS.

1. Config-Driven Routing ArchitectureThe gateway is configured via a JSON configuration that defines:- Data types

• Route definitions
• Domain mappings
• Resource limits

The configuration includes :

• dataTypes[]
• mwcomToDdsRoutes[]
• ddsToMwcomRoutes[]
• Optional limits (max_types, max_routes, max_fields_per_type, arena sizing, etc.)

The dataTypes[] section defines type structures dynamically within the gateway configuration.These types are compiled internally into DDS DynamicTypes at startup, eliminating the need for pre-generated DDS IDL or code generation on the DDS side.

The configuration also includes optional per-route E2E settings, enabling the gateway to apply and validate E2E protection in a configurable way (enable/disable, profile/parameters, DataID, acceptance window, and error-handling policy).

2. mw::com to DDS Routing
   The gateway:

• Subscribes to mw::com events
• Serializes the data using the internally compiled DynamicType
• Publishes to DDS topics in the configured DDS domain

The same MWCom event can intentionally be mapped to multiple DDS domain IDs (e.g., domain 0 and domain 1).
If E2E is enabled for the route, the gateway computes and attaches E2E metadata (e.g., Counter, CRC, DataID) before publishing to DDS. When using Dynamic Types, the gateway can encapsulate the original payload inside an E2E envelope that carries both the payload and the E2E metadata without requiring DDS IDL generation.

This enables:

• Isolation between participants
• Multi-domain system architectures
• Controlled data replication across domains
• Migration between DDS domains

3. DDS to MWCom Routing
   The gateway:

• Subscribes to DDS topics in a specific DDS domain
• Deserializes payloads using the internally generated DynamicType
• Publishes to mw::com events

If E2E is enabled for the route, the gateway validates E2E metadata on reception (CRC verification and counter progression checks). Invalid samples are handled according to configured policy (e.g., drop and report), and only valid data is forwarded to MWCom.

In this direction:

• Each DDS writer belongs to a unique DDS domain.
• Therefore, DDS-to-MWCom routes are mapped to a single DDS domain per route.

4 DDS Stack Abstraction
The gateway defines DDS stack interfaces that allow attaching different DDS implementations via a factory pattern at build time.
Architecture Outlines:

• Only one DDS stack can be attached at a time.
• The stack attachment is abstracted via defined interfaces and instantiated through a factory pattern.

This ensures:

• Vendor independence
• Future extensibility
• Clean separation between routing logic and middleware implementation

5 Dynamic Type Support
The DDS Gateway supports full Dynamic Type handling:

• Type definitions are provided in JSON configuration.
• Types are converted at runtime into DDS DynamicTypes.
• No DDS IDL files are required.
• No DDS code generation step is required.
  -No rebuild of DDS applications is required when types change (gateway-side only).

This enables:

• Runtime flexibility
• Simplified deployment
• Reduced tooling dependency
• Decoupling from DDS vendor-specific IDL toolchains
  The gateway becomes the single authority for type definition and serialization logic.

Key Benefits
1️ MWCom <-> DDS Interoperability
Enables communication between mw::com applications and native DDS applications without modifying either side.
2️ Multi-Domain Support
Allows mapping a single MWCom event to multiple DDS domains for isolation, scalability, and migration use cases.
3️ Controlled Migration Strategy
Supports:

• MWCom to DDS transition
• DDS to MWCom transition
• Coexistence architectures

4️ Configurable Routing Engine
All routing logic is defined declaratively via JSON configuration:

• Data types
• Domains
• Topics
• Instance specifiers
• Resource limits
  No code changes required for new routing scenarios.

5️ Resource Control & Deterministic Memory

• Static arena sizing based on max_serialized_size
• Configurable system limits
• Predictable memory behavior for safety-critical systems

6️ Vendor-Agnostic DDS Integration
Abstract DDS interfaces allow integration of different DDS stacks without changing gateway logic.

7️ Separation of Concerns
Applications remain pure:

• MWCom apps do not need DDS logic.
• DDS apps do not need MWCom logic.
• The gateway handles translation and routing.

8 IDL-Free Operation via Dynamic Types
Eliminates the need for DDS IDL generation and compilation.

All type definitions are configuration-driven and compiled into DDS DynamicTypes at runtime, simplifying integration and reducing development overhead.

9 E2E Safety & Data Integrity
Provides configurable E2E integrity and sequence protection (e.g., CRC and counter checks) across MWCom <-> DDS routes, supporting safety requirements while avoiding duplicated E2E implementations inside each application.

Additional Information

• Potential Enhancement :
  - Configurable QoS policies
  - Extended E2E capabilities (additional profiles), plus broader Security and Safety features (monitoring, reporting, compliance hooks)
  - Tracing and Error Handling support

Estimates for realization

TBD

Affects work products

• Requirements
• Architecture
• Safety/Security Analysis
• Detailed Design

Impact analysis

NA

Safety or Security relevance

• none
• Safety relevant
• Security relevant

ASIL classification

ASIL_B

Expected Implementation Version

1.0