Connectivity frühzeitig planen – Edge Layer verbindet OT und IT

Heute im IoT Use Case Podcast: das Spannungsfeld zwischen IoT für einzelne Maschinen und einem IoT Edge Layer für eine ganze Fabrik, die Fallstricke und Besonderheiten rund um OPC UA, die Rolle von digitalen Zwillingen und künstlicher Intelligenz in der Produktion – und vieles mehr. Zu Gast haben wir von der Firma Kontron AIS Robin Schubert, Produktmanager für Konnektivität in der Produktion, und Frank Tannhäuser, Senior Sales Manager Manufacturing Automation. Wir gehen tief rein und trotzdem in die Breite. Viel Spaß dabei!

Heute mit mir, Dr. Peter Schopf, eurem neuen Podcast-Co-Host. Ich bin Vertretung von Madeleine Mickeleit, die aktuell in einer sehr spannenden Phase in ihrem Leben ist, das heißt kurz vor der Geburt des Nachwuchses. Da freuen wir uns sehr mit ihr und wir wollen sie an der Stelle auch ganz herzlich grüßen. Heute soll es maßgeblich um die Daten gehen und um dieses Edge Layer. Und ich würde euch bitten, euch auch ein bisschen vorzustellen. Robin, wer bist du? Wo sitzt du denn gerade?

Robin

Ich bin heute wieder im Büro, in Dresden, an unserem Standort von Kontron AIS. Ich vertrete das Produktmanagement der FabEagle-Reihe und ganz konkret geht es heute wahrscheinlich viel um das Thema FabEagle®Connect, unsere Lösung für Konnektivität, plus ein paar weitere Tools, die der Konzern beisteuert, die meine Kollegin Vanessa beisteuert, die dann gemeinsam das Thema Edge Layer bedienen können. Ich bin jetzt seit fünf Jahren bei Kontron AIS und drei Jahre davon stecke ich in der Entwicklung von FabEagle®Connect und unseren Leitsystemen.

Da bin ich sehr gespannt, wie weit ihr damit schon seid. Teilweise sind ja wirklich lange Vorlaufzeiten für solche Produkte notwendig. Das ist ja eine Never-Ending-Story in der Regel. Frank, zu dir: Wo bist du gerade?

Frank

Ich mag es, das Private und die Arbeit ein bisschen zu trennen. Deswegen arbeite ich gerne bei uns im Unternehmen. Ich bin im Vertrieb tätig, in der Fabrikautomation, und für unsere Fabrikautomationslösungen wie MES, Leitrechner und die Konnektivitätslösung verantwortlich. Ich habe viele Jahre in der Praxis gearbeitet – Maschinenprogrammierung, Inbetriebnahme von MES-Systemen – und bin jetzt seit rund zehn Jahren im Vertrieb bei Kontron AIS.

Immer gut, jemanden im Vertrieb zu haben, der weiß, wovon er redet, weil er es selbst gemacht hat. Super. Und Kontron AIS: Auf der Homepage habe ich gelesen – ich zitiere – „Ob als Maschinen- oder Anlagenbauer oder als Betreiber einer Fabrik: Wir haben für Sie das passende Softwareprodukt oder die optimale Digitalisierungslösung.“ Das hört sich ja erstmal sehr umfassend an. Was sind denn eure Stärken? Worauf konzentriert ihr euch und was macht ihr vielleicht auch nicht?

Robin

Das Thema ist total spannend, weil wir viele verschiedene Lösungen im Haus haben – von der Konnektivität bis zur Produktionssteuerung. Unser Steckenpferd ist die klassische Automatisierung von Produktionen, also die diskrete Fertigung von Produkten. Dabei sind wir relativ branchenunabhängig. Da, wo wir SPSen in der Produktion finden oder Produktionsleitsysteme, unterstützen wir unsere Kunden – sowohl beim Einsatz eines Produkts als auch bei der Integration. Und gerade die Integration ist oft das Spannende, wo Frank im Vertrieb dann die großen Herausforderungen hat, oder?

Frank

