PLC Vs DCS 1.

PLC was earlier called programmable logic controllers but now it is more famou sly known as programmable controllers. the change was because of the fact that P LC'S can handle analog and digital I/O as earlier it could handle only digital. PLC'S are automatic controllers which is a substitute to hard wired controllers. DCS is implemented in areas for a larger control than PLC including several PLC and use of protocol such as MODBUS,ETHERNET,ETC. 2.In PLC programming part and visualization part i.e. SCADA both are separated b ut in DCS both are merged so that commissioning of DCS is much easier then PLC. Apart from this DCS having data handling capacity much better than PLC there are no limitation of using objects trends. Other than that visualization wise DCS i s much better then PLC. In Power Plants generally company recommends DCS bcoz DI /DO/AI/AOs are much high. In small application we can use PLC. 3.Now a days you cannot really tell the difference between a PLC or a DCS. Since the PLC was integrated with Analog I/O it crosses the boundary of being just di gital and crosses to the realm of DCS in handling Analogs, Bus Systems, Distribu ted I/O and etc. Also, since the DCS now handles logics of Digital I/O it also c rossed the boundary to the realm of PLC. 4.As you know PLC as to its name Programmable Logic Controller. Its main purpose is to replace the relay logic controls which is "On" or "Off". And DCS "Distrib uted Control Systems" its emphasis is Fast analog handling because of communicat ions through Bus systems, networking and etc A PLC can be a component of a DCS A DCS can include Networked PLCs PCs, or other control equipment sharing or dist ributing control of a process or processes. Key word being "distributed". Generally, PLCs are stand alone and perform a particular task, where a DSC is a network of PLCs / RTUs that communicate in some fashion to accomplish a particul ar task. For example, in a water filtration plant, there might be a PLC that is used to perform a backwash of a particular filter, in that same water plant a DC S may be communicating with 14 filter PLCs and starting the backwash routine whe n required. 1. PLC only handled sequential process than DCS can handled both Continue proces s and large loop control. 2. If we see from security angle, PLC doesn't have dongle so peple can crack the software easy. DCS have a dongle so it's only license to industry which have it . From my opinion DCS systems are more complex and include HMI. The realtime HMI d atabase is generated when programming the PLC which is the part of DCS system. W hen you want communicate with bare PLC the realtime database must be created "ma nually". In DCS systems the realtime database is also distibuted so each operato r station has its own RT database. There are also so called Hybrid System like H oneywell PlantScape where RT database is created automatically during PLC progra mming but is stored at realtime server so it is not distributed. Let's see how simple we can make it - by first building a SCADA system - and then by building a DCS system - each from the ground up. Suppose that we're building a brand new factory - and suppose that our first piece of equipment is something like a big industrial oven. This thing will be made u p of heaters, and valves, and conveyor motors, and other assorted machinery - so let's say we get to work and we build us an oven. Now that we've got the mechanical part of the oven built - we need some type of controller for it - something to accurately control all of those different parts in order to turn raw material in to a sellable final product. So what type of control are we going to use? How ab out a PLC - a Programmable Logic Controller? In very simple language a PLC is a type of computer. But the computers that most people are familiar with use a keyboard as an input device and a screen for an output device. PLC's don't have a keyboard. So for an input device, we use an input m odule which is basically a little box with a row of screws on the front of it. We wire up a bunch of pushbuttons, sensors, switches, etc. to the little screws .. . and this will serve as the input device for our PLC computer. We do something si milar for an output device. Instead of using a screen for an output device, we u

