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

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

Koi bhi symbol se pehle, poora loop dekho jo hum abhi build karne wale hain.

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

Real ECU (left, jis cheez ko hum test kar rahe hain) ek command bhejta hai. Simulator (right, ek computer jo motor hone ka dhong karta hai) ko sensor reading ke saath jawab dena hota hai. Arrows ek closed loop banate hain: output → input → output, hamesha ke liye. Humara poora kaam woh box hai jis pe "physics maths" likha hai — ek command ko ek honest reply mein badalna.

Step 1 — ECU ka command voltage mein badlo

KYA. ECU humein directly voltage nahi bhejta. Woh ek PWM duty cycle bhejta hai — $0$ aur $1$ ke beech ek single number jiska matlab hai "switch kitni fraction time ON hai". Signal ke liye PWM (Pulse Width Modulation) dekho.

KYUN. Motor ko voltage se drive kiya jaata hai, lekin ek microcontroller sasta smooth analog voltage nahi bana sakta. Uski jagah woh ek switch bahut tezi se on-off karta hai; motor ko jo average voltage milta hai woh fraction-on times battery voltage hota hai. Toh simulator ko sabse pehle woh trick ulti karni hoti hai aur average voltage recover karna hota hai.

PICTURE. Neeche, square PWM wave (upar) har period ka $70%$ ON hai. Uski flat average (dashed line) battery height ke $0.7$ pe baith jaati hai. Woh average hi hai jo motor actually "dekhta" hai.

Edge case. Agar $D = 0$ toh motor ko $0 V$ milta hai (fully coasting); agar $D = 1$ toh use poori battery milti hai. Formula naturally dono ends cover karta hai — koi special code nahi chahiye.

Step 2 — Voltage se current nikalo

KYA. Current woh hai jo actually motor ki wire mein flow karta hai jab hum use voltage se push karte hain.

KYUN yeh equation aur "sirf Ohm's law" nahi. Ek spinning motor wapas ladta hai. Jaise-jaise woh ghoomta hai, woh apna khud ka voltage generate karta hai jo supply ko oppose karta hai — yeh back-EMF hai. Toh effective push poora $V$ nahi hai, yeh $V$ minus motor ka apna counter-voltage hai. Sirf woh bacha hua push current ko wire ki resistance $R$ se guzaarta hai.

Hum inductance term bhi drop karte hain yahan. Poori physics mein ek $L \frac{d I}{d t}$ piece hota hai (wire changes in current ka resist karti hai), lekin agar woh term $R \cdot I$ ke comparison mein tiny hai, use ignore karna maths ko instant bana deta hai ek aur differential equation ki zaroorat ke bina. Woh trade — accuracy for speed — exactly wahi hai jo real-time demand karta hai.

PICTURE. Ek see-saw socho. Supply voltage $V$ ek side ko neeche push karta hai; back-EMF $K_{e} ω$ doosri side se wapas push karta hai. Farq woh hai jo current drive karne ke liye bacha rehta hai, aur resistance $R$ se divide karne pe pata chalta hai ki kitna current nikalta hai.

Intuition Fourth quadrant — jab motor generator ban jaata hai

Numerator $V - K_{e} ω$ ko dhyan se dekho. Kuch bhi ise positive hone pe majboor nahi karta. Agar motor applied voltage se zyada tezi se ghoom raha hai (jaise ECU suddenly $D$ drop karta hai, lekin rotor ki inertia use spinning rakhti hai), toh $K_{e} ω > V$ , numerator negative ho jaata hai, aur current $I$ bhi negative.

Negative $I$ ulti direction mein flow karta hai — motor se bahar, supply ki taraf wapas. Step 3 mein woh torque sign bhi flip kar deta hai, ek braking (regenerative) torque deta hai jo spin se ladhta hai aur battery mein energy pump bhi kar sakta hai. Exactly yahi electric-car regen braking kaam karta hai. Humara formula ise free mein handle karta hai: koi if nahi chahiye, kyunki subtraction already sign carry karti hai. (Spin direction) × (torque direction) ke chaar combinations motor ke four quadrants hain; yeh signed equation sab cover karta hai.

Step 3 — Current torque ban jaata hai

KYA. Torque woh twist hai jo motor jo bhi ghuma raha hai use apply karta hai.

