Industrielle Kommunikation: OPC UA - eine Standortbestimmung

Mit der OPC-UA-Technologie steht ein industrieller Kommunikationsmechanismus zur Verfügung, der es erlaubt, Systeme von der Steuerungs- bis zur Leit- und Betriebsebene miteinander zu vernetzen. Doch wo steht dieser Standard heute konkret in der Automatisierungstechnik und was muss passieren, um die Akzeptanz von OPC UA im Industrieumfeld stärker zu fördern?

ISW, OPC UA im Industrieumfeld Bildquelle: © Computer&AUTOMATION

Die Herausforderung in der Automatisierungs- und Steuerungstechnik besteht heute darin, verschiedenste Systeme unterschiedlicher Hersteller miteinander zu vernetzen. Maschinen, Anlagen und Komponenten werden an Softwaresysteme zur Produktions- und Unternehmensplanung (Leitsysteme), zur Prozesssteuerung (Bedien- und Überwachungssysteme) und zur Inbetriebnahme (Engineering) angebunden und müssen oftmals auch auf direktem Weg mit weiteren Maschinen, Anlagen und Komponenten kommunizieren. Die Schnittstellen, Profile und Kommunikationsmechanismen zur Vernetzung der einzelnen Systeme sind folglich überaus vielfältig. Zudem sind hier sowohl standardisierte als auch proprietäre Lösungen vorzufinden. Diese Vielfältigkeit sowie die fehlende Durchgängigkeit der Standardisierung führen letztendlich dazu, dass die Aufgabe der Systemvernetzung aktuell mit großem Aufwand verbunden ist.

ISW, OPC UA, vielfältige Kommunikationswege und  mechanismen Bildquelle: © ISW

Die Vielfalt der Kommunikationswege und -mechanismen lässt erkennen, vor welchen Herausforderungen die Automatisierungs- und Steuerungstechnik im Hinblick auf die Vernetzung der Teilsysteme heute steht.

Mit Ethernet existiert für die physikalische Übertragung bereits ein Standard, der den Grundstein für eine einheitliche und durchgängige Kommunikation legt. Zusätzlich ist mit OPC seit geraumer Zeit ein Kommunikationsstandard verfügbar, der die einheitliche und standardisierte Kommunikation in allen Ebenen der Automatisierungspyramide ermöglicht. Die ursprüngliche OPC-Spezifikation (Classic OPC) hat jedoch auch Nachteile, die sich erst im Laufe der Jahre offenbarten. So behinderte zum Beispiel die Bindung an Microsoft-Windows aufgrund des als Basis dienenden OLE-COM- be­ziehungsweise DCOM-Standards eine durchgängige Verbreitung und Integration von OPC. Die Gerätelandschaft und Systemplattformen, für die OPC eigentlich gedacht ist, sind jedoch sehr viel­fältig geworden und gehen heute weit über reine Windows-Plattformen hinaus. Mit anderen Worten: Der Einsatz von Industrie-PCs mit Linux-Betriebssystemen sowie von Embedded-Geräten mit Minimalbetriebssystemen oder Echtzeit-Betriebssystemen, die keine DCOM-Unterstützung anbieten, ist mit dem klassischen OPC ausgeschlossen beziehungsweise nur aufwendig über Gateway-Lösungen umsetzbar.

Weiter hat sich gezeigt, dass der rechnerübergreifende Einsatz von Classic OPC zu aufwendigen und komplizierten Sicherheitseinstellungen führte oder dass Sicherheitsmechanismen aufgrund fehlender Expertise gänzlich abgeschaltet wurden. Nicht zuletzt hat sich bezüglich der Spezifikation eine Trennung des Adressraums in unterschiedliche Dienste (Zugriff auf Prozessdaten, DA), auf historische Daten (HDA) oder beispielsweise auf Ereignisse (AE) als nicht praktikabel erwiesen, und das Fehlen weiterer Eigenschaften – etwa die  Möglichkeit zur Nutzung komplexer Datentypen – hat sich ebenfalls als Manko herausgestellt.

