Exercises — Software-in-the-Loop (SIL) simulation — all software, simulated hardware

Answer: (b). "Loop" ek closed-loop feedback path hai. Neeche figure dekho: do boxes hain — left mein Software (SUT) aur right mein Plant model. Red arrow follow karo — yeh woh command $u$ hai jo software bahar bhejta hai. Phir black arrow wapas follow karo — yeh woh sensor value $v$ hai jo plant return karta hai, jo software ka next input ban jaata hai. Kyunki output loop hokar next input ban jaata hai, data-flow ek closed circle form karta hai — woh circle hi "loop" hai, code mein koi for-loop nahi.

Figure L1.1: closed SIL feedback loop. Red = command signal (key object); black = returned sensor signal jo cycle band karta hai.

(a) ek distractor hai: kisi bhi program mein for loops hote hain. (c) developer ke workflow ko describe karta hai, runtime signal path ko nahi.

1→B, 2→C, 3→A, 4→D.

• SUT (1→B): woh real code jo tum ship karoge.
• Plant model (2→C): equations jo motors/sensors ko replace karti hain.
• Cosim framework (3→A): woh orchestrator jo dono clocks ko step karta hai.
• HAL (4→D): Hardware Abstraction Layer — woh seam jo same core logic ko PC (SIL) ya MCU (production) dono par sirf yeh layer swap karke run karti hai.

Nahi. Ek linear model mein koi saturation limit nahi hoti, isliye actuator command kabhi clamp nahi hoti — windup condition (command max par pinned rehna jab error integrate hota rahe) kabhi occur hi nahi hoti. Tumhe ek high-fidelity model chahiye jisme if speed > max_rpm: speed = max_rpm jaisi limit ho.

Kya karein: current state par derivative evaluate karo, phir aage step karo. $\dot{v}=\frac{Ku-v_0}{\tau }=\frac{100(1)-0}{0.5}=200{\text{rad/s}}^2$ Euler kyun aur kuch fancy kyun nahi? Euler sabse sasta solver hai — ek derivative evaluation per step. Pehli nazar ke liye theek hai; iska cost accuracy hai, jo L3 mein address hoti hai. $v_1=v_0+\dot{v}\Delta t=0+200\times 0.1=\boxed{20\text{rad/s}}$

Derivative dobara evaluate kyun karein? "In-the-loop" ka poora point yahi hai ki naya state next step ko feed karta hai. $\dot{v}=\frac{100(1)-20}{0.5}=\frac{80}{0.5}=160$ $v_2=v_1+160\times 0.1=20+16=\boxed{36\text{rad/s}}$ Dhyan do increment chhota ho gaya ($20\to 16$): model apni steady value $Ku=100$ ki taraf approach kar raha hai. Woh steady value ki taraf lag exactly woh dynamic behaviour hai jo ek medium-fidelity model (upar box mein define kiya gaya — first-order $\dot{v}=(Ku-v)/\tau$ rule) reveal karne ke liye exist karta hai, aur jo low-fidelity speed = K*u model bilkul miss kar deta.

Units pehle kyun convert karein? Model ke terms metres aur seconds (SI) mein hain. km/h ko ek formula mein mix karna jo m/s expect karta hai, physics ko silently galat scale kar dega — ek classic SIL unit bug jo low-fidelity check pakadne ke liye exist karta hai. Conversion factor: $1\text{km}=1000\text{m}$ aur $1\text{h}=3600\text{s}$, isliye $1\frac{\text{km}}{\text{h}}=\frac{1000\text{m}}{3600\text{s}}=\frac{1}{3.6}\frac{\text{m}}{\text{s}}.$ Isliye $v_0=100\times \frac{1}{3.6}=\frac{100}{3.6}=\frac{1000}{36}=\frac{250}{9}\text{m/s}$. Yeh ek repeating decimal $27.\overline{7}\text{m/s}$ hai; hum exact fraction $\frac{250}{9}$ arithmetic mein carry karte hain aur final answers ko sirf end mein 3 decimals par round karte hain (writing $27.778$ ya $49.722$ ek exact fraction ka rounded display hai, kabhi woh value nahi jo hum wapas feed karein).

Deceleration $=p/m=8000/1000=8{\text{m/s}}^2$. $v_1=\frac{250}{9}-8(0.01)=\frac{250}{9}-\frac{2}{25}=\frac{6250-18}{225}=\frac{6232}{225}=27.69\overline{7}\approx \boxed{27.698\text{m/s}}$ Distance update purani velocity $v_0$ se kyun? Yeh Euler ka rule hai — woh interval ke start par state use karta hai. $d_1=50-\frac{250}{9}(0.01)=50-\frac{250}{900}=50-\frac{5}{18}=\frac{895}{18}=49.72\overline{2}\approx \boxed{49.722\text{m}}$ (Agar tumne $v_0$ ko pehle $27.78$ par round kiya aur wapas feed kiya, tum $27.70$ aur $49.72$ padhte — danger display digits mein nahi, balki next computation se pehle rounding mein hai.)

