CLX redundancy with Devicenet Module DNB

[TEJ 0]

Dear Friends, Iam working on Oil Refinery project for which we have proposed the Control Logix L61Processor redundant system. Here the main thing is that we are doing redundancy switchover with 1756-DNB module instead of SRM module. The IO's and SCADA are in Ethernet communication through ENBT module in each rack. Let me clearly explain you the system configuration, Rack 1 Slot 0 -Clx - L61 Slot 1 - 1756-ENBT Slot 2 - DNB Slot 3 - Empty Rack 2 Slot 0 -Clx - L61 Slot 1 - 1756-ENBT Slot 2 - DNB Slot 3 - Empty Both the DNB's are connected through devicenet network. If you require more detail, let me know the same. Is anybody worked on similar system, please come forward. Thanking you in advance.

[TEJ 0]

Friends..... You can get intouch with my mail ID- tej_sjce@yahoo.co.in

[BobLfoot 302]

This is not a recommended approach or even supported any more. but deep in the bowels of the AB Tech Library you'll find a version 7 redundancy manual which told how to do redundancy with version 7 logix 5000 and only CNB Network cards. It was the pre-SRM approach and not pretty. You used GSV and SSV out the wazoo to change rack ownership and listen write rights on the fly. It did work however, anyone who has flow into or out of an unnamed major central Texas Airport on an unnamed major carrier has had a version 7.52 redundant controllogix plc track and process your baggage. I cannot imagine but what this approach would work for sharing the data with the DNB units and conrolling the I/O with the Enet instead of a CNB module. Sorry I've lost all links I had to the manuals but I've read them and they do or did exist.

[Ken Roach 194]

CompactLogix with the 1769-SDN scanner does support a "warm backup" architecture on DeviceNet. This is not a true redundancy architecture because it does not provide cross-loading or management of controller programs, edits, or data tables. If you need a warm backup system for a DeviceNet I/O subsystem, use CompactLogix. If you need a true redundant system, do not attempt to use ControlLogix and DeviceNet. This is not a supported architecture and will not be supported by any Rockwell Automation office, agency, distributor, or authorized integrator. ControlLogix redundancy is available and supported only with the ControlLogix Redundancy System, which entails ControlNet and Redundancy Modules.

[paulengr 44]

Bad idea, as has been posted before. If you really want to use DeviceNet instead of Controlnet, then you need to implement the SRM-module version. This means that you have 3 racks. Two racks have an L61, an SRM module, and a CNB (ControlNet) module. The third rack has a ControlNet module and the DNB module. In this configuration, you have DeviceNet-based I/O but have redundant capability. The reliability (MTTF) of this system by the way is not very good. Take a look at the AB document on implemented "SIL 2" which is effectively what you are doing. Even without redundancy in the processors, the MTTF of a standard L61 processor is so good that you can achieve SIL 2 out of the box. It's not obvious that it can work this way, but also consider using a GuardLogix processor and hear me out a little bit. There are two reasons for redundancy. First, there's safety, and second there's fault tolerance. Let's just consider the 1oo2 (one out of 2) case. If you detect that you have a failure in one of two identical components, then the safety approach would be to shut down the whole system (using component A to check the results of component B). The fault tolerant approach says to ignore the non-working component and continue operating with what you've got. The GuardLogix processor is intended for safety applications so it takes the "shut it down on fault" approach and seems to be at odds with the goal (reliability). HOWEVER, the GuardLogix processor is an order of magnitude more reliable than the stock L61 version. It is so reliable that it can be used in SIL 3 (control reliable, no single points of failure) applications. So even if you're not using it for safety purposes, this processor can achieve the same level of reliability WITHOUT adding redundancy to the system. Just add redundant power supplies. In terms of the overall architecture though I would not choose DeviceNet in the first place. When DeviceNet is working well, it is very, very good. However, a single cable failure or a faulty device can take down the whole system (bus off) because the specification is that if any device on the network sees a garbled packet, then it jams all communication. The result is that faulty wiring or devices can take down all devices. Regardless of how stable/reliable the actual "on the fly" switchover with DNB modules is, the design of DeviceNet is the antithesis of fault tolerance. Instead, I'd investigate going with either ControlNet with the dual-ring architecture or Ethernet/IP with a ring topology. Ethernet ring switches (Hirschmann, N-Tron, Sixnet are 3 such names) can recover in under 50 ms, quick enough that your ControlLogix processor may not even detect that a switch or cable failure had even occurred. Using RSTP you can recover in 1-2 seconds using non-ring managed switches which is slow enough that the processor will definitely recognize the fault but fast enough that most process industries are not severely affected. This is not quite as fancy as the ControlNet version where you have redundant connections directly to each I/O chassis (single point of failure issues exist with the switch/cabling at each I/O chassis) but since single points of failure exist at the hardware I/O level anyways, you won't really increase the MTTF by picking ControlNet over Ethernet/IP in a properly designed system. If this were truly a concern, you could use one of the I/O platforms that has dual Ethernet ports such as a 1756 chassis with a 1756-EN2TR or point I/O with a 1734-AENTR or a 1738-AENTR. However, I'm still not convinced that it will even scratch the surface in terms of lowering the MTTF enough to make a significant difference in terms of reliability of the overall system (the valves and to a lesser extent, sensors are still the major drivers when it comes to MTBF).