PLCs and DCSs Converge

In the past it was fairly easy to determine whether a distributed control system (DCS) or a programmable logic controller (PLC) based system was right for your application, because their strengths and weaknesses were well understood. In recent years, however, this has become more difficult, thanks primarily to the advancement of the microprocessor, which has allowed the technologies to converge.

By Bob Nelson and Todd Stauffer, Siemens Energy & Automation May 1, 2008

Sidebars: ‘PADs’ aid understanding of PLC evolution

In the past it was fairly easy to determine whether a distributed control system (DCS) or a programmable logic controller (PLC) based system was right for your application, because their strengths and weaknesses were well understood. In recent years, however, this has become more difficult, thanks primarily to the advancement of the microprocessor, which has allowed the technologies to converge.

The convergence of PLC and DCS has opened up a new set of options for those process plants that traditionally used PLCs to control their electrical infrastructure (such as motors, drives, and motor control centers), while utilizing DCSs for regulatory control. Also, because your applications may have grown or evolved, you may find that a traditional PLC or DCS no longer meets your requirements. Understanding the merging of PLC and DCS functionality is important for selecting the best system for your company.

Please realize that we will be using broad generalizations in the following analysis, and that every individual application will have exceptions to these “rules.” However, the logic is still sound. Since the authors work on different sides of the PLC/DCS fence for a supplier that has delivered both DCS and PLC solutions to the market for over 25 years, we feel that we are in a unique position to deliver both sides of the story.

At first glance, system architectures look very similar — and they are. Both systems share the following components: field devices, input/output (I/O) modules, controllers, human machine interfaces (HMIs), engineering, supervisory control, and business system integration. Differences become more apparent when you consider the nature and requirements of an application, however.

For example, in a DCS architecture, redundancy is often employed for I/O, controllers, networks, and HMI servers to ensure 100% availability. One of a PLC’s most common applications is the control of discrete field devices such as motors and drives. Effectively doing that requires that the controller be able to execute at high speeds (typically a 10 to 20 msec scan rate), and that the electrical technician responsible for maintaining it be able to read and troubleshoot the configuration in a language that he is familiar with (commonly relay ladder logic).

Because PLCs and DCS are not that different from a technology point of view, we must look beyond technology to the application expertise and domain knowledge built in to these systems by suppliers. This can help you better understand the sweetspots where each is best applied. The seven questions that follow are designed to make you think about your company’s operating philosophy and application requirements, taking into account the point of view of all the major stakeholders in your plant (engineering, operations, maintenance, etc.). The table on page 41 presents the questions and possible answers in a quiz-like format; the discussion of the questions on subsequent pages provides additional food for thought.

1. What are you manufacturing and how?

This may seem like a very basic question, but it is fundamental to determining the requirements of the application and, therefore, the best-fit automation system. Typical factory automation applications, for which the PLC was originally designed, involve the manufacturing and/or assembly of specific items. These applications may employ one or more machines and a fair amount of material movement from machine to machine. A typical characteristic of this type of process is that the operator can usually monitor the items visually as they progress through the manufacturing line. The process is, by nature, very logic-control-intensive, often with high-speed requirements (throughput = profits). This type of process is often controlled by a PLC and HMI combination.

Process automation applications typically involve the transformation of raw materials through the reaction of component chemicals or the introduction of physical changes to produce a new, different product. These applications may be composed of one or more process unit operations piped together. One key characteristic is that the operator can’t see the product. It is usually held within a vessel, and may be hazardous in nature. There is usually a large amount of simple as well as complex analog control (e.g., PID or loop control), although the response time is not exceptionally fast (100 ms or greater). This type of process is often controlled by a DCS, although the analog control capability of a PLC may be more than adequate. A determining factor in the selection process is often the scope of the control application (i.e., plantwide versus single unit, and number of I/O points).

Process applications may also have sequential (or batch) control needs. A PLC can be used effectively for “simple” batch applications, while a DCS is typically better suited for “complex” batch manufacturing facilities that require a high level of flexibility and recipe management.

2. What is the value of the product being manufactured and the cost of downtime?

