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

5.5.21 · D3 · Coding › Embedded Systems & Real-Time Software › Hardware-in-the-Loop (HIL) simulation — real hardware, simul

Yeh page ek practice arena hai. Parent note ne theory build ki (real ECU, simulated plant, real-time deadline, motor update equations). Yahan hum har tarah ki situation ke through grind karte hain jo ek HIL problem throw kar sakta hai — normal numbers, zero inputs, degenerate cases, timing jo barely fail hoti hai, aur exam ke woh twists jo logon ko pakad lete hain.

Shuru karne se pehle, ek reminder plain words mein: HIL mein, ek real controller (ECU — woh chota sa computer jo ek real car ke andar hota) ko fool kiya jaata hai ki woh real motors aur sensors se baat kar raha hai. Sachchi baat mein woh ek simulator se baat karta hai — ek doosra computer jo physics equations ko itni tez solve karta hai ki ECU ke dobara poochne se pehle jawab de sake. Neeche ke har example is hi loop ke andar rehte hain.

Upar ki picture woh loop hai jise har example ek moment par freeze karta hai: ECU ek command emit karta hai, I/O box use simulator tak le jaata hai, simulator apni physics karta hai, I/O box ek sensor value wapas le jaata hai. Ise yaad rakho — har example is ring ka ek arrow hai.

---

Scenario matrix

Har HIL problem jo tumhe milegi woh in case classes mein se ek mein fit hogi. Neeche ka map unhe arrange karta hai; har numbered example us cell ke saath tagged hai jo woh cover karta hai, toh end mein tumne har box ko touch kar liya hoga.

Case class	Kya cheez mushkil banati hai	Covered by
A. Normal closed loop	ordinary numbers, sab kuch range mein	Ex 1
B. Real-time deadline PASS	compute time comfortably step se kam	Ex 2
C. Real-time deadline FAIL	simulator bahut slow → loop toot jaata hai	Ex 3
D. Zero / degenerate input	duty cycle $=0$, ya start par $\omega =0$	Ex 4
E. Sign / direction flip	negative torque, motor ulta ghoom raha hai	Ex 5
F. Signal-conversion limits (clip, both rails)	sensor voltage $0\text{ V}$ ya $5\text{ V}$ hit karti hai; current $I_{\text{max}}$ hit karta hai	Ex 6
G. Real-world word problem	full idle-speed scenario, settling time	Ex 7
H. Exam-style twist	"SIL yeh kyun miss karta hai par HIL kyun pakadta hai?"	Ex 8
I. Limiting / steady-state	$t\to \infty$, kaunsi speed par settle hoga?	Ex 9

Hum numeric cases ke liye ek DC-motor plant reuse karte hain taaki numbers comparable rahein. Iske constants (sab invented but consistent):

Yeh parent note ki quasi-static update chain mein plug ho jaate hain (inductance term $L\frac{dI}{dt}$ dropped, jaise upar define kiya):

$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: pehle guess karo — speed upar jayegi, neeche, ya same rahegi? (Hint: kya motor ko back-EMF se zyada push kiya ja raha hai?)

1. PWM se voltage. $V=D{V}_{\text{batt}}=0.7\times 12=8.4\text{V}$. Yeh step kyun? PWM duty cycle woh ek hi cheez hai jo ECU physically simulator ko deta hai; baaki sab isi se flow karta hai.

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}$. Yeh step kyun? Voltage minus back-EMF resistance ke across net push hai; Ohm's law ise current mein convert karta hai. ($1.7\text{ A}<I_{\text{max}}=5\text{ A}$, toh yahan koi clamp nahi chahiye.)

3. Torque. $\tau =K_{t}I=0.05\times 1.7=0.085\text{N⋅m}$. Yeh step kyun? Current torque banata hai — yeh woh Lorentz-force link hai jo actually shaft ko spin karta hai.

4. Nayi 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}$. Yeh step kyun? Newton's law kehta hai net torque over inertia angular acceleration hai; Euler us time step se multiply karta hai ek tick advance karne ke liye.

