Entscheidungshilfe für industrielle Kommunikationsprotokolle: Modbus vs. MQTT vs. OPC UA

Kommen Sie nicht zu einem Deal.

In jedem Forum wird die gleiche Frage gestellt: "Will ich dieses Projekt mit Modbus oder MQTT verwenden?"„Willst du die OPC UA nutzen?"

Die Antwort lautet immer - sag mir zuerst, wie viele Geräte du auf deiner Website hast, welche physische Schicht du übernimmst und wohin die Daten gehen.

Die Auswahl des Protokolls ist nicht die Auswahl, welche fortgeschrittener ist, sondern die Auswahl, welche in Ihrem Szenario die wenigsten Probleme bereitet. Modbus 1979 geboren, MQTT 1999, OPC UA 2006 - alle drei Protokolle sind nicht tot, was bedeutet, dass jeder seine eigenen Jobs hat. Was Sie brauchen, ist keine Schlussfolgerung „was am besten ist", sondern ein Engineering-Entscheidungsrahmen, mit dem Sie Ihre eigenen Schlussfolgerungen innerhalb von drei Minuten ziehen können.

Drei Dinge, in einem Wort.

* Modbus RTU / TCP *: Master-Stationen fragen nach dem Slave-Stationen, eine Frage nach der anderen. Frame-Format ist fest, Adresse + Funktionscode + Daten + CRC. Die Hauptstation kann nicht sprechen und muss warten, bis die Hauptstation ihn ruft.

Zum Beispiel: Militär-Training. Der Lehrer ruft einen Schüler an und der Schüler meldet „hier". Rufen Sie den nächsten. 30 Personen, eine nach der anderen, in Ordnung. Es ist nicht schlecht, aber wenn es 500 Leute gibt. Bis wir in die letzte Reihe gerufen haben, sind 20 Minuten vergangen.

* * MQTT * *: Veröffentlichung / Abonnement-Modell. Das Gerät selbst entscheidet, wann es meldet, und es braucht niemanden zu fragen. Der Broker ist das Postamt, das Gerät, um Nachrichten in das Thema zu werfen, wer abonniert, wer empfängt.

Analogie vor Ort: Mikro-Gruppe. Der Sensor sendet in der Gruppe ein „Ich überschritten", alle Systeme, die diese Gruppe abonniert haben, sehen gleichzeitig. Man muss nicht warten, wer fragt.

* * OPC UA * *: Objektorientiertes Framework für industrielle Interoperabilität. Nicht nur Daten übertragen, sondern auch ein semantisches Modell - sagen Sie, dass diese Daten "Motorstrom", Einheit in Ampere, Wertbereich 0 - 100, Genauigkeit 0.1. Es gibt auch sichere Kanäle, Zertifizierungszertifikate und Methodenanrufe.

Wie die Fremdsprachenübersetzer: Siemens PLC spricht Deutsch, Rockwell Englisch, Mitsubishi Japanisch, OPC UA übersetzt in die allgemeine Sprache, auch mit einem detaillierten Grammatik-Buch.

Drei Vereinbarungen kämpfen nicht. In realen Projekten werden sie häufig vermischt.

12 Auswahlkriterien, harte Indikatoren

1. Anzahl der Geräte: Die mathematische Decke des Polls

Modbus RTU bei 9600 bps, Lesen Sie ein Hold-Register (Funktion Code 03), Master-Station sendet 8 Byte, von der Station zurück 7 Byte (Adresse + Funktion Code + Byte + 2 Byte Daten + 2 Byte CRC), insgesamt 15 Byte. Zusätzlich zu 3,5 - Zeichen-Frame - Intervall (ca. 4ms @ 9600) und Slave-Reaktionsverzögerung (normalerweise 10 - 50ms, konservativ 20ms):

Einzige Polling-Zeit pro Slave = Frame-Transfer - Zeit + Frame-Intervall + Slave-Reaktionsverzögerung

Frame Übertragungszeit = 15 × 11 Bit ÷ 9600 = 17,2 ms (11 bit / Zeichen): 1 Start-Bit + 8 Daten-Bit + 1 Check-Bit + 1 Stop-Bit)

