Difference between PLC and DCS

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.

Distributed Control System:

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." 

Programmable Logic Controller:

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.

Architecture of PLC - Part 2

I/O Modules:

• Ø  The I/O interface section of a PLC connects it to external field devices.
• Ø The main purpose of the I/O interface is to condition the various signals received from or sent to the external input and output devices
• Ø  Inputs to, and outputs from, a PLC are necessary to monitor and control a process. Both inputs and outputs can be categorized into two basic types: logical or continuous.

Consider the example of a light bulb:

• If it can only be turned on or off, it is logical control.
• If the light can be dimmed to different levels, it is continuous. Continuous values seem more intuitive, but logical values are preferred because they allow more certainty, and simplify control. As a result most controls applications (and PLCs) use logical inputs and outputs for most applications.         

Input module:

The input module connects the input terminals to the rest of the system. Each terminal is usually electrically isolated from the internal electronics by OPTO ISOLATORS. This is a way of passing on the status of the input (on or off) by use of a light emitting diode and phototransistor. A typical opto isolator is shown. They have the advantage of reducing the effects of spurious pulses generated from electromagnetic sources. It is also a safety feature to prevent live voltages appearing on the input lines in the event of a fault. 

Internally a computer usually operates at 5 V DC. The external devices (solenoids, motor starters, limit switches, etc.) operate at voltages up to 110 V AC. The mixing of these two voltages will cause severe and possibly irreparable damage to the PLC electronics. Less obvious problems can occur from electrical noise introduced into the PLC from voltage spikes on signal lines, or from load currents flowing in AC neutral or DC return lines. Differences in earth potential between the PLC cubicle and outside plant can also cause problems.

The question of noise is discussed, but there are obviously very good reasons for separating the plant supplies from the PLC supplies with some form of electrical barrier. This ensures that the PLC cannot be adversely affected by anything happening on the plant. Even a cable fault putting 415 V AC onto a DC input would only damage the input card; the PLC itself (and the other cards in the system) would not suffer. This is achieved by optical isolators, a light-emitting diode and photo-electric transistor linked together.

Protection of the PLC from outside faults. The PLC supply L1/N1 is separate from the plant supply L2/N2 switch on. Because there are no electrical connections between the diode and the transistor, very good electrical isolation (typically 1 and 4kV) is achieved.

A DC input can be provided. When the push-button is pressed, current will flow through D1, causing TR1 to turn on, passing the signal to the PLC internal logic. Diode D2 is a light-emitting diode used as a fault-finding aid to show when the input signal is present. Such indicators are present on almost all PLC input and output cards.

The resistor R sets the voltage range of the input. DC input cards are usually available for three voltage ranges: 5V (TTL), 12V 24V, 24V 50V.

A possible AC input circuit. The bridge rectifier is used to convert the AC to full wave rectified DC. Resistor R2 and capacitor C1 act as a filter (of about 50ms time constant) to give a clean signal to the PLC logic. As before, a neon LP1 acts as an input signal indicator for fault finding, and resistor R1 sets the voltage range. The isolation barrier and monitoring LEDs can be clearly seen. This card handles eight inputs and could be connected to the outside world.

Following are the some of the Input devices.

• Switches and Push buttons

• Sensing Devices                         

• Limit Switches

• Photoelectric Sensors

• Proximity Sensors

• Condition Sensors

• Pressure Switches

• Level Switches

• Temperature Switches

• Vacuum Switches

• Float Switches

• Encoders

Inputs and Outputs connected to PLC

Outputs Modules:

Outputs to actuators allow a PLC to cause something to happen in a process. A short list of popular actuators is given below in order of relative popularity.

Solenoid Valves - Logical outputs that can switch a hydraulic or pneumatic flow.

Lights - Logical outputs that can often be powered directly from PLC output boards.

Motor Starters - Motors often draw a large amount of current when started, so they require motor starters, which are basically large relays.

Servo Motors - A continuous output from the PLC can command a variable speed

or position.

Outputs from PLCs are often relays, but they can also be solid state electronics such as transistors for DC outputs or Triacs for AC outputs. Continuous outputs require special output cards with digital to analog converters.

Output cards again require some form of isolation barrier to limit damage from the inevitable plant faults and also to stop electrical noise corrupting the processor's operations. Interference can be more of a problem on outputs because higher currents are being controlled by Computers and industrial

