Coupled In-the-Loop Test Environment

• Coupled in-the-loop environments are validation frameworks that integrate multiple simulation and real-world domains with synchronized, bidirectional data exchange.
• They employ architectures like centralized orchestration and asynchronous message-bus mediation to maintain temporal coordination and mitigate latency differences.
• These setups enable rigorous system validation and early fault detection across applications such as automotive, power-grid, and embedded cyber-physical systems.

A coupled in-the-loop test environment is a validation framework in which heterogeneous simulation domains, real-time execution, and physical or software artifacts are connected through explicit synchronization and bidirectional data exchange so that closed-loop behavior can be observed under controlled yet realistic conditions. The literature suggests that the term denotes a family of architectures rather than a single implementation pattern: it encompasses software-in-the-loop integration of unmodified binaries, hardware-in-the-loop coupling of controllers and actuators, vehicle-in-the-loop and cyclist-in-the-loop benches, digital-twin synchronization with real assets, and mixed virtual–physical testbeds that preserve operational interfaces such as CAN, ROS 2, IEEE 802.11p, TUN/TAP, or FPGA bus transactions (Veith et al., 2020, Lehfuss et al., 2018, Wu et al., 5 Mar 2026).

1. Conceptual scope and modality taxonomy

Coupled in-the-loop environments are characterized by the coexistence of at least two timing or fidelity domains whose interaction is operationally significant. In the electric-vehicle supply equipment platform, pure software simulations, real-time simulations and actual power hardware—EVSE, grid emulator, and battery-powered vehicle—are combined within one coherent framework, while controller and power hardware-in-the-loop simulations require real-time execution with well-defined simulation sampling rates (Lehfuss et al., 2018). In the power-grid and ICT co-simulation framework, the distinguishing feature is the inclusion of the actual software being deployed, with unmodified application binaries such as iPerf3 and MAS nodes running in Docker or LXC and coupled into the simulation loop through virtual interfaces (Veith et al., 2020).

Automotive work extends the concept beyond conventional HIL. A Software-in-the-Loop toolchain can be correlated with physical proving-ground experiments through a synchronization and refinement loop, and the same process is explicitly described as extendible to Hardware-in-the-Loop, Vehicle-in-the-Loop, or mixed X-in-the-Loop configurations (Fei et al., 2024). A Vehicle-in-the-Loop and digital-twin framework couples a physical test vehicle on a dynamometer test bench with its synchronized virtual counterpart, while a cyclist–vehicle environment couples a Cyclist-in-the-Loop bench and a Vehicle-in-the-Loop bench through a shared Unreal Engine 5 virtual environment (Wu et al., 5 Mar 2026, Kaiser et al., 29 Jul 2025).

The term also appears in embedded and cyber-physical computing contexts. Examples include a virtual ECU twin that couples a SystemC/TLM 2.0 virtual platform to a reference instruction-set simulator via GDB (Dingler et al., 20 Feb 2026), a Virtual-Peripheral-in-the-Loop strategy that bridges TLM virtual prototypes and FPGA-hosted RTL peripherals (Ahmadi-Pour et al., 2023), and an embedded-OS HIL infrastructure in which a DUT, an external reference device, and a CI test node are permanently coupled for nightly regression testing (Weiss et al., 2021). This suggests that “coupled in-the-loop” is best understood as an architectural principle: a test environment is coupled when fidelity-critical artifacts remain active participants rather than being replaced by simplified offline traces.

2. Architectural patterns and middleware structures

One recurrent pattern is centralized orchestration. In the power-grid and communication-network framework, DIgSILENT PowerFactory performs RMS load-flow, contingency, and dynamic simulations; OMNeT++ models Dedicated, Shared, and High-Impairment subnets; mosaik acts as a Python-based co-simulation master for scheduling and data exchange; and AIT Lablink provides the message bus and bridges for PowerFactory, OMNeT++, and other components. All simulators and each vif-sim register as out-of-process participants, and data exchange uses JSON over TCP sockets in a request–reply protocol (Veith et al., 2020).

A second pattern is asynchronous message-bus mediation. In the EVSE validation platform, LabLink is structured in three layers: customized input blocks, a publish-subscribe core data bus, and customized output blocks. Common input/output handling such as type casting and timestamp alignment resides in a common I/O layer, while simulator- or device-specific glue code resides in specific I/O layers. The platform is explicitly described as modular and distributed, with scaling to hundreds of software nodes and multiple DRTSes limited only by aggregate computing power and network bandwidth, because no central orchestrator becomes a bottleneck (Lehfuss et al., 2018).

