M2M-Kommunikation

OPC UA vs. OPC Klassik

| Autor / Redakteur: Robert Wilmes * / Gerd Kucera

Bild 1: OPC UA bietet auch langfristig eine hohe Anpassungsfähigkeit, da die Kommunikation, die Objekte, ihre Rollen (DA, A&E, PRG, HD) und die Profile (Collaboration Models) aufeinander aufbauend strikt getrennt wurden.
Bild 1: OPC UA bietet auch langfristig eine hohe Anpassungsfähigkeit, da die Kommunikation, die Objekte, ihre Rollen (DA, A&E, PRG, HD) und die Profile (Collaboration Models) aufeinander aufbauend strikt getrennt wurden. (Bild: Phoenix Contact)

Das Protokoll OPC UA setzt auf umfassende Standardisierung zur M2M-Kommunikation. Der Beitrag zeigt, wie sich OPC UA unterscheidet und welche Vorteile sich für den Anwender ergeben.

Technisch gesehen weisen OPC UA (Unified Architecture) und die bestehenden OPC-Spezifikationen aus dem Klassik-Bereich kaum Gemeinsamkeiten auf. In den fast 20 Jahren seit ihrer Markteinführung haben sich die Klassik-Spezifikationen wie OPC DA (Data Access) und OPC A&E (Alarm & Event) erfolgreich in zahlreichen industriellen Bereichen bewährt.

Auf ihrer Grundlage sind viele tausend Produkte entstanden sowie hunderttausende Applikationen umgesetzt worden. Funktional hat OPC Klassik die Anwendungsfälle somit lange Zeit hinreichend abgedeckt. Aufgrund der stetig wachsenden Ethernet-basierten Vernetzung genügt der Standard den technologischen Ansprüchen jedoch nicht mehr. Deshalb wurde bereits vor rund zehn Jahren mit der Entwicklung von OPC UA begonnen. Die neue Technologie löst alle zukünftigen Kommunikationsanforderungen der oberhalb der Feldbussysteme angesiedelten Automatisierungstechnik ab.

Das objektorientierte Datenmodell von OPC UA

Mit OPC UA sind sämtliche vorher getrennten Spezifikationen auf ein gemeinsames Datenmodell portiert worden. Denn auch in der neuen OPC-UA-Welt müssen die Daten zyklisch oder im Fall einer Änderung ausgetauscht werden. Ebenso wichtig ist die Verfügbarkeit historischer Daten. Diese Funktionen wurden auf ein Objekt-orientiertes Modell übertragen, in dem jedes Objekt Dienste für die Funktionen Data Access (DA), Alarm & Conditions (AC), Programs und Historical Access (HA) liefert.

OPC Klassik baut auf der DCOM-Technologie von Microsoft auf. 1996 war das eine gute Entscheidung, um den Standard insbesondere bei den Herstellern von Bedienen-und-Beobachten-, Steuerungs- und SCADA-Systemen zu etablieren. Durch OPC Klassik wurden seitenlange Kompatibilitäts- oder Treiberlisten zwischen den Steuerungs- und Visualisierungsanbietern überflüssig. Wegen der verschiedenen per OPC UA adressierten Komponenten kann nicht davon ausgegangen werden, dass alle Geräte mit einem Windows-Betriebssystem arbeiten. Daher sind die beiden OPC-UA-Transportprofile UA-Binary und UA-XML betriebssystemunabhängig spezifiziert worden.

Während UA-Binary auf Geschwindigkeit und Durchsatz optimiert ist, erweist sich das auf HTTP und SOAP-Protokollen basierende UA-XML als Firewall-freundlich. Eine Portierung auf Sensoren wie einen RFID-Leser oder Ethernet-ASIC für Profinet verdeutlicht die Skalierbarkeit von OPC UA sowie die Unabhängigkeit des Standards von Betriebssystemen schon jetzt (Bild 1).

