OPC-UA的替代品

cid*_*cid 16 plc scada opc mqtt opc-ua

作为访问由各种PLC组成的系统的过程数据的解决方案,OPC-UA是否还有其他可行的替代方案?什么是平台独立的,可以与不同品牌的产品"说话"?

我听说过MQTT,但它似乎更像是传输协议,只有那样.它没有像信息建模等所有更高级别的东西.

谢谢你的帮助!

Jou*_*Aro 15

OPC是与PLC通信的唯一标准方式.OPC DA是旧的替代品.OPC UA是新的,现在推荐使用.在OPC之前,只有专有协议和共享协议,如Modbus,但它们只是你提到的低级传输协议.

OPC UA在信息建模方面非常独特,尤其如此.除了普通的PLC通信之外,通过该功能,它还可以为更高级别的系统和应用程序提供新的通信可能性.

请注意,某些PLC本身也可以与OPC UA通信,这使其成为标准.

OPC UA真正标准化为IEC 62541,确保它是独立的.

更新17/07/19:OPC UA现在也被定义为工业4.0通信,正如我在最近的文章中所写的那样.

此外,OPC UA即将推出的1.04版本(目前在RC中)将定义Pub/Sub替代方案(稍后使用UDP和AMQP第一个MQTT),还将定义WebSocket/JSON协议替代方案,这将使Web应用程序的使用更加容易.


Flo*_*ger 9

OPC-UA有一些非常有趣的部分,特别是关于信息建模,互操作性和发布/订阅模式.

然而,尽管它是最严格意义上的标准,但我发现要在webapp中使用它,您需要对网关服务器进行编码.因为它使用原始套接字和二进制(尽管快速)序列化协议.

这就是为什么我们在我的大学创建了一个名为Woopsa的替代协议.我们决定将其基于HTTP + JSON.我们尝试制作一个类似于OPC-UA的协议:它具有信息建模,发布/订阅甚至多请求.这些都是完全开源的.

我们刚刚发布了1.0版本:http://www.woopsa.org/

您可以直接在我们的GitHub上获取源代码:https://github.com/woopsa-protocol/Woopsa

基本上,我们的协议只是使用HTTP + JSON的标准化RESTful API.例如,您可以通过创建一个来读取值GET /woopsa/read/Temperature,它将以JSON回复您:

{"Value":24.2,"Type":"Real"}
Run Code Online (Sandbox Code Playgroud)

您还可以使用meta单词来获取对象树,例如:GET /woopsa/meta/这将为您提供类似的内容:

{
  "Name":"WeatherStation", 
  "Properties": [
    {"Name":"Temperature","Type":"Real"},
    ...
  ],
  "Methods": { ... }
  "Items": [ 
    "Thermostat",
    ...
  ]
}
Run Code Online (Sandbox Code Playgroud)

  • 我想是的。但是,OPC-UA的规范仍在成千上万的页面中,而Woopsa则在一个简短的HTML页面中。我想说Woopsa仍然是OPC-UA的轻巧,通用和可行的替代方案。 (2认同)

ast*_*mas 7

在实际工业应用中,MQTT不是OPC-UA的替代品.早在90年代,OPC的最初目标是提供标准的通信机制和数据模型,以提供实现规范的客户端和服务器之间的互操作性.OPC-UA扩展并概括了数据模型和通信,而没有放弃该核心目标.为此,标准必须指定时间戳的格式,数据类型的编码,历史值,警报等.

MQTT是一种消息传输层,不能通过设计提供互操作性.它没有规定有效载荷的格式,也没有规定如何传输特定数据类型,时间戳,值,层次结构或任何其他允许应用程序理解正在传输的数据的内容.您可以创建一个有效的MQTT服务器,该服务器发出XML,JSON或自定义格式的数据,这些数据是纯文本,加密,base-64编码或您喜欢的任何其他内容.客户端应用程序与服务器交互的唯一方法是事先知道服务器将生成和接受的数据格式.

OPC-UA最近推出了一种发布/订阅机制,以提高带宽利用率,降低MQTT目前提供的通信带宽优势.同时,MQTT规范需要增长以指定数据格式以促进互操作性.期望在MQTT和OPC-UA之间看到功能的融合,主要是MQTT的增长以满足OPC-UA.

MQTT目前是一个更简单的实现,它对嵌入式和资源受限的系统具有优势.添加数据建模规范将起到减少这种优势的作用.

底线是OPC-UA用于互操作性,MQTT用于简单的自定义通信.MQTT需要增长才能成为OPC-UA的替代品.