Friday, 22 August 2014

Programmable Automation Controller (PAC)

Programmable Automation Controller (PAC):

Programmable automation controller (PAC) systems consist of PAC modules, each of which performs a specific function. PAC systems are used in motion control, machine control, machine vision, and other industrial control applications. They include the following types of PAC modules: analog I/O modules, digital I/O modules, relay modules, counter modules, serial modules, servo or stepper controller modules, timer modules, and data acquisition modules. PAC systems with analog I/O modules are used to measure and control industrial automation devices such sensors and actuators. They can also be used to condition high or low voltage signals, thermocouples, resistance temperature detectors (RTD) and strain gauges. PAC systems with digital I/O modules are used to measure and control industrial automation devices such sensors and actuators. PAC systems with data acquisition modules digitize and process multiple sensor or signal inputs for monitoring, analyzing and/or controlling systems and processes. PAC systems with serial modules coordinate the flow of data, control signals, and timing information between data terminal equipment (DTE) and data communication equipment (DCE).  




Programmable automation controller (PAC) systems have backplane slots for adding input/output (I/O) modules and differ by backplane bus type. The VersaModule Eurocard bus (VMEbus) is a popular, 32-bit bus used in industrial, commercial and military applications. VME extensions for instrumentation (VXI) is an electrical and mechanical standard used with automatic test equipment (ATE). Peripheral component interconnect (PCI) is a local bus system designed for high-end computer systems. Compact PCI (cPCI) uses the electrical standards of the PCI bus, but is packaged in a Eurocard. PCI extensions for instrumentation (PXI) is a superset of CompactPCI that adds timing and triggering functions. In terms of ports and interfaces, some programmable automation controller (PAC) systems have an Ethernet, universal serial bus (USB), or video graphics array (VGA) port. Others have a keyboard, mouse, or printer port. Serial PAC systems have RS232, RS422 or RS485 ports. IEEE 1394 or FireWire® (Apple Computer, Inc.) ports are also available.

Programmable automation controller (PAC) systems use popular communication standards and network protocols. Ethernet is a local area network (LAN) protocol that supports data transfer rates of 10 Mbps. Transmission control protocol/Internet protocol (TCP/IP) is the basis for standard Internet protocols. Controller area network bus (CANbus) is a high-speed, serial data network designed for harsh electrical environments and real-time control applications. DeviceNet uses the CAN network protocol to connect industrial devices to PAC modules. The process fieldbus or PROFIBUS is an open-communication standard used in factory automation, process automation, motion control, and safety applications. The MODBUS® (Modbus-IDA) protocol is an open-standard, vendor-neutral messaging structure for communication between intelligent devices. OPC defines a set of standard interfaces based upon OLE/COM technology and can be re-used by human machine interface (HMI) and supervisory control and data acquisition (SCADA) applications. Java® (Sun Microsystems, Inc.) database connectivity (JDBC) allows PAC modules to access to external structured query language (SQL) databases.  

Selection:

Selecting programmable automation controller (PAC) systems requires an analysis of regulatory requirements and special features. PAC systems for international markets should comply with Restriction of Hazardous Substances (RoHS), a European Union (EU) directive that requires all manufacturers of electronic and electrical equipment sold in Europe to demonstrate that their products contain only minimal levels of hazardous substances such as lead and mercury. The EU’s Waste Electrical and Electronics Equipment Regulations (WEEE Regulations) are designed to encourage the reuse, recycling and recovery of electrical and electronic equipment such as PAC systems.

Features of PAC:

Capable of real time communication
Fast boot speed
Achievable deterministic control
Multi-function
Open communication standards
Integrated development environment
Ability to run PC-based control software such as Visual Basic.NET, Visual C#, Embedded Visual 
C++, SCADA software 
Rich I/O Expansion Ability 
 Ethernet 
 RS-232/422/485 
 CAN Bus 

Key Advantages of a PAC

These defining characteristics also describe the key advantages of using PACs in industrial applications:

A single controller with integrated software handles multiple functions across multiple domains.

Complex and changing requirements can be met with little additional cost.

Modular designs make expansion easier.

Networking and communication capabilities link disparate systems and provide more accurate 
and timely data.

Total system cost is lowered, because integrated hardware and software are less expensive, and because development and integration time is reduced.

Modular design improves cash flow.


In summary, PACs now provide the multi-function, multi-domain, multi-tasking, modular, standards-based and efficient control, networking, and communications processor most suited to today's industrial applications.


Thursday, 21 August 2014

Is there any difference between PLC and PAC?


PLCs (programmable logic controllers) have been around for more than 40 years, recent advances have greatly increased their capabilities, blurring the line between a PLC and PAC (programmable automation controller). What differences remain between these two categories? Is there a performance gap between PLCs and PACs that users should keep in mind when choosing the best solution for a particular application?

PLCs were created in the late 1960s to replace relay-based systems. Conceptually they were similar and used ladder logic that mimicked the appearance of wiring diagrams engineers used to represent physical relays and timers, and the connections among them. Early PLCs required dedicated proprietary terminals for programming, had very limited memory, and lacked remote I/O.
By the 1980s, PC-based software was introduced for programming PLCs, which had become faster and had added more features as years passed. Since then, many new technologies have been applied to PLCs, greatly expanding their capabilities on an almost continuous basis.
PACs are relatively new to the automation market, using the term coined by the market research firm ARC in 2001. Since then, there has been no specific agreement as to what differentiates a PAC from a PLC. Some users feel the term PAC is simply marketing jargon to describe highly advanced PLCs, while others believe there is a definite distinction between a PLC and a PAC. In any case, defining exactly what constitutes a PAC isn’t as important as having users understand the types of applications for which each is best suited.