Verify: net torque $0.075\text{N⋅m}$ positive hai, toh speed badhti hai — forecast se match karta hai ki $8.4\text{ V}$ $5\text{ V}$ back-EMF ko overpower karta hai. Units: $\frac{\text{s}}{{\text{kg⋅m}}^2}\cdot \text{N⋅m}=\frac{\text{N⋅m⋅s}}{{\text{kg⋅m}}^2}=\text{rad/s}$ ✓ (kyunki $\text{N⋅m}={\text{kg⋅m}}^2/{\text{s}}^2$). Nayi speed $100.075\text{rad/s}$.

---

Example 2 — Deadline PASS [Case B]

Forecast: dono times add karo, step se compare karo. Pass ya fail?

1. Total compute. $t_{\text{compute}}=180+120=300\mu \text{s}$. Yeh step kyun? Deadline sab kuch cover karta hai ECU command receive karne aur sensor answer deliver karne ke beech — compute aur I/O dono.

2. Available budget. $\Delta t=1\text{ ms}=1000\mu \text{s}$. Yeh step kyun? ECU har $1\text{ ms}$ mein dobara poochta hai; jawab us se pehle ready hona chahiye.

3. Compare aur utilisation lo. $\text{utilisation}=\frac{t_{\text{compute}}}{\Delta t}=\frac{300}{1000}=0.30=30\%$. Slack $=700\mu \text{s}$. Yeh step kyun? Parent note ka real-time law hai $t_{\text{compute}}<\Delta t$; utilisation bas ise re-express karta hai ki "humne tick ka kitna fraction jaala?" — $30\%$ $100\%$ se kaafi kam hai.

Verify: $30\%$ utilisation matlab $70\%$ headroom, toh koi time dilation nahi — ECU kabhi notice nahi karta ki woh simulation mein hai. PASS.

---

Example 3 — Deadline FAIL [Case C]

Forecast: total vs. budget phir se — lekin is baar socho ECU kya experience karta hai.

1. Total. $t_{\text{compute}}=950+120=1070\mu \text{s}$. Yeh step kyun? Same accounting; galti sum mein dikhegi.

2. Compare. $1070\mu \text{s}>1000\mu \text{s}$. Overrun $=70\mu \text{s}$, utilisation $=107\%$. Yeh step kyun? $100\%$ utilisation cross karna ek missed hard deadline ki definition hai.

3. Consequence. Simulator last-tick sensor values late deliver karta hai. ECU stale encoder counts padhta hai, old data par control compute karta hai, aur closed loop unstable ho sakta hai (woh "time dilation" jo parent note mein warn kiya gaya tha). Yeh step kyun? HIL tabhi honest rehta hai jab simulation keep up kare; ek baar lag hone par results meaningless hain.

Verify: $1070>1000$ overrun confirm karta hai; $70\mu \text{s}$ ki deficit ka matlab hai solver ko speed up karo (fixed-step, lookup tables, FPGA) ya loop slow karo. Fixes ke liye dekho FPGA for Real-Time Simulation aur Real-time Operating Systems (RTOS)। FAIL.

---

Example 4 — Zero / degenerate input [Case D]

Forecast: zero volts aur zero speed ke saath, kya kuch move karta hai?

1. Voltage. $V=0\times 12=0\text{V}$. Yeh step kyun? Duty cycle zero matlab PWM fully off hai — bilkul koi drive nahi.

2. Current. $I=\frac{0-0.05\times 0}{2}=\frac{0}{2}=0\text{A}$. Yeh step kyun? Hum $R=2$ se divide karte hain, kisi aisi cheez se nahi jo zero ho sakti — toh formula rest par bhi safe rehta hai. Yeh degenerate check hai.

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}$. Yeh step kyun? Koi current nahi → koi torque nahi → koi change nahi; motor correctly still rehta hai.

Verify: sab zeros, koi division by zero nahi (sirf denominator $R$ hai, ek fixed constant), speed unchanged at $0\text{rad/s}$. Ek HIL rig jo yahan garbage produce karta woh Example 7 ke step 1 mein boot-sequence test fail karta. Clean.

---

