Software-in-the-Loop (SiL) Validation

• Software-in-the-Loop (SiL) is a simulation-based validation method where real software interacts with virtual sensors, plant dynamics, and environmental models.
• SiL is applied across domains like autonomous driving, UAVs, underwater robotics, and smart grids to test integration and control fidelity before hardware deployment.
• SiL frameworks support closed-loop feedback, providing actionable metrics and insights to identify gaps between simulated and real-world performance.

Software-in-the-Loop (SiL) denotes a validation and development arrangement in which the software under test executes against simulated sensors, plant dynamics, communication channels, or environment models rather than a physical asset, while remaining in a closed loop with those models. Across autonomous underwater vehicles, automotive systems, UAV mission frameworks, smart-grid roll-outs, satellite attitude control, and embedded code-generation pipelines, SiL is used to exercise real software artifacts in a software-only environment before processor-, hardware-, vehicle-, or field-level deployment (Meyers et al., 10 Nov 2025, Shuai et al., 2023, Jeon et al., 16 Aug 2025, Veith et al., 2020, Mishamandani, 2020, Fakih et al., 2017).

1. Definition and conceptual scope

In the most direct formulation, SiL is the stage in which the software stack runs inside a simulator rather than on the target physical system. In autonomous driving, this is described as a closed-loop simulation where the ego vehicle’s perception, decision, and control software reacts to simulated traffic and environment over time (Fei et al., 5 Jun 2026). In underwater robotics, the same mission software stack runs on a computer while HoloOcean simulates the vehicle’s motion and sensors, with simulated sensor measurements published on ROS 2 topics as if they were coming from real sensor drivers and control outputs sent back to the simulator (Meyers et al., 10 Nov 2025). In smart-grid co-simulation, SiL means that the actual application software being rolled out is included unchanged inside the simulation loop as a containerized runtime component, rather than modeled abstractly (Veith et al., 2020).

The simulated element varies by domain. In some works it is the plant and its sensors; in others it is the communication substrate, the software deployment environment, or the scenario stimulus. The generated SDF-compatible C code in an embedded workflow can be wrapped in a Simulink S-function and run alongside the original plant/environment so that outputs are compared against a Model-in-the-Loop reference (Fakih et al., 2017). In automotive testing, SiL can also refer to the generation of realistic input signals for software components distributed across ECUs, where the central problem is to provide realistic signal transitions over time rather than only high-level traffic scenes (Parthasarathy et al., 2021, Parthasarathy et al., 2020).

The literature also exhibits terminological variation. Deep-sea robotics uses “simulation in the loop” for a workflow that projects recorded field observations back into a synchronized Gazebo/UUV simulation (Mueller et al., 2018). Heterogeneous HPC scheduling uses “Simulator in the Loop” for a control-theoretic selection mechanism that consults a simulator during execution to choose among dynamic loop scheduling techniques (Mohammed et al., 2018). This suggests that the invariant concept is not a specific simulator or industry domain, but the insertion of executable software into a feedback loop governed by software models rather than exclusively by physical hardware.

2. Canonical architectures and closed-loop mechanisms

A recurrent architectural pattern is state observation, software execution, command generation, model update, and repetition. In the HoloOcean 2.0.1 underwater workflow, the ROS 2 bridge is the SiL enabler: simulator state and sensor outputs are mapped into ROS 2 messages, command topics are accepted from the robot software stack, and the simulator computes accelerations from a Fossen-style torpedo-AUV model before passing those accelerations to Unreal Engine 5 for motion integration and collision handling (Meyers et al., 10 Nov 2025). The vehicle model is written as

$$M\dot{\nu_r} + C(\nu_r)\nu_r + D(\nu_r)\nu_r + g(\eta) = \tau,$$

with

$$M = M_{RB} + M_A,\qquad C(\nu_r) = C_{RB}(\nu_r) + C_A(\nu_r).$$

Here the simulated dynamics, the middleware bridge, and the autonomy nodes form a genuine closed loop rather than a replay-only benchmark.

A second pattern is perception-informed object-level closed-loop simulation. In autonomous driving, esmini provides the scenario/world simulation, OpenSCENARIO and OpenDRIVE define scenarios and maps, OSI provides the message layer, and an ideal camera sensor model converts simulator ground truth into object-level detections (Fei et al., 5 Jun 2026). The paper then inserts a Bayesian Network that models how fog, rain, darkness, and overlap geometry induce missed detections, sizing inaccuracies, positioning offsets, and merged detections. The probabilistic model is defined as a pair $(G,\theta)$, and for continuous variables the joint density factorizes as

