Software-in-the-Loop (SIL) simulation — all software, simulated hardware: Visual walkthrough

5.5.22 · D2 · Coding › Embedded Systems & Real-Time Software › Software-in-the-Loop (SIL) simulation — all software, simula

Parent note ne tumhe SIL ka bada picture diya tha: apna real code ek maths se bani fake duniya ke against chalao. Yeh page bilkul slow ho jaata hai aur loop ko zero se build karta hai, ek arrow ek time, jab tak hum parent page ka sabse important formula prove nahi kar lete — woh fidelity criterion jo batata hai kab simulation ki prediction par trust kiya ja sakta hai.

Hum bilkul zero se shuru karte hain. Agar tumne kabhi feedback loop, time step, ya "solver" word nahi suna, tum bilkul sahi jagah ho.

Step 1 — "Loop" aakhir hota kya hai?

WHAT. Yahan ek loop matlab hai cause and effect ka ek circle jo chalte rehta hai: code duniya ko dekhta hai, kuch decide karta hai, duniya badal deta hai, aur phir dobara dekhta hai. Baar baar.

WHY. Har controller — ek thermostat, gaadi ke brakes, ek drone — isi tarah kaam karta hai. Woh ek baar decide karke nahi ja sakta; duniya chalti rehti hai, isliye code ko baar baar check karte rehna padta hai. Ise hum closed loop kehte hain: output wapas feedback ho jaata hai agle input ke roop mein.

PICTURE. Do boxes aur do arrows ek circle banate hue.

Do words jo tumhare pass hone chahiye baaki sab se pehle:

Controller

woh software jo decide karta hai kya karna hai (tumhara production code)

Plant

jis cheez ko control kiya ja raha hai — motor, car, room — uski physics ke saath

Step 2 — Loop ko wahan kato jahan wires hain

WHAT. Ek real system mein, do boxes physical wires se jude hote hain: ek sensor wire ek measured number code mein le jaati hai, ek actuator wire command bahar le jaati hai. Hum un do crossing points ko ek naam dete hain.

WHY. SIL ka poora trick bilkul inhi do crossing points par rehta hai. Agar hum jaante hain exactly kahan code hardware ko touch karta hai, hum exactly jaante hain kahan fake insert karna hai. Neeche har symbol inhi crossings mein se ek hai.

PICTURE. Wohi circle, ab do wires labeled hain aur ek scissors line mark kar rahi hai jahan hum cut karenge.

Us layer of code ka ek naam hai jo un do pins ko own karti hai — Hardware Abstraction Layer (HAL). Ise do doors ki tarah socho: read_sensor() tumhe $y$ deta hai, write_actuator(u) $u$ ko push karta hai bahar. Ise yaad rakho; yahi cheez hum Step 3 mein swap karte hain.

Step 3 — Duniya ko maths se replace karo (yahi hai SIL)

WHAT. Hum controller box ko exactly jaisa hai waisa rakhte hain aur physical plant box ko nikaal dete hain. Uski jagah hum ek plant model daalte hain: equations ka ek chhota bundle jo, current state aur command $u$ diya, next state aur next reading $y$ produce karta hai.

WHY. Yahi SIL ka poora idea hai. Controller abhi bhi read_sensor() aur write_actuator() call karta hai — wahi doors — lekin un doors ke peechhe ab copper ki jagah ek Python/MATLAB routine hai. Sabse zaroori baat, controller fark nahi bata sakta: woh $u$ deta hai, $y$ wapas pata hai, aur use pata hi nahi ki koi real motor kabhi chali nahi.

PICTURE. Wohi loop, plant box ab ek "maths cloud" ke roop mein redrawn; HAL doors real code (left) aur simulation (right) ke beech seam hain.

Symbols ko seedha wahan padhna jahan woh hain:

next state x_{n + 1} = F (state now x_{n}, command now u_{n})

$x_{n}$ — sab kuch jo tumhe story continue karne ke liye jaanna zaroori hai (speed, distance, temperature…). Subscript $n$ matlab "step number $n$ par".
$u_{n}$ — woh command jo tumhare controller ne step $n$ par produce ki.
$F$ — physics, arithmetic ke roop mein likhi.

Step 4 — Time computer ke andar continuous nahi hota

WHAT. Real plant time mein smoothly move karta hai. Tumhara computer nahi kar sakta; woh sirf instants par hi compute kar sakta hai. Isliye hum time ko equal slices of width $Δ t$ mein kaatein aur sirf yahi poochhte hain "step $0, 1, 2, \dots$ par state kya hai?"

WHY. Controller pehle se ek clock par rehta hai: woh ek fixed rate par jaagta hai (maan lo 100 times per second) aur har baar ek calculation karta hai. Hum wake-ups ke beech gap ko sample period $T_{sample}$ kehte hain. Plant ko controller ke saath step mein rakhne ke liye, hum plant ko har round mein same slice $Δ t$ se aage badhate hain.

