Messdaten am Edge verdichten: Mittelwert, Minimum, Maximum und Rohdaten sinnvoll kombinieren

IIoT Messdaten am Edge verdichten Rohdaten, Mittelwert, Minimum und Maximum kombinieren
→ Produktkategorie: IIoT-Lösungen

 

Ein Sensor liefert jede Sekunde einen Messwert. Bei 100 Messstellen entstehen damit bereits 8,64 Millionen Werte pro Tag – noch bevor Zeitstempel, Qualitätsinformationen, Protokoll-Overhead, Datenbankindizes oder Sicherungskopien berücksichtigt werden. Werden alle Rohdaten dauerhaft in eine zentrale Plattform übertragen, steigen Bandbreite, Speicherbedarf und Kosten schnell an.

Eine reine Reduzierung auf Stunden- oder Tagesmittelwerte löst das Problem jedoch nur scheinbar. Kurze Druckspitzen, Temperaturabfälle, Anlaufströme oder Vibrationen können vollständig verschwinden, obwohl sie für Instandhaltung und Fehleranalyse entscheidend sind. Sinnvolle Datenverdichtung muss deshalb Datenmengen reduzieren, ohne die betrieblich wichtigen Informationen zu zerstören.

Dieser Beitrag zeigt, wie Abtastrate, Zeitfenster, Mittelwert, Minimum, Maximum, Ereignisdaten und ausgewählte Rohdaten kombiniert werden. Außerdem wird erläutert, welche Zeit- und Qualitätsinformationen zu jedem Aggregat gehören und wie sich eine Datenstrategie aufbauen lässt, die Dashboards ebenso unterstützt wie eine spätere Ursachenanalyse.

Inhaltsverzeichnis

  1. Abtastung, Verarbeitung, Übertragung und Speicherung trennen
  2. Auswertungsziel vor der Verdichtung festlegen
  3. Zeitfenster eindeutig definieren
  4. Mittelwert richtig berechnen und interpretieren
  5. Minimum und Maximum zum Peak-Erhalt verwenden
  6. Count, Start, Ende und Streuung ergänzen
  7. Rohdaten gezielt statt vollständig verwerfen
  8. Ereignisgesteuerte Rohdaten und Ringpuffer einsetzen
  9. Zeitstempel und Uhrensynchronisation beherrschen
  10. Datenqualität und fehlende Werte sichtbar halten
  11. Speicherbedarf und Reduktionsfaktor abschätzen
  12. Mehrstufige Aufbewahrung planen
  13. Aufgaben zwischen Sensor, Edge und Cloud verteilen
  14. MQTT, OPC UA und Datenmodell zusammen denken
  15. Praxisbeispiel: Druckverlauf einer Anlage verdichten
  16. Empfohlener Ablauf für die Umsetzung
  17. Häufige Fehler bei der Datenverdichtung
  18. Passende IIoT-Produkte bei ICS Schneider
  19. Fazit
  20. FAQ: Messdaten am Edge aggregieren

Abtastung, Verarbeitung, Übertragung und Speicherung trennen

In IIoT-Projekten werden mehrere Zeitbegriffe häufig vermischt. Für eine belastbare Datenarchitektur sollten vier Ebenen getrennt betrachtet werden:

  • Abtastrate: Wie häufig erfasst der Sensor oder das Eingangsmodul den physikalischen Messwert?
  • Verarbeitungsrate: Wie häufig bewertet die lokale Logik neue Werte, aktualisiert Aggregate oder prüft Grenzwerte?
  • Übertragungsrate: Wie häufig sendet das Feldgerät oder Gateway Daten an das übergeordnete System?
  • Speicherrate: Welche Werte werden in der lokalen oder zentralen Datenbank tatsächlich dauerhaft abgelegt?

Ein Gerät kann beispielsweise jede Sekunde messen, jede Sekunde einen Grenzwert prüfen, aber nur alle fünf Minuten ein Datenpaket übertragen. Das bedeutet nicht automatisch, dass die Werte zwischen den Übertragungen verloren gehen. Je nach Gerät können sie lokal verarbeitet, gepuffert oder zu Aggregaten zusammengefasst werden. Diese Funktionen müssen jedoch konkret geprüft werden; die Bezeichnung „IIoT-fähig“ allein garantiert weder Mittelwertbildung noch Rohdatenspeicherung.

