Unterstützte Kommunikationsprotokolle

Modbus (RTU / TCP)

Zweck und Beschreibung

Ein einfaches und weit verbreitetes Industrieprotokoll zum Austausch von Prozessdaten zwischen Steuerungen, Sensoren und Aktoren. 1979 von Modicon (heute Schneider Electric) entwickelt, hat es sich zum De-facto-Standard der industriellen Automatisierung etabliert. Eingesetzt wird es in SCADA-Systemen, SPS, Frequenzumrichtern, Messgeräten und Sensoren. Dank seiner einfachen Implementierung und des minimalen Bedarfs an Rechenressourcen eignet sich das Protokoll ideal für eingebettete Systeme und Geräte mit begrenztem Speicher.

Architektur und Datenmodell

Das registerbasierte Datenmodell beruht auf vier Arten von Adressräumen:

• Coils (0x) — diskrete Ausgänge (lesbare und schreibbare Bitwerte)
• Discrete Inputs (1x) — diskrete Eingänge (nur lesbar)
• Input Registers (3x) — 16-Bit-Eingangsregister (nur lesbar)
• Holding Registers (4x) — 16-Bit-Halteregister (lesbar und schreibbar)

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

Übertragung

Modbus RTU:

• Serielle Leitungen RS-485 (bis zu 32 Geräte pro Bus, Reichweite bis 1200 m) oder RS-232 (Punkt-zu-Punkt)
• Binäre Datendarstellung
• Integritätsprüfung über CRC-16
• Übertragungsrate: von 1200 bis 115200 Baud
• Halbduplex-Übertragung

Modbus TCP:

• Kapselung der 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)

Wesentliche Funktionen

• Lesen und Schreiben diskreter Signale (Coils) und Register
• Unterstützung der Standard-Funktionscodes (FC 01–06, 15–16, 23)
• Diagnosefunktionen (FC 08)
• Auslesen der Geräteidentifikationsdaten (FC 17, 43)
• Minimaler Bedarf an Rechenressourcen der Geräte
• Einfache Implementierung und Fehlersuche
• Geringe Implementierungskosten
• Behandlung von Ausnahmen und Fehlercodes
• Unterstützung von Broadcast-Nachrichten (Adresse 0) bei RTU
• Skalierbarkeit auf bis zu 247 Geräte 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. Von der OPC Foundation als Nachfolger der klassischen Spezifikationen OPC DA/AE/HDA entwickelt, beseitigt er die Abhängigkeit von Microsoft-DCOM-Technologien. Er ermöglicht die vertikale und horizontale Integration in industriellen Systemen — von der Feldebene bis zu betrieblichen Informationssystemen (ERP, MES). Dank umfangreicher Möglichkeiten der Informationsmodellierung unterstützt er die Konzepte von Industrie 4.0 und digitalen Zwillingen.

Architektur und Datenmodell

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

• Knoten verschiedener Typen: Variable, Object, Method, View, DataType, ReferenceType
• Knotenattribute: Value, DataType, AccessLevel, Timestamp, Quality, DisplayName usw.
• Referenzen zwischen Knoten: hierarchisch, assoziativ, komponentenbasiert
• Datentypen: Primitive, Strukturen, Arrays, Aufzählungen

Unterstützte Dienste:

• Subscription — Überwachung von Datenänderungen mit konfigurierbaren Abtastintervallen und Filtern
• Events & Alarms — asynchrone Benachrichtigungen über Ereignisse, Alarme und Zustände
• Historical Access — Zugriff auf archivierte Daten und Ereignisse
• Methods — Remote-Aufruf von Prozeduren auf Geräten

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

Übertragung

UA Binary Protocol über TCP/IP:

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

HTTPS / SOAP:

• Web-Services-Profil zur 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

Wesentliche Funktionen

• Informationsmodellierung: Übertragung nicht nur „roher“ Werte, sondern komplexer strukturierter Daten mit Semantik, Typisierung und Metadaten
• Subscriptions mit konfigurierbaren Abfrageintervallen, Deadband-Filtern und Pufferung
• Ereignisse und Alarmsystem mit bedingter Filterung
• Methodenaufruf zur Gerätesteuerung und Ausführung von Operationen
• Zugriff auf historische Daten mit Aggregation
• Service Discovery in lokalen Netzen
• Integrierte Sicherheit: Kanalverschlüsselung, Authentifizierung über Zertifikate oder Benutzername/Passwort, Zugriffskontrolle auf Knotenebene
• Serverredundanz und Ausfallsicherheit
• Plattformübergreifend: Windows, Linux, VxWorks, QNX und weitere 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 Verwaltung von IoT-Geräten, optimiert für unzuverlässige Netze, begrenzte Bandbreite und hohe Latenzen. 1999 von IBM zur Überwachung von Ölpipelines entwickelt und von OASIS sowie ISO/IEC (20922:2016) standardisiert. Weit verbreitet im industriellen IoT, in Smart Homes, in der Fahrzeugtelematik und in mobilen Anwendungen. Das Protokoll legt den Schwerpunkt auf die Minimierung von Netzwerkverkehr und Energieverbrauch der Geräte.

