Latenz bei Datenquellen: Ursachen, Messung und Praxisbeispiel

Lesedauer: 5min Veröffentlicht am: August 3, 2026. Zuletzt überarbeitet am: August 3, 2026 Der Autor des Beitrages ist Maximilian Backenstos.
Latenz bezeichnet bei Datenquellen die Zeitspanne zwischen der Entstehung eines Messwerts an einer Maschine oder einem Sensor und dem Moment, in dem dieser Wert im Zielsystem, etwa smartPLAZA, verfügbar und nutzbar ist. Je nach Anwendungsfall reicht sie von wenigen Millisekunden bei sicherheitsrelevanten Steuerungen bis zu mehreren Stunden bei Tages- oder Wochenreports.
Inhalte auf dieser Seite
Primary Item (H2)Sub Item 1 (H3)

Was ist Latenz?

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:

  1. Die Maschine, an der er im Rahmen der Messdatenerfassung entsteht.
  2. Ein Gateway, das ihn weiterleitet.
  3. Das Zielsystem (z.B. smartPLAZA), in dem er gespeichert und angezeigt wird.

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.

Einflussfaktoren auf die Latenz

Latenz entsteht nicht an einer einzigen Stelle, sondern summiert sich aus mehreren Faktoren entlang der Datenstrecke:

  • Erfassung: Bevor ein Wert überhaupt weitergegeben werden kann, muss der Sensor oder die Steuerung ihn zunächst messen und intern bereitstellen. Je nach Gerät und Abtastrate dauert bereits dieser erste Schritt unterschiedlich lange.
  • Leitungsdauer: Die reine Übertragungszeit über die physische Verbindung, abhängig von der Leitungslänge sowie der Qualität der Leitung selbst.
  • Protokoll: Nicht jedes Kommunikationsprotokoll ist gleich schnell. OPC UA, Modbus TCP, MQTT oder proprietäre Herstellerprotokolle unterscheiden sich in der Geschwindigkeit, in der Nachrichtengröße und darin, wie viele Bestätigungsschritte („Handshakes") pro Übertragung nötig sind.
  • Timeouts: Antwortet eine Datenquelle nicht innerhalb einer festgelegten Zeitspanne, wird die Anfrage wiederholt oder abgebrochen. Solche Wartezeiten und Wiederholungsversuche schlagen sich folglich direkt in der gemessenen Latenz nieder, besonders bei instabilen Verbindungen.
  • Verarbeitung unterwegs: Werden Rohdaten gefiltert, umgerechnet oder zu Mittelwerten aggregiert, bevor sie weitergeleitet werden, kostet auch das Zeit, dafür sinkt oft im Gegenzug das Datenvolumen.
  • Bandbreite & Auslastung: Wie viel anderer Datenverkehr läuft gleichzeitig über dieselbe Leitung und wie stabil ist die diese? Eine ausgelastete Verbindung verzögert den Übertrag. Typische Stolperfallen können auch schlechte WLAN-Netze oder Mobilfunkverbindungen sein.
  • Verarbeitungsgeschwindigkeit der eingesetzten Software: Für die Zwischenschritte des Gateways und die Verarbeitung im Zielsystem wird auch Zeit benötigt, was wiederum auch von der Datenmenge und der eingesetzten Hardware abhängt.

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.

Wie kann die Latenz gemessen werden?

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.

Architekturdiagramm: Datenfluss von der Maschine über das Gateway zu smartPLAZA mit Zeitstempeln t0, tgateway und tsmartplaza sowie Formeln zur Latenzberechnung

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.

Prüffall: Gateway Lokal installiert vs. im 400km entfernten Rechenzentrum

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.

Situation

  • Anlage: S7-1500 SPS an einer Maschine, angebunden über das S7-Protokoll
  • Ziel: Abruf von 26 Messwerten von einer SPS alle 0,6 Sekunden
  • Aufbau A (lokal): Gateway vor Ort in der Fertigungshalle auf einem Edge PC installiert,
  • Aufbau B (Rechenzentrum): identische Schnittstelle, Gateway jedoch in 400km entferntem Rechenzentrum installiert
  • smartPLAZA: In Aufbau A & B im 400km entfernten Rechenzentrum installiert
  • Messgröße: Zeit zwischen zwei in smartPLAZA gestempelten Zeilen, gemessen über einen längeren Betriebszeitraum

Ergebnis

  • Stichprobengröße: 192.937 Messungen im lokalen Aufbau, 87.775 Messungen im Rechenzentrums-Aufbau (im Schaubild jeweils als „n" angegeben)
  • Gemessene mittlere Latenz Aufbau A (lokal): 0,61 Sekunden
  • Gemessene mittlere Latenz Aufbau B (Rechenzentrum): 0,90 Sekunden
  • Damit liegt die lokale Verarbeitung im Mittel rund 0,29 Sekunden (-23,3%) vor der Verarbeitung über das Rechenzentrum
  • Bei der Betrachtung nach Perzentilen zeigt sich ein differenzierteres Bild: Auf der Teilstrecke SPS zum Gateway liegen im lokalen Aufbau 51,3 % der Messungen unter 0,6 Sekunden, im Rechenzentrums-Aufbau sind es 0,0 %. Innerhalb einer Sekunde haben die Aufbauten auf dieser Teilstrecke mit 99,9 % bzw. 96,3 % noch eine Differenz von knapp 4%.
    Auf der Teilstrecke Gateway zu smartPLAZA liegen beide Aufbauten dagegen dicht beieinander (93,1 % bzw. 95,3 % unter einer Sekunde), was zeigt, dass der Unterschied zwischen lokaler und zentraler Verarbeitung überwiegend auf der ersten Teilstrecke entsteht, nicht auf der Übertragung zu smartPLAZA selbst
  • Einordnung: Für Anwendungsfälle im Sekundenbereich (z. B. Live-Dashboards) ist der gemessene Unterschied relevant und spürbar; für Reporting- und Analysezwecke im Minutenbereich fällt er praktisch nicht ins Gewicht
Histogramm der Latenzverteilung: lokale Verarbeitung mit Mittelwert 0,61 Sekunden gegenüber Verarbeitung über Rechenzentrum mit Mittelwert 0,90 Sekunden

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.

Vier-Felder-Tabelle: Anteil der Messungen unter bestimmten Latenzschwellen, getrennt nach Teilstrecke und Aufbau (lokal vs. Rechenzentrum)

Welcher Aufbau passt zu welchem Anwendungsfall?

Aus der Latenz-Anforderung des jeweiligen Anwendungsfalls (siehe Tabelle oben) lässt sich eine erste Orientierung für die passende Architektur ableiten:

  • Im Millisekundenbereich sollte die Verarbeitung möglichst nah an der Datenquelle liegen, also lokal am Gateway, um Übertragungswege kurz zu halten.
  • Im Sekundenbereich sind sowohl lokale als auch zentrale Verarbeitung möglich, sofern Netzwerkanbindung und Protokoll stabil sind. Hier entscheidet oft erst die konkrete Messung, welcher Aufbau schneller ist.
  • Im Minuten- bis Stundenbereich ist zentrale Verarbeitung im Rechenzentrum in der Regel ausreichend und bietet Vorteile bei Skalierung und Wartung.

Wie stark sich lokale gegenüber zentraler Verarbeitung tatsächlich auswirkt, zeigt der vorangegangene Prüffall mit konkreten Messwerten.

Fazit

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.

Q&A

Was ist eine akzeptable Latenz für Produktionsdaten?

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.

Ist ein lokales Gateway grundsätzlich schneller als ein zentrales Rechenzentrum?

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.

Wie wird Latenz konkret gemessen?

Ü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.

Welche Rolle spielt das Übertragungsprotokoll für die Latenz?

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.

Sie möchten mehr zum Thema Latenz bei Datenquellen: Ursachen, Messung und Praxisbeispiel erfahren?
Der Autor Maximilian ist Geschäftsführer bei DatenBerg. Er begleitet Kunden von der Datenerfassung bis hin zur automatisierten Auswertung. Ist er nicht bei Kunden im Einsatz, hält er Vorträge zu den Themen Daten nutzen in der Produktion, Anwendungsfälle von Industrie 4.0 und automatisierte Auswertung von Produktionsdaten. Gerne besprechen wir mit Ihnen, wie das Thema Latenz bei Datenquellen: Ursachen, Messung und Praxisbeispiel in Ihrer Produktion umgesetzt werden kann. Kontaktieren Sie uns hier.

Ähnliche Beiträge