Sensoren, SPS und Modbus-Gateways: Erst die Aufgaben klären, dann verbinden
Aktualisiert: vor 4 Tagen
Ein Sensor, eine SPS und ein Modbus-Gateway können im selben Netzwerkplan stehen. Daraus folgt jedoch nicht, dass sie dieselbe Schnittstelle nutzen oder dieselbe Aufgabe erfüllen. Ein Sensor kann an einem SPS-Eingang angeschlossen sein, eine SPS ausgewählte Werte über Modbus bereitstellen und ein Gateway eine serielle Verbindung mit einem IP-Netz verbinden. Jeder dieser Schritte muss für die eingesetzten Geräte geklärt werden.


Verfolgen Sie zunächst einen einzelnen Datenpunkt von seiner Quelle bis zu dem System, das ihn lesen soll. So bleiben Verdrahtung, Steuerungslogik, Protokollumsetzung und Fernzugriff als unterschiedliche Aufgaben erkennbar.
Einen Messwert durch das System verfolgen
Zeichnen Sie den Datenweg in seiner Reihenfolge auf:
Sensor → Eingangs- oder Kommunikationsschnittstelle → SPS-Logik/Datenpunkt → Modbus-Client oder -Server → Gateway oder Netzwerkpfad → SCADA- oder Überwachungsanwendung
Je nach Gerät kann dieser Ablauf anders aussehen. Manche Sensoren liefern analoge oder binäre Signale an einen SPS-Eingang, andere stellen Daten digital bereit. Prüfen Sie in den Handbüchern von Sensor und SPS die tatsächliche Schnittstelle, Verdrahtung, Skalierung und Aktualisierung. Ein Sensor hat nicht automatisch eine Modbus-Adresse, nur weil die SPS an anderer Stelle Modbus verwendet.
Klären Sie anschließend, wo der Wert gespeichert ist und wie ein anderes System darauf zugreifen kann. Die SPS kann einen konfigurierten Datenpunkt über einen Modbus-Server bereitstellen oder als Client ein anderes Gerät abfragen. Prüfen Sie Rolle und Datenzuordnung im SPS-Projekt und im Handbuch. Die Registerzuordnung ist eine gezielte Konfiguration, kein automatisches Abbild aller Sensoreingänge.
Modbus-Variante und Teilnehmerrollen festlegen
Modbus RTU und ASCII verwenden serielle Nachrichtenrahmen. Modbus TCP überträgt Modbus-Anwendungsdaten über TCP/IP mit einem MBAP-Header. Die Varianten nutzen Teile desselben Anwendungsdatenmodells, unterscheiden sich aber im Nachrichtenaufbau und in den Verbindungseinstellungen. RS-485 ist eine häufig verwendete physikalische Schnittstelle für serielles Modbus; sie legt allein noch kein Nachrichtenformat fest.
Teilstrecke | Vor der Konfiguration festhalten |
|---|---|
Sensor zur SPS | Elektrische oder digitale Schnittstelle, Verdrahtung, Skalierung und Gerät, das den Wert liefert |
SPS zum Modbus-Client | SPS-Rolle, RTU/ASCII/TCP-Variante, Endpunkt, serielle Einstellungen oder IP-Adresse/Port sowie unterstützte Funktionscodes |
Gateway zur übergeordneten Anwendung | Gateway-Modus, Quell- und Zielvariante, Client-/Serverrollen, Gerätekennungen und Registerzuordnung |
Die Angabe „Modbus-kompatibel“ klärt diese Einzelheiten nicht. Ein Gerät kann nur bestimmte Funktionscodes oder eine einzelne Variante unterstützen. Den Protokollaufbau beschreiben die Modbus Application Protocol Specification, der Serial Line Protocol Guide und der TCP/IP Implementation Guide. Welche Funktionen ein Gerät tatsächlich umsetzt, entnehmen Sie seinem Handbuch.
Routing, seriellen Transport und Protokollumsetzung unterscheiden
Ein IP-Router leitet IP-Verkehr zwischen Netzen weiter; RFC 1812 beschreibt die Anforderungen an IPv4-Router. Ein serieller Server kann serielle Bytes über eine IP-Verbindung transportieren und dabei die serielle Modbus-Nachricht unverändert lassen. Ein Modbus-Gateway kann eine Variante terminieren und Anfragen in einer anderen erzeugen. Dafür muss es den benötigten Betriebsmodus und die Zuordnung ausdrücklich unterstützen.
Die Produktnamen „Gateway“ und „Router“ reichen daher nicht aus, um das Verhalten zu bestimmen.
Prüfen Sie im Handbuch die Richtung der Umsetzung, die unterstützten Client-/Serverrollen und die Behandlung von Gerätekennungen. Klären Sie außerdem, ob das Gerät Daten durchreicht oder selbst abfragt und neu zuordnet. Fehlen diese Angaben, ist das Verhalten noch nicht belegt. Fragen Sie den Anbieter, bevor Sie die Architektur darauf aufbauen.
Vor der Abfrage eine Datenpunktliste erstellen
Halten Sie für jeden Wert seine Quelle und Interpretation fest, bevor Sie die Anwendung konfigurieren:
Feld | Was festzuhalten ist |
|---|---|
Quelle | Sensorkennung und zugehöriger SPS-Eingang oder Datenpunkt |
Protokollendpunkt | Gerätemodell und Firmware, Client-/Serverrolle sowie RTU/ASCII/TCP-Variante |
Modbus-Anfrage | Datenbereich, Funktionscode, Handbuchreferenz und Adress- oder Offsetkonvention des Clients |
Wertinterpretation | Datentyp, Vorzeichen, Byte- und Wortreihenfolge, Skalierung und Einheit |
Zugriff und Zeitverhalten | Nur lesender oder schreibender Zugriff, erwartete Aktualisierung und zulässiges Abfrageintervall gemäß Geräte- und Anwendungsplanung |
Registerbezeichnungen wie 40001 sind nicht zwingend die numerische Adresse, die ein Client senden muss. Prüfen Sie sowohl das Gerätehandbuch als auch die Adresskonvention der Clientsoftware.
Beginnen Sie mit einem dokumentierten, nur lesend abgefragten Datenpunkt. Vergleichen Sie die Antwort mit einem bekannten Wert und bestätigen Sie Einheit und Skalierung, bevor Sie weitere Register hinzufügen oder Schreibzugriffe erlauben. So lassen sich Transportfehler besser von Adressierungs- oder Datenformatproblemen unterscheiden.
Steuerung und Überwachung klar zuordnen
Legen Sie fest, welches System die Steuerung übernimmt und welches Daten sammelt oder darstellt. Ein Überwachungs-Gateway oder eine entfernte Plattform übernimmt nicht automatisch die Steuerungsaufgabe der SPS. Definieren Sie erlaubten Datenverkehr, Schreibberechtigungen und das Verhalten bei Ausfall der übergeordneten Verbindung.
Dokumentieren Sie für die Fernüberwachung die Netzwerkgrenze, freigegebene Gegenstellen, Kontoberechtigungen und den Weg der Protokolldaten. Der NIST-Leitfaden zur OT-Sicherheit bietet übergeordnete Hinweise zur Planung von Netzsegmentierung, Zugriff und Überwachung. Wenden Sie die Sicherheits- und Änderungsanforderungen des Standorts auf die tatsächliche Topologie an.
Nehmen Sie Cloud-Abfragen erst dann in einen Steuerungspfad auf, wenn der Verantwortliche Zweck, Zugriffsrechte und Verhalten bei einer Netzwerkunterbrechung festgelegt hat. Das benötigte Aktualisierungsintervall muss sich aus der Anwendung und der Gerätedokumentation ergeben, nicht aus einem allgemeinen Beispielwert.
Schrittweise in Betrieb nehmen und beobachten
Prüfen Sie das Sensorsignal oder die digitale Schnittstelle an der SPS. Bestätigen Sie Wert und Einheit im SPS-Projekt.
Klären Sie anhand der aktuellen Handbücher Modbus-Endpunkt, Variante, Rollen, Adresskonvention und unterstützten Funktionscode.
Lesen Sie einen bekannten Datenpunkt ohne Schreibzugriff und vergleichen Sie die Antwort mit der lokalen Anzeige der SPS.
Ergänzen Sie Datenpunkte in kleinen Gruppen. Beobachten Sie Antwortzeiten, Zeitüberschreitungen und Gerätelast beim vorgesehenen Abfrageplan.
Prüfen Sie den freigegebenen Netzwerkpfad und die Zugriffsrichtlinie. Halten Sie fest, was bei Ausfall der übergeordneten Verbindung geschieht.
Bleibt ein Wert aus SPS, Antrieb oder SCADA veraltet oder treten Zeitüberschreitungen auf, hilft der separate Leitfaden zur SPS-/Modbus-Fehlersuche, einen geräteseitigen Fehler von einem Problem im Kommunikationspfad zu unterscheiden. Bewahren Sie die Datenpunktliste zusammen mit der getesteten Firmware und Konfiguration auf, damit spätere Änderungen nachvollziehbar bleiben.
FAQ
Verwenden alle industriellen Sensoren Modbus?
Nein. Ein Sensor kann eine analoge, binäre, Impuls- oder digitale Kommunikationsschnittstelle besitzen. Prüfen Sie vor der Protokollwahl sein Handbuch sowie die unterstützten Eingangs- und Kommunikationsmodule der SPS.
Stellt eine SPS jeden Sensorwert automatisch als Modbus-Register bereit?
Nein. SPS-Projekt und Gerätekonfiguration legen fest, welche Werte zugeordnet sind, wie sie dargestellt werden und welche Funktionscodes sowie Client-/Serverrollen verfügbar sind. Prüfen Sie die Zuordnung in der SPS-Dokumentation.
Ist ein Modbus-Gateway dasselbe wie ein IP-Router?
Nein. Ein IP-Router leitet IP-Pakete weiter. Ein Gerät für seriellen Transport kann Bytes über IP übertragen. Eine Protokollumsetzung erfordert eine ausdrücklich unterstützte Gateway-Funktion für die Quell- und Zielvariante.
Ist 40001 immer die erste Adresse, die im Client einzutragen ist?
Nein. 40001 dient häufig als lesbare Bezeichnung für das erste Holding-Register. Handbücher und Software können jedoch einen bei null beginnenden Offset oder eine andere Konvention erwarten. Prüfen Sie beide Seiten und testen Sie mit einem dokumentierten, nur lesend abgefragten Datenpunkt.
Sollte eine Cloud-Plattform die SPS direkt abfragen?
Das hängt von der freigegebenen Architektur und Sicherheitsrichtlinie ab. Legen Sie vor dem Anschluss eines entfernten Dienstes Netzwerkgrenze, Zugriffsrechte, Abfragelast und Verhalten bei Ausfällen fest. Machen Sie das entfernte System nicht unbeabsichtigt zum Bestandteil des Steuerungspfads.