se an output module which is basically another little box with a row of screws on the front of it. We wire up a bunch of solenoid valves, indicator lamps, motor s tarters, etc. to the little screws ... and this will serve as the output device for our PLC computer. So for this first example, let's say that we decide to go with a PLC system. We bu y the PLC and install it by connecting wires between the oven and the PLC. Then we buy a copy of the programming software from the PLC manufacturer - and then w e write a program for the PLC - we'll probably use ladder logic programming, since t hat's what most PLC's use as their native language. And now the PLC is just about re ady to properly control the system - except that we still need some way for the operator to set and to monitor the temperatures - and to start and stop the conv eyors and so forth. Now for this small system, some meters and pushbuttons and some thumbwheel switc hes might do just fine. We could wire those up and build us an operator's control panel for our oven. But another (better?) way would be to use an HMI - a Human M achine Interface. (This used to be called an MMI - Man Machine Interface - but n ow-a-days we've got to be more politically correct.) So we buy us a nice desktop c omputer and some type of HMI software. We'll need to program the HMI - and usually this is done by dragging and dropping pictures of meters and knobs and buttons onto our computer screen. In other words, we build a virtual control panel for our operator to use. We link these on-screen controls to the PLC's memory through a c ommunication cable. And now we're finally ready to go. Great so far - and we start making some money with our factory. Later on, business is good and we decide that our factory could use two addition al ovens. So we get the mechanical parts built - and now we need to decide how w e're going to control these new ovens. Now the original PLC that we used for oven number one is quite capable of controlling the two additional ovens. We just mig ht need to add a few additional I/O modules to the chassis - and we'll certainly n eed to run some more wires - but basically the same old PLC brain has plenty of ex tra horsepower to handle the new ovens. But - here's an idea: Suppose that we buy two new PLC's - one for each new oven. Now that's certainly going to cost us more mo ney, but at least this way each oven could operate - or be shut down - completel y separately from the other two systems. That's going to make scheduling maintenan ce a lot simpler - and generally give us a lot more flexibility in all of our op erations. Plus - by having three controllers - we're not putting all of our eggs in one basket as the old saying goes. We talk the boss into it - and we buy the new PLC's and install them - and downloa d copies of the original program into them - and we're just about ready to go. But how about that operator control piece of the puzzle? Since we're already using an HMI for our operator's control panel, all we have to do is make two copies of the screens from our original oven - and set these new copies up on the operator's HM I computer. Finally, we extend the communication cable from the HMI station over to the two new PLC's - and now we're up and running. Next the boss hires a bean-counter - someone whose job involves maximizing our f actory's profits. Now this person requires data - he needs to know how much it cos ts to operate the ovens - and how much product we run through them - and how muc h of that product is off-spec and wasted. The best way to get all of this producti on data is to ask the PLC's - after all, they're the brains that are controlling the s ystem. So let's upgrade the old HMI that the operator has been using - to somethin g with more features. This will be called a SCADA system - for Supervisory Contro l And Data Acquisition. It will still have control screens with all of the virtua l buttons and meters and other whatnots that the operator needs to control the o vens - but it will also have some additional features beyond the HMI - features which will allow the SCADA system to suck the production data right out of the P LC's - and to store that data in some type of computer database. Later, the bean-c ounter can retrieve that production data and analyze it to his little heart's cont ent. All is well. Quick review so far: The machinery in our factory is being controlled by PLC's. Fo r a little while we used an HMI (Human/Machine Interface) software package - so that the Human operator could Interface (that is, monitor and operate) the Machi

