Als Pendant bei den Feldbussystemen fungieren die Profile. Sie sind hauptsächlich entstanden, um eine Auswechselbarkeit der Geräte sicherzustellen. In der OP-UA-Welt geht es hingegen um mehr: Der Datenaustausch-Standard zielt darauf ab, die Gesamtheit aller Geräte und Anlagen mit Hilfe der Informationsmodelle abzubilden. Ein Gerät oder Anlagenteil kann mehrere Informationsmodelle beinhalten. So lässt sich ein Informationsmodell mit einer spezifischen Sicht auf ein Gerät oder eine Anlagenfunktion vergleichen. Im Laufe der Jahre sind zahlreiche Informationsmodelle erarbeitet worden. Als Beispiel seien Metamodelle genannt, die nur Regeln aufstellen, wie etwas festgelegt wird. Andere Modelle stellen dar, wie Maschinen- und Anlagentypen abgebildet werden. Weitere Modelle beschäftigen sich mit der Beschreibung von Bussystemen, Branchen und Applikationen über OPC UA.
Das DI-Informationsmodell (OPC UA for Devices 10000-100) der OPC Foundation bietet eine wichtige Sicht auf Geräte oder Assets. Es beschreibt einzelne Geräte mit ihren Eigenschaften, egal von welchem Typ (z.B. Antrieb oder Encoder) diese sind. Das DI-Informationsmodell fokussiert sich dabei auf Asset-Informationen sowie allgemeine Diagnose-, Software-Update- oder Parametrierfunktionen. Deshalb wird es von vielen anderen Informationsmodellen referenziert. Die vor kurzem freigegebene Spezifikation OPC UA Safety (OPC 10000-15) legt dar, wie sich sicherheitsgerichtete Informationen mit bis zu 1.500 Byte Nutzdaten gemäß dem Consumer/Producer-Prinzip als Black-Channel-Ansatz via OPC UA übertragen lassen. Dieses Informationsmodell, das nur die eigentliche Safety-Kommunikation umfasst, wird in Zukunft ebenfalls von weiteren Informationsmodellen oder Companion-Standards referenziert werden. Letztendlich können die Endanwender eigene private Informationsmodelle zusammenstellen, in denen ihre zu überwachenden Geräte und Anlagen abgebildet sind. An dieser Stelle wird bereits deutlich, wie komplex sich die Sammlung von Informationsmodellen in einer Anlage gestalten kann.
Herausforderung für die Steuerungen
Bei den Companion-Standards, die in verschiedenen Organisationen entstehen, ist schnell klargeworden, dass nicht jedes Modell das Rad neu erfinden darf. Dementsprechend wurde in der OPC Foundation eine eigene Arbeitsgruppe gegründet, die übergreifende Gemeinsamkeiten oder Best-Practice-Anwendungen herausarbeitet. Als Beispiel seien die Aktivitäten der Base-Model-Sub-Gruppe angeführt, die Informationen rund um das Ethernet-Interface standardisiert. Außerdem hat der VDMA, der an zahlreichen Standards arbeitet oder diese schon freigegeben hat, u.a. ein allgemeineres Maschinenmodell definiert, das auf andere Maschinentypen übertragen werden kann.
Aufgrund der vielfältigen, kaum noch überblickbaren Aktivitäten der vielen Arbeitsgruppen kommt eine besondere Herausforderung auf frei programmierbare Steuerungen zu. Die SPS weiß im ersten Schritt nicht, welche Steuerungsfunktion sie zukünftig in der jeweiligen Applikation übernehmen soll. Ferner ist ihr nicht bekannt, welche Informationsmodelle abzubilden sind. Zudem legt ein Informationsmodell lediglich die Typen fest. Die Instanzen entstehen erst bei der Nutzung des Modells. Daher muss die Flexibilität der SPS auf das für die externe Kommunikation vorgesehene Interface – also OPC UA – transformiert werden. Das bedeutet, dass ein in die Steuerung integrierter OPC-UA-Server vom Applikationsprogrammierer um zusätzliche Informationsmodelle zu erweitern ist. Neben dem typbasierten Informationsmodell müssen aus Sicht der SPS darüber hinaus die Instanzen generiert, die optionalen Anteile des Modells ausgewählt sowie die Verknüpfung zum realen Prozess hergestellt werden. Hier kommt das Offline-Beschreibungsformat eines OPC-Servers – die sogenannte Nodeset-Datei – zum Einsatz. Das standardisierte, XML-basierte Format lässt sich in einen OPC-Server importieren, und der Server übernimmt dann die Objekte in seinen Namensraum.
Server-Funktionen dank interner Informationsmodelle
Das beschriebene Verfahren soll an einer PLCnext-basierten Steuerung verdeutlicht werden. Der in die PLCnext Control eingebaute OPC-UA-Server beinhaltet erstmals alle wichtigen Grundfunktionen eines Servers. Er fungiert als abgesicherte Kommunikationsschnittstelle zu anderen externen Prozessen. Zu diesem Zweck ist der Server tief in das Security-Konzept der PLCnext-Steuerung integriert, welches von Anfang an auf die Einhaltung der internationalen Security-Norm IEC62443 ausgerichtet wurde.
Der Server unterstützt die wesentlichen Datentypen inklusive mehrdimensionaler Arrays. Funktional können Objektinformationen gelesen, geschrieben sowie subscribed – also bei einer Änderung abonniert – werden. Der OPC-UA-Server supportet Methoden, mit denen sich ganze Parametersätze konsistent übergeben lassen. Im Rahmen der A&C-Spezifikation (OPC UA Alarm and Conditions) können Alarme direkt über Alarmbausteine aus dem Steuerungszyklus ausgelöst werden. Außerdem umfasst die PLCnext-Steuerung eine Datalogger-Funktion, auf deren Daten der Anwender über OPC UA via HDA (Historical Data Access) zugreifen kann. Ferner ist die Möglichkeit der Dateizugriffe auf einen Teil des Steuerungsspeichers über OPC UA File Access implementiert worden. Sämtliche angeführten Server-Funktionen stehen in automatisch eingebauten internen Informationsmodellen zur Verfügung. Sie werden über das Programmierwerkzeug PLCnext Engineer und die OPC-Konfiguration von Variablen gefüllt.
Umsetzung dezentraler Sicherheitsfunktionen mit der PLCnext Technology
Der PLCnext-Baukasten für programmiersprachenunabhängige Automatisierungslösungen wird im Bereich der funktionalen Sicherheitsanforderungen in Richtung Dezentralität erweitert. Bei der neuen Safety-Baugruppe AXC F XT SPLC 1000 handelt es sich um eine nachrüstbare Sicherheitskleinsteuerung, die aufgrund ihrer Linksanreihbarkeit an die PLCnext Controls AXC F 2152 und AXC F 3152 gesteckt werden kann. Dabei beträgt die Baubreite der Baugruppe, die Sicherheitslevel SIL3 sowie PLe erfüllt, lediglich 45mm. Durch die Nutzung der AXC F XT SPLC 1000 verwandeln sich die beiden o.g. PLCnext Controls entweder in ein Profisafe Device oder einen Profisafe F-Host. Als F-Host kann die Erweiterung sowohl lokal gesteckte Safety-Module über den internen Axiobus erreichen als auch via Profinet mit anderen Profisafe-Geräten kommunizieren. Die Funktionalität des F-Hosts und Profisafe Devices lassen sich parallel betreiben und unterstützen somit dezentrale Sicherheitskreise. Typische Einsatzbereiche sind fahrerlose Transportsysteme, die autark sicher reagieren müssen, die Gesamtapplikation aber nur minimal beeinflussen sollen.
Nodeset-Editor erstellt Instanzen
Für ihre Erweiterung um Informationsmodelle muss die Steuerung somit die zusätzlich zu unterstützenden externen Informationsmodelle kennen. Bei einer PLCnext Control werden dazu einfach die neuen Nodeset-Dateien der Companion-Standards in ein spezifisches Verzeichnis auf der Steuerung kopiert. Der in die SPS integrierte OPC-UA-Server liest dieses Verzeichnis beim Neustart ein und stellt zudem alle neuen Typen und Instanzen im vorhandenen Namensraum dar. Auf diese Weise sind nach der Initialisierung des Servers automatisch sämtliche Informationsmodelle in das Namespace-Array übernommen.
