Suchen

Integration eines OPC UA-Servers in ein Profinet-Device

| Autor / Redakteur: Andreas Grüne, Martin Schürmann und André Sonnwald * / Gerd Kucera

TPS-1 ist eine Single-Chip-Geräteschnittstelle für Profinet zur schnellen, unkomplizierten Integration in das Automatisierungsgerät. Der Artikel erklärt die Integration des Chips in das Device.

Firmen zum Thema

Bild 1: Anwendung eines Raspberry PI als Profinet-Controller und TSP-1 Device mit OPC UA-Server.
Bild 1: Anwendung eines Raspberry PI als Profinet-Controller und TSP-1 Device mit OPC UA-Server.
(Bild: Phoenix Contact)

Ein essentieller Bestandteil zur digitalen Vernetzung der Automatisierung in der Industrie-4.0-Umgebung ist OPC UA. Um echtzeitkritische Prozess- und Steuerungsdaten zu verarbeiten, braucht die Datenübertragung in Industrie-4.0-Anwendungen keine neue industrielle Kommunikationslösung. Denn tatsächlich geht es um den Datenaustausch mit anderen Systemen außerhalb der reinen Steuerungsebene, beispielsweise in der Hallen- oder Leitebene respektive der Produktionsplanung. Hier kann OPC UA die notwendige Datenschnittstelle vereinheitlicht über Ethernet zur Verfügung stellen.

Der IEC-Standard Open Platform Communication (OPC) Unified Architecture (UA) von der OPC Foundation kommt im Umfeld von Profinet immer häufiger als zusätzliche Übertragungsschnittstelle zur Anwendung. Die OPC Foundation ist ein Industriekonsortium, das Standards für die offene Konnektivität industrieller Automatisierungsgeräte und -systeme wie Industrie- und Prozesssteuerung erstellt und verwaltet. Profinet (Process Field Network) ist der offene Industrial-Ethernet-Standard der PROFIBUS-Nutzerorganisation e.V. (PNO) für die Automatisierung.

Der OPC UA-Server kann über die vorhandene Profinet-Infrastruktur Daten und Informationen der Automatisierungsgeräte zugänglich machen. Entsprechende Anforderungen ergeben sich aus der Einführung der Industrie-4.0-Kommunikation. Es handelt sich also nicht darum, einen neuen Standard für Prozess- und Steuerungsaufgaben zu definieren, sondern mit dem Konzept einer serviceorientierten Architektur (kurz SOA) entsprechende Informationsmodelle zur Beschreibung von Geräten und ihren Fähigkeiten bereitzustellen (Controller-to-Controller/Leitebene/Cloud).

In diesem Umfeld finden derzeit viele Entwicklungen und Normungen statt. Aktuell wird für Profinet eine Companion Specification erarbeitet, wobei das nachfolgende Beispiel auf dem bisherigen Stand aufsetzt. Die Companion Specification schafft die Voraussetzung, Profinet-spezifische Daten auf einem OPC UA-Server für Profinet-Gerätetypen anzubieten. Mit diesem Schritt kann auch ein Device Infrastrukturdaten zur Verfügung stellen, die auf einem gemeinsamen Informationsmodell aufbauen. So lässt sich eine Kompatibilität zwischen verschiedenen Geräten erreichen.

Der TPS-1 ist ein Profinet-Kommunikationscontroller, der Profinet RT und IRT (Conformance Classes A, B, C) in allen Ausprägungen unterstützt. Der TPS-1 umfasst eine leistungsstarke CPU, welche die Bearbeitung des Profinet-Stacks sowie die Steuerung des Ethernet-Verkehrs übernimmt. Auf diese Weise wird die Applikation von der Kommunikation in dem Netzwerk entlastet. Die internen Datenwege des ASICs sind für Profinet-Daten in Hardware ausgeführt und damit sehr schnell. Über die SPI-Slave-Schnittstelle lässt sich ein Applikationsprozessor anschließen, der mit einer Übertragungsrate von maximal 25 MHz Daten mit dem Kommunikationsprozessor austauschen kann. Ein ebenfalls möglicher paralleler Anschluss erlaubt eine weitere Leistungssteigerung.

