Der fundamentale Unterschied liegt im Einsatzzweck: OPC UA ist ein industrieller Automatisierungsstandard mit semantischem Informationsmodell, der Maschinendaten nicht nur überträgt, sondern auch beschreibt (Einheiten, Hierarchien, Methoden). Es ist optimal für M2M-Kommunikation am Shopfloor und bietet umfassende Sicherheitsmechanismen.

MQTT hingegen ist ein leichtgewichtiges Publish/Subscribe-Transportprotokoll ohne inhärente Datensemantik. Es überträgt effizient beliebige Payloads und skaliert hervorragend für IoT- und Cloud-Szenarien.

Analogie: OPC UA ist wie ein Paketdienst, der weiß, was im Paket ist und wie es behandelt werden muss. MQTT ist wie ein Postbote, der einfach schnell und zuverlässig Briefe zustellt, egal was drin steht.

Ja, theoretisch schon – OPC UA Part 14 (PubSub) definiert ein Publish/Subscribe-Modell, das auch MQTT als Transport unterstützen kann. Damit könnten OPC UA-Nachrichten direkt über MQTT übertragen werden, was die Datensemantik beibehält.

Allerdings gibt es praktische Einschränkungen:

• Geringe Verbreitung: OPC UA PubSub ist noch nicht so weit verbreitet wie klassisches Client/Server OPC UA. Viele SPSen unterstützen es noch nicht nativ.
• Komplexität: Die Konfiguration ist anspruchsvoller als eine einfache Gateway-Lösung.
• Overhead: OPC UA PubSub-Nachrichten sind größer als optimierte JSON-Payloads, was bei großen Datenmengen relevant wird.
• Cloud-Integration: Nicht alle Cloud-Plattformen können OPC UA PubSub nativ verarbeiten – oft braucht man trotzdem einen Adapter.

Fazit: Für Greenfield-Projekte mit modernen Systemen kann OPC UA PubSub interessant sein. Für die meisten KMU mit heterogenen Bestandsanlagen ist die Gateway-basierte Hybrid-Lösung (OPC UA lokal, MQTT zur Cloud) flexibler und pragmatischer.

Für den Einstieg und Pilotprojekte (Budget < 500 €):

• Raspberry Pi 4 (8 GB) mit Hutschienen-Gehäuse + industrielle microSD: Ideal für Prototypen bis 10 Maschinen
• Software: Raspberry Pi OS + Python + Node-RED (alles Open Source)

Für Produktivumgebungen (Budget 500–1500 €):

• OnLogic Helix Serie (fanless Industrie-PC, Intel Celeron/i3, robustes Gehäuse)
• Advantech UNO-2271G: DIN-Rail-Montage, weiter Temperaturbereich (-20 bis 60°C)
• Software: Ubuntu Server + Docker + Portainer (Container-Management)

Für große Installationen mit Vendor-Support (Budget 2000–5000 €):

• Siemens SIMATIC IPC127E mit Industrial Edge Runtime
• Beckhoff CX-Serie mit TwinCAT + OPC UA
• Wago Edge Controller 752-8303/8000-002 mit Docker-Unterstützung

Software-Alternative (ohne eigene Hardware):

• Softing edgeConnector als Software-Gateway auf vorhandenem Industrie-PC
• Kepware ThingWorx Industrial Connectivity: Kommerziell, aber sehr mächtig (über 150 Treiber)

Ja, definitiv – gerade für KMU bietet diese Architektur erhebliche Vorteile:

1. Geringe Einstiegshürde

Ein Raspberry Pi 4 mit Open-Source-Software (ca. 300 € Gesamtinvestition) reicht für erste Pilotprojekte. Kein Vendor-Lock-in, keine Lizenzkosten.

2. Skalierbarkeit ohne Neuentwicklung

Startet man mit 5 Maschinen und will später 50 anbinden, ändert sich die Architektur nicht fundamental – nur mehr Gateways und größerer MQTT-Broker.

3. Pragmatische Sicherheit

Produktionsnetz bleibt isoliert, Gateway als „Puffer“ zur Cloud. Selbst bei Cloud-Kompromittierung ist die Fertigung geschützt.

4. Flexibilität bei Cloud-Wahl

MQTT wird von allen großen Cloud-Anbietern unterstützt. Ein Wechsel von AWS zu Azure erfordert nur Gateway-Rekonfiguration, nicht Neuentwicklung der Shopfloor-Anbindung.

Faustregel: Ab dem Moment, wo Sie mehr als 3 Maschinen cloudbasiert überwachen wollen, lohnt sich der strukturierte Ansatz mit OPC UA + MQTT gegenüber proprietären Einzellösungen.

Die Kombination OPC UA + Edge Gateway + MQTT bietet mehrschichtige Sicherheit (Defense in Depth):

Ebene 1: Shopfloor (OPC UA)

