One of the consistent themes that has surfaced when working with industrial clients is their reliance on high performance rotating machinery. Whether it’s steam turbines delivering electrical power or compressors in mid stream gas fields, these machines are the foundation for most heavy industries. If you consider the combustion engine as a rotating machine as well, we are surrounded by equipment that has been engineered to spin large amounts of metal at significant frequencies for long periods of time. After spending some time with clients managing these machines, I am awed by the level of engineering required in these mechanical marvels of technology. I am also not surprised by the level of monitoring and maintenance required to keep these machines in action. With advances in sensors growing rapidly the management of these key industrial components has improved. Still, there are some challenges managing the sheer volumes of data generated by these highly measured and highly tuned machines. Predictive maintenance mathematics can now forecast a failure due to small changes in vibration, temperature or other variables. However, data frequency can overwhelm traditional SCADA systems which is why processing and anomaly detection has migrated to the edge over time.

Many SCADA systems have been developed to read operational data from rotating machinery at regular intervals for visual dashboard display and historian storage. But in most cases, the irregularities which can cause long term mechanical failures happen within milliseconds. Collecting and processing this data overwhelms traditional database technologies that cannot operate at this high speed on the edge - at the PLC.  For this reason high performance edge databases are required, which can store data at very high frequencies, filter out the noise, and then transmit the data only when certain operational thresholds are met. The solutions that support this type of edge computing and data distribution tend to have very large footprints, and leverage a store and forward methodology that moves the data from an edge device to a gateway through the control network. The main issues with this architecture is that the data volumes overwhelm the controls network and add a layer of complexity, which is expensive and difficult to maintain. 

In previous blogs I have discussed use cases for a single distributed database that can handle very high data volumes, embed filtering and analysis, and distribute only the data that meets a specific measurement threshold. For example, in vehicles this was RPM or oil temperature, and for electrical relays it was amperage and frequency. In these scenarios, the high frequency data was collected but not stored or distributed unless the values were useful to the organization. We were recently given the opportunity to again leverage this workflow to support the operation of a high performance compressor in a gas processing facility. 

Our client’s goal was to catch sub second irregularities in vibrations, which could be used to predict potential issues with their compressor. Their current system reads data from their ControLogix 1756 PLC at 5 second intervals and then inserts this data into their historian - which is too course to adequately identify inconsistencies. The recommended frequency for finding these irregularities would be 100ms, but streaming this volume of data across their control network and into the historian was not practical due to bandwidth and architectural considerations of the underlying database of the historian. 

The solution included the installation of a HarperDB edge node on a small device attached to the control network which would write a stream of PLC tags directly into a “raw data” table.  Over 250 tags were streamed every 100ms into the edge database,which immediately indexed the tags so they would be available for querying. Once indexed, the tags were queried against a table of threshold values for each tag. When a threshold was exceeded, two database operations were performed; first an event was created in an event table, then 60 seconds of high resolution data before the event and 30 seconds of data after the event were inserted into the event details table. Using the built-in clustering capabilities within HarperDB, the event and event details table are then automatically replicated to a HarperDB server node on their business network where the data can be analyzed and integrated into the historian. Instead of a steady stream of data overwhelming the control network and historian, the HarperDB edge database can maintain a steady stream of data and then filter and cluster only the data needed when an event occurs. 

Although significant events may only occur a few times per year, the immediate availability of this data provides key value to support maintenance of critical field assets. Implementing a high performance edge database with automated replication capabilities and a tiny footprint extends the capabilities of existing SCADA and historian applications, and allows end users to view critical high resolution data when they occur.