Messwert plus Qualitätsstatus übertragen: Good, Bad und Uncertain in IIoT-Datenmodellen sinnvoll nutzen

→ Produktkategorie: IIoT-Lösungen

 

Ein Drucksensor meldet seit Stunden konstant 6,42 bar. Im Dashboard sieht der Verlauf vollkommen stabil aus. Tatsächlich ist die Kommunikation zum Sensor jedoch bereits vor zehn Minuten ausgefallen und das Edge-Gateway zeigt lediglich den zuletzt bekannten Wert weiter an. Für einen Benutzer, einen Historian oder eine automatische Auswertung sehen beide Situationen zunächst identisch aus: Es existiert ein Zahlenwert von 6,42 bar. Messtechnisch sind sie jedoch grundverschieden.

Genau deshalb sollte ein industrieller Datenpunkt nicht nur aus einem Messwert bestehen. Neben Wert und Einheit gehören mindestens der maßgebliche Zeitstempel und eine Information über die Verwendbarkeit des Wertes zum Datenmodell. Ein Qualitätsstatus wie Good, Uncertain oder Bad ermöglicht übergeordneten Systemen zu unterscheiden, ob ein Wert regulär gemessen wurde, nur eingeschränkt vertrauenswürdig ist oder überhaupt nicht mehr für die vorgesehene Auswertung verwendet werden darf.

Besonders konsequent ist dieses Prinzip in OPC UA umgesetzt. Dort besitzt ein Datenwert einen StatusCode, dessen grundlegende Qualitätsstufen Good, Uncertain und Bad sind. Wird derselbe Messwert über MQTT an einen Historian oder eine Cloud-Plattform übertragen, existiert eine solche Semantik jedoch nicht automatisch. Das Projekt muss selbst definieren, welche Qualitätsinformationen im Payload übertragen werden und wie sie von nachfolgenden Anwendungen interpretiert werden.

Ein robustes IIoT-Datenmodell beantwortet deshalb nicht nur die Frage „Wie hoch ist der Messwert?“, sondern gleichzeitig „Wann wurde er erfasst und unter welchen Bedingungen darf er verwendet werden?“ Erst die Kombination aus Wert, Zeit und Qualität macht aus einer Zahl einen belastbaren industriellen Datenpunkt.

Warum reicht der Messwert allein nicht aus?

In klassischen Messketten wird häufig selbstverständlich davon ausgegangen, dass ein angezeigter Wert auch ein aktuell gültiger Messwert ist. In einer vernetzten IIoT-Architektur kann sich zwischen Sensor und Benutzer jedoch eine lange Datenkette befinden. Ein Feldgerät liefert Daten an eine SPS oder einen IO-Link-Master, ein Edge-Gateway übernimmt diese Informationen, anschließend werden sie über OPC UA oder MQTT an einen Broker, Historian, ein Dashboard oder eine Cloud-Anwendung übertragen.

An jeder dieser Stellen kann ein Zustand entstehen, bei dem zwar noch eine Zahl vorhanden ist, ihre Aussagekraft aber verändert wurde. Die Kommunikation zum Sensor kann ausgefallen sein, ein Feldgerät kann einen internen Diagnosefehler melden, ein Wert kann außerhalb seines gültigen Messbereiches liegen oder eine Anwendung kann bewusst einen Ersatzwert verwenden. Ebenso kann ein Wert technisch korrekt gemessen worden sein, aber erst mehrere Minuten später aus einem lokalen Puffer übertragen werden.

Wird nur die Zahl weitergegeben, gehen diese Unterschiede verloren. Ein nachfolgendes System kann dann nicht mehr erkennen, ob 6,42 bar tatsächlich aktuell gemessen, aus einem vorherigen Zyklus übernommen oder aufgrund einer Störung nur noch als letzter bekannter Wert verfügbar ist. Besonders bei automatisierten Berichten, Energiekennzahlen, Condition Monitoring oder Machine-Learning-Anwendungen können solche scheinbar kleinen Informationsverluste später erhebliche Fehlinterpretationen verursachen.

Was bedeuten Good, Uncertain und Bad?

