PLC-zu-Roboter-Handshake: Standardisierung von Interlock-Protokollen

Um einen PLC-zu-Roboter-Handshake zu standardisieren, müssen Ingenieure deterministische boolesche Austauschsignale für Bereitschaft, Bewegungsfreigaben, Fehler-Reset und Positionsbestätigung definieren. Ziel ist es, ein Fortschreiten der Sequenz bei mehrdeutigen oder transienten Zuständen zu verhindern. In der Praxis reduzieren standardisierte Interlocks das Kollisionsrisiko, indem sie PLC und Robotersteuerung dazu zwingen, sich vor der Fortsetzung einer Bewegung abzustimmen.

Ein häufiges Missverständnis ist, dass es beim Roboter-Handshake hauptsächlich darum geht, Bits korrekt zuzuordnen. Das ist nicht der Fall. Die schwierigere Aufgabe besteht darin, zwei Steuerungen trotz unterschiedlicher Zykluszeiten, Netzwerk-Timings und transienter Feedback-Verluste auf Zustandsübergänge zu synchronisieren. Ein zugeordnetes Bit ist nicht zwangsläufig ein valides Bit.

In einer Untersuchung von Ampergon Vallis an 500 simulierten Roboterzellen in OLLA Lab betrafen 68 % der anfänglichen Kollisionsfehler asynchrone `In_Position`- oder Zonenfreigabe-Signale, die für weniger als 50 ms ausfielen. Methodik: n=500 simulierte Pick-and-Place- und Transferzellen-Validierungsläufe, Baseline-Vergleich = initiale Benutzerlogik vor Entprellung oder Härtung der Zustandslogik, Zeitfenster = 1. Januar 2026 bis 15. März 2026. Diese Metrik stützt lediglich einen Punkt: kurzzeitige Feedback-Instabilität ist ein häufiger Fehler-Modus bei der ersten Inbetriebnahme. Sie erhebt keinen Anspruch auf eine branchenweite Kollisionsrate.

Schlechte Handshakes führen meist auf unspektakuläre Weise zum Versagen. Eine Spannvorrichtung schließt zu früh, ein Förderband taktet, bevor der Roboter den Bereich verlassen hat, oder ein Greifer fährt in eine Zone, die die PLC als leer angenommen hat. Die Physik lässt sich selten von optimistischem Timing beeindrucken.

Die wesentlichen Signale bei einem PLC-zu-Roboter-Handshake sind Bereitschaft, Sicherheitsfreigaben, Bestätigung des Bewegungszustands, Fehlermanagement und Sequenz-Ausführungsbits. Wenn diese Signale nicht explizit definiert und in ein klares Sequenzmodell eingebunden sind, ist der Handshake nicht standardisiert; er ist lediglich verbunden.

Zentrale Handshake-Signale

Bestätigt, dass die Voraussetzungen auf PLC-Seite für eine Bewegung erfüllt sind. Typische Bedingungen sind ein intakter Sicherheitskreis, geschlossene Schutztüren (wo erforderlich), rückgesetzter Not-Halt, kein aktiver Zellenfehler und ein zulässiger Betriebsmodus.

• `PLC_System_Ready`

Bestätigt, dass die Robotersteuerung für den Automatikbetrieb bereit ist. Dies kann beinhalten: Steuerung fehlerfrei, kein aktiver Programmfehler, kein Schutzzustand und ein mit der Zellensequenz abgestimmter Betriebsmodus.

• `Robot_System_Ready`

Befehl der PLC zur Freigabe der Servo- oder Antriebsleistung, sofern die Architektur diese Befugnis der PLC zuweist.

• `PLC_Request_Motors_On`

Feedback des Roboters, das bestätigt, dass die Antriebsleistung tatsächlich eingeschaltet ist. Befehl und Feedback sind nicht dasselbe. Anlagen lernen dies oft zu ungünstigen Zeiten auf die harte Tour.

• `Robot_Motors_On`

Eine bewusste Reset-Anforderung, die nur ausgegeben wird, wenn die Reset-Bedingungen gültig sind.

• `PLC_Fault_Reset_Request`

Feedback, das anzeigt, dass sich der Roboter nicht mehr im Fehlerzustand befindet.

