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?
Fit für die Digitalisierung
Wie ein Firmware-Update von Siemens OPC-UA-Client und Companion Specs in die Steuerungswelt bringt.
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.
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.
Wie wirken sich die Security-Mechanismen von OPC UA auf die Performance aus? Der Ressourcenbedarf wird immer wieder als Kritikpunkt genannt.
Robert Winter: Bei den Performancediskussionen bezüglich Security sind zwei Aspekte zu beachten. Das eine ist die Verbindungsaufnahme zum Start einer OPC-UA-Session, das andere die Kommunikation zur Laufzeit, also wenn die Werte übertragen werden. Beim Sessionaufbau spürt man den Einfluss von Security deutlich. Je kleiner eine CPU ist, umso stärker.
Zur Laufzeit macht sich Security kaum bemerkbar. Bei unseren Tests betrug die Abweichung zwischen einem bis maximal fünf Prozent zwischen Verschlüsselung und ohne.
Andreas Czech: Unter der Prämisse einer sicheren Kommunikation und zuverlässiger Datenverschlüsselung ist das dann wirklich zu vernachlässigen – vor allem wenn die Daten vorher strukturiert wurden.
Gibt es eine Faustformel, wann ich welche Übertragungsvariante nehmen sollte?
Robert Winter: Wenn ich nur ab und zu einen Wert brauche, reichen die normalen Read/Write Calls. Bei sehr hohen Anforderungen an die Performance und zeitliche Synchronität sind Registered Read/Write die bessere Wahl. Für klassische Kopplungen mit einem HMI-Panel nehme ich OPC-UA-Subscriptions ‒ nicht zu verwechseln mit Pub/Sub.
Wo ist der Unterschied zu Pub/Sub, bei dem man Geräte ja auch als Empfänger eintragen kann?
Robert Winter: Bei Subscriptions meldet man sich mit dem symbolischen Namen eines Datums an der CPU an, das beobachtet werden soll. Die Steuerung prüft auf Basis der internen Sampling Time, ob und wann sich dessen Wert geändert hat. Nach Ablauf der eingestellten Publishing Time wird dieser Wert dann gesendet.
Diese Kommunikationsart verwenden erfahrungsgemäß die meisten Kunden. Subscribion erzeugt zwar weniger Last auf dem Netzwerk, aber das Pollen findet intern auf der CPU statt und kostet folglich in der Steuerung entsprechend viel Performance.
Und der Unterschied zu OPC UA Pub/Sub?
Andreas Czech: Bei OPC UA Pub/Sub wird das Client-Server Modell verlassen und die Kommunikation erfolgt nicht mehr 1:1, sondern gemäß dem Prinzip ‚one to many‘ oder auch ‚many to one‘. Dabei werden beispielsweise Daten zyklisch von der CPU an eine Gruppe von Devices ausgesendet oder umgekehrt von mehreren IO-Devices an die Steuerung übertragen.
Für welche CPUs ist die OPC-UA-Client/Server-Variante verfügbar?
Andreas Czech: Alles, was wir in Richtung OPC UA entwickeln, ist für alle Ausprägungen der S7-1500-Famile verfügbar, vom kleinen dezentralen Controller in der ET 200SP Bauform, über den PC-basierten Open Controller mit integriertem Software-Controller und der IP65/67-Variante bis zum modularen Simatic S7-1500 System inklusive fehlersicheren Varianten und den Technologie-CPUs für erweiterte Motion Control.
Und die S7-1200-Familie?
Andreas Czech: Grundvoraussetzung für eine OPC UA-Implementierung ist eine sichere Kommunikation. Das war bisher in der Firmware der S7-1200 nicht implementiert. An dem Thema arbeiten wir natürlich und es wird sicherlich das eine oder andere in Zukunft kommen. Ziel ist, auch hier nicht nur rein von der Programmiermöglichkeiten der Steuerungen eine Skalierbarkeit zwischen S7-1200 und S7-1500 herzustellen, sondern auch im Bereich der Kommunikation ‒ wenn auch mit etwas abgespecktem Funktionsumfang.
Ab welchen TIA Portal Versionen und CPU-Firmware funktioniert die Konfiguration von Companion Spezifikationen des OPC-UA-Client/Servers?
Andreas Czech: Das funktioniert seit der Version 15 des TIA-Portals und der CPU-Firmware 2.5, also seit 2017. Das ist ein weiterer Beleg, dass uns OPC UA und die Companion Specs sehr wichtig sind. Denn darüber können Maschinenbauer und Anwender ihre Maschinen- und Anlagenteile individuell spezifizieren und über das OPC UA-Informationsmodell intern und für ihre Dienstleister standardisieren. Dies ist mit einer der Gründe für den Hype um OPC UA.
Robert Winter: Der Trend geht dahin, dass manche Firmen ihre eigenen Werks-Spezifikationen erstellen, also definieren, wie Anlagenteile datentechnisch auszusehen haben. OEMs sollen oder müssen dann das Interface ihrer Maschinen dann entsprechend an-passen. Solche firmeneigenen Companion Spezifikationen können wir mit unserem Tool sehr viel besser unterstützen als jeder andere auf dem Markt. Der Maschinenbauer ist wesentlich flexibler und kann sich auf die unterschiedlichen Vorgaben seiner Kunden einstellen.
Andreas Czech: Wichtig für Anwender ist dabei, dass ihre CPUs nach einem Update auf die Firmware 2.6 OPC-UA-Client/Server unterstützen. Wir haben also keine Limitierung der Funktion auf eine neue Hardware-Generation.
Wie sieht das Lizenzmodell aus?
Andreas Czech: Wir haben die Lizenzen für OPC UA entsprechend den CPU-Klassen in drei Stufen geclustert. Es ist also egal, welche Funktionen ein Anwender nutzt, den OPC-UA-Client, den Server oder Companion Spezifikationen verwenden will.
Robert Winter: Die gleiche Funktionalität ist auch auf der Simulation verfügbar. Man kann vorab also schon die komplette Kommunikation virtuell in Betrieb nehmen und die Clients testen.
Für die Digitalisierung im Feld und die vertikale Integration an Mindsphere hat Siemens doch IoT-Controller. Sind die mit dem Firmware-Update der S7-1500-Familie jetzt obsolet?
Andreas Czech: Nein, es sind zwei unterschiedliche Szenarien bei der Datenübertragung in die MindSphere möglich, über MindConnect Elements genannte embedded PCs oder direkt aus der Simatic S7-1500 CPU. Die Kommunikation von einem MindConnect Element wie MindConnect Nano oder IoT2040 zur MindSphere erfolgt über sichere HTTPS-Kommunikation. Das Einsammeln der Daten aus der Steuerungs- oder Feld- ebene erfolgt dagegen über S7- oder OPC UA-Kommunikation. Über MindConnect-Funktionsbausteine kann auch eine Simatic S7-1500 CPU direkt zur MindSphere Daten senden. Die Voraussetzung dafür ist eine sichere Open User Kommunikation.
Das Interview führte IEE-Chefredakteur Stefan Kuppinger
(sk)