Mixing fieldbuses

[Dirk Diggler]

Here's a question for all of you folks.

In a new plant scenario, lets say an 800 point I/O count with about a 50-50 mix of analog and discretes. I think it's a no-brainer to go FF where applicable for the analog control/monitoring. The question is, the remaining 400 or so points where we need shut-off valves, motor controls etc. what do we do? I have heard the Tower of Babel argument regarding using another bus, lets say DeviceNet, to do this control and tend to agree. I would prefer to do this the old fashion way, with 120 VAC I/o (or 24 VDC if that is your thing) and 4-20mA for any drive control.

The problem is that the sales-force from the system vendor management wants to use, continue to tell us that "we can do it". Obviously they want to do it for some reason which they are not telling us. I say anything is doable, but is it a good idea?

Being located in the shop, I don't really have alot of pull in the decisions, but, can someone put together a few bullet points to counter this "sales pitch". I think I know a few of them, but I'm looking for the experts opinion as to why it is not a good idea.

Thanks.

[IanVerhappen]

Hello Dirk,

You are correct in all your assumptions, including the choice of FF as your bus network. With the increase in the number and availability of discrete I/O you should not be severely restricted on the use of on/off devices either. If there is one or more devices for which it is not available in an FF format, both Smat and Emerson have new 'multiplexers' to "transfer" the discrete signals to the H1 network. (Smar also has a device for converting back and forth with analog as well).

Unfortunately, when it comes to motors, we are not so fortunate since there is not yet any motor that has registered its MCC as an Fieldbus device so you may have to use something like DeviceNET for those communications.

Now on to your question about multiple buses on a single host. I will try to give you some from a maintenance perspective.

- having to troubleshoot multiple networks + associated new tools and training
- protocol conversion requirements when going from one system to another
- long term support for the standard

If you send me a note at ian.verhappen@ICE-Pros.com we can talk about your project further and how to integrate if necessary or better yet do it all in Fieldbus. It sounds a bit like the vendor representative is trying to sell you what he has without having to do a lot of thinking or work themselves by pushing the 'standard package'. There is always a way to make things work, especially now that there is a good selection off FF devices available.

Ian

[jberge]

Multiple buses should not be mixed in a system, not because it can't be done, because it can be done using most control systems in the market today, but because the system gets messy and expensive to operate and maintain. I.e. I am sure the system supplier can do it, but will your guys be able to support it? The ability to deal with other bus technologies should essentially be used only to interface your installed base of equipment that you cannot yet get rid of. Mixing buses is more time consuming and invariably results in consultations between vendors and additional tests during commissioning.

Although possible, do think twice before mixing multiple buses in a plant. It is possible to mix FOUNDATION™ Fieldbus, Modbus, and PROFIBUS, etc. in the same plant and made it work at commissioning. Mixing many different buses will be an exercise in complexity and the real challenge is to maintain it for years and to expand or modify it as necessary. Every additional bus is a burden for the maintenance technicians. Mixing many buses in one system will cause troubles that very likely outweigh the benefits of using bus in the first place. There will be too many different kinds of media, cables topologies, configuration tools, troubleshooting tools, gateways, drivers, etc. and they are all configured differently, have devices with different parameterization schemes, and with different implications for the control strategy. There is more to adding a bus to a PLC than to just plop in an interface card. Instead aim for a single primary bus technology in your plant. Use additional buses as a last resort. Take your time sourcing for devices that use this technology. Contrary to popular belief, several FOUNDATION™ Fieldbus devices for discrete I/O and logic exist and you will find then if you just look around (e.g. for shut-off valves, motors, and switches you mentioned). By selecting a single bus you make life easier for maintenance and operations. A system with just a single network technology throughout the system is easiest to use.

Although the major systems supporting FOUNDATION™ Fieldbus also permit interface cards for other buses to be plugged in, they don't support the other protocols as well as they support Fieldbus. Therefore, adding more buses does not add significant value. It is a case of diminishing returns.

For example, if a PLC supports DeviceNet it should not just have a DeviceNet interface card, it must also have a configuration tool that supports complete configuration and getting diagnostics from any DeviceNet devices in the market. Since DeviceNet does not have the equialent of DD, this will not happen, you will only get the basic I/O or support for a selected subset of devices. Therefore I think you are better off using shut-off valves, valve coupler, and discrete I/O modules. Often DeviceNet solutions rely on pre-configured communication, or on separate tools for device parameterization, or have proprietary device support files that may not be available for the type or version of device you are using. Today the reality is that hosts that supports FOUNDATION™ Fieldbus well are able to connect with DeviceNet devices, but do not have easy tools to configure them. Therefore, aim for a single bus. By plopping in an interface card you get relatively easy access to cyclic I/O data scan such as writing the desired speed of a drive. However, accessing the complete set of configuration parameters is poorly supported requiring third party tools.

