IoT-Basics: Was ist OPC UA?

| Autor / Redakteur: Stefan Hoppe / Jürgen Schreier

Ohne OPC UA kein Industrie 4.0! Nur mit standardisierter Kommunikation werden Feldgeräte, Maschinen und die Cloud zum Team.
Ohne OPC UA kein Industrie 4.0! Nur mit standardisierter Kommunikation werden Feldgeräte, Maschinen und die Cloud zum Team. (Bild: Pixabay / CC0)

Semantische Interoperabilität gilt als Schlüssel für Industrie 4.0. Standardisierte und sichere Kommunikation vom Feldgerät bis in die Cloud ist keine Vision mehr, sondern mit OPC UA umsetzbare Realität. Was es mit dem offenen Kommunikationsstandard auf sich hat, erfahren Sie in diesem Beitrag.

OPC UA (kurz für Open Platform Communications United Architecture) ist ein Datenaustauschstandard für die industrielle Kommunikation (Maschine-zu-Maschine- oder PC-zu-Maschine-Kommunikation). Der offene Schnittstellenstandard ist unabhängig vom Hersteller oder Systemlieferanten der Anwendung, von der Programmiersprache, in der die jeweilige Software programmiert wurde, und vom Betriebssystem, auf dem die Anwendung arbeitet.

Der größte Unterschied zu Vorgängerversionen liegt darin, dass Maschinendaten nicht nur transportiert, sondern auch maschinenlesbar semantisch beschrieben werden können. OPC UA ermöglicht den Zugriff auf Daten unterschiedlichster Art in vertikaler als auch horizontaler Richtung. Das Spektrum reicht von OPC-UA-Komponenten direkt integriert auf den Geräten und Steuerungen bzw. Maschinen und Anlagen über sogenannte Gateways bis hin zu aggregierenden Servern.

OPC UA und Industrie 4.0

Eine zentrale Herausforderung von Industrie 4.0 und dem industriellen Internet der Dinge (IIoT) ist der sichere, standardisierte Daten- und Informationsaustausch zwischen Geräten, Maschinen und Diensten auch aus verschiedenen Branchen. Das Reference Architecture Model for Industry 4.0 (RAMI 4.0) hat bereits im April 2015 den IEC-62541-Standard OPC Unified Architecture (OPC UA) [I.1] als einzige Empfehlung für die Umsetzung des Kommunikationslayers gelistet.

Die Grundvoraussetzung für den Einsatz von OPC UA zur Industrie-4.0-Kommunikation ist ein auf dem Internet Protokoll (IP) basierendes Netzwerk. Wer also mit dem Produktstempel "Industrie-4.0-fähig" werben will, muss OPC-UA-fähig sein (integriert oder per Gateway). Explizit wird die Eigenschaft der Informationsmodellierung von OPC UA hervorgehoben.

Service-orientierte Architektur OPC UA

Informationsmodellierung? Viele KMUs schalten hier bereits ab – schnell wird dann OPC UA mit anderen Protokollen verglichen und vermeintliche Einschränkungen in Einsatzszenarien werden festgestellt. Zunächst: Unbewusst liefert jeder Geräte- und Maschinenbauer bereits heute ein Informationsmodell: Daten und Schnittstellen sind ja bereits (über diverse Protokolle) verfügbar. Die neue Welt der Geräte unterstützt uns Menschen, schneller und einfacher die "Things" zu verstehen, da diese nun Dienste, aber vor allem deren Bedeutung anbieten. Gar nicht neu ist das in der IT-Welt – nun wandert aber diese Service-orientierte Architektur (SoA) bis in die "Things" selber vor.

Und genau da hilft OPC UA dem Framework für industrielle Interoperabilität. Geräte- und Maschinenbauer beschreiben die objektorientiere Informationen ihres Systems und definieren auch die Zugriffsrechte mit integrierter IT-Security dazu. Das deutsche BSI hat die Ergebnisse der OPC-UA-Sicherheitsanalyse [I.3] auf seinem Web veröffentlicht. Der Maschinenbauer bleibt damit Herr seiner Daten bzw. er kann sie gezielt und kontrolliert verteilen und somit auch an Big Data und der Analyse monetär teilhaben.

Um diese Daten nun auszutauschen, gibt es zwei Mechanismen:

  • ein Client-Server-Modell, in dem UA-Clients die dedizierten Dienste des UA-Servers nutzen;
  • ein Publisher-Subscriber-Modell, bei dem ein UA-Server konfigurierbare Untermengen von Informationen an eine beliebige Anzahl Zuhörer verfügbar macht.

