Scada Vs Dcs Description

SCADA vs DCS

Prev

The SCADA Gospel: The Editted archives of the SCADA Mailing list Chapter 5. SCADA Technology

Page 1 of 6

Next

SCADA vs DCS DCS and SCADA, what is the difference? Sat, 5 Jul 1997 14:51:19 +0100 < [email protected] (Bob Bryne)>

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: [email protected] I've had occasional problems getting mail from the one subscribed to these lists. Regards Bob Bryne [email protected] [email protected]

Re: DCS and SCADA, what is the difference? Tue, 08 Jul 1997 12:05:44 +1000 < Andrew West [email protected]>

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

http://members.iinet.net.au/~ianw/archive/x4371.htm

7/20/2010

SCADA vs DCS

Page 2 of 6

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

http://members.iinet.net.au/~ianw/archive/x4371.htm

7/20/2010

SCADA vs DCS

Page 3 of 6

SCADA and full DCS functionality in the one system. Regards, .----------------------------------------------------------------. | Andrew West . Foxboro Australia | | Embedded Systems Engineer _--_|\ 42 McKechnie Drive | | Telephone: +61 7 3340 2164 / *\ -- Eight Mile Plains | | Facsimile: +61 7 3340 2100 \_,--._/ Queensland 4113 | | Email: [email protected] v Australia | '----------------------------------------------------------------'

Re: DCS and SCADA, what is the difference? - Andrew West's Discussion Fri, 11 Jul 1997 16:32:00 +1000 < Ian Anderson [email protected]>

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

http://members.iinet.net.au/~ianw/archive/x4371.htm

7/20/2010

SCADA vs DCS

Page 4 of 6

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 non-deterministic. 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. ------------------------------------------------------| Ian Anderson _--_|\ | | / \ | | Sinclair Knight Merz ---- \*_.-._/ | | 7th Floor Durack Centre v | | 263 Adelaide Tce Phone: +61 8 9268 4577 | | PO Box H615 Perth Fax : +61 8 9268 4444 | | Western Australia 6001 EMail: [email protected] | -------------------------------------------------------

Re: DCS and SCADA, what is the difference? - Andrew West's Discussion Fri, 11 Jul 1997 18:18:36 -0400 (EDT) < [email protected]>

http://members.iinet.net.au/~ianw/archive/x4371.htm

7/20/2010

SCADA vs DCS

Page 5 of 6

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 Ref: 071997\msg00007.xml

More comment on DCS and SCADA, what is the difference? Thu, 10 Jul 1997 16:52:44 -0700 < "Jim Y. Cai" [email protected]>

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? Fri, 11 Jul 1997 17:02:00 +1000 < Ian Anderson [email protected]>

Jim Y. Cai made some useful comments to add to this discussion. However the following comment in

http://members.iinet.net.au/~ianw/archive/x4371.htm

7/20/2010

SCADA vs DCS

Page 6 of 6

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, auto-reclose, 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 Prev Building Automation

Home Up

http://members.iinet.net.au/~ianw/archive/x4371.htm

Next SCADA Future

7/20/2010