$$f(x_{1}, \dots, x_{n}) = \prod_{i=1}^{n} f(x_{i} \mid pa(X_{i})).$$

This produces a condition-dependent corruption channel between simulated ground truth and the ADAS/ADS software, thereby replacing ideal sensing with stochastic perception faults.

A third pattern is infrastructure-level SiL, where the modeled environment is not vehicle dynamics but networking and deployment. In large-scale power-grid co-simulation, the software is containerized, attached to a virtual interface implemented with Linux tun/tap, translated through vif and vif-sim, and coupled via mosaik, AIT Lablink, OMNeT++, and DIgSILENT PowerFactory (Veith et al., 2020). The goal is to validate roll-out protocols under congestion, packet loss, and connection failures while the unmodified software stack remains inside the loop. In connected automated vehicles, the Remote Vehicle Emulator uses a Mobility Log Generator and CommSim so that a host-vehicle safety application receives V2V traffic that appears as live over-the-air Basic Safety Messages, with IEEE 802.11p / CSMA/CA timing, backoff, AIFS handling, and optional SINR-based reception reproduced by the emulator (Gupta, 2021).

Architectures that are intended to preserve transferability often mirror a later hardware stage. The AMAD-SRL UAV framework explicitly states that the SiL environment mirrors the complete architecture of the target Hardware-in-the-Loop Simulation system, retaining the same agents, same interfaces, same signal flow, and same module interconnections, while virtualizing avionics, propulsion, actuation, and EO/IR payload connections (Jeon et al., 16 Aug 2025). This architecture validates not only planning correctness but also integration fidelity.

3. Major application domains and validation targets

The function of SiL depends on which subsystem is considered risky, expensive, or difficult to instrument physically. The following configurations are representative.

Domain	Representative SiL configuration	Main validation target
Underwater robotics	HoloOcean 2.0.1 + ROS 2 bridge + CougUV mission software (Meyers et al., 10 Nov 2025)	Controller tuning, navigation, autonomy-node behavior, onboard computational load
UAV autonomy	AMAD-SRL in an HILS-mirroring SiL architecture (Jeon et al., 16 Aug 2025)	Interoperability of BDI agents and symbolic RL/PDDL Dynamic Planner
Automotive ADAS/ADS	esmini/OpenSCENARIO/OpenDRIVE/OSI or CARLA-based stacks (Fei et al., 5 Jun 2026, Gehrke et al., 9 Dec 2025)	Closed-loop safety-function validation, perception-fault injection, scenario execution
Cooperative automated vehicles	Remote Vehicle Emulator with SUMO/CommSim/DSRC (Gupta, 2021)	Real-time emulation of dense V2V traffic for host safety applications
Ackermann vehicular systems	MonoSIM with MVSIM, ROS2, monocular vision, PID/MPC (Rahman et al., 25 Mar 2026)	Lane keeping, trajectory tracking, controller comparison
Smart grid	Containerized application software with mosaik, Lablink, OMNeT++, PowerFactory (Veith et al., 2020)	Software roll-out behavior under ICT and power-grid interaction
Embedded and satellite control	SDF-generated C code in Simulink S-function; ADCS C package against orbital/environment models (Fakih et al., 2017, Mishamandani, 2020)	Functional equivalence, integrated estimator/controller verification
HPC scheduling	Simulator-in-the-Loop for online DLS selection (Mohammed et al., 2018)	Runtime adaptation of scheduling policy under perturbations

Within these domains, the validated artifact may be a controller, a planner, a middleware stack, or a deployment protocol. The underwater CougUV experiments targeted depth-from-surface hold, heading control, altitude-from-bottom hold, and CPU/RAM usage under mission execution (Meyers et al., 10 Nov 2025). The AMAD-SRL study targeted stable integration of a Dynamic Planner into a pre-existing BDI architecture and seamless switching between BDI-driven mission execution and SRL/PDDL-driven dynamic acquisition (Jeon et al., 16 Aug 2025). The smart-grid work targeted resilient large-scale software roll-out protocols rather than plant control alone (Veith et al., 2020). The satellite ADCS thesis used SiL to validate an integrated C implementation containing EKF, TRIAD, B-dot detumbling, rate damping, pointing controllers, manager logic, time management, and orbital/environment functions (Mishamandani, 2020).

Automotive literature also distinguishes between full closed-loop SiL platforms and stimulus-generation methods that support SiL. SilGAN learns from recorded field data how to translate a simple 1-D template into a realistic multivariate maneuver for low-level software testing (Parthasarathy et al., 2021). A related VAE/GAN approach uses unlabeled in-vehicle signals plus metric-guided interpolation so that synthetic stimuli stay controllably similar to specified references (Parthasarathy et al., 2020). These works do not replace the closed-loop simulator; they address the input-stimulation problem that frequently limits SiL coverage.