PICTURE. True speed vs time ka ek smooth curve, computer ke samples dots ke roop mein ek staircase par land karte hue — continuous duniya ek stroboscope se dekhi.

time of step n t_{n} = step count n \cdot slice width Δ t

Step 5 — Physics ko aage step karne ka sabse sasta tarika: Euler

WHAT. Humein physicist ka rate law $\overset{x}{˙} = f (x, u)$ ("state rate $f$ se change hoti hai") ko ek rule mein badalna hai jo computer run kar sake. Sabse simple: assume karo ki rate ek slice ke across constant rehti hai, aur bas multiply karo.

WHY. Multiplication sasta aur instant hai. Yahi forward Euler method hai. Yeh sawaal ka jawaab deta hai "diye hue abhi cheezein kitni tezi se change ho rahi hain, ek slice baad hum kahan honge?" — sabse crude honest jawaab possible.

PICTURE. Ek slice mein zoom: true curve bend leti hai, lekin Euler starting slope ke along seedha chalta hai. Seedhe step aur true curve ke beech gap discretisation error hai.

where we land x_{n + 1} = start here x_{n} + slope now f (x_{n}, u_{n}) \cdot how long we walk Δ t

$f (x_{n}, u_{n})$ — slice ke shuru mein rate of change (physics se). Yeh ek derivative hai, ek baar evaluate kiya.
$\cdot Δ t$ — us slope ke along ek slice bhar time chalo.
Result $x_{n + 1}$ sirf approximately sahi hai, kyunki true slope slice ke during change hui jabki humne pretend kiya woh frozen tha.

Step 6 — Ek poora tick, symbol by symbol

WHAT. Ab Steps 3–5 ko loop ke ek single turn mein assemble karo aur numbers ko move karte dekho, parent note ke braking example use karke: car $100$ km/h par, obstacle $50$ m par.

WHY. Ek tick end-to-end dekhna prove karta hai ki pieces fit hote hain: measurement in → command out → state advanced → new measurement. Yahi SIL engine chalta hua hai.

PICTURE. Loop annotated pehle tick ke liye har arrow par real numbers ke saath.

Ek tick, $Δ t = 0.01$ s, ek simple plant $v_{n + 1} = v_{n} - \frac{u _{n} \cdot P _{m a x}}{m} Δ t$ aur $d_{n + 1} = d_{n} - v_{n} Δ t$ use karke:

new speed v_{n + 1} = 27.78 m/s v_{n} - \frac{u _{n} 0.8 \cdot P _{m a x} max decel}{mass m} Δ t

$P_{m a x} / m = 8 m/s^{2}$ (ek firm brake) maano. Toh:

Plant → Software: $y = v_{n} = 27.78$ m/s ( $= 100$ km/h), $d_{n} = 50$ m.
Software command compute karta hai $u_{n} = 0.8$ (80% pressure).
Software → Plant: $u_{n}$ apply karo.
Plant advance karta hai: $v_{n + 1} = 27.78 - (0.8 \cdot 8) (0.01) = 27.716$ m/s; $d_{n + 1} = 50 - 27.78 (0.01) = 49.722$ m.

Controller ab $27.716$ m/s aur $49.722$ m read karta hai — aur loop phir se ghoomta hai. Har arrow jo tumne dekha woh ek HAL call hai; data flow production jaisi hi hai even though koi wheel nahi chala. (calc_brake_force ki khud ki decision logic test karo Unit Testing for Embedded Systems se.)

Step 7 — Edge cases: jahan loop misbehave karta hai

WHAT. Ek derivation tabhi honest hai jab woh extremes survive kare. Teen degenerate inputs, teen outcomes.

WHY. SIL ki value yahi hai ki yeh extremes test karne ke liye free hain. Lekin har ek SIL ki ek limit bhi expose karta hai. Teeno dekho.

PICTURE. Teen mini-panels: (a) $Δ t$ bahut bada → numbers explode; (b) command saturate hota hai → state ek wall hit karta hai; (c) ek akela freak sensor spike joh model ne kabhi produce nahi kiya.

