Der Roboter läuft schon. Was ihm fehlt, ist Erfahrung.

Fabriken werden nicht ersetzen, was sie bereits installiert haben. Die Chance liegt in einer Schicht, die den Robotern beim Lernen hilft.

Wieder schafft es ein humanoider Roboter in die Nachrichten. In den Fabriken arbeiten derweil weiterhin Roboterarme, die vor Jahren installiert wurden.

Die International Federation of Robotics meldete am 24. September 2026, dass weltweit etwa 5 Millionen Industrieroboter in Fabriken im Einsatz sind. Der Bestand wuchs 2025 um 9 Prozent, und allein in diesem Jahr wurden mehr als 600.000 neue Einheiten installiert. Kaum eine Fabrik wird diesen Bestand verschrotten, nur weil ein neuerer Roboter Beine hat. Eine funktionierende Roboterzelle bleibt in Betrieb. Meine persönliche Einschätzung für die Planung: eher mit 10-15 Jahren Nutzung rechnen als mit einem neuen Roboter zu jeder Premierensaison.

Im Mai schrieb ich, dass nicht der Roboter der schwierige Teil ist, sondern die Fabrik. Daraus ergibt sich die nächste Frage: Wenn die Fabrik ihre Roboter behält, was können wir ergänzen?

Meine Antwort ist Erfahrung.

Was weiß ein alter Roboter eigentlich?

Mehr, als man denkt. Ein Roboter, der jahrelang in derselben Zelle Teile gegriffen hat, war mit schlechtem Licht, falsch liegenden Teilen und staubigen Schichten konfrontiert.

Das Problem ist, dass ein großer Teil dieser Erfahrung die Zelle nie verlässt. Das Programm kennt die Bewegungen. Einige Bediener kennen die Ausnahmen. Der Rest ist verstreut: ein Handyvideo von der Inbetriebnahme, eine Kamera in der Fertigung, deren Aufnahmen selten jemand ansieht, ein Alarmprotokoll, das niemand zweimal liest.

Der Roboter arbeitet also, aber er lernt nicht. Eine neue Aufgabe kann Arbeitszeit von Ingenieuren, Umprogrammierung und das Risiko bedeuten, etwas Funktionierendes zu stören.

Wo steckt diese Erfahrung bereits?

Bevor ich irgendetwas generiere, möchte ich mir ansehen, was schon vorhanden ist. Auf einem typischen Fertigungsboden gibt es mehr Quellen, als viele vermuten:

• Handys der Bediener: Videos eines neuen Ablaufs oder einer manuellen Korrektur.
• Kameras, die bereits die Linie oder das Innere einer Maschine beobachten.
• Kameras für die visuelle Inspektion, bei denen jemand die schwierigen Fälle bereits aussortiert hat.
• Telemetrie: PLC- und MES-Signale, Alarme, Wiederholungsversuche, Zyklusergebnisse, Stillstände.
• Menschen, die einen Ablauf einmal zeigen, von der Seite oder aus ihrer eigenen Perspektive.

Was wir daraus gewinnen möchten, ist konkret: Fehlerepisoden, den Moment, in dem ein Bediener die Situation korrigiert, und seltene Ereignisse, die sich nur schwer gezielt filmen lassen. Dazu kommen einfache Hinweise für die Zuordnung: Wenn ein Alarm gleichzeitig mit einem fehlgeschlagenen Griff ausgelöst wird, weiß man, welche Bilder sich anzusehen lohnen.

Erst vorhandene Erfahrung sammeln, dann generieren.

Was macht die Lernschicht?

Ich stelle sie mir als einen geplanten Kreislauf über dem Roboter vor, nicht an seiner Stelle:

1. Die tatsächliche Arbeit beobachten: Kameras, Roboterzustand, Befehle, Ergebnisse.
2. Die Erfahrung sammeln, die rund um die Maschine bereits vorhanden ist.
3. Die Lücke finden: Warum ist etwas fehlgeschlagen und welche Art von Beispiel fehlte?
4. Die fehlende Erfahrung schaffen: weitere reale Beispiele, eine Vorführung durch einen Menschen, eine Simulation oder generierte Daten.
5. Prüfen: Alte und neue Version anhand realer Ereignisse vergleichen, die das Modell noch nicht gesehen hat.
6. Die Verbesserung signiert auf dem Edge-System bereitstellen, mit einer Möglichkeit zur Rückkehr zur alten Version.

Synthetische Daten stehen in Schritt vier, als eines von mehreren Werkzeugen. Das sage ich bewusst. Die Datengenerierung ist bereits ein umkämpfter Markt mit ernst zu nehmenden Anbietern. „Wir können rendern, was schwer zu filmen ist“ wäre keine Position, die sich verteidigen lässt. Die nützliche Frage kommt vorher: Fehlen tatsächlich Daten? Manchmal reichen besseres Licht, eine stärkere Datenaugmentation oder fünfzig zusätzliche reale Beispiele. Dann ist die richtige Antwort, gar nichts zu generieren.

Eine neue Version geht nur dann in den Betrieb, wenn sie bei zurückgehaltenen realen Ereignissen besser abschneidet als die alte. Wenn nicht, bleibt sie im Labor.

Was ist ein Kompetenzpass?

Das wäre ein aufgabenbezogener Nachweis darüber, wie gut ein Roboter arbeitet, welche Version er verwendet und wo er noch scheitert. Diesen Teil habe ich zuerst verstanden, denn ich komme von der geisteswissenschaftlichen Seite und mag ein gutes Dokument.

Nach diesem Konzept hätte jeder Roboter für jede Aufgabe einen Eintrag: Erfolgsquote, Zykluszeit, Häufigkeit menschlicher Eingriffe, Häufigkeit selbstständiger Erholung, laufende Modellversion, Anzahl realer und synthetischer Trainingsbeispiele, bekannte Schwächen und verwendete Hardware.

So wird aus „Die KI ist besser geworden“ eine Zahl, die jemand unterschreiben kann. Der Pass reist auch mit dem Roboter. In Deutschland vertraut man seit Langem einem Dokument mit Stempel. Ein Roboter mit Pass sollte sich hier also zu Hause fühlen.

Lässt sich das ergänzen, ohne die Sicherheitssteuerung anzutasten?

Das ist eine Entwurfsbedingung, kein nachträglicher Einfall. Die bestehende Steuerung behält die Entscheidungsgewalt. Die Schicht sitzt daneben, liest Zustände, ergänzt Kameras und darf nur ändern, was der bestehende Sicherheitsrahmen erlaubt: das Bildverarbeitungsmodell, die Auswahl des Griffs, die Aufgabenfolge, Wartezustände, die Logik für Wiederholungsversuche und Parameter.

Sie umgeht keine Sicherheitsfunktion, erhöht keine Antriebsgrenzen und ist niemals der einzige Sicherheitsmechanismus. Jede Verhaltensänderung muss weiterhin einer Sicherheitsbewertung der gesamten Zelle unterzogen werden. ISO 10218-2:2025 behandelt Roboteranwendungen und Roboterzellen. Das sind Grundsätze für den geplanten Entwurf; der Bewertungs- und Freigabeweg für eine konkrete Nachrüstung müsste noch mit dem Sicherheitsingenieur festgelegt werden.

Warum sollte ein Unternehmen für Embedded Engineering das bauen?

Weil der größte Teil der Arbeit nicht im maschinellen Lernen liegt.

Eine bestehende Fertigungszelle bietet selten einen sauberen Software-Stack. Sie bietet eine ältere Steuerung, einen Feldbus, eine Kamera, die einen Treiber braucht, und zeitliche Vorgaben, denen ein cleverer Prototyp egal ist. Die Arbeit steckt in Konnektoren für PROFINET, EtherCAT und OPC UA, in der Bildaufnahme mit geringer Latenz und deterministischer Bildverarbeitung, in Edge-Computing direkt an der Linie und in der Absicherung des gesamten Systems: sicherer Systemstart, signierte Modellupdates und ein Weg zurück, falls ein Update fehlschlägt.

