Member Login
Search
Jump to a Date
Sponsored Communities
Cool stuff
Twitter Feed
Neat Stuff

Visit our shop for nerds in control lifestyle products.
Thermal Overload
The threads that wouldn't die...
- PC reliability?
- Windows, real time
- PID loops
- PCs vs. PLCs
- Replacing people
- MS 'monopoly'?
- Software quality
- Where do we go from here?
- Why pay?
- PC reliability?
- Windows, real time
- PID loops
- PCs vs. PLCs
- Replacing people
- MS 'monopoly'?
- Software quality
- Where do we go from here?
- Why pay?
Fortune
Real Users hate Real Programmers.
RSS Feed
www.control.com/rss/
To get a personalized feed, become a member at no cost.
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
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
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
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
iconcnl@vsnl.net
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
iconcnl@vsnl.net
Your use of this site is subject to the terms and conditions set forth under Legal Notices and the Privacy Policy. Please read those terms and conditions carefully. Subject to the rights expressly reserved to others under Legal Notices, the content of this site and the compilation thereof is © 1999-2009 Nerds in Control, LLC. All rights reserved.
advertisements
Servo, stepping motor control, analog & web HMI in one system!
Find the right Modbus device for your project... or list your Modbus device on the largest online Modbus device directory.
Control.com is the largest Automation community on the web. Learn how to advertise here now...
Our Advertisers
Help keep our servers running...
Patronize our advertisers!
Patronize our advertisers!