There are two basic types of output card. Eight outputs are fed from a common supply, which originates local to the PLC cubicle (but separate from the supply to the PLC itself). This arrangement is the simplest and the cheapest to install. Each output has its own individual fuse protection on the card and a common circuit breaker. It is important to design the system so that a fault, say, on load 3 blows the fuse FS3 but does not trip the supply to the whole card, shutting down every output. This topic, called discrimination, is discussed further in Chapter 8. A PLC frequently has to drive outputs which have their own individual supplies.

A typical example is a motor control centre (MCC) where each starter has a separate internal 110-V supply derived from the 415-V bars. The card arrangement could not be used here without separate interposing relays (driven by the PLC with contacts into the MCC circuit). An isolated output card, has individual out-puts and protection and acts purely as a switch. This can be connected directly with any outside circuit. The disadvantage is that the card is more complicated (two connections per output) and safety becomes more involved. An eight-way isolated output card, for example, could have voltage on its terminals from eight different locations.

Relay outputs can be used (and do give the required isolation) but are not particularly common. A relay is an electromagnetic device with moving parts and hence a finite limited life. A purely electronic device will have greater reliability. Less obviously, though, a relay-driven inductive load can generate troublesome interference and lead to early contact failure. Optical isolation is again used to give the necessary separation between the plant and the PLC system. Diode D1 acts as a spike suppression diode to reduce the voltage spike encountered with inductive loads. The output state can be observed on LED1. If NPN transistors are used, a current sinking card can be made. AC output cards invariably use triacs, a typical circuit being. Triacs have the advantage that they turn off at zero current in the load, which eliminates the interference as an inductive load is turned off. If possible, all AC loads should be driven from triacs rather than relays

An output card will have a limit to the current it can supply, usually set by the printed circuit board tracks rather than the output devices. An individual output current will be set for each output and a total overall output. Usually the total allowed for the card current is lower than the sum of the allowed individual outputs.

Automation future: Adaptable expertise for next-generation workforce

Human skills required include an understanding of the potential of automated technologies, how those technologies can be integrated, including with business and other systems, and skills in business analytic.

Until recently, we had become used to dominance of the bandwagon that promoted the view that the future of developed countries depended on the transition from industrial into knowledge-driven service-based economies. It always seemed that the analyses that led to that conclusion were extremely light on understanding the interdependence of different economic sectors and on the sustainability of export markets for the different sectors. Following the financial crash in 2008, there now seems to be a consensus that, after all, manufacturing is the essential growth driver. So far, so good, but the question then is how can the developed countries, with their relatively high cost bases, compete in manufacturing? The answer has many components, but a significant factor is, of course, automation. Accordingly, the overall market for industrial automation software and equipment is predicted to growth at a healthy pace in 2013; the chart below shows the estimated volume of sales of robots in industry by region.

It’s now over 50 years since the introduction of automation into manufacturing industries—the first robots and numerically controlled machine tools into factories, the development of the first computer-aided design technologies, and even the first computerized production planning and control systems. But an explosion in their capabilities has been enabled by the advances in communications technology over the last 20 years, transforming the structure of the industrial landscape profoundly. In most industries, a suitable mix of automation technology has delivered desired outcomes—the ability to produce more with fewer employees, reduced costs, faster time to market, and so on. Figure 2, extracted from Cambashi’s Market Observatory datasets, shows the full scope of today’s industrial automation technology set. But what has been the impact on the workers in terms of required skills and the nature of their activity; and what is the outlook?

Fewer routine tasks

The most obvious impact of automation is the elimination of routine tasks, be they manual production line activities or repetitive office processes. However, the ability to automate manual work has penetrated much further in the last 10 years, a good example being the extent to which even some aspects of design can be automated.

For specific, highly focused design tasks where the parameters and rules can be defined clearly—for example, routing of electrical/electronic circuits—a computer can certainly produce a viable design automatically. Similarly, for tasks like simulation and analysis, specialized expertise is no longer required to create the model in many cases, due to advances in technology that automate that pre-analysis modeling step.

Understand design principles

