Statt Laptop vor dem Schaltschrank: Device- & Applikationsmanagement in der OT skalieren

Herzlich willkommen beim IoT Use Case Podcast, dem Kanal mit den aktuellsten IoT-Projekten unserer Umsetzungspartner am Markt. Heute wieder von der Hannover Messe. Wir sind hier in einem kleinen Mercedes-Bus, speziell für Podcasts eingerichtet. Mit mir sind Tobias Mühlnikel von Portainer und Jürgen Pfeifer von WAGO. Es freut mich sehr, dass ihr heute mit dabei seid hier auf der Hannover Messe. Beschreibt doch mal ganz kurz: Was sind eure Highlights hier auf der Messe?

Jürgen

Mein Highlight ist tatsächlich dieser Bus, in dem wir gerade gesessen sind. Das ist schon ein interessantes Setting: vier Mikrofone, Kamera. Und man sitzt mitten in einer großen Halle, wo nebenan die Center Stage ist, und unterhält sich über die kommenden Themen. Das finde ich ganz inspirierend.

Sehr schön. Tobias, was war dein Highlight hier?

Tobias

Generell natürlich die vorher festgelegten Termine mit unseren strategischen Partnern. Das ist immer gut, die Menschen dann persönlich noch mal zu sehen. Ansonsten ist es vom Messaging her ganz interessant zu sehen, dass viel mehr darauf geachtet wird, auf Souveränität und Datenhoheit. Da gibt es ein paar recht große Player am Markt, die jetzt sagen: Der Standort der Daten oder der Speicherort ist doch wieder sinnvoll und relevant. Aber ansonsten ist das Wichtigste, die Partner wieder persönlich zu sehen.

Ich fand auch spannend, diese Unterscheidung zwischen dem, was auf der Center Stage diskutiert wurde, zum Beispiel von Roland Busch, auch zusammen mit Friedrich Merz: die Unterscheidung zwischen Industriedaten und öffentlichen personenbezogenen Daten, dass da nicht die gleiche Regularik und so weiter vorgenommen werden darf. Ich glaube, diese Unterscheidung, was in der Industrie besonders relevant ist, kommt ganz klar raus.

Jürgen

Das würde ich unterstreichen. Wir brauchen sicher eine besondere Dynamik, um Machine-Learning-Modelle, KI und so weiter nutzen zu können, und keine Regularien an der Stelle. Aber ich glaube, das ist auch ein guter Weg, denn personenbezogene Daten sind bei den meisten Shopfloor-Anwendungen, an die wir denken, wo wir vielleicht Condition Monitoring oder andere Dinge machen wollen, nicht vorhanden. Von daher fallen wir auch nicht unter die Regularien. Das ist ein guter Weg.

Tobias

Und wenn es doch dazu kommt, dass man Lösungen für Computer Vision sucht und dann vielleicht auch noch mal ein paar Leute mit aufnimmt in der Fabrikhalle, dann gibt es sehr, sehr gute Lösungen, um das zu anonymisieren, auch schon auf der Edge, um nicht in Konflikte zu geraten.

Genau darum soll es ja auch heute gehen: Wie kann man „on the edge“, also lokal auch im Werk, von der IT lernen, zum Beispiel KI-Modelle hosten und Ähnliches, maßgeblich auch containerbasiert? Das ist heute unser Hauptthema. Tobias, vielleicht kannst du da mal ein bisschen erzählen: Wie kommt ihr zu dem Thema containerbasiertes Device-Management, auch Applikationsmanagement in der Industrie? Wie bist du persönlich dazu gekommen, und deine Firma Portainer auch?

Tobias