Per-step multiplier $g=1-\Delta t/\tau$ hai; har step $v$ ko $g$ se multiply karta hai. Figure mein red curve woh hai jo diverge hoti hai — woh case hai jisse darna chahiye.

Figure L3.1: same decaying state ke teen Euler runs. X-axis = simulated time (s); Y-axis = state $v$. Black solid = stable decay; black dashed = oscillating-but-shrinking; red = diverging. Dekho kaise sirf red run zero se door magnitude mein grow karta hai.

$\Delta t$ ke har range ko, boundaries including, walk karte hain:

• Degenerate boundary $\Delta t=0$ ($g=1$): koi step nahi liya jaata, isliye $v$ kabhi change nahi hoti — state frozen hai. Yeh trivially "stable" hai par useless: zero time advance ke saath simulation koi progress nahi karta. Hum ise completeness ke liye list karte hain, kyunki yeh woh exact edge hai jahan step size vanish hoti hai.
• $0<\Delta t<\tau$ ($0<g<1$): smooth monotone decay toward 0 — correct physics (black solid).
• Boundary $\Delta t=\tau$ ($g=0$): state ek single step mein exactly 0 par snap ho jaati hai aur wahan rehti hai. Harmless par non-physical (real decay gradual hai, kabhi instant nahi).
• $\tau <\Delta t<2\tau$ ($-1<g<0$): har step sign flip hota hai par magnitude shrink hoti hai — ek decaying oscillation (black dashed). Non-physical wobble, par blow up nahi karta.
• Boundary $\Delta t=2\tau$ ($g=-1$): marginal stability — $v$ forever $+/-$ flip karta hai constant magnitude par, kabhi settle nahi karta. Yeh stable aur unstable ke beech ka knife-edge hai.
• $\Delta t>2\tau$ ($|g|>1$): har step magnitude grow karta hai — true divergence (red curve). Yahi woh "numerical instability" hai jiske baare mein parent note warn karta hai.

SIL ke liye yeh kyun important hai: "faster run karne ke liye" bahut bada $\Delta t$ choose karna plant model ko aisi physics report karwa sakta hai jo kabhi hoti hi nahi, toh tum ek simulation artifact debug karoge, apna code nahi.

6% abstraction error kahan se aata hai? (WHY, derived, asserted nahi): ADC (analog-to-digital converter) ko ek conversion finish karne ke liye 2 clock cycles chahiye; 1 kHz control rate par control period $T=1/1000=1\text{ms}$ hai... lekin yahan delay ek $10\text{ms}$ loop period ke relative quote kiya gaya hai, giving ek fractional delay $\varphi =\frac{\text{delay}}{\text{period}}=\frac{2\text{ms}}{10\text{ms}}=0.2$ of a cycle. $\varphi$ cycles ka ek pure time delay, first order par, loop se phase margin remove karne ke barabar hai: yeh ek phase angle subtract karta hai $\Delta \phi =360^{\circ }\times \varphi \times \frac{f_{\text{crossover}}}{f_{\text{sample}}}\approx 360^{\circ }\times 0.2\times \frac{1}{\approx 7}\approx 10^{\circ }$ loop ke crossover par phase margin ka (yahan crossover sample rate ke ek-sathven ke paas baithta hai, ek typical well-tuned value). Ab standard second-order overshoot-vs-phase-margin relation use karo — textbook approximation ki overshoot percentage $\approx (70-\text{PM in degrees})$ nominal $60^{\circ }$ margin ke paas, yaani phase margin lose karna overshoot roughly one-for-one $50$–$60^{\circ }$ band mein add karta hai. $\approx 10^{\circ }$ margin lose karna isliye order of $6\%$ extra overshoot add karta hai. Toh "$6\%$" ek derived engineering estimate known 2-cycle delay se hai, koi chart se nahi nikala — aur critically, SIL kabhi yeh delay model nahi karta, isliye woh yeh term dekh hi nahi sakta.

Worst-case bound: $4\%+1\%+6\%=11\%$ possible prediction error — $5\%$ margin se bada, isliye SIL akela is spec ke liye trustworthy nahi hai. Pehle kaun sa term? Abstraction error (6%) dominant hai aur woh hai jo SIL structurally dekh hi nahi sakta. Yeh ek unmodeled effect hai (ADC conversion delay), isliye koi bhi solver tuning ise fix nahi kar sakta. Yahi "necessary-but-not-sufficient" limit hai: is spec ki check PIL/HIL par le jaao jahan real timing appear hoti hai, aur discretization sirf tab shrink karo jab woh sasta ho.