• TLS 1.2/1.3 verschlüsselt alle Verbindungen
• X.509-Zertifikate authentifizieren Clients und Server gegenseitig
• Rollenbasierte Zugriffskontrolle (nur autorisierte Clients dürfen kritische Daten lesen/schreiben)
• Netzwerksegmentierung: Produktionsnetz physisch oder via VLAN vom Unternehmensnetz getrennt

Ebene 2: Edge Gateway (DMZ)

• Gateway steht in isolierter DMZ zwischen Produktion und Internet
• Firewall-Regeln erlauben nur spezifische Ports und Richtungen
• Kein direkter Internet-Zugriff auf Shopfloor-Geräte möglich
• Lokale Datenpufferung verhindert, dass bei Cloud-Ausfall Produktionsdaten verloren gehen

Ebene 3: Cloud-Transport (MQTT)

• TLS-verschlüsselte MQTT-Verbindung (Port 8883)
• Username/Password + optional Client-Zertifikat
• Cloud-Anbieter mit ISO 27001, TISAX oder vergleichbaren Zertifizierungen

Zusätzliche Maßnahmen:

• Regelmäßige Software-Updates des Gateways (automatisiert via unattended-upgrades)
• Monitoring & Intrusion Detection (z.B. Fail2ban)
• Logging aller Zugriffe für Audit-Zwecke (DSGVO-konform)
• Keine personenbezogenen Daten in Maschinendaten (falls doch: Pseudonymisierung am Gateway)

Ergebnis: Diese Architektur erfüllt Anforderungen der IEC 62443 (Industrial Security) und ist DSGVO-konform umsetzbar.

Beispielkalkulation für 10 Maschinen:

Hardware (einmalig):

• Edge Gateway (OnLogic Helix): 1.200 €
• Netzwerk-Hardware (Switch, Kabel): 300 €
• OPC UA Retrofit für 3 ältere Maschinen (Anybus Gateways): 3 × 800 € = 2.400 €
• Summe Hardware: 3.900 €

Software & Lizenzen (jährlich):

• MQTT Broker (HiveMQ Cloud Professional): 1.200 €/Jahr
• Cloud-Speicher & Compute (AWS/Azure, geschätzt): 2.400 €/Jahr
• Optional: Kommerzielle Gateway-Software (z.B. Kepware): 2.500 € (einmalig) + 500 €/Jahr Support
• Summe Software (mit Open Source): 3.600 €/Jahr
• Summe Software (kommerziell): 6.600 €/Jahr (inkl. einmalig 2.500 €)

Engineering & Inbetriebnahme (einmalig):

• Konzeption & Planung: 40 h × 100 €/h = 4.000 €
• Programmierung & Konfiguration: 80 h × 90 €/h = 7.200 €
• Tests & Dokumentation: 20 h × 90 €/h = 1.800 €
• Summe Engineering: 13.000 €

Gesamtinvestition im ersten Jahr:

• Open-Source-Variante: ca. 20.500 €
• Kommerzielle Variante: ca. 26.000 €

ROI-Betrachtung:

Typische Einsparungen durch Predictive Maintenance und OEE-Optimierung: 5–15 % Reduktion ungeplanter Stillstände. Bei 10 Maschinen mit je 50.000 € Ausfallkosten pro Tag Stillstand reicht ein vermiedener Ausfalltag pro Jahr, um die Investition zu rechtfertigen.

Python (empfohlen für die meisten Fälle):

• Vorteile: Einfach zu lernen, riesiges Ökosystem (opcua, paho-mqtt, pandas), schnelle Entwicklung
• Nachteile: Langsamer als kompilierte Sprachen, höherer RAM-Verbrauch
• Für wen: Prototypen, Standardfälle bis 100 Datenpunkte, Teams mit Python-Erfahrung

Node.js/JavaScript:

• Vorteile: Sehr gut mit Node-RED kombinierbar, asynchrone I/O für viele parallele Verbindungen, gute Libraries (node-opcua, mqtt.js)
• Nachteile: Callback-Hell bei komplexer Logik, schwierigeres Debugging
• Für wen: Teams mit Web-Entwicklungs-Background, visuelle Programmierung mit Node-RED gewünscht

Go:

• Vorteile: Sehr performant, geringe Ressourcen, statisch kompiliert (Single Binary), gute Concurrency
• Nachteile: Weniger Libraries als Python/Node.js, steilere Lernkurve
• Für wen: Hochperformante Gateways (1000+ Datenpunkte), Container-Deployments

C/C++:

• Vorteile: Maximale Performance, minimaler Footprint, für embedded Systeme
• Nachteile: Aufwendige Entwicklung, fehleranfällig, lange Entwicklungszeiten
• Für wen: Extreme Performance-Anforderungen, Echtzeit-Constraints, embedded Linux

Fazit: Für 90 % der KMU-Anwendungen ist Python die beste Wahl – schnelle Entwicklung, gute Wartbarkeit, ausreichende Performance.