Genau. Die Schnittstellen-Thematiken sind unsere Hauptthemen. Das sind auch die Punkte, die für unsere Kunden wichtig sind. Wir haben zum einen Standardlösungen wie MES-Systeme, aber die Kernaufgabe in solchen Projekten ist häufig herauszufinden: Wie kommen wir an die Daten? Wie machen wir das zuverlässig? Wie funktioniert das stabil? Und wie können wir damit letztendlich dem Kunden weiterhelfen? Das ist teilweise ein eigenes Projekt – die Konnektivität herzustellen. Und da gibt es verschiedene Prozesse, die man anwenden kann. Wir arbeiten in vielen Branchen: Halbleiterfabriken mit hohen Anforderungen und riesigen Datenmengen, ebenso wie klassische Produktionsumgebungen – bis hin zu Herstellern von Poolfolien, die seit 30, 40 Jahren dieselben Prozesse fahren und jetzt digitalisieren wollen. Die brauchen einfach Konnektivität.

In der Vorbereitung hatten wir über euer Konzept des Edge Layers gesprochen. Und diesen Layer, so wie ich es mir vorstelle – und ich bin gespannt auf eure Erklärung – legt man ja sozusagen über die Fabrik, über die Maschinen. Und ich kann mich gut an die Diskussionen erinnern, die wir damals schon hatten: dieser Zwiespalt zwischen Maschinenbauern, die ihre Maschinen konnektieren und Apps dafür bereitstellen wollen, und den Produktionsleitern, die eine Gesamtsicht über die komplette Produktion brauchen – und nicht 20 verschiedene Applikationen von fünf unterschiedlichen Maschinenbauern.
Das heißt, wie passt euer Konzept des Edge Layers da hinein? Wie kam das überhaupt auf? Was war die Grundidee dahinter, welches Kundenproblem habt ihr gesehen – und wie habt ihr das definiert?

Robin

Ich habe dazu eine spannende Zahl vom VDMA gelesen. In einer Umfrage gaben 60 Prozent der Integratoren an, dass sie zusätzliche Gateways oder Middleware-Lösungen benötigen, um Maschinen effizient zu integrieren. Es ist also nach wie vor ein riesiges Thema in der Fabrikautomatisierung, eine passende Middleware zu finden, um Maschinen in die IT zu integrieren. Wir sprechen von Maschinenschnittstellen oder Geräteschnittstellen, die an IT-Systeme angebunden werden müssen – sei es an Leitsysteme wie MES oder an ERP-Systeme zur Materialverwaltung. Ziel ist es, den maximalen Nutzen aus den Maschinendaten zu ziehen oder auch Steuerungsaufgaben umzusetzen.
Der Edge Layer erfüllt nicht nur diese klassische Konnektivitätsaufgabe – Systeme mit unterschiedlichen Schnittstellen zu verbinden. Wir wollen zusätzlich Aspekte wie Update-Fähigkeit integrieren, also Software automatisiert aktualisieren können, und das Monitoring von IoT-Geräten sicherstellen: Sind die Geräte in Betrieb? Wie ist ihre Laufzeit? Wie hoch ist die Uptime? Es geht darum, das gesamte Umfeld der benötigten Geräte für moderne IoT-Anwendungen zu überwachen und zu aktualisieren, um heutigen Sicherheitsstandards gerecht zu werden.

Und das passt gut zu dem Punkt Sicherheit, den du ansprichst. Frank, wenn du in Kundengesprächen bist: Kommen die Kunden auf euch zu, weil sie ein konkretes Problem haben und Standards erfüllen müssen? Oder musst du eher Überzeugungsarbeit leisten und erklären, dass man mit so einem Ansatz Geld sparen oder Ausfallzeiten verhindern kann? Also erlebst du eher Pull oder Push? Und was sind die wichtigsten Bedürfnisse auf Kundenseite?

Frank

