What is the differaence between PLC and DCS?

What is the differaence between PLC and DCS? ..

Answer / sameer

DCS or PLC? What is the difference?
You must automate a process, but you can't decide between a
DCS and a PLC. Are these systems really all that different?
The answers depend on a slew of other questions.
The Programmable Logic Controller (PLC) is king of machine
control while the Distributed Control System (DCS)
dominates process control. If you manufacture plastic
widgets, you speak PLC. If you produce chemicals, you speak
DCS.
Today, the two technologies share kingdoms as the
functional lines between them continue to blur. We now use
each where the other used to rule. However, PLCs still
dominate high-speed machine control, and DCSs prevail in
complex continuous processes.
The early DCS looked dramatically different from the early
PLC. Initially, the DCS performed the control functions of
the analog panel instruments it replaced, and its interface
mimicked their panel displays. DCSs then gained sequence
logic capabilities to control batch processes as well as
continuous ones. DCSs performed hundreds of analog
measurements and controlled dozens of analog outputs, using
multi-variable Proportional Integral Derivative (PID)
control. With the same 8-bit microprocessor technology that
gave rise to the DCS, PLCs began replacing conventional
relay/solid-state logic in machine control. PLCs dealt with
contact input/output (I/O) and started/stopped motors by
performing Boolean logic calculations.
The big change in DCS over the past 20 years is its move
from proprietary hardware to the personal computer (PC) and
standard LAN technologies. With each advance in PC power,
DCSs have moved up in power. PCs gave us speedy,
responsive, multi-media, windowed, operator-process
interfaces (OPI). Relational databases and spreadsheet
software enhance the ability of DCSs to store and
manipulate data. Artificial intelligence (AI) technology
gives us "smart" alarming. Today's DCS architecturally
looks much like the DCS of 20 years ago, but tomorrow's DCS
may control through networked "smart" devices-with no I/O
hardware of its own.
Most DCSs offer redundant controllers, networks, and I/Os.
Most give you "built-in" redundancy and diagnostic
features, with no need for user-written logic.
DCSs allow centralized configuration from the operator or
engineering console in the control room. You can change
programming offline, and download without restarting the
system for the change to be effective.
DCSs allow inter-controller communications. You can do data
exchange in most DCS systems ad hoc (no need for predefined
data point lists). You access data by tag name, regardless
of hardware or location.
DCSs use multi-tasking operating systems, so you can
download and run applications aside from the real-time
control functions and still do fractional-second control.
DCSs now come in "micro" systems, to price-compete with
PLCs-but with full DCS features and capabilities.
The typical DCS has integrated diagnostics and standard
display templates that automatically extend/update when
your database changes. This database is central to the
system-you don't have different databases sitting in the
controllers.
DCSs have user-friendly configuration tools, including
structured English, control block libraries, SFC
(sequential function chart), and even RLL (relay ladder
logic).
Most DCSs allow graphical configuration, provide online
diagnostics, and are self-documenting. Most provide for
user-defined control blocks or customized strategies. The
controllers execute control strategies as independent
tasks; thus, making changes to part of the control logic
has no impact on the rest.
An important difference between DCSs and PLCs is how
vendors market them. DCS vendors typically sell a complete,
working, integrated, and tested system; offering full
application implementation. They offer many services:
training, installation, field service, and integration with
your Information Technology (IT) systems. A DCS vendor
provides a server with a relational database, a LAN with
PCs for office automation, networking support and
integration of third-party applications and systems. The
DCS vendor tries to be your "one-stop shop." The PLC is
more of a "do-it-yourself" device, which is sometimes
simpler to execute.