Die Trennung ist auch für die Fehlersuche wichtig. Ein geglätteter Verlauf kann aus einer niedrigen Sensorabtastrate, einem Gerätefilter, einer langsamen Übertragung oder einer nachträglichen Datenbankaggregation entstehen. Ohne dokumentierte Verarbeitungskette lässt sich später nicht mehr erkennen, an welcher Stelle Information verloren ging.

Auswertungsziel vor der Verdichtung festlegen

Die geeignete Verdichtung ergibt sich nicht aus dem verfügbaren Speicher, sondern aus der späteren Fragestellung. Typische Ziele unterscheiden sich deutlich:

  • Für Energie- und Mengenbilanzen sind zeitgewichtete Mittelwerte, Zählerstände oder Integrale entscheidend.
  • Für Grenzwertüberwachung müssen Minimum, Maximum und Grenzwertdauer erhalten bleiben.
  • Für Zustandsüberwachung sind Streuung, Änderungsrate, Frequenzanteile oder Ereignismerkmale relevant.
  • Für Ursachenanalysen werden Rohdaten vor, während und nach einem Ereignis benötigt.
  • Für Management-Dashboards reichen häufig längere Zeitfenster und stärker verdichtete Kennwerte.

Ein einziger Datenstrom kann nicht alle Anforderungen optimal erfüllen. Deshalb ist eine Kombination aus dauerhaft gespeicherten Aggregaten, zeitlich begrenzt verfügbaren Rohdaten und ereignisbezogenen Rohdatenblöcken meist robuster als die Entscheidung „alles speichern“ oder „nur Mittelwerte speichern“.

Zeitfenster eindeutig definieren

Jedes Aggregat bezieht sich auf ein Zeitfenster. Dieses Fenster muss eindeutig definiert sein. Für regelmäßige Berichte sind nicht überlappende, direkt aufeinanderfolgende Fenster – beispielsweise jede volle Minute – meist am einfachsten:

[10:00:00, 10:01:00), [10:01:00, 10:02:00), …

Die Schreibweise bedeutet: Der Startzeitpunkt gehört zum Fenster, der Endzeitpunkt bereits zum nächsten. Dadurch wird kein Messwert doppelt gezählt. Zusätzlich müssen Zeitzone, UTC-Bezug und Verhalten bei unvollständigen Fenstern festgelegt werden.

Überlappende gleitende Fenster eignen sich für laufende Zustandsbewertungen, erzeugen aber stärker voneinander abhängige Ergebnisse und mehr Daten. Ein gleitender 15-Minuten-Mittelwert, der jede Minute neu berechnet wird, besteht aus 15 Minuten Daten, liefert jedoch jede Minute einen neuen Wert. Für Archivierung und Abrechnung sind feste Fenster meist transparenter; für Online-Überwachung kann ein gleitendes Fenster sinnvoll sein.

Zum Datensatz gehören mindestens Fensterbeginn, Fensterende und verwendete Aggregationsmethode. Nur ein Zeitstempel „10:01“ ohne eindeutige Definition lässt offen, ob er Beginn, Ende oder Mitte des Fensters bezeichnet.

Mittelwert richtig berechnen und interpretieren

Bei konstantem Abtastabstand kann der arithmetische Mittelwert verwendet werden:

Mittelwert = Summe der gültigen Messwerte / Anzahl der gültigen Messwerte

Bei unregelmäßigen Abständen kann ein einfacher Mittelwert das Ergebnis verzerren. Dann ist ein zeitgewichteter Mittelwert geeigneter:

Zeitmittelwert = Σ(Messwert × Gültigkeitsdauer) / Σ(Gültigkeitsdauer)

Der Mittelwert beschreibt das durchschnittliche Niveau innerhalb des Fensters. Er enthält jedoch keine Information darüber, ob der Prozess ruhig war oder zwischen starken Ausschlägen schwankte. Die Folgen zeigt ein einfaches Beispiel:

  • 60 Werte konstant bei 5 bar ergeben einen Mittelwert von 5 bar.
  • 30 Werte bei 0 bar und 30 Werte bei 10 bar ergeben ebenfalls einen Mittelwert von 5 bar.

