Modbus TCP/RTU am STM32: Der Standard für die Gebäudeautomation

Modbus TCP/RTU am STM32 ist in der Gebäudeautomation ein echter Dauerbrenner, weil das Protokoll einfach, robust und in nahezu jeder Leitwarte, SPS-Umgebung und GLT-Software zu finden ist. Ob Heizungsanlage, Lüftungsgerät, Wärmepumpe, Zählertechnik oder Raumautomation: Modbus verbindet Feldgeräte mit übergeordneten Systemen, ohne dass dafür komplexe Stacks oder hohe Rechenleistung nötig wären. Für Entwickler ist das ideal, denn ein STM32 kann als Modbus-Slave (Server) Messwerte, Zustände und Stellgrößen bereitstellen oder als Modbus-Master (Client) mehrere Geräte abfragen und Daten bündeln. In der Praxis entscheidet jedoch nicht das Protokoll allein über Erfolg, sondern die saubere Umsetzung: korrekte Registerabbildung, deterministische Timing-Regeln bei Modbus RTU, stabile TCP-Verbindungen bei Modbus TCP, galvanische Trennung und EMV-Festigkeit am RS-485-Bus sowie ein klares Datenmodell mit Einheiten und Skalierung. Dieser Artikel zeigt, wie Sie Modbus RTU und Modbus TCP auf STM32-Controllern strukturiert implementieren, welche Architekturvarianten in der Gebäudeautomation sinnvoll sind und wie Sie typische Fehlerquellen (Timeouts, CRC, Endianness, Register-Design) konsequent vermeiden.

Warum Modbus in der Gebäudeautomation so verbreitet ist

Modbus ist kein „moderner“ Standard im Marketing-Sinn, aber in der Gebäudeautomation zählt vor allem: interoperabel, vorhersagbar und wartbar. Genau das liefert Modbus. Das Protokoll folgt einem klaren Request/Response-Prinzip, ist leicht zu testen und lässt sich auch in heterogenen Anlagen gut integrieren. Im Vergleich zu komplexeren Systemen ist der Implementierungs- und Diagnoseaufwand gering, und viele Integratoren haben standardisierte Werkzeuge und Routinen.

• Einfaches Datenmodell: Register und Bits, klar adressierbar.
• Breite Tool-Unterstützung: zahlreiche Scanner, Poller, Testprogramme und SCADA/GLT-Anbindungen.
• Übertragungswege: seriell (RTU über RS-485) und IP-basiert (TCP).
• Herstellerunabhängig: in gemischten Anlagen sehr nützlich.

Die offiziellen Spezifikationen und Funktionsbeschreibungen finden Sie bei der Modbus Organization unter Modbus Specifications. Für die Planung eines Geräts, das langfristig in Anlagen laufen soll, lohnt es sich, diese Dokumente als feste Referenz in den Entwicklungsprozess aufzunehmen.

Modbus RTU vs. Modbus TCP: Unterschiede, die in der Praxis zählen

Beide Varianten transportieren im Kern dieselben Funktionscodes und Registerkonzepte, unterscheiden sich aber stark in Transport, Timing und Fehlerbehandlung.

• Modbus RTU: seriell, typischerweise RS-485, rahmt Telegramme über zeitliche Pausen und nutzt CRC16 zur Fehlererkennung.
• Modbus TCP: läuft über TCP/IP, nutzt MBAP-Header statt CRC und ist einfacher zu multiplexen (mehrere Verbindungen, mehrere Clients).
• Topologie: RTU ist oft Busstruktur (mehrere Teilnehmer), TCP ist sternförmig über Netzwerk.
• Diagnose: RTU-Probleme sind häufig physikalisch (Verdrahtung, Abschluss, Störungen), TCP-Probleme eher netzwerkbedingt (Verbindungszustände, Firewall, Timeouts).

In der Gebäudeautomation sehen Sie häufig RTU für Feldbusstrecken im Schaltschrank (kurze Wege, robuste RS-485-Infrastruktur) und TCP für die Anbindung an Management-Systeme, Gateways oder IP-Netze. Ein STM32 kann beide Welten abdecken, je nachdem, welche Peripherie und Ressourcen verfügbar sind.