Einzel-Polling ≈ 17.2 + 4 + 4 + 20 = 45.2ms

200 Slave-Stationen, jedes Lesen 10 Registers (Multi-Register - Lesen-Frame länger, ein Frame kann etwa 125 Registers), die tatsächliche Einzel-Polling etwa 60 - 80ms / Stück.

* * 200 x 70ms = 14 Sekunden. * * Sie schauen auf den Bildschirm in der Steuerung, und die Daten auf dem HMI werden alle 14 Sekunden aktualisiert. Das Alarmsignal läuft 14 Sekunden auf der Straße, bevor Sie es sehen.

Das ist der theoretische Bestwert. Im praktischen Projekt können Reaktionszeiten, Wiederversuche und Abnahme der Liniequalität von der Station diese Zahl verdoppeln.

* * Schlussfolgerung: Bei Geräten < 50 Modbus-RTU - Abfragezyklen innerhalb von 2 - 3 Sekunden sind für die meisten Überwachungsszenarien ausreichend. Mehr als 100 Geräte, entweder Modbus TCP (Ethernet verbraucht keine serielle Bandbreite) oder MQTT.

2. Kommunikationsmodell: Polling vs. Ereignisgetrieben

Modbus ist Polling. Sie fragen alle n Sekunden, und ein Alarmsignal kann zwischen den beiden Polls erzeugt werden, aber Sie müssen bis zur nächsten Runde warten, um es zu sehen.

Szenario: Abwasserbehandlungsanlage, der pH-Wert des Eingangswassers plötzlich von 7 auf 4 gesunken. Die Abfragezyklus von Modbus beträgt 5 Sekunden, im schlimmsten Fall - der pH-Sensor überschreitet die Norm, nachdem er gefragt wurde, müssen Sie fast 5 Sekunden warten, um es zu wissen. Fünf Sekunden sind zu lang für den Prozess.

MQTT ist Ereignisgesteuert Der Sensor erkennt eine Anomalie und sendet sofort eine Nachricht. Der Broker wird innerhalb der gleichen Sekunde an das Überwachungssystem weitergeleitet. Die Verzögerung hängt von der Netzwerkverzögerung + der Broker-Verarbeitungszeit ab und liegt normalerweise innerhalb von 100 ms.

OPC UA unterstützt den Abonnementsmodus (MonitoredItem). Der Client registriert die interessierten Datenpunkte, legt die Abtastenintervalle und die Auslöserbedingungen fest. Veränderungen > Schwellenwerte werden nur gedrängt, nicht dumme Polling-Menge.

* * Fazit: Wenn Ihre Alarm-Reaktionszeit < 1 Sekunde erfordert, kann die Modbus-Abfrage nicht durchgeführt werden, wählen Sie ein MQTT - oder OPC-UA - Abonnement. * *

3. Bandbreite und Latenz: Die physische Schicht bestimmt die unteren Grenzen

Die 1200 - Meter-Grenze des RS - 485, die ich gesehen habe, kann erreicht werden - vorausgesetzt, dass es hochwertiges abgeschirmtes Twisted Pair, 9600 bps, nur ein Gerät und kein Umrichter neben. In der Werkstatt, sobald der Frequenzumrichter eingeschaltet ist, steigt die Kommunikationsfehlerrate in die Höhe, müssen Sie die Baudrate reduzieren und die Abschirmung und Isolierung erhöhen.

Modbus RTU bei 9600 bps hat eine Übertragungsdichte von ca. 800 Bytes / s (ohne Start-Bit - Stop-Bit - Overhead). MQTT geht 4G, Dutzende KB sind kein Problem. Die Effizienz der Binärcodierung von OPC UA ist gut, aber der Zertifikataustausch und die Sitzungsaussprache verbrauchen Hunderte KB beim Aufbau der Verbindung.

