Ein SPS-Baustein mit OPC UA ist noch kein solider Skill. Damit Steuerungsfunktionen auf Edge-Ebene orchestrierbar werden, müssen sie wie IT-Microservices agieren. Dieses Erklärstück zeigt die 5 Kriterien: Zustandsmodelle, Parametrierung, Fehlerbehandlung, SemVer und Pre-Conditions.
In der Software-definierten Fabrik reicht es nicht aus, bestehende SPS-Funktionsbausteine lediglich mit einer OPC-UA-Schnittstelle zu versehen und als „Skill“ zu deklarieren. Ein schlechter Skill überträgt die Altlasten monolithischer Steuerungsprogramme direkt in die Edge-Ebene: Er bleibt schwer testbar, reagiert empfindlich auf Parameterfehler und bringt bei kleinsten Störungen die übergeordnete Prozesskette zum Stehen.
Ein guter Software-Skill verhält sich wie ein professioneller Microservice in der IT-Welt. Er ist in sich geschlossen, hochgradig reaktiv, klar parametriert und bezüglich seiner Umgebung voll orientiert. Soll eine Steuerungsfunktion für die dynamische Orchestrierung durch einen Skill Management and Lifecycle Controller (SMLC) ertüchtigt sein, muss sie in fünf technischen Kerndimensionen sauber durchentwickelt werden.
1. Determinierte Zustände: Das Standard-Zustandsmodell
Ein robuster Skill verbirgt seine interne Komplexität hinter einem eindeutigen, deterministischen Zustandsautomaten. Der übergeordnete Orchestrierer darf nicht raten müssen, was auf der Steuerungsebene passiert.
In der Praxis haben sich Zustandsmodelle nach PackML (ISA-TR88.00.02) bzw. VDI/VDE 2658 (MTP) etabliert. Ein Skill unterscheidet strikt zwischen drei Arten von Zuständen:
- Transient (Übergang):
Zustände, die automatisch durchlaufen werden, z. B. STARTING, COMPLETING, RESETTING. - Static (Rastzustand):
Zustände, in denen der Skill auf externe Befehle wartet, z. B. IDLE, HELD, COMPLETED. - Executing (Ausführung):
Der eigentliche Kernzustand (EXECUTE), in dem die physische oder logische Arbeit verrichtet wird.
+-----------------------------------+
| IDLE |
+-----------------------------------+
| Command: START(Params) |
▼
+-----------------------------------+
| STARTING |
+-----------------------------------+
| Auto-Transition |
▼
+-----------------------------------+
| EXECUTE |
+-----------------------------------+
+-----------------+-----------------+
| Task Complete | Error / Exception |
▼ ▼
| COMPLETING | | EXECUTION_ERROR |
+------------------------------------+
| Auto-Transition | Handled / Reset |
▼ ▼
+------------------------------------+
| COMPLETED | | HELD |
+------------------------------------+
Qualitätsmerkmal:
Ein guter Skill wechselt niemals unaufgefordert ohne Befehl oder klares Ereignis in den Ausführungszustand und meldet seinen aktuellen Status lückenlos in Echtzeit zurück.
2. Robuste Parametrierung & Validierung
Ein Skill muss vor der Ausführung isoliert geprüft werden können. Die Entkopplung gelingt nur, wenn Eingabeparameter strikt von der Ablauflogik getrennt sind.
Die drei Gebote der Skill-Parametrierung:
- Self-Validation vor Ausführung: Sobald Parameter, z. B. Zielkoordinaten
oder Einpresskraft, in die Schnittstelle geschrieben werden, prüft der Skill im Zustand STARTING deren Plausibilität. Liegen Werte außerhalb der physikalischen Grenzen, lehnt der Skill die Ausführung sofort ab und geht geordnet in den Zustand INVALID_PARAMETERS über – bevor eine Aktorik in Bewegung gesetzt wird. - Typisierung und physikalische Einheiten: Parameter nutzen explizite Datentypen und eindeutige physikalische Einheiten, z. B. SI-Einheiten wie Millimeter mm oder Millisekunden ms.
- Immutabilität während der Ausführung: Ist der Zustand EXECUTE erreicht, werden die Parameter für diesen Durchlauf gesperrt. Eine Änderung von Eingabewerten während des Laufs darf das Verhalten des aktiven Skills nicht unkontrolliert beeinflussen.
3. Differenzierte Fehlerbehandlung
In der klassischen Automatisierung führt ein Sensorfehler meist sofort zum Not-Aus der Zelle. Ein guter Software-Skill hingegen unterscheidet präzise zwischen lokalen Prozessfehlern und kritischen Systemfehlern.
+---------------------------------------------------------------------------------+
| DIAGNOSE- & FEHLERKLASSIFIZIERUNG IN SKILLS |
+-----------------------------------+---------------------------------------------+
| LOKALER PROZESSFEHLER | KRITISCHER SYSTEMFEHLER |
| (z. B. Bauteil nicht gegriffen) | (z. B. Endschalter-Kabelbruch, Safety) |
+-----------------------------------+---------------------------------------------+
| ➔ Skill geht in `HELD` / `FAULTED`| ➔ Geht in `ABORTED` / Safety-Interlock |
| ➔ Meldet strukturierten Code | ➔ Verlangt physischen Reset / Eingriff |
| ➔ Erlaubt automatisierte Retry- | ➔ Stoppt unterlagerte Hardware unverzüglich |
| oder Ausweich-Strategien | |
+-----------------------------------+---------------------------------------------+
Aufbau strukturierter Fehlermeldungen
Der Skill liefert im Fehlerfall nicht bloß ein simples Error-Bit, sondern ein konsistentes Diagnose-Objekt:
JSON
{
"errorCode": 2041,
"errorSeverity": "RECOVERABLE",
"errorSource": "VacuumSensor_02",
"message": "Part pick failed: Vacuum threshold of 0.6 bar not reached within 1500ms."
}
Durch diese Differenzierung kann die übergeordnete Edge-Software (SMLC) intelligent reagieren: Bei RECOVERABLE ruft der SMLC beispielsweise automatisch einen Reinigungs-Skill auf und versucht den Vorgang erneut, anstatt die gesamte Anlage stillzusetzen.
4. Semantic Versioning (SemVer)
Da Skills als Software-Dienste über lange Anlagen-Lebenszyklen hinweg gepflegt, optimiert und aktualisiert werden, ist eine saubere Versionierung Pflicht. Hierbei gilt der Standard Semantic Versioning (MAJOR.MINOR.PATCH):
- MAJOR (z. B. 2.0.0):
Inkompatible Schnittstellenänderungen. Es wurden Parameter entfernt, Datentypen geändert oder das Zustandsverhalten grundlegend umgestaltet. Übergeordnete Skripte müssen angepasst werden. - MINOR (z. B. 1.3.0):
Abwärtskompatible Funktionserweiterungen. Es wurden beispielsweise optionale Parameter hinzugefügt oder zusätzliche Diagnosewerte ergänzt. Bestehende Skripte laufen unverändert weiter. - PATCH (z. B. 1.2.4):
Abwärtskompatible Bugfixes und interne Code-Optimierungen auf der SPS. Die äußere Schnittstelle bleibt zu 100 % identisch.
Praxis-Regel:
Der Orchestrierer (SMLC) prüft bei der Registrierung des Skills die Versionskompatibilität. Ein Aufruf von Version 1.x darf niemals unkontrolliert auf einem Modul mit Version 2.0 ausgeführt werden.
5. Explizite Abhängigkeiten & Pre-Conditions
Ein Skill darf nicht stillschweigend voraussetzen, dass die Umgebung in einem bestimmten Zustand ist. Er muss seine Vorbedingungen und Abhängigkeiten explizit deklarieren und vor dem Start autonom validieren.
Beispiele für Skill-Abhängigkeiten:
- Hardware-Prärequisiten:
Druckluft liegt an (
), Schutztür ist verriegelt, Temperatur liegt im Sollbereich. - Prozess-Prärequisiten:
Das Werkstück befindet sich in der definierten Einlaufposition (überprüft durch Lichtschranke). - Inter-Skill-Abhängigkeiten:
Der Skill ScrewComponent erfordert, dass der Skill HoldComponent der Nachbarachse aktiv im Zustand HELD bzw. EXECUTE steht.
Ein professioneller Skill prüft diese Bedingungen im STARTING-Zustand. Sind sie nicht erfüllt, verweigert er die Ausführung mit einer präzisen Rückmeldung ("Pre-Condition 'PneumaticPressure' failed"), anstatt mitten im Vorgang abzubrechen.
Fazit: Die Checkliste für einen guten Skill
Wer Steuerungsfunktionen für die Software-definierte Fabrik entwickelt, sollte jeden Skill gegen diese fünf Prinzipien prüfen:
Erst wenn diese Faktoren erfüllt sind, wird aus einem simplen SPS-Baustein ein echter, wiederverwendbarer Software-Skill, der die Flexibilität moderner Edge-Architekturen voll ausschöpfen kann.
Skill-basierte Automatisierung
Die Software-definierte Fabrik
Zwischen Echtzeit-Anforderungen, funktionaler Sicherheit und gewachsenen Anlagenstrukturen scheint mehr Flexibilität im Brownfield oft unmöglich. Dieses Whitepaper zeigt, wie skillbasierte Architekturen SPS-Funktionen kapseln, Modernisierung vereinfachen und den Weg zur software-definierten Fabrik ebnen.