Es gibt eigentlich zwei Seiten. Einerseits muss jemand eine solche Lösung überhaupt anbieten – dafür stehen wir, weil wir ein Konzept haben, wie man das in verschiedensten heterogenen Umgebungen umsetzen kann. Andererseits ist es inzwischen auch viel ein Pull-Thema. Das hat sich in den letzten Jahren geändert: Viele Kunden wissen bereits sehr genau, was sie in Richtung Edge Layer brauchen. Sie haben sich informiert, und meistens sind es die IT-Abteilungen, die auf uns zukommen – nicht der Produktionsleiter, der sagt: „Ich brauche jetzt Daten von der Maschine.“ Die IT-Teams sind oft klein und müssen trotzdem komplexe Integrationsprojekte stemmen. Dann braucht es eine flexible, einfach konfigurierbare und wartbare Lösung. Deshalb kommt die Anforderung einer einheitlichen Integrationsschicht heute sehr klar von Kundenseite.
Auch die Branchenanforderungen spielen eine große Rolle. In der High-Volume-Produktion haben wir hohe Durchsatzanforderungen: Maschinen stellen mehrere hundert Produkte pro Minute her, und die produktbezogenen Daten müssen zuverlässig übertragen werden. In anderen Branchen – zum Beispiel Pharma – sind es eher regulatorische Anforderungen. Sobald IT im Spiel ist, muss bewertet werden, ob ein Risiko für die Produktqualität besteht, was am Ende Auswirkungen auf den Menschen hat. Diese Anforderungen beeinflussen natürlich auch, was wir im Produktmanagement entwickeln und priorisieren.

Gerade wenn man in Konnektivität investiert, ist das für viele Mittelständler ein mutiger Schritt. Oft wird ein konkreter Anwendungsfall gesucht, der „alles bezahlt“ – ein sogenannter Killer-Use-Case. Aber den gibt es in der Realität selten. Wir hatten das auch in der Sonderfolge mit Madeleine: Es geht eher um viele kleine Gold Nuggets, viele einzelne Erkenntnisse, die man aus den Daten generieren kann. Wie nehmt ihr das wahr – die Seite des konkreten Nutzens in den Projekten?
Also die Integration ist eine wichtige Voraussetzung. Aber um die Geschäftsleitung zu überzeugen – insbesondere einen CFO, der vielleicht nach ein bis zwei Jahren einen klaren Return on Invest sehen will – braucht es eine Reihe an konkreten Argumenten und Anwendungsfällen. Welche Use Cases nehmt ihr da wahr, die für Kunden am wichtigsten sind? Wahrscheinlich bekommst du da im Vertrieb viel direkt mit, Frank.

Frank

Tatsächlich ist es – unabhängig von der Industrie – oft sehr ähnlich. In der klassischen Fertigung, die nicht unbedingt Hightech ist, startet man fast immer mit dem Thema Transparenz: also Sichtbarkeit von Problemen in der Produktion. Man sucht sich ein oder zwei Kernanwendungen heraus, zum Beispiel das Erfassen von Durchsatz- und Qualitätsdaten an der letzten Station einer Maschine, dem End-of-Line-Test zur Qualitätssicherung. Damit hat man schon zwei sehr wichtige Informationen: wie viele gute Teile produziert werden und wo Ausschuss entsteht. Allein diese Sichtbarkeit kann schon die Rechtfertigung liefern, die Lösung weiter auszurollen.
Dazu kommt: Wenn man erst einmal sieht, wann und warum Anlagen stehenbleiben, kann man Wartung verbessern. Oder man vergleicht Tag- und Nachtschichten miteinander und sieht Optimierungspotenziale beim Training der Mitarbeitenden. Schon dieser erste kleine Use Case zeigt oft recht schnell den Return on Investment – und dann beginnt man, das Ganze auf die gesamte Fertigung zu skalieren.
In Hightech-Umgebungen, wie aktuell in den USA bei neuen Playern im Solarzellenmarkt, ist der Einstieg ein anderer. Da reden wir von hochautomatisierten Fabriken mit automatischen Transportsystemen, innovativen Beschichtungs- und Druckprozessen. Dort denkt man sehr früh über Digital Twins nach – in verschiedenen Ausprägungen. Dafür braucht man eine sehr hohe Datenqualität. Und so wird die Integrationsschicht extrem wichtig und das Projekt schnell sehr umfangreich. In solchen Neufabriken startet man selten klein, sondern versucht von Anfang an, ein großes, einheitliches Konzept umzusetzen, mit einem Layer.