If the value of each independent product being manufactured is relatively low, and/or downtime results in lost production, but with little additional cost or damage to the process, the PLC is the likely choice. If the value of a batch is high, either in raw material cost or market value, and downtime not only results in lost production but potentially dangerous and damaging conditions, the selection should be DCS. In some chemical applications, maintaining the process at steady state is critical, because if the system goes down, the product could solidify in the pipes. If the cat cracker in a refinery goes down it could be days before it can be brought back on-line and that means lots of lost revenue.

In contrast, the bottling operation of a brewery that only needs to run 10 hours a day to meet production schedules, and which can be shutdown for system maintenance, troubleshooting, or upgrades, is a classic PLC application.

Dangerous downtime is clearly another deciding factor. The more volatile the application, the more it may require a solution with lots of redundancy to ensure that the system is available when needed.

3. What do you view as the “heart” of the system?

Typically, the heart of a factory automation control system is the controller (PLC). It contains all the logic to move the product through the assembly line. The HMI is often an on-machine panel or a PC-based station that provides the operator with supplemental or exception data. Operational information from data analysis is increasingly needed, however, driving demand for more robust HMIs.

In process automation, where the environment can be volatile and dangerous, and where operators can’t see the actual product, the HMI is considered by most to be the heart of the system. In this scenario, the HMI is a central control room console that provides the only complete “window” into the process.

4. What does the operator need to be successful?

In a PLC environment, the operator’s primary role is to handle exceptions. Status information and exception alarming help keep the operator aware of what is happening in the process, which in many cases can run “lights out.” The DCS plant requires an operator to make decisions and continuously interact with the process to keep it running. In fact, leveraging the operator’s process knowledge is often critical to operational excellence and keeping the process running optimally.

5. What system performance is required?

The speed of logic execution is a key differentiator. The PLC has been designed to meet the demands of high-speed applications that require scan rates of 10ms or less, including operations involving motion control, high-speed interlocking, or control of motors and drives. A DCS doesn’t have to be that quick most of the time. The regulatory control loops normally scan in the 100 to 500 millisecond range. In some cases, it could be detrimental to have control logic execute any faster — possibly causing excessive wear on final control elements such as valves, resulting in premature maintenance and process issues.

The extra cost for redundancy, an insurance policy of sorts, may be well worth it in the case of the typical DCS system, but is often not cost-justified for PLC-based systems.

Taking the PLC system offline to make configuration and engineering changes may have less impact, since the platform is not running continuously or because the process can be restarted easily. In contrast, configuration changes and tweaks to the DCS system are done on-line, while the process is running virtually non-stop. A blast furnace, for example, is planned to stay on-line continuously for five to seven years.

6. What degree of customization is required?

The expectation and desire to be able to create a customized application varies greatly between DCS and PLC users. Because the PLC was originally designed to be a jack of all trades, it’s understood that the development of customized routines and functions is required to meet the unique needs of an application.

Pre-engineered solutions, consisting of standards, templates, and extensive libraries, are what DCS application engineers expect out-of-the-box when working with a new system. The highest priority of a DCS is to deliver reliability and availability, which often results in a design which trades unlimited functionality for repeatability and dependability. The significant tradeoff with the DCS is its inability to accept many custom modifications without creating compatibility issues.

7. What are your engineering expectations?

Factory automation engineers want customizable control platforms, which offer the individual components that can be quickly programmed together to accomplish the task at hand. Often integrators and engineers open the PLC toolkit, roll up their sleeves, and start programming. The tools provided by a PLC are typically optimized to support a bottom-up approach to engineering, which works well for smaller applications.

DCS engineers, on the other hand, are typically most effective using a top-down approach for engineering, which forces them to put significant effort into the upfront design. The ability to propagate libraries and templates throughout the application is very important to minimize rework and promote the use of standards.

ONLINE EXTRA

Do you have a Hybrid Application?

The main article explained the key attributes and differentiators between classic PLC and DCS systems. The same categories of information can be used to define the key requirements for a control system suited for hybrid applications. If the quiz you took revealed a roughly equal number of check marks on the left (PLC) side and on the right (DCS) side, you have a hybrid application.

