Vous êtes sur la page 1sur 12

Subject: difference b/n PLC & DCS Question Sir, I am an automation Engineer and have some confusion that

what is the basic functional difference b/n PLC & DCS? can we say the operation which DCS can control, PLC cann't ? and on the other hand operation which PLC can control, DCS also? Please give me suitable reasons. Sponsored Links M2MMachine-to-Machine connection M2M wireless Remote Controlwww.M2M.TV Know AutomationLearn more about Automation, Process Control and Instrumentation www.pacontrol.com Plant AutomationLearn about Automation Prices, Locations and more. Automation.AboutConstruction.org Answer Dear Sir,
I posted the following answer to a question back in 2001 and thought it might be helpful. The short answer is that the distinctions have become blurred as PLCs in particular have become more adapt at handling analog Signals and processes. PLC for "Programmable Logic Controller". Historically a PLC forte was in discrete control of manufacturing processes. Most of the inputs and outputs for discrete control are binary, meaning they have only two states: on and off. Like a switch. 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 terminology "PLC" is interesting in itself. When they started becoming popular in the 1970s they were often called "relay replacers" since the logic for on/off type operations 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 people 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 processes, not discrete operations. As such, a large number of the inputs and outputs are analog like a 4-20mA signal or 0-10V signal. These signals generally represent temperature, flow, pressure, pH, conductivity or some other process variable. 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 the PLCs but accuracy and complexity was. Typical manufacturers of DCS systems include Moore Products (now Siemens), Foxboro, Triconex, Leeds & Northrup (defunct), and many others. The "distributed" part of the name is indicating that the control functions are spread out among many different hardware parts. Using one big mainframe computer to control a plant was attempted back in the '60s but it soon 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 else about computers has increased at a fantastic rate. The distinct line between 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 available and software is available also. DCS can also perform discrete manufacturing sequences but their higher cost and complexity make it improbable that someone would choose a DSC to control a lathe or grinder. But if just a couple discrete control steps are needed at a process plant (on/off control for a tank level) than it can be used. I hope this contains some of the info you were looking for--if not write back with your specific questions and I'll do my best to answer them.

SCADA vs DCS
DCS and SCADA, what is the difference?
Hi everyone, I am currently writing a project based on replacing a control system in an offshore gas field for my BSc (Hons) degree. I've already received some valuable information from people by way of these lists, and if you don't mind, I am hoping for a little more. As part of this academic project I wish to write a short section on the history of SCADA and DCS, and their differences. From talking to people, I get the impression that several years ago they were considered to be separate entities, but in more recent years the technologies have merged together such that the two have become more or less synonymous with each other. I've done various searches in libraries and on the internet but I can't find any useful references regarding this. Please can anybody supply me with info, or with references, especially internet ones, to assist me in this matter. Can anybody responding also copy to my private email account: r.bryne@virgin.net I've had occasional problems getting mail from the one subscribed to these lists. Regards
Bob Bryne rjb3@student.open.ac.uk r.bryne@virgin.net

Re: DCS and SCADA, what is the difference?


Tue, 08 Jul 1997 12:05:44 +1000
<mailto:%20Andrew%20West%20andreww@foxln.com.au>

Bob Bryne asked: This is one of many areas that were historically separate, but the recent convergence of technologies has blurred the distinctions. The goals of DCS and SCADA are quite different. It is possible for a single system to be capable of performing both DCS and SCADA functions, but few have been

