JohnRezabek
JohnRezabek
JohnRezabek
JohnRezabek
JohnRezabek

5 fieldbus pitfalls to avoid

July 20, 2018
Our next group of common fieldbus errors center around diagnostics and alerts.

Read Part 1: 15 ways to fail at fieldbus

The operations team had asked about a loop that appeared to be unstable, but by engaging the DCS autotune function, the systems engineer discovered issues maintaining a connection to the PID block. Drilling down into the DCS diagnostics application, she noticed that the controller’s backup (standby) redundant partner was unavailable. It was alive, but cycling through successive unresolved downloads, never returning to a healthy state and confirming its availability as a hot backup. Had it not been for the loop troubleshooting, this condition might have gone unnoticed until the primary failed and no partner was available. That would not have been a good day. 

But the redundancy trouble indication was masked by standing “bad quality” flags on the controllers, most due to trivial malfunctions or devices removed for maintenance. The many potential systems malfunctions had never been prioritized, and no procedure or discipline was in place to clear them or investigate for new, more serious malfunctions.

It used to sound great to have gobs of diagnostics from our “web” of “things.” But once deployed, it’s been challenging to run them all down and stamp them out—so it might be helpful to glean some advice from a successful project. Last month’s column started a list of areas warranting attention when you’re aiming to use one of the very capable and robust process fieldbuses—primarily Foundation fieldbus and Profibus PA. Here’s more:

Enable every possible device diagnostic:

Does everything with a microprocessor have diagnostics to share these days? Does it matter that your Ethernet switches haven’t rebooted in 10 years? (It might.) Do you care how cold your valve positioner is? Maybe you do, but turning on all the diagnostics is like enabling every possible alarm in the DCS. The result is a flood, and technicians are consequently numbed to paying attention and acting on the ones that could impact plant availability and performance.

Disable every possible device diagnostic:

Instruments have become very reliable, but the more you employ, the more likely you are to experience malfunctions. Anticipating problems and either fixing them or alerting operations to a possible vulnerability can minimize costly unplanned downtime. Some instruments’ SIL capability, or “safe failure fraction,” relies on having diagnostics coverage and assumes they're monitored for potential faults. It’s irresponsible to deploy smart devices and make no effort to utilize diagnostics—why purchase smart instruments at all?

Neglect to select and prioritize device alerts:

Every alert (e.g., cold positioner) isn’t useful to every endeavor. Every alert that’s meaningful in Fort MacMurray may not be important in Jamnagar. And every smart device has a host of alerts that might be redundant or have no relevance to a useable measurement; these should be disabled.

Once you’ve selected the alerts that are useful, it’s important to determine which ones might warrant a scheduled work order versus the ones that need immediate action—they need to be prioritized, just like process alarms. This needs to be dutifully thought through early in the project.

Don’t create templates for devices reflecting your priorities:

A number of DCS suppliers’ engineering tools support creation of device templates. Default templates have a lot of settings that are useless, and sometimes just wrong. The defaults have been known to spawn puzzling errors upon commissioning, and it’s not that challenging to replace them with your own, if you’ve chosen a system that supports such features. Using this practice, you can ensure that each device will commission and be downloaded with your chosen repertoire of parameters and alerts.

Choose your host system based on outdated heritage standards:

Solutions grafted to hardware and architectures from 1990 are usually challenged to integrate large numbers of smart devices. Even if you choose your supplier’s current offering, it will likely be a disruptive deviation from what was standard a quarter-century ago.

Digital integration of devices can provide distinctive operations for your enterprise. Take care to study the struggles of the pioneers to optimize its usefulness.

[sidebar id=1]

About the author: John Rezabek
About the Author

John Rezabek | Contributing Editor

John Rezabek is a contributing editor to Control