KI, Predictive Maintenance, Data Analytics und Co. – viele Innovationen wurden in den vergangenen 15 Jahren unter dem Überbegriff „Industrie 4.0“ vorgestellt.
Gleich zu Beginn hierzu eine Frage meinerseits:
Wie viele der genannten Technologien setzen Sie bereits heute produktiv über Ihre Fertigung hinweg ein?
Wenn es auch nur eine ist, darf ich Sie beglückwünschen. Beglückwünschen dazu, dass Sie dem Gros der weltweiten Industrielandschaften voraus sind.
Und wenn es keine ist, darf ich Ihnen versichern:
Sie sind damit nicht alleine.
Dieser Beitrag soll Aufschluss darüber geben, was die Hauptursachen für das schwierige Ausrollen von Industrie 4.0 Use-Cases ist und wie Sie dem entgegen wirken können.
Ursache 1: Zugänglichkeit zwischen OT und IT erschwert das Ausrollen
Ich kenne aus meiner Vergangenheit als Ingenieur für Industrie 4.0:
Das Pilotieren für einen Beispiel Use-Case funktioniert halbwegs gut, nun soll im zweiten Schritt ein weiterer Use-Case folgen.
Doch was folgt, ist oft ernüchternd:
Um z.B. auf die notwendigen ERP Daten zuzugreifen, muss wieder der gleiche Genehmigungsweg durchlaufen werden. Der IT-Verantwortliche schüttelt bei Ihrer Frage schon energisch mit dem Kopf, usw. – die Angst, die Hoheit aus der Hand zu geben, scheint real.
Natürlich ist das überspitzt ausgedrückt, aber ich war eine zeit lang sicherlich das Feindbild im IT-Büro.
Und der Einwand ist durchaus berechtigt:
IT-Systeme einfach „aufmachen“ ist nicht die Lösung und stellt ein Sicherheitsrisiko dar. Das andere Extrem aber auch nicht, denn:
Restriktives Berechtigungsmanagement macht Industrie 4.0 Projekte oftmals zunichte, sind doch die Daten genau der Ausgangspunkt eines jeden I4.0-Projekts.
Lösung 1: Spiegel der Realdaten
Die IT will Ihnen keinen Zugang zu Live-Daten geben, dann müssen Sie damit leben. Was helfen kann: Täglich gespiegelte Live-Daten, mit denen Sie nichts „kaputtmachen“ können.
Klare Nachteile: Sie haben nie Real-Time Daten und Sie erschaffen Redundanz. Mit erstem lässt sich meiner Erfahrung nach in vielen Use-Cases noch leben, zweiteres ist kritischer. Schließlich geht die Skalierbarkeit und Einheitlichkeit der Daten verloren, wenn in einem Datensilo gearbeitet wird.
Dennoch: Möglicher Plan B.
Lösung 2: Zentraler Zugang mit Use-Case spezifischen Daten
Eine Alternative bieten Tools, die Daten zentral organisieren und mit entsprechendem Berechtigungsmanagement versehen sind.
Zentrale, von der IT gemanagte Datenspeicher und Zugangspunkte ermöglichen auf einfache Art und Weise das managen von Zugriffen und das auch Use-Case spezifisch.
Die Idee: Statt dezentral Zugänge für die verschiedenen Systeme zu verwalten, bilden Datenmanagement-Lösungen eine Schicht dazwischen und fungieren als zentrale Austauschstelle für die Daten
Problem 2: Keine einheitlichen Schnittstellen von Industrie 4.0 Technologien
Die meisten Macbook Besitzer besitzen auch ein iPhone.
Ein Grund sicherlich: Das gute Zusammenspiel der beiden Geräte aus dem Hause Apple.
Auf dem Shopfloor ist die Situation eine ähnliche: Solang Anlangen, Sensoren und Maschinen vom gleichen Hersteller sind, ist das Zusammenspiel deutlich leichter.
Aber: Selbst hier gibt es teils große Unterschiede, wenn die Produktfamilie verlassen wird.
Und in der Realität ist die Systemlandschaft sogar noch heterogener: Nicht selten sind die Anlagen ähnlicher Use-Cases von unterschiedlichen Herstellern und liefern entsprechend nicht die gleichen Schnittstellen.
Ich weiß nicht, ob Sie mit dem Problem vertraut sind, aber wenn die eine Maschine mit OPC UA kommuniziert, die andere mit MQTT, hat man praktisch zwei mal den gleichen Integrationsaufwand.
Die unterschiedlichen Maschinen mit unterschiedlichen Protokollen nun für den eigentlich gleichen Industrie 4.0 Use-Case einzusetzen, fühlt sich im Prinzip wie ein neuer Pilot an, mit den gleichen Phasen.
Lösung 1: IoT Gateways mit Protokoll Übersetzung
Es gibt mittlerweile einige IoT Gateways, die die Übersetzung zwischen mehreren Protokollen beherrschen. Ich bin sogar der Meinung, dass die Gateways selbst dann Sinn ergeben können, wenn Ihre Anlage per se schon IoT fähig ist.
Der Grund: Ohne Protokollübersetzung müssen Sie die Integration wie gesagt jedes Mal aufs neue Durchführen und die Daten in das gewünschte Format überführen.
Lösung 2: Datenbereitstellung per Model vereinheitlichen
Einen etwas anderen Ansatz fahren wir bei i-flow, und ich bin der Meinung – wenig überraschend – dass dieser etwas eleganter ist.
Anstelle einer Protokollübersetzung auf Shopfloor Ebene denken wir in Datenmodellen. Ein Sensor beispielsweise sollte immer eine Temperatur und vielleicht einen Status ausgeben, unabhängig davon, von welchem Hersteller er ist. Hierfür werden mit i-flow Datenmodelle erstellt, die ebendies definieren:
Ein Temperatursensor hat eine Temperatur in °C und einen Status.
Wenn einmal die Verbindung zwischen Sensordaten und Datenmodell hergestellt ist, also klar ist, welcher Wert der Datenverbindung der °C-Wert und welcher der Status-Wert ist, können Sie auf die so vereinheitlichen Daten mit i-flow zugreifen.
Problem 3: Industrie 4.0 bedarf tiefgehender IT-Kenntnisse
Haben Sie schon einmal eine Formatstransformation von Datumswerten in SQL durchgeführt haben und Datapiplines protokollübergreifen in Ihrer Fertigung aufgebaut?
Nein?
Nun ja, dass Sie sich mit diesem Beitrag auseinandersetzen, derartige Schritte aber noch nicht durchgeführt haben, zeigt doch:
Heutige Lösungen sind deutlich zu komplex, um einen skalierbaren Einsatz von Industrie 4.0 Technologien zu ermöglichen.
Natürlich kann die Hilfe von IT-Experten oder externen Integratoren in Anspruch genommen werden, das kostet aber entweder viel Zeit oder Geld (dazu später mehr).
Ich zumindest kam mir damals oft hilflos vor, wenn ich SQL Tabellen anzapfen musste und mit API-Endpunkten der I4.0-Zulieferer bombardiert wurde.
Ich bin aber ganz klar der Meinung:
Industrie 4.0 Projekte auf dem Shopfloor müssen in den Händen der Prozessexperten liegen und entsprechend müssen diese umzusetzen sein – auch ohne tiefgehende IT Kenntnisse.
Lösung 1: Low-Code und No-Code Plattformen
Immer mehr innovative Software-Unternehmen haben den Need erkannt und bringen Low-Code oder No-Code Plattformen auf den Markt, ebenso wir bei i-flow.
Die Idee: Eine intuitive Oberfläche, die von jedem bedient werden kann, und die aufwendige Programmierarbeit abnimmt, am Ende aber wie ein Programm oder ein Skript funktioniert.
In unserem Fall machen wir die Bereitstellung der Daten so einfach wie noch nie, sodass eben die Prozessexperten mit den Daten arbeiten können.
Problem 4: Heterogene Datenlandschaft in Fabriken
Alle Temperatursensoren liefern auch die gleichen Werte.
Denkste.
Selbst bei einem einfachen Fall wie Temperatursensoren ist es die Regel, dass diese nicht die gleichen Daten senden, vom Protokoll ganz abgesehen.
Woher das kommt, ist klar: Temperatursensoren werden Use-Case spezifisch angeschafft und somit auch use-case spezifisch angebunden.
Das Problem dabei ist jedoch, dass die Temperatursensoren dann auch nur für den einen Use-Case verwendet werden können, zumindest, wenn man nicht großen Aufwand betreiben will.
Der Kern des Problems: Durch die immer weiter wachsende Digitalisierung von Fabriken hält auch eine immer weiter wachsende Heterogenität der Fabrikdaten Einzug. Und hier im Beispiel wurden nur Temperatursensoren angesprochen – von Datenunterschieden auf Maschinenebene will ich gar nicht anfangen.
Heterogenität bedeutet immer auch Normalisierungsaufwand. Spätestens wenn ein IT-Tool auf mehrere Use-Cases ausgerollt werden soll, ist Voraussetzung, dass die Daten jedes Use-Cases gleich aussehen. Ein Plan, der bei der heutigen Datenvielfalt zum Scheitern verurteilt ist und mitunter Grund dafür ist, dass Industrie 4.0 nicht skaliert.
Lösung 1: Datennormalisierung per intelligentem Python Skripting
Python hat sich im Bereich Data Analytics als eine vielgenutzte Programmiersprache etabliert. Wann immer mit großen Datenmengen gearbeitet werden muss, hilft die einfache Struktur der Sprache.
Auch Datennormalisierung lässt sich, wenn richtig durchgeführt, mit Python Skripten abbilden. Der Nachteil (folgt in den nächsten Punkten): Die Skripte müssen am Laufen gehalten werden und setzen IT-Skills und Programmierkenntnisse voraus.
Lösung 2: Mit Datenmodellen Fabrikdaten standardisieren.
Eine weitere Möglichkeit ist die Standardisierung von Fabrikdaten per Data Modelling. Bei Data Modelling werden für jeden Anlagentyp – Maschinen, Sensoren, Produkte, etc. – mittels Datenmodelle definiert, wie die Daten dieser Anlagetypen auszusehen haben.
Bedeutet: Das Datenmodell eines Temperatursensors beispielsweise beinhaltet einen Eintrag für die Temperatur – weil ich von dem Sensor hier einen Wert erwarte. Es können natürlich beliebig viele Standardwerte definiert werden. Das hängt ganz von den Sensoren ab.
Das wichtige: Wann immer ich einen neuen Temperatursensor habe, verbinde ich die Daten, die der Sensor liefert, mit dem Modell, sodass die Struktur der Daten am Ende des Tages der des Modells entspricht.
Der Vorteil: Es ist völlig egal, wie die Daten, die der Sensor ausspuckt, aufgebaut sind. Durch die Verknüpfung mit dem Modell sind die Daten für jeden Sensor auf die gleiche Weise nutzbar.
Problem 5: Langsame IT-Strukturen
Ich weiß nicht, wie groß das Unternehmen ist, für das Sie arbeiten, aber ich bin mir sicher, wir sind uns einig: Die IT Abteilung hat immer haufenweise Arbeit.
Für meine Digitalisierungsprojekte bedeutete das immer: wann immer ich von der IT abhängig bin, wird sich das Projekt ziehen.
Nicht etwa, weil die IT langsam arbeitet, nein, sondern weil die Kollegen einfach dermaßen viel zu tun haben.
Solange aber für jedes I4.0 Projekte die Schnittstellen aufs neue angezapft werden müssen und die Data Pipelines auf neue aufgesetzt werden müssen, wird sich nichts am langsamen Tempo von Roll Outs ändern.
Lösung 1: Externe IT-Dienstleister und System Integratoren engagieren
Die von vielen meiner damaligen Kollegen zwar, nun ja, unbeliebten IT-Dienstleister bzw. Integratoren, können das Problem zumindest lindern. Zwar sind auch diese nicht schnell, aber man weiß recht sicher, dass sie eine Lösung auf die Beine stellen, die funktioniert.
Wenn also ein Industrie 4.0 Use-Case umgesetzt und ausgerollt werden soll und man die Arbeit nicht selbst machen möchte, empfiehlt es sich, auf den Integrator zu setzen. Dieser kann eine bestehenden Lösung am ehesten auf einen ähnlichen Use-Case ausrollen.
Der große Nachteil: Nicht das Tempo, aber der Preis sowie die Abhängigkeit. Die Lösungen sind oftmals sehr teuer und werden nicht beutend günstiger bei weiteren Inbetriebnahmen. Außerdem sind die Lösungen oftmals intransparent, weswegen eine gewisse Abhängigkeit besteht. Wann immer man etwas ändern möchte, wann immer etwas nicht funktioniert, muss zum Telefonhörer gegriffen werden.
Lösung 2: Einfach bedienbare Tools für Datenintegration
Dass das Arbeiten mit Daten nicht kompliziert sein muss, hat die Lösung zu Punkt 3 denke ich gezeigt. Deswegen an dieser Stelle: Einfach bedienbare Tools, idealerweise im No-Code oder Low-Code Bereich, helfen dabei, unabhängiger zu werden.
Der Ansatz Self-Service Integration mit dem bestehenden Team ist hier definitiv am zuelführendsten.
Problem 6: Hohe Initialkosten und Black-Box Solutions
Es gibt viele Gründe, warum Industrieunternehmen auf eine flexiblere Produktion umstellen müssen. Als Lösung, das ist dann oft einheitlich, wird auf neuartige Technologien gesetzt, die von dann teuer eingekauft werden.
Aus meiner heutigen Perspektive würde ich sagen, dass das ein Schuss ins eigene Bein ist.
Denn: natürlich gewinnt man durch I4.0 Lösungen wie digitale Arbeitsanweisungen Flexibilität beim Einsatz von Mitarbeitern, aber dies setzt wiederum voraus, dass sich an der Fertigung selbst nichts ändert. Ändert sich etwas am Use-Case, muss der Integrator erneut beschäftigt werden, es entstehen erneut Kosten und schon überlegt man es sich zwei Mal, ob die Änderung wirklich nötig ist.
Gleiches gilt für die Wartbarkeit solcher extern eingekaufter Lösungen. Sie sind schwer zu warten, weil die Wartung natürlich Teil des Geschäfts des Integrators ist. Dieser hat natürlich kein Interesse daran, dass Fehler einfach zu beheben sind und er nicht gebraucht wird (zugegeben etwas überspitzt ausgedrückt).
Lösung 1: IT Mannschaft aufstocken
Damit Sie nicht in die Abhängigkeit von externen Entwicklern geraten, ist es sicherlich empfehlenswert, die eigenen Ressourcen an IT Experten zu stärken. Der Kampf um die begehrten Mitarbeiter ist jedoch hart.
Lösung 2: Transparente Lösungen in Stückchen
Während früher das Credo „Alles aus einer Hand“ sicherlich nicht schlecht war, muss die Fertigung der Zukunft flexibler sein. Eine Anlage ebenso wenig wie eine Software lassen sich in Zukunft 20-30 Jahre nutzen.
Vielmehr müssen die Anwendungen flexibel, erweiterbar, und austauschbar sein. Werden die einzelnen Tools dann zusammengeschalten, ermöglicht es eine Middleware wie i-flow, Fehlerquellen sofort zu identifizieren und selbst die Probleme zu beheben – vorausgesetzt das Ursprungssystem des Fehler lässt dies zu.
Problem 7: Selbstentwickelte Skripte sind nicht stabil
Angelehnt an das vorangegangene Problem: Selbstentwickelte Skripte.
Was habe ich den Windows Task Scheduler verflucht!
Hintergrund: Auch ich habe für einige Aufgaben der Datenvorverarbeitungen Skripte, also kleine Programme, geschrieben. Diese sollten bspw. Daten von A nach B transportieren und ggf. noch vorverarbeiten, damit die Zielanwendung regelmäßig mit korrekt formatierten und vor allem aktuellen Daten gefüttert wird. (Sicherlich werden auch bei Ihnen die ein oder anderen Management KPIs auf diese Weise aggregiert).
Jetzt das Problem: Die Daten, die in dieses Skript hineinflossen, waren ab und an in anderem Format. Und schon schmiss mein kleines Skript einen Fehler, die Kette brach in sich zusammen und es wurden keine Daten mehr verarbeitet.
Es gibt zig weitere Beispiele, in denen so etwas passieren kann und auch tagtäglich passiert. Wenige Skripte lassen sich noch überblicken, bei vielen ist es ein anderes Thema.
Aber noch schlimmer: Als ich das Unternehmen damals verließ, musste plötzlich jemand anderes meine 30+ Skripte verstehen, warten und erweitern. So viel vorab: Das hat nicht funktioniert. Es wurden neue Skripte geschrieben, die das gleiche taten, aber anders funktionierten. So etwas verschwendet natürlich unheimlich viele Ressourcen und ist keinesfalls nachhaltig.
Lösung 1: No-Code und Low-Code Data Pipelines
Ich denke, dass die Intelligenz solcher Skripte in Tools wandern sollte, die so einfach zu bedienen und verständlich sind, dass man nicht Urheber damit geschaffenen Lösung sein muss.
Die Rede ist, mal wieder, von No-Code oder Low-Code Data Pipelines, die Daten vorverarbeiten lassen und ans Ziel transportieren können.
Sie werden es auch diesmal erahnt haben: wir haben da etwas im Köcher: Unsere Data Flow Engine.
Letztlich ist der Weg, einfache Tools einzusetzen und die Intelligenz im Tool zu belassen, zwar oftmals nicht der von Entwicklern präferierte (ich weiß, Sie schreiben gerne Code und ich kann das sogar nachvollziehen!), am Ende des Tages aber der für das Unternehmen nachhaltigere.
So können sich die Entwickler:innen auf komplexere Aufgaben konzentrieren und IT Aufgaben wie eben solche Data Pipelines können auf die Ingenieure ausgelagert werden.
Denn nur wenn mehr Mitarbeiter auch mit Daten arbeiten können, wird die digitale Transformation vollends gelingen.
Fazit
Zugegeben: Dieser Beitrag darf auch als Eigenwerbung verstanden werden. Er kommt aber von jemanden, der genau diese Probleme erfahren hat und der genau dafür an einer Lösung gearbeitet hat. Ich wollte Industrie 4.0 skalierbar einsetzen, konnte es aber nicht. Deswegen gibt es i-flow.
Vielleicht kennen Sie ja das ein oder andere angesprochene Problem. Ich wäre gespannt, mehr darüber zu erfahren. Nutzen Sie gerne die Kommentarfunktion oder schreiben Sie uns eine Nachricht.
Beste Grüße
Christoph Sauerborn