Software-Container-Management kommt ursprünglich aus der IT und ist da heutzutage nichts mehr Neues. Das ist gängige Praxis. In der OT ist es immer noch recht neu und gerade im Aufschwung.
Portainer hat in der IT mit einem simplen Software-Container-Management gestartet, in klassischen Branchen wie Versicherungen oder Bankwesen. Dann hat man herausgefunden, dass dieser Ansatz, diese Technologie konsumierbar zu gestalten, also für den Endanwender einfach zu handhaben, auch für die OT relevant ist, wo es nicht so viele IT-Experten gibt. Deswegen gab es ein sehr organisches Wachstum in dieser Branche.
So sind wir vor vier, fünf Jahren von der IT Richtung OT gestartet und machen da jetzt auch einen Großteil unseres Umsatzes.

Welche Rolle spielst du da persönlich? Welche Erfahrungen hast du da gemacht?

Tobias

Ich komme ursprünglich als ehemaliger Kunde von Portainer. Ich war bei Volkswagen in der Digitalisierungsplanung und habe Portainer da eingesetzt. Dann habe ich mit dem Team über ein Jahr zusammengearbeitet, herausgefunden, dass es sehr spannend ist, und bin dann von der Kundenseite zum Zulieferer gewechselt.

Das sind natürlich die glaubhaftesten Geschichten. Wenn man selber mal einen Einsatz hatte und sagt: Die Lösung ist so cool, da will ich mitmachen, das ist ein guter Schritt.

Tobias

Genau. Da war ja nicht nur ein Zulieferer am Werk für Digitalisierungsprojekte, sondern mehrere. Dann gab es auch einen regen Austausch mit der Firma WAGO, und so haben wir uns ursprünglich auch kennengelernt, vor ein paar Jahren, also Jürgen und ich.

Jürgen, mal zu dir: Wie lange bist du schon bei WAGO? Was ist deine Rolle, und wie bist du mit Portainer in Kontakt gekommen?

Jürgen

Das sind 25 Jahre. Wenn man das anders formuliert: ein Vierteljahrhundert. Das ist schon krass, wie lange ich bei WAGO bin.
Tatsächlich machen wir so lange ja keine containerisierte Software. Wie Tobias sagte, hat das langsam gestartet und kommt jetzt vielleicht so leicht in den exponentiellen Bereich, dass die Anwendung gewaltig steigt.
Zu der Zeit, als Tobias und ich bei seinem ehemaligen Arbeitgeber Kontakt hatten, konnten wir natürlich auch mit Containern umgehen, aber eher auf „schwarze-Fenster-und-Code-Zeilen“-Ebene. Damals war es mehr was für Experten.
Wir als WAGO kommen aus dem Automatisierungs- und SPS-Umfeld. Dort ist es ingenieurmäßiges Arbeiten, nicht entwicklungsmäßiges Arbeiten. Und da hat uns die grafische Oberfläche von Portainer ziemlich schnell zugesagt. Da haben wir gesagt: Das ist eine Ebene, mit der auch unser typischer Kundenkreis gut umgehen kann.

Tobias

Jürgen präsentiert die Firma WAGO manchmal auch anders. In gemeinsamen Konferenzen, wenn Leute fragen: „Was ist WAGO?“ wird gerne mal ein Gegenstand aus der Jackettasche gezogen.

Jürgen

Heute hast du ihn in der Hosentasche.

Jetzt bin ich gespannt, was du da aus deiner Hosentasche ziehst.

Jürgen

Die WAGO-Klemme muss natürlich immer mit dabei sein, und die mit Feder haben dieses ganz markante Klicken. Ich glaube, die kennt inzwischen jeder, der irgendwo mit Elektrotechnik zu tun hat. Der ist da sicher ähnlich wie ich unterwegs und hat so eine WAGO-Klemme in der Hosentasche.

Sehr gut. Aber da habt ihr euch ja dann auch sehr stark weiterentwickelt. Gerade das Thema Container: Mich würde tatsächlich interessieren, wenn ihr beide das mal definiert. Was ist das, wie funktioniert das für jemanden, der sich damit noch nicht beschäftigt hat, der das nicht kennt? Jürgen, vielleicht fangen wir mal mit dir an, eher aus der OT-Sicht, und dann bin ich gespannt, ob Tobias ergänzt. Wie erklärt ihr das Thema Container einem Laien?