KYUN. Magnetic field mein current-carrying wire ko ek force feel hoti hai (Lorentz force). Woh wire motor ke coils mein wind karo aur force ek twist ban jaati hai. Khoobsurat baat yeh hai: twist directly proportional hai current se — double current, double torque. Isse humein possible simplest line milti hai.

PICTURE. Ek straight-line graph: torque vertical axis pe, current horizontal pe, origin se guzarta hua slope $K_{t}$ ke saath. Woh origin se dono taraf guzarta hai: positive current → driving torque, negative current (regen, Step 2) → opposite direction mein braking torque.

Step 4 — Torque speed change karta hai (spinning cheezein ke liye Newton)

KYA. Ab hum twist ko actually rotor ko ek naye speed tak accelerate karne dete hain.

KYUN yeh ek differential equation hai. Force speed directly set nahi karta — woh speed ka change set karta hai. Newton's second law for rotation kehta hai: net twist = inertia × angular acceleration. Net twist motor ki push hai minus do cheezein jo ise rok rahi hain: ek external load aur friction jo speed ke saath badhti hai. Kyunki yeh humein $ω$ ka rate of change batata hai, humein next $ω$ paane ke liye integrate karna padta hai — aur sasta integrator ek single forward step (Euler) hai.

KYUN Euler aur kuch fancy nahi. Euler kehta hai: "new value = old value + (rate) × (time step)". Yeh ek multiply aur ek add hai — trivially fast, jo real-time deadline demand karti hai. Yeh clever solvers se kam accurate hai, lekin chhote enough $Δ t$ ke saath honest enough hai, aur cost mein predictable hai (koi adaptive step nahi jo deadline blow kare).

PICTURE. Speed-vs-time curve. Har tick pe hum current point pe khade hote hain, slope dekhte hain (net torque humein slope batata hai), aur us slope ke saath $Δ t$ ki ek chhoti straight step lete hain next point pe land karne ke liye.

Formula Speed update

$ω (t_{k + 1}) = ω (t_{k}) + \frac{Δ t}{J} (push τ_{motor} (t_{k}) - external drag τ_{load} - viscous friction b ω (t_{k}))$

$ω (t_{k + 1})$ ::: nayi speed jo hum next tick ko denge (yaad karo $t_{k + 1} = t_{k} + Δ t$ ).
$Δ t$ ::: ek simulation tick ki length, jaise $1 ms$ .
$J$ ::: rotor inertia — motor speed up karne mein kitna sluggish hai (kg·m²).
$τ_{motor} (t_{k})$ ::: Step 3 ka driving twist (negative ho sakta hai = braking).
$τ_{load}$ ::: external load torque — motor jis cheez ko push kar raha hai (pump, wheel, lifted arm pe gravity), N·m mein. Yeh motor ka "kaam" hai; free-spinning shaft ke liye $0$ set karo.
$b$ ::: viscous-damping coefficient (N·m·s/rad); jitna tez ghoomoge, utna zyada drag.

Notice karo poora bracket net twist hai. Jab push exactly load + friction balance kare, bracket zero hota hai, $ω$ change karna band → motor steady state pe aa jaata hai.

Degenerate case — $Δ t$ bahut bada. Agar $Δ t$ itna bada hai ki straight step wildly overshoot kare, simulated speed oscillate ya explode kar sakti hai jabki real motor calm hoti. Yeh numerical instability hai, physics nahi. Fix: $Δ t$ chhota karo, ya implicit (backward-Euler) step use karo. Exactly yahi wajah hai ki HIL rigs $1 - 10 kHz$ pe chalte hain.

Step 5 — Speed se position milti hai

KYA. Speed ko time ke saath add karo taaki pata chale shaft kitna ghuma hai.

KYUN. ECU ka sensor speed directly measure nahi karta — woh rotation count karta hai. Toh humein accumulated angle $θ$ track karna hota hai. Same Euler idea: new angle = old angle + speed × time.

PICTURE. Position ek staircase ki tarah chadhti hai: har tick pe, speed batata hai woh step kitni tall hai.

Step 6 — ECU jo sensor expect karta hai use fake karo

KYA. ECU ko $θ$ ka koi idea nahi hai. Woh sirf encoder pulses samajhta hai — ek real motor mein ek wheel hoti hai slots ke saath, aur ek sensor har slot pe once click karta hai. Humein apna clean angle us click count mein convert karna hoga.

