Die Rolle von Low-Code Anwendungen bei der IIoT Integration

Einleitung

Low-Code hier, No-Code dort. Wann immer man sich nach neuer Software umsieht, springt einen das Angebot an Low- oder gar No-Code Tools entgegen. Was oftmals für besonders Code-Affine Nutzer unnötig erscheinen mag, ist ein Trend, der praktisch unumkehrbar erscheint. Sinnvollerweise, wie ich finde, denn es können nicht von heute auf Morgen ein Großteil der Arbeitskräfte zu Entwicklern umgeschult werden. Doch genau das erfordert der rasend schnell voranschreitende Wandel unserer Arbeitswelt rund um Themen wie Analytics und AI. Welche Entwicklung wir für die Industrie erwarten und warum diese nicht schlecht ist, möchte ich in diesem Beitrag beleuchten.

Doch eins nach dem anderen.

Was versteht man unter No-Code Tools? Und was fällt unter die Gattung Low-Code Tools? Bringen wir ein wenig Licht ins dunkle.

Als No-Code Software bezeichnet man Software oder Plattformen, die es dem User erlauben, digitale Produkte zu erstellen und zu deployen. Meistens werden in den Tools Templates für gängige Use-Cases bereitgestellt oder und Prozesse, die in der Vergangenheit viel Entwicklungsarbeit vorausgesetzt haben, über Drag & Drop umsetzbar gemacht.

Das Ziel solcher Lösungen: Auch solche Nutzer, die keinen Programmier-Background haben, dazu zu befähigen, schnell und günstig Ideen umzusetzen und Anwendungen zu realisieren.

Low-Code Anwendungen unterscheiden sich nicht wesentlich von No-Code Anwendung. Nein, oftmals lassen sich auch Low-Code Anwendungen vollständig ohne Code bedienen. Einige Anwendungen bieten ihren Nutzern die Möglichkeit, in einzelne Teilaspekte mit Code einzugreifen, also einzelne Funktionen über Code selbst zu implementieren. Wieder anderen Low-Code Anwendungen erfordern bei jeder Eingabe grundsätzliches Code-Verständnis, wie beispielsweise Node-Red. Damit sind Low-Code Anwendungen wesentlich flexibler als No-Code Anwendungen, erfordern jedoch ein grundsätzliches Verständnis davon, wie Code ausgeführt wird.

Auch in der Industrie halten Low-Code Tools mehr und mehr Einzug. Ich habe es in den letzten Jahren viel im Kontext von End-To-End Anwendungen gesehen, wie Shopfloor-Management Anwendungen, die Shopfloor-Informationen bündeln. Ein Beispiel wäre hier Tulip oder das ActiveCockpit von Bosch Rexroth.

Je mehr aber das Thema (oder vielmehr: Die schier unbegrenzte Zahl an Themen rund um) Data Science an Prominenz gewinnt, desto mehr BI und Analytics Tools werden mit No- oder Low-Code Mantel angeboten. Ich denke hierbei beispielsweise an Tableau oder die SAP Analytics Cloud, die in den letzten Jahren deutlich an Nutzerfreundlichkeit dazugewonnen haben. Der Trend geht klar zu Self-Service Analytics.

Das Problem viele dieser Anwendungen:

Sie setzen ordentlichen Zugriff bzw. das Vorhandensein von sauberen Daten voraus. Wer Data Science Projekte auf Corporate Ebene betreibt, der weiß um die Schwierigkeiten, auf Daten aus einzelnen Werken zuzugreifen oder gar Werkübergreifende Use-Cases auszurollen.

Als letztes „Missing Piece“ für derartige Vorhaben bzw. generell für Self-Service Analytics rücken nun mehr und mehr Low-Code Tools für IIoT Data Integration in den Fokus. Wir von i-flow sind hier einer der bereits etablierteren Anbieter am Markt, aber es gibt immer neue Tools, die das gleiche Ziel verfolgen:

Die letzte Lücke, die so genannten OT-IT Gap, zu schließen.

Warum die OT-IT Integration das Missing Piece ist

Dass die OT-IT Integration so wichtig für die Digitalisierungsanstrengungen heutiger Industrie-Unternehmen ist, ist auf den ersten Blick gar nicht so offensichtlich. Schließlich gibt es immer irgendwie einen Weg, Daten von A nach B zu transportieren und im Zielsystem zu visualisieren. In der Industrie ist das Problem aber weitaus größer. Stichworte: Wartbarkeit, Skalierbarkeit.

