Sim-to-Real Deployment and Continual Correction › Hardware-in-the-Loop and Staged Deployment
World Models HandbookAll chapters Sim-to-Real Deployment and Continual Correction › Hardware-in-the-Loop and Staged DeploymentOne section · Sections in this chapter9 / 13 ↓
Reading tools Definitions & inline links
Choose your expertise level to adjust how many terms are explained. Beginners see more tooltips, experts see fewer to maintain reading flow. Hover over underlined terms for instant definitions.
Article links
Make inline references clickable
Before any of this touches a physical plant, it goes through a ladder of increasingly realistic test stages. The vocabulary is worth getting right, because the stages differ in what they can and cannot establish.
- Model-in-the-loop (MIL): the controller and the plant are both software models. You are testing the algorithm.
- Software-in-the-loop (SIL): controller code runs against a simulated plant, ordinarily on a development host. This tests executed code paths, software interfaces, and control logic. Host execution profiles can be measured, but ordinarily do not establish target real-time behavior.
- Processor-in-the-loop (PIL): target-compiled controller code runs on the target processor or an equivalent instruction-set simulator, with plant inputs supplied by a simulation harness. This tests the compiled component's numerical behavior and supported resource measurements. Target-code execution time can be measured; full-loop timing still depends on the scheduler, I/O, harness, and workload, and an instruction-set simulator needs its own timing justification.
- Hardware-in-the-loop (HIL): physical control-loop components exchange signals with simulated components in a closed loop. Controller HIL can connect target hardware to a real-time plant simulator to test timing, I/O and injected faults; engine- or power-HIL can include physical loads and power interfaces. Isermann et al. (1999) discuss engine-control HIL and sensor/actuator faults. Fathy et al. (2006) review automotive HIL and an engine-in-the-loop facility. Those configurations provide different evidence and hazards.
- Physical plant trials: the real system, in a controlled environment, under supervision, with a stated operating envelope and independent safeguards.
Each stage provides evidence within its tested conditions. MathWorks' SIL/PIL overview distinguishes host code from target-compiled execution, while its execution-time profiling documentation describes measurements available in both modes. These profiles must be tied to the measured configuration. HIL can measure deadline behavior and fault responses on target hardware, but finite trials alone do not prove that every possible workload meets a deadline. Simulator validation against physical evidence remains separate. Physical hazards can also exist in HIL setups, especially power-HIL systems; using a simulated plant is not a blanket safety guarantee. Test coverage and a formal guarantee, when available, must be stated separately.
A test configuration in which the controller under test runs on its target hardware, connected through realistic electrical interfaces to a real-time simulation of the plant and its environment, so that real-time execution, I/O timing, and fault response can be exercised before a physical plant is involved.
A timing and watchdog sketch
We cannot run HIL here. What we can do is illustrate the class of logic HIL is designed to exercise: the relationship between control period, sensor period, observation age, and a staleness watchdog. This is a software fault-injection sketch on a CPU. It is not a HIL measurement, it does not characterize real-time performance, it says nothing about hardware fidelity, and it is not evidence of deployment readiness. Its only purpose is to make the relevant quantities concrete enough to reason about.
The control loop ticks every control_dt. The sensor publishes a new sample every sensor_dt, which is slower. The watchdog measures the age of the newest observation and forces the command to zero if that age exceeds a timeout. Then we inject a sensor dropout and watch the watchdog react. The design question is how the timeout should be chosen relative to the sensor period: too small and normal operation trips it, too large and a stall goes undetected for longer than the safety budget allows.
WD_CONTROL_DT = 0.01
WD_SENSOR_DT = 0.05
WD_TIMEOUT = 0.12
WD_DROPOUT_AT = 200
def watchdog_trace(control_dt, sensor_dt, timeout, n_steps, dropout_at):
"""Toy I/O timing model with a staleness watchdog.
This is a software fault-injection sketch on a CPU. It is NOT a
hardware-in-the-loop measurement, and it does not characterize
real-time performance, hardware fidelity, or physical safety.
"""
t = 0.0
last_sensor_t = 0.0
next_sensor = 0.0
trips = 0
first_trip = None
ages = np.zeros(n_steps)
commanded = np.ones(n_steps)
for k in range(n_steps):
if k < dropout_at and t >= next_sensor:
last_sensor_t = t
next_sensor += sensor_dt
age = t - last_sensor_t
ages[k] = age
if age > timeout:
trips += 1
commanded[k] = 0.0
if first_trip is None:
first_trip = t
t += control_dt
return ages, commanded, trips, first_trip
ages, commanded, trips, first_trip = watchdog_trace(
WD_CONTROL_DT, WD_SENSOR_DT, WD_TIMEOUT, 400, WD_DROPOUT_AT
)Control period : 0.010 s Sensor period : 0.050 s Watchdog timeout : 0.120 s Sensor dropout begins at : t = 2.00 s First watchdog trip : t = 2.08 s Commands forced to zero : 192 of 400 control ticks Peak observation age : 2.040 s
The sawtooth before the dropout is the consequence of a sensor running slower than the controller: the age oscillates between zero and just under one sensor period. That is not a fault, and the watchdog must not fire on it. An overly tight timeout can produce spurious stops during normal operation. Repeated false alarms can contribute to alarm fatigue and increase the risk that an operator ignores or disables a watchdog. Disabling it removes this detection path; a stall may then go unnoticed unless another independent check detects it. Choose and test the timeout against both ordinary sensor timing and the faults it is meant to catch.
This sketch exposes configured periods, observation age and the software command response. It does not measure execution time or deadline slack, and it injects no random timing jitter. A HIL campaign can separately measure those quantities and exercise interface faults, electrical disturbances, actuator responses and recovery transitions. Sending zero is not universally a safe stop: a plant may coast, fall or require active braking. Verify the fallback appropriate to the physical system and its recovery behavior.