Zwei Ansätze, eine Entscheidung

Für den Konzeptentwurf standen zwei Wege zur Wahl.

Ansatz 1 — Broker mit MQTT

Alle Komponenten reden über einen zentralen Messageen-Broker, jede veröffentlicht auf Topics und abonniert, was sie braucht. Das ist Industriestandard, entkoppelt die Teile vollständig und ließe sich später gegen einen leistungsfähigeren Dienst tauschen. Dagegen steht: Ein Broker muss installiert, konfiguriert und betrieben werden, die zusätzliche Zwischenschicht kostet Latenz und macht die Fehlersuche aufwendiger. Für einen Laborbetrieb ohne dauerhafte Netzinfrastruktur ist das viel Aufbau für wenig Gegenwert.

Ansatz 2 — Gateway und Orchestrator selbst bauen

Keine externe Middleware: REST-HTTP zwischen Gateway und Orchestrator, WebSocket zwischen Orchestrator und Browser. Alles läuft lokal, jede Komponente lässt sich einzeln starten, stoppen und prüfen, und der Kommunikationsfluss ist ohne Broker-Konfiguration sichtbar. Der Preis: keine Spezifikation nach Industriestandard, keine direkte Interoperabilität, und mit wachsender Komponentenzahl steigt der Pflegeaufwand für Schnittstellen.

Warum Ansatz 2

Ausschlaggebend war der Einsatzzweck. Der Prüfstand steht in der Ausbildung: Er muss ohne Netzwerkinfrastruktur starten, nachvollziehbar bleiben und sich im Unterricht erklären lassen. Ein Broker hätte eine Schicht hinzugefügt, die didaktisch nichts beiträgt und im Störungsfall zusätzlich verdächtig wäre. Ob die Entscheidung trägt, beantworten die Szenarienläufe im Kapitel über die Tests.