Ein Leitfaden für die schrittweise Entkopplung von Steuerungstechnik und Prozesslogik im Brownfield.
Wer vor der Aufgabe steht, eine bestehende Fertigungsanlage flexibler zu gestalten, stößt im Brownfield schnell an verfahrenstechnische und wirtschaftliche Grenzen. Die Idee, eine gewachsene speicherprogrammierbare Steuerung (SPS) in einem einzigen großen Umstellungsschritt – dem klassischen „Big Bang“ – durch eine moderne, Software-definierte Architektur zu ersetzen, scheitert in der Praxis regelmäßig.
Die Gründe dafür liegen auf der Hand: Unkalkulierbare Stillstandszeiten, der Verlust eingespielter Prozessparameter und der immense Aufwand für die erneute Validierung funktionaler Sicherheitsketten machen einen radikalen Schnitt betriebswirtschaftlich unvertretbar.
Die Lösung liegt in der kontinuierlichen Evolution durch funktionale Kapselung. Anstatt die bestehende Steuerung herauszureißen, wird der bestehende SPS-Code schrittweise neu strukturiert und über standardisierte Schnittstellen als wiederverwendbare Fähigkeit – als Skill – bereitgestellt.
Doch wie sieht dieser Migrationspfad konkret aus? Ausgehend von Kapitel 3 unseres Whitepapers lassen sich vier aufeinander aufbauende Phasen unterscheiden, die Unternehmen als Roadmap für ihren Umbau nutzen können.
Die 4 Phasen der Migration im Überblick
+-----------------------------------------------------------------------+
| PHASE 1: Entkopplung & Transparenz (Read-Only) |
| Auslesen von SPS-Daten ohne Eingriff in die Ablauflogik |
+-----------------------------------------------------------------------+
▼
+-----------------------------------------------------------------------+
| PHASE 2: Kapselung atomarer Funktionen (SPS-Ebene) |
| Strukturierung in eigenständige Funktionsbausteine / Skills |
+-----------------------------------------------------------------------+
▼
+-----------------------------------------------------------------------+
| PHASE 3: Auslagerung der Orchestrierung (Edge-Ebene) |
| Sequenzlogik wandert auf übergeordnete Software-Controller |
+-----------------------------------------------------------------------+
▼
+-----------------------------------------------------------------------+
| PHASE 4: Dynamische Rekonfiguration (Software-defined Factory) |
| Neue Abläufe ohne SPS-Re-Kompilierung flexibel verknüpfen |
+-----------------------------------------------------------------------+
Phase 1: Entkopplung und Transparenz (Read-Only)
Der erste Schritt erfordert keinerlei Änderung am bestehenden Steuerungscode. Ziel dieser Phase ist es, vollständige Transparenz über die Abläufe im Bestandsnetz zu gewinnen. Über lesende Schnittstellen – typischerweise OPC UA oder MQTT Gateways – werden Prozessdaten, Zustandsvariablen und Fehlermeldungen abgegriffen und einer übergeordneten Edge- oder IT-Schicht zur Verfügung gestellt.
Dieser risikofreie Einstieg erlaubt es dem Team, die tatsächliche Taktung und Variablenstruktur der Anlage zu analysieren, ohne in die kritische Ablauflogik einzugreifen.
Phase 2: Kapselung atomarer Funktionen auf der SPS
Sobald die Datenpunkte transparent sind, beginnt die eigentliche Refaktorisierung des SPS-Codes gemäß IEC 61131. Monolithische Schrittketten und global verteilte Merker werden aufgetrennt. Zusammengehörige Funktionen – etwa das Ansteuern eines Hydraulikzylinders, das Schließen eines Greifers oder das Positionieren einer Achse – werden in in sich geschlossene Funktionsbausteine überführt.
Diese Bausteine bilden die atomaren Skills. Sie besitzen definierte Eingangs- und Ausgangsparameter sowie ein standardisiertes Zustandsmodell, z. B. angelehnt an PackML. Auf dieser Stufe wird der Skill zwar noch von der SPS aufgerufen, er ist jedoch nach außen hin isoliert und parametrierbar.
Phase 3: Auslagerung der Ablauf-Orchestrierung auf die Edge-Ebene
In der dritten Phase findet der eigentliche Paradigmenwechsel statt. Die übergeordnete Prozesslogik – also die Frage, in welcher Reihenfolge, unter welchen Bedingungen und mit welchen Parametern die atomaren Skills aufgerufen werden – wandert von der SPS ab.
Ein auf einer Edge-Plattform installierter Controller, z. B. ein Python-basierter Skill Management and Lifecycle Controller (SMLC), übernimmt die Regie. Er ruft die auf der SPS verbliebenen atomaren Skills über OPC UA auf und steuert den Gesamtablauf. Die SPS wird damit vom "Denker" der Prozesskette zum verlässlichen "Ausführer" einzelner Teilaufgaben.
Phase 4: Dynamische Rekonfiguration
In der finalen Ausbaustufe ist die Fertigung vollständig entkoppelt. Neue Produktvarianten, geänderte Prozessreihenfolgen oder alternative Ausweichrouten bei Anlagenausfällen werden rein auf Software-Ebene durch Rekonfiguration der Skills definiert.
Ein Eingriff in den SPS-Code oder eine erneute Re-Kompilierung des Steuerungsprogramms ist für Ablaufänderungen nicht mehr erforderlich.
Die Entscheidungsgrenze: Was bleibt auf der SPS, was wandert ab?
Bei der Umsetzung stellt sich in der Praxis zwangsläufig die Frage, welche Funktionen auf der Steuerung verbleiben müssen und welche ohne Bedenken auf höhere Software-Schichten verlagert werden können.
Die Zuordnung folgt klaren technischen Kriterien:
- Auf der SPS verbleiben: Alle Aufgaben, die harte Echtzeit (
) erfordern, wie etwa schnelle Achsregelungen oder zeitkritische Sensor-Aktor-Kopplungen. Ebenso verbleiben funktionale Sicherheitsfunktionen wie Not-Halt, Lichtgitter und SIL/PL-Schaltkreise ausnahmslos auf der zertifizierten Safety-SPS. - Auf die Edge-Ebene wandern: Übergeordnete Ablauf- und Schrittketten, die Rezepturverwaltung, Datenaggregationen für KI-Analysen, die Anbindung an MES-/ERP-Systeme sowie flexible Störungsbehandlungs- und Ausweichstrategien.
Welcher Pfad passt zu welcher Ausgangslage?
Jede Anlage im Brownfield startet an einem anderen Punkt:
- Hochintegrierte Bestandsanlagen mit unklarem Code: Hier empfiehlt sich ein fokussierter Start in Phase 1 und 2. Der Fokus liegt zunächst auf der sauberen Entkopplung von Einzelmodulen.
- Modular aufgebaute Maschinen mit moderner SPS-Hardware: Wenn OPC UA bereits nativ auf der Steuerung läuft, kann direkt in Phase 2 und 3 eingestiegen werden, um die Orchestrierung schnell auf eine Edge-Ebene auszulagern.
- Anlagen mit häufigen Produkt- und Rezepturwechseln: Hier amortisiert sich die Umstellung auf Phase 3 und 4 am schnellsten, da Rüst- und Umprogrammierzeiten drastisch sinken.
Fazit & Praxishilfe
Die Migration von der klassischen SPS-Architektur zur Skill-basierten Fertigung ist kein unkalkulierbares Wagnis, wenn sie als stufenweiser Prozess verstanden wird. Wer die Grenzen zwischen harter Echtzeit auf Feldebene und flexibler Orchestrierung auf Edge-Ebene sauber zieht, sichert seinen Anlagenbestand und gewinnt gleichzeitig die Anpassungsfähigkeit moderner Softwarearchitekturen.
Möchten Sie Ihren SPS-Code strukturiert analysieren und in Skills überführen?
In Kapitel 3 unseres Whitepapers finden Sie neben der ausführlichen Methodik das praxiserprobte Arbeitsmittel SPS-to-Skill-Migrationscanvas sowie die 90-Tage-Pilot-Checkliste als Schritt-für-Schritt-Anleitung für Ihr eigenes Projekt:
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.
