替代OPC-UA

作为访问由各种PLC组成的系统的过程数据的解决方案，OPC-UA是否有任何体面的替代方案？某些独立于平台的产品可以与不同品牌的产品“说话”？替代OPC-UA

我听说过MQTT，但它似乎更像是一个传输协议，只有这一点。它没有像信息建模等所有更高级别的东西。

感谢您的帮助！

来源

2014-10-05 cid

OPC是与PLC通信的唯一标准方式。 OPC DA是旧的选择。 OPC UA是现在推荐的新产品。在OPC之前，只有专有协议和像Modbus这样的共享协议，但它们只是您提到的较低级别的传输协议。

OPC UA在信息建模方面非常独特，特别是。除了普通的PLC通讯功能之外，该功能还可以为更高级别的系统和应用程序提供新的通讯功能。

请注意，某些PLC本身也可以使用OPC UA，这使得它成为标准。

而且OPC UA确实标准化为IEC 62541，确保它是独立的。

更新17/07/19：OPC UA现在定义为Industry 4.0 Communication，正如我在我最近的文章中所写的那样。此外，OPC UA即将发布的1.04版本（目前在RC中）将定义Pub/Sub备选方案（稍后使用UDP & AMQP首先MQTT），并且还将定义WebSocket/JSON协议替代方案，这将使启用Web应用程序中的使用。

来源

2014-10-06 08:43:33

作为I.O.T.的选择协议，MQTT越来越流行。它确实有其不足之处 - 然而它的简单性往往被视为一种优势，而OPCUA则承担了委员会设计的开销。

如果您需要将两者结合起来，你可能想考虑尝试我们简单的网关mqtt2opcua

来源

2015-07-27 18:59:01

@NZFarmer作为OPC/OPC-UA的替代品，MQTT对我来说确实非常有前景。但是，MQTT是否处理信息建模？如果是，如何？ – cid 2015-08-04 12:02:55

@cid MQTT的核心是一个非常pub/sub的框架。建议您查看规格。 – 2015-08-05 15:57:39

@NZFarmer是的，它可以在pub/sub架构中工作，很好。这回答了问题_如何。这个问题怎么样_什么？我的意思是OPC/OPC-UA最大的优势之一是它定义了数据的表示/建模。即这种类型的数据将具有字段值，字段时间戳，字段单位等。MQTT如何？它是否定义了这个？ – cid 2015-08-07 07:32:28

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"}

您还可以通过使用meta搭话对象树，例如：GET /woopsa/meta/，这将给你像即：

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

来源

2015-10-13 06:36:23

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

MQTT是一种消息传输层，不提供设计的互操作性。它没有规定有效负载的格式，也没有规定如何传输特定的数据类型，时间戳，值，层次结构或其他任何可以让应用程序理解正在传输的数据的内容。您可以创建一个有效的MQTT服务器，以发出纯文本，加密，base-64编码或其他任何您喜欢的XML，JSON或自定义格式的数据。客户端应用程序与服务器进行交互的唯一方法是事先知道服务器将生成和接受的数据格式。最近OPC-UA引入了发布/订阅机制来提高带宽利用率，从而降低了MQTT目前提供的通信带宽优势。同时，为了促进互操作性，MQTT规范将需要发展以指定数据格式。期望看到MQTT和OPC-UA之间功能的融合，大多数MQTT正在不断发展以满足OPC-UA。

MQTT目前简单得多，这对于嵌入式和资源受限的系统具有优势。数据建模规范的添加将起到减少这种优势的作用。

底线是OPC-UA是用于互操作性的，MQTT用于简单的定制通信。 MQTT需要成长才能成为OPC-UA的替代品。

来源

2016-05-05 11:17:58 asthomas

Unserver是专为解决此问题中描述的确切问题而设计的产品。

它能够与不同的现场设备交谈并在其上面提供统一的HTTP API（）。它通过Modbus RTU与设备集成，但将来会添加其他常用协议。

简而言之，首先你配置一个数据“标签”是这样的：

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

{ 
    data:{ 
    level: 1 
    } 
}

退房的documentation：

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

然后你可以使用API端点自动创建与标签工作获取更多信息。该产品免费供评估和非商业用途。

声明：我是团队的一员。希望这是有用的。

来源

2017-03-22 18:37:08 astreltsov

回答

相关问题