Wie man Physical AI sicher in die Fertigung integriert – mit deterministischer Steuerung

Um Physical AI sicher in die Fertigung zu integrieren, müssen Ingenieure probabilistische Bewegungs- und Entscheidungsmodelle einer deterministischen Steuerungslogik, einem verifizierten Anlagenzustand und festen Sicherheitsverriegelungen unterordnen. In der Praxis bedeutet „physische Intuition“, Scan-Zyklen, Latenz, Hysterese und Zustandsabweichungen zu berücksichtigen, bevor das KI-Verhalten jemals auf echte Maschinen trifft.

Physical AI scheitert nicht an einem Mangel an cleveren Modellen. Sie scheitert daran, dass Industrieanlagen nach wie vor den Gesetzen von Zeit, Trägheit, Reibung und Sicherheitsarchitektur gehorchen.

Diese Unterscheidung ist wichtig, da sich Investitionen in humanoide und physische KI zuletzt auf Kinematik, Wahrnehmung und dynamische Bewegungen konzentriert haben, während der Wert in der Fabrik meist woanders entsteht: bei der deterministischen Ablaufsteuerung, wiederholbaren Zykluszeiten, Fehlerbehebung und der sicheren Interaktion mit Prozessanlagen. Ein Roboter, der einen Rückwärtssalto macht, ist beeindruckend; ein Roboter, der eine geschützte Zelle einen Scan-Zyklus zu früh betritt, ist teuer.

In aktuellen Simulations-Benchmarks von OLLA Lab, bei denen KI-generierte Pick-and-Place-Sequenzen gegen 3D-Digital-Twins getestet wurden, scheiterten 82 % der Sequenzen im ersten Durchlauf an den Abnahmekriterien der Inbetriebnahme, weil sie physikalische Einschränkungen wie Aktorlatenz, Rückmeldezeiten oder Zustandsbestätigungen ignorierten. Methodik: n=61 Sequenzversuche bei Pick-and-Place- und Transferaufgaben, verglichen mit von Ausbildern erstellten deterministischen Baselines, beobachtet während interner Tests von Januar bis März 2026. Dies stützt eine enge These: KI-Logik im ersten Durchlauf übersieht oft physikalische Ausführungsgrenzen. Es beweist nicht, dass KI generell ineffektiv ist, sondern nur, dass eine unkontrollierte Implementierung in der OT ein schlechter Ersatz für Validierung ist.

Physical AI hat in der Industrie Schwierigkeiten, weil die meisten KI-Systeme probabilistisch und asynchron arbeiten, während die industrielle Steuerung auf deterministischer Zustandsbehandlung und begrenztem Fehlerverhalten basiert.

Ein Bildverarbeitungsmodell kann ein Objekt mit hoher Konfidenz klassifizieren und dennoch operativ falsch liegen, wenn die Spannvorrichtung nicht als „geschlossen“ gemeldet wurde, die Zone nicht frei ist oder die nachgelagerte Maschine den Handshake nicht abgeschlossen hat. Die industrielle Steuerung lässt sich von Konfidenzwerten nicht beeindrucken. Sie verlangt nach Freigaben, Rückmeldungen und einem bekannten sicheren Zustand.

Der Kernkonflikt ist architektonischer Natur:

| Dimension | Kinematische / Physical AI | Deterministische SPS-Logik | |---|---|---| | Primäres Ziel | Anpassung von Bewegung/Aktion an wechselnde Bedingungen | Ausführung definierter Abläufe mit begrenztem Verhalten | | Entscheidungsmodell | Probabilistisch, modellbasiert, oft asynchron | Regelbasiert, scan-gesteuert, deterministisch | | Fehlermuster | Konfidenzverlust, Fehlklassifizierung, instabile Policy-Ausgabe | Zustandsabweichung, Verriegelungsverletzung, Timeout, Sequenzfehler | | Zeitverhalten | Variable Inferenz- und Antwortzeiten | Bekannte Scan-Zyklus-Ausführung und explizite Timer | | Hardware-Bezug | Oft abstrahiert durch Middleware oder übergeordnete Schichten | Direkt verknüpft mit E/A, Rückmeldungen, Freigaben und Abschaltungen | | Operativer Nachweis | Aufgabenerfolg unter variablen Bedingungen | Verifizierte Sequenzkorrektheit und sichere Fehlerbehandlung |

