NOVO AI · PRAXISLEITFADEN 20 MIN. LESEZEIT

Die Entscheidung auf einen Blick

MDE-Datenlücken lassen sich im laufenden Betrieb belastbar eingrenzen, wenn Sie die Fehlersuche nicht mit dem Dashboard, sondern mit dem Zeitbezug beginnen. Prüfen Sie zuerst, ob SourceTimestamp, ServerTimestamp und lokale Uhr überhaupt dasselbe Ereignis meinen. Danach kommen StatusCode und Null-Werte, erst dann Wiederanlauf, Pufferung, Zähler-Gegenprobe und Schichtgrenzen.

Zum Vergleich

Der praktische Nutzen dieser Reihenfolge ist einfach: Sie trennen ein Zeitproblem von einem Qualitätsproblem, ein Übertragungsproblem von einem Berichtsproblem und eine Mengendifferenz von einer bloßen Visualisierungsfrage. Genau das fehlt in vielen Diskussionen über fehlerhafte Daten. Die Frage ist nicht nur, dass eine Lücke sichtbar wird, sondern an welcher Stelle sie entsteht.

Dieser Beitrag ist deshalb ein Diagnoseleitfaden für den Betrieb, kein allgemeiner OEE-Überblick und kein eigener Praxistest. Die Herleitung stützt sich auf die Zeitstempel- und Qualitätssemantik aus OPC UA Part 4, auf dokumentierte Hinweise zu NTP- und Uhrverhalten in der Beckhoff-NTP-Dokumentation sowie in den TwinCAT Time Sources, ergänzt um Novo-Inhalte zur Abnahme und Brownfield-MDE.

Wichtig ist die Grenze des Leitfadens: Öffentliche Dokumentation beschreibt Begriffe, Schnittstellen und Herstellerpositionen. Daraus folgt nicht automatisch, dass Ihre konkrete Maschine, Ihr Gateway oder Ihr aktuelles Projekt diese Semantik vollständig und korrekt implementiert. Genau deshalb endet der Beitrag nicht bei Definitionen, sondern in einem Prüfprotokoll mit Verifikationspunkten.

01 / PRAXISWISSEN

Der Diagnosebaum für MDE-Datenlücken

Wenn Sie nur einen Abschnitt übernehmen, dann diesen. Der Diagnosebaum priorisiert die Prüfung nach technischer Trennschärfe. Er beginnt mit dem Zeitmodell, weil jeder spätere Bericht, jede Schichtzuordnung und jede Dauerberechnung daran hängt. Erst wenn klar ist, welche Uhr, welcher Zeitstempel und welcher Qualitätsstatus gelten, lohnt sich die Suche nach Buffering-, Restart- oder Zählerfehlern.

Ich empfehle, den Ablauf genau in dieser Reihenfolge zu dokumentieren. Das ist keine normative Pflicht aus einem Standard, sondern eine abgeleitete Prüfhilfe aus den gelesenen Quellen. Für Brownfield-Setups mit externer Zustandserkennung passt diese Reihenfolge besonders gut, weil dort Zeitbezug, Zustandsklassifikation und nachgelagerte Ursachebuchung klar getrennt betrachtet werden sollten.

Erste Einordnung von MDE-Datenlücken im laufenden Betrieb

Wählen Sie ein Kriterium. Die Optionen stehen direkt nebeneinander.

Beobachtung

Zeitstempel laufen rückwärts, springen oder verschieben sich um feste Offsets

Wahrscheinlich zu prüfen

UTC, lokale Uhr, NTP-Sprünge, falscher Zeitstempeltyp

Erster Nachweis

Rohdatenexport mit SourceTimestamp und ServerTimestamp vergleichen

Nächster Schritt

Zeitquelle einfrieren und vor jeder weiteren Analyse dokumentieren

Beobachtung

Wert vorhanden, Bericht zeigt aber Lücke oder unplausiblen Abschnitt

Wahrscheinlich zu prüfen

StatusCode, Null-Werte, Bad- oder Uncertain-Phasen

Erster Nachweis

Statusfelder und Null-Werte im Export sichtbar machen

Nächster Schritt

Betroffene Abschnitte als QA-Fall markieren, nicht als Produktion buchen

Beobachtung

Nach Netz- oder Rechnerausfall entstehen Doppelungen oder offene Segmente

Wahrscheinlich zu prüfen

Wiederanlauf, Pufferung, Reihenfolge, Schließen offener Ereignisse

Erster Nachweis

Chronologie rund um den Ausfall separat prüfen

Nächster Schritt