Case A — $Δ t$ bahut bada (instability). Agar kisi dynamic ka time constant $τ$ hai aur tum $Δ t ≳ τ$ pick karo, Euler overshoot karta hai, phir aur harder over-correct karta hai, aur $x_{n}$ $\pm \infty$ tak swing ho jaata hai. Plant model theek hai; tumhara solver villain hai. Fix: $Δ t$ chhota karo ya RK4 use karo (ek smarter 4-slope step).
Case B — saturation (ek healthy edge case). Command $u = 0.8$ lekin ek real actuator max out ho jaata hai; model clamp karta hai if v < 0: v = 0 (braking se car reverse nahi ho sakti). Yeh simulate karna ek achhi baat hai — yeh controllers mein integrator windup pakadta hai.
Case C — freak reading (SIL ka blind spot). Real sensors kabhi kabhi electrical interference se ek garbage value emit karte hain. Agar tumhara model sirf smooth $y$ produce karta hai, SIL kabhi woh spike generate nahi karega — toh ek crash-on-bad-reading bug invisible rehta hai. Yahi exactly woh gap hai jo Hardware-in-the-Loop (HIL) aur real Sensor Fusion Algorithms ko close karna hoga.

Step 8 — Teen errors stack karo: fidelity criterion

WHAT. Ab hum parent note ka central formula prove karte hain. SIL jo bhi prediction karta hai, usmein teen separate, additive sources of error hote hain. Inhe add karo aur tumhe "SIL kehta hai" aur "reality karta hai" ke beech total gap milta hai.

WHY. Yeh single inequality batata hai kab SIL par trust karna hai aur kab PIL/HIL par move on karna hai. Yeh poore page ka payoff hai.

PICTURE. Teen stacked coloured bars — model, discretisation, abstraction — ek total error bar mein add hote hue, ek dashed "acceptable" threshold line ke saath.

Formula Simulation fidelity criterion

SIL kitna galat hai Error_{pred} \leq plant equations imperfect Error_{model} + Euler / Δ t (Step 5) Error_{disc} + effects jo tumne chhod diye (Step 7C) Error_{abstr}

Model error — tumhare equations true physics nahi hain (cogging torque, friction ignore kiya). Step 3 ke $F$ se traced.
Discretisation error — Step 5 se $O (Δ t^{2})$ ka jhooth. $Δ t$ ke saath shrink hota hai.
Abstraction error — real-world chaos jo tumne kabhi model nahi kiya: Step 7C ka spike, timing jitter, voltage sag. $Δ t$ ke saath shrink nahi hota — ise reduce karne ke liye tumhe ek model add karna padega.

Conclusion: SIL necessary but not sufficient hai. Yeh prove karta hai ki algorithm logically sahi hai; yeh prove nahi kar sakta ki woh real duniya mein survive karega. Jab Error $_{abstr}$ dominate kare, SIL apna kaam kar chuka hai — HIL ko hand off karo.

Ek-picture summary

Poora page ek frame mein: tumhara real controller (untouched) HAL doors se baat karta hai ek plant model se jo Euler ke zariye ek $Δ t$ at a time aage step karta hai, loop close karta hai — jabki teen error bars neeche quietly accumulate hote rehte hain, decide karte hain ki prediction par trust kiya ja sakta hai ya nahi.

Recall Feynman retelling — plain words mein wapas bolo

Main apna controller code hardware kharide bina test karna chahta hoon. Ek controller bas ek measured number khaata hai aur ek command ugalta hai, hamesha, ek circle mein — yahi closed loop hai. Sirf do jagah hain jahan code duniya ko touch karta hai: ek door jo use reading deta hai, ek jo uska command leta hai (HAL). Toh main apna code exactly jaisa hai waisa rakhta hoon aur un doors ke peechhe real wires ki jagah equations ka bunch daal deta hoon. Code fark nahi bata sakta.

Lekin computer time mein smoothly flow nahi kar sakta, isliye main time ko equal slices $Δ t$ mein kaatta hoon. Physics ko ek slice aage move karne ke liye main sabse crude trick use karta hoon: dekho cheezein abhi kitni tezi se change ho rahi hain, assume karo ki woh rate poore slice bhar chalegi, aur multiply karo — yahi Euler hai. Yeh har step thoda galat hota hai, roughly $Δ t^{2}$ galat, aur agar main $Δ t$ bahut bada banaata hoon toh numbers explode kar jaate hain. Main ek tick run karta hoon — reading in, command out, state advanced — aur repeat karta hoon.

Phir main extremes check karta hoon: bahut-bada $Δ t$ blow up ho jaata hai (solver ki galti), ek limit hit karna jaise clamped brake ek achha test hai, lekin ek random garbage sensor spike kuch aisa hai jo mere smooth equations kabhi produce nahi karenge — isliye SIL usse blind hai. Apni saari galatiyan add karne se teen bars milte hain: mere equations imperfect hain, mera time-stepping imperfect hai, aur maine real-world chaos ignore kiya. Agar aakhri bar bada hai, SIL ne jo kar sakta tha sab kar liya, aur ab real silicon aur real I/O ka time hai. SIL prove karta hai ki meri logic sahi hai — yeh nahi ki woh reality mein survive karega.