Industrie 4.0
Die Migration im Engineering
Eine Industrie 4.0 setzt die Konvergenz von IT und OT voraus. Wie kann ein Migrationsweg von heutigen Technologien hin zu einer Industrie 4.0 diese Konvergenz unterstützen, ohne dabei wichtige Brücken in die Vergangenheit einzureißen?
Der Hype um Industrie 4.0 hat in den letzten Jahren große Resonanz gefunden. Um allerdings diese Vision in die Tat umzusetzen, muss neben der Definition neuer Systeme und Technologien auch ein Migrationspfad für bestehende Systemintegratoren und deren Produkte gefunden werden. Migration und die Konvergenz von IT und OT ist dabei eine große Herausforderung der anstehenden digitalen Revolution. Zwischen den beiden Technologiewelten müssen solide Brücken gebaut werden.
Kommunikation: Die Grundvoraussetzung
Die angestrebte Konvergenz bedingt eine transparente Kommunikations-Infrastruktur, vorzugsweise bis in die Sensorebene. Die OPC Unified Architecture – OPC UA – bietet eine solche Basis. OPC gewährleistet eine universelle, offene, hardware- und softwareunabhängige, sichere und zuverlässige Netzwerk-Kommunikation. Sprich: die Überwachung von konfigurierbaren Timeouts und Verbindungsunterbrechungen sowie eine verschlüsselte Kommunikation. Dazu verwendet es eine skalierbare Client/Server-Architektur, bei der der Client die Datenanfrage initiiert und der Server antwortet und liefert, möglicherweise über einen sicheren Kanal und out of the box. Diese Eigenschaften waren auch die Entscheidungsgrundlage für PLCopen, die OPC-UA-Technologie zur Harmonisierung der Kommunikation in der industriellen Steuerung einzusetzen – und zwar in Zusammenarbeit mit der OPC Foundation (Bild 1).
Kurz gesagt definiert OPC UA das ‚Wie‘ der Kommunikation und PLCopen das ‚Was‘. Und um das ‚Was‘ zu harmonisieren, braucht man definierte und implementierte Profile.
Die Essenz von Profilen
Wenn heute ein PLCopen/IEC-61131-3- Steuerungsprogramm oder -projekt auf Steuerungsplattformen unterschiedlicher Hersteller geladen wird, lässt sich mit diesen Steuerungen über OPC UA kommunizieren und auf die entsprechenden Variablen zugreifen. Die Darstellung im Namensraum der OPC-UA-Server ist jedoch für jede Plattform unterschiedlich: Für jede Steuerung muss jeweils ein Visualisierungsprogramm angepasst werden, obwohl der Steuercode identisch ist.
Die Kunden erwarten heute, dass auf ein Steuerungsprojekt in gleicher Weise über OPC UA zugegriffen wird. Hier setzt die Definition von PLCopen OPC UA an. PLCopen hat dafür gesorgt, dass das gesamte IEC-61131-3-Softwaremodell und der Inhalt der Steuerungsprogramme in den OPC-UA-Namensraum abgebildet werden. Dieser Namensraum kann von einem OPC-UA-Server bereitgestellt werden, der in eine eingebettete Steuerung integriert ist, auch während der Laufzeit. Zudem würde dies mit der Harmonisierung in den Namenskonventionen für die verschiedenen OPC-UA-Clients – also für die verschiedenen Systeme wie HMI oder ERP – gleich aussehen. In diesem Sinne definierte PLCopen die Zugänglichkeit zu den Steuerungsvariablen – welche Variablen Ein-, Aus- oder Ein-/Ausgangsparameter sind – sowie Beschreibungen, wie komplexe Datenstrukturen aufgebaut sind und welche Art von Funktionsblöcken verwendet werden. Darüber hinaus können weitere Metadaten die Anzahl der Aufgaben und deren Zykluszeiten sein.
Dies ist jedoch nur der erste Schritt. In der modernen Welt verlieren die strikte Trennung der Ebenen und der Top-Down-Ansatz des Informationsflusses, wie er in der Automatisierungspyramide definiert ist, seine Dominanz. In einem intelligenten Netzwerk muss jedes Gerät oder jeder Dienst in der Lage sein, die Kommunikation mit allen anderen Geräten und Diensten einzuleiten. Oder anders ausgedrückt: In einem modernen Smart Network ist jedes Gerät oder jeder Dienst in der Lage, eine unabhängige Kommunikation mit allen anderen Diensten einzuleiten. Hierzu haben PLCopen und OPC UA die OPC-UA-Client-Funktionalität in der PLCopen/IEC-61131-3-Steuerung hinzugefügt, oft zu-sätzlich zur Server-Funktionalität. Hierzu haben PLCopen und OPC Foundation einen Satz von ‚Client Function Blocks‘ definiert. Mit dieser auf einer Steuerung implementierten Funktionalität wird es möglich, eine Kommunikationssitzung mit einem beliebigen anderen verfügbaren OPC-UA-Server zu initiieren. Die Steuerung kann komplexe Datenstrukturen horizontal mit anderen Steuerungen unabhängig vom Feldbus-System oder vertikal mit anderen Geräten über einen OPC-UA-Serveraufruf in einem MES/ERP-System austauschen, um Daten zu sammeln oder neue Produktionsaufträge in die Cloud zu schreiben.
Neue Wege der Kommunikation
Durch die Abbildung des OPC-UA-Informationsmodells auf das PLCopen/IEC-61131-3-Softwaremodell ergibt sich ein einheitliches ‚Look and Feel‘ der OPC-UA-Server-Technologie, selbst auf unterschiedlichen Steuerungen. Dies ist Grundlage für die Kommunikation ‚Out-of-the-Box‘, die außerdem Sicherheit beinhalten kann. Anwender können damit darüber hinaus markenunabhängig eine Vorlage im HMI mit den anwendbaren Daten (Struktur) in den Steuerungen verknüpfen, sofern sie das PLCopen-OPC-UA-Mapping unterstützen. Ein Beispiel dieser Namenskonventionen sind die PackTags und die Zustandsmaschine, wie sie in der OMAC-for-Packaging-Spezifikation PackML als Teil des „ISA 88 Technical Report on Machine and Unit States“ definiert sind. Durch die konsequente Anwendung dieser Konventionen lässt sich eine Steuerung ‚out-of-the-box‘ über das OPC-UA-Client-Mapping in die PLCopen-Umgebung integrieren.
Mit dem in der Steuerung enthaltenen Client kann die Kommunikation auf der unteren Ebene initiiert werden und es lassen sich völlig neue Hierarchien und Architekturen anlegen. Auch die Controller-Controller-Kommunikation ist einfach realisierbar, unabhängig von der verwendeten Kommunikationsarchitektur. Dadurch lässt sich eine neue Steuerungsarchitektur initiieren, bei der die Kommunikation den verschiedenen Phasen der Fertigstellung des Produkts folgt (Bild 2).
Zum Beispiel wenn eine Steuerung eine bestimmte Geschwindigkeit für ein Transportsystem (wie ein Band) einstellt, auf dem sich ein Produkt bewegt, das von einem Roboterarm aufgenommen werden muss. Die Steuerung kann einen Methodenaufruf an die Robotersteuerung durchführen, um das Produkt aufzunehmen und gleichzeitig die Geschwindigkeit des Bandes zu übertragen. Der Roboter wiederum kann einen Methodenaufruf an die intelligente Kamera durchführen, um die Rotations- und Translationswerte des Produkts zu erhalten. Mit diesen Werten kann der Roboter die Trajektorie berechnen, um das Produkt reibungslos und korrekt aufzunehmen. Außerdem ist eine vom Controller ausgelöste Kommunikation mit dem ERP/MES-System zur Abfrage von Rezeptinformationen sowie zur Produktverfolgung möglich (Bild 3).
Dadurch ergeben sich ganz neue Möglichkeiten. So kann die Initiierung der Kommunikation auch auf unterster Ebene – etwa durch einen Sensor – erfolgen. Das bedeutet, dass ein Produkt (etwa ein Joghurtbecher) über ein RFID verfügen kann, das alle relevanten Informationen für seine Erstellung enthält. Diese Informationen können von der Steuerung gelesen werden und die verschiedenen Arbeitsstationen können die entsprechenden Aktionen durchführen, wie etwa das Hinzufügen von 98 Gramm Joghurt in der ersten Station. Am Ende kann die Prüfstation die geprüften Aktionen zurückschreiben und einen Methodenaufruf an das ERP-System initiieren, um die Ergebnisse der Verarbeitung an das Track-and-Trace-System zu liefern – auch wenn dieses eventuell in eine Cloud ausgelagert ist. Dies sind alles Kommunikations-Features, die heute schon realisierbar sind (Bild 4).
Ein wichtiges neues Konzept für Produktionsmaschinen im digitalen Zeitalter wird mit der Asset Administration Shell ( kurz: AAS oder Verwaltungsschale) in der Industrie 4.0 definiert. In Zukunft muss jede Anlage, Maschine oder Komponente mit einer AAS ausgestattet sein, um ‚I.4.0 ready‘ zu sein. Im Falle einer Maschine sollte die AAS – wie sie aus einer anderen übergeordneten Instanz (der Cloud) wahrgenommen wird – die Startseite oder das Ressourcenverzeichnis sein, das alle Dienste auflistet, die die Maschine bereitstellen kann.
Die Grundidee der I4.0-Komponenten: Jede Industrie-4.0-Anlage soll eine Asset Administration Shell (AAS) aufweisen, die eine minimale, aber ausreichende Beschreibung gemäß den Industrie-4.0-Anwendungsfällen enthält. Die Asset-Verwaltung besteht somit aus einer Reihe von ‚Submodellen‘. Diese stellen verschiedene Aspekte des betreffenden Vermögenswertes dar; sie können beispielsweise eine Beschreibung der Sicherheit enthalten, aber auch verschiedene Prozessfähigkeiten wie Bewegung oder Synchronisation beschreiben. Auf diese Weise lässt sich eine Maschine (das ‚Asset‘) als aus verschiedenen Teilmengen konstruiert betrachten, die wiederum Assets darstellen (Bild 5).
Auf eine reale Anlage heruntergebrochen könnte dies folgendermaßen aussehen: Auf der untersten Ebene gibt es ein Kombination aus den Assets Antrieb und Motor mit einem Encoder, die mit den in PLCopen Motion Control definierten Funktionalitäten wie MC_Move_Absolute und MC_Power verbunden sind. Auf der nächsthöheren Ebene werden mehrere dieser zusammengefassten Assets wiederum zusammengefasst und ein weiteres Asset – etwa eine Steuerung – hinzugefügt. In diesem Fall kann man Funktionalitäten wie die Synchronisation zwischen den Achsen oder sogar eine virtuelle Achse hinzufügen. Auf der nächsthöheren Ebene repräsentiert das Asset die Maschine, einschließlich der Anwendungssoftware, die in der Steuerung läuft. Auch die Sicherheitsaspekte lassen sich auf diese Weise berücksichtigen.
Um auf die AAS zugreifen zu können, arbeitet PLCopen zusammen mit seinen Mitgliedern an der Definition einer Reihe von Funktionsblöcken. Auf der obersten Ebene könnte dies beispielsweise so aussehen: Die ‚AasTypeId‘ bezieht sich auf den Identifikator einer typspezifischen Adminstrationsshell (Bild 6). Durch die Beschreibung einer solchen AAS kann der Systemintegrator oder Maschinenbauer eine Reihe von Maschinen beschreiben und angeben, welche Teilmodelle und Informationen von jeder Maschine der Reihe implementiert werden. Das Attribut kann leer gelassen werden, wenn keine solche Beschreibung vorhanden ist. Mit der ‚AasInstanceId‘ kann eine Instanz-ID für die AAS angegeben werden. Der Implementierer sollte darauf achten, dass jede einzelne Maschine mit einer eindeutigen ID versehen ist. Die ‚AssetId1‘ bezieht sich auf die serialisierte ID der Maschine, Produktionsstation oder ähnlichem. Wie bei der ‚AasInstanceId‘ ist es erforderlich, einerseits Individualiät, andererseits aber auch ein einfaches Implementieren zu gewährleisten.
Die Informationen und auch die Funktionalitäten einer AAS sind in ‚Submodellen‘ organisiert. Der Inhalt eines Teilmodells kann durch Industrie 4.0 standardisiert oder von einem Systemintegrator frei eingeführt werden. Viele Teilmodelle können von der AAS verwaltet werden (Bild 7).
Auf der nächsten Ebene werden Funktionsblöcke für Eigenschaften verschiedenen Datentypen (Boolean, DateTime, Enumerations, Integers, Real numbers, Strings) vorgeschlagen. Jeder dieser Blöcke weist fast die gleichen Attribute auf (Bild 8).
Industrie 4.0, AAS und PackML
Bild 9: Modelle wie PackML in die AAS werden helfen, IT- und OT-Engineering-Know-how zu verbinden.
© PLCopenIn der Produktion erprobte Informations-Modelle der Automation können als Submodelle dienen. Eines dieser Modelle ist PackML, das den Maschinenbetrieb, eine einheitliche Mensch-Maschine-Schnittstelle und vordefinierte OEE-Kennzahlen (Overall Equipment Efficiency) definiert. Ein PackML-Submodell bietet sich an als Part der AAS für ein semantisches Modell des Maschinenverhaltens (Bild 9).
PLCopen, PackML und OPC UA
Die Standardisierung von Maschinen-Informationsmodellen ist ein Schlüssel-Element, was die Interoperabilität und Konnektivität von Maschinen betrifft. Es ist wichtig, sich auf ein gültiges Modell der internen Control-Software zu einigen, um die Effizienz und Skalierbarkeit der Programmierung von Maschinencode zu gewährleisten. Seit mehr als 25 Jahren arbeitet PLCopen als unabhängiger Verband von Technologie-Anbietern an diesen Prinzipien und der aktiven Förderung der Programmierstandards IEC 61131-3. PLCopen hat sich auch dafür eingesetzt, die Verwendung der IEC 61131-3 als Programmiergrundlage für die Erstellung der ANSI/ISA-TR88.00, ‚Maschinen- und Aggregatzustände‘, einzuführen.
Die OMAC (Organization for Machine Automation and Control) wiederum, die verschiedene Interessengruppen wie OEMs, Systemintegratoren, Technologielieferanten und Endverbraucher vereint, hat den Namen PackML weltweit erfolgreich gefördert und etabliert, mit besonderem Schwerpunkt auf den Markt der Verpackungsmaschinen. Jeder, der PackML einsetzt, weiß, dass diese Normen und Richtlinien auf jede einzelne Produktionsmaschine anwendbar sind.
Im Sinne von Interoperabilität und Software-Effizienz basiert eine moderne ‚offene‘ Verpackungsmaschine heute auf einer Schicht skalierbarer Software, die auf den von PLCopen und OMAC-PackML geförderten Prinzipien basiert. Diese Beziehung kann als mehrschichtige Lösung beschrieben werden (Bild 10).
PLCopen-standardisierte Funktionsblöcke – auf Level 1 platziert – bieten eine plattformunabhängige Zuverlässigkeit und branchenspezifisches Know-how als solide Grundlage für die Steuerungspyramide. Diese bewährten APIs sind für die Entwicklung einer nachhaltigen, zuverlässigen und verteilbaren Maschinensteuerungssoftware unerlässlich. Auf Stufe 2 und 3 werden Anbieter, Systemintegratoren, OEMs und Anwender ermutigt, eigene Anwendungs-bibliotheken und Tools zu schreiben und zu pflegen. Auf diese Weise können wettbewerbsfähige Innovationen sowie Produktdifferenzierung umgesetzt und der Schutz geistigen Eigentums gewährleistet werden – das geistige Eigentum des OEMs ist auf dieser Ebene gekapselt und geschützt.
Durch den Aufruf von übergeordneten Funktionsblöcken lassen sich auf Ebene 4 effizient Programme ausführen. Auf oberster Ebene 5 erscheint PackML als eine höhere Steuerungsebene, die standardisierte Maschinenzustände und Betriebsabläufe, Overall Equipment Effectivenes (OEE) KPIs, Root Cause Analysis (RCA), flexible Rezeptschemata und gängige SCADA- oder MES-Eingaben anbietet. Alle diese möglichen Interaktionen mit dem menschlichen Bediener sind im Laufe der Jahre in vielen Produktionsszenarien rund um den Globus gut definiert und verfeinert worden.
Sowohl PLCopen als auch OMAC haben mit der OPC Foundation zusammengearbeitet, um ihre jeweiligen Modelle in den OPC-UA-Adressraum einzubringen. Dabei wurde unter anderem das IEC-61131-3 Softwaremodell auf ein OPC-UA-Informationsmodell abgebildet, das die Erstellung komplexer Datenstrukturen wie etwa eine PackML Unit Control Data Structure ermöglicht.
Zudem erlaubt OPC UA die automatische Erkennung und Erforschung von Servern und deren komplexen Datenstrukturen. Das heißt, wenn die Client-Server-Installation PLCopen und PackML verwenden würde, hätten diese Maschinentypen das gleiche Informationsmodell und könnten sich fast automatisch verstehen. Ein OPC-UA-Client könnte die verfügbaren PackML-Partner erkunden und nach den gewünschten ‚PackML-Services‘ suchen.
Autor:
Eelco van der Wal ist Managing Director der PLCopen e.V..
Das könnte Sie auch interessieren
Die ersten Schritte der Digitalisierung
Echtzeit-Transparenz im Materialfluss: Dieses Ziel setzte sich das Unternehmen Miba, als es die Digitalisierung der internen Logistikabläufe anging. Wie gut aber gelang letztlich die enge Verknüpfung von ERP und MES? – Ein Erfahrungsbericht.
mehr...Wie verändert das IoT die Unternehmen in 2020?
Wie wird sich die Netzwerk-Technik in den Unternehmen in 2020 verändern? Axel Simon, Chief Technologist bei HPE Aruba, wirft einen Blick in die Glaskugel
mehr...Digitaler Zwilling revolutioniert die Wartung
Als virtuelle Repräsentanten realer Maschinen eröffnen digitale Zwillinge neue Möglichkeiten, um komplexe Industrieanlagen und -systeme zu warten und instandzuhalten. Ein Projektbericht.
mehr...Online die Maschinendaten im Griff
Riesige Datenmengen in wertvolle Informationen verwandeln – wie lässt sich dieser Ansatz einer Smart Industry umsetzen? Die Verknüpfung PC-basierter Steuerungen mit Matlab und einem IoT-Analaytikdienst auf Cloudbasis kann ein praktikabler Ansatz...
mehr...Ohne Edge und Swarm geht es nicht
Mit dem IoT haben sich die Anforderungen an die Verarbeitung von Daten geändert, die Sensoren und Aktoren von Maschinen bereitstellen. Dies muss schnellstmöglich passieren – am besten dort, wo die Daten entstehen. Edge-Knoten und...
mehr...Von der Modellierung direkt in die SPS
Trotz Digitalisierung und I4.0 werden die technischen Funktionen in einer prozesstechnischen Anlage nicht einfacher, wenn man sie auf das kleinste Detail herunterbricht. Die richtigen Werkzeuge sinnvoll kombiniert, lässt sich der hohe...
mehr...Warum Predictive Maintenance?
Um Schäden proaktiv zu erkennen, lohnen sich Investitionen in vorausschauende Wartungssysteme. Nicht nur dass sich so die Lebensdauer einer Maschine erhöht, es eröffnen sich sogar neue Geschäftsmodelle für Maschinenbauer.
mehr...Wo bleiben die neuen Geschäftsmodelle?
Als Kennzeichen eines Industrie-4.0-Umfeldes werden immer wieder die notwendigen neuen Geschäftsmodelle genannt. Doch bis dato ist bei den wenigsten Unternehmen etwas davon zu sehen. Schneider Electric hat nun ein paar Modelle am Laufen.
mehr...Erste Kundenprojekte per BaSys 4.0
Ende Juni 2019 lief das BMBF-Projekt 'Basissystem Industrie 4.0‘ aus. Das Fraunhofer IESE bietet auf dessen Basis nun zusammen mit NetApp und Objective Partner Industrie-4.0-Lösungen mit Support und Adaption auf Kundensysteme an. – Die...
mehr...