Beide Mechanismen sind losgelöst vom eigentlichen Protokoll und daher stehen TCP und HTTPS für die Client-Server und UDP sowie AMQP und MQTT für das Subscriber-Modell zur Verfügung. Definitiv benötigt man beide Varianten:

  • 1. den Peer-to-peer-Kontext für den sicheren, bestätigten Transport – aber mit Einschränkungen in der Anzahl der Verbindungen;
  • 2. die Broadcast-Verteilung an alle unter dem Aspekt "Fire and forget".

OPC UA vereinigt Beides. Die Frage "OPC UA oder AMQP oder MQTT" stellt sich somit aus OPC-Foundation-Sicht nicht – auch OPC UA kann das liefern. Ein Ressourcen-eingeschränktes Gerät mit "nur-MQTT" sollte aber seine Daten im "OPC UA via MQTT"-Informationsmodell-Format abfeuern.

„Praxishandbuch OPC UA“ Mit diesem Fachbuch gibt das Autorenteam rund um Dr. Miriam Schleipen neben einem grundlegenden Überblick über den Kommunikationsstandard OPC UA auch eine Übersicht, welche Tools bei der Umsetzung helfen. Das "Praxishandbuch OPC UA. Grundlagen – Implementierung – Nachrüstung – Praxisbeispiele" bereitet Sie auf die zukunftsträchtige Technologie mit Uses Cases, Lessons leraned und Best Practises vor. Das Fachbuch „OPC UA“ kann hier versandkostenfrei oder als eBook bestellt werden.

Welche Daten und Dienste liefert ein Gerät oder eine Maschine?

Von "außen" betrachtet soll aus der Kommunikationssicht der Zugriff auf Daten und Dienste der Maschine zunächst vollkommen sicher im Sinne der IT-Sicherheit definiert sein. OPC UA bietet hier nicht nur die gängigen IT-Mechanismen zur Authentifizierung, Signierung und Verschlüsselung im Zugriff.

Transport, Security, Zugriffsrechte

Die eigentliche Transportschicht kann in Zukunft jederzeit durch weitere Protokolle erweitert werden. Die Unabhängigkeit vom physikalischen Transportmedium und dem Transportprotokoll ist ein ganz entscheidender Vorteil von OPC UA gegenüber anderen, reinen IoT-Datenprotokollen. Der Geräte- bzw. Maschinenbauer muss sich nicht darum kümmern, sondern nur die Daten und Dienste gesichert bereitstellen.

Modellierung

Maschinen müssen ihre Daten und Dienste maschinenlesbar anbieten, wenn Maschinen und Dienste miteinander sprechen sollen und auch das Engineering durch den Menschen möglichst einfach vonstattengehen soll. Die semantische Festlegung der Schnittstellen kann von den entsprechenden Fachverbänden mit OPC UA modelliert werden. Als Beispiel haben die Unternehmen Harting und Siemens dies für die AutoID-Industrie vorangetrieben und in kurzer Zeit die Spezifikation der Schnittstelle, aber auch die Umsetzung realisiert: RFID-Reader mit integriertem OPC UA mit Unterstützung der AutoID Companion Spec sind lieferbar ab Lager. OPC UA Clients, verfügbar als PLCopen-Bausteine in einer SPS-Steuerung oder einer Visualisierung oder aus der Cloud, können nun mit extrem einfachem Engineering den identischen Zugriff auf die Geräte beider Hersteller umsetzen.

Keine Differenzierung mit OPC UA?

Wenn RFID-Reader unterschiedlicher Hersteller ein identisches Interface bieten – bleibt dann die Differenzierung der Geräte nicht auf der Strecke? Die Antwort lautet: Nein. Denn neben dem standardisierten Informationsmodell kann jeder Gerätehersteller seine eigenen Modelle quasi als "Extra" parallel anbieten. Diese Kombination aus genormtem "Geräte-Standard" und der "Geräte-Individualität" ist sinnvoll und ideal geeignet, um miteinander konkurrierenden Geräteherstellern die Chance zu geben, sich zu einigen, aber trotzdem ihren Mehrwert nach außen abgreifbar zur Verfügung zu stellen. Wichtig bleibt aber: Auf alle Schnittstellen – die standardisierten und die herstellerspezifischen – greift ein OPC-UA-Client mit dem gleichen Mechanismus zu.

Diese Schicht der Modellierung der Daten und Dienste ist der eigentliche Schlüssel für Industrie 4.0 und der wesentliche Unterschied zum "nur IoT-Daten pushen" in die Cloud: Erkannt haben das diverse Organisationen und haben so ihre marktspezifischen Informationsmodelle mit OPC UA modelliert – eine Übersicht findet man im Web der OPC Foundation [I.4]. Übrigens: Eine Mitgliedschaft bei der herstellerunabhängigen Non-Profit-Organisation ist für den Einsatz der OPC-UA Technologie oder der Erstellung von OPC-UA Produkten nicht erforderlich.