Ein kurzer Exkurs: Sicherlich ist Ihnen die Automatisierungspyramide ein Begriff. Ein starres System aus dem letzten Jahrtausend, die eine stark hierarchische Architektur vorsieht. Viele PLCs, weniger viele Shopfloor-Systeme, und noch weniger Corporate-Systeme. Nahezu jede Fabrik ist nach diesem alten Schema aufgebaut.

Während das vor vielen Jahren noch völlig valide war, hat die starre Architektur in einem Zeitalter, in dem auch IT Anwendungen Einzug auf dem Shopfloor halten, ein großes Problem aufgedeckt: Datenflüsse sind heute viel zu dynamisch und das klassische „Point-To-Point-Wiring“, also die starre Vernetzung von Datenpunkt A zu Datenpunkt B, ist nicht mehr sinnvoll managebar. Viel zu hoch sind die Reibungsverluste bei Updates oder gar angedachten Roll-Outs von erfolgreichen Pilotprojekten.

Oder ist Ihnen bereits ein erfolgreiches Pilotprojekt unter Einbezug von Shopfloor-Daten begegnet, dass problemlos innerhalb eines Werkes oder gar werksübergreifend ausgerollt werden konnte? Mir zumindest nicht.

Und genau deswegen ist eine erfolgreiche IIoT Integration, oder eben OT-IT Integration, so wichtig. Die Skalierbarkeit von Data Analytics Projekten steht und fällt mit dem Fundament. Und dieses Fundament kann heute auch mit Low-Code Anwendungen abgebildet werden.

Die Herausforderungen bei der IIoT Integration in Fabriken

Was also ist es, dass die OT-IT Integration so komplex macht? Das hat viele Gründe, auf die ich gerne eingehe. Den Hintergrund mit der Automatisierungspyramide hatte ich schon geschildert. Im folgenden Abschnitt möchte ich aber nochmal auf die tieferliegenden Ursachen eingehen, die da wären:

1. Heterogenität von Shopfloor Daten
2. Stakeholder Problematik
3. Integration von Legacy Systemen
4. Application-Centric Architectures

Aber der Reihe nach.

Heterogenität der Shopfloor Daten

Die Systemlandschaft in deutschen Fabriken ist in etwa so heterogen wie das Klassenzimmer einer internationalen Schule. Maschinen und Anlagen unterschiedlichster Hersteller aus unterschiedlichen Zeiten und Generationen prägen das Bild.

Für die Produktion als solche vermag das an sich nicht kritisch sein, für datengetriebene Use-Cases ist es das aber schon. Unterschiedliche Hersteller bedeuten im Falle des kleinsten Übels unterschiedliche strukturierte Daten, im schlimmsten Falle jedoch proprietäre Protokolle und kryptische Datenpunkte.

Und die Konsequenz ist Ihnen sicher bekannt:

Erwartet das Condition Monitoring Dashboard eine Drehzahl, dann tut es das in einer bestimmten Form, beispielsweise in 1000/min. Ebenso erwartet es, dass die Drehzahlvariable eindeutig gekennzeichnet ist. Jeder, der einmal mehrere Maschinen angebunden hat, weiß, dass es vergebene Liebesmüh ist, homogene Daten vorauszusetzen. Maschinenindividuell müssen die Werte also angebunden, transformiert und weitergegeben werden – immer wieder aufs Neue. Nicht selten sehe ich hierbei Python-Skripte, die auf einem Edge-Server fortlaufend wie fleißige Arbeiter ihren Dienst verrichten – außer, es tritt ein unvorhergesehener Error auf. Dass dieser meist erst dann auffällt, wenn in der Morgenrunde der Fertigungsleitung keine Daten mehr auswertbar sind, ist ein ganz eigenes Thema.

Stakeholder Problematik

Historisch bedingt ist die Arbeiten mit Daten, Schnittstellen und Datenbanken Teil der Aufgaben der IT. Die Arbeit mit Maschinen und Prozessen ist wiederum Teil der OT. Ich denke ich übertreibe nicht, wenn ich sage, dass die Kluft zwischen den Personas dieser beiden Gruppen oft sogar über Zoom-Meetings spürbar ist. Und ich denke ich weiß auch, woran das liegt.

Es ist seit jeher Aufgabe der IT, für einen reibungslosen und sicheren Betrieb von IT-Systemen zu sorgen. Das reicht von der Wartung von Servern bis hin zum Verteilen von Windows Updates. Aus gutem Grund legen die Kollegen aus der IT also einen gewissen Protektionismus an den Tag – ihr Ziel ist schlichtweg nicht, die Produktivität in der Produktion zu steigern, sondern sicherzustellen, dass alles so funktioniert, wie es soll.