Jürgen

Ich finde das Wort „Container“ schon sehr gut und bin glücklich darüber, dieses Wort, wie auch immer es entstanden ist. Denn man kann es schön an dem Bild eines Schiffscontainers beschreiben.
Wenn wir an so einen riesigen Frachter denken, wo viele Container drauf sind, dann ist die gleiche Analogie herstellbar wie bei einem LKW, wo ein Schiffscontainer drauf ist. Und genauso flexibel. Soll heißen: Es ist eine gekapselte Software, die in sich komplett lauffähig ist, die dann aber eine Basis, sprich einen Host braucht, wie im Bild ein LKW oder ein Schiff, das die Fähigkeit herstellt, dass der Container dort genutzt werden kann. So ganz kurz und abstrakt. Tobias kann das sicher gut ergänzen.

Tobias

Die Schifffahrts- und Containeranalogie ist sehr passend. Sie hat uns manchmal auch in Bedrängnis gebracht: Wenn man nicht präzisiert und sagt, man macht Software-Container-Management, sondern nur „Container-Management“ sagt, dann wird schnell an physische Container gedacht, ob man 40-Fuß-Container managt.
Aber die Analogie passt sehr gut, weil es diese modulare Bauweise auch in der Software ist. In der Schifffahrt muss der Hafenbetreiber nicht wissen, was in einem Container ist. Genauso ist es auch beim Betriebssystem in der IT: Da muss nicht festgestellt werden, was tatsächlich in dem Container läuft, sondern das standardisierte Format ist entscheidend, um das großflächig auszurollen, egal auf welche Hardware.
Das bietet den Kunden Vorteile wie Hardwareunabhängigkeit, aber auch Portabilität. Das heißt, es kann schnell skaliert werden. Wenn man es einmal testet, weiß man, dass es so funktioniert. Der Stand kann eingefroren werden, ist aber gleichzeitig sehr flexibel aktualisierbar oder auch rücksetzbar.

Könnt ihr das mal an einem Beispiel, vielleicht auch einem gemeinsamen Beispiel, wo ihr zusammenarbeitet, ganz plastisch beschreiben?

Jürgen

Wir haben schon seit 20 Jahren ein Linux-Betriebssystem bei WAGO. Dann war es immer eine Herausforderung: Menschen, die sich wirklich mit einem Linux-Betriebssystem auskannten, konnten die Funktionalitäten ergänzend zur Basisfunktionalität, sprich der SPS-Funktion, erweitern. Anderen war das nur nach längerer Einarbeitungszeit möglich, aber nicht „out of the box“.
Mit der Containertechnologie kann man auf Plattformen wie GitHub, Docker Hub oder ähnlichen schauen: Was ist denn da vielleicht vorhanden? Nehmen wir das Beispiel Node-RED, das inzwischen recht beliebt geworden ist für nicht-echtzeitkritische oder nicht deterministische Anwendungen. Da braucht man sich nur noch diesen sogenannten Container zu ziehen.
Das Einzige, worauf man achten muss, ist die Standardisierung, die Tobias angesprochen hat: Welche Hardware habe ich denn vor mir? Ist sie 32-Bit oder 64-Bit-Architektur? Dementsprechend wählt man sich das Image für den Docker-Container aus, deployt es, installiert es auf der Hardware, und es läuft.

Tobias