Der TPS-1, der eine mittlere Verlustleistung von 800 mW hat, eignet sich insbesondere für Anwendungen in kleinen, geschlossenen Gehäusen. Er bietet zwei Ports, sodass ein Device sowohl in einer Stern- als auch Linienstruktur arbeiten kann. Als Basis für den TPS-1 sind ein Evaluation Board (Renesas) sowie eine Testbaugruppe (Phoenix Contact) verfügbar. Ein Raspberry PI 3 mit 1,2 GHz Quad Core, 1 GByte DDR2 und einem MicroSD-Karten-Port fungiert als Entwicklungsbaugruppe für die Beispielapplikation. Der Einplatinen-Computer beinhaltet zahlreiche Schnittstellen, einen großen internen Speicher sowie Raspbian (Linux) als Betriebssystem. Somit erweist er sich als ideale, kostengünstige Entwicklungsplattform.

Sämtliche erforderlichen Entwicklungswerkzeuge (wie Compiler, Editor, Remote Desktop oder Cloud-Dienste) sind zudem frei erhältlich. Neben dem OPC UA-Server ist die hier skizzierte Beispielapplikation ebenfalls auf dem Raspberry PI 3 implementiert worden. Ziel des Projekts war die Verwendung einer möglichst einfachen Applikation. Daher werden lediglich zwei Byte Ein- und Ausgabedaten weitergeleitet. Das reicht aus, um auch die Anwendung mit dynamischen Daten zu zeigen. Die OPC UA-Kommunikation fokussiert sich nicht auf die Übertragung von Prozessdaten; dazu wird Profinet genutzt. Der OPC UA-Server stellt vielmehr eine Schnittstelle bereit, die Informationen über das Device liefert (Bild 2).

Bild 2: Der typische prinzipielle Aufbau eines Profinet-OPC UA-Geräts.
Bild 2: Der typische prinzipielle Aufbau eines Profinet-OPC UA-Geräts.
(Bild: Phoenix Contact)

Der detaillierte Aufbau der Beispielapplikation

Die hier vorgestellte Gerätelösung besteht aus einem TPS-1 Evaluation Board, das eine Profinet-Schnittstelle, die Ethernet-Steckverbinder und ein DPRAM als Schnittstelle zur Applikationsbaugruppe enthält. Hinzu kommt die Raspberry PI-3-Baugruppe, auf der die Applikation und der OPC UA-Server integriert worden sind. Als Betriebssystem wird Raspbian, ein für Raspberry angepasstes Linux, eingesetzt. Die Profinet-Kommunikation läuft parallel zur Ethernet-Übertragung auf der gleichen Leitung. Der TPS-1 bietet den TCP/IP-Kanal an. Über diesen internen Kanal können Ethernet-Nachrichten (beispielsweise der TCP/IP-Verkehr) ohne Umwandlung vom Profinet-Netzwerk an den Raspberry PI 3 durchgeleitet werden.

Bild 3: 
Strukturmodell eines OPC UA-Servers.
Bild 3: 
Strukturmodell eines OPC UA-Servers.
(Bild: Phoenix Contact)

Der OPC UA-Server umfasst bereits einen optimierten TCP-Protokoll-Stack (Binärprotokoll, Port 4840). Die Kommunikation wird von der OPC Foundation in Form eines Stacks zur Verfügung gestellt. Für die beschriebene Server-Applikation kommt open62541 (Open Source Implementation of OPC UA der IEC 62541) zur Anwendung. Die Kommunikationsschicht stellt ebenfalls einen SecureChannel (Service Set) bereit, mit dem ein gesicherter Kanal zwischen einem OPC UA-Client und einem OPC UA-Server aufgebaut werden kann. Darüber hinaus gehören Zugriffsfunktionen für die Lieferung der Daten an den OPC-Client zum Server (Bild 3).