Beide Prozesse sind betrieblich völlig unterschiedlich. Der Mittelwert sollte deshalb zumindest mit Minimum und Maximum kombiniert werden. Bei dynamischen Anwendungen sind zusätzlich Standardabweichung, Spannweite oder Grenzwertdauer hilfreich.

Minimum und Maximum zum Peak-Erhalt verwenden

Minimum und Maximum bewahren die Höhe der innerhalb eines Fensters erfassten Extremwerte. Sie verhindern, dass eine kurze Spitze im Mittelwert vollständig verschwindet. Für die richtige Interpretation sind jedoch weitere Angaben erforderlich:

  • Zeitpunkt des Minimums und Maximums,
  • Qualitätsstatus der zugrunde liegenden Rohwerte,
  • Anzahl der gleich hohen Extremwerte, falls relevant,
  • Abtastrate und vorgelagerte Filterung.

Ein Maximum bewahrt nur die Höhe des Peaks, nicht dessen Form oder Dauer. Ein einzelner Messwert von 12 bar und eine Belastung von 12 bar über 40 Sekunden können im Minutenaggregat dasselbe Maximum erzeugen. Für Grenzwertbewertungen sollten deshalb zusätzlich die Dauer oberhalb des Grenzwerts, die Anzahl der Überschreitungen oder ein Ereignisdatensatz gespeichert werden.

Minimum und Maximum können außerdem nur Peaks erhalten, die überhaupt abgetastet wurden. Ein 20 Millisekunden langer Druckstoß bleibt bei einer Abtastung im Sekundentakt möglicherweise vollständig unsichtbar. Datenverdichtung beginnt daher erst nach einer anwendungsgerechten Signalerfassung und Filterung.

Count, Start, Ende und Streuung ergänzen

Für ein aussagekräftiges Aggregat sind vier Werte oft das sinnvolle Minimum:

Mittelwert + Minimum + Maximum + Anzahl gültiger Werte

Die Anzahl zeigt, ob das Fenster vollständig ist. Werden bei einer erwarteten Sekundenabtastung nur 42 statt 60 gültige Werte verarbeitet, ist ein Mittelwert zwar berechenbar, aber nicht ohne Weiteres mit einem vollständigen Fenster vergleichbar.

Je nach Anwendung können folgende Kennwerte ergänzt werden:

  • Start- und Endwert: Erhalten die Richtung der Veränderung und ermöglichen eine einfache Differenzbildung.
  • Standardabweichung: Beschreibt die Streuung, ohne die vollständige Signalform zu speichern.
  • Spannweite: Differenz aus Maximum und Minimum.
  • Grenzwertdauer: Zeit oberhalb oder unterhalb eines definierten Grenzwerts.
  • Anzahl der Zustandswechsel: Hilfreich bei Schaltern, Pumpen oder Ventilen.
  • Qualitätsanteile: Prozentsatz gültiger, unsicherer oder fehlerhafter Eingangswerte.

Welche Kennwerte gespeichert werden, sollte pro Messgröße festgelegt werden. Bei einer langsam veränderlichen Raumtemperatur kann Mittelwert, Minimum und Maximum genügen. Für Pumpendruck oder Maschinenstrom können zusätzliche Ereignis- und Streuungswerte erforderlich sein.

Rohdaten gezielt statt vollständig verwerfen

Aggregate lassen sich nicht wieder in die ursprünglichen Rohdaten zurückverwandeln. Sobald die Reihenfolge und Zwischenwerte gelöscht sind, bleiben spätere Analysen auf die gespeicherten Kennwerte beschränkt. Deshalb sollte vor der Löschung geklärt werden, welche noch unbekannten Fragestellungen in Zukunft auftreten können.

Eine robuste Strategie kombiniert drei Datenklassen:

  • Kurzzeit-Rohdaten: Vollständige Daten mit hoher Auflösung für einige Tage oder Wochen.
  • Langzeit-Aggregate: Mittelwert, Minimum, Maximum, Count und Qualitätsangaben über Monate oder Jahre.
  • Ereignis-Rohdaten: Hochaufgelöste Datenblöcke rund um Alarm, Stillstand, Wartung oder ungewöhnliche Veränderung.

