Ein Drucksensor liefert jede Sekunde einen neuen Messwert. Der Prozess verändert sich jedoch nur sehr langsam. Über mehrere Minuten schwankt der Wert beispielsweise lediglich zwischen 6,41 und 6,44 bar. Muss wirklich jeder einzelne Sekundenwert über das Edge-Gateway an Broker, Historian und Cloud übertragen werden?
Nicht unbedingt. In vielen IIoT-Anwendungen ist es sinnvoll, Messwerterfassung und Datenübertragung voneinander zu trennen. Der Sensor beziehungsweise das Edge-System kann weiterhin mit einer ausreichend hohen Rate erfassen, während nachgelagerte Systeme nur dann einen neuen Wert erhalten, wenn sich die Messgröße relevant verändert.
Dieses Prinzip wird häufig als Change-of-Value, kurz COV, beziehungsweise Publish-on-Change bezeichnet. Eine zentrale Größe dabei ist das Deadband: Es legt fest, wie groß die Änderung eines Messwertes sein muss, bevor ein neuer Datensatz übertragen beziehungsweise gespeichert wird.
Ein gut gewähltes Deadband reduziert Datenmenge und Kommunikationslast, ohne relevante Prozessinformationen zu verlieren. Ein zu kleines Deadband überträgt dagegen hauptsächlich Sensorrauschen. Ein zu großes Deadband kann langsame Trends verschleiern, die Aktualität eines Dashboards reduzieren und relevante Änderungen verspätet sichtbar machen.
Was bedeutet Change-of-Value?
Bei einem festen Sendeintervall wird ein Messwert unabhängig davon übertragen, ob er sich verändert hat.
Beispielsweise:
jede Sekunde → neuen Messwert senden
Ein nahezu konstanter Prozess kann dadurch beispielsweise folgende Datensätze erzeugen:
6,42 → 6,42 → 6,43 → 6,42 → 6,42 → 6,43 bar
Für viele Langzeitüberwachungen enthalten diese Nachrichten nur wenig zusätzliche Information.
Bei Change-of-Value wird dagegen geprüft, wie stark sich der aktuelle Messwert gegenüber einem definierten Referenzwert verändert hat.
Nur wenn die Änderung einen festgelegten Betrag erreicht beziehungsweise überschreitet, wird ein neuer Wert publiziert.
Vereinfacht:
|aktueller Wert - Referenzwert| ≥ Deadband → senden
Dadurch kann die Messstelle intern weiterhin regelmäßig erfasst werden, ohne jede einzelne Abtastung an die übergeordneten Systeme weiterzugeben.
Warum sind Abtastrate und Übertragungsrate nicht dasselbe?
Diese Trennung ist für eine gute IIoT-Architektur besonders wichtig.
Ein System kann beispielsweise:
10 Messwerte pro Sekunde erfassen
aber nur:
bei relevanter Änderung übertragen
oder zusätzlich:
alle 5 Minuten einen Heartbeat senden
Die hohe interne Abtastrate kann weiterhin benötigt werden für:
- lokale Alarmauswertung,
- Min-/Max-Erfassung,
- Rate-of-Change-Berechnung,
- Diagnose,
- Regelung,
- Erkennung kurzer Prozessereignisse.
Die Übertragungsrate beantwortet dagegen eine andere Frage:
Wie häufig muss ein übergeordnetes System wirklich einen neuen Datensatz erhalten?
Eine niedrige Publikationsrate bedeutet deshalb nicht automatisch, dass der Sensor selbst langsam misst.
Was bedeutet Deadband?
Das Deadband definiert die minimale Messwertänderung, die als relevant betrachtet wird.
Beispiel:
Zuletzt übertragener Druck:
6,40 bar
Deadband:
0,10 bar
Neue Messwerte:
| Aktueller Wert | Änderung | Übertragen? |
|---|---|---|
6,43 bar |
+0,03 bar |
Nein |
6,47 bar |
+0,07 bar |
Nein |
6,50 bar |
+0,10 bar |
Ja |
Nach der Übertragung von 6,50 bar wird dieser Wert typischerweise zur neuen Vergleichsbasis.
Wie genau ein konkretes Protokoll, Gateway oder Softwaremodul das Deadband berechnet, muss allerdings projektspezifisch geprüft werden.
Mit welchem Wert wird die Änderung verglichen?
Dieser Punkt ist besonders wichtig bei langsam veränderlichen Messgrößen.
Ein sinnvolles Change-of-Value-Verfahren vergleicht den neuen Messwert häufig mit dem:
zuletzt gemeldeten beziehungsweise übertragenen Wert
Beispiel:
Deadband:
0,10 bar
Zuletzt übertragen:
5,00 bar
Anschließend steigt der Druck langsam:
5,02 → 5,04 → 5,06 → 5,08 → 5,10 bar
Jede einzelne Änderung beträgt nur 0,02 bar.
Gegenüber dem zuletzt übertragenen Wert beträgt die gesamte Änderung am Ende jedoch:
0,10 bar
und ein neuer Wert sollte übertragen werden.
Würde eine ungeeignete Implementierung dagegen ausschließlich jeden Wert mit dem unmittelbar vorherigen Sample vergleichen, könnte eine langsame kontinuierliche Drift unter Umständen sehr lange unterhalb der einzelnen Änderungsschwelle bleiben.
Bei der Projektierung sollte deshalb eindeutig geklärt werden, wie das konkrete COV-Verfahren seine Vergleichsbasis bildet.
Absolutes oder relatives Deadband?
Ein Deadband kann auf unterschiedliche Weise definiert werden.
Ein absolutes Deadband verwendet eine feste technische Einheit:
±0,1 bar
oder:
±0,2 °C
oder:
±5 mm
Ein relatives Deadband kann dagegen als Prozentwert eines definierten Bereiches angegeben werden.
Beispielsweise:
1 % von 0 ... 10 bar = 0,1 bar
Bei industriellen Messgrößen ist ein absolutes Deadband in Engineering Units häufig besonders transparent, weil unmittelbar erkennbar ist, welche reale Änderung für eine neue Übertragung erforderlich ist.
Bei Prozentangaben muss dagegen eindeutig dokumentiert werden, worauf sich der Prozentwert bezieht:
- Messspanne,
- aktueller Messwert,
- letzter übertragener Wert oder
- eine andere definierte Bezugsgröße.
Die tatsächliche Implementierung ist geräte- beziehungsweise softwareabhängig.
Warum muss Sensorrauschen berücksichtigt werden?
Kein realer Sensor liefert bei einer vollkommen konstanten Prozessgröße einen mathematisch unveränderlichen Zahlenwert.
Ein Drucksignal kann beispielsweise schwanken:
6,421 → 6,426 → 6,419 → 6,424 bar
ohne dass sich der reale Prozess relevant verändert.
Mögliche Ursachen sind:
- Sensorrauschen,
- Auflösung der Messkette,
- EMV-Einflüsse,
- kleine reale Prozessschwankungen,
- Digitalisierungsrauschen.
Wird das Deadband kleiner als diese normale Schwankungsbreite gewählt, entsteht trotz Change-of-Value nahezu wieder ein kontinuierlicher Nachrichtenstrom.
Das Deadband sollte deshalb ausreichend oberhalb der normalen irrelevanten Signalvariation liegen.
Welche Rolle spielt die Messwertauflösung?
Auch die Auflösung des Messsystems muss berücksichtigt werden.
Ein Sensor liefert beispielsweise nur Werte in Schritten von:
0,1 °C
Ein Deadband von:
0,01 °C
wäre in diesem Fall praktisch bedeutungslos.
Umgekehrt sollte das Deadband nicht ohne Grund ein Vielfaches der relevanten Prozessauflösung betragen.
Die Parametrierung sollte deshalb mindestens berücksichtigen:
- Sensorauflösung,
- Messgenauigkeit,
- normale Prozessschwankung,
- relevante kleinste Prozessänderung.
Was passiert bei zu kleinem Deadband?
Ein zu kleines Deadband reduziert die Datenmenge kaum.
Beispiel:
Messwert:
50,00 %
normale Schwankung:
±0,04 %
Deadband:
0,01 %
Bereits normales Messrauschen kann ständig neue Nachrichten erzeugen.
Mögliche Folgen sind:
- hohe MQTT-Nachrichtenrate,
- unnötige Datenbankeinträge,
- größere Cloud-Datenmengen,
- mehr Netzwerklast,
- unruhige Dashboards,
- höherer Energiebedarf bei Funk- beziehungsweise Batteriegeräten.
Die Change-of-Value-Funktion verliert dadurch einen großen Teil ihres Nutzens.
Was passiert bei zu großem Deadband?
Ein zu großes Deadband reduziert zwar die Datenmenge sehr effektiv, kann aber wichtige Informationen verdecken.
Beispiel:
Tankfüllstand:
50,0 %
Deadband:
5 %
Der reale Füllstand sinkt langsam:
50 → 49 → 48 → 47 → 46 %
Im übergeordneten System könnte weiterhin über längere Zeit:
50 %
angezeigt werden.
Die Daten sind technisch nicht unbedingt falsch – sie sind jedoch nicht ausreichend aktuell für den gewünschten Einsatzzweck.
Ein zu großes Deadband kann deshalb:
- langsame Trends verschleiern,
- Wartungsprognosen verschlechtern,
- Dashboards veralten lassen,
- statistische Auswertungen verändern,
- relevante Prozessänderungen verspätet sichtbar machen.
Warum braucht Change-of-Value einen Heartbeat?
Ein unveränderter Messwert sollte nicht bedeuten, dass ein übergeordnetes System niemals wieder eine Nachricht erhält.
Andernfalls ist nach längerer Zeit unklar:
Ist der Wert wirklich unverändert?
oder:
Ist Sensor, Gateway oder Kommunikation ausgefallen?
Deshalb ist die Kombination aus Change-of-Value und einem maximalen Sendeintervall sinnvoll.
Beispiel:
COV-Deadband = 0,1 bar
Heartbeat = 5 min
Damit gilt:
- bei relevanter Änderung sofort senden,
- spätestens nach 5 Minuten aktuellen Zustand erneut senden.
Dadurch bleibt der Datenpunkt auch bei einem vollkommen konstanten Prozess aktuell und überwachbar.
Welcher Zeitstempel sollte übertragen werden?
Bei Change-of-Value ist ein eindeutiger Zeitbezug besonders wichtig.
Ein Datensatz sollte möglichst den Zeitpunkt tragen, zu dem der relevante Messwert tatsächlich erfasst beziehungsweise als Änderung erkannt wurde.
Nicht verwechselt werden sollten:
- Messzeitpunkt,
- Publikationszeitpunkt,
- Broker-Eingangszeit,
- Datenbank-Schreibzeit.
Bei normaler Online-Kommunikation können diese Zeitpunkte sehr nah beieinander liegen.
Bei Buffering oder Verbindungsunterbrechungen können sie sich jedoch deutlich unterscheiden.
Für Historian- und Analyseanwendungen sollte deshalb möglichst der ursprüngliche Mess- beziehungsweise Ereigniszeitpunkt erhalten bleiben.
Was passiert bei Änderung des Qualitätsstatus?
Ein Deadband sollte normalerweise nur die Änderung des eigentlichen Messwertes bewerten.
Ändert sich dagegen der Qualitätsstatus eines Datenpunktes von:
Good → Bad
muss diese Information unabhängig davon übertragen werden, ob sich der Zahlenwert verändert hat.
Beispiel:
Letzter Wert:
6,42 bar · Good
Sensor verliert Kommunikation:
6,42 bar · Bad
Der Zahlenwert ist identisch.
Die Bedeutung des Datensatzes hat sich jedoch vollständig geändert.
Auch Änderungen von:
- Good,
- Uncertain,
- Bad,
- Gerätestatus,
- Diagnoseflags
sollten deshalb unabhängig von der normalen Wert-Deadband-Logik behandelt werden.
Deadband und Alarmhysterese nicht verwechseln
Deadband für Messwertübertragung und Hysterese einer Alarmgrenze erfüllen unterschiedliche Aufgaben.
| Funktion | Zweck |
|---|---|
| Telemetry Deadband | reduziert normale Messwertübertragungen |
| Alarmhysterese | verhindert wiederholtes Ein-/Ausschalten eines Alarms an der Grenze |
| Alarmverzögerung | bewertet, wie lange eine Grenzwertverletzung bestehen muss |
Eine Alarmbedingung sollte im Idealfall auf ausreichend häufig erfassten lokalen beziehungsweise unbearbeiteten Prozesswerten ausgewertet werden.
Sie sollte nicht davon abhängen, ob ein Telemetrie-Deadband zufällig bereits eine neue Übertragung ausgelöst hat.
Alarmierung und Datenreduktion sollten deshalb getrennte Funktionen bleiben.
Können kurze Spitzen durch COV verloren gehen?
Change-of-Value allein schützt nicht automatisch vor Informationsverlust.
Ein Edge-System kann beispielsweise jede Sekunde messen, aber nur relevante Änderungen publizieren.
Ein kurzer Druckpeak könnte intern auftreten und wieder verschwinden, bevor der nächste reguläre Heartbeat gesendet wird.
Je nach Anwendung kann deshalb zusätzlich sinnvoll sein:
- Minimum speichern,
- Maximum speichern,
- Mittelwert übertragen,
- Peak als eigenes Event behandeln,
- Rohdaten für begrenzte Zeit lokal puffern.
Ein möglicher Datensatz könnte beispielsweise enthalten:
average = 6,42 bar
min = 6,39 bar
max = 6,91 bar
Damit bleibt ein kurzzeitiger Peak sichtbar, obwohl nicht jedes Rohsample dauerhaft in der Cloud gespeichert wird.
Praxisbeispiel: langsam veränderlicher Prozessdruck
Ein Drucksensor überwacht eine Versorgungsleitung.
Messbereich:
0 ... 10 bar
Normale Betriebsgröße:
ca. 6,5 bar
Interne Erfassung:
1 Wert/s
Das Sensorsignal schwankt im stabilen Betrieb typischerweise um:
±0,02 bar
Zunächst wird jeder Wert per MQTT an den Historian übertragen.
Dadurch entstehen pro Messstelle täglich:
86.400 Nachrichten
obwohl sich der Prozess häufig über Stunden kaum verändert.
Die Edge-Konfiguration wird deshalb beispielhaft geändert auf:
Deadband = 0,10 bar
Heartbeat = 5 min
Der Druck startet bei:
6,40 bar
und verändert sich langsam:
6,42 → 6,44 → 6,46 → 6,48 → 6,50 bar
Erst bei:
6,50 bar
wird ein neuer COV-Wert übertragen.
Bleibt der Druck danach unverändert, wird spätestens mit dem Heartbeat erneut der aktuelle Zustand publiziert.
Die lokale Alarmierung arbeitet unabhängig davon weiter auf den laufend erfassten Messwerten.
Damit wird die IT-seitige Datenmenge deutlich reduziert, während Prozessüberwachung, Alarmierung und Aktualitätskontrolle erhalten bleiben.
Wie stark kann COV die Datenmenge reduzieren?
Die mögliche Reduzierung hängt vollständig von der Prozessdynamik ab.
Bei einem festen Intervall von einer Sekunde entstehen:
86.400 Werte pro Tag und Messstelle
Bei einem Heartbeat von fünf Minuten entstehen allein durch den Heartbeat:
288 Werte pro Tag
Hinzu kommen sämtliche tatsächlichen Change-of-Value-Ereignisse.
Bei einer sehr ruhigen Messgröße kann die Reduktion deshalb erheblich sein.
Bei einem hochdynamischen Prozess kann dagegen fast jedes Sample die Deadband-Grenze überschreiten.
Change-of-Value ist daher besonders interessant für langsam veränderliche Größen wie beispielsweise:
- Tankfüllstand,
- Raumtemperatur,
- bestimmte Prozessdrücke,
- langsame Temperaturprozesse,
- Vorratsmengen.
Was passiert bei Verbindungsunterbrechung?
Ein IIoT-System sollte definieren, was passiert, wenn die Verbindung zum Broker beziehungsweise zur Cloud ausfällt.
Mögliche Strategie:
- Sensor beziehungsweise Edge erfasst weiterhin lokal.
- Relevante COV-Ereignisse erhalten ihren ursprünglichen Zeitstempel.
- Datensätze werden lokal gepuffert.
- Nach Wiederherstellung der Verbindung werden sie übertragen.
Dabei muss verhindert werden, dass ein später übertragener Messwert fälschlich so behandelt wird, als wäre er erst zu diesem Zeitpunkt entstanden.
Zusätzlich sollte nach einem Neustart beziehungsweise Reconnect der aktuelle Zustand gezielt publiziert werden.
Damit kennt das übergeordnete System wieder einen definierten Ausgangswert für die weitere Change-of-Value-Auswertung.
Deadband systematisch auswählen
- Messgröße und Messbereich definieren.
- Sensorauflösung bestimmen.
- Typisches Messrauschen beziehungsweise normale Prozessschwankung bestimmen.
- Kleinste fachlich relevante Prozessänderung definieren.
- Deadband oberhalb irrelevanter Schwankungen festlegen.
- Prüfen, ob das Deadband klein genug für Trend- und Diagnoseanforderungen bleibt.
- Vergleichsbasis des konkreten COV-Algorithmus prüfen.
- Heartbeat beziehungsweise maximales Sendeintervall definieren.
- Qualitäts- und Statusänderungen vom Wert-Deadband ausnehmen.
- Alarme unabhängig von der Telemetrie-Reduktion behandeln.
- Min-/Max- beziehungsweise Peak-Erfassung bei Bedarf ergänzen.
- Original-Zeitstempel erhalten.
- Offline-Buffering und Reconnect-Verhalten definieren.
- Datenmenge und Informationsqualität im Pilotbetrieb überprüfen.
Häufige Fehler
- Abtastrate und Sendeintervall gleichsetzen: Ein Sensor kann schnell messen und trotzdem nur ausgewählte Werte übertragen.
- Deadband kleiner als das normale Sensorrauschen einstellen: Dadurch entsteht nahezu wieder kontinuierliche Telemetrie.
- Deadband nur nach Datenkosten auswählen: Die fachlich relevante kleinste Prozessänderung ist entscheidend.
- Keinen Heartbeat verwenden: Ein unveränderter Wert lässt sich dann schwer von einem Kommunikationsausfall unterscheiden.
- Nur jeden Wert mit dem vorherigen Sample vergleichen: Je nach Implementierung kann eine langsame Drift dadurch ungünstig behandelt werden.
- Alarmhysterese und Telemetrie-Deadband verwechseln: Beide Funktionen haben unterschiedliche Aufgaben.
- Qualitätsstatus dem normalen Deadband unterwerfen: Good → Bad muss auch bei unverändertem Zahlenwert übertragen werden.
- Zeitstempel erst im Cloud-System erzeugen: Bei Buffering geht dadurch der ursprüngliche Messzeitpunkt verloren.
- Change-of-Value ohne Peak-Erfassung verwenden: Kurze relevante Extremwerte können in verdichteten Langzeitdaten fehlen.
- Relatives Deadband ohne Bezugsgröße dokumentieren: Ein Prozentwert ist ohne eindeutige Referenz mehrdeutig.
- Nach Reconnect keinen aktuellen Zustand senden: Das übergeordnete System kann dadurch mit einem veralteten letzten Wert weiterarbeiten.
- Ein einziges Deadband für alle Messgrößen verwenden: Temperatur, Druck, Füllstand und Vibration besitzen völlig unterschiedliche Dynamiken.
IIoT-Lösungen vom Feldgerät bis zur Cloud
ICS Schneider integriert industrielle Messstellen vom Feldgerät über Edge-Gateways bis in SCADA-, Historian- und Cloud-Systeme.
Typische Feldschnittstellen sind beispielsweise:
- RS-485 / Modbus RTU,
- HART,
- IO-Link,
- OPC UA,
- Ethernet.
Für die Übertragung in höhere IT-Ebenen können unter anderem MQTT beziehungsweise HTTPS eingesetzt werden.
Ein typischer Aufbau lautet:
Sensor → Feldkommunikation → Edge-Gateway → MQTT/HTTPS → Historian / Dashboard / Cloud
Das Edge-System kann dabei Aufgaben übernehmen wie:
- Skalierung,
- Zeitstempelung,
- Datenmodellierung,
- lokale Alarmverarbeitung,
- Buffering,
- Datenverdichtung,
- Deadband beziehungsweise Publish-on-Change.
Welche Funktionen tatsächlich zur Verfügung stehen, hängt vom eingesetzten Gateway, Betriebssystem und der jeweiligen Softwarekonfiguration ab.
Ein bei ICS geführtes Beispiel einer IIoT-Gerätearchitektur ist der Siemens SITRANS MS200, der für Vibrations- und Temperaturüberwachung in Kombination mit dem SITRANS CC220 Gateway vorgesehen ist.
Bei einer solchen Architektur sollte klar definiert werden, ob Change-of-Value beziehungsweise Deadband:
- bereits im Sensor,
- im Gateway,
- in einer Edge-Applikation oder
- erst im übergeordneten System
realisiert wird.
Weitere Informationen finden Sie unter IIoT-Lösungen bei ICS Schneider.
Fazit
Ein festes Sendeintervall ist einfach zu konfigurieren, führt bei langsam veränderlichen Messgrößen jedoch häufig zu einer großen Zahl nahezu identischer Datensätze.
Change-of-Value trennt die interne Messwerterfassung von der eigentlichen Übertragung. Ein neuer Datensatz wird erst dann publiziert, wenn sich die Messgröße um einen definierten Betrag verändert.
Entscheidend ist dabei die richtige Deadband-Größe. Sie sollte groß genug sein, um Sensorrauschen und irrelevante Schwankungen nicht ständig zu übertragen, aber klein genug, um fachlich relevante Änderungen und langsame Trends sichtbar zu halten.
Ein COV-System sollte zudem nicht ausschließlich aus einem Deadband bestehen. Ein periodischer Heartbeat stellt sicher, dass ein unveränderter Prozesswert weiterhin als aktuell erkennbar bleibt.
Qualitätsänderungen, Diagnosezustände und Alarme sollten unabhängig vom normalen Wert-Deadband behandelt werden. Auch Original-Zeitstempel, Offline-Buffering und das Verhalten nach einem Reconnect müssen Bestandteil der Datenstrategie sein.
Für eine belastbare IIoT-Telemetrie gilt deshalb: ausreichend schnell erfassen, nur relevante Wertänderungen übertragen, ein an Messrauschen und Prozessdynamik angepasstes Deadband wählen, periodisch einen Heartbeat senden und Status-, Alarm- und Qualitätsänderungen niemals allein von der normalen Change-of-Value-Schwelle abhängig machen.
FAQ: Change-of-Value und Deadband bei IIoT-Messwerten
Was bedeutet Change-of-Value?
Bei Change-of-Value wird ein neuer Messwert erst übertragen, wenn sich die Messgröße gegenüber einer definierten Referenz ausreichend verändert hat.
Was ist ein Deadband?
Das Deadband definiert die minimale Messwertänderung, die einen neuen Datensatz beziehungsweise eine neue Übertragung auslöst.
Ist Deadband dasselbe wie Hysterese?
Nicht unbedingt. Ein Telemetrie-Deadband steuert, wann Messwerte übertragen werden. Eine Alarmhysterese steuert dagegen, wann ein Alarm ein- beziehungsweise zurückgeschaltet wird.
Muss ein Sensor bei COV langsamer messen?
Nein. Der Sensor beziehungsweise das Edge-System kann weiterhin mit hoher Rate erfassen. Nur die Publikationsrate wird reduziert.
Wie groß sollte das Deadband sein?
Es sollte oberhalb der normalen irrelevanten Signalvariation liegen, gleichzeitig aber kleiner als die kleinste fachlich relevante Prozessänderung bleiben.
Was passiert bei einem zu kleinen Deadband?
Sensorrauschen und kleine Prozessschwankungen erzeugen ständig neue Nachrichten. Die gewünschte Datenreduktion fällt dadurch gering aus.
Was passiert bei einem zu großen Deadband?
Langsame Veränderungen können erst verspätet übertragen werden. Trends und aktuelle Prozesszustände können dadurch schlechter sichtbar sein.
Warum braucht Change-of-Value einen Heartbeat?
Ein Heartbeat stellt sicher, dass auch bei unverändertem Messwert regelmäßig ein aktueller Zustand übertragen wird. Dadurch lässt sich ein stabiler Prozess besser von einem Kommunikationsausfall unterscheiden.
Soll ein Qualitätswechsel ein COV-Ereignis auslösen?
Ja. Ändert sich beispielsweise der Status von Good auf Bad, sollte diese Änderung unabhängig vom numerischen Deadband übertragen werden.
Können kurze Peaks bei COV verloren gehen?
Ja, wenn keine zusätzliche Peak-, Min-/Max- oder Ereignislogik vorhanden ist. Relevante Extremwerte sollten deshalb je nach Anwendung separat erfasst werden.
Ist ein absolutes oder prozentuales Deadband besser?
Das hängt von der Anwendung ab. Ein absolutes Deadband in technischen Einheiten ist häufig besonders transparent. Bei einem prozentualen Deadband muss die Bezugsgröße eindeutig definiert sein.
Wo sollte die COV-Logik ausgeführt werden?
Je nach Architektur kann sie im Sensor, in der SPS, im Edge-Gateway oder in einer übergeordneten Anwendung umgesetzt werden. Für schnelle lokale Alarme sollte die sicherheits- beziehungsweise prozessrelevante Auswertung möglichst nicht von einer entfernten Cloud-Verbindung abhängig sein.
Welche IIoT-Lösungen bietet ICS Schneider dafür?
ICS Schneider integriert Sensorik und Feldgeräte über Schnittstellen wie Modbus RTU, HART, IO-Link, OPC UA oder Ethernet in Edge-, SCADA- und Cloud-Architekturen und unterstützt bei Datenmodell, Topic-Design, Zeitstempelung, Alarmen, Buffering und Datenvorverarbeitung.