Critical Segment

Hi to All,

What is the maximum allowed number of Field Devices(e.g. Transmiter, Valve Etc.)on a single fieldbus segment.

best regards,


lovington dela Cruz

[sheusel]

Dear labingtone,

the maximum number of field devices is limited by two major aspects:

- H1 controller
The H1 controller that you use in your application has a usual maximum allowed number of field devices of 16 - however, there are already some Host systems out there that allow 32 devices to be scheduled.

- macrocycle time
With every device connected to your Foundation Fieldbus segment you need more time to schedule the data transmission of all devices. The maximum time allowed for 1 macrocycle depends strongly on your application - as a good rule of thumb the macrocycle should be approx. 1 s
Now if you have 16 multivariable devices connected to the segment you will probably need much more time than 1s to transmit all the data.
If your application is not time-critical then you can also have 32 devices connected to the segment (provided your H1 card can support this).

However, you should keep in mind that with standard H1 host settings a device will be removed from the live list after it did not respond to 3 pass token (=3 macrocycles) - this means that if your macrocycle is 4 s long, it will take 12 seconds before the host will remove a device from the live list and generate an error message.

Mit freundlichen Grüßen / Best regards

Stefan Heusel
Technical Support Manager Fieldbus and Level Products

Pepperl+Fuchs GmbH
Königsberger Allee 87
D-68307 Mannheim

Phone: +49 621 776-1299
Fax: +49 621 776-1234
e-mail: sheusel@de.pepperl-fuchs.com
www.pepperl-fuchs.com

Signals in the World of Automation

Stefan Heusel,

Thanks to your reply.

If we have a mission critical loop what is the maximum mumber of Field Device in the segment.


regards,


Lovington Dela Cruz

[rezabejd]

Deeming a loop "mission critical" does not in itself invoke some limit, beyond those already discussed.

Some of us have used guidelines, classifying loops "level 1","level 2", etc., and assigning loops to segments accordingly, for example, "no more than one level one valve per H1 card". Some of these standards came about before redundant H1 cards were available and so are overly conservative IMO.

The thinking goes something like this: If I have a critical loop, how much incremental risk to its integrity am I willing to take on? Where does the incremental risk come from? We can try to help you think about this, but ultimately you have to decide for your particular installation. Some thoughts:

1) Maintenance activities: If technicians are working on some device, to what extent do they put other devices on the segment at risk? How frequent is this sort of activity? How nervous is my operating organization? This was a bigger issue before we had short circuit protection for spurs. I suppose there's still some risk that a tech will lift the wrong wire. If they are clumsy about attaching a segment analysis tool and do so upstream of the short-circuit protectors (at the H1 card, for example), they can still short out the entire segment and cause a process upset.

By limiting the number of "other" devices on a "critical" segment, we think we cut back on the frequency of these activities. When a tech does have reason to work on a critical segment, there should be better awareness of the consequences of an error.

2) Configuration activities: If someone is making changes to another loop or device on a segment, to what extent will it impact the critical loop(s)? How frequent is this activity? How good is my host system at keeping "downloads" from affecting other devices on a segment? I have heard of hosts that require the segment to be taken out of service before any changes are made.

3) Polling of asynchronous data: Is any of the asynchronous data - for example, valve position - very interesting to operations? If you're running the segment fast - say 500 ms - this data may get updated less frequently than the macrocycle, if you have "too many" devices on the same segment. This also applies to setpoint changes and mode changes (AUTO to MAN, etc.) - which are also asynchronous. How many is "too many" depends on what other function blocks are configured and how fast they are capable of executing. This is dependent on the manufacturer of the device(s) and the device revision.

4) How "close to the brink" of maximum power consumption are you willing to run? You may design for another 40 mA of current, but I would strive to stay away from the ragged edge of minimum power requirements. This is greatly influenced by your choice of power conditioner and any IS or non-incendive qualification you are aiming to achieve.

These are a few of the reasons we chose to limit teh number and type of devices on critical segments. HTH . .

[Mike ONeill]

Usually DCS companies say 1 valve and its associated transmitter but that advice is based on the conventional single cable H1 segment. The latest FF color insert carries info for a new completely redundant confuguration, which changes that picture considerably, leaving the field device as the point with the highest failure rate and without redundancy.

[rezabejd]

Mike,

I think the fully redundant H1 network will find a niche, but I think the device is still the biggest single-point-of-failure in a well-designed "non-redundant" segment. In a land-based process plant in a reasonably inhabitable climate (i.e., not the North Sea, where so many of your customers have to function) - I think we can take reasonably good care of the wire. I've always liked to say, when the ubiquitous cherry-picker comes around and takes out our cable tray, we will have a multitude of problems, far surpassing failed instruments.

There are those out there who are still asking "where's H1 redundancy". You will likely see even more when SIS / ESD (safety) system vendors start supporting H1. A question which will become imprtant to address, especially when we start running HSE out in the plant, is "how clever must I be choosing routes for the redundant cables?"

I would wager a beer or two, that most of the problems we encounter are self-inflicted, or, as I've seen written somewhere, "if you make it fool-proof, they'll make a better fool". In choosing to limit the devices on "critical" segments, most of our thinking was along the lines of "avoiding opportunities to shoot ourselves in the foot". So, even if I have redundant cables, I may still keep the numbers down . . .