Modbus (RTU / TCP)

Zweck und Beschreibung

Ein einfaches und weit verbreitetes industrielles Protokoll zum Austausch technologischer Daten zwischen Steuerungen, Sensoren und Aktoren. 1979 von Modicon (heute Schneider Electric) entwickelt und zum De-facto-Standard der industriellen Automatisierung geworden. Wird in SCADA-Systemen, SPS, Frequenzumrichtern, Messgeräten und Sensoren eingesetzt. Dank seiner einfachen Implementierung und minimalen Anforderungen an Rechenressourcen eignet sich das Protokoll ideal für Embedded-Systeme und Geräte mit begrenztem Speicher.

Architektur und Datenmodell

Das registerbasierte Datenmodell basiert auf vier Adressraumtypen:

• Coils (0x) — digitale Ausgänge (Lesen/Schreiben von Bitwerten)
• Discrete Inputs (1x) — digitale Eingänge (nur Lesen)
• Input Registers (3x) — 16-Bit-Eingaberegister (nur Lesen)
• Holding Registers (4x) — 16-Bit-Holding-Register (Lesen/Schreiben)

Client-Server-Architektur (Master-Slave): Das Master-Gerät initiiert Anfragen, Slaves antworten. Jedes Slave-Gerät besitzt eine eindeutige Adresse (1–247). Das Protokoll enthält keine eingebaute Datensemantik — die Interpretation der Registerwerte erfolgt auf Anwendungsebene und gemäß Gerätedokumentation. Unterstützt Lese- und Schreiboperationen für einzelne und mehrere Register.

Transport

Modbus RTU:

• Serielle Leitungen RS-485 (bis zu 32 Geräte pro Bus, Distanz bis 1200 m) oder RS-232 (Punkt-zu-Punkt)
• Binäre Datenrepräsentation
• Integritätsprüfung mittels CRC-16
• Übertragungsgeschwindigkeit: 1200 bis 115200 Baud
• Halbduplex-Übertragung

Modbus TCP:

• Einkapselung von Modbus-Frames in TCP/IP (Port 502)
• MBAP-Header (Modbus Application Protocol) zur Transaktionsidentifikation
• Vollduplex-Übertragung
• Gleichzeitige Kommunikation mit mehreren Geräten möglich
• Keine Prüfsumme erforderlich (Zuverlässigkeit wird durch TCP gewährleistet)

Schlüsselfunktionen

• Lesen und Schreiben digitaler Signale (Coils) und Register
• Unterstützung standardisierter Funktionscodes (FC 01–06, 15–16, 23)
• Diagnosefunktionen (FC 08)
• Auslesen von Geräteidentifikationsdaten (FC 17, 43)
• Minimale Anforderungen an Rechenressourcen der Geräte
• Einfache Implementierung und Fehlersuche
• Niedrige Implementierungskosten
• Ausnahmebehandlung und Fehlercodes
• Unterstützung von Broadcast-Nachrichten (Adresse 0) bei RTU
• Skalierbarkeit bis zu 247 Geräten pro Leitung (RTU) oder unbegrenzt über TCP

OPC UA

Zweck und Beschreibung

Ein universeller plattformübergreifender Standard (OPC Unified Architecture, IEC 62541) für den sicheren und strukturierten Austausch industrieller Daten, Metadaten und semantischer Informationen. Vom OPC Foundation-Konsortium als Nachfolger der klassischen OPC DA/AE/HDA-Spezifikationen entwickelt, um die Abhängigkeit von Microsoft DCOM-Technologien zu beseitigen. Ermöglicht vertikale und horizontale Integration in industriellen Systemen — von der Feldebene bis zu Unternehmensinformationssystemen (ERP, MES). Unterstützt Industrie-4.0- und Digital-Twin-Konzepte dank umfangreicher Möglichkeiten zur Informationsmodellierung.

Architektur und Datenmodell

Objektorientiertes Datenmodell, das Informationen als adressierbaren Knotenraum (Address Space) darstellt:

• Knoten (Nodes) unterschiedlicher Typen: Variable, Object, Method, View, DataType, ReferenceType
• Knotenattribute: Value, DataType, AccessLevel, Timestamp, Quality, DisplayName usw.
• Referenzen (References) zwischen Knoten: hierarchisch, assoziativ, komponentenbasiert
• Datentypen: primitive Typen, Strukturen, Arrays, Aufzählungen

Unterstützte Dienste:

• Subscription — Abonnement von Datenänderungen mit konfigurierbaren Abtastintervallen und Filtern
• Events & Alarms — asynchrone Benachrichtigungen zu Ereignissen, Alarmen und Zuständen
• Historical Access — Zugriff auf archivierte Daten und Ereignisse
• Methods — Aufruf entfernter Prozeduren auf Geräten

