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

This page is a practice arena. The parent note built the theory (real ECU, simulated plant, real-time deadline, the motor update equations). Here we grind through every kind of situation a HIL problem can throw at you — normal numbers, zero inputs, degenerate cases, timing that just barely fails, and the exam twists that catch people.

Before we start, one reminder in plain words: in HIL, a real controller (the ECU — the little computer that would sit inside a real car) is fooled into thinking it talks to real motors and sensors. In truth it talks to a simulator — a second computer solving physics equations fast enough to answer before the ECU asks again. Every example below lives inside that loop.

The picture above is the loop every example freezes one moment of: the ECU emits a command, the I/O box carries it to the simulator, the simulator does its physics, the I/O box carries a sensor value back. Keep it in mind — each example is one arrow on this ring.

---

The scenario matrix

Every HIL problem you will meet falls into one of these case classes. The map below arranges them; each numbered example is tagged with the cell it covers, so by the end you have touched every box.

Case class	What makes it tricky	Covered by
A. Normal closed loop	ordinary numbers, everything in range	Ex 1
B. Real-time deadline PASS	compute time comfortably under the step	Ex 2
C. Real-time deadline FAIL	simulator too slow → loop breaks	Ex 3
D. Zero / degenerate input	duty cycle $=0$, or $\omega =0$ at start	Ex 4
E. Sign / direction flip	negative torque, motor spinning backward	Ex 5
F. Signal-conversion limits (clip, both rails)	sensor voltage hits $0\text{ V}$ or $5\text{ V}$; current hits $I_{\text{max}}$	Ex 6
G. Real-world word problem	full idle-speed scenario, settling time	Ex 7
H. Exam-style twist	"why does SIL miss this but HIL catches it?"	Ex 8
I. Limiting / steady-state	$t\to \infty$, what speed does it settle at?	Ex 9

We reuse one DC-motor plant for the numeric cases so the numbers stay comparable. Its constants (all invented but consistent):

These plug into the quasi-static update chain from the parent note (the inductance term $L\frac{dI}{dt}$ dropped, as defined above):

$V=D{V}_{\text{batt}},I=\frac{V-K_e\omega }{R},\tau =K_{t}I$ ${\omega }_{k+1}={\omega }_k+\frac{\Delta t}{J}(\tau -{\tau }_{\text{load}}-b{\omega }_k)$

---

Example 1 — Normal closed loop [Case A]

Forecast: guess first — will the speed go up, down, or stay put? (Hint: is the motor being pushed harder than the back-EMF resists?)

1. Voltage from PWM. $V=D{V}_{\text{batt}}=0.7\times 12=8.4\text{V}$. Why this step? The PWM duty cycle is the only thing the ECU physically hands the simulator; everything downstream flows from it.

2. Current. $I=\frac{V-K_e\omega }{R}=\frac{8.4-0.05\times 100}{2}=\frac{8.4-5}{2}=1.7\text{A}$. Why this step? Voltage minus back-EMF is the net push across the resistance; Ohm's law turns it into current. ($1.7\text{ A}<I_{\text{max}}=5\text{ A}$, so no clamp needed here.)

3. Torque. $\tau =K_{t}I=0.05\times 1.7=0.085\text{N⋅m}$. Why this step? Current makes torque — this is the Lorentz-force link that actually spins the shaft.

4. New speed (Euler). ${\omega }_{k+1}=100+\frac{0.001}{0.001}(0.085-0-0.0001\times 100)=100+1\times (0.085-0.01)=100.075\text{rad/s}$. Why this step? Newton's law says net torque over inertia is angular acceleration; Euler multiplies that by the time step to advance one tick.

Verify: net torque $0.075\text{N⋅m}$ is positive, so speed rises — matches the forecast that $8.4\text{ V}$ overpowers the $5\text{ V}$ back-EMF. Units: $\frac{\text{s}}{{\text{kg⋅m}}^2}\cdot \text{N⋅m}=\frac{\text{N⋅m⋅s}}{{\text{kg⋅m}}^2}=\text{rad/s}$ ✓ (since $\text{N⋅m}={\text{kg⋅m}}^2/{\text{s}}^2$). New speed $100.075\text{rad/s}$.

---

Example 2 — Deadline PASS [Case B]

Forecast: add the two times, compare to the step. Pass or fail?

1. Total compute. $t_{\text{compute}}=180+120=300\mu \text{s}$. Why this step? The deadline covers everything between receiving the ECU command and delivering the sensor answer — compute and I/O.

2. Available budget. $\Delta t=1\text{ ms}=1000\mu \text{s}$. Why this step? The ECU asks again every $1\text{ ms}$; the answer must be ready before then.