Automotive hybrid-digital-twin systems employ middleware as a semantic bridge rather than only a transport layer. In the closed-loop CARLA–SUMO platform, the middleware layer comprises a Message Gateway Pipeline, Shadow Vehicle Synchronization, and Command-to-CAN Conversion, linking a physical test site and real CAV to a CARLA–SUMO co-simulation over an IEEE 802.11p / UDP/IP V2X link (Quan et al., 19 May 2026). In the wireless-AI VANET framework, OMNeT++ with INET and RealTimeScheduler is coupled to real devices through Linux TAP interfaces and external-device interfaces such as ExtUpperIeee80211Interface and ExtUpperEthernetInterface, so that real layer-2 packets appear in the simulator as if they were produced by simulated nodes (Redondo et al., 2024).

The same architectural logic appears in lower-level systems. PHiLIP places a DUT shell, a configurable physical reference device, and a Jenkins or Robot Framework test node in a fixed orchestration topology (Weiss et al., 2021), while VPIL places a TLM-to-serial initiator inside the virtual prototype and a responder bridge plus RTL peripherals on an FPGA (Ahmadi-Pour et al., 2023). Across these systems, the coupling substrate may be a scheduler, a message bus, a middleware workstation, a TAP bridge, or a serial responder, but the structural role is the same: it preserves causally relevant interactions across otherwise disjoint execution domains.

3. Temporal coordination, synchronization, and latency compensation

Time coordination is a primary technical problem because coupled environments routinely join domains with incompatible execution granularities. In the power-grid/ICT framework, mosaik imposes discrete-time stepping with fixed $\Delta t$,

$t_{k+1}=t_k+\Delta t,$

and each simulator must report results and block until mosaik issues the next step. For packet injection from software-in-the-loop into OMNeT++, a time_shifted=True flag buffers events until the next $\Delta t$ boundary (Veith et al., 2020).

The EVSE platform makes the multi-rate structure explicit. Its software tasks satisfy $t_{s,o,i}>1\ \text{s}$, while the DRTS and power interface I/O satisfy $t_{s,RT}<1\ \text{ms}$ and $t_{s,Pl}<1\ \text{ms}$. LabLink therefore implements sample-and-hold buffering for slow producers, event-driven updates for fast producers, timestamp alignment through a LabLink timestamp $\tau$, and a no-global-clock policy whose only timing constraint is that $|\tau_{\text{producer}}-\tau_{\text{consumer}}|$ remain below a user-configurable threshold $\Delta\tau_{\max}$ to guarantee causality (Lehfuss et al., 2018).

Autonomous-driving systems introduce synchronization problems tied to perception events rather than only to fixed-step schedulers. In the SIL-to-track correlation study, each repetition is aligned by identifying the relative distance at which the ADS first recognizes the target, defining a synchronization reference halfway between the annotated scenario-start distance and the minimum observed detection distance, and then shifting timestamps so that the synchronization instants coincide across repetitions. The same synchronized reference state is then used to tune simulation set speed and sensor-model range before re-exporting the scenario files (Fei et al., 2024). In the hybrid digital-twin platform, shadow-vehicle synchronization uses coordinate transformation, latency-aware CTRV extrapolation, and EMA filtering, while the simulator clock is periodically reset toward wall-clock using an NTP-like PI controller on measured round-trip delays (Quan et al., 19 May 2026). In the ViL digital-twin framework, latency is handled through time-stamping, linear extrapolation, and a Smith-predictor-style correction applied to the physical state estimate used by the controller (Wu et al., 5 Mar 2026).

These synchronization schemes reflect different causality assumptions. Fixed-step co-simulation emphasizes deterministic scheduler control, event-aligned replay emphasizes state equivalence at perception onset, and predictor-based coupling emphasizes continuity of control under transport and computation delay. A plausible implication is that “coupled in-the-loop” environments should be classified not only by hardware presence, but also by the causal semantics used to declare two domains synchronized.

4. Realization of software, hardware, and digital twins within the loop

