Funktionale Sicherheit und hohe Verfügbarkeit stehen in der klassischen Automatisierungspyramide im Vordergrund. Dies gewährleistet zwar einerseits langjährige Betriebssicherheit, macht es aber andererseits für die Prozessautomatisierung schwierig, zeitnah und kostengünstig neue Technologien zu adaptieren und vor allem an der digitalen Transformation teilzunehmen. Gerade im Hinblick auf die rasante Entwicklung rund um IoT und Industrie 4.0 wird diese ‚Trägheit‘ von Beteiligten als schmerzhaft wahrgenommen. Um dem entgegenzuwirken, hat die NAMUR 2016 mit der Konzeptionierung einer offenen Systemstruktur begonnen, der sogenannten NAMUR Open Architecture (NOA).

Die NAMUR Open Architecture

Die NOA-Pyramide der NAMUR: Das Konzept ermöglicht innovative Lösungen sowohl für neue als auch insbesondere für bestehende Anlagen, da der Kern der Prozessautomatisierung weitgehend unangetastet bleibt.

© Wetcon

Ziel der NOA ist die Erweiterung der bestehenden Automatisierungsstruktur, sodass eine flexible Umsetzung von Industrie 4.0 für Neu- und Bestandsanlagen möglich wird. Dabei sollen die neuen Methoden auf bestehenden, offenen Standards aufsetzen, die Sicherheit der bestehenden Anlagen nicht gefährden, rasche und bezahlbare Implementierungen möglich machen und additiv zur bewährten Automatisierungsarchitektur eingesetzt werden.

NOA trennt Monitoring- und Optimierungsaufgaben von der Kernautomatisierung. Dabei werden die Daten der Kernautomatisierung über offene Schnittstellen in die Systemwelt für Monitoring und Optimierungsaufgaben übertragen. Als eine Option für solch eine offene Schnittstelle wurde OPC UA ausgewählt – in der Industrie 4.0 als 
wichtige Komponente für den Informationsaustausch angesehen. Zusätzliche Sensoren für Monitoring- und Optimierungsaufgaben lassen sich einfach in die offene Systemwelt integrieren, während die Kernautomatisierung weitgehend unverändert belassen wird. Dies öffnet Unternehmen die Tür zur Cloud und ermöglicht es, Daten und Geräte remote zu verwalten, Einblicke zu gewinnen oder maschinelles Lernen einzusetzen.

Soweit die Theorie. Doch welche Lösungen bestehen heute, um die NOA in die Praxis zu überführen?

FITS-Lösung von der FDT Group

Einen konkreten Ansatz gibt es von der FDT Group, einer internationalen gemeinnützigen Organisation, deren Hauptzweck es ist, eine offene Schnittstelle für die Integration von Feldgeräten mit Engineering-, Automatisierungs- und Resourcenmanagementsystemen als IEC-Standard bereitzustellen. Die FDT-Spezifikation (Field Device Tool) teilt eine Automatisierungslösung in drei Komponenten auf und definiert deren Verantwortungsgebiete sowie die Softwareschnittstellen untereinander:

• eine Software-Anwendung wie ein Asset-Management- oder Prozessleitsystem (auch FDT-Rahmenanwendung genannt)
• Gerätetreiber, die die Rolle des ‚Digital Twin‘ eines Feldgerätes einnehmen (Device Type Manager, DTM)
• Kommunikationstreiber, die die Hardware repräsentieren, die nötig ist, um die Feldgeräte mit der Automatisierungssoftware zu verbinden

Aufgaben der Rahmenanwendung sind hauptsächlich die Verwaltung der Feldgeräte-Instanzen, das Speichern der jeweiligen Projektdaten, die Benutzerrechteverwaltung, das Gerätekatalog-Management und das Scannen nach verbundener Hardware. Die von den Geräteherstellern zur Verfügung gestellten DTM-Gerätetreiber enthalten benutzerfreundliche, grafische Bedienoberflächen, mit denen ein Zugriff auf spezifische Gerätefunktionen und -Parameter möglich ist. Das DTM kann von der Rahmenanwendung geöffnet, kontrolliert und wieder geschlossen werden.

Üblicherweise werden Rahmenanwendung, Geräte-DTMs und Kommunikationstreiber einfach auf einem Notebook installiert; darüber lassen sich anschließend unterschiedlichste Feldgeräte konfigurieren und parametrieren, ohne dass dafür mehrere proprietäre Tools der Hersteller zu installieren sind. Die erste FDT-Spezifikation wurde bereits 2001 veröffentlicht, mittlerweile ist FDT als Geräteintegrationstechnologie international weit verbreitet.