3. Compare and take utilisation. $\text{utilisation}=\frac{t_{\text{compute}}}{\Delta t}=\frac{300}{1000}=0.30=30\%$. Slack $=700\mu \text{s}$. Why this step? The real-time law from the parent note is $t_{\text{compute}}<\Delta t$; utilisation just re-expresses it as "what fraction of the tick did we burn?" — $30\%$ is well under $100\%$.

Verify: $30\%$ utilisation means $70\%$ headroom, so no time dilation — the ECU never notices it is in a simulation. PASS.

---

Example 3 — Deadline FAIL [Case C]

Forecast: total vs. budget again — but this time think about what the ECU experiences.

1. Total. $t_{\text{compute}}=950+120=1070\mu \text{s}$. Why this step? Same accounting; the fault will show in the sum.

2. Compare. $1070\mu \text{s}>1000\mu \text{s}$. Overrun $=70\mu \text{s}$, utilisation $=107\%$. Why this step? Crossing $100\%$ utilisation is the definition of a missed hard deadline.

3. Consequence. The simulator delivers last-tick sensor values late. The ECU reads stale encoder counts, computes control on old data, and the closed loop can go unstable (the "time dilation" warned about in the parent note). Why this step? HIL only stays honest while the simulation keeps up; once it lags, results are meaningless.

Verify: $1070>1000$ confirms overrun; the $70\mu \text{s}$ deficit means we must either speed the solver (fixed-step, lookup tables, FPGA) or slow the loop. See FPGA for Real-Time Simulation and Real-time Operating Systems (RTOS) for the fixes. FAIL.

---

Example 4 — Zero / degenerate input [Case D]

Forecast: with zero volts and zero speed, does anything move?

1. Voltage. $V=0\times 12=0\text{V}$. Why this step? Duty cycle zero means the PWM is fully off — no drive at all.

2. Current. $I=\frac{0-0.05\times 0}{2}=\frac{0}{2}=0\text{A}$. Why this step? We divide by $R=2$, not by anything that could be zero — so the formula stays safe even at rest. This is the degenerate check.

3. Torque & speed. $\tau =0.05\times 0=0$; ${\omega }_{k+1}=0+\frac{0.001}{0.001}(0-0-0)=0\text{rad/s}$. Why this step? No current → no torque → no change; the motor correctly stays still.

Verify: all zeros, no division by zero (the only denominator is $R$, a fixed constant), speed unchanged at $0\text{rad/s}$. A HIL rig that produced garbage here would fail the boot-sequence test in Example 7's step 1. Clean.

---

Example 5 — Sign / direction flip [Case E]

Forecast: compare drive voltage to back-EMF. Which is bigger?

1. Voltage. $V=0.5\times 12=6\text{V}$. Why this step? Sets the drive side of the tug-of-war.

2. Back-EMF. $K_e\omega =0.05\times 200=10\text{V}$. Why this step? A spinning motor generates its own voltage opposing the supply; here it is larger than the supply.

3. Current (goes negative). $I=\frac{6-10}{2}=\frac{-4}{2}=-2\text{A}$. Why this step? The sign flips — current now flows backward, meaning the motor acts as a generator (braking). A HIL model must handle this sign, or braking scenarios test wrong. ($|-2|<I_{\text{max}}$, no clamp.)

4. New speed. $\tau =0.05\times (-2)=-0.1\text{N⋅m}$; ${\omega }_{k+1}=200+1\times (-0.1-0-0.0001\times 200)=200+(-0.1-0.02)=199.88\text{rad/s}$. Why this step? Negative torque plus damping decelerates — the motor slows, as physics demands.

Verify: speed dropped from $200$ to $199.88\text{rad/s}$; current sign is negative → regenerative braking captured correctly. Sanity: back-EMF ($10\text{ V}$) $>$ drive ($6\text{ V}$) ⇒ braking ✓.

---

Example 6 — Signal & current limits: both rails and the current ceiling [Case F]

Forecast: the linear encoding is happy to go below $0$ and above $5$ — but the hardware is not. Guess which of the three temperatures get clipped, and whether the stall current blows past $I_{\text{max}}$.

Part (a): both rails.

1. Hot — upper rail. $V_{\text{ideal}}=0.02\times 300=6.0\text{V}\Rightarrow V_{\text{out}}=\min (6.0,5.0)=5.0\text{V}$. ECU decodes $T=5.0/0.02=250\text{°C}$. Why this step? The DAC saturates at its top rail; above $250\text{ °C}$ every temperature reads the same $5\text{ V}$ — a high-side blind spot.