ne. Later we moved from the HMI up to a more powerful software package - a SCADA (Supervisory Control And Data Acquisition) system. This new software still allo wed our human operator to Supervise and Control the system - and it also added s ome features for Data Acquisition for the bean-counter's benefit. Now let's start over with a new factory - and this time we'll use a DCS (Distributed Control System). Suppose that this time we know in advance that the factory we're about to build is going to involve a rather sophisticated process - one which is going to require many interrelated steps - all of which must be carefully coordinated in order t o produce a sellable final product. We're talking about chemicals - or pharmaceuti cals - or something along those lines. (The term continuous process is a familiar buzzword for something like this.) Now yes, we COULD use PLC's for this type of factory - and yes, we COULD use a SCA DA system to supervise and control the whole thing. But - many engineers would d ecide to go with a DCS for something like this. And that's what we're going to do. Now suppose that our new factory still needs something along the lines of our pr evious ovens - how would we control these? Instead of putting a PLC on each oven - we'll use a separate DCS controller for each oven. Now at first glance, these con trollers will each look a lot like an individual I/O module or I/O card in a PLC sys tem. They usually slide right into a chassis - and have wires for inputs and out puts connected to the front of them. So most DCS systems tend to look a lot like a PLC system. The big difference is that each of these DCS controller/card device s will be individually programmed. That's where the term DISTRIBUTED comes from - th e control (or brain-power if you prefer) is DISTRIBUTED among many individual cont rollers. Specifically, in a typical PLC system we generally have only one brain (o r processor) in each chassis - and then several I/O (input/output) modules in th e chassis to handle the signal wires to-and-from the machinery. On the other han d, in a typical DCS system we'll have several brains (or controllers) in a chassis and the I/O wiring associated with each particular brain's machinery will be connec ted directly to the front of that individual controller. Now what about the operator control function? Well, one integral part of a DCS s ystem is a large computer (usually a quite powerful one) which looks a lot like a SCADA terminal. And it does exactly the same job. First, it gives the operator a series of control screens with all of the virtual buttons and meters and othe r whatnots that he (or she) requires in order to control the machinery. Second, it also has the features required to suck the production data right out of the i ndividual controllers - and to store that data in some type of computer database . And in most DCS systems, there is a third function of the DCS terminal: The pr ogramming software for the individual controllers is also usually available on t his terminal - so that reprogramming the controllers is possible right over the existing data communication cables. Quick review of the DCS approach: The machinery in our factory is being controll ed by many individual little controllers. Our operator uses a DCS terminal (comp uter) to monitor and operate the machinery. This DCS terminal also has features to acquire production data and store it in a database for later analysis. Additi onally, the DCS terminal usually has the programming software required for the i ndividual controllers available. And all of the hardware and all of the software required for our DCS system is generally provided by just one manufacturer. Som e people think that's a good thing - and other people think that's a bad thing. In both cases the PLC or controller is sperately programmed and if programmed co rrectly can operate completely on its on and even share required data with other devices (PLCs, PCs, controllers...) and in each case the controllres or PLCs or PCs could send data to a host computer which provides overall operator interfac e, alarming, historical trending and such... you could even have local HMIs wher e you need them. In fact if you had twenty PLCs each programmed to perform a plant function and o nly send data to a HMI or SCADA computer would this not be a DCS system - the co ntrol operations are indeed distributed among the various PLCs, the PLCs do inde ed function on their own and are not dependent upon a host computer to tell them wha to do or when to do it. Is this not the basis of a DCS scheme? Also, the PL

Cs could share data with the other PLCs so they could act upon the information o btained to adjust their given function. I don't know about the PLCs you use, but the one's I use can completely operate a 25+MGD water plant with little or no operator interaction, except a little mon itoring and house keeping via a host SCADA computer. From your two rather long e xplainations, I was not able to see a real big difference. Any more the two are so intergal and integrated that it is hard to draw clear defining differences. B esides, I could use one PLC with plenty of I/O expansion capability to handle al l of the filters in a water plant and even the rest of the plant's operations, v s buying seperate controllers to do the same thing - to the bean counters I know this is a real money saver when put into the context of operational cost over t he life the plant vs the cost of the equipment. PLC was developed as a replacement for many relays. DCS was developed as a repla cement for many PID controllers. These days the difference between these two architectures is not very big. Both have a CPU card (controller module) and an I/O subsystem with I/O modules. In th e past a PLC was purely logic and the DCS purely continuous controller. The PLC was programmed in ladder and the DCS in function blocks. Today both handle all k inds of I/O and can be programmed in multiple languages. In the past a DCS inclu ded servers and workstations software whereas for the PLC the HMI software was p urchased separately. I.e. with a DCS you got an integrated system whereas with PLC you did system integration. In the past a DCS used only proprietary networking whereas a PLC used open network ing making it possible to connect third party hardware. In the past only the DCS applications were proprietary whereas the PLC was an open system. I.e. with the DCS all applications were tailored for the native hardware minimizing configura tion work but making impossible or unfeasible to add hardware and software from third parties. The PLC can freely u se third party hardware and software, required lots of configuration work, but a t least it was possible. Today PLC use OPC to make data available to software as a single integrated database with little of no duplicate work. At the same time , DCS also implement OPC as a gateway that makes access to some data possible al though it is still impossible to choose the workstation software and you still cannot connect third party devices to the DCS networking. These days most PLC manufactures have either bought or aligned them selves with HMI software companies supplying a total solution. Other differences in that past included far better diagnostics and redundancy in the DCS, but thi s gap has been closed. Today, many PLCs are sold as and used in applications whe re in the past only DCS could be used. Historically a DCS was also far more expe nsive, but the competition from PLC and new architectures have driven the initia l price of DCS down although the long term cost may be higher since with a DCS y ou are pretty much locked to a single supplier I think PLCs are parts of a either DCS or SCADA system, so that the question sho uld be DCS Vs. SCADA rather than DCS Vs. PLC. As the previous writer said, DCS stresses on processing (PID) control variables, while SCADA stresses on supervisory (watching). Today, either system is capable of doing both jobs. However, due to limited capabilities of the CPU and budget availability, one have to choose which one (SCADA or DCS) is more appropriate fo r a particular application, i.e 40% SCADA and 60% DCS or vice versa. Choosing th e ratio is implicited in choosing among several vendor/ sofware on the market. Main differences between TRUE DCS & PLC are: 1) Control 2) Communication 3) No. of I/Os that can be connected 4) Scanning time 5) History 6) MMI The biggest difference between DCS and PLCs is that DCS systems provide: Level of intergration between the controller, HMI and historical database (Commo n database, Faceplates/Function blocks interlinked.