Damit bleiben aktuelle Fehler detailliert untersuchbar, während langfristige Trends mit deutlich geringerem Speicherbedarf verfügbar sind. Für besonders wichtige Messstellen können Rohdaten länger aufbewahrt werden als für reine Komfort- oder Umgebungswerte.

Ereignisgesteuerte Rohdaten und Ringpuffer einsetzen

Wird ein Ereignis erst nach seinem Auftreten erkannt, sind die unmittelbar vorausgehenden Werte für die Ursachenanalyse oft am wertvollsten. Ein lokaler Ringpuffer speichert deshalb fortlaufend die letzten Minuten oder Stunden. Bei einem Trigger wird der relevante Bereich vor dem Ereignis gesichert und um einen definierten Nachlauf ergänzt.

Mögliche Trigger sind:

  • Über- oder Unterschreitung eines Grenzwerts,
  • ungewöhnlich schnelle Änderung,
  • große Spannweite oder Standardabweichung im kurzen Fenster,
  • Zustandswechsel einer Maschine,
  • Kommunikationsausfall oder schlechte Signalqualität,
  • manuelle Markierung durch Servicepersonal.

Trigger benötigen Hysterese, Mindestdauer und gegebenenfalls eine Sperrzeit, damit ein verrauschtes Signal nicht unzählige Ereignisse erzeugt. Außerdem muss festgelegt werden, wie gleichzeitige oder überlappende Ereignisse zusammengeführt werden.

Zeitstempel und Uhrensynchronisation beherrschen

Eine Messreihe ist nur dann systemübergreifend auswertbar, wenn der Zeitbezug zuverlässig ist. Idealerweise werden mehrere Zeitpunkte unterschieden:

  • Quellzeit: Zeitpunkt, zu dem Sensor oder Steuerung den Wert erfasst hat.
  • Edge-Eingangszeit: Zeitpunkt, zu dem das Gateway den Wert erhalten hat.
  • Übertragungs- oder Speicherzeit: Zeitpunkt der Übermittlung beziehungsweise Datenbankaufnahme.

Für Prozessanalysen ist grundsätzlich die Quellzeit entscheidend. Die Eingangs- und Speicherzeit helfen, Kommunikationsverzögerungen, Pufferung und nachträglich übermittelte Daten zu erkennen. Alle beteiligten Uhren müssen über eine geeignete Zeitquelle synchronisiert werden; die erforderliche Genauigkeit richtet sich nach der Prozessdynamik.

Bei der Aggregation sind verspätete Daten zu berücksichtigen. Ein Minutenfenster darf nicht stillschweigend nachträglich andere Werte erhalten, ohne Versionierung oder Kennzeichnung. Sinnvoll sind eine definierte Nachlaufzeit, ein Status für unvollständige Fenster und klare Regeln für nachträglich eintreffende Messwerte.

Datenqualität und fehlende Werte sichtbar halten

Ein Mittelwert aus 60 guten Messwerten ist nicht gleichwertig mit einem Mittelwert aus zehn unsicheren Werten und 50 Kommunikationslücken. Qualitätsinformationen dürfen bei der Verdichtung deshalb nicht verloren gehen.

Zu jedem Aggregat sollten mindestens gespeichert werden:

  • Anzahl erwarteter und tatsächlich verwendeter Werte,
  • Anzahl oder Anteil ungültiger und unsicherer Werte,
  • Status „vollständig“ oder „Teilfenster“,
  • Information, ob Werte interpoliert oder ersetzt wurden,
  • Geräte- und Kommunikationsstatus, sofern verfügbar.

Fehlende Werte dürfen nicht automatisch als null interpretiert werden. Ebenso sollte ein ungültiger Extremwert nicht ohne definierte Regel als Minimum oder Maximum erscheinen. Die OPC-UA-Aggregatmodelle zeigen, wie eng Aggregat, Zeitfenster und Qualitätsstatus zusammengehören: Neben Funktionen wie Minimum und Maximum werden auch Qualitäts- und Teilfensterzustände beschrieben.

Speicherbedarf und Reduktionsfaktor abschätzen

Die Anzahl der Rohwerte pro Tag lässt sich einfach abschätzen:

Rohwerte pro Tag = Sensoranzahl × Abtastrate × 86.400