* * Schlussfolgerung: Der lokale Bus, die Bandbreite ist kein Engpass. Fernzugriff, Modbus RTU geht nicht direkt in das öffentliche Netzwerk - Sie haben noch nie jemanden gesehen, der eine RS - 485 - Linie von Peking nach Shijiazhuang zieht. Sie müssen das Portal überschreiten. * *

4. Komplexität des Datenmodells: Vom Register bis zum Objekt

Es gibt nur vier Modbus-Datenmodelle: Spulen (Bits), diskrete Eingabe (Bits), Hold-Register (16 - Bit-Wörter) und Eingabe-Register (16 - Bit-Wörter). Nichts mehr. Keine Gleitkommazahlen, keine Zeichenfolgen, keine Zeitstempel, keine Array-Strukturen - es sei denn, Sie selbst codieren auf mehreren Registeren.

Ein Frequenzumrichter Daten: Betriebszustand (Bit), Einstellungsfrequenz (Flowerpunkt, 2 Register), tatsächliche Frequenz (Flowerpunkt), Ausgangsstrom (Flowerpunkt), Busspannung (Ganzzahl), Betriebszeit (32 Bit, 2 Register), Alarmcode (Bitmaske). Alles wird mit Modbus-Registern implementiert, und Sie müssen eine Excel-Tabelle führen, in der Sie feststellen, welches Register mit welchen Parametern korrespondiert und welche Codierung verwendet wird. Auf zehn Frequenzumrichter verteilt ist eine Zuordnung von mehreren hundert Registeren.

MQTT ist nicht viel besser - ein freies JSON-Format, aber es gibt verschiedene Hersteller für das Feld „Frequenz" mit den Namen freqency, freq, Hz, output _ freq. Es gibt keine Kriterien, man muss sich selbst entscheiden.

Das Informationsmodell (IM) von OPC UA löst dieses Problem von der Protokollschicht aus: Jeder Datenpunkt hat Typ, Einheit, Bereich und Engineering Units. Ein MotorType-Objekt enthält Current, Temperature, Speed - mit eigener Semantik, nicht mit einem nackten Register.

* * Schlussfolgerung: Datenpunkte < 50, einfacher Typ (alle Ganzzahlen / Schalter), Modbus-Register - Zuordnung vollständig ausreichend. Mit mehr als 200 Punkten und komplexen Objektmodellen können Sie mit OPC UA den Aufwand bei der Dokumentation halbieren. * *

5. Sicherheit: Wer ist nackt?

Im Modbus-Zeitalter (1979) hat niemand über die Cybersicherheit nachgedacht. Es gibt kein Authentifizierungsfeld auf dem RTU-Frame, und jedes Gerät, das auf den RS - 485 - Bus zugeschlossen ist, kann Befehle senden - Pumpen ausschalten, Parameter ändern, Register schreiben. Die TCP-Version bietet eine zusätzliche Schicht für TCP-Verbindungen, aber auch kein integriertes TLS.

MQTT kann über TLS verschlüsselt übertragen, Benutzername / Passwort Authentifizierung, Broker-Seite kann auch ACLs steuern, welche Clients veröffentlichen / abonnieren können, welche Themen.

Das Sicherheitsmodell von OPC UA besteht aus drei Teilen: Zertifikat-Authentifizierung (X.509) + Nachrichtensignierung + Nachrichtenverschlüsselung. Benutzer-Token werden ebenfalls unterstützt (Benutzername-Passwort / Zertifikat / Anonym). Vom Verbindungsaufbau bis zur Datenübertragung, vollständige Verschlüsselung der Verbindung.

Einmal ging ich zu einem Wasserwerk, um zu überprüfen, fand ich, dass ihre Modbus TCP-Gateway öffentliche Netzwerk-Port geöffnet ist, in der Lage, direkt in der Frequenzumrichter-Start - Stop-Register zu schreiben. Kein Witz, das gibt es bei kleinen und mittleren Unternehmen zu viel.

* * Fazit: Öffentliche Netzwerke, Remotebetrieb und Wartung, Szenarien mit kritischen Infrastrukturen - nicht mit dem nackten Modbus. Sie müssen mindestens über das MQTT + TLS-Gateway gehen. Wenn Sie bereits über OPC UA-Funktionen verfügen, verwenden Sie direkt den sicheren Kanal. * *

