使用 ctrlX CORE 和 InfluxDB 构建下一代智能 PLC

作者：Jay Clifford / 开发者
2024年2月28日

本文最初发布在 IIoT World 上，此处经许可转载。

程序逻辑控制器（PLC）自 20 世纪 60 年代首次创建以来，在工业自动化中扮演了至关重要的角色。 自那时起，我们在其形态和功能方面看到了渐进式的改进。问题是？虽然 PLC 在管理和控制工业过程中表现卓越，但现代制造业不断发展的需求要求这些设备不仅要控制机械设备。制造商现在寻求利用 PLC 的计算能力来完成更复杂的任务，尤其是在监控机器的健康状况方面。对效率、 预测性维护 和实时数据分析的需求推动了这一转变。那么，这是否意味着我们需要重新思考组织和使用 PLC 的方式呢？

在本博客中，我们将探讨下一代 PLC，即 Rexroth 的 ctrlX core，以及我们如何利用这个平台来整合最佳开源项目，如 InfluxDB 和 Grafana，以创建一个现代化、互联的异常检测堆栈。

PLC 究竟是什么？

在我们继续前进之前，让我们分析一下标准 PLC 的架构和作用。 上述图解将 PLC 分解为其核心组件

• 输入模块：从传感器、开关和按钮等输入设备接收信号，并将这些信号转换为 PLC CPU 可以处理的格式。
• 输出模块：从 PLC 发送控制信号到电机、阀门、灯光和继电器等输出设备。
• 电源：将主交流电（AC）转换为低电压直流电（DC），为 PLC 组件供电。
• CPU（中央处理器）：处理程序数据和指令，根据编程逻辑执行控制操作。它处理逻辑操作、算术操作、排序、计时、计数和数据操作。
• 内存：用于存储用户加载的控制程序。这通常包括易失性内存和非易失性内存类型。易失性内存（如RAM）在操作期间临时存储数据。非易失性内存（如ROM、EEPROM）存储PLC程序，即使在断电后也能保留。
• 编程设备：用于将所需的程序输入到PLC的内存中。

我相信分解PLC的架构有助于消除其设计背后的模糊性。在最简单的情况下，它是一个坚固的计算机，可以重复执行和执行程序。

为了巩固这个想法，让我们看看一个场景来展示PLC的功能： 在上述场景中，PLC自动控制输送带的运动

• 启动/停止控制
  • 按下启动按钮会将信号从PLC发送到电机控制继电器，激活输送带。
  • 按下停止按钮或激活紧急停止会立即发送信号，使电机控制继电器失效，停止输送带。
• 物体检测和处理
  • 光电传感器检测输送带上的物体。
  • PLC可以计数物体，控制它们的间距，并在检查或包装等特定操作中使带子停止。
• 速度控制和监控
  • 速度传感器向PLC提供反馈。
  • PLC调整电机速度以保持输送带速度的恒定，这对于与其他机械同步操作至关重要。
  • PLC还可以响应用户进行的手动速度调整。

有了对PLC工作原理的基本了解，下一代的PLC如ctrlX core是如何迭代这个设计的，以及InfluxDB在其中扮演什么角色呢？

下一代PLC

正如我们所知，大多数标准PLC都有一个嵌入式处理器，用于执行设计的程序。通常，这意味着PLC带有自己的专有操作系统（例如，西门子的SIMATIC Step 7用于其S7 PLC和Rockwell的RSLogix用于Allen-Bradley PLC），在嵌入式处理器上运行。这对于提供容错和性能执行引擎非常出色，但几乎没有扩展空间。

另一方面，ctrlX core提供了一个灵活的硬件规范，这使得制造商可以根据特定任务的需求控制PLC的电源级别。PLC还部署了一个名为Ubuntu IoT Core的Linux操作系统，提供了扩展核心功能和服务的灵活性，用户可以在PLC上安装这些功能和服务。让我们回顾原始的PLC架构，并修改它以反映ctrlX core的设计： 我们在我们的PLC设计中引入了两个新的方面

• 数据平面：这取代了内存中的标准操作数据。它仍然为我们的PLC程序提供访问输入和输出数据的方式，以及一个网关，允许第三方应用程序订阅和发布数据。
• 第三方应用程序：因为我们现在使用的PLC是基于Linux的发行版，我们可以利用内置的Linux服务，例如容器化。这允许开发者在ctrlX core上构建和部署dockerized应用程序，以便与数据平面进行接口。