Die praktische Konsequenz ist einfach: KI kann Bewegungen, Sollwerte oder Aufgabenabsichten vorschlagen, aber sie kann nicht als letzte Instanz über den Maschinenzustand behandelt werden. In der Fertigung muss die Logik, die Bewegungen ermöglicht, immer noch langweilige, aber wesentliche Fragen beantworten: Ist die Schutztür geschlossen? Ist die Achse referenziert? Ist der Zylinder tatsächlich ausgefahren? Langweilige Fragen halten Maschinen intakt.

Das ist auch der Grund, warum die Phrase „SPS vs. KI“ meist falsch gerahmt wird. Die nützliche Unterscheidung ist nicht Ersatz gegen Überleben. Es ist probabilistische Optimierung gegen deterministisches Veto.

Physische Intuition ist die beobachtbare Fähigkeit, Steuerungslogik für das tatsächliche Verhalten von Anlagen zu entwerfen, zu testen und zu überarbeiten – nicht für das Verhalten, das die Software annimmt.

Diese Definition ist enger gefasst, als der Begriff in Marketingtexten meist verwendet wird. In der Automatisierungstechnik ist physische Intuition kein „Gefühl“. Sie ist in der Logik und in der Testmethode sichtbar.

Ein Ingenieur mit physischer Intuition tut Folgendes:

• Fügt Entprellung oder Filterung für verrauschte diskrete Eingänge hinzu.
• Unterscheidet zwischen befohlenem Zustand und nachgewiesenem Zustand.
• Berücksichtigt Ventil-Laufzeiten, Zylinder-Füllzeiten und Sensorverzögerungen.
• Baut Timeout-Behandlungen für fehlgeschlagene Übergänge ein.
• Verhindert Race Conditions bei parallelen Schritten oder asynchronen Signalen.
• Erfordert eine Rückmeldebestätigung, bevor die nächste Aktion freigegeben wird.
• Trennt Sicherheitsfunktionen vom normalen Steuerungsverhalten.

Die 3 Grundpfeiler der physischen Intuition

#### 1. Bewusstsein für den Scan-Zyklus

Scan-Zyklus-Bewusstsein bedeutet zu verstehen, dass die SPS Eingänge liest, Logik löst und Ausgänge nacheinander schreibt, nicht alles gleichzeitig.

Das ist wichtig, weil eine Diskrepanz von nur einem Scan-Zyklus falsche Annahmen darüber erzeugen kann, was physisch geschehen ist. Wenn ein KI-Agent einen Bewegungsbefehl ausgibt und die SPS einen Ausgang bestromt, bedeutet das nicht, dass der Mechanismus die Bewegung abgeschlossen hat. Es bedeutet, dass der Befehl geschrieben wurde. Die Realität bleibt hartnäckig extern.

#### 2. Mechanische Latenz

Mechanische Latenz bedeutet, die Zeit einzuplanen, die reale Geräte benötigen, um nach einem Befehl zu reagieren.

Beispiele hierfür sind:

• Pneumatikzylinder, die Füll- und Laufzeit benötigen
• Motorstarter, die Anlaufzeit benötigen
• Ventile, die Laufzeitverzögerungen oder Haftreibung (Stiction) aufweisen
• Analoge Regelkreise, die langsamer einschwingen, als es diskrete Logik erwartet

Hier hören Timer auf, Dekorationen im Klassenzimmer zu sein, und werden zu Werkzeugen der Ingenieurskunst.

#### 3. Zustandsdiskrepanz

Zustandsdiskrepanz bedeutet, die Lücke zwischen dem, was die Steuerung angefordert hat, und dem, was die Maschine tatsächlich nachgewiesen hat, zu handhaben.

Typische Diskrepanzfälle sind:

• Spannbefehl an, aber Schalter „Spannung geschlossen“ immer noch aus
• Förderband-Ausgang an, aber Nullgeschwindigkeitswächter nicht aktiv
• Roboter-Zonenfreigabe angenommen, aber Präsenzsensor immer noch belegt
• KI-generierter Sollwert akzeptiert, aber Prozessvariable bewegt sich in die falsche Richtung

Die Aufgabe des Ingenieurs ist es nicht, den Befehlspfad zu bewundern. Es ist die Überwachung der Abweichung.

„Simulation-Ready“ sollte operativ als die Fähigkeit definiert werden, Steuerungsverhalten vor dem Einsatz an echten Anlagen zu beweisen, zu beobachten, zu diagnostizieren und gegen realistische Prozessreaktionen abzuhärten.

Das ist nicht dasselbe, wie Ladder-Syntax auswendig zu können. Syntax ist nützlich; Einsatzfähigkeit ist das, was Stillstandszeiten bezahlt.

Ein „Simulation-Ready“-Ingenieur kann:

• Ladder-Logik erstellen, die an explizite E/A und Anlagenzustände gebunden ist
• Definieren, was „korrekt“ bedeutet, bevor die Tests beginnen
• Ursache und Wirkung im simulierten Maschinenverhalten beobachten
• Abnormale Bedingungen injizieren und Fehlerpunkte identifizieren
• Logik nach einem Fehler überarbeiten und gegen dieselben Kriterien erneut testen
• SPS-Zustand mit dem simulierten physikalischen Zustand vergleichen und Abweichungen erklären

Das ist der Standard, der zählt, wenn KI in den Steuerungs-Stack eingeführt wird. Wenn ein Ingenieur nicht erklären kann, warum die simulierte Spannvorrichtung nie als „geschlossen“ gemeldet wurde, validiert er keine KI-Integration. Er schaut sich eine Animation an.

Ingenieure validieren KI-zu-SPS-Handshakes sicher, indem sie KI-Ausgaben innerhalb einer begrenzten Simulationsumgebung testen, in der Steuerungslogik, E/A-Verhalten und Anlagenreaktion beobachtet werden können, ohne Live-Anlagen unkontrolliertem Verhalten auszusetzen.

Hier wird OLLA Lab operativ nützlich. OLLA Lab ist ein webbasierter Simulator für Ladder-Logik und Digital Twins, mit dem Benutzer Logik erstellen, Simulationen ausführen, Variablen prüfen, E/A testen und Verhalten gegen 3D- oder WebXR-Anlagenmodelle validieren können. Im Rahmen dieses Artikels ist seine Rolle spezifisch: Es ist eine Übungsumgebung für die Inbetriebnahme von Logik und KI-zu-Hardware-Interaktionen, kein Abkürzungsweg zur Kompetenz durch Assoziation.

Ein sicherer Validierungs-Workflow umfasst typischerweise:

• Bewegungsanforderung
• Sollwertempfehlung
• Signal „Aufgabe abgeschlossen“
• Routen- oder Sequenzvorschlag

• Sicherheitskette intakt
• Erforderliche Freigaben wahr
• Anlage in bekanntem Zustand
• Handshake nachgelagert/vorgelagert abgeschlossen

• Eingänge umschalten
• Ausgangsübergänge beobachten
• Timer, Zähler, Komparatoren und Zustandsbits überwachen
• Bestätigen, ob der physische Nachweis tatsächlich erbracht wird

• Fehlende Rückmeldung
• Verzögerte Aktorreaktion
• Sensorflattern
• Analoge Drift
• Sequenz-Timeout

• Nachweislogik hinzufügen
• Timeout-Alarme hinzufügen
• Verriegelungen hinzufügen
• Fehlerbehandlung für Wiederholungsversuche oder Fehlerzustände hinzufügen

1. Definition der zu überwachenden KI-Ausgabe
2. Abbildung der deterministischen Abnahmekriterien
3. Simulation des Befehlspfads
4. Injektion abnormaler Zustände
5. Überarbeitung der Ladder-Logik und erneuter Test