Does this mean that the design engineer can get away with lower levels of engineering expertise, a kind of “the calculator eliminates the need for mental arithmetic” effect? Or does engineering expertise need to be augmented by other skills? Today, the latter remains true for most situations. That is, the engineer will need to understand the principles underpinning a design to validate the outcomes of the automated aspects of the process. However, the reliability of automated design technology is improving all the time and in some areas—electronic circuit routing being a case in point—is well-established and produces reliable outcomes. This raises a lot of questions for the future. If the engineer no longer needs to validate the details of the design, what skills will be needed? Surely the detailed engineering expertise must reside somewhere, so is it with the software developer?

The answer is probably that it depends on the industry. But one aspect that is common to all is the point about communications technology. Coupled with dramatic improvements in both ease of use and integration between engineering applications, the ability to search, use, and share information has transformed work processes and the reach of individual engineers. This impacts all areas of the design process, from the ability to access existing options, through assessing more alternatives, to dealing with aspects, such as manufacturability, that might have previously required a hand-off to another engineer. The implication here is that each individual engineer will be in a position to take a broader view of the product development process. To exploit that potential will require a broader understanding of the engineering issues.

We have looked at the impact of automation on design, but what about the domain with which the term “automation” is most associated, the factory? Not only simple production tasks, but even those that may have required a high level of skill like welding complex geometries can be done to the required quality and to a high level of consistency by a robot. The automotive industry, along with the electronics industry, is the major exploiter of robotic technology; see the chart below.

Skill sets are changing

There is no doubt that factory automation results in fewer traditional factory workers; indeed, it’s one of the main justifications for automating. So here again we have the question of the impact on the skills required of the workforce. For the factory, the skills shift is more significant than for other areas. The use of automation technology does not eliminate the traditional jobs altogether. In fact, understanding the manufacturing technologies and processes in the factory is a vital ingredient for process improvement. Nevertheless, the majority of roles will change in nature, at a minimum towards operating more complex computer-controlled equipment.

This trend will increase with the uptake of new technology that enables the “Internet of Things” and its exploitation for industrial Internets. This trend exploits the ability of machines and devices to exchange information over the Internet without human intervention. A recent example is GE’s new advanced sodium-nickel battery plant in Schenectady, N.Y. The plant is peppered with sensors to measure all manner of manufacturing process data (cycle times, process parameters, material tracking, etc.), not only supporting a high degree of automation but also enabling comprehensive process analysis to identify opportunities for improvement. The human skills required are therefore an understanding of the potential for automated technologies, how those technologies can be integrated, including with business and other systems, and skills in business analytics.

The ability of devices to exchange information over the Internet without any human involvement also has major implications for higher-level factory and supply chain management activities. It will not be long before we see those activities having significant automated content as inputs like supply chain status, production status, quality information, and so on are fed automatically into a new planning run. Even the agent of much of the automation in industry, software, is experiencing substantial progress in the automation of its development, with technologies like model-based code generation gaining ground all the time.

Integrated digital factories

While, from an engineering perspective, the technologies that underpin digital factories are fascinating, any discussion of the impact of automation on the workforce should include a global perspective. This is a very large and broad-ranging topic, with no easy answers. While the developed countries see their future post-industrial economies involving high levels of automation, as shown in the chart in Figure 1, Asia is already the largest consumer of robot-based factory automation technology. So, while proponents of automation claim that it gives the high-cost countries the necessary productivity edge to compete in global markets, leadership in exploitation of the technologies is vital. A good example is achieving effective integration between the factory floor and the rest of the enterprise. This is a dynamic and evolving picture, requiring constant assessment of the opportunities for IT-enabled process change in the planning and execution of manufacturing activities. To achieve this requires a broad combination of IT and industry skills.

From this point of view, the developed countries should maintain the advantage for perhaps another decade; but over time, the approaches and methods will be adopted by emerging countries and the need to find other sources of advantage will be pressing. In the short term, it is true that the roles in manufacturing will not be as plentiful as in the past and that many of them will require more advanced skills. In fact, we must bear in mind that we may have reached the point where technology has become so pervasive  that, despite the activities involved in its development, implementation, and maintenance, it is a net eliminator of jobs. The retail industry has suffered just this under the impact of Internet-based automation. Perhaps the most valuable skill of all will be adaptability!

Understanding Derivative in PID Control