designed with this in mind, and therefore they usually fall short somewhere. It has become common for DCS vendors to think they can do SCADA because the system specifications seem so similar, but a few requirements paragraphs about data availability and update processing separates a viable SCADA system from one that would work OK if it weren't for the real world getting in the way. DCS is process oriented : it looks at the controlled process (the chemical plant or whatever) as the centre of the universe, and it presents data to operators as part of its job. SCADA is data-gathering oriented: the control centre and operators are the centre of its universe. The remote equipment is merely there to collect the data--though it may also do some very complex process control! A DCS operator station is normally intimately connected with its I/O (through local wiring, FieldBus, networks, etc.). When the DCS operator wants to see information he usually makes a request directly to the field I/O and gets a response. Field events can directly interrupt the system and advise the operator. SCADA must operate reasonably when field communications have failed. The 'quality' of the data shown to the operator is an important facet of SCADA system operation. SCADA systems often provide special 'event' processing mechanisms to handle conditions that occur between data acquisition periods. There are many other differences, but they tend to involve a lot of detail. The underlying points are: SCADA needs to get secure data and control over a potentially slow, unreliable communications medium, and needs to maintain a database of 'last known good values' for prompt operator display. It frequently needs to do event processing and data quality validation. Redundancy is usually handled in a distributed manner. DCS is always connected to its data source , so it does not need to maintain a database of 'current values'. Redundancy is usually handled by parallel equipment, not by diffusion of information around a distributed database. These underlying differences prompt a series of design decisions that require a great deal more complexity in a SCADA system database and data-gathering system than is usually found in DCS. DCS systems typically have correspondingly more complexity in their process-control functionality. The company I work for has both DCS and SCADA products. The operator stations for each product line can use the same UNIX workstations. The systems share data (and thus form a composite SCADA/DCS system), but the SCADA database architecture is significantly different from the DCS data architecture, to the extent

that the SCADA master station database looks to the DCS operators very much like some directly-connected DCS I/O. The DCS people are (of course) keen to simplify this to cut costs. However, they do not yet have a viable alternative for the mechanisms required in SCADA systems to have communications redundancy and data redundancy to provide the sort of SCADA system reliability that our customers expect. If you look at most customer's system requirements specifications, a careful analysis of the data collection and data quality requirements will indicate if SCADA-style or DCS-style systems are appropriate. In general: the more features a system provides the more it will cost, so if you do not need SCADA-type data gathering facilities it will usually be more economical to use a DCS-type system. If you do need these facilities, you will pay for them. The short answer: DCS and SCADA are still different things, it depends what the customer specifies as to which is appropriate for a particular installation. I hope this has clarified more than it has confused. Also, it is my opinion based on my own experiences with DCS and SCADA. Others may have experience with systems that are designed to provide full SCADA and full DCS functionality in the one system.
Regards,

Re: DCS and SCADA, what is the difference? Andrew West's Discussion
Mr West has made a valuable contribution to the DCS/SCADA discussion (as we have come to expect). DCS/SCADA philosophy differences are as subtle as the differences between RTUs and PLCs. As are their similarities. However, he has only briefly touched on an area which I consider to be one of the major differences between SCADA and DCS systems, especially so for the smaller SCADA systems and single-site SCADA HMIs in comparison to DCS systems. This relates to the alarming and eventing philosophies of the two differing applications. To put in very simplistic terms, a SCADA system is event driven, while a DCS is process state driven. A DCS is primarily interested in process trends, a SCADA system in process events. A SCADA master station or HMI system generally considers changes of state (both status points and analogue changes leading to alarms) as the main criteria driving the data gathering and presentation system. Any undetected changes of state simply cannot be missed. This is reflected firstly in the field devices which are

biased to the rapid scanning of digital inputs, and secondly at the protocol level where transmittal of changes of state (COSs) and sequence of events (SOEs) are generally given higher priority than analogue scans. SCADA software is event driven. A change of state will cause the system to generate all alarms, events, database updates and any special processing required relating to that change directly from the recognition of that change (including any analogue alarms). Event lists and alarm lists are of major importance to the operator, sometimes more so than data screens. Filtering of these lists is often quite complex, allowing displays sorted by plant/system area and alarm/event category/importance. Configuring alarms and events for points is relatively easy, as such attributes are usually added by default when a point is added to a SCADA system database. On the down side, the display of process data can be neglected by system manufacturers. It can be difficult to draw and configure system displays, and graphics can be dismal, although modern operating systems with off the shelf display packages are overcoming this. Conversely, DCS systems and process control system based SCADA HMIs are state based and consider the process variable's present and past states to be the main criteria driving the DCS. (PLC) protocols are generally register scanning based, with no specific change of state processing provided. Should a point toggle between scans, it will not be seen by the DCS. If any change of states are critical (as some would be for a DCS used for SCADA applications), a point must be latched on until it is confirmed it has been scanned, which can be difficult and nondeterministic. Field devices do not scan points as rapidly, but may be able to present them to the DCS in an overall faster time. DCS software tasks are generally run sequentially, rather than event driven. Therefore alarms or events are not generated when a point changes state, but when that particular process is run. Events and alarm lists are secondary in importance to the process displays, and filtering may not be as complex and flexible. Configuring points is a separate task, with points requiring alarms and events needing to be configured in a separate action. On the up side, the generation and display of data, especially analogue trends and standard process blocks, is far more user friendly and easier for both operator and engineer. Of course there are many exceptions to these generalities, and many DCS manufacturers have produced systems to deal with COSs (both by producing event driven base systems and "special" COS description alarming), and similarly there are SCADA systems with greater data acquisition and process control capability.

