Ich beschäftige mich mit der Entwicklung, Implementierung und dem Betrieb von automatischen Prozessleitsystemen (ACS TP). Zunächst arbeitete er mit SCADA-Systemen. Dann wechselte er schnell zur Arbeit mit Protokollen für den Austausch industrieller Geräte. Sowohl selbstschreibende Treiber als auch das Einrichten von Datenerfassungssystemen. Im Moment geht meine Arbeit durch die Atmosphäre von Modbus-s, IEC-101/104-s, OPC und anderen Protokollen.
Abb. 1. Die Vielzahl von Kommunikationsprotokollen, die in industriellen Steuerungssystemen verwendet werdenKurz darüber, wie ein typisches Datenerfassungssystem funktioniert (etwas vereinfacht).
Abb. 2. DatenerfassungssystemEine spezielle Software namens OPC-Server fragt Geräte ab, die an die RS-485-Schnittstelle angeschlossen sind. Der OPC-Server ist eine Art Schicht zwischen dem SCADA-System und den Geräten und übersetzt die Sprache, in der die Geräte kommunizieren, in eine Sprache, die für das SCADA-System verständlich ist. Der Ethernet / RS-485-Konverter wird verwendet, um TCP / IP-Pakete in Pakete zu konvertieren, die durch die physische Umgebung von RS-485 übertragen werden.
Dieses Schema hat mehrere Nachteile:
- Stellen Sie beispielsweise auf dem OPC-Server eine Zeitüberschreitung für das Warten auf eine Antwort von 200 ms ein. Im Idealfall, wenn Pakete ohne Verzögerungen an Ethernet gesendet werden, erfolgt die Kommunikation mit Geräten mit einer guten Geschwindigkeit (Intensität). Wenn jedoch das Paket, das die Antwort enthält, beispielsweise um 300 ms verzögert ist (dies ist mehr als das Antwortzeitlimit von 200 ms), berücksichtigt der OPC-Server, dass die Antwort auf die Anforderung nicht angekommen ist, und sendet die nächste Anforderung. Zu diesem Zeitpunkt kommt die Antwort auf die vorherige Anforderung an, aber der OPC-Server glaubt, dass dies die Antwort auf die aktuelle Anforderung ist, und sendet die falschen Daten nach oben. Infolgedessen "springen" die Daten auf der Workstation. Um solchen Situationen zu entkommen, werden wir eine Zeitüberschreitung festlegen. Nehmen Sie mit einem Abstand von 3000 ms. Wenn die Antwort früher als 3000 ms eintrifft, warten wir nicht auf die verbleibende Zeit, sondern fahren mit der nächsten Anfrage fort. Bisher läuft alles gut, aber sobald mehrere Geräte nicht mehr reagieren, gibt es für jedes Gerät Verzögerungen von 3000 ms. Die Abrufzeit nimmt zu.
- Die meisten in Prozessleitsystemen (Modbus, Stromzähler) verwendeten Protokolle basieren auf der sequentiellen Abfrage derselben Parameter. Da die Parameterwerte die meiste Zeit unverändert bleiben, wird das Datennetz verwendet, um dieselben zu übertragen. Dies ist irrational, wenn das Übertragungsmedium GPRS ist und der Verkehr Geld kostet. Darüber hinaus können in einem GPRS-Übertragungsmedium Paketverzögerungen mehrere Sekunden erreichen. Warum Zeit und Ressourcen verschwenden, um dasselbe zu übertragen?
Für die obigen Situationen ist ein Protokoll besser geeignet, bei dem Daten durch Änderung (sporadisch) nach oben übertragen und nach mehreren Werten in einem TCP-Paket gruppiert werden. Solche Protokolle sind IEC-60870-5-104 und OPC UA. ModBus-TCP ist ebenfalls geeignet, da keine Änderungen übertragen werden. Wenn jedoch nicht viele Daten vorhanden sind, können diese in einem Paket zusammengefasst werden. Es wäre schön, eine Art Controller zu haben, der an eine DIN-Schiene gehängt werden kann, Geräte über RS-485 daran anschließt und Daten über Ethernet an das SCADA-System überträgt.
Im Allgemeinen gibt es einige Hardware-Gateways in beträchtlicher Anzahl. Aber in Form von vorgefertigten unteilbaren Lösungen. Alles in einem. Und ich mag es nicht wirklich. Ich brauchte einmal ein Gateway, das die Protokolle der SET-4TM-Messgeräte in OPC UA mit sechs RS-485-Ports und zwei Ethernet konvertierte. Ein Hersteller hat ein Gateway, das die erforderlichen Austauschprotokolle unterstützt, aber nur wenige RS-485-Ports, der andere hat die richtige Anzahl von RS-485-Ports, aber es gibt keine zwei Ethernet-Ports. Der dritte hat zwei Ethernet-Ports, aber nicht alle Kommunikationsprotokolle. Die vierte hat fast alles, aber es gibt keine OPC UA, die an Bord der IEC-60870-5-104 oder ModBus-TCP verfügbar ist und für diese Protokolle einen OPC-Server benötigt.
Und wie schön wäre es, einen Controller oder einen Mini-PC mit Betriebssystem von einem Hersteller zu kaufen. Kaufen Sie Software für den Controller von einem anderen. Wenn ein Softwarehersteller etwas nicht unterstützt, kaufen Sie eine der Software von einem anderen und kombinieren Sie Softwarekomponenten über eine Standard-Softwareschnittstelle. Es scheint, dass hier eine glänzende Zukunft ist!
Aus diesem Grund werden Protokoll-Gateways aufgrund ihrer Unteilbarkeit in Komponenten weniger häufig verwendet als der OPC-Server und das Ethernet-zu-RS-485-Konverter-Bundle.
Einer der Gründe, warum SCADA für Linux unterentwickelt ist: SCADA ist verfügbar, es werden nur wenige Austauschprotokolle unterstützt und es gibt keine OPC-Server für die Kommunikation mit Geräten. SCADA lässt den Integrator eins zu eins mit der Hardware.
Der Leser kann bereits eine Frage stellen: Was können Sie anbieten? Was ist schon da? Es gibt OPC UA-Server für Linux für die folgenden Protokolle:
Um Daten nicht nur über das OPC UA-Protokoll an die obere Ebene zu übertragen, wurden die „
OPC UA to Modbus Converter und IEC 60870-5-104 “ erstellt. Zusätzlich zur Datenübertragungsfunktion dieser Protokolle verfügt der „Konverter“ über einen integrierten Webserver. Mit einem speziellen Editor können Sie ein Diagramm zeichnen, die Tag-Werte darauf anzeigen und es dann in einem Browser öffnen. Es stellt sich heraus, Mini-SCADA direkt in der Steuerung. Wie die Animation der Schaltung funktioniert, habe ich hier bereits über den Editor
hier geschrieben . In Zukunft ist „OPC UA to MQTT Converter“ geplant.
OPC UA-Server und -Konverter funktionieren auf x64-, ARMv7- und AARCH64-Architekturen.
Daher können Sie für die Hardware sowohl bewährte Lösungen auf Basis von Mini-Industriecomputern als auch alle Arten von "Himbeer-Pi-kompatiblen" ARM-Minicomputern verwenden. Informationen zum Installieren und Konfigurieren der Software anhand von Beispielen finden Sie
hier oder
hier .
Im Allgemeinen sieht die Struktur des Komplexes folgendermaßen aus:
Das System ist skalierbar. Es werden die Komponenten verwendet, die nur zur Lösung des aktuellen Problems erforderlich sind.
Mit dem OPC UA-Server wird unser Schema transformiert:
Wir haben folgendes:
- Der OPC UA-Server sammelt Daten von Geräten über RS-485 ohne große Verzögerungen zwischen den Anforderungen.
- Daten in SCADA werden zur Änderung in mehreren Teilen in einem TCP-Paket ausgegeben.
- Sie können mehrere gleich konfigurierte Workstations mit dem OPC UA-Server verbinden. Nützlich, wenn eine Vervielfältigung erforderlich ist.
Anstelle eines Bündels von OPC-Servern und „Ethernet-zu-RS-485-Konverter“ erhalten wir daher ein Gerät, das deren Funktionalität kombiniert. Ich mag dieses Schema mehr. Und Ihnen?