The third factor in PID is the least understood. Derivative action can do good things, but when used improperly, it causes headaches.

You’ve probably heard the expression, “a little knowledge is dangerous.” This certainly applies to PID loops, especially when you try to dabble with the derivative factor. This element of the control strategy can improve performance, but only in the right situations and when applied properly. Understanding those situations begins with a quick basic review of how PID operates.

Proportional control applies an effort in proportion to how far you are from the setpoint. It’s main drawback is that the closer you get to the setpoint, the less it pushes. Eventually it doesn’t push hard enough to move the variable, so the process can run continuously close to the setpoint, but not quite there.

Integral control tries to even out the difference of the time spend on both sides of the line. If you’ve spent a minute running at 98%, it will try to push you over to 102% for similar amount of time. This action compensates for P’s inability to make that last effort.

Many, if not most, control applications can run perfectly well with just P and I control. (See sidebar.) Ziegler-Nichols tuning produces the traditional curve where the process variable oscillates briefly but settles onto the line with each cycle reducing amplitude by 75%. For applications that require the fastest possible response, seeing that kind of action after a setpoint change would be hugely rewarding to a control engineer.

But let’s say the process in your case is a tank of liquid product that you’re trying to heat. If the process variable (temperature) goes above the setpoint, the product may be ruined or catch on fire. So, how do you get the process variable to move, but not overshoot the setpoint excessively? One answer is introducing a derivative factor.

Derivative acts as a brake or dampener on the control effort. The more the controller tries to change the value, the more it counteracts the effort. In our example, the variable rises in response to the setpoint change, but not as violently. As it approaches the setpoint, it settles in nicely with a minimum of overshoot. It doesn’t move as quickly as the PI-only effort, but without the oscillations, the right amount of derivative action can stabilize the process variable at the setpoint sooner.

Bob Rice, Ph.D., director of solutions engineering for Control Station, sums up the three elements: “The proportional term looks at where my value is currently. Integral looks at where I’ve been over time, and derivative tries to predict where I’m going. Derivative tries to work opposite of where proportional and integral are trying to drive the process. P and I are trying to drive one way, and D is trying to counteract that. Derivative has its largest effect when the process is changing rapidly in one direction. The P and I terms are saying, 'Keep going.’ The derivative catches it and says, 'You’re going too fast. You need to slow down.’”

Factors act when needed

If you think in terms of what the controller wants to do in a given situation, you can begin to analyze how the factors are working at any point in the process. Looking at the situation in the top diagram of the sidebar, the operator has raised the setpoint. How does the controller respond?

As the process variable passes the “cliff” formed by the setpoint change, suddenly the proportional error is huge, although integral and derivative actions are effectively zero. The controller begins to raise the variable responding to the proportional action. As it moves, the P action declines as it gets closer to the setpoint, but the integral action grows as long as the variable is below the line. As the curve suddenly turns up, derivative wakes up in response to the sudden shift and begins to counteract what’s happening with P and I.

As the variable approaches the setpoint, proportional action is almost zero but integral has increased. The derivative braking action continues. Once the variable crosses the line, it changes. P begins to increase its effort in the other direction as it moves above the line. Integral begins to relax now that it has moved past the setpoint. D sees the slope beginning to decline and relaxes as well. Soon the proportional action brings it around, the variable heads toward the setpoint again and all the actions are reversed.

Proportional action is the strongest when the distance from the setpoint is the greatest. Integral increases its effort with every moment that passes with the variable on just one side of the line. Derivative makes no effort when the line is flat, even if it is nowhere close to the setpoint. D will not move the line itself, it can only counteract P and I efforts. So a D controller, if such exists, would be stable and easy to tune, but not particularly effective.

The art of loop tuning is determining the optimum values for each of those actions so that they balance each other and move the specific loop in a way that is best for that process.

So where’s the value?

So if the main purpose is slowing the control effort of the other factors, what’s D good for? Fast acting loops, such as flow and pressure loops, don’t really need it. If a loop can change in a matter of seconds or a minute or two, making it respond 10% faster isn’t much of an improvement. As already mentioned, the best uses are for slow moving loops where overshoot is undesirable.