Die drei Qualitätsstufen sollten nicht als bloße Ampelfarben verstanden werden. Sie beschreiben die Verwendbarkeit eines Datenwertes. Ein Good-Wert ist unter den vorgesehenen Bedingungen verwendbar. Uncertain bedeutet, dass ein Wert vorhanden ist, seine Verwendbarkeit aber eingeschränkt oder zumindest fraglich ist. Bad bedeutet, dass der Wert für die eigentliche Messaufgabe nicht als gültiger Messwert verwendet werden sollte.

Qualitätsstatus	Grundbedeutung	Typisches Beispiel	Reaktion der Anwendung
Good	Wert ist regulär erfasst und für die vorgesehene Verwendung geeignet	Sensor arbeitet fehlerfrei, Kommunikation vorhanden, Wert im gültigen Bereich	Normal anzeigen, speichern und auswerten
Uncertain	Wert ist vorhanden, seine Aussagekraft ist jedoch eingeschränkt	Messbereichsgrenze erreicht, Ersatzwert verwendet oder Genauigkeit eingeschränkt	Wert sichtbar halten, aber kennzeichnen und abhängig von der Anwendung vorsichtig verwenden
Bad	Wert ist nicht als gültiger aktueller Messwert verwendbar	Sensorfehler, Kommunikationsausfall oder kein gültiger Wert vorhanden	Nicht ungekennzeichnet in Berechnungen übernehmen; Fehlerzustand sichtbar machen

Diese drei Stufen sind für viele Anwendungen ein guter Einstieg, reichen für eine professionelle Datenarchitektur allein jedoch häufig nicht aus. Zusätzlich sollte möglichst ein konkreter Grund übertragen werden. Ein Bad wegen Kommunikationsausfall ist betrieblich etwas anderes als ein Bad aufgrund eines internen Sensorfehlers. Ebenso kann Uncertain bedeuten, dass ein Wert zwar noch nutzbar ist, aber beispielsweise aus einem Ersatzverfahren stammt oder außerhalb der spezifizierten Genauigkeit liegt.

Welche Fehlerzustände sollten den Qualitätsstatus beeinflussen?

Der Qualitätsstatus sollte möglichst nahe an der tatsächlichen Fehlerursache erzeugt werden. Erkennt bereits das Feldgerät einen Sensorfehler, sollte diese Diagnose nicht erst auf dem Weg zur Cloud verloren gehen. Erkennt dagegen erst das Gateway, dass keine neuen Daten mehr eintreffen, muss die Edge-Ebene den Status entsprechend ändern können.

Situation	Sinnvoller Grundstatus	Zusätzliche Information
Messung und Kommunikation fehlerfrei	Good	Normalbetrieb
Messwert erreicht beziehungsweise überschreitet spezifizierten Bereich	Uncertain oder anwendungsspezifisch Bad	Out of range / limit exceeded
Sensor meldet internen Fehler	Bad	Sensor failure / device failure
Kommunikation zum Feldgerät unterbrochen	Bad	No communication / not connected
Letzter bekannter Wert wird weitergehalten	Nicht unverändert Good	Last usable value beziehungsweise stale data kennzeichnen
Ersatzwert wird manuell oder automatisch verwendet	Meist Uncertain	Substituted / local override
Gerät befindet sich bewusst in Wartung	Bad oder eigener Wartungsstatus	Out of service / maintenance

Wichtig ist dabei, dass diese Regeln bereits während der Projektierung definiert werden. Wenn jede SPS, jedes Gateway und jede Cloud-Anwendung selbst entscheidet, wann ein Wert Good oder Bad ist, entstehen unterschiedliche Bedeutungen für denselben Status. Ein unternehmensweit einheitliches Qualitätsmodell erleichtert dagegen die Wiederverwendung von Daten erheblich.

Warum gehören Zeitstempel und Qualitätsstatus zusammen?

Ein Qualitätsstatus kann nur zusammen mit dem zeitlichen Bezug vollständig interpretiert werden. Angenommen, ein Sensor liefert um 10:15:42 einen gültigen Druckwert von 6,42 bar. Um 10:15:45 fällt die Kommunikation aus. Wenn das Gateway anschließend weiterhin den letzten Wert anzeigt, muss klar erkennbar bleiben, dass dieser Wert ursprünglich um 10:15:42 erfasst wurde.