Example 5 — Sign / direction flip [Case E]

Forecast: drive voltage ko back-EMF se compare karo. Kaunsa bada hai?

1. Voltage. $V=0.5\times 12=6\text{V}$. Yeh step kyun? Tug-of-war ki drive side set karta hai.

2. Back-EMF. $K_e\omega =0.05\times 200=10\text{V}$. Yeh step kyun? Ek spinning motor apna khud ka voltage generate karta hai jo supply ka virodh karta hai; yahan yeh supply se bada hai.

3. Current (negative ho jaata hai). $I=\frac{6-10}{2}=\frac{-4}{2}=-2\text{A}$. Yeh step kyun? Sign flip ho jaata hai — current ab ulta flow karta hai, matlab motor ek generator ki tarah act karta hai (braking). Ek HIL model ko yeh sign handle karna hi chahiye, warna braking scenarios galat test honge. ($|-2|<I_{\text{max}}$, koi clamp nahi.)

4. Nayi 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}$. Yeh step kyun? Negative torque plus damping decelerate karta hai — motor slow hota hai, jaise physics demand karta hai.

Verify: speed $200$ se $199.88\text{rad/s}$ par drop hui; current sign negative hai → regenerative braking sahi se capture hua. Sanity: back-EMF ($10\text{ V}$) $>$ drive ($6\text{ V}$) ⇒ braking ✓.

---

Example 6 — Signal & current limits: dono rails aur current ceiling [Case F]

Forecast: linear encoding $0$ se neeche aur $5$ se upar jaane ke liye khush hai — lekin hardware nahi. Teen temperatures mein se kaun clip hoga guess karo, aur kya stall current $I_{\text{max}}$ se aage nikal jaata hai.

Part (a): dono 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 decode karta hai $T=5.0/0.02=250\text{°C}$. Yeh step kyun? DAC apni top rail par saturate ho jaati hai; $250\text{ °C}$ se upar har temperature same $5\text{ V}$ read karta hai — ek 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 decode karta hai $T=0/0.02=0\text{°C}$. Yeh step kyun? Ek DAC $0$–$5\text{ V}$ pin par negative volts output nahi kar sakta, toh yeh $0\text{ V}$ par floor ho jaata hai — ECU sochta hai ki $0\text{ °C}$ hai jabki plant actually $-40\text{ °C}$ par hai. Yeh lower-rail case upper rail jitna hi real hai aur ECU ke liye equally invisible.

3. In range — koi clip nahi. $V_{\text{ideal}}=0.02\times 120=2.4\text{V}$, $[0,5]$ ke andar, toh $V_{\text{out}}=2.4\text{V}$ aur $T=2.4/0.02=120\text{°C}$ exactly decode ho jaata hai. Yeh step kyun? Dikhata hai ki encoding sirf rail window ke andar faithful hai; fix yeh hai ki rescale karo taaki poora $-40$ to $300\text{ °C}$ span $0$–$5\text{ V}$ mein map ho.

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}$. Yeh step kyun? Standstill par koi back-EMF nahi hota, toh full supply current drive karta hai — yeh worst case hai jo winding ko stress karta hai.

5. Ceiling tak clamp. $6\text{A}>I_{\text{max}}=5\text{A}$, toh ek faithful model output karta hai $I=\min (6,5)=5\text{A}$, deta hai $\tau =K_t\times 5=0.25\text{N⋅m}$. Yeh step kyun? Real drivers current-limit karte hain; agar HIL model $6\text{ A}$ jaane deta toh over-predict karta torque aur miss karta ECU ki over-current protection logic (Fault Injection Testing target).

Verify (a): hot $250\text{ °C}$ read karta hai (rail $5\text{ V}$) ✓; cold $0\text{ °C}$ read karta hai (rail $0\text{ V}$) ✓; in-range $120\text{ °C}$ exactly decode hota hai ✓ — dono rails aur clean middle sab dikhaye. Verify (b): $I_{\text{raw}}=6\text{ A}$ clamp hota hai $5\text{ A}$ tak, $\tau =0.25\text{ N⋅m}$; bina clamp ke torque hota $0.30\text{ N⋅m}$, ek $20\%$ over-estimate.