• `Robot_Fault_Clear`

Eine Positions-erreicht- oder Zonen-frei-Anzeige, die bestätigt, dass eine programmierte Bewegung oder eine sichere Freigabebedingung tatsächlich eingetreten ist.

• `Robot_In_Position`

Ein abgeleitetes oder direktes Signal, das bestätigt, dass sich der Roboter außerhalb einer geschützten Interferenzzone befindet, bevor ein anderer Aktor sich bewegt.

• `Zone_Clear`

Sequenz-Trigger, der nur ausgegeben wird, wenn alle erforderlichen Freigaben und Zustandsbestätigungen wahr sind.

• `PLC_Cycle_Start`

Feedback, dass der Roboter die befohlene Aufgabe abgeschlossen oder den erwarteten Sequenz-Checkpoint erreicht hat.

• `Robot_Cycle_Complete`

Operative Definition eines standardisierten Handshakes

Ein standardisierter PLC-zu-Roboter-Handshake ist ein deterministischer, bidirektionaler Austausch boolescher Zustände mit definierter Zuständigkeit, gültigen Übergängen, Timeout-Verhalten und Fehlerreaktion. Die Standardisierung ist weniger für die Eleganz als für die Wiederholbarkeit wichtig: Jedes Bit muss vier Fragen klar beantworten:

1. Wer ist der Eigentümer?
2. Wann darf es einschalten?
3. Wann muss es ausschalten?
4. Was tut die Sequenz, wenn es nie ankommt, zu spät kommt oder flackert?

Fehlen diese Antworten, ist die Schnittstelle undokumentierter Optimismus.

Kontext der Normen

Relevante Normen und Richtlinien sind:

• ISO 10218-1 / ISO 10218-2 für Sicherheitsanforderungen an Roboter und Robotersysteme
• RIA TR R15.406 für Schutzmaßnahmen in Roboterzellen
• IEC 61508 als umfassender Rahmen für funktionale Sicherheit elektrischer/elektronischer/programmierbarer Systeme

Diese Normen liefern keine universelle Bit-Liste für jede Zelle. Sie erfordern jedoch einen disziplinierten Umgang mit Sicherheitsfunktionen, Betriebsarten und Risikominimierung.

Race-Conditions verursachen Kollisionen, wenn die PLC ihre Sequenzlogik auf Basis eines transienten oder veralteten Zustands vorantreibt, den die Robotersteuerung nicht stabil aufrechterhalten hat. Der Mechanismus ist simpel: Die PLC sieht eine Freigabe für ein oder zwei Zyklen als wahr an, löst eine nachgelagerte Aktion aus, während der Roboter den angenommenen Zustand bereits verlassen hat oder nie vollständig erreicht hat.

Warum PLC- und Roboter-Timing voneinander abweichen

Eine PLC und eine Robotersteuerung werten Zustände nicht notwendigerweise im gleichen Takt aus.

• Ein PLC-Task kann alle 2-10 ms ausgeführt werden
• Roboter-E/A-Updates können in einem anderen Intervall aktualisiert werden
• Der Netzwerktransport fügt Jitter hinzu
• Motion-Blending kann ein Positionsbit kurzzeitig entwerten
• HMI- oder übergeordnete Logik kann Sequenzbefehle asynchron schreiben

Diese Diskrepanz reicht aus, um ein falsches Gefühl von Sicherheit zu erzeugen. Sequenzfehler liegen oft in der Lücke zwischen „einmal wahr“ und „lange genug wahr, um vertrauenswürdig zu sein“.

Häufige Muster von Race-Conditions

#### 1. Transienter Verlust von `In_Position` während des Blending

Ein Roboter erreicht einen Zielbereich, setzt `In_Position`, verliert es aber kurzzeitig während des Trajektorien-Blendings oder Zonenübergangs. Die PLC sieht das Bit lange genug, um eine Klemme zu lösen, ein Förderband zu takten oder ein Tor zu öffnen. Der Roboter kann sich physisch noch innerhalb der Interferenzhülle befinden.

#### 2. Verwechslung von Befehl und Feedback