Würde stattdessen bei jedem Gateway-Zyklus ein neuer aktueller Zeitstempel erzeugt, könnte der alte Wert so aussehen, als sei er weiterhin frisch gemessen worden. Der Qualitätsstatus Bad würde zwar auf die Störung hinweisen, aber die Historie wäre trotzdem unnötig missverständlich. Besonders problematisch wird dies, wenn nachfolgende Anwendungen den Status nicht konsequent auswerten.

Deshalb sollte möglichst zwischen dem Zeitpunkt der tatsächlichen Messwerterfassung und späteren Verarbeitungs- beziehungsweise Übertragungszeitpunkten unterschieden werden. Für die Prozesshistorie ist in der Regel der ursprüngliche Messzeitpunkt entscheidend. Beim Store-and-Forward darf ein nach einer Stunde übertragenes Datenpaket nicht plötzlich so aussehen, als sei der darin enthaltene Messwert erst bei Wiederherstellung der Verbindung entstanden.

Qualitätsstatus in OPC UA

OPC UA behandelt die Datenqualität als festen Bestandteil eines Datenwertes. Neben dem eigentlichen Wert können Zeitinformationen und ein StatusCode übertragen werden. Die oberste Qualitätsstufe dieses StatusCodes unterscheidet zwischen Good, Uncertain und Bad. Zusätzlich stehen detailliertere Statusinformationen zur Verfügung, mit denen beispielsweise Kommunikations-, Geräte- oder Messbereichsprobleme genauer beschrieben werden können.

Das ist ein wesentlicher Vorteil gegenüber Datenmodellen, in denen lediglich eine Zahl übertragen wird. Ein OPC-UA-Client kann nicht nur 6,42 bar lesen, sondern gleichzeitig feststellen, ob dieser Wert für die vorgesehene Verarbeitung geeignet ist. Ein Historian kann einen Bad-Wert weiterhin dokumentieren, ohne ihn wie einen normalen Prozesswert in Mittelwerte oder Kennzahlen einzurechnen.

Beim Übergang von OPC UA auf ein anderes Protokoll sollte diese Information nicht verloren gehen. Liest ein Edge-Gateway beispielsweise einen OPC-UA-Datenpunkt mit einem detaillierten StatusCode und publiziert anschließend nur noch den nackten Zahlenwert über MQTT, wurde ein wesentlicher Teil des ursprünglichen Datenmodells entfernt.

Good, Bad und Uncertain über MQTT übertragen

MQTT transportiert Nachrichten, schreibt dem Anwendungs-Payload aber nicht automatisch vor, wie die Qualität eines Messwertes dargestellt werden muss. Genau deshalb muss bei einer MQTT-Architektur ein verbindliches Payload-Schema definiert werden. Ein schlankes Datenmodell könnte beispielsweise nicht nur den Wert, sondern Einheit, ursprünglichen Messzeitpunkt und Qualitätsstatus enthalten.

Beispiel:

{"value":6.42,"unit":"bar","quality":"Good","sourceTimestamp":"2026-09-01T10:15:42.250Z"}

Bei einem Kommunikationsausfall sollte nicht einfach derselbe Payload mit einem neuen Zeitstempel erneut als Good publiziert werden. Abhängig von der Architektur kann stattdessen beispielsweise ein Bad-Status mit Fehlergrund übertragen werden oder der Prozesswert kann auf null gesetzt werden, wenn überhaupt kein verwendbarer Wert mehr vorhanden ist.

{"value":null,"unit":"bar","quality":"Bad","reason":"NoCommunication","sourceTimestamp":"2026-09-01T10:15:45.000Z"}

Wird bewusst der letzte bekannte Wert mit übertragen, sollte dies ebenfalls eindeutig erkennbar sein:

{"value":6.42,"unit":"bar","quality":"Uncertain","reason":"LastUsableValue","sourceTimestamp":"2026-09-01T10:15:42.250Z"}

Die konkreten Feldnamen sind projektspezifisch. Entscheidend ist weniger, ob das Feld quality, status oder qualityCode heißt, sondern dass dessen Bedeutung dokumentiert und in allen beteiligten Systemen konsistent umgesetzt wird.

Statusinformationen aus Feldgeräten sinnvoll abbilden

