John Rezabek is a process control specialist for ISP Corp., Lima, Ohio. Email him at [email protected]Consultants focusing on operator effectiveness have been known to draw some inspiration from military aircraft designs, which incorporate a lot of graphical depictions of flight and combat variables on their cockpit "heads-up" displays. The present generation of operator graphics uses some of these elements, often hiding or eliminating numerical values and incorporating retro panel board faceplates, animated bar graphs and dials. But when I pitch these ideas to the boss, he has a straightforward rebuttal: Do we expect our operators to be fighter pilots? That's a very succinct way of saying, jazzy new graphics aside, we don't rely on operators for life-or-death split-second judgments and actions, like one would a pilot in combat. In fact, most HAZOPs, layer of protection analyses (LOPAs) and alarm philosophies specify allowing 10 minutes for an operator to respond to take credit for an operator intervention. Some companies require a lot more than 10 minutes, or not at all! "Our operators are rocks," one HAZOP leader told me.
While operators aren't supposed to be ready to unleash a Sidewinder missile and shoot down the enemy in a fraction of a second, they still benefit from a keen awareness of the state of the process. Most process phenomena are taking place inside opaque piping, vessels and machinery; instrumentation is the only way anyone has a notion of what's happening. The measurements and indications we deliver to operators' monitors or panel boards constitute their eyes and ears. In the view of ISA 18.2-2009/IEC 62682, the "situational awareness" we provide is supposed to be optimized—for clarity, accuracy and consistency—to ensure that operators can intervene and prevent the process from entering the upset state. But what the tidy concentric diagram in section 5.3 (http://bit.ly/1aXqlZH) doesn't depict is that the target or optimal operating regime is frequently at the edges of the capacities and ratings of equipment.
See also "Alarm management technical library"
[pullquote]When we ask what the best indication of an abnormal situation is, alarm philosophies might suggest we consider suppressing or eliminating redundancies. For example, a flow alarm, a motor status and pressure indication may all have alarms configured that indicate a pump has tripped. In this simplistic example, the rationalization team might conclude, "I don't want the operator to get three alarms for the same malfunction." But taking away alarms (and redundancy) means the remaining "best" indication needs bulletproof reliability if we expect it to alert an operator who has hundreds or thousands of variables to monitor.
If you remember the days of pneumatics, a measurement came to the control house panel as a pressure (3-15 PSI) in a single tube. If you wanted to alarm on that measurement, you procured a pressure switch, calibrated it to actuate at the desired alarm setting and wired the switch to a light box or annunciator. Pneumatic controls offered an endearingly uncomplicated and direct linkage between the process variable and the alarm system. Perhaps you don't find it that endearing, but it did engender the single-loop integrity we'd like our modern systems to replicate.
Autonomous devices on a fieldbus segment solving function blocks have built-in alarming capability and can be configured to publish their measured variable and any alarm status relentlessly on a precisely synchronized, deterministic network. If my alarm philosophy compels me to configure only the "best" indications for a single malfunction, it would be ideal if I could obtain the alarms in this manner with as few intervening complications as possible. Even if I'm creatively implementing state-based or first-out suppression, I want to invoke these measures if and only if the measurements are timely and validated.
It would be nice, but in many implementations of fieldbus the DCS alarm system isn't listening directly to the devices on the bus. It's not uncommon for systems to employ a grafted-on approach, where all the fieldbus data is funneled into the legacy controller infrastructure. A measurement used in a PID controller relies on the PID block to generate alarms, so all the intervening code and communication is necessary to ensure the alarm is annunciated. As systems move toward architectures where the I/O isn't closely held by (i.e., wired to) the controllers, autonomous and deterministic delivery of alarms would be a measurable benefit.
