SPS–Roboter-Handshake: Zustände, Signale und Wiederanlauf richtig definieren

Kurz gesagt: Eine zuverlässige SPS–Roboter-Schnittstelle ist ein vereinbarter Zustandsautomat: Jede Anfrage wird quittiert, jeder Auftrag endet mit „fertig“ oder „Fehler“, jedes Warten hat eine Frist und jeder Neustart klare Bedingungen. Lose aufeinander abgestimmte Bits funktionieren oft nur bis zur ersten Unterbrechung.

Warum lose Signale scheitern

Zwei Steuerungen mit Signalaustausch teilen weder dieselbe Uhr noch denselben Programmzyklus. SPS und Robotersteuerung lesen Eingänge, verarbeiten Logik und schreiben Ausgänge in ihrem jeweiligen Rhythmus; der Feldbus hat zusätzlich sein Aktualisierungsintervall. Ein kurz gesetztes Signal wird möglicherweise übersehen, ein dauerhaft gesetztes mehrfach ausgewertet. Im Normalbetrieb fällt das selten auf, weshalb „Start“ und „Fertig“ für eine Vorführung genügen können. Nach Stopp, Reset oder Verbindungsabbruch fehlt dann die gemeinsame Sicht auf angeforderte und abgeschlossene Arbeit.

Den Vertrag als Zustände beschreiben

Beschreiben Sie Zustände mit Verantwortlichen statt nur eine Variablenliste. Eine beispielhafte Folge lautet bereit, Anfrage, angenommen, beschäftigt, abgeschlossen und Fehler. Diese Namen dienen der Erklärung; sie sind weder Norm noch Signalbelegung eines Herstellers. Für jeden Übergang müssen Auslöser, gültige Bedingungen, zulässige Reaktionszeit und Verhalten bei Zeitüberschreitung feststehen.

Das Grundmuster besteht aus vier Schritten: Die SPS setzt die Anfrage, der Roboter quittiert, die SPS nimmt die Anfrage zurück und der Roboter nimmt die Quittierung zurück. Jeder Zustand bleibt bis zur Antwort bestehen; damit entfällt die Abhängigkeit vom Erkennen eines kurzen Impulses. Zeitvorgaben bleiben nötig: Kommunikationszyklen, Watchdogs, Quittierungsfristen und die Reaktion auf einen nicht fortschreitenden Austausch sind festzulegen.

Alte und doppelte Befehle verhindern

Eine beim Reset anstehende Anfrage kann nach Neustart als neuer Auftrag erscheinen. Verlangen Sie einen definierten Rückweg in den Ruhezustand vor der nächsten Annahme. Das Zurücksenden der Auftrags- oder Rezeptkennung bestätigt die gewünschte Operation, identifiziert aber nicht allein eine konkrete Ausführung: Aufeinanderfolgende Teile können dasselbe Rezept verwenden. Unterstützt die Schnittstelle dies, ergänzen Sie eine Befehlssequenzkennung mit Regeln zu Speicherung, Überlauf, Sitzung und Neustart. Legen Sie fest, wie Duplikate und ein ungewisser Abschluss geklärt werden. Vor Wiederaufnahme der Automatik muss der tatsächliche Anlagen- und Teilezustand feststehen: Greifer belegt oder leer, Vorrichtung beladen oder nicht. Kennungen allein beweisen keine exakt einmal abgeschlossene physische Operation.

Sicherheit von gewöhnlicher Steuerung trennen

Ein Bereitschaftsbit, Heartbeat oder über die Standardschnittstelle übertragener Wert „Zutritt sicher“ bleibt gewöhnliche Steuerungsinformation, unabhängig vom Namen. Schutzstopps, Zugangsschutz und weitere Sicherheitsfunktionen werden auf Grundlage der Risikobeurteilung der vollständigen Anwendung getrennt ausgelegt und validiert — dem Gegenstand von ISO 10218-2:2025. Der Handshake sollte Sicherheitsereignisse trotzdem als Information melden, damit Bedienpersonen Prozessfehler und Schutzstopp unterscheiden und korrekt reagieren können. Manuelle Wiederherstellung ist keine Routinearbeit; OSHA weist auf zahlreiche Roboterunfälle unter nicht routinemäßigen Bedingungen hin.

Unterbrochene Abläufe testen

Prüfen Sie mehr als den Normalzyklus: rasch aufeinanderfolgende Anfragen, Kommunikationsunterbrechung, Neustart jeder Steuerung während eines Auftrags, fehlende Greiferrückmeldung und kontrollierte manuelle Wiederherstellung. Zeitgestempelte Ereignisse beider Steuerungen helfen, die Reihenfolge nachzuvollziehen. Für die Zustandsbegriffe bietet PackML, von OMAC entwickelt und von ISA als ISA-TR88.00.02 übernommen, ein veröffentlichtes Maschinenzustandsmodell. Es beschreibt Maschinenzustände, nicht die Signalbelegung eines Roboters.

Checkliste vor Budget- oder Auftragsfreigabe

• Von beiden Programmierern vereinbarte Signalverantwortung und Zustandsübergänge.
• Frist und definierte Reaktion für jeden Wartezustand.
• Regeln für alte und doppelte Anfragen sowie eine geeignete Auftragsidentifizierung.
• Wiederanlauf nach Neustart einer oder beider Steuerungen.
• Getrennt bewertete und validierte Sicherheitsfunktionen.
• FAT-Nachweis der unterbrochenen Fälle einschließlich Alarmen und Bedienhandlungen.

Was dieser Leitfaden nicht nachweist

Die Planungshilfe definiert keine Standardsignalliste, behandelt kein konkretes SPS- oder Robotermodell und berichtet keine Tests. Das Ausgangsverhalten bei Stopp, Busausfall und Neustart ist produktspezifisch und muss aus Herstellerunterlagen entnommen werden. Risikobeurteilung und Validierung der Sicherheitsfunktionen am tatsächlichen System durch qualifizierte Personen bleiben erforderlich.

Quellen und weitere Prüfung

• ISO 10218-2:2025 — Sicherheitsanforderungen für industrielle Roboteranwendungen und Zellen (Katalogseite; 2025-02; ursprüngliche Prüfung 2026-10-11).
• OMAC — PackML (Übersicht zur Entwicklung durch OMAC und Übernahme als ISA-TR88.00.02; undatiert; ursprüngliche Prüfung 2026-10-12).
• OSHA — Robotik (Übersicht zu Unfällen unter nicht routinemäßigen Betriebsbedingungen; undatiert; ursprüngliche Prüfung 2026-10-12).

Der nächste sinnvolle Schritt

Erstellen Sie Zustandsdiagramm und Signaltabelle vor dem ersten Programmcode. Die Seite Robotik und Automation ist der Einstieg in eine Prüfung von Machbarkeit und Zuständigkeiten. Projekte werden über Eurobots/ReBots abgegrenzt; eine schlüsselfertige Komplettinstallation wird nicht vorausgesetzt. Das AYXWORKS-Portfolio beschreibt den technischen Hintergrund.