Industrie 4.0: Probieren statt normieren
Beck IPC bietet einen bewährten Weg vom Sensor zur Cloud
Fortsetzung des Artikels von Teil 1
Der kommende Ethernet-Standard TSN im IIoT
Wie positionieren sich US-Unternehmen zum kommenden Ethernet-Standard TSN (Time-Sensitive Networking)?
Christoph Müller: Bei der Vorbereitung des IIoT sind US-Unternehmen schon weit fortgeschritten. Nicht von ungefähr genießt dort das Thema TSN viel Aufmerksamkeit. Das von ehemaligen Cisco-Mitarbeitern gegründete US-Unternehmen Nebbiolo Technologies beispielsweise hat vor kurzem einen Fog Controller mit TSN auf den Markt gebracht. Bei ihm handelt es sich um einen Server an der Maschine als lokale Kommunikations- und Datenübertragungs-Instanz. Er war auf der Hannover Messe zu sehen.
Warum brauchen wir TSN als weiteren Industrial-Ethernet-Standard, wo es doch schon viele bewährte gibt?
Thomas Schumacher: Um das IIoT voranzutreiben, ist ein Standard wie TSN unentbehrlich. Das IIoT beruht ja letztlich auf dem Internet und nicht auf Automatisierungstechnik. TSN ist als Transportlayer gedacht, der Deterministik nicht auf die Feldebene beschränkt, sondern ins Internet bringt. Der Standard soll also kein unterlagertes Automatisierungsnetz unterhalb des IT-Netzes darstellen, sondern die beiden zum Verschmelzen bringen. Das Ziel von TSN ist also, die Hürde zwischen Internet/IT- und Automatisierungswelt zu entfernen, indem Automatisierungs-und IT-Netz mit Deterministik zusammenwachsen.
Genau das leisten die etablierten Industrial-Ethernet-Protokolle nicht: Sie sind im Gegensatz zum TSN-Protokoll nicht Internet-fähig, können also keine Welten miteinander verbinden.
Die TSN-Initiative sah den Zweck von TSN anfangs hauptsächlich darin, eine Echtzeit-Basis für das OPC-UA-Protokoll herzustellen. Ihr Unternehmen definiert die Bedeutung von TSN also viel umfassender …
Christoph Müller: Ja, und da wären wir bei einem weiteren Unterschied zwischen deutschen und US-Unternehmen: Die Amerikaner betrachten TSN als Kern der Sache, und ihnen ist egal, was oberhalb von TSN läuft, ob OPC UA, MQTT oder MTConnect. Interessanterweise treiben in den USA die Infrastrukturanbieter hier die Entwicklung voran; Router von Cisco, die zugleich als Fog Controller dienen, wären ein entsprechendes Konzept. Ein Zeichen für einen solchen Trend ist, dass sich in den USA zusätzlich zum IIC ein »Fog Club« gebildet hat. Auf jeden Fall erwarten wir, dass TSN ein wichtiges Thema werden wird.
Ihr Unternehmen entwickelte schon 2010 eine Kommunikationslösung, die Unternehmens-IT und OT (Operational Technology), also die Feldebene, miteinander verbindet. Welche Ziele verfolgten Sie seinerzeit damit?
Thomas Schumacher: Die Version 1 unserer Kommunikationslösung war marktreif, bevor OPC UA die Aufmerksamkeit der Fachwelt auf sich zog und von TSN die Rede war. Seit 2014 gibt es übrigens die Version 2.
Schon 2010 wollten wir zwei Ziele erreichen, die immer noch hochaktuell sind: Erstens ging es uns darum, die Vorteile der IT etwa in puncto Programmierung und Rechenleistung für die Automatisierung nutzbar zu machen. Und zweitens wollten wir IT und OT verschmelzen, weil das die Chance eröffnet, Intelligenz vom Feld ins Internet zu verlagern, genauer gesagt: als Service in die Cloud. Denken Sie an das autonome Fahren: Es wird erst dann richtig funktionieren, wenn alle Autos online sind und eine übergeordnete Instanz den Verkehr regelt. Ähnliches kann auch in der Automatisierung funktionieren – die übergeordnete Instanz wäre hier die Cloud. Autonomes Fahren erfordert Sensorik, Deterministik sowie Algorithmen zur Daten- und Befehlsverarbeitung; Automatisierung auf Cloud-Basis benötigt genau dasselbe.
Welchem Funktionsprinzip folgt Ihre Kommunikationslösung?
Thomas Schumacher: Als Basis dient ein Kommunikationsverfahren, das den IT-Leuten einen digitalen Zwilling aus der Automatisierung, also ein Prozessabbild, zur Verfügung stellt. Der klassische EVA-Zyklus auf der Feldebene besteht aus Eingabe, Verarbeitung und Ausgabe. Unser Ziel ist, den EVA-Zyklus so weit wie möglich im Internet, also in der Cloud, laufen zu lassen. Eine HTML5-HMI als digitaler Zwilling im Internet bedeutet, dass die Visualisierung as-a-Service in der Cloud stattfindet und auf der Feldebene nicht mehr nötig ist. Aufrufen lässt sie sich dann mit jedem beliebigen Endgerät, meist im Browser. Digitale Zwillinge der Automatisierung laufen also as-a-Service im Internet, sprich: in der Cloud.
Denkbar ist natürlich nicht nur Visualisierung-as-a-Service, sondern auch Predictive-Maintenance-as-a-Service und sogar Steuerung-as-a-Service. Und Maschinenfunktionen lassen sich as-a-Service freischalten und sperren. Wenn immer mehr Intelligenz in der Cloud ist, bedarf es letztlich weniger Intelligenz im Feld, was Kosten spart. Mehrwert lässt sich auch durch Anbindung von Apps an die Produktion schaffen, mit denen Kunden individuelle Erzeugnisse entwerfen und bestellen können, die dann in Losgrößen bis hinunter zu Eins gefertigt werden. Wir liefern die Technik zur Anbindung von Apps sowie von Plattformen für Services, die einen Mehrwert bringen.
- Beck IPC bietet einen bewährten Weg vom Sensor zur Cloud
- Der kommende Ethernet-Standard TSN im IIoT
- Kommunikationslösung für das IIoT
Lesen Sie mehr zum Thema
