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

Answer: (b). The "loop" is the closed-loop feedback path. Look at the figure below: the two boxes are the Software (SUT) on the left and the Plant model on the right. Follow the red arrow — that is the command $u$ the software sends out. Then follow the black arrow back — that is the sensor value $v$ the plant returns, which becomes the software's next input. Because the output loops back to become the next input, the data-flow forms a closed circle — that circle is the "loop," not any for-loop in the code.

Figure L1.1: the closed SIL feedback loop. Red = the command signal (the key object); black = the returned sensor signal that closes the cycle.

(a) is a distractor: any program has for loops. (c) describes the developer's workflow, not the runtime signal path.

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

• SUT (1→B): the real code you will ship.
• Plant model (2→C): equations replacing motors/sensors.
• Cosim framework (3→A): the orchestrator that steps both clocks.
• HAL (4→D): Hardware Abstraction Layer — the seam that lets the same core logic run on PC (SIL) or MCU (production) by swapping only this layer.

No. A linear model has no saturation limit, so the actuator command is never clamped — the windup condition (command pinned at max while error keeps integrating) never occurs. You need a high-fidelity model with a if speed > max_rpm: speed = max_rpm limit.

What we do: evaluate the derivative at the current state, then step forward. $\dot{v}=\frac{Ku-v_0}{\tau }=\frac{100(1)-0}{0.5}=200{\text{rad/s}}^2$ Why Euler and not something fancier? Euler is the cheapest solver — one derivative evaluation per step. For a first look it's fine; its cost is accuracy, addressed in L3. $v_1=v_0+\dot{v}\Delta t=0+200\times 0.1=\boxed{20\text{rad/s}}$

Why re-evaluate the derivative? The whole point of "in-the-loop" is that the new state feeds the next step. $\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}}$ Notice the increment shrank ($20\to 16$): the model is approaching its steady value $Ku=100$. That lag toward the steady value is exactly the dynamic behaviour a medium-fidelity model (defined in the box above — the first-order $\dot{v}=(Ku-v)/\tau$ rule) exists to reveal, and a low-fidelity speed = K*u model would miss entirely.

Why convert units first? The model's terms are in metres and seconds (SI). Mixing km/h into a formula that expects m/s would silently scale the physics wrong — a classic SIL unit bug the low-fidelity check exists to catch. The conversion factor: $1\text{km}=1000\text{m}$ and $1\text{h}=3600\text{s}$, so $1\frac{\text{km}}{\text{h}}=\frac{1000\text{m}}{3600\text{s}}=\frac{1}{3.6}\frac{\text{m}}{\text{s}}.$ Therefore $v_0=100\times \frac{1}{3.6}=\frac{100}{3.6}=\frac{1000}{36}=\frac{250}{9}\text{m/s}$. This is a repeating decimal $27.\overline{7}\text{m/s}$; we carry the exact fraction $\frac{250}{9}$ through the arithmetic and only round the final answers to 3 decimals at the very end (writing $27.778$ or $49.722$ is a rounded display of an exact fraction, never a value we feed back in).

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}}$ Why update distance with the old velocity $v_0$? This is Euler's rule — it uses the state at the start of the interval. $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}}$ (If you had rounded $v_0$ to $27.78$ first and fed that back, you'd read $27.70$ and $49.72$ — the danger is not the display digits but rounding before the next computation.)

The per-step multiplier is $g=1-\Delta t/\tau$; each step multiplies $v$ by $g$. The red curve in the figure is the one that diverges — that is the case to fear.

Figure L3.1: three Euler runs of the same decaying state. X-axis = simulated time (s); Y-axis = state $v$. Black solid = stable decay; black dashed = oscillating-but-shrinking; red = diverging. Watch how only the red run grows in magnitude away from zero.

Walking every range of $\Delta t$, boundaries included:

• Degenerate boundary $\Delta t=0$ ($g=1$): no step is taken at all, so $v$ never changes — the state is frozen. This is trivially "stable" but useless: with zero time advance the simulation makes no progress. We list it for completeness, because it is the exact edge where the step size vanishes.
• $0<\Delta t<\tau$ ($0<g<1$): smooth monotone decay toward 0 — the correct physics (black solid).
• Boundary $\Delta t=\tau$ ($g=0$): the state snaps to exactly 0 in a single step and stays there. Harmless but non-physical (real decay is gradual, never instant).
• $\tau <\Delta t<2\tau$ ($-1<g<0$): sign flips each step but magnitude shrinks — a decaying oscillation (black dashed). Non-physical wobble, but it doesn't blow up.
• Boundary $\Delta t=2\tau$ ($g=-1$): marginal stability — $v$ flips $+/-$ forever at constant magnitude, never settling. This is the knife-edge between stable and unstable.
• $\Delta t>2\tau$ ($|g|>1$): magnitude grows every step — true divergence (red curve). This is the "numerical instability" the parent note warns about.

Why this matters for SIL: picking $\Delta t$ too large to "run faster" can make the plant model report physics that never happen, so you'd debug a simulation artifact, not your code.

