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

Before we start, one promise: every symbol is earned before use. Here are the only ingredients, defined once:

Definition Our vocabulary (define once, reuse everywhere)

$n$ — the tick counter: a plain whole number $0, 1, 2, 3, \dots$ that labels which controller step we are on. Tick $n = 0$ is the start, $n = 1$ is one $Δ t$ later, and so on. Any symbol with a little subscript $n$ (like $v_{n}$ or $u_{n}$ ) means "the value of that thing on tick $n$ ". So $v_{0}$ is the speed at the very first tick, $v_{1}$ the speed one tick later.
$v$ — the speed of the motor. Think "how fast the wheel spins", measured in revolutions per second (rev/s). The plant model tracks this number.
$v_{ref}$ — the target speed we want. The controller's whole job is to make $v$ approach $v_{ref}$ .
$e = v_{ref} - v$ — the error. Literally "how far off are we?" If $e > 0$ we're too slow; if $e < 0$ we're too fast; if $e = 0$ we're perfect.
$u$ — the control command the software sends (a PWM duty, a number the code computes each tick).
$Δ t$ — the time step: how many seconds pass between two controller ticks. If the controller runs at 100 Hz then $Δ t = 1/100 = 0.01$ s.
$K$ — the gain: a fixed dial inside the software that says "for each unit of error, push this hard". Big $K$ = aggressive; small $K$ = gentle. It lives only in the controller, never in the plant.
$τ$ (Greek "tau") — the plant's time constant: how sluggish the physical motor is. A big $τ$ means it takes a long time to react.

Formula The two equations we will simulate all page long

Controller (the software under test): $u_{n} = K (v_{ref} - v_{n}) = K e_{n}$ Read the subscript out loud: "the command $u$ on tick $n$ equals the gain times the error on tick $n$ ". This is a proportional controller — output is proportional to error. We use proportional (not integral or derivative) because it is the simplest tool that answers the question "which way and how hard do I push?" and it is enough to expose every case below.

Plant (the simulated motor), discretised with the Euler method: $v_{n + 1} = v_{n} + (u_{n} - v_{n}) \frac{Δ t}{τ}$ Here $v_{n + 1}$ means "the speed on the next tick" — we build it from the speed on this tick $v_{n}$ plus one small change. Why no $K$ here? $K$ is the controller's dial and appears only in the controller equation above. The plant is a plain first-order lag: its rate of change is "(command $u_{n}$ ) minus (current speed $v_{n}$ )", scaled by how sluggish it is ( $Δ t / τ$ ). Putting $K$ in both equations would secretly square the gain — a classic bug. Keep it in one place.

Why Euler? Euler is the plainest rule for "step a continuous thing forward one tick": new value = old value + rate × time step. We pick it precisely because its failure mode (blowing up when $Δ t$ is too big) is a case we must show — see Example 5.

The scenario matrix

Every SIL simulation you will ever run falls into one of these cells. The examples below are labelled with the cell they cover.

Cell	Case class	What makes it special	Covered by
A	Nominal, $e > 0$ (too slow)	The happy path: converge upward	Example 1
B	Sign flip, $e < 0$ (too fast)	Command must go negative	Example 2
C	Zero input, $e = 0$	Degenerate: nothing should move	Example 3
D	Degenerate hardware model ( $τ \to 0$ )	Instant plant — limiting behaviour	Example 4
E	Numerical instability ( $Δ t$ too large)	Solver diverges — a simulation bug, not a code bug	Example 5
F	Real-world word problem	Braking-distance stopping question	Example 6
G	Exam-style twist	"SIL passed but hardware failed" — abstraction error	Example 7

For the running examples (unless a cell overrides it) we fix: $K = 0.5$ , $τ = 0.2$ s, $Δ t = 0.01$ s.

