OPC-UA: Optimierung proprietärer Kommunikationsstrukturen

Die OPC-UA-Technologie verfügt über zwei Merkmale, die besonders hervorzuheben sind: die Unabhängigkeit vom jeweiligen Betriebssystem und die Skalierbarkeit. Beide Aspekte ermöglichen es nun, OPC UA von der PC-dominierten HMI-/Leitebene auf Steuerungen und Geräte zu portieren, die in der Feldebene installiert sind. Die verschiedenen Implementierungsebenen – PC und Gerät – bieten Vor- und Nachteile. Durch das Herunterbrechen auf die Geräte kann sich die Automatisierungslandschaft jedoch erheblich verändern. Nachfolgend werden unterschiedliche Szenarien einer Client-/Server-Integration in Steuerungen und Geräte sowie die entsprechenden Verbesserungspotentiale aufgezeigt. Im ersten Schritt ist dabei zwischen einer ­Client- oder Server-Funktion zu unterscheiden. Der Server auf der Steuerung stellt eine konsequente Weiterentwicklung des ­Client-Server-Gedankens respektive des Top-Down-Ansatzes in die Steuerungsebene dar. Im Gegensatz dazu kehrt die zusätzliche Client-Funktion auf der Steuerung das klassische Top-Down-Szenario komplett um.

Industrie-PC kann als externe Ressource entfallen

Aus Anwendersicht erweist sich der UA-Server auf der Steuerung nicht als große Innovation. Viele der aktuell am Markt etablierten OPC-Server für Steuerungen holen sich ihre Konfiguration – also die Information, welche Variablen mit welchem Typ zur Verfügung gestellt werden sollen – direkt von der Steuerung. Das gilt auch für die Lösung von Phoenix Contact. Ändert sich das Projekt auf der Steuerung, passt sich der Namensraum der Variablen im OPC-Server automatisch an. Der PC fungiert damit eigentlich als externe Ressource des Projekts auf der Steuerung. Der wesentliche Vorteil eines Servers auf der Steuerung ergibt sich durch den Wegfall des PCs sowie die Reduzierung um einen so genannten Single Point of Failure. In allen Szenarien, in denen man keinen PC benötigt, oder dort, wo zahlreiche OPC-Clients über einen PC mit mehreren Steuerungen kommunizieren, eröffnet ein dezentraler Ansatz mit OPC-Servern auf der Steuerung Vorteile. Als nachteilig zeigt sich die höhere Belastung der Steuerung, so dass der Anwender unter Umständen eine leistungsfähigere SPS nutzen muss. Zudem fallen bei vielen dezentralen Servern höhere Lizenzkosten als bei einem einzige Server auf dem PC an. Der Anwender muss bei seiner Entscheidung somit wie immer Kosten und Nutzen abwägen (Bild 1).

Durchgängige Zertifizierungshierarchie

Für den Anwender und Betreiber kann es darüber hinaus ungünstig sein, sich aufgrund der Implementierung des OPC-UA-Servers auf der Steuerung mit dem Thema Security auseinandersetzen zu müssen. Natürlich können Client und Server jedes beliebige Zertifikat akzeptieren. In diesem Fall ist die Zugriffssicherheit allerdings nicht mehr gegeben. Bei einer zertifikatsbasierten Security-Lösung sind die betroffenen Zertifikate sämtlicher anderen Kommunikationsteilnehmer auszutauschen, wenn sich ein Teilnehmer ändert. Als Lösung bietet sich der Aufbau einer durchgängigen Zertifikatshierarchie an, sodass neue Geräte mit der gleichen Zertifikatshierarchie automatisch in die Datenübertragung aufgenommen werden. Das Beispiel verdeutlicht, dass das Thema ­Security heute noch nicht flächendeckend in der Steuerungswelt angekommen ist. Ein sicherer Datenzugriff wird jedoch zunehmend gefordert – egal, ob ein OPC-UA-Server auf der Steuerung implementiert wurde oder nicht.
Als sinnvolle Erweiterung der OPC-Server-Funktion auf der Steuerung erweisen sich auch kaskadierte Server-Konzepte. In diesem Szenario läuft ein Server mit Basis­funktionen, mit dem beispielsweise die ­lokalen HMI-Geräte direkt kommunizieren. Ein überlagerter OPC-UA-Server holt sich die Informationen vom lokalen Server und stellt sie den Leitsystemen mit dedizierten Zugriffsregeln zur Verfügung.

Steuerungen tauschen Daten aus

