In this chapter

Chapter 5 of 13

  1. 5.1Approach 1: Broker with MQTT
  2. 5.2Approach 2: Gateway and orchestrator as an in-house development
  3. 5.3Decision for approach 2
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 05 Design

Solution approaches and concept decision

Concept decision between an MQTT broker and an in-house development consisting of gateway and orchestrator

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

Summary

The options were a central MQTT broker and an in-house development consisting of a gateway and an orchestrator without external middleware. The in-house development was chosen because it starts without network infrastructure and remains explainable in class.

Approach 1: Broker with MQTT

All components communicate via a central message broker using the MQTT protocol (Message Queuing Telemetry Transport): each one publishes to topics and subscribes to what it needs.

  • In favor: MQTT is an industry standard, decouples the parts completely and could later be swapped for a more powerful service.
  • Against: A broker has to be installed, configured and operated; the additional intermediate layer costs latency and makes troubleshooting harder. For laboratory operation without permanent network infrastructure, the setup is out of proportion to the benefit.

Approach 2: Gateway and orchestrator as an in-house development

There is no external middleware: REST-HTTP between gateway and orchestrator, WebSocket between orchestrator and browser.

  • In favor: Everything runs locally, each component can be started, stopped and checked individually, and the communication flow is visible without broker configuration.
  • Against: There is no specification according to an industry standard and no direct interoperability; as the number of components grows, the maintenance effort for the interfaces increases.
0required external services
2ports (8100 gateway, 8050 orchestrator)

Decision for approach 2

The decisive factor was the intended use: the test rig is used in training and has to start without network infrastructure, remain comprehensible and be explainable in class. A broker would have added a layer that contributes nothing didactically and would additionally be a suspect in the event of a fault.

Whether the decision holds is shown by the cycle measurement (Chapter 9) and the evaluation (Chapter 11); the scenario runs (Chapter 10) test the model, not the communication path. The structure of the architecture follows in Chapter 6.