By including an additional bus in a loop the centralized controller or a gateway must be used for the translation. Since the loop cannot be closed on the Fieldbus, you no longer have single loop integrity. Redundancy of the controllers etc. would become an issue. Since the buses have different fault mechanisms it is necessary to configure special communication watchdogs and interlocks. Simply using Fieldbus devices throughout is best.

The FOUNDATION™ function block diagram control strategy programming language (based on IEC 61804) has some very rich features such as status propagation and mode that will get lost if other bus technologies or proprietary programming languages are mixed in the control loop. Today, thanks to status, a thermocouple failure will send the control valve to a failsafe position without me having to make any interlock programming whatsoever. The status is detected by the AI block and propagated through the PID block to the AO block where the action occurs. This interlock is built into the blocks and I get it for free just by building the control loop. Similarly, I get the reset windup protection if somebody takes control of the final control element (e.g. from the local panel in the drive) or a limit is reached - this is propagated backwards up a multi-level cascade. No other bus technology or control strategy programming language does this as easily.

Jonas Berge
SMAR
==================
jberge@smar.com.sg
http://www.smar.com
Learn Fieldbus at your own pace: http://www.isa.org/fieldbuses

Here's a question for all of you folks.

In a new plant scenario, lets say an 800 point I/O count with about a 50-50 mix of analog and discretes. I think it's a no-brainer to go FF where applicable for the analog control/monitoring. The question is, the remaining 400 or so points where we need shut-off valves, motor controls etc. what do we do? I have heard the Tower of Babel argument regarding using another bus, lets say DeviceNet, to do this control and tend to agree. I would prefer to do this the old fashion way, with 120 VAC I/o (or 24 VDC if that is your thing) and 4-20mA for any drive control.

The problem is that the sales-force from the system vendor management wants to use, continue to tell us that "we can do it". Obviously they want to do it for some reason which they are not telling us. I say anything is doable, but is it a good idea?

Being located in the shop, I don't really have alot of pull in the decisions, but, can someone put together a few bullet points to counter this "sales pitch". I think I know a few of them, but I'm looking for the experts opinion as to why it is not a good idea.

Thanks.

[Dirk Diggler]

Thanks Jonas.

My thinking is pretty much the same as yours.

Cheers.

[dewey320]

Dirk, (nice handle by the way, loved that movie)

First off, I realized this reply is a full year after your original post but I just got here and was very suprised at the answers I saw being provided to you.

I would be very wary of the type of "blanket statements" made in reply to your post. I also applaud your choice of FF technology, however FF is not always the right tool for all cases. Motors are a good example of that. Allow me to quote Mr. Verhappen from earlier in this post;


"If there is one or more devices for which it is not available in an FF format, both Smat and Emerson have new 'multiplexers' to "transfer" the discrete signals to the H1 network. (Smar also has a device for converting back and forth with analog as well).

Unfortunately, when it comes to motors, we are not so fortunate since there is not yet any motor that has registered its MCC as an Fieldbus device so you may have to use something like DeviceNET for those communications."

Ok, so since a particular device (MCC in this case) is not available for FF then we should pound the square peg into the round hole and convert the discretes to FF?? I strongly disagree with this approach. While the discrete mux devices for FF are quite handy in many cases (limit switches for instance) you would lose all the diagnostics available over the DeviceNet.

What you really need to do is sit down and evaluate the benefits of adding another bus vs. the complexity it would bring to your control system config and maintenance. Depending on how your control system handles multiple busses it may be a no brainer to add. On the other hand it may not be worth the effort. You can't answer this question without that information and unless the other guys posting on this thread had that info then making blanket statements like "multiple busses should not be used in a system" is not very responsible.

I've personally worked on several projects with multiple busses and have seen dozens more that contained at least 2 or three bus types and worked very well. I've also been involved in a project that used FF, Profibus DP, ASi, and Modbus in one system that went in on time and under budget and is a dream to maintain because of additional diagnostics from all the digital devices (from all busses). Currently, I'm working on a greenfield project with 20,000 I/O, we're using FF (of course), and also DeviceNet and Modbus.

