Steuerungen, insbesondere SPS-Steuerungen, bilden seit jeher eine wesentliche gerätetechnische Basis für die Automatisierung von industriellen Prozessen. Auch im Zeitalter von Industrie 4.0 (I4.0) und Industrial Internet ist davon auszugehen, dass diese für die Produktionsautomatisierung von morgen weiterhin benötigt werden. Dafür müssen sie jedoch an die I4.0-Fertigungsbedingungen angepasst werden. Worum geht es dabei im Detail? Industrie 4.0 ist gleichbedeutend mit hochgradig vernetzten Produktionssystemen auf Basis von Cyber Physical Systems (CPS), die in diesem Zusammenhang auch als Cyber Physical Production Systems (CPPS) bezeichnet werden. Diese müssen folgende Bedingungen erfüllen:

• Vernetzung in lokalen und globalen Netzwerken
• Überwindung der starken Informationskapselung von Steuerungen
• Einführung des Dienst-Paradigmas in die Produktionsautomatisierung (Produktionsdienste)
• Autonomie, Rekonfigurierbarkeit und Agilität (Plug&Work)
• Interoperabilität zwischen heterogenen Steuerungssystemen
• Dynamische Veränderbarkeit der Abhängigkeiten zur Laufzeit
• Nutzung von Modellen zur Entwicklung ‚höherwertiger‘ Steuerungsansätze
• Orchestrierung heterogener Steuerungen.

Heutige SPS-Steuerungen können diese Anforderungen mehrheitlich nicht beziehungsweise lediglich nur rudimentär oder mit extrem hohem Aufwand erfüllen. Warum ist das so? Aus ihrer historischen Entwicklung heraus sind Speicherprogrammierbare Steuerungen als proprietäre Gerätesysteme ausgelegt, die unter Echtzeit-Bedingungen lokal betrieben werden. Falls aus Anwendersicht eine Vernetzung dieser Steuerungen erforderlich ist, kommen dazu ebenfalls proprietäre oder standardisierte TCP/IP-Protokolle zum Einsatz. Das heißt: Die aus dem Internet und Web-weit verbreiteten Standardtechnologien spielten bei SPS-Steuerungen bisher kaum eine Rolle. Seit einigen Jahren vollzieht sich aber ein Wandel und SPS-Hersteller integrieren zunehmend IKT-Technologien aus der Web-Welt in ihre Systeme.

Unterschiedliche Ansätze für eine Cloud-SPS

Bild 1: Cloud-basierte Werkzeugmaschinensteuerung nach piCASSO: Die lokale Aktorik und Sensorik der Maschine ist über die 'Aktive Netzwerk-Brücke' mit der Cloud verbunden. Diese übernimmt die Kopplung der Nicht-Echtzeit mit der Echtzeit im Inneren der Maschine.

© Universität Stuttgart

So erscheint es aus heutiger Sicht nicht mehr unmöglich, dass künftig auch zeit- und einsatzkritische Funktionen in eine Industrial Cloud ausgelagert werden. Dafür muss beispielsweise die IT-Kapselung der Steuerungsfunktionalität aufgehoben werden. Das bedeutet, dass Steuerungsfunktionen und/oder Steuerungskomponenten aus der klassischen SPS als Software-Objekte herausgelöst werden. Nur so kann die Steuerung als Software-Instanz in einer Cloud fungieren und auch in den prozessnahen Ebenen (Steuerung, Regelung) online und mit höchster Flexibilität eingreifen. Aktuelle Forschungsprojekte verfolgen hier zwei unterschiedliche Ansätze:

• Verlagerung einer klassischen SPS als virtualisierte Steuerung in eine Cloud
• sowie Verlagerung der Steuerungs- pro­gramme/-algorithmen als Dienste in eine Cloud.

Grundsätzlich berücksichtigen beide Ansätze, dass Steuerungsprogramme üblicherweise nach dem Standard IEC 61131-3 erstellt werden. Grund hierfür ist, dass die Industrie Steuerungen aus der Cloud derzeit nur akzeptiert, wenn das Engineering auch industrieüblich erfolgt.

Zum Ansatz der Virtualisierung einer SPS in der Cloud gehört unter anderem das Projekt piCASSO, welches die Universität Stuttgart koordiniert (Bild 1).