Figure s01 — the closed SIL loop. Sketch of the layout: a lavender rounded box on the left labelled "Software under test — $u_{n} = K (v_{ref} - v_{n})$ ", and a mint rounded box on the right labelled "Simulated plant — $v_{n + 1} = v_{n} + (u_{n} - v_{n}) Δ t / τ$ ". A coral arrow points right from software to plant carrying the "command $u_{n}$ "; a lavender arrow loops back underneath, pointing left from plant to software carrying the "sensed speed $v_{n}$ ". A small butter-coloured arrow drops into the software box from above, marked " $v_{ref}$ = target enters here". The caption underneath reads: the software never learns the plant is fake — it just reads $v_{n}$ . As you read each example, trace which arrow the numbers travel along.

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

Example 1 — Cell A: nominal, the motor is too slow

Step 1 — Compute the error $e_{0}$ . $e_{0} = v_{ref} - v_{0} = 10 - 0 = 10$ Why this step? The controller can't act until it knows "how far off". Error is the software's only input.

Step 2 — Controller computes the command $u_{0}$ . $u_{0} = K e_{0} = 0.5 \times 10 = 5$ Why this step? This is literally the line of production code under test: u = K * (v_ref - v). Positive error → positive push. Good.

Step 3 — Plant advances one Euler step. $v_{1} = v_{0} + (u_{0} - v_{0}) \frac{Δ t}{τ} = 0 + (5 - 0) \frac{0.01}{0.2} = 5 \times 0.05 = 0.25$ Why this step? This is the simulated hardware reacting. The plant uses the command $u_{0}$ directly (no extra $K$ ) — notice the software never sees this equation, it only sees the resulting $v_{1}$ next tick. That is the "in-the-loop" feedback.

Answer: $v_{1} = 0.25$ rev/s.

Recall Was your forecast right?

It moves up by only $0.25$ , not near 10 ::: Correct — Euler with a small $Δ t$ nudges gently; convergence takes many ticks, which is exactly why we simulate rather than eyeball.

Verify: Sign check — motor was too slow ( $e > 0$ ), and $v$ increased ( $0 \to 0.25$ ). Units check: $(u_{0} - v_{0})$ is in rev/s, $Δ t / τ$ is dimensionless (s/s), so the increment is rev/s. ✓

Example 2 — Cell B: the sign flip, motor is too fast

Step 1 — Error is now negative. $e_{0} = 10 - 20 = - 10$ Why this step? We must show the reader the case where the sign of the input flips — the parent contract demands every sign. Negative error means "too fast".

Step 2 — Command flips sign. $u_{0} = 0.5 \times (- 10) = - 5$ Why this step? A correct proportional controller reverses its push automatically. If your code had a abs() or unsigned type bug, SIL would catch it right here — the sim would keep accelerating instead of braking.

Step 3 — Plant step. $v_{1} = 20 + (u_{0} - v_{0}) \frac{Δ t}{τ} = 20 + (- 5 - 20) (0.05) = 20 + (- 25) (0.05) = 20 - 1.25 = 18.75$ Why this step? The negative command drags $v$ down. Confirmed motion toward target.

Answer: $u_{0} = - 5$ , $v_{1} = 18.75$ rev/s.

Verify: Symmetry sanity check against Example 1 — in Ex 1 error was $+ 10$ ; here it's $- 10$ , so the command is exactly negated ( $+ 5$ vs $- 5$ ). ✓ And $v$ decreased, correct for "too fast". ✓

Example 3 — Cell C: the zero / degenerate input

Step 1 — Error is zero. $e_{0} = 10 - 10 = 0$ Why this step? The degenerate input is the one where the two inputs cancel. We must confirm the software forms exactly $0$ here — a subtraction bug or floating-point residue would show up as a tiny nonzero error, and this is where we'd catch it.

Step 2 — Command is zero. $u_{0} = 0.5 \times 0 = 0$ Why this step? Zero error should mean zero push. This is the degenerate input every controller must handle. A divide-by-error bug or a NaN would surface here.

Step 3 — Plant step. $v_{1} = 10 + (u_{0} - v_{0}) \frac{Δ t}{τ} = 10 + (0 - 10) (0.05) = 10 + (- 10) (0.05) = 10 - 0.5 = 9.5$ Why this step? We advance the plant even though the command is zero, precisely to reveal that "no command" does not mean "no motion" — the $- v_{n}$ drag term still acts. This is the whole point of the example, so we must run the step rather than assume nothing happens.