2018 hat die FDT Group die Einführung einer Industrial-Internet-of-Things(IIoT)-Server-Architektur namens FDT IIoT Server – FITS – angekündigt, die eine flexible Plattform für verschiedene IIoT-basierte Lösungen darstellen soll. Grundlage für diese Entwicklung waren umfangreiche Befragungen von Endkunden und Herstellern – zentrale Fragen waren dabei  die Integration von OPC UA sowie die Verwendung mobiler Endgeräte für das Feldgeräte-Management.

Der plattformunabhängige Ansatz sowie die Verwendung von .NET Core ermöglicht die Applikation auf Microsoft-, Linux- und macOS-Betriebssystemen, und bildet die Brücke von bisherigen FDT-Basisinstallationen hin zur Unterstützung von IIoT und Industrie 4.0. Im Mittelpunkt der FITS-Architektur steht ein zentraler FDT-Server, an den ein OPC-UA-Server und ein Webserver angegliedert sind. Der OPC-UA-Server bietet beglaubigten OPC-UA-Clients den Zugang zu DTM-Daten, der Webserver stellt Browser-basierten Clients wie Smartphones, Tablets oder PCs von den DTMs bereitgestellte Web UIs zur Verfügung. Auch Apps lassen sich damit unterstützen. Der FITS-Standard soll Ende 2019 auf den Markt kommen.

OPC UA als Basis

Pactware-OPC-UA-Plugin mit Azure-IoT-Central-Anbindung. Durch ein Plugin wird Pactware um die Funktionalität eines OPC-UA-Servers ­erweitert, über den sich Prozesswerte auslesen und zu verschiedenen Cloud-Lösungen hin übertragen lassen.

© Wetcon

Sowohl die NAMUR als auch die FITS-Lösung setzen auf die OPC Unified Architecture, kurz OPC UA. Das OPC-UA-Protokoll ermöglicht einen standardisierten, sicheren und zuverlässigen plattformunabhängigen Datenaustausch zwischen Geräten, Maschinen und Diensten aus unterschiedlichen Industrien. Angewendet wird es in Komponenten aller industriellen Bereiche – von Sensoren, Aktuatoren und Kontrollsystemen über Manufacturing-Execution- und Enterprise-Resource-Planning Systeme bis in die Cloud.

Allgemein wird es als Schlüsselkommunikations- und Datenmodellierungs-Technologie in der Industrie 4.0 anerkannt – das Reference Architecture Model for Industry 4.0 etwa hat OPC UA als einzige Empfehlung für die Umsetzung einer Kommunikationsschicht genannt. Die Cloud-Computing-Plattformen Microsoft Azure und Amazon Web Services bieten bereits von sich aus OPC-UA-Adapter an, die mit einem OPC-UA-Server verbunden werden und relevante Informationen direkt in deren IoT-Lösungen übertragen. Für Googles Cloud-Computing-Plattform gibt es aktuell eine Drittanbieter-Komponente, die diesen Zweck erfüllt.

DI und FDT OPC UA Model

OPC-UA-Informationsmodelle enthalten Definitionen von Typen und ihrer Beziehungen untereinander, ähnlich der objektorientierten Programmierung. Dabei gibt es generischere Informationsmodelle wie etwa das Informationsmodell für Geräte (OPC UA Device Integration Model). Dieses definiert, wie die Informationen eines Geräts auf OPC-UA-Objekte, -Methoden und -Variablen abgebildet werden, unabhängig von seinen zugrundeliegenden Protokollen. Darüber hinaus erlaubt es angebundenen Clients, Geräte zu konfigurieren, zu operieren oder Fehler zu beheben, ohne Wissen über die Geräte-Interna besitzen zu müssen. Das OPC UA Device Integration Model fungiert zudem als Basis für weitere, spezialisiertere Informationsmodelle, wie beispielsweise OPC UA for Analyzer Devices (ADI) oder Field Device Integration (FDI).

Speziell für FITS wurde in einer Kooperation zwischen der FDT Group und der OPC Foundation das sogenannte OPC UA Information Model for FDT Technology entwickelt, das DTM-Informationen nach OPC UA abbildet. Hierbei wurden verschiedene einfache Use Cases ausgewählt und berücksichtigt, die sich kombinieren lassen, und so auch komplexere Anwendungsfälle erlauben.

Pactware avanciert zum OPC-UA-Server

Als FDT-Rahmenanwendung beinhaltet Pactware ebenso wie FITS eine FDT-Server-Komponente, über die die Geräte-DTMs angesprochen werden. Zudem stellt Pactware ein Plugin-System zur Verfügung, mit dem sich seine Funktion fast beliebig erweitern lässt. Damit wird ein Einstiegspunkt für einen OPC-UA-Server greifbar. Doch wie sieht die Entwicklung eines OPC-UA-Plugins für Pactware im Detail aus?