Restart-Testfall und Export-Reihenfolge in ein Prüfprotokoll aufnehmen

Beobachtung

Laufzeit wirkt plausibel, Stückzahl oder Zykluszahl passt aber nicht

Wahrscheinlich zu prüfen

Zählerquelle, Reset, Rollover, falsche Zyklusannahme

Erster Nachweis

Zählerdelta gegen gemeldete Produktionszeit rechnen

Nächster Schritt

Zähler-Gegenprobe mit Annahmen und Sensitivität dokumentieren

Beobachtung

Lücken nur an Schichtende, Pausen oder Auftragswechseln

Wahrscheinlich zu prüfen

Schichtgrenzen, Kalenderlogik, Schnitt offener Ereignisse

Erster Nachweis

Grenzereignisse an denselben Uhrzeiten vergleichen

Nächster Schritt

Regelwerk für Schichtschnitt und offene Ereignisse angleichen

Beobachtung

Zustand ist da, Stillstandsgrund oder Kommentar fehlt

Wahrscheinlich zu prüfen

Trennung zwischen Zustandserkennung und Ursachenbuchung

Erster Nachweis

Prüfen, ob nur Ursachefelder fehlen oder die Zeitachse selbst

Nächster Schritt

Bedien- oder Zusatzdatenfluss separat betrachten

Die ersten beiden Zeilen klären bereits einen großen Teil der Diskussion. In OPC UA Part 4 sind Zeitstempel und StatusCode getrennte Informationsfelder. Ein scheinbar fehlender Datensatz kann also auch bedeuten, dass ein Wert zwar transportiert wurde, aber wegen Qualitätsstatus oder Null-Semantik nicht für die Auswertung taugt. Wer diese Ebenen vermischt, sucht an der falschen Stelle.

Für Brownfield-Projekte mit externer Sensorik ist zusätzlich wichtig, dass nicht jede sichtbare Lücke eine fehlende Maschinenbeobachtung ist. Die öffentliche Novo-Dokumentation zur Maschinendatenerfassung für Bestandsmaschinen trennt ausdrücklich zwischen Zustandserkennung und Ursachenklärung. Genau diese Trennung sollten Sie in Ihrem Prüfprotokoll beibehalten, sonst wird aus einem Diagnoseproblem vorschnell ein Vorwurf an Bedienung oder Technik.

Schritt 1: Rohdaten vollständig ziehen.
Exportieren Sie für den betroffenen Zeitraum mindestens Ereigniszeit, vorhandene Zeitstempeltypen, StatusCode oder Qualitätsflag, Wert beziehungsweise Zustand, Maschinenkennung, Schichtbezug und Zählerstände. Erwartetes Ergebnis ist eine chronologisch prüfbare Rohsicht. Verifikation: Jeder Berichtseintrag muss auf mindestens einen konkreten Rohdatensatz zurückführbar sein.
Schritt 2: Zeitmodell einfrieren.
Dokumentieren Sie, welche Uhr den Ereigniszeitpunkt setzt, ob UTC oder lokale Zeit verwendet wird und ob SourceTimestamp oder ServerTimestamp in Berichten landet. Erwartetes Ergebnis ist ein eindeutiges Zeitmodell pro Datenpfad. Verifikation: Dieselbe physische Situation darf im Export nicht mit wechselndem Zeitbezug erscheinen.
Schritt 3: Qualitätsfelder vor der Fachlogik prüfen.
Behandeln Sie Bad-, Uncertain- und Null-Fälle getrennt von Produktion und Stillstand. Erwartetes Ergebnis ist eine klare QA-Klasse für technisch unsichere Abschnitte. Verifikation: Kein Abschnitt mit schlechtem Status wird stillschweigend als sichere Laufzeit oder sicherer Stopp verrechnet.
Schritt 4: Ausfall und Wiederanlauf isolieren.
Untersuchen Sie die Chronologie direkt vor, während und nach Kommunikationsunterbrechungen oder Rechnerneustarts. Erwartetes Ergebnis ist eine nachvollziehbare Reihenfolge ohne Doppelung. Verifikation: Offene Ereignisse schließen konsistent, und der erste Datensatz nach Wiederanlauf erklärt den Übergang statt ihn zu verdecken.
Schritt 5: Zähler-Gegenprobe rechnen.
Vergleichen Sie Zählerdelta, gemeldete Produktionszeit und dokumentierte Zyklusannahmen. Erwartetes Ergebnis ist keine Wahrheit in einer Zahl, sondern eine Plausibilitätsgrenze. Verifikation: Größere Differenzen führen zu einer fokussierten Suche nach Reset, Rollover, falscher Zustandsklassifikation oder unpassender Taktannahme.
Schritt 6: Grenzereignisse an Schicht- und Auftragsgrenzen prüfen.
Sehen Sie sich Segmente an, die eine Pause, ein Schichtende oder einen Auftragswechsel schneiden. Erwartetes Ergebnis ist ein konsistenter Kalenderschnitt. Verifikation: Dasselbe Grenzbild führt unabhängig von Schicht oder Bericht immer zur gleichen Zuordnung.