Rollenmodell: STM32 als Modbus-Slave, Modbus-Master oder Gateway

Die funktionale Rolle bestimmt Ihre Architektur. Gerade in Retrofit- oder Gateway-Projekten ist das entscheidend.

• STM32 als Modbus-Slave (Server): Das Gerät stellt Register bereit, die ein GLT-System oder eine SPS abfragt. Typisch für Sensor-/Aktorgeräte, Regler, Zähler, I/O-Module.
• STM32 als Modbus-Master (Client): Das Gerät liest viele Slaves aus, aggregiert Daten, führt Logik aus oder stellt Daten an ein anderes System weiter (z. B. MQTT/HTTP).
• STM32 als Gateway: RTU ↔ TCP (oder RTU ↔ anderes Protokoll). Häufig in Bestandsanlagen, wenn Feldbusgeräte an IP-Systeme angebunden werden sollen.

Für Gateways ist ein sauberes Mapping (Adressierung, Unit IDs, Registeroffsets) sowie eine strikte Trennung der Datenpfade wichtig, damit Lastspitzen auf der einen Seite nicht die andere Seite blockieren.

Registerdesign: Das eigentliche „API-Design“ Ihres Geräts

Bei Modbus entscheidet das Registerdesign darüber, wie gut Ihr Gerät integrierbar und wartbar ist. Ein verbreiteter Fehler ist, Register „nach Gefühl“ zu vergeben, ohne klare Struktur, Einheiten und Skalierung. Besser ist ein konsistentes Schema, das sich über Produktvarianten hinweg fortführen lässt.

• Adressräume sauber trennen: Coils (Bits), Discrete Inputs, Holding Registers, Input Registers.
• Einheiten und Skalierung definieren: z. B. Temperatur in 0,1 °C, Druck in 0,01 bar, Leistung in Watt.
• Read-only vs. Read/Write: Schreibbare Register klar begrenzen und validieren.
• Status- und Diagnose-Register: Fehlercodes, Betriebszustände, Kommunikationszähler, Firmware-Version.
• Versionierung: Registerplan-Version als Registerwert, damit Integrationen eindeutig sind.

Skalierung als Vertrag: Zahlen sind ohne Kontext wertlos

Wenn ein Integrator nicht weiß, ob „235“ für 23,5 °C oder 235 °C steht, sind Fehlinterpretationen vorprogrammiert. Dokumentieren Sie Skalierung konsequent und geben Sie, wenn möglich, Bereichsgrenzen an (Min/Max) sowie einen definierten Fehlerwert (z. B. 0x7FFF für „Sensorfehler“).

Modbus RTU auf STM32: RS-485-Hardware, Timing und CRC

Modbus RTU wird typischerweise über RS-485 umgesetzt. Dafür benötigen Sie neben der STM32-UART einen RS-485-Transceiver und in vielen Anlagen eine galvanische Trennung. Elektrisch ist RS-485 sehr robust, aber nur bei korrekter Busauslegung.

• RS-485-Transceiver: A/B-Leitungen, Terminierung (typisch 120 Ω an den Busenden), Biasing gegen Floating.
• DE/RE-Steuerung: Sende-/Empfangsumschaltung (Driver Enable / Receiver Enable), oft per GPIO oder UART-Hardware-Feature.
• EMV: verdrillte Leitungen, saubere Masseführung, Schutzbeschaltung (TVS), ggf. Common-Mode-Drosseln.
• Galvanische Trennung: empfehlenswert bei langen Strecken, unterschiedlichen Potenzialen oder störintensiver Umgebung.

RTU-Rahmung: 3,5 Zeichenzeiten als kritische Grenze

Modbus RTU rahmt Telegramme nicht mit Längenfeldern, sondern mit zeitlichen Pausen. Üblich ist eine stille Zeit von 3,5 Zeichenzeiten zwischen Frames und mindestens 1,5 Zeichenzeiten zwischen Zeichenblöcken. Eine Zeichenzeit hängt von Baudrate, Datenbits, Parität und Stopbits ab. Für eine typische 8N1-Konfiguration (1 Startbit, 8 Datenbits, 1 Stopbit) ergibt sich 10 Bit pro Zeichen.