Control algorithms for advanced control strategies highly evolved and proven (Bo iler Master, Distillation towers, Kiln control). Complete turnkey control solution from one vendor from P&ID development throught to startup. Huge number of I/O can be controlled 100K+ points. In my over 25 years of experience in industrial control no expert in their right mind would ever consider using anything but a DCS system for control of a large plant that has a mixture of analog and digital loops. DCS vendors have the expe rience and resources to make it happen. With PLC/HMI you need to rely on systems integrators to make it all work. You get what you pay for. The difference between the PLC and the DCS is the database, i.e. when using the DCS the engineering work that you do is in one environment, for example mimics, programming, trends, reports, program creation, etc. Whereas in a PLC environmen t you need two databases to do engineering, i.e. in a PLC environment you can do programming, I/O configuration, etc. To develop mimics you need SCADA where you can build your trends, alarm windows, etc. so you can see that you need 2 datab ases to develop your engineering work on the PLC. It depends on the PLC and the DCS of course. But the thing is that there is more than one scan' possible. And that the system programmers should understand this an d set the system up appropriately. For example in a DCS you can set scan rates for individual loops (from typically 50mSec upward) and in PLCs you can use time interrupt scans which run at fixed time intervals and put things like control loops (which should execute that way) in those scans. In both DCS's and PLC's it is possible to overload the processor by trying to scan t oo much to often. What happens then is with luck that lower priority tasks slow down but the ones that must run on a fixed scan continue. However I have heard o f cases when some tasks stopped completely. It totally depends on the particular PLC or DCS. Some DCS have the ability to ha ve very fast scan times, but they can load up the processor significantly. I wou ld suggest that a DCS can have a scan time of between 100ms to 10000ms but in mo st applications 1000ms is normal. As a rule of thumb for quick response time critical tasks a PLC is your best bet , whereas for continuous centralised control a PLC or DCS can be used. If necess ary to hand information back from a PLC to a DCS, you can do it via a Profibus or similar link. There is no difference. Years ago a PLC was a relay replacement package (doing b asically digital I/O) while a DCS consisted of multiple controllers that could c ommunicate with each other thus "distributing" control. Today the line between DCS and PLC is thin. Some may run faster than other while some DCS/PLC are designed for specific types of applications. The difference between PLC & DCS lies in the architecture & concept of design of the system. Fundamental difference is PLC is developed independently irrespective of HMI fun ctions,where as DCS is developed with total perfomance of the system as a basic requirement. PLC for "Programmable Logic Controller". Historically a PLC forte was in discret e control of manufacturing processes. Most of the inputs and outputs for discret e control are binary, meaning they have only two states: on and off. Like a swit ch. Little processing power is needed for computing on/off signals so PLC tended to be very fast and are used in machine tool and other industries. The terminol ogy "PLC" is interesting in itself. When they started becoming popular in the 19 70s they were often called "relay replacers" since the logic for on/off type ope rations was done with relays arranged in a digital logic format. It was thought that calling them a computer would turn off many electricians and would scare pe ople away from buying them. Manufacturers of the most popular PLCs include Allen -Bradley, Siemens, Modicon and a bunch of others. DCS stands for "Distributed Control System". DCS's were designed to control proc esses, not discrete operations. As such, a large number of the inputs and output s are analog like a 4-20mA signal or 0-10V signal. These signals generally repre