OPC UA definiert verschiedene Discovery-Mechanismen zur Bekanntmachung von OPC UA-fähigen Teilnehmern sowie deren Funktionen und Eigenschaften. Damit kann ein OPC UA-Client schon vorhandene Daten abfragen. Die Datenstruktur des OPC UA-Servers besteht aus dem Basisgerätemodell. Ergänzend dazu lassen sich eine oder mehrere Companion Specifications sowie für den Hersteller wichtige Modelle hinzufügen. Der Vorteil einer solchen Gliederung liegt im einheitlichen Datenaustausch zwischen Anlagen, Maschinen und Geräten unterschiedlicher Hersteller.

Das Informationsmodell des OPC UA-Servers

Ein OPC UA-Server besitzt ein leistungsfähiges Informationsmodell. Der Adressraum des Servers basiert auf einem vollständig vernetzten Graphen. Die Daten werden in Nodes (Knoten) abgelegt. Der Node stellt das grundlegende Element der OPC UA-Kommunikation dar. Nahezu jedes Element ist auf einen Knoten reduziert, der einem Objekt aus der objektorientierten Programmierung ähnelt. Der Node besitzt Attribute, die gelesen werden können. Ein einzelner Knoten lässt sich mit OPC UA-Funktionalitäten (wie Data Access oder Commands) koppeln. Er ist mit einem eindeutigen Identifier (NodeID) ausgestattet. Nodes, die zum Beispiel zu den Profinet-Daten gehören, werden zu einem Namespace zusammengefasst, der wiederum durch einen eindeutigen Identifier auffindbar ist. Zum einfachen Zugriff auf einen Namespace wird oftmals ein Namespace-Index verwendet (etwa „ns=3; i=54438“), hier Profinet-Namespace. Der Namespace 0 ist dem Basis-NodeSet der OPC Foundation vorbehalten.

Das beschriebene Beispiel greift auf das Basismodell zurück, das den Namespace 0 repräsentiert und um den bisherigen Stand der Profinet Companion Specification (hier Namespace 3) erweitert wird. Ein Arbeitskreis der Profinet-Nutzerorganisation ergänzt die Profinet Companion Specification, die sich noch in der Definition befindet, sukzessive. Während seines Startvorgangs fordert der Server seinen Node-Manager dazu auf, den Address Space zu erstellen, also die notwendigen (statischen) Nodes.

XML-formatierter Export mit dem UA Modeler

Zur Modellierung der Datenstrukturen kommt der UA Modeler der Firma Unified Automation (Kalchreuth bei Erlangen) zum Einsatz. Mit dem Werkzeug lassen sich beliebige Daten und Strukturen entwerfen. Die OPC UA-Umgebung umfasst bereits viele Built-in-Datentypen wie Boolean, Byte oder ByteString. Diese werden dann den NodeClasses (Object, ObjectType etc.) zugeordnet. Der UA Modeler kann das definierte Datenmodell XML-formatiert exportieren. Damit liegt eine Form vor, die sich nach der Übersetzung in den OPC UA-Server einbinden lässt. Das Software Development Kit (SDK) für open62541 beinhaltet einen XML-NodeSet-Compiler. Bei einem NodeSet handelt es sich um eine Menge von Knoten (ein OPC UA-Knoten gehört genau zu einem Node), dem ein eindeutiger Name (Namespace) zugewiesen wird. Der Compiler übersetzt die XML-Dateien, welche die Datenstruktur des Basismodells und der Profinet Companion Specification enthalten, in C-Quellen (*.c- und *.h-Dateien). Folgende Schritte müssen vollzogen werden:

  • Modellkonvertierung in C-Quellen (XML-NodeSet-Compiler),
  • Nutzung (Einbindung) der generierten Strukturen (Objekttypen, Methoden),
  • Einlesen der TPS-1-Daten und Beschreiben der Nodes.