Heute sieht die Automatisierungswelt jedoch anders aus und OPC UA adressiert ein weitaus breiteres Anwendungsfeld. Neben den Steuerungen und Bedienen-und-Beobachten-Geräten müssen zahlreiche weitere Werkzeuge und Applikationen standardisiert Daten austauschen. So verwalten Asset-Management-Tools die Geräte, Qualitätsmanagement-Werkzeuge nehmen jeden Fertigungsschritt auf, während ERP- und MES-Systeme die Produktionsaufträge für die Automatisierung verwalten. Die Software-Lösungen verzahnen sich immer stärker mit der Automatisierungstechnik. Aufgrund dieser Veränderungen steigen auch die Anforderungen an die OPC-Schnittstelle stetig.

Bild 1: OPC UA bietet auch langfristig eine hohe Anpassungsfähigkeit, da die Kommunikation, die Objekte, ihre Rollen (DA, A&E, PRG, HD) und die Profile (Collaboration Models) aufeinander aufbauend strikt getrennt wurden.
Bild 1: OPC UA bietet auch langfristig eine hohe Anpassungsfähigkeit, da die Kommunikation, die Objekte, ihre Rollen (DA, A&E, PRG, HD) und die Profile (Collaboration Models) aufeinander aufbauend strikt getrennt wurden. (Bild: Phoenix Contact)

Vor diesem Hintergrund zielt OPC UA auf die Schaffung eines umfassenden Standards für die Maschine-zu-Maschine-Kommunikation (M2M) ab, einer grundlegenden Voraussetzung für das Zukunftsprojekt Industrie 4.0, das Internet der Dinge sowie Cyber Physical Systems (CPS). In diesen Ansätzen tauschen unterschiedliche Geräte und Werkzeuge Daten über eine gemeinsame Kommunikationsplattform aus.

Die SPS stehen somit nicht mehr im Zentrum der Automatisierungslösung. Vielmehr fließen viele Informationen von intelligenten Geräten und Technologie-Steuerungen an der SPS vorbei zu den überlagerten Tools. Die Kommunikation wird zum wichtigsten System innerhalb der Lösung. Diese Entwicklung wurde unter anderem durch den Trend zu Ethernet-basierten Feldbussystemen wie Profinet, Ethernet/IP und ModbusTCP ausgelöst. Über die Ethernet-Mechanismen integrieren sich immer mehr von überall erreichbare Geräte funktional in die Kommunikationsstrukturen.

OPC UA integriert eine skalierbare Security-Lösung

Bild 2: Die verschiedenen Kommunikationsprotokolle, die Betriebssystem-unabhängig spezifiziert wurden, nutzen für die Zugriffssicherheit die Standardmechanismen aus der IT-Welt, also SSL in HTTPS sowie x.509-Zertifikate in UA/WS Secure Conversation.
Bild 2: Die verschiedenen Kommunikationsprotokolle, die Betriebssystem-unabhängig spezifiziert wurden, nutzen für die Zugriffssicherheit die Standardmechanismen aus der IT-Welt, also SSL in HTTPS sowie x.509-Zertifikate in UA/WS Secure Conversation. (Bild: Phoenix Contact)

Um den höheren Anforderungen an die Zugriffssicherheit Rechnung zu tragen, umfasst OPC UA ein skalierbares Security-Konzept. Reichen die Maßnahmen der User- und Application-Security nicht aus, können die Daten auf der Transport-Ebene über SSL-Mechanismen verschlüsselt werden. User- und Application-Security sichern die Autorisierung von Nutzern sowie die Integrität der Client- und Server-Programme über x.509-Zertifikate ab.

Damit sich die Sicherheitsfunktionen an die Anforderungen der jeweiligen Applikation anpassen lassen, definiert OPC UA den Mechanismus der Endpunkte. Diese können unterschiedliche Security-Eigenschaften und Datenstrukturen enthalten.

Wichtiger als die Standardisierung der Kommunikationsprotokolle ist die Vereinheitlichung entsprechender Profile. Denn erst durch die Profile (Collaboration Models) können die OPC-UA-Clients den Inhalt der Daten über Meta-Informationen interpretieren. Aktuell gibt es Profile (Bild 2) für bestimmte Funktionen (beispielsweise der S95-Standard für die MES-Ankopplung), für Geräte (zum Beispiel Analyzer Devices oder gemäß IEC 61131 programmierbare Steuerungen) sowie für verschiedene Branchen oder Bussysteme (beispielsweise die Gebäudeinstallation und Energietechnik).