---

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

Forecast: sequence par nazar daalo — kya $800$ se doori kum ho rahi hai, ya badh rahi hai?

1. PASS band. $800\pm 20=[780,820]\text{RPM}$. Yeh step kyun? Test ka acceptance criterion ek fixed window hai; last value ko iske andar land karna chahiye.

2. Last value check karo. $806\in [780,820]$ ✓ → final reading par PASS. Yeh step kyun? Yahi literally parent ke Example 1 ka PASS criterion hai.

3. Damping = setpoint ke baare mein error kam hoti hai. Settling ka sahi measure error hai $e_k=|{\text{speed}}_k-800|$, yaani har sample target se kitna door hai, step-to-step jump nahi. Compute karo: $e_0=|780-800|=20$, $e_1=|840-800|=40$, $e_2=|792-800|=8$, $e_3=|806-800|=6$. Pehle cranking transient ke baad errors $40\to 8\to 6$ fall karte hain — ek shrinking magnitude jo $800$ ko dono sides se straddle karta hai. Woh decaying, alternating-sign error ek damped (stable, settling) oscillation ka textbook signature hai. Yeh step kyun? Parent ne warn kiya tha ki growing $800\to 850\to 750$ swing matlab $K_p$ bahut high hai. Sahi test yeh hai ki error envelope decay kare; yahan karta hai, toh PID gains healthy hain.

4. Unit conversion. $\omega =800\text{RPM}\times \frac{2\pi }{60}=\frac{800\times 2\pi }{60}\approx 83.78\text{rad/s}$. Yeh step kyun? Hamare plant equations $\text{rad/s}$ use karte hain; convert karne se idle target seedha motor model ko feed ho sakta hai.

Verify: last value $806$, $[780,820]$ ke andar ✓; setpoint errors $40\to 8\to 6$ transient ke baad decrease ho rahe hain ✓ (damped); $800\text{RPM}=83.78\text{rad/s}$ (check: $83.78\times 60/(2\pi )\approx 800$ ✓). Is response ke peeche tuning ke liye dekho PID Control.

---

Example 8 — Exam-style twist [Case H]

Forecast: bug real silicon par real timing ke baare mein hai, ek live loop ke andar. Har level se do yes/no sawaal poochho — kya yeh real hardware run karta hai? kya yeh real-time loop close karta hai? — aur answers unhe rank karne do.

1. MIL — miss karega. Controller abhi bhi sirf ek block-diagram model hai jo PC par run karta hai; koi code nahi, koi processor nahi, koi ISR nahi. $30\mu \text{s}$ lateness ke liye koi jagah nahi hai. Yeh step kyun? Tum ek hardware-timing bug ko kisi aisi cheez par reproduce nahi kar sakte jisme zero hardware ho.

2. SIL — miss karega. Ab actual C code compile aur run hota hai, lekin PC par, target chip par nahi. PC timing ka microcontroller ki ISR latency se koi relation nahi, toh phir bug kabhi fire nahi hota. Yeh step kyun? SIL logic check karta hai, real interrupt timing nahi — bilkul wahi cheez jis par yeh bug depend karta hai.

3. PIL — partially. Code real processor par run karta hai, toh ISR aur uska $30\mu \text{s}$ lateness ab genuinely occur karta hai aur variable corrupt kar sakta hai. Lekin plant abhi bhi PC se feed kiye gaye numbers hain, live real-time closed loop nahi, toh tum corruption dekh sakte ho uske full physical consequence ke bina. Yeh step kyun? PIL real silicon add karta hai (cause pakadta hai) lekin real-time signals nahi (effect nahi dikhata).

4. HIL — poori tarah pakadta hai. Real ECU aur ek live closed loop: ISR genuinely microcontroller par late fire hoti hai, shared variable corrupt karta hai, ECU ek wrong actuator command emit karta hai, real-time plant simulator us wrong command par react karta hai aur altered sensor values wapas feed karta hai — toh fault visibly wrong closed-loop behaviour ke roop mein dikhti hai (jaise log par speed glitch). Yeh step kyun? HIL pehla level hai jisme dono real hardware timing aur live physical loop hain — exactly woh do ingredients jo is bug ko ek observable failure banane ke liye chahiye.

