SCADA vs DCS Page 1 of 6

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
< rjb3@student.open.ac.uk (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:

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
< Andrew West andreww@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

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: andreww@foxln.com.au v Australia |
'----------------------------------------------------------------'

Re: DCS and SCADA, what is the difference? - Andrew West's

Discussion
Fri, 11 Jul 1997 16:32:00 +1000
< Ian Anderson IAnderson@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 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: ianderson@skm.com.au |
-------------------------------------------------------

Re: DCS and SCADA, what is the difference? - Andrew West's

Discussion
Fri, 11 Jul 1997 18:18:36 -0400 (EDT)
< Jmapat@aol.com>

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" jimcai@genecon-antai.com>

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 IAnderson@skm.com.au>

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 Home Next

Building Automation Up SCADA Future

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