Hi guys,

I am working in a project where we need to perform a 2 out of 3 voting using fieldbus devices, however the devices are installed in 3 different H1 segments.

How can I perform this voting? I mean, if they are not including in the same segment how they can communicate each other? Just for information I'm using Delta V system.

Thanks,
Thiago

 

Thank you for your good question, and a challenging opportunity.

A smart logic solver will be able to distinguish a sensor failure from a process failure. The smart logic solver is smart enough to not trip the system as sensor failure.

However, the voting scheme is to be implemented over multiple segments.

This is my preliminary suggestion. I need to review and discuss the following with experts.

1. IEC 61511
2. Delta V System
3. Logic solver application

If I find a sure solution I must tell you the development, as it is very interesting and pioneering.

Thank you once again for giving me a chance to think on the subject.

In the meantime, if you want to provide any information (standards, manuals) to help, please contact me at tapas @ daresd. com

 

I ran your question by one of our fieldbus consultants (http://www.emersonprocess.com/solutions/consulting/fieldbus) and here's his reply:

It appears that there are redundant instruments, such as level transmitters, of same process measurement. So owner wants 2oo3 voting to give best chance of really knowing the level. To eliminate single point of failure, each transmitter is on separate segments, and also ought to be on separate H1 cards.

The only viable technique is to bring all the data into a control module inside DeltaV and perform the 2oo3 logic there. Probably, I'd use "middle select" and alarm if the high or low deviated more than some allowable amount from the middle, or if there was bad status. The only FF precaution is that since measurements are on separate segments, there is some lack of consistency (due to sample time translation), so therefore if process variable is ramping, a false deviation due to taking measurements at different points in time is likely. The controls engineer needs to factor in maximum process rate of change and not set the deviation alarm so small that difference in time sampling gives a false alarm. Since most FF devices are pretty fast, usually this can be estimated on macrocycles alone. But in the case of temperature deviation and using a slower device (such as 848T, which can be 1.5 seconds between updates), the device acquisition time has to be added to the macrocycle time. Rail bus delay in DeltaV backplane factors in as well, but is usually much faster than macrocycle, so usually it is ignored. (the reason why engineers use a little design margin in most things they do.)

The guy asking how to do it appears to believe FF can only be "control-in-field." but in this case, it is an I/O bus and the 2oo3 is "control-in-controller."

Hope that helps,
Jim Cahill
http://www.EmersonProcessXperts.com

 

Hi,

As very correctly indicated by EPM process expert
It has to be on 3 xtr on 3 different segment & voting to be carried out in Delta V controllers.
Interprocess delays amongst 3 segment is negligible, but clock synchronisation is critical
but managable. Check scan time of voting result?

We personally feel you require dedicated
function blocks for performing this function &
check about the availability of dedicated FB in
Delta V controllers. This is a must.

You can always use multiple function blocks to achieve this voting, but keep it mind this scheme
does not have bumpless transfer from 3-->2--> 1
transmitters in case of failure/isolation of xtrs.
If you are using it for control purpose, it is still a delicate situation.

We have implemented this type of scheme with split
architecture system of Foxboro & Taylor, they have dedicated modules for 2oo3 voting, which was
truly bumpless in forward/reverse direction with
100/250 ms of response/processing time. But this was different time zone of 'RELIABILITY'.

PLEASE DECIDE ON CYCLE TIME FOR 2oo3 Voting.

We appreciate your feedback.

Jari
[email protected]