GuyMiller

Best Practice Rack 0

10 posts in this topic

Is there any reason not to have input and output modules on the same rack as the processor and Ethernet cards? We have RIO’s and sometimes have networking outages, I want to move critical IO to Rack0 the same rack as the processor, is this bad practice?  I've seen architecture for BMS that only have Ethernet cards and processors in Rack 0... 

Share this post


Link to post
Share on other sites

Burner management, especially for boilers, has some specific requirements but I’ve never seen anything that excludes DI and/or DO from being in the same rack. By way of example, my racks typically look like this (can be more or less for any card).

Processor

Ethernet (SCADA and HMI)

Ethernet (Remote IO if required. Different subnet, typically 10.)

DI

DI

DO

DO

AI

AI

AO

AO


I don’t think putting the Ethernet cards next to the processor is as critical in AB as it can be with other PLC’s but I prefer the order I listed. 

1 person likes this

Share this post


Link to post
Share on other sites

Be careful here!  Most BMSs are setup up with redundant controllers.  Are these redundant controller?  If so, you can't have any IO in the main rack.  I know this true for CNet, DNet and ENet.  Not sure about RIO.

You'll need to find and read the manuals.

2 people like this

Share this post


Link to post
Share on other sites
2 minutes ago, pcmccartney1 said:

Be careful here!  Most BMSs are setup up with redundant controllers.  Are these redundant controller?  If so, you can't have any IO in the main rack.  I know this true for CNet, DNet and ENet.  Not sure about RIO.

You'll need to find and read the manuals.

I've got three very large boilers about 250' from me. Not one of them has a redundant controller. The requirement is for the control PLC to be separate from the burner management PLC. They have that. For process heaters, we've never used redundant controllers (personally not a fan of redundancy but I'm sure it has a use somewhere). We also do not separate the process control from the BMS for non-boiler applications. In truth, you DON'T NEED a separate process control PLC for a boiler IF you control the process with a DCS or some other control system (technically that is separate). Some companies sell the 2 PLC approach but that's a sales of service thing, not an absolute requirement if you already have good process control in place.

I spent the better part of 25 years designing and implementing "non-boiler" burner BMS on everything from a 1MMBTU/Hr glycol reboiler to a couple of hundred MMBTU hot oil heaters. The last BMS was for a 20MMBtu/Hr lean oil still reboiler.

NFPA recommendations are pretty clear for the various types of heaters. NFPA 85, 86, and 87 define what is needed for the type of heater and they are easy to read and understand.  No redundancy required. Of course this is industry dependent and I'm only talking about the oil and gas industry.

Share this post


Link to post
Share on other sites

So we might have different definitions of BMS.  I'm calling it a Boiler rather than a Burner.  Having spent 15 years in the power generation industries, DCS controlled the plant  including the steam turbines, while redundant PLCs controlled the boilers and non-redundant PLCs for the BOP (Balance of Plant) controls.  I've seen every conceivable configuration 1v2, 1v3, 1v4 arrangements.  Even seen 5 CPUs in a ring where each controlled a elevation of the boiler (think the old Combustion Engineering tangentially fired boiler elevations or FW or BW boilers) and was the backup for another elevation.  Generally, the CPUs each had a main rack filled only with comms modules and then the additional racks had the IO with comms to talk back to the both PLC.

1 person likes this

Share this post


Link to post
Share on other sites