Ein OPC-UA-Client beinhaltet gegenüber dem OPC-Server funktional eine viel größere Veränderung. Möchte der Client, zum Beispiel ein HMI-Gerät, zyklisch Werte einer Steuerung lesen, empfiehlt sich der Client/Server-Ansatz über Subscription von OPC. Will die Steuerung allerdings Event-orientiert Daten von einem weiteren UA-Server lesen oder in ihn ­schreiben, muss sie zum UA-Client werden. Über diesen Ansatz können Steuerungen verschiedener Hersteller als erstes Anwendungsszenario untereinander Daten weiterleiten. Findet der OPC-Client der einen Steuerung auf dem Server der anderen SPS Variablen, die er kennt, oder Strukturen eines geläufigen Variablentyps, kann er diese automatisch mit eigenen Informationen verknüpfen. Auf diese Weise sind sämtliche Herausforderungen gelöst, die sich beispielsweise durch unterschiedliche Plattformen ergeben. Intelligente Ethernet-basierte Geräte mit zahlreichen Parametern tauschen so ebenfalls Daten über ein Protokoll mit allen OPC-Client-fähigen Steuerungen aus. Die Grenzen dieser Szenarien liegen lediglich in der gewünschten Update-Rate. Denn nach heutigem Stand kann sich die OPC-UA-Technologie aus Performance-Sicht nicht mit Ethernet-basierten Feldbusstandards wie Profinet messen (Bild 2).
Ein anderes Anwendungsbeispiel beschreibt die Veränderung der Kommunikation mit überlagerter Software in der Engineering-Kette. Asset- oder Qualitätsmanagementsysteme benötigen zum Beispiel konsolidierte Daten zu Betriebsstunden, Fertigungsparametern oder Qualitätsmesswerten. Diese sind allerdings erst zum Ende einer Schicht oder eines Auftrags erforderlich. Über die OPC-Client-Bausteine lassen sich entsprechende Informationen standardisiert in den Datenbanken der Leit- und Managementsysteme ablegen, ohne Werkzeuge oder steuerungsspezifische Protokolle anpassen zu müssen. Die Kommunikationsrichtung wird einfach umgedreht, der Datenaustausch also durch die Steuerung initiiert (Bild 3).

Definition der Client-Bausteine

Die beiden dargelegten Ansätze – OPC UA als Server sowie die Client-Bausteine – hat die OPC Foundation frühzeitig aufgenommen und spezifiziert. Im ersten Schritt wurde 2012 die PLCopen-Abbildungsvorschrift für OPC-UA-Server erstellt. Danach begann das Konsortium sofort mit der Definition von OPC-UA-Client-Bausteinen für die IEC 61131, die eine Kommunikation mit weiteren Servern ermöglicht. In beiden Spezifikationen haben die PLCopen- und die OPC-Nutzerorganisation gemeinsam mit den beteiligten Unternehmen die Idee einer übergreifenden Datenübertragung schnell und effizient umgesetzt. Der OPC-UA-Server ist bereits seit längerem auf vielen PCs und Steuerungen verschiedener Hersteller implementiert. Die Definition der Client-Bausteine wurde 2014 abgeschlossen, wobei erste Implementierungen seit kurzem auf dem Markt erhältlich sind.
Die aufgeführten Szenarien zeigen das Potenzial der neuen OPC-UA-Technologie. Mit einem herstellerübergreifenden Standard lassen sich zahlreiche proprietäre Kommunikationsstrukturen optimieren. Durch OPC UA verändert sich die Welt der MES-/ERP-Kopplung von Steuerungen definitiv. Die Herausforderung der OPC-UA-Technologie liegt dabei in der Einfachheit. OPC UA ist ein mächtiges Protokoll mit unzähligen Funktionen und Freiheitsgraden. Wenn die Komplexität der Schnittstellen dem Bediener, Systemintegrator sowie Maschinen- und Anlagenbauer nicht verborgen wird und die Fehlerdiagnose nur durch Spezialisten erfolgen kann, wenden sich die vielen Vorteile der Technologie schnell zum Nachteil. Trotzdem ergibt sich ein großes Innovationspotenzial. Die Implementierung von OPC-UA-Clients und -Servern auf den Steuerungen eröffnet eine große Chance, einen weltweiten sowie branchen- und herstellerübergreifenden Standard auf der SPS für den azyklischen, Event-orientierten dezentralen Datenaustausch zu etablieren. rt

Dipl.-Ing. Robert Wilmes arbeitet im Software-Marketing der Business Unit Control Systems bei Phoenix Contact Electronics in Bad Pyrmont.