Ich glaube, da gibt es sehr, sehr viele gemeinsame Projekte. Eins, das wir nennen können, ist beispielsweise auf Bohrschiffen in den Staaten, auch in anderen Weltregionen. Das spiegelt sehr schön wider, wo man das alles finden kann: wo man die Hardware von WAGO finden kann, aber dann auch unsere Software.
Dem Endkunden war sehr wichtig, dass er diese Flexibilität ausspielen kann. Das heißt: Er ist nicht angewiesen auf einen Hardware- oder Softwarehersteller, wenn er Änderungen vornehmen will, sondern kann gucken, was verfügbar ist, was er darauf laufen lassen kann, und zahlt nicht in einem sehr geschlossenen Ökosystem sehr, sehr viel Geld im Nachgang für Change Requests.
Da ging es in dieser Öl- und Gasindustrie um Millionen für kleine Change Requests. Da ist der Kunde sehr froh, dass er dieses geschlossene Ökosystem damit aufgebrochen hat.

Wenn man sich das vorstellt: Wir haben den Container, und dafür brauchen wir sozusagen das Schiff, also die Hardware. Welche Grenzen oder Limitierungen gibt es da? Was sind die Anforderungen an so eine Hardware? Irgendwo wird es wahrscheinlich zu klein werden. Das hängt natürlich vom Anwendungsfall ab. Könnt ihr beschreiben, in welchem Bereich und mit welchen Hardware-Themen man da arbeitet?

Tobias

Es kommt natürlich sehr stark auf den Endanwendungsfall an. Wenn ich ein sehr großes LLM deployen will, ist klar, dass man dafür Arbeitsspeicher braucht. Wenn es eine sehr leichtgewichtige Lösung ist, dann geht es wirklich runter, bis auf ganz kleine Embedded-Geräte.
Den Kunden dürfen wir nennen: In dem Fall Cummins. Da laufen Container auch auf ganz kleinen Bosch-Steuergeräten. Das ist spannend, weil man dann auch auf Embedded-Geräten laufen kann. Dazu gibt es auch eine eigene Podcast-Folge mit euch.
Für uns als Control Plane ist nicht so entscheidend, wie groß die Hardware ist. Wir reden hier von 10 MB Arbeitsspeicher, was meistens da sein sollte.

Jürgen

Das ist die Basis für den initialen Footprint, und dann kommt es auf die Anwendung an, was die wirklich benötigt.

Eine Anwendung: Du hast es gerade angesprochen, Large Language Models, LLMs. Das ist ja gerade das Thema generative KI. Viele verwechseln das noch mit der klassischen KI, wo man ein eigenes Modell trainiert für einen ganz bestimmten Anwendungsfall. Jetzt hat man plötzlich diese Transformer-Modelle, diese Foundation-Modelle, generative KI. Die brauchen ja durchaus Rechenleistung. Habt ihr da schon Beispiele oder Ideen, wie generative KI im Shopfloor eingesetzt wird, vielleicht in einem Container, um das gut zu managen? Welche Anwendungsfälle sind euch präsent?

Jürgen

Ich würde vorausschieben, dass wir viele Anwendungen haben, wo bereits Machine-Learning-Modelle oder Anomalie-Erkennung oder was auch immer, was ja letztendlich auch unter den Oberbegriff KI fällt, laufen. Die laufen auf der ganz normalen CPU der Geräte. In dem Fall sind es sehr häufig Edge-Computer von WAGO.
Das Thema LLM benötigt manchmal etwas mehr Rechenleistung, kann aber auch auf Edge-Computern in einem Schaltschrank laufen. Dann sind es oft Tiny LLMs. Dafür ist in unseren Edge-Computern bei Bedarf zusätzliche Hardware, sogenannte KI-Beschleuniger, verbaut, die es für den Zielmarkt im Verhältnis zum Edge-Computer in einem guten Preis-Leistungs-Verhältnis gibt. Das verdoppelt nicht die Aufwände und den Invest, sondern ist ein prozentualer Anteil davon.

Tobias