Programmable Logic Controllers. When PLCs were solely
replacements for hard-wired relays, they had only digital
I/O, with no operator interface or communications. Simple
operator interfaces appeared, then evolved into
increasingly complex interfaces as PLCs worked with
increasingly complex automation problems. We went from a
panel of buttons and I/O-driven lamps to PLC full-color
customized graphic displays that run on SCADA software over
a network.
PLCs now have many DCS-like control functions (e.g., PID
algorithms) and analog I/O. They've moved past their
birthplace: the digital world (switch and binary sensor
inputs and output contacts to run motors and trigger
solenoids).
PLCs are fast: They run an input-compute-output cycle in
milliseconds. On the other hand, DCSs offer fractional
second (1/2 to 1/10) control cycles. However, some DCSs
provide interrupt/event-triggered logic for high-speed
applications.
PLCs are simple, rugged computers with minimal peripherals
and simple OSs. While increasing reliability, PLC
simplicity is not conducive to redundancy. Thus, fully
redundant ("hot," automatic, bumpless) variations of PLCs,
with their added hardware and software, sometimes suffer
from a reduction in their reliability-a characteristic PLCs
are famous for.
Data exchange typically requires you to preassign data
registers and hard code their addresses into the logic. If
you add registers or need to reassign data, you typically
have to deal manually with the Domino Effect.
Typical PLC Relay Ladder Logic (RLL) languages include
function blocks that can perform complex control and math
functions (e.g., PID algorithms). Complex multi-loop
control functions (e.g., cascade management and loop
initialization) are not typical. For functions too messy to
implement in RLL, most PLCs provide a function block that
calls a user-written program (usually in BASIC or C).
PLCs typically operate as "state" machines: They read all
inputs, execute through the logic, and then drive the
outputs. The user-written logic is typically one big RLL
program, which means you may have to take the whole PLC off-
line to make a change of any size. You also run into
database synchronization problems because of the separation
of PLCs and the Man Machine Interface (MMI) software
packages, as opposed to the central databases of DCSs.
A PLC will run in a stand-alone configuration. A DCS
controller normally expects an operator interface and
communications, so it can send alarms, messages, trend
updates, and display updates.
Many PLC installations use interface software from third-
party vendors for improved graphics and various levels of
alarming, trending, and reporting. The PLC and MMI software
normally interact by sitting on the network and using the
register exchange mechanism to get data from and to the
various PLCs. This type of communication presumes you have
preassigned data registers and can fetch data on an
absolute address basis. This can lead to data processing
errors (e.g., from the wrong input) you won't encounter
with the central database of a DCS.
Some PLCs use proprietary networks, and others can use
LANs. Either way, the communication functions are the same-
fetch and put registers. This can result in bottlenecking
and timing problems if too many PCs try communicating with
too many PLCs over a network.
A PLC may have a third-party package for operator
interfaces, LAN interface to PCs and peripherals, PLC data
highway or bus, redundant controllers with local and
distributed I/O, local MMI and local programming
capability. The PLC would have redundant media support, but
not the redundant communication hardware or I/O bus
hardware you'd find in a DCS. A PLC would have
preprogrammed I/O cards for specific signal types and
ranges.
Today, the decision between PLC and DCS often depends on
business issues rather than technical features. Questions
to consider are those involving:
The internal expertise to execute the project, Level of
support available from a vendor/integrator, Long-term
maintainability, and Life-cycle costs.
PLCs and DCSs overlap in their features, but also have
distinct strengths and weaknesses. When deciding between
the two, know who will deliver and support your system, and
how they will do it.

Comparing PLC and DCS

Posted by Anonymous on 6 May, 2004 - 6:34 pm
I am new in the field of automation. Could anybody tell me
the difference between PLC and DCS other than I/O handling
capacity?
Reply to this post...

Posted by Randy on 7 May, 2004 - 7:15 pm
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 digital and crosses
to the realm of DCS in handling Analogs, Bus Systems,
Distributed I/O and etc. Also, since the DCS now handles
logics of Digital I/O it also crossed the boundary to the
realm of PLC.

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 "Distributed
Control Systems" its emphasis is Fast analog handling
because of communications through Bus systems, networking
and etc.

Summarizing all these, PLC = DCS......

Hope that I shed light on you.

rtj
Reply to this post...

Posted by Anonymous on 7 May, 2004 - 7:17 pm
PLC=Programmable Logic Controller
DCS=Distributed Control System

A PLC can be a component of a DCS

A DCS can include Networked PLCs, PCs, or other control
equipment sharing or distributing control of a process or
processes. Key word being "distributed".
Reply to this post...

Posted by David Farris, Bristol Babcock Inc. on 7 May,
2004 - 10:40 pm
As I understand it, the two really don't compare as a PLC
is Programmable Logic Controller and DCS is Distributed
Control System. 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 particular
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 DCS may be communicating
with 14 filter PLCs and starting the backwash routine when
required.
Reply to this post...

Posted by Bob Peterson on 13 May, 2004 - 10:49 pm
While a trivial example, it serves as an illustration,
although having programmed hundreds of such filters, I
can't ever recall putting a seperate PLC on
each filter. Just not cost effective. the part about the
DCS initiating backwash might be true in some cases but in
many cases it would be inititated on time, dp, or flow
locally. In fact, most of the installations I have seen of
such things are indeed standalone and typically only report
alarms and status to the DCS and rarely does the DCS
actually do any control at all. But, YMMV.

Bob Peterson
Reply to this post...

Posted by Sutrisno on 7 May, 2004 - 10:52 pm
The differences between PLC and DCS:

1. PLC only handled sequential process than DCS can handled
both Continue process 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.
Reply to this post...

Posted by Anonymous on 10 May, 2004 - 3:38 pm
Why this question, may we know?
Reply to this post...