Die Geräteparameter lassen sich über verschiedene FDT-Schnittstellen auslesen oder modifizieren, die von den Geräte-DTMs bereitgestellt werden. Dies wären beispielsweise

• IDtmSingleDeviceDataAccess zum Auslesen und Schreiben von Online-Geräteparametern
• IDtmSingleInstanceDataAccess zum Auslesen und Schreiben von Offline-Geräteparametern
• IDtmParameter als Ergänzung für die Offline-Geräteparameter
• IDtmOnlineParameter für Upload und Download von Geräteparametern.
   

‚Quickstart Reference Client‘ aus dem OPC UA .NET Stack, verbunden mit dem OPC-UA-Pactware-Plugin. Der quelloffene OPC-UA-Client zeigt hier ausschnitts­weise die vom Plugin bereitgestellten OPC-UA-Knoten am Beispiel eines optischen Distanzmessers.

© Wetcon

Das Pactware-Plugin kann diese FDT-Schnittstellen ansprechen und die Geräteparameter sowie weitere Daten und Funktionalitäten in einem eigenen OPC-UA-Adressraum auf dem OPC-UA-Server bereitstellen. Als Auslöser für das Einlesen und Bereitstellen der Daten eines Feldgeräts ist es möglich, sich innerhalb des Plugins auf bestimmte Pactware-Ereignisse zu registrieren, beispielsweise, wenn ein Projekt geöffnet oder wenn ein neues DTM hinzugefügt wird. Im letzteren Fall werden die Daten und Geräteparameter der geladenen DTMs ausgelesen und als Objekte im OPC-UA-Server hinzugefügt. Dabei sind die Geräte-Objekte gemäß Device Integration Model einem DeviceSet-Knoten untergeordnet und stellen jeweils weitere Subtypen und Variablen bereit – die Geräteparameter befinden sich als Variablen unter einem ParameterSet-Knoten. Der eigentliche Wert eines Geräteparameters wird dann zu dem Zeitpunkt über die entsprechende DTM-Schnittstelle ausgelesen, an dem ein OPC-UA-Client diesen anfordert.

Die OPC Foundation bietet einen offiziellen quelloffenen .NET-Stack an, der Referenz-Implementierungen von OPC-UA-Clients- und -Servern sowie diverse Beispiel-Anwendungen beinhaltet. Damit lassen sich OPC-UA-Clients und -Server entwickeln. Eine darauf aufsetzende und bereits verfügbare Open-Source-Implementierung eines solchen Pactware-Plugins, die zudem das bereits angesprochene OPC UA Device Integration Model umsetzt, findet sich auf https://github.com/wetcon.

Anbindung an Microsoft IoT Central

Übertragung der Messwerte eines IO-Link-Distanzmessers nach Azure IoT Central. Periodisch werden die Messwerte über den OPC-UA-Server ausgelesen und als Telemetriedaten an die Cloud übertragen. Schaubilder zeigen darin deren zeitliche Entwicklung.

© Wetcon

Ein OPC-UA-Client kann nun den Prozesswert eines Feldgerätes in regelmäßigen Zeitabständen auslesen und beispielsweise nach Azure IoT Central übertragen. IoT Central ist eine IoT-SaaS(Software as a Service)-Lösung, mit Fokus auf einfacher Bedienung, Sicherheit und Skalierbarkeit, die keine Cloud-Kenntnisse erfordert. Geräte sowie deren Prozesswerte und Eigenschaften lassen sich über eine webbasierte Bedienoberfläche anlegen. Für die Übertragung der realen Geräteparameter nach IoT Central können verschiedene Protokolle verwendet werden – unter anderem MQTT oder HTTP. Microsoft stellt zu diesem Zweck SDKs für verschiedene Programmiersprachen zur Verfügung. Schritt-für-Schritt-Anleitungen sowie Quelltexte von Konsolen-Anwendungen, die Feldgeräte-Parameter nach Azure IoT oder nach AWS IoT übertragen, sind in der Open-Source-Implementierung inbegriffen.

Alternativ lassen sich mit Pactware über ein weiteres Plugin auch ohne OPC-UA-Server Geräteparameter direkt in die Cloud übertragen. Das Produkt ‚fielddevice.cloud‘ geht genau diesen Weg. Im Vergleich zu IoT Central ist dort kein explizites Anlegen von Geräte-Informationen notwendig; zudem sind dort die Möglichkeiten der Visualisierung der Gerätedaten durch benutzerspezifische Microsoft Power BI Reports vielfältiger.

Autor
Jonas Jelli arbeitet als Software Architect bei Wetcon in Senden bei Neu-Ulm.