Bei 100 Sensoren und einer Abtastung pro Sekunde entstehen 8,64 Millionen Rohwerte täglich. Werden je logischem Datensatz beispielhaft 32 Byte für Wert, Zeitstempel, Kennung und Status angesetzt, sind das rund 276 MB pro Tag – ohne Datenbank-Overhead, Indizes, Replikation und Sicherungen.

Werden je Sensor und Minute Mittelwert, Minimum, Maximum und Count gespeichert, entstehen:

100 Sensoren × 1.440 Minuten × 4 Werte = 576.000 Aggregatwerte pro Tag

Gegenüber 60 Rohwerten pro Minute werden vier Kennwerte gespeichert. Die reine Werteanzahl sinkt damit in diesem Beispiel um den Faktor 15. Werden zusätzlich Zeitpunkte der Extremwerte, Qualitätsanteile und Ereignisdaten gespeichert, fällt die Reduktion geringer aus – die Aussagekraft steigt jedoch deutlich.

Für eine realistische Kapazitätsplanung müssen Nachrichten- und Datenbankformat, Kompression, Metadaten, Indexe, Replikation, Sicherung, Aufbewahrungsdauer und erwartete Ereignisrate einbezogen werden.

Mehrstufige Aufbewahrung planen

Statt alle Daten nach derselben Frist zu löschen, empfiehlt sich eine mehrstufige Aufbewahrung. Ein mögliches Konzept ist:

Datenebene Beispielauflösung Beispielhafte Aufbewahrung Hauptzweck
Rohdaten 1 Sekunde 14 Tage aktuelle Fehlersuche
Kurzzeit-Aggregate 1 Minute 12 Monate Betrieb und Instandhaltung
Langzeit-Aggregate 15 Minuten oder 1 Stunde mehrere Jahre Trends, Berichte und Planung
Ereignisdaten hohe Auflösung mit Vor- und Nachlauf nach Kritikalität Ursachenanalyse und Nachweis

Die Zeiträume sind keine allgemeingültige Vorgabe. Sie müssen zu Prozessrisiko, Gewährleistung, regulatorischen Anforderungen, Analysebedarf und Speicherbudget passen. Vor jeder automatischen Löschung sollte geprüft werden, ob Aggregate bereits vollständig und nachvollziehbar erzeugt wurden.

Aufgaben zwischen Sensor, Edge und Cloud verteilen

Verdichtung am Edge reduziert Übertragungsvolumen und funktioniert auch bei eingeschränkter Verbindung. Gleichzeitig darf die lokale Verarbeitung nicht zu einer undurchsichtigen Blackbox werden. Eine zweckmäßige Aufteilung kann so aussehen:

  • Sensor oder Messgerät: Physikalische Erfassung, notwendige Signalfilterung, Statusinformationen und gegebenenfalls lokale Grenzwertprüfung.
  • Edge-Gerät oder Gateway: Zeitbezug, Protokollumsetzung, Fensteraggregation, Ringpuffer, Ereigniserkennung und Store-and-forward.
  • Zentrale Plattform: Langzeitspeicherung, standortübergreifende Analyse, Visualisierung, Modellbildung und Verwaltung der Datenregeln.

Die Konfiguration der Edge-Logik muss versioniert werden. Ändert sich ein Zeitfenster von einer auf fünf Minuten oder wird eine Filterzeit angepasst, sind Daten vor und nach der Änderung nicht ohne Kennzeichnung vergleichbar. Deshalb gehören Konfigurationsversion und Berechnungsregel zum Datenmodell.

MQTT, OPC UA und Datenmodell zusammen denken

Ein Kommunikationsprotokoll löst nicht automatisch die semantischen Fragen der Verdichtung. MQTT transportiert Nachrichten, legt aber das fachliche Nutzdatenmodell nicht fest. Das Projekt muss daher selbst definieren, ob ein Wert Rohwert, Mittelwert oder Maximum ist, auf welches Fenster er sich bezieht und welchen Qualitätsstatus er besitzt.

Ein Aggregatdatensatz sollte mindestens enthalten:

  • eindeutige Messstellenkennung,
  • Messgröße und Einheit,
  • Fensterbeginn und Fensterende,
  • Aggregationsfunktion,
  • Wert und gegebenenfalls Zeitpunkt des Extremwerts,
  • Sample-Anzahl und Qualitätsangaben,
  • Version der Berechnungs- und Gerätekonfiguration.