Nicht jedes Feldgerät liefert direkt einen Qualitätswert namens Good, Uncertain oder Bad. Ein IO-Link-Sensor kann beispielsweise Prozessdaten zusammen mit Diagnose- und Statusinformationen bereitstellen. Ein HART-Gerät kann eigene Gerätestatus- und Diagnoseinformationen liefern. Eine SPS wiederum erkennt eventuell zusätzlich Kommunikationsfehler oder ungültige Eingangsbereiche.

Die Aufgabe des Edge- beziehungsweise Integrationssystems besteht dann darin, diese unterschiedlichen Informationen auf ein gemeinsames übergeordnetes Modell abzubilden. Meldet beispielsweise ein IO-Link-Drucksensor einen internen Gerätefehler, kann das Gateway daraus quality = Bad und reason = DeviceFailure erzeugen. Wird dagegen lediglich ein Warnzustand erkannt, bei dem der Messwert noch eingeschränkt nutzbar ist, kann eine Zuordnung zu Uncertain sinnvoller sein.

Diese Übersetzung sollte nicht spontan während der Programmierung entstehen. Ein Mapping-Dokument sollte festlegen, welche Feldgerätediagnose welchen IT/OT-Status erzeugt. Dadurch bleibt nachvollziehbar, warum ein bestimmter Messpunkt im Historian als Bad gespeichert wurde und welche technische Ursache dahinterlag.

Warum der letzte gültige Messwert gefährlich werden kann

Das Weiterhalten des letzten gültigen Wertes ist in vielen Steuerungs- und Visualisierungssystemen technisch sinnvoll. Ein Display springt dadurch bei einem kurzen Kommunikationsaussetzer nicht sofort auf Null und Trends bleiben optisch ruhiger. Problematisch wird dieses Verhalten erst, wenn der gehaltene Wert nicht eindeutig als solcher gekennzeichnet wird.

Ein Druck von 6,42 bar kann nach einem Sensorausfall zehn Sekunden, zehn Minuten oder mehrere Stunden auf dem Bildschirm stehen bleiben. Ein Mensch erkennt ohne zusätzliche Information nicht, dass sich dieser Wert seit dem Ausfall überhaupt nicht mehr aktualisiert hat. Eine automatisierte Anwendung erkennt es noch weniger, wenn sie ausschließlich das Zahlenfeld verarbeitet.

Deshalb sollte die Datenqualität mit zunehmendem Alter beziehungsweise beim erkannten Kommunikationsverlust verändert werden. Ob ein letzter Wert als Uncertain weitergegeben oder unmittelbar auf Bad gesetzt wird, hängt von der Anwendung ab. Für einen langsam veränderlichen Tankfüllstand kann ein wenige Sekunden alter Wert eventuell noch informativ sein. Für eine schnelle Sicherheitsfunktion wäre dieselbe Strategie völlig ungeeignet. Die Grenze zwischen „noch eingeschränkt nutzbar“ und „nicht mehr verwendbar“ ist damit Teil der Prozessanforderung.

Qualität bei Offline-Pufferung und Store-and-Forward

Ein Kommunikationsausfall zwischen Edge-Gateway und Cloud bedeutet nicht automatisch, dass die lokalen Messwerte schlecht sind. Läuft die Verbindung vom Sensor zum Gateway weiterhin einwandfrei, kann das Gateway weiterhin gültige Good-Werte mit korrektem ursprünglichem Zeitstempel erfassen und lokal speichern.

Wird die Cloud-Verbindung später wiederhergestellt, können diese Daten nachträglich übertragen werden. Ihre Qualität bleibt trotzdem Good, weil die eigentliche Messung zum damaligen Zeitpunkt gültig war. Lediglich der Übertragungszeitpunkt liegt später. Genau hier zeigt sich, warum Datenqualität und Transportzustand getrennt betrachtet werden sollten.

Anders ist die Situation, wenn bereits die Verbindung zwischen Feldgerät und Edge-Gateway ausgefallen war. Dann entstehen während dieses Zeitraums keine neuen gültigen Prozesswerte. Eine spätere Wiederverbindung darf die Lücke nicht dadurch kaschieren, dass der letzte Wert rückwirkend über den gesamten Zeitraum kopiert wird.

Wie Historian, Dashboard und Analyse reagieren sollten