$t_{\mathrm{char}}=\frac{N_{\mathrm{bits}}}{\mathrm{baud}}$

Mit Nbits = 10 bei 8N1 ist die Frame-Pause näherungsweise:

$t_{\mathrm{silent}}=3.5\cdot t_{\mathrm{char}}$

In der STM32-Implementierung bedeutet das: Sie brauchen eine verlässliche Zeitmessung (Timer/USART-Idle-Line/Timeout-Mechanismus), um Frame-Grenzen sauber zu erkennen. Je nach Baudrate und Systemlast ist eine DMA-basierte UART-Empfangsstrategie mit Idle-Line-Erkennung oft besonders stabil.

CRC16 in Modbus RTU: Fehlererkennung korrekt implementieren

Modbus RTU nutzt CRC16 (CRC-16/Modbus). Die Prüfsumme wird über den gesamten Frame (Adresse, Funktionscode, Daten) berechnet und am Ende angehängt (Low-Byte zuerst). Der konkrete Algorithmus ist in den offiziellen Spezifikationen dokumentiert; als Referenz dient Modbus Specifications. Für STM32-Projekte ist wichtig, CRC- und Endianness-Details exakt einzuhalten, weil selbst kleine Abweichungen zu sporadischen „CRC Errors“ führen, die schwer zu debuggen sind.

Modbus TCP auf STM32: Ethernet-Stack, Socket-Handling und MBAP-Header

Modbus TCP kapselt Modbus-Requests in TCP-Verbindungen. Statt CRC enthält jedes Telegramm einen MBAP-Header (Modbus Application Protocol), der u. a. Transaction ID und Länge beinhaltet. Das vereinfacht die Rahmung, verschiebt aber die Komplexität Richtung Netzwerkzustände: Verbindungen können abbrechen, Clients können mehrere Requests pipelinen, und Sie müssen Ressourcenlimits sauber setzen.

• TCP-Server auf Port 502: Standardport für Modbus TCP (in manchen Umgebungen durch Firewalls eingeschränkt).
• Mehrere Clients: je nach Anwendung zulassen oder begrenzen, um RAM/CPU zu schützen.
• Timeouts: klare Lese-/Schreib-Timeouts und Keepalive-Strategien, um „hängende“ Sockets zu vermeiden.
• Threading/RTOS: optional, aber oft hilfreich, wenn Netzwerk und Applikation entkoppelt werden sollen.

Wenn Ihr STM32 Ethernet nutzt, ist ein TCP/IP-Stack wie LwIP in Embedded-Projekten sehr verbreitet. Einstieg und Quellen finden Sie bei LwIP. Für die STM32-seitige Konfiguration sind STM32CubeMX und die ST-Beispielprojekte in vielen Fällen ein effizienter Startpunkt.

STM32-Implementierungsstrategien: HAL/LL, DMA, Interrupts und Zustandsmaschinen

Ob RTU oder TCP: Eine stabile Modbus-Implementierung auf STM32 profitiert von einer ereignisgetriebenen Architektur. Blockierende Warteschleifen führen in der Praxis zu Timing-Problemen, Watchdog-Resets oder „zähen“ Reaktionszeiten bei Lastspitzen.

• DMA für UART RX: reduziert Interruptlast und verhindert Datenverlust bei hohen Baudraten.
• Idle-Line-Erkennung: hilft, Frame-Enden bei RTU robust zu erkennen.
• Kurze ISRs: im Interrupt nur signalisieren, Verarbeitung im Task/Loop.
• Zustandsmaschine: klare States für Empfang, Validierung, Verarbeitung, Antwort.
• Watchdog-Design: nicht blind füttern, sondern Systemgesundheit prüfen (Queues, Overruns, Netzwerk).

Buffering und Grenzen: Schutz vor Überlast

In echten Anlagen können Poller aggressiv konfigurierte Abfragezyklen fahren. Ihr Gerät muss damit umgehen, ohne instabil zu werden. Setzen Sie Limits:

• Maximale PDU-Länge: eingehende Requests validieren und zu große Frames sauber verwerfen.
• Rate-Limits: optional, um CPU-Spitzen zu glätten (vor allem bei TCP mit mehreren Clients).
• Queue-Größen: definieren Sie feste Puffer, statt unkontrollierter Heap-Allokation.