sent temperature, flow, pressure, pH, conductivity or some other process variabl e. Complex algorithms are programmed into the DCS to provide accurate control of thing like food and medicine manufacturing. Speed wasn't as critical as with th e PLCs but accuracy and complexity was. Typical manufacturers of DCS systems inc lude Moore Products (now Siemens), Foxboro, Triconex, Leeds & Northrup (defunct) , and many others. The "distributed" part of the name is indicating that the con trol functions are spread out amoung many different hardware parts. Using one bi g mainframe computer to control a plant was attempted back in the '60s but it so on became clear that one bug, hang-up, or failure could cause the whole plant to shutdown. Distributed control gives a safety margin! Of course, since the early 90's, microprocessors, memory, speed and everything e lse about computers has increased at a fantasitic rate. The distinct line betwee n PLC and DCS is blurring a little and it is not usual to find a PLC performing simple to moderately hard process control functions. Analog cards are readily av ailable and software is available also. DCS can also perform discrete manufactur ing sequences but their higher cost and complexity make it improbable that someo ne would choose a DSC to control a lathe or grinder. But if just a couple discre te control steps are needed at a process plant (on/off control for a tank level) than it can be used. Traditional PLCs are migrating towards traditional DCSs, and vice versa. Honeywell PlantScape/Experion is an example of a DCS moving towards a PLC. Fisher Delta V is an example of a PLC moving towards a DCS. In a small or medium plant, where there are about 100-200 I/Os total, many peopl e use a PLC (Allen-Bradley), and many use DCS (Delta V, PlantScape). By the way, the SCADA is just that, supervisory and data acquisition. I don't us ually see SCADA within a plant. I usually see it used to supervise multiple smal l sites. In my industry, well monitoring is often done by SCADA systems, with li ttle RTUs at each well site. If you have a small plant, I suggest you talk to a PLC and DCS vendor. They ALL have a system/solution starting at 5 I/Os and going up to 500 I/Os. They all hav e pretty much the same stuff. The difference may be the industry and application specific experience of the office nearest you. Oh, and price, but these change daily. Well technically the SCADA is the system, PLCs or DCS' are the hardware platform on which the SCADA system is built. As mentioned by others, history has more to do with it than anything else. PLCs were developed to handle (relatively) high speed discrete digital I/O, high speed counters, timers etc. with the idea of ma chine control and repeat precision in mind. DCS systems were developed to handle multiple loops of analog control, cascading loops and higher integer intensive math processes, even though reaction speed may be lost because in the process co ntrol industry, things rarely happened in fractions of a second. DCS' were also the first to come up with graphical user interfaces. Now, PLCs are able to handle analog I/O better than they used to, and processor speed has improved to where DCS' can handle higher speed I/O better than they us ed to. GUI systems as mentioned above, i.e. Intellution, Wonderware etc. elimina ted that advantage to DCS systems, but it does still depend on the size of the s ystem, redundancy requirements etc. DCS based systems have a long history of suc cessful operation in very large systems that AFAIK, PLCs with GUIs have not prov en yet. Still, for a lot of applications, the hardware platform makes little difference, other than the familiarity of the users and technicians. For instance, it you h ave a waste water district that uses PLCs for pump station controls and wants to put together an overall SCADA system to look at their entire district as a whol e, it would make sense to use the same PLCs they are currently using as the plat form for the SCADA system. On the other hand, if a chemical plant is not using P LCs for anything now, the analog intense application would warrant a DCS as a be tter solution, and maybe tie in a few PLC-like functions where necessary. Most DCS platforms use dedicated hardware controllers with one or more redundant partner processors synchronously running the same application code. If one proc essor dies, the other is at exactly the same point in the execution cycle and (i