Wenn dieser Ablauf sauber dokumentiert ist, können Sie die spätere Freigabe gezielter formulieren. Genau dafür ist das interne MDE-Abnahmeprotokoll für Bestandsmaschinen nützlich: Es trennt Zeitbasis, Zustandswechsel, Schichtgrenzen, erkennbare Datenlücken und Zähler-Gegenprobe als eigenständige Freigabefragen. Für Troubleshooting im Betrieb ist das ein besseres Raster als ein pauschales Daten sind falsch.

02 / PRAXISWISSEN

Zeitstempel zuerst: SourceTimestamp, ServerTimestamp und Uhrkonsistenz

Die technisch wichtigste Unterscheidung ist banal formuliert und im Alltag dennoch leicht zu übersehen: Wann ist das Ereignis an der Quelle passiert? und wann hat ein Server diesen Zustand empfangen oder für gültig gehalten? In OPC UA 7.11.3 steht diese Trennung explizit. Genau daraus folgt, warum zwei Berichte bei gleichem Prozessverlauf unterschiedlich aussehen können.

SourceTimestamp ist nicht ServerTimestamp

Der SourceTimestamp soll die Quellzeit in UTC abbilden und möglichst nahe an der Entstehung des Werts gesetzt werden. Außerdem soll er für dieselbe Wertinstanz unverändert bleiben, auch wenn ein OPC-UA-Server den Wert von einem anderen Server übernimmt. Der ServerTimestamp beschreibt dagegen den Zeitpunkt, zu dem der Server den Wert erhalten oder weiterhin für aktuell gehalten hat.

Das hat unmittelbare Folgen für Ihre Fehlersuche. Wenn ein Bericht scheinbar dichte Daten zeigt, aber Zeitabstände beim Rückrechnen nicht stimmen, prüfen Sie zuerst, ob die Auswertung auf ServerTimestamp statt auf SourceTimestamp basiert. Ein unveränderter Maschinenzustand kann auf Serverseite mehrfach aktualisiert erscheinen, obwohl sich an der Quelle nichts verändert hat. Dann liegt keine echte Maschinenlücke vor, sondern ein anderer Zeitbezug.

Umgekehrt ist ein leerer oder nuller SourceTimestamp nicht automatisch ein Beweis für Kommunikationsausfall. Laut OPC UA 7.11.3 wird der SourceTimestamp auf null gesetzt, wenn die Quelle den Zeitstempel nicht anwenden konnte oder nicht verfügbar ist. Der Fehler liegt dann zunächst in der Erzeugung oder Weitergabe des Quellzeitstempels, nicht zwingend im Bericht oder im Dashboard.

UTC, lokale Zeit und feste Offsets

Der zweite Prüfpunkt ist unspektakulär, aber wirksam: Liegt ein konstanter Offset vor, etwa genau eine oder zwei Stunden? Dann sprechen Sie eher über Zeitzone, Sommerzeit oder eine fehlerhafte Umrechnung als über echte Lücken. Ein Zeitversatz mit fester Differenz ist diagnostisch etwas ganz anderes als ein unregelmäßiger Zeitsprung oder eine rückwärts laufende Sequenz.

Deshalb empfehle ich, im Export immer mindestens eine Referenzspalte zu ergänzen: UTC-Rohzeit, lokale Darstellungszeit oder den klar dokumentierten Konvertierungsschritt. Sobald diese Transparenz fehlt, wird ein reines Anzeigeproblem mit einem Erfassungsproblem verwechselt. Gerade bei Schichtberichten, in denen Zeiten gerundet oder lokalisiert dargestellt werden, ist das ein häufiger Denkfehler in der Analyse.

NTP- und SNTP-Sprünge nicht mit Prozessereignissen verwechseln

Die Beckhoff-Dokumentation zu TwinCAT/BSD beschreibt, dass lokale Industrie-PC-Zeiten per NTP mit Zeitservern synchronisiert werden. In den TwinCAT Time Sources wird zusätzlich erläutert, dass übliche Betriebssystem-Synchronisation in diskreten Intervallen arbeitet und dadurch sprunghafte Änderungen der absoluten Zeit entstehen können. Für Ihre Diagnose bedeutet das: Nicht jeder Zeitbruch ist eine unterbrochene Produktion.