KYUN floor function. Pulses poore clicks hote hain — $3.7$ pulses nahi ho sakte. Floor $⌊ \cdot ⌋$ fraction phenk deta hai, sirf complete clicks rakhta hai, exactly real hardware ki tarah. Yeh woh moment hai jab simulation pure maths rehna chhod deta hai aur kuch aisa ban jaata hai jo ek real pin produce kar sake.

PICTURE. Ek smooth angle ramp (upar) ek discrete pulse-count staircase mein chop hoti hai (neeche). Har baar jab angle ek aur $2 π / PPR$ slice cross karta hai, count ek se tick up hota hai.

Ye pulses I/O box ke digital output se ECU ke timer pin pe jaate hain — higher-level messages ke liye often CAN Bus Protocol jaisi bus se, lekin encoder ke liye raw pulses.

Step 7 — Deadline jo sab kuch ek saath baandhti hai

KYA. Steps 1→6 loop ka ek chakkar hai. Pakad: woh sab khatam ho jaane chahiye ECU ka agla control cycle shuru hone se pehle.

KYUN. ECU ka apna clock hai — maan lo woh har $1 ms$ mein sochta aur kaam karta hai. Agar humare saat steps compute karne mein $1 ms$ se zyada lagta hai, ECU ko stale sensor data milta hai. ECU ko aisa lagta hai jaise time slow ho gaya, aur uska PID Control loop unstable ho sakta hai — chahe physics perfect rahi ho. HIL mein correctness ka matlab hai correct aur waqt pe. Yahi wajah hai ki HIL ek Real-time Operating Systems (RTOS) ya ek FPGA for Real-Time Simulation pe chalta hai hard, guaranteed deadlines ke saath.

PICTURE. Ek timeline: har $Δ t$ slot mein poora compute block hona chahiye gunjaaish ke saath. Ek slot jo overflow kare (red) ek missed deadline hai — ek bug chahe numbers sahi the.

Ek-picture summary

Upar jo sab hai woh ek arrow hai jo apni khud ki tail chase kar raha hai: command → voltage → current → torque → speed → position → pulses → wapas ECU mein, sab ek $Δ t$ ke andar.

Recall Feynman retelling — seedhe shabdon mein wapas bolo

ECU 0 aur 1 ke beech ek number chillata hai jiska matlab hai "itna hard push karo". Hum (1) us fraction ko ek average voltage mein convert karte hain — yeh trust karte hue ki switch ek tick se bahut tezi se flip karta hai, toh motor average feel karta hai. Lekin motor already ghoom raha hai aur wapas push kar raha hai, toh (2) real push hamara voltage hai minus uski back-push, wire ki resistance se divide karo — yeh current hai; aur agar spin kabhi voltage se aage nikal jaaye, woh current negative ho jaata hai aur motor brake karta hai. (3) Zyada current matlab proportionally zyada twist (negative current → braking twist). (4) Woh twist, minus load jise hum drive kar rahe hain aur friction jo neeche kheench rahi hai, rotor ko ek time-step $Δ t$ mein thoda sa speed up karta hai — aur clock $t_{k + 1} = t_{k} + Δ t$ advance karta hai. (5) Thodi si zyada spin matlab thoda sa zyada angle ghuma. (6) Hum woh angle poore encoder clicks mein chop karte hain, kyunki yahi woh language hai jo ECU samajhta hai. (7) Hum woh clicks wapas bhejte hain — lekin tabhi jab un sab ke liye compute time $t_{compute}$ $Δ t$ ke andar raha, ECU ke agle heartbeat se pehle. Jab push finally drag balance kare, speed change karna band kar deti hai aur motor steadily idle karta hai, jo exactly woh moment hai jiske liye ECU ka controller hunt kar raha tha.

Single idea: ek simulator sirf ek bahut disciplined mirror hai — woh ECU ka command wapas reflect karta hai woh sensor reading ki tarah jo ek real motor produce karta, aur use ECU ke blink karne se pehle karna hota hai.

Sibling deep-dive pages surrounding ideas build karte hain: Model-in-the-Loop (MIL), Software-in-the-Loop (SIL) aur Processor-in-the-Loop (PIL) dikhate hain ki HIL fidelity ladder pe kahan baithta hai; Fault Injection Testing aur System Identification dikhate hain ki loop chalne ke baad tum us se kya karte ho.