OPC UA beschreibt standardisierte Aggregatfunktionen und Qualitätszustände, unter anderem für Mittelwert, Minimum, Maximum, Count und Zeitpunkte von Extremwerten. Entscheidend ist dennoch, welche Funktionen das konkrete Gerät, der Server oder die Plattform tatsächlich unterstützt und wie sie konfiguriert sind.

Bei Funk- und LPWAN-Systemen ist außerdem zwischen Mess- und Übertragungsintervall zu unterscheiden. Ein Gerät kann häufiger messen, als es Datenpakete sendet. Das spart Energie und Funkvolumen, erfordert aber klare Regeln dafür, welche Informationen im Paket enthalten sind und was bei einer unterbrochenen Verbindung geschieht.

Praxisbeispiel: Druckverlauf einer Anlage verdichten

Eine Druckmessstelle wird jede Sekunde erfasst. Für das Betriebsdashboard sollen Minutenwerte übertragen werden, kurze Druckspitzen müssen jedoch für die Instandhaltung erkennbar bleiben.

Für jedes volle Minutenfenster speichert das Edge-System:

  • zeitgewichteten Mittelwert,
  • Minimum mit Zeitpunkt,
  • Maximum mit Zeitpunkt,
  • Start- und Endwert,
  • Anzahl gültiger und ungültiger Messwerte,
  • Zeit oberhalb des Warnwerts.

Parallel hält ein Ringpuffer die Rohdaten der letzten zehn Minuten. Überschreitet der Druck 8 bar oder steigt er innerhalb von zwei Sekunden um mehr als 1 bar, werden fünf Minuten vor und fünf Minuten nach dem Trigger als Ereignisdatensatz gesichert.

In einer Beispielminute liegen 59 Werte nahe 5 bar und ein Wert bei 9 bar. Der Mittelwert beträgt nur ungefähr 5,07 bar und würde im Trend unauffällig wirken. Das Maximum von 9 bar zeigt die Spitze. Der Zeitpunkt des Maximums erlaubt die Zuordnung zu einem Schaltvorgang, und der gesicherte Rohdatenblock zeigt Form, Dauer und Vorgeschichte des Peaks.

Fällt die Kommunikation zur zentralen Plattform aus, werden Aggregate und Ereignisdaten lokal gepuffert und später mit ursprünglicher Quellzeit übertragen. Die Empfangszeit in der Cloud ersetzt nicht den Messzeitpunkt.

Empfohlener Ablauf für die Umsetzung

  1. Messaufgabe beschreiben: Betriebsentscheidung, Alarm, Nachweis und spätere Analyse klar benennen.
  2. Prozessdynamik bestimmen: Kürzeste relevante Ereignisdauer und erforderliche Abtastrate festlegen.
  3. Signalweg dokumentieren: Sensorfilter, SPS-Zyklus, Gateway-Abfrage und Plattformverarbeitung erfassen.
  4. Fenster definieren: Länge, Ausrichtung, Zeitzone und Verhalten an Fenstergrenzen festlegen.
  5. Aggregate auswählen: Mittelwert, Minimum, Maximum, Count und anwendungsspezifische Zusatzwerte bestimmen.
  6. Qualitätsregeln festlegen: Ungültige, unsichere, fehlende und interpolierte Werte behandeln.
  7. Rohdatenstrategie planen: Kurzzeitaufbewahrung, Ringpuffer sowie Vor- und Nachlauf definieren.
  8. Ereignisse konfigurieren: Grenzwerte, Änderungsraten, Hysterese und Sperrzeiten festlegen.
  9. Zeit synchronisieren: Quellzeit, Eingangszeit, UTC-Bezug und zulässige Abweichung dokumentieren.
  10. Übertragung absichern: Pufferung, Wiederholung und Duplikaterkennung bei Verbindungsstörungen prüfen.
  11. Datenmodell versionieren: Berechnungsmethode, Einheiten und Konfigurationsstand mitführen.
  12. Mit realen Ereignissen testen: Peaks, Ausfälle, verspätete Daten und Gerätewechsel simulieren.
  13. Speicherbedarf messen: Reale Datensatzgröße und Ereignisrate statt nur theoretischer Werte verwenden.
  14. Regelmäßig überprüfen: Verdichtungsregeln an neue Analyse- und Betriebsanforderungen anpassen.