Funktionscodes, Exceptions und Kompatibilität

Modbus lebt von klarer Fehlerkommunikation. Wenn ein Request nicht bedient werden kann, liefern Sie eine definierte Exception Response zurück. Typische Gründe:

• Illegal Function: Funktionscode wird nicht unterstützt.
• Illegal Data Address: Registeradresse nicht gültig oder außerhalb des Bereichs.
• Illegal Data Value: Wert oder Länge nicht plausibel (z. B. zu viele Register).
• Slave Device Failure: interner Fehler, z. B. Sensor nicht verfügbar.

Kompatibilität entsteht auch durch konservative Entscheidungen: Unterstützen Sie zuerst die am häufigsten genutzten Funktionscodes (z. B. Read Holding Registers, Read Input Registers, Write Single Register/Coil, Write Multiple Registers), bevor Sie Spezialfälle ergänzen.

Endianness, Registerbreite und Float-Werte: Typische Integrationsfallen

Modbus-Register sind 16 Bit breit. Viele reale Werte sind aber 32 Bit (z. B. Zählerstände) oder IEEE-754-Floats. Daraus entstehen Integrationsfragen, die Sie früh festlegen sollten:

• 32-bit Integer: zwei Register, definierte Wortreihenfolge (High/Low). Dokumentation ist Pflicht.
• Float (IEEE 754): zwei Register, Wort- und Byteorder klar definieren (z. B. „ABCD“ vs. „CDAB“).
• Signierung: signed/unsigned unterscheiden, Skalierung konsistent halten.
• Grenzwerte: definieren, wie NaN/Inf oder Sensorfehler abgebildet werden.

In der Gebäudeautomation ist es oft sinnvoll, Floats zu vermeiden und stattdessen skalierte Integer zu nutzen. Das reduziert Interpretationsfehler und ist in vielen GLT-/SPS-Systemen einfacher handhabbar.

Gateway-Szenarien: Modbus RTU ↔ Modbus TCP auf einem STM32

Ein sehr typisches Retrofit-Projekt ist ein Gateway, das mehrere RTU-Geräte über RS-485 an ein IP-Netz bringt. Technisch betrachtet kapseln Sie RTU-Requests in TCP oder bilden virtuelle Slaves ab. Dafür sind zwei Muster verbreitet:

• Transparentes Routing: TCP-Client sendet an Unit ID, Gateway leitet als RTU an Adresse weiter, Antwort zurück. Vorteil: weniger Mapping-Aufwand. Nachteil: Timing und Serialisierung müssen sauber gemanagt werden.
• Datenpunkt-Aggregation: Gateway pollt RTU-Geräte zyklisch, hält Werte lokal und stellt sie als Modbus TCP-Register bereit. Vorteil: entkoppelt Lastspitzen und erlaubt Vorverarbeitung. Nachteil: Mapping- und Synchronisationsaufwand.

Für Gebäudeautomation ist Aggregation häufig vorteilhaft, weil GLT-Systeme gerne konsistent und schnell lesen, während der RTU-Bus begrenzte Kapazität hat. Mit lokal gepufferten Werten bleibt das System responsiv, selbst wenn einzelne RTU-Teilnehmer kurzfristig ausfallen.

Test und Inbetriebnahme: So wird Modbus im Feld wirklich zuverlässig

Modbus-Projekte scheitern oft nicht im Code, sondern in der Inbetriebnahme. Eine strukturierte Teststrategie spart Zeit:

• Registerplan als Prüfdokument: Tabelle mit Adresse, Typ, Einheit, Skalierung, Zugriff, Default, Bereich.
• RTU-Bustests: Abschlusswiderstände, Biasing, Leitungslängen, Störquellen, Baudrate/Parität.
• TCP-Tests: mehrere Clients, lange Laufzeit, Verbindungsabbrüche, Reconnect-Handling, Timeouts.
• Fehlerszenarien: Sensor ausstecken, Bus unterbrechen, Netz weg, Neustart, Brownout, Watchdog.
• Diagnose-Register: Kommunikationszähler (Requests, Exceptions, CRC-Fehler, Timeouts) als Servicehilfe.