Die Thematik Digital Twin finde ich super. Man kann das ja aus vielen Perspektiven betrachten – den digitalen Zwilling des Produkts, der Maschine, der ganzen Produktion, auf elektrischer, mechanischer und prozessualer Ebene.

[13:04] Herausforderungen, Potenziale und Status quo – So sieht der Use Case in der Praxis aus

Robin, wenn es darum geht, die Anwendungsfälle im Blick zu behalten – wir hatten eingangs schon darüber gesprochen, dass es schwierig ist, ein Produkt in einem Umfeld zu platzieren, das oft starken Projektcharakter hat. Wie fließen die Use Cases der Kunden in eure Produktentwicklung ein? Welche Rolle spielen sie für euch?

Robin

Der Kunde beziehungsweise der konkrete Anwendungsfall spielt bei uns die Hauptrolle. Abseits der sehr modernen Themen wie Digital Twin oder analytische datengetriebene Optimierung arbeiten viele Unternehmen in Europa noch mit Anlagen, die zehn bis fünfzehn Jahre alt sind. Rund 70 Prozent der Produktionsanlagen wurden vor 2010 gebaut. Diese bringen ganz unterschiedliche Schnittstellenprotokolle und Integrationslösungen mit. Deshalb schauen wir immer auf einen sehr diversen Markt. Wir wollen Bestandsanlagen in moderne IT-Umgebungen und neue Produktionsleitsysteme integrieren, genauso wie wir auch neue Anlagen digital anbinden. Unser Ziel ist es, Konnektivität möglichst breit aufzustellen – von klassischen älteren Schnittstellen bis zu modernen Standards, die sich immer weiter durchsetzen. OPC UA ist dafür ein gutes Beispiel: Heute liegt die Marktdurchdringung vielleicht bei 25 Prozent, in den nächsten Jahren wird ein Anstieg auf über 40 Prozent erwartet. Aber OPC UA ist kein Standard, den man per Klick konfiguriert. Dahinter steckt viel Know-how. Man muss nicht nur eine einzelne Maschine betrachten, sondern eine gesamte Produktionslandschaft mit 50 oder 100 Maschinen, die an ein MES angebunden werden und dort Steuerungs- oder Transparenzaufgaben erfüllen.
Ein Thema, das ich gerne ergänzen möchte, ist Security. Das ist eines dieser kleinen Gold Nuggets, die oft vergessen werden. Es lässt sich enorm schwer quantifizieren, wie viel man in Update-Fähigkeit, in Security, in ein gehärtetes Betriebssystem oder in automatisierte Update-Prozesse investieren möchte. Aber genau das ist strategisch entscheidend. Wir begleiten unsere Kunden dabei, damit sie ihre Systeme in Zukunft skalierbar und sicher betreiben können.

Gerade Open Source spielt ja auch eine Rolle in Produktionsumfeldern – gleichzeitig gibt es Herausforderungen bei der Security. Was sind deiner Ansicht nach die Trade-offs zwischen Open Source und proprietären Softwarelösungen?

Robin

Open Source hat definitiv einen festen Platz in der modernen Automatisierung. Linux ist ein gutes Beispiel – unglaublich vielseitig und weit verbreitet. Und es gibt viele Open-Source-Integrationsbibliotheken, die sich hervorragend für Pilotprojekte eignen. Aber wenn wir auf den kommenden Cyber Resilience Act oder auch auf Betriebe mit hohen regulatorischen Anforderungen schauen – wie bei NIS2 –, dann wird klar: Es braucht einen Partner, der Verantwortung übernimmt. Jemand, der Updates bereitstellt, Bibliotheken überwacht, Integration und Aktualisierung unterstützt und gemeinsam mit dem Betreiber ein Konzept entwickelt, wie die Produktion auch in zehn Jahren sicher und effizient läuft. Da spielen viele Faktoren zusammen – und ein Integrationspartner, der das aktiv begleitet, ist extrem wichtig.

Gerade der Cyber Resilience Act ist spannend – und in Kombination mit NIS2 nicht trivial. Frank, erzeugt das bei euren Kunden schon eine spürbare Nachfrage? Ist das Bewusstsein da, was da auf sie zukommt – oder herrscht noch viel Unsicherheit?

