Question

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

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

感谢您的帮助！

Answer 1

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＆amp; AMQP，首先是MQTT），并且还将定义WebSocket / JSON协议替代方案，这将使用于Web应用程序。

Answer 2

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",
    ...
  ]
}

Answer 3

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

Answer 4

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

如果您需要将两者合并，您可以考虑尝试使用我们的简单网关mqtt2opcua

Answer 5

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

它能够与不同的现场设备通信并提供统一的HTTP API 最重要的。它通过Modbus RTU与设备集成，但将来会添加其他常用协议。

简而言之，首先要配置数据标签＆＃39;像这样：

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

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

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

{
  data:{
    level: 1
  }
}

查看documentation了解详情。该产品可免费评估和非商业用途。

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

Answer 6

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

作为中介和最终用户组件的云服务，它们充当设备表示或操作员界面（https://www.eltra.ch/）

主要是为了简化CANopen设备与智能手机应用程序的集成而创建的，但是我很快意识到，它可以用于任何IoT项目。

该项目的主要灵感来自CANopen和FDT架构。

第一个想法是提供解决方案，该解决方案允许您使用REST / JSON之类的Web标准将您的设备连接到Internet（避免使用二进制协议，网关，防火墙，代理问题以及所有这些人员，这会使整个过程变得更加复杂）在短时间内。

诸如HTTP / REST / JSON / WebSocket之类的Web标准在所有操作系统和体系结构中都可以很好地运行，并且还可以轻松地以任何现代语言集成最终用户应用程序。

主要功能：

相同的API双方（设备和操作员）
CANopen CiA-311数据模型表示
节点，对象字典，索引，子索引，强数据类型，范围等。您知道CANopen =您在家
历史数据
RPC支持-自定义命令执行
简单的云服务API https://eltra.ch/docs
标准身份验证方案
SSL加密
用于Windows，Linux，Android，IPhone，Raspberry PI的跨平台解决方案

SDK在Github上可以作为开源软件使用

https://github.com/eltra-ch/eltra-sdk

目前，该库已在.NET Standard中实现，并已在Windows，Linux（x64和ARM32），Android，iPhone上进行了测试。

Nuget软件包位于以下位置：

https://www.nuget.org/packages/Eltra.Connector/

如果OPC UA的复杂性过高而Woopsa不适合您的设计，则ELTRA可以替代。

免责声明：该项目是我的硕士学位论文的一部分，而eltra.ch服务是我的私人网站

OPC-UA的替代品

6 个答案: