Über zwei besonders hervorzuhebenden Merkmale verfügt OPC UA: die Unabhängigkeit vom jeweiligen Betriebssystem und die Skalierbarkeit. Beide Aspekte ermöglichen es, OPCUA von der PC-dominierten HMI-/Leitebene auf Steuerungen und Geräte zu portieren, die in der Feldebene installiert sind. 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.

OPC-UA-Server für flexiblere Bedienkonzepte

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. Ändert sich das Projekt auf der Steuerung, wird der Namensraum der Variablen im OPC-Server automatisch angepasst. Der PC fungierte damit eigentlich als externe Ressource des Projekts auf der Steuerung. Der wesentliche Vorteil eines Servers auf der Steuerung ergibt sich durch den Wegfall des PC sowie die Reduzierung um einen sogenannten Single-Point-of-Failure.

Der zentrale Ansatz eines OPC-UA-Servers auf dem PC und der dezentrale Ansatz des OPC-UA-Servers auf der Steuerung unterscheiden sich funktional kaum; zentral sind größere Mengengerüste möglich, während der dezentrale Ansatz mehr Flexibilität bietet.

© Phoenix Contact

In allen Szenarien, in denen gar kein PC nötig ist, 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 auf den Steuerungen höhere Lizenzkosten als bei einem einzigen Server auf dem PC an. Der Anwender muss bei seiner Entscheidung somit wie immer Kosten und Nutzen abwägen.
Ungünstig für Anwender und Betreiber kann darüber hinaus sein, dass sie sich aufgrund der Implementierung des OPC-UA-Servers auf der Steuerung mit dem Thema Security ausei­nander setzen 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 Zertifikats-basierten 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, so dass 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 Basisfunktionen auf der Steuerung, 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.

(Noch) ein Manko – die ­Performance

Ein auf der Steuerung befindlicher OPC-UA-Client bedeutet 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 OPC. Der OPC-Client wird dabei vom OPC-Server über Werte-Änderungen und Events regelmäßig informiert; sprich: Es ist eine Art Abonnement (Subscription). 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 Anwendungs-Szenario untereinander Daten weiterleiten.

Die OPC-UA-Client-Bausteine auf der Steuerung drehen die Automatisierungs­pyramide um; applikationsgetrieben werden überlagerte Server oder MES-Systeme mit Informationen versorgt.

© Phoenix Contact

Findet der OPC-Client der einen Steuerung auf dem Server der anderen Steuerung Variablen, die er kennt, oder Strukturen eines geläufigen ­Variablentyps, kann er diese auto­matisch mit eigenen Informationen verknüpfen. Auf diese Weise sind sämtliche Herausforderungen gelöst, die sich zum Beispiel 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 OPC UA aus Performance-Sicht nicht mit Ethernet-basierten Feldbusstandards wie etwa Profinet messen.

Ein anderes Anwendungsbeispiel beschreibt die Veränderung der Kommunikation mit überlagerter Software in der Engineering-Kette. Asset- oder Qualitäts-Management-Systeme 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 Management-Systeme ablegen, ohne Werkzeuge oder steuerungsspezifische Protokolle anpassen zu müssen. Die Kommunika­tionsrichtung wird einfach umgedreht, der Datenaustausch also jetzt durch die Steuerung initiiert.

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 der verschiedenen 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-Technik. 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 von OPC UA 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.

Auf der anderen Seite eröffnet die Technik aber auch ein enormes ­Innovationspotenzial. Die Implemen­tierung von OPC-UA-Clients und ­-Servern auf den Steuerungen bietet die große Chance, einen weltweiten ­sowie branchen- und herstellerüber­greifenden Standard auf der SPS für den azyklischen, Event-orientierten ­dezentralen Datenaustausch zu etablieren. Was sich aus einem solchen Potenzial an Mehrwert entwickelt, bleibt ­abzuwarten.

Autor: Robert Wilmes ist Mitarbeiter im Software-Marketing bei Phoenix Contact Electronics, Bad Pyrmont.