Architektur und Datenmodell

Asynchrones Publish/Subscribe-Modell mit zentralem Broker:

• Publisher — Gerät oder Anwendung, die Nachrichten an Topics veröffentlicht
• Subscriber — Gerät oder Anwendung, die Nachrichten aus Topics abonniert
• Broker — zentraler Server für das Routing von Nachrichten (Mosquitto, HiveMQ, EMQ X usw.)

Topics — hierarchische Pfadstruktur zur Kategorisierung von Nachrichten:

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

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

Übertragung

• Transportschicht: TCP/IP (Port 1883 für ungesicherte Verbindungen)
• TLS/SSL (Port 8883) für Verschlüsselung und Authentifizierung
• WebSockets zur Integration in Browser und Webanwendungen
• Protokollversionen: MQTT 3.1.1 (am weitesten verbreitet), MQTT 5.0 (erweiterter Funktionsumfang)
• Header-Größe: mindestens 2 Byte (Fixed Header)
• Keep-alive-Mechanismus: periodisches PINGREQ/PINGRESP zur Verbindungsüberwachung
• Der brokerbasierte Betrieb gewährleistet die Entkopplung von Publisher und Subscriber, horizontale Skalierung und zentrale Verwaltung

Wesentliche Funktionen

• QoS (Quality of Service) mit drei Stufen der Zustellgarantie:
  • QoS 0: At most once (ohne Bestätigung)
  • QoS 1: At least once (mit Bestätigung)
  • QoS 2: Exactly once (vierstufiger Handshake)
• Minimaler Netzwerk-Overhead: 2 Byte Fixed Header, effiziente Binärkodierung
• LWT (Last Will and Testament): automatischer Benachrichtigungsmechanismus bei unerwarteter Trennung eines Geräts — der Broker veröffentlicht eine vordefinierte Nachricht, wenn der Client die Sitzung nicht ordnungsgemäß beendet
• Clean Session / Persistent Session: Möglichkeit, Abonnements und Nachrichten nach erneuter Verbindung wiederherzustellen
• Retained Messages: Verfügbarkeit des 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 Versorgungszählern: Strom, Gas, Wasser und Wärme (Device Language Message Specification / Companion Specification for Energy Metering). Entwickelt von der DLMS User Association gemeinsam mit der IEC, um die Interoperabilität intelligenter Zähler in automatisierten Mess- und Abrechnungssystemen (AMBS) sicherzustellen. Er ermöglicht das Fernauslesen von Zählern, die Überwachung der Spannungsqualität, die Tarifverwaltung sowie die Erkennung unbefugter Zugriffe. Weit verbreitet bei Stromnetzbetreibern, Versorgungsunternehmen und Integratoren von Smart-Grid-Systemen.

Architektur und Datenmodell

COSEM-Objektmodell (Companion Specification for Energy Metering):

• Zählerdaten werden als logische Objekte (COSEM-Objekte) mit Interface-Klassen dargestellt
• OBIS-Codes (Object Identification System) — Sechs-Byte-Bezeichner zur universellen Adressierung von Parametern: A-B:C.D.E*F
  • A — Energieart (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
• 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
• Load Profiles: Pufferobjekte zur Speicherung von Zeitreihendaten
• Skriptsystem: Ausführung von Aktionssequenzen auf dem Zähler

Übertragung

Bitübertragungs- und Sicherungsschicht:

• Optische Schnittstelle (IEC 62056-21, Flag) — Direktverbindung über einen Infrarotkopf zum lokalen Auslesen
• RS-485 / RS-232 mit HDLC-Protokoll (High-Level Data Link Control) für Multidrop-Netze
• TCP/IP (Port 4059) — DLMS over TCP oder IP-Kapselung für den 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ärmemesssystemen

Übertragungsprofile je nach Zählerimplementierung:

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

Wesentliche Funktionen

• Zählerauslesung — aktuelle Werte von Energieverbrauch, Leistung, Spannung, Strom und Leistungsfaktor
• Load Profiles — detaillierte zeitgestempelte Daten (15-Minuten-, Stunden- und Tagesintervalle)
• Ereignisprotokolle — Erfassung von Manipulationen am Gehäuse, Stromausfällen, Überspannungen und Parameteränderungen
• Mehrstufige Authentifizierung und Autorisierung: rollenbasierte Zugriffskontrolle (öffentlicher Zugriff, Lesen, Konfiguration)
• Tarifverwaltung — Fernänderung von Tarifplänen und -sätzen
• Zeitsynchronisation für die Genauigkeit der Zeitstempel
• Relaissteuerung (Zuschalten/Abschalten der Last)
• Überwachung der Spannungsqualität (Spannungseinbrüche, Spannungsspitzen, Oberschwingungen)
• Unterstützung von Gruppenoperationen über mehrere Zähler hinweg
• Kryptografischer Datenschutz und Nachrichtenintegrität