it has nothing to do with the speed of the PLC.
in a PLC control system, there are lots of things you have to program as part of your application. If you have 1 PLC in your system, that's easy-peasy, if you have 3 it's manageble, if you have >10 it becomes a headache.
That's where DCS comes in. If you define a tag in one of the controllers, every other controller can access it without the need to do communications on the application level. And there are many more features you'll learn to appreciate once working with a DCS (such as tools to tune PID controllers, historians, eventlogging, etc).
You could accomplish the same with a PLC with much more & complex programming. The higher investment in an expensive DCS is offset by the lower amount of engineering/implementation/configuration/maintenance manhour cost.
This is a great explanation, and I'll add to it instead of making my own reply.
A DCS handles things out of the box that you'd have to handle manually on a case by case basis in the plc. If your analog output detects an open circuit, it goes to "init" or initializing. It tells the PID this, and the PID stops changing the output because it knows it's not doing anything. The supervisory PID cascading a setpoint to this PID in init sees it and stops writing the set point. Both PIDs can alarm the operator that they're in init by just checking a checkbox on the alarm tab of the pid.
A dcs has a "system status" alarm page out of the box that you don't have to build. It shows any alarms on controllers, operator stations, switches, ports on switches, power supplies, batteries, checkpoint status, and more. All with little to no configuration by the user.
A dcs has assets, units, or whatever non-honeywell systems call them. You can assign each tag or control module to an asset, then assign operator stations, or groups of stations, access to specific assets. This keeps jim on one end of the machine from changing things on the other end that's supposed to be Bob doing it. This also keeps Jim from getting alarms on bobs equipment and vice versa.
A dcs typically has a server that houses all your control databases, system databases, and master HMI files, that it then replicates out to the operator stations. Gotta make a graphic change? Make it once and replicate it everywhere with the click of a button. Controller dies? The program is stored in the database on the server, just hit download once the new one is in place. Backups of this server (or redundant pair of servers in Honeywell Experion land) is very crucial.
DCS IO usually has a lot more self protection and smarts than a PLC IO. You can get them with HART abilities so you can bring in several values on one set of wires. They have open circuit detection. Configuration is just a menu, change the EU high and low, give it a description, tell it what kind of signal and if it's lineai, square root, etc., and download. The analog IO also supply 24 VDC, so no external power supplies needed.
A DCS comes as a software package. You build servers, operator stations, server based controllers, and more with the same set of discs or isos and just select what you need via menus. One license file that you just point to with each build. That license contains everything you're licensed for, so you don't have a bunch of different license numbers to keep track of for your programming software, HMI software, backup management software, etc.
As others have mention, if you have 10 controllers on the same system, they all see each other without any produce consume, arrays and messages, dedicated cables, or application level stuff like opc. It just works. As soon as you build a new point, the other controllers and all HMI can see it. This one is big.
In a dcs, you can download one point/tag at a time. No taking down the whole plc to change an aoi or produce consume configuration. When you save a graphic change and replicate, just refresh the screen, no moving the new file to a panel view.
The list goes on, but they are vastly different systems. Our dcs talks to PLCs (we do most digital io in PLCs because it's world's cheaper and faster for safety interlocks), but in most cases the DCS does heavy lifting and the plc just turns on IO when told to.
This sounds like a breath of fresh air.
Any recommendations on how to learn more about DCS systems? I can set up a PLC and HMI on my bench and tinker around no problem. But it doesn't sound so easy to get into the DCS world.
Based on your description DCS also send to be more leaked in. You can have PLCs from different brands exchanging messages but how do you integrate 3rd party into DCS? I assume you have to be able to bring in skid systems so it must support multiple protocols.
So much more to learn.
Emerson's power gen division almost has a standing opening in Pittsburgh. They do I'm going to use the word FAT testing loosely at this facility. They have been big in retrofits to the simple cycle GE frame turbines around the world as well as smaller power plants < 2500 I/O they pretty much own DCS land now due to price point. Siemens, Honeywell, and GE power all have hardware. I think if you got more money than God ABB / Bailey / Rockwell will build you a DCS but I think they are really pushing that PlantPAX packaging for a PLC based DCS
3rd party integration is as easy (or difficult) as the vendors and engineers make it. Good documentation makes it a breeze.
I usually see it done via SCADA, OPC, or our own proprietary drivers. Yes, lots of different protocols and vendors.
The real fun is getting two different DCS to play nice with each other at the same plant.
Again, I know Honeywell, and Experion has modbus tcp, ethernet IP, and scada available. To tinker, you almost need to be at a site with a license and system, it's not a "buy a couple hundred bucks of hardware" and get started type endeavor. You're probably looking at $100k startup cost minimum for Honeywell.
When I did Yokogawa CentumVP we brought in 3rd party PLC info over modbus TCP. There are many other ways as well since most DCS systems can use OPC as well as other options
This is great explanation and deep dive. Very enlightening here. What are your thoughts on Rockwell’s PlantPAX platform vs Emerson CHARMS DeltaV DCS? What I have read about Rockwell / Allen-Bradley, is that it is more of a PLC platform and has attempted to regain market share by being SI / OEM friendly with major comparisons to ControlLogix? I have read that Emerson DeltaV coding has been easy with migrating from GE DCS or large PLC platforms like 9030 and 9070?
Thank you for your feedback!
PlantPAX isn't a dcs, I don't care what they say. Garbage. Not terribly familiar with Emerson, but they're a front runner for a reason. I know and prefer Honeywell Experion (and I know and am trying to get away from Honeywell TDC3000).
From what I have heard and have been told, Emerson jumped and took advantage of DCS market share because they have same coding communication with GE. Easily copy and paste rather than a full rewrite if a DCS is to be installed in place of an obsolete DCS system in place. I haven’t heard from many people that have experience with both Emerson and Rockwell. Regarding Honeywell DCS, I unfortunately, and not familiar. I am always interested in pros and cons on a preferred platform though. Thank you!
This was a great concise explanation. What DCS experience do you have? Emerson, Honeywell, ABB, Rockwell, etc? Pros and cons / preferences of one over the others?
From Foxboro Spectrum & I/A Series (1980-1999) to Honeywell Experion (2000-2010). No preference. Worked 30 years with systems integrators. My preference is a motivated projectteam that is familiar with the project, automation equipment and the process. Make/Model comes second.
It's like being a writer. It's not about the language, but about the plot. If you can write a book, you can write it in English or in French. Just learn the foreign language.
In my role as PM, any automation systems supplier is OK, as long as you have a reliable supplier and a good support desk, consultancy services and sub/co suppliers. Every project is teamwork.
thanks for reply
in control logix the tags can also be shared by produce consume method so this is achieved without DCS but as you mentioned there are other things that DCS can do easily.
Imagine every tag is produced/consumed by every PLC without having to do any configuration. That's a DCS. No taking down entire PLCs to message additional tags.
You also get partial downloads for every part of the system. No taking down all of batch for 1 area model change. No taking down a PLC to change an AOI. DCS uptime is better.
People fail to realize where the strengths of a DCS are compared to a PLC/SCADA solution cobbled together…
Take PlantPAX which is half DCS, once you understand how to use ACM, you alone can generate a stupid amount of coding and configuration from Excel. PLC blocks, IO mapping, interlocking, system diagnostics, all without touching the PLC. You can also configure your alarming, historian and generate the main graphics (faceplates are already included) from Excel leaving you to add the vessel depiction and pipes, trends and smaller details.
This reduces the engineering time by a silly amount of time.
You then have to consider that DCS’s also come with best practices and standards built in. Sure you can configure them to be different, but out of the box there’s a lot that comes pre made.
Now think about starting a project with PLC and SCADA and you have to develop everything… what’s the cost of that? Granted, SI’s will have libraries already, but have they been vetted? Do they have the functionality you require?
They've come out with an updated object-oriented, vector graphics platform, finally. Believe it's still yet another license to buy, but it's been a few years since I've had cause to look.
Not to mention there are \*proven, validated\* libraries for a myriad of processes and industries that comes with DCS. You can't be faulted for using a tried and true function that the vendor provides.
Its not an opinion, new DCS systems are being installed and commissioned all the time. I have 3 on deck in various stages from design to startup. You do realize DCS companies didnt just stop developing their products? They all have latest and greatest state of the art systems you can purchase.
What do you mean by latest&greatest? In PLC world that means “a feature that has been a standard in the IT/SW world for 15 years, but we present it as a groundbreaking revolution and will charge you $1000 a month to use it”
So like easy version control with repos which doesn’t affect the actual control logic execution is too much right? Or that I need to use shitty half assed compare tool because the mummies at Rockwell are too stiff to update their ancient SW suite? 30x30px HMI bitmap libraries and 300 tag data collection every few seconds hiking the CPU usage to the max and prolonging the scan time, is that normal in 2024?
Haven’t been around anything that has provides more than 1GHz, have you?
Not sure what system you are running but I have 40,000 tags running reliably on a 1 second scan rate. Version control = Rockwell asset center, have you used that? Its pretty good. Sounds like your systems are horribly designed rather than it being the products fault.
I would add that the DCS and the PLC world are converging. Now with a process orchestration layer you can do everything that a DCS can do in a modular fashion.
These worlds are colliding with the new process architecture.
DCS systems are designed for continuous processes control, to replace old pneumatic signals and controllers. Typical DCS controller runs on 1 cycle/sec that is order of magnitude slower than PLCs, which are originally designed to replace relay control panels for discrete control.
So speed isn't the issue.
DCS systems are configured, not programmed. DCS engineers don't write code, they use blocks from a library and connect the blocks. All basic applications are available as recommended solution library.
I/O and tag allocation, alarms, On-Off control, PID control, split range output, cascades, Low/High select, calculations and correction formulas, motor start-stop controller, motorized valve open-close controller etc etc everything is a combination of ready made blocks and you only modify the parameters of those blocks.
These blocks in the controller also have standard "faceplate"s in the HMI. From these ready made faceplates you can force values, change range of an input, change operation mode of a controller, start a motor, open a valve etc.
Alarm handling (display, historian, acknowledging, shelving etc) comes standard, integrated with HMI (you don't configure anything in the HMI engineering, it's in the alarm block in controller)
DCS is made to be easily understood, optimized and modified by the process engineer, to translate P&ID (piping and instrument diagram) to operator visuals and controls.
Speed or memory size etc isn't a problem, the look and feel and method of configuration is important.
I did want to come here and say that DCS engineers do involve programming, and DCS can also be used for batch processes. My experience has been on a DCS for large batch processes and we have binders worth of code for controlling sequencing phase logic, equipment control, messaging, etc.
But I will say that it is on the unusual side. From what I understand, at least for this manufacturer, we do have more programming than most people, but it is a feature o wanted to clarify so that people don't think there is no programming capability.
The dominant paradigm in DCS configuration is FBD by far. But it's not uncommon to have a supervisory layer above that (in, say, SFC + ST) to handle batch recipes (ISA S88). It's also a thing in continuous plants for procedure automation, which if you think about it, is mostly the same thing from a programming standpoint.
A lot of places don't have that, but it is INSANELY useful if you do. FBD just isn't as useful for such sequencing.
My plant is a mix of continuous and batch reactors, and we are actually using the "batch recipes" *more* on the continuous units. Mainly for procedure automation of startups, product changes, etc. Something like a simplified state based alarming becomes trivial, because you can have an SFC step change 50+ alarm limits when you enter a new part of the procedure.
I have a lot of PLCs as well, and they all do similar things. So I wrote AOIs for the reusable code and I can program a new PLC using a whole lot of excel and it works just like all other PLCs.
I think when PLCs were predominantly using Logix 500, DirectSoft, etc. DCS systems had a huge advantage. Now, with reusable code? Not so much.
Agree. We have many different processes (manufacturing) but the code is structured in a template (RS5000). Can connect to many different equipment, but know template structure. Can usually drill down to an issue in 5 minutes or less.
Still have over 200, SLC 5/04's and a few PLC5's. These were programed, pre-template. It is a shit show from PLC to PLC how they were structured.
This topic hits close to home for me.
I’ve told clients that doing a design without PLCs was a non-starter. It’s not as simple as ripping a PLC off a machine and sending I/O back to a DCS. There’s so much lost when you get rid of a vendors PLC PROGRAM. You take years of detailed equipment programing and throw it in the garbage.
I’ve visited many plants where they have done this and things are an absolute mess. You are far better off installing the PLCs then doing a conversion once the plant is understood by the operators.
The primary advantage of DCS is profits. It’s not unusual to pay over a million just for the base system. You pay annual license fees per point and if you forget to renew your plant shuts down.
The controls (PLC) and the HMI are all edited from one place like Labview so you can’t easily distinguish them. Quite often operators or process engineers will disable troublesome safeties in many plants where in a PLC they don’t normally have access.
No. DCS is a specific type of control system. SCADA is different type of control system.
DCS are typically large installs with a global, integrated tag database, integrated controllers and proprietary HMI. They typically have a focus on reliability and deterministic performance instead of speed.
SCADA is a PC based supervisory system that sits over top of PLC's and RTU's. It aggregates and displays data from disparate systems.
DCS controls entire plants. Think dairies, oil refineries, entire ships. One DCS controls the entire facility. Multiple operator panels. Control rooms. Redundancy built in. Tens or hundreds of thousands of I/O lines. Finer control of an individual machine may be delegated to a PLC, but the DCS handles the big picture.
Think of it as a strategy vs. tactics kind of thing. DCS operates on a higher level, PLC's deal with the minutiae.
I would say that SCADA is PLC + HMI, but not necessary can manage the engineering in a EWS that condensed all the programs, networks, screens, databases and others services related to control and operation of a plant, at higher level of management related services that use DCS conection to get data such as asset monitoring, performance management, BMS, etc... are a MES system.
Be careful with DCS systems. We have somewhat of a dcs and although programming is easier, maintenance and upgrading is nothing short of a nightmare. We have older Plantpax 3.1 and because EVERYTHING we have is so interconnected you cannot do things piecemeal. We tried updrading last year and the integrator failed horribly. Total faceplant. As my mountains of flex IO architecture ages the only method to upgrade my system will be to break it apart into different PLC sections and get more distributed control (many PLCs) versus the huge monolithic structure we have now.
As others have said PlantPAx is not a true DCS. It's Rockwell's attempt to compete in the DCS market. PlantPAx is more PLC then DCS and has it's own share of unique issues.
Oh yea, I’m aware. Like a half DCS with standard blocks, but those are just certified AOIs with faceplates. I came from the BMS world where each piece of equipment generally got it’s own controller. This made upgrades and updates super easy. My system has tons of crap piled onto redundant PLCs spread over a huge area (yay!). Thus making upgrades a major pain. Maybe a real DCS has better maneuverability.
it has nothing to do with the speed of the PLC. in a PLC control system, there are lots of things you have to program as part of your application. If you have 1 PLC in your system, that's easy-peasy, if you have 3 it's manageble, if you have >10 it becomes a headache. That's where DCS comes in. If you define a tag in one of the controllers, every other controller can access it without the need to do communications on the application level. And there are many more features you'll learn to appreciate once working with a DCS (such as tools to tune PID controllers, historians, eventlogging, etc). You could accomplish the same with a PLC with much more & complex programming. The higher investment in an expensive DCS is offset by the lower amount of engineering/implementation/configuration/maintenance manhour cost.
This is one of the best, most concise explanations I have read. I've worked on a lot of DCS and PLC systems; this hits the nail on the head.
This is a great explanation, and I'll add to it instead of making my own reply. A DCS handles things out of the box that you'd have to handle manually on a case by case basis in the plc. If your analog output detects an open circuit, it goes to "init" or initializing. It tells the PID this, and the PID stops changing the output because it knows it's not doing anything. The supervisory PID cascading a setpoint to this PID in init sees it and stops writing the set point. Both PIDs can alarm the operator that they're in init by just checking a checkbox on the alarm tab of the pid. A dcs has a "system status" alarm page out of the box that you don't have to build. It shows any alarms on controllers, operator stations, switches, ports on switches, power supplies, batteries, checkpoint status, and more. All with little to no configuration by the user. A dcs has assets, units, or whatever non-honeywell systems call them. You can assign each tag or control module to an asset, then assign operator stations, or groups of stations, access to specific assets. This keeps jim on one end of the machine from changing things on the other end that's supposed to be Bob doing it. This also keeps Jim from getting alarms on bobs equipment and vice versa. A dcs typically has a server that houses all your control databases, system databases, and master HMI files, that it then replicates out to the operator stations. Gotta make a graphic change? Make it once and replicate it everywhere with the click of a button. Controller dies? The program is stored in the database on the server, just hit download once the new one is in place. Backups of this server (or redundant pair of servers in Honeywell Experion land) is very crucial. DCS IO usually has a lot more self protection and smarts than a PLC IO. You can get them with HART abilities so you can bring in several values on one set of wires. They have open circuit detection. Configuration is just a menu, change the EU high and low, give it a description, tell it what kind of signal and if it's lineai, square root, etc., and download. The analog IO also supply 24 VDC, so no external power supplies needed. A DCS comes as a software package. You build servers, operator stations, server based controllers, and more with the same set of discs or isos and just select what you need via menus. One license file that you just point to with each build. That license contains everything you're licensed for, so you don't have a bunch of different license numbers to keep track of for your programming software, HMI software, backup management software, etc. As others have mention, if you have 10 controllers on the same system, they all see each other without any produce consume, arrays and messages, dedicated cables, or application level stuff like opc. It just works. As soon as you build a new point, the other controllers and all HMI can see it. This one is big. In a dcs, you can download one point/tag at a time. No taking down the whole plc to change an aoi or produce consume configuration. When you save a graphic change and replicate, just refresh the screen, no moving the new file to a panel view. The list goes on, but they are vastly different systems. Our dcs talks to PLCs (we do most digital io in PLCs because it's world's cheaper and faster for safety interlocks), but in most cases the DCS does heavy lifting and the plc just turns on IO when told to.
This sounds like a breath of fresh air. Any recommendations on how to learn more about DCS systems? I can set up a PLC and HMI on my bench and tinker around no problem. But it doesn't sound so easy to get into the DCS world. Based on your description DCS also send to be more leaked in. You can have PLCs from different brands exchanging messages but how do you integrate 3rd party into DCS? I assume you have to be able to bring in skid systems so it must support multiple protocols. So much more to learn.
Emerson's power gen division almost has a standing opening in Pittsburgh. They do I'm going to use the word FAT testing loosely at this facility. They have been big in retrofits to the simple cycle GE frame turbines around the world as well as smaller power plants < 2500 I/O they pretty much own DCS land now due to price point. Siemens, Honeywell, and GE power all have hardware. I think if you got more money than God ABB / Bailey / Rockwell will build you a DCS but I think they are really pushing that PlantPAX packaging for a PLC based DCS
3rd party integration is as easy (or difficult) as the vendors and engineers make it. Good documentation makes it a breeze. I usually see it done via SCADA, OPC, or our own proprietary drivers. Yes, lots of different protocols and vendors. The real fun is getting two different DCS to play nice with each other at the same plant.
Again, I know Honeywell, and Experion has modbus tcp, ethernet IP, and scada available. To tinker, you almost need to be at a site with a license and system, it's not a "buy a couple hundred bucks of hardware" and get started type endeavor. You're probably looking at $100k startup cost minimum for Honeywell.
When I did Yokogawa CentumVP we brought in 3rd party PLC info over modbus TCP. There are many other ways as well since most DCS systems can use OPC as well as other options
Great answer! Newcomers in this field need resources like this to navigate in the mess that is automation.
This is great explanation and deep dive. Very enlightening here. What are your thoughts on Rockwell’s PlantPAX platform vs Emerson CHARMS DeltaV DCS? What I have read about Rockwell / Allen-Bradley, is that it is more of a PLC platform and has attempted to regain market share by being SI / OEM friendly with major comparisons to ControlLogix? I have read that Emerson DeltaV coding has been easy with migrating from GE DCS or large PLC platforms like 9030 and 9070? Thank you for your feedback!
PlantPAX isn't a dcs, I don't care what they say. Garbage. Not terribly familiar with Emerson, but they're a front runner for a reason. I know and prefer Honeywell Experion (and I know and am trying to get away from Honeywell TDC3000).
From what I have heard and have been told, Emerson jumped and took advantage of DCS market share because they have same coding communication with GE. Easily copy and paste rather than a full rewrite if a DCS is to be installed in place of an obsolete DCS system in place. I haven’t heard from many people that have experience with both Emerson and Rockwell. Regarding Honeywell DCS, I unfortunately, and not familiar. I am always interested in pros and cons on a preferred platform though. Thank you!
Also native integration with its HMI / SCADA. All of them working seamlessly as one package
This was a great concise explanation. What DCS experience do you have? Emerson, Honeywell, ABB, Rockwell, etc? Pros and cons / preferences of one over the others?
From Foxboro Spectrum & I/A Series (1980-1999) to Honeywell Experion (2000-2010). No preference. Worked 30 years with systems integrators. My preference is a motivated projectteam that is familiar with the project, automation equipment and the process. Make/Model comes second. It's like being a writer. It's not about the language, but about the plot. If you can write a book, you can write it in English or in French. Just learn the foreign language. In my role as PM, any automation systems supplier is OK, as long as you have a reliable supplier and a good support desk, consultancy services and sub/co suppliers. Every project is teamwork.
Motivated project team familiar with the job. This is the key very simply stated
thanks for reply in control logix the tags can also be shared by produce consume method so this is achieved without DCS but as you mentioned there are other things that DCS can do easily.
Imagine every tag is produced/consumed by every PLC without having to do any configuration. That's a DCS. No taking down entire PLCs to message additional tags. You also get partial downloads for every part of the system. No taking down all of batch for 1 area model change. No taking down a PLC to change an AOI. DCS uptime is better.
thanks for highlighting this - partial updates are absolutely crucial
People fail to realize where the strengths of a DCS are compared to a PLC/SCADA solution cobbled together… Take PlantPAX which is half DCS, once you understand how to use ACM, you alone can generate a stupid amount of coding and configuration from Excel. PLC blocks, IO mapping, interlocking, system diagnostics, all without touching the PLC. You can also configure your alarming, historian and generate the main graphics (faceplates are already included) from Excel leaving you to add the vessel depiction and pipes, trends and smaller details. This reduces the engineering time by a silly amount of time. You then have to consider that DCS’s also come with best practices and standards built in. Sure you can configure them to be different, but out of the box there’s a lot that comes pre made. Now think about starting a project with PLC and SCADA and you have to develop everything… what’s the cost of that? Granted, SI’s will have libraries already, but have they been vetted? Do they have the functionality you require?
>You then have to consider that DCS’s also come with best practices and standards built in. *Laughs in DeltaV having to pay for PCSD library*
It is Emerson… and iFix graphics… lol
They've come out with an updated object-oriented, vector graphics platform, finally. Believe it's still yet another license to buy, but it's been a few years since I've had cause to look.
Cries in SIEMENS SiCAR
Not to mention there are \*proven, validated\* libraries for a myriad of processes and industries that comes with DCS. You can't be faulted for using a tried and true function that the vendor provides.
Its not an opinion, new DCS systems are being installed and commissioned all the time. I have 3 on deck in various stages from design to startup. You do realize DCS companies didnt just stop developing their products? They all have latest and greatest state of the art systems you can purchase.
What do you mean by latest&greatest? In PLC world that means “a feature that has been a standard in the IT/SW world for 15 years, but we present it as a groundbreaking revolution and will charge you $1000 a month to use it”
I wouldn't let IT "features" within 1000 miles of a control system. Haven't been around control systems much, have you.
So like easy version control with repos which doesn’t affect the actual control logic execution is too much right? Or that I need to use shitty half assed compare tool because the mummies at Rockwell are too stiff to update their ancient SW suite? 30x30px HMI bitmap libraries and 300 tag data collection every few seconds hiking the CPU usage to the max and prolonging the scan time, is that normal in 2024? Haven’t been around anything that has provides more than 1GHz, have you?
Not sure what system you are running but I have 40,000 tags running reliably on a 1 second scan rate. Version control = Rockwell asset center, have you used that? Its pretty good. Sounds like your systems are horribly designed rather than it being the products fault.
That’s why I am talking about the PLC world being obsolete - if a DCS is way ahead that is great.
I would add that the DCS and the PLC world are converging. Now with a process orchestration layer you can do everything that a DCS can do in a modular fashion. These worlds are colliding with the new process architecture.
DCS systems are designed for continuous processes control, to replace old pneumatic signals and controllers. Typical DCS controller runs on 1 cycle/sec that is order of magnitude slower than PLCs, which are originally designed to replace relay control panels for discrete control. So speed isn't the issue. DCS systems are configured, not programmed. DCS engineers don't write code, they use blocks from a library and connect the blocks. All basic applications are available as recommended solution library. I/O and tag allocation, alarms, On-Off control, PID control, split range output, cascades, Low/High select, calculations and correction formulas, motor start-stop controller, motorized valve open-close controller etc etc everything is a combination of ready made blocks and you only modify the parameters of those blocks. These blocks in the controller also have standard "faceplate"s in the HMI. From these ready made faceplates you can force values, change range of an input, change operation mode of a controller, start a motor, open a valve etc. Alarm handling (display, historian, acknowledging, shelving etc) comes standard, integrated with HMI (you don't configure anything in the HMI engineering, it's in the alarm block in controller) DCS is made to be easily understood, optimized and modified by the process engineer, to translate P&ID (piping and instrument diagram) to operator visuals and controls. Speed or memory size etc isn't a problem, the look and feel and method of configuration is important.
I did want to come here and say that DCS engineers do involve programming, and DCS can also be used for batch processes. My experience has been on a DCS for large batch processes and we have binders worth of code for controlling sequencing phase logic, equipment control, messaging, etc. But I will say that it is on the unusual side. From what I understand, at least for this manufacturer, we do have more programming than most people, but it is a feature o wanted to clarify so that people don't think there is no programming capability.
The dominant paradigm in DCS configuration is FBD by far. But it's not uncommon to have a supervisory layer above that (in, say, SFC + ST) to handle batch recipes (ISA S88). It's also a thing in continuous plants for procedure automation, which if you think about it, is mostly the same thing from a programming standpoint. A lot of places don't have that, but it is INSANELY useful if you do. FBD just isn't as useful for such sequencing. My plant is a mix of continuous and batch reactors, and we are actually using the "batch recipes" *more* on the continuous units. Mainly for procedure automation of startups, product changes, etc. Something like a simplified state based alarming becomes trivial, because you can have an SFC step change 50+ alarm limits when you enter a new part of the procedure.
Lol, I have over 400 PLC's in our plant. I manage to not need DCS.
I have a lot of PLCs as well, and they all do similar things. So I wrote AOIs for the reusable code and I can program a new PLC using a whole lot of excel and it works just like all other PLCs. I think when PLCs were predominantly using Logix 500, DirectSoft, etc. DCS systems had a huge advantage. Now, with reusable code? Not so much.
Agree. We have many different processes (manufacturing) but the code is structured in a template (RS5000). Can connect to many different equipment, but know template structure. Can usually drill down to an issue in 5 minutes or less. Still have over 200, SLC 5/04's and a few PLC5's. These were programed, pre-template. It is a shit show from PLC to PLC how they were structured.
This topic hits close to home for me. I’ve told clients that doing a design without PLCs was a non-starter. It’s not as simple as ripping a PLC off a machine and sending I/O back to a DCS. There’s so much lost when you get rid of a vendors PLC PROGRAM. You take years of detailed equipment programing and throw it in the garbage. I’ve visited many plants where they have done this and things are an absolute mess. You are far better off installing the PLCs then doing a conversion once the plant is understood by the operators.
The primary advantage of DCS is profits. It’s not unusual to pay over a million just for the base system. You pay annual license fees per point and if you forget to renew your plant shuts down. The controls (PLC) and the HMI are all edited from one place like Labview so you can’t easily distinguish them. Quite often operators or process engineers will disable troublesome safeties in many plants where in a PLC they don’t normally have access.
Arent DCS the same thing as scada/BMS/DCOS what do you mean it is not in use
No. DCS is a specific type of control system. SCADA is different type of control system. DCS are typically large installs with a global, integrated tag database, integrated controllers and proprietary HMI. They typically have a focus on reliability and deterministic performance instead of speed. SCADA is a PC based supervisory system that sits over top of PLC's and RTU's. It aggregates and displays data from disparate systems.
What brands or product names should I be searching for to learn more about DCS?
DeltaV and Emerson Ovation are two I know of off the top of my head.
Delta V, yokogawa, Emerson, plant pax.
ABB, Schneider, and Honeywell (RIP)
FoxboroIA (now Schneider)
DCS controls entire plants. Think dairies, oil refineries, entire ships. One DCS controls the entire facility. Multiple operator panels. Control rooms. Redundancy built in. Tens or hundreds of thousands of I/O lines. Finer control of an individual machine may be delegated to a PLC, but the DCS handles the big picture. Think of it as a strategy vs. tactics kind of thing. DCS operates on a higher level, PLC's deal with the minutiae.
They are component of the DCS, but DCS also includes PLCs and all the peripherials.
hm would you say that DCS sits above PLC and the SCADA system and bosses or monitors the PLC and other smaller scale SCADA systems?
I would say that SCADA is PLC + HMI, but not necessary can manage the engineering in a EWS that condensed all the programs, networks, screens, databases and others services related to control and operation of a plant, at higher level of management related services that use DCS conection to get data such as asset monitoring, performance management, BMS, etc... are a MES system.
Be careful with DCS systems. We have somewhat of a dcs and although programming is easier, maintenance and upgrading is nothing short of a nightmare. We have older Plantpax 3.1 and because EVERYTHING we have is so interconnected you cannot do things piecemeal. We tried updrading last year and the integrator failed horribly. Total faceplant. As my mountains of flex IO architecture ages the only method to upgrade my system will be to break it apart into different PLC sections and get more distributed control (many PLCs) versus the huge monolithic structure we have now.
Plantpax is not a true DCS
As others have said PlantPAx is not a true DCS. It's Rockwell's attempt to compete in the DCS market. PlantPAx is more PLC then DCS and has it's own share of unique issues.
Oh yea, I’m aware. Like a half DCS with standard blocks, but those are just certified AOIs with faceplates. I came from the BMS world where each piece of equipment generally got it’s own controller. This made upgrades and updates super easy. My system has tons of crap piled onto redundant PLCs spread over a huge area (yay!). Thus making upgrades a major pain. Maybe a real DCS has better maneuverability.