技术文章

监控工业信息网络对于确保性能、减少计划外停机以及优化日常生产中的能源使用至关重要。监控这些网络的一个重要方面是了解所使用的协议，其中最常见的是 HTTP、OPC UA 和 MQTT 等。在本文中，我们将特别关注监控 MQTT，随着 IIoT（工业物联网）的兴起，MQTT 在运营技术网络中变得越来越常见。 

那么如何解决监控MQTT的任务呢？其中一项要求是拥有方便可靠的工具供您使用，例如MQTT 往返传感器。但另一个关键点是了解正在使用的 MQTT 架构，它可用于了解数据流并进行故障排除，并在出现任何问题时采取有效措施。这意味着您需要了解所使用的MQTT 代理、高可用性要求等因素。

在以下部分中，我们将简要研究可靠、高可用和高性能环境中使用的 MQTT 架构。但首先，我们来看看什么是 MQTT 代理和主题。  

MQTT：为什么、如何、什么？

通信是工业生产网络车间层面的关键价值。正如您可以想象的那样，工作人员习惯于在整个工作日使用通讯应用程序在团体或个人之间轻松发送、接收或共享信息，以确保任务完成。MQTT 是一种轻量级标准化协议，通常由机器和控制器用来在组中或在特定实体之间发送、接收或共享信息。这个概念与个人消息应用程序非常接近。因此，MQTT 被广泛应用于工厂、城市、家庭和车辆的许多智能应用中。

一个人可以发布特定主题的信息，其他人可以订阅这些主题以立即接收所发布的信息。管理已发布消息的分发的实例就是所谓的消息代理。该软件可以在 Raspberry Pi 等小型嵌入式设备上运行，也可以在 Cedalo 的Pro Mosquitto MQTT Broker等云服务中运行。

此时，关于MQTT 客户端（例如 PLC 或智能传感器设备）需要考虑的要点是：

• 他们可以发布有关主题的消息（例如“温度/来自/传感器A”）

• 他们通过 MQTT 代理接收来自订阅主题（例如“温度/来自/sensorB”）的消息

• 他们保持与已建立的代理的连接或在连接丢失时重新连接

有关 MQTT 的更多详细信息，请查看IT 解释：MQTT。

MQTT 代理的连接性和功能对于确保这种通信以及信息的传输至关重要，因此持续监控代理的状态并建立高可用性架构是一个好主意。

MQTT架构

如前所述，从客户端的角度使用 MQTT 非常简单 – 发布和订阅主题。但是，根据信息安全性、可用性的要求以及数据产生/消费的不同地点，实现信息传输所需的架构可能会有所不同。我们将了解基本的 MQTT 架构，然后转向高可用性代理、 MQTT 架构的真实场景以及静态与动态消息映射，所有这些对于设置监控时理解都很重要。 

基本 MQTT 架构

在基本架构中，同一位置有多个客户端和一个经纪商。本质上，“同一位置”意味着底层网络通信不需要通过互联网连接跨越边界。

例如，信息通过 MQTT 代理使用 TCP 以太网连接从一个客户端传输到另一个客户端（参见图 1）。

图 1  - 基本 MQTT 架构：同一位置的一个代理和多个客户端

该架构可以轻松地针对本地部署和少量客户端（< 500）进行设置，而无需使用传输加密（TLS），因为其他机制可以保护网络免受侵犯。基本架构的优点是设置过程简单并且提供大量客户端软件包。

在生产环境中使用此架构的一个缺点是管理访问权限。这意味着不同的客户端可以或不能访问每个主题，并且当客户端数量增加或消息发布率较高时，可能会出现性能和可用性问题。因此，为了准备可扩展的高性能架构，需要一个具有访问管理 API 的高可用性代理，这将在下一节中介绍。

高可用性 MQTT 代理的概念

基本架构使用一个代理。但是，您可以让来自不同位置的客户端通过互联网与经纪商进行通信。如果您对 MQTT Broker 的可用性有很高的要求，那么高可用性集群（HA Broker）的概念就发挥了作用。