Ein Qualitätsstatus besitzt nur dann einen praktischen Nutzen, wenn die empfangenden Systeme ihn tatsächlich auswerten. Das Dashboard kann einen Uncertain-Wert beispielsweise weiterhin anzeigen, aber visuell anders kennzeichnen. Bei Bad sollte erkennbar sein, dass kein gültiger aktueller Prozesswert vorliegt. Der Historian kann den Datensatz trotzdem speichern, damit die Störung später nachvollzogen werden kann.

Für Berechnungen muss zusätzlich festgelegt werden, welche Qualitätsstufen berücksichtigt werden dürfen. Ein Tagesmittelwert aus Druckdaten sollte nicht automatisch Werte enthalten, die während eines Kommunikationsausfalls als Bad markiert wurden. Auch Uncertain-Werte sollten abhängig von der Kennzahl bewusst ein- oder ausgeschlossen werden.

Dasselbe gilt für Machine Learning und Condition Monitoring. Werden historische Daten ungefiltert exportiert, kann ein über Stunden gehaltener letzter Messwert wie eine außergewöhnlich stabile Prozessphase aussehen. Die Qualitätsinformation sollte deshalb bis in den Analyse-Datensatz erhalten bleiben und nicht bereits beim Export entfernt werden.

Praxisbeispiel: Druckmessung verliert die Kommunikation

Ein IO-Link-Drucksensor misst an einer Pumpenstation einen Ausgangsdruck von 6,42 bar. Das Edge-Gateway erfasst Prozesswert, Sensorstatus und Zeitstempel und publiziert die Daten an einen MQTT-Broker. Im Normalbetrieb entsteht beispielsweise:

value = 6.42 bar | quality = Good | sourceTimestamp = 10:15:42

Um 10:15:45 wird die Verbindung zwischen IO-Link-Master und Sensor unterbrochen. Das Gateway besitzt noch den letzten Messwert, erkennt aber gleichzeitig, dass keine gültigen neuen Prozessdaten mehr eintreffen. Würde es weiterhin alle fünf Sekunden 6,42 bar mit Quality Good und neuem Zeitstempel veröffentlichen, entstünde im Historian eine vollständig falsche Prozesshistorie.

Stattdessen wird der Status auf Bad gesetzt und als Grund NoCommunication übertragen. Das Dashboard kann den letzten bekannten Wert weiterhin als Information anzeigen, kennzeichnet ihn jedoch klar als nicht aktuell gültig. Der Historian speichert den Ausfallzustand, verwendet die entsprechenden Werte aber nicht für normale Prozessmittelwerte.

Um 10:18:12 ist die Verbindung wieder verfügbar. Der nächste regulär erfasste Wert beträgt 6,57 bar und erhält wieder Quality Good. In der Historie ist damit eindeutig sichtbar, dass zwischen 10:15:45 und 10:18:12 keine gültigen neuen Druckwerte vorlagen.

Die Qualität beschreibt damit nicht, ob eine Zahl im Datenpaket vorhanden ist. Sie beschreibt, ob diese Zahl für die jeweilige Messaufgabe unter den bekannten Bedingungen verwendet werden darf.

Qualitätsmodell systematisch planen

1. Pro Datenpunkt festlegen, welche Informationen übertragen werden: mindestens Wert, Einheit, maßgeblicher Zeitstempel und Qualitätsstatus.
2. Good, Uncertain und Bad eindeutig definieren: Die gleiche Stufe muss in SPS, Edge, Historian und Cloud dieselbe grundsätzliche Bedeutung besitzen.
3. Fehlergründe ergänzen: Kommunikationsfehler, Sensorfehler, Messbereichsüberschreitung, Ersatzwert und Wartungszustand nicht alle nur als unspezifisches Bad behandeln.
4. Feldgerätediagnosen auf das zentrale Modell abbilden: Mapping für IO-Link, HART, Modbus, OPC UA und andere Quellen dokumentieren.
5. Stale- beziehungsweise Last-Value-Verhalten festlegen: Definieren, wie lange ein alter Wert noch angezeigt und wie seine Qualität verändert wird.
6. Transportfehler von Messwertfehlern trennen: Eine ausgefallene Cloud-Verbindung macht lokal korrekt gepufferte Messwerte nicht automatisch Bad.
7. Verhalten nachfolgender Systeme definieren: Dashboard, Alarmierung, Historian und Analysen müssen wissen, wie sie mit Uncertain und Bad umgehen sollen.

