OPC-UA的替代方案

Question

作为访问由各种PLC组成的系统的处理数据的解决方案，OPC是否有任何合适的替代方案？什么是独立的平台，可以与不同品牌的产品“说话”？

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

谢谢你的帮忙!

Answer 1

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

OPC UA在信息建模方面是非常独特的，尤其是。有了这一特性，除了普通的PLC通信之外，它还为更高层次的系统和应用程序提供了新的通信可能性。

请注意，一些PLC也可以以本地的方式谈论OPC UA，这使它成为了这样一个标准。

并且OPC是真正标准化的IEC 62541，确保它是独立的。

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

更新20/05/05: OPC UA版本1.04定义Pub/Sub备选方案，使用UDP实现本地网络中的安全数据多播，使用AMQP/MQTT实现基于安全代理的数据和事件向云系统的传递。版本1.04还定义了WebSocket/JSON协议替代方案，这使得在web应用程序中更容易使用。所有这些都没有广泛提供，但希望在2020年至21年间流行起来。

Answer 2

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

然而，尽管它是一个严格意义上的标准，但我发现要在the应用程序中使用它，需要编写网关服务器。因为它使用原始套接字和二进制(虽然快速)序列化协议。

这就是为什么我们在我的大学里创建了一个叫做Woopsa的替代协议。我们决定基于HTTP + JSON。我们试图制定一个类似OPC的协议:它有信息建模、发布/订阅，甚至还有多个请求。都是完全开源的。

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

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

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

Answer 3

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

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

OPC最近引入了一种发布/订阅机制，以提高带宽利用率，从而减少了MQTT目前提供的通信带宽优势。同时，MQTT规范需要扩展以指定数据格式，以促进互操作性。期望看到MQTT和OPC之间功能的融合，主要是MQTT增长以满足OPC。

MQTT目前是一个简单得多的实现，它对于嵌入式和资源受限的系统具有优势。添加数据建模规范将减少这一优势。

底线是OPC用于互操作性，MQTT用于简单的自定义通信。在成为OPC的替代品之前，MQTT需要成长。