Diese spezielle Hardware kann meistens auch in Containern durchgeroutet werden und so konsumiert werden, ohne dass man Best Practices aus der IT verlässt, und es bleibt skalierbar. Das ist spannend für den Endanwender, weil er seine vertraute Umgebung weiter nutzen kann, wie er seine Software-Container bisher managt, und kann dann einfach mit Hardware nachrüsten und die hinzufügen.
Bezüglich LLMs in der Industrie sehen wir häufig Inline-Inspection. Man sollte logischerweise nicht diese Weltmodelle deployen, weil das nicht skaliert, allein aufgrund der aktuellen RAM-Preise und der benötigten Hardware.

Jürgen

Ich würde auch davon abraten, diese Weltmodelle einzusetzen. Je konkreter man arbeiten möchte, und im Industriekontext möchte man oft sehr konkret arbeiten, weil man begrenzte Aufgaben erledigen will, desto größer und umfangreicher das Modell ist, umso größer ist auch die Gefahr des Halluzinierens.
Wenn das entsprechend „gated content“ ist oder vordefinierte LLMs, je konkreter, desto besser kriege ich auch einen konkreten Anwendungsfall und Ergebnisse.

Die Anwendungsfälle sind momentan zumindest gar nicht so komplex: dass man das Benutzerhandbuch auf konkrete Fragen auswertet oder Fehlercodes übersetzt. Das ist beschränkt auf das Benutzerhandbuch, den Fehlercode und die Anfragen. Da braucht man nicht das ganz große Modell.

Tobias

Wichtig ist auch: Wenn der Kunde affin ist und das implementieren möchte, dann wird er häufig auch ein LLM verwenden, um den Use Case zu definieren oder mal einen Chatbot zu fragen. Dann ist es gut, wenn man da vertreten ist und das LLM ausspuckt, wie das umzusetzen ist. Das ist interessant, dass so ein LLM dann sagt, man solle den Software-Stack als containerbasierten Software-Stack aufbauen. Da wurde auch beispielsweise immer wieder eine Control Plane genannt. Das war ganz lustig zu hören, dass ein Chatbot einem Anweisungen gibt, wie das aussehen soll.

Einladung an alle Zuhörerinnen und Zuhörer: Testet das doch mal. Fragt mal genau, wie euer Setup ist und wie die KI das implementieren würde, potenziell mit Containern. Unabhängig von generativer KI zurück zum Thema Container im Shopfloor: Wir sind im OT-Bereich. Was kann die OT von der IT lernen? Was ist anders? Welche Funktionalitäten sollte man übernehmen?

Jürgen

Sehr häufig musste man tatsächlich mit seinem Engineering-Werkzeug, sprich mit dem Notebook, an den Schaltschrank: Notebook auf die Knie, eine 1:1-Kabelverbindung zur SPS und dann den Programmdownload machen. Schritt für Schritt wurde das mit Netzwerktechnik und TCP/IP besser, aber oft war es so, dass man selbst bei gleichartigen Anwendungen, die verteilt in einer Liegenschaft oder Fabrikhalle waren, trotzdem nacheinander den Download machen musste.
Wenn wir im IoT-Kontext denken, dass wir Maschinen vernetzen wollen, sei es für MES-Anwendungen oder Energiemonitoring: Sowohl beim initialen Rollout als auch erst recht bei Änderungen wird es mit dieser 1:1-Beziehung verdammt mühsam.
Der große Vorteil, den die Containerisierung bieten kann, beziehungsweise das, was wir von der IT lernen können, ist, dass Verteilmechanismen oder Deploy-Mechanismen viel flexibler sind. Man kann in größerer Masse ausrollen und auch zu geplanten Zeiten, sodass es die Produktion nicht beeinflusst.

Kannst du diese Flexibilität an einem konkreten Kundenprojekt festmachen?

Jürgen

