Latenz ist die Zeit, die ein Messwert von seiner Entstehung bis zu seiner Verfügbarkeit im Zielsystem benötigt.
In der Maschinendatenerfassung in der Produktion gliedert sich die Verarbeitung oft in drei Schritte:
Wie schnell dieser Weg zurückgelegt wird, beeinflusst unmittelbar die Reaktionszeit auf Störungen, die Aktualität von Dashboards und die Zuverlässigkeit von Auswertungen, und sollte daher nicht dem Zufall überlassen werden.
Messbar wird Latenz über Zeitstempel: An jeder Station wird der Zeitpunkt festgehalten, zu dem der Wert dort ankommt bzw. verarbeitet wird. Die Differenz zwischen zwei solchen Zeitstempeln ergibt die Latenz der jeweiligen Teilstrecke, und die Summe aller Teilstrecken die Gesamtlatenz. Voraussetzung dafür ist, dass alle beteiligten Systeme zeitlich synchronisiert sind, da bereits kleine Abweichungen zwischen den Uhren die gemessene Latenz verfälschen würden. Hier empfiehlt sich der Einsatz eines zentralen NTP-Servers zur Synchronisierung der einzelnen Elemente.
Latenz entsteht nicht an einer einzigen Stelle, sondern summiert sich aus mehreren Faktoren entlang der Datenstrecke:
Keiner dieser Faktoren wirkt isoliert, sondern sie addieren sich in der Praxis zu der Gesamtlatenz, die letztlich im Zielsystem ankommt. Ebenfalls kann eine Fehlfunktion, wie mangelnde Bandbreite eine Kettenreaktion hervorrufen. Müssen Daten kurzzeitig gepuffert werden, kann sich zum Beispiel die Verarbeitungsgeschwindigkeit im Gateway reduzieren.
Auf dem Weg in die smartPLAZA durchläuft ein Messwert drei zentrale Stationen: die Datenquelle an der Maschine, ein Gateway zur Protokollumsetzung und Pufferung sowie schließlich smartPLAZA selbst zur Speicherung und späteren Darstellung. Zwischen jedem dieser Übergänge lässt sich die Latenz messen, wodurch sich die Gesamtverzögerung in klar abgrenzbare Teilstrecken zerlegen lässt. Sowohl das Gateway als auch die smartPLAZA stempelt die Daten, sobald diese fertig verarbeitet sind. Die Zeit an der Quelle lässt sich dagegen oft nicht bestimmen, außer die Datenquelle stellt diese bereit. Von daher kann um die Latenz bis zum Gateway zu berechnen alternativ die Zeit zwischen zwei Datenpunkten am Gateway betrachtet werden.

Wie stark die Latenz an jeder dieser Schnittstellen tatsächlich ausfällt, hängt stark vom konkreten Aufbau ab. Der folgende Prüffall zeigt das anhand realer Messungen.
Macht es einen messbaren Unterschied, ob Daten direkt vor Ort in der Fertigungshalle verarbeitet werden oder erst den Weg in ein 400km entferntes Rechenzentrum zurücklegen müssen? Dieser Prüffall vergleicht beide Aufbauten unter sonst gleichen Bedingungen.

Während das Histogramm die Latenz über die gesamte Strecke betrachtet, schlüsselt die folgende Tabelle den Unterschied nach Teilstrecke auf und zeigt, an welcher Stelle er tatsächlich entsteht.

Aus der Latenz-Anforderung des jeweiligen Anwendungsfalls (siehe Tabelle oben) lässt sich eine erste Orientierung für die passende Architektur ableiten:
Wie stark sich lokale gegenüber zentraler Verarbeitung tatsächlich auswirkt, zeigt der vorangegangene Prüffall mit konkreten Messwerten.
Der Prüffall und die daraus abgeleitete Einordnung zeigen: Latenz ist kein abstrakter Wert, sondern das Ergebnis konkreter architektonischer Entscheidungen. Der Vergleich zwischen lokalem Gateway und Rechenzentrum macht deutlich, dass eine größere Leitungsdauer und Timeouts, sich auf die Latenz auswirken. Für die Praxis bedeutet das: Wer weiß, an welcher Stelle der Kette die Latenz tatsächlich entsteht, ob bei der Erfassung, der Übertragung, der Verarbeitung oder der Speicherung, kann folglich gezielt dort ansetzen, wo es für den jeweiligen Anwendungsfall wirklich zählt. Nicht jeder Prozess benötigt eine Reaktionszeit im Millisekundenbereich, aber jeder Prozess sollte die für ihn passende Latenz bewusst wählen können.
Das hängt vom Anwendungsfall ab: Sicherheitsrelevante Steuerungen benötigen Latenzen im Millisekundenbereich, während für Reporting- und Analysezwecke auch Latenzen im Sekunden- bis Minutenbereich üblicherweise ausreichen.
Nicht zwangsläufig. Wie der Prüffall in diesem Beitrag zeigt, hängt der tatsächliche Unterschied von Netzwerkqualität, Datenvolumen und Protokoll ab und lässt sich nur durch reale Messung verlässlich beurteilen.
Über Zeitstempel an den einzelnen Stationen der Datenstrecke, etwa bei Entstehung des Messwerts, bei Ankunft am Gateway und bei Ankunft im Zielsystem. Die Differenz zwischen zwei Zeitstempeln ergibt die Latenz der jeweiligen Teilstrecke, vorausgesetzt, alle beteiligten Systeme sind zeitlich synchronisiert.
Protokolle wie OPC UA, Modbus TCP oder MQTT unterscheiden sich im Overhead und in der Anzahl nötiger Bestätigungsschritte, was sich direkt auf die Übertragungszeit auswirkt. Welches Protokoll am schnellsten ist, hängt vom konkreten Anwendungsfall und der vorhandenen Infrastruktur ab.