2. Cold — lower rail. $V_{\text{ideal}}=0.02\times (-40)=-0.8\text{V}\Rightarrow V_{\text{out}}=\max (-0.8,0)=0\text{V}$. ECU decodes $T=0/0.02=0\text{°C}$. Why this step? A DAC cannot output negative volts on a $0$–$5\text{ V}$ pin, so it floors at $0\text{ V}$ — the ECU thinks it is $0\text{ °C}$ when the plant is really $-40\text{ °C}$. This lower-rail case is just as real as the upper one and equally invisible to the ECU.

3. In range — no clip. $V_{\text{ideal}}=0.02\times 120=2.4\text{V}$, inside $[0,5]$, so $V_{\text{out}}=2.4\text{V}$ and $T=2.4/0.02=120\text{°C}$ decodes back exactly. Why this step? Shows the encoding is faithful only inside the rail window; the fix is to rescale so the whole $-40$ to $300\text{ °C}$ span maps into $0$–$5\text{ V}$.

Part (b): current ceiling.

4. Raw stall current. $V=1\times 12=12\text{V}$, $I_{\text{raw}}=\frac{12-0.05\times 0}{2}=6\text{A}$. Why this step? At standstill there is no back-EMF, so the full supply drives current — this is the worst case that stresses the winding.

5. Clamp to the ceiling. $6\text{A}>I_{\text{max}}=5\text{A}$, so a faithful model outputs $I=\min (6,5)=5\text{A}$, giving $\tau =K_t\times 5=0.25\text{N⋅m}$. Why this step? Real drivers current-limit; if the HIL model let $6\text{ A}$ through it would over-predict torque and miss the ECU's over-current protection logic (a Fault Injection Testing target).

Verify (a): hot reads $250\text{ °C}$ (rail $5\text{ V}$) ✓; cold reads $0\text{ °C}$ (rail $0\text{ V}$) ✓; in-range $120\text{ °C}$ decodes exactly ✓ — both rails and the clean middle all shown. Verify (b): $I_{\text{raw}}=6\text{ A}$ clamps to $5\text{ A}$, $\tau =0.25\text{ N⋅m}$; without the clamp torque would be $0.30\text{ N⋅m}$, a $20\%$ over-estimate.

---

Example 7 — Real-world word problem: idle-speed test [Case G]

Forecast: eyeball the sequence — does the distance from 800 shrink, or grow?

1. PASS band. $800\pm 20=[780,820]\text{RPM}$. Why this step? The test's acceptance criterion is a fixed window; the last value must land inside it.

2. Check last value. $806\in [780,820]$ ✓ → PASS on the final reading. Why this step? That is literally the PASS criterion from the parent's Example 1.

3. Damping = error about the setpoint shrinks. The correct measure of settling is the error $e_k=|{\text{speed}}_k-800|$, i.e. how far each sample sits from the target, not the step-to-step jump. Compute: $e_0=|780-800|=20$, $e_1=|840-800|=40$, $e_2=|792-800|=8$, $e_3=|806-800|=6$. After the first cranking transient the errors fall $40\to 8\to 6$ — a shrinking magnitude that straddles $800$ from both sides. That decaying, alternating-sign error is the textbook signature of a damped (stable, settling) oscillation. Why this step? The parent warned that a growing $800\to 850\to 750$ swing means $K_p$ too high. The proper test is whether the error envelope decays; here it does, so the PID gains are healthy.

4. Unit conversion. $\omega =800\text{RPM}\times \frac{2\pi }{60}=\frac{800\times 2\pi }{60}\approx 83.78\text{rad/s}$. Why this step? Our plant equations use $\text{rad/s}$; converting lets the idle target feed the motor model directly.

Verify: last value $806$ inside $[780,820]$ ✓; setpoint errors $40\to 8\to 6$ after the transient are decreasing ✓ (damped); $800\text{RPM}=83.78\text{rad/s}$ (check: $83.78\times 60/(2\pi )\approx 800$ ✓). See PID Control for the tuning behind this response.

---

Example 8 — Exam-style twist [Case H]

Forecast: the bug is about real timing on real silicon, inside a live loop. Ask two yes/no questions of each level — does it run real hardware? does it close a real-time loop? — and let the answers rank them.

1. MIL — miss it. The controller is still just a block-diagram model running on your PC; there is no code, no processor, no ISR. The $30\mu \text{s}$ lateness has nowhere to happen. Why this step? You cannot reproduce a hardware-timing bug on something that contains zero hardware.

2. SIL — miss it. Now the actual C code compiles and runs, but on the PC, not the target chip. PC timing has no relation to the microcontroller's ISR latency, so again the bug never fires. Why this step? SIL checks logic, not real interrupt timing — the very thing this bug depends on.