In OLLA Lab wird dieser Workflow durch den Ladder-Editor, den Simulationsmodus, das Variablen-Panel, Szenariosteuerungen, analoge Werkzeuge und den Digital-Twin-Kontext unterstützt. Der nützliche Teil ist nicht, dass die Simulation industriell aussieht. Der nützliche Teil ist, dass sie den Ingenieur zwingt, den Rung-Zustand mit dem Anlagenzustand in Einklang zu bringen.

Die Grundregel lautet, dass Physical AI der deterministischen Sicherheitsarchitektur und den verifizierten Maschinenfreigaben untergeordnet bleiben muss.

Diese Aussage sollte nicht als vollständige Vorgabe für das Sicherheitsdesign gelesen werden. Die Sicherheit kollaborativer Robotik hängt von der anwendungsspezifischen Risikobeurteilung, dem Design der Sicherheitsfunktionen und der Interpretation von Normen ab. Dennoch ist das Steuerungsprinzip stabil: Keine KI-Schicht darf in der Lage sein, festverdrahtete oder sicherheitsgerichtete Schutzfunktionen zu umgehen.

In der Praxis benötigen Ingenieure üblicherweise Verriegelungen wie:

• Not-Halt-Kette intakt
• Schutztür geschlossen und überwacht
• Lichtvorhang oder Bereichsscanner frei
• Servo bereit / Antriebe fehlerfrei
• Spannvorrichtung oder Aufnahme bestätigt
• Teil vorhanden oder Bereich frei
• Achse referenziert / in Position
• Kein aktiver Fehler- oder Timeout-Zustand
• Sichere Geschwindigkeit / sichere Zonenbedingungen, falls zutreffend

OLLA Lab kann genutzt werden, um diese Beziehungen zu proben, indem Freigabelogik erstellt, Rückmeldeübergänge simuliert und beobachtet wird, was passiert, wenn ein Nachweis ausbleibt. Das ist eine nützlichere Übung, als einen fehlerfreien Demo-Pfad zu beobachten. Echte Inbetriebnahme dreht sich meist darum, was passiert, wenn ein Signal lügt, klemmt oder zu spät kommt.

Aus Sicht der Normen sollte dieser Abschnitt sorgfältig eingegrenzt werden. IEC 61508 etabliert den breiteren Rahmen für funktionale Sicherheit bei elektrischen, elektronischen und programmierbaren sicherheitsbezogenen Systemen. Für Maschinenanwendungen arbeiten Ingenieure zudem innerhalb maschinenspezifischer Sicherheitsnormen und Risikobeurteilungsmethoden. Die Behauptung des Artikels ist eng gefasst: Die Validierung von KI-Verhalten gegen deterministische Überwachungslogik steht im Einklang mit der Disziplin der funktionalen Sicherheit; sie ist kein Ersatz für formales Sicherheitsdesign oder SIL-Bestimmung.

Probabilistische KI sollte nicht direkt an Live-Produktionshardware getestet werden, da die industrielle Inbetriebnahme kontrollierte Fehlermodi, begrenztes Risiko und den Nachweis erfordert, dass sich das System unter abnormalen Bedingungen sicher verhält.

Live-Produktionslinien sind schlechte Orte, um zu entdecken, dass eine Policy die pneumatische Verzögerung ignoriert hat, dass eine Sequenz ohne Nachweis fortgeschritten ist oder dass ein empfohlener Sollwert einen Regelkreis destabilisiert. Fabriken sind auf Ausstoß optimiert, nicht auf improvisiertes Lernen.

Die Risiken sind nicht abstrakt:

• Anlagenschäden durch vorzeitige Bewegung oder fehlerhafte Sequenzierung
• Produktverlust durch instabile Prozessübergänge
• Sicherheitsrisiken, wenn Annahmen über menschlichen Zugang falsch sind
• Verlängerte Ausfallzeiten durch Fehlerzustände, die nie modelliert wurden
• Irreführende Konfidenz, wenn eine Sequenz unter idealen Bedingungen „meistens funktioniert“