InfluxDB和Grafana在其中扮演什么角色？我们如何利用这些新的服务和ctrlX core的额外计算能力？

开源数据历史记录器

InfluxDB是一个开源的时间序列数据库，从头开始设计，专门用于处理大量时间序列数据。近年来，它已成为许多下一代数据历史记录器的基石，这些记录器正在取代标准的关系数据库。我们可以将这种转变归因于InfluxDB的几个独特特性

• 高吞吐量数据摄入：InfluxDB有效地管理来自多个并行来源的数据摄入，非常适合大量数据生成的环境。
• 写入时模式灵活性：它提供了一种“写入时模式”方法，允许灵活且快速地存储数千个机器标签，而无需预设计模式。这使得它可以适应不同的数据结构。
• 低系统需求：由于安装和运营需求最小，InfluxDB是本地数据存储的有效解决方案，可以为其他关键的PLC过程节省硬件资源。
• 高级基于时间的查询：在各个时间粒度（秒、分钟、小时、天等）上执行有效的时间聚合（如平均值、总和、最小值、最大值）。
• 高分辨率时间戳：高粒度的时间戳（高达纳秒级精度）使其适用于详细级别上的精确机械设备监控。

用户可以通过其第三方应用商店直接在ctrlX core上安装InfluxDB。这将自动安装最新的开源实例。那么，这对我的站点工程师有什么好处呢？让我们回顾一下我们的传送带示例。

机器异常检测

在这个示例中，我们将ctrlX core部署到我们的传送带上。像以前一样，PLC程序包括以下功能

• 停止/启动控制
• 物体检测和处理
• 速度控制和监控

除此之外，我们还将部署InfluxDB作为本地边缘数据历史记录器。InfluxDB将连接到ctrlX core数据平面，并从传送带伺服器摄入以下健康指标

• 振动
• 速度
• 温度

在下图所示的标准操作期间，系统将存储这些传感器指标到InfluxDB。Grafana直接连接到InfluxDB，在HMI上直接向用户显示这些原始指标读取： 这是在行业中的标准做法。然而，使用InfluxDB OSS（开源软件）内置的任务引擎，我们可以对历史数据和当前遥测数据进行自动分析，以查找趋势。在这个InfluxDB任务中，我们将历史读数与当前指标进行比较，发现温度和振动都有上升趋势。我们使用这些数据通过Grafana发送警报，通知现场工程师我们的当前遥测读数表明其中一个电机正在承受不断增加的压力，可能需要维护。

这种场景为InfluxDB和Grafana如何将预测性维护和异常检测直接引入PLC提供了一种基本方法。这种方法的优点是，在识别和警报潜在故障时，延迟更低，因为这些过程发生在数据源附近。我们还使用了PLC的硬件功能，而不是引入另一个边缘设备来执行此分析。

边缘数据复制

最后，作为额外的功能，InfluxDB OSS具有一个内置功能，可以从一个InfluxDB实例将数据写入另一个远程InfluxDB实例。这可以是InfluxDB 无服务器、专用、集群（本地），甚至是另一个远程InfluxDB OSS实例。 此功能允许您将来自不同生产线的数据进行聚合，以便进行进一步分析。一些资产包括

• 同一类型生产线的异常检测——发现是否有生产线开始偏离其他生产线。
• 提高组织透明度。例如，如果您的数据科学家需要真实机器数据来训练机器学习模型，此功能提供了一种非侵入式的方式将所需数据卸载。
• 固有安全性。InfluxDB充当OT和IT网络的中间数据写入器和接收器——数据仅单向移动。

结论

工业4.0的演变迫使许多制造商创造性地思考如何从车间地面上的PLC中提取、存储和分析数据。对于许多较旧的系统，这种做法不会改变（在这些情况下，结合PTC Kepware和InfluxDB，大多数PLC都能解决这个问题）。然而，我希望这篇博客在您考虑将新设备引入生产线时能为您提供帮助。新一代PLC，如ctrlX core，从头开始构建，以适应作为强大机器控制器和边缘计算设备的双重灵活性。与开源项目如InfluxDB和Grafana搭配使用，您将能够开发出成本效益高的解决方案，以实现机器健康分析的自动化。

为了了解配置InfluxDB有多简单，我强烈推荐查看这个互动演示。我还建议您查看Rexroth在如何将InfluxDB安装和配置到ctrlX core上的教程。如果您对这篇博客或InfluxDB有任何疑问，我强烈推荐加入InfluxDB 社区。