Hardware-in-the-Loop (HIL) simulation — real hardware, simulated plant: Question bank

Before we start, a quick vocabulary anchor so no term or symbol appears unexplained on this page.

Definition The motor symbols, in plain words + units (needed by SE2, TF8, WHY6, EC1, EC2)

Picture a small DC motor. Electricity flows in, the shaft spins.

$V$ — the drive voltage (volts, V) the ECU effectively applies; $V = D \cdot V_{battery}$ where $D$ is the PWM duty fraction.
$I$ — the current (amps, A) flowing through the motor coil.
$R$ — the coil's resistance (ohms, $Ω$ ): how much it fights current.
$L$ — the coil's inductance (henries, H): how much it resists changes in current; $\frac{d I}{d t}$ is "how fast the current is changing per second".
$ω$ (omega) — the shaft's angular velocity (radians per second, rad/s): how fast it spins.
$θ$ (theta) — the shaft's angle / rotor position (radians, rad): how far it has turned; one full turn is $2 π$ rad.
$τ$ (tau) — torque (newton-metres, N·m): the twisting force the motor makes.
$J$ — the rotor's moment of inertia (kg·m²): how hard it is to spin up (rotational "mass").
$b$ — the damping coefficient (N·m·s/rad): friction that opposes spinning.
$K_{t}$ — torque constant (N·m/A): torque produced per amp, $τ = K_{t} I$ .
$K_{e}$ — back-EMF constant (V·s/rad): a spinning motor generates a voltage $K_{e} ω$ that pushes back against $V$ .
PPR — Pulses Per Revolution: how many electrical pulses the shaft's encoder (angle sensor) emits per full turn — the resolution of the position reading.

Figures that carry the timing intuition

The single hardest idea on this page is closed-loop real-time. These two pictures anchor it.

Figure — Hardware-in-the-Loop (HIL) simulation — real hardware, simulated plant

Look at the red loop: the ECU's command leaves through the DAC/PWM I/O, the simulator turns it into new physics, the ADC/encoder feeds new sensor values back — and this must close every step. That red loop is what SIL/PIL do not fully have.

The red step is an overrun: the simulator's compute time exceeds the deadline $Δ t$ . The feedback the ECU expected at the tick arrives late. To a fixed-rate PID loop, late feedback is indistinguishable from phase lag — and phase lag in a feedback loop eats stability margin until oscillation begins. That is why "hard real-time" (a guaranteed deadline, enforced by an RTOS or FPGA) is not a luxury but a correctness requirement.

Finally, why the Euler line in SE2 is true. Continuous physics says $\frac{d ω}{d t} = \frac{1}{J} (τ - τ_{load} - bω)$ — the slope of the speed curve. We only know things now, at $t_{k}$ , so we take the slope now and walk forward one step: $ω (t_{k + 1}) = ω (t_{k}) + Δ t \cdot (slope now)$ . The red tangent is that "slope now"; using a future torque we haven't computed would mean reading the slope from a point we haven't reached — impossible in a causal, real-time loop.

True or false — justify

TF1. In HIL, the controller software runs on your PC.

False. That is Software-in-the-Loop (SIL). The defining feature of HIL is that production firmware runs on the real target microcontroller; only the plant is simulated.

TF2. HIL simulates the ECU and tests it against real hardware.

False — it is exactly backwards. The ECU is real; the plant (motors, sensors, environment) is what gets simulated.

TF3. If the plant model is more physically accurate, the HIL test is always better.

False. Accuracy that makes a step take longer than the real-time deadline breaks the loop entirely — a slightly rougher model that meets timing beats a perfect model that overruns.

TF4. HIL removes the need for Model-in-the-Loop (MIL) and SIL testing.

False. These are a V-model progression; MIL/SIL catch algorithm bugs cheaply and early, so HIL only has to hunt the hardware/timing bugs the others cannot see.

TF5. A fixed-step solver is chosen mainly because it is more accurate than an adaptive one.

