.png)
Unified Namespace und die Automatisierungspyramide
- Stephan Bellmann
- vor 6 Tagen
- 21 Min. Lesezeit
Daniel Goldeband über das Aufbrechen der Automatisierungspyramide und wie Unified Namespace das Problem deutscher Produktionen lösen kann.
Inhalt
Über das Interview
Das Interview mit Daniel war ein sehr lockeres Interview. Ich bin auf sehr viel Kompetenz kombiniert mit lockeren Sprüchen gestoßen. Daniel ist Mitgründer von iFlow und man merkt einfach, dass er sein Business versteht. Neben der Idee des Unified Namespace und seiner Unternehmung wird auch sehr gut und an einigen konkreten Beispielen die Idee hinter Industrie 4.0 erklärt. Daniel fällt es nicht schwer, die Probleme der produzierenden Unternehmen klar und einfach zu benennen. Man bekommt in dem Interview einen wirklich guten und generalisierten Überblick über die Lage in den heutigen deutschen Unternehmen. Die Idee hinter iFlow wird in diesem Interview klar und deutlich erklärt. Ein Startup, mit bereits internationaler Erfahrung, das zur Entwicklung deutscher Unternehmen beitragen kann.
“Wenn ich scheiß Prozesse digitalisiere, habe ich am Ende einen digitalen Scheißprozess.”
Über Daniel Goldeband
Daniel hat nach seinem Studium zum Wirtschaftsingenieur im Traineeprogramm bei Bosch angefangen. Danach war er für mehr als vier Jahre bei Bosch Rexroth und hat mehrere Stationen im Bereich IIoT durchlaufen und hat damit Industrie 4.0 im Unternehmen vorangetrieben. 2021 hat er mit zwei weiteren Kollegen das Unternehmen iFlow gegründet, mit dem er die Idee des Unified Namespace an produzierende Unternehmen weitergibt.
Hauptthemen
Der veraltete Umgang mit Daten im Zuge der Industrie 4.0 Entwicklung
Problem der Erreichbarkeit von Fabrikdaten
Was ist das Problem für Unternehmen, die Industrie 4.0 umsetzen möchten?
Das übergeordnete Problem ist die nicht ausreichende Erreichbarkeit der Fabrikdaten im Zuge der Industrie 4.0 Entwicklung. Veraltete Enterprise-Architektur-Modelle wie die weit verbreitete Automatisierungspyramide erschweren diese Erreichbarkeit. Einzelne Projektansätze können diese Probleme vielleicht stellenweise lösen, jedoch können diese Lösung nicht hochselektiert werden.
Industrie 4.0 Reifegrad
Wie gut sind produzierende Unternehmen gegenüber der Industrie 4.0-Entwicklung gerüstet?
Die Enterprise-Architektur Unified Namespace gilt als Enabler für die Entwicklung einer Industrie 4.0 Produktion. Daniel benennt einen Reifegrad, der die Einführung einer Unified Namespace Architektur ermöglicht.
Stufe 0: Das Unternehmen hat seine Prozesse sauber definiert und standardisiert. “Wenn ich scheiß Prozesse digitalisiere, habe ich am Ende einen digitalen Scheißprozess.”
Stufe 1: Das Unternehmen stellt seine Prozesse transparent dar. Die Effektivität der Maschine muss beispielsweise als Dashboard abbildbar sein.
Stufe 2: Das Unternehmen hat smarte Prozesse implementiert, wie z.B. Predictive Maintenance
Stufe 3: Das Unternehmen führt eine Smart Factory. Die Produktionsprozesse werden smart umgesetzt. Diese Stufe des Reifegrades ist aber bei kaum einem Unternehmen erreicht.
Problem der Automatisierungspyramide
Warum ist die Automatisierungspyramide für Industrie 4.0 Ansätze ungeeignet?
Bei dem Modell der Automatisierungspyramide gibt es zwei gravierende Nachteile:
Erreichbarkeit der Daten: Mit der Aufteilung der verschiedenen Ebenen der Automatisierungspyramide bleiben die Daten oft auf den jeweiligen Ebenen hängen bzw. sind schwer zu erreichen. Beispielsweise generiert eine Maschine viele Daten, die jedoch im System der Maschine verbleiben. Das gleiche gilt auch für MES- oder ERP-Systeme. Es bilden sich sogenannte Datensilos, deren Erreichbarkeit begrenzt ist.
Qualität der Daten: Durch die Vielzahl von Maschinenherstellern und MES-Anbietern stehen Daten herstellerspezifisch in unterschiedlicher Qualität zur Verfügung. Es gibt somit unterschiedliche Protokolle und Schnittstellen, was den Zugang zu den Daten massiv erschwert.
Unified Namespace erklärt
Unified Namespace als zentraler Zugangspunkt aller Fabrikdaten
Was ist Unified Namespace?
Im Kern geht es um die IT-OT-Konvergenz, bei der sich im Zuge der Industrie 4.0-Entwicklung die Daten aus der IT-Ebene und der OT-Ebene immer mehr vermischen. Single Interface to Clean Factory Data ist das Stichwort, das Daniel benennt. Also ein zentraler, standardisierter Speicherort für alle Fabrikdaten, um dessen Zugriffe zu erleichtern: Das Unified Namespace. Dabei geht es um eine datenzentrierte Architektur, bei der die Daten im Mittelpunkt stehen und die Systeme und Applikationen drum herum aufgebaut werden.
Unified Namespace als ebenenübergreifende Lösung vs. Automatisierungspyramide
Warum ist Unified Namespace besser als die Automatisierungspyramide?
iFlow möchte über den Ansatz von Unified Namespace das Datenmodell der Automatisierungspyramide aufbrechen, um die Daten nicht auf den jeweiligen Ebenen der Automatisierungspyramide zu belassen, sondern um die Daten zentral und ebenenübergreifend abspeichern und abrufen zu können (Publish Subscribe Mechanismus).
Das Problem der verschiedenen Anbieter
Das Problem der verschiedenen Maschinenhersteller bleibt doch weiter bestehen?
Auch mit der Lösung von Unified Namespace bleibt das Problem der verschiedenen Anbieter bestehen, denn auch gegenüber dem Unified Namespace sind diese Daten bzw. Schnittstellen nicht standardisiert. Aber genau dafür bietet iFlow eine Lösung gegenüber dem Kunden an, sodass der Kunde dieses Problem an iFlow abgibt. Der Ansatz von iFlow ist es, aus der Komplexität der Datenstruktur eine einfache Anwendung zu machen. Oft werden komplexe Probleme mit vermeintlich einfachen Lösungen noch komplexer, die dann wiederum nur von Experten bedient werden können. Genau das möchte iFlow nicht.
Aktuelle Analyse deutscher Produktionen
Deutsche Produktionen zu 80% veraltet
Hinken wir in Deutschland wirklich so sehr hinterher?
Der aktuelle Stand der deutschen Produktion ist besonders auf der OT-Ebene veraltet. Dies gilt besonders für die dort verwendeten Softwaresysteme.
Erstmal Industrie 4.0 implementieren
Was ist mit Industrie 5.0?
Oft hört man bereits von Industrie 5.0 und weiter. Laut Daniel müsse jedoch erstmal Industrie 4.0 implementiert werden, bevor wir über weitere Begriffe nachdenken sollten.
Das Problem liegt oft im Mindset der deutschen Unternehmen
Worin fehlt es uns hier in Deutschland?
Die Idee Industrie 4.0 kommt zwar aus Deutschland. Dennoch fehlt es hier im Vergleich z.B. zur USA oft am agilen und risikobereiten Mindset.
Interview
Ich habe mir mal deinen Werdegang angeguckt und es ist ja schon beeindruckend, was du alles gemacht hast. Du hast angefangen an der RWTH. Was hast du da studiert?
Ich habe Wirtschaftsingenieurwesen Fachrichtung Maschinenbau studiert.
Also Mechanical Engineering with Business Administration. Richtig?
Im Englischen, ganz genau.
Und danach warst du zwei Jahre bei Bosch, da warst du im Trainee-Programm!?
Genau, ja, da gibt es so ein Trainee-Programm. Da hast du die Möglichkeit, dir die unterschiedlichen Unternehmensbereiche anzugucken. Und das habe ich für zwei Jahre gemacht. Man darf dann sogar auch ins Ausland. Ich habe mich dann immer so in dem Themenbereich Industrial Internet of Things getummelt und das eben aus unterschiedlichen Blickwinkeln betrachtet. Einmal aus Kundensicht, einmal aus Anwendersicht, einmal aus Entwicklersicht. Genau, also die unterschiedlichen Perspektiven angenommen, die so ein
Industrial Internet of Things Projekt hat.
Und danach warst du ganze vier Jahre bei Bosch Rexroth. Das ist ein riesiges Unternehmen. Also die haben etwa 33.000 Mitarbeiter, weltweit. Und die sind hauptsächlich in der Steuerungstechnologie unterwegs, wenn ich das richtig gelesen habe?
Jaja, das gehört ja auch zu Bosch. Das ist eine 100%tige Bosch-Tochter.
Ja genau, die haben verschiedene Bereiche. Ich glaube, die hießen früher Mannesmann oder so. Dann hat es Bosch gekauft und dann wurde es irgendwann zu Rexroth. Die haben ganz viele Bereiche. Die Hydraulik ist ganz groß. Bagger, mobile Geräte, da kommt viel auch von Bosch Rexroth. Dann machen die noch Industrietechnik, und dazu gehört dann die Steuerungstechnik oder auch Lineartechnik.
Also das, was man oft in Maschinen und Anlagen findet oder auch Transfertechnik, was auch in der Fabrik zu finden ist. Ich war dort immer im Bereich Industrietechnik unterwegs.
Und kannst du so ein bisschen erzählen, was du da gemacht hast?
Okay, das waren zwei Stationen. Die eine Station war direkt nach dem Trainee-Programm, da habe ich als Projektleiter Industrie 4.0 vorangetrieben. Das war ein Standort in Stuttgart von Bosch-Rexroth. Da war Industrie 4.0 noch relativ in den Kinderschuhen.
Ich glaube, Siemens oder so hatte diesen Begriff geprägt. Und dann ist es irgendwann auch zu Bosch gekommen. Und dann hat Bosch gesagt, jetzt brauchen wir Projektleiter in den Werken, die die Themen vorantreiben, also Digitalisierung von Wertströmen. Und das habe ich dann für zwei Jahre gemacht als Projektleiter.
Und danach habe ich das Thema als Gruppenleiter weitergeführt. Das heißt, ich habe ein Team bekommen und wir haben das Ganze ein bisschen größer gedacht. Zusammen mit meinem Team waren wir dann dafür zuständig, das für eine komplette Business-Unit voranzutreiben. Also unsere Aufgabe war es am Ende, Industrie 4.0 oder auch die Digitalisierung der Wertströme in unseren Werken voranzutreiben.
Und das hast du dann bis zum Ende gemacht, also bis 2021. Und danach hast du dich selbstständig gemacht. Bei dir im LinkedIn-Profil steht Geschäftsführer. Klingt cool.
Haha, ja, genau, ich habe mich selbstständig gemacht mit zwei Mitstreitern. Wir waren alle vorher bei Bosch. Und die anderen beiden haben auch mal in meinem Team gearbeitet. Dann haben wir gemeinsam gegründet, weil wir einfach ein Problem erkannt haben, worum es ja auch wahrscheinlich gleich geht.
Genau: wie kommt man eigentlich an die Daten im Unternehmen, um am Ende Industrie 4.0 Projekte zu machen!?
Genau! Also von ganz einfachen Projekten wie der Visualisierung von Kennzahlen einer Maschineneffektivität, bis hin zu Analytics und AI, wo man dann wirklich große Datenmengen genutzt hat, um Modelle zu trainieren. Und diese Use Cases haben alle eins gemeinsam, nämlich sie brauchen Daten. Und das ist einfach super painful, heute an diese Daten zu kommen.
Da gab es einfach kein cooles Tool, also weder am externen Markt noch intern bei Bosch, was uns irgendwie dazu befähigt hätte, diese Themen in unseren Werken skalierbar aufzusetzen. Also nicht: ich mache jetzt mal ein Projektchen, sondern es wirklich skalierbar zu machen, dass es auf unterschiedlichen Standorten applizierbar ist. Und daran ist es immer gescheitert. Deshalb haben wir eben irgendwann gegründet, um das Problem zu lösen.
Das heißt, heute macht ihr das mit iFlow, also über euer Startup. Das gibt es wie lange? Drei Jahre oder so?
Genau, dreieinhalb Jahre.
Aber nicht nur ihr seid auf dem Markt, nicht nur ihr habt die perfekte Lösung, auch andere haben mittlerweile sehr gute Lösungen. Ist das richtig?
Ja, also wir haben die perfekte Lösung, andere haben eine gute Lösung und sind auch da dran. Am Ende kann man das unter IT-OT-Konvergenz zusammenfassen. Also, IT ist ja am Ende die IT-Ebene, die beispielsweise über eine Software wie SAP abgebildet wird. ERP oder MES. Und unten die OT-Ebene, also eben die Ebene mit den Assets, die du brauchst für deine Produktion, wie Maschinensensoren, Aktuatoren usw. Das ist sozusagen die Feldebene, die OT-Ebene. Und diese beiden Welten, also IT und OT, die verschwimmen immer mehr auf Basis eben vor allem der Technologien und der Weiterentwicklung der Technologien. Und diese IT-OT-Konvergenz beschreibt im Prinzip den großen Trend, der mit Industrie 4.0 eben so bisschen angefangen und aufgedeckt hat, was eigentlich so die großen Probleme sind.
Und diese IT-OT-Konvergenz, dieser Begriff, der beschreibt eigentlich ganz gut, wie die Technologien sozusagen zusammenwachsen, um am Ende aus IT und OT eine Einheit zu machen, sodass man eigentlich gar keinen Unterschied mehr hat, ob jetzt eine Maschine oder ob ich die Software bediene. Ähnlich wie bei deinem Smartphone. Das ist einfach nur ein smartes Device mit ganz ganz viel Technik und Software drin und diese Plastikhülle da drum rum, die spielt eigentlich immer weniger eine Rolle. Und wir sind in diesem Bereich und kümmern uns eben im Speziellen um diese Themen. Aber natürlich gibt es da auch ganz ganz viele andere Technologien und Anbieter, die sich in dem Umfeld tun.
Ich weiß selber, dass viele Unternehmen damit zu kämpfen haben, das wirklich umzusetzen, wirklich innovativ zu werden und den richtigen Weg einzuleiten. Da kommen ständig neue Technologien und Innovationen auf den Markt. Das ist doch schwierig für Unternehmen, den richtigen Weg zu finden. Gibt es hier “Vorzeigeunternehmen”, die den genau richtigen Weg in die richtige Zukunft einleiten?
Wir sehen tatsächlich bei unseren Kunden oder auch mit den potenziellen Kunden, mit denen wir sprechen, ein ganz großes Spektrum an Reifegrad. Wir sehen die, die gerade anfangen, und wir sehen die, die noch nicht am Ende sind, aber die relativ weit sind sozusagen, wenn man es mal als Industrie 4.0 Reifegrad betitelt. Im Prinzip gibt es da mehrere Stufen. Also Stufe 0 ist immer: ich brauche saubere und vor allem standardisierte Prozesse.
Wenn ich scheiß Prozesse digitalisiere, habe ich am Ende einen digitalen Scheißprozess. Also bringt mir nichts, wenn ich die Prozesse nicht vorher gerade ziehe. Und dann ist der nächste Punkt, die Prozesse transparent zu machen. Zum Beispiel, wie ist denn meine Maschinen-Effektivität, damit ich diese am Ende auswerten und analysieren kann und auch Maßnahmen definieren kann. Um dann zu schauen, wie kann ich diese Effektivität verbessern und sie dann auch nachvollziehen, ob meine Maßnahmen auch wirklich greifen. Der dritte Schritt ist dann, ich habe nicht nur Dashboards, die mir Kennzahlen und transparente Prozesse anzeigen, die ich dann verbessern kann, sondern ich habe smarte Prozesse. Das heißt, ich kann zum Beispiel über Predictive Maintenance vorhersagen, wann die Maschine ausfällt, damit ich zum Beispiel Kosten einspare.
Also, Long Story Short gibt es in diesem Reifegrad-Prozess Unternehmen, die noch am Anfang stehen und Unternehmen, die schon sehr weit sind.
Ist iFlow nur unternehmensintern anzuwenden oder wird es auch unternehmensübergreifend angewendet?
Es gibt einen Kunden von uns, der nutzt iFlow, um seine globale Supply Chain zu digitalisieren. Und wir als iFlow funktionieren da als zentraler Data Hub, also als zentraler Daten Hub, der Systeme und Produkte weltweit von sich, aber auch von seinen Partnern integriert. Und das ist in dem Fall Sto. Sto ist ein großes Unternehmen und führend im Fassadenbau und der Fassadenvorfabrikation.
Und der nutzt iFlow tatsächlich, um Daten unternehmensübergreifend zu integrieren. Unser originärer Use-Case ist allerdings innerhalb eines Unternehmens. Das heißt, das sind typischerweise die Unternehmen, die sagen: Wie kann ich erstmal meine Daten, die ich generiere, nutzen, um meine Prozesse transparent zu machen, um meine Prozesse zu optimieren und zu automatisieren.
Das ist eigentlich unser originärer Use-Case innerhalb einer Fabrik und Fabrik übergreifend.
Die agile, unternehmensübergreifende Produktion ist ja wahrscheinlich noch eher die Wunschvorstellung. Also ein Kunde schickt einfach einen Auftrag in eine virtuelle Fabrik und dann passiert das alles automatisiert über Verwaltungsschalen bzw. Assets. Das ist jetzt in dieser Form noch nicht bzw. kaum umsetzbar!?
Genau, diesen Reifegrad gibt es Stand heute nur auf Powerpointfolien, weil das ist am Ende die nächste Stufe, dass man sagt, ich habe nicht nur Predictive Maintenance, sondern ich automatisiere sozusagen auch noch die Entscheidungszyklen. Das heißt, ein kundengenerierter Auftrag, der sehr individuell ist und auf der Basis von Simulationen in die Fabrik gebracht wird, der dann auch automatisiert verarbeitet und produziert wird. Das ist am Ende noch Wunschkonzert, aber ja, coole Vision, glaube ich.
Ja, dann lass uns doch mal reingehen in die Automatisierungspyramide. Du hast im Vorgespräch gesagt, dass das eigentlich ein veraltetes System ist. Warum?
Die Automatisierungspyramide, so wie sie heute ist, ist ja im Prinzip erstmal nur ein Modell, das es schon, ich weiß gar nicht, vielleicht seit den 80ern oder so gibt und auf dessen Basis viele produzierende Unternehmen oder wahrscheinlich alle produzierende Unternehmen ihre Enterprise-Architektur aufgebaut haben. Das heißt, man hat Maschinen, Sensoren, Aktuatoren auf der Feldebene und über unterschiedliche Software-Systeme, wie zum Beispiel SCADA, MES, ERP-Systeme, werden diese Daten dann eben genutzt oder auch aggregiert, um am Ende Unternehmensentscheidungen oder auch Entscheidungen bezüglich des Produktionsprozesses zu fällen. Und dieses Konstrukt, dieses Modell, ist
ein Stück weit in die Jahre gekommen, weil es jetzt im Zuge von Industrie 4.0 und im Zuge dieser “Industrial Initiative Things” Bewegung einfach neue Anforderungen gibt an diese Enterprise Architektur. Also wenn man früher gesagt hat, ich integriere mein System, also meine Maschine in meine Enterprise Architektur, dann habe ich das einmal gemacht und ich wollte das nie wieder anrühren. Never change a running system Style. Heute aber durch die Anforderungen von Industrie 4.0 oder auch “Industrie Interactive Things” Projekten, brauche ich die Daten nicht nur in meinem ERP- oder MES System, sondern ich brauche die Daten zum Beispiel auch in meinem Analytics System. Ich vergleiche Analytics Use Cases gerne auch mit agiler Entwicklung von Software. Genauso ist es im Analytics Projekt. Ich weiß am Anfang noch nicht zu 100 Prozent, welche Daten ich aus meiner Enterprise-Architektur brauche, wie müssen die Daten formatiert und strukturiert sein, was will ich am Ende überhaupt alles machen mit den Daten. Das ergibt sich alles über die Zeit, das ist ein ständiger iterativer Prozess. Und genau diese Agilität, die muss ich eben auch in meiner Enterprise-Architektur abbilden können, damit ich diese Daten eben auch nutzen kann. Und nicht wie heute, dass sie vergraben sind in ganz vielen unterschiedlichen Silos innerhalb der Automatisierungspyramide.
Das Modell der Automatisierungspyramide ist also zu starr. Das ist bezogen auf die Daten nicht agil genug!
Genau! Zwei große Kernprobleme, die sich aus dieser Automatisierungspyramide ergeben, sind einmal die Datenverfügbarkeit, weil die Daten in ganz vielen Silos vergraben sind. Zum Beispiel in deinen Maschinen, in deinem ERP- oder MES-System. Dann ist immer die Frage, wie komme ich jetzt an die Daten?
Und Problem Nummer zwei ist die Datenqualität. Also einfach weil die Vielfalt an Maschinenherstellern, an Steuerungsherstellern, MES-Anbietern und so weiter so groß ist, sehen die Daten, die in diesem System liegen, immer anders aus und werden auch über unterschiedliche Protokolle oder über unterschiedliche Schnittstellen bereitgestellt. Und das macht es sehr komplex, an die Daten dran zu kommen und dann auch eben so aufzubereiten, dass sie in der notwendigen Qualität auch verfügbar sind.
Punkt zwei leuchtet mir ein. Da geht es um Standardisierung. Aber Punkt eins verstehe ich nun nicht so ganz. Da entstehen sozusagen Datensilos. Eventuell kommt man nicht an die Daten dran, hast du gesagt. Aber warum? Warum komme ich nicht an meine Daten ran? Die liegen doch im System.
Es gibt ja innerhalb der Automatisierungspyramide, zum Beispiel bei Maschinen, ganz ganz viele Steuerungshersteller. Und immer wenn ich an Daten von meiner Maschine möchte, muss ich irgendwie eine Schnittstelle in der Steuerung bedienen. Das Problem bis jetzt, es gibt ganz ganz viele Steuerungshersteller auf der Welt. Es gibt zwar ein paar große, aber diese Schnittstellen sehen immer anders aus. Also das Protokoll ist immer ein anderes. Das ist meistens herstellerspezifisch. Und zweitens hängt es auch davon ab, wie der Maschinenprogrammierer am Ende die Daten in der Steuerung bereitgestellt hat, am Ende an die Daten zu kommen. Weiter höher gedacht, also von der Maschine weggehend, zum Beispiel MES, das gleiche Problem. Es gibt ganz, ganz viele MES-Anbieter oder veraltete Software, die noch gar keine Schnittstellen bieten. Da komme ich gar nicht an die Daten ran. Oder es gibt ganz viele MES-Anbieter, wo es eine Schnittstelle gibt, aber die ist super veraltet. Oder ich muss direkt auf die Datenbank zugreifen und ich habe noch keine moderne REST-Schnittstelle. Also auch in der IT gibt es ganz, ganz viele Schwierigkeiten, an die Daten zu kommen. Und das ist auch bei den großen Anbietern ein fucking Pain. Zum Beispiel bei SAP.
Heute mit S4HANA ist es deutlich einfacher geworden, an die Daten zu kommen. Aber früher, also vor zwei, drei Jahren, war das noch eine verdammte Katastrophe. Da wurde mit sehr, sehr vielen prioritären Schnittstellen und Protokollen agiert, damit man an Daten aus SAP kommt.
Kann man sich als Außenstehender wahrscheinlich gar nicht vorstellen, dass das so ein Problem ist. Aber das ist ja wirklich ein riesen Problem mit der Standardisierung!? Was ist da die Lösung?
Genau, richtig. Es gibt Standardisierungsinitiativen wie zum Beispiel OPC UA oder andere. Aber selbst die bringen Probleme bzw. Herausforderungen mit sich. Zum Beispiel die OPC UA-Spezifikation, die ist so breit, die besteht aus mehreren tausend Seiten. Dadurch, dass die so flexibel ist und so viele optionale Elemente enthält, wird sie Stand heute von den unterschiedlichen Maschinenherstellern ganz unterschiedlich implementiert. Das heißt, selbst wenn ich zwei Maschinen habe oder zwei Systeme, die OPC UA sprechen, heißt das noch lange nicht, dass die problemlos interagieren können. Es ist am Ende ein Lottogewinn, dass die beiden wirklich interoperabel sind, also Plug and Play miteinander funktionieren. Das heißt also, obwohl es diese Standards gibt, und es ist auch gut, dass es die gibt, weil OPC UA schon vieles vereinfacht. Aber, obwohl es diese Standards gibt, ist es heute immer noch ein Pain. Und die Lösung dazu ist am Ende, was wir Unified Namespaces nennen, was ein zentraler Zugangspunkt ist, ein zentraler Ort für saubere Fabrikdaten. Auf Englisch Single Interface to Clean Factory Data. Und dieser Unified Namespace, der beinhaltet am Ende alle Businessdaten, die eben relevant sind, um zum Beispiel solche Industrie 4.0 Projekte zu fahren.
Also ihr habt da ein Space sozusagen, wo alle Daten gesammelt sind und jeder kommt an die Daten dran. Da gibt's keine Unterschiede mehr zwischen unterschiedlichen Anbietern und Protokollen und so weiter.
Genau, Unified Namespace ist, wie gesagt, ein zentraler Zugangspunkt, ein zentraler Ort. Wir nennen das auch Single Source of Truth für Fabrikdaten. Dort können eben unterschiedliche Systeme wie IT- oder auch OT-Systeme angebunden und integriert werden, was einen extrem großen Vorteil hat. Ich kann jetzt verschiedenste Systeme, zum Beispiel meine Maschine, nur noch einmalig in den Unified Namespace anbinden und die Daten können von dort aus in jegliche Zielsysteme innerhalb dieses Unified Namespaces verteilt werden. Das basiert auf einem Publish Subscribe Mechanismus. Das heißt, die Daten werden in den Unified Namespace publiziert und von dort aus können sie von jedem Zielsystem abonniert werden. Also das heißt weiter verteilt werden.
Aber gibt es in dem Unified Namespace bezogen auf die Datenarchitektur nicht auch sowas wie eine Automatisierungspyramide? Du generierst ja Daten in der Fabrik, also auf der Feldebene. Dann hast du ja trotzdem noch die Steuerebene, die Prozessleitebene usw. Also die Aufteilung zwischen IT und OT.
Du brauchst ja eine gewisse Datenstruktur, selbst in einem Unified Namespace oder nicht?
Also am Ende ist es so, dass wir mit dem Unified Namespace sozusagen diese Automatisierungspyramide aufbrechen. Das ist nicht mehr ein starres Konstrukt, wo die Daten von den Maschinen über Sensoren und über PLCs zum SCADA, zum MES und ins ERP ganz starr fließen, sondern wir brechen das auf und die Sensorik, die Maschinen und so weiter, sprechen direkt mit dem Unified Namespace, werden direkt dort angebunden. Und auch die IT-Systeme sind an dem Unified Namespace angebunden, was dazu führt, dass alle Daten in diesem zentralen Zugangspunkt vorhanden sind und zugänglich sind für jeden User, aber auch für jedes Zielsystem, also für jedes System, was diese Daten braucht. Das heißt, wir brechen diese starre Verkettung von Systemen innerhalb einer Automatisierungspyramide auf.
Das coole daran ist, wir nennen das Data Centric Architectures, also datenzentrierte Architekturen. Das heißt, man geht weg von applikationszentrierter Architektur. Zum Beispiel SAP hat seine Daten, meine MS hat andere Daten, die Maschine hat wiederum andere Daten und alle sind Silos für sich. Ich aber stelle die Daten in den Mittelpunkt meiner Architektur und die Systeme und Applikationen baue ich darum herum.
Aber die verschiedenen Anbieter der Maschinen und IT-Systeme bleiben ja. Wie kommunizieren die dann genau mit dem Unified Namespace?
Sehr gute Frage. That's where the magic happens. Genau dafür bietet iFlow eine Lösung, also unsere Software, über ganz, ganz viele Kollektoren. Also wir haben über 200 Kollektoren zu allen gängigen OT- aber auch IT-Systemen, wo eben unsere Kunden diese Interfaces, diese Schnittstellen nutzen können, um am Ende ihre Systeme in den Unified Namespace zu integrieren. Und… Wir sagen auch nicht, wir können alles, also wir können bei weitem nicht alles, einfach weil die Vielfalt so groß ist an Systemen und proprietären Schnittstellen. Aber dazu bieten wir zum Beispiel über ein SDK, also über ein Software Development Kit, die Möglichkeit, dass unsere Kunden oder Dienstleister eigene Schnittstellen implementieren können.
Und das machen die Anbieter auch mit oder gibt es da Probleme vertraglicher Natur?
Nein, also da gibt es keine Probleme, weil zum Beispiel das Siemens S7-Protokoll, also Siemens RFC, das proprietäre Protokoll von Siemens zum Beispiel. Da gibt es Bibliotheken zu, die man nutzen kann und dann eben einbindet. Und wir haben eben eine Abstraktionsebene als Software implementiert für den User.
Wie erfolgreich seid ihr mit eurer Idee? Das klingt ja alles nach einer perfekten Lösung auch als Grundlage für Industrie 4.0 Technologien.
Ja, unsere Kunden sind super zufrieden. Wir haben Kunden weltweit, zum Beispiel in den USA, auch in Asien haben wir eine Installation. In Europa haben wir Installationen. Wir haben Kunden, vor allem aus dem Automotive Bereich. Dazu gehört zum Beispiel die Hirschvogel Group in Europa, die auch mehrere Standorte weltweit hat. Aber wir haben auch Kunden aus anderen Industrien, wie zum Beispiel den angesprochenen Sto, aus der Baubranche. Wir haben mit Karl Storz zum Beispiel ein Unternehmen aus der Medizintechnik oder auch Kunden aus dem Maschinenbau. Also relativ breit gefächert mit Fokus auf Automobil. Also eigentlich hat jeder das Problem. Deswegen sind wir da eigentlich auch relativ breit vertreten. Aber wie gesagt, mit Fokus auf Automotive.
Wie ist das eigentlich mit dem Unified Namespace, den ihr zur Verfügung stellt, ist das ein anderer als ein Unified Namespace von eurer Konkurrenz zum Beispiel? Gibt es da wieder Unterschiede oder sind die kompatibel?
Also am Ende ist der Unified Namespace im Prinzip erstmal nur ein Architekturkonzept, das aus den USA kommt. Da gibt es einen Walker Reynolds, einen Influencer aus den USA, der diesen Term ins Leben gerufen hat, Unified Namespace. Tatsächlich ist es jetzt kein neues Architekturkonzept. Also das gibt es schon lange, aber Walker Reynolds hat eben diesen Term ins Leben gerufen, was es eigentlich ganz geil macht, das eben auch Leuten zu beschreiben. Das heißt also, dieses Unified Namespace ist erstmal ein Konzept. Das ist kein Produkt, sondern ein Architekturkonzept, das sich aus einem Broker-basierten Ansatz zusammensetzt, um am Ende Datenströme zu verteilen. Aber es gibt auch andere Anbieter, die dieses Konzept unterstützen, ähnlich wie iFlow. Da setzen wir uns vor allem mit einem Punkt ab, und das ist Simplicity.
Also das heißt, wenn wir unsere Kunden fragen, warum habt ihr euch für iFlow entschieden, dann ist das immer die erste Antwort, weil wir einfach den Benutzer ins Zentrum von unserer Entwicklung stellen um am Ende eine geile User Experience zu haben und um es den Usern so einfach wie möglich zu machen, an diese Daten zu kommen. Weil das ist genau der Punkt, wo wir früher gescheitert sind, mit ganz, ganz viel Oldschool.
Und diese Software Tools findet man heute noch überall, vor allem im OT Fabrikbereich, wo man so denkt, das sind so DOS-Style Anwendungen, wo man schon keinen Bock hat, die zu nutzen.
Ich war ja mittlerweile auch in einigen Produktionsstätten unterwegs und die Realität sieht wirklich so aus, wie du es gerade beschrieben hast. Euer Ansatz mit iFlow ist in vielen Unternehmen noch wünschenswert!
Ja, total. Und vor allem, wenn man sich auch anschaut, was für Tools da noch genutzt werden, also Tools im Sinne von Software, dann ist es teilweise wirklich erschreckend, weil die einfach nicht mehr state of the art sind. Das ist nichts mehr. Und unsere Mission ist ja, Komplexität aus dem System zu nehmen. Also aus Komplexität, Einfachheit zu machen, indem wir die Architektur vereinfachen. Aber das geht nicht mit einem komplexen Produkt.
Das grenzt uns auch stark von anderen Anbietern ab, die ein komplexes Produkt bauen, um Dinge zu vereinfachen. Das kreiert aber, und das ist auch meine Erfahrung, jetzt zum Beispiel bei Bosch, das kreiert immer Bottlenecks. Also wenn ich ein komplexes Produkt habe, das nur ganz wenige Experten nutzen können, dann habe ich immer Bottlenecks.
Wenn ich bottlenecks habe, dann wird es immer langsamer vorangehen, als ich eigentlich will. Und die Digitalisierung ist aber was, was eigentlich jeder machen muss. Also was jeder im Unternehmen vorantreiben muss. Und dafür brauche ich eben auch die richtigen Tools. Dafür muss ich eben auch die Leute enablen, da mitzuarbeiten. Das geht nur mit einfachen Tools.
Ja, verstehe ich und das macht auch absolut Sinn, wie du das beschreibst. Aber vielleicht die Frage nochmal anders gestellt: wenn jetzt ein anderer Anbieter, der nicht iFlow heißt, auch das gleiche Konzept implementiert in einem Unternehmen, Unified Namespace, sind die beiden Systeme dann kompatibel, oder erzeugt ihr durch euren Lösungsansatz in Wahrheit wieder eine zusätzliche Komplexität?
Du meinst, ob iFlow mit einem anderen Anbieter interagieren kann. Das geht tatsächlich problemlos, weil ein Kernmerkmal von Unified Namespace ist Open Architecture. Das heißt, das ist eine offene Architektur, was eben dazu befähigt, alle Systeme zu integrieren. Ich habe es vorhin beschrieben, wir nutzen zum Beispiel Open Source Technologien wie MQTT. MQTT ist eine sehr gängige Open Source Technologie, wo der Kunde sehr frei ist in der Auswahl der Anbieter und er kann auch von heute auf morgen die Anbieter switchen, weil es eben die Möglichkeit gibt, diese unterschiedlichen Anbieter bzw. Broker Technologien zu bridgen, also zu synchronisieren. Und das ist eben ein großer Vorteil dieser Architektur, dass das eben offen ist und auf Basis von Open Source Technologien aufgebaut ist, sodass der Kunde am Ende kein Login mehr hat vom Anbieter und es eigentlich dem Kunden überlassen ist, den coolsten und geilsten Anbieter auszuwählen. Versus ich muss halt mein SAP nutzen, weil ich nicht weiß, was passiert, wenn mein Business um die Ohren fliegt, wenn ich morgen einen anderen Anbieter nutze als ERP-System.
Das heißt, ihr verdrängt SAP?
Nein, das heißt es nicht. Wir sind am Ende ein Datenverteilsystem. Wir sind am Ende ein Mittel zum Zweck, eine Middleware. Es wird immer Business-Applikationen geben, wie ein ERP-System, das spezifische Focus-Use-Cases entwickelt und abstrahiert für den Endkunden, wie zum Beispiel Auftragsplanung im ERP oder im MES.
Spezifische Kernfunktionen sind nicht Teil dieser Unified Namespace Architektur. Es gibt teilweise Überschneidungen. Das kann sein, das machen dann aber unsere Kunden. Die bauen teilweise über Microservices einzelne Funktionsbausteine, die gegebenenfalls früher in einem MES oder in einem ERP-System gewesen wären, in den Unified Namespace ein. Aber der Unified Namespace wird es nicht komplett ablösen.
Das heißt also, ihr macht kein User Interface. Das, was ihr macht, ist Backend!?
Am Ende gibt es schon ein User Interface bei uns, wo der Kunde zum Beispiel die Maschine anbindet und die Maschine in den Unified Namespace integriert, um die Daten zu integrieren. Aber am Ende sind es reine Datenflüsse, die in diesem System konfiguriert werden.
Ok, verstanden. Ich habe mir übrigens ein paar Videos angeguckt von Walter Reynolds. Ziemlich interessant, der Typ. Er erklärt das Thema wirklich gut!
Der ist super streitbar, das macht er auch wirklich gut.
Es gab bis jetzt immer eine Weiterentwicklung der Technologien und Methoden. Es gab Industrie 2.0, 3.0, 4.0. Es gab die Automatisierungspyramide. Jetzt gibt es die Idee mit Unified Namespace. Es endet ja nicht an dieser Stelle. Was kommt danach? Wie sieht die Welt von iFlow in zehn Jahren aus?
Manche sprechen ja schon von Industrie 5.0. Ich bin tatsächlich kein Freund davon, jetzt darüber nachzudenken, was mit Industrie 5.0 oder 7.0 oder 10.0 passiert. Weil wir haben noch so viele Hausaufgaben zu bewältigen. 80 Prozent der Unternehmen, mit denen wir sprechen, sind noch bei Industrie 3.0. Also wir haben noch nicht mal einen Reifegrad in unseren Unternehmen. Das heißt, wir haben noch nicht mal die erste Stufe von Industrie 4.0 erklommen, also die Transparenz der Prozesse und Daten. Und es gibt noch so viel zu tun, so viele Probleme und es gibt noch so viel Arbeit. Ich fokussiere mich erstmal darauf, gemeinsam mit den Unternehmen Industrie 4.0 zu enablen.
Ja, finde ich sehr gut deinen Ansatz. Dennoch bleibt die Entwicklung nicht stehen und ich bin mir nicht sicher, ob diese Entwicklung die produzierenden Unternehmen nicht ein Stück weit überrollt in Deutschland. Ist das aus deiner Sicht ein Problem in Deutschland? Wir meckern ja gerne darüber, dass die deutschen Unternehmen technologisch nicht hinterher kommen. Ist das wirklich so?
Also hinterher hinken würde ich jetzt nicht sagen. Also wenn ich mir jetzt zum Beispiel Bosch anschaue, wo ich lange Zeit gearbeitet habe. Wie perfekt Bosch es verstanden hat, in Serie und in einer extrem guten Qualität Millionen von Dieselpumpen herzustellen, das hat kein anderer geschafft auf der Welt. Aber gleichzeitig gibt es natürlich große Herausforderung mit der Digitalisierung und Industrie 4.0, wo wir mit Deutschland zwar Frontrunner waren, gerade bei Industrie 4.0, der Term kommt ja aus Deutschland. Das wurde ja auch mit viel Fördergeldern vorangetrieben. Aber wenn ich mir anschaue, wer da weiter ist, dann würde ich auf jeden Fall mal sagen, vom Mindset her sind uns zum Beispiel die USA voraus.
Die testen einfach viel mehr aus. Und das ist eigentlich auch das Wichtige in der Industrie 4.0 oder im Software-Kontext. Dass man einfach mal ausprobiert, Dinge evaluiert und keine Wissenschaft draus macht, wo wir in Deutschland oder auch in Europa eher dazu neigen. Also wir stellen zum Beispiel fest, ganz konkret, dass es Kunden gibt in den USA, die deutlich schneller einfach mal die Software testen. Da gibt es in Deutschland teilweise Unternehmen, die dann sehr viele Runden drehen, um erstmal die Entscheidung zu fällen, ob sie überhaupt mal testen wollen. Und ich glaube, viele Länder sind uns da vom Mindset ein bisschen voraus, was das Thema Schnelligkeit und Agilität angeht.
Daniel, vielen Dank für deinen Input. Das hat mir sehr viel Spaß gemacht.
Cool, danke Stephan. Hat Spaß gemacht, es war mir eine Freude.
Metadaten
Durchführung Interview: 08.01.2025 (remote)
Interviewsprache: deutsch
Interviewer: Stephan Bellmann
Interviewpartner: Daniel Goldeband
Autorisierung: 22.01.2025
Comments