Die PLC aktiviert `Motors_On_Request` und behandelt den Roboter sofort als bewegungsfähig, ohne das verifizierte `Robot_Motors_On`-Feedback abzuwarten. Das ist Befehlslogik, die vorgibt, Gerätestatuslogik zu sein.

#### 3. Doppelspulen- oder Phantom-Bit-Verhalten

Derselbe Sequenzzustand wird von mehr als einem Netzwerk, Task oder Steuerungspfad geschrieben. Das Ergebnis ist ein Bit, das in Trend-Snapshots gültig erscheint, aber nicht deterministisch zugewiesen ist.

#### 4. Timer-Substitution als Nachweis

Ein Programmierer fügt eine feste Verzögerung ein, anstatt auf eine positive Bestätigung wie `Zone_Clear` oder `Robot_In_Position_Stable` zu warten. Timer sind nützlich für Entprellung und Timeout-Überwachung. Sie sind kein Beweis dafür, dass eine Bewegung sicher abgeschlossen wurde.

Warum standardisierte Logik dieses Risiko reduziert

Standardisierte Logik reduziert Race-Conditions, indem sie das Fortschreiten der Sequenz von einem verifizierten Zustand abhängig macht, nicht von einer angenommenen Zeitdauer. Der Unterschied ist kompakt und wichtig: Zeit ist kein Beweis; Feedback ist ein Beweis.

Hier sollte auch definiert werden, was „Simulation-Ready“ bedeutet. Ein Simulation-Ready-Ingenieur ist nicht jemand, der Ladder-Syntax auswendig zeichnen kann. Es ist jemand, der Steuerungslogik vor Erreichen der realen Maschine gegen realistisches Prozessverhalten beweisen, beobachten, diagnostizieren und härten kann.

Um einen sicheren Interlock zu programmieren, verwenden Sie eine serielle Verifizierung von Bereitschaft, fehlerfreiem Zustand und stabilem Feedback, bevor der nächste Sequenzbefehl verriegelt wird. Das Ziel ist nicht, dass das Netzwerk ordentlich aussieht. Das Ziel ist, vorzeitige Bewegungen zu erschweren.

### Beispiel: `PLC_Cycle_Start` Interlock-Struktur

Unten ist ein Ladder-Beispiel in Textform, das ein begrenztes Muster zeigt. Die Tag-Benennung variiert je nach Plattform; das Logikprinzip nicht.

|----[XIC PLC_System_Ready]----[XIC Robot_Fault_Clear]----[XIC Robot_Motors_On]----[XIC Zone_Clear]----[TON T4:0 50ms]----| | | |----[XIC T4:0.DN]------------------------------------------------------------------------------------------------[OTE PLC_Cycle_Start]----|

Was dieses Netzwerk tut

• `PLC_System_Ready` verifiziert, dass die Zelle laufen darf.
• `Robot_Fault_Clear` verhindert das Fortschreiten der Sequenz in einen bekannten abnormalen Zustand.
• `Robot_Motors_On` bestätigt, dass der Roboter tatsächlich mit Leistung versorgt wird.
• `Zone_Clear` bestätigt, dass der Roboter physisch außerhalb des Interferenzbereichs ist.
• `TON` Entprellung erfordert, dass die Freigabekette für eine minimale stabile Zeitdauer wahr bleibt, bevor `PLC_Cycle_Start` ausgegeben wird.

Warum der Entprell-Timer wichtig ist

Ein Entprell-Timer filtert kurzzeitige Signalinstabilitäten, verursacht durch:

• Netzwerk-Jitter,
• Übergänge im Bewegungszustand,
• verrauschte abgeleitete Zonenlogik,
• Sensor-Flattern,
• kurze Einbrüche des Steuerungszustands während Programmübergängen.

Richtig eingesetzt, validiert ein Entprell-Timer die Signalstabilität. Faul eingesetzt, wird ein Timer zum Aberglauben mit Millisekunden-Anhang.

Empfohlene Programmierregeln

#### Definieren Sie die Zuständigkeit explizit

Jedes Handshake-Bit sollte eine autoritative Quelle haben. Wenn `Robot_In_Position` an drei Stellen synthetisiert werden kann, ist es kein Signal; es ist ein Argument.

