Maschinen- und Anlagenbau
Steuern aus der Cloud
Heute existierende Maschinen- und Anlagensteuerungen stoßen in einigen Bereichen an ihre Grenzen – gerade wenn Anforderungen wie Skalierbarkeit, schnelle Rekonfiguration der Anlage und steigende Komplexität der Algorithmen relevant sind. Steuern aus der Cloud heraus ist ein Konzept, mit dem sich diese Grenzen überwinden ließen.
Gängige Industriesteuerungen sind heute leistungsstarke, aber auch sehr komplexe Systeme. Für den Anwender hat diese Entwicklung positive wie negative Seiten. Einerseits kann er dadurch für seine Fertigung auf hochtechnologische Maschinen und Anlagen zurückgreifen und – je nach Anwendungsfall – das am besten geeignete System wählen. Zudem können Maschinenhersteller eigenes Prozess-Know-how in die Steuerungen integrieren, um dem Anwender ein Optimum der jeweiligen Anlage zur Verfügung zu stellen.
Andererseits stellt der Betrieb dieser Maschinen für den Anwender aber nicht selten eine große Herausforderung dar. Während der Maschinenhersteller oftmals Steuerungssysteme eines einzigen Herstellers einsetzt und hierfür die notwendigen Experten im Unternehmen hat, muss der Anlagenbetreiber unter Umständen einen ganzen Maschinenpark mit unterschiedlichen Steuerungen in Betrieb halten. Treten Probleme auf, muss er Experten für die verschiedenen Systeme vorhalten oder auf Servicetechniker des Anbieters zurückgreifen und dadurch hohe Kosten und eventuell lange Stillstandzeiten in Kauf nehmen. Telepräsenzportale sind zwar eine mögliche Lösung hierfür, bieten jedoch nicht immer die nötige Eingriffstiefe.
Ein weiterer problematischer Punkt für den Anwender ist der Schutz des Prozess-Know-hows. Für jemanden, der Zugriff auf die Steuerung hat, ist es heute ein leichtes, Informationen aus der Steuerung herunterzuladen. Es gestaltet sich jedoch schwierig, einzelne Maschinensteuerungen vor Ort vor unbefugtem Zugriff zu schützen. Gerade in Zeiten von industriellen Trojanern sollte der Schutz von Prozess-Know-how aber im Vordergrund stehen.
Neben diesen Nachteilen im Service- und Administrationsbereich kommt hinzu, dass heutige Steuerungssysteme nicht auf die wandlungsfähige Produktion von morgen vorbereitet sind. Fehlende Hardware- und Softwareschnittstellen sind nur schwer nachrüstbar und eine Rekonfigurierbarkeit ist nur mit großem zusätzlichem Aufwand möglich. Außerdem wird zwar die Rechenleistung der Maschinensteuerung heute bei einfachen Applikationen so gut wie nie komplett genutzt; sollen allerdings komplexe Regler, Simulationen oder Kollisionsberechnungen parallel zum Bearbeitungsprozess erfolgen, reicht die Performance einer Maschinensteuerung in der Regel nicht aus. Mit anderen Worten: Eine Skalierung der vorhandenen Ressourcen ist heute nicht möglich, ohne die komplette Steuerung zu tauschen.
Die Potenziale cloudbasierter Steuerungen
Eine cloudbasierte Steuerung hingegen verspricht gerade im Hinblick auf eine wandlungsfähige Produktion zwei entscheidende Vorteile: Zum einen kann Rechenleistung abhängig von der Komplexität der Algorithmen und Steuerungsfunktionen automatisch zur Verfügung gestellt werden. Es ist somit nicht mehr notwendig, überdimensionierte Steuerungshardware mit jedem Automatisierungssystem auszuliefern, die nahezu nie genutzt wird und im Fall neuer Anforderungen nicht mehr ausreichend ist. Zum anderen lässt sich eine räumliche Änderung der Anlagenanordnung einfacher realisieren. Dazu ist eine strikte Trennung zwischen Hardware und Software notwendig.
Durch die Verlagerung der Steuerungsfunktionen in die Cloud kann eine Maschine letztlich einfacher mit anderen Maschinen interagieren und mit ihnen Informationen über Services austauschen. Vorgänge wie die manuelle Umkonfiguration und die Erstellung neuer Hardwareverbindungen werden dabei obsolet. Darüber hinaus sind die Vernetzung mit mobilen Geräten und die Interaktion mit dem Bediener deutlich ein-facher umzusetzen, wenn Teile der Steuerung in der Cloud realisiert sind.
Gleiches gilt für das Aufspielen effizienterer Algorithmen – Stichwort: App-Konzept –, die die Produktivität optimieren. Auch diese können vom Steuerungstechnik-Anbieter einfach bei Bedarf auf bestehende Maschinen aufgespielt werden. Weiterhin entfällt die Notwendigkeit, Hardware für Steuerungen und die zugehörige Firmware zum Nachstellen von Fehlerfällen beim Kunden vorzuhalten. Steuerungstechnik-Anbieter können sich vielmehr direkt auf die Steuerung einloggen und diese diagnostizieren.
Bis hierhin lässt sich also festhalten: Die vorhandene Steuerungstechnik kann durch eine Verlagerung in die Cloud aufgebrochen, modularisiert und mit Mechanismen des Cloud-Computing, wie globale Datenverarbeitung und serviceorientierten Software-Architekturen, erweitert werden. Eine cloudbasierte Steuerung bietet somit eine geeignete Grundlage für die Vernetzung und Bereitstellung von Rechenleistung für zukünftige Cyber-Physische Systeme in der Produktionstechnik.
Damit nicht genug: Gerade bei komplexen und teuren Anlagen gestaltet es sich heute schwierig, eine ausreichende Datenbasis für Condition Monitoring aufzubauen, um zielgerichtet Probleme zu identifizieren und Lösungen ableiten zu können. Mit der Verlagerung der Steuerung in die Cloud hingegen stehen alle notwendigen Informationen der Maschine für die Fehlerdiagnose bereit und die Daten vieler Maschinen können zusammengeführt werden.
Last but not least erlaubt eine cloudbasierte Steuerung den Schutz der Prozessparameter und die Anwendung zeitgemäßer Sicherheitsmechanismen (Security). Demgegenüber sind auf heutigen speicherprogrammierbaren Steuerungen nur vergleichsweise einfache Sicherheitsmechanismen umgesetzt, die aufgrund der begrenzten Ressourcen nicht durch rechenintensivere neue Verfahren (Verschlüsselung, Zertifikate, …) ersetzbar sind.
Die Steuerungsarchitektur in der Cloud
Bild 1 zeigt beispielhaft die Architektur einer cloudbasierten Werkzeugmaschinensteuerung. Die lokale Aktorik und Sensorik der Maschine ist über eine „aktive Netzwerkbrücke“ mit der Cloud verbunden. Diese übernimmt die Kopplung der Nichtechtzeit von Wide Area Networks (WAN) / Local Area Network (LAN) mit der Echtzeit im Inneren der Maschine. Unterschiedliche Instanzen einer Steuerung lassen sich starten, wobei die dabei instanziierten Module wie NC-Steuerung, Human Machine Interface (HMI), Programmable Logic Controller (PLC), Schnittstelle für Mehrwertdienste und das Communication Module (COM) miteinander kommunizieren. Benötigt ein Modul mehr Rechenperformance, wird dieses dynamisch vom Betriebssystem zur Verfügung gestellt.
Durch eine Bereitstellung von Steuerungstechnik in der Cloud treten allerdings auch einige Herausforderungen zutage. Die größte ist sicherlich die Kommunikation der Soll- und Istwerte zwischen der lokalen Maschine und der globalen Steuerungstechnik über öffentliche Netzwerke. Hierfür ist es wichtig, zunächst die Größe und Zykluszeiten der zu kommunizierenden Nutzdaten zu kennen. Betrachtet man eine heutige 5-Achs-Werkzeugmaschine wie beispielsweise die HSC 600 von Exeron, an der nachfolgende Messungen durchgeführt wurden, so ergeben sich die in Tabelle 1 dargestellten Nutzdaten:
Die zu übertragenden Soll- und Istwerte zwischen Antrieben (Spindel und sechs Antriebe für fünf Achsen) und Steuerung begrenzen sich auf sehr geringe Datenmengen (46 bis 96 Byte), welche aber im 1-ms-Zyklus transferiert werden. Da die Lageregelung auf den Antriebsverstärkern erfolgt, werden lediglich das Antriebssteuerwort und der Lagesollwert an die Achsen über Sercos III übertragen. Nur die Spindel bildet eine Ausnahme, da hier zusätzlich noch der Geschwindigkeitssollwert übermittelt wird. Als Istwerte werden Lage, Geschwindigkeit, Drehmoment und die Messwerte der Endschalter übertragen.
Die von der Steuerung mit den I/O-Modulen kommunizierten Soll- und Istwerte (SPS-relevante Informationen) benötigen nur 50 bis 52 Byte an Daten und werden ebenfalls im 1-ms-Zyklus übertragen. Im Vergleich zu den Achsdaten sind die I/O-Daten eher statisch, das heißt es treten kaum Änderungen auf.
Aufgrund der langsamen Reaktionszeit der meisten I/O-Module wäre eine deutlich reduzierte Zykluszeit mit Sercos III realisierbar. Die zu übertragenen Daten zwischen HMI und Steuerung sind abhängig von der aktuell vom Benutzer betrachteten Ansicht. Dabei übersteigt die zyklische Datenmenge selten 100 Byte bei gleichzeitig geringer Zykluszeit.
Nach der Studie des Statistischen Bundesamtes nutzen 80 % der deutschen Unternehmen mindestens einen DSL-Internet-Anschluss. Ein Anwendungsszenario wäre also, dass ein mittelständisches Unternehmen seine Fräsmaschine mit einer Steuerung aus der Cloud betreibt.
Das Kommunikationsverhalten bei DSL-Anschluss
Aus diesem Grund wurde am Institut für Steuerungstechnik der Universität Stuttgart das Kommunikationsverhalten eines DSL-Internet-Anschlusses analysiert, in dem die Pakete über einen Proxyserver mit 6000 kBit/s geroutet werden. Die Übertragung der Daten erfolgt damit sowohl über Wide Area Network (WAN) als auch über Local Area Network (LAN). Eine Optimierung des Netzwerk-Verkehrs, zum Beispiel durch Priorisierung oder spezielles Routing, soll dabei nicht durchgeführt werden.
Um die Eigenschaften des Kommunikationskanals zu ermitteln, wurde ein Testsystem bestehend aus zwei Twincat-3-Systemen von Beckhoff aufgebaut (siehe Bild 2). Twincat 3 dient dabei als echtzeitfähige Datenquelle/Datensenke, die jeweils im Millisekundentakt Pakete (8 Byte) versendet beziehungsweise empfängt. Vier Byte des Pakets werden hiervon als fortlaufende Zählvariable übertragen, um Ausfälle zu erkennen. Die Realisierung der Übertragung geschieht wie folgt:
■ Der PC mit dem ersten Twincat-3-System erzeugt Pakete (Sender).
■ Die Pakete werden über ADS (Beckhoff-spezifisches Kommunikationsprotokoll) an einen auf dem PC in-stallierten TCP- oder UDP-Server übergeben.
■ Der TCP- oder UDP-Server übermittelt die Pakete an einen zweiten PC mit Twincat-3-System und TCP- oder UDP-Server. Der TCP-Server nutzt dabei SOCK_STREAM der UDP-Server SOCK_DGRAM zur Übertragung.
■ Die Pakete werden über ADS in das zweite Twincat-3-System (Empfänger) übertragen und ausgewertet.
Bild 3. Grenzen der Datenpufferfüllstände bei Datenübertragung mit TCP (oben) beziehungsweise UDP (unten).
© ISWZur Stabilisierung der Verbindung wurde zusätzlich beim Empfänger ein Puffer implementiert, welcher 1000 Pakete – also eine Sekunde – zwischenspeichert. Dieser wird zu Beginn der Messung befüllt.
Um die Verzögerung durch die zwei ADS-UDP-Server zu ermitteln, erfolgte zunächst der Aufbau einer direkten Kommunikation zwischen Sender und Empfänger. Eine Kommunikation über die zwei ADS-UDP-Server findet dabei nicht statt. Im Durchschnitt dauert die Übertragung einer UDP-Nachricht hierbei 22 ms. Wird die Nachricht vom Sender über die ADS-UDP-Server an den Empfänger verschickt, dauert es im Durchschnitt 3 ms länger. Die Verzögerungen durch die zwei ADS-UDP-Server sind also minimal.
Unterschiedliche Tests führten schließlich zu folgenden Ergebnissen (siehe auch Bilder 3 und 4):
Bild 4. Zeitraum zwischen dem Eintreffen von Daten mit TCP (oben) beziehungsweise UDP (unten).
© ISW■ Pakete lassen sich nicht im Millisekundentakt über WAN/LAN übertragen. Wie die Aufzeichnung des Netzverkehrs ergab, wurden im Durchschnitt 204 Pakete bei TCP (verteilt auf zwei TCP-Telegramme mit etwa 1440 Byte und 192 Byte, die direkt nacheinander gesendet werden) und drei Pakete bei UDP zu Nachrichten zusammengefasst. Eine mögliche Erklärung für die Kombination von drei Paketen zu einer UDP-Nachricht ist, dass nur so die Minimallänge eines Ethernet-Frames erreichbar ist.
■ Bei UDP beträgt der Abstand zwischen zwei empfangenen Nachrichten im Empfänger im Durchschnitt 5,8 ms. Da die Nachrichten noch im 3-ms-Abstand auf dem Kabel zu detektieren sind, werden die Nachrichten während der verbleibenden Übertragung zum Empfänger noch zusammengefasst. Wo ist nicht bekannt – vermutlich aber im nicht-echtzeitfähigen UDP-Server des Empfängers.
■ Bei TCP beträgt der Abstand zwischen zwei empfangenen Nachrichten im Empfänger durchschnittlich 145 ms.
■ Der maximale Abstand zwischen zwei empfangenen Nachrichten beträgt bei TCP 240 ms, bei UDP 102 ms.
■ Bei 3,6 Mio. Paketen, die über UDP übertragen worden sind, gingen 270 Pakete verloren. Dabei sind am häufigsten drei aufeinander folgende Pakete ausgefallen (21 mal). Im schlechtesten Fall fielen 72 aufeinander folgende Pakete aus. Unter der Annahme, dass jeweils drei Pakete zu einer Nachricht zusammengefasst worden sind, sind also bis zu 24 Nachrichten ausgefallen.
■ Eine Puffergröße von 1000 Paketen ist deutlich überdimensioniert. Ein sinnvoller Wert liegt zwischen 100 und 300 Paketen.
Zusammenfassend lässt sich festhalten, dass eine cloudbasierte Maschinensteuerung nach dieser Untersuchung durchschnittliche Latenzen bei der Übertragung von 25 ms (UDP) kompensieren muss. Des Weiteren Abstände zwischen dem Eintreffen von Paketen (Sollwerten) von bis zu 240 ms bei TCP und bis zu 102 ms bei UDP sowie einen Ausfall von bis zu 72 aufeinander folgenden Paketen (Sollwerten) bei Nutzung von UDP. Ob sich dieses Verhalten bei erhöhter Anzahl an Bytes – den Datenmengen einer Werkzeugmaschine entsprechend – ändert, ist noch zu untersuchen.
Die Lösung der identifizierten Probleme
Die Latenz bei heutigen Werkzeugmaschinen mit modernen Ethernet-basierenden Feldbussen liegt konstant bei 1 ms. Die durchschnittliche Latenz bei der Nutzung von UDP zur Übertragung von Soll- und Istwerten beträgt hingegen 25 ms. Findet die Lageregelung auf den Antriebsverstärkern statt, stellt eine Zykluszeit-Steigerung kein Problem dar. Heutige CNC-Steuerungen benötigen hauptsächlich den Antriebsstatus, um konturtreu auf der Bahn zu stoppen.
Entscheidender ist, dass die Sollwerte nicht mehr konstant in definierten Zyklen eintreffen. Dies ist nur durch Puffer zu lösen. Treten zusätzlich noch Latenzspitzen von bis zu 240 ms auf, muss der Puffer eine entsprechende Größe haben, um diese abzufangen. Durch einen Puffer von 100 bis 300 ms würde sich das Geräteverhalten nur geringfügig ändern und bei vielen Anwendungen kein Unterschied erkennbar sein. Allerdings muss die Schleppabstandsüberwachung in der CNC abgeschaltet oder zumindest geeignet angepasst werden. Im Gegensatz zu Sollwerten sind Istwerte nicht zu puffern, sondern können direkt an die CNC übergeben werden.
Im Vergleich zu der alternierenden Latenz wiegt der Ausfall von Sollwerten schwerer. Denn dadurch wird die Qualität der Werkstück-Oberfläche beeinträchtigt und im schlechtesten Fall sowohl Werkzeug als auch Werkstück zerstört. Um Telegrammausfälle zu vermeiden, sind drei Ansätze möglich:
1. Wird ein Telegrammausfall erkannt, lassen sich die fehlenden Sollwerte interpolieren. Hierbei können lediglich Informationen im Antriebssteuerwort verloren gehen. Diese Informationen liegen aber normalerweise über mehrere Zyklen an, wodurch sich das Problem verringert.
2. Durch den Puffer von mehreren 100 ms lassen sich theoretisch Sollwerte erneut anfordern, bevor diese benötigt werden. Hierfür sind allerdings die Sollwerte in der Steuerung ebenfalls zu speichern, und entsprechende Kommunikationsmechanismen zum erneuten Anfordern von Sollwerten müssen vorhanden sein.
3. Der Telegrammausfall wird ignoriert und einfach der nächste vorhandene Sollwert genutzt. Diese Strategie führt eventuell zu einer starken Beschleunigung, gefolgt von einem starken Abbremsen der Achsen. Weiterhin hat die Strategie zur Folge, dass der Puffer sich langsam leert. Um dieses zu verhindern, ist die Taktrate der CNC kurzzeitig zu erhöhen, so dass der Puffer wieder aufgefüllt werden kann. Auch hier müssen Kommunikationsmechanismen zum Anfordern von zusätzlichen Sollwerten existieren.
Für beide Probleme gibt es prinzipiell Lösungen. Welche davon letzten Endes am besten geeignet ist, ist noch an einem realen Aufbau zu untersuchen. Die hier vorgestellten Ergebnisse sind Voruntersuchungen für das durch das BMBF geförderte Projekt „Industrielle Cloud-basierte Steuerungsplattform für eine Produktion mit cyberphysischen Systemen“ – kurz pICASSO. In diesem Projekt sind neben dem Institut für Steuerungstechnik der Werkzeugmaschinen und Fertigungseinrichtungen (ISW) der Universität Stuttgart, dem Fraunhofer IPK und dem Institut für Werkzeugmaschinen und Fabrikbetrieb der TU Berlin die Firmen Bosch, Homag, Linutronix, Reis Robotics, Robomotion und Sotec engagiert.
Autoren: Dr. Armin Lechler ist geschäftsführender Oberingenieur am ISW, Jan Schlechtendahl ist am ISW Gruppenleiter für Industrielle Steuerungstechnik, Prof. Dr. Alexander Verl ist Geschäftsführender Direktor am ISW und Fraunhofer IPA.
Der Kongress
Vertiefende Informationen zum Thema liefert der Autor im Rahmen des begleitenden Kongresses zur Fachmesse SPS IPC Drives (26. bis 28. November) in Nürnberg. Der Vortrag ist Teil der Session 1a „Automation und Cloud“ und findet am ersten Messetag um 10 Uhr statt. Das vollständige Kongressprogramm steht auf der Website www.mesago.de/sps zum Download zur Verfügung.
Das könnte Sie auch interessieren
Die Zukunft von CANopen
Ähnlich wie die Automobilindustrie benötigt auch die Industrieautomation immer mehr Busbandbreite. Zudem gewinnt in puncto Kommunikation das Thema Cloud mehr und mehr an Bedeutung. Wie trägt das in beiden Branchen seit Langem etablierte...
mehr...Unbefugter Zutritt abgewehrt
Anlagenmodernisierungen bedingen oft neue sicherheitstechnische Vorkehrungen. So auch bei einem Hersteller von Reinigungs- und Desinfektionsmitteln, der unter anderem den Materialfluss im Bereich eines Rolltors abzusichern hatte.
mehr...Kompakte Steuerungen und Antriebe ein Muss
Smart Factories versprechen dem Betreibern eine hohe Flexibilität - etwa durch den Einsatz von fahrerlosen Transportsystemen oder mobilen Roboterlösungen. Die Automatisierung dieser Subsysteme erfordert wiederum äußerst kompakte Steuerungs- und...
mehr...WLAN in der Fabrik - die Auswahlkriterien
WLAN bietet sich für diverse Anwendungen in der Fabrik an. Aufgrund der vielen Einflussfaktoren ist jedoch nicht immer offensichtlich, wie sich ein Netzwerk nach dem Standard IEEE 802.11 auf die Anforderungen des industriellen Einsatzes optimieren...
mehr...Safety einfach integrieren
Maschinen- und Anlagenbauer gehen mehr und mehr dazu über, Sicherheitsfunktionen über den Kommunikationsbus abzubilden. Wie lässt sich die Integration auf Komponentenseite mit vertretbarem Aufwand bewerkstelligen?
mehr...Flexibel puffern per Software
Die vollständige Automatisierung manueller oder halbautomatischer Prozesse ist bei sehr kurzen Taktzeiten eine große Herausforderung. Der Maschinenbauer Goldfuß setzt in puncto Werkstückträger-Transport auf ein System, welches die Bildung flexibler...
mehr...Individuelle IoT-Systeme
Wie groß? Wie viel Leistung? Wie robust? Welches Gehäuse? Die Anforderungen an IoT-Systeme sind extrem unterschiedlich. Mit der Gestaltung individueller Embedded-Applikationen können perfekt auf die Anwendung gemünzte Geräte entstehen.
mehr...Ein digitales Abbild
Der digitale Zwilling begleitet Maschinen und Anlagen ihr Leben lang – von der ersten Idee über den laufenden Betrieb bis hin zum Blick in die Zukunft. Das Ziel dabei: Fehler vermeiden, Anlagen optimieren und Ausfällen vorbeugen.
mehr...Stolpersteine beim Gleichstrom
Die Frage "Gleichstrom oder Wechselstrom?" gewinnt an Wichtigkeit – nicht zuletzt durch den zunehmenden Einsatz regenerativer Energiequellen, die Gleichspannung erzeugen. Beim Schalten und Schützen mit Gleichstrom gilt es allerdings, einige...
mehr...