6. Interoperabilität: Mit wem Geräte sprechen

Im Idealfall läuft das gleiche Protokoll auf allen Geräten - Sie, Siemens, ich, Schneider, AB, alle mit Profinet. Die Wirklichkeit ist nicht so.

Der Vorteil von Modbus liegt genau darin: Fast alle SPS unterstützen Modbus RTU / TCP, sei es das CM1241 - Modul der Siemens S7-1200 oder die RS - 485 - Anschlüsse der Mitsubishi FX-Serie. Gerätehersteller sind auch gerne unterstützt - keine Lizenzgebühren zu zahlen, die Implementierung ist einfach, in wenigen Tagen können Sie einstellen.

Die Interoperabilität von MQTT beruht auf einer konventionellen Themenstruktur und dem JSON-Format. Die Vereinbarungen können jedoch unterschiedlich sein. * * Die Sparebug-B - Spezifikation * * füllt diese Lücke - sie definiert Standard-Theme - Namensräume, Datentyp-Codierung, Geräte-Geburt - / Todesnachrichten.

Die Interoperabilität von OPC UA ist im Protokoll eingebaut: Die Companion Spezifikationen decken Dutzende von Branchen ab, darunter Robotik, Spritzgießmaschinen, CNC und Windenergie. Der OPC UA-Server von Siemens und der OPC UA-Client von Rockwell können direkt miteinander kommunizieren, ohne dass Code für die Zuordnungsschicht geschrieben werden muss.

Aber wiederum: Die unterstützenden Spezifikationen für OPC UA befinden sich noch in der Entwicklung und werden nicht von allen Geräten unterstützt. Die Implementierung von OPC UA von einigen Herstellern ist eine Tasche - Knoten können durchsuchen und die tatsächliche Datenaktualisierungsfrequenz kann nicht mithalten.

* * Schlussfolgerung: Die Interoperabilität mit mehreren PLC / DCS-Marken ist eine harte Forderung → OPC UA. Alle Geräte sind inländische Zähler / Sensoren → Modbus RTU ausreichend. Cloud-Plattform - Anschluss → MQTT erforderlich. * *

7. Entwicklungszyklen und Teamfähigkeiten

Das ist eine sehr unterschätzte Sache.

Modbus-Entwicklung: Finde eine serielle Port-Bibliothek, sende 8 Bytes, empfängt 7 Bytes, tun zwei Tage, geht es. Das Protokoll enthält Hunderte von Code-Streiben. Mit dem Python-Pymodbus oder dem NModbus in C # können Sie die Register am Nachmittag lesen und schreiben. Innerhalb von drei Tagen ist ein Modbus-Hauptstation - Antrieb von vielen Ingenieuren vorhanden.

MQTT-Entwicklung: Installieren Sie eine MQTT-Bibliothek, Broker-Adresse, Port, Thema und drei Zeilen Code. Veröffentlichen / Abonnieren von zwei Zeilen. Ein Tag Hand. Broker-Bereitstellung (Mosquitto / EMQX) in einer halben Stunde abgeschlossen.

OPC UA-Entwicklung: Ich will die Wahrheit sagen - nicht einfach. Adressraummodellierung, Zertifikatsverwaltung, Konfiguration von Sicherheitsrichtlinien, Abonnements / Methoden-Aufrufe, die Lernkurve ist viel steiler als die beiden vorherigen. Es ist eine Sache, einen Server mit dem UAExpert-Client zu verbinden, und eine andere, einen vollständigen OPC-UA - Server selbst zu schreiben. Die Industrie verwendet in der Regel KepServerEx, Siemens OPC UA Server diese bewährten Produkte, die meisten SDKs, nicht viel von Grund auf geschrieben. Ein Team ohne OPC-UA - Erfahrung, 2 - 4 Wochen für die technische Validierung reserviert.