3. PIL — partially. The code runs on the real processor, so the ISR and its $30\mu \text{s}$ lateness now genuinely occur and can corrupt the variable. But the plant is still numbers fed in from the PC, not a live real-time closed loop, so you may see the corruption without seeing its full physical consequence. Why this step? PIL adds real silicon (catches the cause) but not real-time signals (may not show the effect).

4. HIL — catches it fully. Real ECU and a live closed loop: the ISR fires late on the genuine microcontroller, corrupts the shared variable, the ECU emits a wrong actuator command, the real-time plant simulator reacts to that wrong command and feeds altered sensor values back — so the fault shows up as visibly wrong closed-loop behaviour (e.g. a speed glitch on the log). Why this step? HIL is the first level with both real hardware timing and a live physical loop — exactly the two ingredients this bug needs to become an observable failure.

Verify: detection strength ranks HIL $>$ PIL $>$ SIL $=$ MIL for a hardware-timing bug. Two boolean tests decide it — "real chip?" (false, false, true, true) and "live real-time loop?" (false, false, false, true) — and HIL is the only level that scores true on both. This matches the parent note's promise that HIL "eliminates works in simulation but fails in hardware surprises." Closure: the further right you push a test toward real hardware plus real signals, the more timing-and-integration faults it can expose — which is precisely why HIL exists. (Add a real vehicle around it and you reach Vehicle-in-the-Loop (VIL).)

---

Example 9 — Limiting / steady state [Case I]

Forecast: at steady state, acceleration is zero — so what must the net torque be?

1. Set acceleration to zero. Steady state means ${\omega }_{k+1}={\omega }_k$, so the bracket in the update must vanish: $\tau -b\omega =0$. Why this step? The whole point of a limit: the Euler increment vanishes, leaving an algebra equation, no more stepping.

2. Expand torque in terms of $\omega$. With $I=\frac{V-K_e\omega }{R}$ and $\tau =K_{t}I$: $K_t\cdot \frac{V-K_e\omega }{R}-b\omega =0.$ Why this step? We want one equation in the single unknown $\omega$.

3. Solve for ${\omega }_{\infty }$. ${\omega }_{\infty }=\frac{K_{t}V}{K_t{K}_e+bR}=\frac{0.05\times 8.4}{0.05\times 0.05+0.0001\times 2}=\frac{0.42}{0.0025+0.0002}=\frac{0.42}{0.0027}\approx 155.56\text{rad/s}.$ Why this step? Rearranging isolates the steady speed; plugging the shared constants gives the number the HIL log should asymptote to.

Verify: at $\omega =155.56$: back-EMF $=0.05\times 155.56\approx 7.78\text{ V}$, current $=(8.4-7.78)/2\approx 0.311\text{ A}$ (well under $I_{\text{max}}$), torque $\approx 0.01556\text{ N⋅m}$, damping torque $=0.0001\times 155.56\approx 0.01556\text{ N⋅m}$ — equal, so net torque $\approx 0$ ✓. Steady state $155.56\text{rad/s}$, and note it sits above Example 1's one-step $100.075$, confirming the motor is still accelerating there.

---

Recall Quick self-test

One-step new speed at $D=0.7,\omega =100$ (Ex 1)? ::: $100.075\text{rad/s}$ Utilisation when compute$=300\mu s$, step$=1\text{ms}$ (Ex 2)? ::: $30\%$, PASS Overrun when compute$=1070\mu s$, step$=1000\mu s$ (Ex 3)? ::: $70\mu \text{s}$, FAIL Current sign when back-EMF ($10$V) beats drive ($6$V) (Ex 5)? ::: negative, $-2\text{A}$ (braking) Cold $-40°C$ encoded on a $0$–$5$V pin reads what (Ex 6)? ::: $0°C$ (floored at the lower rail) Stall current at $D=1,\omega =0$ before/after clamp (Ex 6)? ::: $6\text{ A}$ raw → clamped to $5\text{ A}$ Steady-state speed at $D=0.7$ (Ex 9)? ::: $155.56\text{rad/s}$

---

Connections: the plant math here comes from the parent HIL note; the timing budget links to Real-time Operating Systems (RTOS) and FPGA for Real-Time Simulation; the idle-speed loop uses PID Control and PWM (Pulse Width Modulation); the temperature/current failure cases connect to Fault Injection Testing and the sensor frames to CAN Bus Protocol; the test-level ranking touches Model-in-the-Loop (MIL), Software-in-the-Loop (SIL), Processor-in-the-Loop (PIL) and Vehicle-in-the-Loop (VIL).