Rice suggests, “With a slow loop, the future’s pretty easy to predict because you know it’s going to keep going for 20 to 30 minutes. But if you’ve got something like a flow loop where in two or three samples, your process can be in a completely different direction, derivative is not going to provide any benefit. If you’ve got processes that tend to overshoot and are very slow, that’s where your benefit’s going to come: one-way batch systems where you can only heat but you can’t cool, or you can only cool but you can’t heat. Overshoot is completely unacceptable in those cases, because if you go past your setpoint, you don’t have an opposite action to bring it back. You use derivative to be sure you don’t.”

So you don’t need D in most cases? Probably not. Rice adds, “About 90% of the loops out there are probably PI control. It’s going to get you good enough control for most of your applications, and it’s simpler. A well tuned PI controller is going to beat a moderately tuned PID controller every time. Adding the extra tuning parameter adds complexity, which can confuse a lot of people. It’s only in those remaining percentage points where you’ve got a really slow loop but you can’t afford MPC or other advanced controls, then you can add some derivative to take the edge off so it doesn’t overshoot and tend to oscillate as much.”

George Buckbee, P.E., vice president of marketing and product development for ExperTune warns that some traditional loop tuning beliefs should not be considered as universal. “That Ziegler-Nichols quarter amplitude damping thing is a bit of a fallacy for a lot of loops,” he advises. “The criteria for what is 'good performance’ really do change from one loop to the next, but usually it’s faster movement toward the setpoint with less risk of overshoot. You have to choose those criteria wisely, and define them for control performance on a per-loop basis”.

As the sidebar shows, there are approaches that can achieve the effect of derivative control without using it at all. However, as Buckbee points out, each loop has to be approached individually using the right tuning for a given situation.

D for dangerous

This all sounds very positive, so where does the problem come in? Buckbee compares using derivative to learning to drive: “Derivative is like trying to drive your car with one foot on the gas and one foot on the brake. To my 16-year-old son who’s just learning, that was the first thing he wanted to do.” Such an approach might work for a skilled race car driver, but most loops don’t need that kind of immediate and violent action.

It is derivative’s tendency to act quickly that introduces most of the problems. Anytime it sees the process variable head up or down, it’s going to respond even if the change is really nothing but noise. Buckbee adds, “Derivative is looking at fast, short-term changes in the process variable, and that’s all that noise is. It goes up by 1%, and the next sample it’s down by 1%. Derivative looks at that and says, 'Wow, a 1% change in one second—that’s pretty fast, something’s going on, I better make a change.’ The controller is going to try and compensate for that kind of movement, and you’re going to beat up the valve.”

So the main negative result from derivative action is excessive wear on equipment. If you drive your car by alternately flooring the gas and slamming on the brakes, or worse, driving with both pressed at the same time, it will wear out quickly. One solution, at least in some cases, is using a filter on the process variable to reduce noise. But this can introduce its own problems. “You need to coordinate the amount of derivative action with the amount of filtering that you do,” Buckbee suggests. “If you overfilter, you might as well not have derivative at all. You shouldn’t find the filtering value and the derivative value independently of each other.”

Rice also cautions, “A lot of controllers that use derivative have internal filtering. You have four parameters, P, I, D, and derivative lag filter. A lot of controllers implement this derivative filtering concept and don’t always tell you what they’re doing. Some don’t do a very good job of it. You get into a very complicated algorithm where there isn’t just one or two PID forms, there’s 10 or 12 or 15 variations that can really muck up the tuning process.”

D for destabilizing

Even in situations where loops move slowly and fit the description for appropriate derivative deployment, you have to be careful how much you use. Rice suggests that if the dampening action is too high, you have to turn up the P and I action to compensate, like trying to accelerate your car with a foot on the brake.

“If you have a system like a really slow temperature loop, users tend to put a lot of derivative in there because they don’t like the overshoot,” he says. “What ends up happening is you have to put a pretty large proportional and integral effect in there to get the process to even move, and the derivative sits there and fights it all day long. If you’ve got a system where there’s an upset, you want to be able to recover from that upset quickly, but derivative’s dampening effect is going to hamper that response. Large derivative action tends to destabilize a loop because it doesn’t allow it to change. The rule of thumb is that if your derivative time is greater than the reset time of your controller, you’ve got issues. That should never, ever occur.”