Answer: $v_{1} = 9.5$ rev/s (it drifts below target).

Verify: Plug the true equilibrium: for $v$ to stay put we need $u - v = 0$ with $u = K e = K (v_{ref} - v)$ , i.e. $K (v_{ref} - v) = v$ . Solving: $v_{e q} = \frac{K v _{ref}}{1 + K} = \frac{0.5 \times 10}{1.5} = \frac{10}{3} \approx 3.33$ . So the loop settles at $10/3$ , not 10 — confirming the offset. ✓

Example 4 — Cell D: degenerate hardware, $τ \to 0$ (instant motor)

Step 1 — Inspect the ratio. $\frac{Δ t}{τ} = \frac{0.01}{τ}$ As $τ \to 0$ , this ratio $\to \infty$ . Why this step? The whole update is scaled by $Δ t / τ$ . A limiting input must be inspected symbolically, not just numerically.

Step 2 — Restate the command, then take a concrete small $τ = 0.005$ . First recompute the controller output exactly as in Example 1, because we start from the same state: $e_{0} = v_{ref} - v_{0} = 10 - 0 = 10, u_{0} = K e_{0} = 0.5 \times 10 = 5$ Now run one plant step with the shrunken time constant: $\frac{Δ t}{τ} = \frac{0.01}{0.005} = 2, v_{1} = v_{0} + (u_{0} - v_{0}) \frac{Δ t}{τ} = 0 + (5 - 0) (2) = 10$ Why this step? We must show, not assume, where $u_{0} = 5$ comes from — it is the same controller line $u_{0} = K (v_{ref} - v_{0})$ from Example 1. A concrete degenerate value then shows the danger before it explodes: one step already jumps all the way to the target and would overshoot the true continuous answer.

Step 3 — Recognise the failure mode. When $Δ t / τ > 1$ , one Euler step overshoots the true continuous answer, and when it reaches 2 the simulation sits on the edge of oscillating and blowing up. A "faster" (smaller $τ$ ) motor needs a smaller $Δ t$ to stay accurate.

Answer: As $τ \to 0$ the discrete plant becomes unstable unless $Δ t$ shrinks in step; the "instant motor" is a degenerate model SIL cannot faithfully simulate without refining the time step.

Verify: Stability of Euler for $v_{n + 1} = v_{n} (1 - Δ t / τ) + \dots$ requires $∣1 - Δ t / τ ∣ < 1$ , i.e. $Δ t / τ < 2$ . At $τ = 0.005$ : $Δ t / τ = 2$ — exactly on the unstable boundary. ✓

Example 5 — Cell E: numerical instability, a simulation bug not a code bug

Step 1 — Compute the growth factor. $\frac{Δ t}{τ} = \frac{0.5}{0.2} = 2.5 (> 2!)$ Why this step? From Example 4 we know $> 2$ means unstable. We're deliberately past the cliff, so we expect the next steps to diverge.

Step 2 — Tick 1. $v_{1} = 0 + (u - v_{0}) \frac{Δ t}{τ} = 0 + (5 - 0) (2.5) = 12.5$ Why this step? We take the very first Euler step with the oversized ratio to see how badly a single update overshoots — $12.5$ already blows past the sensible resting value.

Step 3 — Tick 2. $v_{2} = 12.5 + (5 - 12.5) (2.5) = 12.5 + (- 7.5) (2.5) = 12.5 - 18.75 = - 6.25$ Why this step? We feed the overshot $v_{1}$ back in. Because it overshot, the correction term flips sign and over-corrects, flinging $v$ negative. This shows the divergence is a feedback effect of the bad step size, not a one-off.

Step 4 — Tick 3. $v_{3} = - 6.25 + (5 - (- 6.25)) (2.5) = - 6.25 + (11.25) (2.5) = - 6.25 + 28.125 = 21.875$ Why this step? Repeating once more shows the swing is growing ( $12.5 \to - 6.25 \to 21.875$ ), not settling. Three ticks is the minimum needed to prove the amplitude is increasing rather than a lucky bounce.

