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

(b). In both SIL and HIL the plant is simulated (so (a) is true of both — not a distinguishing feature). PID and automation appear in many test styles. The unique HIL signature is that the production ECU/microcontroller executes real firmware, exchanging real electrical signals. Compare the ladder: Model-in-the-Loop (MIL) (all model), Software-in-the-Loop (SIL) (code on PC), Processor-in-the-Loop (PIL) (code on target CPU, no real I/O), then HIL (target + real I/O).

$\Delta t=\frac{1}{f}=\frac{1}{2000\text{ Hz}}=0.0005\text{ s}=0.5\text{ ms}.$

$V=D\cdot V_{\text{batt}}=0.7\times 12=8.4\text{ V}.$ Why: PWM's average delivered voltage is duty cycle times supply — this is exactly the first step the simulator does when it reads the ECU's PWM pin.

$I=\frac{V-K_e\omega }{R}=\frac{8.4-(0.05)(20)}{2}=\frac{8.4-1.0}{2}=\frac{7.4}{2}=3.7\text{ A}.$ Why quasi-static: we dropped the $LdI/dt$ inductance term because it is tiny compared to $RI$, which lets the simulator finish inside $\Delta t$.

${\tau }_{\text{motor}}=K_t\cdot I=0.05\times 3.7=0.185\text{ N⋅m}.$

The Euler update from the parent note: $\omega (t_{k+1})=\omega (t_k)+\frac{\Delta t}{J}({\tau }_{\text{motor}}-{\tau }_{\text{load}}-b\omega (t_k)).$ Net torque: ${\tau }_{\text{net}}=0.185-0.05-(0.001)(20)=0.185-0.05-0.02=0.115\text{ N⋅m}.$ Acceleration $\times$ step: $\frac{\Delta t}{J}{\tau }_{\text{net}}=\frac{0.001}{0.01}\times 0.115=0.1\times 0.115=0.0115\text{ rad/s}.$ $\omega (t_{k+1})=20+0.0115=20.0115\text{ rad/s}.$ What it looks like: in the figure the shaft speed nudges up by a hair because net torque is positive — the tiny slope segment over one $\Delta t$.

$\text{RPM}=\omega \cdot \frac{60}{2\pi }.$ $20\cdot \frac{60}{2\pi }=\frac{1200}{2\pi }\approx 190.986\text{ RPM}.$ $20.0115\cdot \frac{60}{2\pi }\approx 191.096\text{ RPM}.$

$\text{utilization}=\frac{t_{\text{compute}}}{\Delta t}=\frac{0.85}{1.0}=0.85=85\%.$ Since $0.85\text{ ms}<1\text{ ms}$, the law $t_{\text{compute}}<\Delta t$ holds — valid, but with only $15\%$ headroom. Cutting it close: a slower branch (e.g. a fault-injection path) could blow the deadline. See Real-time Operating Systems (RTOS).

(a) Total: $t_{\text{compute}}=0.18+0.09+0.15=0.42\text{ ms}.$ (b) $0.42<0.5$ → valid, headroom $0.08\text{ ms}$ ($16\%$). (c) The fastest step you can sustain has $\Delta t=t_{\text{compute}}$, so $f_{\max }=\frac{1}{0.42\text{ ms}}=\frac{1}{0.00042\text{ s}}\approx 2380.95\text{ Hz}\approx 2.38\text{ kHz}.$ Above that, compute overruns the step and the ECU sees frozen sensors.

Plan (this is Fault Injection Testing layered on HIL):

1. Bring engine to steady $800\text{ RPM}$ idle in the plant model.
2. Inject fault: command the I/O box's DAC to drive the TPS line to $0\text{ V}$ (or float it) — simulating a broken sensor wire.
3. ECU's diagnostic reads an implausible/out-of-range TPS.
4. ECU should set a fault code and enter limp-home (fixed safe throttle map).
5. Plant responds; measure engine speed and the throttle-motor PWM. PASS criterion: within $500\text{ ms}$ of injection the ECU (a) raises the diagnostic flag and (b) keeps engine speed within a safe band (no stall, no runaway). The figure shows the closed loop with the red fault-injection tap cutting into the sensor path. Why HIL and not SIL here: the fault lives in the electrical signal path (open circuit, wrong voltage). Only real I/O hardware can reproduce that; a pure-software Software-in-the-Loop (SIL) rig cannot break a wire.

Step k = 0 (${\omega }_0=0$):

• Error $=20-0=20$. $D=\text{clip}(0.1\times 20,0,1)=\text{clip}(2.0,0,1)=1.0$ (saturated).
• $V=1.0\times 12=12\text{ V}$.
• $I=(12-0.05\cdot 0)/2=6.0\text{ A}$.
• ${\tau }_{\text{motor}}=0.05\times 6.0=0.30\text{ N⋅m}$.
• ${\tau }_{\text{net}}=0.30-0.05-0.001\cdot 0=0.25\text{ N⋅m}$.
• ${\omega }_1=0+\frac{0.001}{0.01}(0.25)=0.1\times 0.25=0.025\text{ rad/s}$.

Step k = 1 (${\omega }_1=0.025$):

• Error $=20-0.025=19.975$. $D=\text{clip}(0.1\times 19.975,0,1)=1.0$ (still saturated).
• $V=12\text{ V}$.
• $I=(12-0.05\cdot 0.025)/2=(12-0.00125)/2=5.999375\text{ A}$.
• ${\tau }_{\text{motor}}=0.05\times 5.999375=0.29996875\text{ N⋅m}$.
• ${\tau }_{\text{net}}=0.29996875-0.05-0.001\cdot 0.025=0.24994375\text{ N⋅m}$.
• ${\omega }_2=0.025+0.1\times 0.24994375=0.025+0.024994375=0.049994375\text{ rad/s}$.

Reading it: at start the error is huge, so the P-controller slams the duty cycle to its ceiling ($D=1$, saturated). The shaft crawls up from rest — realistic, because inertia $J$ resists sudden speed. Only much later (as $\omega \to 20$) will $D$ come off the rail and the loop settle.

(a) On the unlucky slice both run: $t_{\text{compute}}=0.06+0.30=0.36\text{ ms}$, but the slice budget is only $0.1\text{ ms}$. Since $0.36>0.1$, it overruns by $3.6\times$ — invalid. Even the electrical-only slices are fine ($0.06<0.1$); the mechanical burst is what kills it. (b) Multi-rate / multi-tasking simulation: run the electrical model in a fast $0.1\text{ ms}$ task and the mechanical model in a slower $1\text{ ms}$ task, on separate cores or a hard-real-time scheduler (Real-time Operating Systems (RTOS)), so the heavy mechanical work never lands inside a single fast slice. Hardware option: offload the stiff, deterministic electrical ODE to an FPGA for Real-Time Simulation running in parallel at sub-microsecond rates, freeing the CPU. That is exactly why FPGAs appear in high-end HIL rigs.

HIL's defining feature vs SIL ::: the controller runs on the real target hardware with real I/O The real-time validity law ::: $t_{\text{compute}}<\Delta t$ Max sustainable update rate ::: $f_{\max }=1/t_{\text{compute}}$ Convert rad/s to RPM ::: multiply by $60/(2\pi )$ Fix for a stiff fast sub-model that overruns ::: multi-rate scheduling and/or an FPGA co-processor Why back-EMF must be subtracted ::: current feels only leftover voltage $V-K_e\omega$