When we let others compute savings or benefits for a project, we might get answers that are slanted toward their interests, which may or may not be consistent with ours. Having said that, I must add that the numbers offered by our service or hardware providers are far from useless, and can be a handy starting point for determining the opti-mum design strategy for your projects.
One tool that I'm trying on the Internet is Emerson's "I/O on Demand" savings calculator (www.ioondemandcalculator.com). It's a very slick tool. You enter a few parameters—the number of I/O, the proportion coming in as muxed, fieldbus and wireless, and the mean length of home-run cables—and you instantly get an estimate of the magnitude of your savings versus conventional point-to-point. I poked around a bit looking for where I could enter the cost of transmitters, the proportion of safety (SIF) loops versus basic control services, or the number of devices per fieldbus segment. Well, these things aren't there—details, details.
"Diversity of I/O" is an important consideration in designing any project. For example, I was a little puzzled by my friends at Shell, who specified dual-redundant H1 cards, whether the Foundation fieldbus(FF) segments were in critical control applications or not. It seemed like senseless enrichment of their DCS vendor, since H1 card failures are rare, and FF continues to function, DCS I/O or not. However, the problem was that making all the decisions about what was critical and what wasn't costs time and engineering man-hours. If you only have a few dozen instruments, maybe this cost is low.
But, imagine the effort if you consider thousands of applications. Shell's experts determined it was far cheaper—and much faster—to just spend the money on hardware. If you're installing five identical fermenters with a couple dozen I/O each, your ability to judiciously segregate I/O into "safety," "critical control" and "indicate only" is much easier than the refinery retrofit, where one is invariably pestering operators and process specialists, asking, "How do you use this?"
What other circumstances create man-hour -sapping complications for the designer? Not surprisingly, Emerson's calculator loves you if you enter 100% wireless I/O. According to the calculator, more wireless = more savings. But we know 100% of our I/O typically can't be wireless—even if it were really the cheapest option. If you have any control or automated valve services, you will be running some wire. When I do the math, the incremental costs to add spurs to these fieldbus segments make WirelessHART at best a break-even option in many circumstances.
Wireless zealots contend that uncertainty favors wireless, as you can just plop in another device when you find out you need one. That may be true, but I can plop in FF devices pretty easily too, as long as my segments start with a little spare capacity. And the folks doing the economics don't account for the engineering effort —like the one that Shell judiciously avoids—of determining "Can this device be wireless?"
Then comes the HAZOP (hazard and operability study), where a diverse team of experts stares at the design and asks a lot of "what if" questions. This is where indicators become alarms, alarms become interlocks, and interlocks become safety instrumented functions (SIFs). This is where we could really use some help! Now my wireless device has to become wired, my muxed device has to become FF, or my FF device has to become 4-20 mA (and become duplicated or triplicated) for a newly minted SIF. Cripes, I hope the boss has forgotten that spreadsheet where I trumpeted all those great savings—time to get out his wallet.
Most of us are going to want some WirelessHART capability in our plants. Those who do their own math may stand a chance of getting a better deal. Know what your real savings are, and you'll help your supplier know how much his wares need to cost.
