There are many tools on the market for historizing process data. These tools typically treat each point of data individually when historizing, which works great for trend screens and instrumentation reporting. However, it is often desirable to log a "set" or "group" of data together, associating many data points with a single event. This use case is particularly common with batching operations, where detailed records must be kept. This can be accomplished many different ways. One such approach, that of a so called “data pump,” is described below.
解决方案概述
我们应对这一挑战的解决方案之一是每次在设备上完成操作时创建和记录数据的“有效载荷”。例如，考虑将散装材料添加到混合罐中。该操作包含几个相关信息，可以历史化，例如：
- Start Time
- 时间结束
- 单位（例如：混合坦克102）
- Batch ID
- Event Description: (Ex: "Sucrose Addition")
- End Condition (Completed Naturally or Manually Aborted)
- Setpoint Amount (Requested Quantity)
- 实际金额（交付的数量）
- 错误％（[实际 - 设定点] / [setPoint] x 100）
- 泵速
- Etc.
为了捕获此信息，在每个操作中内置了PLC（可编程逻辑控制器）逻辑以收集相关数据。操作完成时，然后将该数据合并到PLC中的单个记录对象，通常是用户定义的数据类型。然后，该记录将其放在“首先，首先出局”的队列对象中。在控制系统（PLC外部）的其他地方，该队列被监视以获取新记录。随着新记录的出现，控制系统从队列的正面读取适当的数据，将其记录到SQL数据库表中，并与PLC握手，以表明该记录已成功处理。一旦在PLC级别收到握手后，就会索引队列以丢弃上一个记录，并将下一个记录向前移动以进行处理。在控制系统确认该记录的成功处理之前，没有从队列中删除任何记录。在此体系结构中，基本上确保了排队的数据记录。即使处理队列的机制失败，PLC（更重要的是，自动化过程）也可以按正常运行。在这种情况下，队列可能会积累未经处理的记录的积压，但是一旦将处理机制带回网上，它们就可以快速处理。 Providing a large enough queue object is important because it gives the data pump a buffer. This allows the control system to weather any interruption of communications that might occur between the PLC and the mechanism that processes the records.
Queue Sizing
PLC中的队列对象的尺寸应足够大，以积累几个小时的记录，使生产能够在交流问题进行故障和更正的同时继续进行。一旦恢复了通信，处理机制就可以通过记录的积压来相对迅速地工作。由于记录是按顺序处理的，并包括自己的时间戳，因此处理中的任何较小延迟都不会产生很少的后果。数据可能会稍微延迟从PLC到历史数据库，但是保留了该数据的完整性（和序列）。
警报 /故障
如果数据收集至关重要，则还应实现警报，该警报在队列退回时触发，并累积到记录的某些阈值。例如，如果队列尺寸可以支持500记录，则您可以选择在队列达到50或100时警报。选择警报阈值取决于队列的大小，在“正常”操作期间，队列往往是多么满，以及控制支持人员的预期响应时间（查找数据泵的任何问题）。
在队列完全填充记录的情况下，任何新记录都不能添加到队列中（因此不会记录到SQL数据库）。因此，还建议PLC逻辑持有生产（以及任何新记录的生成），直到可以解决该问题为止。否则，将发生无法正确历史的事件。但是，如果生产吞吐量比数据完整性更高，则集成商和最终用户可能会选择不持有其流程。在这种情况下，PLC只是丢弃任何“溢出”数据，而无论队列已满，该过程都将继续运行。
Additional Considerations
实施此类型的数据泵的一个优点是，您可以在记录处理机制上“ piggyback”，以触发控制系统中的其他操作。例如，使用新的“批处理”处理的记录可能表明该单元的先前批处理已完成，这意味着可以安全地生成并分发报告的报告。在另一个示例中，您可以选择标记食用原材料的事件，以便可以通过将材料使用向客户的ERP系统报告的其他过程运行。
技术实施
尽管最好使用FIFO对象和支持逻辑来处理数据泵的PLC部分，但处理记录的FIFO的机制可以采用多种形式。下面列出了一些选项，大约按ECS的建议顺序说明：
- 在通过电感自动化点火中，由SQL桥模块提供的交易组。这些是点火内的可配置对象，可以使用触发器，握手标签和SQL连接到表或存储过程。
- In Ignition, using Gateway scoped "Tag Change Scripts" that mimic the behavior of a Transaction Group but allow for more customization at the sacrifice of some convenience. Some sample screenshots of this implementation can be seen below.
- 在Rockwell Automation的FactoryTalk View SE中，使用VBA代码定期检查PLC是否有新记录，执行SQL数据库功能来处理数据，并使用PLC握手。
- Via a custom written application (typically a .NET windows service or similar) that is capable of both monitoring tag values in a PLC and also executing SQL functions.
Sample Implementation
Below is a partial sample of PLC logic that manages a FIFO of records. Note that the first rung handles processing of the queue (via the FFU instruction) and not the loading of the queue with new records (via the FFL instruction). Loading of the queue would be handled elsewhere in your PLC program. The second rung adds a brief delay before incrementing the "Record Rqst" trigger tag, which is monitored externally for change.
Here an Ignition Gateway Tag Change Script is shown, monitoring a "Record_Rqst" tag value within one of our S88Builder control systems. In this case the trigger is an integer tag in the PLC that is incremented any time a new record has been unloaded and is ready for processing.
Ignition then executes the following script (reduced here for simplicity). A more complete solution would implement error handling or might be implemented in a script library rather than directly within the Tag Change script.
Jordan Stoltz是工程总监 - 自动化生态系统ECS Solutions, a certified member of theControl System Integrators Association(CSIA). For more information about ECS Solutions, visit its profile on theCSIA工业自动化交流。