Mit der Spezifikation OPC Unified Architecture – kurz OPC UA – wurde dieser Standard nun an aktuelle Anforderungen angepasst. OPC UA erlaubt die plattformunabhängige, skalierbare und abgesicherte Kommunikation mit hohem Datendurchsatz zur Verbindung verschiedenster Systeme. Dies wird vor allem durch den eigens entwickelten Kommunikationsstack erreicht, der in Ansi-C, .Net oder Java umgesetzt sein kann und so auf verschiedenen Systemen ausführbar ist. Die Übertragung erfolgt durch ein binäres Protokoll basierend auf TCP/IP und hat damit einen geringen Overhead zur Übertragung von Daten. Der Kommunikationsstack ist auch verantwortlich für die Verschlüsselung und Signierung der Daten und verfügt somit über eine integrierte Sicherheit.

Ungeachtet der Vorteile, die sich aus den Neuerungen von OPC UA ergeben, ist es für eine allgemeingültige Kommunikation jedoch auch von Bedeutung, dass für entsprechende Anwendungsfälle eine einheitliche Semantik für die Kommunikation besteht. Diese ist für OPC UA, wie auch bei den meisten Kommunikationsmechanismen, die oberhalb der Feldebene aufzufinden sind, allerdings nur bedingt gegeben. Zwar lassen sich mit OPC UA Daten theoretisch semantisch beschreiben, allerdings fehlt es an eindeutigen Bezeichnungen und Zuordnungen von Maschinendaten. Möchte man beispielsweise einen Lagesollwert einer Maschinenachse auslesen, so ist der Wert abhängig von der Steuerung mit unterschiedlichen Bezeichnern abzufragen und damit nicht eindeutig. Zum Problem der fehlenden Semantik kommt hinzu, dass auch die Verbreitung von OPC UA noch zu wünschen übrig lässt. Denn während das klassische OPC im Bereich der industriellen Kommunikation häufig Verwendung findet, ist die neue und bessere OPC-UA-Technologie vor allem im Bereich der Werkzeugmaschinen und In-dustrieroboter eher selten anzufinden.

In Summe führen diese Defizite zu einem Mehraufwand in der Entwicklung, Pflege und Verwaltung von Automatisierungssoftware. Hat ein Hersteller beispielsweise Maschinen mit Steuerungssystemen verschiedener Anbieter im Portfolio, so macht dies die Entwicklung mehrerer Schnittstellen oder zumindest die Anpassung einer Schnittstelle erforderlich. Anders ausgedrückt: Die Verfügbarkeit eines allgemeingültigen, standardisierten Kommunikationsmechanismus mit definierter Semantik für Anwendungsfälle wie beispielsweise HMI, MES oder BDE/MDE würde letztendlich zu einer Verschlankung der Entwicklung und zur spürbaren Reduktion der Softwarekomplexität führen und somit großes Potenzial für Kosteneinsparungen sowie für bessere Software bergen.

Zur Lösung des Problems bezüglich fehlender semantischer Standards kann die Feldbus-Kommunikation als Vorbild dienen. So definieren die etablierten Konzepte wie beispielsweise Sercos, Profinet oder Ethercat eine Semantik, die für den Zugriff auf bestimmte Parameter angewendet wird. Durch die Zusammenfassung und Gliederung von Parametern werden Profile gebildet, die einen Satz an Funktionalität für definierte Gerätetypen beschreiben. Klassische Beispiele sind Profile für Antriebe und I/O-Module, aber auch „exotischere“ Lösungen wie etwa Energieprofile.

Eine Abbildung von Profilen ist mit OPC UA ebenfalls möglich. OPC UA bietet dafür so genannte Companion-Standards an. Dabei handelt es sich um Informationsmodelle, die über die klassisch verfügbaren Informationsmodelle wie „Data Access“, „Alarms&Events“ oder „Historical Data Access“ hinausgehen. Companion-Standards werden entweder durch Arbeitsgruppen unter dem Dach der OPC Foundation definiert – als Beispiel sei hier die Spezifikation für Analyzer Devices (ADI) genannt – oder in gemeinsamen Arbeitsgruppen beziehungsweise in Kooperationen der OPC Foundation und einer oder meh-reren anderen Organisationen – man denke etwa an das Informationsmodell OPC UA for IEC 61131-3 als Resultat der Zusammenarbeit mit PLCopen.