Für STM32-Projekte sind STM32CubeIDE und STM32CubeMX praktische Werkzeuge, um UART, DMA, Timer und optional Ethernet-Konfiguration reproduzierbar aufzusetzen. Gerade bei RTU-Timing hilft eine saubere Timer- und DMA-Konfiguration, um Frames robust zu erkennen und gleichzeitig CPU-Last niedrig zu halten.

Security und Betrieb: Was in der Gebäudeautomation oft übersehen wird

Modbus ist historisch nicht als „sicheres“ Protokoll entworfen worden. In vielen Anlagen ist das Risiko durch Netzsegmentierung und physische Trennung reduziert, aber mit IP-Vernetzung (Modbus TCP) steigt die Angriffsfläche. Deshalb sind organisatorische und technische Maßnahmen wichtig:

• Netzsegmentierung: Modbus TCP in OT-Netzen betreiben, Zugriff von IT-Netzen kontrollieren.
• Schreibzugriffe begrenzen: nur notwendige Register schreibbar machen, Werte validieren.
• Ressourcenlimits: maximale Verbindungen, Rate-Limits, Timeouts gegen Überlast und Fehlkonfiguration.
• Firmware-Update-Strategie: für langfristigen Betrieb, inklusive Versionierung und Rollback-Konzept.

Wenn Modbus TCP über unsichere Netze geführt werden muss, wird in der Praxis häufig ein abgesicherter Tunnel (z. B. VPN) oder ein vorgelagertes Gateway mit Zugriffskontrolle eingesetzt. Das ist oft realistischer als „Security in Modbus“ nachzurüsten.

Weiterführende Ressourcen für Spezifikation und Implementierung

• Modbus Organization: Spezifikationen (RTU, TCP, Funktionscodes)
• LwIP: Lightweight TCP/IP Stack (für Modbus TCP auf Embedded)
• ST: STM32CubeMX (Konfiguration von UART, Timern, Ethernet)
• ST: STM32CubeIDE (Entwicklung, Debug, Build)

Für ein belastbares Ergebnis in der Gebäudeautomation lohnt es sich, Modbus nicht nur als „Kommunikationsfunktion“ zu betrachten, sondern als Schnittstellenvertrag: Registerdesign, Skalierung, Fehlerbehandlung, Diagnostik und eine robuste Hardwarebasis (RS-485-Auslegung, EMV, Trennung) bestimmen am Ende, ob Ihr STM32-Gerät im Feld über Jahre stabil betrieben werden kann.

IoT-PCB-Design, Mikrocontroller-Programmierung & Firmware-Entwicklung

PCB Design • Arduino • Embedded Systems • Firmware

Ich biete professionelle Entwicklung von IoT-Hardware, einschließlich PCB-Design, Arduino- und Mikrocontroller-Programmierung sowie Firmware-Entwicklung. Die Lösungen werden zuverlässig, effizient und anwendungsorientiert umgesetzt – von der Konzeptphase bis zum funktionsfähigen Prototyp.

Diese Dienstleistung richtet sich an Unternehmen, Start-ups, Entwickler und Produktteams, die maßgeschneiderte Embedded- und IoT-Lösungen benötigen. Finden Sie mich auf Fiverr.

Leistungsumfang:

• IoT-PCB-Design & Schaltplanerstellung

• Leiterplattenlayout (mehrlagig, produktionstauglich)

• Arduino- & Mikrocontroller-Programmierung (z. B. ESP32, STM32, ATmega)

• Firmware-Entwicklung für Embedded Systems

• Sensor- & Aktor-Integration

• Kommunikation: Wi-Fi, Bluetooth, MQTT, I²C, SPI, UART

• Optimierung für Leistung, Stabilität & Energieeffizienz

Lieferumfang:

• Schaltpläne & PCB-Layouts

• Gerber- & Produktionsdaten

• Quellcode & Firmware

• Dokumentation & Support zur Integration

Arbeitsweise:Strukturiert • Zuverlässig • Hardware-nah • Produktorientiert

CTA:
Planen Sie ein IoT- oder Embedded-System-Projekt?
Kontaktieren Sie mich gerne für eine technische Abstimmung oder ein unverbindliches Angebot. Finden Sie mich auf Fiverr.