Zwei Szenarien sollen aufzeigen, welche Vorteile sich für den Anwender aus dem Technologiewechsel ergeben. In der ersten Anwendung wird das Bedien- und Fernwartungskonzept auf OPC UA umgestellt. Die zweite Applikation ermöglicht eine einfache Integration in die Fertigungssteuerung, die Auftragsverwaltung sowie die Kommunikation mit Asset-/Qualitätsmanagement-Systemen.

Bild 3: Kaskadierte OPC-UA-Client/Server-Konzepte unterstützen die spezifischen Kommunikationsanforderungen der jeweiligen Bereiche.
Bild 3: Kaskadierte OPC-UA-Client/Server-Konzepte unterstützen die spezifischen Kommunikationsanforderungen der jeweiligen Bereiche. (Bild: Phoenix Contact)

Kaskadierte Server-Installation auf Steuerungen

Für den Anwendungsfall wurde das PLCopen-UA-Profil für eine gemäß IEC 61131 programmierte SPS festgelegt. Es beinhaltet mehrere Ausprägungen, die sich an der Leistungsfähigkeit der Steuerung oder des PCs orientieren. Dabei können OPC-UA-Server direkt auf der SPS laufen und sich dort die Ressourcen, wie Prozessor und Speicher, mit der Steuerungs-Applikation teilen. Der OPC-UA-Server kann natürlich auch weiterhin auf dem PC installiert werden und sich die Daten über ein effektiveres proprietäres Protokoll von der SPS holen.

Beide Lösungen haben Vor- und Nachteile, weshalb sich zum Beispiel ihre Kaskadierung als sinnvoll erweist. Ein OPC-UA-Server auf dem PC, der als Schaltstelle für die mit Security-Methoden geschützten Fernzugriffe dient, speichert die historischen Daten. Der zweite auf der Steuerung befindliche OPC-UA-Server setzt alle Anforderungen hinsichtlich eines einfachen Bedien- und Diagnosekonzepts um. Sind in der Applikation mehrere SPS verbaut, können sich die lokalen Bediengeräte mit jeder Steuerung verbinden und Informationen ohne Umwege austauschen. Der auf dem PC installierte OPC-UA-Server wird zur zentralen abgesicherten Datensammelstation (Bild 3).

Bild 3: Kaskadierte OPC-UA-Client/Server-Konzepte unterstützen die spezifischen Kommunikationsanforderungen der jeweiligen Bereiche.
Bild 3: Kaskadierte OPC-UA-Client/Server-Konzepte unterstützen die spezifischen Kommunikationsanforderungen der jeweiligen Bereiche. (Bild: Phoenix Contact)

Neben dem standardisierten Adressraum einer Steuerungs-Applikation bietet der PLCopen-Standard viele Zusatzinformationen (Metadaten) über die Programmstruktur und den Aufbau von Datenstrukturen. Auf Basis dieser Informationen können beispielsweise sich wiederholende mechatronische Einheiten wie Trafostationen oder Pumpensteuerungen über einen Link mit dem Leitsystem oder untereinander zum Zweck der M2M-Kommunikation verbunden werden. Der Verknüpfungsaufwand und die Fehlersuche reduzieren sich so im Vergleich zu einer herkömmlichen manuellen Verbindung der Einzelelemente erheblich.

Informationsaustausch zwischen Fertigung und Leitebene

MES-Systeme übernehmen zum Beispiel die Produktions-, Material- und Personalplanung sowie das Informations-Management. In der Regel sind ihnen ERP-Lösungen übergeordnet, die die Fertigungsaufträge initiieren und den Kundenaufträgen zuordnen. Zukünftig verschwimmen die Grenzen zwischen beiden Tools immer mehr. Die in der Produktionszelle montierte SPS bleibt der zentrale Kommunikationspartner für diese Aufgaben.

