Drei Träume für eine andere Fabrik

Es gibt drei Dinge, die sich jeder, der jemals eine industrielle Maschine in Betrieb genommen hat, mindestens einmal gefragt hat. Drei Dinge, die man nicht laut ausspricht, weil sie wie Utopien erscheinen. Dieser Artikel stellt sie in eine Reihe.

Eine Szene, um zu beginnen

Nachtschicht, Abteilung X. Eine Linie stoppt. Das HMI-Panel zeigt einen Code: E-1423. Das Handbuch befindet sich in einem Schrank in drei Gebäuden Entfernung. Der Techniker, der diese Maschine kennt, ist im Urlaub. Der Bediener hat zwei Möglichkeiten: den Kundendienst anrufen – der vielleicht am Morgen antwortet – oder raten. In der gesamten industrialisierten Welt wiederholen sich solche Szenen hunderte Male pro Nacht.

Das Problem ist nicht, dass ein Handbuch fehlt. Es gibt zu viele Handbücher. Das Problem ist, dass die Maschine genau weiß, was sie braucht – der Drucksensor sagt ihr seit dreißig Sekunden, dass etwas nicht stimmt – aber sie kann keine Sprache sprechen, die der Bediener versteht, und wenn sie es kann, beschreibt sie das Problem anstatt der Lösung. "Druck außerhalb des Bereichs" ist kein hilfreicher Satz um drei Uhr nachts. "Überprüfen Sie das Ventil V12 im Luftkreislauf, es ist wahrscheinlich verklemmt" ist es.

Von hier aus beginnt die Arbeit, die wir leisten. Kein neues SPS. Keine schönere HMI. Eine andere Denkweise darüber, wie die Software im Jahr 2026 aussehen sollte, die eine Maschine antreibt. Und drei feste Ideen – man kann sie ruhig Träume nennen – die wir versuchen, zusammenzuhalten.

Traum Nummer eins: Automatisieren ohne zu programmieren

Die industrielle Automatisierung, so wie sie heute ist, erfordert eine sehr spezielle Figur: jemanden, der eine Sprache programmieren kann – die IEC 61131-3-Familie mit ihren Dialekten Ladder, Function Block, Structured Text – die praktisch nirgendwo sonst in der Softwarewelt verwendet wird. Wer diese Sprachen kennt, ist selten, teuer und hat fast immer drei Wochen Verspätung.

Das Paradoxe ist, dass diejenigen, die die Maschine wirklich kennen, oft nicht die Programmierer sind. Es ist der Abteilungsleiter, der erfahrene Wartungsmitarbeiter, der Integrator, der zwanzig ähnliche Anlagen installiert hat. Diese Leute wissen *was* die Maschine tun soll. Sie haben keine Lust, eine Programmiersprache zu lernen, die in den 90er Jahren entstanden ist, um es zu erklären.

Die Idee ist, die Kette umzukehren. Softwareentwickler schreiben wiederverwendbare Komponenten – Bewegungssteuerung, Sensorverwaltung, Betriebsabläufe – nur einmal in modernen, universellen Programmiersprachen. Der Maschinenintegrator programmiert sie nicht, sondern setzt sie zusammen und gibt mündlich oder schriftlich an, was die Maschine tun soll. Ein großes Sprachmodell – ein LLM – fungiert als Übersetzer: Es nimmt die funktionale Spezifikation des Integrators entgegen und wandelt sie in eine ausführbare Konfiguration um, indem es die bereits geschriebenen und getesteten Komponenten zusammenstellt.

Es ist nicht die Fantasie von „KI, die den Code für dich schreibt“. Es ist etwas bescheideneres und realistischeres: KI, die deine Spezifikation liest und aus zertifizierten Komponenten auswählt, wie sie zu kombinieren sind. Der kritische Code – der eine Achse mit einem Zyklus von 5 Millisekunden bewegt – wird weiterhin von einem Menschen in einer Sprache geschrieben, die Determinismus und Zuverlässigkeit gewährleistet. Aber dieser Code wird einmal geschrieben und hundertmal wiederverwendet.

Traum Nummer zwei: Die Maschine, die sich selbst kennt

Heute sprechen die Maschinen wenig und schlecht. Ein Alarm ist ein numerischer Code. Eine Diagnose ist eine Reihe von LEDs. Ein Log ist eine Binärdatei, die nur der Hersteller öffnen kann. Das Wissen, wie diese Maschine mit diesen Toleranzen nach zweitausend Zyklen funktioniert, befindet sich im Kopf einer Person oder in einem PDF irgendwo.

Der zweite Traum ist, dass die Maschine sich selbst kennt. Nicht im mystischen Sinne – im ganz konkreten Sinne: Die technische Dokumentation, die Prozessparameter, typische Fehlerfälle und die Interventionsverfahren befinden sich nicht mehr in einem Schrank oder auf einem separaten Dokumentenserver, sondern in der Maschine selbst, lesbar von ihrer eigenen Software. Und wenn etwas nicht stimmt, sagt die Maschine nicht "Fehler 1423". Sie sagt "Das Ventil V12 klemmt wahrscheinlich, Sie sollten es überprüfen; in der Zwischenzeit kann ich mit 60 % der Geschwindigkeit im degradierten Modus fortfahren".