Branchenspezifische Informationsmodelle (Companion Specifications): Maschinenbau, Energie, Öl & Gas, Pharmazie.

Transport

UA Binary Protocol über TCP/IP:

• Binäres Protokoll mit optimierter Serialisierung (Port 4840)
• Hohe Leistung und minimaler Overhead

HTTPS / SOAP:

• Web-Services-Profil für Integration mit Unternehmenssystemen
• JSON-Kodierung für Cloud-Anwendungen

OPC UA PubSub:

• Publisher-Subscriber-Modell für verteilte Systeme
• Transport: UDP Multicast, MQTT, AMQP, Ethernet TSN
• Deterministische Übertragung für zeitkritische Anwendungen

Sicherheit:

• Mehrstufige Sicherheitsmodi (None, Sign, SignAndEncrypt)
• X.509-Zertifikate zur Authentifizierung
• AES-, RSA-Verschlüsselung

Schlüsselfunktionen

• Informationsmodellierung: Übertragung nicht nur „roher" Werte, sondern komplexer strukturierter Daten mit Semantik, Typisierung und Metainformationen
• Abonnements (Subscriptions) mit konfigurierbaren Abfrageintervallen, Deadband-Filtern und Pufferung
• Ereignisse (Events) und Alarmsystem mit bedingter Filterung
• Methodenaufrufe (Methods) zur Gerätesteuerung und Ausführung von Operationen
• Historischer Datenzugriff mit Aggregation
• Dienstentdeckung (Discovery) im lokalen Netzwerk
• Integrierte Sicherheit: Kanalverschlüsselung, Authentifizierung per Zertifikat oder Benutzername/Passwort, Zugriffskontrolle auf Knotenebene
• Redundanz und Ausfallsicherheit von Servern
• Plattformunabhängigkeit: Windows, Linux, VxWorks, QNX und andere Betriebssysteme
• Skalierbarkeit: von Mikrocontrollern bis zu verteilten Systemen

MQTT

Zweck und Beschreibung

Ein leichtgewichtiges Nachrichtenprotokoll (Message Queuing Telemetry Transport) für Telemetrie, Fernüberwachung und Steuerung von IoT-Geräten, optimiert für unzuverlässige Kommunikationskanäle, begrenzte Bandbreite und hohe Latenz. 1999 von IBM für die Überwachung von Ölpipelines entwickelt, standardisiert durch OASIS und ISO/IEC (20922:2016). Weit verbreitet im industriellen IoT, Smart Homes, Fahrzeugtelematik und mobilen Anwendungen. Das Protokoll zielt auf Minimierung des Netzwerkverkehrs und des Energieverbrauchs der Geräte ab.

Architektur und Datenmodell

Asynchrones Publish/Subscribe-Modell mit zentralem Broker:

• Publisher — Gerät oder Anwendung, das Nachrichten in Topics veröffentlicht
• Subscriber — Gerät oder Anwendung, das Nachrichten aus Topics abonniert
• Broker — zentraler Nachrichten-Routing-Server (Mosquitto, HiveMQ, EMQ X usw.)

Topics — hierarchische Pfadstruktur zur Kategorisierung von Nachrichten:

• Ebenentrennzeichen: / (z. B. factory/building1/temperature)
• Wildcards: + (eine Ebene), # (mehrere Ebenen)
• Abonnementbeispiel: sensors/+/temperature oder factory/#

Datenformat wird von der Anwendung definiert: JSON, Protocol Buffers, XML, Binärdaten, Text.
Retained Messages: Der Broker speichert die letzte Nachricht eines Topics und sendet sie neuen Abonnenten zu.
Persistente Sitzungen: Der Broker behält Client-Abonnements bei Trennung bei.

Transport

• Transportschicht: TCP/IP (Port 1883 für ungesicherte Verbindungen)
• TLS/SSL (Port 8883) zur Verschlüsselung und Authentifizierung
• WebSockets für Integration mit Browsern und Webanwendungen
• Protokollversionen: MQTT 3.1.1 (am weitesten verbreitet), MQTT 5.0 (erweiterte Funktionen)
• Header-Größe: mindestens 2 Bytes (fester Header)
• Keep-Alive-Mechanismus: periodisches Senden von PINGREQ/PINGRESP zur Verbindungsüberwachung
• Broker-basierte Architektur gewährleistet Entkopplung von Publishern und Subscribern, horizontale Skalierung und zentrales Management

Schlüsselfunktionen

• QoS (Quality of Service) drei Zustellungsgarantie-Level:
  • QoS 0: Höchstens einmal (ohne Bestätigung)
  • QoS 1: Mindestens einmal (mit Bestätigung)
  • QoS 2: Exakt einmal (vierstufiger Handshake)