此 HA 代理是使用同一代理的三个、五个甚至更多实例（节点）来实现的。这些节点可以位于不同的可用区域，通常位于基础设施提供商的服务器上。有关管理代理的多个节点（以及不同的集群模式）的示例，请参阅Mosquitto MQTT 高可用性及其不同的集群模式。

图 2  - 具有三个集群节点和区域冗余端点的 HA 代理

存在不同的概念来实现这些 HA 代理（对于德国读者，这篇 heise 在线文章很好地概述了它）。

一种方法是选择一个集群代理（节点）作为主节点并管理流量。与此同时，其他代理仍处于备用模式，并且可以在几毫秒内设置为主代理。

从足够高的角度来看，HA 代理提供可通过互联网、本地网络或虚拟专用网络 (VPN) 访问的端点，保证 99.9% 或更高的技术可用性，与消息数量或数量无关。连接的客户端。可能有数千或数万个客户端而没有注意到任何性能泄漏。节点故障的监控和反应由底层软件自动完成，例如代理实例的集群扩展插件。您可以阅读有关Mosquitto 高可用性集群的技术详细信息以获取更多信息。

MQTT 架构可能的真实场景

在现实世界中，生产信息网络数据流或流使用不同的协议。例如，一种常见的方法是使用 Webhook（HTTP、POST）进行数据接收器或流分析摄取。另一方面，生产环境中的数据源由具有实时功能的PLC或嵌入式PC组成。这里经常使用MQTT协议。根据自动化金字塔的概念，信息网络中的实体可以按照信息层次进行排列（见图3）。

图 3  - 数据消费者和数据接收器上下文中可能的生产环境场景的不同信息级别的概念视图。

必须就数据处理实例（即 MQTT 代理）的位置做出额外的单独决策 - 无论是在本地还是在云端。后者可以进一步分为使用共享或专用基础设施。

这种方法将产生以下高级要求：

• 不同位置的多个客户端以及使用桥接和高可用性集群的多个代理必须进行通信。

• 可靠的公司级站点到站点连接需要通过 VPN、专用电缆连接或使用 HTTPS 数据传输来建立。

• 需要一个主题命名和元数据值排列的一致概念。

让我们详细看看第一个高级要求。基本的 MQTT 架构可用于在客户端之间提供即时通信和数据流，如上所示。图 3 演示了代理可以在本地实现为具有多个节点的 HA 代理。Broker 1、2、3 为不同的生产线或物流基础设施提供消息分发服务。

互连这些代理的关键功能称为桥接。桥接 MQTT 代理可以在不同级别或站点之间映射消息。例如，您可以将主题命名为“from_level_0”或“energy_metrics_for_facility_mmgt”。有关桥接的更详细说明，请参阅Mosquitto Bridge 配置说明博客。

最终，经纪商的桥接功能确保位于不同信息级别或不同位置的客户可以通过多个桥接经纪商交换信息。对于这种情况，代理是托管在本地还是在云中并不重要。

对于监控而言，主要挑战是协调和定义主题命名约定和主题映射。构建消息循环的风险随着涉及的代理数量的增加而增加。检测消息循环和冗余流量是需要流量分析功能的另一个挑战。

在图 3 所示的场景中，还存在从 MQTT 到 HTTP 协议桥接的情况。这对于选定的主题有意义，因此，聚合它们并将它们存储在由公司级别的 Webhook 提供的中央数据湖中的特定信息是有意义的。

静态与动态消息映射

上述架构（参见图 3）可以通过 MQTT 桥接的静态配置来实现。但随着我们将可能的用例付诸实践，对智能动态桥接的需求可能会增加。

想象一下，如果在公司层面，您发现高度聚合的 BI 报告缺少某个指标或信息。然后，您可以向 AI 机器人发出请求，并提示：“对于下一个月营业额评估期，请提供每条生产线 AGV 运行公里数总和的条形图。” 这当然可能是未来的功能需求。

然后，执行功能必须自动重新定义各个级别的桥接配置，以确保数据从 AGV 传输到中央数据湖。从技术上讲，已经可以使用MQTT API 和 REST API等远程接口来使用一个构建块来更新 MQTT 代理配置。这可以称为智能动态桥接，是更高级 MQTT 架构的起点。