Chapter 09 Model
The simulation cycle
One cycle every 50 ms: sequence, change transmission, monitoring and cycle accuracy
The simulation does not run event-driven but time-driven in a fixed cycle of 50 ms (20 Hz). Only changed sensors are written to the signal bridge; a heartbeat and a watchdog monitor the connection. On the Windows development computer, the mean cycle time was 55.78 ms. The bound of 100 ms is thus met on average, but it is not assured: a fixed cycle is not a guaranteed cycle.
Sequence of a cycle
The orchestrator calls the model (compute_step, Chapter 8) in every cycle. Every cycle runs through the same steps (Fig. 9):
Read inputs
The orchestrator fetches the process image from the gateway (GET /api/state).
Calculate physics
compute_step advances the state by Δt = 0.05 s.
Report state
The state is sent to the debug channel via UDP.
Compare outputs
The calculated sensors are compared with the state of the previous cycle.
Write changes
Only changed sensors go via the gateway to the signal bridge; this keeps the serial link free.
Update display
The state is sent to all connected browsers via WebSocket.
Wait out remaining time
The cycle waits out the time remaining until 50 ms; if it takes longer, the waiting time is omitted and the next cycle starts immediately.
Why only changes are written
Ten sensors at 20 Hz would be 200 write commands per second over a serial line, almost all of which change nothing. The comparison with the last state reduces this to the actual edges, i.e. the transitions of a sensor from 0 to 1 or vice versa.
Monitoring the connection
The coupling monitors itself: a heartbeat (regular sign of life) runs every 0.5 s, and in addition there is a three-stage watchdog (monitoring timer) with a 2 s limit. If the sign of life fails to appear, the firmware of the signal bridge autonomously establishes a defined state, namely all outputs off, instead of freezing the last state.
Cycle accuracy
The fixed cycle is a specification, not a guarantee. Measurements were taken on the Windows development computer; the target platform of the system is a Raspberry Pi (Chapter 6).
Measurement result: On the Windows development computer, the mean cycle frequency was 17.9 Hz instead of the assumed 20 Hz, the mean cycle time 55.78 ms. Interpretation: The 100 ms bound from NFA-02 (Chapter 4) is met on average. Limit of the statement: A general-purpose operating system gives no real-time guarantee, and the thesis does not claim otherwise.
The diagram shows the cycle duration over 1200 cycles. The values lie between the target cycle of 50 ms and about 66 ms and are distributed over two clusters, one near 50 ms and one at about 65 ms.
How the cycle is reflected in the overall evaluation is stated in Chapter 11; the model test itself (Chapter 10) runs independently of the real-time cycle directly against compute_step.
