Datenerfassung, Produktionsmengen und OEE bei FANUC-CNC-Maschinen: ein Anwendungsszenario
Beim Schichtwechsel ändern sich die Zählerstände an den Maschinen bereits, während die Zahlen im Bericht noch auf der letzten manuellen Erfassung beruhen. Will die Werkstattleitung wissen, welche Produkte heute gefertigt wurden und welche Maschinen gerade laufen, muss sie häufig erst vor Ort nachsehen und anschließend die Aufzeichnungen zusammenführen.
Betrachten wir eine typische Zerspanungswerkstatt mit FANUC-CNC-Maschinen: Wenn die Steuerung die benötigten Daten zugänglich macht, kann das industrielle intelligente Gateway von Woody Betriebszustand, aktuelles Bearbeitungsprogramm und Zählerinformationen erfassen. Eine lokale App auf dem Gateway bereitet diese Rohvariablen anschließend zu Produktionsaufzeichnungen auf, die sich nach Maschine, Produkt und Schicht einsehen lassen.
Für diesen Ansatz müssen weder zuerst alle Maschinensteuerungen vereinheitlicht noch eine Cloud-Plattform aufgebaut werden. Das Gateway übernimmt die Datenerfassung und stellt die Laufzeitbasis für lokale Anwendungen bereit. Die Zuordnung zu Produkten, die Auswertungsregeln und die Dashboard-Seiten müssen weiterhin entsprechend den tatsächlichen Anforderungen der Werkstatt konfiguriert oder entwickelt werden.
Zuerst die Daten aus der Maschine auslesen
Vor der Anbindung prüft der Anlageningenieur das genaue Modell der FANUC-Steuerung, die Kommunikationsschnittstellen, den geeigneten Treiber, die Zugangsbedingungen und die auslesbaren Variablen. Die Unterstützung der FANUC-Datenerfassung bedeutet nicht, dass jede Steuerung dieselben Daten bereitstellt.
Dieses Szenario verwendet eine Ethernet-Anbindung: Die Maschine wird an das lokale Maschinennetz angeschlossen, das Gateway über Ethernet2 mit diesem Netz verbunden. In der Web-Verwaltungsoberfläche des Gateways wird ein Gerät angelegt, der passende Treiber ausgewählt und werden die Kommunikationsparameter sowie die zu erfassenden Variablen konfiguriert. Anschließend wird jede Variable mit der Maschinenanzeige und den tatsächlichen Abläufen abgeglichen.
Für den Einstieg genügen die im Alltag benötigten Daten: der von der Maschine bereitgestellte Betriebszustand, Name oder Nummer des aktuellen Programms, ein Produktionszähler oder Fertigmeldungssignal sowie vorhandene Alarminformationen. Die Bedeutung der Zustandsvariablen muss anhand der tatsächlichen Maschinenlogik bestätigt werden. „Im Automatikmodus“ darf nicht unmittelbar mit „in Bearbeitung“ gleichgesetzt werden. Auch das Erfassungsintervall ist auf die Kommunikationslast der Maschine und die Anforderungen der Anwendung abzustimmen; ein für alle Maschinen gleichermaßen geeignetes Intervall wird nicht zugesichert.
Das Gateway in der Abbildung wird durch die gemeinsame Darstellung der WD2E-Serie veranschaulicht. Das tatsächliche Modell, die Schnittstellen und die Anschlussbedingungen sind nach den Gegebenheiten vor Ort auszuwählen. In diesem Szenario werden ausschließlich Maschinendaten gelesen; Fernstart und Fernstopp, das Schreiben von Parametern und das Herunterladen von Bearbeitungsprogrammen sind nicht Bestandteil des Szenarios.
Vom Maschinenzähler zur Produktionsmenge je Produkt
Ein einzelner Zählerstand beantwortet noch nicht die Frage: „Welche Produkte wurden heute gefertigt?“ Auch ein Programmname ist noch kein fertiger Produktdatensatz. Die Zuordnung zwischen Programm und Produkt muss gepflegt werden.
Die Prozessverantwortlichen können über die Geschäftsformulare der lokalen App eine Produkttabelle pflegen und Namen von Bearbeitungsprogrammen mit Produktinformationen verknüpfen. Sobald das Gateway das aktuelle Programm und den Zählerstand oder das Fertigmeldungssignal erfasst hat, ermittelt die Anwendung das Produkt nach den vereinbarten Regeln. Sie erzeugt Produktionsaufzeichnungen mit Maschine, Produkt und Zeitangaben und speichert sie in der integrierten SQLite-Datenbank.
Entscheidend ist dabei nicht die Anzahl der Tabellenfelder, sondern ob die Zähl- und Auswertungsregeln zum tatsächlichen Bearbeitungsprozess passen:
- Bearbeitungszyklen und Produktionsmenge müssen unterschieden werden. Ein Bearbeitungszyklus kann mehrere Werkstücke umfassen, aber auch eine Probebearbeitung oder ein Leerlauf sein. Er darf ohne vorherige Klärung nicht als Anzahl von Gutteilen gezählt werden.
- Bei einem Programmwechsel muss die Zuordnung der Aufzeichnungen eindeutig sein. Dafür sind die zeitliche Abfolge des Programmwechsels und die Zähleränderungen gemeinsam zu betrachten. Aufzeichnungen mit unklarer Zuordnung sind zur Prüfung zu kennzeichnen; es reicht nicht, ihnen einfach den zuletzt erfassten Programmnamen zuzuweisen.
- Zählerrücksetzungen und Erfassungslücken müssen berücksichtigt werden. Das Zurücksetzen durch den Bediener, ein Maschinenneustart oder eine Kommunikationsunterbrechung können die Aufzeichnungen beeinflussen. Änderungen eines kumulierten Zählerstands dürfen nicht ungeprüft als neu produzierte Menge gelten.
- Tages- und Schichtgrenzen müssen einheitlich definiert sein. Die Zuordnung einer Schicht über Mitternacht und die Frage, ob Probebearbeitungen mitgezählt werden, sind zuerst von Produktion und Prozessverantwortlichen festzulegen und anschließend in die Anwendungsregeln zu übernehmen.
Nach Klärung dieser Bedingungen kann die lokale App die Aufzeichnungen nach Datum, Maschine oder Produkt zusammenfassen und Dashboards, Berichte und Trendkurven innerhalb der Web-Verwaltungsoberfläche des Gateways anzeigen. Lua übernimmt die Backend-Verarbeitung und Geschäftslogik; JS/CSS/HTML dienen der Gestaltung der Frontend-Seiten. Das Gateway stellt das Framework bereit. Die konkrete Anwendung muss konfiguriert oder entwickelt werden, und die Auswertungsergebnisse sind zu prüfen.
OEE lässt sich nicht allein aus einem Betriebssignal berechnen
Auf Basis der Produktionsaufzeichnungen kann auch OEE, die Gesamtanlageneffektivität, betrachtet werden. Sie verbindet Verfügbarkeit, Leistung und Qualität und hilft der Werkstatt, die Nutzung ihrer Maschinen aus unterschiedlichen Perspektiven zu beurteilen.
OEE = Verfügbarkeit × Leistung × Qualität
| Kennzahl | Berechnungsgrundlage | Benötigte Daten |
|---|---|---|
| Verfügbarkeit | Laufzeit ÷ geplante Produktionszeit | Bestätigter Betriebszustand, Zustandsaufzeichnungen und geplante Produktionszeit |
| Leistung | Ideale Bearbeitungszeit je Stück × Gesamtstückzahl ÷ Laufzeit | Ideale Bearbeitungszeit je Stück für jedes Produkt sowie Gesamtstückzahl und Laufzeit nach den vereinbarten Regeln |
| Qualität | Gutstückzahl ÷ Gesamtstückzahl | Gutstückzahl und Gesamtstückzahl für denselben Auswertungsumfang |
Der Maschinenzustand kann als Grundlage für die Ermittlung der Laufzeit dienen. Die geplante Produktionszeit, Stillstandskategorien und die ideale Bearbeitungszeit je Stück müssen jedoch von Produktion und Prozessverantwortlichen definiert werden. In diesem Szenario wird empfohlen, die OEE je Produkt und für den zugehörigen Auswertungszeitraum getrennt anzuzeigen. Eine einzige Bearbeitungszeit darf nicht auf alle Produkte angewendet werden; ebenso dürfen die OEE-Werte einzelner Produkte nicht direkt addiert oder zu einem einfachen Durchschnitt für die gesamte Schicht zusammengefasst werden. Ist die geplante Produktionszeit, die Laufzeit oder die Gesamtstückzahl null, sind die jeweiligen Quotienten als nicht anwendbar zu kennzeichnen. Bei unvollständigen Daten ist eine Prüfung erforderlich; das Ergebnis darf nicht als gültige OEE angezeigt werden.
Auch Qualitätsdaten benötigen eine unabhängige Quelle. Ein Bearbeitungszähler belegt nicht, dass ein Werkstück die Qualitätsanforderungen erfüllt. Qualitätsdaten können über Formulare der lokalen App eingegeben oder, sofern die Schnittstellenbedingungen dies zulassen, aus einem Prüfsystem übernommen werden. Ohne verlässliche Qualitätsdaten sollten zunächst Laufzeit und Produktionsmenge angezeigt werden. Die Qualität darf nicht standardmäßig auf den Höchstwert gesetzt werden; Schätzwerte dürfen nicht als gemessene OEE ausgewiesen werden.
Sind die Daten vollständig und die Berechnungsregeln eindeutig, kann die Logik zur OEE-Berechnung und -Anzeige in der lokalen App entwickelt werden. Es handelt sich nicht um einen automatisch vom Gateway erzeugten Standardbericht. Ebenso lässt sich aus einer einzelnen OEE-Zahl nicht die Ursache eines Stillstands ableiten. Für die Ursachenanalyse werden zusätzlich Rückmeldungen vor Ort, Alarmaufzeichnungen oder ein gesondert gestalteter Ablauf zur Erfassung von Stillstandsursachen benötigt.
Beim Schichtwechsel zuerst die Aufzeichnungen ansehen, dann vor Ort prüfen
Nach Fertigstellung der Anwendung kann die Werkstattleitung im eingebetteten Dashboard des Gateways zunächst den aktuellen Zustand, Produktinformationen und Schichtaufzeichnungen einsehen und anschließend Auffälligkeiten vor Ort überprüfen. Die Prozessverantwortlichen pflegen die Produktzuordnungen, während die Produktion Zusammenfassungen nach denselben Regeln nutzt, statt mit getrennten, zu unterschiedlichen Zeiten abgeschriebenen Zahlen zu arbeiten.
Die Seiten sollten den Zeitpunkt der letzten Aktualisierung anzeigen und Kommunikationsunterbrechungen, veraltete Daten und tatsächliche Stillstände unterscheiden. Diese Hinweise und die Regeln zur Behandlung von Abweichungen müssen in der Anwendung umgesetzt werden. Zeigt eine Maschine einen Stillstand an, weiß das System dadurch noch nicht, ob Material fehlt, ein Werkzeug gewechselt wird oder eine Störung vorliegt. Dazu sind weiterhin entsprechende Informationen aus der Werkstatt nötig.
Lokale Verarbeitung, Speicherung und Anzeige benötigen weder eine Cloud-Plattform noch einen zusätzlichen Anwendungsserver. Soll später eine zentrale Übersicht über mehrere Werkstätten oder Werke entstehen, lassen sich die Datenveröffentlichung über MQTT, HTTP/HTTPS und die Integration mit einer empfangenden Plattform gesondert konfigurieren. Datenempfang, Authentifizierung, Feldzuordnung und die Bedienoberfläche für die Geschäftsprozesse müssen weiterhin separat umgesetzt werden. Sie stehen nicht automatisch zur Verfügung, nur weil eine Netzwerkverbindung besteht.
Vor der Anbindung zu klären
- Genaues CNC-Modell, Treiberkompatibilität, Kommunikationsschnittstellen, Zugriffsrechte und verfügbare Variablen prüfen und jede Variable mit den Anzeigen vor Ort abgleichen.
- Die Zuordnung zwischen Programm und Produkt, die Bedeutung von Zähler- oder Fertigmeldungssignalen, die Zuordnung bei Produktwechseln sowie die Behandlung von Aufzeichnungen nach Zählerrücksetzungen und Kommunikationsunterbrechungen festlegen.
- Schichten, geplante Produktionszeit, Definition des Betriebszustands und ideale Bearbeitungszeit je Stück für jedes Produkt vereinbaren und eine unabhängige Quelle für Qualitätsdaten bereitstellen.
- Formulare, Auswertungslogik, Seiten und Hinweise auf Abweichungen der App planen sowie Verantwortlichkeiten für Entwicklung und Pflege festlegen. Die Fähigkeiten des Frameworks sind keine vorinstallierte Geschäftsanwendung.
- Aufbewahrungsdauer, Sicherungen und Zugriffsrechte anhand der verfügbaren Speicherressourcen und der Aufzeichnungsfrequenz planen. Eine unbegrenzte Speicherung oder lückenlose Aufzeichnung wird nicht zugesichert.
Eine Zerspanungswerkstatt, die zunächst ihre aktuelle Produktion besser verstehen möchte, kann mit Zustands- und Mengenaufzeichnungen einer einzelnen Maschine beginnen. Nach Prüfung der Datenerfassung und der Auswertungsregeln können Produktzuordnung, Schichtzusammenfassungen und OEE hinzukommen. Das Gateway macht Maschinendaten nutzbar, die lokale App strukturiert sie nach den Regeln der Werkstatt, und Produktion sowie Prozessverantwortliche erläutern, was diese Zahlen tatsächlich bedeuten.