Ein Revolution Pi MQTT-Gateway bietet den vertrauten Raspberry-Pi-Software-Stack in einem Hutschienengehäuse für den Schaltschrank – mit 24-V-Versorgung, industriellen I/O-Modulen und einem längeren Produktlebenszyklus. Dieser Artikel zeigt, wo industrielle Pi-basierte Steuerungen sinnvoll sind, wie Sie Feldsignale eines Revolution Pi in Python lesen und an MQTT publizieren und was sich ändert, wenn aus einem Prototyp ein produktives Gateway wird. Dieselben Muster gelten für andere industrielle Geräte auf Basis des Compute Module 4 und Compute Module 5.
Warum ein industrieller Raspberry Pi
Ein Standard-Raspberry-Pi ist hervorragend für Prototypen, doch der Schaltschrank ist eine andere Umgebung: 24 V DC, elektrische Störungen, große Temperaturbereiche, Vibrationen und Instandhaltungspersonal, das Hutschienenmontage und Schraubklemmen erwartet. Industrielle Steuerungen auf Basis des Raspberry Pi Compute Module lösen diese Probleme und behalten dabei Raspberry Pi OS (oder ein eng verwandtes Derivat), Python, Node-RED und das übrige Ökosystem bei, das Sie bereits kennen.
Die Revolution-Pi-Familie von KUNBUS ist das bekannteste Beispiel. Ein Basismodul wie der RevPi Connect enthält das Compute Module, Ethernet-Ports und die Spannungsaufbereitung. Erweiterungsmodule für digitale I/O, analoge I/O und Feldbus-Gateways werden seitlich angesteckt und kommunizieren über einen Rückwandbus-Steckverbinder mit dem Basismodul. Andere Hersteller bauen CM4- und CM5-basierte Steuerungen mit eigener I/O; der Integrationsansatz aus diesem Artikel lässt sich mit einer anderen I/O-Bibliothek übertragen.
| Anforderung | Standard-Pi | Industrielle Pi-basierte Steuerung |
|---|---|---|
| Versorgung | 5 V USB-C | 24 V DC, oft mit weitem Eingangsbereich |
| Montage | Gehäuse oder Hutschienenadapter | Native Hutschiene |
| I/O | 3,3-V-GPIO | 24-V-Digitalein-/-ausgänge, 0–10 V und 4–20 mA analog |
| Speicher | SD-Karte | eMMC auf dem Compute Module |
| Umgebung | Büro | Temperatur- und EMV-Werte für den Schaltschrank |
| Lebenszyklus | Consumer-Rhythmus | Langzeitverfügbarkeit als Designziel |
Typische Architektur
In den meisten Installationen ersetzt der industrielle Pi nicht die SPS, die die Maschine steuert. Er sitzt als Edge-Gateway daneben:
- Feldsignale erreichen die Steuerung direkt über I/O-Module (ein Türkontakt, ein Durchflussmesser-Impuls, ein 4–20-mA-Druckmessumformer) oder indirekt über Modbus TCP, Modbus RTU oder ein anderes Protokoll von der vorhandenen SPS.
- Die Gateway-Anwendung tastet Werte ab, skaliert sie, wendet Totbänder an, erkennt Zustandswechsel und versieht alles mit Zeitstempeln.
- MQTT transportiert die Daten ausgehend zu einem Broker in der Cloud oder im Werksnetz, wo Dashboards, Historians und Alarmierungswerkzeuge sie abonnieren.
- Optionale Befehle gelangen über MQTT zurück zu Ausgängen – aber nur für nicht sicherheitsrelevante Funktionen und mit expliziter Validierung.
Diese Aufteilung ist wichtig. Die SPS hält die Steuerung deterministisch und sicherheitsgerichtet, während das Gateway Konnektivität und Datenmodellierung übernimmt – genau die Dinge, die eine SPS oft schlecht kann. Stammen Ihre Signale aus einer SPS statt aus direkter I/O, zeigt der Leitfaden Raspberry Pi Modbus MQTT die Abfrageseite im Detail.
RevPi-I/O in Python lesen
Der Revolution Pi stellt alle Modulwerte über ein Prozessabbild bereit, das der piControl-Treiber verwaltet. Sie konfigurieren die Module im Web-Tool PiCtory, vergeben für jede I/O einen Namen und lesen bzw. schreiben diese Namen anschließend aus jeder beliebigen Sprache. Der Befehl piTest ist der schnellste Plausibilitätstest:
piTest -d # erkannte Module auflisten
piTest -r I_1 # Eingang I_1 lesen
piTest -w O_1,1 # Ausgang O_1 setzen
In Python bildet die Bibliothek revpimodio2 das Prozessabbild auf Objekte ab, die nach Ihrer PiCtory-Konfiguration benannt sind. Sie unterstützt sowohl zyklisches Polling als auch Event-Callbacks, was gut zu MQTT passt: Eingänge ändern sich selten, und Publizieren bei Änderung hält den Datenverkehr gering.
import json
import os
import time
import paho.mqtt.client as mqtt
import revpimodio2
BROKER = os.getenv("MQTT_HOST", "broker.connectmq.com")
PORT = int(os.getenv("MQTT_PORT", "1883"))
USERNAME = os.getenv("MQTT_USERNAME")
PASSWORD = os.getenv("MQTT_PASSWORD")
CLIENT_ID = os.getenv("MQTT_CLIENT_ID", "revpi-gw-r2d7k1")
PREFIX = os.getenv("TOPIC_PREFIX", "connectmq/demo/r2d7k1/plant1/packaging/line2/revpi1")
DIGITAL_INPUTS = ["I_1", "I_2", "I_3"] # Namen aus PiCtory
ANALOG_INPUTS = {"InputValue_1": 0.001} # Name -> Skalierungsfaktor (z. B. mV zu V)
client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=CLIENT_ID)
if USERNAME:
client.username_pw_set(USERNAME, PASSWORD)
if PORT == 8883:
client.tls_set()
client.will_set(f"{PREFIX}/status", "offline", qos=1, retain=True)
client.reconnect_delay_set(1, 60)
def on_connect(client, userdata, flags, reason_code, properties):
client.publish(f"{PREFIX}/status", "online", qos=1, retain=True)
client.subscribe(f"{PREFIX}/cmd/O_1", qos=1)
def on_message(client, userdata, msg):
value = msg.payload.decode().strip().lower()
if value in ("1", "true", "on"):
rpi.io.O_1.value = True
elif value in ("0", "false", "off"):
rpi.io.O_1.value = False
client.on_connect = on_connect
client.on_message = on_message
client.connect_async(BROKER, PORT, keepalive=30)
client.loop_start()
rpi = revpimodio2.RevPiModIO(autorefresh=True)
rpi.handlesignalend(rpi.cleanup)
def publish_digital(ioname, iovalue):
payload = {"value": bool(iovalue), "ts": round(time.time(), 3)}
client.publish(f"{PREFIX}/di/{ioname}", json.dumps(payload), qos=1, retain=True)
for name in DIGITAL_INPUTS:
rpi.io[name].reg_event(publish_digital)
publish_digital(name, rpi.io[name].value) # Anfangszustand
rpi.mainloop(blocking=False)
while not rpi.exitsignal.wait(5):
analog = {n: round(rpi.io[n].value * f, 3) for n, f in ANALOG_INPUTS.items()}
client.publish(f"{PREFIX}/ai", json.dumps({**analog, "ts": int(time.time())}), qos=1)
client.publish(f"{PREFIX}/status", "offline", qos=1, retain=True)
client.loop_stop()
client.disconnect()
Digitaleingänge werden bei jeder Änderung sofort und als Retained Message publiziert, sodass ein Subscriber immer den aktuellen Zustand kennt. Analogwerte werden alle fünf Sekunden abgetastet. Der Befehls-Handler akzeptiert nur explizite Werte für einen benannten Ausgang und ignoriert alles andere. Beachten Sie, dass das Befehls-Abonnement per Konvention ein nicht gespeichertes (non-retained) Topic nutzt: Läge ein gespeicherter „on“-Befehl auf dem Broker, würde der Ausgang bei jedem Neustart des Gateways schalten.
Topic-Design für Werksdaten
Industrielle Gateways profitieren von einer Topic-Hierarchie, die das Werk abbildet: Unternehmen, Standort, Bereich, Linie, Zelle oder Maschine. Diese ISA-95-Struktur ist das Rückgrat eines Unified Namespace (UNS): Die ISA-95-Ebenen (Enterprise → Site → Area → Line → Cell) werden direkt zur Topic-Struktur des UNS auf dem MQTT-Broker, etwa acme/werk-stuttgart/verpackung/linie-2/revpi1. Das macht Abonnements natürlich (plant1/packaging/# für alles in einem Bereich). ConnectMQ erkennt Topics im ISA-95-Stil und zeigt verbundene Geräte im Portal nach diesen Ebenen an, was die Navigation durch eine große Gateway-Flotte erleichtert. Der Leitfaden MQTT Sparkplug B und Unified Namespace erklärt, wann sich Sparkplug B zusätzlich zu einfachem JSON lohnt.
Ein paar Regeln halten den Namespace über Jahre nutzbar:
- Den Anlagenpfad ins Topic und die Messwerte in den Payload legen, nicht umgekehrt.
- Stabile Signalnamen aus PiCtory oder einer Zuordnungstabelle verwenden, niemals rohe Registeradressen.
- Status und Metadaten (Firmware-Version, Hash der I/O-Konfiguration) auf Retained-Topics publizieren.
- Befehls-Topics getrennt halten (
.../cmd/...) und genau dokumentieren, wer darauf publizieren darf.
Vom Pilotprojekt zur Produktion
Der obige Code reicht für einen Piloten auf dem öffentlichen MQTT-Broker, doch Werksdaten gehören nicht auf einen öffentlichen Broker – er ist nur für Tests und Prototypen gedacht. Produktive Gateways brauchen einen privaten Broker, TLS und einige betriebliche Gewohnheiten:
- Private Zugangsdaten über TLS. Legen Sie einen Broker bei ConnectMQ an, verwenden Sie den im Portal generierten Benutzernamen, das Passwort und die Client ID und verbinden Sie sich über Port 8883. Client IDs sind an die ausgegebenen Zugangsdaten gebunden, sodass sich ein Gateway nicht als ein anderes ausgeben kann.
- Nur ausgehende Verbindungen. Das Gateway baut die Verbindung zum Broker auf; im OT-Netz sind keine eingehenden Firewall-Regeln nötig.
- Store and Forward. Halten Sie eine lokale Warteschlange vor, damit Netzwerkausfälle keine Datenlücken verursachen. Das Muster MQTT-Nachrichten offline puffern in Python funktioniert unverändert auf einem RevPi.
- Dienstverwaltung. Betreiben Sie das Skript als systemd-Unit mit automatischem Neustart und nutzen Sie den Hardware-Watchdog.
- Härtung. SSH-Schlüssel, Firewall, regelmäßige Updates und ein eigener Dienstbenutzer, wie in der Checkliste zur Absicherung des Raspberry Pi im IoT beschrieben.
- Änderungsmanagement. Versionieren Sie PiCtory-Konfiguration und Gateway-Code gemeinsam, damit die I/O-Namen im Code immer zur Hardware passen.
Ein verwalteter MQTT-Broker übernimmt die Serverseite: Zertifikate, Verfügbarkeit und Kontingente. Für größere Werke halten die Pläne Dedicated und BYOC den Datenverkehr auf einem isolierten Cluster oder in Ihrem eigenen Cloud-Konto.
Wo industrielle Pi-Gateways gut passen
Industrielle Pi-basierte Steuerungen sind eine starke Wahl, um ältere Maschinen mit Sensoren nachzurüsten, die die SPS nie hatte, um Medien wie Druckluft, Wasser und Energiezähler zu überwachen, Maschinenzustände für OEE-Berechnungen zu erfassen und Protokolle umzusetzen, wo ein Hersteller-Gateway teuer oder geschlossen wäre. Sie sind kein Ersatz für Sicherheits-SPSen und sollten keine schnellen Regelkreise schließen, die von deterministischem Timing abhängen. Lassen Sie diese in der dafür ausgelegten Steuerung und das Gateway berichten, was passiert.
Einen breiteren Überblick über Edge-Gateways auf der Pi-Plattform bieten das Raspberry Pi MQTT-Tutorial und die offizielle Compute-Module-Dokumentation.
Verbinden Sie Ihre industriellen Gateways mit ConnectMQ
Starten Sie einen Piloten im kostenlosen Serverless-Plan unter app.connectmq.com, ohne Kreditkarte, und sehen Sie Ihre RevPi-Signale innerhalb weniger Minuten im Live-Topic-Explorer. Hat der Pilot seinen Nutzen bewiesen, ziehen Sie dieselben Gateways ohne Codeänderung auf einen Dedicated- oder BYOC-Broker um.
Häufig gestellte Fragen
Kann ich auf einem Revolution Pi Node-RED statt Python verwenden?
Ja. Node-RED läuft auf dem RevPi und bietet Nodes für das Prozessabbild; die integrierten MQTT-Nodes publizieren an jeden Broker. Python gibt Ihnen mehr Kontrolle über Pufferung und Tests.
Ersetzt der Revolution Pi eine SPS?
Er kann einfache Steuerungslogik ausführen, doch die meisten Werke behalten ihre vorhandenen SPSen für Steuerung und Sicherheit und nutzen den RevPi daneben als Daten-Gateway.
Wie schnell kann ein RevPi-Gateway Daten publizieren?
Der I/O-Zyklus ist für Monitoring schnell genug, aber die eigentliche Frage ist, wie oft die Verbraucher Daten benötigen. Publizieren Sie digitale Signale bei Änderung und Analogwerte in einem festen Intervall.
Ist MQTT sicher genug für Werksdaten?
MQTT über TLS mit eindeutigen Zugangsdaten pro Gateway, nur ausgehenden Verbindungen und einem privaten Broker ist ein solides Design. Publizieren Sie Werksdaten niemals auf einem öffentlichen Broker.
