It may surprise you to know that PLC, HMI and SCADA implementations
today are consistently proving more expensive than DCS for the same
process or batch application. CEE finds out more.
Traditionally,
DCSs were large, expensive and very complex systems that were
considered as a control solution for the continuous or batch process
industries. In large systems this is, in principle, still true today,
with engineers usually opting for PLCs and HMIs or SCADA for smaller
applications, in order to keep costs down.
So what has changed?
Integrating independent PLCs, the required operator interface and
supervisory functionality, takes a lot of time and effort. The focus is
on making the disparate technology work together, rather than improving
operations, reducing costs, or improving the quality or profitability of
a plant.
Yet a
PLC/ SCADA system may have all or part of the following list of independent and manually coordinated databases.
* Each controller and its associated I/O
* Alarm management
* Batch/recipe and PLI
* Redundancy at all levels
* Historian
* Asset optimisation
* Fieldbus device management
Each
of these databases must be manually synchronised for the whole system
to function correctly. That is fine immediately after initial system
development. However, it becomes an unnecessary complication when
changes are being implemented in on-going system tuning and further
changes made as a result of continuous improvement programmes.
Making changes
Every
time a change is made in one database, the others usually need to be
updated to reflect that change. For example, when an I/O point and some
control logic are added there may be a need to change or add a SCADA
element, the historian and the alarm database. This will require the
plant engineer to make these changes in each of these databases, not
just one – and get it right.
In another scenario, a change may
be made in an alarm setting in a control loop. In a PLC implementation
there is no automatic connection between the PLC and the SCADA/ HMI.
This can become a problem during start up of a new application, where
alarm limits are being constantly tweaked in the controller to work out
the process, while trying to keep the alarm management and HMI
applications up to date with the changes and also being useful to the
operator.
Today’s DCS, which are also sometimes called ‘process
control systems,’ are developed to allow a plant to quickly implement
the entire system by integrating all of these databases into one. This
single database is designed, configured and operated from the same
application.
This can bring dramatic cost reductions when using
DCS technology, when compared with PLC/ SCADA (or HMI): at least in the
cost of engineering. DCS hardware has always been considered as being
large and expensive. This is certainly no longer the case today. DCS
hardware even looks like a PLC, and the software runs on the same
specification PC, with the same networking – so why the extra cost? Is
it the software? Although it is true to say that DCS software can be
made to be expensive – but only by buying all of the many advanced
functional features that are available – and often that you would not
use or need!
Where smaller and medium systems are concerned,
then price comparisons on acquiring hardware and software are comparable
to PLC/SCADA. So, the real difference is actually in the costs
associated with the workflow – which is enhanced and simplified by the
single database at the heart of a DCS.
At this point one may
think that DCS functionality is biased towards control loops, whilst
PLCs are biased towards discrete sequential applications and that this,
therefore, is not a like-for-like comparison. This is another myth. A
DCS today is just as functionally and cost-effective as a PLC in fast
logic sequential tasks.
Demonstrating advantagesABB
was able to offer CEE some examples to demonstrate how savings can be
realised by using today’s DCS workflow, when compared with a PLC/HMI
(SCADA) system. The company has compiled the information from decades of
implementation expertise of ABB engineers, end-user control engineers,
consultants and multiple systems integrators who actively implement both
types of control solutions based on application requirement and user
preferences. It is easier to structure this explanation along a generic
project development sequence of tasks.
Step 1: System design PLC/
SCADA control engineers must map out system integration between HMI,
alarming, controller communications and multiple controllers for every
new project. Control addresses (tags) must be manually mapped in
engineering documents to the rest of the system. This manual process is
time consuming and error prone. Engineers also have to learn multiple
software tools, which can often take weeks of time.
DCS approach:
As control logic is designed, alarming, HMI and system communications
are automatically configured. One software configuration tool is used to
set up one database used by all system components. As the control
engineer designs the control logic, the rest of the system falls into
place. The simplicity of this approach allows engineers to understand
this environment in a matter of a few days. Potential savings of 15 -
25% depending on how much HMI and alarming is being designed into the
system.
Step 2: ProgrammingPLC/
SCADA control logic, alarming, system communications and HMI are
programmed independently. Control engineers are responsible for the
integration/ linking of multiple databases to create the system. Items
to be manually duplicated in every element of the system include:
scalability data, alarm levels, and Tag locations (addresses). Only
basic control is available. Extensions in functionality need to be
created on a per application basis (e.g. feed forward, tracking,
self-tuning, alarming). This approach leads to non-standard
applications, which are tedious to operate and maintain. Redundancy is
rarely used with PLCs. One reason is the difficulty in setting it up and
managing meaningful redundancy for the application.
The DCS
way: When control logic is developed, HMI faceplates, alarms and system
communications are automatically configured. Faceplates automatically
appear using the same alarm levels and scalability set up in the control
logic. These critical data elements are only set up once in the system.
This is analogous to having your calendars on your desktop and phone
automatically sync vs. having to retype every appointment in both
devices. People who try to keep two calendars in sync manually find it
takes twice the time and the calendars are rarely ever in sync.
Redundancy is set up in software quickly and easily, nearly with a click
of a button. Potential savings of 15 - 45%
Step 3: Commissioning and start-upTesting
a PLC/ HMI system is normally conducted on the job site after all of
the wiring is completed and the production manager is asking “why is the
system not running yet?” Off line simulation is possible, but this
takes an extensive effort of programming to write code which will
simulates the application you are controlling. Owing to the high cost
and complex programming, this is rarely done.
DCS benefits:
Process control systems come with the ability to automatically simulate
the process based on the logic, HMI and alarms that are going to be used
by the operator at the plant.
This saves significant time
on-site since the programming has already been tested before the wiring
is begun. Potential savings are 10 - 20% depending on the complexity of
the start up and commissioning.
Step 4: TroubleshootingPLC/
SCADA offers powerful troubleshooting tools for use if the controls
engineer programs them into the system. For example, if an input or
output is connected to the system, the control logic will be programmed
into utilising the control point. But when this is updated, did the data
get linked to the desperate HMI? Have alarms been set up to alert
operators of problems? Are these points being communicated to the other
controllers? Programming logic is rarely exposed to the operator since
it is in a different software tool and not intuitive for an operator to
understand.
The DCS way: All information is automatically
available to the operator based on the logic being executed in the
controllers. This greatly reduces the time it takes to identify the
issues and get your facility up and running again. The operator also has
access to view the graphical function blocks as they run to see what is
working and not (read only). Root Cause Analysis is standard. Field
device diagnostics (HART and fieldbus) are available from the operator
console. Potential savings of 10 - 40% (This varies greatly based on the
time spent developing HMI and alarming, and keeping the system up to
date.)
Step 5: The ability to change to meet process requirementsPLC/
SCADA: Changing the control logic to meet new application requirements
is relatively easy. The challenge comes with additional requirements to
integrate the new functionality to the operator stations. Also,
documentation should be developed for every change. This does not happen
as frequently as it should. If you were to change an input point to a
new address or tag, that change must be manually propagated throughout
the system.
The DCS way: Adding or changing logic in the system
is also easy. In many cases even easier to change logic with built in
and custom libraries of code. When changes are made, the data entered
into the control logic is automatically propagated to all aspects of the
system. This means far less errors and the system has been changed with
just a single change in the control logic.
Potential savings of 20 - 25% on changes is not uncommon. This directly affects continuous improvement programmes.
Step 6: Operator trainingWith
PLC/ SCADA operator training is the responsibility of the developer of
the application. There is no operator training from the vendor since
every faceplate, HMI screen or alarm management function can be set up
differently from the next. Even within a single application, operators
could see different graphics for different areas of the application they
are monitoring.
The DCS way: Training for operators is
available from the process control vendor. This is owing to the
standardised way that information is presented to operators. This can
significantly reduce operator training costs and quality due to the
common and expected operator interface on any application, no matter who
implements the system. This can commonly save 10 -15 percent in
training costs which can be magnified with the consistency found across
operators and operator stations.
Step 7: System documentationPLC/SCADA
documentation is based on each part of the overall system. As each
element is changed, documentation must be created to keep each document
up to date. Again, this rarely happens, causing many issues with future
changes and troubleshooting.
The DCS way: As the control logic is
changed, documentation for all aspects of the system is automatically
created. This can save 30 - 50 percent depending on the nature of the
system being put in place. These savings will directly minimise downtime
recovery.
Time saving estimates are based on typical costs
associated with a system using ~500 I/O, Two controllers, one
workstation and 25 PID Loops.
Conclusion If
you are using, or planning to use, PLCs and HMI/ SCADA to control your
process or batch applications, your application could be a candidate for
the use of a DCS solution to help reduce costs and gain better control.
The developer can concentrate on adding functionality that will provide
more benefits, reducing the return on investment payback period and
enhancing the system’s contribution for years to come. The divide
between DCS and PLC/ SCADA approaches is wide, even though some
commonality at the hardware level can be observed; the single database
is at the heart of the DCS benefit and is a feature that holds its value
throughout its life. The new economic proposal may be a DCS, says ABB.
Source:-http://www.controlengeurope.com/article/40827/DCS-and-PLC-SCADA-a-comparison-in-use.aspx
In the above diagram, you can see ladder logic looks like simple control circuit schematics where input sources (switches, push-buttons, proximity sensors, etc) are shown on the left and output sources are shown on the right.