Frank

Es ist tatsächlich noch viel Abwarten im Spiel. Viele wollen noch gar nicht so richtig wahrhaben, dass da etwas auf sie zukommt, das sie in den nächsten Jahren stark beschäftigen wird. Am Ende ist es immer eine Risikoabwägung. Manche sagen: „Ich habe zwar Windows-Rechner in der Produktion, aber die stehen doch abgeschottet im Produktionsnetz.“ Nur dass trotzdem Personen physischen Zugang haben und theoretisch Dinge tun können, die sie nicht tun sollten – das wird gerne unterschätzt.
Für Betreiber bedeutet der Cyber Resilience Act künftig Aufwand und Kosten rund um Lizenz- und Systemwartung. Bei Maschinenbauern sehen wir zwei Lager: diejenigen, die sich intensiv damit beschäftigen und Know-how aufbauen – und diejenigen, die es schlicht nicht auf dem Schirm haben, weil sie stark im Preiswettbewerb stehen und jede zusätzliche Sicherheitsanforderung als Kostenfaktor betrachten. Gleichzeitig gibt es aber immer mehr Fabrikbetreiber, die solche Anforderungen bewusst in ihre Lastenhefte schreiben. Dann müssen Maschinenbauer ein Update- und Sicherheitskonzept über den gesamten Lifecycle einer Maschine mitliefern.

Gerade die Produktionsleiter oder Fabrikbesitzer haben ja eine enorme Macht über den Einkauf. Und wenn dort nicht hineingeschrieben wird, dass man an die Maschinendaten rankommen möchte, lässt man sich später vom Maschinenbauer oft den Softwarezugang oder die Datenanbindung separat verkaufen. Robin, wie siehst du als Produktmanager den Cyber Resilience Act aus Produktionssicht? Was sind aus deiner Sicht die wichtigsten Aspekte, die berücksichtigt werden müssen?

Robin

Der Cyber Resilience Act richtet sich besonders an uns als Softwarehersteller. Wir werden verpflichtet, Software kontinuierlich zu aktualisieren, zu unterstützen und Verantwortung für die Bibliotheken zu übernehmen, die wir in unserer Software einsetzen. Das ist ein guter Schritt in Richtung mehr Sicherheit und aktueller Software in der Industrie. Gleichzeitig stellt es uns vor Herausforderungen, weil regelmäßige, iterative Softwareupdates ein erheblicher Kostentreiber in der Entwicklung sind.
Aber das Potenzial ist groß: Betreiber erhalten Produkte, die aktuell und sicher sind und ein gutes Fundament für weitere Sicherheitsaspekte bieten. Für viele wird es jedoch schwierig, wenn sie selbst entwickelte Software im Einsatz haben. Wer Legacy-Software nutzt, für die keine Updates mehr möglich sind oder niemand mehr die Verantwortung trägt, wird in Zukunft vor erheblichen Herausforderungen stehen – sowohl beim Aktualisieren als auch bei der kontinuierlichen Überwachung von Sicherheitsrisiken.

Ich glaube auch, dass das absolut notwendig ist. Viele unterschätzen, wie aufwendig es ist und welche Prozesse man für strukturierte Softwareentwicklung, Lifecycle-Management und Updates etablieren muss.

[21:15] Lösungen, Angebote und Services – Ein Blick auf die eingesetzten Technologien

Kommen wir mal zu OPC UA. Das würde mich noch einmal interessieren – idealerweise an einem konkreten Referenzbeispiel, wo ihr vielleicht auch in Schwierigkeiten geraten seid. Ihr hattet eingangs gesagt: Das ist nicht Plug-and-Play, man verbindet und ist fertig. Kannst du ein Beispiel schildern, wo Herausforderungen aufgetreten sind?

Frank