4. Evaluation criteria and representative results

The literature does not report a universal SiL score. Instead, evaluations are task-specific and often system-level. In the plug-in hybrid tractor study, SiL is the first validation stage for a reinforcement-learning-based energy management system, and the SiL test demonstrates that the ensemble learning system with an optimal combination can achieve 1.09% higher vehicle energy efficiency than a single Q-learning strategy with the EXD function (Shuai et al., 2023). In the UAV target-acquisition study, mission efficiency improved by approximately 75% over a coverage-based baseline, measured by travel distance reduction (Jeon et al., 16 Aug 2025).

Several papers use correlation against higher-fidelity baselines. In underwater robotics, the authors report strong correlation between simulated flat-terrain altitude-hold behavior and a reservoir field trial, and they track onboard resource usage at 1 Hz while the full mission stack runs on the CougUV computer (Meyers et al., 10 Nov 2025). The reported averages are close: Real World 27.4% CPU and 8.29% RAM, versus HIL Simulation 26.5% CPU and 8.21% RAM. In autonomous driving, correlation between SiL and physical testing is quantified with Pearson correlation and Relative Root Mean Squared Error, with most Pearson $r$ values above 0.9 for relative distance and longitudinal velocity across stationary-target, cut-in, and cut-out scenarios (Fei et al., 2024).

Other studies emphasize emulator accuracy and runtime scalability. The Remote Vehicle Emulator reports average Channel Busy Percentage / Channel Busy Ratio within about $\pm 0.7\%$ of ns-3 and average Packet Error Rate within about $\pm 2\%$ of ns-3, while a 40-second simulation with 5000 nodes that takes about 32 minutes in ns-3 is completed in about 41.99 seconds in CommSim (Gupta, 2021). In MonoSIM, mean squared deviations over multiple randomized tracks are reported separately for PID and MPC: PID yields lateral $0.0136\,\mathrm{m}^2$ and angular $0.000548\,\mathrm{rad}^2$, whereas MPC yields lateral $0.0390\,\mathrm{m}^2$ and angular $$M = M_{RB} + M_A,\qquad C(\nu_r) = C_{RB}(\nu_r) + C_A(\nu_r).$$0 (Rahman et al., 25 Mar 2026).

SiL is also used to quantify improvement after synchronization of simulated and real conditions. In the deep-sea robot framework, EKF localization with navigation sensors only gives a position error of $$M = M_{RB} + M_A,\qquad C(\nu_r) = C_{RB}(\nu_r) + C_A(\nu_r).$$1 and orientation error of $$M = M_{RB} + M_A,\qquad C(\nu_r) = C_{RB}(\nu_r) + C_A(\nu_r).$$2, while adding visual markers reduces these to $$M = M_{RB} + M_A,\qquad C(\nu_r) = C_{RB}(\nu_r) + C_A(\nu_r).$$3 and $$M = M_{RB} + M_A,\qquad C(\nu_r) = C_{RB}(\nu_r) + C_A(\nu_r).$$4; subsequent covariance optimization and outlier rejection improve smoothness and reduce orientation error further (Mueller et al., 2018). In code-generation verification, the central criterion is functional equivalence of outputs between the SIL simulation of generated code and the MIL reference, rather than throughput or latency metrics (Fakih et al., 2017).

These result types are heterogeneous by design. Some papers prioritize energy efficiency, some trajectory deviation, some communication fidelity, some localization accuracy, and some exact output equivalence. This suggests that SiL is best understood as a methodological layer whose success criterion is inherited from the system under validation.

5. Fidelity, reality gap, and known limitations

A persistent issue is that SiL can be both indispensable and misleading when its models are too idealized. In autonomous driving, ideal-sensing object-level simulation is criticized for bypassing the functional insufficiencies of perception algorithms and thus yielding over-optimistic safety assessments (Fei et al., 5 Jun 2026). The proposed causal probabilistic framework addresses this by injecting realistic perception errors derived from physical triggering conditions such as fog, rain, darkness, and object overlap. The claim is not that raw-sensor rendering is always necessary, but that object-level SiL must model the causal path from environment to perception insufficiency if it is to support SOTIF-oriented validation.

A broader empirical study decomposes the reality gap into perception gap, actuation gap, and behavior gap, and treats SiL as the fully virtual baseline in which sensing and vehicle dynamics are handled entirely by the simulator (Lambertenghi et al., 26 Sep 2025). That study reports that SiL can produce both false negatives and false positives relative to real-world testing, and notes actuation mismatches on the order of 30–70% in some low-level tests. Mixed-Reality improves perceptual realism without compromising safety or control, whereas SiL and ViL each simplify critical aspects of real-world dynamics and sensing (Lambertenghi et al., 26 Sep 2025). This directly challenges the misconception that a successful SiL run necessarily transfers.