This is not a Burner Management System (I just happened to see BMS' set up like this); however, my application does have redundant controllers, I've consulted Rockwell and have found

"In a redundancy system, you can use only I/O modules in a remote chassis. You cannot use I/O modules in the redundant chassis pair. This table describes differences in network use for I/O in redundancy systems."

Thank you everyone.

1 person likes this

Share this post


Link to post
Share on other sites
21 hours ago, pcmccartney1 said:

So we might have different definitions of BMS.  I'm calling it a Boiler rather than a Burner.  Having spent 15 years in the power generation industries, DCS controlled the plant  including the steam turbines, while redundant PLCs controlled the boilers and non-redundant PLCs for the BOP (Balance of Plant) controls.  I've seen every conceivable configuration 1v2, 1v3, 1v4 arrangements.  Even seen 5 CPUs in a ring where each controlled a elevation of the boiler (think the old Combustion Engineering tangentially fired boiler elevations or FW or BW boilers) and was the backup for another elevation.  Generally, the CPUs each had a main rack filled only with comms modules and then the additional racks had the IO with comms to talk back to the both PLC.

I'm sure there are significant differences in the different industry practices as well as the practices of the company that operates the boiler. In our industry (Oil and Gas Processing) and in the companies I have worked for in the past (contract as well as being an employee), Fired heaters follow the NFPA 87 standard (I made ours more stringent and it tends to be very close to NFPA 85), Ovens and Furnaces, which we don't use, should follow NFPA 86, and of course boilers should follow NFPA 85. Interestingly enough, the BMS on the two Cogens
across the road from me, have a fairly primitive form of BMS. Controls were in the Foxboro DCS and the BMS is a Honeywell relay based system (that has a known flaw that has caused one explosion that I'm aware of. The aftermath of the result of the flaw is actually what got me into BMS design a long time ago). If we start them back up I'm not sure what we will do for the BMS other than we will not leave the relay system in place. It'll probably be an Allen Bradley CLX. 

Chapter 4 and 5 of NFPA 85 is where the control system requirements are laid out. They are pretty specific but don't require specific hardware or redundancy. The do require separate controls (what used to be called the boiler fireman, which in the "old days" was an actual person that adjusted a valve) than the burner management system (lighting and shutdown control).

If my customer said thou shalt use redundant PLC's I'd have more than happily provided them with the solution they wanted for the appropriate fee :o)

1 person likes this

Share this post


Link to post
Share on other sites
6 hours ago, GuyMiller said:

This is not a Burner Management System (I just happened to see BMS' set up like this); however, my application does have redundant controllers, I've consulted Rockwell and have found

"In a redundancy system, you can use only I/O modules in a remote chassis. You cannot use I/O modules in the redundant chassis pair. This table describes differences in network use for I/O in redundancy systems."

Thank you everyone.

That's what I like about this forum. I don't come from a background in redundancy so I didn't even think about the answer in that way, however, there are many, very good, voices here. I'm glad that you got your answer.

Share this post


Link to post
Share on other sites

Michael, you and I have talked a few times over the years.  I also have many years in the refining and down stream processes.  Again mostly the DCS side but remember safety systems (like ICS Triplex) being in charge of controlled and emergency shutdown.  Usually a triple voting system, hence 1v3.

On the cogen side, I also did 22+ ABB Combustion Turbines with a hybrid control system with a high speed analog controller for speed, temperature, fuel/air ratio, VAR, etc..  Again, the safety systems were in another PLC with the 1v3 voting system.  A governor system served as an additional backup with 1v3 hydraulic valve voting systems.

It all seemed to be about availability, redundancy, hot-swap of components from controllers, IO Modules, and all the way down to triple redundant power supplies with load sharing.  You and I both know that a power plant or a refinery comes down for service only once every five or ten years.

1 person likes this

Share this post


Link to post
Share on other sites
1 hour ago, pcmccartney1 said:

Michael, you and I have talked a few times over the years.  I also have many years in the refining and down stream processes.  Again mostly the DCS side but remember safety systems (like ICS Triplex) being in charge of controlled and emergency shutdown.  Usually a triple voting system, hence 1v3.

On the cogen side, I also did 22+ ABB Combustion Turbines with a hybrid control system with a high speed analog controller for speed, temperature, fuel/air ratio, VAR, etc..  Again, the safety systems were in another PLC with the 1v3 voting system.  A governor system served as an additional backup with 1v3 hydraulic valve voting systems.

It all seemed to be about availability, redundancy, hot-swap of components from controllers, IO Modules, and all the way down to triple redundant power supplies with load sharing.  You and I both know that a power plant or a refinery comes down for service only once every five or ten years.

We are 100% in agreement and I've enjoyed those conversations. I have no refinery or power plant experience but I know there is a big difference between either of those tripping off and a gas plant tripping off. Things go bad quickly when a refinery has an unplanned shutdown. What we do is simple by comparison.

I went to an SIS design training class led by Paul Gruhn many years ago. We had people from TAPS (Trans-Alaska Pipeline System, we are working on owning that and a bunch of other North Slope assets as I type this), refinery, chemical, power, and even pharmaceutical people in the class. They had some very interesting problems to solve. I spoke to Paul after class because I wanted to see if my take on his class was correct. My take was that by many orders of magnitude, the gas processing industry was simpler than any other represented industry in the class. Paraphrasing, he said that he wasn't sure why we had signed up for the 4.5 day class but he was glad we came.

In our world, If a control function is even assigned a SIL rating, it's typically only 1 (I'm not talking about the MOC process). 1oo1 voting is adequate however I do like to use a level transmitter in conjunction with a level switch. ESD systems are mostly hard-wired relay based. If it's a safety critical analog device we usually install two wired to the same PLC and different IO card but we don't have many of those.  Some locations, purchased from others, have Triconix and AB Safety Rated hardware but those aren't even used in a way that makes sense (one transmitter wired to two inputs for 1oo2 voting?) Our DCS systems are redundant. Some PLC systems are redundant but it's not what I prefer, in a gas plant. We can usually solve the problem where a processor fails pretty easily. Everything fails safe by design and while we don't like downtime it's manageable, so shut down, we pull a new processor out of the parts bin, reload the program, and start back up. I've seen that once with an Allen Bradley in 15 years and a lot of different facilities and, though it took a few months for the real problem to manifest itself (bad IO rack) the problem showed up again. This time in such way as to indicate that the backplane was bad, which explained why the processor we sent to AB came back as tested good. Ie we can tolerate an outage much easier than other industries can. Well... it depends on the size of the facility. A BCF/Day is not something you want to see go down. A 10,000 horsepower pipeline pump station with 5 days of storage is much easier to deal with. 

A redundant GE system of ours failed a couple of years ago. I was managing the plant at the time and the operator called to ask me a few questions about a problem he was having. No urgency but the problem was strange enough that I drove out and, though I'm not familiar with GE, I was able to troubleshoot well enough to call a friend / coworker and ask if it was possible for both processors on the redundant racks to lose their mind. It turns out, for GE, it is. The primary and secondary controller lost the entire program. No clue why. GE couldn't figure it out (but they were happy to charge us to check the processor out), and it wasn't a power issue. All of the IO held last position because that's what the programmer told it to do (not how I would have done it) and the plant continued to run. We talked to the operator and he said that there was only one loop not working and "there wasn't that much on the PLC". We supplied fuel to a refinery that was about 1/2 mile away. Shutting down was always sketchy due to being the source of fuel to a fairly large refinery. Going on bypass was the usual solution to any problem. Their fuel would go rich but they just blended it out. So, with that in mind, the engineer and I decided to run until Monday morning (1/2 a day) until our GE guy could come reload the programs. The PLC "wasn't doing anything anyway". It ran perfectly all night. But, um... yeah, there were 23 control loops, 18 were real important. It's a wonder the place didn't come down but that is how simple gas processing, by comparison, is. And luck counts. We found out the hard way that the control parameters, I think there are over 20 for each loop, do not save with the program. So when he loaded the program and switched the controller to run "stuff" started hitting the fan when all of the control valves moved to 0% input. Primary overpressure protections is a relief valve in our plants. Those started "working" and we tripped the ESD to bring the plant to a safer state. We were already on bypass. The flare system worked fine. There was some confusion for why the loops weren't working. Finally someone checked parameters and they were all 0. Thankfully whoever built the HMI historized all of the parameters and we were able to pull them and reset all of the loops. It took two guys about 4 hours to fix them.  The plant was online about an hour after startup began. We were running on a new processor and redundant processor. We had two in stock. If not for the control loop issue everything would have been resolved much sooner. I'm not a fan of GE PLC's...

1 person likes this

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now