Dieses Ziel haben Kollegen aus der OT zwar auch, jedoch ist es im Speziellen Aufgaben von Industrie 4.0 Ingenieuren und Data Scientists, durch digitale Hilfsmittel die Produktivität zu steigern.

Nun der Zielkonflikt:

Während es also oftmals historisch bedingt Aufgabe der IT ist, die Infrastruktur für I4.0 Anwendungen bereitzustellen, ist die Einführung neuer Systeme entgegen den Interessen der IT. Das gilt insbesondere dann, wenn die neuen Systeme nur mehr Arbeit für sie bedeuten und aus ihrer Perspektive vermeintliche Redundanzen aufgebaut werden.

Gleichzeitig kann es aber auch nicht Ziel der IT-Kollegen sein, dass dezentrale OT-Kollegen auf eigene Faust IT-Infrastrukturen aufbauen oder gar ungeregelt auf Datensysteme zugreifen.

Ein vermeintliches Dilemma also.

Integration von Legacy Systemen

Ich hatte es schon unter Punkt 1 angesprochen: Unterschiedliche Systeme machen die OT-IT Integration komplex. Proprietäre Systeme stehen dabei am Ende der Fahnenstange.

Viele Brown-Field Maschinen geben entweder noch gar keine Daten aus, weil sie zu alt sind, oder aber tun dies über herstellerspezifische Schnittstellen. In vielen Fällen liegen die Daten vielleicht sogar vor, sind aber durch den Hersteller nicht freigegeben.

Das sind diese Momente, in denen es echte Steuerungsentwickler braucht – oder ein gut gefülltes Budget zum Nachrüsten der Maschine durch den Hersteller oder durch Dienstleister. Denn, so ungern ich das feststellen muss: Für dieses Problem gibt es keine skalierbare Lösung und es bleibt eine Einzelfallentscheidung, ob es für die Nachrüstung einen Business Case gibt.

Application Centric Architectures

Jetzt betreten wir Terrain, dass es durch seine Tragweite durchaus in sich hat: Application Centric Architectures.

So wie die Automatisierungspyramide über Jahrzehnte so aufgebaut wurde, dass es starre Verkettungen von Informationen gab, so hat sich auch die Software-Landschaft entwickelt. Über die Jahre haben immer mehr Anwendungen Einzug gehalten, die für sich selbst den Anspruch hatten, zentrale Anlaufstelle für Daten zu sein. ERP, MES oder Shopfloor Management System.

Das Problem hierbei ist, dass all diese Anwendungen eigene Datenstrukturen aufbauen und die Daten mit Appliationslogik verarbeiten. In der Praxis gibt es aber eben nicht das eine System, das alle Daten so bereithält, wie unterschiedliche Systeme dies brauchen. In der Folge haben sich Strukturen entwickelt, in denen es unendliche viele Datenverbindungen und Datensilos gibt.

Der ein oder andere wird jetzt die Stirn runzeln und Datalakes einwerfen, die dieses Problem lösen sollen. Und ja, die Idee hinter Datalakes ist nicht schlecht, aber abgesehen davon, dass sie sich nicht für „Data in Motion“ eignen, spielt Problem 1 eine wichtige Rolle. Wenn nämlich sämtliche Shopfloor Assets ihre heterogenen Daten ungefiltert in Datalakes ablegen, weiß am Ende niemand mehr, was er oder sie damit anfangen soll. Es ist schlicht nicht mehr möglich, die Daten mit Sinn zu versehen. Und wenn, dann nur in abgekapselten Projekten.

Es fehlt also die Single Source of Truth und das zentrale System, das für die Datendistribution in andere Anwendungen hinein verantwortlich ist.

Low-Code Software für die Vereinfachung von IIoT Integrationen

Nun, Probleme ohne Lösungen wären unlösbar Probleme. Und da wir es auf dem Shopfloor nicht gerade mit dem P-NP-Problem zu tun haben, besteht Hoffnung für die Menschheit. Um das Thema dieses Papers nicht zu verfehlen, werde ich mich im Folgenden auf Lösungen beschränkten, die Low-Code Tools zur Verfügung stellen, wie ich es bereits angeteasert habe.

Lösung für das Heterogenitätsproblem