How well multiple busses perform together in a single system is largely a function of how that system is designed. Some systems are designed to do just that and do it extremely well. You should talk to some systems owners and see what they think.

Making statements like;

"aim for a single primary bus technology in your plant. Use additional buses as a last resort. Take your time sourcing for devices that use this technology".

just seems flawed to me. We should be able to choose the best instrument for the specific task at hand and it should work with my system and all the other devices connected to it regardless of protocol. Limiting ourselves to devices that use a particular protocol means you're probably not building your control in an efficient and cost effective manner. At the end of the day the objective is a plant that runs and runs well.

My point is that we don't use FF (in most cases anyway) just for the sake of getting to play with FF devices. We use it as a tool to do process control. It happens to be one of the best tools available for that task in my opinion. For that task. Hammers work great for pounding nails but I'm not so sure I'd want to use one for stripping wire or driving screws.

Don't get me wrong here, I'm not anti FF at all. In fact I work for a company that manufactures many FF devices and I love working with it. But until it can fry my eggs in the morning I'll go on using a frying pan for that.

Hopefully next time you'll be able to get some feedback from people that have actually done what you asked about or even work in a plant rather than someone trying to sell consulting services or textbooks.


rgds,

dewey

[Mike ONeill]

Remember that FF, Profibus, ASI-bus etc are simply communications technologies to enable any plant to run properly and efficiently.
If anything, Profibus is the most capable at integrating communications at all levels: ProfiNET at the high end, through ProfibusDP for digitals and ProfibusPA for analogs (not to mention ProfiDRIVE and ProfiSAFE for drives and safety systems).
Any expert advocating "FF for everything" should visit a bottling plant.
Dewey has the right idea; "horses for courses" is the right way to go, not trying to make something fit just so that someone can claim another successful sale.

[Dirk Diggler]

Thanks Dewey.

I'm glad someone has finally hit the nail on the head. Since originally starting this thread, I've become much more educated on the whole Fieldbus issue. I am in 100% agreement with a few things you said.

"We should be able to choose the best instrument for the specific task at hand and it should work with my system and all the other devices connected to it regardless of protocol"

How well multiple busses perform together in a single system is largely a function of how that system is designed. Some systems are designed to do just that and do it extremely well.

"we don't use FF (in most cases anyway) just for the sake of getting to play with FF devices. We use it as a tool to do process control."

"until it can fry my eggs in the morning I'll go on using a frying pan for that." I love Eggs!

Since a year ago, we have found an engineering resource that is very good at helping us get the right tool for the job and have gotten us back on track.

DD

[Robin Burnikell]

Dear Dewey,

I agree with much of what you said, however, I do think you have been unjustly harsh on some of the people that put forward equally relevant comments on this thread that I also agree with.

My short life so far has taught me that things are rarely as they seem, and everyons opinions and views are built on their experiences. We all have different experiences and hence different views. If you can take in everyone’s experiences and weave a line through them you often find something more valuable.

So after reading all this thread for the first time I would just add the following.

A key thing with most Fieldbus technologies is that having a registered device or system does not mean you support ALL the features and functions that are available with that technology. It normally means you just have the basic set. With technologies like FF and others there is a huge difference in functionality and end user benefits between the basic set and the full set.

As we know Fieldbus standards are currently constantly evolving. Consequently there is a big difference between last year, this year and next year. To implement a multiple bus system is not only asking a lot of your people, but it is also asking your system supplier to stay up to date with two or more bus technologies at once.

Past and current history shows bus technologies are evolving so fast the vast majority of companies including the worlds biggest and best known names in Process control are unable to keep up to date with little more than just the basic functionality with just one technology, let alone several.

But, yes we (smar) and many others have done it, our systems do support multiple bus technologies, seamlessly (as the sales men say). But that does not mean we recommend it, nor does it mean you get the full set of features and benefits offered by every bus, or even any of the buses in many cases! The end user, as everyone on this thread agrees, must weigh it up.

The whole issue becomes even further fogged depending on what the frame work of the system in consideration is. For instance in the case of FF many (but not all) FF systems available today are based on older "closed" proprietary hardware and software platforms (such as DCSs and PLCs) rather than the newer "Open" systems based on the FFs specification of linking devices.