Da würde ich noch mal auf das eingehen, was du gerade sagtest: Was können wir von der IT lernen? Da gibt es eine Abkürzung, die heißt CI/CD, also Continuous Integration, Continuous Deployment oder Development.
Da kam mal die Frage an einen Kollegen von mir im Vertrieb, vom Kunden: Unterstützt ihr bei WAGO dieses Konzept? Glücklicherweise ist diese Frage bis ins Business Development durchgeroutet worden, und wir konnten darauf eine Antwort finden, sodass dieser Kunde jetzt tatsächlich seine Entwicklung für das SPS-Programm, für viele gleichartige Maschinen, Maschinen-Connectivity, wie vorhin skizziert, über eine CI/CD-Pipeline macht und die Applikationen dann in mehrere hundert Geräte verteilt, in dem Fall auch mit Portainer. Das ist wirklich etwas, wo man absolut davon lernen kann: Werkzeuge aus der IT, die in der OT gut genutzt werden können.

Tobias

Und das, ohne ignorant zu sein und zu sagen: Jetzt nutzen alle in der OT andere Tools und müssten IT-Experten sein. Man gibt das unterschwellig mit als Best Practices, ohne dass eine Zwei-Monats-Schulung für jeden Mitarbeiter notwendig ist.
Gerade im Hinblick auf Rollout, aber auch Versionskontrolle: Vorher hatte man den legendären goldenen USB-Stick. Da ist dann der Stand drauf, keiner weiß, welcher Stand aktuell auf der Maschine ist. Das bringt zusätzliche Vorzüge wie Versionskontrolle mit sich, wo man nicht nur weiß, was aktuell läuft, sondern was man auch als Rollback ausrollen kann, wenn etwas nicht läuft. Das sind entscheidende Themen. In der IT ist das gängige Praxis, in der OT ist das manchmal noch ein kleines Wunder, wenn so etwas vor Ort auftaucht, genauso wie eine dedizierte Testumgebung. Vieles wird immer noch sehr stark in der Produktion getestet.

Jetzt haben wir eine ganze Reihe solcher Fachbegriffe, die für Menschen im OT-Bereich gar nicht so gängig sind. Können wir da noch mal detaillierter rein? CI/CD: Kannst du das definieren? Rollback hast du gerade angesprochen. Kannst du das aus deiner Sicht beschreiben, was es tut?

Tobias

Ich habe in der Software unterschiedliche Versionsstände. Aktuell läuft beispielsweise Versionsstand A. Dann mache ich einen Rollout, will einen neuen Softwarestand ausrollen, und bin bei Versionsstand B. Ich stelle aber fest, dass ich damit nicht zufrieden bin. Dann gehe ich die Rolle rückwärts, mache den Rollback und bin wieder beim Softwarestand A, der funktioniert hat, und kann das mit technischen Tools sehr einfach machen. Was in einer alten oder noch gängigen Welt zum Teil sehr schwierig war.
Das andere Thema ist, dass man den Entwicklungsweg und den Rolloutweg automatisiert gestaltet. Das ist das, was man in der IT unter CI/CD versteht: von dem Erstellen der Software bis hin zum Delivery, also wie es ausgerollt wird, automatisiert und möglichst beschleunigt.

Das Thema Testumgebung ist in der IT total relevant. Ich weiß zugegebenermaßen gar nicht, wie die OT das macht ohne Testumgebung, weil man immer wieder neue Stände applizieren und testen muss.

Tobias

Es gibt auf jeden Fall Kunden, die haben ihre eigenen Laborumgebungen. Man braucht ja meistens, um sicherzugehen, Test-Hardware, weil man das oft nicht einfach in der Cloud testen kann, auch mit Aktuatoren und Sensorik. Das ist preisintensiv. Das kann sich sicher nicht jeder leisten, sollte es aber, weil man in kritischen Umgebungen vorher einmal, idealerweise mit realer Hardware, testen sollte.

Wenn ihr in Gesprächen seid mit potenziellen Kunden: Was sind die Hauptthemen? Gibt es Widerstände? Dieser Konflikt IT/OT ist ja teilweise auch ein persönlicher Konflikt, wo Menschen sich angegriffen fühlen. Merkt ihr Widerstände oder ist es eher ein Informationsthema, dass man aufklären muss und wenn man es verstanden hat, nutzt man es?