Dienste

Unabhängig von der Bestimmung des Gerätes oder der Maschine sind bestimmte Dienste immer vorhanden; nur einige sollen hier vorgestellt werden:

  • Datendienste liefern heute an Visualisierungen die benötigen Live-Daten (die IT-Welt spricht hier von Realtime-Daten – nicht zu verwechseln mit deterministischen Daten aus der harten Echtzeit) der Maschine. Auch historische Daten aus der Vergangenheit oder Alarme, wenn bestimmte Wertlevel über- oder unterschritten werden, gehören in diese Kategorie der Dienste.
  • Administration-Dienste wirken eher auf die Funktionalität der Geräte: Eine SPS-Steuerung kann darüber definiert zwischen Stopp- und Start-Zustand geschaltet werden (dieser Dienst wurde z.B. von der PLCopen & OPCF-Arbeitsgruppe definiert), um z.B. neue Logik-Ablaufprogramme per OPC-UA-Filetransfer in die Steuerung zu transferieren. Eine Verteilung einer überarbeiteten SPS-Logik in viele weltweit verteilte Anwendungen wie Windturbinen ist damit einfach und vor allem sicher realisierbar. Das Senden und Laden von Dateien dient auch dezentralen SmartMeter-Anwendungen.
  • Monitoring-Dienste können zu jedem Zeitpunkt Informationen über das Gerät selber liefern, wie z.B. die Temperatur der CPU oder deren Auslastung, die Lüfterdrehzahl usw.
  • Applikationsdienste bzw. Maschinendienste: Der Geräte- bzw. Maschinenbauer kann hier einfach seine eigenen Dienste nach außen definieren – in verketteten Maschinen in der Holzbranche z.B. "Auslesen Vorschubgeschwindigkeit" oder "Betriebsbereitschaft" ebenso wie in ganz anderen Branchen wie einer intelligenten Kamera "Bild aufnehmen und auswerten".

Betriebssystem und Realtime

Welches Betriebssystem in einer Maschine werkelt oder ob gegebenenfalls eine spezielle Echtzeitrealisierung implementiert ist, spielt keine Rolle aus Sicht einer externen Geräte- und Maschinenkommunikation: Nichts ist davon nach außen – in einem Industrie-4.0-kompatiblen Gerät – sichtbar. Die Auswahl eines Betriebssystems, z.B. eines Steuerungsherstellers, unterliegt anderen Kriterien und bietet die eigentliche Basis für die Differenzierung der Maschinenfunktionalität:

Lange Supportverfügbarkeit, Freistellung von IP-Policies, eine exzellente Software-Toolkette für einfaches Engineering, skalierbarer Einsatz vom kleinsten Embedded-System bis in Many-Multi-Core-Systeme sind z.B. Faktoren, die den einen Steuerungshersteller vom anderen unterscheiden.

Skalierbarkeit

OPC UA ist skalierbar von kleinen Geräten bis in die IT-Ebene. Bereits im Jahr 2012 hat das Fraunhofer-Institut Lemgo einen OPC-UA-Server auf einen 10-kB-Footprint abgespeckt, um ihn in kleinsten Sensoren auf Chips zu integrieren.

Die Firma Areva hat einen OPC-UA-Server in den Sensor von Überwachungsgeräten für Armaturen und deren elektrische Antriebe integriert (Bild 2.3). Diese Lösung wird in der Nuklearbranche zur Überwachung kritischer Systeme in entfernten Umgebungen eingesetzt. Neben der Zuverlässigkeit der Daten ist daher auch die integrierte Sicherheit ein wesentlicher Aspekt. Der OPC-UA-Server benötigt hier eine Speicherauslastung beginnend bei 240 kByte Flash und 35 kByte RAM.

Adaptierung

Als "Early Adapter" haben Beckhoff und Siemens den OPC-UA-Standard bereits im Jahr 2008 unterstützt, in Geräte integriert und ab Lager verkauft. Heute unterstützen nahezu alle SPS-, Visualisierungs- und MES-Hersteller diesen Standard. Die Anbindung einer neuen Produktionsmaschine dauert somit nicht mehr Tage – mit erheblichem Integrations- und Testaufwand –, sondern ist in weniger als einer Stunde umsetzbar. OPC UA wächst sowohl in kleinste Geräte, aber auch in die Cloud weiter.

Seit Mai 2015 sind die OPC-UA-Spezifikationen öffentlich verfügbar und die OPC Foundation hat die Öffnung von Stacks als OpenSource für Evaluierungszwecke Im Jahr 2016 umgesetzt. Für die professionelle OPC-UA-Integration in industrielle Produkte bieten Firmen Toolkits und Beratung an.

Praktische Anwendungen von OPC UA

