过程数据在全厂资产健康生态系统中的重要性
即使是对大多数bent利内华达监控平台和System 1资产健康管理应用程序本身的粗略审查，也显示了引入过程数据的能力。在我们的硬件平台中，有典型的输入通道或模块类型，可以配置为接受比例直流电压或比例4-20 mA电流信号。在我们的System 1软件中，过程数据可以通过各种数字协议导入，包括Modbus, OPC-DA，以及从版本21.1开始的OPC-UA。但是，由于存在许多将流程数据导入系统1的机制，因此一个更基本的问题是，“为什么这种数据类型很重要?”
简单的答案是过程数据告诉我们环境和背景机器在其中运行。示例包括吸入和排出压力、气体温度和成分、泵、涡轮机或压缩机内的质量流量、发电机中的电气负载和功率因数、燃气轮机入口的环境空气温度、润滑油过滤器的压力以及许多其他参数。
所有这些都直接或间接地影响着机器。
如果没有过程数据提供的背景信息，通过严格观察振动数据来理解机器的行为并诊断问题通常几乎是不可能的。泵或水轮机空化时的振动水平与机器不空化时的类似振动水平非常不同。同样，加载时的行为与卸载时的行为是不同的。
如果你认为我夸大其词，不妨考虑一下内华达机械诊断服务全球总监尼古拉斯•帕姆顿最近的一句话。当被问及是否有能力为使用System 1安装的客户进行远程机械诊断时，他非常强调:“我们必须有过程和助剂的系统1的数据，否则我们将无法进行状态监测。”通过过程数据，尼古拉斯谈论的是过程流体本身的参数，如泵、压缩机和涡轮机——吸入和排出压力、吸入和排出温度、流量等。尼古拉斯所说的辅助数据是指机器周围辅助系统的工艺数据，如密封油、润滑油、中间冷却器等。他说的是可以影响机器的上游和下游的参数，比如敲鼓内部的条件，通过入口过滤器，以及许多其他可以引用的参数。它们的共同点是，所有这些通常都被认为是“过程数据”，并且在试图确定因果关系时都很重要。机器是否因加工过程中的异常而出现故障?由于操作超出规格?还是纯粹的机械问题发生在轴承、密封、联轴器或基础上，或者电机或发电机的电气问题?简短的回答是，没有过程数据来增加可用的振动数据，答案往往是不可能确定的。虽然诊断医生可能能够识别异常振动的多种可能原因，但他们往往无法分离出一个真正的原因。
我们的客户也普遍认同尼古拉斯的观点。例如，我们最近有机会与一位经验丰富的旋转机械工程师交谈，他支持他公司的全球石化设施。多年来，他甚至根据他在该领域诊断机械问题的丰富经验为我们写了一些Orbit文章。我们直截了当地问他，如果没有过程数据，他是否会尝试诊断机械问题。他的回答非常有见地:“如果你想那样做，你是在自找麻烦。”他解释说:“在极少数情况下，你可能可以在驱动程序上运行它，但几乎不可能在驱动机器上运行，因为这个过程对它的影响太大了。即使是像汽轮机这样的驱动器，你也需要知道阀门位置等基本工艺参数。”他接着解释说，这在他的公司很少是一个问题，因为过程数据很容易通过他们的PI系统历史记录在本地和远程获得。但他确实指出，这些数据的可用分辨率有时可能是个问题。它们的历史记录大约每10秒捕获一次更新的过程条件。
正如这位客户所指出的，以10秒分辨率处理数据通常就足够了，但并非总是如此。对于非常快速的过程波动，例如在压缩机喘振及其特征的快速流量反转期间发生的波动，即使是1秒的数据也可能不够，因此需要使用真正的动态压力传感器，而不是适合相对缓慢变化变量的变送器。专用的防喘振控制器和喘振检测平台将包含这样的传感器，通常允许用户看到动态压力脉动，并在控制器采取规避行动之前计算发生的喘振循环次数。
但除了特殊情况外，在处理数据时，多快才算足够快呢?答案是，在大多数情况下，1秒的数据对于机械诊断目的来说绰绰多，并且通常可以从这个分辨率的过程控制系统中获得-即使历史机没有以该分辨率保存它。如果1秒的数据不切实际，那么在大多数情况下，10秒的数据就足够了。最终，关于足够的数据分辨率的决定将由所涉及的材料的物理特性以及变量在实践中变化的速度来决定。例如，燃气轮机入口的环境空气温度在10秒内不会发生显著变化。工艺流的气体成分波动也不可能超过10秒。因此，10秒的分辨率就足够了。相比之下，流体膜推力轴承中巴氏体温度的10秒分辨率可能不够，因为在推力载荷快速变化的情况下，巴氏体温度会发生非常迅速的变化。
总的来说，虽然1秒数据(甚至10秒数据)通常足以用于机器诊断，但有时需要更快的速度。例如，故障(例如压缩机喘振)10秒的数据可能太慢了。
它可能是在导致机器故障的时刻，需要详细的事件序列来确定是进程触发了机器，还是机器触发了进程。它可能是在警报或绊倒后的瞬间，以确保随后的事件按照预期发生，而不是在10秒甚至1秒的趋势中无法明显看到的意外异常。幸运的是，我们理解这样的需求，并设计了System 1来解决这些问题，允许在必要时以200ms的间隔收集System 1服务器中最多20%的进程点。由于很少需要这种分辨率的连续数据，因此可以配置基于状态的触发器，以不同的分辨率收集过程数据，在需要时提供超高分辨率，在不需要时提供“正常”分辨率(通常为1秒)。
如果流程数据在历史记录中对您可用，为什么需要通过将其导入系统1并将其存储在系统1数据库中来复制该数据呢?好问题。有几个非常令人信服的理由说明这是有道理的。
Ease-of-correlation
当数据存在于两个不同的系统中时，您可以从两个系统中导出数据，并将其导出到Microsoft Excel等通用环境中，以构建多变量趋势，但这可能非常耗时。你也可以使用两个屏幕(或分屏)，直观地比较两个系统的趋势，但当你必须调整每个系统中的水平轴以获得相同的时间尺度时，这同样是麻烦和不精确的。当两种类型的数据都存在于系统1中，并且可以简单地选择多变量趋势时，这要容易得多。时间尺度可以很容易地改变，甚至可以建立X-Y图，如振动与负载，流量或压力。如果没有导出到Excel的繁琐过程，这在两个不同的系统中是不可能实现的。
最佳分辨率
正如我们所指出的，1秒甚至10秒的数据通常就足够了，但是在需要更快的200ms分辨率的情况下，您的历史记录不太可能以这些速率存档数据，即使它能够这样做。负责运营数据的OT人员可能要管理数十万个标签，并且默认分辨率要低得多，例如5秒或10秒的数据。系统1不会让过程历史学家负担这些细节。它只是在需要的时候以所需的分辨率获取所需的数据。
更强大的决策支持
同样的道理，我们发现旋转机械工程师很少会仅仅依靠振动数据来诊断问题，当系统1能够访问过程数据并将其作为基于规则的人工智能的一部分时，它的决策支持能力会更加有效。
您可能已经假设到目前为止的讨论都是关于关键机器资产的。但事实是，过程数据在监控不那么关键的资产方面也很重要。通过便携式数据收集方法来处理工厂范围内的资产是很常见的，越来越多的无线系统可以自动收集数据，甚至可以进行异常检测和诊断。正如过程数据在监控关键资产和了解机器振动变化的背景方面很有价值一样，它在不那么关键的资产中也很有价值。
正如我们的一位客户多年前所说的那样:“泵不会死，它们会被杀死。”他说的是操作人员通常没有意识到某些工艺条件会对机器造成难以置信的损害。泵的空化是一个经典的例子，但还有其他的例子。当资产的振动发生变化，或者它的磨损速度似乎比预期的要快时，知道是这个过程本身导致了机器的死亡，还是及时发现问题以防止机器的死亡，这不是很好吗?
整个工厂还有另一个方面，那就是所谓的固定(即非旋转)资产。当您考虑大多数工厂中的管道、容器、热交换器、锅炉、储罐、过滤器和其他静态设备的数量，甚至查看分配给它们的维护团队的规模时，很明显，用于维护固定资产的资金远远超过用于维护旋转资产的资金。在这些资产上花费更多资金的原因之一是，对这些资产进行连续甚至间歇监测的技术很少与旋转机械的技术相提并论。因此，经常使用基于检查的方法。
然而，一个巨大的未开发的潜力是过程数据。这些资产中的每一个都有与之相关的过程变量。油箱液位。液体温度。流。正如那位客户关于泵被“杀死”的评论一样，我们从研究管道腐蚀的人那里听到了同样的事情。它不会以恒定的线性方式腐蚀。当暴露在不规范的条件下，它通常在几分钟或几小时内就会比在规范条件下数月或数年降解得更多。因此，测量管壁厚度可能需要人工检查，但监控通过管道的特性可能已经在您的过程控制系统中，因此不需要额外的传感器。您只需开始将来自这些传感器的数据用于其他目的:作为管道可能不喜欢的条件的代理。 Differential pressure across filter elements might be another example. Or flow imbalances that might tell you something is leaking. The list goes on and on. Why not bring the process data from those fixed assets into System 1 and start using it for this additional purpose? One customer, in fact, uses System 1 for exactly that purpose and hasn't even added their rotating equipment yet!
作为状态监测程序的一部分，过程数据重要吗?是的——我希望这篇文章已经充分说明了这一点。但不要错误地停止使用你的关键机器。想想整个工厂，你甚至没有理由停止使用旋转机器。在不添加任何额外传感器的情况下，您可能会发现，您可以通过简单地监视过程数据来提高固定资产的可靠性，而不仅仅是为了控制目的。
我们的专家
杰弗瑞Sipek
软件产品经理
生物
作为软件产品经理，Jeff倾听客户需求并为System 1 Analytics建立方向。在Bently Nevada工作期间，Jeff在基于状态的维护和资产管理方面积累了30年的经验。