Wenn Zeitstempel plötzlich nach vorn oder hinten springen, prüfen Sie zuerst, ob die betroffene Uhr überhaupt auf Betriebssystemebene synchronisiert wird und welche Uhr der Datenpfad tatsächlich verwendet. Die Beckhoff-Dokumentation empfiehlt für absolute Zeitbezüge eher TC- oder DC-Zeit als frei laufende lokale Uhren. Diese Aussage belegt kein Verhalten anderer Hersteller, sie zeigt aber sauber, warum die Uhrarchitektur selbst ein eigenständiger Prüfpunkt ist.

Ein praktischer Testfall ist leicht aufzusetzen: Vergleichen Sie für denselben Ereignisabschnitt Rohdaten, Visualisierung und Serverlog vor und nach einem dokumentierten Neustart oder einer geplanten Netztrennung. Wenn nur die absolute Zeit springt, aber die physische Reihenfolge gleich bleibt, suchen Sie im Zeitmodell weiter. Wenn Reihenfolge, Dauer und Status gemeinsam entgleisen, ist die Ursache tiefer im Datenpfad zu suchen.

Dieser Schritt gehört bewusst an den Anfang. Eine spätere Zählerprüfung hilft wenig, wenn die Zeitleiste selbst nicht stabil ist. Erst wenn die Uhrkonsistenz erklärt ist, können Sie überhaupt beurteilen, ob eine Lücke in Minuten real, nur verschoben oder bloß falsch etikettiert ist.

03 / PRAXISWISSEN

StatusCode, Null-Werte und scheinbar fehlende Ereignisse

Viele Teams suchen bei MDE-Datenlücken zuerst nach komplett fehlenden Datensätzen. Technisch wichtiger ist oft die Frage, ob vorhandene Werte überhaupt verwendbar sind. In OPC UA Part 4 ist der StatusCode genau dafür da: Er beschreibt die Nutzbarkeit des Werts. Ein Wert mit schlechtem Status kann im Export stehen und für die Auswertung dennoch unbrauchbar sein.

Bad, Uncertain und Good sauber trennen

Die Spezifikation verlangt, dass Clients mindestens die Schwere des StatusCode prüfen, bevor sie einen Wert verwenden. Zusätzlich gilt: Wenn der Status einen Fehler anzeigt, ist der Wert zu ignorieren, und der Server soll ihn auf null setzen. Für eine Diagnose heißt das nicht, dass jedes System diese Semantik perfekt umsetzt. Es heißt aber, dass Statusprüfung fachlich vor jeder KPI-Berechnung stehen sollte.

Wenn Ihre Auswertung einen Abschnitt mit Bad- oder Uncertain-Status stillschweigend als Laufzeit übernimmt, bekommen Sie keine Datenlücke im engeren Sinn, sondern eine scheinbar glatte Zeitleiste mit versteckter Unsicherheit. Das ist für operative Berichte gefährlicher, weil der Fehler weniger sichtbar wird. Meine Empfehlung lautet daher: Führen Sie technisch unsichere Abschnitte als eigene QA-Klasse und sperren Sie davon abhängige Kennzahlen bis zur Klärung.

Null-Werte sind Information, kein Leerzeichen

Ein Null-Wert oder ein nuller SourceTimestamp wird im Alltag leicht wie ein fehlendes Feld behandelt. Für die Diagnose ist das zu grob. Ein bewusst gesetzter Null-Wert kann anzeigen, dass der Server keinen bekannten Wert hat oder dass ein Fehlerfall vorliegt. Diese Information gehört nicht in dieselbe Kategorie wie eine optische Lücke in einer Visualisierung, in der Spalten einfach ausgeblendet wurden.

Gerade bei Brownfield-MDE ist diese Unterscheidung nützlich. Die öffentliche Novo-Seite zur Maschinendatenerfassung für Bestandsmaschinen beschreibt Zustandszeiten als Grundlage für Transparenz, trennt aber die Erklärung von Stillstandsgründen ausdrücklich als zusätzliche Aufgabe. Wenn also Grundcodes fehlen, die Zustandszeit aber vorhanden ist, liegt das Problem auf einer anderen Ebene als bei einem technisch ungültigen Zeitabschnitt.

Prüftabelle für Status- und Null-Fälle im Rohdatenexport

Wählen Sie ein Kriterium. Die Optionen stehen direkt nebeneinander.

Beobachtung im Export