• Minimaler Netzwerk-Overhead: 2-Byte-Fixheader, effiziente binäre Kodierung
• LWT (Last Will and Testament): Mechanismus zur automatischen Benachrichtigung bei unerwarteter Geräte-Trennung — der Broker veröffentlicht eine vordefinierte Nachricht, falls der Client die Sitzung abnormal beendet
• Clean Session / Persistent Session: Möglichkeit, Abonnements und Nachrichten nach erneuter Verbindung wiederherzustellen
• Retained Messages: Verfügbarkeit des letzten aktuellen Werts für neue Abonnenten
• Geringer Energieverbrauch: ideal für batteriebetriebene Geräte
• Skalierbarkeit: Unterstützung von Millionen gleichzeitiger Verbindungen auf Broker-Clustern
• Wildcard-Abonnements für flexible Topic-Filterung

DLMS / COSEM (IEC 62056)

Zweck und Beschreibung

Ein internationaler Standard für den Datenaustausch mit Messgeräten für Energieressourcen: Strom, Gas, Wasser, Wärme (Device Language Message Specification / Companion Specification for Energy Metering). Vom DLMS User Association gemeinsam mit der IEC entwickelt, um die Interoperabilität intelligenter Zähler (Smart Metering) in Systemen zur automatisierten kommerziellen Erfassung von Energieressourcen (АСКУЭ) sicherzustellen. Ermöglicht Fernablesung, Überwachung der Stromqualität, Tarifmanagement und Erkennung unbefugten Zugriffs. Weit verbreitet bei Energieversorgern, Versorgungsunternehmen und Systemintegratoren für Smart Grids.

Architektur und Datenmodell

COSEM-Objektmodell (Companion Specification for Energy Metering):

• Zählerdaten werden als logische Objekte (COSEM objects) mit Interface-Klassen dargestellt
• OBIS-Codes (Object Identification System) — sechsbyteiger Identifikator zur universellen Adressierung von Parametern: A-B:C.D.E*F
  • A — Energieträger-Typ (1=Strom, 6=Wärme, 7=Gas, 8=Wasser)
  • B — Messkanal
  • C — physikalische Größe (z. B. 1=Wirkenergie)
  • D — Messart (8=Integrationszeit)
  • E — Tarifzone
  • F — historische Tiefe

DLMS-Protokoll:

• Anwendungsschicht gemäß OSI-Modell
• Assoziationen (Associations) mit unterschiedlichen Zugriffsrechten: Public, Reader, Manager
• Authentifizierung: Low Level Security (LLS), High Level Security (HLS) mit Challenge-Response
• Verschlüsselung: Unterstützung der DLMS Security Suite mit AES-GCM-128-Algorithmen
• Lastprofile (Load Profiles): Pufferobjekte zur Speicherung von Zeitreihendaten
• Skriptsystem: Ausführung von Aktionssequenzen am Zähler

Transport

Physikalische und Sicherungsschicht:

• Optischer Port (IEC 62056-21, Flag) — direkte Verbindung über Infrarotkopf zur lokalen Auslesung
• RS-485 / RS-232 mit HDLC-Protokoll (High-Level Data Link Control) für Mehrpunkt-Netzwerke
• TCP/IP (Port 4059) — DLMS over TCP oder IP-Einkapselung für Fernzugriff
• GSM/GPRS/LTE — Datenübertragung über Mobilfunknetze (Wrapper-Protokolle)
• PLC (Power Line Communication) — Übertragung über Stromleitungen (PRIME, G3-PLC)
• M-Bus — zur Integration mit Wasser- und Wärmezählsystemen

Übertragungsprofile je nach Zählerimplementierung:

• IEC 62056-46: COSEM over HDLC
• IEC 62056-47: COSEM-Transport über TCP-UDP/IP

Schlüsselfunktionen

• Zählerablesung — aktuelle Werte von Energieverbrauch, Leistung, Spannung, Strom, Leistungsfaktor
• Lastprofile (Load Profiles) — detaillierte Daten mit Zeitstempeln (15-Minuten-, Stunden-, Tagesintervalle)
• Ereignisprotokolle — Protokollierung von Gehäuseöffnung, Stromausfällen, Überspannungen, Parameteränderungen
• Mehrebenen-Authentifizierung und -Autorisierung: rollenbasierte Zugriffskontrolle (öffentlicher Zugriff, Lesen, Konfigurieren)
• Tarifmanagement — Fernänderung von Tarifplänen und -sätzen
• Zeitsynchronisation zur Gewährleistung der Genauigkeit von Zeitstempeln
• Relaissteuerung (Zu-/Abschaltung der Last)
• Überwachung der Stromqualität (Spannungseinbrüche, Überspannungen, Oberschwingungen)
• Unterstützung von Gruppenoperationen über mehrere Zähler hinweg
• Kryptografischer Datenschutz und Nachrichtenintegrität