Uns ist Usability sehr wichtig – auch beim Einrichten der OPC-UA- Kommunikation. Redaktion IEE

Uns ist Usability sehr wichtig – auch beim Einrichten der OPC-UA-Kommunikation. Redaktion IEE

Herr Czech, ich dachte die IoT-Anbindung der Steuerungsebene sei durch. Wo drückt denn der Schuh?

Andreas Czech: Beim Thema Digitalisierung stehen häufig Dinge wie Engineering im TIA-Portal mit Standardisierung der Projekte und Schnittstellen im Fokus. Genauso wichtig ist aber auch, welche Kommunikationsmethoden wie genutzt werden. Selbst bei OPC UA gibt es unterschiedliche Möglichkeiten und damit Optimierungspotenzial.

In Sachen IoT-Anbindung arbeitet Siemens mit OPC UA als Interface. Wie hat Siemens OPC UA implementiert?

Robert Winter: Wir haben OPC UA stufenweise in die Simatic S7-1500-Familie eingeführt, angefangen mit der ersten Stufe eines OPC-UA-Servers mit dem Firmware-Update 2.0 und TIA Portal V14. Das war im Dezember 2016. Bei der Version 15 des TIA Portals Ende 2017 stand eigentlich der OPC-UA-Client auf der Roadmap. Wir haben uns dann aber dafür entschieden, Themen wie die OPC-UA-Methoden und Companion Spezifikationen vorzuziehen. Das war uns zu dem Zeitpunkt wichtiger.

Was brannte Ihnen denn bei den Themen unter den Nägeln?

Robert Winter: Bei der ersten Version des OPC-UA-Servers konnten wir nicht sofort den kompletten Funktionsumfang an OPC-UA-Diensten und -Services für den Datenzugriff implementieren. Hier ergänzen die OPC-UA-Methoden die Server Funktionalität, die man etwa für die Übermittlung eines Statuswerts nach einer Übertragung benötigt. Für eine konsistente Datenübertragung ist das aber sehr wichtig.

Im Oktober 2018 wurde der OPC-UA-Client mit der aktuellen TIA Portal Version 15.1 und Firmware 2.6 zur Verfügung gestellt.

Andreas Czech: Die Implementierung haben wir in drei Etappen geteilt: Zuerst der OPC-UA-Server, dann die Ergänzungen mit den Methoden und den Companion Spezifikationen, gefolgt vom OPC-UA-Client. Diese Roadmap haben wir aufgestellt, weil die Implementierung aller OPC-UA-Themen in Summe ein großes Paket darstellte. Und selbst wir als Siemens müssen unsere Entwicklungsressourcen einteilen, zumal wir immer unserem hohen Qualitätsanspruch Rechnung tragen wollen. Wenn wir etwas einbauen, dann erwarten unsere Kunden zu Recht, dass es bereits von Anfang an funktioniert.

Welche Use-Cases stehen mit der Client-Erweiterung im Fokus?

Robert Winter: Der Client hat zwei Haupt-Use-Cases. Das ist zum einen die Controller-Controller-Kommunikation zwischen PLCs, auch über Herstellergrenzen hinweg. Damit können Systemintegratoren von einer S7-1500-Steuerung eine Controller-Kommunikation zu Fremdsystemen aufbauen. Der zweite Use Case betrifft die vertikale Kommunikation aus der Steuerung heraus mit MES/ERP-Systemen oder einer Cloud. Über den eigenen OPC-UA-Client kann das nun auch die Steuerung aktiv initiieren.

Und die Methoden für die Controller-zu-Controller-Kommunikation, basieren die auf den standardisierten PLCopen-Bausteinen?

Andreas Czech: OPC UA ist eine Spezifikation der OPC Foundation. Aber es gibt keine von der OPC Foundation spezifizierte API. Hierzu hat die PLCopen wiederum einen Vorschlag gemacht, wie man einen OPC-UA-Client umsetzen kann. Wir haben uns, wie andere Anbieter auch, an diesen Vorschlag gehalten und unsere Funktionsbausteine für die verschiedenen Kommunikationsarten auf Basis dieser Vorlage erstellt.

Also Verbindungsaufbau, Write, Send, Fetch und dergleichen.

Robert Winter: Es gibt eine Bibliothek an Funktionsbausteinen, darunter sind Bausteine, um eine Verbindung auf- oder abzubauen, um Werte zu lesen oder zu schreiben. Und es gibt auch Bausteine, um Methoden aufzurufen.

Sie hatten anfangs nach den Herausforderungen gefragt, die Erstellung der Verbindungen ist eine. Bisher hat der Projekteur die Kommunikations- und Systemfunktionen Schritt für Schritt von Hand ausprogrammiert. Unser Anspruch war, hier die Usability zu verbessern und uns damit vom Wettbewerb abzuheben. Daher haben wir, wie beim TIA Portal üblich, Wizards und Dialoge entwickelt, die den Projekteur durch die komplette Konfiguration des OPC-UA-Clients führen. Das sauber zu implementieren war sehr aufwendig, aus unserer Sicht aber notwendig, um unseren Kunden eine optimale Handhabbarkeit zu bieten.

