Das klassische Problem
Szenario: Eine Roboterzelle fällt aus. Es gibt einen Fehler. Der Service-Techniker vor Ort versucht, wieder hochzufahren. Aber ist der Roboter sicher? Ist die Peripherie ready? Hat er die richtigen Komponenten kalibriert?
Ohne explizite Bedingungen entsteht Unsicherheit. Manche fahren an, obwohl die Sicherheitstore offen sind. Andere warten auf den Anrufer-im-Büro, weil unklar ist, ob die Zelle startup-ready ist.
Das kostet Stunden — für jedes Ereignis.
Die Lösung: Explizite Bedingungen
Modelliere Sicherheit und Betriebsbereitschaft als explizite, überprüfbare Bedingungen — nicht als versteckte Prüfungen im Code.
Das C# Framework strukturiert das in zwei Kategorien:
Safety-Conditions
Diese sind nicht-negotiable. Die Zelle läuft NICHT ohne sie:
- Sicherheitstore geschlossen
- Notfall-Stop nicht betätigt
- Schutzvorrichtungen installiert
- Keine Person im Gefährdungsbereich
RunConditions
Dies sind „betriebliche" Bedingungen — kann die Zelle sinnvoll starten und arbeiten?
- Material ist verfügbar
- Greifer ist installiert und kalibriert
- Stromversorgung stabil
- Netzwerk-Verbindung zur IT besteht
- Vorige Sequenz ist aufgeräumt
Ein praktisches Beispiel: Schweißzelle
Safety-Conditions zum Starten von "Schweißen":
- Sicherheitstore geschlossen? ✓
- Notfall-Stopp nicht aktiviert? ✓
- Hochspannungs-Schaltschrank verschlossen? ✓
- Schutzgas-Schlauch angebunden? ✓
RunConditions zum Starten von "Schweißen":
- Schweißdraht vorhanden? ✓
- Stromquelle läuft im korrekten Modus? ✓
- Gasdurchfluss OK? ✓
- Zelle ist aus "Idle"-Status, nicht aus "Error"? ✓
Wenn ALL diese erfüllt sind: Grünes Licht, Schweißen kann starten. Wenn auch nur eine nicht erfüllt: Klare Meldung, welche Bedingung fehlt.
Der Ansatz: Conditions als Datenmodell
Beste Practice ist, Conditions als strukturiertes Modell zu speichern — nicht als Magic-Strings:
class SafetyCondition {
Id: "DOOR_CLOSED"
Display: "Sicherheitstür geschlossen"
Status: true / false
LastChecked: DateTime
RecomendedFix: "Bitte Sicherheitstür schließen"
}
Damit kannst du:
- Alle Conditions abfragen und anzeigen (HMI: "Warum kann ich nicht starten?")
- Historisch tracken, wann/warum Starts blockiert wurden
- Automatisch Wartungs-Alerts generieren ("Tür wird zu häufig geöffnet")
Zustandslogik: Deterministische Recovery
Ein großer Vorteil von expliziten Conditions: Recovery wird vorhersehbar.
Szenario: Zelle ist in Error. Service-Techniker vor Ort will recovering versuchen.
Mit expliziten Conditions kann er eingeben: "Roboter manuel hoch, alles checken, Fehler bereinigt."
Das System prüft dann sofort: Ist die Fehler-Ursache weg? Sind alle Safety-Conditions erfüllt? JA → Zelle geht in Ready. NEIN → Fehlermeldung mit dem fehlenden Punkt.
Ohne Conditions: "Versuch es, vielleicht geht's." → Lange Debugging-Session.
Mit Conditions: "Diese drei Dinge müssen erfüllt sein." → Klare Handlung.
Simulation & Testing
Ein weiterer Vorteil: Mit expliziten Conditions kann man virtuell testen.
"Was passiert, wenn der Greifer nicht kalibriert ist?" — Du setzt die Condition auf FALSE und siehst, wie die Zelle reagiert. Du kannst neue Fehlerszenarien durchspielen, bevor real etwas schiefgeht.
Best Practice: Hiearchische Conditions
Bei großen Zellen kann es viele Conditions geben. Eine Hierarchie hilft:
- Zellen-Level: Energie, Safety-Schränke, allgemeine Sicherheit
- Roboter-Level: Roboter-Power, Notfall-Stop, Kalibration
- Sequenz-Level: Für Schweißen: Stromquelle, Draht, Schutzgas
Das HMI zeigt dann hierarchisch: "Zelle ready? Roboter ready? Schweißsequenz ready?" Der Bediener navigiert schnell zu dem Punkt, der nicht erfüllt ist.
Fazit
Explizite Safety- und RunConditions sind ein Designmuster, nicht nur eine Checkliste.
Sie führen zu:
- Schnellerer Recovery nach Fehlern
- Höherer Sicherheit ohne "Workarounds"
- Besserer Diagnose (jede Bedingung ist dokumentiert)
- Automatisierter Testing-Möglichkeiten
Investiere Zeit in ein klares Conditions-Modell — es zahlt sich schnell aus.