Verify: detection strength rank karta hai HIL $>$ PIL $>$ SIL $=$ MIL ek hardware-timing bug ke liye. Do boolean tests decide karte hain — "real chip?" (false, false, true, true) aur "live real-time loop?" (false, false, false, true) — aur HIL hi ek level hai jo dono par true score karta hai. Yeh parent note ke promise se match karta hai ki HIL "works in simulation but fails in hardware surprises" eliminate karta hai. Closure: jitna right test ko real hardware plus real signals ki taraf push karo, utne zyada timing-and-integration faults expose honge — yehi precisely woh reason hai ki HIL exist karta hai. (Iske around ek real vehicle add karo aur tum Vehicle-in-the-Loop (VIL) tak pahunch jaate ho.)

---

Example 9 — Limiting / steady state [Case I]

Forecast: steady state par, acceleration zero hai — toh net torque kya hona chahiye?

1. Acceleration ko zero set karo. Steady state matlab ${\omega }_{k+1}={\omega }_k$, toh update mein bracket vanish hona chahiye: $\tau -b\omega =0$. Yeh step kyun? Limit ka poora point yahi hai: Euler increment vanish ho jaata hai, ek algebra equation bacha rehta hai, aur stepping band ho jaati hai.

2. $\omega$ ke terms mein torque expand karo. $I=\frac{V-K_e\omega }{R}$ aur $\tau =K_{t}I$ ke saath: $K_t\cdot \frac{V-K_e\omega }{R}-b\omega =0.$ Yeh step kyun? Hum single unknown $\omega$ mein ek equation chahte hain.

3. ${\omega }_{\infty }$ solve karo. ${\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}.$ Yeh step kyun? Rearrange karne se steady speed isolate hoti hai; shared constants plug karne se woh number milta hai jis par HIL log asymptote hona chahiye.

Verify: $\omega =155.56$ par: back-EMF $=0.05\times 155.56\approx 7.78\text{ V}$, current $=(8.4-7.78)/2\approx 0.311\text{ A}$ ($I_{\text{max}}$ se kaafi kam), torque $\approx 0.01556\text{ N⋅m}$, damping torque $=0.0001\times 155.56\approx 0.01556\text{ N⋅m}$ — equal, toh net torque $\approx 0$ ✓. Steady state $155.56\text{rad/s}$, aur note karo ki yeh Example 1 ke one-step $100.075$ se upar baithta hai, confirm karta hai ki motor abhi bhi wahan accelerate kar raha hai.

---

Recall Quick self-test

$D=0.7,\omega =100$ par one-step new speed (Ex 1)? ::: $100.075\text{rad/s}$ Utilisation jab compute$=300\mu s$, step$=1\text{ms}$ (Ex 2)? ::: $30\%$, PASS Overrun jab compute$=1070\mu s$, step$=1000\mu s$ (Ex 3)? ::: $70\mu \text{s}$, FAIL Current sign jab back-EMF ($10$V) drive ($6$V) ko beat kare (Ex 5)? ::: negative, $-2\text{A}$ (braking) Cold $-40°C$ ko $0$–$5$V pin par encode karne se kya read hoga (Ex 6)? ::: $0°C$ (lower rail par floored) $D=1,\omega =0$ par stall current clamp se pehle/baad (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: yahan ki plant math parent HIL note se aati hai; timing budget Real-time Operating Systems (RTOS) aur FPGA for Real-Time Simulation se link karta hai; idle-speed loop PID Control aur PWM (Pulse Width Modulation) use karta hai; temperature/current failure cases Fault Injection Testing se connect karte hain aur sensor frames CAN Bus Protocol se; test-level ranking Model-in-the-Loop (MIL), Software-in-the-Loop (SIL), Processor-in-the-Loop (PIL) aur Vehicle-in-the-Loop (VIL) ko touch karti hai.