Verpackungsmaschinen

Wie läuft die Umsetzung von PackML und OPC UA in Verpackungsmaschinen ab?

Wir implementieren PackML-Zustandsmodelle und OPC-UA-Schnittstellen in Verpackungsmaschinen.

Unsere Kunden sind Maschinenbauer und Linienintegratoren. Maschine, Marke und Endkunde bleiben bei Ihnen; wir übernehmen die Teile, die Spezialwissen verlangen:

• Zustands- und Betriebsartenmodelle nach PackML über OPC UA, einheitlich auf allen Maschinen einer Linie umgesetzt
• Schnittstellen von der Maschine zum Manufacturing Execution System (MES), einschließlich Informationsmodellen nach Companion Specifications
• die darunterliegende Gateway- und Sensorebene, die viele einzelne Datenströme in einem festen Zyklus zusammenführt
• eigene Netzwerkknoten und Gateways, einschließlich Inbetriebnahme der Baugruppe und Portierung des Netzwerk-Stacks
• Migration von CANopen oder einem älteren Feldbus auf Echtzeit-Ethernet, bei der das Verhalten der Maschine erhalten bleibt
• Schulung Ihrer Ingenieure in PackML, OPC UA oder dem Netzwerk-Stack, die erste Implementierung gemeinsam mit ihnen und danach Third-Level-Support hinter ihrem First Level

Die Installation und Inbetriebnahme kompletter Linien vor Ort übernehmen wir nicht. Bei Integration und Test arbeitet unser Team vor Ort mit Ihren Ingenieuren, sonst remote. Wie wir zusammenarbeiten und abrechnen, steht auf der Seite zur Zusammenarbeit.

Warum reicht eine bessere OEE-Auswertung ohne einheitliches Zustandsmodell nicht aus?

Ohne gemeinsames Zustandsmodell summieren sich die Unterschiede über die ganze Linie, und keine Auswertung gleicht uneinheitliche Quelldaten aus.

Drei Hersteller bedeuten drei Vorstellungen davon, was „läuft“ heißt, während ein Werk meist eine einzige OEE-Zahl haben möchte. Jeder Bericht oberhalb der Linie muss dann rekonstruieren, was passiert ist, statt die Protokolle einfach zu lesen, und Rekonstruktionen gehen gerade in kritischen Fällen schief, etwa wenn zwei Maschinen in derselben Sekunde den Zustand wechseln. Ein gemeinsames Zustandsmodell löst das ohne immer aufwendigere Auswertungen, und es ist gezielte Entwicklungsarbeit, die ein Maschinenprogramm alle paar Jahre einmal braucht. Für die Ebene darunter gilt dasselbe: ein Gateway, das mehrere tausend Datenpunkte in einem festen Zyklus von 2 ms erfassen und bereitstellen muss, oder die Migration weg von einem Feldbus, auf dem die Maschine seit zehn Jahren läuft.

Welche Aufgaben übernehmen Sie bei der Maschinenintegration?

Jede einzelne Ebene der Maschine: das Zustandsmodell, die MES-Schnittstelle, das E/A-Gateway, das Netz.

• Eine Maschine mit PackML. Das Zustands- und Betriebsartenmodell wird über der vorhandenen Steuerungslogik umgesetzt, und die Ablauflogik bleibt, wie sie ist.
• Mehrere Hersteller, eine Linie. Dasselbe Modell auf Maschinen, die nie gemeinsam spezifiziert wurden, damit die Linie als Ganzes meldet.
• Eine Schnittstelle von der Maschine zum MES. Informationsmodellierung mit OPC UA und Companion Specifications, auf der Maschinen- oder der Integrationsseite.
• Mehr Sensoren, als die Steuerung verkraftet. Viele einzelne Datenströme werden an einem Gateway zusammengeführt und in einem festen Zyklus veröffentlicht.
• Ein Gerät, das es noch nicht gibt. Ein eigener Netzwerkknoten oder ein eigenes Gateway, entwickelt ab der Inbetriebnahme der Baugruppe.
• Ein Feldbus, der abgelöst werden muss. CANopen oder ein älterer Feldbus wird auf Echtzeit-Ethernet umgestellt, und das Verhalten der Maschine bleibt erhalten.
• Ihr Team einarbeiten. Erst die Schulung, dann die erste Implementierung gemeinsam mit Ihrem Team.

