Report by exception ist eine Datenerfassungsmethode, bei der eine Maschine oder ein Edge‑Gerät einen Wert nur dann sendet, wenn er sich um mehr als einen definierten Schwellenwert ändert, anstatt Messwerte in festen Zeitintervallen zu übertragen. Die Alternative, Polling, fragt jedes Gerät in regelmäßigen Abständen nach seinem aktuellen Wert — unabhängig davon, ob sich etwas verändert hat oder nicht. Auf einem modernen Fabrikboden mit Hunderten von Tags, die von PLCs, Sensoren und Vision‑Systemen stammen, entscheidet der Unterschied zwischen diesen beiden Ansätzen darüber, ob Ihr Netzwerk gesund bleibt oder in redundanten Daten versinkt. Dieser Artikel erklärt Report by Exception, die dahinterstehenden Totband‑ (Deadband) und Change‑of‑Value‑Techniken und wie Sie Maschinendaten wirtschaftlich skalieren, ohne das wirklich wichtige Signal zu verlieren.
Polling ist in vielen älteren SCADA‑ und Historian‑Setups die Voreinstellung, weil es einfach ist: Ein Master‑Gerät fragt jeden Tag in einem Zyklus ab, sagen wir einmal pro Sekunde, und schreibt alles, was zurückkommt. Das Problem ist, dass sich die meisten Prozesswerte die meiste Zeit nicht ändern. Eine Tanktemperatur, die zehn Minuten lang bei 72,0 °C bleibt, erzeugt bei Abfragen im Sekundentakt trotzdem 600 identische Messwerte. Hochgerechnet auf alle Tags an einer Linie zahlen Sie für Bandbreite, Speicher und Edge‑CPU, um Daten zu übertragen, die nichts Neues aussagen.
Polling skaliert außerdem schlecht. Jedes neue Gerät verlängert die Poll‑Schleife, sodass entweder Ihre Abtastrate langsamer wird oder Sie die Last auf mehr Kanäle und Gateways verteilen müssen. Auf beschränkten Verbindungen (Mobilfunk, LoRa oder ein geteiltes industrielles VLAN) kann der fixe Traffic‑Fußboden von Polling die Messwerte verdrängen, die Ihnen wirklich wichtig sind. Das Verständnis Ihres tatsächlichen Datenprofils ist eine Voraussetzung für jede Echtzeit‑Überwachung — genauso wie das Verstehen Ihrer Verluste eine Voraussetzung zur Verbesserung der Gesamtanlageneffektivität ist.
Report by Exception (oft RBE oder ereignisgesteuertes Reporting genannt) kehrt das Modell um. Das Edge‑Gerät hält den zuletzt übermittelten Wert und vergleicht ihn kontinuierlich mit dem Live‑Messwert. Es sendet ein Update nur, wenn die neue Messung einen Schwellenwert überschreitet. Während der Prozess stabil ist, bleibt auf dem Draht nichts verändert, und in dem Moment, in dem ein Wert sich bewegt, wird die Änderung sofort propagiert. Das Ergebnis ist Traffic, der proportional zu der tatsächlichen Variabilität Ihres Prozesses ist — nicht dazu, wie viele Tags Sie haben oder wie schnell Sie abfragen.
Zwei Mechanismen machen das zuverlässig:
Die meisten Implementierungen kombinieren beides: Das Totband unterdrückt Rauschen, die COV‑Logik steuert das eigentliche Reporting, und ein Heartbeat oder eine Maximalzeit‑Einstellung garantiert ein periodisches Update auch während langer stabiler Phasen, sodass nachgelagerte Systeme wissen, dass die Verbindung lebt.
Deadband wird üblicherweise als absoluter Wert oder als Prozentsatz des Signalspektrums angegeben. Nehmen wir an, Sie haben einen Temperatursensor mit einem Messbereich von 0 bis 200 °C, der ein Live‑Analogsignal liefert, das etwa 0,3 °C elektrisches Rauschen enthält. Sie setzen ein Deadband von 1,0 °C.
Nun die Bandbreiten‑Rechnung. Bei Abfragen im Sekundentakt erzeugt dieses einzelne Tag 86.400 Nachrichten pro Tag, unabhängig vom Verhalten. Angenommen, die Temperatur überschreitet während der Produktion etwa 40‑mal pro Stunde das Deadband von 1,0 °C, das sind 960 Ereignisse pro Tag, plus ein Sicherheits‑Heartbeat alle 15 Minuten, der 96 Nachrichten hinzufügt. Report by Exception sendet also grob 1.056 Nachrichten pro Tag gegenüber 86.400 beim Polling — eine Reduktion von etwa 98,8 Prozent. Bei 300 Tags mit ähnlichem Profil gehen Sie von 25,9 Millionen Nachrichten täglich auf rund 317.000 und haben keine der aussagekräftigen Übergänge verloren.
Der Hebel ist die Deadband‑Breite. Zu breit und Sie glätten echte Ereignisse weg; zu eng und Rauschen kommt durch. Stimmen Sie jedes Tag auf seinen eigenen Rauschboden und die kleinste Änderung ab, die geschäftliche Bedeutung hat — so wie ein gut aufgebauter Control‑Plan Toleranzen pro Merkmal statt einer einheitlichen Regel vorgibt.
Die Befürchtung bei Report by Exception ist, etwas Wichtiges zu verpassen. Dem begegnen Sie, indem Sie den Deadband gezielt und nicht aus dem Bauch heraus setzen:
So angewendet ist Report by Exception nicht verlustbehaftet. Sie behalten jede Transition, die Ihre definierte Signifikanzschwelle überschreitet, und hören einfach auf, für die Zwischenphasen mit flachen Kurven zu bezahlen. Für die Ursachenanalyse bei hartnäckigen Verlusten sind genau diese Übergänge gewünscht, und eine Pareto‑Analyse der Exception‑Ereignisse macht die größten Verursacher schneller sichtbar als das Durchsieben von polled‑Rauschen.
Das ist keine Alles‑oder‑Nichts‑Entscheidung. Eine pragmatische Architektur nutzt beides:
Die Abwägungen: Report by Exception benötigt Edge‑Logik, um letzte Werte zu halten und Deadbands auszuwerten, und kann bei starken Prozessschwankungen burstigen Traffic erzeugen. Polling ist denkbar simpel und zeitlich deterministisch, aber verschwenderisch und schlecht skalierbar. Viele SCADA‑Historianer unterstützen beide Modelle pro Tag, sodass Sie die Methode an das Signal anpassen können. Dasselbe gestufte Denken, das reaktive von proaktiver Wartung trennt, gilt auch hier: Verwenden Sie standardmäßig die kostengünstigere ereignisgesteuerte Methode und reservieren Sie die schwerere Fixed‑Cadence‑Methode dort, wo sie ihre Kosten rechtfertigt. Ereignisströme füttern zudem sauber zustandsbasierte Wartung, bei der ein Überschreiten einer Schwelle genau der Auslöser ist, auf den Sie reagieren.
Fabrico ist die Echtzeit‑Datenbasis, die auf der von Ihrer Fertigung genutzten Erfassungsmethode aufsetzt. Es ingestiert Live‑Maschinen‑ und Produktionssignale für Echtzeit‑OEE und Produktionsüberwachung und kann Maschinen per Computer‑Vision auslesen, wo es keine PLC gibt, die abgefragt werden kann oder Events pusht — oft der Fall bei älteren oder eigenständigen Anlagen. Dieser Vision‑Pfad liefert Ihnen einen exception‑artigen Stream (Zykluszählungen, Stopps, Zustandswechsel) von Ausrüstung, die nie für IIoT instrumentiert wurde. Im Wartungsbereich ist Fabrico ein feldbereites CMMS, das Arbeitsaufträge, Anlagen, vorbeugende Planung und Ersatzteile abdeckt, sodass die Ereignisse, die Ihre Datenebene sichtbar macht, direkt in Maßnahmen münden. Fabrico ist in der EU entwickelt und bietet EU‑Datenresidenz — wichtig, wenn Ihre Maschinendaten die Region nicht verlassen dürfen. Entdecken Sie die OEE‑Monitoring‑ und CMMS‑Übersichten, um zu sehen, wie die Teile zusammenpassen.
Nicht, wenn der Deadband richtig eingestellt ist. Sie behalten jede Änderung, die Ihre definierte Signifikanzschwelle überschreitet, und unterdrücken nur Bewegungen, die kleiner sind — was definitionsgemäß Rauschen oder unterhalb der Handlungsschwelle liegend ist. Ein verpflichtendes Heartbeat‑Intervall garantiert zudem eine periodische Messung auch während langer stabiler Phasen, sodass Historianer und nachgelagerte Systeme immer einen aktuellen Anker haben und die Verbindung als aktiv bestätigen können.
Change‑of‑Value‑Reporting ist die Regel, die ein Update auslöst, wenn sich ein Wert im Vergleich zum zuletzt gemeldeten unterscheidet. Deadbanding ist die Toleranzzone, die definiert, wie groß diese Differenz sein muss, damit sie zählt. In der Praxis arbeiten sie zusammen: Das Deadband filtert Zittern und analoges Rauschen heraus, und die COV‑Logik steuert die tatsächliche Übertragung, wenn das Signal die Zone verlässt.
Ja — und die meisten gut gestalteten Systeme tun das. Verwenden Sie Report by Exception für die Mehrheit der kontinuierlichen analogen Tags und Zustandsänderungen und reservieren Sie Polling für Fälle, die einen garantierten Wert in fester Taktung benötigen, etwa für regulatorische Protokolle oder legacy‑Geräte, die keine Events pushen können. Viele Historianer und Gateways erlauben, die Methode pro Tag einzustellen, sodass Sie jedes Signal der passenden Vorgehensweise zuordnen können.
Bereit, effiziente Maschinendaten in Echtzeit‑OEE und handlungsfähige Wartung zu verwandeln? Buchen Sie eine Fabrico‑Demo und sehen Sie, wie eine Live‑Datenbasis, einschließlich Vision für Maschinen ohne PLC, sich über Ihre Fertigung hinweg skaliert.
Anmeldung
Blog