Posted by Wieslaw Chodura on 10 May, 2004 - 5:12 pm
From my opinion DCS systems are more complex and include
HMI. The realtime HMI database is generated when
programming the PLC which is the part of DCS system. When
you want communicate with bare PLC the realtime database
must be created "manually". In DCS systems the realtime
database is also distibuted so each operator station has
its own RT database. There are also so called Hybrid System
like Honeywell PlantScape where RT database is created
automatically during PLC programming but is stored at
realtime server so it is not distributed.
Reply to this post...

Posted by Ron Beaufort on 11 May, 2004 - 11:44 pm
The following is basically a “cut and paste” from something
I posted some time ago on another forum - specifically to
answer a beginner’s questions about DCS; SCADA; PLC’s; HMI;
MMI; etc. It seemed to help him so maybe there’s something
in here which will help you too.

Disclaimer to one and all! What follows is a
general “beginner level” discussion - there are exceptions
to all of these “rules”.

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 up 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 into a sellable final
product. So what type of control are we going to use? How
about 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 module” 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 similar for an
output device. Instead of using a screen for an output
device, we use 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 starters, 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 buy 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 we write a program for the PLC -
we’ll probably use “ladder logic” programming, since that’s
what most PLC’s use as their native language. And now the
PLC is just about ready 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
conveyors and so forth.

Now for this small system, some meters and pushbuttons and
some thumbwheel switches 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 Machine Interface. (This used to be called an MMI -
Man Machine Interface - but now-a-days we’ve got to be more
politically correct.) So we buy us a nice desktop computer
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 communication 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 additional ovens. So we get the mechanical
parts built - and now we need to decide how we’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 might need to add a few
additional I/O modules to the chassis - and we’ll certainly
need to run some more wires - but basically the same old
PLC “brain” has plenty of extra 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 money, but at least this way each
oven could operate - or be shut down - completely
separately from the other two systems. That’s going to make
scheduling maintenance a lot simpler - and generally give
us a lot more flexibility in all of our operations. 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 download 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 HMI 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 factory’s profits. Now this person
requires data - he needs to know how much it costs to
operate the ovens - and how much product we run through
them - and how much of that product is “off-spec” and
wasted. The best way to get all of this production data is
to ask the PLC’s - after all, they’re the “brains” that are
controlling the system. So let’s upgrade the old HMI that
the operator has been using - to something with more
features. This will be called a SCADA system -
for “Supervisory Control And Data Acquisition”. It will
still have control screens with all of the virtual buttons
and meters and other whatnots that the operator needs to
control the ovens - 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
PLC’s - and to store that data in some type of computer
database. Later, the bean-counter can retrieve that
production data and analyze it to his little heart’s
content. All is well.

Quick review so far: The machinery in our factory is being
controlled by PLC’s. For 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 Machine. 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 allowed our human operator to Supervise and Control
the system - and it also added some 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 to produce a sellable final product.
We’re talking about chemicals - or pharmaceuticals - 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 SCADA system to supervise and control
the whole thing. But - many engineers would decide 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 previous 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 controllers will each look a lot like
an individual “I/O module” or “I/O card” in a PLC system.
They usually slide right into a chassis - and have wires
for inputs and outputs 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”
devices will be individually programmed. That’s where the
term “DISTRIBUTED” comes from - the control (or “brain-
power” if you prefer) is DISTRIBUTED among many individual
controllers. Specifically, in a typical PLC system we
generally have only one “brain” (or processor) in each
chassis - and then several I/O (input/output) modules in
the chassis to handle the signal wires to-and-from the
machinery. On the other hand, 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 connected directly to the front of that
individual controller.

Now what about the operator control function? Well, one
integral part of a DCS system 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 other 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 individual 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
programming software for the individual controllers is also
usually available on this 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 controlled by many individual little
controllers. Our operator uses a DCS terminal (computer) 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. Additionally, the DCS terminal
usually has the programming software required for the
individual controllers available. And all of the hardware
and all of the software required for our DCS system is
generally provided by just one manufacturer. Some people
think that’s a good thing - and other people think that’s a
bad thing.

So which is the better approach - PLC or DCS? This is
usually decided by the engineers who initially design the
factory. And in practice, there are a lot of factories out
there who use combinations of the two approaches.

Finally: Please remember that this was intended to be a
general “beginner level” discussion - there are exceptions
to all of these “rules” ... but hopefully this will give
you a “starting point” from which to build.

Hope this helps ... best regards,
Ron
Reply to this post...

Posted by Matthew Hyatt on 27 May, 2004 - 4:22 pm
Ron,

In both cases the PLC or controller is sperately programmed
and if programmed correctly 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 interface, alarming, historical
trending and such... you could even have local HMIs where
you need them.