Figure s02 — stable vs unstable Euler. Sketch of the layout: one set of axes, horizontal axis "tick number $n$ ", vertical axis "simulated speed $v_{n}$ (rev/s)". A mint curve with round markers climbs smoothly and levels off near 5 — this is the safe run ( $Δ t = 0.01$ , ratio $0.05$ ). A coral curve with square markers zig-zags violently: its points sit at $12.5$ (tick 1), then $- 6.25$ (tick 2), then $21.875$ (tick 3), each swing bigger than the last — this is the divergent run ( $Δ t = 0.5$ , ratio $2.5$ ) we just computed by hand. A legend distinguishes "stable" (mint) from "diverges" (coral). Watch the coral markers land exactly on our three computed numbers.

Answer: $v_{1} = 12.5, v_{2} = - 6.25, v_{3} = 21.875$ — divergent oscillation caused by the solver, not the SUT.

Verify: The three values above, and $Δ t / τ = 2.5 > 2$ predicting instability. ✓

Example 6 — Cell F: the real-world word problem

Step 1 — Recall the stopping-distance formula. $d_{stop} = \frac{v ^{2}}{2 a}$ Why this step? We use $v^{2} / (2 a)$ because it answers exactly "how far to reach zero speed under constant deceleration" — derived from energy: the car must shed kinetic-energy-per-mass $\frac{1}{2} v^{2}$ at rate $a$ per metre.

Step 2 — Plug in (units: m/s and m/s²). $d_{stop} = \frac{3 0 ^{2}}{2 \times 6} = \frac{900}{12} = 75 m$ Why this step? Substituting the actual numbers turns the abstract formula into the concrete distance we can compare against the gap. Units: $(m/s)^{2} / (m/s^{2}) = m$ . ✓

Step 3 — Compare to the gap. $d_{stop} = 75$ m but obstacle is at $50$ m. Margin $= 50 - 75 = - 25$ m. Why this step? A margin is only meaningful as (available gap) minus (needed distance); a negative result is the unambiguous "collision" signal.

Answer: No — the car needs 75 m but has only 50 m; it fails by 25 m. The controller must brake earlier or harder.

Verify: Solve for the maximum safe speed at 50 m: $v_{m a x} = 2 a d = 2 \times 6 \times 50 = 600 \approx 24.49$ m/s. Since $30 > 24.49$ , collision confirmed. ✓

Example 7 — Cell G: the exam twist ("SIL passed, hardware failed")

Step 1 — SIL command (fresh data $v_{n} = 8$ ). $e_{n}^{SIL} = v_{ref} - v_{n} = 10 - 8 = 2, u_{n}^{SIL} = K e_{n}^{SIL} = 0.5 \times 2 = 1$ Why this step? SIL modelled zero delay, so it uses the current true speed $v_{n}$ — this is the "ideal" command the code was verified against.

Step 2 — Hardware command (stale data $v_{n - 2} = 6$ ). $e_{n}^{HW} = v_{ref} - v_{n - 2} = 10 - 6 = 4, u_{n}^{HW} = K e_{n}^{HW} = 0.5 \times 4 = 2$ Why this step? The real ADC hands over 2-tick-old data. The same code line runs, but its input is the stale $v_{n - 2}$ , so we recompute with $6$ instead of $8$ to see what the hardware truly does.

Step 3 — Compare the two commands. $u_{n}^{HW} - u_{n}^{SIL} = 2 - 1 = 1$ Why this step? Subtracting isolates the pure effect of the delay — one full unit of extra, unwanted push — which is the number that quantifies the abstraction error.

Answer: SIL says $u = 1$ ; real hardware says $u = 2$ . The extra unit is the invisible timing bug SIL missed.

Verify: Difference $u^{HW} - u^{SIL} = 0.5 (4 - 2) = 1$ , and hardware pushes twice as hard as SIL predicted. ✓

Wrap-up: the matrix, filled

Recall Which example covered each cell?

A→Ex1, B→Ex2, C→Ex3, D→Ex4, E→Ex5, F→Ex6, G→Ex7 ::: Every cell of the scenario matrix now has a fully worked, verified example.

Return to the parent topic.