It really does come down to the user being able to define system requirements accurately, as Andrew has written in his last few paragraphs. Vendors can usually provide a system fully meeting any customer's requirements, however the requirements may lead to a DCS or SCADA with high customisation, this may add significant cost and complexity, for features which are not necessarily required. The value of relevant system requirements and specifications that both reflect all of a customer's internal requirements, and can be met with systems commercially available cannot be overstated. That's where companies like SKM can provide services to clients, offering independent knowledge using SCADA/Automation staff with many years expedience, from both user and vendor backgrounds. It our responsibility to carefully consider the cost consequences to the client of overspecifiying features that are functionally inappropriate. A few well meaning but ill chosen functions can lead to dramatic capital cost increases with little operational benefit.
-------------------------------------------------------

Re: DCS and SCADA, what is the difference? Andrew West's Discussion
I agree with everything stated....however I must add that diferent SCADA/HMI packages approach the event driven process differently...some like wonderware and Intellution are for the most part polled processed. (intellution can exception process on analog and digital inputs and outputs). Other packages, like USDATA's Factorylink are totally exception processed, i.e. only when there is a change in state does the processor have activity. Polling on the other hand goes through discrete polling times (scans) to acquire the data...thus there is a heavier burden on the proceesor. best reagards Pat Porto

More comment on DCS and SCADA, what is the difference?


I did some research on the subject for my book. So here I just provide some evidences for the great comment from the gentleman. Sorry I forget your name. First DCS was developed indepently by Honeywell and Yokogawa in mid-1970s based on [1] from ISA society.

According to [9] from Power industry, the expression " supervisory control and data acquisition" evolved from planning studies by Bonneville Power Administration in the late 1960s. The term Supervisory Control and Data Acquisition " was first shown up in publication in the first PICA (Power Industry Computer Applications) Conference in 1973. In addition to the different industries, by-products because of this different industries are RTUs for SCADA, PLC/controllers for DCS. From the RTU and PLC/controllers, you can feel the difference between SCADA and DCS. RTU stands for Remote Control Unit and sometimes is called dumb RTU because without SCADA's polling and issuing commands to him., RTU is just a black box standing there in substations and will never intervene your process. Instead , PLC/Controllers can and usually do automatically control the process based on your setpoints even there is no DCS connected to him. There are three kinds of SCADA/DCS vendors. 1. Proprietary SCADA vendors such as ABB/SC, EMPROSE for power industry, VALMET Automation Sage division in Canada for oil/gas pipeline. Their SCADA may be called high-end SCADA 2. Off-the-shelf SCADA/MMI/DCS software vendors, such as USDATA, Intellution, Wonderware

RE: More comment on DCS and SCADA, what is the difference?


Jim Y. Cai made some useful comments to add to this discussion. However the following comment in his response would appear to be a little outdated: ---------I suspect that all manufacturers of RTUs would tend to disagree with this comment.