Sie stellt allerdings nur einen Teil der Applikation dar, die darüber hinaus zusätzliche Technologie-Steuerungen oder PC-basierte Lösungen wie Bilderfassungssysteme beinhaltet. Hinzu kommen weitere intelligente Systeme, die nicht in den Feldbus der Steuerung integriert sind, weil sie nicht zyklisch Daten mit ihr austauschen müssen.

In diesem Szenario verfügen sämtliche Teilsysteme innerhalb der Fertigungszelle über einen eigenen OPC-UA-Server. Zur Kommunikation mit den Teilsystemen sind auf der SPS OPC-UA-Client-Funktionsbausteine implementiert, die im PLCopen-Standard definiert wurden. Sie bieten alle Funktionen, um selbst komplexe Informationen zyklisch oder aus dem IEC61131-Programm gesteuert mit anderen Teilsystemen auszutauschen. OPC UA wird damit zum überlagerten Rückgrat der Fertigungszelle.

Bild 4: OPC UA fungiert sowohl als Kommunikationsrückgrat in der Maschine als auch als Schnittstelle für alle Werkzeuge im Control Network.
Bild 4: OPC UA fungiert sowohl als Kommunikationsrückgrat in der Maschine als auch als Schnittstelle für alle Werkzeuge im Control Network. (Bild: Phoenix Contact)

MES-spezifische Objekte und zukunftsgerichtete Lösung

In Ethernet-basierten Applikationen wie Profinet werden die Informationen über das gleiche Netzwerk verteilt. Die SPS fungiert als zentraler Ansprechpartner für die ERP- und MES-Systeme. Zu diesem Zweck unterstützt der auf der SPS installierte OPC-UA-Server neben dem PLCopen-Profil auch ein Profil mit MES-spezifischen Objekten, etwa gemäß ISA-S95-Standard oder nach den Vorgaben des MES-D.A.CH-Verbands, einem Zusammenschluss deutschsprachiger MES-Unternehmen. Die dort festgelegten Objekte liefern die 40 bis 50 wichtigsten Kennzahlen der Fertigungszellen für das Leitsystem. Die überlagerte MES-/ERP-Umgebung ist ebenfalls heterogen.

Hier gibt es noch zahlreiche spezifische Lösungen, die sich zum Beispiel mit der Wartung und Diagnose von Betriebsmitteln (Asset Management) oder der Erfassung von Qualitätsdaten (Qualitäts-Management) beschäftigen. Diese Tools erhalten mit OPC UA ein leistungsfähiges Interface für den Zugriff auf die SPS, einzelne Geräte oder die intelligenten Teilsysteme wie Technologie-Steuerungen (Bild 4).

Die beschriebenen Informationsmodelle nach PLCopen oder ISA S95 zeigen nur einen kleinen Auszug aus den aktuell definierten Abbildungsvorschriften. Weitere Vorschriften entstehen etwa für die Energietechnik und die Gebäudeinstallation. Die jeweiligen Organisationen und Hersteller-Vereinigungen können sich auf die Inhalte der Daten konzentrieren, OPC UA kümmert sich um die Datenaustausch-Mechanismen.

Das Kommunikationsprotokoll OPC UA ist somit sowohl technologisch über seine Eigenschaften als auch strategisch durch die vielen Profile gut aufgestellt, um zukünftige Anforderungen der Automatisierungstechnik abzudecken. OPC UA soll dabei die Echtzeit-fähigen, Ethernet-basierten Feldbussysteme nicht ersetzen, sondern arbeitet optimal mit ihnen zusammen.

Lesen Sie auch zu OPC UA:

OPC UA over TSN – gemeinsame Sprache für die Zukunft

OPC UA over TSN – gemeinsame Sprache für die Zukunft

30.11.17 - Durch die Kombination von OPC UA und TSN gelingt der Datenaustausch zwischen Geräten verschiedener Hersteller. So entsteht eine einheitliche Kommunikation, die viele Vorteile mit sich bringt lesen

* Dipl.-Ing. Robert Wilmes ist Mitarbeiter im Software Marketing der Business Unit Control Systems, Phoenix Contact Electronics GmbH, Bad Pyrmont.

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Kontaktieren Sie uns über: support.vogel.de/ (ID: 42713395 / Industrial Networking)