Als Beispiele für den sinnvollen Einsatz von Companion-Standards seien MTConnect und PLCopen für OPC UA erwähnt. MTConnect ist ein Standard für die Bereitstellung von Maschinendaten, der durch die gemeinnützige Organisa-tion MTConnect Institute entwickelt und gepflegt wird. Er definiert umfangreiche Informationsmodelle für Geräte und Komponenten (zum Beispiel Steuerungen, Achsen). Weiter werden Informationsmodelle für so genannte Assets zur Verfügung gestellt, mit denen der Zugriff auf prozessnahe Daten und beispielsweise Werkzeugdaten in standardisierter Form möglich ist. In Zusammenarbeit mit der OPC Foundation wurde MT-Connect in Form der Companion-Spezifikation MTConnectOpcUa in den OPC-UA-Standard eingebracht.

Mit dem PLCopen-Companion-Standard wurde schließlich eine Companion-Spezifikation geschaffen, die das PLCopen-Softwaremodell auf einen OPC-UA-Server-Adressraum definiert. Dadurch vereinfacht sich der Datenaustausch zwischen ERP, MES oder HMI-Systemen und der Steuerung deutlich, da die Datenzugriffe konsistent sind. Steuerungsprogramme werden unabhängig von der Steuerung und vom OPC-UA-Server immer identisch im OPC-UA-Adressraum umgesetzt. So lassen sich  beispielsweise Funktionsbausteine und viele weitere Informationen des Automatisierungsgerätes nach außen hin zur Verfügung stellen.

Ein Bereich, für den ein Companion-Standard allerdings noch aussteht, ist die Kommunikation zwischen HMI und NC-Steuerung. Gerade hier herrschen sehr heterogene Kommunikationsstrukturen vor. So bieten NC-Steuerung sehr unterschiedliche, oft proprietäre Schnittstellen. Zu nennen sind hier unter anderem Beckhoff ADS, Fanuc Focas, Heidenhain-DNC und Siemens DDE beziehungsweise CAP. Meist wird auch nur das HMI desselben Herstellers, eventuell in modifizierter Form, angebunden. Will ein Maschinenbauer jedoch Maschinen für verschiedene Kunden mit unterschiedlichen Steuerungen ausliefern oder ein eigenes Bediener-Interface anbinden, so wird erheblicher Mehraufwand generiert, da jede Schnittstelle implementiert und gepflegt werden muss. Selbst beim Einsatz von Steuerungen unterschiedlicher Hersteller mit gleichen Schnittstellen werden meist Anpassungen notwendig, da Bezeichner in der Regel nicht eindeutig sind.

Die Companion-Standards PLCopen und MTConnect lassen sich auf diesen Bereich nur bedingt anwenden: Während mit der PLCopen-Spezifikation ein Standard existiert, der sich auf SPS-An­wendungen konzentriert, ist MTConnect aufgrund der umfangreichen Informationsmodelle für beispielsweise Werkzeugdaten, Steuerungen und Achsen zwar prädestiniert für Werkzeug­maschinen, präsentiert sich jedoch als unidirektionaler Kommunikationsmechanismus und ermöglicht somit keinen schreibenden Zugriff auf eine NC-Steuerung. Aktuelle Umsetzungen nehmen deshalb entweder Mehraufwand durch die Implementierung und Pflege mehrerer Schnittstellen in Kauf oder nutzen eine zwischengelagerte Schnittstelle, um die verschiedenen Kommunikationsmechanismen auf eine Schnittstelle abbilden zu können.

Der Einsatz von OPC UA zuzüglich eines geeigneten Companion-Standards wäre in diesem Anwendungsfall demnach vorteilhaft. Durch den Einsatz von OPC UA als einheitliche Kommunikationsschnittstelle könnten in einem ersten Schritt die Anzahl an Schnittstellen reduziert werden. Die Verfügbarkeit eines Companion-Standards, der zumindest für gängige Maschinendaten wie beispielsweise die Betriebsartenanwahl, Achspositionen oder die Alarmquittierung eine eindeutige Adressierung und Beschreibung vorgibt, würde dann aufwendige Anpassungen überflüssig machen und die Austauschbarkeit von HMI oder Steuerungssystemen erheblich vereinfachen. Am ISW laufen diesbezüglich bereits Untersuchungen.