* * Schlussfolgerung: 3 Tage Entwicklung → Modbus. 1 Tag Entwicklung → MQTT. Es gibt ein spezielles Personal und das Projekt ermöglicht Lernkosten → OPC UA. * *

8. Hardware-Kosten: Preisdifferenz auf Chip-Klasse

Der RS - 485 - Transceiver (MAX485 / SP3485) kostet weniger als 1 CNY. Zusätzlich zu zwei 120 Ω - Terminationswiderstörungen, einem TVS-Schutzrohr, die BOM-Kosten innerhalb von 3 US-Dollar. Die UART-Peripheriegeräte des STM32F103 MCU werden direkt betrieben, ohne dass ein externes PHY erforderlich ist.

Mindeste Hardwareanforderungen für MQTT: Netzwerkstack (WiFi / Ethernet / 4G-Modul) + TCP / IP-Protokollstack. ESP32 ist mit WiFi + BLE, der Massenpreis ist etwa 12 - 15 Blocks, läuft FreeRTOS + LwIP + paho MQTT ohne Druck. Wenn es sich um ein 4G-Modul handelt (ca. 20 Blocks mit dem Air724UG), kann es auch MQTT-AT - Befehle ausführen.

OPC UA hat Hardwareanforderungen. Ein minimaler OPC UA-Server (unterstützt die Sicherheitsrichtlinie Basic256Sha256 und unterstützt 1000 variable Knoten) benötigt ca. 256 KB RAM + 512 KB Flash. Sie können die Embedded-Version von open62541 auf einem STM32H7 (Cortex-M7, ~ 30 Blocks) ausführen, aber nicht so einfach wie „Anzeigen". Industrielle OPC UA-Gateways verwenden normalerweise Linux-Boards der ARM Cortex-A - Serie (z. B. T113 - i, ab 40 - 50 Stück).

* * Schlussfolgerung: Machen Sie einen Modbus RTU-Temperatur - Feuchte-Sensor für 50 €, die Hardware-Kosten des OPC UA-Systems können nicht bezahlt werden. Für ein Industrie-Gateway mit einem Preis von 5000 ist die Hardware-Kosten von OPC UA überhaupt keine Frage. * *

9. Cloud-Zugang: Die angeborenen Gene des Protokolls

Modbus wurde für lokale Busse entwickelt. Sie können RS - 485 nicht direkt in die Alibaba Cloud IoT-Plattform schließen. Sie müssen über das Gateway - - Modbus RTU → Gateway (Protokolübertragung) → MQTT / HTTP → Cloud gehen.

MQTT eignet sich natürlich für den Zugriff auf die Cloud. AWS IoT Core, Alibaba Cloud IoT, EMQX Cloud, ThingsBoard - die ersten Bürger aller Mainstream-IoT - Plattformen sind MQTT. Das Thema-Routing ist flexibel, die Last Will-Nachricht löst die Offline-Erkennung von Geräten und die Nachricht (Retentioned) sorgt dafür, dass neue Abonnenten sofort auf dem neuesten Stand sind.

Das Client / Server-Modell von OPC UA ist nicht für die Cloud geeignet - die Latenz von WANs ist hoch, und das sichere Handshake und die Sitzungsverwaltung von UA sind schwer zu bewältigen. OPC UA verfügt jedoch über eine Pub / Sub-Erweiterung (2018 veröffentlicht), die UDP-Multicast und MQTT-Broker - Übertragungen unterstützt, die sich speziell auf Cloud-Zugangsprobleme konzentrieren. Allerdings gibt es derzeit nur wenige Fälle von OPC UA Pub / Sub, die indirekte Route von OPC UA Server → Edge Gateway → MQTT → Cloud sind.

* * Fazit: Ihr Datenendpunkt ist die Cloud → MQTT, zögern Sie nicht. Lokale SCADA / Historian → OPC UA. Sowohl in der Cloud als auch lokal überwacht → Kombination aus MQTT + OPC UA. * *

10. Geschichte: Nicht ändern, nicht ändern

