How to assign cost to DCS points

T

Thread Starter

Terry Dixon

It seems that everyone gets to use the system free, until we run out of space. The next project then has to pay not only for their project, but for the new processors, and I/O cards. A $50,000 project can easily swell to nearly twice that.

Is there a formula to determine the value of, say, an analog input, output, and the blocks that make up a level controler? I can guess what
might go into such a formula, but what do you use, if anything?
 
R
What it boils down to this what do you have and what are your licenses. first update the P&ID's, do a detail point count, write
specification that are detailed and clearly define what you want. Then go get a detailed quote and hold your contractor to it. He can also hold you to it. Control your scope and if operations what to change things after the freeze dates issue a change order to them, get a quote for the changes from your contractor befor releasing it.

Sound easy but as we all know it is a lot of work....

Randy
 
I work for a leading DCS manufactuer, integrator, field service, ect. When we want a job such as yours we place a bid along with other DCS companies. Try contacting Westinghouse Process Control Inc., Bailey/ABB, Honeywell, Yokagawa, ect. Spec what you need, hardware, MMI, engineering, field service support, and anything else important to you.
 
T
I think you misunderstood my question (usually because I'm not clear when asking the quesitons)

I'm on staff at a mill and am in charge of the DCS. The problem is that as the process grows, the DCS gets full. Down the line, a project
comes up that exceeds the remaining capacity of the DCS. The cost of the aforementioned project the swells because it is necessary to
expand the DCS to accomodate the process control logic. It would be more fair to spread the cost over all projects instead of blindsiding
someone with the cost of the expansion.
 
B

Bruce Durdle

I tried to set up a system for handling this a few years ago. The problem is that:

(1) most projects design for about 20% spare capacity in DCS, PLC etc.

(2) after commissioning there is quite a lot of this spare capacity unused

(3) project engineers etc become aware of this and think up bright ideas to use it all - after all, it's "free". Once cast in stone, these often very trivial uses become cast in stone.

(4) a real project surfaces that will use the remaining spare capacity + 1 input. Result - this project has to bear the cost of not only the capacity it uses, but also the costs of hardware used in all the trivial projects
carried out previously.

It can get fairly extreme - I know one plant where the next addition of instrumentatio will need an expansion of the equipment rack room, with all that implies.

The solution I proposed was to look at the actual cost of the complete DCS system, and assign a value to unused capacity on that basis. So if 20% of I/O is left unused, the associated value is 20% of the cost of I/O for the complete system. It's pretty easy for the old TDC2000/3000 where each box had a definite number of inputs and therefore each input or output can be assigned a value, but in more amorphous systems it will need a bit more
work. It also becomes a lot harder where there is a lot of cost in processing modules.

However, the bean counters werre just not interested, so it turned into a fairly academic exercise. But it's amazing how the threat to add a cost recovery factor to some projects made them quite uneconomic.

Bruce.
 
B

Bruce Durdle

I tried to set up a system for handling this a few years ago. The problem is that:

(1) most projects design for about 20% spare capacity in DCS, PLC etc.

(2) after commissioning there is quite a lot of this spare capacity unused

(3) project engineers etc become aware of this and think up bright ideas to use it all - after all, it's "free". Once cast in stone, these often very trivial uses become cast in stone.

(4) a real project surfaces that will use the remaining spare capacity + 1 input. Result - this project has to bear the cost of not only the capacity it uses, but also the costs of hardware used in all the trivial projects carried out previously.

It can get fairly extreme - I know one plant where the next addition of instrumentatio will need an expansion of the equipment rack room, with all that implies.

The solution I proposed was to look at the actual cost of the complete DCS system, and assign a value to unused capacity on that basis. So if 20% of I/O is left unused, the associated value is 20% of the cost of I/O for the complete system. It's pretty easy for the old TDC2000/3000 where each box had a definite number of inputs and therefore each input or output can be assigned a value, but in more amorphous systems it will need a bit more work. It also becomes a lot harder where there is a lot of cost in processing modules.

However, the bean counters were just not interested, so it turned into a fairly academic exercise. But it's amazing how the threat to add a cost recovery factor to some projects made them quite uneconomic.

Bruce.
 
A

Arnold Dillon

We bid jobs for PLC and DCS systems periodically. Usually, we go through an exercise to total up our engineering and configuration time, then price the hardware and come up with a total system cost. However, I then usually check this price against a price of somewhere around $500 per point. This seems to be sort of a reasonable price average, especially for large systems. A small system could cost up to twice that much per point just because of the base amount engineering and setup that has to be done, regardless of the system size.

In your case, you have a sunk cost in the installed base of the system. This might be ignored depending upon what type of system upgrades that you plan. Probably, you should come up with an average amount of engineering time required to configure a set of new points in the system based upon previous experience. Then take the incremental cost of adding another processing cabinet with processor, power supply, etc. Finally, assign cost to the I/O cards. Add it all together and divide by a number of points that you use in an average addition. This won't be perfect, but it will make a cost assignment like you're trying to achieve. You can adjust your formula after a few DCS system additions and you determine if you're too high or low. (Better to be 10% high on the first job. No one will mind if you reduce the cost in the future).

My guess is that you'll come up with one cost for discrete points and another more expensive cost for analog points.
 
B
Hi Arnold:

Do you have a price breakdown of your $500 estimate between engineering, implementation and hardware costs per I/O??

Bob Pawley
250-493-6146
 
B

Bob Peterson

I about choked when I saw this. It seems so far out. But then I thought about it a bit.

Here is a fairly typical smallish PLC project sample:

100 digital I/O
30 analog I/O

Hardware costs:

Digital I/O $2000
Analog I/O $2500
PLC/cables/power Supply/Racks $3000
Terminal blocks/misc $1000
Cabinet $500
Scada Software $2500
Scada Hardware $1500

Labor to assemble and test: $2000
Design/Drafting $5000
Software $7500
Startup 1 week $5000

Total $32,500


Note where the money is at. The purchased items are only about 40% of the cost. Labor is about 60%. (BTW-I did not adjust the numbers to come out that way-the numbers were just my initial guesses).

Or about $250 per point just from the integrators side.

By the time you add in end user project management, training, installation, an extra couple weeks of startup, redesign, etc., and keeping in mind that the cost of hardware and software for a DCS typically far exceeds that of an equivalent PLC system, $500 a point is not that far off.

By the way, it would not surprise me if it cost $100 or more per point to install the thing. Field work is just extremely costly. If you want to save money, that's were you can save some. Anything you can do in a shop as opposed to out in the field will almost always save you money. Unfortunately, the techniques that reduce your field costs, tend to increase the "control panel" cost, and the PM's driving the projects rarely understand this. They want the lowest cost "control panel" even if it substantially drives up the cost of field work.

Bob Peterson
 
A

Arnold Dillon

Not really. I came up with the $500 per point price tag based upon some survey information that floated around a couple of years ago. The survey talked about cost-per-point for new DCS installations including hardware and programming. Mostly it was directed at large systems. Around $500 turned out to be an average for an installed system cost not including field instruments.

I use it mainly as a reality check when doing proposals. It isn't how I come up with final costs.

-Arnold Dillon
615-346-3400
 
A

Arnold Dillon

Bob,

I haven't spent much time looking at your assignment of costs, but they seem reasonable. The only thing that I'll quibble about is that --"the cost of hardware and software for a DCS typically far exceeds that of an equivalent PLC system." --That statement was true 5 or 6 years ago, but today I don't necessarily agree.

It is true that some small PLC's and maybe even some good sized systems like SLC-500's can be cheaper, particularly if the control is mostly discrete with relatively simple logic. On the other hand, if you jump into something like a ControLogix package, a lot of analog control, isolated inputs, batch logic, and a bunch of complicated inter-tied process systems, then I'll bet that I may be able to do the job cheaper with some of the scaled down DCS systems marketed today. This won't be because the hardware is cheaper, but there is more functionality built into the configuration software that lets some of the more complicated programming happen a little easier. -At least for me.

Six years ago there were no scaled down DCS systems. Everything was built and initially configured by the manufacturer. Operator consoles started at $30K and unless you had at least 100 analog loops or some really special requirements, a DCS didn't start to become cost effective. Today, I can buy and integrate some of the DCS hardware and software just like the PLC systems. The operator stations are conventional computers and the processor and I/O racks don't look much different than a lot of PLC's. Only the software is different.

-But for a complicated process control strategy requiring that functionality, the $500 per point number may still be a rough yardstick (read very rough) regardless if the control system is a PLC or DCS.

-Arnold Dillon
 
B
> Bob,
>
> I haven't spent much time looking at your assignment of costs, but they
> seem reasonable. The only thing that I'll quibble about is that --"the
> cost of hardware and software for a DCS typically far exceeds that of an
> equivalent PLC system." --That statement was true 5 or 6 years ago,
> but today I don't necessarily agree.

I think you will find that on a point for point basis the cost of PLC points (I/O and HMI) versus DCS points still comes down on the side of the PLC. And by a substantial margin.

> It is true that some small PLC's and maybe even some good sized systems
> like SLC-500's can be cheaper, particularly if the control is mostly
> discrete with relatively simple logic. On the other hand, if you jump
> into something like a ControLogix package, a lot of analog control,
> isolated inputs, batch logic, and a bunch of complicated inter-tied
> process systems, then I'll bet that I may be able to do the job cheaper
> with some of the scaled down DCS systems marketed today. This won't be
> because the hardware is cheaper, but there is more functionality built
> into the configuration software that lets some of the more complicated
> programming happen a little easier. -At least for me.

True. The main point being "at least for me". The cost of retraining people who are only familiar with DCS's to efficiently use PLCs (and vice versa) is typically prohibitive. The same problem occurs when you try to switch from brand X PLC to brand Y (or brand X DCS to brand Y DCS). I tend to agree there is more built in functionality in DCS systems then with PLCs. But thats by design. DCS's tend to lock you into their way of thinking and their method of control. If you do not want to use their built in functionality, it can be substantially more difficult to roll your own then with a PLC, so
people tend to use the stuff it comes with, forcing the control to fit the DCS. I have seen some rather strange things done for this very reason.

In my guesses I guessed that the labor cost was 60% of the "control panel" cost, and purchased items was only 40%. It would not take a whole lot of extra engineering time required for a PLC control panel to actually cost more then an equivilant DCS control panel, even if the DCS purchased items cost more. Just the cost of sending a couple of engineers to a PLC training class for a week might skew the numbers in favor of a DCS if the engineers needed the PLC training.

Another issue here is the preferential pricing some integrators or end users get over others. Some people pay double what others do for the same AB part. I suspect this is probably true in the DCS world as well. Not knowing what pricing is actually available puts people at a disadvantage when trying to compare actual costs. And the PLC/DCS sales people like it that way. The more befuddled the users are over real costs the better for them.

A somewhat humourous aside here. I worked on a job not to long ago where the end user had a DCS (Honeywell IIRC). For some reason, they could only use a certain number of characters for a tag name. Our tags came out in our standard numbering system with one more character. It was going to cost something like $30,000 to "upgrade" the DCS to accept tag names with an extra character, so they elected to delete one letter in each tag so that it would fit in the allowed number of letters. Seems to me it was like 7 letters was allowed, but all our tags were 8. Came out with strange tag names in a few cases, but it worked, and they did not have to spend $30k for this "upgrade".

> Six years ago there were no scaled down DCS systems. Everything was
> built and initially configured by the manufacturer. Operator consoles
> started at $30K and unless you had at least 100 analog loops or some
> really special requirements, a DCS didn't start to become cost
> effective. Today, I can buy and integrate some of the DCS hardware and
> software just like the PLC systems. The operator stations are
> conventional computers and the processor and I/O racks don't look much
> different than a lot of PLC's. Only the software is different.

I concur that today DCS's are much more cost effective then even a few years ago. But I would dispute your contention that there were no scaled down DCS systems 6 years ago. Bailey had some pretty reasonable stuff, as did Provox, at least as far as scaled down went. But cost wise it was still insane. And I am talking more like 10-15 years ago, not 6.

> -But for a complicated process control strategy requiring that
> functionality, the $500 per point number may still be a rough yardstick
> (read very rough) regardless if the control system is a PLC or DCS.

I suppose it would depend on the level of complexity and whether the DCS had a builtin function you could use. I have done some fairly complex math with PLCs and it was relatively easy, but I have been programming PLCs for almost 20 years now. Particularly in a PLC5 and SLCs with the compute instruction where you can enter an algebraic formula directly. I have only done a couple DCS projects, but they were all substantially more difficult (and not by a little bit) to handle the things I was doing then with any PLC. And mostly I was doing simple sequential control. The thing I like about PLCs is it does what I tell it to do. I am not forced to do what it thinks I should. In both of the DCS projects I was involved in, we actually had to change the way the equipment functioned (usually in minor ways) to accomodate the way the DCS worked. To me this is not desirable.

I am still curious if the $500 included installation and training.

Bob Peterson
 
Arnold:

From another post it appears that 60% of a typical project cost is labour.

I would suggest that this could be broken down to approximately 25 design labour, 25 implementation labour and 10 set-up and testing for a total of 60.

Does this seem reasonable?

Bob
 
To all those who incur costs due to the differences between hardware units such as PLC, DCS, Networks.

Imagine if the software you used was completely independent of these hardware concerns.

What would your world then be like?

Bob Pawley
250-493-6146
 
Top