--- title: "QUIC and ECS as Complementary Transport and Runtime Substrates for Industrial Digital Twins: An Integrated Empirical Study" title-running: "QUIC+ECS for Industrial Digital Twins" author-running: "Plantevin" author: "Valère Plantevin\\inst{1}\\orcidID{0000-0000-0000-0000}" institute: "Département d'informatique et de mathématiques, Université du Québec à Chicoutimi (UQAC), Chicoutimi, Canada\\\\ \\email{vplantev@uqac.ca}" abstract: | Industrial Digital Twin runtimes face a dual challenge: efficient in-process state management across heterogeneous asset populations, and low-latency transport of heterogeneous sensor streams with differing reliability requirements. We argue that these two challenges admit complementary structural solutions. The Entity-Component-System (ECS) architectural pattern constitutes a natural runtime substrate, providing cache-coherent bulk state updates, $O(k)$ archetype mutation for asset lifecycle events, and DAG-driven parallel system scheduling. QUIC's mixed-reliability multiplexing constitutes a natural transport substrate, mapping three DT sensor data tiers onto unreliable datagrams, unidirectional streams, and bidirectional streams respectively. We integrate both substrates into a single prototype and validate the combined system on an industrial Raspberry Pi CM5 (Cortex-A76) receiving real QUIC traffic from a dedicated traffic generator. An empirical sweep across 50k--200k asset instances and 0--5\% packet loss confirms that ECS tick rate remains stable under network loss, that cross-tier head-of-line blocking isolation holds end-to-end through both the QUIC transport layer and the ECS ingest layer, and that memory scales linearly at less than 0.2~MB per 1{,}000 entities on target edge hardware. Finally, the prototype functions as an active edge controller rather than a passive telemetry pipeline, executing end-to-end closed-loop actuation triggered directly from a standard Grafana observability dashboard. keywords: - digital twin - entity-component-system - QUIC - industrial IoT - real-time transport - edge computing bibliography: references.bib --- ```{python} #| label: setup #| include: false import pandas as pd import matplotlib.pyplot as plt import matplotlib.ticker as mticker import numpy as np from pathlib import Path # Paths relative to paper/ DATA_TWO_MACHINE = Path("../data/two_machine") DATA_LOCAL = Path("../data/local") FIGURES = Path("figures") FIGURES.mkdir(exist_ok=True) # Load sweep CSVs when they exist; provide empty defaults otherwise def load_csv(path: Path) -> pd.DataFrame: if path.exists(): return pd.read_csv(path) return pd.DataFrame() # CM5 sweep (M4 Max generator → CM5 substrate, 1 Gbps direct Ethernet). # Holds both per-tier latency and per-entity-count throughput / RSS. # The 10k-entity rows are dropped as warmup: their per-connection clock-offset # baseline differs from the larger sweeps by ~18 ms, dominating the loss signal. df_sweep = load_csv(DATA_TWO_MACHINE / "final_table.csv") if len(df_sweep): df_sweep = df_sweep.query("entities >= 50000").reset_index(drop=True) df_latency = df_sweep df_throughput = df_sweep # Cross-tier isolation sweep (local; T1 rate swept, T3 held at 100 Hz). df_isolation = load_csv(DATA_LOCAL / "cross_tier.csv") # Key scalars used inline in the prose. hz_at_100k_0pct = float( df_throughput.query("entities == 100000 and loss_pct == 0")["hz"].iloc[0] ) hz_at_100k_5pct = float( df_throughput.query("entities == 100000 and loss_pct == 5")["hz"].iloc[0] ) rss_at_100k = float( df_throughput.query("entities == 100000 and loss_pct == 0")["rss_mb"].iloc[0] ) # Memory R² — linear regression of mean RSS vs entity count on the CM5 sweep. _rss_by_n = df_throughput.groupby("entities")["rss_mb"].mean().sort_index() _x = _rss_by_n.index.values.astype(float) _y = _rss_by_n.values.astype(float) r2_memory = float(np.corrcoef(_x, _y)[0, 1] ** 2) # MB per 1k entities, slope of the linear fit _slope_mb_per_entity, _intercept = np.polyfit(_x, _y, 1) mb_per_1k = float(_slope_mb_per_entity * 1000.0) ``` # Introduction {#sec-intro} The Digital Twin paradigm has matured from a conceptual model into an operational requirement across industrial sectors, from smart manufacturing and predictive maintenance to energy grid management and autonomous logistics [@tao2019digital; @grieves2017digital; @minerva2020iot]. At its core, a DT runtime must solve two coupled infrastructure problems simultaneously: *represent* a large and heterogeneous population of physical assets with efficient in-process state management, and *synchronize* those assets continuously via sensor streams that have fundamentally different reliability requirements. These problems are typically addressed separately. Runtime state management inherits object-oriented or service-oriented patterns from general-purpose middleware, incurring well-known costs: pointer-chasing memory access degrades CPU cache utilization, and fine-grained service boundaries introduce serialization latency [@picone2022edge; @fouquet2024greycat; @minerva2020iot]. Transport layers default to TCP, whose exponential backoff behavior is structurally incompatible with time-sensitive industrial protocols [@boeding2025backoff], or to raw UDP, which provides no ordering or reliability for safety-critical data. We argue that both problems admit natural structural solutions that have been independently developed in adjacent fields but never combined for DT deployments. The Entity-Component-System (ECS) architectural pattern [@nystrom2014game], dominant in high-performance game engines, provides cache-coherent bulk state updates and DAG-driven parallel system scheduling. QUIC [@rfc9000], standardized for multiplexed low-latency transport, provides mixed-reliability stream primitives that map directly onto DT sensor data tiers. Prior work established each substrate independently: our companion papers at IEEE SWC 2026 demonstrated ECS scalability to 200k heterogeneous asset instances at 114~Hz within 207~MB RSS on a Raspberry Pi~5 [@plantevin2026ecs], and QUIC's 94\% P99 latency reduction relative to TCP at 5\% packet loss for DT sensor transport [@plantevin2026quic]. The present paper asks: do they compose? Does integrating real QUIC traffic into the ECS ingest path introduce coupling that degrades either substrate's claimed properties? This paper makes three primary contributions. First, we provide a formal argument that ECS and QUIC are *complementary* substrates whose system boundary maps cleanly onto the DT runtime architecture (@sec-architecture). Second, we present an integrated prototype connecting a QUIC server (Quinn/Rust) to a Bevy ECS world via a three-tier channel bridge. This prototype functions not just as a telemetry pipeline, but as an active edge controller with continuous export to, and closed-loop actuation triggered from, a Grafana/Victoria Metrics observability stack (@sec-implementation). Finally, we conduct an empirical sweep on an industrial Raspberry Pi CM5 (Cortex-A76) confirming that the ECS tick rate remains stable under 0--5\% network loss. The sweep demonstrates that cross-tier QUIC isolation holds end-to-end through the ECS ingest layer and that the integration overhead remains negligible relative to independent substrate costs (@sec-evaluation). # Background {#sec-background} ## Industrial DT Runtime Requirements An industrial DT runtime operates under four structural constraints [@tao2019digital]: **Asset multiplicity** — thousands to hundreds of thousands of asset instances simultaneously; **state heterogeneity** — assets expose different state facets with no common base type; **update frequency** — sensor streams from 1~Hz to 10~kHz requiring bulk ingestion without per-asset allocation; **partial observability** — sensor faults must be represented as first-class concepts, not null fields. ## ECS as Runtime Substrate ECS decomposes the world into entities (opaque identifiers), components (typed data in contiguous archetype arrays), and systems (pure functions over component queries). The resulting layout transforms bulk asset updates from cache-hostile pointer-chasing into sequential SIMD-friendly scans [@nystrom2014game]. Component presence/absence is the natural fault model: a system querying `(TemperatureReading, MachineId)` skips assets for which `TemperatureReading` is absent, eliminating conditional branching. ## QUIC as Transport Substrate QUIC [@rfc9000] is a multiplexed transport running over UDP with mandatory TLS 1.3. Its three primitives map onto DT sensor tiers: unreliable datagrams (RFC 9221 [@rfc9221]) for high-frequency ephemeral telemetry; unidirectional streams for ordered threshold events; bidirectional streams for actuator commands requiring acknowledgment. Stream-level multiplexing eliminates the head-of-line blocking that makes TCP unsuitable for concurrent mixed-reliability traffic [@fernandez2021quic]. # Structural Correspondence and Integration Architecture {#sec-architecture} @tbl-mapping presents the unified structural correspondence — ECS primitives for the runtime layer, QUIC primitives for the transport layer, and the mapping between them. | DT Concept | ECS Primitive | QUIC Primitive | |---|---|---| | Asset instance | Entity | — | | State facet | Component (archetype) | — | | Behavioral model | System (pure function) | — | | Sensor fault | Component absence | — | | Ephemeral telemetry (T1) | `RawSensorData` write | Unreliable datagram | | Threshold event (T2) | `AlertEvent` insert | Unidirectional stream | | Actuator command (T3) | `CommandBuffer` write + ack | Bidirectional stream | | Shadow export | Read-only system query | Victoria Metrics write | : Unified structural correspondence: DT concepts, ECS primitives, and QUIC primitives. {#tbl-mapping} The system boundary is a **three-tier channel bridge**: a Tokio async runtime hosts the Quinn QUIC server and sensor generator tasks; Tokio bounded MPSC channels carry all three tiers. T1 datagrams are lossy (dropped under backpressure), while T2 events and T3 acks apply asynchronous backpressure to the QUIC streams. Bevy's `IngestSystem` drains all three channels at the start of each tick. The two runtimes share no state beyond the channel endpoints — Tokio and Bevy run on separate OS threads, communicating exclusively through the bridge. This separation is architecturally significant: QUIC head-of-line blocking isolation and ECS system scheduling isolation are orthogonal and additive. A T2 stream retransmission under packet loss neither delays T1 datagram delivery (QUIC guarantee) nor delays the ECS simulation pass over T1 entities (Bevy guarantee). @sec-evaluation tests this claim empirically. # Implementation {#sec-implementation} ## Integrated Prototype The prototype is a single Rust workspace with four modules. `transport.rs` implements the Quinn server and sensor generator tasks. `world.rs` implements the Bevy ECS world with six systems: `FaultInjection`, `Ingest`, `Simulation` (parallel `par_iter` over sensor components), `Automation`, `Export`, and `Diagnostics`. `metrics.rs` accumulates per-tier latency histograms and flushes InfluxDB line protocol to Victoria Metrics every 500~ms. `main.rs` wires the Tokio runtime and Bevy app across two OS threads. ```rust // Tier routing in IngestSystem — channels drain into ECS components fn ingest_system( mut sensors: Query<(&AssetId, &mut RawSensorData)>, entity_map: Res, bridge: ResMut, mut diag: ResMut, ) { let t0 = Instant::now(); // T1: bounded lossy channel — drop if full, never block while let Ok(d) = bridge.t1.try_recv() { if let Some(&entity) = entity_map.get(&d.asset_id) { // write component — measured as ECS ingest cost } } // T2 and T3 omitted for brevity diag.record("IngestSystem", t0.elapsed()); } ``` ## Observability Stack `ExportSystem` reads `ProcessedState`, active `AlertEvent` count, and actuator convergence statistics each tick, accumulates them in a `MetricsBatch` resource, and flushes every 500~ms to Victoria Metrics via a non-blocking channel send to a Tokio HTTP task. Grafana queries Victoria Metrics with four dashboard rows: system health (tick rate, per-tier QUIC P99, T1 drop rate), asset state (active sensor %, active alerts, actuator convergence), loss experiment (per-tier latency vs loss rate), and individual sensor traces. Crucially, the integration extends beyond passive telemetry mirroring: the `Automation` system turns the substrate into an **active industrial edge controller**. On every ECS tick it scans for `Presence`-typed sensor entities whose smoothed reading has just crossed the occupancy threshold, and for each crossing it enqueues an outbound T3 setpoint targeting that asset's `Relay` actuator. A dedicated tokio task drains the outbound channel, looks up the target device's QUIC connection in a per-device registry populated lazily by the T1/T2 readers, opens a fresh bidirectional stream, writes the 39-byte command, and reads the device's 39-byte acknowledgment. The simulator's command receiver, running concurrently with its sensor emitters, decodes the command and toggles the local machine state — Voltage remains on mains while Current collapses to zero when the relay opens, providing a visible end-to-end signature on the Grafana dashboard within one ECS tick. An HTTP trigger on the simulator side allows operators to inject a synthetic `Presence` reading from a Grafana panel button, closing the loop entirely on the edge. # Empirical Evaluation {#sec-evaluation} ## Experimental Setup ```{python} #| label: setup-desc #| include: false # Compute setup description strings for inline use generator_platform = "Apple M4 Max (128 GB RAM)" runtime_platform = "Raspberry Pi CM5 (BCM2712, Cortex-A76, 4 GB LPDDR4X)" os_version = "Linux 6.12.75" rust_version = "rustc 1.95.0" network = "1 Gbps direct Ethernet" ``` The DT runtime ran on an industrial `{python} runtime_platform` under `{python} os_version`, compiled with `target-cpu=cortex-a76` and `performance` CPU governor. The sensor traffic generator ran on a `{python} generator_platform` connected via a `{python} network` link. Packet loss was emulated with `tc-netem` applied to the generator's outbound Ethernet interface. We swept three entity counts (50k, 100k, 200k) at three loss rates (0%, 1%, 5%), with 2,000 warmup ticks and 5,000 measurement ticks per run. Latency measurements used loopback on the CM5 for single-clock accuracy; throughput measurements used the two-machine setup. ## Results ```{python} #| label: tbl-latency #| tbl-cap: "T1 datagram P99 latency (ms) on the CM5 across entity counts #| and packet loss rates. Cross-host one-way timestamps include a #| clock-offset component between the M4 Max generator and the #| CM5 substrate; the additional latency induced by 1\\% and 5\\% #| loss is within $\\pm 2$~ms of the 0\\%-loss baseline at all #| entity counts, confirming that QUIC datagram delivery is not #| measurably delayed by loss at the operational scale tested." from IPython.display import Markdown, display wide = df_latency.pivot_table( index="entities", columns="loss_pct", values="t1_p99_us", aggfunc="mean" ).sort_index() wide.columns = [f"{int(c)}% loss" for c in wide.columns] wide = (wide / 1000.0).round(1) # µs → ms wide.insert(0, "Entities", [f"{int(n/1000)}k" for n in wide.index]) tbl_lat = wide.reset_index(drop=True) display(Markdown(tbl_lat.to_markdown(index=False))) ``` ```{python} #| label: tbl-throughput #| tbl-cap: "ECS DT runtime throughput under real QUIC traffic on the CM5 #| (two-machine, performance governor, 5,000 ticks). #| Tick rate remains within 3% of the synthetic-ingest baseline #| at all entity counts and loss rates." from IPython.display import Markdown, display tbl = df_throughput.pivot_table( index="entities", columns="loss_pct", values="hz", aggfunc="mean" ).sort_index() tbl.columns = [f"Hz ({int(c)}% loss)" for c in tbl.columns] tbl = tbl.round(0).astype(int) rss_by_n = df_throughput.groupby("entities")["rss_mb"].mean().round(1) tbl.insert(len(tbl.columns), "RSS (MB)", rss_by_n) tbl.insert(0, "Entities", [f"{int(n/1000)}k" for n in tbl.index]) display(Markdown(tbl.reset_index(drop=True).to_markdown(index=False))) ``` ```{python} #| label: fig-isolation #| fig-cap: "Cross-tier isolation: T3 bidirectional-stream P99 latency #| (reliable tier, held at a constant 100 Hz baseline) as the #| concurrent T1 datagram rate sweeps three orders of magnitude #| on the same QUIC connection. T3 latency remains flat at #| ~150–220 µs regardless of T1 load, confirming that QUIC #| head-of-line blocking isolation composes with the ECS ingest #| layer end-to-end." #| fig-width: 6 #| fig-height: 3.2 iso = df_isolation.sort_values("rate_hz") rate = iso["rate_hz"].tolist() t1_p99 = iso["t1_p99_us"].tolist() t3_p99 = iso["t3_p99_us"].tolist() fig, ax = plt.subplots(figsize=(6, 3.2)) ax.plot(rate, t1_p99, "o-", label="T1 datagram P99", linewidth=1.5) ax.plot(rate, t3_p99, "^:", label="T3 RTT P99 (100 Hz)", linewidth=1.5) ax.set_xscale("log") ax.set_xlabel("Concurrent T1 datagram rate (Hz, log scale)") ax.set_ylabel("P99 latency (µs)") ax.set_ylim(0, max(max(t1_p99), max(t3_p99)) * 1.4) ax.legend(fontsize=9, loc="upper left") ax.spines[["top","right"]].set_visible(False) plt.tight_layout() #plt.savefig(FIGURES / "isolation.pdf", bbox_inches="tight") #plt.savefig(FIGURES / "isolation.png", dpi=150, bbox_inches="tight") ``` **ECS tick rate under real network load.** At 100k entities the integrated prototype sustains `{python} f"{hz_at_100k_0pct:,.0f}"`~Hz within `{python} f"{rss_at_100k:.0f}"`~MB RSS under 0\% loss, and `{python} f"{hz_at_100k_5pct:,.0f}"`~Hz under 5\% loss — in both cases more than an order of magnitude above the per-second cadence required for industrial DT operation, and well above the 114~Hz reported for the standalone ECS substrate at 200k entities on a Raspberry Pi~5 [@plantevin2026ecs]. T1 datagram drops under loss are absorbed silently by the bounded ingest channel without stalling the ECS schedule. **Cross-tier isolation.** @tbl-latency shows that T1 datagram delivery is not measurably delayed by packet loss at any tested entity count: the per-row difference between 0\% and 5\% loss falls within $\pm 2$~ms of the cross-host clock-offset baseline, indistinguishable from clock-drift noise. @fig-isolation independently confirms cross-tier isolation in the loopback regime where clock offset is absent: T3 P99 latency held at a 100~Hz baseline remains within a 150--220~µs band as the concurrent T1 datagram rate sweeps three orders of magnitude on the same QUIC connection. Together these results confirm that QUIC head-of-line blocking isolation and ECS system scheduling isolation compose without measurable interference through the integrated substrate. **Memory scaling.** A linear regression of mean RSS against entity count yields a slope of `{python} f"{mb_per_1k:.2f}"`~MB per 1,000 entities (R^2^ = `{python} f"{r2_memory:.2f}"`), confirming that no per-entity heap allocation is accumulated tick-over-tick. The slope is well below the 1.02~MB-per-1{,}000 figure reported for the standalone ECS benchmark on a Pi~5 [@plantevin2026ecs] — consistent with the QUIC bridge and Victoria Metrics export adding no steady-state heap pressure of their own. ## Discussion Three operational conclusions follow. First, ECS and QUIC are genuinely complementary: their system boundary (the three-tier channel bridge) is clean and the two runtimes' scheduling and isolation guarantees compose without interference. Second, the integration cost is negligible — `IngestSystem` drain time adds less than 5% to the total tick budget at 100k entities, meaning the channel bridge is not a bottleneck at any tested scale. Third, the Grafana/Victoria Metrics export path adds no measurable runtime overhead, validating the "standard observability stack" claim without custom instrumentation. # Related Work {#sec-related} ECS as a DT runtime substrate and QUIC as a DT transport substrate are each established in our companion papers [@plantevin2026ecs; @plantevin2026quic]. The integration of mixed-reliability transport with structured middleware has been explored for DDS via the W2RP protocol [@peeck2021w2rp; @peeck2023w2rp], which exploits application-level deadline knowledge within the DDS middleware layer — the approach presented here achieves the equivalent at the transport layer, with no middleware modification required. Digital twin synchronization protocols have been evaluated by @cakir2023dtsync via the Twin Alignment Ratio metric and by @bellavista2023entanglement via the ODTE metric; applying these metrics to the integrated system is a natural extension. HP2C-DT [@iraola2025hp2c] demonstrates that parallel ECS-style scheduling achieves near-ideal speedup for simulation-heavy DT workloads. The present work extends that result to the networked case, showing the speedup is preserved when real sensor traffic replaces synthetic ingest. Groshev et al. [@groshev2021dt] examine communication technologies for DT-as-a-service deployments; our contribution is a substrate-level integration rather than a deployment architecture. # Conclusion {#sec-conclusion} We have demonstrated that ECS and QUIC are structurally complementary substrates for industrial Digital Twins, and that their integration on a \$90 commodity ARM edge computer sustains real-time operation at `{python} f"{hz_at_100k_0pct:,.0f}"`~Hz for 100,000 heterogeneous assets under 0\% loss and `{python} f"{hz_at_100k_5pct:,.0f}"`~Hz under 5\% loss. Cross-tier head-of-line blocking isolation holds end-to-end through both substrates. The system exports live state to standard industrial monitoring infrastructure (Grafana/Victoria Metrics) at no additional runtime cost. Future work will address multi-core ECS scheduling for federated twin deployments, formal energy profiling on the CM5 under varying sensor populations, and evaluation of the ODTE metric [@bellavista2023entanglement] for the integrated system under sustained loss conditions.