Wir setzen in unserem Leitrechnersystem ein Track-and-Trace- und Produktionsmanagementsystem ein, vor allem für Montagelinien im Automotive-, Pharma- und Elektronikbereich. Diese Linien sind auf höchsten Durchsatz optimiert. Die Taktzeiten der einzelnen Stationen müssen so gering wie möglich sein, damit die Produktion schnell und effizient läuft. Die Kommunikation der Linie mit dem übergeordneten Leitsystem wird dabei ganz schnell zum Bottleneck, weil jede Millisekunde Teil der Taktzeit ist.
Deshalb haben wir in der Vergangenheit – und auch heute noch – gerne auf sehr basische, bewährte Protokolle wie TCP/IP gesetzt. Das ist stabil, erprobt und performant. Irgendwann kam jedoch die Anforderung: „Nehmt bitte OPC UA – das ist die standardisierte Schnittstelle der Zukunft.“ Also haben wir OPC UA eingesetzt. Und hatten anfangs Performance-Probleme, weil OPC UA on top auf TCP/IP läuft und zusätzliche Latenz erzeugt. Kommunikationszeiten gingen plötzlich teils in den Sekundenbereich. Das ist in einer hoch getakteten Fertigung schlicht nicht akzeptabel.
Auch die Datenkonsistenz ist ein kritisches Thema. Die Daten müssen exakt zu dem Produkt gehören, das gerade in Bearbeitung ist – und nicht zu dem vorherigen oder dem nächsten. Sobald sich Daten überlappen oder vermischen, wird die Information unbrauchbar.
Ein weiteres Thema ist, dass man sich im Klaren sein muss, wie die Daten überhaupt übertragen werden sollen – also die Datenstrukturen selbst. Arbeitet man klassisch auf Tag-Ebene, quasi wie OPC Classic unter dem Deckmantel von OPC UA? Oder nutzt man die neueren Mechanismen wie Events und Methoden? Auch dann müssen Vorkehrungen getroffen werden, um Datenkonsistenz sicherzustellen. Das betrifft sowohl die Client-Seite als auch die Server-Seite. Der Maschinenbauer muss die Daten korrekt bereitstellen, und der Nutzer – etwa ein MES oder Leitsystem – muss sie sauber verarbeiten.

Und dann ist da noch die Frage, welche Bibliotheken man verwendet. Nutzt man ein kommerziell verfügbares Produkt, bei dem ein Dienstleister dahintersteht, der im Problemfall unterstützt? Oder eine Open-Source-Bibliothek, die man einbindet – in der Hoffnung, dass sie auch unter hohen Performance-Anforderungen stabil läuft? Das kann im Vergleich zu klassischer, TCP/IP-basierter Kommunikation schnell zu zusätzlichem Aufwand führen.

Das ist nach wie vor ein großes Thema: Konnektivität ist eben nicht einfach – vor allem bei einem heterogenen Maschinenpark. Robin, du hast auch gesagt, die Maschinen sind teilweise recht alt geworden.  

Robin

Wenn ich auf unsere Projekte schaue oder mit dem Projektmanagement spreche, dann sehen wir sehr häufig, dass die eigentliche Konfiguration der Konnektivitätssoftware nur einen kleinen Teil des Aufwands ausmacht. Ein Großteil unserer Arbeit besteht in Beratung und Spezifizierung: herauszufinden, wie die Maschinenschnittstellen aufgebaut sind, wie ein OPC-UA-Server strukturiert werden muss und wie die Architektur der Datenintegration aussieht. Die gesamte Komplexität steckt im Detail, und die Software ist dann „nur“ das Werkzeug, diese Architektur effizient umzusetzen.

Und um das umzusetzen, braucht es ja Bausteine – wie euer FabEagle zum Beispiel. Wie fügt sich das in solche Implementierungen ein? Wie erleichtert ihr euch damit die Arbeit? Und wie entwickelt sich das weiter?

Robin