Where does the 6% abstraction error come from? (the WHY, derived, not asserted): The ADC (analog-to-digital converter) needs 2 clock cycles to finish a conversion; at a 1 kHz control rate the control period is $T=1/1000=1\text{ms}$... but here the delay is quoted relative to a $10\text{ms}$ loop period, giving a fractional delay $\varphi =\frac{\text{delay}}{\text{period}}=\frac{2\text{ms}}{10\text{ms}}=0.2$ of a cycle. A pure time delay of $\varphi$ cycles is, to first order, the same as removing phase margin from the loop: it subtracts a phase angle $\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 }$ of phase margin at the loop's crossover (here crossover sits near one-seventh of the sample rate, a typical well-tuned value). Now use the standard second-order overshoot-vs-phase-margin relation — the textbook approximation that overshoot percentage $\approx (70-\text{PM in degrees})$ near a nominal $60^{\circ }$ margin, i.e. losing phase margin adds overshoot roughly one-for-one in the $50$–$60^{\circ }$ band. Losing $\approx 10^{\circ }$ of margin therefore adds on the order of $6\%$ extra overshoot. So the "$6\%$" is a derived engineering estimate from the known 2-cycle delay, not a chart pulled from nowhere — and crucially, SIL never models this delay, so it cannot see this term at all.

Worst-case bound: $4\%+1\%+6\%=11\%$ possible prediction error — larger than the $5\%$ margin, so SIL alone is not trustworthy for this spec. Which term first? The abstraction error (6%) dominates and is the one SIL structurally cannot see. It's an unmodeled effect (ADC conversion delay), so no amount of solver tuning fixes it. That is exactly the "necessary-but-not-sufficient" limit: move this spec's check to PIL/HIL where real timing appears, and shrink discretization only if it's cheap.

First, note what each symbol means: pid(error) is a pure-computation controller — input is the tracking error, output is the command; it touches no hardware, so it is core logic and stays put. The offending line is instead the direct memory-mapped register read *(volatile int*)0x4001A004. It is hardware-specific and cannot exist on a host PC. Refactor — pull it behind a HAL call:

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

Now control_step is platform-independent: $\text{SUT}=\text{Core Logic}+\text{HAL}$. In SIL the framework links a hal_read_sensor that returns the plant model's sensor value; on the target it links the register version. This mirrors Unit Testing for Embedded Systems, where the same seam lets you inject stub inputs.

• (i) Sign error → SIL. This is pure algorithm logic. Feed a known rotating input through the plant model; a sign flip makes the fused angle diverge from ground truth immediately, cheaply, in software.
• (ii) EMI-spike crash → HIL. An EMI outlier is an abstraction-error effect — real electrical noise with heavy-tailed spikes that a clean Gaussian SIL model won't produce. Real analog front-end + wiring (HIL) is where such glitches actually appear. Plan: SIL first (catch the cheap logic bug), then HIL (catch the physical-world bug). This is the parent note's "necessary but not sufficient" doctrine applied.

Why these thresholds (the WHY): the local error per step scales like $(\Delta t/\tau {)}^{p+1}$, where $p$ is the method's order — Euler is order $p=1$, RK4 is order $p=4$. To hit the same small error target $\epsilon$:

• Euler: error $\sim (\Delta t/\tau {)}^2$, so $\Delta t/\tau \sim \sqrt{\epsilon }$ — a loose bound, forcing many small steps; the "$\tau /10$" captures needing $\sim$10 steps across one time constant to resolve it.
• RK4: error $\sim (\Delta t/\tau {)}^5$, which shrinks dramatically faster, so the same $\epsilon$ is met with a much larger step — the "$\tau /2$" (about 2 steps per time constant).

The ratio $\frac{\tau /2}{\tau /10}=5$ between allowed step sizes is the payoff of RK4's higher order. Now the 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 is cheaper here — 48000 < 60000 evals — and more accurate, because its larger stable step outweighs its 4× per-step cost. The lesson: "Euler is fast" is a per-step claim; total cost = steps × cost/step, and a stiffer accuracy demand can flip the winner.

Argument: SIL's prediction error is bounded by (model + discretization + abstraction) error, and the abstraction term covers exactly the effects you didn't model — sensor EMI spikes, MCU timing jitter, voltage sag — so 100000 passing scenarios only prove correctness within your model's world, never outside it. Zero SIL failures cannot bound the un-modeled term. Correct move: SIL proves algorithm correctness; escalate through Hardware-in-the-Loop (HIL) and a Real-Time Operating Systems (RTOS)-scheduled real-time run to validate timing and physical robustness before any ship decision.

In SIL, the artifact under test is the software (SUT), while the plant model is a trusted stand-in. Forward Euler computes every new-state value from old-state values only. For decay with time constant $\tau$, Euler diverges when $\Delta t>$ ==$2\tau$, and is marginally stable exactly at $\Delta t=2\tau$. The one error term SIL structurally cannot see is abstraction error== (unmodeled effects). Euler step for $v_1$ in L2.1 ::: $20$ rad/s RK4 vs Euler total evals in L5.1 ::: 48000 vs 60000 — RK4 cheaper