Ultimately, the use of derivative action can be beneficial, but it has to be used in the right situations and in the right amounts. Your starting assumption should be to see if the process will run satisfactorily on PI control alone for the reasons already mentioned. As the sidebar shows, careful tuning of P and I factors can achieve much of the same no-overshoot benefit in certain conditions, so that is probably a better approach to begin with. Adding derivative should be done cautiously and with appropriate filtration. Like cooking with hot sauce, in the right context and in skilled hands, the result can be remarkable. But if it’s used inappropriately, it’s a recipe for disaster.

Derivative action at work

John Ziegler and Nathaniel Nichols, the fathers of PID loop tuning, recognized as far back as 1942 that derivative action dampens the control effort. They discovered through trial and error that setting the derivative time to at least half of the process deadtime would slow the controlled response to a step change in the setpoint.

The top trend chart shows a typical first-order process responding to a setpoint change under the influence of a full, three-term PID controller tuned according to the Zeigler-Nichols rules. The middle trend chart shows the same response with the brakes off; that is, with derivative action disabled. The rate at which the process variable climbs after the setpoint change and the degree by which it overshoots the setpoint have both increased.

Ironically, overshoot can be eliminated entirely by leaving the derivative action disabled, decreasing the proportional gain and increasing the integral time. The bottom trend chart shows the process’s setpoint response under the influence of a PI-only controller tuned according to the critical damping rules that call for a 69% smaller proportional gain and an integral time lengthened by a factor equal to the process gain. No derivative action is required.

Part 4: Feed forward

You’ve seen the equations, but have you thought about how those elements work together? Part 4: Feed forward

In the first three blog posts (see Part 1, Part 2, and Part 3) we covered the basics of PID math. We started with the basic proportional-only controller and worked in the integral and derivative components. Well before get too far, let’s review the proportional-only controller:

u(t) = Kpe(t)
u(t) is the output of the controller at the end of the scan. If the output of the controller is a valve, then the output is the valve position that the controller is requesting after it has seen the inputs.

Kpe(t) is the proportional component, the P in PID. e(t), usually called “error,” is simply the difference between the setpoint and the process variable. Kp gain is a factor that is multiplied by the error to give you the new output—the new valve position. It’s that simple. The error at that instant of the scan is calculated and the new output is calculated.

The pseudo code that we discussed was:

Error = Setpoint – ProcessValueOutput = K * ErrorWith this code the output changes immediately after the error changes. I like to use a cruise control on a car as an example. As soon as the car starts to slow down as it starts to climb a hill, the change in error (speed) immediately causes the output to change.

But what if you know that the speed is about to slow down? What if you can see the hill coming? That’s where feed forward comes in. The first step is detecting a condition that will affect the process value. This can be an upstream flow rate that affects a level controller, a pressure change that affects a flow controller or any number of variables. The important thing is that the feed forward signal has to have a predictable affect on the controlled variable.

The math behind it is conceptually pretty simple. The feed forward signal is multiplied by a gain and then added directly to the output:

Error = Setpoint – ProcessValueOutput = K * Error + FeedForward * KfThat way as long as the feed forward signal doesn’t change, the controller is not affected. But, a change in the feed forward signal immediately makes a proportional type shift in the output.

The math does get more complicated when the time that it takes for the signal to affect the process value has to be considered. In that case a lead or lag calculation must be done to slow down or speed up the feed forward signal.

Part 3: More on derivative control

To investigate how derivative action works, let’s look at a proportional derivative or PD controller. PID controllers are far more common than PD alone, but we already have an understanding of the integral component’s effects from the first two parts of this series, so we don’t need to review it again.

For a PD controller, we add the derivative of the error into the equation. Similar to what we discussed in the previous posts, we’re not really interested in deriving a derivative of the error function. Conceptually, the derivative in this case refers to how fast the error is changing. So, if we take the change in error divided by the change in time we get the slope.

To explain how this works, let’s look at the pseudo code for this controller. The calculation of error is the same as before: setpoint minus process value. Since the derivative reduces down to the change in error, the output is now the same proportional component as before: gain times error. The current error minus last error is multiplied by the gain and divided by the derivative time constant. The current error is stored in last error for use in the next scan.

Error : = Setpoint – ProcessValue;

Output : = K * Error + K/tau_i * (Error – LastError);