Wenn wir eine Anfrage bekommen, starten wir klassisch in der Spezifikation und gehen dann in die Architektur und schließlich in die Anwendung unserer Softwarelösung. Wir achten bei unserem Design sehr darauf, modular zu arbeiten. Schnittstellen und Protokolle sind als Module repräsentiert. Das heißt, Eigenschaften einer jeweiligen Schnittstelle kann ich einfach konfigurieren. Und wenn ich spezifische Logik umsetzen muss – etwa Daten zwischen einem OPC-UA-Client und einer MQTT-Schnittstelle transformieren, filtern oder anders sortieren – mache ich das in einer eigenen Komponente, beispielsweise in C#. Wir trennen also Komplexität sauber voneinander und stellen sicher, dass der Produktanteil im Projekt leicht aktualisierbar bleibt.
Darauf aufbauend nutzen wir das KontronGrid, um FabEagle®Connect als Docker-Container bereitzustellen. Damit sind wir in der Lage zu skalieren: Wir können die Lösung per Knopfdruck auf verschiedene Edge-Gateways ausrollen und so Inbetriebnahme und Updates weitgehend automatisieren. Da kommen zwei Welten eng zusammen – Update-Fähigkeit und klassische Konnektivität, die wir direkt in der Software adressieren.

[28:05] Übertragbarkeit, Skalierung und nächste Schritte – So könnt ihr diesen Use Case nutzen

Gerade KI ist natürlich ein Thema, das aktuell überall diskutiert wird. Gleichzeitig ist KI nicht gleich KI. Viele reden über generative KI, aber klassische KI ist im Produktionsumfeld ja schon lange etabliert. Ihr seid von Sensorik bis Betriebssystem aktiv – wo kann künstliche Intelligenz in der Produktion aus eurer Sicht eine Rolle spielen?

Frank

Der Integrationslayer spielt eine ganz zentrale Rolle. Die Datenqualität ist entscheidend und vor allem die Kontextinformationen rund um die Daten. Das muss schon beim Design der Schnittstellen berücksichtigt werden. Der Integrationslayer stellt Konsistenz sicher und sorgt dafür, dass die KI später auch bewerten kann: „Diese Daten kann ich nutzen.“
In den Projekten, die wir aktuell betreuen, hat der Integrationslayer deshalb zwei Aufgaben: Einerseits stellt er Daten für klassische Anwendungen wie ein MES, also eine Produktionssteuerung, bereit. Andererseits übernimmt er eine Art Weichenfunktion. Es werden nicht mehr alle Daten erst ins MES übertragen, um von dort zur KI zu gelangen. Stattdessen liefert der Integrationslayer Daten direkt und sauber strukturiert an einen Data Lake, wo sie für spätere Analysen vorbereitet werden.
Bei der Integration kann man sehr viel Vorarbeit für spätere KI-Anwendungen leisten. Digital-Twin-Funktionen sind dabei spannend. Unsere Rolle sehen wir vor allem darin, die Infrastruktur bereitzustellen – also die Daten zuverlässig und kontextreich in eine Umgebung wie einen Data Lake zu übertragen. Die eigentlichen KI-Anwendungen sind in unserer Praxis weniger generisch. Es ist nicht so, dass man eine KI installiert und plötzlich „Magie“ passiert. Man braucht Prozessexperten, die die Abläufe verstehen, daraus Modelle entwickeln und diese Modelle wie einen digitalen Zwilling im Betrieb einsetzen.
Wir hatten einmal ein Projekt, da sagte der Kunde: „Wir haben ein Leitrechnersystem, wir sammeln seit zehn Jahren Daten, wir produzieren 500.000 Teile im Jahr – macht doch mal was damit.“ Also haben wir ein Pilotprojekt gemacht, Daten analysiert und Algorithmen angewendet. Ergebnis: Die Datenqualität war nicht besonders und musste zunächst verbessert werden. Und die Erkenntnisse, die wir auswerten konnten und auf die wir stolz waren, kommentierten die Prozessingenieure mit: „Ja, das sind bekannte physikalische Zusammenhänge.“ Also nichts, was wirklich weiterhilft.
Das zeigt: Egal wie viel Geld man investiert, entscheidend ist die richtige Fragestellung. Wenn ich Richtung Predictive Maintenance gehen will, muss klar sein: Für welche Komponenten genau? Für Roboter, Transportsysteme, bestimmte Motoren, bei denen es schon Probleme gab? Oder geht es darum, Prozesse zu überwachen und Anomalien früh zu erkennen? Und die andere Richtung ist, Prozesse aktiv zu optimieren, Fehler möglichst früh zu erkennen oder interne Parameter zu berechnen, die man nicht direkt messen kann – um dann die Technologie weiterzuentwickeln.