Der Unterschied besteht zwischen einem passiven Objekt, das signalisiert, und einem aktiven Objekt, das vorschlägt. Das erste überlässt das Problem dem Bediener. Das zweite löst es gemeinsam mit ihm.

Dies erfordert zwei wenig selbstverständliche Dinge. Erstens, dass das Wissen über die Maschine – historisch in Handbüchern, Schaltplänen, CAD-Zeichnungen und im Kopf von Technikern bewahrt – formalisiert und in das System integriert wird. Zweitens, dass das System einen Gesprächspartner hat, der in der Lage ist, ein Gespräch zu führen: wiederum ein LLM, das hier nicht zur Code-Generierung, sondern zur Übersetzung von Symptomen in verständliche Aktionen in der Sprache desjenigen verwendet wird, der vor dem Bedienfeld steht.

Wieder einmal ist es keine Magie. Es ist besser dokumentiert, besser indizierte Dokumentation und eine konversationelle Schnittstelle darüber. Aber es verändert alles für diejenigen, die Nachtschicht haben.

Traum Nummer drei: Die Software, die überall läuft

Der dritte Traum ist der technischste und paradoxerweise auch der politischste. Heute ist die industrielle Automatisierung eine Welt geschlossener Ökosysteme. Jeder große SPS-Hersteller hat seine eigene Sprache, seine eigene Entwicklungsumgebung, seine eigene Hardware, seine eigenen Treiber, sein eigenes Händlernetzwerk. Der Wechsel des Anbieters bedeutet, alles neu zu schreiben.

Das Ziel ist es, ein Softwaresystem zu entwickeln, das auf generischer Hardware läuft – ein Industrie-Mini-PC, ein Embedded-Controller, ein Server im Keller – wobei die Hardware anhand von Budget und benötigter Leistung ausgewählt wird, nicht danach, welche Marke von SPS den Zuschlag erhalten hat. Ein Linux-Betriebssystem in Echtzeitversion, Kommunikationskarten basierend auf offenen Standards (EtherCAT für alle), Softwarekomponenten in modernen Sprachen für die deterministischen Teile und in agileren Sprachen für die nicht-deterministischen Teile.

Die Regel, und hier wird die Utopie konkret: Die Hardware soll die Leistung beeinflussen, niemals die Zuverlässigkeit. Dieselbe Logik muss auf einer weniger leistungsstarken Maschine identisch funktionieren – nur langsamer. Wenn die Zykluszeit von 5 auf 10 Millisekunden steigt, bewegt sich die Achse mit der gleichen Präzision, aber mit halber Geschwindigkeit. Nie "fast gleich". Nie "funktioniert außer in diesem Fall". Dasselbe System, dieselben Entscheidungen, dieselben Garantien.

Dies ist der Teil, in dem erfahrene Ingenieure lachen. Sie wissen sehr gut, dass Echtzeit schwierig ist, dass Linux nicht als Echtzeit-System geboren wurde, dass LLMs nicht auf einem Raspberry Pi laufen und dass das Mischen verschiedener Sprachen im selben Stack mehr Fallstricke birgt, als Tutorials versprechen. Sie haben Recht. Aber die Richtung ist die richtige, und die Bausteine, um sie zu bauen – die Echtzeit-Erweiterungen des Linux-Kernels, ausgereifte Open-Source-EtherCAT-Stacks, LLMs, die auf bescheidener Hardware laufen – existieren heute, zum ersten Mal alle zusammen.

Warum "Utopie"

Utopie ist ein ehrliches Wort. Keine dieser drei Dinge ist heute ein fertiges Produkt. Die erste erfordert LLMs, die zuverlässig genug sind, um in einer Produktionsumgebung eingesetzt zu werden, und wir stehen erst am Anfang. Die zweite erfordert eine enorme Formalisierung des industriellen Wissens, das heute fast ausschließlich informell ist. Die dritte erfordert den Aufbau offener Alternativen gegen geschlossene Ökosysteme, die einen Vorsprung von zwanzig Jahren haben.

Aber die drei Träume zusammen, wenn sie in eine Reihe gestellt werden, zeichnen eine klare Richtung: eine Automatisierung, in der die Hardware eine Massenware ist, die Software wiederverwendbar ist, das Wissen in die Maschine eingebettet ist und die Figur des SPS-Programmierers – heute Flaschenhals einer ganzen Industrie – nicht verschwindet, sondern dorthin verlagert wird, wo sie wirklich gebraucht wird, nämlich um die Basiskomponenten einmal für alle zu schreiben.

In den folgenden Artikeln werden wir die Teile dieses Puzzles vorstellen, an denen wir arbeiten. Eines nach dem anderen, ohne zu versprechen, dass das Puzzle vollständig ist. Das ist es noch nicht. Aber das Bild beginnt sich abzuzeichnen.