Industrielle Messdaten werden heute häufig wesentlich länger genutzt als das eigentliche Messgerät. Ein Drucksensor kann nach fünf Jahren ausgetauscht sein, die SPS wurde inzwischen modernisiert und das ursprüngliche Edge-Gateway existiert vielleicht nicht mehr. Die Messwerte aus dieser Zeit liegen jedoch weiterhin im Historian, in einer SQL-Datenbank oder in einer Cloud-Plattform und sollen für Trendanalysen, Energieberichte, Qualitätsnachweise oder Condition Monitoring verwendet werden.
Genau hier entsteht ein Problem, das bei der ersten Inbetriebnahme einer IIoT-Anwendung leicht übersehen wird: Ein Zahlenwert allein beschreibt eine physikalische Messung nicht vollständig.
Steht in einer Datenbank beispielsweise der Wert 6,42, muss auch Jahre später noch eindeutig feststellbar sein, welche physikalische Größe damit gemeint war, in welcher Einheit der Wert vorlag und welche Skalierung zum Zeitpunkt der Messung gültig war. Bei einem Druckwert macht es einen erheblichen Unterschied, ob 6,42 bar, 6,42 kPa oder 6,42 Pa gemeint sind. Noch kritischer wird es, wenn nicht der bereits skalierte Druck, sondern ein analoger oder digitaler Rohwert gespeichert wurde.
Ein typischer Fall entsteht beim Austausch eines Drucktransmitters. Ursprünglich bildet ein 4…20-mA-Sensor den Messbereich 0…10 bar ab. Später wird an derselben Messstelle ein Sensor für 0…16 bar eingesetzt. Der SPS-Kanal bleibt gleich, die Datenpunktbezeichnung bleibt gleich und möglicherweise ändert sich auch das MQTT-Topic nicht. Die mathematische Bedeutung des Eingangssignals hat sich jedoch geändert.
Werden historische Rohdaten später mit der aktuell hinterlegten 0…16-bar-Skalierung erneut ausgewertet, entstehen falsche Prozesswerte. Die Daten sehen technisch sauber aus, sind zeitlich korrekt sortiert und können sogar den Status „Good“ besitzen – trotzdem ist ihre physikalische Bedeutung falsch.
Die zentrale Aussage lautet: Einheit und Skalierung gehören zur messtechnischen Bedeutung eines Datenpunkts. Ändert sich diese Bedeutung, muss nachvollziehbar bleiben, ab welchem Zeitpunkt welche Konfiguration gültig war. Historische Messwerte dürfen niemals stillschweigend mit einer späteren Skalierung neu interpretiert werden.
Inhaltsverzeichnis
1. Warum ein Messwert mehr als eine Zahl ist
2. Rohsignal, Skalierung und Engineering Value auseinanderhalten
3. bar, Pa und Anzeigeeinheiten richtig behandeln
4. Warum eine geänderte Skalierung historische Daten verändert
5. Was genau versioniert werden sollte
6. Versionen benötigen einen eindeutigen Gültigkeitszeitraum
7. Warum der Messzeitpunkt über die richtige Skalierung entscheidet
8. Einheit und Bereich mit OPC UA sauber beschreiben
9. Skalierung und Einheit bei MQTT eindeutig halten
10. Edge-Gateway als zentrale Skalierungsstelle
11. Store-and-Forward ohne nachträgliche Skalierungsfehler
12. Rohwerte oder bereits skalierte Messwerte speichern?
13. Skalierung und Kalibrierkorrektur nicht vermischen
14. Warum ein Good-Status keinen Skalierungsfehler erkennt
15. Sensorwechsel und Messbereichsänderungen sauber dokumentieren
16. Bestehende Messdaten nachträglich absichern
17. Typische Datenfehler systematisch erkennen
18. Praktische Architektur für dauerhaft nutzbare Messdaten
19. IIoT-Lösungen von ICS Schneider
21. Häufige Fragen zu Einheiten und Skalierungen in Messdaten
1. Warum ein Messwert mehr als eine Zahl ist
Aus messtechnischer Sicht besteht ein Messwert aus einem Zahlenwert und einer Einheit. In einer automatisierten Datenkette kommen jedoch weitere Informationen hinzu, die für seine spätere Interpretation genauso wichtig sein können.
Ein Druckwert muss beispielsweise eindeutig als Druckgröße identifizierbar sein. Zusätzlich muss bekannt sein, ob er in Pa, kPa, MPa oder bar dargestellt wird. Entsteht dieser Wert erst durch die Skalierung eines elektrischen Signals, muss außerdem nachvollziehbar sein, welcher Messbereich dem Signal zugrunde lag.
In der Praxis existieren deshalb mehrere Ebenen zwischen dem physikalischen Prozess und dem Wert im Dashboard.
| Ebene | Beispiel | Bedeutung |
|---|---|---|
| Physikalische Messgröße | Prozessdruck | Die tatsächlich zu erfassende Größe |
| Sensor- bzw. Eingangssignal | 4…20 mA | Elektrische Übertragung der Messinformation |
| Skalierung | 4…20 mA entsprechen 0…10 bar | Zuordnung zwischen Signal und physikalischer Größe |
| Engineering Value | 6,42 bar | Bereits in eine physikalische Einheit umgerechneter Messwert |
| Anzeige- oder Recheneinheit | 642 kPa bzw. 642.000 Pa | Alternative Darstellung derselben physikalischen Größe |
Diese Ebenen sollten gedanklich voneinander getrennt bleiben. Besonders problematisch wird es, wenn eine Änderung auf einer Ebene unbemerkt als Änderung einer anderen Ebene behandelt wird.
Ein Wechsel von bar auf Pa verändert beispielsweise nicht den Sensor und auch nicht dessen Messbereich. Es handelt sich lediglich um eine Einheitenumrechnung derselben physikalischen Größe. Ein Wechsel des Sensors von 0…10 bar auf 0…16 bar verändert dagegen tatsächlich die Skalierung zwischen Sensorsignal und Prozessdruck.
Diese Unterscheidung bildet die Grundlage für ein dauerhaft belastbares Datenmodell.
2. Rohsignal, Skalierung und Engineering Value auseinanderhalten
Bei einem klassischen analogen Drucktransmitter kann die Messkette beispielsweise beim Prozess beginnen und über einen 4…20-mA-Ausgang zu einer SPS führen. Der Analogeingang digitalisiert den Strom, die Steuerung oder das Edge-Gateway skaliert diesen Wert und erst danach entsteht der Druckwert, der in einem Historian gespeichert oder über MQTT übertragen wird.
Solange diese gesamte Kette unverändert bleibt, ist die Zuordnung eindeutig. Probleme entstehen meist erst bei einer späteren Änderung.
Angenommen, 12 mA entsprechen bei einem Messbereich von 0…10 bar genau der Mitte des Bereichs. Der daraus berechnete Druck beträgt 5 bar. Wird derselbe 4…20-mA-Eingang später für einen 0…16-bar-Sensor verwendet, entsprechen 12 mA jetzt 8 bar.
Der Eingangsstrom von 12 mA ist in beiden Fällen vollkommen korrekt. Erst die Skalierung entscheidet darüber, ob daraus 5 oder 8 bar werden.
Für eine lineare Messkette lässt sich dieser Zusammenhang allgemein durch eine Zuordnung zwischen unterem und oberem Rohwert sowie unterem und oberem Engineering-Wert beschreiben. Entscheidend für die Datenhaltung ist nicht die konkrete Formel, sondern dass deren Parameter zeitlich eindeutig nachvollziehbar bleiben.
3. bar, Pa und Anzeigeeinheiten richtig behandeln
Für Druck ist Pascal die kohärente SI-Einheit. Das in der industriellen Messtechnik weit verbreitete bar ist eine andere Einheit derselben physikalischen Größe.
Die Umrechnung ist exakt:
1 bar = 100.000 Pa
Damit entsprechen 6,42 bar exakt 642.000 Pa beziehungsweise 642 kPa.
Eine saubere Einheitenumrechnung verändert deshalb immer Zahlenwert und Einheit gemeinsam. Aus 6,42 bar darf nicht einfach durch Austausch des Einheitenlabels „6,42 Pa“ werden.
Für IIoT-Projekte kann es sinnvoll sein, eine projektweit festgelegte Recheneinheit zu verwenden. Zentrale Analytics könnten Druckwerte beispielsweise grundsätzlich in Pa verarbeiten, während Instandhalter und Bediener weiterhin bar im Dashboard sehen.
Eine solche Architektur ist jedoch keine zwingende Voraussetzung. Ebenso legitim ist es, Engineering Values direkt in bar zu speichern. Entscheidend ist nicht, welche Einheit gewählt wird, sondern dass sie eindeutig dokumentiert und in allen beteiligten Systemen gleich interpretiert wird.
Eine reine Änderung der Anzeige von bar auf Pa erfordert deshalb nicht automatisch eine neue Sensorskalierung. Ändert sich dagegen die Einheit, in der Werte dauerhaft gespeichert oder über eine Schnittstelle definiert werden, muss dieser Wechsel für historische Daten eindeutig nachvollziehbar bleiben.
4. Warum eine geänderte Skalierung historische Daten verändert
Eine Skalierung beschreibt die mathematische Zuordnung zwischen einem Eingangswert und der gewünschten physikalischen Größe.
Bei 4…20 mA ist diese Zuordnung besonders anschaulich. Der Strombereich bleibt häufig unverändert, obwohl ein angeschlossener Sensor einen völlig anderen Messbereich besitzt.
Genau daraus entsteht ein typischer Fehler in Historian- und Cloud-Systemen. Wird die Skalierung eines Datenpunkts lediglich überschrieben, kennt das System anschließend nur noch die aktuelle Konfiguration.
Die historischen Rohwerte besitzen jedoch weiterhin die Bedeutung, die zum damaligen Messzeitpunkt gültig war.
Ein Rohwert aus der Zeit des 0…10-bar-Sensors darf deshalb auch Jahre später nur mit dieser 0…10-bar-Skalierung interpretiert werden. Die spätere Installation eines 0…16-bar-Sensors darf die Bedeutung des alten Datensatzes nicht verändern.
Das ist der eigentliche Sinn einer Skalierungsversion: Sie verhindert, dass sich die physikalische Interpretation bereits gespeicherter Daten nachträglich durch Änderungen an der aktuellen Anlagenkonfiguration verschiebt.
5. Was genau versioniert werden sollte
Nicht jede Änderung an einer Messstelle ist dieselbe Art von Änderung. Für eine übersichtliche Datenhaltung sollte deshalb unterschieden werden, ob sich der Messbereich, die Einheit, die Kalibrierkorrektur oder lediglich das physische Gerät geändert hat.
| Änderung | Was sollte nachvollziehbar bleiben? | Auswirkung auf historische Werte |
|---|---|---|
| Sensor 0…10 bar wird durch 0…16 bar ersetzt | Neue Skalierung und neuer Gültigkeitsbeginn | Alte Rohwerte weiterhin mit alter Skalierung auswerten |
| Anzeige wird von bar auf Pa umgestellt | Verwendete Einheitenkonvention bzw. Schnittstellenversion | Physikalische Messung bleibt identisch |
| Sensor wird durch baugleiches Gerät ersetzt | Geräteidentität und Wechselzeitpunkt | Skalierung kann unverändert bleiben |
| Kalibrierkorrektur wird geändert | Neue Korrektionsversion | Skalierung muss sich nicht ändern |
| Tank-Linearisierung wird geändert | Neue Linearisierungs- bzw. Strapping-Version | Historische Umrechnung muss zur damaligen Kennlinie passen |
In einer konkreten Software müssen diese Informationen nicht zwingend als fünf verschiedene Datenbankobjekte umgesetzt werden. Die technische Implementierung darf durchaus kompakter sein.
Entscheidend ist lediglich, dass eine spätere Auswertung eindeutig beantworten kann: Welche Konfiguration galt für diesen Messwert zu diesem Zeitpunkt?
6. Versionen benötigen einen eindeutigen Gültigkeitszeitraum
Eine Versionsnummer allein löst das Problem noch nicht. Zusätzlich muss bekannt sein, wann eine Version gültig wurde.
Für eine Messstelle kann beispielsweise bis zum 30. Juni eine Skalierung von 0…10 bar gelten und ab dem 1. Juli eine neue Skalierung von 0…16 bar. Der historische Datenbestand muss an dieser zeitlichen Grenze eindeutig aufgeteilt werden können.
In einer Datenbank kann dies technisch über einen Gültigkeitsbeginn und optional ein Gültigkeitsende, über eine Konfigurationshistorie oder über unveränderliche Änderungsereignisse umgesetzt werden.
Für die fachliche Aussage ist die konkrete Datenbanktechnik zweitrangig. Wichtig ist, dass eine alte Version beim Aktivieren einer neuen Version nicht verloren geht.
Diese Vorgehensweise bietet einen weiteren Vorteil: Ein Sensorwechsel muss nicht zwangsläufig eine neue Messstellen-ID erzeugen. Der logische Prozesspunkt kann weiterhin PT101 heißen, während dessen technische Konfiguration historisch nachvollziehbar wechselt.
Damit bleibt die Zeitreihe aus Sicht des Prozesses zusammenhängend, ohne die technische Rückverfolgbarkeit zu verlieren.
7. Warum der Messzeitpunkt über die richtige Skalierung entscheidet
Versionierung funktioniert nur zuverlässig, wenn der Messwert einen eindeutig definierten Zeitbezug besitzt.
Besonders deutlich wird das bei einer Kommunikationsunterbrechung. Angenommen, ein Edge-Gateway speichert Messwerte lokal, weil die Verbindung zum übergeordneten Historian ausgefallen ist. Während dieser Offline-Phase wird um 10:00 Uhr die Sensorkonfiguration geändert.
Ein Wert, der um 09:59:58 Uhr entstanden ist, gehört noch zur alten Skalierung. Das gilt auch dann, wenn er erst um 10:15 Uhr nach Wiederherstellung der Verbindung an die Cloud übertragen wird.
Würde die Skalierung allein anhand des Empfangszeitpunkts ausgewählt, würde dieser Wert fälschlicherweise bereits der neuen Konfiguration zugeordnet.
Für die historische Interpretation sollte deshalb möglichst der ursprüngliche Mess- beziehungsweise Erfassungszeitpunkt herangezogen werden. Ist ein echter Sensor-Zeitstempel nicht verfügbar, muss zumindest klar definiert sein, ob beispielsweise die SPS- oder Gateway-Zeit den relevanten Erfassungszeitpunkt darstellt.
Der später entstandene Übertragungs- oder Speicherzeitpunkt darf nicht stillschweigend an dessen Stelle treten.
8. Einheit und Bereich mit OPC UA sauber beschreiben
OPC UA bietet für analoge Prozesswerte standardisierte Mechanismen, um die Einheit eines Wertes maschinenlesbar zu beschreiben. Dadurch muss ein Client beispielsweise nicht aus einem Variablennamen wie „Pressure_bar“ erraten, welche Einheit verwendet wird.
Zusätzlich kann ein Engineering-Bereich angegeben werden. Damit lassen sich beispielsweise normaler Wertebereich und Einheit eines analogen Datenpunkts strukturiert darstellen.
Das ist besonders hilfreich, wenn unterschiedliche Geräte und Hersteller in ein gemeinsames IIoT- oder SCADA-System integriert werden.
Eine wichtige Eigenschaft von OPC UA ist außerdem die Möglichkeit, eine geänderte Semantik eines Datenpunkts zu signalisieren. Wird beispielsweise die Engineering Unit oder der Engineering-Bereich verändert, kann ein Client erkennen, dass sich die Bedeutung des Datenpunkts geändert hat.
Diese Mechanismen lösen jedoch nicht automatisch die historische Versionierung. Ein Client kann erkennen, dass die aktuelle Konfiguration geändert wurde. Soll ein Messwert aus dem Vorjahr später mit der damals gültigen Einheit oder Skalierung ausgewertet werden, muss die Anlagen- beziehungsweise Historian-Architektur diese frühere Konfiguration weiterhin verfügbar halten.
OPC UA liefert damit wichtige Bausteine für saubere Semantik, ersetzt aber kein Konfigurationsarchiv.
9. Skalierung und Einheit bei MQTT eindeutig halten
MQTT ist bewusst flexibel aufgebaut. Das Protokoll transportiert Nachrichten zwischen Publisher und Subscriber, schreibt aber nicht vor, wie ein industrieller Messwert innerhalb der Nutzdaten strukturiert sein muss.
Diese Freiheit ist einer der Gründe, warum MQTT für IIoT-Anwendungen so vielseitig einsetzbar ist. Gleichzeitig bedeutet sie, dass die fachliche Bedeutung eines Messwerts vom Projekt selbst sauber definiert werden muss.
Bei einer Druckmessstelle sollte deshalb eindeutig vereinbart sein, welche Einheit übertragen wird, ob bereits ein Engineering Value oder noch ein Rohwert vorliegt und wie eine Änderung der Skalierung kenntlich gemacht wird.
Die Einheit ausschließlich in den Topic-Namen einzubauen ist häufig unflexibel. Ein stabiler Datenpunkt für den Prozessdruck kann unabhängig davon bestehen bleiben, ob der Wert später in bar, kPa oder Pa bereitgestellt wird.
Ebenso muss nicht bei jeder Skalierungsänderung ein komplett neuer MQTT-Topic-Baum entstehen. Sinnvoller ist in vielen Architekturen eine stabile semantische Messstellen-ID, während die technische Konfiguration separat verwaltet und versioniert wird.
Aktuelle Metadaten können beispielsweise separat bereitgestellt werden. Für eine belastbare Historie muss jedoch zusätzlich nachvollziehbar bleiben, welche frühere Metadatenkonfiguration zu welchem Zeitpunkt gültig war.
10. Edge-Gateway als zentrale Skalierungsstelle
In Brownfield-Anlagen treffen häufig sehr unterschiedliche Datenquellen aufeinander. Ein Sensor liefert 4…20 mA, ein anderer einen Modbus-Registerwert, ein dritter überträgt bereits einen digitalen Druckwert mit Einheit.
Ein Edge-Gateway eignet sich gut, um diese unterschiedlichen Quellen in ein einheitliches Datenmodell zu überführen.
Die Skalierung kann dann kontrolliert an einer definierten Stelle erfolgen. Gleichzeitig können Einheit, Messstellen-ID, Zeitstempel und Qualitätsstatus vereinheitlicht werden, bevor die Daten in Richtung SCADA, Historian oder Cloud übertragen werden.
Wichtig ist jedoch eine klare Verantwortlichkeit. Wenn bereits die SPS einen 4…20-mA-Wert in bar umrechnet, sollte das Edge-Gateway nicht nochmals eine zweite unabhängige Skalierung durchführen. Andernfalls entstehen mehrere Stellen, an denen dieselbe physikalische Bedeutung konfiguriert werden muss.
Je weniger unabhängige Skalierungspunkte eine Messkette besitzt, desto leichter lässt sie sich warten und validieren.
Die zentrale Frage bei der Architektur lautet deshalb nicht nur „Wo können wir skalieren?“, sondern vor allem „Welches System ist fachlich für diese Skalierung verantwortlich?“
11. Store-and-Forward ohne nachträgliche Skalierungsfehler
Lokale Pufferung ist für industrielle IIoT-Anwendungen besonders wichtig. Ein vorübergehender Ausfall von WAN, Broker oder Cloud darf nicht automatisch zu Datenverlust führen.
Bei versionierten Skalierungen entsteht dabei eine zusätzliche Anforderung.
Wird ein bereits skalierter Engineering Value am Edge erzeugt und zusammen mit seinem ursprünglichen Zeitstempel gespeichert, bleibt seine damalige Bedeutung zunächst erhalten. Ändert sich anschließend die Skalierung, ist der gepufferte Wert davon nicht betroffen.
Werden dagegen ausschließlich Rohwerte gepuffert und erst später im übergeordneten System skaliert, muss zu jedem historischen Rohwert eindeutig bestimmt werden können, welche Skalierung zum Messzeitpunkt gültig war.
Beide Ansätze können technisch richtig sein. Problematisch wird nur eine Mischform, bei der Rohwerte gespeichert werden, während bei der späteren Verarbeitung automatisch die gerade aktuelle Skalierung verwendet wird.
Gerade bei Store-and-Forward muss die Konfigurationszuordnung deshalb genauso robust sein wie der eigentliche Datenpuffer.
12. Rohwerte oder bereits skalierte Messwerte speichern?
Für viele Anwendungen reicht es aus, dauerhaft nur den Engineering Value zu speichern. Ein Historian für Prozessdruck kann beispielsweise direkt bar oder Pa aufzeichnen. Das vereinfacht Auswertung, Reporting und Visualisierung erheblich.
Die zusätzliche Speicherung des Rohwerts bietet jedoch Vorteile, wenn hohe Anforderungen an Rückverfolgbarkeit oder spätere Fehlerkorrektur bestehen.
Wird Jahre später festgestellt, dass eine SPS-Skalierung zwischen zwei Wartungsterminen falsch parametriert war, kann eine vorhandene Rohdatenreihe möglicherweise korrekt neu ausgewertet werden.
Ohne Rohdaten bleibt dagegen nur der bereits falsch skalierte Engineering Value.
Eine pauschale Empfehlung, grundsätzlich jede Anlage mit vollständiger Rohdatenarchivierung auszurüsten, wäre trotzdem nicht sinnvoll. Speicherbedarf, Datenrate, Kritikalität der Messung und Nachweispflichten unterscheiden sich erheblich.
Für kritische Messstellen kann die Kombination aus Rohwert und Engineering Value sinnvoll sein. Für einfache Trenddaten reicht häufig der korrekt skalierte und eindeutig versionierte Engineering Value.
Entscheidend ist in beiden Fällen, dass einmal gespeicherte Originaldaten nicht stillschweigend durch später neu berechnete Werte ersetzt werden. Wird eine historische Datenreihe korrigiert, sollte erkennbar bleiben, welche Werte ursprünglich gespeichert und welche nachträglich abgeleitet wurden.
13. Skalierung und Kalibrierkorrektur nicht vermischen
Ein besonders wichtiger Unterschied besteht zwischen Skalierung und Kalibrierkorrektur.
Die Skalierung beschreibt zunächst die nominelle Übertragung. Ein Transmitter mit 4…20 mA und 0…10 bar definiert damit, welche elektrische Größe welchem Druck zugeordnet wird.
Eine Kalibrierung untersucht dagegen, wie stark das konkrete Messgerät von einem Referenzwert abweicht. Aus dieser Abweichung können – sofern dies für das Messsystem vorgesehen ist – Korrektionswerte entstehen.
Ein Sensor kann deshalb weiterhin einen nominellen Messbereich von 0…10 bar besitzen, während sich nach einer neuen Kalibrierung lediglich die verwendete Korrektur ändert.
Würde beides in einer einzigen undokumentierten Umrechnungsformel zusammengeführt, lässt sich später kaum noch erkennen, ob sich der Sensorbereich, die Anlagenparametrierung oder nur die Kalibrierkorrektur geändert hat.
Für anspruchsvolle Messdaten sollten diese Informationen deshalb logisch getrennt bleiben.
14. Warum ein Good-Status keinen Skalierungsfehler erkennt
Ein Qualitätsstatus beschreibt typischerweise, ob ein Messwert aus Sicht der Datenquelle beziehungsweise Kommunikation verwendbar ist.
Ein Sensor kann ordnungsgemäß arbeiten, der Feldbus kann fehlerfrei kommunizieren und der Messwert kann trotzdem physikalisch falsch interpretiert werden.
Das passiert beispielsweise, wenn ein 0…10-bar-Sensor angeschlossen ist, die SPS jedoch versehentlich auf 0…16 bar skaliert.
Der Analogeingang sieht einen gültigen Strom. Es liegt kein Kabelbruch und kein Kommunikationsfehler vor. Der Qualitätsstatus kann deshalb vollkommen korrekt „Good“ sein.
Der daraus berechnete Druck ist trotzdem falsch.
Datenqualität besteht daher nicht nur aus Kommunikationsstatus und Sensorzustand. Auch Konfigurationsmanagement, Skalierungsprüfung und dokumentierte Änderungen gehören dazu.
15. Sensorwechsel und Messbereichsänderungen sauber dokumentieren
Instandhaltung ist einer der wichtigsten Gründe für Versionswechsel.
Wird ein defekter 0…10-bar-Sensor durch einen baugleichen Sensor mit demselben Messbereich ersetzt, bleibt die grundlegende Skalierung möglicherweise unverändert. Trotzdem sollte nachvollziehbar sein, ab wann ein anderes physisches Gerät an der Messstelle eingesetzt wurde.
Wird dagegen ein 0…16-bar-Sensor montiert, ändert sich zusätzlich die Skalierung. In diesem Fall müssen Gerätewechsel und neue mathematische Zuordnung beide dokumentiert werden.
Die Messstellen-ID selbst muss deshalb nicht ständig geändert werden. Für die Prozesssicht bleibt beispielsweise „Druck hinter Pumpe P101“ dieselbe Messgröße.
Technisch besitzt dieser logische Datenpunkt aber über seine Lebensdauer mehrere Konfigurationsstände.
Eine solche Trennung zwischen stabiler Anlagenidentität und versionierter Geräte- beziehungsweise Messkonfiguration erleichtert sowohl Instandhaltung als auch spätere Datenanalysen erheblich.
16. Bestehende Messdaten nachträglich absichern
Viele Unternehmen besitzen bereits jahrelange Messhistorien, bei denen Einheit und Skalierung nicht konsequent mitgespeichert wurden.
Eine nachträgliche Bereinigung ist möglich, sollte aber konservativ erfolgen.
Zunächst sollten Wartungsprotokolle, SPS-Programme, Sensorlisten, Kalibrierscheine und Projektstände ausgewertet werden. Daraus lassen sich häufig Zeiträume bilden, für die eine bestimmte Konfiguration eindeutig belegt ist.
Problematisch sind Übergangszeiträume, bei denen beispielsweise bekannt ist, dass ein Sensor im Juli getauscht wurde, der genaue Tag aber nicht mehr nachvollziehbar ist.
In einem solchen Fall sollte kein scheinbar exakter Versionswechsel erfunden werden.
Eine transparente Kennzeichnung des betreffenden Datenbereichs als unsicher ist technisch wesentlich sauberer als eine nachträgliche Skalierung, für die keine belastbare Grundlage existiert.
Gerade für KI-, Reporting- und Predictive-Maintenance-Projekte ist diese Unterscheidung wichtig. Ein großer Datenbestand ist nicht automatisch ein guter Datenbestand.
17. Typische Datenfehler systematisch erkennen
| Beobachtung | Mögliche Ursache | Sinnvolle Prüfung |
|---|---|---|
| Messwert springt exakt nach Wartung oder Sensorwechsel | Messbereich oder Skalierung geändert | Wartungsprotokoll und Konfigurationshistorie vergleichen |
| Werte unterscheiden sich um Faktor 100.000 | bar und Pa verwechselt | Einheit und Konvertierung entlang der gesamten Datenkette prüfen |
| Rohsignal ist plausibel, Engineering Value nicht | Falsche Skalierung | Zuordnung zwischen Eingangssignal und Messbereich kontrollieren |
| Historische Werte verändern sich nach einer Parametrierung | Altdaten werden mit aktueller Skalierung neu interpretiert | Versions- und Gültigkeitslogik des Historian prüfen |
| Einheitenlabel ändert sich, Zahlenwert bleibt unverändert | Nur Beschriftung statt echter Einheitenumrechnung geändert | Numerische Transformation kontrollieren |
| Nach einer Offline-Phase sind nur ältere Werte falsch | Beim Store-and-Forward wurde die falsche Konfiguration angewendet | Messzeitpunkt, Pufferspeicher und Skalierungsversion vergleichen |
| Messwertstatus ist Good, Wert aber physikalisch unplausibel | Konfigurations- statt Kommunikationsfehler | Skalierung, Messbereich und Geräteparametrierung prüfen |
18. Praktische Architektur für dauerhaft nutzbare Messdaten
Eine robuste IIoT-Datenarchitektur muss nicht zwangsläufig komplex sein. Entscheidend ist eine klare Trennung zwischen stabiler Messstellenidentität und veränderlicher technischer Konfiguration.
Der physikalische Prozesspunkt erhält eine dauerhafte Identität. Diese kann beispielsweise über Anlagenstruktur, Maschine und Messstellenkennzeichen abgebildet werden.
Dazu wird eine technische Konfiguration geführt, in der unter anderem Sensor, Messbereich, Einheit, Skalierung und gegebenenfalls Kalibrierkorrektur beschrieben sind. Jede relevante Änderung erhält einen eindeutigen Gültigkeitsbeginn.
Der Messwert selbst besitzt einen Erfassungszeitpunkt und kann dadurch dem zu diesem Zeitpunkt gültigen Konfigurationsstand zugeordnet werden.
Am Edge kann die Skalierung durchgeführt und anschließend ein bereits eindeutig interpretierter Engineering Value an Historian oder Cloud übertragen werden. Alternativ können Rohwerte übertragen werden, wenn die übergeordnete Architektur die historische Zuordnung der Skalierungsstände zuverlässig sicherstellt.
Für die Praxis ist weniger entscheidend, ob die Informationen in einer SQL-Tabelle, einem Asset-Modell, einem OPC-UA-Informationsmodell oder einer anderen Konfigurationsdatenbank liegen.
Entscheidend ist die fachliche Rückverfolgbarkeit:
Welcher Sensor erzeugte den Wert, welche Skalierung galt, in welcher Einheit liegt er vor und zu welchem Zeitpunkt war diese Konfiguration gültig?
Kann ein System diese vier Fragen auch Jahre später zuverlässig beantworten, ist bereits ein wesentlicher Teil der langfristigen Datenqualität erreicht.
19. IIoT-Lösungen von ICS Schneider
ICS Schneider Messtechnik unterstützt bei der Integration industrieller Messgeräte von der Feldebene bis in übergeordnete IT- und OT-Systeme. Eine Übersicht finden Sie unter IIoT-Lösungen.
Eine typische Architektur verbindet Sensoren und Messumformer über vorhandene Feldschnittstellen mit SPS oder Edge-Gateway. Dort können Messdaten aggregiert, skaliert, mit einem definierten Zeitbezug versehen und anschließend über beispielsweise MQTT, OPC UA oder HTTPS an SCADA-, Historian- oder Cloud-Systeme weitergegeben werden.
Gerade bei der herstellerübergreifenden Integration ist das Datenmodell ein wesentlicher Bestandteil der technischen Lösung. Unterschiedliche Registerbelegungen, Einheiten und Skalierungen müssen auf eine einheitliche Semantik abgebildet werden, ohne dabei die ursprüngliche Herkunft der Messdaten zu verlieren.
Für Druckanwendungen finden Sie weitere Lösungen unter IIoT-Drucküberwachung.
Der Zusammenhang zwischen Messwert, Einheit, Anlagenstruktur und Qualitätsstatus wird außerdem im Fachbeitrag „MQTT-Topics für Messdaten planen: Einheit, Anlagenstruktur und Qualitätsstatus richtig abbilden“ behandelt.
Für den zeitlichen Bezug der Daten ist zusätzlich der Beitrag „Zeitstempel für IIoT-Messdaten: Sensor, SPS oder Gateway?“ relevant.
Wenn Daten während eines Kommunikationsausfalls lokal gespeichert werden müssen, ergänzt der Fachbeitrag „Edge-Pufferspeicher dimensionieren: Offline-Dauer, Datenrate und Speicherreserve berechnen“ die technische Betrachtung.
20. Fazit
Industrielle Messdaten bleiben nur dann langfristig nutzbar, wenn ihre physikalische Bedeutung erhalten bleibt.
Ein Zahlenwert und ein Zeitstempel reichen dafür insbesondere bei Rohdaten nicht aus. Zusätzlich muss nachvollziehbar sein, wie aus dem ursprünglichen Sensorsignal der physikalische Engineering Value entstanden ist.
Eine Änderung von 0…10 auf 0…16 bar verändert die Skalierung. Ein Wechsel von bar auf Pa verändert dagegen die Einheit beziehungsweise Darstellung derselben physikalischen Größe. Eine neue Kalibrierkorrektur wiederum verändert weder zwangsläufig Einheit noch nominellen Messbereich.
Diese unterschiedlichen Änderungen sollten deshalb nicht in einer einzigen undokumentierten Konfiguration zusammengefasst werden.
Besonders wichtig ist die zeitliche Gültigkeit. Ein historischer Messwert muss mit der Konfiguration interpretiert werden, die bei seiner Erfassung gültig war – nicht mit der Konfiguration, die heute am Messpunkt eingestellt ist.
Genau deshalb gehören Zeitstempel und Konfigurationshistorie zusammen.
Bei OPC UA können Einheit und Engineering-Bereich maschinenlesbar beschrieben und Änderungen der Semantik signalisiert werden. Bei MQTT muss das entsprechende Datenmodell projektspezifisch festgelegt werden. In beiden Fällen bleibt die langfristige Historisierung früherer Konfigurationsstände eine Aufgabe der konkreten Anlagen- und Datenarchitektur.
Für Edge- und Store-and-Forward-Systeme gilt derselbe Grundsatz. Entweder wird der Messwert bereits mit der damals gültigen Skalierung als Engineering Value gespeichert oder der Rohwert muss zusammen mit den Informationen erhalten bleiben, die später eine eindeutige historische Skalierung ermöglichen.
Eine technisch belastbare Datenkette lässt sich damit auf einen einfachen Grundsatz reduzieren:
Messwert, Einheit, Skalierung und Zeitbezug dürfen über die Lebensdauer einer Messstelle niemals voneinander getrennt werden.
Wer diese Zusammenhänge bereits beim Aufbau der IIoT-Architektur berücksichtigt, vermeidet nicht nur klassische Faktorfehler zwischen bar und Pa. Gleichzeitig entsteht eine deutlich bessere Grundlage für Historian, MES, Reporting, Condition Monitoring und spätere Datenanalysen.
21. Häufige Fragen zu Einheiten und Skalierungen in Messdaten
Warum muss eine Skalierung versioniert werden?
Weil sich die Zuordnung zwischen einem Rohsignal und der physikalischen Messgröße im Laufe der Zeit ändern kann. Historische Rohwerte müssen auch später mit derjenigen Skalierung ausgewertet werden, die bei ihrer Erfassung gültig war.
Wann benötige ich eine neue Skalierungsversion?
Eine neue Version ist erforderlich, wenn sich die mathematische Zuordnung zwischen Eingangssignal und Engineering Value ändert. Typische Beispiele sind ein anderer Sensormessbereich oder eine geänderte Linearisierung.
Benötigt ein Wechsel von bar auf Pa eine neue Sensorskalierung?
Nicht automatisch. bar und Pa sind unterschiedliche Einheiten derselben physikalischen Größe. Bleibt der zugrunde liegende Messwert unverändert und wird lediglich die Anzeige umgerechnet, ändert sich die Sensorskalierung nicht. Wird dagegen die Einheit der gespeicherten oder übertragenen Daten geändert, muss diese Änderung für die Schnittstelle und historische Interpretation eindeutig dokumentiert sein.
Wie viele Pascal sind ein bar?
Ein bar entspricht exakt 100.000 Pa. Entsprechend sind beispielsweise 6,42 bar gleich 642.000 Pa beziehungsweise 642 kPa.
Was ist der Unterschied zwischen Skalierung und Einheitenumrechnung?
Die Skalierung ordnet einem Roh- oder Eingangssignal eine physikalische Messgröße zu, beispielsweise 4…20 mA zu 0…10 bar. Eine Einheitenumrechnung wandelt anschließend denselben physikalischen Wert beispielsweise von bar in Pa um.
Was ist der Unterschied zwischen Skalierung und Kalibrierkorrektur?
Die Skalierung beschreibt die nominelle Zuordnung zwischen Signal und Messbereich. Eine Kalibrierkorrektur berücksichtigt dagegen eine individuell ermittelte Abweichung des konkreten Messgeräts. Beide Informationen können sich unabhängig voneinander ändern.
Muss bei jedem Sensorwechsel eine neue Skalierung angelegt werden?
Nicht unbedingt. Wird ein Sensor durch ein baugleiches Gerät mit identischem Ausgangssignal und identischem Messbereich ersetzt, kann die Skalierung unverändert bleiben. Der Gerätewechsel selbst sollte trotzdem dokumentiert werden.
Was passiert bei einem Sensorwechsel von 0…10 auf 0…16 bar?
Die Zuordnung zwischen dem Eingangssignal und dem Druck ändert sich. Für Messwerte ab dem Wechselzeitpunkt ist deshalb eine neue Skalierung erforderlich. Historische Daten davor müssen weiterhin mit dem alten Messbereich interpretiert werden.
Sollte ich Rohwerte oder bereits skalierte Werte speichern?
Beides kann sinnvoll sein. Engineering Values sind direkt nutzbar und vereinfachen Analysen. Rohwerte erhöhen dagegen die Nachvollziehbarkeit und können eine spätere Neuberechnung ermöglichen. Welche Variante sinnvoll ist, hängt von Kritikalität, Datenmenge und Anforderungen an die Rückverfolgbarkeit ab.
Kann ein Good-Qualitätsstatus trotzdem einen falschen Messwert enthalten?
Ja. Der Sensor und die Kommunikation können einwandfrei funktionieren, während eine falsche Skalierung hinterlegt ist. Der Wert kann dann technisch gültig übertragen werden, obwohl seine physikalische Interpretation falsch ist.
Welche Rolle spielt der Zeitstempel?
Über den maßgeblichen Mess- beziehungsweise Erfassungszeitpunkt lässt sich bestimmen, welche Konfiguration zu diesem Wert gehörte. Das ist insbesondere wichtig, wenn Daten gepuffert und erst später übertragen werden.
Warum darf beim Store-and-Forward nicht einfach die aktuelle Skalierung verwendet werden?
Weil ein gepufferter Messwert vor einer späteren Konfigurationsänderung entstanden sein kann. Seine Interpretation richtet sich nach der zum ursprünglichen Messzeitpunkt gültigen Skalierung.
Was bietet OPC UA für Einheiten?
OPC UA stellt standardisierte Informationen für Engineering Units und Wertebereiche bereit. Dadurch können Clients die Einheit eines analogen Messwerts maschinenlesbar erkennen. Änderungen der Semantik können außerdem gekennzeichnet werden.
Speichert OPC UA automatisch alte Einheiten und Skalierungen?
Nein. OPC UA stellt Mechanismen zur Beschreibung der aktuellen Semantik bereit. Die langfristige Historisierung früherer Konfigurationen muss durch die jeweilige Server-, Historian- oder Anlagenarchitektur umgesetzt werden.
Wie behandelt MQTT Einheit und Skalierung?
MQTT definiert den Transport von Nachrichten, aber kein verbindliches industrielles Messdatenformat. Deshalb muss das Projekt selbst festlegen, in welcher Einheit Werte übertragen werden und wie Skalierung und Konfigurationsversion eindeutig zugeordnet werden.
Sollte die Einheit Teil des MQTT-Topic-Namens sein?
Das ist technisch möglich, kann aber spätere Einheitenänderungen unnötig erschweren. Häufig ist es robuster, eine stabile Messstellen-ID zu verwenden und die Einheit als eindeutig zugeordnete Daten- beziehungsweise Metadateninformation zu behandeln.
Was sollte nach einem Sensorwechsel dokumentiert werden?
Mindestens der Wechselzeitpunkt, die Identität des neuen Sensors, sein Messbereich und gegebenenfalls die neue Skalierung beziehungsweise Kalibrierinformation sollten nachvollziehbar bleiben.
Wie gehe ich mit historischen Daten um, deren Skalierung nicht mehr bekannt ist?
Die Skalierung sollte nur dann rückwirkend zugeordnet werden, wenn sie aus belastbaren Unterlagen wie SPS-Ständen, Wartungsprotokollen oder Gerätekonfigurationen rekonstruiert werden kann. Ist die Zuordnung nicht eindeutig, sollte der betreffende Zeitraum als unsicher gekennzeichnet werden.
Welche Angaben benötigt ICS Schneider für ein IIoT-Datenmodell?
Hilfreich sind Messstellenliste, physikalische Messgrößen, Sensor- und Messbereiche, Ausgangssignale beziehungsweise Registerbelegungen, verwendete Engineering Units, SPS- und Edge-Systeme, Abtastraten, Zeitstempelquelle, Anforderungen an Datenqualität und Pufferung sowie die geplanten Zielsysteme wie SCADA, Historian, MQTT-Broker oder Cloud-Plattform.