--- title: DDS & LET Middleware url: https://www.emergentmind.com/topics/middleware-dds-logical-execution-time type: topic --- # DDS & LET Middleware Middleware systems integrating Data Distribution Service (DDS) with Logical Execution Time (LET) present a paradigm for achieving deterministic, real-time communication in distributed cyber-physical environments. In the context of the Cyber-Physical Mobility Lab (CPM Lab), this architectural approach underpins a four-layered vehicular control stack, providing both horizontally scalable communications and globally synchronized execution across heterogeneous nodes. The design merges DDS's decentralized, low-latency publish–subscribe messaging and dynamic discovery with LET semantics, producing a system capable of bit-identical experiment reproducibility and hard real-time guarantees under dynamic network conditions [2004.10063]. ## 1. Four-Layer Middleware Architecture The CPM Lab’s control stack is organized into four logical layers: 1. **High-Level Controllers (HLC)**: Executed on Intel NUC hosts, responsible for centralized trajectory generation and networked decision logic. 2. **DDS-Based Middleware**: Deployed both on NUCs and per-vehicle Raspberry Pis, this layer ensures message transport, topic-based discovery, time synchronization, and LET enforcement. 3. **Mid-Level Controllers (MLC)**: Resident on each vehicle’s Raspberry Pi, these modules fuse sensor data, generate local decisions, and translate trajectories to control primitives. 4. **Low-Level Controllers (LLC)**: Implemented on ATmega2560 microcontrollers, these units effectuate direct actuation via torque and steering commands. All controllers interact via DDS Topics. Example topics include "FusedPose" (sensor-fusion outputs), "Trajectory[n]" (HLC-to-MLC setpoints), "ControlCmd[n]" (MLC-to-LLC actuation primitives), and "Heartbeat" (clock sync, liveness). The system enforces fine-grained QoS profiles per topic—for example, control streams employ RELIABLE reliability with DEADLINE matching the controller period and small LATENCY_BUDGETs (e.g., 5 ms) [2004.10063]. ## 2. Dynamic Participation through DDS DDS’s intrinsic participant discovery supports seamless adaptation to dynamic memberships. When an MLC—physical or simulated—joins the DDS Domain, it: - Announces its presence, - Matches existing readers/writers by topic and datatype, - Begins participating immediately, without static configuration. For HLCs, vehicle presence is inferred automatically by querying matched DataReaders. This enables the number of vehicles $N$ to vary transparently at runtime. User-level control code remains agnostic to these changes; logic remains invariant to additions or removals of vehicles. **Table: DDS Topic Mappings and Roles** | Topic | Publisher | Subscriber | |-----------------|-------------------|-------------------| | FusedPose | MLC (per vehicle) | HLC | | Trajectory[n] | HLC | MLC (vehicle $n$) | | ControlCmd[n] | MLC | LLC (vehicle $n$) | | Heartbeat | All nodes | All nodes | ## 3. Logical Execution Time Enforcement A periodic global time base underpins LET enforcement. Heartbeat messages exchanged at 100 Hz synchronize local clocks $t_{\mathrm{phys}}$ across all nodes. LET semantics are built atop this foundation: - **Logical Window**: For each cycle $k \in \mathbb{N}$, the window $[t_k, t_k + \Delta]$, with $t_k = k \cdot \Delta$ and $\Delta$ as the LET period (e.g., 100 ms). - **Physical to Logical Time Mapping**: $$ T_{\mathrm{log}}(t_{\mathrm{phys}}) = \left\lfloor \frac{t_{\mathrm{phys}}}{\Delta} \right\rfloor \Delta $$ - **Scheduling Constraint**: For each periodic task $i$, worst-case execution time $C_i$ must satisfy $C_i \leq \Delta_i = \Delta$. - **Deliver-At-Deadline Semantics**: Inputs are snapshot at window start $t_k$, tasks execute in parallel, outputs are held until $t_k + \Delta$, and finally published atomically. This distributed scheduling approach induces the illusion of instantaneous computation at the logical deadline. As a result, executions are deterministic, and repeated experimental runs yield bit-identical outputs, a crucial property for reproducibility in distributed cyber-physical systems. ## 4. Middleware Driver Algorithms and Configuration LET-enforced DDS operation on each node follows a uniform pattern: ```c initialize_DDS_domain(); global_clock = sync_via_heartbeat(); Δ = user_defined_period; // e.g. 100 ms loop forever: t_phys_now = global_clock.read(); k = floor(t_phys_now / Δ); t_window_start = k * Δ; t_window_end = t_window_start + Δ; // 1) Collect inputs from samples stamped ≥ t_window_start inputs = reader.read_all(stamp >= t_window_start); // 2) Trigger application logic outputs = application_task(inputs); // 3) Wait for the end of the tick sleep_until(t_window_end); // 4) Publish outputs atomically writer.write(outputs, stamp = t_window_end); // 5) Publish heartbeat (for clock synchronization) heartbeat_writer.write({node_id, t_window_end}); ``` LET period $\Delta$ and DDS parameters are distributed through configuration files (JSON) and DDS XML QoS profiles. The following illustrates configuration snippets: ```json { "let_period_ms": 100, "dds_domain_id": 42, "vehicle_id": 7 } ``` ```xml RELIABLE_RELIABILITY_QOS 0 100000000 0 5000000 BEST_EFFORT_RELIABILITY_QOS 0 100000000 ``` ## 5. Empirical Performance and Determinism Stress-testing CPM-Lab’s DDS+LET middleware with 18 vehicles at $\Delta = 100$ ms (using pure platoon controllers) demonstrated: - Worst-case end-to-end latency (HLC→LLC→HLC): 92 ms - One-sigma jitter on 100 ms tick: 1.3 ms across all nodes - No dropped windows across sustained 30-minute operation These observations confirm that the architecture reliably delivers hard-real-time, deterministic performance and supports scalable distributed experimentation [2004.10063]. ## 6. Significance and Research Context The CPM-Lab platform operationalizes a Giotto-style LET runtime alongside DDS’s decentralized publish–subscribe middleware. This fusion supports: - Arbitrary scaling of real/simulated vehicles without requiring code changes, - Deterministic data exchanges of control and sensor topics, - Infrastructure-independence between simulated and physical deployments. A plausible implication is that this methodology generalizes to other distributed cyber-physical systems requiring deterministic, real-time interactions with dynamic membership. The CPM-Lab provides an open research environment for exploring multi-agent control, trajectory planning, and networked decision-making under controlled, reproducible conditions [2004.10063]. Source: https://www.emergentmind.com/topics/middleware-dds-logical-execution-time