Bad oder Uncertain bei vorhandenem Wert

Mögliche Bedeutung

Wert liegt vor, ist aber nicht sicher verwendbar

Empfohlene Behandlung

Als QA-Fall markieren, nicht automatisch als produktive Zeit zählen

Beobachtung im Export

Null bei Fehlerstatus

Mögliche Bedeutung

Fehlersemantik des Datenwerts

Empfohlene Behandlung

Nicht mit Nullproduktion oder Nullstillstand verwechseln

Beobachtung im Export

Null, ServerTimestamp vorhanden

Mögliche Bedeutung

Quellzeit fehlt, Transportzeit ist dennoch sichtbar

Empfohlene Behandlung

Zeitursprung separat klären, Bericht nicht ungeprüft aggregieren

Beobachtung im Export

Leer, aber Zustandswechsel vollständig

Mögliche Bedeutung

Zusatzdaten oder Bedienrückmeldung fehlt

Empfohlene Behandlung

Problem in Ursachebuchung, nicht in der Grundzeitachse

Wenn Sie diese Fälle systematisch trennen, vermeiden Sie die klassische Eskalation: Daten sind falsch, weil im Schichtbericht ein Feld leer blieb. Die bessere Aussage lautet dann zum Beispiel: Zeitachse vorhanden, Quellzeit teilweise unbestimmt, Qualitätsstatus nicht freigegeben, Ursachebuchung unvollständig. Das klingt weniger dramatisch, ist aber für die Behebung technisch wesentlich genauer.

Für die organisatorische Seite lohnt zusätzlich der Blick in den Beitrag Fehlerhafte BDE-Daten in der Produktion. Dort geht es breiter um Governance und Fehlklassifikation. Für den hier behandelten Fall ist der zentrale Nutzen, BDE- und MDE-Anteile nicht zu vermischen: Ein leeres Ursachencode-Feld ist etwas anderes als ein unzuverlässiger Maschinenzeitstempel.

04 / PRAXISWISSEN

Wiederanlauf, Pufferung und Reihenfolge nach Ausfällen

Video mit Maschinenhistorie, Zustandsband und Zyklusmarkierungen als sinnvolle Ergänzung zur Prüfung von Chronologie und Segmentgrenzen.

Wenn MDE-Datenlücken erst nach Verbindungsabbrüchen, Reboots oder Wartungsfenstern sichtbar werden, ist die Zeitsyntax allein nicht mehr genug. Dann müssen Sie prüfen, wie der Datenpfad mit offenen Ereignissen, verspätet eintreffenden Meldungen und der ersten Nachricht nach Wiederanlauf umgeht. Genau an dieser Stelle entstehen sonst Doppelungen, negative Dauern oder künstlich verlängerte Laufzeiten.

Erst die Chronologie rund um den Ausfall isolieren

Ich empfehle, jeden fraglichen Fall in ein enges Zeitfenster zu zerlegen: letzter plausibler Datensatz vor dem Ausfall, sichtbare Lücke, erster Datensatz nach Wiederanlauf, erste stabile Sequenz danach. Erst diese Mikrosicht zeigt, ob ein altes Ereignis sauber geschlossen wurde oder ob der Neustart eine zweite Version derselben Phase erzeugt. Für diese Prüfung brauchen Sie keine besondere Softwarefunktion, sondern einen exportierbaren Verlauf.

Die Quellenlage ist hier bewusst begrenzt. Aus den vorliegenden Standards folgt keine allgemeine Aussage dazu, wie jede konkrete MDE-Lösung puffert oder wieder anläuft. Genau deshalb ist eine lokale Prüfroutine nötig. Der Leitfaden macht also keine Produktbehauptung, sondern übersetzt die vorhandene Zeit- und Qualitätssemantik in einen praxistauglichen Restart-Testfall.

Offene Ereignisse müssen erkennbar geschlossen werden

Ein häufiger Denkfehler ist, die Zeitleiste über eine Kommunikationslücke hinweg einfach fortzuschreiben. Wenn die Maschine während der Unterbrechung in demselben Zustand blieb, ist diese Fortsetzung fachlich denkbar, aber nur dann belastbar, wenn sie als Rekonstruktion kenntlich gemacht wird. Wird sie unmarkiert als sicher gemessene Zeit dargestellt, verschwindet die Unsicherheit aus dem Bericht, obwohl sie technisch vorhanden war.