Another way to tell is by how closely your application is to the following definitions (from an Intech article published Sept 2007, “Hybrid Control Identity Crisis:

“The marriage of the discrete functions, which PLCs handled so simply and economically, with the sophisticated analog continuous control capabilities of the DCSs.”

“The architectural marriage of the PLC simplicity and cost with the sophisticated operator displays, alarm management, and easy but sophisticated configuration capabilities of the DCS.”

How to select a control system

If you determine that you have a hybrid control situation, here are the things you need in your process control system:

Controller – Can execute fast scan logic (10- 20 msec), such as that required for motor control, and slow scan logic (100 – 500 msec) such as required for analog control, simultaneously in a single controller.

Engineering configuration languages – Provides ladder logic, function block diagram, and a powerful programming language for creation of custom logic from scratch.

Redundancy – Offers the option of tailoring the level of system redundancy to deliver the required system availability by balancing up-front cost versus the cost of unplanned downtime.

Batch capabilities – Provides modular batch capability to cost-effectively address the continuum of simple to complex batch applications

Alarm management – Offers power alarm management tools to help operators respond effectively to        plant upset conditions

System diagnostics / asset management – Provides both a rich set of built-in system diagnostics, as well as asset management of all critical assets in the plant (transmitters, valve positioners, motors, drives, MCCs, heat exchangers, etc.)

Scalability – Hardware, software, and licensing supports smooth and economical scaleup from small all-in-one systems (10’s of I/O) up to large client/server systems (10,000’s of I/O)

by Bob Nelson, PLC Marketing Manager, and Todd Stauffer, DCS Marketing Manager, for Siemens Energy & Automation. The authors can be reached at bob.nelson@siemens.com and todd.stauffer@siemens.com .

Author Information

Adapted from a whitepaper by Bob Nelson, PLC marketing manager, and Todd Stauffer, DCS marketing manager, for Siemens Energy & Automation. They can be reached at bob.nelson@siemens.com and todd.stauffer@siemens.com .

1. What are you manufacturing and how?

Manufacturing or assembly of specific items (aka “things”)

Involves the combination and/or transformation of raw materials (aka “stuff”)

Product is visible as it moves through the process

Often impossible to visually see the product as it moves through the process

High-speed logic control (such as motors)

Regulatory/analog (loop) control

Simple batch control

Complex batch control

2. What is the value of the product being manufactured and the cost of downtime?

Value of the individual component being manufactured is relatively low

The value of a “batch” can be very high (either in raw material cost or market value)

Downtime mainly results in lost production

Downtime not only results in lost production, but can result in dangerous conditions

Downtime does not typically damage the process equipment

Downtime can result in process equipment damage (product hardens, etc.)

Return to steady state production after an outage is short and relatively straightforward

Return to steady state production after an unplanned outage can be long, expensive, and difficult

3. What do you view as the “heart” of the system?

Typically, the heart of the system is the controller

Typically, the heart of the system is the HMI

4. What does the operator need to be successful?

The operator’s primary role is to handle exceptions

The operator’s interaction is typically required to keep the process in its target performance range

Status information (on/off, run/stop) is critical information for the operator

Faceplates and analog trends are critical to “see” what is happening to the process

Exception-based alarming is key information for the operator

Alarm management is key to safe operation of the process and for responding effectively during plant upset conditions

Manufacturing might be able to run “lights-out”

HMI loss could force the shutdown of the process

5. What system performance is required?

Fast logic scan (approx. 10ms) is required to perform motor or motion control

Control loops require deterministic scan execution at a speed of 100 to 500 ms

Redundancy may not be cost justified

System redundancy is often required

System can be taken offline to make configuration changes

Online configuration changes often required

Analog control: simple PID only

Analog control: simple to advanced PID control up to Advanced Process Control

Diagnostics to tell you when something is broken

Asset Management alerts you to what might break before it does

6. What degree of customization is required?

High level programming languages are available for creating custom logic

Custom logic created from existing function blocks

Customized routines usually required

Many algorithms (i.e., PID) are complex and do not vary among applications

Standard libraries considered nice features

Standard application libraries are expected (function blocks and faceplates)

Provisions must be available to integrate functions/products into an integrated architecture

Entire system is expected to function as a complete solution

7. What are your engineering expectations?

Program/configure individual components and integrate later (bottom-up)

Upfront design of complete system before implementation begins (top-down)

Desire customizable platforms to build upon

Looking for significant “out-of-the-box” functionality

System designed to be flexible

System designed to make it “easy” to engineer process applications

Solution is generic in nature, to be applied on a wide variety of applications

Use of pre-defined, pre-tested functions saves time

Use ladder logic to configure application

Use function block diagram to configuration application

‘PADs’ aid understanding of PLC evolution

Krzysztof Pietrusewicz, PhD

Control Engineering Poland

In applications in which the programmable logic controller (PLC) is appropriate, there are still choices to make, because the PLC itself has evolved. In 2001, the industry was introduced to what has been called the next stage of the PLC’s evolution: the programmable automation controller, or PAC. This next-generation of control products combines ruggedness (typical of the PLC) with multidomain functionality and the openness of personal-computer-based control platforms. The technology of intelligent modules added to traditional PLCs, however, gives them functionality they were not able to handle until now. These devices are not full-blown PACs, but they are also not traditional PLCs. I call them PADs, for programmable automation devices. This middle-class of controller technology may be just right for a given application, and shows how PLCs have evolved.

PAD controllers offer much more flexibility than traditional PLCs during programming and configuration. Like a PAC, a PAD lets the users program their applications (machine control, process control, motion control) with the use of one programming platform. The existence of the linear memory type and the deterministic multitasking real-time operating system makes PADs similar to PC-based controllers, but in a rugged, industrial focused solution.

PADs give users a lot of possibilities without letting them fully interfere with the system core or the meaning of system files (as with Windows XP, whereby deleting some files can crash the system). Linear memory, typically in the removable version, lets users flexibly program their applications. One does not have to care about placing the variable in the memory area, or if this area is limited or not. The system does it. A large amount of memory, which is typical for PCs, is now also available for PADs.

Built-in communications interfaces are a key element of PADs. Two or three years ago users looked for PLCs with support for communication procedures (the hardware had to be extended with additional modules). Now we are seeing built-in communications hardware/software support, in the form of two or more onboard communication interfaces. PADs have at least three communication interfaces, such as serial, CAN, Ethernet and others.

The most important thing that differentiates PADs and PLCs is the flexibility of programming interface. In simple PLCs (or even powerful and complex ones), two or three programming languages typically are supported. PADs extend the number of languages supported to four of five. These include ladder diagram (LAD), object programming (SFC) , Function Block Diagram (FBD) and Structured Text (ST), which can be used for the implementation of complex control algorithms as well as for the complex floating point evaluations. PADs typically introduce floating point solvers. Without the possibility to execute the floating point evaluations (when only fixed-point is available), the quality of PLC control can be very limited. PADs remove that limitation.

A typical PLC also has the so-called floating value of the scan time, i.e., the more evaluations we need, the longer the scan time. In some PLC models, the user can fix the value of the scanning time. But in PADs, one can also fix a couple of scan times and use the mechanism of priorities for different types of applications. For example, temperature control needs different values of sampling (scan) time than pressure control systems.

There are only two considerations related to memory construction in PLCs: the total amount of memory, and the removability of the memory cartridge/card. PADs make us look at memory usage in a whole new way, and introduce the aspect of linearity of the memory.

PLCs have fixed memory areas: digital inputs, analog inputs, flags, registers, counters, timers. Also the number of counters in a typical PLC is fixed or determined by the memory range. In last few years, however, some PLCs have allowed users to freely configure such areas. But after configuring the PLC, the programmer has only the number of memory elements he or she has configured.

In more advanced programming situations, one does not have to care about the memory ranges for the programming instructions or where in memory the variable is. PADs support this aspect of memory usage. The only thing a PAD programmer has to do is map the variables with the inputs and outputs of the programmable device. Also, more and more programming software for PADs offers the possibility of generating the project off-line, putting it on the memory card, and then using it in the device.

According to Control Engineering research, in 2004-2006 many users were not sure what a PAC was. In 2007, 6% of user reported replacing existing PLCs with PACs. But in both 2006 and 2007, about 20% of users reported supplementing their existing PLC systems. This indicates that PACs are not replacing PLCs today, but that PLCs are evolving.

PADs are a small but necessary step in the evolution of PLCs. While PACs are the most advanced control solution today, the PAD is a wider class of control system which, to the more experienced engineer, will seem very similar to a PLC. The programming interface is closer to a PLC than to a PAC, but the possibilities PADs offer for advanced engineers are amazing.

Krzysztof Pietrusewicz, Ph.D., Control Engineering Poland, teaches at the Szczecin University of Technology, Institute of Control Engineering, University Centre of Mechatronics. Reach him atkp@controlengpolska.comorKrzysztof.Pietrusewicz@ps.pl.