Das häufigste Szenario: Eine Abwasserbehandlungsanlage mit 200 Modbus RTU-Zählern (Wei Sheng / Kolu / Linyang), die seit fünf Jahren auf dem RS - 485 - Bus laufen. Sie müssen jetzt die Cloud als Energieverbrauchsmanagement-Plattform nutzen.

Haben Sie die 200 Stück ausgetauscht? Unrealistisch. Das Budget ist eine Sache, und der Schlüssel ist, dass sie überhaupt nicht schlecht sind. Die Verwendung von Modbus-MQTT - Gateway ist die vernünftigste Lösung: das Zähler läuft weiterhin Modbus RTU, das Gateway macht die Polling-Erfassung, die Daten in JSON verpacken und gehen MQTT in der Cloud. Am Ende des Zählers ist der Modbus stabil, die Cloud ist die moderne IoT-Architektur - beide Seiten leiden nicht.

Das gleiche gilt: In einer Lackierwerkstatt gibt es 50 AB PLCs, die alle auf EtherNet / IP laufen. Sie möchten ein MES-System hinzufügen, sodass diese PLC-Daten von MES gelesen werden können. Szenario A: Jede SPS ist mit einem Modbus TCP-Modul ausgestattet. Szenario B: Fügen Sie ein KepServer / Ignition OPC UA-Gateway hinzu, um die OPC UA-Schnittstelle nach der Aggregation von EtherNet / IP-Daten auszusprechen. Option B ändert keine Leitung vor Ort Ausrüstung.

* Verwenden Sie ein Gateway, um eine Brücke zu erstellen, und denken Sie nicht daran, Ihre vorhandenen Geräte vollständig zu aktualisieren - das kostet mehr Geld. * *

11. Geräte entdecken: Wer weiß, was im Bus ist

Modbus verfügt über keinen Mechanismus zur Entdeckung von Geräten. Sie wissen, welche Geräte von der Station 1 bis 247 aufgehängt werden? Die einzige Methode: Senden Sie einen Code 03 (Lese-Halt - Register) oder 08 (Diagnostik) und so weiter.Überstritten, ohne Ausrüstung. Dieser Prozess nennt sich „Adressen-Scan" - 247 Adressen mit 9600 bps brauchen Dutzende von Sekunden, und einige Geräte melden Ausnahmen beim Lesen von unbekannten Registeren.

Auch MQTT selbst hat keine Geräte-Erkennung. Das Gerät sendet eine Nachricht an ein bestimmtes Thema, aber dies beruht auf der vereinbarten Geschäftslogik und nicht auf dem Protokoll-Mechanismus. Die Spezifikation von Sparebug B enthält Geburts - / Todesnachrichten für das Gerät, erfordert jedoch das aktive Zuhören des Empfängers.

OPC UA enthält einen Discovery-Dienst (Discovery Server, Standardport 4840). Der Client verbindet sich mit dem Discovery Server, fragt "Welche Server haben Sie unten registriert", erhält die Liste und die Endpunkt-URL, und geht dann zur Verbindung. OPC-UA - Server können auch automatisch über mDNS (Multicast DNS) im LAN erkannt werden.

* * Fazit: Geräte wechseln häufig, Netzwerktopologie ändert sich dynamisch → OPC UA-Erkennungservice sparen Sie viel Konfigurationszeit. Das Gerät ist fixiert, installiert und nicht bewegt → Modbus manuell einstellen ist auch kein Problem. * *

12. Firmware-Upgrades und Konfigurationsverwaltung

Modbus definiert nur Datenlesen und Schreiben. Upgrade der Firmware? Es gibt keinen Standardfunktionscode. Einige Hersteller verwenden den benutzerdefinierten Bereich des Funktionscodes 0x41 - 0xFF, aber jeder ist anders und kann nicht miteinander kommunizieren.

Ähnlich wie MQTT - Übertragung von Firmwarepaketen kann, aber das Format und der Prozess können Sie selbst bestimmen.

OPC UA verfügt über einen Standard-Methoden - Aufruf. Sie können eine Methode "Firmware-Upgrade" definieren, die die URL - und Versionsnummerparameter der Firmware-Datei akzeptiert und den Fortschritt und das Ergebnis des Upgrades zurückgibt. Die Device Integration Package Specification (DI) definiert zudem ein Standardmodell für das Gerätemanagement.