Wie wir wissen, finden wir die Heterogenität auf vielen Leveln – von den Schnittstellen bis hin zur Namenskonvention. Leider hilft es nicht, einfache Protokollübersetzer einzusetzen und alle sind glücklich. Eine der wenigen echten Lösungen, die nachhaltige Skalierbarkeit erlaubt, ist die Harmonisierung von Fabrikdaten. Und wie wir sehen, ist das Protokoll hierbei völlig egal und muss nicht einmal angeglichen werden.

Was meine ich damit: Nun, sprechen wir zunächst darüber, was ich generell mit Harmonisierung der Daten meine, bevor ich erkläre, warum das Ausgabeprotokoll gar keine Rolle spielt.

Das einfachste Beispiel: Nach Anbindung zweier artgleichen Maschinen unterschiedlicher Hersteller an das Low-Code zur IIoT Integration harmonisieren Sie alle notwendigen Daten. Wenn das beispielsweise die Drehzahl ist, legen Sie vorab fest (z.B. in einem Datenmodell), welches Format Ihre Drehzahl in Ihrem Unternehmen haben soll.

Beispiel: Drehzahlen für Drehmaschinen sollen ganze Zahlen sein in der Einheit 1000/min.

Das Low-Code Tool ist dann für die Transformation eingehender Daten zuständig, also für das Angleichen von eingehenden Drehzahlen an das Datenmodell.

Aus 10/s wird dann 600/min, und aus [1,0000] wird 60/min.

Die Daten werden also auf Basis eines Datenmodells harmonisiert. In der Regel macht es hierbei Sinn, das Datenmodell auf Basis des Use-Cases zu definieren, der skaliert werden soll. Wenn Sie also an jeder Maschine das gleiche Condition Monitoring Dashboard nutzen möchten, erstellen Sie ein Datenmodell für genau dieses Dashboard. Im nächsten Schritt findet nun die Harmonisierung eingehender Daten statt.

Und jetzt der Part, warum das Ausgabeformat dann egal ist: Heterogenität finden Sie nicht nur bei Datenquellen, sondern auch bei den Datensenken. Diese Heterogenität ist aber unmöglich auflösbar, weswegen Sie die Daten in unterschiedlichen Protokollen bereitstellen können müssen. Das heißt, Sie akzeptieren unterschiedliche Zielprotokolle, nachdem Sie einmal eingehende Daten harmonisiert haben. Ihre Single Source of Truth ist dann nämlich nicht mehr die Zielapplikation, sondern die Data Management Lösung, die davor geschaltet wurde. Aufmerksamen Lesern erkennen bereits den Zusammenhang zum Problem der Application Centric Architecture.

Lösung für die Stakeholder Problematik

Wenn es darum geht, Mitarbeiter aus der IT von Low-Code Systemen, mit denen Nicht-ITler Daten nutzen sollen, stößt man erfahrungsgemäß oft auf Widerstand – wie beschrieben. Und in der Tat braucht es mehr als bloß die Einführung eines neuen Tools: Ein Umdenken ist von Nöten. Mit den richtigen Argumenten gelingt aber auch das.

Wichtig ist doch, dass alle Parteien bestmöglich ihre Ziele erreichen können. Mit richtig eingesetzten Tools ist das problemlos möglich. Mehr noch: Wenn in der OT-IT Integration Low-Code Tools eingesetzt werden, die es den Kollegen aus IT erlauben, Systeme zu administrieren, die vorher abseits ihres Zugriffs lagen, wird gesamtunternehmerisch großes bewirkt.

Doch was heißt das konkret: Nun ja, im Status Quo ist die IT für IT-Systeme verantwortlich. Oftmals dümpeln OT-Systeme das Dasein als Insellösungen. In dem Moment, in dem eine von der IT gemanagte Verbindung zwischen OT und IT geschaltet wird, kann sichergestellt werden, dass

1. Nur der Zugriff auf OT-Systeme hat, der sie haben soll
2. Standards auch standortübergreifend eingehalten werden
3. Mehr Anfragen im Self-Service erledigt werden können
4. Weniger Redundanzen in der Datenlandschaften vorkommen

Gleichzeitig sind auch auf OT bzw. Data Science Seite die Vorteile klar. Es ist plötzlich möglich, dass

1. Deutlich schneller auf Datenpunkte zugegriffen werden kann
2. Data Science Projekte und Erfolge auf andere Systeme übertragen werden können
3. Nicht wegen jeder Kleinigkeit die IT behelligt werden muss, sondern Lösungen auch explorativ erzielt werden können
4. Die Standardisierung von Use-Cases unternehmensweit massiv beschleunigt werden kann