Even in domains with high-fidelity plant models, limitations remain concrete and localized. The HoloOcean CougUV study reports that heading responses are less comparable at the surface because the top fin was sometimes not fully submerged due to small waves, and that this surface interaction is not modeled in HoloOcean (Meyers et al., 10 Nov 2025). External disturbances such as currents and waves were not applied in the shown simulations. The underwater deep-sea SIL framework addresses a different facet of the gap by embedding recorded spatial and environmental conditions, including noise, haze, illumination, and color attenuation, back into the simulator so that benchmarking occurs under matched conditions (Mueller et al., 2018).

Real-time constraints also delimit what counts as credible SiL for later hardware stages. In vEDGAR, CARLA is described as already strong for SiL, but not as a hard real-time platform: Unreal Engine 4 cannot satisfy hard real-time requirements, LiDAR remains the main bottleneck for soft real-time sensor fidelity, CARLA 0.9.15 lacks native ROS2 support, synchronous-mode buffering can delay streams, and multi-GPU deployment introduces additional synchronization issues (Gehrke et al., 9 Dec 2025). The correlation study for Volvo’s CSPAS likewise shows that acceleration signals are harder to match than speed or distance, with cut-out longitudinal acceleration reaching a mean RRMSE of 28.42%, near the paper’s “poor” boundary (Fei et al., 2024).

The cumulative picture is not that SiL is unreliable, but that its reliability is conditional on what is simulated faithfully. This suggests that high transferability depends less on the presence of a simulator per se than on the adequacy of sensor, actuator, timing, environment, and interface models for the particular claim being made.

6. Position within development workflows and relation to adjacent methods

SiL is frequently placed between model-level design and hardware-level deployment. In automatic code generation from Simulink to SDF, Model-in-the-Loop provides the reference behavior, and Software-in-the-Loop checks the generated C code inside a Simulink verification model before any later deployment concerns are addressed (Fakih et al., 2017). The SSS-1P satellite thesis defines a five-level path of Software-in-the-Loop, Processor-in-the-Loop, Hardware-in-the-Loop, experimental model, and satellite flight model, with SiL as the first integrated verification step for the full ADCS package (Mishamandani, 2020). In plug-in hybrid energy management, SiL is explicitly the first validation stage before HiL (Shuai et al., 2023).

In systems built for later hardware parity, the SiL stage often preserves the same interfaces as the target platform. The AMAD-SRL environment mirrors the complete architecture of the intended HILS platform so that later hardware transition should require minimal redesign (Jeon et al., 16 Aug 2025). The CAT Vehicle Testbed is organized so that there is no distinction between a simulated autonomous vehicle and a real autonomous vehicle from the ROS controller’s perspective, allowing a simulation-first workflow to transition into HIL through a ROS/JAUS bridge (Bhadani et al., 2018). The vEDGAR work frames CARLA as a baseline SiL capability that requires a service-oriented wrapper and substantial extensions before it can support a constrained form of HiL on the EDGAR research vehicle stack (Gehrke et al., 9 Dec 2025).

Adjacent modalities refine which elements are real and which remain simulated. In the ADS reality-gap study, SiL is fully virtual, Vehicle-in-the-Loop uses a real vehicle with simulated perception, Mixed-Reality preserves real sensor streams while inserting virtual objects, and real-world testing removes the simulator from the control loop (Lambertenghi et al., 26 Sep 2025). In deep-sea robotics, “simulation-in-the-loop” denotes a synchronized real/simulated benchmark loop rather than a purely predeployment stage (Mueller et al., 2018). In HPC, “Simulator in the Loop” is used for online selection of scheduling policies under perturbations rather than for cyber-physical controller validation (Mohammed et al., 2018). A further extension appears in SILO for cable routing, where simulation is not only a training environment but also an online intermediary that converts policy outputs into simulator-produced joint targets before commanding the real robot (Tao et al., 6 Jul 2026).

Taken together, these workflows show that SiL is not a single protocol but a family of software-mediated validation strategies. What unifies them is executable software running inside a feedback structure that is sufficiently realistic to answer a predeployment question: whether a controller transfers, whether an autonomy architecture interoperates, whether communication timing is credible, whether rollout protocols remain resilient, or whether generated code preserves model behavior. In that sense, SiL is less a substitute for physical testing than a technical layer for making later testing narrower, safer, and more interpretable.