* * Schlussfolgerung: Firmware-Upgrades für Massengeräte sind die Kernanforderung → OPC UA-Methodenanrufe sind viel besser als ein eigenes Protokoll. Gelegentlich Upgrades, das USB-Kabel vor Ort zu knüpfen → Modbus genügt. * *

Entscheidungspfad, gehen Sie durch

你的项目
│
├── 设备数量 > 100？
│   ├── 是 ──→ 需要事件驱动（报警 < 1s 响应）？
│   │         ├── 是 ──→ 需要多种品牌互操作？
│   │         │         ├── 是 ──→ 【OPC UA】
│   │         │         └── 否 ──→ 【MQTT】
│   │         └── 否 ──→ 【Modbus TCP】（配高性能主站，轮询周期可接受）
│   │
│   └── 否 ──→ 需要上云？
│              ├── 是 ──→ 【MQTT】
│              └── 否 ──→ 公网传输 / 需要安全？
│                        ├── 是 ──→ 【OPC UA / MQTT+TLS】
│                        └── 否 ──→ 【Modbus RTU】
│                                  最简单的方案永远最好

Nicht alle Szenarien führen zu einer Vereinbarung. Meistens wählt man eine Kombination.

Hybrid-Architektur: Das Spiel eines echten Projekts

Klassische Kombination: Modbus RTU → Gateway → MQTT → Cloud

Zähler und Sensoren unter dem Modbus RTU, mit einem eingebetteten Gateway (z. B. Huawei AR650, Han Yingtong IG902 oder Sie selbst mit Raspberry Pi + Node-RED gespart) Protokollübertragung:

┌──────────┐  RS-485    ┌──────────┐  MQTT/TLS  ┌─────────────┐
│ 电表 ×50 │───────────→│  Modbus- │───────────→│ 云 IoT 平台  │
│ Modbus   │  Modbus RTU│  MQTT 网关│            │ (Ali/AWS)   │
│ RTU      │            │          │            │             │
└──────────┘            └──────────┘            └─────────────┘

Das Gateway tut zwei Dinge: Polls 50 Zähler Spannung / Strom / Leistung / Strom, in Minutenintervalle in JSON verpackt, gehen MQTT in die Cloud zu veröffentlichen. Die Zähler sind nicht gewechselt, die Cloud ist modern. Diese Architektur wurde bereits unzählige Male auf verteilten PV-Monitoring - und Energiemanagement-Plattformen getestet.

OPC UA als Aggregationsebene

50 Modbus TCP Slave-Stationen in der Fabrik (verteilt in fünf Werkstätten), die oberen MES-Schicht, um die Daten einheitlich zu erhalten. Setzen Sie ein OPC UA-Server - Gateway in der Mitte, laufen Sie KepServer oder ein eigenes Programm mit open62541 geschrieben:

┌────────────┐
│   MES 系统  │
└─────┬──────┘
      │ OPC UA Client
      ▼
┌──────────────────┐
│  OPC UA Server   │ ◄── 聚合网关
│  (KepServerEx等) │
└──┬───┬───┬───┬──┘
   │   │   │   │  Modbus TCP
   ▼   ▼   ▼   ▼
  50台 Modbus TCP 从站 (PLC/仪表)

Vorteil: MES verbindet nur eine OPC UA-Schnittstelle und kümmert sich nicht um die IP-Adresse und die Registerzuordnung jedes Geräts. Die Datenaggregation und die Modellierung des Adressraums werden intern im Gateway durchgeführt.

Doppelkanal: MQTT Reporting + Modbus TCP Local Control

Ein intelligentes Landwirtschaftliches Gewächshaus: 50 LoRa-Temperatur - Feuchte-Sensoren werden über das LoRa-Gateway → MQTT an die Cloud-Plattform für die Trendanalyse gemeldet. Zur gleichen Zeit im Gewächshaus Ventilator, Rollverschluss-Motor gehen Modbus TCP, lokale Touchscreen (HMI) direkte Steuerung. Die Cloud-Plattform kann auch MQTT-Befehle an das Gateway senden, das Gateway über Modbus TCP-Befehle steuert den Anschluss des Ventilators.

