Das Recovery-Dilemma
Szenario: Roboterzelle fällt aus. Fehler. Ein Service-Techniker wird gerufen. Er kommt um 10 Uhr, beginnt zu debuggen, findet nach einer Stunde den Grund, behebt ihn, versucht einen Restart — aber die Zelle startet nicht "sauber" wieder.
Warum? Weil die Zelle während des Fehlers in einem "Halb-Zustand" sitzengeblieben ist. Vielleicht war eine Sequenz nicht abgeräumt, vielleicht sind Outputs nicht zurückgesetzt, vielleicht wartet ein Mechanismus noch auf einen Sensor, der kommen wird ... oder nicht.
Das ist teuer: Große Fabrik, komplette Schicht hindurch kein Output. Bei einer strukturierten Recovery-Strategie würde der Bediener vor Ort in 10 Minuten wieder fahren.
Ein klares Recovery-Modell
Die Zelle braucht Recovery-Pfade aus jedem Fehler-Zustand für jede Sequenz.
Typ 1: Automatische Recovery
Manche Fehler beheben sich selbst. Sensorausfall? Versuche es in 5 Sekunden nochmal. Wenn der Sensor dann aktiv ist: weiter. Wenn nicht: zur nächsten Recovery-Ebene.
Typ 2: Bedienen-Driven Recovery
Der Bediener handelt (z.B. "Material laden") und triggert eine Retry. Das HMI zeigt genau, was zu tun ist.
Typ 3: Restart-Recovery
"Diese Sequenz ist zu beschädigt. Räum auf, und starten Sie von vorne." Das setzt Output-Pins zurück, wartet auf Sensoren, bringt alles in einen sauberen Zustand.
Typ 4: Escallation
Wenn automatisch und Manual-Recovery nicht funktionieren: Service ist nötig. Das HMI zeigt eine klare Fehlermeldung mit Kontakt zum Support.
Im Code: State Machine mit Recovery-Pfaden
Jede Sequenz ist eine State Machine (Zustandsautomat).
Zustand: "Teil greifen"
├─ Running
│ ├─ Sensor erkannt? → Weiter
│ └─ Timeout nach 10s? → Error
├─ Error
│ ├─ Automatische Retry? → Running
│ ├─ Bediener: "Nochmal versuchen"? → Running
│ └─ Bediener: "Skip"? → Nächste Sequenz
└─ Success → Nächste Sequenz
Das ist bekomplex als ein großer "wenn das, dann jenes"-Block. Aber es ist wartbar.
Best Practice: Recovery-Matrice
Dokumentiere klar: Für jede Sequenz und jeden möglichen Fehler X gibt es eine Recovery-Strategie Y.
| Sequenz | Fehler | Recovery |
|---|---|---|
| Teil greifen | Sensor-Timeout | Retry 3x, dann Bediener-Action |
| Teil greifen | Greifer blockiert | HMI: "Greifer freigeben, dann weiter" |
| Schweißen | Stromquelle Fehler | Auto-Reset, Retry |
HMI-Design für Recovery
Das HMI ist der Schlüssel zwischen Fehler und Recovery.
- Klare Fehlermeldung: Nicht "Error 0x1234", sondern "Sicherheitstür ist offen. Bitte schließen und OK klicken."
- Empfohlene Action: "Würde Sie bitte das Material überprüfen und 'Retry' klicken?"
- Manuelle Befehle: Buttons für "Retry", "Skip", "Reset" je nach Kontext.
- Service-Info: Für Fehler, die Bediener nicht beheben können: Support-Kontakt und Fehler-Code.
Logging: Die Spur zurück zum Fehler
Structured recovery ist nur möglich, wenn du Fehlerspur hast.
- Was passierte vor dem Fehler?
- Welcher Zustand war aktiv?
- Welche Sensoren/Outputs waren im welchen Status?
- Was war die genaue Recovery-Aktion?
Mit gutem Logging kann Support-Teams später ein Video des Fehlers "sehen", auch wenn sie physisch nicht vor Ort sind.
Simulation & Testing
Best Practice: Simuliere Recovery vor der echten Inbetriebnahme.
"Was, wenn der Greifer jetzt blockiert?" — Du setzt das Input-Flag auf FALSE in der Simulation, schaust, wie die Zelle reagiert. Braucht Recovery noch Tuning? Jetzt ist Zeit dafür, nicht beim Kunden.
Fazit
Recovery ist nicht "Notfall-Management" — es ist Normal-Mode-Design.
Jede Sequenz sollte clear, documented Recovery-Pfade haben. Das HMI sollte präzise, actionable Fehlermeldungen zeigen. Mit dieser Mentalität sinkt MTTR (Mean Time To Recovery) dramatisch — von Stunden auf Minuten.