#### Trennen Sie Befehlsbits von Feedbackbits

Verwenden Sie `Request_Motors_On` nicht als Beweis dafür, dass die Motoren eingeschaltet sind. Halten Sie Befehle und Nachweise getrennt.

#### Fügen Sie Timeout-Überwachung hinzu

Jedes erwartete Feedback sollte einen Timeout-Pfad haben:

• Befehl ausgegeben,
• Feedback erwartet,
• Timeout überschritten,
• Fehler verriegelt,
• Wiederherstellungspfad definiert.

Eine Sequenz ohne Timeout-Verhalten ist nicht robust. Sie ist nur geduldig, bis sie versagt.

#### Verriegeln Sie Sequenzzustände, keine momentanen Hoffnungen

Verwenden Sie explizite Zustandslogik oder Sequenzer-Schritte, damit der Fortschritt von validierten Übergängen abhängt. Dies ist besonders wichtig, wenn sich Roboterbewegungen und Hilfsaktoren denselben Arbeitsbereich teilen.

#### Entwerfen Sie die Fehlerreaktion, bevor der „Happy Path“ fertig ist

Wenn `In_Position` mitten im Zyklus abfällt, definieren Sie, ob die Zelle:

• pausiert,
• zurückfährt,
• einen Fehler ausgibt und Bedienereingriffe erfordert,
• oder zu einem bekannten sicheren Schritt zurückkehrt.

Die Maschine wird diese Frage irgendwann stellen. Es ist besser, sie vor der Inbetriebnahme zu beantworten.

OLLA Lab simuliert asynchrone Timing-Fehler, indem Ingenieure Ladder-Logik gegen einen digitalen Zwilling testen können, während sie E/A-Zustandsänderungen, Sequenzverhalten und Fehlerreaktionen in einer risikofreien Umgebung beobachten. Das macht es nützlich für Proben und Validierung, nicht als Ersatz für formale Standortabnahmen oder Sicherheitszertifizierungen.

Operative Definition der Digital-Twin-Validierung in diesem Kontext

In diesem Artikel bedeutet Digital-Twin-Validierung, zu testen, ob die Ladder-Logik das beabsichtigte Maschinenverhalten gegen ein realistisches virtuelles Gerätemodell unter normalen und abnormalen Bedingungen erzeugt. Beobachtbare Verhaltensweisen umfassen:

• Umschalten diskreter Eingänge und Verifizierung der Ausgangsreaktion,
• Überwachung von Tag-Zustandsübergängen in der Sequenz,
• Injizieren von transientem Feedback-Verlust,
• Überprüfung, ob Interlocks unsichere Bewegungen blockieren,
• Vergleich des Ladder-Zustands mit dem simulierten Gerätezustand,
• Überarbeitung der Logik nach einem Fehler und erneutes Testen.

Wie der Workflow in OLLA Lab aussieht

Mit OLLA Lab kann ein Ingenieur:

• die Handshake-Logik im webbasierten Ladder-Editor erstellen,
• das Programm im Simulationsmodus ausführen,
• Tags, E/A und Analogwerte im Variablen-Panel inspizieren,
• das Verhalten der Roboterzelle oder Maschine in der 3D/WebXR-Simulation beobachten,
• abnormale Bedingungen wie ein wegfallendes `Robot_In_Position`-Signal injizieren,
• bestätigen, ob die Sequenz wie geplant anhält, einen Fehler ausgibt oder sich erholt.

Hier wird OLLA Lab operativ nützlich. Es gibt Ingenieuren einen Ort, um genau die Art von Fehlern zu proben, die zu teuer, zu unsicher oder zu störend sind, um sie an echter Hardware zu üben.

Eine konkrete Validierungsübung

Ein praktischer Handshake-Test in OLLA Lab könnte so aussehen:

1. Erstellen Sie eine Pick-and-Place-Sequenz mit `PLC_System_Ready`, `Robot_Motors_On`, `Zone_Clear` und `PLC_Cycle_Start`.
2. Lassen Sie die Zelle normal laufen und bestätigen Sie, dass der Roboter die Zone räumt, bevor das Förderband taktet.
3. Injizieren Sie einen kurzen Abfall von `Robot_In_Position` oder `Zone_Clear` mitten im Zyklus.
4. Beobachten Sie, ob die Entprelllogik den transienten Fehler korrekt filtert.
5. Erhöhen Sie die Fehlerdauer und verifizieren Sie, dass die PLC das Fortschreiten der Sequenz anhält und einen Fehler verriegelt.
6. Überarbeiten Sie die Netzwerk- oder Zustandslogik und führen Sie denselben Test erneut aus.

Diese Schleife – bauen, beobachten, Fehler injizieren, überarbeiten, erneut testen – ist der eigentliche Trainingswert. Syntax allein lehrt kein Urteilsvermögen bei der Inbetriebnahme.

Was OLLA Lab beweisen sollte und was nicht

OLLA Lab kann Ingenieuren helfen, Sequenzlogik, E/A-Verhalten und Fehlerbehandlung vor der Bereitstellung zu validieren. Es kann die Probe von Inbetriebnahmetätigkeiten wie Interlock-Verifizierung und Tests abnormaler Zustände unterstützen.

OLLA Lab beweist für sich allein nicht:

• die Korrektheit der Feldverdrahtung,
• die endgültige Leistung der Sicherheitsfunktion,
• das Erreichen von SIL-Leveln,
• die Compliance-Abnahme,
• oder die Standortkompetenz unter anlagenspezifischen Einschränkungen.

Ein Simulator ist ein disziplinierter Probenraum. Er ist kein Verzicht auf Normen.

Der PLC-zu-Roboter-Handshake sollte von formalen Sicherheitsnormen, einer dokumentierten Steuerungsphilosophie und einem deterministischen Zustandsdesign geleitet werden. Die Normen bilden den Sicherheitsrahmen; das Sequenzdesign bestimmt, ob sich die Zelle innerhalb dieses Rahmens kohärent verhält.

Normen und Richtlinien zur Verankerung der Arbeit

Definieren Sicherheitsanforderungen für Industrieroboter und Robotersysteme, einschließlich der Integrationsverantwortlichkeiten.

• ISO 10218-1 / ISO 10218-2

Bietet praktische Schutzrichtlinien für Roboteranwendungen und Zelldesign.

• RIA TR R15.406

Rahmt die breitere Disziplin der funktionalen Sicherheit für programmierbare Systeme ein.

• IEC 61508

Definieren steuerungsspezifische Signalsemantik, Bewegungszustandsbits und Sicherheits-E/A-Verhalten.

• Handbücher der Roboterhersteller

Ingenieurspraktiken, die wichtiger sind als Slogans

#### Schreiben Sie eine Schnittstellenmatrix

Dokumentieren Sie jedes Handshake-Bit mit:

• Quelle,
• Ziel,
• Normalzustand,
• Bedeutung bei Aktivierung,
• Reset-Verhalten,
• Timeout-Erwartung,
• Fehlerkonsequenz.

#### Definieren Sie „korrektes“ Verhalten vor dem Testen

Beginnen Sie keine Simulation oder FAT-artige Validierung ohne eine operative Definition des Erfolgs. „Roboter läuft“ ist keine Definition. „Förderband taktet erst, nachdem `Zone_Clear` für 50 ms kontinuierlich wahr ist und kein aktiver Roboterfehler vorliegt“ ist eine Definition.

#### Behandeln Sie abnormale Zustände als Anforderungen erster Klasse

Testen Sie:

• fehlerhaften Roboter bei Zyklusstart,
• Motoren aus während der Sequenz,
• veraltetes `Cycle_Complete`,
• weggefallenes `In_Position`,
• Reset-Versuch unter ungültigen Bedingungen.

#### Halten Sie Sicherheits- und Sequenzlogik getrennt

Sicherheitsrelevante Funktionen müssen gemäß der anwendbaren Architektur und Normen entworfen und validiert werden. Standard-Sequenzbits sind kein Ersatz für Sicherheitsfunktionen. Das sorglose Vermischen dieser Rollen führt dazu, dass Dokumentation zur Fiktion wird.

