作为访问由各种 PLC 组成的系统的过程数据的解决方案，是否有任何不错的替代 OPC-UA 的解决方案？独立于平台并且可以与不同品牌的产品“对话”的东西？
我听说过MQTT，但它似乎更像是一种传输协议，仅此而已。它没有信息建模等所有更高级别的东西。
感谢您的帮助！
【问题讨论】：
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，正如我在最近的文章中所写的那样。
2005 年 5 月 20 日更新：OPC UA 版本 1.04 定义了 Pub/Sub 替代方案，使用 UDP 在本地网络中进行安全数据多播，使用 AMQP/MQTT 将基于代理的数据和事件安全传送到云系统。 1.04 版还定义了一个 WebSocket/JSON 协议替代方案，可以更轻松地在 Web 应用程序中使用。这些都还没有被广泛使用，但希望会在 2020-21 年的时间范围内流行起来。
【讨论】：
MQTT 作为 I.o.T 的首选协议越来越受欢迎。它确实有缺点 - 但是它的简单性通常被视为一种优势，而 OPCUA 承担了委员会设计的开销。
如果您需要将两者结合起来，您可以考虑尝试我们的简单网关mqtt2opcua
【讨论】：
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。例如，您可以通过 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 的替代品。
【讨论】：
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
}
}
查看documentation 了解更多信息。 该产品可免费用于评估和非商业用途。
免责声明：我是团队的一员。希望这有用。
【讨论】：
我刚刚发布了应对这一挑战的另一种方法。该项目名为 ELTRA IoT。
它是云服务作为中介和最终用户组件，充当设备表示或操作员界面 (https://www.eltra.ch/)
创建它主要是为了简化 CANopen 设备与智能手机应用程序的集成，但我很快意识到它可以用于任何物联网项目。
这个项目的灵感主要来自 CANopen 和 FDT 架构。
第一个想法是提供解决方案，允许使用 REST/JSON 等 Web 标准将您的设备接入互联网（避免二进制协议、网关、防火墙、代理问题和所有这些人员问题，这会使整个过程更加复杂）短时间内。
像 HTTP/REST/JSON/WebSocket 这样的 Web 标准与所有操作系统和架构都兼容，并且还允许以任何现代语言轻松集成最终用户应用程序。
主要特点：
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 服务是我的私人网站
【讨论】：