Der letzte Punkt verdient Aufmerksamkeit. Für ein System, das KI-Updates erhält, würde ich sichere Updates und Sicherheit über den gesamten Lebenszyklus von Anfang an einplanen und prüfen, ob der EU Cyber Resilience Act für die konkrete Umsetzung gilt. Das ist ein Projektgrundsatz, keine Feststellung zum rechtlichen Geltungsbereich.

Embedded-Teams kennen auch das Muster, einer funktionierenden Plattform eine neue Funktion hinzuzufügen, ohne sie neu zu entwickeln. Die öffentliche Fallstudie von Promwad beschreibt, wie einer modernen Bildverarbeitungsplattform über einen Linux-Treiber ein analoger Videoausgang hinzugefügt wurde, ohne die Platine neu zu entwickeln. Eine Lernschicht folgt demselben Muster, eine Ebene höher.

Wie sähe der erste Proof of Concept aus?

Bewusst klein: Ausnahmen in einem Teilebehälter, bevor der Roboter zugreift.

Eine Teilefamilie. Eine fest installierte Kamera über dem Behälter. Zwei oder drei seltene, aber sichtbare Situationen: ein Teil ist falsch ausgerichtet, unter einem anderen verdeckt oder doppelt gestapelt. Die Kamera erkennt die Situation, und der bestehende Roboter erhält eine Antwort innerhalb fester Grenzen: annehmen, überspringen, stoppen oder einen Bediener rufen. Keine freie Navigation, kein Humanoid, kein neuronales Netz innerhalb einer Sicherheitsfunktion.

Dann kommt der Teil, der mir am wichtigsten ist: ein ehrlicher Vergleich:

• nur reale Daten,
• reale Daten plus gewöhnliche Augmentation,
• zusätzlich gerenderte Szenen,
• zusätzlich generierte Varianten,
• zusätzlich einfach mehr reale Beispiele bei gleichen Kosten sammeln.

Getestet wird an realen Ereignissen, die vom Training ausgeschlossen waren. Wenn generierte Daten stärkere herkömmliche Methoden bei gleicher Fehlalarmrate nicht übertreffen, sollte man aufhören und genau das sagen. Ich würde als Ziel 25 Prozent weniger übersehene Ausnahmefälle gegenüber dem Ausgangswert bei gleicher Fehlalarmrate vorschlagen. Das ist ein vorgeschlagenes Testziel, das mit einem Entwicklungspartner zu vereinbaren wäre, kein Ergebnis.

Auch die Wirtschaftlichkeit ist einfache Arithmetik. Nehmen wir eine Station mit 1.000.000 Zyklen pro Jahr, 1 Prozent kostspieligen Fehlern, 50 Euro pro Vorfall und 30 Prozent davon, die sich mit besserer Bildverarbeitung vermeiden ließen. Das ergibt 150.000 Euro im Jahr vor Kosten. Bei 100.000 Zyklen ergeben dieselben Annahmen 15.000 Euro. Das kann weniger sein, als die Lösung kostet. Diese Zahlen dienen nur zur Veranschaulichung und stammen nicht von einem Kunden. Entscheidend ist: Die Station muss nach den Kosten ihrer Fehler ausgewählt werden, nicht danach, wie gut die Demo aussieht.

Was kann ich heute ehrlich sagen?

Für diese Aufgabe wurde noch kein Modell trainiert. Bisher habe nur ich dabei etwas gelernt.

Es gibt einen Plan, eine Liste von Hypothesen und einen klaren Weg, sie zu beweisen oder zu verwerfen. Für den Anfang brauche ich einen Entwicklungspartner mit einer installierten Zelle, einem Fehlerprotokoll, Zugang zu realen Bildern und einem Ingenieur, der einen Test genehmigen darf. Die Referenzdaten müssen rechtmäßig beschafft werden, und die Nutzungsrechte müssen schriftlich feststehen. Rohe Produktionsdaten bleiben am Standort des Kunden. Nur was der Vertrag erlaubt, verlässt ihn.

Falls die erste Zelle zeigt, dass eine Lampe die günstigere Lösung ist, wäre auch das ein nützliches Ergebnis.

Welcher Roboter bei Ihnen weiß etwas, das nie jemand aufgeschrieben hat?