Der Umstieg von starrem SPS-Code auf modulare Skills verspricht maximale Flexibilität im Bestand. Doch viele Pilotprojekte bleiben im Brownfield stecken. Hier sind die 5 häufigsten Praxisfallen – von versteckten Monolithen bis zur ignorierten Instandhaltung – und wie Sie sie umgehen.
Die Vision ist verlockend: Eine Fertigung, die sich per Software auf neue Produktvarianten anpasst, indem Prozesse auf Edge-Ebene als Skills flexibel neu orchestriert werden. Doch der Weg von der traditionellen Speicherprogrammierbaren Steuerung (SPS) zur Software-definierten Fabrik ist im Brownfield voller Stolpersteine.
In der Praxis scheitern Pilotprojekte selten an der Edge-Hardware oder der Netzwerkanbindung. Es sind klassische Architektur- und Denkfehler an der Schnittstelle zwischen IT und OT, die vielversprechende Ansätze ausbremsen. Wenn Sie vermeiden wollen, dass Ihr Skill-Pilot nach den ersten Testläufen als „teures akademisches Experiment“ abgehakt wird, sollten Sie diese fünf typischen Fehler vermeiden.
1. Der „Fake Skill“: Der alte SPS-Monolith im OPC-UA-Gewand
+-----------------------------------------------------------------------+
| FALSCHER ANSATZ (FAKE SKILL) |
| [ 10.000 Zeilen SPS-Monolith ] <── (OPC UA "Start") ── [ Edge ] |
| ➔ Keine Flexibilität, Re-Validierung weiterhin teuer |
+-----------------------------------------------------------------------+
| RICHTIGER ANSATZ (ATOMARE SKILLS) |
| [ Edge / SMLC ] ───┬──► [ Skill: Pick ] (SPS) |
| ├──► [ Skill: Inspect ] (Kamera) |
| └──► [ Skill: Place ] (SPS) |
| ➔ Echte Modularität, Parameter flexibel anpassbar |
+-----------------------------------------------------------------------+
Der Fehler:
Man nimmt das bestehende, 10.000 Zeilen lange IEC-61131-Programm der Alt-Anlage, setzt eine OPC-UA-Schnittstelle darauf und versieht den gesamten Funktionsbaustein mit einer Start-Methode. Man deklariert die Anlage stolz als „Skill-fähig“.
Die Praxis-Folge:
Sie haben nichts gewonnen außer einer zusätzlichen Protokollschicht. Der SPS-Code bleibt ein undurchsichtiges Geflecht aus globalen Merkern und starren Schrittketten. Wenn sich der Prozess ändert, müssen Sie weiterhin tief in den SPS-Code eingreifen, neu kompilieren und die gesamte Sicherheitskette re-validieren.
So geht es besser:
Brechen Sie den Monolithen konsequent auf. Isolieren Sie echte, atomare Fähigkeiten, z. B. Positionieren, Greifen, Fügen. Die SPS führt nur noch diese Einzelfunktionen aus; die Prozessabfolge wandert als Logik auf die Edge-Ebene.
2. Die Safety-Falle: Versuchte Echtzeit-Steuerung von der Edge
Der Fehler:
Das Projektteam ist begeistert von Python, Docker und modernen Edge-Möglichkeiten und versucht, zeitkritische Regelkreise (
) oder funktionale Sicherheitsfunktionen wie Not-Halt oder Lichtgitter auf die Edge-Plattform auszulagern.
Die Praxis-Folge:
Das Projekt prallt bei der ersten Sicherheitsprüfung mit voller Wucht an der Realität ab. Nicht-deterministische Netzwerk-Latenzen, z. B. Jitter im Millisekundenbereich, führen zu unvorhersehbarem Schwingverhalten von Achsen. Der Sicherheitsbeauftragte verweigert die Abnahme der Zelle – das Projekt steht still.
So geht es besser:
Halten Sie sich an die harte Trennung von Ausführung und Orchestrierung:
- SPS & Feld-Hardware: Ausnahmslos zuständig für harte Echtzeit, Achsregelungen und SIL-/PL-zertifizierte Sicherheitsketten.
- Edge & SMLC: Zuständig für die nicht-zeitkritische Sequenz-Orchestrierung, Parameterübergabe und MES-/ERP-Anbindung.
3. Das Scope-Monster: Der „Big Bang“ an der komplexesten Anlage
Der Fehler:
Um den maximalen Wert der Technologie zu beweisen, wählt das Team für den ersten Pilotversuch die komplexeste, verkettete Haupt-Montagelinie im Werk aus – mit 25 Stationen, heterogenem Steuerungsmix und extrem engen Taktzeitvorgaben.
Die Praxis-Folge:
Die Komplexität erschlägt das Projekt. Jede unvorhergesehene Unterbrechung während der Testphase verursacht sofort spürbaren Produktionsausfall. Der Druck der Werksleitung steigt, die Geduld sinkt und das Projekt wird abgebrochen, bevor die Skill-Architektur ihre Stärken überhaupt ausspielen konnte.
So geht es besser:
Starten Sie mit einer fokussierten, isolierten Zelle, z. B. einer eigenständigen Verpackungs-, Qualitätsprüf- oder Pick-and-Place-Station im Brownfield. Beweisen Sie dort das Zusammenspiel von SPS-Skills, SMLC und ERP-Anbindung im Rahmen eines 90-Tage-Piloten, bevor Sie in die Breite gehen.
4. Der Elfenbeinturm: Die OT-Instandhaltung nicht mitgenommen
+-----------------------------------------------------------------------+
| DIE TYPISCHE GRABENBILDUNG |
| |
| [ IT / Edge-Entwickler ] [ OT-Instandhalter / SPS-Profi ]|
| - Liebt Python, Docker & Git - Schätzt TIA, KOP & Diagnostik|
| - Baut die Edge-Architektur - Steht nachts um 02:00 an der |
| Maschine |
| |
| ➔ Wenn beide nicht gemeinsam entwickeln, scheitert der Pilot! |
+-----------------------------------------------------------------------+
Der Fehler:
Ein reines Software- oder Innovationsteam entwickelt die Skill-Architektur am grünen Tisch. Die klassische OT-Instandhaltung und die SPS-Programmierer vor Ort werden erst am Tag der Inbetriebnahme eingebunden.
Die Praxis-Folge:
Wenn nachts um 02:00 Uhr die Fertigung steht und der Skill-Orchestrierer auf der Edge einen Fehler meldet, kann der Schichtinstandhalter mit seinen gewohnten SPS-Diagnosewerkzeugen nichts anfangen. Die Folge: Akzeptanzverlust, Unmut auf der Hallenfläche und der Ruf nach Rückabwicklung auf den alten Zustand.
So geht es besser:
Binden Sie die Hallenmannschaft ab Tag 1 ein. Ein Skill muss auch über einfache HMI-Statusanzeigen diagnosefähig sein. Wenn der SPS-Programmierer versteht, dass der Skill-Ansatz ihm das lästige Schreiben von variablen Schrittketten abnimmt, wird er vom Gegner zum größten Unterstützer des Projekts.
5. Hardcoded Edge-Skripte: Fehlende Schnittstellen-Semantik
Der Fehler:
Auf der Edge-Ebene werden im Python-Skript des Orchestrierers feste Knotennamen und IP-Adressen hart hinterlegt, z. B. client.get_node("ns=2;s=Device1.Var_104_Start").
Die Praxis-Folge:
Bei jeder kleinen Code-Anpassung auf der SPS oder beim Austausch eines Anlagenteils bricht die Edge-Orchestrierung ab. Von der versprochenen „Plug-and-Produce“-Flexibilität bleibt nichts übrig – stattdessen entsteht eine neue Form von unübersichtlichem „Spaghetti-Code“, nur diesmal auf der Software-Ebene.
So geht es besser:
Arbeiten Sie von Anfang an mit standardisierten Skill-Steckbriefen und semantischen Modellen, z. B. via Verwaltungsschale / AAS oder OPC UA Information Models. Der Orchestrierer darf nicht nach Variablen-Namen suchen, sondern muss universelle Fähigkeiten wie PickAndPlace über definierte Semantik-IDs aufrufen.
Fazit: Die Erfolgsformel für Skill-Piloten
Wer im Brownfield erfolgreich von der SPS zum Skill migrieren möchte, braucht vor allem eines: Pragmatismus und klare Schnittstellen.
- Denken Sie klein beim Scope, aber groß bei der Architektur.
- Kapseln Sie SPS-Code in echte, atomare Skills.
- Lassen Sie Safety und Echtzeit dort, wo sie hingehören: auf der Steuerung.
- Nutzen Sie saubere Skill-Steckbriefe statt Hardcoding.
- Entwickeln Sie gemeinsam mit der Instandhaltung vor Ort.
Wenn Sie diese fünf Regeln beherzigen, wird Ihr Pilotprojekt nicht nur technisch funktionieren, sondern den Grundstein für die nachhaltige Transformation Ihrer Fertigung legen.
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.