LastError : = Error; 


So what does this mean?

The proportional component is affected by the error at that time, in the present. The integral component is affected by an accumulation of the error, or the past. The derivative component is a measure of how fast the error is changing, or a prediction of the future error.

How is this prediction of the future used? At first glance you might think that this term would be used to get you to your setpoint that much faster. But, that is not really the case. In practice, the derivative component is used to detect when the process variable is changing too fast, and it puts the brakes on to prevent overshooting the setpoint.

So if the derivative component acts as brakes on the momentum, how does it get you to the setpoint faster? It does this by allowing you to use a higher proportional gain to get you there quickly, but dampening the overshoot that would normally make that level of gain unstable.

The tuning constants for derivative control are typically the same units as the time constant for reset. A couple of other considerations though are important. On many controllers the derivative term is filtered independently. This prevents signal noise or spurious disturbances from being interpreted as a change in momentum, which causes the derivative action to overreact. Also, on some controllers the derivative does not actually derive from the error, but instead on the process variable signal alone. This prevents a change is set point from being seen as a change in momentum.

Part 2: Adding integral and derivative to the mix.

Last week we started with proportional. (Read Part 1) Now let’s look at the next part of the equation, the integral component:

The most striking (and scariest) part of this equation is the big integral sign in the middle. If you’ve had high school calculus, you think to yourself, “I’ve got this. Integrals don’t scare me. I just need to find the area under the curve from time zero to time t of the error function.”

But, this is the real world. What is time zero? How do I integrate an error function? The good news is that the real definition is much simpler than calculus. What the PID function does is take a portion of the error and adds it to a running total. This running total, sometimes called reset, is added to the output. Since reset increases or decreases a little at a time, it adjusts the output of the valve incrementally each scan.

For a PI controller, the two factors that we have covered so far are K_p and K_i, but if you look at the faceplate for most industrial systems, there is only one K (gain) that has no units, and a τ_i (integral time constant) designated as seconds or minutes per repeat. So, a little translation is required. Most industrial controllers don’t use the independent form of the equation shown above. Instead, they use the dependent form of the equation: 

The K is typically the same as the proportional gain, K_p.  The factor τ_i determines how much of the error is going to be applied to the accumulated reset on each scan. So in the big mathy equation, K_i can essentially be replaced by the faceplate parameters:  K⁄τ_i.

What’s important to understand from this is that the gain that affects the proportional action of a controller also affects the integral action. But, the integral time constant τ_i only affects the integral action.

In pseudo code this would look like:

Error := Setpoint - ProcessValue;
Reset := Reset + K/tau_i * Error;
Output := K * Error + Reset;
The unit’s minutes per repeat for the integral time constant τ_i  comes from the fact that if the error stays constant, that is how long would it take for the integral accumulator to repeat the proportional change in output.

Note: Another way of specifying the integral tuning parameter is in seconds, and then it is the reciprocal of seconds per repeat. If the integral time constant is in seconds, the bigger the number, then the slower the response. If the integral is in seconds per repeat, the opposite is true.

Derivative
Now let’s look at derivative:

Again, this is another mathy looking equation with a simple explanation. The mathy definition first, the output will be changed by the derivative (or rate of change) of the error function. What this means is that the output will be affected by the change in error from one scan to another. Adding this to our pseudocode gives us:

Error := Setpoint - ProcessValue;
Reset := Reset + K/tau_i * Error;
Output := K * Error + Reset + ((PreError – Error) * K/tau_d));

PreError := Error;  //Save the error for the next scan
What is intended is for the output to change as soon as the process variable begins to move either toward or away from the setpoint. What results can be a very quick response to a change in error from one scan to another.

The intention of derivative action is to respond to changes as they begin to occur. For example, if a temperature is starting to rise, the valve will begin to open as soon as it sees the change instead of waiting for it to cross a setpoint. This can result in a very rapid response to a small change. This rapid response can become unstable if there is noise in the process variable or on a setpoint change. So, the derivative action is often filtered separately and is sometimes calculated on PV only to ignore setpoint changes.

Summary
So now we have reviewed the three components of the PID algorithm. One way they have been described is in terms of the flow of time. P depends on the present error, I on the accumulation of past errors, and D on the prediction of future errors based on current rate of change.