MDE Abnahmeprotokoll für Bestandsmaschinen

Für OEE-nahe Auswertungen müssen Sie klar unterscheiden, was als längerer Verfügbarkeitsverlust und was als kurzer Leistungsverlust gilt. OEE.com beschreibt diese Logik über die Six Big Losses und weist ausdrücklich darauf hin, dass die Schwelle zwischen Equipment Failure und Minor Stop werkseitig festgelegt werden kann. Ein Beispiel dort ist eine Regel ab zwei Minuten mit Grundzuordnungspflicht.

Für Ihr Abnahmeprotokoll heißt das: Die Schwelle ist keine versteckte Softwareeinstellung, sondern Teil der Freigabe. Schreiben Sie auf, ab welcher Dauer ein Stopp einen Grundcode erhalten muss, wann ein Setup als geplanter Stopp gilt und wie kurze Unterbrechungen ohne Instandhaltungseinsatz behandelt werden. Nur dann können Schichtberichte und OEE-nahe Dashboards dasselbe meinen.

Wichtig ist auch die Trennung zwischen Zustand und Ursache. Ein System kann verlässlich erkennen, dass die Maschine nicht produziert. Daraus folgt noch nicht automatisch, warum sie nicht produziert. Die Novo-Dokumentation formuliert diese Grenze offen: Stillstandsgründe brauchen je nach Setup Bedienerrückmeldungen, Maschinenmeldungen oder weitere Datenquellen. Ein MDE-Abnahmeprotokoll sollte diese Grenze nicht verwischen.

Praktisch können Sie drei Freigabestufen unterscheiden: erstens Zustandserkennung freigegeben, zweitens Zustand plus stabile Stoppschwelle freigegeben, drittens Ursachezuordnung mit zusätzlicher Datenquelle freigegeben. Diese Staffelung ist wesentlich ehrlicher als ein Ja-Nein-Häkchen „Stillstandsanalyse aktiv“, das in Wahrheit mehrere verschiedene Fähigkeitsstufen vermischt.

Bei kontinuierlicher Erfassung reicht es nicht, nur sichtbare Diagrammlücken zu suchen. Sie müssen auch prüfen, ob Reihenfolge, Vollständigkeit und Wiederanlauf nach Kommunikationsunterbrechungen sauber abgebildet werden. MTConnect v2.5 ist dafür eine nützliche Referenz, weil der Standard UTC-Timestamps, monoton steigende Sequenznummern, FIFO-Buffer sowie firstSequence und lastSequence für die Einordnung des Datenbereichs dokumentiert.

Auch wenn Ihr Setup kein MTConnect spricht, können Sie dieselbe Abnahmelogik übernehmen. Stellen Sie die Frage: Wie erkennt das System, dass zwischen zwei Ereignissen Daten fehlen? Gibt es Sequenzen, fortlaufende IDs, markierte Kommunikationslücken oder nur stilles Überschreiben? Ein Datenstrom ohne Lückenkennzeichnung ist für operative Analysen riskant, weil Ausfallzeit und Übertragungsfehler ununterscheidbar werden.

Ein sinnvoller Test ist eine kontrollierte Unterbrechung der Datenübertragung während eines beobachteten Maschinenzustands. Danach prüfen Sie, ob der Wiederanlauf als echte Lücke, als UNAVAILABLE-ähnlicher Zustand oder als nahtlose Fortsetzung erscheint. Die MTConnect-Logik, bei Datenquellenverlust UNAVAILABLE mit Zeitstempel zu setzen, zeigt die Richtung: Ausfälle sollen erkennbar, nicht kaschiert sein.

Pass liegt vor, wenn Sie im Export nachvollziehen können, was während der Unterbrechung passiert ist, und wenn spätere Auswertungen diese Lücke entweder gesondert behandeln oder die betroffene Kennzahl sperren. Fail liegt vor, wenn das System den Ausfall nicht erkennbar macht und daraus scheinbar lückenlose Produktivzeit oder scheinbar exakte Stoppdauer erzeugt.

Der letzte Kernschritt ist die Gegenprobe über Mengen oder Zyklen. Ein Zustandsmodell kann für Stillstandsanalyse sehr gut und für Mengen noch unzureichend sein. Prüfen Sie deshalb, welche Quelle für die Mengenfreigabe führend ist: ein Maschinenzähler, eine bekannte Taktlogik, eine Auftragsrückmeldung oder eine manuelle Referenzstichprobe. Ohne diese Festlegung wird jede OEE-Diskussion unsauber.

Bei Maschinen mit mehreren Teilen pro Zyklus, Nachläufen oder Leerhüben reicht die bloße Zyklenerkennung oft nicht. Sie müssen dokumentieren, wie viele Teile ein freigegebener Zyklus repräsentiert und wie Sonderfälle behandelt werden. Andernfalls entstehen kleine, aber systematische Abweichungen, die sich über Schichten und Wochen zu falschen Leistungsbildern aufaddieren.

Für die Pilotfreigabe ist eine prozentuale Toleranz als Empfehlung sinnvoll, etwa maximal 0,5 % Differenz zwischen MDE-Menge und Referenzzähler. Diese Zahl ist kein Standardwert, sondern ein Beispiel für eine belastbare Freigabelogik. Bei stark variierenden Losen oder bei Mehrfachauswurf kann eine andere Grenze sachgerechter sein, solange sie vorab festgelegt ist.

Die Freigabe sollte außerdem zwischen Mengenanzeige und mengenbasierter KPI-Berechnung unterscheiden. Ein Display kann brauchbare Stückzahlen liefern, obwohl die Datenqualität noch nicht genügt, um Leistung sauber gegen ideale Zykluszeit auszuwerten. Diese Unterscheidung ist im Retrofit wertvoll, weil sie frühe Transparenz ermöglicht, ohne zu früh mathematische Genauigkeit zu behaupten.

Das dritte Fehlerbild entsteht, wenn der Datenstrom nach Ausfall wieder korrekt läuft, die Unterbrechung jedoch im späteren Bericht unsichtbar bleibt. Für das Auge sieht die Kurve dann geschlossen aus, obwohl reale Minuten nicht gemessen wurden. Gerade bei Schichtvergleichen ist das gefährlich, weil Teams Unterschiede diskutieren, die in Wahrheit aus Erfassungsunterbrechungen statt aus Prozessverhalten stammen.

Das vierte Fehlerbild ist die Verwechslung von Zustand und Ursache. Das System erkennt zuverlässig Stillstand, doch die Grundzuordnung bleibt manuell oder indirekt und wird später als automatisch präzise interpretiert. Die Folge sind scheinbar tiefe Ursachenbäume mit unsicherer Basis. Abhilfe schafft nur eine explizite Kennzeichnung, welche Felder gemessen, welche zugeordnet und welche manuell ergänzt wurden.

Wenn Sie diese Fehlerbilder im Kopf behalten, verkürzt sich die Fehlersuche deutlich. Die Frage lautet dann nicht mehr allgemein „Stimmt das System?“, sondern präziser: Stimmt die Uhr, die Erkennung, die Kalenderlogik, die Mengenbasis oder nur die Erzählung über die Ursache nicht? Genau diese Präzision macht ein gutes Abnahmeprotokoll im Alltag wertvoll.