John Rezabek is a process control specialist for ISP Corp., Lima, Ohio. Email him at [email protected]An enormous Shell hydrocarbon upgrading facility in the Middle East was preparing for start-up and commissioning, and the engineers were at odds about how to handle "device alerts"—diagnostic messages from smart devices about their self-evaluated "health" or lack thereof. Some devices had a large number of diagnostics available.
When engineers sat down with the asset management software and attempted to configure their intelligent HART and fieldbus instruments on a device-by-device basis, they found it to be rather time-consuming—many mouse clicks and 30 to 45 minutes or more for a typical positioner. There wasn't going to be time to optimize the settings prior to start-up. The debate became, shall we shut off all the diagnostic messages and risk missing some valuable intelligence during start-up, or leave them all enabled and deal with the nuances of the configuration later?
The "leave them enabled" camp prevailed, and to their dismay, the ensuing start-up was fraught with nuisance alarms and alarm floods that had some concerned about the ability of operators to maintain control of the plant. Leaving all device alerts disabled, in retrospect, may have been a more prudent choice for those circumstances.
Also Read "They'll Make a Better Software Fool"
But engineers deploying intelligent devices and asset management systems want their customers—the "operate and maintain" organization—to glean the value from digitally integrated devices. Would they be forced to begin months in advance, trudging through the configurations of each intelligent field device on their project?
There had to be a better way. There should be a path, they thought, to pre-configure some default settings for an entire class of field devices, which could then be downloaded to devices when the wires were landed and the devices commissioned in the field.
When confronted with the challenge of deploying thousands of fieldbus devices for a new project, Shell engaged its main automation vendor, Emerson Process Management, and Emerson's strategic planning manager, Scott Hokeness, to help engineer this vision.
Emerson's AMS Device Manager and DeltaV DCS engineering tools, like a lot of their kin, employ a configuration element called a "placeholder" to allow systems designers to represent the assignment and location of every fieldbus device on a project, its function block capabilities and settings for the parameters in those function blocks. Device-resident blocks used in control could be configured offline and bulk-edited using Excel spreadsheet templates.
But most diagnostic settings are configured in the device's transducer block, whose function is primarily to provide a process variable (PV) in engineering units from a raw measurement. Normally, the transducer block placeholder was populated with default settings, many of which were not interesting to Shell or whose settings were inappropriate for the service.
So Hokeness and his crew went to work, and devised a way for users to create their own library of templates for each device on a project. Shell's engineers created templates for each category of device; e.g., a 648 temperature transmitter with a Type K thermocouple or a fail-open rotary DVC6200. Emerson's system then converted the templates containing the settings and generated a placeholder for each, which Shell's systems engineers could use for populating the project's configuration database.
This capability has great promise to make Shell's next large project amazingly efficient, the FAT and commissioning trouble-free, providing a distinctly useful foundation for intelligent device management for the operating plant. Plans are in place to explore extending this capability to HART devices (which have a similar number of diagnostic settings) in a future release. All of Emerson's AMS Device Manager users will get the Foundation fieldbus templating tools when they upgrade to the new version 12.5 release.