Jürgen

Wenn wir an die Anwendungsfälle denken, wird es sehr gerne genutzt, sobald die Vorteile erkennbar sind. Was aber dennoch vorhanden ist und wahrscheinlich aus guten Gründen länger vorhanden bleibt, ist der OT-IT-Gap. Den kann man technisch sehr gut überbrücken, aber organisatorisch ist es getrennt, auch vom Verantwortungsbereich und von den Kostenstellen.
Dinge, die uns als Anwender von Firmenrechnern ärgern, wenn plötzlich ein Update drüber läuft, sind in der IT ärgerlich. In der OT wäre das, drastisch formuliert, tödlich. Ich kann nicht einfach ein Update zu beliebiger Zeit drüber spielen, ohne zu wissen, was die Physik dahinter macht. Der physikalische Impact ist in der OT ein ganz anderer als in der IT.
Aber da gibt es Mechanismen, dass diejenigen, die für den Betrieb von Maschinen und Anlagen verantwortlich sind, diese Technologien „gaten“ können: Die bestimmen, zu welcher Uhrzeit sie das erlauben. Es wird nicht einfach drübergebügelt, wie wir es als PC-Anwender schon mal schmerzlich erfahren haben.

Tobias

Das, was wir gesagt haben, soll nicht IT eine Vormachtstellung geben, sondern eher die OT befähigen, Tools und Best Practices einzusetzen. Die IT ist auch darauf angewiesen, solche Zusammenhänge zu verstehen. Das sollte nicht ignoriert werden, indem man sagt: Wir übernehmen jetzt den kompletten Shopfloor, und uns interessiert nicht, was vor Ort abgeht, weil wir 20 Kilometer entfernt sind.

Wenn ihr mit Kunden sprecht: Die lassen sich ja nicht nur über Architektur überzeugen, da geht es oft um Zahlen, Daten, Fakten. Habt ihr KPIs, die ihr adressiert? Beispiele, wo man sagt: Updates um ein X-Faches schneller, Fehlerquote sinkt? Welche Zahlen stehen da im Raum?

Jürgen

Ganz schnell geht es mit den Argumenten: Laptop auf den Knien und vor dem Schaltschrank hocken versus ein Mausklick. Und nicht nur meine Produktionszelle, wo ich die IoT-Gateways oder auch Steuerungen update, sondern gleich den anderen, gleichartigen Produktionsstandort in einem ganz anderen Land mit. Es gibt genug Szenarien, wo Techniker heute noch um die Welt jetten. Da braucht man nicht lange diskutieren, wenn man die Funktionen vorstellt. Das wird gern genommen.

Das ist ein schöner Business Case, wenn man Reisekosten und Reisezeit berechnen kann. Das lohnt sich in der Regel relativ schnell.

Tobias

Andere Themen sind der Strategievorteil. Ich hatte es eingangs erwähnt mit dem Gaskunden: flexible Architektur, um später nachzurüsten, um nicht von einem Solution Provider abhängig zu sein, wenn es darum geht, einen weiteren Datenpunkt bei der Energieerfassung zu berücksichtigen, der dann auf einmal zwei Millionen US-Dollar kostet. Das ist transparent für jeden: Das kostet in Implementierung und Support nicht zwei Millionen US-Dollar.
Das sieht man auch in der Cloud: Wenn man sich abhängig macht von gewissen Cloud-Providern, kann es schnell böse Überraschungen geben hinsichtlich Kostensteigerungen, automatischen Kostensteigerungen, obwohl kein Mehrwert zusätzlich geschaffen wird.
Kunden schätzen diese Unabhängigkeit: Entweder selbst zusammenbauen, wenn sie dazu in der Lage sind und das wollen, oder ein Systemintegrator übernimmt das, aber die Flexibilität bleibt.