┌──────────┐  LoRa  ┌────────┐  MQTT  ┌──────────┐
│ 传感器×50 │───────→│ LoRa   │───────→│ 云平台    │ ← 数据分析
└──────────┘        │ 网关   │        └────┬─────┘
                    └───┬────┘             │ MQTT 控制指令
                        │ Modbus TCP      ▼
                    ┌───┴────────────┐
                    │ 本地 HMI + PLC │ ← 实时控制
                    │  (风机/卷帘)    │
                    └────────────────┘

Warum so gestaltet? Der Sensor meldet kleine Datenmengen, aber mit hoher Frequenz (pro Minute), wodurch MQTT den Datenverkehr sparen kann. Die Ventilatorsteuerung erfordert eine geringe Latenz (< 500ms muss reagieren), Modbus TCP Direct Connection ist am zuverlässigsten. Die Analyse der Cloud-Plattform → die Schleife der Steuerung der Anweisungen gehen MQTT, kann eine Verzögerung von mehreren hundert Millisekunden akzeptieren.

Wann sollte man nicht mischen?

Wenn Ihr Projekt nicht mehr als 30 Geräte enthält, keine Cloud benötigt, keine Remote-Wartung benötigt - eine SPS mit Modbus RS - 485 - Bus und einem HMI-Bildschirm, drei Kabel (A / B / GND), reicht. Komplizieren Sie die Struktur nicht für „Fortschrittenheit". Einfachheit im Engineering ist Zuverlässigkeit.

Protokoll-Portfolio - Quick Checklist

Niemand wird die Wahrheit für Sie sagen

Es gibt keine Sicherheitsmechanismen für Modbus, das ist wahr. Sein Frame ist Klartext, und CRC ist unabhängig von der Übertragung von Fehlern unabhängig von bösartiger Manipulation. Wenn jemand einen Modbus-TCP - Port in das öffentliche Netzwerk aussetzt, ist das nicht anders, als wenn man die Türen der Fabrik offen lässt.

Modbus hat keine Ereignis-Treiber Sie wollen Ereignisse? Versuchen Sie, sich selbst etwas schneller zu besprechen.

Modbus hat kein Standardmodell für Daten. Das Zähler der Fabrik A legt die Spannung in 40001 Register, die Fabrik B legt 40002. Ihr Code ist voll von if-else - Beurteilungen über das Gerätmodell.

Aber Modbus lebt seit mehr als vierzig Jahren nicht durch seine Funktionsfähigkeit, sondern durch seine einfache genug. Es kann auf einem 8 - Bit-Sinochip laufen, kann bei minus 30 Grad stabil laufen und kann einen Nachmittag umsetzen. MQTT erschien, OPC UA erschien, und es ist nicht tot, weil es eine Menge Szenarien gibt, die nicht fortgeschrittene Funktionen benötigen - 30 Geräte, eine Fabrik, lokale HMI, Modbus RTU eine Linie bis zum Ende, was heißt Over-Engineering? OPC UA wird als Over-Engineering bekannt.

Umgekehrt, wenn Sie mit 500 Geräten in einem Umkreis von 50 Kilometern konfrontiert sind, die Cloud-Analysen benötigen und Alarm-Push - Anfragen verlangen - wenn Sie Modbus halten, machen Sie sich Ärger. MQTT + Modbus-Gateway ist die pragmatischste Option.

Wenn Sie in einer Anlage mit mehreren Marken SPS arbeiten und eine einheitliche Schnittstelle für das MES-System auf der oberen Exposition benötigen - OPC UA ist die Standard-Antwort.

Kein Protokoll ist perfekt, du wählst das am wenigsten schlechte in deinem Szenario. Die Weisheit dieser Linie besteht darin, zu wissen, wann es reicht, zu wissen, wann es ein Upgrade ist.