Defining the needs of users

Generally, PACs and PLCs serve the same purpose. Both are primarily used to perform: automation, process control, data acquisition functions such as digital and analogue control, serial string handling, PID, motion control, and machine vision. Most suppliers carry a wide range of PLCs and PACs, which can make it difficult to choose the right product for a particular application. 

PLCs are often programmed in ladder logic, a graphical programming language resembling the rails and rungs of ladders that is designed to emulate old electrical relay wiring diagrams .Typically they have been best suited for machine control, both simple and high speed. Common characteristics of these PLCs are simple program execution scans, limited memory, and a focus on discrete I/O with on/off control.

On the other hand, PAC control programs are usually developed with more generic software tools that permit the designed program to be shared across several different machines, processors, HMI terminals or other components in the control system architecture.It is geared more toward complex automation system architectures composed of a number of PC-based software applications, including HMI (human machine interface) functions, asset management, historian, advanced process control (APC), and others. A PAC is also generally a better fit for applications with extensive process control requirements, as PACs are better able to handle analog I/O and related control functions. A PAC tends to provide greater flexibility in programming, larger memory capacity, better interoperability, and more features and functions in general.

Unlike PLCs, which constantly scan all the I/O inputs in the control system at very high rates of speed, PACs utilize a single tag name database and a logical address system to identify and map I/O points as needed.

As a result of having an architecture based on ladder logic and a focus on discrete on-off control, expanding a PLC beyond its original capabilities—such as adding extensive analog control capabilities—has often proved difficult. In older or lower-end PLCs, separate hardware cards usually had to be added and programmed to accomplish functions outside the PLC’s core focus. These functions included, but weren’t limited to, networking multiple components, extensive process control, and sophisticated data manipulation.


To answer the demand for more PLC functionality, manufacturers have added features and capabilities. For example, older PLCs could only accommodate a relatively small number of PID loops, typically about 16, while new PLCs can handle thousands of such loops. Newer PLCs often feature multiple communication ports, and greatly increased memory as compared to older models (see Figure 1).
On the other hand, PACs provide a more open architecture and modular design to facilitate communication and interoperability with other devices, networks, and enterprise systems. They can be easily used for communicating, monitoring, and control across various networks and devices because they employ standard protocols and network technologies such as Ethernet, OPC, and SQL.
PACs also offer a single platform that operates in multiple domains such as motion, discrete, and process control. Moreover, the modular design of a PAC simplifies system expansion and makes adding and removing sensors and other devices easy, often eliminating the need to disconnect wiring. Their modular design makes it easy to add and effectively monitor and control thousands of I/O points, a task beyond the reach of most PLCs.
Another key differentiator between a PLC and a PAC is the tag-based programming offered by a PAC. With a PAC, a single tag-name database can be used for development, with one software package capable of programming multiple models. Tags, or descriptive names, can be assigned to functions before tying to specific I/O or memory addresses. This makes PAC programming highly flexible, with easy scalability to larger systems.

Depends on Application:

For simple applications, such as controlling a basic machine, a PLC is a better choice than a PAC. Likewise, for most applications that consist primarily of discrete I/O, a PLC is the best choice—unless there are other extraordinary requirements such as extensive data handling and manipulation.

If the application includes monitoring and control of a large number of analog I/O points, then a PAC is generally the better solution. This is also the case when the application encompasses an entire plant or factory floor, a situation that typically calls for distributed I/O in large numbers, along with extensive loop control—functions better suited to a PAC than to a PLC.
The confusion arises when an application lies somewhere between simple and complex, and in these circumstances a high-end PLC or a low-end PAC platform will work. Ultimately, a choice between the two will be defined strictly by other factors outside of specific application requirements. These factors include, but aren’t limited to, past experience with each platform, price, the level of local support, and anticipated future growth and changes.
Once a decision is made between a PLC or a PAC, users typically have a wide range of products from which to choose, even if only a single vendor is being considered. That’s because PLCs and PACs are typically designed in systems of scale, meaning there is a family of controllers to choose from that range from lower I/O count to larger system capacity, with correspondingly more features and functions as I/O counts and prices increase.



Wednesday, 20 August 2014

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.











Tuesday, 19 August 2014

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.
plc input cards

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
DC input card
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.





Monday, 18 August 2014

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.

Figure 1: Graph shows sales of robots by region 2010-2015, according to IFR World Robotics Report 2012. Courtesy: Cambashi Observatory

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?
Figure 2: Key industrial automation component technologies include development tools, software, automation hardware and computers, information integration, and networking. Courtesy: Cambashi Observatory

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.
Figure 3: Current penetration of robots by industry shows leadership by electrical and electronics, motor vehicles, and automotive parts industries, according to IFR World Robotics Report 2012. Courtesy: Cambashi Observatory

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!

Friday, 15 August 2014

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.

Thursday, 14 August 2014

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 1Part 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.