Wie hilft ein gemeinsames Zustandsmodell bei der Störungsanalyse?

Ein Stillstand wird in dem Moment zugeordnet, in dem er entsteht.

Wenn jede Maschine dieselben Zustände und Betriebsarten zeigt (in der Abbildung im ersten Abschnitt dargestellt), meldet die Linie, welche Maschine zuerst den Zustand gewechselt hat und warum. Ein Bediener muss das nicht nachträglich rekonstruieren. Auch die Logik auf Linienebene wird einfacher, weil Materialmangel und Rückstau zu lesbaren Maschinenzuständen werden und keine Heuristiken auf Basis von Sensor-Timing mehr brauchen.

Wie lassen sich viele Sensordaten deterministisch erfassen?

Wir führen die Sensordatenströme am Gateway zusammen und veröffentlichen sie in einem festen Zyklus.

Die Last bestimmt heute die Zahl der Sensordatenströme, nicht der Regelkreis. Viele serielle und I²C-Datenströme werden am Gerät erfasst, dort mit Zeitstempel versehen und in einem festen Zyklus weitergegeben, sodass die Steuerung in jedem Zyklus genau eine begrenzte, vorhersehbare Eingabe sieht. Mit dieser Struktur hat eine ausgelieferte Maschine einen Zyklus von 2 ms über mehrere tausend Datenpunkte gehalten, und die Zusammenführung wurde nicht zum Engpass.

Wie sieht ein eigener Netzwerkknoten auf dieser Ebene aus?

Ein eigener Knoten wird für seinen Zweck gebaut und ist meist eines von zwei Dingen: ein Geräteknoten oder ein Gateway.

Ein Beispiel: Unser Team hat beides für einen Hersteller von Verpackungsmaschinen gebaut, oft in derselben Halle im Einsatz, aber mit unterschiedlichen Aufgaben:

• Ein Echtzeit-Ethernet-Knoten mit Anbindung an UART und I²C für die Steuerung von Sensoren und Aktoren in einem Zyklus von 2 ms, geliefert als Migration von CANopen. Die Ablauflogik der Maschine blieb erhalten, angepasst wurde die Netzwerkanbindung.
• Ein Gateway, das in einem Netz Slave und in einer Unterebene darunter Master ist, eingesetzt für Förder- und Bewegungssteuerung. Es ist auf der Seite zur Fördertechnik beschrieben, weil die Fördersteuerung sein Haupteinsatz ist.

Beides ist Produktentwicklung für den Maschinenbauer. Seine Maschinen und seine Kunden bleiben seine; wir entwickeln den Knoten für seine Maschinen.

Wie lassen sich neue Formate mit wenig Entwicklungsaufwand einführen?

Die Kosten eines Formatwechsels entscheiden sich im Entwurf, lange bevor das Format wechselt.

Sie hängen davon ab, wie Formatparameter und Zustandsbehandlung der Maschine ursprünglich strukturiert wurden. Wir halten formatabhängige Werte als Parameter gegen ein festes Zustandsmodell, sodass ein neuer Artikel eine Datenänderung mit Validierung ist und keine neue Ablauflogik. Weil die Zustände standardisiert sind, kann das MES den Formatwechsel dann steuern und protokollieren, statt ihm nur zuzusehen.

Welche Zustände und Übergänge definiert PackML?

PackML legt standardisierte Zustände und Betriebsarten fest und dazu die zulässigen Übergänge zwischen den Zuständen.

Zu den Zuständen gehören Idle, Starting, Execute, Holding, Suspending, Stopping, Aborting, Completing, Resetting und Clearing, und ihr Wert liegt darin, dass sie auf jeder Maschine, die sie umsetzt, dasselbe bedeuten. „Holding“ an der Füllmaschine und „Holding“ am Packer beschreiben denselben Zustand, sodass eine Liniensteuerung und ein MES mit beiden arbeiten können, und das ohne eigene Übersetzungstabelle je Lieferant. Die Übergänge sind so wichtig wie die Namen. Weil die zulässigen Übergänge festgelegt sind, lässt sich eine Linie über Zustände verriegeln statt über individuelle Signale, und eine Maschine, die später in die Linie kommt, übernimmt denselben Vertrag und braucht dafür keine eigene Ablauflogik.