Ingenieure sollten Handshake-Kompetenz mit einem kompakten Korpus an technischen Nachweisen demonstrieren, die Sequenzabsicht, Fehlerbehandlung und Revisionsdisziplin zeigen. Eine Screenshot-Galerie reicht nicht aus. Jeder kann grüne Bits sammeln.

Verwenden Sie diese Struktur:

1) Systembeschreibung

Geben Sie den Zweck der Zelle und die Schnittstellen klar an.

Beispiel: „Zwei-Achsen-Förderband-Transferzelle mit einem Knickarmroboter für Pick-and-Place zwischen Einlauf und Nest. PLC steuert Förderband, Klemme und Sequenzzustand. Roboter liefert Motors-on, Fault-clear, In-position und Cycle-complete Feedback.“

2) Operative Definition von „korrekt“

Definieren Sie, was korrekt in beobachtbarem Verhalten bedeutet.

Beispiel: „`PLC_Cycle_Start` darf nur einschalten, wenn Sicherheitsfreigaben gesund sind, Robotermotoren an sind und `Zone_Clear` kontinuierlich für 50 ms wahr ist. Förderbandbewegung wird gehemmt, während der Roboter sich in der Transferzone befindet.“

3) Ladder-Logik und simulierter Gerätezustand

Zeigen Sie die Netzwerk- oder Zustandslogik zusammen mit der simulierten Maschinenreaktion.

Beinhaltet:

• Ladder-Ausschnitt,
• Tag-Liste,
• Sequenzmatrix,
• 3D- oder Simulationszustandsnachweis, der zeigt, dass der Roboter die Zone geräumt hat, wenn das Förderband startet.

4) Der injizierte Fehlerfall

Führen Sie bewusst eine abnormale Bedingung ein.

Beispiel: „Injizierter 30 ms Abfall bei `Robot_In_Position` während der gemischten Ausfahrbewegung.“

5) Die vorgenommene Revision

Erklären Sie die Logikänderung und warum sie notwendig war.

Beispiel: „50 ms Entprellung bei `Zone_Clear` hinzugefügt, Befehls- und Feedback-Tags getrennt und einen Sequenz-Haltezustand bei Timeout verriegelt.“

6) Gelernte Lektionen

Stellen Sie die technische Schlussfolgerung klar dar.

Beispiel: „Die ursprüngliche Logik behandelte den transienten Positionsnachweis als stabile Freigabe. Die überarbeitete Logik erforderte eine anhaltende Bestätigung und verhinderte vorzeitige Förderbandbewegungen.“

Diese Art von Artefakt ist nützlich, weil sie logisches Denken demonstriert, nicht nur Vertrautheit mit dem Werkzeug.

Ein standardisierter Handshake ist besser, weil er das Verhalten über Zellen, Teams und Fehlerzustände hinweg vorhersehbar macht. Ad-hoc-Logik mag während einer Demo funktionieren und dennoch bei Drift, Latenz, Wartungsänderungen oder Wiederherstellungsszenarien versagen.

Praktische Vorteile der Standardisierung

Jeder weiß, was jedes Bit bedeutet und wann es gültig ist.

• Reduzierte Mehrdeutigkeit bei der Inbetriebnahme

Klare Zuständigkeiten und Timeout-Logik machen Fehler nachvollziehbar.

• Schnellere Fehlerisolierung

Bewegung hängt von Beweisen ab, nicht von Annahmen.

• Sichereres Sequenzverhalten

Standardvorlagen reduzieren Neuerfindungen, ohne das technische Urteilsvermögen einzufrieren.

• Bessere Wiederverwendbarkeit über Projekte hinweg

Ein dokumentierter Handshake ist in einem digitalen Zwilling oder einer Simulationsumgebung einfacher systematisch zu testen.

• Verbesserter Simulations- und FAT-Workflow

Der Punkt ist nicht bürokratische Ordentlichkeit. Der Punkt ist, dass wiederholbare Schnittstellen weniger mysteriös versagen.

- OPC UA Spezifikationsportal - ISO 10218 Roboter und Robotik-Geräte Normenseite - IEC 61508 Übersicht funktionale Sicherheit - Virtual commissioning and digital twin review (Journal of Manufacturing Systems) - NIST Smart Manufacturing Testbed Ressourcen