Für mich ein Gewinn auf beiden Seiten. So lange sichergestellt ist, dass der IT die Steuermöglichkeiten gewährt werden, die eine Landschaft ohne Wild-West Mentalität ermöglichen, ist jedem geholfen.

Lösung für Application Centric Architectures

Der aus meiner Sicht größte Game-Changer ist der Weg weg von einer Application Centric Architecture hin zu einer Data Centric Architecture. In dem Moment, in dem man die Daten bzw. eine Datendrehscheibe in die Mitte meiner Digitalisierungsbemühungen steckt, nimmt die Gesamtarchitektur massiv an Komplexität ab.

Stellen Sie sich alleine die ganzen individuellen Skripte vor, die Systeme miteinander verbinden. Alle fallen weg. Ebenso müssen Sie Ihr Zielsystem nur noch einmalig an die Data Management Lösung anschließen – sofern sich Änderungen im Quellsystem ergeben, kann der Data Scientist bzw. Industrie 4.0 Ingenieur eigenständig die Anpassung im Data Routing vornehmen.

Bestmöglich umsetzen lässt sich die Data Centric Architecture im Übrigen mit einem so genannten Unified Namespace auf Basis von MQTT oder Apache Kafka. In dem System wird zentral die Struktur für Datenpakete vom Shopfloor definiert und die Daten vom Shopfloor zyklisch in der definierten Form an einen MQTT-Broker oder eben Kafka Broker gestreamt. In Form eines Pub-/Sub-Systems können nun beliebig viele Systeme die Daten konsumieren und verarbeiten.

Effizient, schlank und kostengünstig.

Eine Low-Code Lösung zur IIoT Integration implementieren

Nun ist jede Idee nur nobler Vorsatz, wenn sie nicht in die Tat umgesetzt wird. Wie sollte daher vorgegangen werden, wenn eine Low-Code Lösung zur IIoT Integration implementiert werden soll? Auch das möchte ich kurz beleuchten.

Anforderungsanalyse und Auswahl der Software

Wo kein quantifizierbarer Mehrwert, da kein Business Case. Ich denke uns ist allen klar, dass der erste Schritt immer sein muss, die internen Anforderungen für eine Low-Code Lösung aufzunehmen. Hier einige Fragen, die Sie sich stellen sollten:

1. Welche Schnittstellen bietet das Tool?
2. Wie wird das Tool gewartet – zentral oder dezentral?
3. Wie sehr können Sie Einfluss auf die künftige Entwicklung des Tools nehmen?
4. Welche Support-Leistungen können Sie vom Anbieter erwarten?
5. Sind die geplanten Use-Cases umsetzbar?
6. Welche Protokolle werden unterstützt?
7. Welche Form der Datenvorverarbeitung lässt das Tool zu?
8. Welche Mitarbeiter können das Tool bedienen?
9. Was kostet das Tool?

Ich möchte ehrlich sein: Die perfekte Software, die alle Anforderungen zu größtmöglicher Zufriedenheit erfüllt, gibt es nicht. Ihr Ziel sollte daher sein, den Grad der Anforderungserfüllung zu maximieren.

Relevante Stakeholder im Planungs- und Implementierungsprozess einbeziehen

Ich kenne es selbst aus meiner Zeit, in der ich selbst I4.0 Lösungen in einer Business Unit einführen musste: den maximal nachhaltigen Erfolg erzielt man, wenn alle Stakeholder abgeholt werden. Nun ist es stark von der Unternehmensstruktur abhängig, wie man hier idealerweise vorgeht.

Um nur ein Beispiel zu nennen: Wird eine Software an nur einem Standort eingeführt, hat man es mit anderen Anforderungen und Stakeholdern zu tun, als wenn es sich um ein Zentralprojekt handelt.

Dennoch kann bin ich überzeugt, dass die Grundidee in beiden Fällen gleich sein muss. Es gilt als erstes, die involvierten Menschen zu überzeugen und einzubeziehen.

Mein Vorgehen: Im ersten Schritt immer auf die Erfahrung der unterschiedlichen Kollegen zurückgreifen, und diese Erfahrungen wertschätzend annehmen. Wenn Sie zu einem späteren Zeitpunkt auf genannte Punkte erneut eingehen, fühlt sich jeder ernst genommen.

Data Governance Richtlinien einplanen und implementieren