Für operative Transparenz ist eine sichtbare QA-Zone meistens ehrlicher als eine künstlich glatte Zeitreihe. Genau in diese Richtung argumentiert auch das interne MDE-Abnahmeprotokoll, wenn es erkennbare Datenlücken und eine Gegenprobe über unabhängige Zähler fordert. Im Troubleshooting ist dieselbe Logik hilfreich: Eine markierte Unsicherheit ist prüfbar, eine still kaschierte nicht.

Reihenfolge, Doppelungen und verspätete Meldungen getrennt betrachten

Nach einem Wiederanlauf können drei verschiedene Fehlerbilder auftreten. Erstens kommt ein Segment doppelt vor, weil ein alter Puffer und eine neue Live-Meldung dieselbe Phase abbilden. Zweitens fehlt ein Schließereignis, sodass eine Lauf- oder Stoppdauer künstlich bis zum Neustart weiterwächst. Drittens trifft die Reihenfolge verspätet ein, wodurch negative oder unplausible Dauern entstehen. Diese drei Fälle sehen im Dashboard ähnlich aus, sind aber technisch verschieden.

Prüfen Sie deshalb nicht nur Summen, sondern jede Zustandskante im engen Fenster. Notieren Sie für jedes Segment Startzeit, Endzeit, Status, Erfassungsquelle und die Frage, ob es vor oder nach Wiederanlauf entstanden ist. Erwartetes Ergebnis ist eine lückenlos erklärbare Reihenfolge. Wenn das nicht gelingt, ist ein reiner Schichtbericht keine ausreichende Belegquelle für die Ursachenanalyse.

Bei Brownfield-Lösungen ohne direkten SPS-Zugriff ist diese Trennung besonders wichtig. Die öffentliche Novo-Lösungsseite begründet den Ansatz mit externer Zustandserkennung und empfiehlt ausdrücklich, Erkennung und Datenqualität im Pilot zu prüfen, bevor weitere Anlagen ausgerollt werden. Das ist keine Aussage über Buffering im Einzelfall, wohl aber ein sauberer methodischer Hinweis: Wiederanlauf und Datenqualität gehören in die Abnahme und in die laufende Störanalyse.

Wenn Sie aus dieser Prüfung ein Standardprotokoll machen, sparen Sie sich viele Diskussionen im Eskalationsfall. Der Anbieter bekommt dann nicht nur die Aussage nach einem Reboot stimmt die Schicht nicht, sondern ein reproduzierbares Fehlfenster mit Reihenfolge, erwarteter Schließkante und beobachteter Abweichung. Damit verkürzt sich der Weg zur belastbaren Fehlerursache erheblich.

05 / PRAXISWISSEN

Zähler-Gegenprobe: So entlarven Sie stille Zeit- oder Mengendifferenzen

Selbst eine sauber wirkende Zeitachse beweist noch nicht, dass Produktions- und Stückzahlangaben zueinander passen. Genau deshalb gehört eine Zähler-Gegenprobe in jedes Prüfprotokoll. Sie beantwortet nicht sofort, ob der Zähler oder die Zeitachse richtig ist. Sie zeigt aber, ob beide Sichtweisen in derselben Größenordnung liegen oder ob eine stille Differenz vorliegt, die eine vertiefte Prüfung zwingend macht.

Was die Gegenprobe leisten kann und was nicht

Die Gegenprobe ist kein Ersatz für eine vollwertige Mengenvalidierung. Die Novo-Lösungsseite zur Maschinendatenerfassung für Bestandsmaschinen formuliert diese Grenze offen: Stückzahlen und OEE brauchen zusätzliche Quellen oder validierte Zykluserkennung. Für die Fehlersuche ist das nützlich, weil Sie damit nicht mehr erwarten, dass eine Zustandszeit allein jede Mengendifferenz erklärt.

Als Diagnosemittel ist die Gegenprobe dennoch sehr stark. Wenn ein Zählerdelta und die gemeldete Produktionszeit grob auseinanderlaufen, richten Sie die Suche entweder auf die Zustandsklassifikation oder auf die Zählerquelle. Bleiben beide annähernd plausibel, rückt eher die Grenze zwischen Produktion, Leerlauf, Kurzstopp oder Rüstphase in den Vordergrund. Genau darum geht es: nicht die absolute Wahrheit aus einer Zahl ziehen, sondern den Suchraum verkleinern.

Ein transparentes Beispielszenario mit Annahmen

Das folgende Szenario ist ausdrücklich eine Annahme und kein gemessenes Kundenergebnis. Sie prüfen ein Produktionsfenster von 450 Minuten nach Abzug geplanter Pause. Die Zeitachse weist 330 Minuten Produktion, 45 Minuten Stillstand, 20 Minuten Rüsten und 55 Minuten Datenlücke aus. Damit ist die Bezugszeit formal geschlossen. Offen bleibt aber, ob die 330 Produktionsminuten real oder nur scheinbar plausibel sind.