Virtualisierung einer SPS in der Cloud

Hierbei wird eine skalierbare Steuerungsplattform für cyber-physische Systeme in industriellen Produktionen erforscht. Virtualisierung bedeutet in diesem Zusammenhang, dass eine klassische Soft-SPS nicht mehr direkt auf einem Rechner läuft. Stattdessen gibt es innerhalb eines Servers eine Anzahl von virtuellen Maschinen (virtuelle Rechner), auf denen jeweils eine Soft-SPS arbeiten kann. Die in piCASSO realisierte Steuerungsplattform bietet eine skalierbare Rechenleistung, die abhängig von der Komplexität der Algorithmen automatisch zur Verfügung gestellt wird. Wesentliche Schwerpunkte der Forschungen sind dabei die strengen Anforderungen der Produktionstechnik wie Echtzeit-Fähigkeit, Verfügbarkeit und Sicherheit. Als Demonstrationsobjekt für die Projekt-Ergebnisse dienen Roboter und Fertigungsanlagen, die über die Cloud gesteuert werden.

Die lokale Aktorik und Sensorik der Maschine ist bei diesem Ansatz über eine ‚aktive Netzwerk-Brücke‘ mit der Cloud verbunden. Diese Netzkomponente stellt die Verbindung zwischen dem echtzeitfähigen Netz im Inneren der Maschine und der nichtechtzeitfähigen Umgebung her. Aktiv bedeutet hier, dass echtzeitrelevante Berechnungen – wie etwa die Ausführung von Regelungsalgorithmen – nicht in der Cloud stattfinden, sondern in der Netzwerk-Brücke selbst. Andererseits werden die Daten für übergeordnete Methoden, Auswertungen oder Echtzeit-Simulationen in die Cloud übertragen.

Zwar kann eine klassische Software-SPS – zum Beispiel Codesys – als virtualisierte Steuerung in der Cloud ablaufen; die Vernetzung und mangelnde Kompatibilität zur Web-Welt sind jedoch problematisch, da sie als geschlossenes System ursprünglich nicht als Internetdienst entwickelt wurde. Eingriffe beziehungsweise Modifizierungen oder Erweiterungen dieser Steuerungen sind durch Dritte kaum möglich. Mit anderen Worten: Funktionalitäten beziehungsweise Steuerungsalgorithmen lassen sich als Dienste nicht oder nur schwer herauslösen. Darüber hinaus sind aufwendige virtuelle Maschinen nötig, die nur als ganze Plattformen (Betriebssystem und alle zugehörigen Komponenten für einen virtuellen Rechner) zur Verfügung stehen und nicht als ‚leichtgewichtige‘ Web-Objekte instanziiert und genutzt werden können. Ein weiterer Nachteil ist, dass eine Virtualisierung vom Grundsatz her das Dienst-Paradigma nicht unterstützt und damit auch nicht die Flexibilität der in der Web-Welt weit verbreiteten Dienste-orientierten Architektur (SOA – Service oriented Architecture) aufweist.

Die Vorteile einer Virtualisierung liegen allerdings gerade darin, dass durch entsprechende Auslegung der Betriebssysteme für die virtuellen Maschinen ein Echtzeit-Verhalten erreicht werden kann. Dies geschieht etwa durch die Erweiterung des Echtzeit-Betriebssystems LinuxRT um Mechanismen des Cloud-Computing sowie Methoden zur Instanziierung mehrerer Steuerungskerne.

Steuerungen als Service aus der Cloud

Mit dem Ansatz, industrielle Steuerungsprogramme nach IEC 61131 als Dienst aus einer Cloud zu nutzen, startete im Jahr  2014 das Projekt CICS (Cloud based Industrial Control Services). Koordinatoren sind die Hochschule Düsseldorf sowie die Universität Augsburg in Zusammenarbeit mit dem Fraunhofer-Institut für Eingebettete Systeme und Kommunikationstechnik ESK. Im Gegensatz zur Virtualisierung von klassischen SPS-Steuerungen entwickelt das CICS-Konzept eine neue, auf Web-Technologien basierende SPS. Das CICS-Architekturmodell basiert im Wesentlichen auf zwei Voraussetzungen:

• In Anlehnung an eine klassische SPS besteht eine CICS-Steuerung aus den Komponenten Steuerungsprogramm (CICS Program), Runtime (CICS Runtime) und E/A-Konfiguration (CICS Router). Diese Komponenten sind bedarfs- und anwendungsorientiert als Dienste im Netz verteilbar.
• Basierend auf Web-Technologien entstehen verschiedene Modelle zur Umsetzung dieser Architektur.

So ergeben sich zwei serverbasierte und zwei clientbasierte Umsetzungen einer CICS-Steuerung mit dem Vorteil der Dienstfähigkeit. Als verkürzte Erläuterung seien hier nur zwei Lösungen erläutert:

In der clientbasierten Lösung dient die Cloud nur der Verwaltung der CICS-Controller-Dienste. Die komplette SPS läuft im Client (Webbrowser) als Dienstinstanz. Die Prozessdaten-Kommunikation zu den Automatisierungsgeräten erfolgt direkt zwischen Client und Gerät – ohne Beteiligung der Cloud.

In einer Server-Client-Mischlösung wird in der Cloud die CICS-Runtime in Form instanziierbarer Dienste ausgeführt, während die E/A-Konfiguration als CICS-Router-Instanz im Client läuft. Auch hier erfolgt die Prozessdaten-Kommunikation direkt zwischen Client und Automatisierungsgerät, wobei allerdings zusätzlich das E/A-Abbild der SPS über einen Blockkanal zwischen Client und Runtime-Instanz zur Cloud übertragen wird.

Beide beispielhaften Lösungen bieten den Vorteil einer extrem hohen Flexibilität während der Laufzeit (Wandelbarkeit). Das geforderte Dienstparadigma ist vollständig bis auf die Ebene der Steuerungsalgorithmen sowie der E/A-Konfiguration umsetzbar. Ein Nachteil liegt aktuell noch darin, dass alle Komponenten einer CICS-Steuerung – inklusive der SPS-Runtime – in einer nicht echtzeitfähigen JavaScript-Umgebung ablaufen. Dies wird sich aber zukünftig durch die Verfügbarkeit deterministischer IP-Netze, Echtzeit-Webbrowser und entsprechender Echtzeit-Betriebssysteme in der Cloud relativieren.

Connectivität in die Cloud

Eine Cloud-SPS benötigt sowohl im zyklischen als auch Event-getriebenen Betrieb eine zuverlässige bidirektionale Verbindung zur Feldebene. Diese kann innerhalb einer privaten Cloud künftig über TSN (Time Sensitive Networks) je nach Ausprägung der lokalen Server-Infrastruktur weitgehend deterministisch erfolgen. Kommt eine Public Cloud – also ein externer Cloud-Anbieter – zum Einsatz, muss nach heutigem Stand das teure und unflexible ‚Multiprotocol Label Switching‘ (MPLS) genutzt werden. So liegen die Kosten für einen MPLS-Link zwischen zwei Unternehmen über dem zehnfachen einer entsprechenden Breitband-Internet-Anbindung. Bei MPLS spricht man von einer verbindungsorientierten Übertragung, in der die zu übertragenden Pakete mit Hilfe von sogenannten Labels eine feste Route innerhalb des Netzes eines Providers nehmen. Das bedeutet, dass ein MPLS-Link in Gegensatz zum verbindungslosen Internet zwischen zwei Partnern geschaltet werden muss, bevor eine Kommunikation stattfinden kann. Je nach Provider und Fähigkeiten der Router kann das mit entsprechendem Aufwand verbunden sein. Eine Änderung in einem Link oder die Hinzunahme von Teilnehmern in ein MPLS-VPN macht einen Eingriff des Providers in sein Netz notwendig. Auf diese Weise garantiert MPLS die geforderte QoS (Quality of Service), also eine festgelegte Bandbreite und Latenzzeit. Künftig soll dies mit Hilfe von SDN (Software Defined Networks) und entsprechenden MNS (Managed Network Services) deutlich einfacher, fle-xibler und kostengünstiger erfolgen.