Andreas Czech: Zusätzlich hat unser OPC-UA-Server im Vergleich zu anderen Lösungen den Vorteil, dass er nicht generisch programmiert werden muss, gerade auch im Hinblick auf die Implementierung einer OPC-UA-Companion-Spezifikation.

Mit dem kostenlosen OPC UA Modeling Editor SiOME kann der Kunde beliebige OPC-UA-Informationsmodelle ohne viel Aufwand selbst implementieren. Das ist ein Zusatznutzen zum Beispiel für OEMs, die auf diese Art und Weise wesentlich schneller eine branchenspezifische Companion Spezifikation oder kundeneigene Standards im TIA Portal umsetzen können. Anders als bei Nicht-Siemens-Lösungen ist somit keine zeitaufwendige Anpassung der Firmware bei der Steuerung erforderlich.

Bei uns wird der OPC-UA-Client per Wizard und Drag&Drop grafisch programmiert.

Bei uns wird der OPC-UA-Client per Wizard und Drag&Drop grafisch programmiert. Redaktion IEE

Für Profinet gibt es doch auch eine Controller-zu-Controller-Kommunikation. Was empfehlen Sie ihren Kunden?

Robert Winter: Profinet ist für die Echtzeit-Kommunikation gedacht, insbesondere wenn es auf Mikrosekunden im IO-Device- und Antriebsbereich ankommt. Profinet, wenn auch sehr weit verbreitet und internationaler Standard, ist und bleibt aber ein Feldbus. OPC UA dagegen ist universeller und über Feldbusgrenzen hinweg einsetzbar. Der Nachteil: Stand heute ist OPC UA nicht echtzeitfähig. Dazu fehlt Pub/Sub in der Breite.

Ist Pub/Sub denn schon in die S7-1500 implementiert?

Robert Winter: Noch nicht, ist aber in der Pipeline für eine der nächsten Firmware-Versionen. Wir wollen Pub/Sub zunächst über das User Data Protocol, also UDP, implementieren, anschließend auch auf TSN. Time Sensitive Networking ermöglicht Determinismus auf Ethernet-Basis. Damit wird OPC UA ebenfalls echtzeitfähig.

In Hannover hatten Sie aber bereits einen Demonstrator mit OPC Pub/Sub und TSN gezeigt.

Robert Winter: Stimmt, wir haben OPC UA Pub/Sub in einen Communication Processor integriert, also nicht auf der CPU selbst. In einer Roboter-Demo haben diese CPUs eine Controller-Controller- sowie IO-Kommunikation aufgebaut. Das ist eine Machbarkeitsstudie, die zeigt, was in Zukunft mit der CPU-integrierten TSN-Funktionalität möglich ist.

Inwieweit spielt die Performance der CPUs bei dem Thema Client/Server-Implementierung von OPC UA eine Rolle?

Robert Winter: Das ist ein sehr wichtiges Thema, das immer wieder diskutiert wird. Dabei spielt jedoch die CPU-Performance nicht die entscheidende Rolle. Einen größeren Einfluss hat die Wahl des jeweiligen Kommunikations-Services. Nutzt man normales Lesen und Schreiben, Registered Read/Write, Subscriptions oder Methoden? Die größte Performance haben Registered Read/Write-Calls.

Warum?

Robert Winter: Registered Read/Write erfolgt die Abfrage ohne irgendwelche Metadaten. Ich frage das Datum über dessen symbolischen Namen an und bekomme eine interne ID zurück mit der direkt auf die Daten zugegriffen werden kann. Das ist das Performanteste, was es heute gibt.

Andreas Czech: Für die Übertragungsperformance fast noch wichtiger ist, wie die Daten eines Projekts modelliert wurden. Neben dem symbolischen Einzelzugriff gibt es die Möglichkeit, die Daten als Arrays oder in Strukturen zu modellieren. Das Problem dabei: Manche OPC-UA-Server unterstützen diese Option nicht – wir dagegen schon.

Die beste Performance holt man also heraus, wenn die Daten als Arrays und Strukturen vorliegen. Als Block übertragen, fällt der Kommunikations-Overhead komplett weg.

Und Ihre Entwickler haben das getestet?

Andreas Czech: Mal grob über den Daumen gepeilt: Wenn tausend Werte als Array oder Struktur modelliert sind, dann kann man diese mit einer Simatic-CPU 1518 in ein oder zwei Millisekunden transferieren. Bei tausend Einzelwerten dauert das 160 Millisekunden. Daraus lässt sich ableiten, dass symbolische Einzelzugriffe aus Performancesicht am schlechtesten sind, besser ist es, die Daten zu modellieren und Arrays oder Strukturen per Registered Read/Write zu transferieren.

Seite 1 von 212