In fact if you had twenty PLCs each programmed to perform a
plant function and only send data to a HMI or SCADA
computer would this not be a DCS system - the control
operations are indeed distributed among the various PLCs,
the PLCs do indeed 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 PLCs could share data with the other PLCs so they could
act upon the information obtained 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 monitoring and
house keeping via a host SCADA computer. From your two
rather long explainations, 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.
Besides, I could use one PLC with plenty of I/O expansion
capability to handle all of the filters in a water plant
and even the rest of the plant's operations, vs 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 the life the plant vs
the cost of the equipment.

Though many will argue that there are significant
differences and cost advantages, blah, blah, blah... I
stand on the platform that supports both are very similar
and each can perform the functions of the other and can be
integrated to provide solutions to a wide range of plant
automation schemes.

MJH
Reply to this post...

Posted by Jonas Berge on 13 May, 2004 - 10:44 pm
PLC was developed as a replacement for many relays. DCS was
developed as a replacement 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 the 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 kinds of I/O and can be
programmed in multiple languages. In the past a DCS
included servers and workstations software whereas for the
PLC the HMI software was purchased 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 networking 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 configuration
work but making impossible or
unfeasible to add hardware and software from third parties.
The PLC can freely use third party hardware and software,
required lots of configuration work, but at 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 although
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 themselves with
HMI software companies supplying a total solution. Other
differences in that past included far better diagnostics
and redundancy in the DCS, but this gap has been closed.
Today, many PLCs are sold as and used in applications where
in the past only DCS could be used. Historically a DCS was
also far more expensive, but the competition from PLC and
new architectures have driven the initial price of DCS down
although the long term cost may be higher since with a DCS
you are pretty much locked to a single supplier.

Since a couple of years ago a technology called FOUNDATION
(tm) Fieldbus introduced a new system architecture based on
standard networking providing a leap similar to that from
DDC to DCS/PLC. The new system architecture is explained in
chapter 1 of the book "Fieldbuses for Process Control:
Engineering, Operation, and Maintenance" (buy online in
hardcopy or download
immediately in softcopy):
http://www.isa.org/fieldbuses

If you can't buy the book now, you can download chapter 1
(overview) for free in softcopy form. It's free, but you
must register an account. If your email does not support
this hyperlink feature correctly, please copy the entire
link and paste it into your Internet browser. Mind the line
wrap, make sure to get the complete path all the way to the
4585:
http://www.isa.org/Template.cfm?
Section=Shop_ISA&template=/Eco
mmerce/ProductDisplay.cfm&ProductID=4585

Jonas Berge
SMAR
===========
jberge@smar.com.sg
www.smar.com
Learn fieldbus at your own pace: www.isa.org/fieldbuses
Reply to this post...

Posted by FEMI ADULEYE on 14 July, 2005 - 12:49 pm
I have greatly benefited from this discussion.

However, I am of the opinion that there's no functional
difference between a PLC and a DCS today. Both can comprise
intelligent devices networked over a data highway for
control of sophisticated processes.

With PLC units manning process areas and then communicating
with a supervisory controller(strictly supervising, not
controlling); one could without any controversy call that a
DCS.

In essence, PLC = DCS, today!!!
Reply to this post...

Posted by Tom on 20 March, 2006 - 7:55 pm
Thanks for contribution of everybody. I think I should
contribute, too.

I think PLCs are parts of a either DCS or SCADA system, so
that the question should 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 for a particular
application, i.e 40% SCADA and 60% DCS or vice versa.
Choosing the ratio is implicited in choosing among several
vendor/ sofware on the market.

I could be wrong, though.

Tom
Reply to this post...

Posted by p.k.kundu on 7 April, 2007 - 1:23 am
Today both can serve the purpose of othersto some extent.
But a DCS conceptual development is basic/advance control
and other higher level control/advance fn. Where as PLC is
build basically for logic control including safety logic
upto SIL4 level but can accept analogue input preferred in
2oo3 configuration.
Reply to this post...

Posted by Manoj Joshi on 19 May, 2007 - 3:04 pm
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
Reply to this post...

Posted by Usman Alvi on 26 September, 2007 - 10:38 pm
Dear Mr. Joshi,

Please little illustrate the points of differences that you
mentioned here. In this case it will be more clear.
Reply to this post...

Posted by EPK on 25 October, 2007 - 11:23 pm
The biggest difference between DCS and PLCs is that DCS
systems provide:
Level of intergration between the controller, HMI and
historical database (Common database, Faceplates/Function
blocks interlinked.
Control algorithms for advanced control strategies highly
evolved and proven (Boiler 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 experience 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.
Reply to this post...

Posted by STEVEN MATSEBA on 15 June, 2007 - 12:12 am
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
environment 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 databases to develop your engineering
work on the PLC.
Reply to this post...

Posted by Jasir Sabri on 14 December, 2007 - 1:02 am
The discussion here was very useful. Thank you all.
Reply to this post...

Is This Answer Correct ?

8 Yes

6 No