Die Produktionsinsel _PHUKET zeigt, wie Software-definierte Fertigung in der Praxis gelingt: Ein Python-SMLC, Asset Administration Shells und OPC UA entkoppeln die OT-Zelle flexibel. Dieser technische Walkthrough zeigt Skill-Architektur und ERP-Anbindung an Proalpha im Detail.
Die Produktionsinsel _PHUKET der Technologie-Initiative SmartFactory-KL e.V. verkörpert die praktische Umsetzung der Open SmartFactory Architecture. Während klassische Automatisierungskonzepte auf starren Pyramidensystemen (ISA-95) basieren, bricht _PHUKET diese Hierarchie zugunsten einer entkoppelten, modularisierten und serviceorientierten Architektur auf.
+-----------------------------------------------------------------------------------+
| BUSINESS-IT / ERP |
| (z. B. Proalpha Integration WB) |
+-----------------------------------------------------------------------------------+
▲ REST / OpenAPI / JSON
▼ (Aufträge / MDE-Rückmeldungen)
+-----------------------------------------------------------------------------------+
| ORCHESTRIERUNGS- & AGENTENEBENE |
| SMLC (Skill Management & Lifecycle Controller in Python) |
| Verwaltungsschale (AAS Repository / REST API) |
+-----------------------------------------------------------------------------------+
▲ OPC UA PubSub / Client-Server
▼ (Skill-Commands & State Tracking)
+-----------------------------------------------------------------------------------+
| EDGE- & PROTOKOLL-ADAPTION |
| Interface Apps / Container (Containerized Protocol Converters) |
+-----------------------------------------------------------------------------------+
▲ Proprietäre Feldbusse / APIs
▼ (Kuka/Yaskawa Robot-APIs, S7-TCP, MODBUS)
+-----------------------------------------------------------------------------------+
| AKTORIK & SENSORIK (OT) |
| Robotik, Sensor-Hubs, E/A-Module, Antriebs-Frequenzumrichter |
+-----------------------------------------------------------------------------------+
Kernprinzipien der _PHUKET-Architektur:
- Kapselung von Funktionalität in Skills:
Physikalische Befehle (z. B. „Bewege Achse X zu Position Y“) werden in semantische Fähigkeiten übersetzt (z. B. PickAndPlace oder JoinComponent). - Herstellerneutrale Semantik über Asset Administration Shells (AAS):
Jedes physische Asset (Roboter, Kamera, Greifer) und jedes logische Modul ist als Digitaler Zwilling nach den Spezifikationen der Industrial Digital Twin Association (IDTA) beschrieben. - Echtzeit-OT und entkoppelte IT-Logik:
Die SPS garantiert zeitkritische Reaktionszeiten (
), während der übergeordnete Python-SMLC die dynamische Ablaufsteuerung ohne Determinismus-Verlust übernimmt. - End-to-End-Integration in die Business-IT:
Die Insel agiert nicht als isolierte Datensenke, sondern meldet Prozess- und Materialdaten direkt an ERP-Systeme wie Proalpha zurück.
Der Skill Management and Lifecycle Controller (SMLC) in Python
Der SMLC fungiert als exekutive Steuerungsinstanz auf Edge- bzw. Zellenebene. Auf der Produktionsinsel _PHUKET ist dieser Controller als modularer Python-Service implementiert. Python bietet den Vorteil einer nahtlosen Einbindung von Bibliotheken für Datenverarbeitung, OPC UA (Asyncio-basiert) und Anbindungen an REST-Schnittstellen.
Zustandsmodell des SMLC (nach Namur NE 148 / VDI/VDE 2658 & PackML)
Um eine einheitliche Interaktion zwischen SMLC und den ausführenden Modulen zu gewährleisten, folgt jeder Skill einem definierten Zustandsautomaten:
+-------------------------------------------------------+
| IDLE |
+-------------------------------------------------------+
| Start(Parameters)
▼
+-------------------------------------------------------+
| STARTING |
+-------------------------------------------------------+
| Auto-Transition |
▼
+-------------------------------------------------------+
| EXECUTE |
+-------------------------------------------------------+
| Task Complete |
▼
+-------------------------------------------------------+
| COMPLETING |
+-------------------------------------------------------+
| Auto-Transition |
▼
+-------------------------------------------------------+
| COMPLETED |
+-------------------------------------------------------+
Python-Referenzimplementierung (SMLC Skill Controller Core)
Python
import asyncio
from enum import Enum
from typing import Dict, Any, Optional
from asyncua import Client, Node, ua
class SkillState(Enum):
IDLE = "IDLE"
STARTING = "STARTING"
EXECUTE = "EXECUTE"
COMPLETING = "COMPLETING"
COMPLETED = "COMPLETED"
FAULTED = "FAULTED"
class SMLCSkillController:
"""
Skill Management & Lifecycle Controller (SMLC) Node
Orchestriert OPC UA-basierte Skills auf der Produktionsinsel _PHUKET.
"""
def __init__(self, opc_ua_endpoint: str, skill_node_id: str):
self.endpoint = opc_ua_endpoint
self.skill_node_id = skill_node_id
self.client: Optional[Client] = None
self.current_state: SkillState = SkillState.IDLE
async def connect(self):
self.client = Client(url=self.endpoint)
await self.client.connect()
print(f"[SMLC] Verbunden mit OPC UA Server: {self.endpoint}")
async def execute_skill(self, parameters: Dict[str, Any]) -> bool:
"""
Führt einen parametrisierten Skill über die OPC UA-Methodenschnittstelle aus.
"""
if not self.client:
raise ConnectionError("[SMLC] Keine Verbindung zum OPC UA Server.")
try:
# 1. State Verification
self.current_state = SkillState.STARTING
print(f"[SMLC] Starte Skill {self.skill_node_id} mit Parametern: {parameters}")
# 2. Parameter in OPC UA Nodes schreiben
for param_key, param_val in parameters.items():
param_node = self.client.get_node(f"ns=2;s={self.skill_node_id}.Parameters.{param_key}")
data_type = await param_node.read_data_type_as_variant_type()
await param_node.write_value(ua.DataValue(ua.Variant(param_val, data_type)))
# 3. Exec-Methode aufrufen
method_node = self.client.get_node(f"ns=2;s={self.skill_node_id}.Start")
object_node = self.client.get_node(f"ns=2;s={self.skill_node_id}")
result = await object_node.call_method(method_node)
# 4. Monitor Loop
self.current_state = SkillState.EXECUTE
success = await self._wait_for_completion()
if success:
self.current_state = SkillState.COMPLETED
return True
else:
self.current_state = SkillState.FAULTED
return False
except Exception as e:
print(f"[SMLC Error] Fehler bei Skill-Ausfuehrung: {str(e)}")
self.current_state = SkillState.FAULTED
return False
async def _wait_for_completion(self, timeout_sec: float = 30.0) -> bool:
state_node = self.client.get_node(f"ns=2;s={self.skill_node_id}.State")
start_time = asyncio.get_event_loop().time()
while (asyncio.get_event_loop().time() - start_time) < timeout_sec:
val = await state_node.read_value()
if val == "COMPLETED":
return True
elif val in ["FAULTED", "ABORTED"]:
return False
await asyncio.sleep(0.1)
return False
Verwaltungsschale & OPC UA als semantisches Rückgrat
Ein wesentliches Element von _PHUKET ist die durchgehende Semantik. Ein OPC-UA-Knoten liefert zwar Datenpunkte, erklärt jedoch nicht ohne Weiteres den konzeptionellen Kontext. Die Asset Administration Shell (AAS) schließt diese Lücke.
+-----------------------------------------------------------------------------------+
| VERWALTUNGSSCHALE (AAS) - Submodel: OperationalSkills |
+-----------------------------------------------------------------------------------+
| SubmodelElementCollection: PickAndPlaceSkill |
| ├── SemanticId: https://smartfactory.de/sd/skills/PickAndPlace/1/0 |
| ├── Property: TargetPositionX (Float) |
| ├── Property: TargetPositionY (Float) |
| └── EndpointReference: opc.tcp://192.168.10.50:4840/ns=2;s=RoboSkill01 |
+-----------------------------------------------------------------------------------+
▼ Mapping
+-----------------------------------------------------------------------------------+
| OPC UA SERVER (Informationsmodell) |
+-----------------------------------------------------------------------------------+
| ObjectsFolder/Modules/RobotArm |
| ├── NodeId: ns=2;s=RoboSkill01 (MethodNode) |
| ├── NodeId: ns=2;s=RoboSkill01.State (VariableNode, String) |
| └── NodeId: ns=2;s=RoboSkill01.Parameters.TargetX (VariableNode, Double) |
+-----------------------------------------------------------------------------------+
Registrierung & Dynamic Lookup im SMLC
Wenn ein neues Modul an _PHUKET angedockt wird (Plug-and-Produce):
- Das Modul stellt seine AAS im Netzwerk über eine AAS-Registry bereit.
- Der SMLC liest das Submodel TechnicalData und OperationalSkills aus.
- Der SMLC extrahiert die EndpointReference der OPC UA-Schnittstelle sowie die Zuordnung der Methoden-IDs zu den universellen Semantik-IDs.
- Der Skill steht dem Gesamtsystem dynamisch zur Verfügung, ohne dass der Quellcode des SMLC geändert werden muss.
Interface Apps für proprietäre & Legacy-Schnittstellen
Nicht jedes Werkzeug in der Praxis verfügt nativ über eine OPC-UA-Schnittstelle oder unterstützt Verwaltungsschalen-Konzepte. Auf _PHUKET werden bestehende Legacy-Geräte (z. B. RS-232-Messuhren, serielle Greifer oder ältere Roboter-Controller wie KUKA KRC2 / Yaskawa DX100) über containerisierte Interface Apps eingebunden.
+-----------------------------------------------------------------------------------+
| SMLC / AAS REPOSITORY |
+-----------------------------------------------------------------------------------+
▲ Standardisierte API
│ (OPC UA Server / REST Interface) │
+-----------------------------------------------------------------------------------+
| INTERFACE APP (Docker Container) |
| | Standard-Schnittstelle | | Protocol Adaption Engine | |
| | (AsyncUA / REST Server) | ◄----► | (Bytes parsing, CRC, Handshake) | |
+-----------------------------------------------------------------------------------+
▲ Proprietaerer Bus
│ (TCP Raw / Serial / Socket / Modbus RTU) │
+-----------------------------------------------------------------------------------+
| PROPRIETÄRES OT-ASSET (Legacy) |
+-----------------------------------------------------------------------------------+
Aufgaben der Interface App:
- Protokoll-Translation:
Übersetzung proprietärer Byte-Streams (z. B. Modbus RTU über RS-485 oder TCP-Sockets) in standardisierte OPC UA Information Models. - Latenz-Entkopplung:
Pufferung hochfrequenter Sensorsignale (
), Aggregation von Messwerten und Bereitstellung strukturierter Zustandsobjekte an den SMLC. - Kapselung der Herstellerspezifika:
Austausch der Hardware ohne Anpassung der übergeordneten Software-Schicht (die Interface App ändert sich, das OPC-UA-Informationsmodell bleibt identisch).
ERP/MES-Integration: Der Referenzfall Proalpha im Mittelstand
In der industriellen Praxis endet die Automatisierung nicht an der Zelle. Das fertigungsnahe ERP-System Proalpha ist im deutschsprachigen Mittelstand weit verbreitet. Die Anbindung der Zelle an Proalpha stellt sicher, dass Produktionsaufträge automatisiert abgearbeitet und Materialverbräuche sowie Fertigungsrückmeldungen (BDE/MDE) ohne manuelle Zwischenschritte verbucht werden.
Der Datenfluss: Vom Proalpha-Auftrag zur Skill-Ausführung
[Proalpha ERP] ──(1. Production Order: JSON/REST) ──► [Integration Workbench (INWB)]
(2. REST Trigger / MQTT)
▼
│ [Modul-Zelle _PHUKET] ◄──(4. Execute Skill)─── [SMLC Orchestrator] │
│ (3. Status Monitoring & Data Aggregation) │
│ ▼ │
│ [Sensors / OT] ───(5. Process Data)───► [AAS / Edge Store] ──────┘
(6. BDE/MDE Feedback)
▼
[Proalpha INWB / ERP REST]
Ablaufschritte der Integration:
- Auftrags-Push:
Proalpha stellt einen Fertigungsauftrag bereit (Produktvariante, Stückzahl, Parameter) über die Proalpha Integration Workbench (INWB) per REST API oder MQTT. - Translation & Zerlegung:
Der SMLC nimmt den JSON-Auftrag entgegen und löst die benötigte Skill-Kette auf: - Ausführung & In-Situ-Überwachung:
Der SMLC führt die Skills auf _PHUKET aus und erfasst Prozessparameter (z. B. Einpresskraft, Schraubdrehmoment, Prüfbild-Score). - BDE/MDE-Rückmeldung:
Nach erfolgreicher Beendigung sendet der SMLC ein strukturiertes JSON-Rückmelde-Telegramm an die Proalpha INWB:- Gutmenge / Ausschlussmenge
- Verbrauchte Chargen/Materialien (Tr Rückverfolgbarkeit)
- Prozesszeiten (Start, Ende, Störungsausfallzeiten)
Integration-Matrix: Die 4 Edge-Plattformen im Proalpha-Szenario
Wenn die Produktionsinsel _PHUKET oder eine vergleichbare Zelle in der Praxis umgesetzt wird, stellt sich die Frage nach der passenden Edge-Hardware- und Software-Plattform.
Wie lassen sich Siemens Industrial Edge, ctrlX AUTOMATION, PLCnext Technology und WAGO Open Automation in ein solches Proalpha-Szenario einbinden?
+------------------------------------------------------------------------------------------------------------------+
| VERGLEICHSMATRIX: PROALPHA-ANBINDUNG AUF EDGE-PLATTFORMEN |
+--------------------+-----------------------------+-----------------------------+---------------------------------+
| PLATTFORM | INTEGRATIONS-MUSTER | EMPFOHLENE INTEGRATION-LAYER| TECH-STACK ON BOARD |
+--------------------+-----------------------------+-----------------------------+---------------------------------+
| Siemens Ind. Edge | Centralized Gateway / | Industrial Edge App + | S7 Connector, MQTT App, Node-RED,
|
| Rest-API Adapter | Proalpha INWB Connector | Docker-Engine |
+-----------------------+-----------------------------+-----------------------------+------------------------------+
| ctrlX AUTOMATION | Microservice App Architecture| ctrlX Data Layer + | Python / Go Apps, REST API Client, |
| (Native Containerized) | Custom Integration App | ctrlX Data Layer REST-Broker |
+-----------------------+-----------------------------+-----------------------------+------------------------------+
| PLCnext Technology | Open Linux Hybrid | PLCnext Runtime + | C++ / Python Engine, eAtmosphere, |
| (IEC 61131 + High-Level) | Docker-Container INWB Bridge| REST Data Client |
+-----------------------+-----------------------------+-----------------------------+------------------------------+
| WAGO Open Automation | Lean Edge Container System | Docker Engine + | Node-RED, Mosquitto MQTT, |
| (Minimal Overhead) | Python REST Service | Dockerized Interface Services |
+-----------------------+-----------------------------+-----------------------------+------------------------------+
1. Siemens Industrial Edge im Proalpha-Szenario
- Architektur-Pattern:
Einbindung über vorstrukturierte Edge Apps. Der Siemens S7-Connector liest OT-Daten aus der S7-1500; eine benutzerdefinierte Docker-Edge-App nimmt die Daten via Databus (MQTT) auf und kommuniziert per HTTPS/REST mit der Proalpha Integration Workbench. - Vorteil:
Hohe Datensicherheit und zentrales Flottenmanagement über das Siemens Industrial Edge Management (IEM). - Nachteil:
Größerer Overhead beim Bau eigener Entwicklungs-Container im Vergleich zu reinen Linux-Umgebungen.
2. ctrlX AUTOMATION im Proalpha-Szenario
- Architektur-Pattern:
Direkte Nutzung des ctrlX Data Layer. Eine Python- oder Go-basierten App lauscht auf Ereignisse im Data Layer (z. B. Skill-Zustandswechsel) und setzt diese unmittelbar in REST-Calls an die Proalpha API um. - Vorteil:
Extrem geringe Latenz und saubere Trennung. Der SMLC kann als eigene ctrlX App nativ neben der SPS-Laufzeit ausgeführt werden. - Nachteil:
Entwickler müssen das App-Packaging nach ctrlX-Standards beherrschen.
3. PLCnext Technology im Proalpha-Szenario
- Architektur-Pattern:
Hybride Ausführung. Die zeitkritische OT-Steuerung verbleibt in der PLCnext-Runtime, während der Python-SMLC und der Proalpha-REST-Adapter direkt im parallelen Linux-Umfeld (in Docker oder als native Linux-Dienste) laufen. - Vorteil:
Direkter Zugriff auf den gemeinsamen System-Speicher (ESM). Sehr einfache Übertragung von C++/Python-Code aus Forschungsprojekten wie _PHUKET auf die Industriehardware. - Nachteil:
Konfigurationsmanagement bei großen Flotten erfordert zusätzliche IT-Werkzeuge.
4. WAGO Open Automation im Proalpha-Szenario
- Architektur-Pattern:
Schlanke Container-Infrastruktur. Ein Node-RED- oder Python-Docker-Container auf dem WAGO Edge Controller übernimmt sowohl die Modbus-/OPC-UA-Kommunikation zur Zelle als auch die Transformation und den Datenaustausch mit Proalpha. - Vorteil:
Maximale Kosten-Effizienz, keine wiederkehrenden Plattform-Lizenzgebühren, hohe Entwicklungsfreiheit. - Nachteil:
Sicherheitskonzepte und Patch-Prozesse für die Anbindung an die Proalpha INWB müssen vom Betreiber eigenständig aufgesetzt werden.
Fazit: Die Zelle _PHUKET als Blaupause für die Praxis
Der technische Walkthrough der Produktionsinsel _PHUKET zeigt: Software-definierte Produktion ist kein Zukunftskonzept mehr, sondern funktionierende industrielle Praxis.
Durch das Zusammenspiel aus Python-basiertem SMLC, semantischer Beschreibung via Verwaltungsschale (AAS), OPC-UA-Kommunikation und einer durchgängigen ERP-Anbindung an Systeme wie Proalpha entstehen Fertigungszellen, die maximale Flexibilität mit hoher Prozessstabilität verbinden.
SmartFactory-KL Production Level 4 Demonstrator
Dieses Video veranschaulicht praxisnah die grundlegenden Konzepte modularer, flexibler Produktionsstrukturen und die Verknüpfung von OT und IT im Rahmen der SmartFactory-KL Modellfabrik.
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.