Häufige Fehler

• Nur den Zahlenwert übertragen: Spätere Systeme können nicht mehr unterscheiden, ob der Wert aktuell, ersetzt oder ungültig ist.
• Bei Kommunikationsausfall den letzten Wert weiterhin als Good senden: Dadurch entsteht eine scheinbar gültige, aber falsche Prozesshistorie.
• Übertragungszeit als Messzeit verwenden: Gepufferte Daten erhalten dadurch einen falschen zeitlichen Bezug.
• Jeden Warnzustand sofort als Bad behandeln: Dadurch geht die wichtige Zwischenstufe Uncertain verloren.
• Alle Fehler lediglich als „Bad“ speichern: Ohne Grund lässt sich später kaum unterscheiden, ob Sensor, Kommunikation oder Konfiguration betroffen waren.
• OPC-UA-Qualität beim MQTT-Mapping verwerfen: Aus einem strukturierten Datenwert wird dadurch nur noch eine unqualifizierte Zahl.
• Quality im Historian speichern, aber bei Auswertungen ignorieren: Bad-Werte können dann trotzdem in Mittelwerte, KPIs oder Modelle gelangen.
• Qualitätslogik erst in der Cloud erzeugen: Die Cloud kennt häufig nicht mehr alle feldnahen Diagnoseinformationen, die am Edge verfügbar waren.

IIoT-Sensorik und Edge-Integration

Für ein belastbares Qualitätsmodell ist nicht ein einzelnes Kommunikationsprotokoll entscheidend, sondern die gesamte Datenkette vom Feldgerät bis zum übergeordneten System. Sensoren und intelligente Feldgeräte sollten vorhandene Diagnoseinformationen möglichst digital bereitstellen. SPS, IO-Link-Master und Edge-Gateways müssen diese Informationen übernehmen, vereinheitlichen und zusammen mit Wert und Zeitstempel weitergeben.

Ein konkretes Beispiel ist der IDS350 elektronische Drucksensor mit IO-Link-Schnittstelle. Neben dem eigentlichen Prozesswert können über IO-Link Diagnose-, Status- und zusätzliche Geräteinformationen an die übergeordnete Ebene übergeben werden. Diese Informationen können anschließend in einem Edge-System auf ein einheitliches Datenqualitätsmodell abgebildet werden.

Für Brownfield- und IIoT-Architekturen kann eine industrielle Edge-Plattform verschiedene Feldquellen zusammenführen, Werte skalieren, Zeitstempel und Qualitätsinformationen verwalten und ausgewählte Daten über OPC UA, MQTT oder HTTPS an weitere IT/OT-Systeme übergeben. Welche Funktionen konkret zur Verfügung stehen, hängt von Gateway, Software und Projektkonfiguration ab.

Passende Komponenten und Integrationslösungen finden Sie unter IIoT-Lösungen bei ICS Schneider. Ein konkretes Feldgerät mit digital verfügbaren Diagnose- und Statusinformationen ist der IDS350 mit IO-Link-Schnittstelle.

Fazit

Ein industrieller Messwert besteht in einer modernen IIoT-Architektur aus mehr als einer Zahl. Ohne Information über Zeit und Qualität kann ein technisch vorhandener Wert leicht als aktuell und gültig interpretiert werden, obwohl der Sensor ausgefallen ist, eine Ersatzwertstrategie aktiv ist oder die Daten bereits veraltet sind.

Die Qualitätsstufen Good, Uncertain und Bad bieten eine verständliche Grundstruktur. Good kennzeichnet regulär verwendbare Daten, Uncertain Werte mit eingeschränkter Aussagekraft und Bad nicht verwendbare Messwerte. Für die Diagnose sollte zusätzlich ein konkreter Statusgrund erhalten bleiben.

OPC UA stellt diese Qualitätsinformation unmittelbar als Bestandteil des Datenwertes bereit. Wird dagegen MQTT verwendet, muss ein entsprechendes Quality-Feld bewusst im eigenen Payload-Schema vorgesehen werden. Beim Mapping zwischen den Protokollen darf die ursprünglich vorhandene Statusinformation nicht verloren gehen.

