DDS gateway

### 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 Architecture**The 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

- [x] Requirements
- [x] Architecture
- [x] Safety/Security Analysis
- [x] Detailed Design

### Impact analysis

NA

### Safety or Security relevance

- [ ] none
- [x] Safety relevant
- [x] Security relevant

### ASIL classification

ASIL_B

### Expected Implementation Version

1.0