Die Anforderungen an Automatisierungsbaugruppen wachsen: Auf der Hannover Messe 2017 haben der VDMA und das Fraunhofer IOSB-INA einen Leitfaden für Praktiker vorgestellt, der sich mit dem Industrie-4.0-Kommunikations-Retrofit befasst und aufzeigt, wie sich OPC UA-basierte Kommunikation für Maschinen und Anlagen nachrüsten lässt.
Ein Ende 2016 veröffentlichter ZVEI-Leitfaden fordert neben einer OPC UA-Schnittstelle auch zahlreiche weitere Eigenschaften und Funktionen, die bereits jetzt benötigt werden. Eine Herausforderung für Produktmanager und Entwickler.
OPC UA (Open Platform Communications Unified Architecture) ist ein industrielles, auf Server und Client basierendes M2M-Kommunikationsprotokoll.
Es ist die aktuellste Spezifikation der OPC Foundation. Ein großer Unterschied zu den Vorgängern ist die Fähigkeit, Maschinendaten (Messwerte, Parameter etc.) semantisch, und damit maschinenlesbar, zu beschreiben.
OPC UA hat eine Service-orientierte Architektur (SOA), die aus mehreren Schichten aufgebaut ist. Alle durch OPC UA definierten Basisdienste (Base Services) sind abstrakte Beschreibungen protokollunabhängiger Methoden, die das Fundament für die gesamte OPC UA-Funktionalität bereitstellen.
Weitere wichtige Merkmale von OPC UA sind:
OPC UA hat sehr gute Chancen, dauerhaft zu einem der wichtigsten Protokolle für Industrie 4.0 und das IoT zu werden.
Wir beraten Sie gerne, wie Sie die Anforderungen von Industrie 4.0 mit unseren Produkten und Lösungen in Ihrem Unternehmen umsetzen können.
Im April 2017 veröffentlichten die hinter Industrie 4.0 (I4.0) stehenden Branchenverbände zahlreiche Dokumente, von denen einige einen detaillierten Einblick in den aktuellen Stand der Standardisierungsarbeiten rund um dieses Thema bieten. Eines dieser Dokumente ist der VDMA-Leitfaden Industrie 4.0 Kommunikation mit OPC UA.
Dieser Leitfaden erhebt den Anspruch, Maschinen- und Anlagenbauer sowie Betreiber bei der Einführung von I4.0-Kommunikation auf der Basis von OPC UA durch die Beschreibung von drei Migrationsschritten zu unterstützen.
Dabei wird die Diskrepanz berücksichtigt, die durch die zum Teil sehr abstrakten – aber nach wie vor unvollständigen – I4.0-Konzepte und Spezifikationen der verschiedenen Normierungsgruppen und dem zunehmenden Wettbewerbsdruck durch die immer schnellere Digitalisierung entsteht. Somit ist der VDMA-Leitfaden als pragmatischer Lösungsansatz zu verstehen.
Das VDMA-Dokument bietet konkrete Handlungsempfehlungen, um Erweiterungsnutzen (Value Added Services) für bereits existierende Produkte, Maschinen und Anlagen zu schaffen.
Zuerst wird klargestellt, dass es bei „I4.0-Kommunikation“ nicht um eine weitere Methode zum zeitkritischen Transport von Prozess- und Steuerungsdaten, sondern um grundlegend neue Konzepte, wie bspw. serviceorientierte Architekturen (SOA) und Informationsmodelle, geht.
Damit können einzelne Komponenten, Maschinen und Anlagen ihre Dienste innerhalb eines IP-Netzwerks anbieten, um SOA-basiert zu abstrakteren Maschinen- und Anlagendiensten orchestriert zu werden. Aber auch einfache und relativ bodenständige Anwendungen, wie Condition Monitoring oder Energieeffizienzoptimierungen, lassen sich per I4.0-Kommunikation als Value Added Services umsetzen.
Um Maschinen- und Anlagenbauer sowie Betreiber zur nachträglichen Integration – sprich Retrofit – und dem Einsatz von OPC UA zu bewegen, zeigt der VDMA-Leitfaden einen aus drei Schritten bestehenden Migrationspfad auf.
Laut VDMA müssen Anwender zunächst ein IP-Netzwerk für den OPC UA-Einsatz aufbauen, das über den Nahbereich einer Maschine bzw. Anlage hinausreicht und auch IT-Systeme wie MES und ERP einbezieht. Hierfür eignen sich laut Leitfaden Ethernet, WLAN und 5G-Mobilfunk (wobei 5G wohl noch ein paar Jahre dauert und bis dahin auch 4G ausreichen dürfte).
In dieses erweiterte Netzwerk wird ein OPC-UA-Server eingefügt und mit mindestens einer SPS verbunden. Mit Hilfe des Servers kann bspw. der OPC UA-Client eines MES-Systems auf die Daten der SPS zugreifen, um Condition Monitoring oder eine Energieeffizienzüberwachung zu realisieren.
Der Leitfaden weist dabei auch auf die IT-Security hin und beschreibt, dass für die OPC UA-Kommunikation zwischen Server und Client Zugriffsrechte konfiguriert und Zertifikate erstellt und verwaltet werden müssen.
OPC UA ist in der Automatisierungstechnik der einzige etablierte Standard mit breiter Unterstützung, der Informationsmodelle nutzt und neben dem protokollbasierten Datenzugriff umfassend vorgibt, wie solche Modelle dokumentiert, implementiert und referenziert werden. Ein OPC UA-Informationsmodell bildet eine Obermenge unterschiedlicher Datenobjekte, also eine mehr oder weniger abstrakte Abbildung einzelner Knoten mit ihren Eigenschaften, Beziehungen und Operationen, die sich damit ausführen lassen.
Da sich andere Standards auf die Kommunikationsregeln für Protokolle konzentrieren, sind Informationsmodelle genau das, was der M2M-Kommunikation bisher fehlte. Daher empfiehlt der VDMA als zweiten Schritt zur I4.0-Kommunikation den Herstellern, innerhalb einer Branche eine einheitliche OPC UA-Companion-Spezifikation zu entwickeln. Als Beispiel wird EUROMAP 77 für Spritzgussmaschinen relativ ausführlich vorgestellt.
OPC UA differenziert drei Kategorien für Informationsmodelle: Zum einen Modelle für Geräte (Devices) als Basis. Darauf aufbauend die Companion-Spezifikationen und drittens übergeordnete erweiterte Informationsmodelle. In einer einzigen OPC UA-Anwendung können mehrere dieser Modelle gleichzeitig zum Einsatz kommen.
Insofern richtet sich der dritte Schritt in erster Linie an Komponentenhersteller und Maschinenbauer. Ihnen wird verdeutlicht, dass es trotz einer brancheneinheitlichen Companion-Spezifikation auch in Zukunft deutliche Unterscheidungsmerkmale zwischen funktional identischen Produkten geben kann.
Hierfür eignen sich aus Sicht des VDMA die erweiterten OPC UA-Informationsmodelle. Sie ermöglichen einem Hersteller die Umsetzung geschützten Wissens als Alleinstellungsmerkmal, um sich vom Wettbewerb abzuheben.
Die Umsetzung der ersten beiden Schritte des VDMA-Leitfadens versprechen einen interessanten Mehrwert, erfordern aber auch sehr viel Detailarbeit, deren Komplexität und Kosten nicht unterschätzt werden sollten. Es ist zu beachten, dass sich bei vielen Bestandsanlagen eine OPC UA-Schnittstelle nicht ohne weiteres hinzufügen lässt, um auf die vorhandenen SPS-Daten zuzugreifen.
Auch wenn der Zugriff auf SPS-Daten durch ein nachgerüstetes OPC-UA-Gateway möglich ist, bedeutet das nicht, dass diese Daten einen Mehrwert bieten, bzw. ein brauchbares Informationsmodell ergeben. Daher muss u. U. in das SPS-Programm eingegriffen werden, um dem Gateway den Zugriff auf geeignete Daten zu ermöglichen. Häufig müssen neue Sensoren hinzugefügt werden, um Daten für Condition Monitoring oder Predictive Maintenance zu gewinnen.
Insgesamt ist der VDMA-Leitfaden ein Schritt in die richtige Richtung. Das Hinzufügen OPC UA-basierter Kommunikation schafft in vielen Maschinen und Anlagen neue Value Added Services, die die Gesamteffizienz steigern und so Investitionen zügig amortisieren.
Auf Grund fehlender Detailvorgaben müssen allerdings vielfach die erforderlichen OPC-UA-Informationsmodelle selbst definiert und ggf. an später existierende I4.0-Standards angepasst werden. Doch diese Probleme sind vertretbar, da es sich dabei lediglich um Konfigurationsänderungen handelt.
Des Weiteren lässt sich die vom VDMA beschriebene OPC UA-Kommunikation über zusätzliche Softwarekomponenten auch um eine I4.0-konforme Verwaltungsschale ergänzen, so dass der Schritt in Richtung Industrie 4.0 noch deutlicher ausfällt und der ZVEI-Leitfaden mit den Anforderungen an I4.0-Produkte gleich mit umgesetzt wird.
Der Ende November 2016 vom ZVEI veröffentlichte Leitfaden Welche Kriterien müssen Industrie-4.0-Produkte erfüllen? zeigt Anbietern und Anwendern auf, welche Anforderungen I4.0-Produkte erfüllen sollen bzw. müssen und unterscheidet dabei zwischen drei unterschiedlichen Zeithorizonten:
Der Leitfaden greift zwar nahezu das vollständige Gedankengut der Standardisierungsgremien auf. Allerdings ist zu beachten, dass die Details für die mittel- und langfristigen Anforderungen von den Standardisierungsgremien überhaupt noch nicht vollumfänglich beschrieben wurden.
Ein Grundgedanke der I4.0-Standards ist die Definition möglichst universeller Regeln zur datenzentrierten Beschreibung beliebiger technischer Gegenstände (Assets) über deren gesamten Lebenszyklus. Der Begriff des „technischen Gegenstands“ ist dabei sehr weitreichend spezifiziert: damit ist quasi alles gemeint, was für eine Organisation einen Wert hat, also nicht nur der physische Antrieb oder Sensor, sondern auch etwa Ideen oder Software.
Hierfür bezieht sich der ZVEI-Leitfaden auf das Referenzarchitekturmodell RAMI 4.0, über das inzwischen sehr viel diskutiert und geschrieben wurde. Daher hier nur eine kurze Zusammenfassung: RAMI 4.0 beschreibt ein Asset durch drei Dimensionen.
Eine Dimension stellt den Produktlebenszyklus mit den beiden elementaren Stufen Type und Instanz dar. Hier wären z. B. Datenblätter, Handbücher, Konstruktions- und Konfigurationsdaten zu finden.
Eine weitere Dimension spezifiziert sieben Hierarchieebenen vom Product bis zur Connected World. Nostalgiker finden hier die gute alte Automatisierungspyramide wieder, allerdings um zwei Ebenen erweitert.
Die dritte Dimension mit den sechs Schichten vom Asset bis zum Business dient als eigentliche Schnittstelle zur digitalen Welt. Hier erfolgt die Kommunikation mit anderen Systemen. Diese Dimension korreliert mit der sog. Verwaltungsschale (Asset Administration Shell), einem weiteren Referenzmodell aus der I4.0-Welt. Man spricht auch von der virtuellen Repräsentanz des Assets, oder – etwas eingängiger formuliert – vom digitalen Zwilling. Asset plus Verwaltungsschale bilden gemäß den Standardisierungsgremien die sog. Industrie-4.0-Komponente.
Eine solche I4.0-Komponente ermöglicht den standardkonformen Zugriff auf das Asset und ist somit der eigentliche Kern des ZVEI-Leitfadens. Dabei geht es um die Zusammenhänge, wie ein künftiges Produkt identifiziert und in ein Netzwerk eingebunden wird, um mit anderen Produkten „I4.0-konform“ zu kommunizieren bzw. um die Kommunikationsmöglichkeiten selbst.
Entwickler von Automatisierungsbaugruppen müssen sich also mit den beiden komplexen Fragen „Was genau ist eine Verwaltungsschale?“ und „Wie und wo realisiere ich diese Verwaltungsschale?“ auseinandersetzen. Die gute Nachricht ist: Sie können sich mit den Antworten etwas Zeit lassen.
Bitkom, DKE, VDI, VDMA und ZVEI haben die Verwaltungsschale noch gar nicht vollständig spezifiziert – genaugenommen existieren zurzeit nur vage Beschreibungen der Anforderungen. Insofern ist die Verwaltungsschale gemäß ZVEI für 2017er-Produkte auch nur ansatzweise zu berücksichtigen.
So gesehen reicht es momentan offensichtlich aus, wenn Produktentwickler folgende Kurzanleitung beachten:
Für den mittelfristigen Zeithorizont des Leitfadens, also für den Zeitraum bis 2021, ist dann allerdings mindestens eine mehr oder weniger vollständige Verwaltungsschale für jede I4.0-Komponente zwingend erforderlich. Doch zuvor müssen die Standardisierungsorganisationen erst einmal vollumfängliche Spezifikationen abliefern.
Entwickler müssen aber auf jeden Fall sicherstellen, dass ein 2017er-Produkt mit den zuvor beschriebenen Minimalfunktionen zu einem späteren Zeitpunkt auf eine vollständige Verwaltungsschale aufgerüstet werden kann.
Ein gemäß ZVEI entwickeltes I4.0-Produkt lässt sich in eine Domain-basierte Umgebung einfügen (siehe Abbildung 1). Die einzelnen Systeme sind hier in unterschiedlichen Kommunikationsdomains zusammengefasst.
Die gesamte Automatisierungstechnik wie etwa Sensoren, Aktoren, Steuerungen oder Edge Gateway ist in der OT-Domain (OT = Operational Technology) zu finden. ERP und MES befinden sich in der IT-Domain (IT = Information Technology) und externe Systeme in der CT-Domain (CT = Cloud Technology).
Abbildung 1: In einer Kommunikationsumgebung gehören zu den einzelnen Baugruppen sog. Verwaltungsschalen. Zusammen mit dem physischen Gegenstand bilden sie die I4.0-Komponente.
Die Verwaltungsschale bzw. die per QR-Code erreichbare produktspezifische Website eines 2017er-Produkts lässt sich an unterschiedlichen Stellen verorten. Im einfachsten Fall befindet sie sich direkt im jeweiligen Produkt, bspw. einer Steuerung mit den jeweiligen Ressourcen. Alternativ sind auch Implementierungen auf einem Edge Gateway oder in einer x-beliebigen Cloud möglich.
Zu einer Komponente können auch mehrere Verwaltungsschalen gehören, die bei Bedarf auch an unterschiedlichen Orten liegen – z. B. eine Verwaltungsschale direkt im Sensor, die andere in der Cloud.
Hatte man bisher vielleicht den Eindruck, sich beim Thema Industrie 4.0 in einer Art luftleerem Raum zu bewegen, in den im Grunde jeder seine eigenen Ideen und Vorstellungen hineininterpretieren kann, so zeichnet sich langsam aber sicher ein klareres Bild der I4.0-Konzepte ab. Nicht zuletzt durch die Arbeit des VDMA und des ZVEI gibt es jetzt endlich Kriterien und Vorgaben, aus denen sich konkrete Handlungen für Hersteller und Betreiber von Maschinen und Anlagen ableiten lassen.
Nun gilt es die Ärmel hochzukrempeln und die neuen Vorgaben Stück für Stück in die Tat umzusetzen, um auch in Zukunft wettbewerbsfähig zu bleiben!
SSV Software Systems GmbH
Dünenweg 5
30419 Hannover
Fon: +49(0)511 · 40 000-0
Fax: +49(0)511 · 40 000-40
Impressum · Datenschutz · AGB
© 2024 SSV SOFTWARE SYSTEMS GmbH. Alle Rechte vorbehalten.
ISO 9001:2015