Deshalb ist die Digital-Twin-Validierung wichtig. In einer begrenzten Simulation können Ingenieure den befohlenen Zustand, den SPS-Zustand und die simulierte Anlagenreaktion vergleichen, ohne für Fehler mit Ausschuss, Stillstand oder verbogenem Metall zu bezahlen.

Die Literatur unterstützt diese Richtung weitgehend. Aktuelle Arbeiten zu Digital Twins, immersiver industrieller Ausbildung und virtueller Inbetriebnahme weisen konsistent auf Gewinne bei der frühen Fehlererkennung, Sequenzvalidierung sowie der Vorbereitung von Bedienern und Ingenieuren hin, wobei die Ergebnisse je nach Qualität und Wiedergabetreue der Implementierung variieren. Dieser Vorbehalt ist wichtig. Eine schwache Simulation kann schlechte Gewohnheiten genauso effizient lehren wie eine starke gute.

Der richtige Nachweis ist ein kompakter Korpus an ingenieurtechnischen Belegen, keine Galerie von Interface-Screenshots.

Wenn jemand behauptet, er könne KI-unterstütztes Automatisierungsverhalten validieren, sollte er zeigen können, wie er Korrektheit definiert, Fehler injiziert, Logik überarbeitet und das Ergebnis verifiziert hat. Alles andere ist Präsentation, nicht Ingenieurskunst.

Verwenden Sie diese Struktur:

Geben Sie die Abnahmekriterien in beobachtbaren Begriffen an: Sequenzreihenfolge, Rückmeldezeiten, Alarmschwellen, sicheres Stoppverhalten, Wiederherstellungspfad und Bedingungen für den Zyklusabschluss.

Führen Sie eine realistische abnormale Bedingung ein: verzögertes Zylinderausfahren, defekter Näherungsschalter, verrauschter Sensor, analoge Drift oder fehlender Handshake.

Dokumentieren Sie die Änderung: hinzugefügte Freigabe, Timeout, speichernde Fehler, Wiederholungslimit, Totzone, Filter oder Zustandsbestätigung.

1. Systembeschreibung Beschreiben Sie die Maschine oder Prozesszelle, das Steuerungsziel, den KI-Beitrag und die deterministische SPS-Rolle.
2. Operative Definition von „korrekt“
3. Ladder-Logik und simulierter Anlagenzustand Zeigen Sie die Rung-Logik, die Tag-Struktur und das entsprechende simulierte Maschinenverhalten. Erklären Sie, wie Ausgänge, Rückmeldungen und Zustandsbits zusammenhängen.
4. Der injizierte Fehlerfall
5. Die vorgenommene Überarbeitung
6. Gelernte Lektionen Geben Sie an, was das erste Design falsch angenommen hat und was das überarbeitete Design zuverlässiger beweist.

Diese Struktur lässt sich gut auf die Szenarioarbeit in OLLA Lab übertragen, da die Plattform geführte Builds, explizite E/A-Mappings, Variableninspektion, Analog-/PID-Werkzeuge und szenariobasierte Inbetriebnahmeanmerkungen unterstützt. Noch wichtiger ist, dass sie Beweise liefert, die ein anderer Ingenieur überprüfen kann, ohne raten zu müssen, was mit „funktionierend“ gemeint war.

OLLA Lab hilft Ingenieuren beim Aufbau von karriererelevanter Urteilsfähigkeit bei der Inbetriebnahme, indem es sie Aufgaben proben lässt, die Arbeitgeber an Live-Systemen selten erlauben: Logik validieren, E/A verfolgen, abnormale Bedingungen handhaben und Steuerungsverhalten nach Fehlern überarbeiten.

Das ist eine begrenzte Behauptung, und es ist die richtige.

Die nützlichen Trainingsfunktionen der Plattform für diesen Zweck umfassen:

• Webbasierter Ladder-Logik-Editor zum Erstellen von diskreter, zeit-, zähler-, vergleichs-, mathematik- und PID-gesteuerter Logik
• Simulationsmodus zum sicheren Ausführen und Stoppen von Logik bei gleichzeitigem Umschalten von Eingängen und Beobachten von Ausgängen
• Variablen-Panel zur Überwachung von Tags, Analogwerten, PID-Verhalten und Szenariozustand
• 3D / WebXR-Simulationen zur Verknüpfung von Ladder-Zustand mit sichtbarem Anlagenverhalten
• Digital-Twin-Validierung zur Überprüfung, ob die Sequenz gegen realistische Maschinenmodelle funktioniert
• Szenario-Bibliothek mit Kontexten aus Fertigung, Wasser, HLK, Versorgungsbetrieben, Lagerhaltung, Lebensmittel/Getränke, Chemie und Pharma
• Geführte Build-Anweisungen mit E/A-Mapping, Steuerungsphilosophie, Verriegelungen und Verifizierungsschritten
• KI-Laborassistent (Yaga) für Onboarding und korrigierende Anleitung, begrenzt durch die Notwendigkeit der Benutzerverifizierung
• Zusammenarbeits- und Bewertungs-Workflows für Dozenten-geführte oder teambasierte Überprüfungen

Der entscheidende Unterschied ist, dass OLLA Lab einen Lernenden von der bloßen Syntax-Exposition hin zum Denken im Stil einer Inbetriebnahme führen kann. Es zertifiziert keine Standortkompetenz, ersetzt keine betreute Felderfahrung und verleiht keinen Konformitätsstatus. Es gibt Ingenieuren einen Ort, um genau die Argumentationskette zu üben, die in echten Fabriken teuer ist.

Diese Argumentationskette umfasst:

• Welcher Zustand ist befohlen?
• Welcher Zustand ist nachgewiesen?
• Was muss wahr sein vor einer Bewegung oder einem Übergang?
• Was passiert, wenn der Nachweis nie eintrifft?
• Wie wird der Fehler gemeldet?
• Wie wird die Wiederherstellung gesteuert?

Das sind die Fragen, die zählen, wenn Physical AI das Demo-Video verlässt und sich einer echten Maschine nähert.

Ingenieure sollten KI als eine übergeordnete oder unterstützende Schicht betrachten, die Wahrnehmung, Optimierung und Aufgabenanpassung verbessern kann, während SPS die deterministische Ausführungsschicht bleiben, die für die Sequenzintegrität und die Steuerung des Maschinenzustands verantwortlich ist.

Diese Aufteilung wird sich weiterentwickeln, aber sie wird nicht so bald verschwinden. Fertigungssysteme benötigen nach wie vor explizite Verriegelungen, begrenzte Übergänge und erklärbare Fehlerbehandlung. Wenn überhaupt, erhöht mehr KI den Wert von Ingenieuren, die definieren können, wo Nicht-Determinismus erlaubt ist und wo nicht.

Ein nützliches mentales Modell ist dieses:

• KI entscheidet, was wünschenswert sein könnte
• Steuerungslogik entscheidet, was zulässig ist
• Sicherheitssysteme entscheiden, was erlaubt ist

Wenn diese Schichten vermischt werden, wird die Inbetriebnahme zum Theater. Wenn sie sauber getrennt werden, wird die Integration handhabbar.

Erkunden Sie den breiteren Kontext in unserem Future of Automation Hub.

Lesen Sie: Vendor-Aware Agents: Bridging the Gap Between LLMs and Real PLCs

Lesen Sie: Industry 5.0: Reclaiming Human Dignity in a Dark Factory

Üben Sie die sichere Validierung von KI-Sequenzen in der 3D-Roboterzellen-Simulation in OLLA Lab.

- IEC 61131-3: Programmable controllers — Part 3: Programming languages - IEC 61508 Functional safety standards family - NIST AI Risk Management Framework (AI RMF 1.0) - EU Industry 5.0 policy background - Digital twin overview (NIST)

Das Team von OLLA Lab entwickelt Werkzeuge für die nächste Generation von Automatisierungsingenieuren, die deterministische Steuerung mit moderner KI-Integration verbinden.

Dieser Artikel wurde auf technische Konsistenz mit den Prinzipien der industriellen Automatisierung, der funktionalen Sicherheit und der aktuellen Praxis der virtuellen Inbetriebnahme geprüft.