Ebenso wichtig ist der zeitliche Bezug. Ein zuletzt gültiger Wert darf nach einem Kommunikationsausfall nicht durch immer neue Zeitstempel wie ein aktueller Messwert aussehen. Umgekehrt dürfen korrekt am Edge gepufferte Good-Werte bei einem reinen Cloud-Ausfall ihren ursprünglichen Qualitätsstatus behalten.

Für belastbare IIoT-Messdaten gilt deshalb: Wert, Einheit, ursprünglichen Messzeitpunkt und Qualitätsstatus gemeinsam übertragen, die Bedeutung von Good, Uncertain und Bad eindeutig definieren, detaillierte Fehlergründe erhalten und sicherstellen, dass Dashboard, Historian und Analysen diese Information tatsächlich berücksichtigen.

FAQ: Good, Bad und Uncertain bei IIoT-Messdaten

Was bedeutet Good bei einem Messwert?

Good bedeutet, dass der Messwert unter den vorgesehenen Bedingungen regulär erfasst wurde und für die vorgesehene Verarbeitung verwendet werden kann.

Was bedeutet Uncertain?

Uncertain bedeutet, dass ein Wert vorhanden ist, seine Qualität oder Verwendbarkeit jedoch eingeschränkt ist. Je nach Ursache kann er weiterhin informativ sein, sollte aber nicht ungeprüft wie ein Good-Wert verarbeitet werden.

Was bedeutet Bad?

Bad kennzeichnet einen Wert, der nicht als gültiger Messwert verwendet werden sollte. Typische Ursachen sind Sensorfehler, Kommunikationsausfall oder ein vollständig fehlender gültiger Prozesswert.

Sind Good, Bad und Uncertain Bestandteil von MQTT?

Nein. MQTT definiert den Transport von Nachrichten, aber kein allgemeines Qualitätsmodell für industrielle Messwerte. Quality, Status, Zeitstempel und Fehlergrund müssen deshalb im jeweiligen Payload- beziehungsweise Datenmodell definiert werden.

Wie wird die Datenqualität in OPC UA übertragen?

OPC UA verwendet einen StatusCode als Bestandteil des Datenwertes. Dessen grundlegende Qualitätsstufen unterscheiden zwischen Good, Uncertain und Bad; zusätzliche Statusinformationen können den konkreten Zustand genauer beschreiben.

Sollte bei einem Bad-Status weiterhin der letzte Messwert übertragen werden?

Das hängt vom Datenmodell ab. Ein letzter bekannter Wert kann weiterhin informativ sein, darf aber nicht ungekennzeichnet als aktueller Good-Wert erscheinen. Alternativ kann der Prozesswert auf null gesetzt und der letzte gültige Wert separat gespeichert werden.

Ist ein alter Messwert automatisch Bad?

Nicht zwingend. Ein korrekt gemessener und anschließend lokal gepufferter Wert kann weiterhin Good sein, wenn sein ursprünglicher Messzeitpunkt erhalten bleibt. Ein alter Wert, der aufgrund eines ausgefallenen Sensors nur weitergehalten wird, muss dagegen entsprechend gekennzeichnet werden.

Was ist wichtiger: Qualitätsstatus oder Zeitstempel?

Beide Informationen ergänzen sich. Der Status beschreibt die Verwendbarkeit des Wertes, während der Zeitstempel zeigt, wann er tatsächlich erfasst wurde. Erst zusammen lässt sich der Datenpunkt zuverlässig interpretieren.

Sollten Bad-Werte im Historian gespeichert werden?

Ja, das kann sehr sinnvoll sein. Dadurch bleibt nachvollziehbar, wann eine Messstelle gestört war. Für Mittelwerte, KPIs und andere Berechnungen sollten Bad-Werte jedoch nicht automatisch wie gültige Prozesswerte behandelt werden.

Welches konkrete Feldgerät eignet sich als Beispiel für ein IIoT-Qualitätsmodell?

Der IDS350 mit IO-Link-Schnittstelle ist ein geeignetes Beispiel, weil neben Prozessdaten auch Diagnose- und Statusinformationen digital an eine übergeordnete Ebene übertragen werden können. Ein Edge-Gateway kann diese Informationen anschließend auf ein einheitliches Quality-Modell für OPC UA, MQTT oder weitere IT/OT-Systeme abbilden.