A distinctive feature of many coupled environments is the use of operationally authentic artifacts rather than surrogate API-level stand-ins. In the power-grid testbed, containerized software-in-the-loop integration proceeds by launching a container with an unmodified application, creating a TUN device as default route, running a vif userspace daemon to read and write packets from tun0, starting vif-sim outside the container, registering it with mosaik, and connecting vif-sim⟨tx,rx⟩ to an OMNeT++ node ⟨rx,tx⟩ through API calls (Veith et al., 2020). In the centralized automotive framework, the full perception–planning–control software runs natively on the central car server hardware under test, with no ECU flashing or intermediate HiL layers, and with direct interfaces to CARLA, real sensors, and motion gateways (Wu et al., 5 Mar 2026).

Physical hardware can enter the loop at multiple abstraction levels. The EVSE platform couples a DRTS, CHIL or PHIL interface, a power amplifier, and live hardware such as an EVSE and EV (Lehfuss et al., 2018). The satellite-attitude platform couples a MATLAB/Simulink satellite simulator to an NVIDIA Jetson Nano running ROS 2 nodes and four Maxon EC 60 flat brushless DC motors driven by Maxon EPOS4 Compact 50/5CAN controllers over USB and CANopen (Sakal et al., 26 Aug 2025). The DSRC-based connected-vehicle framework couples RTCSim and an RF channel emulator to an on-board IEEE 802.11p radio unit, GNSS, and CAN-bus interface through coax and time-tagged control of channel cards (Shah et al., 2019).

Digital twins extend the same principle to perception and scene realism. The hybrid CAV platform synchronizes a real CAV as a shadow vehicle inside CARLA–SUMO and converts virtual control commands into chassis-actuating CAN messages (Quan et al., 19 May 2026). The cyclist–vehicle platform stimulates a real vehicle camera by rendering the UE5 scene at 60 Hz onto a projection screen while the vehicle’s ROS 2 track-and-follow stack processes the images as live input (Kaiser et al., 29 Jul 2025). The adverse-weather TWICE platform uses IPG CarMaker, a Vehicle Radar Test System, a Video Interface Box and Camera-Box for direct injection, a high-resolution display plus OTA camera stimulation, and real radar and camera ECUs under test (Neto et al., 2023).

At the computing-system boundary, the same coupled logic appears in virtual-platform research. The virtual ECU twin executes a production ECU binary across a SystemC/TLM virtual platform and a QEMU reference simulator linked by a GDB-based coupling agent (Dingler et al., 20 Feb 2026), while VPIL forwards memory-mapped TLM transactions into a byte-stream protocol consumed by an FPGA-hosted responder bridge and RTL peripherals (Ahmadi-Pour et al., 2023). The common technical objective is early validation without waiting for full hardware availability, while still preserving instruction, bus, peripheral, or actuator semantics that matter for system behavior.

5. Validation methodology and representative metrics

Coupled in-the-loop environments are typically validated along four axes: synchronization fidelity, communication latency, closed-loop control behavior, and sim-to-real correlation. The metrics differ by domain, but the reported evaluations are consistently quantitative.

Environment	Reported metrics	Representative results
Power-grid/ICT SIL (Veith et al., 2020)	Ping Round-Trip Time; TCP Bulk Throughput	23 ms→447 ms; 6 102 kB/s→3 654 kB/s
EVSE co-simulation/HIL (Lehfuss et al., 2018)	Node 1 phase-voltage; charging power offset	230 V to ≈ 210 V; ≈ 10 % offset
ADS SIL correlation (Fei et al., 2024)	Pearson correlation coefficient; RRMSE	p-value below 0.05 indicates significance; Excellent if RRMSE < 10%
Hybrid CAV digital twin (Quan et al., 19 May 2026)	V2X latency; tracking accuracy	$\tau_{\mathrm{avg}}=18.3\ \mathrm{ms}$, $t_{k+1}=t_k+\Delta t,$0, $t_{k+1}=t_k+\Delta t,$1; lateral error RMS 0.12 m
Cyclist–vehicle coupled testbed (Kaiser et al., 29 Jul 2025)	Modality-specific latency; trajectory RMSE	steering 23.2 ms; typical RMSE 0.3–0.5 m
ViL digital twin (Wu et al., 5 Mar 2026)	Command-to-bench delay; state error norm	$t_{k+1}=t_k+\Delta t,$2, $t_{k+1}=t_k+\Delta t,$3; RMS $t_{k+1}=t_k+\Delta t,$4
Satellite HIL (Sakal et al., 26 Aug 2025)	Controller loop time; end-to-end latency	$t_{k+1}=t_k+\Delta t,$5; under 10 ms