Anwendung vertikal: Energie-Monitoring und Big Data

Mit Energie-Monitoring in dezentralen Liegenschaften sind Betreiber in der Lage, sämtliche Anforderungen zur optimierten, energetischen Betriebsführung umzusetzen. Als Beispiel werden in Städten wie Aachen mit deren Gebäudemanagement bis zu 2000 Liegenschaften und mehr verwaltet. Das Energie-Monitoring-System "e2watch der regio iT gesellschaft für informationstechnologie mbh" wurde in Kooperation mit dem Gebäudemanagement der Stadt Aachen entwickelt [I.7].

Als dezentrales Gerät wurde eine Embedded-Kleinststeuerung verwendet, die die Messdaten sammelt, zunächst lokal puffert und zu frei konfigurierbaren Zeitpunkten mit der Cloud synchronisiert (Bild 6). Als Transportweg wird OPC UA als IT-Standard mit integrierter Security genutzt. Die Steuerung pusht dabei als OPC UA Client die Daten als "Historic Access"-Daten direkt in die "Big-Data-Managementlösung" in der Cloud. Dort findet eine weitere Analyse bzw. Auswertung der Daten statt, auf die Betreiber und Nutzer der Liegenschaften mit einer internetbasierten Visualisierung zugreifen können.

Ein weiterer Nutzen besteht darin, dass Kennwertvergleiche und Benchmarking zwischen gleichwertigen Liegenschaften vorgenommen werden können, um ein Energie-Verbrauchscontrolling durchzuführen. Durch den Zugang zu den ausgewerteten Daten wird auch eine positive Beeinflussung des Nutzerverhaltens erwartet.

Das adressierbare Kundenpotenzial dieser Lösung ist auf viele Branchen übertragbar: Daten sammeln, puffern und weiterleiten sind verbreitete Aufgaben.

Anwendung horizontal: M2M in der Wasserwirtschaft

Der Zweckverband Wasser und Abwasser Vogtland bestätigt die finanziellen Einsparpotenziale als wesentliches Resultat einer kompletten Kommunikationsarchitektur, basierend auf OPC UA. Für die wasser- und abwassertechnische Versorgung (Wasserversorgung von 40 Städten und Gemeinden, Abwasserentsorgung in 37 Städten und Gemeinden mit zusammen 240 000 Einwohnern) sind mehr als 550 Anlagen auf einer Fläche von 1400 km² verteilt.

Die Zahl der Anlagen umfasst Wasserwerke, Pumpanlagen, Hochbehälter, Kläranlagen und Kanal-Entlastungsbauwerke. In der Vergangenheit wurden Informationen nur zentral in der Leitwarte gesammelt, um dort teilweise kostenintensive Serviceeinsätze zu koordinieren. Spezielle Anforderungen, wie die Pufferung von Prozessdaten bei Ausfall des Kommunikationstransportes und der Einsatz vieler verschiedener Protokolle mit unterschiedlichen Konfigurationen, haben über Jahre zu einem hohen Pflegeaufwand und entsprechenden Kosten geführt.

Durch die Abschaffung der proprietären Kommunikationsprotokolle und die Installation einer dezentralen, vernetzten Intelligenz wurden der Engineering- und Serviceaufwand reduziert und damit die Kosten gesenkt – und dies bei gleichzeitiger Erhöhung der IT-Sicherheit und Verfügbarkeit der Daten. Unter Nutzung von OPC UA für die direkte M2M-Kommunikation sollten alle Geräte der dezentralen Liegenschaften autark agieren, die kleinsten Embedded-Steuerungen untereinander intelligent vernetzt sein und direkt miteinander kommunizieren.

Damit stellt diese Anwendung eine erste reale Umsetzung der Ergebnisse der Zusammenarbeit der PLCopen- und der OPC-Arbeitsgruppe dar: Reale Objekte (z.B. eine Pumpe) wurden in der IEC-61131-3-SPS-Steuerung als komplexes Objekt mit Interaktionsmöglichkeiten modelliert. Durch den in die Steuerung integrierten OPC-UA-Server standen diese Objekte automatisch für semantische Interoperabilität als komplexe Datenstruktur der Außenwelt zur Verfügung.

Inhalt des Artikels:

Kommentar zu diesem Artikel abgeben

Schreiben Sie uns hier Ihre Meinung ...
(nicht registrierter User)

Zur Wahrung unserer Interessen speichern wir zusätzlich zu den o.g. Informationen die IP-Adresse. Dies dient ausschließlich dem Zweck, dass Sie als Urheber des Kommentars identifiziert werden können. Rechtliche Grundlage ist die Wahrung berechtigter Interessen gem. Art 6 Abs 1 lit. f) DSGVO.
Kommentar abschicken
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 45732011 / Industrie 4.0)