Der verwendete Industrie-4.0-Demonstrator wurde als Forschungsobjekt für die Erprobung und Veranschaulichung der Vernetzung dezentraler Steuerungsarchitekturen vielfältig als Messexponat eingesetzt und zuletzt der Hochschule als Schenkung überlassen. Bei der Übergabe war die Anlage nicht mehr funktionsfähig und wurde im Rahmen einer Abschlussarbeit an der Hochschule Kempten wieder in Betrieb genommen. Der Demonstrator gliedert sich in drei eigenständige Module, die von einer übergeordneten Steuerung koordiniert und kontrolliert werden können: ein manueller Bestückungsplatz, ein Handling-System für den Objekttransport und ein Staplermodul für die Einlagerung von Standard-Lagerboxen. Jedem Modul wurde eine Kleinsteuerung in Form eines Raspberry Pi zugeordnet, die die Ansteuerung der Hardware (Aktorik und Sensorik) jeweils über Ethercat-Koppler mit 24V-Ein/Ausgangsmodulen umsetzen. Für das Handling-System sind drei eigenständige Achsregler mit integrierten Steuerungen verbaut, die mittels Can-Bus angesteuert werden können. Die Anbindung erfolgt über einen Ethercat/Can-Koppler, der die Regler mit der zentralen Steuerung verbindet, die als eine Win-V3-Soft-SPS von Codesys auf einem Standard-PC ausgeführt ist, um die Abläufe zu steuern und die Visualisierung umzusetzen. Eine Achssteuerung in harter Echtzeit ist demnach (Win V3) nicht möglich, war aber für die gemachten Betrachtungen an dem Transport- und Lagersystem nicht notwendig. Für die Datenübertragung zwischen den dezentralen Steuerungen und der übergeordneten Soft-SPS wurde zunächst das gängige ethernetbasierte Kommunikationssystem TCP/IP genutzt: zwischen jedem Raspberry Pi und der Soft-SPS wurde eine eigenständige TCP/IP-Client-Server-Datenübertragung implementiert, sodass die Daten zwar sicher, aber eventuell mit eingeschränkter Performance (je nach Auslastung der Kommunikation) übertragen wurden. Dieses System sollte als Ausgangspunkt für einen ersten Vergleich zu einer Datenübertagung, die auf der von Codesys neu veröffentlichte IEC-Bibliothek für OPC UA Pub/Sub (nach den Spezifikationen der OPC Foundation) basiert, dienen.
Das macht OPC UA Pub/Sub anders
Pub/Sub spezifiziert, dass Daten nicht zwingend nur an einen Empfänger gesendet werden. Es ist möglich von einem Sender (Publisher) Daten an einen, mehrere oder alle Teilnehmer (Subscriber) im Netzwerk zu senden. Dazu sendet der Publisher seine Daten unter einem Themennamen (Topic) in das Netzwerk. Jeder Teilnehmer, der diese Daten empfangen möchte, kann diese unter dem Themennamen abonnieren und nutzen. Die Daten selbst werden verbindungslos, also ohne Empfangsbestätigung, übertragen. Die dadurch mögliche schnellere Übertragung ist entsprechend weniger sicher alsl bei dem alternativ genutzten TCP/IP-Protokoll. Pub/Sub nutzt dazu auf den untersten Netzwerkschichten (OSI-Model) das User Data Protokoll (UDP), das wiederum auf dem Internet Protokoll (IP) aufsetzt. Innerhalb der Codesys Entwicklungsumgebung wird Pub/Sub als gewöhnliche IEC-Bibliothek umgesetzt und angeboten. Auch ohne Lizenzierung ist diese 30 Minuten lang nutzbar, bevor die Übertragung abbricht und danach durch einen Neustart des Programms neu aufgebaut werden kann. Für eine dauerhafte Nutzung muss für jeden Teilnehmer, der OPC UA Pub/Sub nutzen will, eine Lizenz erworben und über den Lizenzmanager installiert werden. Die Kosten einer Lizenz belaufen sich Stand Januar 2021 auf 50 Euro. Im Zuge einer Smart-Factory-Potenzialanalyse für ihren Kunden KSB identifizierte die Managementberatung NEONEX Opti mierungschancen bei der Beschaffung der Lieferantendokumentation sowie der Erstellung von Unterlagen zur Qualitätsprüfung entlang der Supply-Chain. ‣ weiterlesen
Signifikante Ressourceneinsparung bei Pumpenhersteller KSB
NEONEX, Fabasoft Approve & KSB: „Win-win-win-Situation“ durch starke Partnerschaft
Signifikante Ressourceneinsparung bei Pumpenhersteller KSB
Aufbau von OPC UA Pub/Sub in Codesys
Für den Aufbau eines Publishers muss innerhalb der Codesys-Entwicklungsumgebung mit fünf in der Bibliothek enthaltenen Funktionsbausteinen gearbeitet werden. Die hauptsächliche Parametrierung wird im UADP.Connection-Baustein ausgeführt: Die IP-Adressen des Senders und der Empfänger sowie die verwendete Portnummer und der Themenname (in Form einer numerischen ID) werden festgelegt. Für die Übertragung an mehrere oder alle Teilnehmer kann eine Multicast-Adresse verwendet werden. Für einen Publisher kann die durch diesen Baustein definierte Verbindung genutzt werden, um die Daten eines DataSet-Bausteins, die mittels eines Writer- und eines WriterGroup-Baustein aufbereitet werden, zu versenden. Für einen Subscriber werden die beiden Bausteine zur Aufbereitung durch einen Reader- und einen ReaderGroup-Baustein ersetzt und die Parametrierung des Connection- Bausteins entsprechend angepasst. Alle Bausteine sind nach den Konzepten der objektorentierten Programmierung gestaltet und müssen auch so verwendet werden. Um zum Beispiel Daten für die Übertragung aufzubereiten, muss die Grundstruktur aus dem Funktionsbaustein DataSet der gelieferten Bibliothek geerbt werden. Dadurch können die zu übertragenden Variablen relativ einfach über die ererbte Methode „PrepareValues“ für die Übertragung registriert werden. So können Datenstrukturen einfach und effizient in beliebigen Varianten erzeugt werden, weshalb es nötig wird sicherzustellen, dass sowohl Sender als auch Empfänger identische Data Sets besitzen. Dafür beinhaltet der Data-Set-Baustein der Bibliothek zusätzlich noch einen Versionscode, der über die Methode „Init“ gesetzt werden kann. Bei nicht identischen Versionscodes kann keine Übertragung zu Stande kommen.
Die Performance von Pub/Sub-TCP/IP
Da die Implementierung von Pub/Sub in der Bibliothek über UDP umgesetzt ist, lassen sich prinzipiell nur geringe bis gar keine Unterschiede bei den Übertragungsgeschwindigkeiten von Pub/Sub im Vergleich zu TCP/IP erwarten. Zur Messung wurden gleiche Dateninhalte (2Byte) zwischen zwei Steuerungen übertragen und lieferten das erwartete, in nebenstehender Abbildung dargestellte Ergebnis. Übertragungszeiten sind im Mittel quasi identisch, wobei Pub/Sub minimal schnellere Zeiten liefern kann. Die Abarbeitungszeiten des Netzwerk-Codes liegen im einstelligen Mikrosekunden-Bereich, sind aber je nach Umsetzung tendenziell für Pub/Sub etwas länger. Das heißt, Pub/Sub stellt tatsächlich keinerlei überflüssigen Overhead in den Raum, der Performance-Einbußen erzeugen könnte.
