The Importance of Process Data in a Plantwide Asset Health Ecosystem
Even a cursory review of most Bently Nevada monitoring platforms - and the System 1 Asset Health Management application itself - reveals the ability to bring in process data. In our hardware platforms, there are typically input channels or module types that can be configured to accept proportional DC voltages or proportional 4-20 mA current signals . In our System 1 software, process data can be imported via a variety of digital protocols, including Modbus, OPC-DA, and beginning with release 21.1, OPC-UA. But since numerous mechanisms exist for getting process data into System 1, a more fundamental question is, "Why is this data type important?"
The simple answer is that process data tells us the environment and context in which the machine is operating. Examples include suction and discharge pressures, gas temperature and composition, mass flow within a pump, turbine, or compressor, electrical load and power factor in a generator, ambient air temperature for a gas turbine inlet, pressure across a lube oil filter, and many other parameters.
All these directly or indirectly impact the machine.
Understanding a machine's behavior and diagnosing a problem by looking strictly at vibration data and without the context afforded by process data is often next-to-impossible. Vibration levels while a pump or hydraulic turbine is cavitating are very different from similar vibration levels when the machine is not cavitating. Likewise, behavior under load is different than behavior when unloaded.
If you think I'm overstating, consider this recent quote from Nicolas Péton, Bently Nevada's Global Director for Machinery Diagnostic Services. When asked about the ability to do remote machinery diagnostics for a customer using their System 1 installation, he was absolutely emphatic: "we must have process and auxiliaries' data within System 1, or we will not be able to do condition monitoring." By process data, Nicolas is talking about the parameters of the process fluid itself in things like pumps, compressors, and turbines - suction and discharge pressures, suction and discharge temperatures, flow, etc. By auxiliaries' data, Nicolas means process data specific to the auxiliary systems surrounding the machine - seal oil, lube oil, intercoolers, etc. And he is talking about the parameters upstream and downstream of the machine that can impact it, such as conditions inside a knockout drum, across an inlet filter, and many others that could be cited. The common denominator is that all are generically thought of as "process data" and all are important when trying to ascertain cause-and-effect relationships. Is the machine misbehaving due to anomalies in the process? Due to operation outside of specifications? Or is a purely mechanical issue happening in a bearing, seal, coupling, or foundation - or electrical issue in a motor or generator? The short answer is that without process data to augment the available vibration data, the answer is often impossible to ascertain. While diagnosticians may be able to identify multiple possible causes for abnormal vibration, they will frequently not be able to isolate the one true cause.
Nicolas's observation is widely echoed by our customers, as well. For example, we recently had a chance to speak with a seasoned rotating machinery engineer who supports his company's global petrochemical facilities. He's even written some Orbit articles for us over the years based on his extensive experience diagnosing machinery problems in the field. We asked him straight out if he would attempt to diagnose a machinery problem without process data. His answer was very insightful: "You're asking for trouble if you try to do that." He elaborated, "In a very small number of instances you might be able to get away with it on the driver, but almost never on the driven machine because the process affects it so much. Even on a driver like a steam turbine, you really need to know basic process parameters like valve position." He went on to explain that this was rarely a problem within his company, because process data is readily available locally and remotely via their PI System historian. But he did note that the available resolution of this data could sometimes be a problem. Their historian captures updated process conditions approximately every 10 seconds.
As this customer pointed out, process data at 10-second resolution will usually suffice, but not always. For very fast process fluctuations, such as incurred during compressor surge and its characteristic rapid flow reversals, even 1-second data may be insufficient and necessitate the use of a true dynamic pressure sensor rather than a transmitter suitable for relatively slow-changing variables. Purpose-built anti-surge controllers as well as surge detection platforms will incorporate such sensors and typically allow the user to see the dynamic pressure pulsations as well as to count the number of surge cycles incurred before the controller takes evasive action.
But aside from special cases, how fast is fast enough when it comes to process data? The answer is that 1-second data will be more than adequate for machinery diagnostic purposes in most cases and is often available from the process control system at this resolution - even if the historian does not save it at that resolution. And if 1-second data is impractical, 10-second data will suffice in most cases. Ultimately, the decision regarding adequate data resolution will be governed by the physics of the materials involved and how fast the variable can change in practice. Ambient air temperature at a gas turbine inlet, for example, is not going to change markedly in 10 seconds. Nor is the gas composition of a process stream likely to fluctuate faster than 10 seconds. Thus, 10-second resolution is adequate. In contrast, 10-second resolution for babbitt temperature in a fluid-film thrust bearing is probably not adequate as very rapid temperature changes can occur in the babbitt under rapid changes in thrust load .
Overall, while 1-second data (and even 10-second data) is usually adequate for machinery diagnostics, there are times when faster speeds are warranted. For example, malfunctions (such as compressor surge, as just one example) 10-second data may be far too slow.
It might be in the moments leading up to a machine trip where a detailed sequence of events is required to determine whether the process tripped the machine, or the machine tripped the process. It might be in the moments after an alarm or trip to ensure ensuing events happened as expected versus unexpected anomalies that wouldn't be apparent from a 10-second or even 1-second trend. Fortunately, we understand such needs and have engineered System 1 to address them by allowing up to 20% of the process points in a System 1 server to be collected at 200ms intervals when necessary. Because continual data at such resolutions is rarely required, you can configure state-based triggers that collect process data at different resolutions, providing ultra-high resolution when you need it, and "normal" resolution (often 1-second) when you don't.
If the process data is available to you in your historian, why would you need to replicate that data by importing it into System 1 and storing it in the System 1 database? Great question. There are several highly compelling reasons why this makes sense.
Ease-of-correlation
When data exists in two different systems, you can export from both systems and into a common environment like Microsoft Excel to build multi-variable trends, but that can be very time consuming. You can also use two screens (or a split screen) and visually compare trends from both systems, but that is likewise cumbersome and inexact when you must adjust horizontal axes in each system to have the same time scale. It is far easier when both types of data exist in System 1 and can simply be selected for multivariable trends. Time scales can be easily changed, and even X-Y plots can be established, such as vibration versus load, flow, or pressure. That isn't possible with two disparate systems without the tedium of exporting to Excel.
Optimal resolution
As we pointed out, 1-second or even 10-second data will often suffice, but in those instances where faster 200ms resolution is required, it is unlikely that your historian is archiving the data at those rates, even if it is capable of doing so. The OT personnel responsible for Operational Data may be managing hundreds of thousands of tags and defaulting to much lower resolution, such as 5- or 10-second data. System 1 does not burden the process historian with such details. It simply grabs the data it needs, when it needs it, at the resolution required.
More powerful decision support
In the same way we established that practicing rotating machinery engineers would rarely try to diagnose a problem armed only with vibration data, System 1's Decision Support capabilities can be far more effective when it has access to process data and can use this as part of its rule-based artificial intelligence.
You might have assumed that the discussion up to this point was all about critical machinery assets. But the truth is that process data can be vital in monitoring less critical assets, too. It's common to address plantwide assets with portable data collection approaches, and increasingly with wireless systems that automate the data collection and even the anomaly detection and diagnostic pieces. Just as process data is valuable in monitoring critical assets and understanding the context of changes in the machine's vibration, it is also valuable in less-critical assets.
As one of our customers put it many years ago "pumps don't die, they're killed." What he was saying is that operators often don't realize that certain process conditions can be incredibly damaging to machines. Pump cavitation is a classic, but there are others. When vibration changes on an asset, or it seems to be wearing out faster than expected, wouldn't it be nice to know if the process itself contributed to the machine's demise - or to catch the problem fast enough to prevent the machine's demise?
There's another aspect to plantwide here, too, and that's so-called fixed (i.e., non-rotating) assets. When you consider the amount of piping, vessels, heat exchangers, boilers, tanks, filters, and other static equipment in most plants, and even look at the size of the maintenance teams assigned to them, it becomes apparent that far more money is spent maintaining fixed assets than rotating assets. One of the reasons more money is spent on these assets is because the technology to continuously or even intermittently monitor them is rarely at par with the technology for rotating machinery. Thus, inspection-based approaches are often used.
A huge untapped potential, however, is the process data. Every one of those assets has process variables associated with it. The tank level. The liquid temperature. The flow. Just as with that customer's comments about pumps being "killed", we heard the same thing from people that have studied pipe corrosion. It didn't corrode in constant, linear fashion. It would often degrade more in just a few minutes or hours when exposed to off-spec conditions than in months or years of within-spec conditions. Thus, manual inspection may be required to measure pipe wall thickness, but monitoring characteristics of what is moving through the pipe is likely already in your process control system and thus needs no additional sensors. You just start using the data from those sensors for an additional purpose: as a proxy for conditions that the pipe may not like. 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!
Is process data important as part of a condition monitoring program? Yes - and I hope this article has made that abundantly clear. But don't make the mistake of just stopping with your critical machinery. Think plantwide and there's no reason to even stop with your rotating machinery. Without adding so much as a single additional sensor, you may well find that you can improve the reliability of your fixed assets by simply monitoring that process data for condition purposes instead of merely control purposes.
Our Experts
Jeffery Sipek
Software Product Manager
BIO
As a Software Product Manager, Jeff listens to customer needs and establishes the direction for System 1 Analytics. While working for Bently Nevada, Jeff has accumulated 30 years of experience in condition-based maintenance and asset management.