For a pure FF system the advantages/disadvantages of choosing an Open or Closed platform is well understood, but in a mixed bus system it is not so clear. With the older "closed" system you have the advantages and disadvantages of all your eggs in one basket. With modern "open" systems you have the advantages and disadvantages of a best of breed multi-vendor system.

Buses are languages, and as we all know some words/ phrases of a language do not have a comparable translation into another language.

So my personal belief, is that based on current technologies and past history one should not aim to have a multiple bus system. In my opinion they can be beneficial in specific circumstances, but you should aim to have one primary bus technology and then where and when that technology does not deliver weigh up the benefits and disadvantages of implementing further buses on the same system.

My personal recommendation to anybody trying to make this assessment would be to seek advice from more than one supplier (even if you feel you are already committed to a supplier) and get as much end user feedback as possible.

Robin

[dewey320]

Robin,

Thanks for the reply, I did not intend for my previous post to be inflammatory. I do still however stand behind what I said.

We, as systems vendors, need to be painfully aware of our customers objectives when they install systems. I might be going out on a limb here but having worked at end users companies in the past let me take a shot at it. My objective when installing a new control system would be to create a system that does what I need to operate the plant efficiently while coming in on budget and schedule. My objective is most certainly NOT to try to use one bus technology wherever possible. Bus technologies or any other technology for that matter are a means to an end. No more.

you said;

So my personal belief, is that based on current technologies and past history one should not aim to have a multiple bus system. In my opinion they can be beneficial in specific circumstances, but you should aim to have one primary bus technology and then where and when that technology does not deliver weigh up the benefits and disadvantages of implementing further buses on the same system.

But the fact remains that FF does not measure up for every single type of device in the plant. I have to agree with your statement, so long as you are willing to admit that if your plant has any motors, drives, or PLC's, then you may want to take a look at DeviceNet or Profibus DP.

I have to scratch my head though when you say;

But, yes we (smar) and many others have done it, our systems do support multiple bus technologies, seamlessly (as the sales men say). But that does not mean we recommend it, nor does it mean you get the full set of features and benefits offered by every bus, or even any of the buses in many cases!

Why bother building the "seamless" multiple bus capability in a system if you don't recommend using it? Surely that is an advantage you must have to offer customers that some of your competitors do not. No?

Finally;

My personal recommendation to anybody trying to make this assessment would be to seek advice from more than one supplier (even if you feel you are already committed to a supplier) and get as much end user feedback as possible.

I absolutely agree. It doesn't take a lot of research (hands on, not internet banter like we post here) to understand the differences between functionality offered in different systems.


rgds,

dewey

[Robin Burnikell]

Hi Dewey,

I believe my statements are roughly in line with your last post.

I was an end user of control systems for about 10 years before I joined Smar to become a supplier. The problem for end users is suppliers like to tie in end users and often band open technology to entice and relax the end user during the selection stage, but find many other ways to tie in end users.

The problem for the end user is that their cost is the Total Cost of Ownership whereas the system supplier is looking to come in on time and on budget for the supply of the system (CAPEX part) and then aim to maximise after sales support contracts (OPEX part).

Multiple bus systems are often attractive and efficient up to SAT, but in my experience they add significantly to OPEX costs and therefore impact the TCO for the end user. If the supplier is going to get the after sales support contract it also benefits the supplier further as they have increased the value of the contract.

As a simple example I have just returned from presenting Smar's system and products at the Profibus International Conference held in the UK this week. During the workshops one problem mentioned by several people that occurs surprisingly frequently was installers not familiar with Profibus try to use DP or PA cable where PA or DP respectively should have been used. If you now mix that with FF H1, FF HSE, DeviceNet, ASi etc you can see that supporting multiple bus technologies considerably adds to OPEX costs in many ways.

HOWEVER as per my previous post, if the TCO benefit of multiple busses outweighs the TCO cost of multiple busses then OK and there are many cases where it does. But the end user must consider this carefully because the supplier has significant interest in supplying multiple bus systems, many of which do not benefit the end user.

I believe the aim should always be to give users genuine choices. The reason smar implemented more than just one bus on our system is to provide users the option of using for instance profibus DP for communication to drives, motors and PLCs etc as you suggest. I am sure this is why other suppliers (ABB and Emerson) have also implemented multiple bus standards on their systems.

My point is simply, just because the option is there to use it, it does not necessarily mean we recommend it should be used. It needs careful consideration for all the reasons I mentioned previously.

Regards,

Robin