Alternative zu OPC-UA

Question

Gibt es eine gute Alternative zu OPC-UA als Lösung für den Zugriff auf Prozessdaten eines Systems, das aus verschiedenen SPS besteht? Etwas, das plattformunabhängig ist und mit Produkten verschiedener Marken "sprechen" kann?

Ich habe von MQTT gehört, aber es scheint viel mehr wie ein Transportprotokoll zu sein, und nur das. Es hat nicht alle höheren Ebenen Sachen wie die Informationsmodellierung, etc.

Vielen Dank für Ihre Hilfe!

Answer 1

OPC ist der einzige Standard für die Kommunikation mit SPSen. OPC DA ist die alte Alternative. OPC UA ist der neue und wird heutzutage empfohlen. Vor OPC gab es nur proprietäre Protokolle und geteilte Protokolle wie Modbus, aber sie sind nur Transportprotokolle der unteren Ebene, wie Sie erwähnt haben.

OPC UA ist ziemlich einzigartig mit dem Information Modeling, besonders. Damit ermöglicht es neben der reinen SPS-Kommunikation neue Kommunikationsmöglichkeiten für übergeordnete Systeme und Anwendungen.

Beachten Sie, dass einige PLCs auch OPC UA nativ sprechen können, was sie zu einem Standard auf diesem Weg macht.

Und OPC UA ist wirklich als IEC 62541 standardisiert und stellt sicher, dass es unabhängig ist.

Update 17/07/19: OPC UA wird jetzt auch als Industry 4.0 Communication definiert, wie ich in meinem letzten Artikel geschrieben habe.

Auch die kommende Version 1.04 (in RC im Moment) von OPC UA wird Pub/Sub Alternativen definieren (mit UDP & AMQP zuerst MQTT später) und wird auch eine WebSocket/JSON-Protokollalternative definieren, die einfacher zu ermöglichen Verwendung in Webanwendungen.

Answer 2

MQTT wird als Protokoll der Wahl für I.o.T. Es hat seine Nachteile - aber seine Einfachheit wird oft als eine Stärke gesehen, während OPCUA trägt den Overhead von Design von Ausschuss.

Wenn Sie die beiden zu kombinieren, benötigen, können Sie gerne unser einfaches Gateway prüfen, versuchen mqtt2opcua

Answer 3

OPC-UA einige sehr interessante Teile, vor allem Informationsmodellierung in Bezug auf die Interoperabilität und die Publish/Subscribe-Muster.

Obwohl es ein Standard im engsten Sinne ist, habe ich festgestellt, dass Sie einen Gateway-Server codieren müssen, um es in einer Webapp zu verwenden. Weil es rohe Sockets und ein binäres (wenn auch schnelles) Serialisierungsprotokoll verwendet.

Deshalb haben wir an meiner Universität ein alternatives Protokoll namens Woopsa erstellt. Wir haben uns entschieden, es auf HTTP + JSON aufzubauen. Wir haben versucht, ein OPC-UA ähnliches Protokoll zu erstellen: Es gibt Information Modeling, Publish/Subscribe und sogar Multi-Requests. Es ist alles komplett Open-Source.

Wir haben gerade Version veröffentlicht 1.0 hier: http://www.woopsa.org/

Sie können den Quellcode direkt auf unserer GitHub erhalten: https://github.com/woopsa-protocol/Woopsa

Grundsätzlich unser Protokoll ist nur ein standardisiertes RESTful API über HTTP + JSON.Zum Beispiel können Sie einen Wert von einem GET /woopsa/read/Temperature machen lesen und es wird Sie in JSON Antwort:

{"Value":24.2,"Type":"Real"} 

Sie können auch den Objektbaum beispielsweise durch Verwendung des meta Wortes erhalten: GET /woopsa/meta/, die Sie so etwas wie , dass:

{ 
    "Name":"WeatherStation", 
    "Properties": [ 
    {"Name":"Temperature","Type":"Real"}, 
    ... 
    ], 
    "Methods": { ... } 
    "Items": [ 
    "Thermostat", 
    ... 
    ] 
} 

Answer 4

In einer praktischen industriellen Anwendung ist MQTT keine alternative zum OPC-UA. Das ursprüngliche Ziel von OPC war es in den 90er Jahren, einen Standard-Kommunikationsmechanismus und ein Datenmodell bereitzustellen, die eine Interoperabilität zwischen Clients und Servern, die die Spezifikation implementiert haben, bereitstellen würden. OPC-UA erweitert und verallgemeinert das Datenmodell und die Kommunikation, ohne dieses Kernziel aufzugeben. Dazu muss der Standard Dinge wie das Format eines Zeitstempels, die Codierung von Datentypen, historische Werte, Alarme usw. angeben.

MQTT ist eine Nachrichtentransportschicht, die keine Interoperabilität durch Design bietet. Es legt nicht das Format der Nutzlast fest, spezifiziert nicht, wie ein bestimmter Datentyp, Zeitstempel, Wert, Hierarchie oder irgendetwas anderes übertragen wird, das es einer Anwendung erlauben würde, die übertragenen Daten zu verstehen. Sie können einen gültigen MQTT-Server erstellen, der XML-, JSON- oder benutzerdefinierte formatierte Daten ausgibt, die als Klartext, verschlüsselt, Base-64-kodiert oder in beliebiger anderer Form vorliegen. Eine Client-Anwendung kann nur dann mit Ihrem Server interagieren, wenn Sie im Voraus wissen, welches Datenformat der Server erstellt und akzeptiert.

OPC-UA hat kürzlich einen Publish/Subscribe-Mechanismus eingeführt, um die Bandbreitennutzung zu verbessern und so den Kommunikationsbandbreitenvorteil zu reduzieren, den MQTT derzeit bietet. Gleichzeitig muss die MQTT-Spezifikation wachsen, um Datenformate zu spezifizieren, um die Interoperabilität zu fördern. Erwarten Sie eine Konvergenz der Funktionalität zwischen MQTT und OPC-UA. Meistens wächst MQTT, um OPC-UA zu erfüllen.

MQTT ist im Moment eine viel einfachere Implementierung, die Vorteile für eingebettete und ressourcenbeschränkte Systeme bietet. Die Hinzufügung einer Datenmodellierungsspezifikation würde diesen Vorteil verringern.

Die Quintessenz ist, dass OPC-UA für Interoperabilität und MQTT für einfache benutzerdefinierte Kommunikation ist. MQTT muss wachsen, bevor es eine Alternative zu OPC-UA sein kann.

Answer 5

Unserver ist ein Produkt entwickelt, um das genaue Problem in dieser Frage beschrieben zu lösen.

Es ist in der Lage zu sprechen mit verschiedenen Feldgeräten und bieten eine einheitliche HTTP API auf oben von ihnen. Es integriert sich mit Geräten über Modbus RTU, aber andere gemeinsame Protokolle werden in der Zukunft hinzugefügt.

Kurz gesagt, zuerst konfigurieren Sie eine Daten 'Tag' wie folgt aus:

{ 
    "name": "tank1", 
    "device": "plc1", 
    "properties": [ 
    { 
     "name": "level", 
     "address": "HR0", 
     "type": "numeric", 
     "raw": "int16" 
    } 
    ] 
} 

Dann können Sie mit dem Tag arbeiten ein API-Endpunkt unter Verwendung von automatisch erstellt:

GET http://localhost:9000/tags/tank1 

{ 
    data:{ 
    level: 1 
    } 
} 

Schauen Sie sich die documentation Für mehr Information. Das Produkt ist frei für Bewertung und nicht-kommerzielle Nutzung.

Haftungsausschluss: Ich bin ein Teil des Teams. Ich hoffe, das ist nützlich.