Ich glaube, das ist generell bei solchen Projekten notwendig: Es müssen mehrere Expertisen zusammenkommen – das Wissen, wie die Produktion läuft, die Datenexpertise und die Integrationskompetenz.
Robin, generative KI – wir haben viel über klassische KI gesprochen, also eigene Modelle für bestimmte Daten. Siehst du auch für generative KI eine Rolle im Produktionsumfeld?

Robin

Das ist eine schwierige Frage, weil sich viele Use Cases aktuell erst entwickeln. Wir spielen intern bereits verschiedene Ansätze durch, wie wir generative KI bei uns nutzen können. Ein klassisches Szenario ist die Softwareentwicklung: Unsere Lösungen bestehen aus Code – wir können es also als Werkzeug zur Qualitätskontrolle und Verbesserung nutzen. Denkbar ist auch, dass wir künftig Logikbausteine in FabEagle®Connect per Prompt erzeugen lassen. Zum Beispiel gebe ich vor: „Strukturiere die Nachricht, verschiebe die temperaturbezogenen Parameter nach vorne und kürze bestimmte Formate.“ Solche Code-Snippets kann eine KI schon heute generieren.
Und wenn wir über Konnektivität sprechen, geht es natürlich immer auch darum, KI überhaupt anzubinden. Wenn ich meine Software mit einem Service wie ChatGPT kommunizieren lassen möchte, ist das eine Aufgabe der Konnektivität. Dafür braucht es Standardprotokolle – wir haben es ja vorhin besprochen: TCP/IP, REST-Schnittstellen und ähnliches. Viele generative KI-Dienste sind Cloud-Applikationen, die Nachrichten empfangen und senden müssen. Da spielt Konnektivität eine ganz klassische Rolle.

Super. Vielen Dank von meiner Seite – ich fand das Gespräch sehr spannend. Wir haben über OPC UA gesprochen und darüber, dass es nicht so einfach ist, wie man manchmal denkt. Wir sind eingestiegen mit dem Edge Layer, den ihr prägt, und haben gesehen, wie wichtig Partnerschaften und Updates sind, gerade unter den aktuellen regulatorischen Anforderungen. Es wurde deutlich, wie sinnvoll es ist, mit zuverlässigen Partnern zusammenzuarbeiten. Und ich würde euch damit auch das letzte Wort geben: Wie nimmt man mit euch Kontakt auf – und was wollt ihr unseren Hörerinnen und Hörern noch mitgeben?

Frank

Am einfachsten erreicht man uns über unsere Website: kontron-ais.com. Ich möchte mitgeben: Konnektivität ist immer noch nicht einfach – aber man sollte keine Angst davor haben. Es lohnt sich, diese Aufgabe aktiv anzugehen, weil man in solchen Projekten viel lernen und viele Chancen nutzen kann, die man vielleicht schon lange im Kopf hatte. In solchen Projekten schafft man die Grundlagen für zukünftige Entwicklungen.

Robin
Das Thema Konnektivität – ob mit Edge Layer oder anderen Ansätzen – sollte man strategisch angehen. Es geht nicht nur um die reine Verbindung, sondern auch um Aspekte wie Update-Fähigkeit, Bereitstellung und Aktualisierung im Produktionsumfeld. Das muss bereits beim Anlagendesign mitgedacht werden. Wie betreibe ich Konnektivität langfristig – skalierbar und updatefähig, gemeinsam mit einem Partner oder über verschiedene Lösungen hinweg? Wer diese Fragen früh berücksichtigt, behält alle Möglichkeiten offen – ob später KI, Big Data oder ein Data Lake realisiert wird. Wer das von Anfang an plant, hat die Flexibilität, mit zukünftigen Anforderungen gut umzugehen. Kommen Sie gerne auf uns zu. Wir kennen die Themen, wir setzen sie in Projekten um – und der Austausch mit einem Integrationspartner mit Praxiserfahrung ist genau der richtige erste Schritt.

Die Kontakte packen wir in die Show Notes. Herzlichen Dank euch beiden – und bis zum nächsten Podcast.

Frank

Vielen Dank, Peter.

Robin

Vielen Dank, ciao!