n theory) seamlessly takes over control. The transfer is pretty reliable, but li ke all things designed by mortal man it is not perfect. The PC's typically provide the user's 'window' into the DCS where a PLC would be likely to employ a dedicated HMI rather than the PC executing the actual contro l program. Even here the line between DCS and PLC is blurring as the newer dedic ated HMIs are often PC-based running the odious Windows CE. In a larger DCS there will be several dedicated workstations for Operator Interf aces, plus a Data Historian, an Engineering station, etc, sharing common access to the system whereas most PLCs still have a single HMI. Until recently Sun Spar cStations were highly favoured in the process and power industries for their sta bility and reliability. Some of our Sparcs were not rebooted in a two year perio d between generating unit outages, and very rarely suffered any problems. Window s has improved since the days of the Blue Screen of Death, but still comes nowhe re close to Solaris for stability. I guess I'm a Unix die-hard because reliable hardware and stable software makes my life easier and I like the fact that I am in control in Unix, not Bill and the sodding Wizards which think they know bette r than me and that damned paper clip and... long live Solaris! 23.Marketing drives each of these system hardware and software platforms. When Windows NT was sufficiently stable for CAD stations, the public indicated a will ingness, or desire to use commercially available open system hardware and softwa re instead of the propriety networks and systems of the previous era. In the ea rly days of electronic controls the hand-held radios generated output spikes in the analog controls. Great concern existed about radios permitted in the "host computer room". With reasonable grounding practices, few are concerned about ra dios today. Among the differences between the systems in the previous decades, PLC manufactu rers shipped hardware in a box for the customer or others to integrate. This wa s typically discrete contact logic, timers and counters to activate motors or so lenoids. These were often sold to the industry as relay replacement systems. SCADA systems were often a software package integrated with other company hardwa re as a system. These covered the remote pipeline and unmanned utility pumping station control via a central dispatch center. The DCS manufacturers staged their hardware and software as a system with the ca binets, assembly, wiring, testing and optional application programming among the services provided. These were the replacement for single-loop PID controllers and analog indicators. Customers were continuous process plants for water, wast e water, boiler, refinery, chemical etc. Customers often required intrinsic saf ety. This required a systems approach to comply with the codes and standards. Again, the use of 64-bit microprocessors with graphical workstations permit all of the features of each of these systems regardless of the previous differences. 24. i.PLC: Logic scanning is continuous and scan time defines the overall time t o execute the full logic on the controller. DCS: Logic execution is modular and scan time is definable for each module. so t here is no overall scan time, logic execution is based on process requirements ( fast or slow loops) ii.PLC: The control of PLC is not ditributed throughout the network, its central ly controlled. So probability of total failure is greater and also maintenance i s difficult. DCS: The control is distributed and failure of one node has partial effect on pr ocess. cprobability of process failure is less. maitenance is easy and features like hot swapping of DCS equipments gives more flexibility to maintenance people . 25. >PLC: Logic scanning is contineous and scan time defines the overall time to execute the full logic on the controller. Not really, most PLC have time based interrupts and you can run for example PID loops from there. So scantime IS defineable. It's all a matter of the software d esign. DCS: Logic execution is modular and scantime is defineable for each module. so t here is no overall scan time, logic execution is based on process requirements ( fast or slow loops)

Not really either, most DCS's do have a scan time, sometimes a very slow one. Ag ain you have to design your application correctly. PLC: The control of PLC is not ditributed throughout the network, its centrally controlled. So probability of total failure is greater and also maintenance is d ifficult. Not true. In a network of PLC's each is running it's own program, just like a DC S. I almost think that a DCS is a PLC/SCADA with a bigger marketing budget. 26. Most if not all DCS manufacturers sell a solution, including hardware, softw are, commissioning, and after-market support. PLC vendors sell an empty processo r and a pile of bits to be integrated by a third-party vendor. The DCS vendor ha s usually spent a substantial amount of time and money on proving the interopera bility of all the components of their system, including processors, I/O, MMI, Hi storian, etc. This level of testing is much less common in a PLC system because it is typically performed by the system integrator on a case-by-case basis where the cost of very detailed testing can not be justified for a one-off job. The c hances of an unpredicted or unforseen condition arising in a PLC system is there fore higher. The technical capabilities of high-end PLC hardware is pretty close to that of a mid-range DCS.