19

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

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

谢谢你的帮助！

4

6 回答 6

19

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

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

请注意，某些 PLC 也可以原生地与 OPC UA 通信，这使其成为一种标准。

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

2019 年 7 月 17 日更新：正如我在最近的文章中所写，OPC UA 现在也被定义为工业 4.0 通信。

2005 年 5 月 20 日更新：OPC UA 版本 1.04 定义了 Pub/Sub 替代方案，使用 UDP 在本地网络中进行安全数据多播，使用 AMQP/MQTT 将基于代理的数据和事件安全传送到云系统。1.04 版还定义了一种 WebSocket/JSON 协议替代方案，可以更轻松地在 Web 应用程序中使用。这些都不是广泛可用的，但希望会在 2020-21 年的时间范围内流行起来。

于 2014-10-06T08:43:33.073 回答
9

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

然而，即使它是严格意义上的标准，我发现要在 web 应用程序中使用它，您需要编写网关服务器。因为它使用原始套接字和二进制（虽然很快）序列化协议。

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

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

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

基本上，我们的协议只是一个使用 HTTP+JSON 的标准化 RESTful API。例如，您可以通过 a 读取一个值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-13T06:36:23.043 回答
9

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

于 2016-05-05T11:17:58.237 回答
1

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

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

于 2015-07-27T18:59:01.620 回答
1

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

它能够与不同的现场设备通信，并在它们之上提供统一的 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
  }
}

查看文档以获取更多信息。该产品可免费用于评估和非商业用途。

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

于 2017-03-22T18:37:08.233 回答
1

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

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

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

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

第一个想法是提供解决方案，允许在短时间内使用 REST/JSON 等 Web 标准（避免二进制协议、网关、防火墙、代理问题和所有这些人员，这使得整个过程更加复杂）将您的设备接入互联网.

像 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 服务是我的私人网站

于 2020-08-22T06:14:26.350 回答