Im selben Zeitfenster steigt der Maschinenzähler von 1200 auf 1480 Teile. Für die erste Plausibilisierung nehmen Sie vereinfacht an, dass ein stabiles Automatikteil im Mittel einer Minute produktiver Zeit entspricht. Das ergibt 280 produktive Minuten aus dem Zählerdelta. Zwischen Zeitachse und Zähler bleiben also 50 Minuten Differenz. Diese Zahl beweist keinen Softwarefehler, sie fokussiert aber die Suche.

Beispielszenario zur Zähler-Gegenprobe, ausdrücklich mit Annahmen

Wählen Sie ein Kriterium. Die Optionen stehen direkt nebeneinander.

Wert

450 min

Herleitung

Geplantes Produktionsfenster nach Abzug geplanter Pause

Diagnostische Aussage

Gemeinsame Zeitbasis für alle Kategorien

Wert

330 min

Herleitung

Aus MDE-Zustandszeiten

Diagnostische Aussage

Berichtsseitige Produktionssicht

Wert

45 min Stopp, 20 min Rüsten, 55 min Datenlücke

Herleitung

330 + 45 + 20 + 55 = 450

Diagnostische Aussage

Zeitachse ist formal geschlossen

Wert

280 Teile

Herleitung

1480 - 1200

Diagnostische Aussage

Unabhängige Mengensicht

Wert

280 min

Herleitung

Annahme 1 Teil pro Minute

Diagnostische Aussage

Erste Gegenprobe gegen 330 min Produktionszeit

Wert

50 min

Herleitung

330 - 280

Diagnostische Aussage

Suche auf Zustandsklassifikation, Zählerlogik oder Taktannahme fokussieren

Für die Sensitivität genügt schon ein kleiner Schritt. Wenn die reale mittlere Leistung nicht bei 1,0, sondern bei 0,9 Teilen pro Minute liegt, entspräche das Zählerdelta rund 311,11 Minuten. Bei 1,1 Teilen pro Minute läge die gleiche Produktion nur bei 254,55 Minuten. Die verbleibende Differenz zur Zeitachse schwankt dann zwischen 18,89 und 75,45 Minuten. Genau deshalb muss die Taktannahme im Protokoll offen dokumentiert werden.

Das Rechenprinzip lässt sich knapp notieren als Zeitdifferenz = gemeldete Produktionszeit - (Zählerdelta / angenommene Teile_pro_Minute). Relevante Folge: Eine große Differenz ist kein Urteil, sondern ein Wegweiser. Sie kann auf einen Reset oder Rollover im Zähler, auf Mehrfachteile pro Zyklus, auf eine ungeeignete Taktannahme oder auf falsch klassifizierte Produktionszeit verweisen.

Woran Sie Zählerprobleme erkennen können

Wenn die Differenz nur an bestimmten Uhrzeiten oder nach Neustarts auftaucht, prüfen Sie zuerst Reset- oder Rollover-Effekte. Wenn die Differenz dagegen mit bestimmten Produktfamilien auftritt, liegt der Verdacht eher auf einer ungeeigneten Ein-Teil-pro-Zyklus-Annahme oder auf wechselnden Mehrfachausbringungen. Wenn die Zeitachse gleichzeitig viele kurze Laufsegmente ohne entsprechende Stückzahl zeigt, rückt die Zustandsklassifikation in den Vordergrund.

Für Brownfield-Setups ist diese Gegenprobe auch organisatorisch nützlich. Sie verhindert, dass eine Schichtdiskussion nur über Vertrauen geführt wird. Mit derselben Logik können Sie später sauber begrenzen, wofür die Daten bereits freigegeben sind: vielleicht für Zustandszeiten, noch nicht für Mengen; vielleicht für Schichtvergleich, noch nicht für vollständige OEE. Genau diese gestufte Freigabe beschreibt auch das interne MDE-Abnahmeprotokoll.

Wenn Sie den Nutzen einer belastbaren Datenbasis intern erklären müssen, kann die LEIBINGER-Fallstudie als Beispiel dienen, wie sichtbare Maschinen- und Auftragsdaten überhaupt erst wirtschaftlich relevante Verluste erkennbar machen. Für diesen Diagnoseleitfaden ist daran vor allem wichtig: Die betriebliche Wirkung entsteht erst dann, wenn Zeit- und Mengensicht nachvollziehbar zusammenpassen.

06 / PRAXISWISSEN

Schichtwechsel, Auftragsgrenzen und offene Ereignisse

Wenn MDE-Datenlücken nur an bestimmten Uhrzeiten, Pausen oder Übergaben sichtbar werden, ist der Fehlerraum enger als zunächst gedacht. Dann lohnt es sich, nicht die gesamte Linie zu untersuchen, sondern ganz gezielt Grenzereignisse zu sammeln. Eine falsche Schichtzuordnung sieht im Bericht aus wie ein Datenproblem, ist aber fachlich ein Problem des Kalenderschnitts oder der Regel für offene Ereignisse.

Grenzereignisse getrennt sammeln

Ich empfehle fünf feste Testfälle: Ereignis kurz vor Schichtende, direkt nach Schichtbeginn, über eine Pause hinweg, über einen Auftragswechsel hinweg und während eines manuellen Eingriffs ohne Produktionsfreigabe. Für jeden Fall halten Sie fest, wie Rohdaten, Schichtbericht und gegebenenfalls Auftragsbericht denselben Zeitraum darstellen. Erst dadurch sehen Sie, ob eine Lücke wirklich fehlt oder nur anders geschnitten wurde.

Das interne MDE-Abnahmeprotokoll nennt klare Schichtgrenzen ausdrücklich als Freigabekriterium. Für Troubleshooting im Betrieb ist die Aussage noch praktischer: Wenn ein Fehler ausschließlich an Grenzen auftritt, prüfen Sie zuerst Schnitt- und Kalenderlogik statt Sensormontage oder physische Zustandserkennung. Diese Eingrenzung spart Zeit und verhindert unnötige Maßnahmen an der Maschine.

Offene Ereignisse brauchen eine feste Policy

Für die Berichtserstellung müssen Sie entscheiden, wie ein Ereignis behandelt wird, das vor Schichtende beginnt und danach weiterläuft. Eine saubere Policy kann das Segment schneiden, der alten Schicht zuordnen, der neuen Schicht zuordnen oder als geteiltes Ereignis führen. Entscheidend ist nicht, welche Variante Sie wählen, sondern dass Dashboard, Export und Review dieselbe Regel anwenden.

Wenn diese Policy nicht dokumentiert ist, wirkt jede Grenzsituation wie ein technischer Sonderfehler. In Wirklichkeit fehlt dann eine Werkregel. Das gilt ebenso für Auftragsgrenzen. Eine Zustandszeit darf nicht unbemerkt zwei Aufträgen zugeschlagen werden, nur weil Auftragsbuchung und Maschinensignal zeitlich versetzt eintreffen. Bei solchen Fällen hilft kein zusätzlicher Sensor; es hilft nur ein klarer Abgleich der zeitlichen Zuordnungsregeln.

Für die tägliche Arbeit ist daraus eine einfache Empfehlung abzuleiten: Führen Sie Grenzfälle nicht im Sammelbegriff Datenproblem. Trennen Sie in Ihrem Ticket oder Prüfblatt zwischen Zeitmodell, Qualitätsstatus, Wiederanlauf und Kalenderschnitt. Erst dann erkennen Sie, welche Fachrolle zuständig ist: Automatisierung, IT, Produktionssystem oder Schichtorganisation.

07 / PRAXISWISSEN

Dokumentationsvergleich: Was öffentlich beschrieben ist – und was nicht

Dokumentationsvergleich, kein eigener Praxistest: Die folgende Tabelle vergleicht ausschließlich öffentlich gelesene Dokumentation. Novo AI veröffentlicht diesen Vergleich und ist selbst Anbieter; dieser Interessenkonflikt gehört offen benannt. Die verglichenen Quellen haben zudem unterschiedliche Rollen: OPC UA beschreibt Standardsemantik, Beckhoff dokumentiert Zeitquellen und NTP-Verhalten in konkreten Systemen, Novo beschreibt den eigenen Brownfield-Ansatz und die Grenzen der Zustandserfassung.

Genau deshalb geht es hier nicht um Siegerpunkte, sondern um eine nüchterne Frage: Welche öffentlich belegbaren Aussagen helfen Ihnen bei der Diagnose von MDE-Datenlücken, und wo bleibt die Dokumentation bewusst oder faktisch stumm? Fehlende öffentliche Angabe heißt dabei nicht, dass eine Funktion fehlt. Es heißt nur, dass sie in den gelesenen Quellen nicht dokumentiert war.

Dokumentationsvergleich zu Diagnosepunkten für MDE-Datenlücken

Wählen Sie ein Kriterium. Die Optionen stehen direkt nebeneinander.