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

This page assumes nothing. Every word, arrow, and symbol the parent note leaned on is built here from the ground up, in an order where each idea rests on the one before it.

0. The picture the whole topic hangs on

Before any symbol, look at the loop itself. Everything else is just a label on one of these boxes or arrows.

Why the topic needs this: the word "loop" appears in the name SIL. If you don't see the circle, none of the timing, feedback, or "the software doesn't know it's fake" ideas make sense.

1. Signal — the thing that flows on the arrows

Picture: a wire carrying a value. In the real car this wire is a real cable; in SIL it is a variable passed between two functions. Same meaning, different medium.

Why needed: the parent note talks about "sensor data", "control outputs", "CAN bus messages", "ADC readings". Every one of those is a signal — a number travelling along an arrow in the loop picture.

2. Sensor and Actuator — the two ends

Picture: sensor = an eye (world → number), actuator = a hand (number → world). The code sits between the eye and the hand.

Why needed: SIL's whole trick is to replace the eye and the hand with equations. To understand what is being replaced, you must first know what they do.

3. Plant — the machine being controlled

Picture: think of a factory ("plant") that takes an input command and slowly produces an output behaviour.

Why needed: the parent's central component is the "plant model". You cannot model a plant if you don't know a plant is the physical system, separate from the code.

4. Model — a maths stand-in for reality

Look at the two curves: the real machine (orange dots) and the model (blue line) don't match perfectly — and that's fine. A model only has to be close enough to reveal a bad decision by the software.

Why needed: SIL replaces hardware with a model. "Fidelity", "low/medium/high fidelity", "model error" — all of these are statements about how closely the blue line hugs the orange dots.

5. State — the memory of the plant

Picture: a snapshot. Freeze the world; the numbers written on that frozen frame are the state.

Why needed: the parent writes velocity_next = velocity - .... That is: new state computed from old state. The loop is really "state → software → command → new state → repeat".

6. Discrete time vs continuous time

This is the deepest symbol the parent uses, so we build it slowly with a picture.

• The real plant lives in continuous time.
• Your controller is a computer program; it can only run at ticks. So it lives in discrete time.

The symbols the parent throws at you, decoded:

Why needed: the whole "cosimulation / solver / stability" section is about how to make the smooth plant fit onto the discrete ticks of the code. Miss this and the parent's Euler formula is gibberish.

7. Turning smooth physics into steps — the Euler idea

Look back at figure s03: the straight blue jumps are Euler steps. When $\Delta t$ is too big, the jumps overshoot the orange curve badly — that is the "numerical instability / divergence" the parent warns about.

8. Feedback and closed-loop

Picture: this is the circle of arrows from figure s01. Break any arrow and the loop is open.

Why needed: SIL is a closed-loop test — the whole value is that the software's outputs come back to it as new inputs, exactly like reality.

9. HAL — the swappable adaptor

Picture: a wall socket. Your appliance (core logic) plugs into a standard socket. Behind the wall it might be solar, coal, or a battery — the appliance never knows. Swapping what's behind the wall = swapping the HAL.

Why needed: without the HAL split there'd be no way to run the same production code on a PC. The whole technique depends on this one swappable layer.

10. Proportionality — reading $\propto$ and $e^x$

Picture: folding paper — each fold doubles thickness. The parent's claim "bug-fix cost is \, $10\times, $100\times, $1000\times$ across stages" is exactly this: each later stage multiplies the cost. That's why fixing bugs early (in SIL) is so cheap.

The prerequisite map

Read it top-down: signals let sensors talk; sensors close the loop; plants get modelled; models carry state through time; time forces the Euler step; the HAL lets real code join the loop; cost explains why we bother. All arrows converge on SIL.

Equipment checklist

Cover the right side and answer each; only continue to the deep-dives when all are green.

See also: the parent topic, and once these foundations feel solid: Hardware-in-the-Loop (HIL), Unit Testing for Embedded Systems, Real-Time Operating Systems (RTOS), Sensor Fusion Algorithms.