Bild 4: 
Der Aufbau einer Secure Session zwischen dem OPC UA-Server und dem OPC UA-Client.
Bild 4: 
Der Aufbau einer Secure Session zwischen dem OPC UA-Server und dem OPC UA-Client.
(Bild: Phoenix Contact)

Somit ist der vollständige Server vorhanden. Für den TPS-1 bedeutet das, dass sich die Daten, die ein Profinet-Device bislang über Information & Maintenance (I&M) liefern kann, nun auch mit Hilfe des OPC UA-Informationsmodells bereitstellen lassen. Für den Anwender sind sicher noch weitere Daten von Bedeutung, um die das Informationsmodell des OPC UA-Servers erweitert werden kann (Bild 4).

Sichere Datenübertragung in der Kommunikationsschicht

Wie erwähnt, erfolgt der Datenaustausch auf der Netzwerkebene über ein OPC-spezifisches binäres Protokoll auf Basis von TCP/IP. In der Kommunikationsschicht sichert der Service „SecureChannel Service Set“ die Datenübertragung bis auf die Ebene der Applikation ab. Der Client kann so die Sicherheitskonfiguration des Servers abfragen und einen Kommunikationskanal einrichten, der für die Vertraulichkeit und Vollständigkeit (Integrität) der weitergeleiteten Meldungen sorgt. Auf dem gesicherten Kanal stellt das Session Service Set die anwenderspezifische Verbindung zu einer Applikation her. Beim Test und der Inbetriebnahme der Beispiel-Applikation waren die UA-Experten der Firma Unified Automation behilflich.

Bild 5: Die Software-Architektur der Raspbian-­Applikation aus dem beschriebenen Beispiel.
Bild 5: Die Software-Architektur der Raspbian-­Applikation aus dem beschriebenen Beispiel.
(Bild: Phoenix Contact)

Bild 5 zeigt die Software-Architektur der Raspbian-Applikation. Das in den Raspberry PI 3 integrierte Betriebssystem Raspbian (Linux) unterstützt die SPI-Slave-Schnittstelle des TPS-1 nicht vollständig. Daher ist in der dargestellten Implementierung ein anderer, einfacherer Weg verwendet worden. Dazu wurde ein Kernel-Modul (tpsmodule.ko) eingefügt, das einen Teil der Profinet-Applikation des Devices enthält. Durch den Aufruf eines Character-Devices (/dev/TPS-1) über das „System Call Interface“ kann eine Applikation die Profinet-spezifischen Daten vom TPS-1 im User Space abholen und dem OPC UA-Server zur Verfügung stellen. Zur Initialisierung des OPC UA-Servers – hier insbesondere der Teil der Profinet Companion Specification – sind Funktionen implementiert worden, die den Server mit den erforderlichen Daten versorgen, zum Beispiel addDev(), CreateDev() oder CreateMod().

Schlussbemerkung: OPC UA ist ein ausgereifter Standard, mit dem sich die Anforderungen von Industrie 4.0 hinsichtlich der Interoperabilität lösen lassen. Am Beispiel des Profinet-Kommunikationscontrollers TPS-1 und des Betriebssystems Raspbian wird deutlich, dass die Voraussetzungen zur zügigen Implementierung inzwischen gegeben sind und ein Device mit einem OPC UA-Server ausgestattet werden kann.

* Andreas Grüne arbeitet im Research & Development Profinet bei Phoenix Contact Software, Lemgo. Martin Schürmann entwickelt Firmware Bus Coupler und André Sonnwald ist im Development Firmware tätig, beide arbeiten bei Phoenix Contact Electronics, Bad Pyrmont.

Artikelfiles und Artikellinks

(ID:46053644)