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

False in spirit — the target microcontroller is absent, but SIL still models the hardware's behaviour (dynamics, limits). No physical part, but the hardware's role is very much simulated.

False — a core SIL property is that the code is unaware; it calls the same HAL functions and receives numbers, so it "thinks" it is driving real hardware. That obliviousness is what makes the test faithful.

False — SIL only exercises what you modelled. Unmodelled effects (ADC delay, EMI spikes, voltage sag, timing jitter) are invisible, so SIL proves logical correctness only, never real-world survival.

False — they answer different questions. SIL asks "is my algorithm logically right?"; HIL asks "does it survive real I/O timing and electrical reality?" SIL comes first and cheaper; HIL cannot be skipped.

False — a low-fidelity linear model runs faster and still catches unit, polarity, and sign errors. Fidelity should be just enough to invalidate bad software; excess fidelity costs speed and dev time for no extra bug-catching.

False — you need enough realism to fail bad software, not perfect physics. A bug giving 10% overshoot in a crude model would give more on real hardware; SIL flags it either way.

False — unit tests check isolated functions against fixed expected outputs; SIL runs the whole controller closed-loop against an evolving plant, catching feedback-and-timing bugs a static unit test never sees.

False — if $\Delta t$ is tiny (needed for stiff dynamics), the simulation can run slower than real time, defeating the rapid-iteration purpose. Speed depends on the solver and step size, not on "software" alone.

False — shrinking $\Delta t$ improves accuracy but slows the run, and past a point buys negligible accuracy. Too large a $\Delta t$ causes divergence; the goal is the sweet spot, not the smallest value.

The error: the HAL is exactly why the same core logic can compile for both. In SIL the HAL routes to the plant model; on the MCU it maps to memory-mapped I/O. Swapping only the HAL is the whole trick.

The error: real noise has outliers (EMI spikes), not just clean Gaussian scatter. A bug that crashes on one wild reading stays hidden — this is an abstraction error, not a fixable numeric detail.

The error: SIL isn't broken — the model omitted cogging torque ($\tau =K_{t}I$ ignored it). This is model error: SIL can only catch effects you chose to represent.

The error: the real ADC had a 2-cycle conversion delay feeding stale data to the loop; SIL never modelled that latency. The tool was fine — the timing abstraction was incomplete.

The error: Euler carries $O(\Delta t^2)$ local error and can miss fast transients or diverge; RK4 is more accurate per step. They agree only when $\Delta t$ is small enough for your dynamics — not universally.

The error: the real plant evolves continuously; sampling it only at controller ticks can alias fast dynamics with time constants under 10 ms. The plant often needs finer internal integration than the control rate.

The error: SIL validates the fusion logic against modelled sensor streams, but real multi-sensor drift, dropout, and clock skew are abstraction gaps. SIL is necessary, not sufficient, for deployment confidence.

Because the software is closed-loop with the model: its outputs feed back into the plant, which produces the next inputs. It's a feedback cycle, not a one-shot input/output check.

The digital controller only acts at discrete instants ($n{T}_{\text{sample}}$), and a computer can only advance the plant in finite steps ($\Delta t$). Discretization is how continuous physics is stepped forward on a finite machine.

Later stages add irreversibility (PCBs, deployed units) and coordination overhead (manufacturing, recalls). SIL fixes are just "edit code, recompile, re-run" — minutes, no physical artifacts, hence the exponential cost curve.

So one portable y = f(x, state) compiles unchanged for both host and target; only the thin HAL implementation swaps. Without the split you'd rewrite hardware-touching logic for every platform.

SIL typically models data flow and idealised timing, not real task preemption, priority inversion, or jitter under an RTOS. Those are runtime scheduling effects that need PIL/HIL on real silicon to expose.

Necessary: it catches algorithm/logic bugs earliest and cheapest. Not sufficient: prediction error also includes model, discretization, and abstraction gaps, so passing SIL cannot certify real-world robustness alone.

Interception keeps the algorithm byte-identical to production. If you edited the algorithm to talk to the model, you'd be testing different code than you ship — invalidating the whole exercise.

The plant must be initialised to a defined starting state (e.g. speed and distance) before the software's first read; an uninitialised or garbage initial state makes the whole closed-loop run meaningless from line one.

That's numerical instability (divergence): the solver amplifies error each step. It's a simulation artifact, not a real controller failure — you must shrink $\Delta t$ or use a stabler solver like RK4 before trusting results.

The fast transient lives and dies between controller samples and gets aliased or missed. You need finer internal plant integration (sub-stepping) than the control period, or SIL will silently hide those dynamics.

Usually nothing — if your noise model has no outliers, that code path is never exercised. This is a classic abstraction-error blind spot; add fault-injection or move to HIL to reach it.

Model error shrinks toward zero, but simulation cost rises and you still carry discretization and abstraction error. The prediction error is floored by those, so "perfect plant" never buys "perfect prediction."

Then controller pathologies that only appear under saturation — like integrator windup — stay hidden, because the simulated actuator never hits its ceiling. High-fidelity models add these limits precisely to expose such bugs.

Neither is automatically right — the disagreement localises the gap. HIL includes real I/O and timing SIL abstracted away, so the mismatch tells you which unmodelled effect matters and must be added or accepted.