Methodologically, the autonomous-driving SIL study formalizes correlation using both the Pearson coefficient

$t_{k+1}=t_k+\Delta t,$6

and the relative root-mean-squared error, with the empirical categories Excellent, Good, Fair, and Poor defined by thresholds at 10%, 20%, and 30% (Fei et al., 2024). The cyclist–vehicle study compares proving-ground and test-bench trajectories using

$t_{k+1}=t_k+\Delta t,$7

together with an RMSE over the trajectory samples (Kaiser et al., 29 Jul 2025). The wireless-AI VANET framework reports Packet Error Rate, throughput, average one-way delay, and decision latency, and relates these to RL-mediated adaptation of IEEE 802.11p parameters under mixed LiDAR, video, and background traffic (Redondo et al., 2024).

Some coupled environments focus on regression throughput and coverage rather than only physical fidelity. PHiLIP reports a nightly run with $t_{k+1}=t_k+\Delta t,$8 platforms and $t_{k+1}=t_k+\Delta t,$9 tests per platform, yielding approximately $\Delta t$0 tests/s over a $\Delta t$1 min cycle, with command latencies of approximately $\Delta t$2 for address-based access and $\Delta t$3 for named-based access, and coverage $\Delta t$4 for all 98 peripheral tests on 22 boards nightly (Weiss et al., 2021). This broadens the notion of validation: a coupled environment may be judged by physical realism, control stability, or CI-scale reproducibility, depending on the artifact under test.

6. Strengths, limitations, and emerging directions

A common misconception is that coupling alone guarantees realism. The reported studies are more cautious. In the EVSE platform, a charging-power discrepancy of approximately 10% appears because the real vehicle’s battery model and controller cannot be perfectly matched in software (Lehfuss et al., 2018). In the power-grid/ICT framework, mosaik’s JSON/TCP request–reply adds approximately one RTT per packet, single-threaded scheduling introduces polling overhead for vif-sim processes, TUN/TAP transitions create kernel↔user context switches per packet, and each container uses a separate process and TCP connection (Veith et al., 2020). In the satellite HIL platform, reaction-wheel current deadband, noisy Hall-effect sensing near zero speed, and torque limits required switching to velocity commands, dropping angular-acceleration terms from the real loop, and reducing adaptation gains (Sakal et al., 26 Aug 2025).

Human-interactive and vehicular environments show different constraints. In the cyclist–vehicle system, pedaling power from standstill exhibits approximately $\Delta t$5 ms latency, avatar arm motion is asymmetric at approximately $\Delta t$6 ms upward and $\Delta t$7 ms downward, and the setup is described as limited to single-cyclist scenarios and line-of-sight interactions (Kaiser et al., 29 Jul 2025). In the DSRC HIL emulator, the maximum is approximately 1000 nodes on a single workstation before control-plane saturation or thread jitter exceeds slot time (Shah et al., 2019). In the OMNeT++–RoSeNet coupling, a fully worked-out real-time synchronization scheme and numerical latency measurements were not yet available, and time-sync and performance evaluation were explicitly left for future work (Böhm et al., 2015).

At the same time, the literature consistently positions coupled environments as a bridge between pure simulation and field deployment. Purely virtual simulations are reported to struggle to capture all real-world factors in centralized automotive software testing (Wu et al., 5 Mar 2026), and wireless-AI work notes the risk of unexpected outcomes when simulated solutions are implemented in the real world (Redondo et al., 2024). The directions proposed across the corpus are correspondingly pragmatic: ZeroMQ or binary protocols, event-driven stepping, multiplexed vif-sim architectures, and surrogate models for large-scale power-grid co-simulation (Veith et al., 2020); cloud-edge collaborative multi-user operation for hybrid CAV twins (Quan et al., 19 May 2026); CAN/CAN-FD and SPI support for wireless-AI HIL (Redondo et al., 2024); and richer Emulation Control Interface mechanisms for OMNeT++/RoSeNet (Böhm et al., 2015).

Taken together, these systems define a mature research area centered on causal fidelity under heterogeneous execution. A coupled in-the-loop test environment is therefore not merely a mixed setup of “real” and “virtual” components. It is a synchronized, instrumented, and validation-oriented arrangement in which the interfaces, latencies, and failure modes of those components are themselves treated as first-class experimental variables.