False. It is chosen because its per-step compute time is predictable — adaptive step size can suddenly take longer and blow the real-time deadline, even if it is more accurate.

TF6. If the simulator computes each step faster than real-time, we should let it run as fast as it can.

False. It must wait until wall-clock time reaches the step boundary; running ahead would feed the ECU sensor data from the future and desynchronise the closed loop.

TF7. In HIL the ECU can tell it is connected to a simulator instead of real hardware.

False (that is the whole point). Signals reach the ECU as real voltages, PWM edges and CAN frames through I/O hardware, so its ADC/GPIO/timers see the same electrical reality as in the car.

TF8. Ignoring inductance in the motor voltage equation is always a safe simplification.

False. It is only valid when the inductive term

L \frac{d I}{d t}

(voltage lost to changing current) is far smaller than the resistive term

R \cdot I

— i.e. slow current dynamics. For fast switching the neglected term dominates and the model lies.

Spot the error

SE1. "Our HIL rig runs the plant model at 100 Hz and the ECU control loop at 1 kHz — perfect match."

Error: the plant updates 10× slower than the controller reads sensors, so the ECU sees stale, stair-stepped data. The simulator rate must be at least as fast as the fastest ECU loop it feeds.

SE2. "Step 4 of our loop updates

ω

using the new torque

τ (t_{k + 1})

we haven't computed yet."

Error: Euler integration walks forward using the slope now (see the tangent figure):

ω (t_{k + 1}) = ω (t_{k}) + \frac{Δ t}{J} (τ (t_{k}) - τ_{load} - b ω (t_{k}))

, all evaluated at the current time

t_{k}

. Using a not-yet-computed future torque is a causality violation.

SE3. "We inject a sensor fault by editing the ECU firmware to return a bad reading."

Error: that changes the thing under test. Proper Fault Injection Testing corrupts the simulated signal path (e.g., DAC outputs a stuck voltage) so the unmodified firmware faces the fault.

SE4. "To convert the simulator's temperature value into something the ECU can read, we use an ADC."

Error: the direction is reversed. The simulator holds a number and must produce a voltage the ECU's pin can read, so it needs a DAC; an ADC is what reads the ECU's analog outputs back into the simulator.

SE5. "The plant model diverges to infinity after a few seconds, but the physics is correct, so the ECU code must be fine."

Error: an exploding Euler integration is usually a numerical instability — the step

Δ t

is too large for the system's fast dynamics, not evidence about the ECU at all.

SE6. "We validate timing on a normal desktop OS because it's easier to program."

Error: a general-purpose OS has no hard deadline guarantees; a background task can preempt the loop and miss a step. HIL needs an RTOS or FPGA for deterministic timing.

SE7. "Encoder count is

⌊ θ \cdot PPR ⌋

where

θ

is the rotor angle in radians and PPR is pulses per revolution."

Error: you must first convert the angle to revolutions by dividing by

2 π

rad per turn:

⌊ \frac{θ}{2 π} \cdot PPR ⌋

. Forgetting the

2 π

inflates the pulse count by a factor of

\approx 6.28

SE8. "Our ADC front end samples the simulated sensor voltage directly at 1 kHz — no filter needed."

Error: without an anti-aliasing low-pass filter before the ADC, any signal content above half the sample rate folds back as fake low-frequency noise (aliasing), corrupting the reading. Real-time fidelity requires filtering the analog signal before it is sampled.

Why questions

WHY1. Why simulate the plant instead of testing against the real engine/motor?

Because real plants can be expensive, dangerous, not-yet-built, or impossible to push into corner cases (overheat, sensor loss) without destroying them — the simulator gives repeatable, safe, cheap access to those scenarios.

WHY2. Why must HIL run the production firmware on the real chip, not a PC build?

Only the real target exercises compiler-specific code generation, interrupt (ISR) timing, and peripheral drivers — the exact class of bugs that "works in simulation, fails in hardware" surprises come from.

WHY3. Why is PWM the natural signal for the ECU→simulator command?

The ECU commands actuators by varying a duty fraction

