Maschinendaten ohne Kontext sind nur Rauschen: Stillstandsgründe, Zustandsmodelle und Datenqualität
DBR77 Team · Veröffentlicht am
Maschinendaten werden nützlich, wenn jedes Signal in einen Zustand übersetzt wird, auf den sich alle geeinigt haben, und wenn jeder Stillstand einen Grund trägt. Ohne Maschinenzustandsmodell und Stillstandsgründe kann ein Signal „steht" nicht sagen, ob die Linie auf Material gewartet hat, umgerüstet wurde oder ausgefallen ist.
Warum ein Rohsignal noch keine Information ist
Ein SPS-Bit oder ein Stromsensor sagt Ihnen nur, ob die Maschine taktet. Eine geplante Reinigung, ein Stau und ein leerer Zulauf sehen in den Rohdaten identisch aus.
Ohne Kontext ist der größte Balken im Stillstands-Pareto „unbekannt", und damit kann niemand etwas anfangen.
An einer Linie für Wellpappverpackungen brachte die Erfassung des Grundes in zwei Sekunden im Moment des Stillstands „unbekannt" aus dem Pareto und half zusammen mit dem Live-Maschinenstatus und Alarmen mit klaren Verantwortlichen, die durchschnittliche Reaktionszeit auf einen Stillstand von 24 auf 9 Minuten zu senken.
Ein einfaches Maschinenzustandsmodell
Ein Zustandsmodell ist eine kurze, feste Liste von Zuständen, in denen sich jede Maschine befinden kann, mit genau einer Definition pro Zustand. Industriestandards gehen weiter: Das PackML-Modell der OMAC, von der ISA als TR88.00.02 übernommen, gibt Maschinen herstellerübergreifend einheitliche Zustände. Für das Monitoring einer Brownfield-Linie reichen meist sieben Zustände.
| Zustand | Definition | Wie er erkannt wird | Zählt gegen die OEE? |
|---|---|---|---|
| Produktion | Produziert mit oder nahe der idealen Taktrate | Takt- oder Zählsignal steigt | Nein, aber langsame Takte sind ein Leistungsverlust |
| Leerlauf (Kurzstillstand) | Kurzer Stopp, vom Bediener behoben | Kein Takt länger als einige Taktzeiten, unterhalb der Schwelle für eine Grunderfassung | Ja, Leistung |
| Ungeplanter Stillstand | Ausfall, Stau oder Störung oberhalb der Schwelle | Kein Takt über die Schwelle hinaus, kein geplantes Ereignis aktiv | Ja, Verfügbarkeit |
| Umrüsten | Wechsel auf das nächste Produkt oder Format | Bediener startet es am Tablet oder der Auftrag wechselt | Ja, Verfügbarkeit |
| Geplanter Stillstand | Reinigung, geplante Instandhaltung, Inspektion in der geplanten Zeit | Vom Bediener aus geplanten Gründen gewählt oder aus dem Plan | Ja, Verfügbarkeit |
| Materialmangel / Rückstau | Maschine bereit, aber kein Material von vorne oder kein Platz dahinter | Puffersensoren oder SPS-Flags, oder gewählter Grund | Ja, Verfügbarkeit, als externe Ursache markiert |
| Nicht geplant | Keine Produktion vorgesehen: Pausen, keine Schicht, keine Aufträge | Schichtkalender | Nein, aus der geplanten Produktionszeit herausgerechnet |
Die OEE-Spalte folgt den Definitionen von Vorne: Die geplante Produktionszeit schließt nur Zeit aus, in der keine Produktion beabsichtigt ist, und die sechs großen Verluste zählen Rüstzeiten als Verfügbarkeitsverlust und Kurzstillstände als Leistungsverlust. Manche Werke klammern die geplante Instandhaltung aus, und beides funktioniert, wenn es überall gleich angewendet wird.
Wie Sie Stillstandsgründe gestalten, die Bediener auch nutzen
Der Zustand zeigt, dass die Maschine steht, und der Grund sagt, warum. Eine gute Liste von Gründen ist kurz genug für zwei Sekunden und konkret genug, um daraus zu handeln.
- 10 bis 15 Gründe pro Maschinentyp. Längere Listen enden bei „Sonstiges". Eine Presse und ein Palettierer brauchen unterschiedliche Listen.
- Die Sprache der Bediener. Verwenden Sie Begriffe wie „Folienriss" und „Leimdüse verstopft"; aus dem ERP kopierte Kostenstellencodes funktionieren an der Maschine nicht.
- Höchstens zwei Ebenen. Eine Kategorie (Mechanik, Material, Qualität, Organisation) und ein konkreter Grund.
- Eine klare Schwelle. Vorne nennt eine Beispielregel: Jeder Stillstand über zwei Minuten bekommt einen Grund. Kürzere Stopps zählen als Kurzstillstände.
- Erfassung beim Stillstand. Der Bediener wählt den Grund am Tablet direkt an der Maschine, solange die Ursache noch offensichtlich ist. Dafür ist die Bediener-App gebaut.
Prüfen Sie die Liste monatlich. Steigt „Sonstiges" über einige Prozent der Stillstandszeit, sagen Ihnen die Bediener damit, dass ein Grund fehlt.
Zustände und Gründe an einer laufenden Linie sehen
In einer 30-minütigen Online-Demo zeigen wir, wie DBR77 IIoT Maschinensignale in Zustände übersetzt, Gründe direkt beim Stillstand erfasst und ein Pareto erstellt, mit dem Sie arbeiten können.
Einheitliche Definitionen über alle Schichten
Daten verlieren am schnellsten an Wert, wenn Schichten für dasselbe Ereignis unterschiedliche Begriffe verwenden. Die Nachtschicht bucht einen Stau als „Mechanik", die Frühschicht als „Material". Nach einem Monat erscheint ein großes Problem im Pareto als zwei halb so große.
Schreiben Sie das Zustandsmodell und die Liste der Gründe auf, mit einem Satz Definition pro Eintrag. Schulen Sie jede Schicht auf dieselbe Version. Ändern Sie Definitionen nur zu einem festen Stichtag und dokumentieren Sie die Änderung, damit Trends vorher und nachher vergleichbar bleiben.
Dasselbe gilt auf Werksebene. Ein Ziel von ISA-95 ist eine gemeinsame Terminologie für Produktions- und Geschäftssysteme. Für ein einzelnes Werk heißt das praktisch: ein Wörterbuch, das jede Schicht und jedes System verwendet. Die Seite Module zeigt, wie Zustände, Gründe und Alarme in DBR77 IIoT zusammenspielen.
Prüfungen der Datenqualität vor dem Skalieren
Bevor Sie die Konfiguration einer Linie auf die nächsten fünf Linien kopieren, prüfen Sie, ob die Daten stimmen. Fehler, die an einer Linie klein sind, vervielfachen sich im ganzen Werk.
- Fehlende Zustände. Addieren Sie alle Zustände pro Schicht. Decken sie nicht die volle Schichtzeit ab, fällt ein Signal aus oder ein Zustand ist nicht definiert.
- Falsche ideale Taktzeiten. Vorne weist darauf hin, dass eine Leistung über 100 % meist bedeutet, dass die ideale Taktzeit zu hoch angesetzt ist. Prüfen Sie jedes Produkt, nicht nur das Hauptprodukt.
- Abweichende Uhrzeiten. Wenn Edge-Geräte, SPS und Server unterschiedliche Uhrzeiten haben, landen Stillstände in der falschen Schicht und die Reaktionszeiten stimmen nicht. Synchronisieren Sie die Uhren, zum Beispiel mit NTP.
- „Unbekannt" und „Sonstiges". Verfolgen Sie deren Anteil an der Stillstandszeit wöchentlich. Ein steigender Anteil heißt, dass eine Liste oder eine Gewohnheit korrigiert werden muss.
Welche Signale Sie überhaupt erfassen sollten, lesen Sie unter welche Daten Sie von Maschinen erfassen sollten.
Wo sich Kontext auszahlt
Mit sauberen Zuständen und Gründen kann man der Live-OEE vertrauen, weil sie aus vereinbarten Ereignissen berechnet wird, und eine Schichtübergabe lässt sich direkt aus den Daten aufbauen.
Für manuelle Arbeitsplätze ganz ohne Maschinensignal kann eine Kamera den Zustand liefern. Die Vision-AI-Ebene von IRIS erkennt Takte und Anwesenheit, ohne in die Maschine einzugreifen.
Häufige Fragen
Was ist ein Maschinenzustandsmodell?
Eine feste Liste von Zuständen, in denen sich eine Maschine befinden kann, etwa Produktion, Leerlauf, ungeplanter Stillstand und Umrüsten, jeweils mit einer Definition und einer Erkennungsregel. Es macht aus Rohsignalen Ereignisse, die sich über Maschinen und Schichten hinweg vergleichen lassen.
Wie viele Stillstandsgründe sollte eine Maschine haben?
In der Regel 10 bis 15 pro Maschinentyp, in der Sprache der Bediener. Längere Listen drängen die Leute zu „Sonstiges". Prüfen Sie die Liste monatlich und ergänzen Sie einen Grund nur, wenn eine echte Lücke auftaucht.
Zählen geplante Stillstände gegen die OEE?
Nach der Definition von Vorne ja. Nur Zeit ohne Produktionsabsicht, etwa Pausen, wird aus der geplanten Produktionszeit herausgerechnet. Umrüsten, Reinigung und geplante Instandhaltung senken trotzdem die Verfügbarkeit.
Was sollten wir prüfen, bevor wir auf weitere Linien skalieren?
Prüfen Sie, ob die Zustände die volle Schichtzeit abdecken, ob die idealen Taktzeiten für jedes Produkt stimmen, ob alle Uhren synchronisiert sind und ob „unbekannt" nur einen kleinen Anteil der Stillstandszeit ausmacht.
Fazit
Ein praktischer erster Schritt ist die Prüfung auf fehlende Zustände an einer Linie: Addieren Sie die Zustände einer Schicht und prüfen Sie, ob sie die volle Schichtzeit abdecken. Sehen Sie sich dann an, wie viel Stillstandszeit unter „unbekannt" und „Sonstiges" läuft. Diese beiden Zahlen zeigen, ob das Zustandsmodell oder die Liste der Gründe nachgebessert werden muss, bevor Sie die Konfiguration auf die nächste Linie kopieren.
Machen Sie aus Ihren Maschinensignalen Entscheidungen
Buchen Sie eine 30-minütige Demo und sehen Sie Zustandsmodell, Grunderfassung und Live-Pareto in DBR77 IIoT, und wie sie zu Ihren Linien passen würden.
Quellen
- Vorne, The Six Big Losses, 2026
- Vorne, Calculating OEE, 2026
- OMAC, PackML, 2026
- ISA, ISA-95 standard, 2026
- IETF, RFC 5905: Network Time Protocol Version 4, 2010
- DBR77-IoT-Pilotdaten, Linie für Wellpappverpackungen (Kunde anonym), 2026