Data Governance – sicherlich vielen ein Begriff, umfasst so ziemlich alles, was es über das kontrollierte Arbeiten mit Daten zu beschreiben gilt. Zu umfassend für dieses Paper, weswegen ich mich hier auf das Grobkonzept von Data Governance für Daten im Dunstkreis Industrie 4.0 beschränken möchte.

Die Einführung von Standards ist so lange von Vorteil, bis es zu viel Standards gibt. Ein einleuchtender Satz, den ich aufgeschnappt hatte, als es ich bei einer Branchenkonferenz einen Vortrag darüber hörte, warum Maschinenbauer auf verbreitete Protokolle bei der Maschinenanbindung setzen sollten. Für mich ist der Satz auch auf interne Projekte anwendbar.

Standards helfen ungemein, gesamtunternehmerisch schneller voranzukommen – im Kleinen wie im Großen. Wenn einmal definiert ist, wie die Daten für ein Condition Monitoring Dashboard auszusehen haben, sollte das unternehmensweit gelten. Das mag tollkühn klingen, aber ist der einzige Weg zu skalierbaren Lösungen.

Das heißt nicht, dass man die Individualität von einzelnen Standorten außer Acht lassen muss. Individualität wird es immer geben und ist auch sinnvoll. Wann immer es sinnvoll möglich ist, Individualität zu vermeiden, sollte ebendas getan werden.

Eine effektive Data Governance Richtlinie aufzustellen, kostet viele Körner. Einmal gemacht, kommen die Vorteile schnell zum Vorschein. Dabei sollte stets von oben nach unten standardisiert werden.

Doch was hat das alles zu tun mit Low Code Lösungen?

Nun ja, Low Code Lösungen reduzieren die Komplexität von Software ungemein, was auch bedeutet, dass die Software für wesentlich mehr Menschen zugänglich gemacht wird. Während der Schritt als solcher zu begrüßen ist, muss gleichzeitig stärker denn je darauf geachtet werden, dass keine Wild West Mentalität entsteht. Denn:

Man schaufelt sich damit immer tiefer in die Misere. „Never change a running system” ist schließlich eine hochangepriesene Lebenseinstellung in der Produktion, deswegen sollte man das „Running System“ mit Bedacht und Weitsicht entwerfen. Und genau hierbei helfen Rahmenbedingungen, die von Experten der IT gesetzt werden.

Unterschiedlichen User-Gruppen den Einstieg erleichtern: Nutzer-Trainings

Wissen Sie, was der häufigste Grund für das Scheitern von Softwareeinführungen in Unternehmen ist?

Trommelwirbel – es ist ein schlechtes Onboarding.

Ich gebe ja zu, ich gehöre auch eher zur Gattung Anwender, die Tutorials überspringen, wild drauf los klicken und sich selbst den Weg durch Anwendungen bahnen. Nur leider führt dieses Vorgehen oftmals dazu, dass die Anwendung entweder nicht korrekt verstanden wird (immer schlecht, insbesondere für Low-Code Anwendungen) oder aber unvorteilhaft genutzt wird.

Deswegen: Wann immer eine neue Anwendung flächendeckend eingesetzt werden und insbesondere von Nicht-ITler genutzt werden soll, gehört ein klarer Onboarding-Plan und genügend Material mit dazu.

Fazit

Low-Code Lösungen in der IIoT Integration sind der logische nächste Schritt in der Evolution von digitalen Produktionssystemen. Sie vereinfachen und standardisieren der Integrationsprozesse erlauben nicht nur die Skalierbarkeit von IIoT Anwendungen, sie erlauben es auch, dass Data Governance Richtlinien es auf den Shopfloor schaffen.

In Zeiten, in denen es mehr und mehr Self-Service Lösungen gibt, ist es die Datenintegration, die das Self-Service auf ganzer Linie erlaubt. Ich bin überzeugt, dass es hierfür aber das passende Tool braucht, um Projekte und Skalierungsphasen in geordneten Bahnen ablaufen zu lassen.

Über i-flow

Mit i-flow setzen wir genau dort an. Skalierbares Data-Management auf der Edge mit zahlreichen Features, die ausschließlich für die Skalierbarkeit von Industrie 4.0 Anwendungen entwickelt wurden. Ich würde mich freuen, ins Gespräch zu kommen und nochmal genauer aufzuzeigen, wie wir Ihre Data Analytics Projekte deutlich beschleunigen, den Return of Invest schneller herbeiführen und wir bei erfolgreicheren Projekten helfen.

In diesem Sinne – ihr Christoph Sauerborn