D

, and the effective drive voltage is

V = D \cdot V_{battery}

; the simulator can read that duty cycle directly and turn it back into physics.

WHY4. Why do we bother with Processor-in-the-Loop (PIL) between SIL and HIL?

PIL runs the code on the target processor but still simulates I/O in software — it catches processor-specific numeric/compiler issues before you invest in the full physical I/O rig of HIL.

WHY5. Why does a real-time deadline miss make the control loop go unstable, not just inaccurate?

A fixed-rate PID loop assumes feedback arrives on time; a late sample (see the overrun figure) is mathematically the same as inserting phase lag, and lag in a feedback loop erodes stability margin until the loop oscillates or diverges.

WHY6. Why use System Identification before building the plant model?

Because the plant constants — torque constant

K_{t}

, inertia

J

, damping

b

, resistance

R

— are often unknown; identifying them from real measurements makes the simulated plant behave like the true one, so the HIL test is trustworthy.

WHY7. Why prefer an FPGA over a CPU for very fast plant models?

An FPGA computes in parallel hardware with cycle-deterministic timing, so it can hit microsecond-scale update rates that a sequential CPU (even with an RTOS) cannot guarantee.

Edge cases

EC1. What happens in the loop when the ECU commands 0% duty cycle (

D = 0

Then the drive voltage

V = 0

, so current comes only from back-EMF:

I \approx - \frac{K _{e} ω}{R}

— the motor freewheels and decelerates under damping

b

and load; the simulator must still produce valid (decaying) sensor signals, not freeze.

EC2. What if the shaft speed

ω

is exactly zero at start-up?

The back-EMF term

K_{e} ω

vanishes, so the current is

I = \frac{V}{R}

(full stall current) — a physically real, large inrush the model must represent; treating

ω = 0

as a special divide-case would wrongly hide it.

EC3. What if the ECU commands a negative or bidirectional duty (regenerative braking / reverse)?

The duty

D

(or an H-bridge direction bit) can make

V

negative, so torque

τ = K_{t} I

reverses; in regen the motor acts as a generator feeding current back, and the HIL rig must model both current directions and reproduce the correct signed voltage — clamping

D \geq 0

would silently break the test.

EC4. How should HIL behave when the ECU under test crashes or hangs?

The simulator keeps running real-time and must detect the missing/stale command (e.g., a watchdog on the CAN/PWM input) — a genuine failure mode the rig should surface, not paper over by holding the last value forever.

EC5. What if the simulator's step time occasionally overruns

Δ t

by a tiny amount?

Even rare overruns inject jitter the ECU interprets as time dilation; a correct HIL platform must either guarantee the deadline (hard real-time) or flag the overrun as a test-invalidating event, never silently continue.

EC6. Is HIL still meaningful if the ECU has no analog sensors at all, only CAN?

Yes — the I/O box just becomes a CAN transceiver feeding simulated sensor frames; "real hardware, simulated plant" is defined by what is real, not by which signal types are used.

EC7. Where does Vehicle-in-the-Loop (VIL) sit relative to HIL at the limit of realism?

VIL adds a real vehicle (or driver) into the loop while still simulating the surrounding traffic/environment — it is the step beyond HIL when even the plant's physical body must be real.

EC8. What is the degenerate case where HIL collapses into SIL?

If you replace the real ECU with a software model of it and remove the physical I/O, nothing real remains in the loop — you are back to pure Software-in-the-Loop (SIL).

Recall Quick self-test

The single feature that separates HIL from every simulation-only method ::: real production firmware runs on the real target hardware; only the plant is simulated. The single constraint that makes HIL hard to build ::: hard real-time — every plant update must finish before the next control-loop deadline. The correct device to send a simulated sensor voltage to the ECU ::: a DAC (Digital-to-Analog Converter), since the simulator holds a number and the ECU pin needs a voltage. Why a late feedback sample destabilises a PID loop ::: a late sample is equivalent to added phase lag, which reduces stability margin until the loop oscillates.