Jürgen

Ich würde das noch ergänzen: Wenn es bisher oft so war, dass auf sehr OT-nahen Geräten genau eine Anwendung gelaufen ist, dann brauchte man den Integrator, der das öffnen kann, der die Version hat, die Softwareversion. Selbst wenn man die als Eigentümer selbst abgelegt und dokumentiert hat, heißt das ja nicht, dass man die Software versteht und eine Änderung vornehmen kann.
Mit containerisierter und flexibel verteilbarer Software kann man beispielsweise einen weiteren Container oder einen zweiten oder dritten hinzu deployen, der zusätzlich lesend auf vorhandene Signale zugreifen kann, eigene Berechnungen anstellt und „on the edge“ andere Auswertungen liefert, die die bisherige Software nicht gemacht hat. Dadurch, dass beides containerisiert ist, beeinflusst sich beides nicht. Man hat Modularität in der Software, und die kann wachsen, unabhängig davon, wer und wie es initial realisiert wurde, solange es containerisiert ist und der Zugriff auf die gewünschten Daten vorhanden ist.

Tobias

Genau, ich kann dann wirklich so eine Art Reserve im Schaltschrank vorhalten, weil es für den Endkunden Aufwand ist, neue Hardware zu kaufen. Das möchte er nicht alle sechs Monate für eine neue Applikation machen. Dann muss er die Schaltpläne anfassen, und das Ganze muss eingebaut werden. Idealerweise macht man das nicht alle sechs Monate, sondern vielleicht erst in ein paar Jahren wieder.

Angenommen, jemand ist jetzt überzeugt und sagt: Jawohl, das mache ich jetzt. Ich lege los. Was sind typische Fehler oder Probleme, die auftreten?

Jürgen

Wenn es um ein OT-nahes Device geht, vielleicht auch eine PLC, damit man die Möglichkeiten hat, wie vorhin beschrieben, Applikationen nachzurüsten, muss man den Zugriff auf alle Signale, auf alle I/Os bereithalten, damit andere Applikationen darauf zugreifen können. Das ist die Basisarchitektur. Wenn ich das zu sehr kapsle und nur eine Applikation zur Verfügung stelle, kann ich keine zweite dazunehmen. Das sollte man am Anfang auf der Ebene beachten.

Tobias

Darüber hinaus sollte man das nicht nur auf eine Komponente reduzieren, sondern idealerweise ganzheitlich adressieren: das ganze Projekt vor Augen haben, mit der eigenen Security-Abteilung sprechen, IT-Security, alle ins Boot holen, weil es häufig ein gemeinsames Projekt zwischen OT und IT ist. Es ist pragmatisch, wenn ein Team anfängt, aber irgendwann müssen alle abgeholt werden. Wenn das zu spät geschieht, gibt es interne Konflikte, die man idealerweise vermeiden kann.

Danke. Das war sehr spannend. Gerade diese Kombination IT, OT und voneinander lernen, ist ein wichtiges Thema. Habt ihr noch letzte Ergänzungen dazu? Sonst wäre meine Frage noch, was ihr noch auf der Hannover Messe macht.

Tobias

Ich habe keine weiteren Ergänzungen. Als Nächstes liegt ein Meetup an, unser Partner-Dinner, wo wir mit strategischen Partnern zusammensitzen und noch mal zusammenkommen heute Abend. Dann geht es morgen weiter zu einem Hardware-Hersteller aus Nürnberg.

Jürgen

Ich bin heute hier, um Inspiration zu gewinnen, und werde noch mal genau nach dem Thema AI schauen und wie sich da das Thema IoT und AI jetzt entwickelt.

Dann freue ich mich auch auf den Austausch, den wir jetzt haben, im IoT Use Case Podcast, auch im Team, im Netzwerk. Bis zum nächsten Mal.