Pehle, samjho har symbol ka matlab kya hai: pid(error) ek pure-computation controller hai — input tracking error hai, output command hai; koi hardware nahi touch karta, isliye yeh core logic hai aur wahi rehta hai. Offending line instead woh direct memory-mapped register read *(volatile int*)0x4001A004 hai. Yeh hardware-specific hai aur host PC par exist nahi kar sakti. Refactor — ise HAL call ke peeche le jaao:

int hal_read_sensor(void);   // SIL: plant-model value return karta hai
                             // MCU: 0x4001A004 read karta hai
int control_step(void) {
    int raw = hal_read_sensor();       // core logic untouched
    int cmd = pid(setpoint - raw);     // pid() unchanged, still pure
    return cmd;
}

Ab control_step platform-independent hai: $\text{SUT}=\text{Core Logic}+\text{HAL}$. SIL mein framework ek hal_read_sensor link karta hai jo plant model ki sensor value return karta hai; target par woh register version link karta hai. Yeh Unit Testing for Embedded Systems se mirror karta hai, jahan same seam tumhe stub inputs inject karne deta hai.

• (i) Sign error → SIL. Yeh pure algorithm logic hai. Plant model se ek known rotating input feed karo; ek sign flip fused angle ko immediately ground truth se diverge kar deta hai, sasta, software mein.
• (ii) EMI-spike crash → HIL. EMI outlier ek abstraction-error effect hai — real electrical noise with heavy-tailed spikes jo ek clean Gaussian SIL model produce nahi karega. Real analog front-end + wiring (HIL) woh jagah hai jahan aisi glitches actually appear hoti hain. Plan: SIL pehle (sasta logic bug pakdo), phir HIL (physical-world bug pakdo). Yeh parent note ka "necessary but not sufficient" doctrine applied hai.

Yeh thresholds kyun (WHY): local error per step scale hoti hai $(\Delta t/\tau {)}^{p+1}$ ki tarah, jahan $p$ method ka order hai — Euler order $p=1$ hai, RK4 order $p=4$ hai. Same small error target $\epsilon$ hit karne ke liye:

• Euler: error $\sim (\Delta t/\tau {)}^2$, isliye $\Delta t/\tau \sim \sqrt{\epsilon }$ — ek loose bound, bahut se chhote steps force karta hai; "$\tau /10$" capture karta hai ek time constant resolve karne ke liye $\sim$10 steps ki zaroorat.
• RK4: error $\sim (\Delta t/\tau {)}^5$, jo dramatically faster shrink hoti hai, isliye same $\epsilon$ bahut bade step se meet hoti hai — "$\tau /2$" (approximately 2 steps per time constant).

Allowed step sizes ka ratio $\frac{\tau /2}{\tau /10}=5$ RK4 ke higher order ka payoff hai. Ab counting:

Euler: $\Delta t=10/10=1\text{ ms}$ → steps $=60/0.001=60000$ → evals $=60000\times 1=60000$. RK4: $\Delta t=10/2=5\text{ ms}$ → steps $=60/0.005=12000$ → evals $=12000\times 4=48000$. Decision: RK4 yahan sasta hai — 48000 < 60000 evals — aur zyada accurate bhi, kyunki uska bada stable step uski 4× per-step cost se zyada hai. Lesson: "Euler fast hai" ek per-step claim hai; total cost = steps × cost/step, aur ek stiffer accuracy demand winner flip kar sakti hai.

Argument: SIL ki prediction error (model + discretization + abstraction) error se bounded hai, aur abstraction term exactly un effects ko cover karta hai jo tumne model nahi kiye — sensor EMI spikes, MCU timing jitter, voltage sag — isliye 100000 passing scenarios sirf tumhare model ke duniya mein correctness prove karte hain, bahar nahi. Zero SIL failures un-modeled term ko bound nahi kar sakte. Sahi move: SIL algorithm correctness prove karta hai; Hardware-in-the-Loop (HIL) aur ek Real-Time Operating Systems (RTOS)-scheduled real-time run ke through escalate karo timing aur physical robustness validate karne ke liye, kisi bhi ship decision se pehle.

SIL mein, test hone wala artifact software (SUT) hai, jabki plant model ek trusted stand-in hai. Forward Euler har new-state value ko old-state values se compute karta hai. Time constant $\tau$ ke saath decay ke liye, Euler diverge karta hai jab $\Delta t>$ ==$2\tau$, aur exactly $\Delta t=2\tau$ par marginally stable hota hai. Woh ek error term jo SIL structurally dekh hi nahi sakta woh hai abstraction error== (unmodeled effects). L2.1 mein $v_1$ ke liye Euler step ::: $20$ rad/s L5.1 mein RK4 vs Euler total evals ::: 48000 vs 60000 — RK4 sasta