The SCADA Gospel: The Editted archives of the SCADA Mailing list

Prev Chapter 5. SCADA Technology Next

SCADA vs DCS
DCS and SCADA, what is the difference?
Sat, 5 Jul 1997 14:51:19 +0100
< r j b3@st udent . open. ac. uk ( Bob Br yne) >
Hi everyone,
I amcurrently writing a project based on replacing a control systemin an offshore gas field for my BSc
(Hons) degree. I've already received some valuable information frompeople by way of these lists, and if you
don't mind, I amhoping 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. Fromtalking 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 fromthe one subscribed to these lists. Regards
Bob Br yne
r j b3@st udent . open. ac. uk
r . br yne@vi r gi n. net
Re: DCS and SCADA, what is the difference?
Tue, 08 Jul 1997 12:05:44 +1000
< Andr ew West andr eww@f oxl n. 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 systemto 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 systemspecifications seemso similar, but a few requirements paragraphs about data availability
and update processing separates a viable SCADA systemfromone 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 systemand 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 systemoperation. 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 systemdatabase and data-gathering systemthan 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 forma composite SCADA/DCS
system), but the SCADA database architecture is significantly different fromthe 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 systemreliability that our customers expect.
If you look at most customer's systemrequirements 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 systemprovides 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.
Regar ds,
. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - .
| Andr ew West . Foxbor o Aust r al i a |
| Embedded Syst ems Engi neer _- - _| \ 42 McKechni e Dr i ve |
| Tel ephone: +61 7 3340 2164 / *\ - - Ei ght Mi l e Pl ai ns |
| Facsi mi l e: +61 7 3340 2100 \ _, - - . _/ Queensl and 4113 |
| Emai l : andr eww@f oxl n. com. au v Aust r al i a |
' - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - '
Re: DCS and SCADA, what is the difference? - Andrew West's
Discussion
Fri, 11 Jul 1997 16:32:00 +1000
< I an Ander son I Ander son@skm. com. au>
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 systemis event driven, while a DCS is process state
driven. A DCS is primarily interested in process trends, a SCADA systemin process events.
A SCADA master station or HMI systemgenerally 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 systemto generate all alarms, events,
database updates and any special processing required relating to that change directly fromthe recognition of
that change (including any analogue alarms).
Event lists and alarmlists 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/systemarea 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 systemdatabase. On the down side, the display of
process data can be neglected by systemmanufacturers. 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 systembased 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 non-deterministic. Field devices do not scan points as rapidly, but may be able to
present themto 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 alarmlists 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 systemrequirements accurately, as Andrew has
written in his last few paragraphs.
Vendors can usually provide a systemfully 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 systemrequirements 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, fromboth 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.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
| I an Ander son _- - _| \ |
| / \ |
| Si ncl ai r Kni ght Mer z - - - - \ *_. - . _/ |
| 7t h Fl oor Dur ack Cent r e v |
| 263 Adel ai de Tce Phone: +61 8 9268 4577 |
| PO Box H615 Per t h Fax : +61 8 9268 4444 |
| West er n Aust r al i a 6001 EMai l : i ander son@skm. com. au |
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Re: DCS and SCADA, what is the difference? - Andrew West's
Discussion
Fri, 11 Jul 1997 18:18:36 -0400 (EDT)
< J mapat @aol . com>
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
< " J i mY. Cai " j i mcai @genecon- ant ai . com>
I did some research on the subject for my book. So here I just provide some evidences for the great
comment fromthe gentleman. Sorry I forget your name.
First DCS was developed indepently by Honeywell and Yokogawa in mid-1970s based on [1] fromISA
society.
According to [9] fromPower industry, the expression "supervisory control and data acquisition" evolved from
planning studies by Bonneville Power Administration in the late 1960s.
The termSupervisory 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. Fromthe 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
< I an Ander son I Ander son@skm. com. au>
JimY. 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 formof 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 performautomated 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 Home Next
Building Automation Up SCADA Future