In nahezu allen Fertigungsumgebungen, auch in Halbleiter-Fabs, werden Informationen zwischen den logischen Beteiligten analog dem Prinzip der Automatisierungspyramide nach ISA 95 ausgetauscht. Diese Norm teilt Systeme eines Shopfloors in verschiede Ebenen ein. Ganz unten steht die Sensor-/Feldebene. Darauf baut die SPS(PLC)/Maschinenebene auf. In verschiedenen Branchen unterschiedlich ausprägt ist die darauffolgende SCADA/Leitsystem-Ebene (Supervisory Control and Data Acquisition). MES (Manufacturing Execution System) und ERP (Enterprise Resource Planning) bilden den oberen Teil der Pyramide ab. Das ISA 95 Prinzip besagt, dass eine Ebene zunächst nur direkt mit der darunter bzw. darüberliegenden Ebene kommuniziert. Einfaches Beispiel: Das SCADA System gibt einer Maschine einen Befehl, z. B. für den Start eines Fertigungsprozesses, wirkt aber nicht direkt auf einen Sensor dieser Maschine ein. Dieses Kommunikationsprinzip hat sich bisher bewährt, da es übersichtlich ist und sich damit auch Verantwortung für bestimmte Systeme trennen lässt.
Abbildung 1: Automatisierungspyramide und neue Informationstechnologien
Ebene |
Fragestellung (Auswahl) |
Daten |
| ERP | Für welchen Kunden wurde die Schraube hergestellt. | Auftragsdaten |
| MES | Wann wurde die Schraube hergestellt? In welcher Charge wurde die Schraube hergestellt? |
Chargendaten |
| SCADA | Welche Rohmaterialcharge wurde verwendet? Wie wurde die Maschine bestückt? | Shopfloor Logistik Daten |
| SPS | Welches NC-Programm wurde verwendet? Gab es Störungen während des Drehens/Fräsens? Welches Werkzeug wurde verwendet? |
Maschinendaten |
| Sensor | Wie waren die Leistungsdaten der Achsantriebe der Maschine? | Sensor/Aktor Daten |
Es zeigt sich die Problematik, dass nur die wenigsten Daten entlang des Informationsflusses der Automatisierungspyramide nach oben gemeldet werden. Typischerweise werden Daten aggregiert oder schlicht nicht weiterverarbeitet. Man kann sich in unserem Beispiel überlegen, ob im ERP-System tatsächlich die Ist-Leistungsachsdaten für die Bearbeitung der konkreten Schrauben gespeichert werden. In den meisten Fällen ist dem nicht so.
Um nun Daten aus allen Systemen in allen Schichten der Automatisierungspyramide zu bekommen, bedarf es einer dritten Dimension der Kommunikation, sowie einer Datenplattform, in der alle relevanten Daten homogen gespeichert werden können. Neue Informationstechnologien wie der Digitale Zwilling können sich an der Datenplattform andocken und haben damit Zugriff auf allen Daten der Automatisierungspyramide.
Abbildung 2: Zusätzlicher Datenaustausch mit einer Datenplattform
Aber wie sehen diese neuen Kommunikationskanäle aus?
Auf ERP- und MES-Ebene ist der Zugriff vergleichsweise einfach. Die meisten Applikationen bieten Schnittstellen (Application Programming Interface, API) an, die mit Hilfe entsprechender Dokumentation einfach verwendet werden können. Da die Ausprägung der SCADA-Ebene von Branche zu Branche stark unterschiedlich ist, gibt es dafür keine allgemeine Lösung. Hier muss anwendungsspezifisch eine Lösung gefunden werden. Auf der SPS-Ebene scheint sich der Standard OPC UA (Unified Architecture) zur Kommunikation mit Maschinen durchzusetzen. In der Sensor-/Feldebene gibt es eine große Varianz an anbieterspezifischen Lösungen, so dass es aktuell keine Standards gibt. In einigen Feldbussystemen gibt es die Möglichkeit, Sensordaten direkt über die Feldbuskoppler an dritte Systeme zu übergeben. Vereinzelt implementieren auch Sensorhersteller schon einen weiteren Datenkanal neben der Standardschnittstelle, wie z. B. WiFi in Kombination mit dem MQTT-Protokoll.
Maschinendaten als größte Datenquelle im Shopfloor
Moderne Maschinen sind im allgemeinen heutzutage bereits hochautomatisiert. Dabei wird die komplette Sensorik der Maschine zyklisch gemessen, digitalisierte Signale durch die SPS verarbeitet und in Kontext gesetzt, um die entsprechenden Steuerungsbefehle anschließend an die Aktorik auszugeben. Neben der oft proprietären Datenübertragung zur Mensch-Maschine-Schnittstelle, an der Bediener meist über ein Touchpanel Befehle an die Maschine übergeben können, hat sich OPC UA als offene und standardisierte Schnittstelle in vielen wichtigen Industrien wie z. B. Automotive- oder Pharma-Industrie zum Quasistandard durchgesetzt. Dabei wird standardmäßig zunächst der einfachste Anwendungsfall, nämlich das Bereitstellen von Nutzdaten per OPC UA Direct Access, implementiert. Auf der Maschine befindet sich ein sogenannter OPC UA Server, der Nutzdaten kontinuierlich veröffentlicht. Ein übergeordnetes System kann per OPC UA Client Daten von der Maschine laden und entsprechend weiterverarbeiten. Es werden die Aktual- bzw. Ist-Daten der Maschine übertragen. Da verfügbare Daten auf dem OPC UA Server per Browsing-Funktion live erkundbar sind, werden die Art und der Inhalt oft nur in der maschinenspezifischen Dokumentation beschrieben. Für diesen Anwendungsfall reicht das oft aus.
Soll die Maschine dagegen auch vom übergeordneten System gesteuert werden, so ist ein komplizierteres Kommunikationsszenario erforderlich, da Server und Client miteinander interagieren müssen. Es bietet sich die Implementierung einer State Machine an. Diese besteht aus einer Zustandsvariablen und OPC UA Methoden, durch die die Transition von einem Zustand in den anderen ausgelöst werden können. Der OPC UA Client löst die Methode einer Transition aus. An dieser Stelle können der Methode sogar noch Parameter mitgegeben werden. Die Maschine prüft, ob der Zustandsübergang tatsächlich möglich ist, und setzt entsprechend im Erfolgsfall die Zustandsvariable neu. Im Idealfall wird durch den OPC UA Server ein zusätzliches Event asynchron ausgelöst, welches wiederum dem OPC UA Client mitteilt, dass der neue Zustand tatsächlich erreicht wurde. Abbildung 3 zeigt ein stark vereinfachtes Zustandsmodell einer Maschine mit nur zwei Zuständen. Gängige Anwendungsfälle wie Maschinenzustandsteuerung, Rezeptübergabe, Kommunikation mit im Prozess vor- und nachgelagerten Maschinen oder gesteuertem Werkzeugwechsel erfordern sehr viel komplexere Kommunikationsszenarien. Hier gilt es umfangreiche Dokumentationen zum Informationsmodell zu erstellen. Strebt man eine branchenweite, firmenübergreifende Standardisierung an, so bietet sich die Veröffentlichung des Informationsmodells in sogenannten OPC UA Companion Specifications an, welche dann auch durch die OPC Foundation verwaltet werden.
Abbildung 3: OPC UA State Machine
Jede schriftliche Standardisierung kann falsch interpretiert werden
Jede Kommunikationsschnittstelle muss dokumentiert werden, sei es in projektspezifischen Dokumenten oder allgemein zugänglichen Companion Specifications. Die Dokumentation geschieht in den meisten Fällen in Form von PDF-Dokumenten. Das Problem bei einer jeden Beschreibung in natürlicher Sprache (welche meist mit Tabellen und Diagrammen angereichert wird) ist, dass sie dennoch interpretiert werden muss. Dabei entstehen zwangsläufig Unklarheiten und Fehler. Des Weiteren lässt sich eine realisierte Implementation einer Schnittstelle nicht komplett testen, ohne dass der entsprechende Partner mit seinem Teil der Schnittstelle verfügbar ist. Um diese allgegenwärtige Problematik im Kontext einer OPC UA Kommunikation lösen zu können, wurde eine Software entwickelt, mit der eine Verhaltenssimulation der Schnittstelle erstellt werden kann. Das Verhalten des OPC UA Clients und auch des OPC UA Servers kann für ein Kommunikationsszenario, basierend auf einem Informationsmodell, grafisch modelliert werden. Als Beschreibungssprache wurde das Prinzip PETRI Netz gewählt, da dieses schon stark formalisiert und leicht verständlich ist. Damit können nicht nur der sogenannte „Happy Flow“ in der Kommunikation dargestellt werden, sondern auch diverse Fehlerszenarien. Es entsteht somit je ein Verhaltensmodell für beide Kommunikationspartner. Diese Verhaltensmodelle können nun automatisch in eigenständige Simulationsprogramme kompiliert werden, welche dann als einfache Applikationen zur Verfügung stehen.
Abbildung 4: Verhaltensmodelle in Form von PETRI Netzen (vereinfachte Darstellung)
Diese Simulationsapplikationen können jetzt einfach zwischen den Kommunikationspartnern getauscht werden. Der Besitzer des OPC UA Servers (entspricht dem Maschinenlieferant) bekommt das Simulationsmodell des OPC UA Clients – Genauso umgekehrt. Damit ist jetzt jeder Partner in der Lage einen Teil der Schnittstelle zu entwickeln und ausführlich zu testen. Mit diesem Vorgehen kann nun ein tatsächliches Plug & Play während der Inbetriebnahme der Schnittstelle erfolgen. Kostbare Inbetriebnahme-Zeit im Shopfloor wird gespart und Entwicklungsressourcen können effektiv eingesetzt werden.
Fazit
OPC UA eignet sich hervorragend, um Maschinendaten einer übergeordneten Datenplattform zugänglich zu machen. Des Weiteren ist eine bidirektionale Kommunikation einfach mit State Machines zu realisieren. Beide Vorteile sind Grundlage und Enabler für moderne digitales Services wie Künstliche Intelligenz und Digitale Zwillinge. Um die Schnittstellen-Implementation in ihrer Umsetzung deutlich zu beschleunigen und in ihrer Qualität zu verbessern, wurde eine Software entwickelt, mit der sich um ein bestehendes Informationsmodell ein zusätzliches Verhaltensmodell der beiden Kommunikationsteilnehmer grafisch erstellen lässt. Diese Verhaltensmodelle können in eigenständige Simulatorapplikationen umgewandelt werden und lassen sich dann zwischen den Kommunikationspartnern austauschen. Damit hat jeder Partner die Chance seine eigene Schnittstelle zu 100% zu testen.
_ _ _ _ _
Autor:
Marco Grafe
Solution Specialist for Smart Manufacturing and Digital Transformation | ZEISS Digital Innovation
Marco Grafe arbeitet als „Solution Specialist for Smart Manufacturing and Digital Transformation“ bei ZEISS Digital Innovation und bündelt die Entwicklungsaktivitäten rund um Industrie 4.0. Dabei nutzt er praktische Erfahrungen aus 15 Jahren als Ingenieur im Maschinen- und Anlagenbau, insbesondere in den Branchen Halbleiter, Automotive und Pharma.
_ _ _ _ _
Dieser Beitrag ist exklusiv für die NEXT „Im Fokus: Software“ erschienen.