Häufige Fehler bei der Datenverdichtung

Fehler Typische Folge Bessere Vorgehensweise
Nur Mittelwerte speichern Kurze Extremwerte und Schwankungen verschwinden Mindestens Minimum, Maximum und Count ergänzen
Abtast- und Übertragungsintervall gleichsetzen Reale Messauflösung bleibt unklar Alle Verarbeitungsebenen getrennt dokumentieren
Maximum ohne Zeitpunkt speichern Keine Zuordnung zu Anlagenereignissen möglich Zeitpunkt des Extremwerts mitführen
Fehlende Werte als null behandeln Mittelwert und Minimum werden verfälscht Fehlwerte kennzeichnen und Count speichern
Unregelmäßige Werte arithmetisch mitteln Lange gültige Zustände werden falsch gewichtet Zeitgewichteten Mittelwert verwenden
Rohdaten sofort löschen Spätere Ursachenanalyse ist nicht mehr möglich Kurzzeit-Rohdaten und Ereignispuffer vorsehen
Keine Uhrensynchronisation Ereignisse verschiedener Systeme passen zeitlich nicht zusammen Geeignete Zeitquelle und zulässige Abweichung definieren
Aggregation ohne Qualitätsstatus Vollständige und lückenhafte Fenster wirken gleichwertig Qualitätsanteile und Teilfensterstatus speichern
Konfiguration stillschweigend ändern Historische Zeitreihen werden nicht vergleichbar Berechnungsregel und Version mit den Daten speichern

Passende IIoT-Produkte bei ICS Schneider

WIKA PEW-1000 – häufig messen und bedarfsgerecht übertragen

Der WIKA PEW-1000 ist ein funkbasierter Drucksensor für industrielle Anwendungen. Mess- und Übertragungsintervalle können abhängig vom Messwert konfiguriert werden. Das Gerät kann häufiger messen, ohne jeden einzelnen Messwert zu übertragen. Damit verdeutlicht es den grundlegenden Unterschied zwischen lokaler Erfassung und Funkübertragung besonders gut.

Welche Messwerte, Statusinformationen und Verdichtungsfunktionen in einer konkreten Konfiguration übertragen beziehungsweise in der Plattform verarbeitet werden, muss anhand der Geräte- und Systemkonfiguration festgelegt werden.

WIKA NETRIS®2 – zwei 4…20-mA-Signale per LoRaWAN® übertragen

Die WIKA Funkeinheit NETRIS®2 erfasst zwei eigensichere analoge 4…20-mA-Eingangssignale und überträgt die Messdaten über konfigurierbare LoRaWAN®-Datenpakete an eine Cloud. Sie eignet sich für Fernüberwachung und vorbeugende Instandhaltung in explosionsgefährdeten Bereichen.

WIKA NETRIS®3 – digitale Messgerätedaten in die IIoT-Struktur einbinden

Die WIKA Funkeinheit NETRIS®3 erhält Daten digital von einem passenden WIKA-Messgerät und überträgt sie über konfigurierbare Datenpakete mit LoRaWAN® an eine Cloud. Sie ist für zentralisierte Fernüberwachung und Big-Data-Anwendungen in der Prozessindustrie vorgesehen.

WIKA A2G-500 – dezentraler Datenknoten für die Gebäudetechnik

Der WIKA A2G-500 misst Differenzdruck, Relativdruck und Vakuum in Lüftungs- und Klimaanlagen. Messwerte stehen analog, über Modbus® RTU oder LoRaWAN® zur Verfügung. Als dezentraler Datenknoten kann das Gerät je nach Ausführung bis zu vier Eingangssignale einbinden.

Weitere Funkmessgeräte und Lösungen zur digitalen Druck-, Temperatur- und Füllstandsüberwachung finden Sie in der Kategorie IIoT-Lösungen bei ICS Schneider.

Fazit

Sinnvolle Edge-Verdichtung reduziert Datenmenge, ohne betriebliche Information unnötig zu vernichten. Der Mittelwert beschreibt das Niveau, Minimum und Maximum erhalten erfasste Extremwerte, Count und Qualitätsstatus zeigen die Belastbarkeit des Ergebnisses. Zeitpunkte der Extremwerte, Grenzwertdauer und Streuungskennwerte ergänzen die Aussage je nach Anwendung.

