rezabek
rezabek
rezabek
rezabek
rezabek

Connecting all instruments to IIoT seems ideal, smart and practical, but is it really?

March 30, 2015
When instruments "talk" back, their messages become priority. Don't miss the alert that saves you from a plant shutdown.
John Rezabek is a process control specialist for ISP Corp., Lima, Ohio. Email him at [email protected]As we're hurried forward into the promised new "Industrial Internet of Things" - the "IIoT," a.k.a. "pervasive sensing," will we find the presumed wealth of previously hidden information useful or interesting? Surely there will be something I care about—like that "thing" that broke and caused the fire that crippled crucial production. I wish that "thing" had been on the network and would have called me at home before the vapor cloud escaped and ignited. Or that "thing" that fouls my turbines and exchangers and causes me to take numerous shutdowns for cleaning and repair. Is that thing going to be on the network somewhere so it can send me some email? The thing that caused a spill or release – will it have an IP address on the Internet? The trouble is, for every "thing" that I can imagine communicating and potentially saving me from some adversity, there are 20 things already flooding the network with data. Somewhere among all those hundreds or thousands of messages is one I wish I could read right now, but how do I go about finding it?

The situation is largely analogous to the process industry's problem with alarm management. Alarms on process data became "free" with the advent of the PLC and DCS – a few mouse clicks and any piece of data could be made to make noise (sound the horn) or change color on the HMI. And that's what we did. On my system, every module template has a minimum of five alarm parameters configured. Multiply that times a few hundred or a few thousand, and you have the makings of an alarm flood. As for device alerts, we don't have to wait for the IIoT; we're really already there. Rather than obscuring the real urgency and priority of process malfunctions that require timely action, the host of information-laden smart devices obscures or desensitizes us to device problems that would benefit from prompt attention. It could be the sort of attention that would avert some of those process problems, and that's where the real value lies.

See Also: The Ultimate HMI

When you're applying traditional alarm rationalization to a process HMI like a DCS, a team of individuals representing operations (preferably experienced operators), controls, process specialists, and possibly machinery and safety specialists, consider each alarm in the system to determine if it passes muster. For example, an alarm should only be an alarm (make a noise and appear on an alarm summary) if it indicates an abnormal condition requiring timely operator action. While examining a given alarm, it makes sense for the team to 1) document the likely causes, consequences and corrective actions the operator might take; 2) prioritize it based on consequence and urgency; 3) store these findings in a master alarm database. Doing this for thousands of alarms can be tedious and exhausting for the group tasked with making these decisions. It can take months of work.

[pullquote]Don't we need to do the same for our device alarms if we expect them to be useful? Someone needs to decide if the control valve on the feed to the hydrotreater has a high deviation from setpoint, it should be inspected for worn packing and scheduled for an overhaul before the week is out. Meanwhile, all the "configuration changed" alerts can go straight to the spam bucket. Another valve maybe isn't so critical and gets a lower priority, or a higher deviation alarm setpoint. Like process alarm management, each alert should be meaningful and have a defined action to remedy the issue detected. But where do we find the team and the time to do device alert management when we struggle to find the resources for even process alarm management? Can our suppliers help out with this?

Like our process plants, supplier companies are beginning to experience a turnover in expertise. A lot is headed out the door as the older generation decides it might be more relaxing to make wine and hit golf balls than design new and better instruments. Before all these folks hit the links for good, end users could benefit from their years of experience and insight applied to device alarm management. Before the tidal wave of IIoT engulfs us, let's at least understand what the experts think is really useful. We're struggling for the resources and the will to do it on our own.

About the Author

John Rezabek | Contributing Editor

John Rezabek is a contributing editor to Control