Even old technology "dumb" RTUs that did do nothing but collect data were capable of fast and accurate scanning of digital inputs to within 1msec resolution for SOE purposes, and many of these were capable of rudimentary automatic control. Most RTUs designed and built within the past 7 years or so are capable of far more than data gathering. Time tagging to 1msec is available as standard in most cases, for point counts numbering in the thousands. In addition, most major RTUs come with some form of PLC type functionality, and many with higher level processing such as PID functions, gas calculations (AGA3,7 etc), capacitor bank control, autoreclose, remote configurabilty, etc, etc. RTUs forming the hub of an SCS (substation control system) are far more than black boxes, and can perform many automatic functions within the substation, not to mention distribution automation via automatic control and re-configuration of field switches external to the site. Similarly RTUs installed at major water, gas and transport nodes can perform automated control of satellite sites. And of course some RTUs are PLC based, and some PLCs are RTU based, which is another discussion again (and has been the subject of a few discussions on this mailing list). Ian Anderson Ref: 071997\msg00018.xml

This has been discussed several times, but when I did a search on the site I couldn't locate the threads. You might want to try your own search, though. SCADA (Supervisory control and Data Acquisition) is essentially a computer based (usually PC nowadays) system for displaying field data. The difference between it and HMI (Human Machine Interface) software aren't significant. Most SCADA systems are tag based, and a lot of HMI software is set up to read registers in PLCs directly. SCADA software like Wonderware or the Fix includes graphics displays, trending, alarms, data logging, and recipes. They will work with PLC or DCS systems. I like to refer to most SCADA systems as "leg savers" because they collect and display the data without making a guy run around with a clip board. Most SCADA software is capable of control logic and recipe control, but these functions are often unused. The SCADA has to get its field process data from field devices, generally either a DCS or PLC based system. It often includes communications over serial link, but many use ethernet, radio telemtery, and leased line or dial-up phone lines. In the last couple of years remote I/O is also used for getting field data into the SCADA screen. DCS has its roots in the process industry, where control was generally based on independent single loop PID controllers. DCS was a communications link to get the analog process data, and in some cases tuning info and status info, back to a central computer. The control logic resided in the controllers, and any programming was in proprietary and often obscure languages. The computer display evolved into todays SCADA systems. The communications was almost always serial, and usually employed proprietary protocols. Bristol Babcock, Fisher Porter, and Foxboro were big names in this kind of product. PLCs have their roots in manufacturing, where most control was done through relay logic and based on discrete status info from limit switches etc. The original PLCs were relay replacers, communications was limited, and analog data functions were expensive and cumbersome. Over the years the ability of PLCs to handle math functions, analog data, and communications has mushroomed, and now equal or exceed those of a DCS. DCS and PLC systems are becoming indistinguishable. Most DCS's now have open protocols, and are physically starting to look like a PLC (Bristol Babcock's Control Wave for example). At the same time PLCs began to include DCS type functions like PID and multiple processors (Allen Bradley's ControlLogix for example). PLCs are gaining market share in the process industries, but a lot of engineers still stick with DCS because of unique industry-specific functions. PLCs are generally, but not always, less expensive.

"DIFFERENCE BETWEEN PLC,DCS&SCADA" Messages in this discussion "RE: DIFFERENCE BETWEEN PLC,DCS&SCADA" Posted by Tom Jenkins on Aug-23-01 at 09:34 AM This has been discussed several times, but when I did a search on the site I couldn't locate the threads. You might want to try your own search, though. SCADA (Supervisory contol and Data Acquisition) is essentially a computer based (usually PC nowadays) system for displaying field data. The difference between it and HMI (Human Machine Inerface) software aren't significant. Most SCADA systems are tag based, and a lot of HMI software is set up to read registers in PLCs directly. SCADA software like Wonderware or the Fix include grapics dispalys, trending, alarms, data logging, and recipes. They will work with PLC or DCS systems. I like to refer to most SCADA systems as "leg savers" because they collect and display the data without making a guy run around with a clip board. Most SCADA software is capable of control logic and recipe control, but these functions are often unused. The SCADA has to get its field process data from field devices, generally either a DCS or PLC based system. It often includes communications over serial link, but many use ethernet, radio telemtery, and leased line or dial-up phone lines. In the last couple of years remote I/O is also used for getting field data into the SCADA screen. DCS has its roots in the process industry, where control was generally based on independent single loop PID controllers. DCS was a communications link to get the analog process data, and in some cases tuning info and status info, back to a central computer. The control logic resided in the controllers, and any programming was in proprietary and often obscure languages. The computer display evolved into todays SCADA systems. The communications was almost always serial, and usually employed proprietary protocols. Bristol Babcock, Fisher Porter, and Foxboro were big names in this kind of product. PLCs have their roots in manufacturing, where most control was done through relay logic and based on discrete status info from limit switches etc. The original PLCs were relay replacers, communications was limited, and analog data functions were expensive and cumbersome. Over the years the ability of PLCs to handle math functions, analog data, and communcations has mushroomed, and now equal or exceed those of a DCS. DCS and PLC systems are becoming indistinguishable. Most DCS's now have open protocols, and are physically starting to look like a PLC (Bristol Babcock's Control Wave for example). At the same time PLCs began to include DCS type functions like PID and multiple processors (Allen Bradley's ControlLogix for example). PLCs are gaining market share in the process industries, but a lot of engineers still stick with DCS because of unique industryspecific functions. PLCs are generally, but not always, less expensive. "RE: DIFFERENCE BETWEEN PLC,DCS&SCADA" Posted by Mark Baker on Aug-23-01 at 02:52 PM !!!!WOW!!!! what an answer. Tom, I think Terry will be proud of you for this one. Respect Man Im impressed. Mark "RE: DIFFERENCE BETWEEN PLC,DCS&SCADA" Posted by Pierre on Aug-23-01 at 03:49 PM stone-

There is also a "whyte colar" aspect to differentiate those 3 systems. In those days DCS vendors had a captive clientelle... the PLCs where not much danger for them market share, the PLC just didn't do enough. Captive means ... like in prison! Read some threads about vendors of Alien Rodney's who are not cooperative at all... they have a pretty good territorial defense system going for them. More captive = More money to charge the End-User With the arrival of SCADA systems, there sales fell to the ground. This is because SCADA systems offered drivers to comunicate with manyer products. Making these "softwares" really afordable and by the same thime the hardware too... Next purchase meant competing supplyers The arrival of more so-called open protocols stretched this fact to the point where all those big guys are leanning more every days toward each others. It's becoming more and more difficult to set a limit where one could says this is a DCS and this is a SCADA/PLC system. One thing for shure is the fact that you can learn easely to configure/program a SCADA an apply this knowledge to another brand of software. You have learned Fix... you could work on Wonderware within hours... For me the fall of the DCS as a "for-serious-industries-only" system originate from the same principle that explain why Lotus123 brought us PCs. Power to the people ! Smaller companies could have systems which compares technicaly on many aspect with larger DCS. Today we often see a system with some parts where a dedicated hardware/network/protocol is layed out, centralised in a control center which comunicates with other parts where PLCs rule. Part of all this hoping on the office intranet where an SQL server distributes answers for request of info from those "whyte colar". What could this be called... This is one good situation for systems integrators Hey That's me

A typical DCS would be ... Honeywell TDC with a few pairs of wires running across the plant... everywhere, some Honeywell controlers, Honeywell transmitters, etc. To get another brand into this system the fast way would have been a 4-20mA input... but this did not permit you to change the Set-point, read the valvle opening, error codes, P.I.D. settings, etc. You more or less Captive. Not being captive would be to have an "open" network like Modbus+ running on a pair a wires accross the plant, any SCADA system in the control center, seing an acting on it all. Just check how many vendors sell stuff compatible with Modbus... now the negotiation power is on your side... almost When SCADA arrived we could have answered your question by this:

DCS = Closed (they would never admit to that) SCADA = Open (they want you to beleive that) PLC = arms eyes and legs of SCADA Today ... it's not as strictly divided "RE: DIFFERENCE BETWEEN PLC,DCS&SCADA" Posted by Terry Woods on Aug-23-01 at 06:45 PM Damn! I'm proud of you, my boys! I can't think of any thing else to add. Another one of those "One thing that I know" things is that even us old guys don't know everything about everything. (Although I certainly have an opinion on everything and anything! That's part of my charm, isn't it?) I learned a few things in this thread... just like a new kid. Gotta stop now, I feel a tear welling up.

Vous aimerez peut-être aussi