Mqtt OPC-UA的替代方案

作为访问由各种PLC组成的系统的过程数据的解决方案，OPC-UA是否有合适的替代方案？平台独立，可以与不同品牌的产品“对话”的东西

我听说过，但它似乎更像是一个传输协议，仅此而已。它没有像信息建模这样的所有更高层次的东西

---

谢谢你的帮助

OPC是与PLC通信的唯一标准方式。OPC DA是旧的替代方案。OPC-UA是目前最新推荐的一种。在OPC之前，只有专有协议和共享协议，如Modbus，但正如您所提到的，它们只是较低级别的传输协议

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

请注意，一些PLC还可以与OPC UA进行本机对话，这使得OPC UA成为一种标准

OPC UA真正标准化为IEC 62541，确保其独立性

更新17/07/19：OPC UA现在也被定义为我在最近的文章中写到的

---

更新20/05/05:OPC UA版本1.04定义了发布/订阅替代方案，使用UDP在本地网络中进行安全数据多播，使用AMQP/MQTT将基于代理的数据和事件安全交付到云系统。版本1.04还定义了WebSocket/JSON协议替代方案，使web应用程序更易于使用。这些都还没有普及，但有望在2020-21年的时间范围内流行起来。

MQTT作为I.o.T的首选协议越来越受欢迎。它确实有其缺点——然而，它的简单性通常被视为一种优势，而OPCUA承担了委员会设计的开销

---

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

< P> OPC-UA有一些非常有趣的部分，特别是关于信息建模、互操作性和发布/订阅模式。 然而，即使它是最严格意义上的标准，我发现要在webapp中使用它，您需要编写网关服务器代码。因为它使用原始套接字和二进制（尽管很快）序列化协议

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

我们刚刚在这里发布了1.0版：

您可以直接在我们的GitHub上获取源代码：

基本上，我们的协议只是一个使用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",
    ...
  ]
}

---

在实际工业应用中，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的替代品。

是一款旨在解决本问题中描述的确切问题的产品

它能够与不同的现场设备进行通信，并在网络上提供统一的HTTP API 在他们上面。 它通过Modbus RTU与设备集成，但将来将添加其他通用协议

简言之，首先要像这样配置数据“标记”：

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

然后，您可以使用自动创建的API端点处理标记：

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

{
  data:{
    level: 1
  }
}

有关更多信息，请查看。 该产品免费评估和非商业用途

---

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

我刚刚发布了另一种应对这一挑战的方法。该项目称为ELTRA IoT

它是云服务作为中介和终端用户组件，充当设备表示或操作员界面（）

它主要是为了简化CANopen设备与智能手机应用程序的集成，但我很快意识到