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.

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.

© ISW

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.

OPC UA zur Anbindung von HMI-Systemen

Der Schwerpunkt der Forschungs- und Entwicklungstätigkeit des ISW liegt in der Konzeption und Anwendung steuerungstechnischer Mittel zur Automatisierung von Werkzeugmaschinen und anderen Produktionseinrichtungen. Im Rahmen der Aufgabenstellungen ergibt sich immer wieder die Notwendigkeit, grafische Bedienoberflächen oder Auswertesoftware an Steuerungssysteme anzubinden.

rot: klassische Kommunikationsstruktur (KS); gelb: vereinfachte KS durch vereinheitlichende herstellerspezifische Schnittstelle; grün: KS durch standardisierte Schnittstelle und einheitliche Semantik

© ISW

Für ein Kooperationsprojekts entwickelt das ISW beispielsweise die Steuerung und Regelung sowie das HMI einer neuartigen Maschine für die dynamische Materialprüfung. Die Materialversuche variieren in der Ausführungsdauer von wenigen Minuten bis zu mehreren Wochen. Um die Versuche zu dokumentieren und die Haltbarkeit der getesteten Materialien und Bauteile zu belegen, müssen die Messwerte aus der Weg- und Kraftmessung und aus weiteren Messungen peripherer Sensorik hochfrequent – aktuell mit 1 bis 2 kHz – erfasst werden. Dies hat zur Folge, dass sehr viele Messdaten anfallen. Außerdem ist zu beachten, dass die Ergebnisse der Schwingprüfung entscheidend sind für die Sicherheit eines Produkts. Die Daten müssen also gegen Manipulation geschützt werden.

Bisherige Umsetzungen zur Steuerung und Regelung solcher Anlagen basieren auf spezieller Hardware und stellen somit ein abgeschlossenes System dar. Im Rahmen des Projekts wurde versucht, eine möglichst hohe System-Offenheit zu realisieren, um die Erweiterung durch Hardware und Software einfach und günstig zu ermöglichen. Zum Einsatz kamen daher Standard-Steuerungskomponenten, um die Kosten zu senken und die Integration von weiteren Sensoren und Aktoren über die Hinzunahme von Feldbus-Klemmen zu ermöglichen. Das HMI wurde neu entwickelt und basiert auf OPC UA, um die Anbindung weiterer Software über eine definierte Schnittstelle zu erlauben sowie den nötigen Durchsatz zur Übertragung aller Messwerte zu erreichen.

OPC UA für Smart Devices

Ein weiteres Anwendungsfeld für OPC UA sind mobile Geräte wie Smartphones und Tablet-PCs. Im Alltag bereits fest etabliert, kommen diese Smart Devices auch in der Automatisierungstechnik immer mehr zum Einsatz – etwa in den Bereichen Projektplanung und -opti­mierung, Fernwartung, Diagnose, SCADA- und HMI-Systeme. Zwar liegt die Anzahl an Apps, sprich von Software-Anwendungen, welche die Funktionalität von Smart Devices erweitern, noch weit hinter der Anzahl der Apps im IT- und Consumer-Bereich zurück; ein Wachstumstrend ist jedoch unverkennbar.

Monitoring als Beispielanwendung für Smart Devices, die über OPC UA mit Steuerungssystemen kommuniziert.

© ISW

Die Kommunikation betreffend ist festzustellen, dass Apps – sofern sie eine Verbindung zum Steuerungssystem aufbauen – auf unterschiedlichen Kommunikationsmechanismen basieren. Am weitesten verbreitet sind dabei noch Modbus-TCP oder Ethernet IP; eine allgemeingültige, standardisierte Form der Kommunikation im Bereich der Apps gibt es jedoch nicht. Dies erschwert die Austauschbarkeit und Übertragbarkeit der Anwendungen. Mobile Anwendungen können daher oft nur mit den Steuerungssystemen einzelner Hersteller kommunizieren oder implementieren mehrere Kommunikationsschnittstellen für die herstellerübergreifende Kommunikation. Sicherheitsmechanismen sind meist Fehlanzeige. Weiter ist festzustellen, dass kaum Apps für den Bereich der Werkzeugmaschinen und Industrieroboter zur Verfügung stehen, abgesehen von Hilfsanwendungen ohne Kommunikation zum Steuerungssystem. Die meisten Anwendungen mit Kommunikation zum Steuerungssystem konzentrieren sich auf Speicherprogrammierbare Steuerungen, was sicherlich auch an der konservativen Haltung der Werkzeugmaschinen- und Steuerungshersteller liegt.

Am ISW wurde deshalb eine Anwendung entwickelt, die auf Basis von OPC UA eine herstellerunabhängige Kommunikation zu Steuerungssystemen von Werkzeugmaschinen, Industrierobotern und Automatisierungssystemen im Allgemeinen aufbauen kann. Die Anwendung erlaubt auf Basis einer grafischen Bedienoberfläche das Herstellen und Trennen einer Verbindung zum Automatisierungsgerät, den lesenden und schreibenden Zugriff auf Prozessvariablen, sofern deren Verfügbarkeit explizit erlaubt wird, sowie die Nutzung sogenannter Subscriptions, also das „Abonnieren“ von Prozessvariablen zur automischen Erkennung und Übertragung von Werte-Änderungen.

Bei der Konzeption der Anwendung wurde großer Wert auf die Modularisierung der Anwendung gelegt. Der OPC-UA-Client ist in Form eines Remote-Services implementiert und von der grafischen Bedienoberfläche entkoppelt. Die Kommunikation zwischen dem OPC-UA-Client und der Bedienoberfläche erfolgt über eine definierte Schnittstelle, beschrieben durch die Android Interface Definition Language (AIDL). Durch die Trennung von grafischer Bedienoberfläche und Funktionalität sowie durch die Auslagerung des OPC-UA-Clients in einen Remote-Service ist die Basisanwendung erweiterbar. Das heißt, es besteht die Möglichkeit, weitere Funktionalität mit Zugriff auf den OPC-UA-Remote-Service zu erstellen und in die App zu integrieren.

Vorteilhaft am Einsatz von OPC UA ist hier die Möglichkeit, nicht nur steuerungsseitig herstellerunabhängig zu agieren, sondern aufgrund der Plattform-Unabhängigkeit von OPC UA auch Smart Devices unterschiedlicher Hersteller und mit unterschiedlichen Betriebssystemen einzusetzen. Weiter ist gerade im Bereich der drahtlosen Kommunikation die Anforderung an eine abgesicherte Verbindung besonders relevant. OPC UA bietet durch die in den Kommunikationsstack integrierten Sicherheitsmechanismen zur Verschlüsselung und Signierung von Daten eine Lösung, die keinen Mehraufwand bei der Umsetzung generiert oder den Einsatz von weiteren Tools erfordert.

Autor: Matthias Keinert ist wissenschaftlicher Mitarbeiter am ISW der Universität Stuttgart.