Rohdaten bleiben dennoch unverzichtbar, wenn Signalform, Ereignisfolge oder bisher unbekannte Zusammenhänge untersucht werden sollen. Eine praxistaugliche Architektur kombiniert deshalb kurzfristige Rohdaten, langfristige Aggregate und hochaufgelöste Ereignisdaten aus einem Ringpuffer.

Entscheidend sind klar definierte Zeitfenster, synchronisierte Uhren, nachvollziehbare Qualitätsregeln und eine versionierte Berechnung. Erst wenn Abtastung, Verarbeitung, Übertragung und Speicherung getrennt dokumentiert sind, bleiben Messdaten auch Monate oder Jahre später zuverlässig interpretierbar.

FAQ: Messdaten am Edge aggregieren

Welche Werte sollte ein Edge-Gerät mindestens speichern?

Für viele Prozessgrößen sind Mittelwert, Minimum, Maximum, Anzahl der gültigen Werte, Fensterbeginn, Fensterende und Qualitätsstatus ein sinnvoller Mindestumfang. Die genaue Auswahl hängt von Prozessdynamik und Auswertungsziel ab.

Reichen Minimum und Maximum aus, um Peaks zu erhalten?

Sie erhalten die Höhe eines abgetasteten Extremwerts, aber nicht dessen Form und Dauer. Für kritische Peaks sollten zusätzlich der Zeitpunkt, die Grenzwertdauer und ein Rohdatenblock rund um das Ereignis gespeichert werden.

Wann ist ein zeitgewichteter Mittelwert erforderlich?

Wenn Messwerte in unregelmäßigen Abständen eintreffen oder unterschiedlich lange gültig sind. Bei konstantem Abtastabstand entspricht der zeitgewichtete Mittelwert im Regelfall dem arithmetischen Mittelwert.

Wie lang sollte ein Aggregationsfenster sein?

Das Fenster muss deutlich kürzer als die relevanten Prozessänderungen sein und zur betrieblichen Entscheidung passen. Eine Minute kann für langsame Temperaturverläufe ausreichen, für Druckstöße oder Schwingungen jedoch viel zu lang sein.

Sollten Rohdaten vollständig gelöscht werden?

Nicht unmittelbar. Eine begrenzte Kurzzeitaufbewahrung und ereignisgesteuerte Rohdatenblöcke erhalten die Möglichkeit zur Ursachenanalyse, ohne alle Rohwerte dauerhaft speichern zu müssen.

Was geschieht bei einer unterbrochenen Verbindung?

Das Edge-System sollte Daten lokal puffern und später mit der ursprünglichen Quellzeit übertragen. Puffergröße, Überlaufverhalten, Wiederholung und Duplikaterkennung müssen definiert und getestet werden.

Ist MQTT bereits eine Datenverdichtung?

Nein. MQTT ist ein Transportprotokoll. Welche Rohwerte oder Aggregate übertragen werden und wie Zeitfenster, Qualität und Einheiten beschrieben sind, muss das Nutzdatenmodell festlegen.

Welche Rolle spielt OPC UA bei Aggregaten?

OPC UA definiert standardisierte Aggregatfunktionen und zugehörige Qualitätsinformationen. Ob ein konkreter Server oder ein Gerät diese Funktionen unterstützt, muss jedoch anhand seiner Implementierung und Konfiguration geprüft werden.

Warum sollte die Sample-Anzahl gespeichert werden?

Sie zeigt, ob das Zeitfenster vollständig ist und wie viele Werte tatsächlich in die Berechnung eingingen. Ohne Count können ein vollständiger und ein stark lückenhafter Mittelwert gleich aussehen.

Kann Edge-Verdichtung eine zu niedrige Abtastrate ausgleichen?

Nein. Ein nicht erfasster Peak kann später nicht rekonstruiert werden. Zuerst muss die Abtastrate zur Prozessdynamik passen; erst danach sollte verdichtet werden.

Diese Website benutzt Cookies. Wenn du die Website weiter nutzt, gehen wir von deinem Einverständnis aus.
Mehr Infos