In this chapter

Chapter 6 of 13

  1. 6.1The path of a signal
  2. 6.2Software in three layers
  3. 6.3A model is a plugin
All chapters
  1. 01Initial situation
  2. 02Objective and approach
  3. 03State of the art
  4. 04Requirements
  5. 05Solution approaches and concept decision
  6. 06System architecture
  7. 07The test rig
  8. 08The heated-tank model
  9. 09The simulation cycle
  10. 10Five test scenarios
  11. 11Result and limits
  12. 12Outlook
  13. 13Preliminary projects

Chapter 06 System

System architecture

Four levels from the controller to the browser display, three software layers, plugin interface

By Chapter 6 of 13 2 min read Updated: 30 September 2026

Summary

Four levels connect the controller with the simulation on a Raspberry Pi; the software consists of three layers. Every plant model implements the same interface, so that 13 models run without any change to the orchestrator.

The setup can be read as four levels (Fig. 1): the controller at 24 V, converter stages, signal bridge and the simulation on a Raspberry Pi.

Four levels from the controller to the simulation: Siemens LOGO! (24 V), converter stages, Arduino Mega as signal bridge, Raspberry Pi with gateway, orchestrator and physics model.
Fig. 1 System overview: controller, interface, communication, simulationSource: Own illustration

The path of a signal

Twelve channels lead from the controller to the model, ten back (Fig. 2).

  1. Controller switches

    An output of the LOGO! puts 24 V on a channel.

  2. Convert level

    An optocoupler turns this into 5 V, galvanically isolated.

  3. Bridge reads

    The Arduino Mega transmits the state serially at 115200 baud.

  4. Model calculates

    The gateway provides the inputs, the orchestrator retrieves them and calculates the model in the cycle.

  5. Report back

    Changed sensors travel back the same way and, via relay contacts, apply 24 V to the controller again.

Path of the signals from the hardware level via the model calculation to the visualisation in the browser.
Fig. 2 Data flow between signal level, model calculation and visualisationSource: Own illustration

Software in three layers

  • Presentation layer: the browser with Canvas 2D animation, operating panel and error log, supplied via WebSocket.
  • Application layer: orchestrator.py on port 8050. It paces the simulation, loads models at runtime (hot swap) and distributes the results.
  • Communication layer: gateway.py on port 8100, the bridge between serial hardware and HTTP, with its own read and write thread and automatic reconnection.
Three layers: presentation in the browser, application in the orchestrator, communication in the gateway.
Fig. 5 (simplified) — Software architecture in three layersSource: Own illustration

A model is a plugin

Every plant model is an exchangeable module (plugin) with the same structure; the orchestrator knows only one call:

compute_step(inputs, dt) → { plant, sensors, outputs_logical }

inputs are the twelve channels from the outputs of the controller, dt is the step size. What comes back are the physical state (plant), the sensor bits (sensors) and the logical outputs (outputs_logical). Because this holds for all models, 13 plant models now run on the same platform (Fig. 6), without any change to the orchestrator. However, the interface is only agreed upon as a convention, not formally specified (Chapter 11).

Several physics models with an identical plugin interface; the heated tank is one of them.
Fig. 6 Plant models with an identical plugin interfaceSource: Own illustration

Continue with the hardware of the signal level (Chapter 7) and the heated-tank model (Chapter 8).

View the key figures of the platform