Sind die Voraussetzungen für eine deterministische IP-basierte Kommunikation erfüllt, kommen zwei verschiedene Transportmechanismen zum Tragen: TCP und UDP. Während in virtualisierten Steuerungen die unterschiedlichsten darauf aufbauenden Anwendungsprotokolle (unter anderem die gängigen M2M-Protokolle) zum Einsatz kommen, fokussiert man bei der serviceorientierten Cloud-SPS auf solche Protokolle, die jeder gängige Webbrowser beziehungsweise jeder Javascript-basierte Applikationsserver wie etwa node.js unterstützt. Über entsprechende Gateways wird dann bei Bedarf eine Brücke zu klassischen Industrieprotokollen geschlagen.

Bild 2: Round-Trip-Zeiten für unterschiedliche Web-Protokolle und Browser.

© CCAD / Fraunhofer ESK

So setzt das Projekt CICS vor allem auf WebSocket in Verbindung mit JSON, eine Alternative stellt WebRTC dar. Während WebSocket auf TCP aufbaut, verwendet WebRTC UDP. Beide haben ihre spezifischen Vor- und Nachteile bezüglich Performance und Security. Da bei WebSocket ein Teilnehmer direkt eine Verbindung zum anderen Teilnehmer aufbaut, muss dieser im Public-Cloud-Szenario auch von außen erreichbar sein. Bei WebRTC bauen hingegen beide Teilnehmer zunächst eine Verbindung mit einem Signalisierungsserver auf, um sich danach direkt zu verbinden. Hier muss also keiner der Teilnehmer direkt von außen erreichbar sein. Untersuchungen zur Round Trip Time (RTT) zeigen, dass WebRTC dem WebSocket-Protokoll überlegen ist, unter anderem aufgrund kürzerer Verbindungs-Aufbauzeiten und einer effizienteren Sicherungsschicht (Bild 2).

Da über WebRTC gleichzeitig Prozessdatenübertragung und Video/Audio-Streaming möglich sind, lassen sich serviceorientierte Steuerungen künftig auf einfache Weise mit Echtzeit-Bilderkennungsdiensten koppeln, was zu völlig neuen Low-Cost-Anwendungen führen könnte. Ein Beispiel sind Telemetrie-Anwendungen, bei denen die automatische Erkennung des Szenarios nicht vor Ort sondern auf leistungsfä-higen Servern geschieht und damit ein mobiler Roboter gesteuert wird. Denkbar sind auch IoT-Anwendungen, bei denen Video/Audio-Informationen zusätzlich zu anderen Sensor-Informationen übertragen werden, um die jeweiligen Umgebungen echtzeitnah zu analysieren.

Die anstehenden Herausforderungen

Auch wenn nach einhelliger Auffassung serviceorientierte Architekturen als neue Technologie in der Automatisierungswelt und damit auch in Industrie 4.0 eine besondere Rolle spielen, stellt die Einführung des Dienst-Paradigmas in der Steuerungstechnik eine besondere Herausforderung dar. Neben den geeigneten Engineering-Werkzeugen kommt es vor allem auf neue Geschäftsmodelle für die Nutzung der Cloud-Computing-Steuerungen an. Dazu gehört zum Beispiel, dass zukünftig auch Steuerungsfunktionen und -algorithmen zeitbezogen vermietet werden können (Control as a Service). Viele Geräte, Maschinen und Anlagen, die mit Steuerungen ausgerüstet sind, arbeiten nicht rund um die Uhr, sondern nur in zeitlich eng begrenzten Rahmen. Durch den Wegfall der Hardware-Steuerungen können Investitionskosten in laufende Betriebskosten umgewandelt werden, welche vielfach wesentlich wirtschaftlicher für den Betreiber sein können. Kurzum: Bekannte Dienst-Geschäftsmodelle aus der IT-Welt könnten sicher zukünftig auch für eine Cloud-Steuerung nach entsprechender Anpassung genutzt werden.

Bezogen auf SPS-Steuerungen sind erste Einsatzfälle zur Nutzung von kompletten Steuerungen als Dienst aus der Cloud etwa in zwei Jahren und zur Nutzung von Steuerungsalgorithmen als ‚Software as a Service‘ voraussichtlich ab 2020 zu erwarten.

Autoren:
Reinhard Langmann ist als Professor an der Hochschule Düsseldorf im Bereich Automatisierungstechnik tätig;
Michael Stiller ist wissenschaftlicher Mitarbeiter am Fraunhofer-Institut für eingebettete Systeme und Kommunikationstechnik ESK.